1. 30 7月, 2014 10 次提交
    • L
      Revert "cdc_subset: deal with a device that needs reset for timeout" · 1d8fcba1
      Linus Torvalds 提交于
      This reverts commit 20fbe3ae.
      
      As reported by Stephen Rothwell, it causes compile failures in certain
      configurations:
      
        drivers/net/usb/cdc_subset.c:360:15: error: 'dummy_prereset' undeclared here (not in a function)
          .pre_reset = dummy_prereset,
                       ^
        drivers/net/usb/cdc_subset.c:361:16: error: 'dummy_postreset' undeclared here (not in a function)
          .post_reset = dummy_postreset,
                        ^
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: NDavid Miller <davem@davemloft.net>
      Cc: Oliver Neukum <oneukum@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d8fcba1
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · b527caee
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
       1) Make fragmentation IDs less predictable, from Eric Dumazet.
      
       2) TSO tunneling can crash in bnx2x driver, fix from Dmitry Kravkov.
      
       3) Don't allow NULL msg->msg_name just because msg->msg_namelen is
          non-zero, from Andrey Ryabinin.
      
       4) ndm->ndm_type set using wrong macros, from Jun Zhao.
      
       5) cdc-ether devices can come up with entries in their address filter,
          so explicitly clear the filter after the device initializes.  From
          Oliver Neukum.
      
       6) Forgotten refcount bump in xfrm_lookup(), from Steffen Klassert.
      
       7) Short packets not padded properly, exposing random data, in bcmgenet
          driver.  Fix from Florian Fainelli.
      
       8) xgbe_probe() doesn't return an error code, but rather zero, when
          netif_set_real_num_tx_queues() fails.  Fix from Wei Yongjun.
      
       9) USB speed not probed properly in r8152 driver, from Hayes Wang.
      
      10) Transmit logic choosing the outgoing port in the sunvnet driver
          needs to consider a) is the port actually up and b) whether it is a
          switch port.  Fix from David L Stevens.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits)
        net: phy: re-apply PHY fixups during phy_register_device
        cdc-ether: clean packet filter upon probe
        cdc_subset: deal with a device that needs reset for timeout
        net: sendmsg: fix NULL pointer dereference
        isdn/bas_gigaset: fix a leak on failure path in gigaset_probe()
        ip: make IP identifiers less predictable
        neighbour : fix ndm_type type error issue
        sunvnet: only use connected ports when sending
        can: c_can_platform: Fix raminit, use devm_ioremap() instead of devm_ioremap_resource()
        bnx2x: fix crash during TSO tunneling
        r8152: fix the checking of the usb speed
        net: phy: Ensure the MDIO bus module is held
        net: phy: Set the driver when registering an MDIO bus device
        bnx2x: fix set_setting for some PHYs
        hyperv: Fix error return code in netvsc_init_buf()
        amd-xgbe: Fix error return code in xgbe_probe()
        ath9k: fix aggregation session lockup
        net: bcmgenet: correctly pad short packets
        net: sctp: inherit auth_capable on INIT collisions
        mac80211: fix crash on getting sta info with uninitialized rate control
        ...
      b527caee
    • F
      net: phy: re-apply PHY fixups during phy_register_device · d92f5dec
      Florian Fainelli 提交于
      Commit 87aa9f9c ("net: phy: consolidate PHY reset in phy_init_hw()")
      moved the call to phy_scan_fixups() in phy_init_hw() after a software
      reset is performed.
      
      By the time phy_init_hw() is called in phy_device_register(), no driver
      has been bound to this PHY yet, so all the checks in phy_init_hw()
      against the PHY driver and the PHY driver's config_init function will
      return 0. We will therefore never call phy_scan_fixups() as we should.
      
      Fix this by calling phy_scan_fixups() and check for its return value to
      restore the intended functionality.
      
      This broke PHY drivers which do register an early PHY fixup callback to
      intercept the PHY probing and do things like changing the 32-bits unique
      PHY identifier when a pseudo-PHY address has been used, as well as
      board-specific PHY fixups that need to be applied during driver probe
      time.
      Reported-by: NHauke Merthens <hauke-m@hauke-m.de>
      Reported-by: NJonas Gorski <jogo@openwrt.org>
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d92f5dec
    • O
      cdc-ether: clean packet filter upon probe · c472ab68
      Oliver Neukum 提交于
      There are devices that don't do reset all the way. So the packet filter should
      be set to a sane initial value. Failure to do so leads to intermittent failures
      of DHCP on some systems under some conditions.
      Signed-off-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c472ab68
    • O
      cdc_subset: deal with a device that needs reset for timeout · 20fbe3ae
      Oliver Neukum 提交于
      This device needs to be reset to recover from a timeout.
      Unfortunately this can be handled only at the level of
      the subdrivers.
      Signed-off-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20fbe3ae
    • A
      net: sendmsg: fix NULL pointer dereference · 40eea803
      Andrey Ryabinin 提交于
      Sasha's report:
      	> While fuzzing with trinity inside a KVM tools guest running the latest -next
      	> kernel with the KASAN patchset, I've stumbled on the following spew:
      	>
      	> [ 4448.949424] ==================================================================
      	> [ 4448.951737] AddressSanitizer: user-memory-access on address 0
      	> [ 4448.952988] Read of size 2 by thread T19638:
      	> [ 4448.954510] CPU: 28 PID: 19638 Comm: trinity-c76 Not tainted 3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty #813
      	> [ 4448.956823]  ffff88046d86ca40 0000000000000000 ffff880082f37e78 ffff880082f37a40
      	> [ 4448.958233]  ffffffffb6e47068 ffff880082f37a68 ffff880082f37a58 ffffffffb242708d
      	> [ 4448.959552]  0000000000000000 ffff880082f37a88 ffffffffb24255b1 0000000000000000
      	> [ 4448.961266] Call Trace:
      	> [ 4448.963158] dump_stack (lib/dump_stack.c:52)
      	> [ 4448.964244] kasan_report_user_access (mm/kasan/report.c:184)
      	> [ 4448.965507] __asan_load2 (mm/kasan/kasan.c:352)
      	> [ 4448.966482] ? netlink_sendmsg (net/netlink/af_netlink.c:2339)
      	> [ 4448.967541] netlink_sendmsg (net/netlink/af_netlink.c:2339)
      	> [ 4448.968537] ? get_parent_ip (kernel/sched/core.c:2555)
      	> [ 4448.970103] sock_sendmsg (net/socket.c:654)
      	> [ 4448.971584] ? might_fault (mm/memory.c:3741)
      	> [ 4448.972526] ? might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3740)
      	> [ 4448.973596] ? verify_iovec (net/core/iovec.c:64)
      	> [ 4448.974522] ___sys_sendmsg (net/socket.c:2096)
      	> [ 4448.975797] ? put_lock_stats.isra.13 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
      	> [ 4448.977030] ? lock_release_holdtime (kernel/locking/lockdep.c:273)
      	> [ 4448.978197] ? lock_release_non_nested (kernel/locking/lockdep.c:3434 (discriminator 1))
      	> [ 4448.979346] ? check_chain_key (kernel/locking/lockdep.c:2188)
      	> [ 4448.980535] __sys_sendmmsg (net/socket.c:2181)
      	> [ 4448.981592] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600)
      	> [ 4448.982773] ? trace_hardirqs_on (kernel/locking/lockdep.c:2607)
      	> [ 4448.984458] ? syscall_trace_enter (arch/x86/kernel/ptrace.c:1500 (discriminator 2))
      	> [ 4448.985621] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600)
      	> [ 4448.986754] SyS_sendmmsg (net/socket.c:2201)
      	> [ 4448.987708] tracesys (arch/x86/kernel/entry_64.S:542)
      	> [ 4448.988929] ==================================================================
      
      This reports means that we've come to netlink_sendmsg() with msg->msg_name == NULL and msg->msg_namelen > 0.
      
      After this report there was no usual "Unable to handle kernel NULL pointer dereference"
      and this gave me a clue that address 0 is mapped and contains valid socket address structure in it.
      
      This bug was introduced in f3d33426
      (net: rework recvmsg handler msg_name and msg_namelen logic).
      Commit message states that:
      	"Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
      	 non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
      	 affect sendto as it would bail out earlier while trying to copy-in the
      	 address."
      But in fact this affects sendto when address 0 is mapped and contains
      socket address structure in it. In such case copy-in address will succeed,
      verify_iovec() function will successfully exit with msg->msg_namelen > 0
      and msg->msg_name == NULL.
      
      This patch fixes it by setting msg_namelen to 0 if msg_name == NULL.
      
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: <stable@vger.kernel.org>
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40eea803
    • A
      isdn/bas_gigaset: fix a leak on failure path in gigaset_probe() · 86b7987d
      Alexey Khoroshilov 提交于
      There is a lack of usb_put_dev(udev) on failure path in gigaset_probe().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
      Acked-by: NTilman Schmidt <tilman@imap.cc>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86b7987d
    • L
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · c98158ed
      Linus Torvalds 提交于
      Pull ARM SoC fixes from Arnd Bergmann:
       "A nice small set of bug fixes for arm-soc:
      
         - two incorrect register addresses in DT files on shmobile and hisilicon
         - one revert for a regression on omap
         - one bug fix for a newly introduced pin controller binding
         - one regression fix for the memory controller on omap
         - one patch to avoid a harmless WARN_ON"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: dts: Revert enabling of twl configuration for n900
        ARM: dts: fix L2 address in Hi3620
        ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable()
        pinctrl: dra: dt-bindings: Fix pull enable/disable
        ARM: shmobile: r8a7791: Fix SD2CKCR register address
        ARM: OMAP2+: l2c: squelch warning dump on power control setting
      c98158ed
    • D
      AFS: Correctly assemble the client UUID · 0ef13515
      David Howells 提交于
      Correctly assemble the client UUID by OR'ing in the flags rather than
      assigning them over the other components.
      Reported-by: NHimangi Saraogi <himangi774@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ef13515
    • R
      mm: fix page_alloc.c kernel-doc warnings · 1aab4d77
      Randy Dunlap 提交于
      Fix kernel-doc warnings and function name in mm/page_alloc.c:
      
        Warning(..//mm/page_alloc.c:6074): No description found for parameter 'pfn'
        Warning(..//mm/page_alloc.c:6074): No description found for parameter 'mask'
        Warning(..//mm/page_alloc.c:6074): Excess function parameter 'start_bitidx' description in 'get_pfnblock_flags_mask'
        Warning(..//mm/page_alloc.c:6102): No description found for parameter 'pfn'
        Warning(..//mm/page_alloc.c:6102): No description found for parameter 'mask'
        Warning(..//mm/page_alloc.c:6102): Excess function parameter 'start_bitidx' description in 'set_pfnblock_flags_mask'
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1aab4d77
  2. 29 7月, 2014 8 次提交
    • A
      Merge tag 'omap-for-v3.16/n900-regression' of... · a1ae5b12
      Arnd Bergmann 提交于
      Merge tag 'omap-for-v3.16/n900-regression' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
      
      Merge "omap n900 regression fix for v3.16 rc series" from Tony Lindgren:
      
      Minimal regression fix for n900 display that got broken with
      enabling of twl4030 PM features. Turns out more work is needed
      before we can enable twl4030 PM on n900.
      
      I did not notice this earlier as I have my n900 in a rack
      and the display did not get enabled for device tree based booting
      until for v3.16.
      
      * tag 'omap-for-v3.16/n900-regression' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
        ARM: dts: Revert enabling of twl configuration for n900
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      a1ae5b12
    • T
      ARM: dts: Revert enabling of twl configuration for n900 · d937678a
      Tony Lindgren 提交于
      Commit 9188883f (ARM: dts: Enable twl4030 off-idle configuration
      for selected omaps) allowed n900 to cut off core voltages during
      off-idle. This however caused a regression where twl regulator
      vaux1 was not getting enabled for the LCD panel as we are not
      requesting it for the panel.
      
      Turns out quite a few devices on n900 are using vaux1, and we need
      to either stop idling it, or add proper regulator_get calls for all
      users. But until we have a proper solution implemented and tested,
      let's just disable the twl off-idle configuration for now for n900.
      Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Fixes: 9188883f (ARM: dts: Enable twl4030 off-idle configuration for selected omaps)
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d937678a
    • E
      ip: make IP identifiers less predictable · 04ca6973
      Eric Dumazet 提交于
      In "Counting Packets Sent Between Arbitrary Internet Hosts", Jeffrey and
      Jedidiah describe ways exploiting linux IP identifier generation to
      infer whether two machines are exchanging packets.
      
      With commit 73f156a6 ("inetpeer: get rid of ip_id_count"), we
      changed IP id generation, but this does not really prevent this
      side-channel technique.
      
      This patch adds a random amount of perturbation so that IP identifiers
      for a given destination [1] are no longer monotonically increasing after
      an idle period.
      
      Note that prandom_u32_max(1) returns 0, so if generator is used at most
      once per jiffy, this patch inserts no hole in the ID suite and do not
      increase collision probability.
      
      This is jiffies based, so in the worst case (HZ=1000), the id can
      rollover after ~65 seconds of idle time, which should be fine.
      
      We also change the hash used in __ip_select_ident() to not only hash
      on daddr, but also saddr and protocol, so that ICMP probes can not be
      used to infer information for other protocols.
      
      For IPv6, adds saddr into the hash as well, but not nexthdr.
      
      If I ping the patched target, we can see ID are now hard to predict.
      
      21:57:11.008086 IP (...)
          A > target: ICMP echo request, seq 1, length 64
      21:57:11.010752 IP (... id 2081 ...)
          target > A: ICMP echo reply, seq 1, length 64
      
      21:57:12.013133 IP (...)
          A > target: ICMP echo request, seq 2, length 64
      21:57:12.015737 IP (... id 3039 ...)
          target > A: ICMP echo reply, seq 2, length 64
      
      21:57:13.016580 IP (...)
          A > target: ICMP echo request, seq 3, length 64
      21:57:13.019251 IP (... id 3437 ...)
          target > A: ICMP echo reply, seq 3, length 64
      
      [1] TCP sessions uses a per flow ID generator not changed by this patch.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NJeffrey Knockel <jeffk@cs.unm.edu>
      Reported-by: NJedidiah R. Crandall <crandall@cs.unm.edu>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Hannes Frederic Sowa <hannes@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      04ca6973
    • J
      neighbour : fix ndm_type type error issue · 545469f7
      Jun Zhao 提交于
      ndm_type means L3 address type, in neighbour proxy and vxlan, it's RTN_UNICAST.
      NDA_DST is for netlink TLV type, hence it's not right value in this context.
      Signed-off-by: NJun Zhao <mypopydev@gmail.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      545469f7
    • D
      sunvnet: only use connected ports when sending · 8266f5fc
      David L Stevens 提交于
      The sunvnet driver doesn't check whether or not a port is connected when
      transmitting packets, which results in failures if a port fails to connect
      (e.g., due to a version mismatch). The original code also assumes
      unnecessarily that the first port is up and a switch, even though there is
      a flag for switch ports.
      
      This patch only matches a port if it is connected, and otherwise uses the
      switch_port flag to send the packet to a switch port that is up.
      Signed-off-by: NDavid L Stevens <david.stevens@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8266f5fc
    • D
      Merge tag 'linux-can-fixes-for-3.16-20140725' of git://gitorious.org/linux-can/linux-can · 8356f976
      David S. Miller 提交于
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2014-07-25
      
      this is a pull request of one patch for the net tree, hoping to get into the
      3.16 release.
      
      The patch by George Cherian fixes a regression in the c_can platform driver.
      When using two interfaces the regression leads to a non function second
      interface.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8356f976
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 31dab719
      Linus Torvalds 提交于
      Pull ARM AES crypto fixes from Herbert Xu:
       "This push fixes a regression on ARM where odd-sized blocks supplied to
        AES may cause crashes"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: arm-aes - fix encryption of unaligned data
        crypto: arm64-aes - fix encryption of unaligned data
      31dab719
    • L
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · e8a91e0e
      Linus Torvalds 提交于
      Pull powerpc fixes from Ben Herrenschmidt:
       "Here are 3 more small powerpc fixes that should still go into .16.
      
        One is a recent regression (MMCR2 business), the other is a trivial
        endian fix without which FW updates won't work on LE in IBM machines,
        and the 3rd one turns a BUG_ON into a WARN_ON which is definitely a
        LOT more friendly especially when the whole thing is about retrieving
        error logs ..."
      
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
        powerpc: Fix endianness of flash_block_list in rtas_flash
        powerpc/powernv: Change BUG_ON to WARN_ON in elog code
        powerpc/perf: Fix MMCR2 handling for EBB
      e8a91e0e
  3. 28 7月, 2014 9 次提交
  4. 27 7月, 2014 2 次提交
    • L
      Fix gcc-4.9.0 miscompilation of load_balance() in scheduler · 2062afb4
      Linus Torvalds 提交于
      Michel Dänzer and a couple of other people reported inexplicable random
      oopses in the scheduler, and the cause turns out to be gcc mis-compiling
      the load_balance() function when debugging is enabled.  The gcc bug
      apparently goes back to gcc-4.5, but slight optimization changes means
      that it now showed up as a problem in 4.9.0 and 4.9.1.
      
      The instruction scheduling problem causes gcc to schedule a spill
      operation to before the stack frame has been created, which in turn can
      corrupt the spilled value if an interrupt comes in.  There may be other
      effects of this bug too, but that's the code generation problem seen in
      Michel's case.
      
      This is fixed in current gcc HEAD, but the workaround as suggested by
      Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
      when compiling the kernel, which disables the gcc code that causes the
      problem.  This can result in slightly worse debug information for
      variable accesses, but that is infinitely preferable to actual code
      generation problems.
      
      Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
      non-debug builds to verify that the debug build would be identical: we
      can do
      
          export GCC_COMPARE_DEBUG=1
      
      to make gcc internally verify that the result of the build is
      independent of the "-g" flag (it will make the compiler build everything
      twice, toggling the debug flag, and compare the results).
      
      Without the "-fno-var-tracking-assignments" option, the build would fail
      (even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
      compare failure.
      
      See also gcc bugzilla:
      
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801Reported-by: NMichel Dänzer <michel@daenzer.net>
      Suggested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2062afb4
    • H
      mm: fix direct reclaim writeback regression · 8bdd6380
      Hugh Dickins 提交于
      Shortly before 3.16-rc1, Dave Jones reported:
      
        WARNING: CPU: 3 PID: 19721 at fs/xfs/xfs_aops.c:971
                 xfs_vm_writepage+0x5ce/0x630 [xfs]()
        CPU: 3 PID: 19721 Comm: trinity-c61 Not tainted 3.15.0+ #3
        Call Trace:
          xfs_vm_writepage+0x5ce/0x630 [xfs]
          shrink_page_list+0x8f9/0xb90
          shrink_inactive_list+0x253/0x510
          shrink_lruvec+0x563/0x6c0
          shrink_zone+0x3b/0x100
          shrink_zones+0x1f1/0x3c0
          try_to_free_pages+0x164/0x380
          __alloc_pages_nodemask+0x822/0xc90
          alloc_pages_vma+0xaf/0x1c0
          handle_mm_fault+0xa31/0xc50
        etc.
      
       970   if (WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD)) ==
       971                   PF_MEMALLOC))
      
      I did not respond at the time, because a glance at the PageDirty block
      in shrink_page_list() quickly shows that this is impossible: we don't do
      writeback on file pages (other than tmpfs) from direct reclaim nowadays.
      Dave was hallucinating, but it would have been disrespectful to say so.
      
      However, my own /var/log/messages now shows similar complaints
      
        WARNING: CPU: 1 PID: 28814 at fs/ext4/inode.c:1881 ext4_writepage+0xa7/0x38b()
        WARNING: CPU: 0 PID: 27347 at fs/ext4/inode.c:1764 ext4_writepage+0xa7/0x38b()
      
      from stressing some mmotm trees during July.
      
      Could a dirty xfs or ext4 file page somehow get marked PageSwapBacked,
      so fail shrink_page_list()'s page_is_file_cache() test, and so proceed
      to mapping->a_ops->writepage()?
      
      Yes, 3.16-rc1's commit 68711a74 ("mm, migration: add destination
      page freeing callback") has provided such a way to compaction: if
      migrating a SwapBacked page fails, its newpage may be put back on the
      list for later use with PageSwapBacked still set, and nothing will clear
      it.
      
      Whether that can do anything worse than issue WARN_ON_ONCEs, and get
      some statistics wrong, is unclear: easier to fix than to think through
      the consequences.
      
      Fixing it here, before the put_new_page(), addresses the bug directly,
      but is probably the worst place to fix it.  Page migration is doing too
      many parts of the job on too many levels: fixing it in
      move_to_new_page() to complement its SetPageSwapBacked would be
      preferable, except why is it (and newpage->mapping and newpage->index)
      done there, rather than down in migrate_page_move_mapping(), once we are
      sure of success? Not a cleanup to get into right now, especially not
      with memcg cleanups coming in 3.17.
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bdd6380
  5. 26 7月, 2014 11 次提交