linux.kernel - 26 new messages in 15 topics - digest

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

linux.kernel@googlegroups.com

Today's topics:

* [PATCHSET] mremap/mmap mess - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/20faef31b43fde88?hl=en
* Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33) - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/744b2baf61c0ac2a?hl=en
* kmemcheck: make bitfield annotations truly no-ops when disabled - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/9319cde622ba276e?hl=en
* smc91x: fix unused flags warnings on UP systems - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a36534900026e060?hl=en
* gpiolib: gpio naming in sysfs - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a04fa922e483d9ce?hl=en
* cfq-iosched: Take care of corner cases of group losing share due to deletion
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/562c03960036639a?hl=en
* OOM kernel behaviour - 2.6.32 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/495e2a01ee7fcfbf?hl=en
* tracing: Add pipe_close interface - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a8ceb009729186a5?hl=en
* pass upstream rev to scripts/get_maintainer.pl - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/3e473de10bd2ff3c?hl=en
* [GIT PULL][v2.6.33] tracing: Remove comparing of NULL to va_list in trace_
array_vprintk() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/59b320cbcd591edd?hl=en
* KVM related crash - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8d01a54e0dc51146?hl=en
* firmware/WHENCE: Use consistent field name for licence information - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e1fab013f406f56a?hl=en
* audit: Fixes and tasklist_lock -> RCU conversion - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fe7a907971c3fefb?hl=en
* (none) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9abaed68cf317095?hl=en
* linux-next: manual merge of the tty tree with the trivial tree - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/7289155079fde012?hl=en

==============================================================================
TOPIC: [PATCHSET] mremap/mmap mess
http://groups.google.com/group/linux.kernel/t/20faef31b43fde88?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 9 2009 5:40 am
From: Peter Zijlstra

On Wed, 2009-12-09 at 13:12 +0000, Hugh Dickins wrote:
> On Wed, 9 Dec 2009, Peter Zijlstra wrote:

> > /me ponders.. doesn't the binfmt engine cruft need the args in place in
> > order to execute?
>
> Hardly looked, Al will be more up to date with all the grisly details.
>
> The "binfmt engine cruft" being search_binary_handler()? I think the
> args have to be "ready to go" before that, but that's different from
> the new mm actually being used as an mm before that. It used not to
> be used early, but from 2.6.23 on it is used early, via get_user_pages.

Yeah, explicitly the fn() call in there which will mostly land you
load_elf_binary(). After that I loose track.

> > That is, IIRC the problem is that you need to have the argc/env in place
> > for the binfmt engine thing, and need to have ran the binfmt engine
> > thing before you know the personality.
>
> It is a problem that personality is discovered late in the sequence,
> and that is a considerable part of what Al is up against.
>
> >
> > As to your idea, if that were feasible we could do without the copy and
> > simply steal the pages directly from the old mm.
>
> Perhaps, but I think that would lead to a gradual accumulation
> of more and more pages pinned in memory by scattered references.

Well, IF the binfmt stuff can deal with the arrays being in the old mm
then it doesn't need to pin them I think, but I really don't know how
all this binfmt stuff works.

Reading fs/binfmt_elf.c:load_elf_binary() it looks like there might be a
spot where the personality is know and we still have the old mm around,
maybe we can hook in there -- we'd need to visit all binfmt though..

If we can make the binfmt stuff pass the correct location to
flush_old_exec() we could do the copy there.

> I Cc'ed you really because I wasn't much involved in the variable
> length arg discussions, and don't remember how important swappability
> was viewed at the time. It is a significant feature of what you and
> Ollie ended up with, so I'm guessing it was then viewed as essential.
> That would be my view.
>
> But now it's suggested that the TLB+cache effects of using an mm there
> are counter-productive, and better to forget swappability: well, I want
> to keep it, and Al is making a brave effort to hold on to it, but I'm
> wary of the weirdness involved.

Right, the swappability is key, without that you can easily run the
kernel into the ground if you don't have a limit on the argv/env arrays.
And not having a limit was the whole point.

--
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, Dec 9 2009 5:50 am
From: Al Viro

On Wed, Dec 09, 2009 at 11:43:57AM +0000, Hugh Dickins wrote:
> ... my hair ;-)
> I have to say, Dr Frankenstein, that this idea fills me with dread.
>
> I'm not saying it's impossible, but the resulting creature sounds like
> it's going to be special in several easily-buggy hard-to-maintain ways.
>
> I think you already realize that shmem file pages (shared) live by
> different rules from anonymous pages (COWed): they're both swappable,
> but switching a group of pages from one to the other is going to be
> weird new territory. (In fairness, my suggestion involves some
> weird new territory too, but considerably less scary to me.)

Umm... Note that these guys are considerably simpler than shmem; _nothing_
will have them mapped anywhere until after that eviction and nothing will
modify their address_space in any way (no truncation, etc.).

And no, I'm not particulary happy about the picture - the sight of, ahem,
locking hierarcy rules in mm/filemap.c alone is a cause for dread. It had
been a while since I'd done any serious RTFS on mm/*, so...

Anyway, it's obviously *not* -rc1 fodder at the moment. So what I'm going
to do is to leave that one as it is in mainline, push the rest of mmap/mremap
stuff to Linus later today and get to VFS and audit queues. After the -rc1,
OTOH...
--
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: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)
http://groups.google.com/group/linux.kernel/t/744b2baf61c0ac2a?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 9 2009 5:40 am
From: Mark Brown

On Tue, Dec 08, 2009 at 09:35:59PM -0500, Alan Stern wrote:
> On Tue, 8 Dec 2009, Linus Torvalds wrote:

> > It's just that I think the "looping over children" is ugly, when I think
> > that by doing it the other way around you can make the code simpler and
> > only depend on the PM device list and a simple parent pointer access.

> I agree that it is uglier. The only advantage is in handling
> asynchronous non-tree suspend dependencies, of which we probably won't
> have very many. In fact, I don't know of _any_ offhand.

There's some potential for this in embedded audio - it wants to bring
down the entire embedded audio subsystem at once before the individual
devices (and their parents) get suspended since bringing them down out
of sync can result in audible artifacts. Depending on the system the
suspend may take a noticable amount of time so it'd be nice to be able
to run it asynchronously, though we don't currently do so.

At the minute we get away with this mostly through not being able to
represent the cases that are likely to actually trip up over it.

> Interestingly, this non-tree dependency problem does not affect resume.

Embedded audio does potentially - the resume needs all the individual
devices in the subsystem and can take a substantial proportion of the
overall resume time. Currently we get away with a combination of
assuming that all the drivers are live when we decide to start resuming
them and using the ALSA userspace API to deal with bringing the resume
out of line, but it's not ideal.
--
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: kmemcheck: make bitfield annotations truly no-ops when disabled
http://groups.google.com/group/linux.kernel/t/9319cde622ba276e?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 9 2009 5:40 am
From: Pekka Enberg

Andrew Morton kirjoitti:
> On Sun, 6 Dec 2009 18:42:13 +0100
> Vegard Nossum <vegard.nossum@gmail.com> wrote:
>
>> It turns out that even zero-sized struct members (int foo[0];) will affect
>> the struct layout, causing us in particular to lose 4 bytes in struct sock.
>>
>> This patch fixes the regression in CONFIG_KMEMCHECK=n case.
>
> Which kernel version is the regression relative to?

AFAICT, it dates back to 2.6.31 when kmemcheck was introduced in
mainline. Vegard?

> Should we backport this into 2.6.32.x?

I guess so. Eric, how bad is the regression?

Pekka
--
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, Dec 9 2009 6:00 am
From: Eric Dumazet

Le 09/12/2009 14:31, Pekka Enberg a écrit :

>
> I guess so. Eric, how bad is the regression?
>

Not too bad, skbuff one was separately addressed.

http://git2.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=14d18a81b5171d4433e41129619c75748b4f4d26
--
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: smc91x: fix unused flags warnings on UP systems
http://groups.google.com/group/linux.kernel/t/a36534900026e060?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 9 2009 5:50 am
From: Mike Frysinger

Local flags variables will be declared whenever these functions get used,
but obviously on UP systems the flags parameter won't be touched. So add
some dummy ops that get optimized away anyways to satisfy gcc's warnings.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/net/smc91x.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
index ae4983a..b0c92b6 100644
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -534,9 +534,9 @@ static inline void smc_rcv(struct net_device *dev)
#define smc_special_lock(lock, flags) spin_lock_irqsave(lock, flags)
#define smc_special_unlock(lock, flags) spin_unlock_irqrestore(lock, flags)
#else
-#define smc_special_trylock(lock, flags) (1)
-#define smc_special_lock(lock, flags) do { } while (0)
-#define smc_special_unlock(lock, flags) do { } while (0)
+#define smc_special_trylock(lock, flags) (flags == flags)
+#define smc_special_lock(lock, flags) do { flags = 0; } while (0)
+#define smc_special_unlock(lock, flags) do { flags = 0; } while (0)