1. 08 Jun, 2013 3 commits
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma · d7a39e30
      Linus Torvalds authored
      Pull slave-dmaengine fixes from Vinod Koul:
       "Fix from Andy is for dmatest regression reported by Will and Rabin has
        fixed runtime ref counting for st_dma40"
      
      * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
        dmatest: do not allow to interrupt ongoing tests
        dmaengine: ste_dma40: fix pm runtime ref counting
      d7a39e30
    • Linus Torvalds's avatar
      Merge tag 'trace-fixes-v3.10-rc3-v3' of... · 14d0ee05
      Linus Torvalds authored
      Merge tag 'trace-fixes-v3.10-rc3-v3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull tracing fixes from Steven Rostedt:
       "This contains 4 fixes.
      
        The first two fix the case where full RCU debugging is enabled,
        enabling function tracing causes a live lock of the system.  This is
        due to the added debug checks in rcu_dereference_raw() that is used by
        the function tracer.  These checks are also traced by the function
        tracer as well as cause enough overhead to the function tracer to slow
        down the system enough that the time to finish an interrupt can take
        longer than when the next interrupt is triggered, causing a live lock
        from the timer interrupt.
      
        Talking this over with Paul McKenney, we came up with a fix that adds
        a new rcu_dereference_raw_notrace() that does not perform these added
        checks, and let the function tracer use that.
      
        The third commit fixes a failed compile when branch tracing is
        enabled, due to the conversion of the trace_test_buffer() selftest
        that the branch trace wasn't converted for.
      
        The forth patch fixes a bug caught by the RCU lockdep code where a
        rcu_read_lock() is performed when rcu is disabled (either going to or
        from idle, or user space).  This happened on the irqsoff tracer as it
        calls task_uid().  The fix here was to use current_uid() when possible
        that doesn't use rcu locking.  Which luckily, is always used when
        irqsoff calls this code."
      
      * tag 'trace-fixes-v3.10-rc3-v3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Use current_uid() for critical time tracing
        tracing: Fix bad parameter passed in branch selftest
        ftrace: Use the rcu _notrace variants for rcu_dereference_raw() and friends
        rcu: Add _notrace variation of rcu_dereference_raw() and hlist_for_each_entry_rcu()
      14d0ee05
    • Rafael J. Wysocki's avatar
      Revert "ACPI / scan: do not match drivers against objects having scan handlers" · ea7f6656
      Rafael J. Wysocki authored
      Commit 9f29ab11 ("ACPI / scan: do not match drivers against objects
      having scan handlers") introduced a boot regression on Tony's ia64 HP
      rx2600.  Tony says:
      
        "It panics with the message:
      
         Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel
      
         [...] my problem comes from arch/ia64/hp/common/sba_iommu.c
         where the code in sba_init() says:
      
              acpi_bus_register_driver(&acpi_sba_ioc_driver);
              if (!ioc_list) {
      
         but because of this change we never managed to call ioc_init()
         so ioc_list doesn't get set up, and we die."
      
      Revert it to avoid this breakage and we'll fix the problem it attempted
      to address later.
      Reported-by: default avatarTony Luck <tony.luck@gmail.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ea7f6656
  2. 07 Jun, 2013 11 commits
  3. 06 Jun, 2013 18 commits
    • Linus Torvalds's avatar
      Merge tag 'staging-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · e2b02e25
      Linus Torvalds authored
      Pull staging driver fixes from Greg Kroah-Hartman:
       "Here are some staging and IIO driver fixes for the 3.10-rc5 release.
      
        All of them are tiny, and fix a number of reported issues (build and
        runtime)"
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      * tag 'staging-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        iio:inkern: Fix typo/bug in convert raw to processed.
        iio: frequency: ad4350: Fix bug / typo in mask
        inkern: iio_device_put after incorrect return/goto
        staging: alarm-dev: information leak in alarm_compat_ioctl()
        iio:callback buffer: free the scan_mask
        staging: alarm-dev: information leak in alarm_ioctl()
        drivers: staging: zcache: fix compile error
        staging: dwc2: fix value of dma_mask
      e2b02e25
    • Linus Torvalds's avatar
      Merge tag 'tty-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · 3b285cb2
      Linus Torvalds authored
      Pull tty/serial driver fixes from Greg Kroah-Hartman:
       "Here are some small bugfixes, and one revert, of serial driver issues
        that have been reported"
      
      * tag 'tty-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        Revert "serial: 8250: Make SERIAL_8250_RUNTIME_UARTS work correctly"
        serial: samsung: enable clock before clearing pending interrupts during init
        serial/imx: disable hardware flow control at startup
      3b285cb2
    • Linus Torvalds's avatar
      Merge tag 'usb-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · c6d6b9d1
      Linus Torvalds authored
      Pull USB fixes from Greg Kroah-Hartman:
       "Here are a number of USB bugfixes and new device ids for the 3.10-rc5
        tree.
      
        Nothing major here, a number of new device ids (and movement from the
        option to the zte_ev driver of a number of ids that we had previously
        gotten wrong, some xhci bugfixes, some usb-serial driver fixes that
        were recently found, some host controller fixes / reverts, and a
        variety of smaller other things"
      
      * tag 'usb-3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (29 commits)
        USB: option,zte_ev: move most ZTE CDMA devices to zte_ev
        USB: option: blacklist network interface on Huawei E1820
        USB: whiteheat: fix broken port configuration
        USB: serial: fix TIOCMIWAIT return value
        USB: mos7720: fix hardware flow control
        USB: keyspan: remove unused endpoint-array access
        USB: keyspan: fix bogus array index
        USB: zte_ev: fix broken open
        USB: serial: Add Option GTM681W to qcserial device table.
        USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device
        USB: EHCI: fix regression related to qh_refresh()
        usbfs: Increase arbitrary limit for USB 3 isopkt length
        USB: zte_ev: fix control-message timeouts
        USB: mos7720: fix message timeouts
        USB: iuu_phoenix: fix bulk-message timeout
        USB: ark3116: fix control-message timeout
        USB: mos7840: fix DMA to stack
        USB: mos7720: fix DMA to stack
        USB: visor: fix initialisation of Treo/Kyocera devices
        USB: serial: fix Treo/Kyocera interrrupt-in urb context
        ...
      c6d6b9d1
    • Linus Torvalds's avatar
      Merge tag 'pci-v3.10-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · c51aa6db
      Linus Torvalds authored
      Pull PCI fixes from Bjorn Helgaas:
       "This fixes a crash when booting a 32-bit kernel via the EFI boot stub.
      
        PCI ROM from EFI
            x86/PCI: Map PCI setup data with ioremap() so it can be in highmem"
      
      * tag 'pci-v3.10-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        x86/PCI: Map PCI setup data with ioremap() so it can be in highmem
      c51aa6db
    • Linus Torvalds's avatar
      Merge tag 'for-linus-v3.10-rc5' of git://oss.sgi.com/xfs/xfs · e6395b68
      Linus Torvalds authored
      Pull more xfs updates from Ben Myers:
       "Here are several fixes for filesystems with CRC support turned on:
        fixes for quota, remote attributes, and recovery.  There is also some
        feature work related to CRCs: the implementation of CRCs for the inode
        unlinked lists, disabling noattr2/attr2 options when appropriate, and
        bumping the maximum number of ACLs.
      
        I would have preferred to defer this last category of items to 3.11.
        This would require setting a feature bit for the on-disk changes, so
        there is some pressure to get these in 3.10.  I believe this
        represents the end of the CRC related queue.
      
         - Rework of dquot CRCs
         - Fix for remote attribute invalidation of a leaf
         - Fix ordering of transaction replay in recovery
         - Implement CRCs for inode unlinked list
         - Disable noattr2/attr2 mount options when CRCs are enabled
         - Bump the limitation of ACL entries for v5 superblocks"
      
      * tag 'for-linus-v3.10-rc5' of git://oss.sgi.com/xfs/xfs:
        xfs: increase number of ACL entries for V5 superblocks
        xfs: disable noattr2/attr2 mount options for CRC enabled filesystems
        xfs: inode unlinked list needs to recalculate the inode CRC
        xfs: fix log recovery transaction item reordering
        xfs: fix remote attribute invalidation for a leaf
        xfs: rework dquot CRCs
      e6395b68
    • Andy Lutomirski's avatar
      net: Unbreak compat_sys_{send,recv}msg · a7526eb5
      Andy Lutomirski authored
      I broke them in this commit:
      
          commit 1be374a0
          Author: Andy Lutomirski <luto@amacapital.net>
          Date:   Wed May 22 14:07:44 2013 -0700
      
              net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
      
      This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept
      MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints.  It
      also reverts some unnecessary checks in sys_socketcall.
      
      Apparently I was suffering from underscore blindness the first time around.
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Tested-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7526eb5
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Use current_uid() for critical time tracing · f17a5194
      Steven Rostedt (Red Hat) authored
      The irqsoff tracer records the max time that interrupts are disabled.
      There are hooks in the assembly code that calls back into the tracer when
      interrupts are disabled or enabled.
      
      When they are enabled, the tracer checks if the amount of time they
      were disabled is larger than the previous recorded max interrupts off
      time. If it is, it creates a snapshot of the currently running trace
      to store where the last largest interrupts off time was held and how
      it happened.
      
      During testing, this RCU lockdep dump appeared:
      
      [ 1257.829021] ===============================
      [ 1257.829021] [ INFO: suspicious RCU usage. ]
      [ 1257.829021] 3.10.0-rc1-test+ #171 Tainted: G        W
      [ 1257.829021] -------------------------------
      [ 1257.829021] /home/rostedt/work/git/linux-trace.git/include/linux/rcupdate.h:780 rcu_read_lock() used illegally while idle!
      [ 1257.829021]
      [ 1257.829021] other info that might help us debug this:
      [ 1257.829021]
      [ 1257.829021]
      [ 1257.829021] RCU used illegally from idle CPU!
      [ 1257.829021] rcu_scheduler_active = 1, debug_locks = 0
      [ 1257.829021] RCU used illegally from extended quiescent state!
      [ 1257.829021] 2 locks held by trace-cmd/4831:
      [ 1257.829021]  #0:  (max_trace_lock){......}, at: [<ffffffff810e2b77>] stop_critical_timing+0x1a3/0x209
      [ 1257.829021]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff810dae5a>] __update_max_tr+0x88/0x1ee
      [ 1257.829021]
      [ 1257.829021] stack backtrace:
      [ 1257.829021] CPU: 3 PID: 4831 Comm: trace-cmd Tainted: G        W    3.10.0-rc1-test+ #171
      [ 1257.829021] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
      [ 1257.829021]  0000000000000001 ffff880065f49da8 ffffffff8153dd2b ffff880065f49dd8
      [ 1257.829021]  ffffffff81092a00 ffff88006bd78680 ffff88007add7500 0000000000000003
      [ 1257.829021]  ffff88006bd78680 ffff880065f49e18 ffffffff810daebf ffffffff810dae5a
      [ 1257.829021] Call Trace:
      [ 1257.829021]  [<ffffffff8153dd2b>] dump_stack+0x19/0x1b
      [ 1257.829021]  [<ffffffff81092a00>] lockdep_rcu_suspicious+0x109/0x112
      [ 1257.829021]  [<ffffffff810daebf>] __update_max_tr+0xed/0x1ee
      [ 1257.829021]  [<ffffffff810dae5a>] ? __update_max_tr+0x88/0x1ee
      [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff810dbf85>] update_max_tr_single+0x11d/0x12d
      [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff810e2b15>] stop_critical_timing+0x141/0x209
      [ 1257.829021]  [<ffffffff8109569a>] ? trace_hardirqs_on+0xd/0xf
      [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff810e3057>] time_hardirqs_on+0x2a/0x2f
      [ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff8109550c>] trace_hardirqs_on_caller+0x16/0x197
      [ 1257.829021]  [<ffffffff8109569a>] trace_hardirqs_on+0xd/0xf
      [ 1257.829021]  [<ffffffff811002b9>] user_enter+0xfd/0x107
      [ 1257.829021]  [<ffffffff810029b4>] do_notify_resume+0x92/0x97
      [ 1257.829021]  [<ffffffff8154bdca>] int_signal+0x12/0x17
      
      What happened was entering into the user code, the interrupts were enabled
      and a max interrupts off was recorded. The trace buffer was saved along with
      various information about the task: comm, pid, uid, priority, etc.
      
      The uid is recorded with task_uid(tsk). But this is a macro that uses rcu_read_lock()
      to retrieve the data, and this happened to happen where RCU is blind (user_enter).
      
      As only the preempt and irqs off tracers can have this happen, and they both
      only have the tsk == current, if tsk == current, use current_uid() instead of
      task_uid(), as current_uid() does not use RCU as only current can change its uid.
      
      This fixes the RCU suspicious splat.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      f17a5194
    • Dan Williams's avatar
      USB: option,zte_ev: move most ZTE CDMA devices to zte_ev · 73228a05
      Dan Williams authored
      Per some ZTE Linux drivers I found for the AC2716, the following patch
      moves most ZTE CDMA devices from option to zte_ev.  The blacklist stuff
      that option does is not required with zte_ev, because it doesn't
      implement any of the send_setup hooks which the blacklist suppressed.
      
      I did not move the 2718 over because I could not find any ZTE Linux
      drivers for that device, nor even any Windows drivers.
      Signed-off-by: default avatarDan Williams <dcbw@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73228a05
    • Bjørn Mork's avatar
      USB: option: blacklist network interface on Huawei E1820 · b8a24e62
      Bjørn Mork authored
      The mode used by Windows for the Huawei E1820 will use the
      same ff/ff/ff class codes for both serial and network
      functions.
      Reported-by: default avatarGraham Inggs <graham.inggs@uct.ac.za>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8a24e62
    • Johan Hovold's avatar
      USB: whiteheat: fix broken port configuration · 9eecf22d
      Johan Hovold authored
      When configuring the port (e.g. set_termios) the port minor number
      rather than the port number was used in the request (and they only
      coincide for minor number 0).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9eecf22d
    • Dave Chinner's avatar
      xfs: increase number of ACL entries for V5 superblocks · 0a8aa193
      Dave Chinner authored
      The limit of 25 ACL entries is arbitrary, but baked into the on-disk
      format.  For version 5 superblocks, increase it to the maximum nuber
      of ACLs that can fit into a single xattr.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinuguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 5c87d4bc)
      0a8aa193
    • Dave Chinner's avatar
      xfs: disable noattr2/attr2 mount options for CRC enabled filesystems · f763fd44
      Dave Chinner authored
      attr2 format is always enabled for v5 superblock filesystems, so the
      mount options to enable or disable it need to be cause mount errors.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit d3eaace8)
      f763fd44
    • Dave Chinner's avatar
      xfs: inode unlinked list needs to recalculate the inode CRC · ad868afd
      Dave Chinner authored
      The inode unlinked list manipulations operate directly on the inode
      buffer, and so bypass the inode CRC calculation mechanisms. Hence an
      inode on the unlinked list has an invalid CRC. Fix this by
      recalculating the CRC whenever we modify an unlinked list pointer in
      an inode, ncluding during log recovery. This is trivial to do and
      results in  unlinked list operations always leaving a consistent
      inode in the buffer.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 0a32c26e)
      ad868afd
    • Dave Chinner's avatar
      xfs: fix log recovery transaction item reordering · 75406170
      Dave Chinner authored
      There are several constraints that inode allocation and unlink
      logging impose on log recovery. These all stem from the fact that
      inode alloc/unlink are logged in buffers, but all other inode
      changes are logged in inode items. Hence there are ordering
      constraints that recovery must follow to ensure the correct result
      occurs.
      
      As it turns out, this ordering has been working mostly by chance
      than good management. The existing code moves all buffers except
      cancelled buffers to the head of the list, and everything else to
      the tail of the list. The problem with this is that is interleaves
      inode items with the buffer cancellation items, and hence whether
      the inode item in an cancelled buffer gets replayed is essentially
      left to chance.
      
      Further, this ordering causes problems for log recovery when inode
      CRCs are enabled. It typically replays the inode unlink buffer long before
      it replays the inode core changes, and so the CRC recorded in an
      unlink buffer is going to be invalid and hence any attempt to
      validate the inode in the buffer is going to fail. Hence we really
      need to enforce the ordering that the inode alloc/unlink code has
      expected log recovery to have since inode chunk de-allocation was
      introduced back in 2003...
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit a775ad77)
      75406170
    • Dave Chinner's avatar
      xfs: fix remote attribute invalidation for a leaf · ea929536
      Dave Chinner authored
      When invalidating an attribute leaf block block, there might be
      remote attributes that it points to. With the recent rework of the
      remote attribute format, we have to make sure we calculate the
      length of the attribute correctly. We aren't doing that in
      xfs_attr3_leaf_inactive(), so fix it.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinuguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 59913f14)
      ea929536
    • Dave Chinner's avatar
      xfs: rework dquot CRCs · bb9b8e86
      Dave Chinner authored
      Calculating dquot CRCs when the backing buffer is written back just
      doesn't work reliably. There are several places which manipulate
      dquots directly in the buffers, and they don't calculate CRCs
      appropriately, nor do they always set the buffer up to calculate
      CRCs appropriately.
      
      Firstly, if we log a dquot buffer (e.g. during allocation) it gets
      logged without valid CRC, and so on recovery we end up with a dquot
      that is not valid.
      
      Secondly, if we recover/repair a dquot, we don't have a verifier
      attached to the buffer and hence CRCs are not calculated on the way
      down to disk.
      
      Thirdly, calculating the CRC after we've changed the contents means
      that if we re-read the dquot from the buffer, we cannot verify the
      contents of the dquot are valid, as the CRC is invalid.
      
      So, to avoid all the dquot CRC errors that are being detected by the
      read verifier, change to using the same model as for inodes. That
      is, dquot CRCs are calculated and written to the backing buffer at
      the time the dquot is flushed to the backing buffer. If we modify
      the dquot directly in the backing buffer, calculate the CRC
      immediately after the modification is complete. Hence the dquot in
      the on-disk buffer should always have a valid CRC.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarBen Myers <bpm@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 6fcdc59d)
      bb9b8e86
    • Peter Zijlstra's avatar
      arch, mm: Remove tlb_fast_mode() · 29eb7782
      Peter Zijlstra authored
      Since the introduction of preemptible mmu_gather TLB fast mode has been
      broken. TLB fast mode relies on there being absolutely no concurrency;
      it frees pages first and invalidates TLBs later.
      
      However now we can get concurrency and stuff goes *bang*.
      
      This patch removes all tlb_fast_mode() code; it was found the better
      option vs trying to patch the hole by entangling tlb invalidation with
      the scheduler.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Tony Luck <tony.luck@intel.com>
      Reported-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      29eb7782
    • Linus Torvalds's avatar
      Merge branch 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild · 2c95523c
      Linus Torvalds authored
      Pull kbuild fixes from Michal Marek:
       "There is one fix for a kbuild regression, plus three kconfig fixes for
        bugs that have alway been there, but are simple enough to be fixed in
        an -rc"
      
      * 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
        kconfig/menu.c: fix multiple references to expressions in menu_add_prop()
        mconf: handle keys in empty dialogs
        kbuild: Don't assume dts files live in arch/*/boot/dts
        scripts/config: fix assignment of parameters for short version of --*-after options
      2c95523c
  4. 05 Jun, 2013 8 commits
    • Matt Fleming's avatar
      x86/PCI: Map PCI setup data with ioremap() so it can be in highmem · 65694c5a
      Matt Fleming authored
      f9a37be0 ("x86: Use PCI setup data") added support for using PCI ROM
      images from setup_data.  This used phys_to_virt(), which is not valid for
      highmem addresses, and can cause a crash when booting a 32-bit kernel via
      the EFI boot stub.
      
      pcibios_add_device() assumes that the physical addresses stored in
      setup_data are accessible via the direct kernel mapping, and that calling
      phys_to_virt() is valid.  This isn't guaranteed to be true on x86 where the
      direct mapping range is much smaller than on x86-64.
      
      Calling phys_to_virt() on a highmem address results in the following:
      
       BUG: unable to handle kernel paging request at 39a3c198
       IP: [<c262be0f>] pcibios_add_device+0x2f/0x90
       ...
       Call Trace:
        [<c2370c73>] pci_device_add+0xe3/0x130
        [<c274640b>] pci_scan_single_device+0x8b/0xb0
        [<c2370d08>] pci_scan_slot+0x48/0x100
        [<c2371904>] pci_scan_child_bus+0x24/0xc0
        [<c262a7b0>] pci_acpi_scan_root+0x2c0/0x490
        [<c23b7203>] acpi_pci_root_add+0x312/0x42f
        ...
      
      The solution is to use ioremap() instead of phys_to_virt() to map the
      setup data into the kernel address space.
      
      [bhelgaas: changelog]
      Tested-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: stable@vger.kernel.org	# v3.8+
      65694c5a
    • Johan Hovold's avatar
      USB: serial: fix TIOCMIWAIT return value · f4488035
      Johan Hovold authored
      Fix regression introduced by commit 143d9d96 ("USB: serial: add
      tiocmiwait subdriver operation") which made the ioctl operation return
      ENODEV rather than ENOIOCTLCMD when a subdriver TIOCMIWAIT
      implementation is missing.
      Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4488035
    • Alexey Kardashevskiy's avatar
      vfio: fix crash on rmmod · 9a6aa279
      Alexey Kardashevskiy authored
      devtmpfs_delete_node() calls devnode() callback with mode==NULL but
      vfio still tries to write there.
      
      The patch fixes this.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      9a6aa279
    • Guennadi Liakhovetski's avatar
      cpufreq: cpufreq-cpu0: use the exact frequency for clk_set_rate() · 0ca68436
      Guennadi Liakhovetski authored
      clk_set_rate() isn't supposed to accept approximate frequencies, instead
      a supported frequency should be obtained from clk_round_rate() and then
      used to set the clock.
      Signed-off-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Acked-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0ca68436
    • Michael Wang's avatar
      cpufreq: protect 'policy->cpus' from offlining during __gov_queue_work() · 2f7021a8
      Michael Wang authored
      Jiri Kosina <jkosina@suse.cz> and Borislav Petkov <bp@alien8.de>
      reported the warning:
      
      [   51.616759] ------------[ cut here ]------------
      [   51.621460] WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule+0x58/0x60()
      [   51.629638] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode
      [   51.675581] CPU: 0 PID: 244 Comm: kworker/1:1 Tainted: G        W    3.10.0-rc1+ #10
      [   51.683407] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08 01/24/2013
      [   51.690901] Workqueue: events od_dbs_timer
      [   51.695069]  0000000000000009 ffff88043a2f5b68 ffffffff8161441c ffff88043a2f5ba8
      [   51.702602]  ffffffff8103e540 0000000000000033 0000000000000001 ffff88043d5f8000
      [   51.710136]  00000000ffff0ce1 0000000000000001 ffff88044fc4fc08 ffff88043a2f5bb8
      [   51.717691] Call Trace:
      [   51.720191]  [<ffffffff8161441c>] dump_stack+0x19/0x1b
      [   51.725396]  [<ffffffff8103e540>] warn_slowpath_common+0x70/0xa0
      [   51.731473]  [<ffffffff8103e58a>] warn_slowpath_null+0x1a/0x20
      [   51.737378]  [<ffffffff81025628>] native_smp_send_reschedule+0x58/0x60
      [   51.744013]  [<ffffffff81072cfd>] wake_up_nohz_cpu+0x2d/0xa0
      [   51.749745]  [<ffffffff8104f6bf>] add_timer_on+0x8f/0x110
      [   51.755214]  [<ffffffff8105f6fe>] __queue_delayed_work+0x16e/0x1a0
      [   51.761470]  [<ffffffff8105f251>] ? try_to_grab_pending+0xd1/0x1a0
      [   51.767724]  [<ffffffff8105f78a>] mod_delayed_work_on+0x5a/0xa0
      [   51.773719]  [<ffffffff814f6b5d>] gov_queue_work+0x4d/0xc0
      [   51.779271]  [<ffffffff814f60cb>] od_dbs_timer+0xcb/0x170
      [   51.784734]  [<ffffffff8105e75d>] process_one_work+0x1fd/0x540
      [   51.790634]  [<ffffffff8105e6f2>] ? process_one_work+0x192/0x540
      [   51.796711]  [<ffffffff8105ef22>] worker_thread+0x122/0x380
      [   51.802350]  [<ffffffff8105ee00>] ? rescuer_thread+0x320/0x320
      [   51.808264]  [<ffffffff8106634a>] kthread+0xea/0xf0
      [   51.813200]  [<ffffffff81066260>] ? flush_kthread_worker+0x150/0x150
      [   51.819644]  [<ffffffff81623d5c>] ret_from_fork+0x7c/0xb0
      [   51.918165] nouveau E[     DRM] GPU lockup - switching to software fbcon
      [   51.930505]  [<ffffffff81066260>] ? flush_kthread_worker+0x150/0x150
      [   51.936994] ---[ end trace f419538ada83b5c5 ]---
      
      It was caused by the policy->cpus changed during the process of
      __gov_queue_work(), in other word, cpu offline happened.
      
      Use get/put_online_cpus() to prevent the offline from happening while
      __gov_queue_work() is running.
      
      [rjw: The problem has been present since recent commit 031299b3
      (cpufreq: governors: Avoid unnecessary per cpu timer interrupts)]
      
      References: https://lkml.org/lkml/2013/6/5/88Reported-by: default avatarBorislav Petkov <bp@alien8.de>
      Reported-and-tested-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarMichael Wang <wangyun@linux.vnet.ibm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2f7021a8
    • Aaron Lu's avatar
      ACPI / scan: do not match drivers against objects having scan handlers · 9f29ab11
      Aaron Lu authored
      With the introduction of ACPI scan handlers, an ACPI device object
      with an ACPI scan handler attached to it must not be bound to an ACPI
      driver any more.  Therefore it doesn't make sense to match those
      ACPI device objects against a newly registered ACPI driver in
      acpi_bus_match(), so make that function return 0 if the device
      object passed to it has an ACPI scan handler attached.
      
      This also addresses a regression related to a broken ACPI table in
      the BIOS, where it has defined a _ROM method under the PCI root
      bridge object.  This causes the video module to treat that object
      as a display controller device (since only display devices are
      supposed to have a _ROM method defined according to the ACPI spec).
      As a result, the ACPI video driver binds to the PCI root bridge
      object and overwrites the previously assigned driver_data field of
      it, causing subsequent calls to acpi_get_pci_dev() to fail.
      
      [rjw: Subject and changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=58091Reported-by: default avatarJason Cassell <bluesloth600@gmail.com>
      Reported-and-bisected-by: default avatarDmitry S. Demin <dmitryy.demin@gmail.com>
      Cc: 3.9+ <stable@kernel.org>
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9f29ab11
    • Wei Yongjun's avatar
      ACPI / APEI: fix error return code in ghes_probe() · a98d4f64
      Wei Yongjun authored
      Fix to return a negative error code in the acpi_gsi_to_irq() and
      request_irq() error handling case instead of 0, as done elsewhere
      in this function.
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Reviewed-by: default avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a98d4f64
    • Ross Lagerwall's avatar
      acpi-cpufreq: set current frequency based on target P-State · 8673b83b
      Ross Lagerwall authored
      Commit 4b31e774 (Always set P-state on initialization) fixed bug
      #4634 and caused the driver to always set the target P-State at
      least once since the initial P-State may not be the desired one.
      Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target()
      routine if target_freq == policy->cur) caused a regression in
      this behavior.
      
      This fixes the regression by setting policy->cur based on the CPU's
      target frequency rather than the CPU's current reported frequency
      (which may be different).  This means that the P-State will be set
      initially if the CPU's target frequency is different from the
      governor's target frequency.
      
      This fixes an issue where setting the default governor to
      performance wouldn't correctly enable turbo mode on all cores.
      Signed-off-by: default avatarRoss Lagerwall <rosslagerwall@gmail.com>
      Reviewed-by: default avatarLen Brown <len.brown@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: 3.8+ <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8673b83b