Skip to content

L
linux
Switch branch/tag
  1. 16 Sep, 2006 8 commits
  3. 12 Sep, 2006 1 commit
  5. 09 Sep, 2006 2 commits
  7. 06 Sep, 2006 10 commits
    • Adrian Bunk's avatar
      Linux 2.6.16.29-rc1 · aa95228d
      Adrian Bunk authored
      aa95228d
    • Alan Cox's avatar
      pci_ids.h: add some VIA IDE identifiers · 47251e05
      Alan Cox authored 
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      47251e05
    • David S. Miller's avatar
      [PKTGEN]: Make sure skb->{nh,h} are initialized in fill_packet_ipv6() too. · 8b385946
      David S. Miller authored 
      Mirror the bug fix from fill_packet_ipv4()
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      8b385946
    • Chen-Li Tien's avatar
      [PKTGEN]: Fix oops when used with balance-tlb bonding · da56aea0
      Chen-Li Tien authored 
      Signed-off-by: default avatarChen-Li Tien <cltien@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      da56aea0
    • Dean Nelson's avatar
      ia64 SGI-SN2: fix silent data corruption caused by XPC · c1646ad4
      Dean Nelson authored 
      Jack Steiner identified a problem where XPC can cause a silent
data corruption.  On module load, the placement may cause the
xpc_remote_copy_buffer to span two physical pages.  DMA transfers are
done to the start virtual address translated to physical.

This patch changes the buffer from a statically allocated buffer to a
kmalloc'd buffer.  Dean Nelson reviewed this before posting.  I have
tested it in the configuration that was showing the memory corruption
and verified it works.  I also added a BUG_ON statement to help catch
this if a similar situation is encountered.
Signed-off-by: default avatarRobin Holt <holt@sgi.com>
Signed-off-by: default avatarDean Nelson <dcn@sgi.com>
Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      c1646ad4
    • YOSHIFUJI Hideaki's avatar
      [IPV6]: Fix kernel OOPs when setting sticky socket options. · a3c94d77
      YOSHIFUJI Hideaki authored 
      Bug noticed by Remi Denis-Courmont <rdenis@simphalempin.com>.
Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      a3c94d77
    • Sonny Rao's avatar
      idr: fix race in idr code · eebf6e7f
      Sonny Rao authored 
      I ran into a bug where the kernel died in the idr code:

cpu 0x1d: Vector: 300 (Data Access) at [c000000b7096f710]
    pc: c0000000001f8984: .idr_get_new_above_int+0x140/0x330
    lr: c0000000001f89b4: .idr_get_new_above_int+0x170/0x330
    sp: c000000b7096f990
   msr: 800000000000b032
   dar: 0
 dsisr: 40010000
  current = 0xc000000b70d43830
  paca    = 0xc000000000556900
    pid   = 2022, comm = hwup
1d:mon> t
[c000000b7096f990] c0000000000d2ad8 .expand_files+0x2e8/0x364 (unreliable)
[c000000b7096faa0] c0000000001f8bf8 .idr_get_new_above+0x18/0x68
[c000000b7096fb20] c00000000002a054 .init_new_context+0x5c/0xf0
[c000000b7096fbc0] c000000000049dc8 .copy_process+0x91c/0x1404
[c000000b7096fcd0] c00000000004a988 .do_fork+0xd8/0x224
[c000000b7096fdc0] c00000000000ebdc .sys_clone+0x5c/0x74
[c000000b7096fe30] c000000000008950 .ppc_clone+0x8/0xc
-- Exception: c00 (System Call) at 000000000fde887c
SP (f8b4e7a0) is in userspace

Turned out to be a race-condition and NULL ptr deref, here's my fix:

Users of the idr code are supposed to call idr_pre_get without locking, so the
idr code must serialize itself with respect to layer allocations.  However, it
fails to do so in an error path in idr_get_new_above_int().  I added the
missing locking to fix this.
Signed-off-by: default avatarSonny Rao <sonny@burdell.org>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      eebf6e7f
    • Christian Borntraeger's avatar
      fix misoptimization in futex unqueue_me · 397f9fde
      Christian Borntraeger authored 
      This patch adds a barrier() in futex unqueue_me to avoid aliasing of two
pointers.

On my s390x system I saw the following oops:

Unable to handle kernel pointer dereference at virtual kernel address
0000000000000000
Oops: 0004 [#1]
CPU:    0    Not tainted
Process mytool (pid: 13613, task: 000000003ecb6ac0, ksp: 00000000366bdbd8)
Krnl PSW : 0704d00180000000 00000000003c9ac2 (_spin_lock+0xe/0x30)
Krnl GPRS: 00000000ffffffff 000000003ecb6ac0 0000000000000000 0700000000000000
           0000000000000000 0000000000000000 000001fe00002028 00000000000c091f
           000001fe00002054 000001fe00002054 0000000000000000 00000000366bddc0
           00000000005ef8c0 00000000003d00e8 0000000000144f91 00000000366bdcb8
Krnl Code: ba 4e 20 00 12 44 b9 16 00 3e a7 84 00 08 e3 e0 f0 88 00 04
Call Trace:
([<0000000000144f90>] unqueue_me+0x40/0xe4)
 [<0000000000145a0c>] do_futex+0x33c/0xc40
 [<000000000014643e>] sys_futex+0x12e/0x144
 [<000000000010bb00>] sysc_noemu+0x10/0x16
 [<000002000003741c>] 0x2000003741c

The code in question is:

static int unqueue_me(struct futex_q *q)
{
        int ret = 0;
        spinlock_t *lock_ptr;

        /* In the common case we don't take the spinlock, which is nice. */
 retry:
        lock_ptr = q->lock_ptr;
        if (lock_ptr != 0) {
                spin_lock(lock_ptr);
                /*
                 * q->lock_ptr can change between reading it and
                 * spin_lock(), causing us to take the wrong lock.  This
                 * corrects the race condition.
[...]

and my compiler (gcc 4.1.0) makes the following out of it:

00000000000003c8 <unqueue_me>:
     3c8:       eb bf f0 70 00 24       stmg    %r11,%r15,112(%r15)
     3ce:       c0 d0 00 00 00 00       larl    %r13,3ce <unqueue_me+0x6>
                        3d0: R_390_PC32DBL      .rodata+0x2a
     3d4:       a7 f1 1e 00             tml     %r15,7680
     3d8:       a7 84 00 01             je      3da <unqueue_me+0x12>
     3dc:       b9 04 00 ef             lgr     %r14,%r15
     3e0:       a7 fb ff d0             aghi    %r15,-48
     3e4:       b9 04 00 b2             lgr     %r11,%r2
     3e8:       e3 e0 f0 98 00 24       stg     %r14,152(%r15)
     3ee:       e3 c0 b0 28 00 04       lg      %r12,40(%r11)
                /* write q->lock_ptr in r12 */
     3f4:       b9 02 00 cc             ltgr    %r12,%r12
     3f8:       a7 84 00 4b             je      48e <unqueue_me+0xc6>
                /* if r12 is zero then jump over the code.... */
     3fc:       e3 20 b0 28 00 04       lg      %r2,40(%r11)
                /* write q->lock_ptr in r2 */
     402:       c0 e5 00 00 00 00       brasl   %r14,402 <unqueue_me+0x3a>
                        404: R_390_PC32DBL      _spin_lock+0x2
                /* use r2 as parameter for spin_lock */

So the code becomes more or less:
if (q->lock_ptr != 0) spin_lock(q->lock_ptr)
instead of
if (lock_ptr != 0) spin_lock(lock_ptr)

Which caused the oops from above.
After adding a barrier gcc creates code without this problem:
[...] (the same)
     3ee:       e3 c0 b0 28 00 04       lg      %r12,40(%r11)
     3f4:       b9 02 00 cc             ltgr    %r12,%r12
     3f8:       b9 04 00 2c             lgr     %r2,%r12
     3fc:       a7 84 00 48             je      48c <unqueue_me+0xc4>
     400:       c0 e5 00 00 00 00       brasl   %r14,400 <unqueue_me+0x38>
                        402: R_390_PC32DBL      _spin_lock+0x2

As a general note, this code of unqueue_me seems a bit fishy. The retry logic
of unqueue_me only works if we can guarantee, that the original value of
q->lock_ptr is always a spinlock (Otherwise we overwrite kernel memory). We
know that q->lock_ptr can change. I dont know what happens with the original
spinlock, as I am not an expert with the futex code.
Signed-off-by: default avatarChristian Borntraeger <borntrae@de.ibm.com>
Acked-by: default avatarIngo Molnar <mingo@redhat.com>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      397f9fde
    • maximilian attems's avatar
      [SERIAL] icom: select FW_LOADER · 8c0e503b
      maximilian attems authored 
      The icom driver uses request_firmware()
and thus needs to select FW_LOADER.
Signed-off-by: default avatarmaximilian attems <maks@sternwelten.at>
Signed-off-by: default avatarOlaf Hering <olh@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      8c0e503b
    • Alan Cox's avatar
      Missing PCI id update for VIA IDE · 97bc8f75
      Alan Cox authored 
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      97bc8f75
  9. 05 Sep, 2006 8 commits
  11. 31 Aug, 2006 2 commits
  13. 30 Aug, 2006 6 commits
  15. 27 Aug, 2006 1 commit
  17. 26 Aug, 2006 2 commits
    • Mark Huang's avatar
      ulog: fix panic on SMP kernels · 189abe08
      Mark Huang authored 
      Fix kernel panic on various SMP machines. The culprit is a null
ub->skb in ulog_send(). If ulog_timer() has already been scheduled on
one CPU and is spinning on the lock, and ipt_ulog_packet() flushes the
queue on another CPU by calling ulog_send() right before it exits,
there will be no skbuff when ulog_timer() acquires the lock and calls
ulog_send(). Cancelling the timer in ulog_send() doesn't help because
it has already been scheduled and is running on the first CPU.

Similar problem exists in ebt_ulog.c and nfnetlink_log.c.
Signed-off-by: default avatarMark Huang <mlhuang@cs.princeton.edu>
Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      189abe08
    • Neil Brown's avatar
      Fix a potential NULL dereference in md/raid1 · fbb8b6ef
      Neil Brown authored 
      At the point where this 'atomic_add' is, rdev could be NULL,
as seen by the fact that we test for this in the very next
statement.
Further is it is really the wrong place of the add.
We could add to the count of corrected errors
once the are sure it was corrected, not before
trying to correct it.
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      fbb8b6ef
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7