1. 15 2月, 2012 6 次提交
    • S
      USB/xHCI: Support device-initiated USB 3.0 resume. · 4ee823b8
      Sarah Sharp 提交于
      USB 3.0 hubs don't have a port suspend change bit (that bit is now
      reserved).  Instead, when a host-initiated resume finishes, the hub sets
      the port link state change bit.
      
      When a USB 3.0 device initiates remote wakeup, the parent hubs with
      their upstream links in U3 will pass the LFPS up the chain.  The first
      hub that has an upstream link in U0 (which may be the roothub) will
      reflect that LFPS back down the path to the device.
      
      However, the parent hubs in the resumed path will not set their link
      state change bit.  Instead, the device that initiated the resume has to
      send an asynchronous "Function Wake" Device Notification up to the host
      controller.  Therefore, we need a way to notify the USB core of a device
      resume without going through the normal hub URB completion method.
      
      First, make the xHCI roothub act like an external USB 3.0 hub and not
      pass up the port link state change bit when a device-initiated resume
      finishes.  Introduce a new xHCI bit field, port_remote_wakeup, so that
      we can tell the difference between a port coming out of the U3Exit state
      (host-initiated resume) and the RExit state (ending state of
      device-initiated resume).
      
      Since the USB core can't tell whether a port on a hub has resumed by
      looking at the Hub Status buffer, we need to introduce a bitfield,
      wakeup_bits, that indicates which ports have resumed.  When the xHCI
      driver notices a port finishing a device-initiated resume, we call into
      a new USB core function, usb_wakeup_notification(), that will set
      the right bit in wakeup_bits, and kick khubd for that hub.
      
      We also call usb_wakeup_notification() when the Function Wake Device
      Notification is received by the xHCI driver.  This covers the case where
      the link between the roothub and the first-tier hub is in U0, and the
      hub reflects the resume signaling back to the device without giving any
      indication it has done so until the device sends the Function Wake
      notification.
      
      Change the code in khubd that handles the remote wakeup to look at the
      state the USB core thinks the device is in, and handle the remote wakeup
      if the port's wakeup bit is set.
      
      This patch only takes care of the case where the device is attached
      directly to the roothub, or the USB 3.0 hub that is attached to the root
      hub is the device sending the Function Wake Device Notification (e.g.
      because a new USB device was attached).  The other cases will be covered
      in a second patch.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      4ee823b8
    • S
      USB: Refactor hub remote wake handling. · 714b07be
      Sarah Sharp 提交于
      Refactor the code to check for a remote wakeup on a port into its own
      function.  Keep the behavior the same, and set connect_change in
      hub_events if the device disconnected on resume.  Cleanup references to
      hdev->children[i-1] to use a common variable.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      714b07be
    • S
      USB/xHCI: Enable USB 3.0 hub remote wakeup. · 4296c70a
      Sarah Sharp 提交于
      USB 3.0 hubs have a different remote wakeup policy than USB 2.0 hubs.
      USB 2.0 hubs, once they have remote wakeup enabled, will always send
      remote wakes when anything changes on a port.
      
      However, USB 3.0 hubs have a per-port remote wake up policy that is off
      by default.  The Set Feature remote wake mask can be changed for any
      port, enabling remote wakeup for a connect, disconnect, or overcurrent
      event, much like EHCI and xHCI host controller "wake on" port status
      bits.  The bits are cleared to zero on the initial hub power on, or
      after the hub has been reset.
      
      Without this patch, when a USB 3.0 hub gets suspended, it will not send
      a remote wakeup on device connect or disconnect.  This would show up to
      the user as "dead ports" unless they ran lsusb -v (since newer versions
      of lsusb use the sysfs files, rather than sending control transfers).
      
      Change the hub driver's suspend method to enable remote wake up for
      disconnect, connect, and overcurrent for all ports on the hub.  Modify
      the xHCI driver's roothub code to handle that request, and set the "wake
      on" bits in the port status registers accordingly.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      4296c70a
    • S
      USB: Suspend functions before putting dev into U3. · 3b9b6acd
      Sarah Sharp 提交于
      The USB 3.0 bus specification introduces a new type of power management
      called function suspend.  The idea is to be able to suspend different
      functions (i.e. a scanner or an SD card reader on a USB printer)
      independently.  A device can be in U0, but have one or more functions
      suspended.  Thus, signaling a function resume with the standard device
      remote wake signaling was not possible.
      
      Instead, a device will (without prompt from the host) send a "device
      notification" for the function remote wake.  A new Set Feature Function
      Remote Wake was developed to turn remote wake up on and off for each
      function.
      
      USB 3.0 devices can still go into device suspend (U3), and signal a
      remote wakeup to bring the link back into U1.  However, they now use the
      function remote wake device notification to allow the host to know which
      function woke the device from U3.
      
      The spec is a bit ambiguous about whether a function is allowed to
      signal a remote wakeup if the function has been enabled for remote
      wakeup, but not placed in function suspend before the device is placed
      into U3.
      
      Section 9.2.5.1 says "Suspending a device with more than one function
      effectively suspends all the functions within the device."  I interpret
      that to mean that putting a device in U3 suspends all functions, and
      thus if the host has previously enabled remote wake for those functions,
      it should be able to signal a remote wake up on port status changes.
      However, hub vendors may have a different interpretation, and it can't
      hurt to put the function into suspend before putting the device into U3.
      
      I cannot get an answer out of the USB 3.0 spec architects about this
      ambiguity, so I'm erring on the safe side and always suspending the
      first function before placing the device in U3.  Note, this code should
      be fixed if we ever find any USB 3.0 devices that have more than one
      function.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      3b9b6acd
    • S
      USB/xhci: Enable remote wakeup for USB3 devices. · 623bef9e
      Sarah Sharp 提交于
      When the USB 3.0 hub support went in, I disabled selective suspend for
      all external USB 3.0 hubs because they used a different mechanism to
      enable remote wakeup.  In fact, other USB 3.0 devices that could signal
      remote wakeup would have been prevented from going into suspend because
      they would have stalled the SetFeature Device Remote Wakeup request.
      
      This patch adds support for the USB 3.0 way of enabling remote wake up
      (with a SetFeature Function Suspend request), and enables selective
      suspend for all hubs during hub_probe.  It assumes that all USB 3.0 have
      only one "function" as defined by the interface association descriptor,
      which is true of all the USB 3.0 devices I've seen so far.  FIXME if
      that turns out to change later.
      
      After a device signals a remote wakeup, it is supposed to send a Device
      Notification packet to the host controller, signaling which function
      sent the remote wakeup.  The host can then put any other functions back
      into function suspend.  Since we don't have support for function suspend
      (and no devices currently support it), we'll just assume the hub
      function will resume the device properly when it received the port
      status change notification, and simply ignore any device notification
      events from the xHCI host controller.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      623bef9e
    • S
      xHCI: Kick khubd when USB3 resume really completes. · d93814cf
      Sarah Sharp 提交于
      xHCI roothubs go through slightly different port state machines when
      either a device initiates a remote wakeup and signals resume, or when
      the host initiates a resume.
      
      According to section 4.19.1.2.13 of the xHCI 1.0 spec, on host-initiated
      resume, the xHC port state machine automatically goes through the U3Exit
      state into the U0 state, setting the port link state change (PLC) bit in
      the process.
      
      When a device initiates resume, the xHCI port state machine goes into
      the "Resume" state and sets the PLC bit.  Then the xHCI driver writes U0
      into the port link state register to transition the port to U0 from the
      Resume state.
      
      We can't be sure the device is actually in the U0 state until we receive
      the next port status change event with the PLC bit set.  We really don't
      want khubd to be polling the roothub port status bits until the device
      is really in U0.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAndiry Xu <andiry.xu@amd.com>
      d93814cf
  2. 14 2月, 2012 3 次提交
  3. 11 2月, 2012 7 次提交
  4. 10 2月, 2012 5 次提交
  5. 09 2月, 2012 18 次提交
    • L
      Linux 3.3-rc3 · d65b4e98
      Linus Torvalds 提交于
      d65b4e98
    • L
      Merge branch 'iommu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · 63082402
      Linus Torvalds 提交于
      One patch fixes an bug in the ARM/MSM IOMMU code which returned sucess
      in the unmap function even when an error occured and the other patch
      adds a workaround into the AMD IOMMU driver to better handle broken IVRS
      ACPI tables (this patch fixes the case when a device is not listed in
      the table but actually translated by the iommu).
      
      * 'iommu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu/msm: Fix error handling in msm_iommu_unmap()
        iommu/amd: Work around broken IVRS tables
      63082402
    • L
      Merge branch '3.3-rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending · 19e75ed4
      Linus Torvalds 提交于
      This series contains pending target bug-fixes and cleanups for v3.3-rc3
      that have been addressed the past weeks in lio-core.git.
      
      Some of the highlights include:
      
       - Fix handling for control CDBs with data greater than PAGE_SIZE (andy)
       - Use IP_FREEBIND for iscsi-target to address network portal creation
         issues with systemd (dax)
       - Allow PERSISTENT RESERVE IN for non-reservation holder (marco)
       - Fix iblock se_dev_attrib.unmap_granularity (marco)
       - Fix unsupported WRITE_SAME sense payload handling (martin)
       - Add workaround for zero-length control CDB handling (nab)
       - Fix discovery with INADDR_ANY and IN6ADDR_ANY_INIT (nab)
       - Fix target_submit_cmd() exception handling (nab)
       - Return correct ASC for unimplemented VPD pages (roland)
       - Don't zero pages used for data buffers (roland)
       - Fix return code of core_tpg_.*_lun (sebastian)
      
      * '3.3-rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: (26 commits)
        target: Fix unsupported WRITE_SAME sense payload
        iscsi: use IP_FREEBIND socket option
        iblock: fix handling of large requests
        target: handle empty string writes in sysfs
        iscsi_target: in_aton needs linux/inet.h
        target: Fix iblock se_dev_attrib.unmap_granularity
        target: Fix target_submit_cmd() exception handling
        target: Change target_submit_cmd() to return void
        target: accept REQUEST_SENSE with 18bytes
        target: Fail INQUIRY commands with EVPD==0 but PAGE CODE!=0
        target: Return correct ASC for unimplemented VPD pages
        iscsi-target: Fix discovery with INADDR_ANY and IN6ADDR_ANY_INIT
        target: Allow control CDBs with data > 1 page
        iscsi-target: Fix up a few assignments
        iscsi-target: make one-bit bitfields unsigned
        iscsi-target: Fix double list_add with iscsit_alloc_buffs reject
        iscsi-target: Fix reject release handling in iscsit_free_cmd()
        target: fix return code of core_tpg_.*_lun
        target: use save/restore lock primitive in core_dec_lacl_count()
        target: avoid multiple outputs in scsi_dump_inquiry()
        ...
      19e75ed4
    • L
      Merge tag 'md-3.3-fixes' of git://neil.brown.name/md · 4d39aa1b
      Linus Torvalds 提交于
      Some simple md-related fixes.
      
      1/ two small fixes to ensure we handle an interrupted resync properly.
      2/ avoid loading the bitmap multiple times in dm-raid
      
      * tag 'md-3.3-fixes' of git://neil.brown.name/md:
        md: two small fixes to handling interrupt resync.
        Prevent DM RAID from loading bitmap twice.
      4d39aa1b
    • L
      Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6 · 4a68d54c
      Linus Torvalds 提交于
      SPI bug fixes for v3.3-rc2
      
      Minor SPI device driver changes.  A rename of the pch_spi_pcidev symbol
      that merely eliminates a modpost warning, and a Kconfig change to allow
      the Samsung spi driver to build on EXYNOS.
      
      * tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6:
        spi-topcliff-pch: rename pch_spi_pcidev to pch_spi_pcidev_driver
        spi: Add spi-s3c64xx driver dependency on ARCH_EXYNOS4
      4a68d54c
    • L
      Merge branch 'akpm' (Andrew's tree) · 15a46353
      Linus Torvalds 提交于
      Five fixes
      
      * branch 'akpm':
        pcmcia: fix socket refcount decrementing on each resume
        mm: fix UP THP spin_is_locked BUGs
        drivers/leds/leds-lm3530.c: fix setting pltfm->als_vmax
        mm: compaction: check for overlapping nodes during isolation for migration
        nilfs2: avoid overflowing segment numbers in nilfs_ioctl_clean_segments()
      15a46353
    • R
      pcmcia: fix socket refcount decrementing on each resume · 025e4ab3
      Russell King 提交于
      This fixes a memory-corrupting bug: not only does it cause the warning,
      but as a result of dropping the refcount to zero, it causes the
      pcmcia_socket0 device structure to be freed while it still has
      references, causing slab caches corruption.  A fatal oops quickly
      follows this warning - often even just a 'dmesg' following the warning
      causes the kernel to oops.
      
      While testing suspend/resume on an ARM device with PCMCIA support, and a
      CF card inserted, I found that after five suspend and resumes, the
      kernel would complain, and shortly die after with slab corruption.
      
        WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()
      
      As the message doesn't give a clue about which kobject, and the built-in
      debugging in drivers/base/power/main.c happens too late, this was added
      right before each get_device():
      
        printk("%s: %p [%s] %u\n", __func__, dev, kobject_name(&dev->kobj), atomic_read(&dev->kobj.kref.refcount));
      
      and on the 3rd s2ram cycle, the following behaviour observed:
      
      On the 3rd suspend/resume cycle:
      
        dpm_prepare: c1a0d998 [pcmcia_socket0] 3
        dpm_suspend: c1a0d998 [pcmcia_socket0] 3
        dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 3
        dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 3
        dpm_resume: c1a0d998 [pcmcia_socket0] 3
        dpm_complete: c1a0d998 [pcmcia_socket0] 2
      
      4th:
      
        dpm_prepare: c1a0d998 [pcmcia_socket0] 2
        dpm_suspend: c1a0d998 [pcmcia_socket0] 2
        dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 2
        dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 2
        dpm_resume: c1a0d998 [pcmcia_socket0] 2
        dpm_complete: c1a0d998 [pcmcia_socket0] 1
      
      5th:
      
        dpm_prepare: c1a0d998 [pcmcia_socket0] 1
        dpm_suspend: c1a0d998 [pcmcia_socket0] 1
        dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 1
        dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 1
        dpm_resume: c1a0d998 [pcmcia_socket0] 1
        dpm_complete: c1a0d998 [pcmcia_socket0] 0
        ------------[ cut here ]------------
        WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()
        Modules linked in: ucb1x00_core
        Backtrace:
        [<c0212090>] (dump_backtrace+0x0/0x110) from [<c04799dc>] (dump_stack+0x18/0x1c)
        [<c04799c4>] (dump_stack+0x0/0x1c) from [<c021cba0>] (warn_slowpath_common+0x50/0x68)
        [<c021cb50>] (warn_slowpath_common+0x0/0x68) from [<c021cbdc>] (warn_slowpath_null+0x24/0x28)
        [<c021cbb8>] (warn_slowpath_null+0x0/0x28) from [<c0335374>] (kobject_get+0x28/0x50)
        [<c033534c>] (kobject_get+0x0/0x50) from [<c03804f4>] (get_device+0x1c/0x24)
        [<c0388c90>] (dpm_complete+0x0/0x1a0) from [<c0389cc0>] (dpm_resume_end+0x1c/0x20)
        ...
      
      Looking at commit 7b24e798 ("pcmcia: split up central event handler"),
      the following change was made to cs.c:
      
                      return 0;
              }
       #endif
      -
      -       send_event(skt, CS_EVENT_PM_RESUME, CS_EVENT_PRI_LOW);
      +       if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
      +               skt->callback->early_resume(skt);
              return 0;
       }
      
      And the corresponding change in ds.c is from:
      
      -static int ds_event(struct pcmcia_socket *skt, event_t event, int priority)
      -{
      -       struct pcmcia_socket *s = pcmcia_get_socket(skt);
      ...
      -       switch (event) {
      ...
      -       case CS_EVENT_PM_RESUME:
      -               if (verify_cis_cache(skt) != 0) {
      -                       dev_dbg(&skt->dev, "cis mismatch - different card\n");
      -                       /* first, remove the card */
      -                       ds_event(skt, CS_EVENT_CARD_REMOVAL, CS_EVENT_PRI_HIGH);
      -                       mutex_lock(&s->ops_mutex);
      -                       destroy_cis_cache(skt);
      -                       kfree(skt->fake_cis);
      -                       skt->fake_cis = NULL;
      -                       s->functions = 0;
      -                       mutex_unlock(&s->ops_mutex);
      -                       /* now, add the new card */
      -                       ds_event(skt, CS_EVENT_CARD_INSERTION,
      -                                CS_EVENT_PRI_LOW);
      -               }
      -               break;
      ...
      -    }
      
      -    pcmcia_put_socket(s);
      
      -    return 0;
      -} /* ds_event */
      
      to:
      
      +static int pcmcia_bus_early_resume(struct pcmcia_socket *skt)
      +{
      +       if (!verify_cis_cache(skt)) {
      +               pcmcia_put_socket(skt);
      +               return 0;
      +       }
      
      +       dev_dbg(&skt->dev, "cis mismatch - different card\n");
      
      +       /* first, remove the card */
      +       pcmcia_bus_remove(skt);
      +       mutex_lock(&skt->ops_mutex);
      +       destroy_cis_cache(skt);
      +       kfree(skt->fake_cis);
      +       skt->fake_cis = NULL;
      +       skt->functions = 0;
      +       mutex_unlock(&skt->ops_mutex);
      
      +       /* now, add the new card */
      +       pcmcia_bus_add(skt);
      +       return 0;
      +}
      
      As can be seen, the original function called pcmcia_get_socket() and
      pcmcia_put_socket() around the guts, whereas the replacement code
      calls pcmcia_put_socket() only in one path.  This creates an imbalance
      in the refcounting.
      
      Testing with pcmcia_put_socket() put removed shows that the bug is gone:
      
        dpm_suspend: c1a10998 [pcmcia_socket0] 5
        dpm_suspend_noirq: c1a10998 [pcmcia_socket0] 5
        dpm_resume_noirq: c1a10998 [pcmcia_socket0] 5
        dpm_resume: c1a10998 [pcmcia_socket0] 5
        dpm_complete: c1a10998 [pcmcia_socket0] 5
      Tested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      025e4ab3
    • H
      mm: fix UP THP spin_is_locked BUGs · b9980cdc
      Hugh Dickins 提交于
      Fix CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_SMP=n CONFIG_DEBUG_VM=y
      CONFIG_DEBUG_SPINLOCK=n kernel: spin_is_locked() is then always false,
      and so triggers some BUGs in Transparent HugePage codepaths.
      
      asm-generic/bug.h mentions this problem, and provides a WARN_ON_SMP(x);
      but being too lazy to add VM_BUG_ON_SMP, BUG_ON_SMP, WARN_ON_SMP_ONCE,
      VM_WARN_ON_SMP_ONCE, just test NR_CPUS != 1 in the existing VM_BUG_ONs.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b9980cdc
    • A
      drivers/leds/leds-lm3530.c: fix setting pltfm->als_vmax · ec44fd42
      Axel Lin 提交于
      In current code, pltfm->als_vmin is set to LM3530_ALS_WINDOW_mV and
      pltfm->als_vmax is 0.  This does not make sense.  I think what we want
      here is setting pltfm->als_vmax to LM3530_ALS_WINDOW_mV.
      
      Both als_vmin and als_vmax local variables will be set to
      pltfm->als_vmin and pltfm->als_vmax by a few lines latter.  Thus also
      remove a redundant assignment for als_vmin and als_vmax in this patch.
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
      Acked-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Tested-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ec44fd42
    • M
      mm: compaction: check for overlapping nodes during isolation for migration · dc908600
      Mel Gorman 提交于
      When isolating pages for migration, migration starts at the start of a
      zone while the free scanner starts at the end of the zone.  Migration
      avoids entering a new zone by never going beyond the free scanned.
      
      Unfortunately, in very rare cases nodes can overlap.  When this happens,
      migration isolates pages without the LRU lock held, corrupting lists
      which will trigger errors in reclaim or during page free such as in the
      following oops
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        IP: [<ffffffff810f795c>] free_pcppages_bulk+0xcc/0x450
        PGD 1dda554067 PUD 1e1cb58067 PMD 0
        Oops: 0000 [#1] SMP
        CPU 37
        Pid: 17088, comm: memcg_process_s Tainted: G            X
        RIP: free_pcppages_bulk+0xcc/0x450
        Process memcg_process_s (pid: 17088, threadinfo ffff881c2926e000, task ffff881c2926c0c0)
        Call Trace:
          free_hot_cold_page+0x17e/0x1f0
          __pagevec_free+0x90/0xb0
          release_pages+0x22a/0x260
          pagevec_lru_move_fn+0xf3/0x110
          putback_lru_page+0x66/0xe0
          unmap_and_move+0x156/0x180
          migrate_pages+0x9e/0x1b0
          compact_zone+0x1f3/0x2f0
          compact_zone_order+0xa2/0xe0
          try_to_compact_pages+0xdf/0x110
          __alloc_pages_direct_compact+0xee/0x1c0
          __alloc_pages_slowpath+0x370/0x830
          __alloc_pages_nodemask+0x1b1/0x1c0
          alloc_pages_vma+0x9b/0x160
          do_huge_pmd_anonymous_page+0x160/0x270
          do_page_fault+0x207/0x4c0
          page_fault+0x25/0x30
      
      The "X" in the taint flag means that external modules were loaded but but
      is unrelated to the bug triggering.  The real problem was because the PFN
      layout looks like this
      
        Zone PFN ranges:
          DMA      0x00000010 -> 0x00001000
          DMA32    0x00001000 -> 0x00100000
          Normal   0x00100000 -> 0x01e80000
        Movable zone start PFN for each node
        early_node_map[14] active PFN ranges
            0: 0x00000010 -> 0x0000009b
            0: 0x00000100 -> 0x0007a1ec
            0: 0x0007a354 -> 0x0007a379
            0: 0x0007f7ff -> 0x0007f800
            0: 0x00100000 -> 0x00680000
            1: 0x00680000 -> 0x00e80000
            0: 0x00e80000 -> 0x01080000
            1: 0x01080000 -> 0x01280000
            0: 0x01280000 -> 0x01480000
            1: 0x01480000 -> 0x01680000
            0: 0x01680000 -> 0x01880000
            1: 0x01880000 -> 0x01a80000
            0: 0x01a80000 -> 0x01c80000
            1: 0x01c80000 -> 0x01e80000
      
      The fix is straight-forward.  isolate_migratepages() has to make a
      similar check to isolate_freepage to ensure that it never isolates pages
      from a zone it does not hold the LRU lock for.
      
      This was discovered in a 3.0-based kernel but it affects 3.1.x, 3.2.x
      and current mainline.
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc908600
    • X
      nilfs2: avoid overflowing segment numbers in nilfs_ioctl_clean_segments() · 1ecd3c7e
      Xi Wang 提交于
      nsegs is read from userspace.  Limit its value and avoid overflowing nsegs
      * sizeof(__u64) in the subsequent call to memdup_user().
      
      This patch complements 481fe17e ("nilfs2: potential integer overflow
      in nilfs_ioctl_clean_segments()").
      Signed-off-by: NXi Wang <xi.wang@gmail.com>
      Cc: Haogang Chen <haogangchen@gmail.com>
      Acked-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1ecd3c7e
    • A
      usb-storage: reorganize target-specific code · af74d2da
      Alan Stern 提交于
      Now that usb-storage has a target_alloc() routine, this patch (as1508)
      moves some existing target-specific code out of the slave_alloc()
      routine to where it really belongs.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af74d2da
    • A
      SCSI & usb-storage: add flags for VPD pages and REPORT LUNS · 09b6b51b
      Alan Stern 提交于
      This patch (as1507) adds a skip_vpd_pages flag to struct scsi_device
      and a no_report_luns flag to struct scsi_target.  The first is used to
      control whether sd will look at VPD pages for information on block
      provisioning, limits, and characteristics.  The second prevents
      scsi_report_lun_scan() from issuing a REPORT LUNS command.
      
      The patch also modifies usb-storage to set the new flag bits for all
      USB devices and targets, and to stop adjusting the scsi_level value.
      
      Historically we have seen that USB mass-storage devices often don't
      support VPD pages or REPORT LUNS properly.  Until now we have avoided
      these things by setting the scsi_level to SCSI_2 for all USB devices.
      But this has the side effect of storing the LUN bits into the second
      byte of each CDB, and now we have a report of a device which doesn't
      like that.  The best solution is to stop abusing scsi_level and
      instead have separate flags for VPD pages and REPORT LUNS.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NPerry Wagle <wagle@mac.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09b6b51b
    • A
      SCSI: fix typo in definition of struct scsi_target · de8c46bf
      Alan Stern 提交于
      This patch (as1506) corrects a typo in the definition of the
      scsi_target structure.  pdt_1f_for_no_lun is supposed to be a
      single-bit flag, not a full-sized integer.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de8c46bf
    • L
      Merge tag 'sound-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · e862f2e4
      Linus Torvalds 提交于
      sound fixes #2 for 3.3-rc3
      
      A collection of small fixes, mostly for regressions.
      In addition, a few ASoC wm8994 updates are included, too.
      
      * tag 'sound-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ASoC: wm8994: Disable line output discharge prior to ramping VMID
        ASoC: wm8994: Fix typo in VMID ramp setting
        ALSA: oxygen, virtuoso: fix exchanged L/R volumes of aux and CD inputs
        ALSA: usb-audio: add Edirol UM-3G support
        ALSA: hda - add support for Uniwill ECS M31EI notebook
        ALSA: hda - Fix error handling in patch_ca0132.c
        ASoC: wm8994: Enabling VMID should take a runtime PM reference
        ALSA: hda/realtek - Fix a wrong condition
        ALSA: emu8000: Remove duplicate linux/moduleparam.h include from emu8000_patch.c
        ALSA: hda/realtek - Add missing Bass and CLFE as vmaster slaves
        ASoC: wm_hubs: Correct line input to line output 2 paths
        ASoC: cs42l73: Fix Output [X|A|V]SP_SCLK Sourcing Mode setting for master mode
        ASoC: wm8962: Fix word length configuration
        ASoC: core: Better support for idle_bias_off suspend ignores
        ASoC: wm8994: Remove ASoC level register cache sync
        ASoC: wm_hubs: Fix routing of input PGAs to line output mixer
      e862f2e4
    • T
      Merge tag 'asoc-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus · 982d411c
      Takashi Iwai 提交于
      A few small WM8994 updates to go on top of the previous lot of things
      that were sent.  They collide with some -next work so I'd really like to
      get them into 3.3-rc3 if possible to merge back up into the -next code.
      All driver specific and unexciting in the grand scheme of things.
      982d411c
    • M
    • M
      ASoC: wm8994: Fix typo in VMID ramp setting · f647e152
      Mark Brown 提交于
      The VMID ramp rate is supposed to be 0x3, not 11b. Fix that.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: stable@vger.kernel.org
      f647e152
  6. 08 2月, 2012 1 次提交