linux.kernel - 25 new messages in 17 topics - digest

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

linux.kernel@googlegroups.com

Today's topics:

* USB: don't read past config->interface[] if usb_control_msg() fails in usb_
reset_configuration() - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/885f3821a494a777?hl=en
* clocksource mutex deadlock, cat current_clocksource (2.6.33-rc6/7) - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e482f38068a1a167?hl=en
* Restrict initial stack space expansion to rlimit - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c1edecbd60f1c6b3?hl=en
* 2.6.33-rc7 problems - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/36295478136aa4b9?hl=en
* P4 PMU early draft - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cbcaa116bfdc609d?hl=en
* x86: make 64 bit use early_res instead of bootmem before slab - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/a6a29cc058de25ea?hl=en
* Stop Bad Credit History - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/84ccbdfb65eefbdc?hl=en
* scsi: zorro7xx: braces code style fix - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7d90659ee452898e?hl=en
* powerpc: mpc5121: PSC UART support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/21e09aff9ddcf14a?hl=en
* drivers: dream: Codestyle fix - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/19405e58a9f406f0?hl=en
* Revert "x86: ptrace and core-dump extensions for xstate" - 4 messages, 1
author
http://groups.google.com/group/linux.kernel/t/06e74467e61eef71?hl=en
* e1000e: Don't disable jumbo frames on 82537L due to eeprom contents - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/19cd8b48d471b99e?hl=en
* e1000e: Only disable ASPM on 82573L devices - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/600704851d6eb658?hl=en
* 2.6.33-rc6 crashes on resume - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6dc9f99de8146cff?hl=en
* dvb: l64781.ko broken with gcc 4.5 - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fae100dea0f5cd49?hl=en
* Make vm_max_readahead configurable at run-time - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1ed86ee956fca84c?hl=en
* UIO: Review of drivers/uio/Kconfig - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7d04fc5307434258?hl=en

==============================================================================
TOPIC: USB: don't read past config->interface[] if usb_control_msg() fails in
usb_reset_configuration()
http://groups.google.com/group/linux.kernel/t/885f3821a494a777?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 9 2010 2:20 pm
From: roel kluin

On Tue, Feb 9, 2010 at 11:01 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Tue, Feb 09, 2010 at 05:01:53PM +0100, Roel Kluin wrote:
>> After the loop `for (i = 0; i < config->desc.bNumInterfaces; i++)' if no
>> break occurred, i equals config->desc.bNumInterfaces. so if
>> usb_control_msg() failed then after goto reset_old_alts we read from
>> config->interface[config->desc.bNumInterfaces].
>> We can safely decrement i as well if the break occurred.
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>> Acked-by: Alan Stern <stern@rowland.harvard.edu>
>
> Bah, yes, you're right. :)  Good catch.

Could you please confirm whether this patch is the better or the
other (in this same thread)?

Thanks,
Roel
--
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: Tues, Feb 9 2010 3:00 pm
From: Sarah Sharp

On Tue, Feb 09, 2010 at 11:01:24PM +0100, Roel Kluin wrote:
> After the loop `for (i = 0; i < config->desc.bNumInterfaces; i++)' if no
> break occurred, i equals config->desc.bNumInterfaces. so if
> usb_control_msg() failed then after goto reset_old_alts we read from
> config->interface[config->desc.bNumInterfaces].
>
> Reported-by: "Juha Leppanen" <juha_motorsportcom@luukku.com>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
>
> >> You correctly identified a problem, but your fix is wrong -- or at
> >> least, it is much too complicated. The proper fix goes like this:
> >
> > /* If not, reinstate the old alternate settings */
> > if (retval < 0) {
> > reset_old_alts:
> > - for (; i >= 0; i--) {
> > + for (i--; i >= 0; i--) {
> > struct usb_interface *intf = config->interface[i];
> > struct usb_host_interface *alt;
>
>
> Are you really sure this is better?

Yes.

> If usb_hcd_alloc_bandwidth() fails, in the loop _before_ the
> reset_old_alts label, don't we still have to reinstate the old
> alternate settings for that usb_interface config->interface[i]? This
> was what my initial patch tried to do.

No, you do not. Take a look at usb_hcd_alloc_bandwidth() in
drivers/usb/core/hcd.c. If an allocation fails for interface i when
the HCD's check_bandwidth() function is called, then
hcd->driver->reset_bandwidth is called. We only need to clean up the
interfaces that have successfully been allocated bandwidth (0 to i - 1).

> Alternatively usb_hcd_alloc_bandwidth() could undo what it does if an
> error occurs there, then I think i could be decremented.

Yes, that's what usb_hcd_alloc_bandwidth() does at the reset label.

Sarah
--
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: clocksource mutex deadlock, cat current_clocksource (2.6.33-rc6/7)
http://groups.google.com/group/linux.kernel/t/e482f38068a1a167?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 2:20 pm
From: Andreas Mohr

On Tue, Feb 09, 2010 at 11:02:02AM +0100, Thomas Gleixner wrote:
> Just verified, that there is no timekeeping related patch after
> 2.6.33-rc4 except the kgdb lockup prevention patch, which is
> not touching any code which is relevant at boot time.
>
> So bisecting between rc4 and now is probably the best thing to do.

Despairing is the best thing to do methinks.

-rc5 gcc 4.4 new .config: acpi_pm lockup
-rc4 gcc 4.4 new .config: reboot (directly after unpacking kernel)
-rc4 gcc 4.4 old (trusted) .config: reboot!! (dito)
-rc4 gcc 4.3 old (trusted) .config: reboot!!! (dito)

I'm currently zeroing in on the libgcc1 upgrade that I did on
2010-02-04 (which also made gcc-4.4 the default system compiler).
I don't have any friggin' idea what else could have caused this.

gcc 4.3 has been configured using CC=gcc-4.3 HOSTCC=gcc-4.3
, but as said, this also failed.

Andreas Mohr
--
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: Restrict initial stack space expansion to rlimit
http://groups.google.com/group/linux.kernel/t/c1edecbd60f1c6b3?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 2:30 pm
From: Helge Deller

On 02/09/2010 10:51 PM, Michael Neuling wrote:
>>> I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it
>>> as well.
>>
>> There's only one CONFIG_GROWSUP arch - parisc.
>> Could someone please test it on parisc?

I did.

> How about doing:
> 'ulimit -s 15; ls'
> before and after the patch is applied. Before it's applied, 'ls' should
> be killed. After the patch is applied, 'ls' should no longer be killed.
>
> I'm suggesting a stack limit of 15KB since it's small enough to trigger
> 20*PAGE_SIZE. Also 15KB not a multiple of PAGE_SIZE, which is a trickier
> case to handle correctly with this code.
>
> 4K pages on parisc should be fine to test with.

Mikey, thanks for the suggested test plan.

I'm not sure if your patch does it correct for parisc/stack-grows-up-case.

I tested your patch on a 4k pages kernel:
root@c3000:~# uname -a
Linux c3000 2.6.33-rc7-32bit #221 Tue Feb 9 23:17:06 CET 2010 parisc GNU/Linux

Without your patch:
root@c3000:~# ulimit -s 15; ls
Killed
-> correct.

With your patch:
root@c3000:~# ulimit -s 15; ls
Killed
_or_:
root@c3000:~# ulimit -s 15; ls
Segmentation fault
-> ??

Any idea?

Helge

>> From: Michael Neuling<mikey@neuling.org>
>>
>> When reserving stack space for a new process, make sure we're not
>> attempting to expand the stack by more than rlimit allows.
>>
>> This fixes a bug caused by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba ("mm:
>> variable length argument support") and unmasked by
>> fc63cf237078c86214abcb2ee9926d8ad289da9b ("exec: setup_arg_pages() fails
>> to return errors").
>>
>> This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg.
>> 80K on 4K pages or 'ulimit -s 79') all processes will be killed before
>> they start. This is particularly bad with 64K pages, where a ulimit below
>> 1280K will kill every process.
>>
>> Signed-off-by: Michael Neuling<mikey@neuling.org>
>> Cc: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>> Cc: Americo Wang<xiyou.wangcong@gmail.com>
>> Cc: Anton Blanchard<anton@samba.org>
>> Cc: Oleg Nesterov<oleg@redhat.com>
>> Cc: James Morris<jmorris@namei.org>
>> Cc: Ingo Molnar<mingo@elte.hu>
>> Cc: Serge Hallyn<serue@us.ibm.com>
>> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
>> Cc:<stable@kernel.org>
>>
>> fs/exec.c | 21 +++++++++++++++++++--
>> 1 file changed, 19 insertions(+), 2 deletions(-)
>>
>> diff -puN fs/exec.c~fs-execc-restrict-initial-stack-space-expansion-to-rlimit
> fs/exec.c
>> --- a/fs/exec.c~fs-execc-restrict-initial-stack-space-expansion-to-rlimit
>> +++ a/fs/exec.c
>> @@ -571,6 +571,9 @@ int setup_arg_pages(struct linux_binprm
>> struct vm_area_struct *prev = NULL;
>> unsigned long vm_flags;
>> unsigned long stack_base;
>> + unsigned long stack_size;
>> + unsigned long stack_expand;
>> + unsigned long rlim_stack;
>>
>> #ifdef CONFIG_STACK_GROWSUP
>> /* Limit stack size to 1GB */
>> @@ -627,10 +630,24 @@ int setup_arg_pages(struct linux_binprm
>> goto out_unlock;
>> }
>>
>> + stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE;
>> + stack_size = vma->vm_end - vma->vm_start;
>> + /*
>> + * Align this down to a page boundary as expand_stack
>> + * will align it up.
>> + */
>> + rlim_stack = rlimit(RLIMIT_STACK)& PAGE_MASK;
>> + rlim_stack = min(rlim_stack, stack_size);
>> #ifdef CONFIG_STACK_GROWSUP
>> - stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
>> + if (stack_size + stack_expand> rlim_stack)
>> + stack_base = vma->vm_start + rlim_stack;
>> + else
>> + stack_base = vma->vm_end + stack_expand;
>> #else
>> - stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
>> + if (stack_size + stack_expand> rlim_stack)
>> + stack_base = vma->vm_end - rlim_stack;
>> + else
>> + stack_base = vma->vm_start - stack_expand;
>>