twitter: linux.kernel - 26 new messages in 19 topics

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

Today's topics:

* busy inodes -> ext3 umount crash - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f78e1c3f6ea5fa8a?hl=en
* repost - RFC [Patch] Remove "please try 'cgroup_disable=memory' option if
you don't want memory cgroups" printk at boot time. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e50341f9a5d4e4cc?hl=en
* uml: Drop private round_down definition - 5 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a915b824f988d2b2?hl=en
* Taming execve, setuid, and LSMs - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/455440aeaf3d02e1?hl=en
* Fix typo in percpu.h - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2f363eb64fc6b6ab?hl=en
* [PATCH] lockdep fix incorrect percpu usage - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1a391d1f6149f0c6?hl=en
* [PATCH 2.6.29.x - 2.6.31.1] module: fix __module_ref_addr() - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/d4f570ea2ea35f52?hl=en
* [PATCH] modules fix incorrect percpu usage - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c98cef4d5381474f?hl=en
* uml: Fix build breakage after slab.h changes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1348b2d59567e510?hl=en
* mx5: Add USB device definitions for Freescale MX51 Babbage HW - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/6f3f19df69e3942d?hl=en
* Avoid the use of congestion_wait under zone pressure - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/65204523a890609a?hl=en
* ACPI: DMI init_set_sci_en_on_resume for multiple Lenovo ThinkPads - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/5a062fe48888bc56?hl=en
* x86: correctly wire up the newuname system call - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3a3a1eba22964661?hl=en
* acpi: Fall back to manually changing SCI_EN - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/daa92e2a7f5dfc23?hl=en
* Staging: comedi: drivers: fix coding style issues in das08.c - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/d466bde5d94e110f?hl=en
* start_kernel(): bug: interrupts were enabled early - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cf6012901770396c?hl=en
* change alloc function in pcpu_alloc_pages - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/271c90dc271c12b7?hl=en
* rcu: shrink rcutiny by making synchronize_rcu_bh() be inline - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/4d4c698fd760ee6e?hl=en
* Add a global synchronization point for pvclock - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/76b116df6177d9b9?hl=en

==============================================================================
TOPIC: busy inodes -> ext3 umount crash
http://groups.google.com/group/linux.kernel/t/f78e1c3f6ea5fa8a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 20 2010 7:20 am
From: Jiri Slaby

On 04/19/2010 04:33 PM, Jiri Slaby wrote:
> The trigger for busy inodes is as simple as (I=initialization done only
> once):
> I> # dd if=/dev/zero of=/dev/shm/ext3 bs=1024 count=1 seek=$((100*1024))
> I> # mkfs.ext3 -m 0 /dev/shm/ext3
> # mount -oloop /dev/shm/ext3 /mnt/c
> # umount /mnt/c
> # dmesg|tail
> VFS: Busy inodes after unmount of loop0. Self-destruct in 5 seconds.
> Have a nice day...
>
> (The printk time varies -- this sequence really suffices.)

Well, this happens only after gnome-session is started and it's fuzzy --
sometimes it happens, sometimes not. I didn't find 100% trigger yet.

>> So if you can easily reproduce
>> the "busy inodes" message then I'd start with debugging that one. Do you
>> see it also with vanilla kernels?

Vanilla seems not to be affected. It's in next/master already though
(2603ecd9). I'll investigate it further later.
--
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: repost - RFC [Patch] Remove "please try 'cgroup_disable=memory' option
if you don't want memory cgroups" printk at boot time.
http://groups.google.com/group/linux.kernel/t/e50341f9a5d4e4cc?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 20 2010 7:30 am
From: Larry Woodman

Re-posting, cc'ing linux-mm as requested:

We are considering removing this printk at boot time from RHEL because
it will confuse customers, encourage them to change the boot parameters
and generate extraneous support calls. Its documented in
Documentation/kernel-parameters.txt anyway. Any thoughts???

Larry Woodman

==============================================================================
TOPIC: uml: Drop private round_down definition
http://groups.google.com/group/linux.kernel/t/a915b824f988d2b2?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Apr 20 2010 7:30 am
From: Jeff Dike

On Tue, Apr 20, 2010 at 04:33:58PM +0800, Amerigo Wang wrote:
> On Mon, Apr 19, 2010 at 11:53:05PM +0200, Jan Kiszka wrote:
> >Already defined in kernel.h. The official version assumes that 'n' is
> >power of two - which it is in our case.
> >
> >Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
> >---
> > arch/um/sys-x86_64/signal.c | 2 --
> > 1 files changed, 0 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/um/sys-x86_64/signal.c b/arch/um/sys-x86_64/signal.c
> >index 1a899a7..07797d1 100644
> >--- a/arch/um/sys-x86_64/signal.c
> >+++ b/arch/um/sys-x86_64/signal.c
> >@@ -165,8 +165,6 @@ struct rt_sigframe
> > struct _fpstate fpstate;
> > };
> >
> >-#define round_down(m, n) (((m) / (n)) * (n))
> >-
> > int setup_signal_stack_si(unsigned long stack_top, int sig,
> > struct k_sigaction *ka, struct pt_regs * regs,
> > siginfo_t *info, sigset_t *set)
>
> Shouldn't this signal.c #include <linux/kernel.h>?

I agree - if this is going to depend on kernel.h, it should be
explicitly included.

Jeff
--
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 5 ==
Date: Tues, Apr 20 2010 7:40 am
From: Jiri Kosina

On Mon, 19 Apr 2010, Jan Kiszka wrote:

> Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
> ---
> arch/um/drivers/line.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
> index 7a656bd..7f7338c 100644
> --- a/arch/um/drivers/line.c
> +++ b/arch/um/drivers/line.c
> @@ -19,7 +19,6 @@ static irqreturn_t line_interrupt(int irq, void *data)
> {
> struct chan *chan = data;
> struct line *line = chan->line;
> - struct tty_struct *tty;
>
> if (line)
> chan_interrupt(&line->chan_list, &line->task, line->tty, irq);

Applied, thanks.

--
Jiri Kosina
SUSE Labs, Novell Inc.
--
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/

== 3 of 5 ==
Date: Tues, Apr 20 2010 7:40 am
From: Jiri Kosina

On Mon, 19 Apr 2010, Jan Kiszka wrote:

> Remove duplicates and unused prototypes.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@web.de>

Applied, thanks.

== 4 of 5 ==
Date: Tues, Apr 20 2010 7:40 am
From: Jeff Dike

On Tue, Apr 20, 2010 at 06:09:49PM +0800, Amerigo Wang wrote:
> On Mon, Apr 19, 2010 at 11:53:06PM +0200, Jan Kiszka wrote:
> >We can't pull in linux/sched.h, so just declare the struct.
> >
>
> Did you meet any build error? If yes, please include it.

What does this patch fix, aside from being a bit cleaner?

If it built before, without having a task_struct declaration, I think
that means that the elf_core_copy_fpregs was never used. The
task_struct * in the declaration would become a private task_struct,
known only to the declaration. If the implementation or callers have
the regular task_struct, it will be a different one, and the
prototypes will conflict due to the different types of the first
parameter.

Jeff

--
Work email - jdike at linux dot intel dot com
--
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/

== 5 of 5 ==
Date: Tues, Apr 20 2010 7:40 am
From: Jiri Kosina

On Tue, 20 Apr 2010, Amerigo Wang wrote:

> On Mon, Apr 19, 2010 at 11:53:05PM +0200, Jan Kiszka wrote:
> >Already defined in kernel.h. The official version assumes that 'n' is
> >power of two - which it is in our case.
> >
> >Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
> >---
> > arch/um/sys-x86_64/signal.c | 2 --
> > 1 files changed, 0 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/um/sys-x86_64/signal.c b/arch/um/sys-x86_64/signal.c
> >index 1a899a7..07797d1 100644
> >--- a/arch/um/sys-x86_64/signal.c
> >+++ b/arch/um/sys-x86_64/signal.c
> >@@ -165,8 +165,6 @@ struct rt_sigframe
> > struct _fpstate fpstate;
> > };
> >
> >-#define round_down(m, n) (((m) / (n)) * (n))
> >-
> > int setup_signal_stack_si(unsigned long stack_top, int sig,
> > struct k_sigaction *ka, struct pt_regs * regs,
> > siginfo_t *info, sigset_t *set)
>
> Shouldn't this signal.c #include <linux/kernel.h>?

Well, it gets included implicitly through uaccess.h -> sched.h ->
kernel.h.

Applied, thanks.

==============================================================================
TOPIC: Taming execve, setuid, and LSMs
http://groups.google.com/group/linux.kernel/t/455440aeaf3d02e1?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Apr 20 2010 7:30 am
From: Andrew Lutomirski

On Tue, Apr 20, 2010 at 8:37 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Mon, 2010-04-19 at 16:39 -0500, Serge E. Hallyn wrote:
>> Quoting Andrew Lutomirski (luto@mit.edu):

>> > and LSM transitions. I
>> > think this is a terrible idea for two reasons:
>> > 1. LSM transitions already scare me enough, and if anyone relies on
>> > them working in concert with setuid, then the mere act of separating
>> > them might break things, even if the "privileged" (by LSM) app in
>> > question is well-written.
>>
>> hmm...
>>
>> A good point.
>
> At least in the case of SELinux, context transitions upon execve are
> already disabled in the nosuid case, and Eric's patch updated the
> SELinux test accordingly.
>

True, but I think it's still asking for trouble -- other LSMs could
(and almost certainly will, especially the out-of-tree ones) do
something, and I think that any action at all that an LSM takes in the
bprm_set_creds hook for a nosuid (or whatever it's called) process is
wrong or at best misguided.

Can you think of anything that an LSM should do (or even should be
able to do) when a nosuid process calls exec, other than denying the
request outright? With my patch, LSMs can still reject the open_exec
call.

--Andy
--
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 3 ==
Date: Tues, Apr 20 2010 7:40 am
From: "Serge E. Hallyn"

Quoting Andrew Lutomirski (luto@mit.edu):
> On Tue, Apr 20, 2010 at 8:37 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Mon, 2010-04-19 at 16:39 -0500, Serge E. Hallyn wrote:
> >> Quoting Andrew Lutomirski (luto@mit.edu):
>
> >> > and LSM transitions. I
> >> > think this is a terrible idea for two reasons:
> >> > 1. LSM transitions already scare me enough, and if anyone relies on
> >> > them working in concert with setuid, then the mere act of separating
> >> > them might break things, even if the "privileged" (by LSM) app in
> >> > question is well-written.
> >>
> >> hmm...
> >>
> >> A good point.
> >
> > At least in the case of SELinux, context transitions upon execve are
> > already disabled in the nosuid case, and Eric's patch updated the
> > SELinux test accordingly.
> >
>
> True, but I think it's still asking for trouble -- other LSMs could
> (and almost certainly will, especially the out-of-tree ones) do
> something, and I think that any action at all that an LSM takes in the
> bprm_set_creds hook for a nosuid (or whatever it's called) process is
> wrong or at best misguided.

I could be wrong, but I think the point is that your reasoning is
correct, and that the same reasoning must apply if we're just
executing a file out of an fs which has been mounted with '-o nosuid'.

> Can you think of anything that an LSM should do (or even should be
> able to do) when a nosuid process calls exec, other than denying the
> request outright? With my patch, LSMs can still reject the open_exec
> call.
>
> --Andy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/

== 3 of 3 ==
Date: Tues, Apr 20 2010 8:20 am
From: Andrew Lutomirski

On Tue, Apr 20, 2010 at 10:35 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
>>
>> True, but I think it's still asking for trouble -- other LSMs could
>> (and almost certainly will, especially the out-of-tree ones) do
>> something, and I think that any action at all that an LSM takes in the
>> bprm_set_creds hook for a nosuid (or whatever it's called) process is
>> wrong or at best misguided.
>
> I could be wrong, but I think the point is that your reasoning is
> correct, and that the same reasoning must apply if we're just
> executing a file out of an fs which has been mounted with '-o nosuid'.

I tend to agree, except that only root can set nosuid (presumably) and
making that change will change existing behavior. Is that a problem?

==============================================================================
TOPIC: Fix typo in percpu.h
http://groups.google.com/group/linux.kernel/t/2f363eb64fc6b6ab?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 20 2010 7:40 am
From: Jiri Kosina

On Mon, 19 Apr 2010, Justin P. Mattock wrote:

> Fix a typo in arch/x86/include/asm/percpu.h
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> arch/x86/include/asm/percpu.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
> index 66a272d..9899afa 100644
> --- a/arch/x86/include/asm/percpu.h
> +++ b/arch/x86/include/asm/percpu.h
> @@ -105,7 +105,7 @@ do { \
>
> /*
> * Generate a percpu add to memory instruction and optimize code
> - * if a one is added or subtracted.
> + * if one is added or subtracted.
> */

Applied, thanks.

==============================================================================
TOPIC: [PATCH] lockdep fix incorrect percpu usage
http://groups.google.com/group/linux.kernel/t/1a391d1f6149f0c6?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 20 2010 7:40 am
From: Mathieu Desnoyers

* Greg KH (greg@kroah.com) wrote:
> On Wed, Mar 31, 2010 at 11:43:16AM +0900, Tejun Heo wrote:
> > On 03/31/2010 12:05 AM, Mathieu Desnoyers wrote:
> > > I see. These patches are "on their way" to mainline, so it's better not to
> > > create conflicts. So the lockdep patch should only be applied to -stable, but
> > > separate module.c patch should apply to both -stable and mainline. Am I
> > > correct ?
> >
> > I'll push proper fixes to mainline in a few days. For -stable, yeah,
> > probably.
>
> Ok, did a patch ever end up in Linus's tree for this that I can pull
> into the -stable releases?
>
> thanks,
>
> greg k-h

Hi Greg,

Here is the updated patch, stating which mainline commit from Tejun fixes it by
refactoring the code. I'll leave the decision to pick this targeted fix or Tejun
refactoring into -stable up to you.

lockdep fix incorrect percpu usage

Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed
for per cpu pointers).

git blame points to commit:

lockdep.c: commit 8e18257d29238311e82085152741f0c3aa18b74d

But it's really just moving the code around. But it's enough to say that the
problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23.

It should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these
stable branches are still maintained).

The mainline kernel as of 2.6.34-rc5 is not affected by this problem because
commit 10fad5e46f6c7bdfb01b1a012380a38e3c6ab346 fixed it by refactoring.

(tested on 2.6.33.1 x86_64)

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Randy Dunlap <randy.dunlap@oracle.com>
CC: Eric Dumazet <dada1@cosmosbay.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Tejun Heo <tj@kernel.org>
CC: Ingo Molnar <mingo@elte.hu>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: stable <stable@kernel.org>
---
kernel/lockdep.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux.trees.git/kernel/lockdep.c
===================================================================
--- linux.trees.git.orig/kernel/lockdep.c 2010-03-19 16:18:34.000000000 -0400
+++ linux.trees.git/kernel/lockdep.c 2010-03-30 09:48:43.000000000 -0400
@@ -600,9 +600,9 @@ static int static_obj(void *obj)
* percpu var?
*/
for_each_possible_cpu(i) {
- start = (unsigned long) &__per_cpu_start + per_cpu_offset(i);
- end = (unsigned long) &__per_cpu_start + PERCPU_ENOUGH_ROOM
- + per_cpu_offset(i);
+ start = (unsigned long) per_cpu_ptr(&__per_cpu_start, i);
+ end = (unsigned long) per_cpu_ptr(&__per_cpu_start
+ + PERCPU_ENOUGH_ROOM, i);

if ((addr >= start) && (addr < end))
return 1;

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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: [PATCH 2.6.29.x - 2.6.31.1] module: fix __module_ref_addr()
http://groups.google.com/group/linux.kernel/t/d4f570ea2ea35f52?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 20 2010 7:40 am
From: Mathieu Desnoyers

* Greg KH (greg@kroah.com) wrote:
> On Mon, Mar 29, 2010 at 10:22:38PM -0400, Mathieu Desnoyers wrote:
> > * Steven Rostedt (rostedt@goodmis.org) wrote:
> > > On Mon, 2010-03-29 at 14:07 -0700, Greg KH wrote:
> > > > On Mon, Mar 29, 2010 at 04:09:46PM -0400, Mathieu Desnoyers wrote:
> > > > > * Steven Rostedt (rostedt@goodmis.org) wrote:
> > > > > > This patch does not apply to 2.6.34-rc, and the code in upstream looks
> > > > > > to have been fixed. Should this go to stable?
> > > > >
> > > > > Yes. 2.6.34-rc does not have this issue anymore, but the patch is needed in
> > > > > -stable.
> > > >
> > > > Why is this not in .34-rc2? Can you find the specific patch in Linus's
> > > > tree that solves this and let stable@kernel.org know about it?
> > > >
> > >
> > > Looks like it was this commit:
> > >
> > > commit e1783a240f491fb233f04edc042e16b18a7a79ba
> > > Author: Christoph Lameter <cl@linux-foundation.org>
> > > Date: Tue Jan 5 15:34:50 2010 +0900
> > > module: Use this_cpu_xx to dynamically allocate counters
> > >
> > > Mathieu's fix was:
> > >
> > > - return (local_t *) (mod->refptr + per_cpu_offset(cpu));
> > > + return (local_t *) per_cpu_ptr(mod->refptr, cpu);
> > >
> > > As Mathieu states in his change log, the bug is that the mod->refptr is
> > > outside the assembly obfuscation of the per_cpu_offset(). This allows
> > > the compiler to optimize and cause a NULL pointer dereference with the
> > > manipulation of per cpu data.
> > >
> > > Christoph Lameter's change fixes this bug as a side effect:
> > >
> > > -static inline local_t *__module_ref_addr(struct module *mod, int cpu)
> > > -{
> > > -#ifdef CONFIG_SMP
> > > - return (local_t *) (mod->refptr + per_cpu_offset(cpu));
> > > -#else
> > > - return &mod->ref;
> > > -

twitter

Tuesday, April 20, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts