1. 09 Sep, 2006 2 commits
  2. 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
      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
  3. 05 Sep, 2006 8 commits
  4. 31 Aug, 2006 2 commits
  5. 30 Aug, 2006 6 commits
  6. 27 Aug, 2006 1 commit
  7. 26 Aug, 2006 7 commits
  8. 25 Aug, 2006 1 commit
  9. 23 Aug, 2006 3 commits