1. 25 Aug, 2011 7 commits
    • Tejun Heo's avatar
      mtrr: fix UP breakage caused during switch to stop_machine · cbbfa38f
      Tejun Heo authored
      While removing custom rendezvous code and switching to stop_machine,
      commit 192d8857 ("x86, mtrr: use stop_machine APIs for doing MTRR
      rendezvous") completely dropped mtrr setting code on !CONFIG_SMP
      breaking MTRR settting on UP.
      
      Fix it by removing the incorrect CONFIG_SMP.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarAnders Eriksson <aeriksson@fastmail.fm>
      Tested-and-acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cbbfa38f
    • Josh Boyer's avatar
      lockdep: Add helper function for dir vs file i_mutex annotation · e096d0c7
      Josh Boyer authored
      Purely in-memory filesystems do not use the inode hash as the dcache
      tells us if an entry already exists.  As a result, they do not call
      unlock_new_inode, and thus directory inodes do not get put into a
      different lockdep class for i_sem.
      
      We need the different lockdep classes, because the locking order for
      i_mutex is different for directory inodes and regular inodes.  Directory
      inodes can do "readdir()", which takes i_mutex *before* possibly taking
      mm->mmap_sem (due to a page fault while copying the directory entry to
      user space).
      
      In contrast, regular inodes can be mmap'ed, which takes mm->mmap_sem
      before accessing i_mutex.
      
      The two cases can never happen for the same inode, so no real deadlock
      can occur, but without the different lockdep classes, lockdep cannot
      understand that.  As a result, if CONFIG_DEBUG_LOCK_ALLOC is set, this
      can lead to false positives from lockdep like below:
      
          find/645 is trying to acquire lock:
           (&mm->mmap_sem){++++++}, at: [<ffffffff81109514>] might_fault+0x5c/0xac
      
          but task is already holding lock:
           (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffff81149f34>]
          vfs_readdir+0x5b/0xb4
      
          which lock already depends on the new lock.
      
          the existing dependency chain (in reverse order) is:
      
          -> #1 (&sb->s_type->i_mutex_key#15){+.+.+.}:
                [<ffffffff8108ac26>] lock_acquire+0xbf/0x103
                [<ffffffff814db822>] __mutex_lock_common+0x4c/0x361
                [<ffffffff814dbc46>] mutex_lock_nested+0x40/0x45
                [<ffffffff811daa87>] hugetlbfs_file_mmap+0x82/0x110
                [<ffffffff81111557>] mmap_region+0x258/0x432
                [<ffffffff811119dd>] do_mmap_pgoff+0x2ac/0x306
                [<ffffffff81111b4f>] sys_mmap_pgoff+0x118/0x16a
                [<ffffffff8100c858>] sys_mmap+0x22/0x24
                [<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b
      
          -> #0 (&mm->mmap_sem){++++++}:
                [<ffffffff8108a4bc>] __lock_acquire+0xa1a/0xcf7
                [<ffffffff8108ac26>] lock_acquire+0xbf/0x103
                [<ffffffff81109541>] might_fault+0x89/0xac
                [<ffffffff81149cff>] filldir+0x6f/0xc7
                [<ffffffff811586ea>] dcache_readdir+0x67/0x205
                [<ffffffff81149f54>] vfs_readdir+0x7b/0xb4
                [<ffffffff8114a073>] sys_getdents+0x7e/0xd1
                [<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b
      
      This patch moves the directory vs file lockdep annotation into a helper
      function that can be called by in-memory filesystems and has hugetlbfs
      call it.
      Signed-off-by: default avatarJosh Boyer <jwboyer@redhat.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e096d0c7
    • Linus Torvalds's avatar
      e33f2d23
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/brodo/cpupowerutils · be5378f3
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/brodo/cpupowerutils:
        cpupower: use man(1) when calling "cpupower help subcommand"
        cpupower: make NLS truly optional
        cpupower: fix Makefile typo
        cpupower: Make monitor command -c/--cpu aware
        cpupower: Better detect offlined CPUs
        cpupower: Do not show an empty Idle_Stats monitor if no idle driver is available
        cpupower: mperf monitor - Use TSC to calculate max frequency if possible
        cpupower: avoid using symlinks
      be5378f3
    • Linus Torvalds's avatar
      Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging · e5b1d9cc
      Linus Torvalds authored
      * 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging:
        hwmon: (i5k_amb) Drop i5k_channel_pci_id
        hwmon: (ntc_thermistor) Simplify if sequence
      e5b1d9cc
    • Linus Torvalds's avatar
      Merge branch '3.1-rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending · f385b697
      Linus Torvalds authored
      * '3.1-rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: (21 commits)
        target: Convert acl_node_lock to be IRQ-disabling
        target: Make locking in transport_deregister_session() IRQ safe
        tcm_fc: init/exit functions should not be protected by "#ifdef MODULE"
        target: Print subpage too for unhandled MODE SENSE pages
        iscsi-target: Fix iscsit_allocate_se_cmd_for_tmr failure path bugs
        iscsi-target: Implement iSCSI target IPv6 address printing.
        target: Fix task SGL chaining breakage with transport_allocate_data_tasks
        target: Fix task count > 1 handling breakage and use max_sector page alignment
        target: Add missing DATA_SG_IO transport_cmd_get_valid_sectors check
        target: Fix SYNCHRONIZE_CACHE zero LBA + range breakage
        target: Remove duplicate task completions in transport_emulate_control_cdb
        target: Fix WRITE_SAME usage with transport_get_size
        target: Add WRITE_SAME (10) parsing and refactor passthrough checks
        target: Fix write payload exception handling with ->new_cmd_map
        iscsi-target: forever loop bug in iscsit_attach_ooo_cmdsn()
        iscsi-target: remove duplicate return
        target: Convert target_core_rd.c to use use BUG_ON
        iscsi-target: Fix leak on failure in iscsi_copy_param_list()
        target: Use ERR_CAST inlined function
        target: Make standard INQUIRY return 'not connected' for tpg_virt_lun0
        ...
      f385b697
    • Andi Kleen's avatar
      Add a personality to report 2.6.x version numbers · be27425d
      Andi Kleen authored
      I ran into a couple of programs which broke with the new Linux 3.0
      version.  Some of those were binary only.  I tried to use LD_PRELOAD to
      work around it, but it was quite difficult and in one case impossible
      because of a mix of 32bit and 64bit executables.
      
      For example, all kind of management software from HP doesnt work, unless
      we pretend to run a 2.6 kernel.
      
        $ uname -a
        Linux svivoipvnx001 3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux
      
        $ hpacucli ctrl all show
      
        Error: No controllers detected.
      
        $ rpm -qf /usr/sbin/hpacucli
        hpacucli-8.75-12.0
      
      Another notable case is that Python now reports "linux3" from
      sys.platform(); which in turn can break things that were checking
      sys.platform() == "linux2":
      
        https://bugzilla.mozilla.org/show_bug.cgi?id=664564
      
      It seems pretty clear to me though it's a bug in the apps that are using
      '==' instead of .startswith(), but this allows us to unbreak broken
      programs.
      
      This patch adds a UNAME26 personality that makes the kernel report a
      2.6.40+x version number instead.  The x is the x in 3.x.
      
      I know this is somewhat ugly, but I didn't find a better workaround, and
      compatibility to existing programs is important.
      
      Some programs also read /proc/sys/kernel/osrelease.  This can be worked
      around in user space with mount --bind (and a mount namespace)
      
      To use:
      
        wget ftp://ftp.kernel.org/pub/linux/kernel/people/ak/uname26/uname26.c
        gcc -o uname26 uname26.c
        ./uname26 program
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      be27425d
  2. 24 Aug, 2011 12 commits
  3. 23 Aug, 2011 18 commits
  4. 22 Aug, 2011 3 commits