headers
Samuel Thibault | 1 Oct 2009 01:01
Gravatar

Re: [PATCH,TRIVIAL] Fix csum_ipv6_magic asm memory clobber

H. Peter Anvin, le Wed 30 Sep 2009 15:45:15 -0700, a écrit :
> On 09/30/2009 03:40 PM, Andrew Morton wrote:
> > You describe it as "trivial" and also cc stable <at> kernel.org.  These things
> > are contradictory!
> > 
> > Maybe backporting it is a good idea from a sleep-soundly-at-night POV. 
> > I don't know..
> 
> /me suspects it was supposed to mean "trivially correct",

Yes.

> which isn't really what "trivial" means.

Ah.

> This is a potentially serious bug and should be treated as such.

Yes.  Actually it hit Hurd's pfinetv4 when we tried to compile it with
gcc-4.3 (bogus checksums).

Samuel
Permalink | Reply | 3 comments |
headers
Ingo Molnar | 1 Oct 2009 01:09
Picon
Picon
Favicon

Re: x86: mce: Please revert 22223c9b417be5fd0ab2cf9ad17eb7bd1e19f7b9


* Borislav Petkov <petkovbb <at> googlemail.com> wrote:

> On Wed, Sep 30, 2009 at 11:48:59PM +0200, Ingo Molnar wrote:
> > I.e. something like the patch below. Completely untested.
> 
> [..]
> 
> > Note, while looking at the interaction of decode_mce() with the other 
> > MCE code i also noticed a few other things and made the following 
> > cleanups/fixes:
> > 
> >  - Fixed the mce_decode() weak alias - a weak alias is really not good
> >    here, it should be a proper callback. A weak alias will be overriden
> >    if a piece of code is built into the kernel - not good, obviously.
> 
> The original idea was for the edac_mce_amd.o module to override the 
> weak symbol but the problem with that is that when CONFIG_CPU_SUP_AMD 
> is set, MCE decoding is built in by default thus overriding the weak 
> symbol even on non-AMD systems running distro kernels with multiple 
> x86 CPU types support. Your patch solves that.
> 
> However, currently we can't get rid of the decoding code when booted 
> on non-AMD boxes - it amounts to ~ 15K of object code on non-debug 
> builds. Is it worth the trouble to add it to initmem on such boxes and 
> remove it during boot?

it's ~5K here. Btw., how would that work? Initmem cannot generally be 
discarded optionally like that.
(Continue reading)

Permalink | Reply | 23 comments |
headers
Andrew Morton | 1 Oct 2009 01:08

Re: [Patch] rwsem: fix rwsem_is_locked() bug

On Tue, 29 Sep 2009 23:19:02 -0400
Amerigo Wang <amwang <at> redhat.com> wrote:

> 
> rwsem_is_locked() tests ->activity without locks, so we should always
> keep ->activity consistent. However, the code in __rwsem_do_wake()
> breaks this rule, it updates ->activity after _all_ readers waken up,
> this may give some reader a wrong ->activity value, thus cause
> rwsem_is_locked() behaves wrong.
> 
> Brian has a kernel module to reproduce this, I can include it
> if any of you need. Of course, with Brian's approval.
> 
> With this patch applied, I can't trigger that bug any more.
> 

Changelog doesn't describe the bug well.

> 
> ---
> diff --git a/lib/rwsem-spinlock.c b/lib/rwsem-spinlock.c
> index 9df3ca5..44e4484 100644
> --- a/lib/rwsem-spinlock.c
> +++ b/lib/rwsem-spinlock.c
>  <at>  <at>  -49,7 +49,6  <at>  <at>  __rwsem_do_wake(struct rw_semaphore *sem, int wakewrite)
>  {
>  	struct rwsem_waiter *waiter;
>  	struct task_struct *tsk;
> -	int woken;
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Morton | 1 Oct 2009 01:13

Re: [PATCH] floppy: Add an extra bound check on ioctl arguments

On Wed, 30 Sep 2009 13:17:09 +0200
Arjan van de Ven <arjan <at> infradead.org> wrote:

> gcc is not convinced that the floppy.c ioctl has sufficient bound checks,

gad.  You said "floppy" and "ioctl" in the same sentence.  Where angels
fear to tread.

It would be useful if you were to quote the gcc output in the changelog
please.  I assume that you're using some magical new gcc option or
something?
Permalink | Reply | 1 comment |
headers
Tilman Schmidt | 1 Oct 2009 01:15

capi.c calls receive_buf with interrupts disabled (was: N_PPP_SYNC ldisc BUG: sleeping function called from invalid context)

Jarek Poplawski schrieb:
> Tilman Schmidt wrote, On 09/30/2009 08:55 PM:
[...]
>> - ppp_sync_receive() was called, as the LD's receive_buf method,
>>   via handle_recv_skb() [drivers/isdn/capi/capi.c line 504, inlined]
>>   from handle_minor_recv() [drivers/isdn/capi/capi.c line 519]
>>
>> - handle_minor_recv() was called from capi_recv_message()
>>   [drivers/isdn/capi/capi.c line 656]
>>
>> - capi_recv_message() was called, as the CAPI application's
>>   recv_message method, from recv_handler()
>>   [drivers/isdn/capi/kcapi.c line 268]
>>
>> - recv_handler() is never called directly. It's only scheduled
>>   via the work queue ap->recv_work from capi_ctr_handle_message()
>>   [drivers/isdn/capi/kcapi.c line 349]
>>
>> Even if we don't trust the backtraces, there's not much room for
>> another activation path. So for all I know, the expectation of the
>> tty logic should have been met. The call was indeed processed from
>> a work queue.
>>
>> Why then does mutex_lock() complain?
> 
> Hmm... capi_recv_message() calls handle_minor_recv() under
> spin_lock_irqsave(), doesn't it?

Well spotted. Indeed it does. That explains it, of course.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Oct 2009 01:16

Re: [PATCH] floppy: Add an extra bound check on ioctl arguments

On Wed, 30 Sep 2009 13:17:09 +0200
Arjan van de Ven <arjan <at> infradead.org> wrote:

> 
> >From 90d75780b319153d050bb1c0f3f38ce054775615 Mon Sep 17 00:00:00 2001
> From: Arjan van de Ven <arjan <at> linux.intel.com>
> Date: Wed, 30 Sep 2009 13:13:59 +0200
> Subject: [PATCH] floppy: Add an extra bound check on ioctl arguments
> 
> gcc is not convinced that the floppy.c ioctl has sufficient bound checks,
> and frankly, as a human I have a hard time proving the same more or less
> (the size comes from the ioctl argument. humpf. maybe. the code isn't
> very nice)
> 
> This patch adds an explicit check to make 100% sure it's safe, better
> than finding out later that there indeed was a gap.
> 
> Signed-off-by: Arjan van de Ven <arjan <at> linux.intel.com>
> ---
>  drivers/block/floppy.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index 5c01f74..0f11a77 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
>  <at>  <at>  -3497,6 +3497,9  <at>  <at>  static int fd_ioctl(struct block_device *bdev, fmode_t mode, unsigned int cmd,
>  	    ((cmd & 0x80) && !capable(CAP_SYS_ADMIN)))
>  		return -EPERM;
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Oct 2009 01:22
Favicon

Re: [PATCH,TRIVIAL] Fix csum_ipv6_magic asm memory clobber

From: Andrew Morton <akpm <at> linux-foundation.org>
Date: Wed, 30 Sep 2009 16:19:39 -0700

> From: Samuel Thibault <samuel.thibault <at> ens-lyon.org>
> 
> Just like ip_fast_csum, the assembly snippet in csum_ipv6_magic needs a
> memory clobber, as it is only passed the address of the buffer, not a
> memory reference to the buffer itself.
> 
> This caused failures in Hurd's pfinetv4 when we tried to compile it with
> gcc-4.3 (bogus checksums).
> 
> Signed-off-by: Samuel Thibault <samuel.thibault <at> ens-lyon.org>
> Signed-off-by: Andrew Morton <akpm <at> linux-foundation.org>

I'm happy to see this go in via the x86 tree, and thus:

Acked-by: David S. Miller <davem <at> davemloft.net>
Permalink | Reply | 1 comment |
headers
devzero | 1 Oct 2009 01:25
Picon

Re: [GIT PULL] block updates for 2.6.32-rc

>> Hi Linus,
>> 
>> This looks huge, but it's mostly a cciss driver update and the addition
>> of drbd. I would have submitted this before -rc1, but Plumbers got in
>> the way.
>
>And DRBD is defintively not ready.  Even if people want to merge another
>duplicate RAID driver including another crappy user interface it has
>tracing stuff of a form that would let Ingo go beserk and also uses the
>stupid connector.

so, if DRBD is too ugly to be merged, i wonder why it`s not put in staging 
then before other kernel devs find yet another reason for not merging it 
at all. if they want it to be cleaned up, they can do it there or they can 
make the driver maintainer do it. or they can do it together. or they can 
let just sit it there until greg complains :)

all in all, it`s better than letting brilliant things like these live outside the
kernel tree. (which is more than 8 yrs now for DRBD)

What the Linux Staging tree is
The Linux Staging tree (or just "staging" from now on) is used to hold 
stand-alone drivers and filesystems that are not ready to be merged into 
the main portion of the Linux kernel tree at this point in time for various 
technical reasons. It is contained within the main Linux kernel tree so that 
users can get access to the drivers much easier than before, and to provide 
a common place for the development to happen, resolving the "hundreds 
of different download sites" problem that most out-of-tree drivers have had 
in the past.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Airlie | 1 Oct 2009 01:27
Picon
Gravatar

Re: [PATCH] drm/radeon/kms: Convert RS690/RS740 to new init path.

On Tue, Sep 29, 2009 at 10:32 PM, Jerome Glisse <jglisse <at> redhat.com> wrote:
> Also cleanup register specific to RS690/RS740.
>
> Signed-off-by: Jerome Glisse <jglisse <at> redhat.com>
> ---
>  drivers/gpu/drm/radeon/radeon.h      |   10 +
>  drivers/gpu/drm/radeon/radeon_asic.h |   41 ++--
>  drivers/gpu/drm/radeon/rs600.c       |    7 +-
>  drivers/gpu/drm/radeon/rs690.c       |  358 +++++++++++++++++++++------------
>  drivers/gpu/drm/radeon/rs690r.h      |   99 ----------
>  5 files changed, 266 insertions(+), 249 deletions(-)
>  delete mode 100644 drivers/gpu/drm/radeon/rs690r.h

This forgets to add rs690d.h here so breaks the build.

Dave.
Permalink | Reply | 0 comments |
headers
Greg KH | 1 Oct 2009 01:27
Gravatar

Re: [stable] [patch for 2.6.31-stable] zaurus c3000 aka spitz: fix resume

On Wed, Sep 30, 2009 at 10:32:52PM +0200, Pavel Machek wrote:
> 
> 
> Spitz resume was broken for year or likely two, and it would be very
> nice to fix it for 2.6.31-stable release. One liner is below...
> 
> It is in 2.6.32-rc1/2, with some more signoffs...

Now queued up.

Next time please let me know what the git commit id is for the patch,
it's necessary for me to be able to include it in the -stable tree.

thanks,

greg k-h
Permalink | Reply | 1 comment |

Gmane