1. 05 6月, 2008 7 次提交
  2. 04 6月, 2008 2 次提交
    • J
      ax25: Fix NULL pointer dereference and lockup. · 7dccf1f4
      Jarek Poplawski 提交于
      From: Jarek Poplawski <jarkao2@gmail.com>
      
      There is only one function in AX25 calling skb_append(), and it really
      looks suspicious: appends skb after previously enqueued one, but in
      the meantime this previous skb could be removed from the queue.
      
      This patch Fixes it the simple way, so this is not fully compatible with
      the current method, but testing hasn't shown any problems.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7dccf1f4
    • D
      bluetooth: rfcomm_dev_state_change deadlock fix · 537d59af
      Dave Young 提交于
      There's logic in __rfcomm_dlc_close:
      	rfcomm_dlc_lock(d);
      	d->state = BT_CLOSED;
      	d->state_changed(d, err);
      	rfcomm_dlc_unlock(d);
      
      In rfcomm_dev_state_change, it's possible that rfcomm_dev_put try to
      take the dlc lock, then we will deadlock.
      
      Here fixed it by unlock dlc before rfcomm_dev_get in
      rfcomm_dev_state_change.
      
      why not unlock just before rfcomm_dev_put? it's because there's
      another problem.  rfcomm_dev_get/rfcomm_dev_del will take
      rfcomm_dev_lock, but in rfcomm_dev_add the lock order is :
      rfcomm_dev_lock --> dlc lock
      
      so I unlock dlc before the taken of rfcomm_dev_lock.
      
      Actually it's a regression caused by commit
      1905f6c7 ("bluetooth :
      __rfcomm_dlc_close lock fix"), the dlc state_change could be two
      callbacks : rfcomm_sk_state_change and rfcomm_dev_state_change. I
      missed the rfcomm_sk_state_change that time.
      
      Thanks Arjan van de Ven <arjan@linux.intel.com> for the effort in
      commit 4c8411f8 ("bluetooth: fix
      locking bug in the rfcomm socket cleanup handling") but he missed the
      rfcomm_dev_state_change lock issue.
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      537d59af
  3. 03 6月, 2008 6 次提交
  4. 02 6月, 2008 1 次提交
    • A
      [CRYPTO] cts: Init SG tables · c4913c7b
      Alexey Dobriyan 提交于
      Steps to reproduce:
      
      	modprobe tcrypt		# with CONFIG_DEBUG_SG=y
      
      testing cts(cbc(aes)) encryption
      test 1 (128 bit key):
      ------------[ cut here ]------------
      kernel BUG at include/linux/scatterlist.h:65!
      invalid opcode: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU 0 
      Modules linked in: tea xts twofish twofish_common tcrypt(+) [maaaany]
      Pid: 16151, comm: modprobe Not tainted 2.6.26-rc4-fat #7
      RIP: 0010:[<ffffffffa0bf032e>]  [<ffffffffa0bf032e>] :cts:cts_cbc_encrypt+0x151/0x355
      RSP: 0018:ffff81016f497a88  EFLAGS: 00010286
      RAX: ffffe20009535d58 RBX: ffff81016f497af0 RCX: 0000000087654321
      RDX: ffff8100010d4f28 RSI: ffff81016f497ee8 RDI: ffff81016f497ac0
      RBP: ffff81016f497c38 R08: 0000000000000000 R09: 0000000000000011
      R10: ffffffff00000008 R11: ffff8100010d4f28 R12: ffff81016f497ac0
      R13: ffff81016f497b30 R14: 0000000000000010 R15: 0000000000000010
      FS:  00007fac6fa276f0(0000) GS:ffffffff8060e000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00007f12ca7cc000 CR3: 000000016f441000 CR4: 00000000000026e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
      Process modprobe (pid: 16151, threadinfo ffff81016f496000, task ffff8101755b4ae0)
      Stack:  0000000000000001 ffff81016f496000 ffffffff80719f78 0000000000000001
       0000000000000001 ffffffff8020c87c ffff81016f99c918 20646c756f772049
       65687420656b696c 0000000000000020 0000000000000000 0000000033341102
      Call Trace:
       [<ffffffff8020c87c>] ? restore_args+0x0/0x30
       [<ffffffffa04aa311>] ? :aes_generic:crypto_aes_expand_key+0x311/0x369
       [<ffffffff802ab453>] ? check_object+0x15a/0x213
       [<ffffffff802aad22>] ? init_object+0x6e/0x76
       [<ffffffff802ac3ae>] ? __slab_free+0xfc/0x371
       [<ffffffffa0bf05ed>] :cts:crypto_cts_encrypt+0xbb/0xca
       [<ffffffffa07108de>] ? :crypto_blkcipher:setkey+0xc7/0xec
       [<ffffffffa07110b8>] :crypto_blkcipher:async_encrypt+0x38/0x3a
       [<ffffffffa2ce9341>] :tcrypt:test_cipher+0x261/0x7c6
       [<ffffffffa2cfd9df>] :tcrypt:tcrypt_mod_init+0x9df/0x1b30
       [<ffffffff80261e35>] sys_init_module+0x9e/0x1b2
       [<ffffffff8020c15a>] system_call_after_swapgs+0x8a/0x8f
      Code: 45 c0 e8 aa 24 63 df 48 c1 e8 0c 48 b9 00 00 00 00 00 e2 ff ff 48 8b 55 88 48 6b c0 68 48 01 c8 b9 21 43 65 87 48 39 4d 80 74 04 <0f> 0b eb fe f6 c2 01 74 04 0f 0b eb fe 83 e2 03 4c 89 ef 44 89 
      RIP  [<ffffffffa0bf032e>] :cts:cts_cbc_encrypt+0x151/0x355
       RSP <ffff81016f497a88>
      ---[ end trace e8bahiarjand37fd ]---
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c4913c7b
  5. 01 6月, 2008 1 次提交
    • S
      kbuild: fix $(src) assignmnet with external modules · 96d97f26
      Sam Ravnborg 提交于
      When we introduced support for KBUILD_EXTRA_SYMBOLS
      we started to include the externam module's kbuild
      file when doing the final modpost step.
      
      As external modules often do:
      ccflags-y := -I$(src)
      
      We had problems because $(src) was unassinged and
      gcc then used the next parameter for -I resulting in
      strange build failures.
      
      Fix is to assign $(src) and $(obj) when building
      external modules.
      
      This fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10798Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Tvrtko <tvrtko.ursulin@sophos.com>
      Cc: Andrea Arcangeli <andrea@qumranet.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      96d97f26
  6. 31 5月, 2008 23 次提交