linux.kernel - 5 new messages in 4 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* usbnet: Convert dev(dbg|err|warn|info) macros to netdev_<level> - 2 messages,
1 author
http://groups.google.com/group/linux.kernel/t/7ae1dd4510edc70f?hl=en
* oom: badness heuristic rewrite - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d037a724c15ddb78?hl=en
* linux-next: build failure after final merge (net tree) - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/d8ca3acdfce5b045?hl=en
* cpm_uart: Use resource_size() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/16bbf8458cb2c9b9?hl=en

==============================================================================
TOPIC: usbnet: Convert dev(dbg|err|warn|info) macros to netdev_<level>
http://groups.google.com/group/linux.kernel/t/7ae1dd4510edc70f?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 16 2010 11:40 pm
From: David Miller

From: Joe Perches <joe@perches.com>
Date: Mon, 15 Feb 2010 00:25:11 -0800

> These macros are too similar to the dev_<level> equivalents
> but take a usbnet * argument. Convert them to the recently
> introduced netdev_<level> macros and remove the old macros.
>
> The old macros had "\n" appended to the format string.
> Add the "\n" to the converted uses.
>
> Some existing uses of the dev<foo> macros in cdc_eem.c
> probably mistakenly had trailing "\n". No "\n" added there.
>
> Fix net1080 this/other log message inversion.
>
> Signed-off-by: Joe Perches <joe@perches.com>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Wed, Feb 17 2010 12:10 am
From: David Miller

I had to revert this series, the build fails:

drivers/net/wireless/rndis_wlan.c: In function 'rndis_query_oid':
drivers/net/wireless/rndis_wlan.c:731: error: implicit declaration of function 'devdbg'
drivers/net/wireless/rndis_wlan.c: In function 'set_essid':
drivers/net/wireless/rndis_wlan.c:948: error: implicit declaration of function 'devwarn'
drivers/net/wireless/rndis_wlan.c: In function 'rndis_connect':
drivers/net/wireless/rndis_wlan.c:1796: error: implicit declaration of function 'deverr'
drivers/net/wireless/rndis_wlan.c: In function 'rndis_wlan_auth_indication':
drivers/net/wireless/rndis_wlan.c:2273: error: implicit declaration of function 'devinfo'
make[3]: *** [drivers/net/wireless/rndis_wlan.o] Error 1
make[3]: *** Waiting for unfinished jobs....
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: oom: badness heuristic rewrite
http://groups.google.com/group/linux.kernel/t/d037a724c15ddb78?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 16 2010 11:50 pm
From: Minchan Kim

On Wed, Feb 17, 2010 at 6:41 AM, David Rientjes <rientjes@google.com> wrote:
> On Tue, 16 Feb 2010, Minchan Kim wrote:
>
>> > Again, I'd encourage you to look at this as only a slight penalization
>> > rather than a policy that strictly needs to be enforced.  If it were
>> > strictly enforced, it would be a prerequisite for selection if such a task
>> > were to exist; in my implementation, it is part of the heuristic.
>>
>> Okay. I can think it of slight penalization in this patch.
>> But in current OOM logic, we try to kill child instead of forkbomb
>> itself. My concern was that.
>
> We still do with my rewrite, that is handled in oom_kill_process().  The
> forkbomb penalization takes place in badness().

I thought this patch is closely related to [patch 2/7].
I can move this discussion to [patch 2/7] if you want.
Another guys already pointed out why we care child.

>
>> 1. Forkbomb A task makes 2000 children in a second.
>> 2. 2000 children has almost same memory usage. I know another factors
>> affect oom_score. but in here, I assume all of children have almost same
>> badness score.
>> 3. Your heuristic penalizes A task so it would be detected as forkbomb.
>> 4. So OOM killer select A task as bad task.
>> 5. oom_kill_process kills high badness one of children, _NOT_ task A
>> itself. Unfortunately high badness child doesn't has big memory usage
>> compared to sibling. It means sooner or later we would need OOM again.
>>
>
> Couple points: killing a task with a comparatively small rss and swap
> usage to the parent does not imply that we need the call the oom killer
> again later, killing the child will allow for future memory freeing that
> may be all that is necessary.  If the parent continues to fork, that will
> continue to be an issue, but the constant killing of its children should
> allow the user to intervene without bring the system to a grinding halt.

I said this scenario is BUGGY forkbomb process. It will fork + exec continuously
if it isn't killed. How does user intervene to fix the system?
System was almost hang due to unresponsive.

For extreme example,
User is writing some important document by OpenOffice and
he decided to execute hackbench 1000000 process 1000000.

Could user save his important office data without halt if we kill
child continuously?
I think this scenario can be happened enough if the user didn't know
parameter of hackbench.

> I'd strongly prefer to kill a child from a forkbombing task, however, than
> an innocent application that has been running for days or weeks only to
> find that the forkbombing parent will consume its memory as well and then
> need have its children killed.  Secondly, the forkbomb detection does not

Okay.
consider my argue related to 2/7, pz.

> simply require 2000 children to be forked in a second, it requires
> oom_forkbomb_thres children that have called execve(), i.e. they have
> seperate address spaces, to have a runtime of less than one second.
>
>> My point was 5.
>>
>> 1. oom_kill_process have to take a long time to scan tasklist for
>> selecting just one high badness task. Okay. It's right since OOM system
>> hang is much bad and it would be better to kill just first task(ie,
>> random one) in tasklist.
>>
>> 2. But in above scenario, sibling have almost same memory. So we would
>> need OOM again sooner or later and OOM logic could do above scenario
>> repeatably.
>>
>
> In Rik's web server example, this is the preferred outcome: kill a thread
> handling a single client connection rather than kill a "legitimate"
> forkbombing server to make the entire service unresponsive.
>
>> I said _BUGGY_ forkbomb task. That's because Rik's example isn't buggy
>> task. Administrator already knows apache can make many task in a second.
>> So he can handle it by your oom_forkbomb_thres knob. It's goal of your
>> knob.
>>
>
> We can't force all web servers to tune oom_forkbomb_thres.
>
>> So my suggestion is following as.
>>
>> I assume normal forkbomb tasks are handled well by admin who use your
>> oom_forkbom_thres. The remained problem is just BUGGY forkbomb process.
>> So if your logic selects same victim task as forkbomb by your heuristic
>> and it's 5th time continuously in 10 second, let's kill forkbomb instead
>> of child.
>>
>> tsk = select_victim_task(&cause);
>> if (tsk == last_victim_tsk && cause == BUGGY_FORKBOMB)
>>       if (++count == 5 && time_since_first_detect_forkbomb <= 10*HZ)
>>               kill(tsk);
>> else {
>>    last_victim_tsk = NULL; count = 0; time_since... = 0;
>>    kill(tsk's child);
>> }
>>
>> It's just example of my concern. It might never good solution.
>> What I mean is just whether we have to care this.
>>
>
> This unfairly penalizes tasks that have a large number of execve()
> children, we can't possibly know how to define BUGGY_FORKBOMB.  In other
> words, a system-wide forkbombing policy in the oom killer will always have
> a chance of killing a legitimate task, such as a web server, that will be
> an undesired result.  Setting the parent to OOM_DISABLE isn't really an
> option in this case since that value is inherited by children and would
> need to explicitly be cleared by each thread prior to execve(); this is
> one of the reasons why I proposed /proc/pid/oom_adj_child a few months
> ago, but it wasn't well received.
>

I don't want to annoy you if others guys don't have any complain.
If it has a problem in future, at that time we could discuss further
in detail with
real example.
I hope we don't received any complain report. :)

Thanks for good discussion, David.

--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next: build failure after final merge (net tree)
http://groups.google.com/group/linux.kernel/t/d8ca3acdfce5b045?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 17 2010 12:00 am
From: Stephen Rothwell

On Tue, 16 Feb 2010 23:11:09 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Feb 2010 17:40:15 +1100
>
> > After merging, today's linux-next build (sparc64 defconfig) failed like
> > this:
>
> Fixed for at least 6 hours:

Excellent, thanks.

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

==============================================================================
TOPIC: cpm_uart: Use resource_size()
http://groups.google.com/group/linux.kernel/t/16bbf8458cb2c9b9?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 17 2010 12:10 am
From: Tobias Klauser

Use the resource_size function instead of manually calculating the
resource size. This reduces the chance of introducing off-by-one errors.

Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index a9802e7..722eac1 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -61,7 +61,7 @@ void __iomem *cpm_uart_map_pram(struct uart_cpm_port *port,
void __iomem *pram;
unsigned long offset;
struct resource res;
- unsigned long len;
+ resource_size_t len;

/* Don't remap parameter RAM if it has already been initialized
* during console setup.
@@ -74,7 +74,7 @@ void __iomem *cpm_uart_map_pram(struct uart_cpm_port *port,
if (of_address_to_resource(np, 1, &res))
return NULL;

- len = 1 + res.end - res.start;
+ len = resource_size(&res);
pram = ioremap(res.start, len);
if (!pram)
return NULL;
--
1.6.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en