1. 06 May, 2009 6 commits
    • Andi Kleen's avatar
      Eliminate thousands of warnings with gcc 3.2 build · 57adc4d2
      Andi Kleen authored
      When building with gcc 3.2 I get thousands of warnings such as
      
      include/linux/gfp.h: In function `allocflags_to_migratetype':
      include/linux/gfp.h:105: warning: null format string
      
      due to passing a NULL format string to warn_slowpath() in
      
      #define __WARN()		warn_slowpath(__FILE__, __LINE__, NULL)
      
      Split this case out into a separate call.  This also shrinks the kernel
      slightly:
      
                text    data     bss     dec     hex filename
             4802274  707668  712704 6222646  5ef336 vmlinux
                text    data     bss     dec     hex filename
             4799027  703572  712704 6215303  5ed687 vmlinux
      
      due to removeing one argument from the commonly-called __WARN().
      
      [akpm@linux-foundation.org: reduce scope of `empty']
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57adc4d2
    • Hugh Dickins's avatar
      doc: hashdist defaults on for 64bit · 429aa0fc
      Hugh Dickins authored
      kernel boot parameter `hashdist' now defaults on for all 64bit NUMA.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Acked-by: default avatarMel Gorman <mel@csn.ul.ie>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      429aa0fc
    • Wu Fengguang's avatar
      inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positive · 381a80e6
      Wu Fengguang authored
      There is what we believe to be a false positive reported by lockdep.
      
      inotify_inode_queue_event() => take inotify_mutex => kernel_event() =>
      kmalloc() => SLOB => alloc_pages_node() => page reclaim => slab reclaim =>
      dcache reclaim => inotify_inode_is_dead => take inotify_mutex => deadlock
      
      The plan is to fix this via lockdep annotation, but that is proving to be
      quite involved.
      
      The patch flips the allocation over to GFP_NFS to shut the warning up, for
      the 2.6.30 release.
      
      Hopefully we will fix this for real in 2.6.31.  I'll queue a patch in -mm
      to switch it back to GFP_KERNEL so we don't forget.
      
        =================================
        [ INFO: inconsistent lock state ]
        2.6.30-rc2-next-20090417 #203
        ---------------------------------
        inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
        kswapd0/380 [HC0[0]:SC0[0]:HE1:SE1] takes:
         (&inode->inotify_mutex){+.+.?.}, at: [<ffffffff8112f1b5>] inotify_inode_is_dead+0x35/0xb0
        {RECLAIM_FS-ON-W} state was registered at:
          [<ffffffff81079188>] mark_held_locks+0x68/0x90
          [<ffffffff810792a5>] lockdep_trace_alloc+0xf5/0x100
          [<ffffffff810f5261>] __kmalloc_node+0x31/0x1e0
          [<ffffffff81130652>] kernel_event+0xe2/0x190
          [<ffffffff81130826>] inotify_dev_queue_event+0x126/0x230
          [<ffffffff8112f096>] inotify_inode_queue_event+0xc6/0x110
          [<ffffffff8110444d>] vfs_create+0xcd/0x140
          [<ffffffff8110825d>] do_filp_open+0x88d/0xa20
          [<ffffffff810f6b68>] do_sys_open+0x98/0x140
          [<ffffffff810f6c50>] sys_open+0x20/0x30
          [<ffffffff8100c272>] system_call_fastpath+0x16/0x1b
          [<ffffffffffffffff>] 0xffffffffffffffff
        irq event stamp: 690455
        hardirqs last  enabled at (690455): [<ffffffff81564fe4>] _spin_unlock_irqrestore+0x44/0x80
        hardirqs last disabled at (690454): [<ffffffff81565372>] _spin_lock_irqsave+0x32/0xa0
        softirqs last  enabled at (690178): [<ffffffff81052282>] __do_softirq+0x202/0x220
        softirqs last disabled at (690157): [<ffffffff8100d50c>] call_softirq+0x1c/0x50
      
        other info that might help us debug this:
        2 locks held by kswapd0/380:
         #0:  (shrinker_rwsem){++++..}, at: [<ffffffff810d0bd7>] shrink_slab+0x37/0x180
         #1:  (&type->s_umount_key#17){++++..}, at: [<ffffffff8110cfbf>] shrink_dcache_memory+0x11f/0x1e0
      
        stack backtrace:
        Pid: 380, comm: kswapd0 Not tainted 2.6.30-rc2-next-20090417 #203
        Call Trace:
         [<ffffffff810789ef>] print_usage_bug+0x19f/0x200
         [<ffffffff81018bff>] ? save_stack_trace+0x2f/0x50
         [<ffffffff81078f0b>] mark_lock+0x4bb/0x6d0
         [<ffffffff810799e0>] ? check_usage_forwards+0x0/0xc0
         [<ffffffff8107b142>] __lock_acquire+0xc62/0x1ae0
         [<ffffffff810f478c>] ? slob_free+0x10c/0x370
         [<ffffffff8107c0a1>] lock_acquire+0xe1/0x120
         [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0
         [<ffffffff81562d43>] mutex_lock_nested+0x63/0x420
         [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0
         [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0
         [<ffffffff81012fe9>] ? sched_clock+0x9/0x10
         [<ffffffff81077165>] ? lock_release_holdtime+0x35/0x1c0
         [<ffffffff8112f1b5>] inotify_inode_is_dead+0x35/0xb0
         [<ffffffff8110c9dc>] dentry_iput+0xbc/0xe0
         [<ffffffff8110cb23>] d_kill+0x33/0x60
         [<ffffffff8110ce23>] __shrink_dcache_sb+0x2d3/0x350
         [<ffffffff8110cffa>] shrink_dcache_memory+0x15a/0x1e0
         [<ffffffff810d0cc5>] shrink_slab+0x125/0x180
         [<ffffffff810d1540>] kswapd+0x560/0x7a0
         [<ffffffff810ce160>] ? isolate_pages_global+0x0/0x2c0
         [<ffffffff81065a30>] ? autoremove_wake_function+0x0/0x40
         [<ffffffff8107953d>] ? trace_hardirqs_on+0xd/0x10
         [<ffffffff810d0fe0>] ? kswapd+0x0/0x7a0
         [<ffffffff8106555b>] kthread+0x5b/0xa0
         [<ffffffff8100d40a>] child_rip+0xa/0x20
         [<ffffffff8100cdd0>] ? restore_args+0x0/0x30
         [<ffffffff81065500>] ? kthread+0x0/0xa0
         [<ffffffff8100d400>] ? child_rip+0x0/0x20
      
      [eparis@redhat.com: fix audit too]
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Christoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      381a80e6
    • Breno Leitao's avatar
      jsm: removing unused spinlock · fd1e6c1d
      Breno Leitao authored
      This patch removes bd_lock spinlock (inside jsm_board structure).
      The lock is initialized in the probe function and not used anymore.
      Signed-off-by: default avatarBreno Leitao <leitao@linux.vnet.ibm.com>
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fd1e6c1d
    • Alan Cox's avatar
      vt: Add a note on the historical abuse of CLOCK_TICK_RATE · fab89223
      Alan Cox authored
      This is one area where we can't just magic away the bizarre use of
      CLOCK_TICK_RATE as it leaks to user space APIs. It also means the visible
      CLOCK_TICK_RATE is frozen for architectures which is horrible.
      
      We need to fix this somehow
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fab89223
    • Linus Torvalds's avatar
      Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 · 413f81eb
      Linus Torvalds authored
      * 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
        drm/r128: fix r128 ioremaps to use ioremap_wc.
        drm: cleanup properly in drm_get_dev() failure paths
        drm: clean the map list before destroying the hash table
        drm: remove unreachable code in drm_sysfs.c
        drm: add control node checks missing from kms merge
        drm/kms: don't try to shortcut drm mode set function
        drm/radeon: bump minor version for occlusion queries support
      413f81eb
  2. 05 May, 2009 24 commits
  3. 04 May, 2009 10 commits
    • Stephen Smalley's avatar
      selinux: Fix send_sigiotask hook · 65c90bca
      Stephen Smalley authored
      The CRED patch incorrectly converted the SELinux send_sigiotask hook to
      use the current task SID rather than the target task SID in its
      permission check, yielding the wrong permission check.  This fixes the
      hook function.  Detected by the ltp selinux testsuite and confirmed to
      correct the test failure.
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      65c90bca
    • Jake Edge's avatar
      proc: avoid information leaks to non-privileged processes · f83ce3e6
      Jake Edge authored
      By using the same test as is used for /proc/pid/maps and /proc/pid/smaps,
      only allow processes that can ptrace() a given process to see information
      that might be used to bypass address space layout randomization (ASLR).
      These include eip, esp, wchan, and start_stack in /proc/pid/stat as well
      as the non-symbolic output from /proc/pid/wchan.
      
      ASLR can be bypassed by sampling eip as shown by the proof-of-concept
      code at http://code.google.com/p/fuzzyaslr/ As part of a presentation
      (http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were
      also noted as possibly usable information leaks as well.  The
      start_stack address also leaks potentially useful information.
      
      Cc: Stable Team <stable@kernel.org>
      Signed-off-by: default avatarJake Edge <jake@lwn.net>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f83ce3e6
    • Marcel Holtmann's avatar
      Bluetooth: Fix issue with sysfs handling for connections · a67e899c
      Marcel Holtmann authored
      Due to a semantic changes in flush_workqueue() the current approach of
      synchronizing the sysfs handling for connections doesn't work anymore. The
      whole approach is actually fully broken and based on assumptions that are
      no longer valid.
      
      With the introduction of Simple Pairing support, the creation of low-level
      ACL links got changed. This change invalidates the reason why in the past
      two independent work queues have been used for adding/removing sysfs
      devices. The adding of the actual sysfs device is now postponed until the
      host controller successfully assigns an unique handle to that link. So
      the real synchronization happens inside the controller and not the host.
      
      The only left-over problem is that some internals of the sysfs device
      handling are not initialized ahead of time. This leaves potential access
      to invalid data and can cause various NULL pointer dereferences. To fix
      this a new function makes sure that all sysfs details are initialized
      when an connection attempt is made. The actual sysfs device is only
      registered when the connection has been successfully established. To
      avoid a race condition with the registration, the check if a device is
      registered has been moved into the removal work.
      
      As an extra protection two flush_work() calls are left in place to
      make sure a previous add/del work has been completed first.
      
      Based on a report by Marc Pignat <marc.pignat@hevs.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Tested-by: default avatarMarc Pignat <marc.pignat@hevs.ch>
      a67e899c
    • Omar Laazimani's avatar
      usbnet: CDC EEM support (v5) · 9f722c09
      Omar Laazimani authored
      This introduces a CDC Ethernet Emulation Model (EEM) host side
      driver to support USB EEM devices.
      
      EEM is different from the Ethernet Control Model (ECM) currently
      supported by the "CDC Ethernet" driver.  One key difference is
      that it doesn't require of USB interface alternate settings to
      manage interface state; some maldesigned hardware can't handle
      that part of USB.  It also avoids a separate USB interface for
      control and status updates.
      
      [ dbrownell@users.sourceforge.net: fix skb leaks, add rx packet
      checks, improve fault handling, EEM conformance updates, cleanup ]
      Signed-off-by: default avatarOmar Laazimani <omar.oberthur@gmail.com>
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f722c09
    • Andreas Herrmann's avatar
      x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo · 35d11680
      Andreas Herrmann authored
      Commit 7ad728f9
      (cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t)
      changed the output of /proc/cpuinfo for siblings:
      
      Example on an AMD Phenom:
      
        physical id   : 0
        siblings : 1
        core id	   : 3
        cpu cores  : 4
      
      Before that commit it was:
      
        physical id	: 0
        siblings : 4
        core id	   : 3
        cpu cores  : 4
      
      Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings.
      This is due to the following hunk of above commit:
      
      |  --- a/arch/x86/kernel/cpu/proc.c
      |  +++ b/arch/x86/kernel/cpu/proc.c
      |  @@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf
      |          if (c->x86_max_cores * smp_num_siblings > 1) {
      |                  seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
      |                  seq_printf(m, "siblings\t: %d\n",
      |  -                          cpus_weight(per_cpu(cpu_core_map, cpu)));
      |  +                          cpumask_weight(cpu_sibling_mask(cpu)));
      |                  seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
      |                  seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
      |                  seq_printf(m, "apicid\t\t: %d\n", c->apicid);
      
      This was a mistake, because the impact line shows that this side-effect
      was not anticipated:
      
         Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y
      
      So revert the respective hunk to restore the old behavior.
      
      [ Impact: fix sibling-info regression in /proc/cpuinfo ]
      Signed-off-by: default avatarAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      LKML-Reference: <20090504182859.GA29045@alberich.amd.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      35d11680
    • Satoru SATOH's avatar
      tcp: Fix tcp_prequeue() to get correct rto_min value · 0c266898
      Satoru SATOH authored
      tcp_prequeue() refers to the constant value (TCP_RTO_MIN) regardless of
      the actual value might be tuned. The following patches fix this and make
      tcp_prequeue get the actual value returns from tcp_rto_min().
      Signed-off-by: default avatarSatoru SATOH <satoru.satoh@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c266898
    • Hannes Hering's avatar
      ehea: fix invalid pointer access · 0b2febf3
      Hannes Hering authored
      This patch fixes an invalid pointer access in case the receive queue
      holds no pointer to the next skb when the queue is empty.
      Signed-off-by: default avatarHannes Hering <hering2@de.ibm.com>
      Signed-off-by: default avatarJan-Bernd Themann <themann@de.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b2febf3
    • Takashi Iwai's avatar
      Merge branch 'fix/misc' into for-linus · 5d7ee52f
      Takashi Iwai authored
      * fix/misc:
        ALSA: indigo-express: add missing 64KHz flags
      5d7ee52f
    • Takashi Iwai's avatar
      Merge branch 'fix/asoc' into for-linus · dea6a9d3
      Takashi Iwai authored
      * fix/asoc:
        ASoC: Remove BROKEN from mpc5200 kconfig
        ASoC: TWL4030: Fix gain control for earpiece amplifier
        ASoC: Set the MPC5200 i2s driver to BROKEN status.
        ASoC: Fix logic in WM8350 master clocking check
      dea6a9d3
    • Takashi Iwai's avatar
      Merge branch 'fix/pcm-jiffies-check' into for-linus · 56dc16f7
      Takashi Iwai authored
      * fix/pcm-jiffies-check:
        ALSA: pcm core - Avoid jiffies check for devices with BATCH flag
        ALSA: Add missing SNDRV_PCM_INFO_BATCH flag to some drivers
      56dc16f7