1. 26 Jul, 2013 1 commit
  2. 22 Jul, 2013 9 commits
  3. 18 Jul, 2013 5 commits
    • Sujith Manoharan's avatar
      ath9k_hw: Fix multicast search for AR9002 family · 64b6f46f
      Sujith Manoharan authored
      
      
      The multicast search bit is disabled for the AR9003
      family, but this is required for AR9002 too. Fix this in
      the INI override routine.
      Signed-off-by: default avatarSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      64b6f46f
    • Larry Finger's avatar
      rtlwifi: Fix build errors for unusual cases · 6f334c2b
      Larry Finger authored
      
      
      The present build configuration for the rtlwifi family of drivers will
      fail under two known conditions:
      
      (1) If rtlwifi is selected without selecting any of the dependent drivers,
          there are errors in the build.
      (2) If the PCI drivers are built into the kernel and the USB drivers are modules,
          or vice versa, there are missing globals.
      
      The first condition is fixed by never building rtlwifi unless at least one
      of the device drivers is selected. The second failure is fixed by splitting
      the PCI and USB codes out of rtlwifi, and creating their own mini drivers.
      If the drivers that use them are modules, they will also be modules.
      
      Although a number of files are touched by this patch, only Makefile and Kconfig
      have undergone significant changes. The only modifications to the other files
      were to export entry points needed by the new rtl_pci and rtl_usb units, or to
      rename two variables that had names that were likely to cause namespace collisions.
      
      Reported-by: Fengguang Wu <fengguang.wu@intel.com>  [Condition 1]
      Reported-by: Ben Hutchings <bhutchings@solarflare.com> [Condition 2]
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Ben Hutchings <bhutchings@solarflare.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6f334c2b
    • Bob Copeland's avatar
      ath5k: fix extra set bit in multicast mask · f287cbd0
      Bob Copeland authored
      
      
      Bit 32 was always set which looks to have been accidental,
      according to git history.
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f287cbd0
    • Geert Uytterhoeven's avatar
      rt2x00: RT2X00 should depend on HAS_DMA · 6a084839
      Geert Uytterhoeven authored
      
      
      If NO_DMA=y:
      
      drivers/built-in.o: In function `rt2x00queue_unmap_skb':
      drivers/net/wireless/rt2x00/rt2x00queue.c:129: undefined reference to `dma_unmap_single'
      drivers/net/wireless/rt2x00/rt2x00queue.c:133: undefined reference to `dma_unmap_single'
      drivers/built-in.o: In function `rt2x00queue_map_txskb':
      drivers/net/wireless/rt2x00/rt2x00queue.c:112: undefined reference to `dma_map_single'
      drivers/net/wireless/rt2x00/rt2x00queue.c:115: undefined reference to `dma_mapping_error'
      drivers/built-in.o: In function `rt2x00queue_alloc_rxskb':
      drivers/net/wireless/rt2x00/rt2x00queue.c:93: undefined reference to `dma_map_single'
      drivers/net/wireless/rt2x00/rt2x00queue.c:95: undefined reference to `dma_mapping_error'
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: linux-wireless@vger.kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6a084839
    • Arnd Bergmann's avatar
      ssb: fix alignment of struct bcma_device_id · b01a60be
      Arnd Bergmann authored
      
      
      The ARM OABI and EABI disagree on the alignment of structures
      with small members, so module init tools may interpret the
      ssb device table incorrectly, as shown  by this warning when
      building the b43 device driver in an OABI kernel:
      
      FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
      not a modulo of the size of section __mod_ssb_device_table=88.
      
      Forcing the default (EABI) alignment on the structure makes this
      problem go away. Since the ssb_device_id may have the same problem,
      better fix both structures.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Michael Buesch <mb@bu3sch.de>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b01a60be
  4. 17 Jul, 2013 3 commits
  5. 16 Jul, 2013 16 commits
  6. 14 Jul, 2013 6 commits
    • Linus Torvalds's avatar
      Linux 3.11-rc1 · ad81f054
      Linus Torvalds authored
      ad81f054
    • Linus Torvalds's avatar
      Merge branch 'slab/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux · 54be8200
      Linus Torvalds authored
      Pull slab update from Pekka Enberg:
       "Highlights:
      
        - Fix for boot-time problems on some architectures due to
          init_lock_keys() not respecting kmalloc_caches boundaries
          (Christoph Lameter)
      
        - CONFIG_SLUB_CPU_PARTIAL requested by RT folks (Joonsoo Kim)
      
        - Fix for excessive slab freelist draining (Wanpeng Li)
      
        - SLUB and SLOB cleanups and fixes (various people)"
      
      I ended up editing the branch, and this avoids two commits at the end
      that were immediately reverted, and I instead just applied the oneliner
      fix in between myself.
      
      * 'slab/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux
        slub: Check for page NULL before doing the node_match check
        mm/slab: Give s_next and s_stop slab-specific names
        slob: Check for NULL pointer before calling ctor()
        slub: Make cpu partial slab support configurable
        slab: add kmalloc() to kernel API documentation
        slab: fix init_lock_keys
        slob: use DIV_ROUND_UP where possible
        slub: do not put a slab to cpu partial list when cpu_partial is 0
        mm/slub: Use node_nr_slabs and node_nr_objs in get_slabinfo
        mm/slub: Drop unnecessary nr_partials
        mm/slab: Fix /proc/slabinfo unwriteable for slab
        mm/slab: Sharing s_next and s_stop between slab and slub
        mm/slab: Fix drain freelist excessively
        slob: Rework #ifdeffery in slab.h
        mm, slab: moved kmem_cache_alloc_node comment to correct place
      54be8200
    • Steven Rostedt's avatar
      slub: Check for page NULL before doing the node_match check · c25f195e
      Steven Rostedt authored
      
      
      In the -rt kernel (mrg), we hit the following dump:
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff811573f1>] kmem_cache_alloc_node+0x51/0x180
      PGD a2d39067 PUD b1641067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: sunrpc cpufreq_ondemand ipv6 tg3 joydev sg serio_raw pcspkr k8temp amd64_edac_mod edac_core i2c_piix4 e100 mii shpchp ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom sata_svw ata_generic pata_acpi pata_serverworks radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
      CPU 3
      Pid: 20878, comm: hackbench Not tainted 3.6.11-rt25.14.el6rt.x86_64 #1 empty empty/Tyan Transport GT24-B3992
      RIP: 0010:[<ffffffff811573f1>]  [<ffffffff811573f1>] kmem_cache_alloc_node+0x51/0x180
      RSP: 0018:ffff8800a9b17d70  EFLAGS: 00010213
      RAX: 0000000000000000 RBX: 0000000001200011 RCX: ffff8800a06d8000
      RDX: 0000000004d92a03 RSI: 00000000000000d0 RDI: ffff88013b805500
      RBP: ffff8800a9b17dc0 R08: ffff88023fd14d10 R09: ffffffff81041cbd
      R10: 00007f4e3f06e9d0 R11: 0000000000000246 R12: ffff88013b805500
      R13: ffff8801ff46af40 R14: 0000000000000001 R15: 0000000000000000
      FS:  00007f4e3f06e700(0000) GS:ffff88023fd00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 00000000a2d3a000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process hackbench (pid: 20878, threadinfo ffff8800a9b16000, task ffff8800a06d8000)
      Stack:
       ffff8800a9b17da0 ffffffff81202e08 ffff8800a9b17de0 000000d001200011
       0000000001200011 0000000001200011 0000000000000000 0000000000000000
       00007f4e3f06e9d0 0000000000000000 ffff8800a9b17e60 ffffffff81041cbd
      Call Trace:
       [<ffffffff81202e08>] ? current_has_perm+0x68/0x80
       [<ffffffff81041cbd>] copy_process+0xdd/0x15b0
       [<ffffffff810a2125>] ? rt_up_read+0x25/0x30
       [<ffffffff8104369a>] do_fork+0x5a/0x360
       [<ffffffff8107c66b>] ? migrate_enable+0xeb/0x220
       [<ffffffff8100b068>] sys_clone+0x28/0x30
       [<ffffffff81527423>] stub_clone+0x13/0x20
       [<ffffffff81527152>] ? system_call_fastpath+0x16/0x1b
      Code: 89 fc 89 75 cc 41 89 d6 4d 8b 04 24 65 4c 03 04 25 48 ae 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 74 12 41 83 fe ff 74 27 <48> 8b 00 48 c1 e8 3a 41 39 c6 74 1b 8b 75 cc 4c 89 c9 44 89 f2
      RIP  [<ffffffff811573f1>] kmem_cache_alloc_node+0x51/0x180
       RSP <ffff8800a9b17d70>
      CR2: 0000000000000000
      ---[ end trace 0000000000000002 ]---
      
      Now, this uses SLUB pretty much unmodified, but as it is the -rt kernel
      with CONFIG_PREEMPT_RT set, spinlocks are mutexes, although they do
      disable migration. But the SLUB code is relatively lockless, and the
      spin_locks there are raw_spin_locks (not converted to mutexes), thus I
      believe this bug can happen in mainline without -rt features. The -rt
      patch is just good at triggering mainline bugs ;-)
      
      Anyway, looking at where this crashed, it seems that the page variable
      can be NULL when passed to the node_match() function (which does not
      check if it is NULL). When this happens we get the above panic.
      
      As page is only used in slab_alloc() to check if the node matches, if
      it's NULL I'm assuming that we can say it doesn't and call the
      __slab_alloc() code. Is this a correct assumption?
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c25f195e
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 41d9884c
      Linus Torvalds authored
      Pull more vfs stuff from Al Viro:
       "O_TMPFILE ABI changes, Oleg's fput() series, misc cleanups, including
        making simple_lookup() usable for filesystems with non-NULL s_d_op,
        which allows us to get rid of quite a bit of ugliness"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        sunrpc: now we can just set ->s_d_op
        cgroup: we can use simple_lookup() now
        efivarfs: we can use simple_lookup() now
        make simple_lookup() usable for filesystems that set ->s_d_op
        configfs: don't open-code d_alloc_name()
        __rpc_lookup_create_exclusive: pass string instead of qstr
        rpc_create_*_dir: don't bother with qstr
        llist: llist_add() can use llist_add_batch()
        llist: fix/simplify llist_add() and llist_add_batch()
        fput: turn "list_head delayed_fput_list" into llist_head
        fs/file_table.c:fput(): add comment
        Safer ABI for O_TMPFILE
      41d9884c
    • Al Viro's avatar
      sunrpc: now we can just set ->s_d_op · dae3794f
      Al Viro authored
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      dae3794f
    • Al Viro's avatar
      cgroup: we can use simple_lookup() now · 786e1448
      Al Viro authored
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      786e1448