1. 07 Mar, 2014 40 commits
    • Tejun Heo's avatar
      sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN · 599b45bd
      Tejun Heo authored
      commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.
      It's a bit odd to see a newer device showing mod15write; however, the
      reported behavior is highly consistent and other factors which could
      contribute seem to have been verified well enough.  Also, both
      sata_sil itself and the drive are fairly outdated at this point making
      the risk of this change fairly low.  It is possible, probably likely,
      that other drive models in the same family have the same problem;
      however, for now, let's just add the specific model which was tested.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarmatson <lists-matsonpa@luxsci.me>
      References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Denis V. Lunev's avatar
      ata: enable quirk from jmicron JMB350 for JMB394 · 69f554c9
      Denis V. Lunev authored
      commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.
      Without the patch the kernel generates the following error.
       ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
       ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
       ata11.15: PMP revalidation failed (errno=-19)
       ata11.15: failed to recover PMP after 5 tries, giving up
      This patch helps to bypass this error and the device becomes
      Signed-off-by: default avatarDenis V. Lunev <den@openvz.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: <linux-ide@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Peter Zijlstra's avatar
      perf/x86: Fix event scheduling · f84d4534
      Peter Zijlstra authored
      commit 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 upstream.
      Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures,
      with perf WARN_ON()s triggering. He also provided traces of the failures.
      This is I think the relevant bit:
      	>    pec_1076_warn-2804  [000] d...   147.926153: x86_pmu_disable: x86_pmu_disable
      	>    pec_1076_warn-2804  [000] d...   147.926153: x86_pmu_state: Events: {
      	>    pec_1076_warn-2804  [000] d...   147.926156: x86_pmu_state:   0: state: .R config: ffffffffffffffff (          (null))
      	>    pec_1076_warn-2804  [000] d...   147.926158: x86_pmu_state:   33: state: AR config: 0 (ffff88011ac99800)
      	>    pec_1076_warn-2804  [000] d...   147.926159: x86_pmu_state: }
      	>    pec_1076_warn-2804  [000] d...   147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1
      	>    pec_1076_warn-2804  [000] d...   147.926161: x86_pmu_state: Assignment: {
      	>    pec_1076_warn-2804  [000] d...   147.926162: x86_pmu_state:   0->33 tag: 1 config: 0 (ffff88011ac99800)
      	>    pec_1076_warn-2804  [000] d...   147.926163: x86_pmu_state: }
      	>    pec_1076_warn-2804  [000] d...   147.926166: collect_events: Adding event: 1 (ffff880119ec8800)
      So we add the insn:p event (fd[23]).
      At this point we should have:
        n_events = 2, n_added = 1, n_txn = 1
      	>    pec_1076_warn-2804  [000] d...   147.926170: collect_events: Adding event: 0 (ffff8800c9e01800)
      	>    pec_1076_warn-2804  [000] d...   147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00)
      We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]).
      These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so
      that's not visible.
      	  pmu->start_txn() /* nop - BP pmu */
      So here we should end up with:
        0: n_events = 3, n_added = 2, n_txn = 2
        4: n_events = 4, n_added = 3, n_txn = 3
      But seeing the below state on x86_pmu_enable(), the must have failed,
      because the 0 and 4 events aren't there anymore.
      Looking at group_sched_in(), since the BP is the leader, its
      event_sched_in() must have succeeded, for otherwise we would not have
      seen the sibling adds.
      But since neither 0 or 4 are in the below state; their event_sched_in()
      must have failed; but I don't see why, the complete state: 0,0,1:p,4
      fits perfectly fine on a core2.
      However, since we try and schedule 4 it means the 0 event must have
      succeeded!  Therefore the 4 event must have failed, its failure will
      have put group_sched_in() into the fail path, which will call:
      on 0 and the BP event.
      Now x86_pmu_del() will reduce n_events; but it will not reduce n_added;
      giving what we see below:
       n_event = 2, n_added = 2, n_txn = 2
      	>    pec_1076_warn-2804  [000] d...   147.926177: x86_pmu_enable: x86_pmu_enable
      	>    pec_1076_warn-2804  [000] d...   147.926177: x86_pmu_state: Events: {
      	>    pec_1076_warn-2804  [000] d...   147.926179: x86_pmu_state:   0: state: .R config: ffffffffffffffff (          (null))
      	>    pec_1076_warn-2804  [000] d...   147.926181: x86_pmu_state:   33: state: AR config: 0 (ffff88011ac99800)
      	>    pec_1076_warn-2804  [000] d...   147.926182: x86_pmu_state: }
      	>    pec_1076_warn-2804  [000] d...   147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2
      	>    pec_1076_warn-2804  [000] d...   147.926184: x86_pmu_state: Assignment: {
      	>    pec_1076_warn-2804  [000] d...   147.926186: x86_pmu_state:   0->33 tag: 1 config: 0 (ffff88011ac99800)
      	>    pec_1076_warn-2804  [000] d...   147.926188: x86_pmu_state:   1->0 tag: 1 config: 1 (ffff880119ec8800)
      	>    pec_1076_warn-2804  [000] d...   147.926188: x86_pmu_state: }
      	>    pec_1076_warn-2804  [000] d...   147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0
      So the problem is that x86_pmu_del(), when called from a
      group_sched_in() that fails (for whatever reason), and without x86_pmu
      TXN support (because the leader is !x86_pmu), will corrupt the n_added
      Reported-and-Tested-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Dave Jones <davej@redhat.com>
      Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Marek Szyprowski's avatar
      x86: dma-mapping: fix GFP_ATOMIC macro usage · a9710605
      Marek Szyprowski authored
      commit c091c71ad2218fc50a07b3d1dab85783f3b77efd upstream.
      GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other
      flags, where meaningful is the LACK of __GFP_WAIT flag. To check if caller
      wants to perform an atomic allocation, the code must test for a lack of the
      __GFP_WAIT flag. This patch fixes the issue introduced in v3.5-rc1.
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Levente Kurusa's avatar
      ahci: disable NCQ on Samsung pci-e SSDs on macbooks · aa5b8c45
      Levente Kurusa authored
      commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream.
      Samsung's pci-e SSDs with device ID 0x1600 which are found on some
      macbooks time out on NCQ commands.  Blacklist NCQ on the device so
      that the affected machines can at least boot.
      Original-patch-by: default avatarLevente Kurusa <levex@linux.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Laurent Dufour's avatar
      powerpc/crashdump : Fix page frame number check in copy_oldmem_page · fb22dbab
      Laurent Dufour authored
      commit f5295bd8ea8a65dc5eac608b151386314cb978f1 upstream.
      In copy_oldmem_page, the current check using max_pfn and min_low_pfn to
      decide if the page is backed or not, is not valid when the memory layout is
      not continuous.
      This happens when running as a QEMU/KVM guest, where RTAS is mapped higher
      in the memory. In that case max_pfn points to the end of RTAS, and a hole
      between the end of the kdump kernel and RTAS is not backed by PTEs. As a
      consequence, the kdump kernel is crashing in copy_oldmem_page when accessing
      in a direct way the pages in that hole.
      This fix relies on the memblock's service memblock_is_region_memory to
      check if the read page is part or not of the directly accessible memory.
      Signed-off-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Tested-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Tony Breeds's avatar
      powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly · 64747d3d
      Tony Breeds authored
      commit 41dd03a94c7d408d2ef32530545097f7d1befe5c upstream.
      Currently we're storing a host endian RTAS token in
      rtas_stop_self_args.token.  We then pass that directly to rtas.  This is
      fine on big endian however on little endian the token is not what we
      This will typically result in hitting:
      	panic("Alas, I survived.\n");
      To fix this we always use the stop-self token in host order and always
      convert it to be32 before passing this to rtas.
      Signed-off-by: default avatarTony Breeds <tony@bakeyournoodle.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Trond Myklebust's avatar
      SUNRPC: Fix races in xs_nospace() · 830d5bd8
      Trond Myklebust authored
      commit 06ea0bfe6e6043cb56a78935a19f6f8ebc636226 upstream.
      When a send failure occurs due to the socket being out of buffer space,
      we call xs_nospace() in order to have the RPC task wait until the
      socket has drained enough to make it worth while trying again.
      The current patch fixes a race in which the socket is drained before
      we get round to setting up the machinery in xs_nospace(), and which
      is reported to cause hangs.
      Link: http://lkml.kernel.org/r/20140210170315.33dfc621@notabene.brown
      Fixes: a9a6b52e (SUNRPC: Don't start the retransmission timer...)
      Reported-by: default avatarNeil Brown <neilb@suse.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lars-Peter Clausen's avatar
      ASoC: wm8958-dsp: Fix firmware block loading · 6319b13b
      Lars-Peter Clausen authored
      commit 548da08fc1e245faf9b0d7c41ecd8e07984fc332 upstream.
      The codec->control_data contains a pointer to the device's regmap struct. But
      wm8994_bulk_write() expects a pointer to the parent wm8998 device.
      The issue was introduced in commit d9a7666f ("ASoC: Remove ASoC-specific
      WM8994 I/O code").
      Fixes: d9a7666f ("ASoC: Remove ASoC-specific WM8994 I/O code")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Iwai's avatar
      ASoC: sta32x: Fix array access overflow · 76a94d6a
      Takashi Iwai authored
      commit 025c3fa9256d4c54506b7a29dc3befac54f5c68d upstream.
      Preset EQ enum of sta32x codec driver declares too many number of
      items and it may lead to the access over the actual array size.
      Use SOC_ENUM_SINGLE_DECL() helper and it's automatically fixed.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Acked-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Iwai's avatar
      ASoC: sta32x: Fix wrong enum for limiter2 release rate · 27b5a374
      Takashi Iwai authored
      commit b3619b288b621e63f66908045f48495869a996a6 upstream.
      There is a typo in the Limiter2 Release Rate control, a wrong enum for
      Limiter1 is assigned.  It must point to Limiter2.
      Spotted by a compile warning:
      In file included from sound/soc/codecs/sta32x.c:34:0:
      sound/soc/codecs/sta32x.c:223:29: warning: ‘sta32x_limiter2_release_rate_enum’ defined but not used [-Wunused-variable]
       static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
      include/sound/soc.h:275:18: note: in definition of macro ‘SOC_ENUM_DOUBLE_DECL’
        struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
      sound/soc/codecs/sta32x.c:223:8: note: in expansion of macro ‘SOC_ENUM_SINGLE_DECL’
       static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lars-Peter Clausen's avatar
      ASoC: sta32x: Fix cache sync · df87c814
      Lars-Peter Clausen authored
      commit 70ff00f82a6af0ff68f8f7b411738634ce2f20d0 upstream.
      codec->control_data contains a pointer to the regmap struct of the device, not
      to the device private data. Use snd_soc_codec_get_drvdata() instead.
      The issue was introduced in commit 29fdf4fb ("ASoC: sta32x: Convert to
      Fixes: 29fdf4fb (ASoC: sta32x: Convert to regmap)
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mark Brown's avatar
      ASoC: da732x: Mark DC offset control registers volatile · 8efd0345
      Mark Brown authored
      commit 75306820248e26d15d84acf4e297b9fb27dd3bb2 upstream.
      The driver reads from the DC offset control registers during callibration
      but since the registers are marked as volatile and there is a register
      cache the values will not be read from the hardware after the first reading
      rendering the callibration ineffective.
      It appears that the driver was originally written for the ASoC level
      register I/O code but converted to regmap prior to merge and this issue
      was missed during the conversion as the framework level volatile register
      functionality was not being used.
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Acked-by: default avatarAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Takashi Iwai's avatar
      ASoC: wm8770: Fix wrong number of enum items · 1276754c
      Takashi Iwai authored
      commit 7a6c0a58dc824523966f212c76322d47c5b0e6fe upstream.
      wm8770 codec driver defines ain_enum with a wrong number of items.
      Use SOC_ENUM_DOUBLE_DECL() macro and it's automatically fixed.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Acked-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Acked-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dylan Reid's avatar
      ASoC: max98090: sync regcache on entering STANDBY · ecbda047
      Dylan Reid authored
      commit c42c8922c46d33ed769e99618bdfba06866a0c72 upstream.
      Sync regcache when entering STANDBY from OFF.  ON isn't entered with
      OFF as the current state, so the registers were not being re-synced
      after suspend/resume.
      The 98088 and 98095 already call regcache_sync from STANDBY.
      Signed-off-by: default avatarDylan Reid <dgreid@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andrew Honig's avatar
      kvm: x86: fix emulator buffer overflow (CVE-2014-0049) · 5a03bc08
      Andrew Honig authored
      commit a08d3b3b99efd509133946056531cdf8f3a0c09b upstream.
      The problem occurs when the guest performs a pusha with the stack
      address pointing to an mmio address (or an invalid guest physical
      address) to start with, but then extending into an ordinary guest
      physical address.  When doing repeated emulated pushes
      emulator_read_write sets mmio_needed to 1 on the first one.  On a
      later push when the stack points to regular memory,
      mmio_nr_fragments is set to 0, but mmio_is_needed is not set to 0.
      As a result, KVM exits to userspace, and then returns to
      complete_emulated_mmio.  In complete_emulated_mmio
      vcpu->mmio_cur_fragment is incremented.  The termination condition of
      vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments is never achieved.
      The code bounces back and fourth to userspace incrementing
      mmio_cur_fragment past it's buffer.  If the guest does nothing else it
      eventually leads to a a crash on a memcpy from invalid memory address.
      However if a guest code can cause the vm to be destroyed in another
      vcpu with excellent timing, then kvm_clear_async_pf_completion_queue
      can be used by the guest to control the data that's pointed to by the
      call to cancel_work_item, which can be used to gain execution.
      Fixes: f78146b0Signed-off-by: default avatarAndrew Honig <ahonig@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hui Wang's avatar
      ALSA: hda - Enable front audio jacks on one HP desktop model · 80c24504
      Hui Wang authored
      commit 1de7ca5e844866f56bebb2fc47fa18e090677e88 upstream.
      The front headphone and mic jackes on a HP desktop model (Vendor Id:
      0x111d76c7 Subsystem Id: 0x103c2b17) can not work, the codec on this
      machine has 8 physical ports, 6 of them are routed to rear jackes
      and all of them work very well, while the remaining 2 ports are
      routed to front headphone and mic jackes, but the corresponding
      pin complex node are not defined correctly.
      After apply this fix, the front audio jackes can work very well.
      [trivial fix of enum definition by tiwai]
      BugLink: https://bugs.launchpad.net/bugs/1282369
      Cc: David Henningsson <david.henningsson@canonical.com>
      Tested-by: default avatarGerald Yang <gerald.yang@canonical.com>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hsin-Yu Chao's avatar
      ALSA: hda/ca0132 - Fix recording from mode id 0x8 · 3d92e99d
      Hsin-Yu Chao authored
      commit 13c12dbe3a2ce17227f7ddef652b6a53c78fa51f upstream.
      Incorrect ADC is picked in ca0132_capture_pcm_prepare(),
      where it assumes multiple streams while there is one stream
      per ADC. Note that ca0132_capture_pcm_cleanup() already does
      the right thing.
      The Chromebook Pixel has a microphone under the keyboard that
      is attached to node id 0x8. Before this fix, recording would
      always go to the main internal mic (node id 0x7).
      Signed-off-by: default avatarHsin-Yu Chao <hychao@chromium.org>
      Reviewed-by: default avatarDylan Reid <dgreid@chromium.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hsin-Yu Chao's avatar
      ALSA: hda/ca0132 - setup/cleanup streams · 6e52b4fd
      Hsin-Yu Chao authored
      commit 28fba95087a7f3d107a3a6728aef7dbfaf3fd782 upstream.
      When a HDMI stream is opened with the same stream tag
      as a following opened stream to ca0132, audio will be
      heard from two ports simultaneously.
      Fix this issue by change to use snd_hda_codec_setup_stream
      and snd_hda_codec_cleanup_stream instead, so that an
      inactive stream can be marked as 'dirty' when found
      with a conflict stream tag, and then get purified.
      Signed-off-by: default avatarHsin-Yu Chao <hychao@chromium.org>
      Reviewed-by: default avatarChih-Chung Chang <chihchung@chromium.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Clemens Ladisch's avatar
      ALSA: usb-audio: work around KEF X300A firmware bug · 19ee64e6
      Clemens Ladisch authored
      commit 624aef494f86ed0c58056361c06347ad62b26806 upstream.
      When the driver tries to access Function Unit 10, the KEF X300A
      speakers' firmware apparently locks up, making even PCM streaming
      impossible.  Work around this by ignoring this FU.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Christoph Hellwig's avatar
      fs: fix iversion handling · d5685be1
      Christoph Hellwig authored
      commit dff6efc326a4d5f305797d4a6bba14f374fdd633 upstream.
      Currently notify_change directly updates i_version for size updates,
      which not only is counter to how all other fields are updated through
      struct iattr, but also breaks XFS, which need inode updates to happen
      under its own lock, and synchronized to the structure that gets written
      to the log.
      Remove the update in the common code, and it to btrfs and ext4,
      XFS already does a proper updaste internally and currently gets a
      double update with the existing code.
      IMHO this is 3.13 and -stable material and should go in through the XFS
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Michal Hocko's avatar
      memcg: fix endless loop caused by mem_cgroup_iter · 5fb67b91
      Michal Hocko authored
      commit ecc736fc3c71c411a9d201d8588c9e7e049e5d8c upstream.
      Hugh has reported an endless loop when the hardlimit reclaim sees the
      same group all the time.  This might happen when the reclaim races with
      the memcg removal.
                                                      [rmdir root]
        mem_cgroup_iter(root, NULL, reclaim)
          // prev = NULL
            last_visited = iter->last_visited   // gets root || NULL
            css_tryget(last_visited)            // failed
            last_visited = NULL                 [1]
          memcg = root = __mem_cgroup_iter_next(root, NULL)
            iter->last_visited = root;
          reclaim->generation = iter->generation
       mem_cgroup_iter(root, root, reclaim)
         // prev = root
            last_visited = iter->last_visited   // gets root
            css_tryget(last_visited)            // failed
      The issue seemed to be introduced by commit 5f578161 ("memcg: relax
      memcg iter caching") which has replaced unconditional css_get/css_put by
      css_tryget/css_put for the cached iterator.
      This patch fixes the issue by skipping css_tryget on the root of the
      tree walk in mem_cgroup_iter_load and symmetrically doesn't release it
      in mem_cgroup_iter_update.
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Reported-by: default avatarHugh Dickins <hughd@google.com>
      Tested-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: <stable@vger.kernel.org>	[3.10+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Dumazet's avatar
      net: use __GFP_NORETRY for high order allocations · a9e3d789
      Eric Dumazet authored
      [ Upstream commit ed98df3361f059db42786c830ea96e2d18b8d4db ]
      sock_alloc_send_pskb() & sk_page_frag_refill()
      have a loop trying high order allocations to prepare
      skb with low number of fragments as this increases performance.
      Problem is that under memory pressure/fragmentation, this can
      trigger OOM while the intent was only to try the high order
      allocations, then fallback to order-0 allocations.
      We had various reports from unexpected regressions.
      According to David, setting __GFP_NORETRY should be fine,
      as the asynchronous compaction is still enabled, and this
      will prevent OOM from kicking as in :
      CFSClientEventm invoked oom-killer: gfp_mask=0x42d0, order=3, oom_adj=0,
      oom_score_adj=0, oom_score_badness=2 (enabled),memcg_scoring=disabled
      Call Trace:
       [<ffffffff8043766c>] dump_header+0xe1/0x23e
       [<ffffffff80437a02>] oom_kill_process+0x6a/0x323
       [<ffffffff80438443>] out_of_memory+0x4b3/0x50d
       [<ffffffff8043a4a6>] __alloc_pages_may_oom+0xa2/0xc7
       [<ffffffff80236f42>] __alloc_pages_nodemask+0x1002/0x17f0
       [<ffffffff8024bd23>] alloc_pages_current+0x103/0x2b0
       [<ffffffff8028567f>] sk_page_frag_refill+0x8f/0x160
       [<ffffffff80295fa0>] tcp_sendmsg+0x560/0xee0
       [<ffffffff802a5037>] inet_sendmsg+0x67/0x100
       [<ffffffff80283c9c>] __sock_sendmsg_nosec+0x6c/0x90
       [<ffffffff80283e85>] sock_sendmsg+0xc5/0xf0
       [<ffffffff802847b6>] __sys_sendmsg+0x136/0x430
       [<ffffffff80284ec8>] sys_sendmsg+0x88/0x110
       [<ffffffff80711472>] system_call_fastpath+0x16/0x1b
      Out of Memory: Kill process 2856 (bash) score 9999 or sacrifice child
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Florian Westphal's avatar
      net: ip, ipv6: handle gso skbs in forwarding path · d868190c
      Florian Westphal authored
      commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.
      Marcelo Ricardo Leitner reported problems when the forwarding link path
      has a lower mtu than the incoming one if the inbound interface supports GRO.
      Host <mtu1500> R1 <mtu1200> R2
      Host sends tcp stream which is routed via R1 and R2.  R1 performs GRO.
      In this case, the kernel will fail to send ICMP fragmentation needed
      messages (or pkt too big for ipv6), as GSO packets currently bypass dstmtu
      checks in forward path. Instead, Linux tries to send out packets exceeding
      the mtu.
      When locking route MTU on Host (i.e., no ipv4 DF bit set), R1 does
      not fragment the packets when forwarding, and again tries to send out
      packets exceeding R1-R2 link mtu.
      This alters the forwarding dstmtu checks to take the individual gso
      segment lengths into account.
      For ipv6, we send out pkt too big error for gso if the individual
      segments are too big.
      For ipv4, we either send icmp fragmentation needed, or, if the DF bit
      is not set, perform software segmentation and let the output path
      create fragments when the packet is leaving the machine.
      It is not 100% correct as the error message will contain the headers of
      the GRO skb instead of the original/segmented one, but it seems to
      work fine in my (limited) tests.
      Eric Dumazet suggested to simply shrink mss via ->gso_size to avoid
      sofware segmentation.
      However it turns out that skb_segment() assumes skb nr_frags is related
      to mss size so we would BUG there.  I don't want to mess with it considering
      Herbert and Eric disagree on what the correct behavior should be.
      Hannes Frederic Sowa notes that when we would shrink gso_size
      skb_segment would then also need to deal with the case where
      SKB_MAX_FRAGS would be exceeded.
      This uses sofware segmentation in the forward path when we hit ipv4
      non-DF packets and the outgoing link mtu is too small.  Its not perfect,
      but given the lack of bug reports wrt. GRO fwd being broken this is a
      rare case anyway.  Also its not like this could not be improved later
      once the dust settles.
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Reported-by: default avatarMarcelo Ricardo Leitner <mleitner@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Florian Westphal's avatar
      net: core: introduce netif_skb_dev_features · a999dd5c
      Florian Westphal authored
      commit d206940319c41df4299db75ed56142177bb2e5f6 upstream.
      Will be used by upcoming ipv4 forward path change that needs to
      determine feature mask using skb->dst->dev instead of skb->dev.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Florian Westphal's avatar
      net: add and use skb_gso_transport_seglen() · 3fb03b59
      Florian Westphal authored
      commit de960aa9ab4decc3304959f69533eef64d05d8e8 upstream.
      [ no skb_gso_seglen helper in 3.10, leave tbf alone ]
      This moves part of Eric Dumazets skb_gso_seglen helper from tbf sched to
      skbuff core so it may be reused by upcoming ip forwarding path patch.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Daniel Borkmann's avatar
      net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode · b306713b
      Daniel Borkmann authored
      [ Upstream commit ffd5939381c609056b33b7585fb05a77b4c695f3 ]
      SCTP's sctp_connectx() abi breaks for 64bit kernels compiled with 32bit
      emulation (e.g. ia32 emulation or x86_x32). Due to internal usage of
      'struct sctp_getaddrs_old' which includes a struct sockaddr pointer,
      sizeof(param) check will always fail in kernel as the structure in
      64bit kernel space is 4bytes larger than for user binaries compiled
      in 32bit mode. Thus, applications making use of sctp_connectx() won't
      be able to run under such circumstances.
      Introduce a compat interface in the kernel to deal with such
      situations by using a 'struct compat_sctp_getaddrs_old' structure
      where user data is copied into it, and then sucessively transformed
      into a 'struct sctp_getaddrs_old' structure with the help of
      compat_ptr(). That fixes sctp_connectx() abi without any changes
      needed in user space, and lets the SCTP test suite pass when compiled
      in 32bit and run on 64bit kernels.
      Fixes: f9c67811 ("sctp: Fix regression introduced by new sctp_connectx api")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Duan Jiong's avatar
      ipv4: fix counter in_slow_tot · e82a32af
      Duan Jiong authored
      [ Upstream commit a6254864c08109c66a194612585afc0439005286 ]
      since commit 89aef892("ipv4: Delete routing cache."), the counter
      in_slow_tot can't work correctly.
      The counter in_slow_tot increase by one when fib_lookup() return successfully
      in ip_route_input_slow(), but actually the dst struct maybe not be created and
      cached, so we can increase in_slow_tot after the dst struct is created.
      Signed-off-by: default avatarDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jiri Bohac's avatar
      bonding: 802.3ad: make aggregator_identifier bond-private · 4380aafd
      Jiri Bohac authored
      [ Upstream commit 163c8ff30dbe473abfbb24a7eac5536c87f3baa9 ]
      aggregator_identifier is used to assign unique aggregator identifiers
      to aggregators of a bond during device enslaving.
      aggregator_identifier is currently a global variable that is zeroed in
      This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:
      create bond0
      change bond0 mode to 802.3ad
      enslave eth0 to bond0 		//eth0 gets agg id 1
      enslave eth1 to bond0 		//eth1 gets agg id 2
      create bond1
      change bond1 mode to 802.3ad
      enslave eth2 to bond1		//aggregator_identifier is reset to 0
      				//eth2 gets agg id 1
      enslave eth3 to bond0 		//eth3 gets agg id 2
      Fix this by making aggregator_identifier private to the bond.
      Signed-off-by: default avatarJiri Bohac <jbohac@suse.cz>
      Acked-by: default avatarVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Emil Goode's avatar
      usbnet: remove generic hard_header_len check · 07ea875e
      Emil Goode authored
      [ Upstream commit eb85569fe2d06c2fbf4de7b66c263ca095b397aa ]
      This patch removes a generic hard_header_len check from the usbnet
      module that is causing dropped packages under certain circumstances
      for devices that send rx packets that cross urb boundaries.
      One example is the AX88772B which occasionally send rx packets that
      cross urb boundaries where the remaining partial packet is sent with
      no hardware header. When the buffer with a partial packet is of less
      number of octets than the value of hard_header_len the buffer is
      discarded by the usbnet module.
      With AX88772B this can be reproduced by using ping with a packet
      size between 1965-1976.
      The bug has been reported here:
      This patch introduces the following changes:
      - Removes the generic hard_header_len check in the rx_complete
        function in the usbnet module.
      - Introduces a ETH_HLEN check for skbs that are not cloned from
        within a rx_fixup callback.
      - For safety a hard_header_len check is added to each rx_fixup
        callback function that could be affected by this change.
        These extra checks could possibly be removed by someone
        who has the hardware to test.
      - Removes a call to dev_kfree_skb_any() and instead utilizes the
        dev->done list to queue skbs for cleanup.
      The changes place full responsibility on the rx_fixup callback
      functions that clone skbs to only pass valid skbs to the
      usbnet_skb_return function.
      Signed-off-by: default avatarEmil Goode <emilgoode@gmail.com>
      Reported-by: default avatarIgor Gnatenko <i.gnatenko.brain@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Emil Goode's avatar
      net: asix: add missing flag to struct driver_info · 89663e73
      Emil Goode authored
      [ Upstream commit d43ff4cd798911736fb39025ec8004284b1b0bc2 ]
      The struct driver_info ax88178_info is assigned the function
      asix_rx_fixup_common as it's rx_fixup callback. This means that
      FLAG_MULTI_PACKET must be set as this function is cloning the
      data and calling usbnet_skb_return. Not setting this flag leads
      to usbnet_skb_return beeing called a second time from within
      the rx_process function in the usbnet module.
      Signed-off-by: default avatarEmil Goode <emilgoode@gmail.com>
      Reported-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Nithin Sujir's avatar
      tg3: Fix deadlock in tg3_change_mtu() · 1c13ac55
      Nithin Sujir authored
      [ Upstream commit c6993dfd7db9b0c6b7ca7503a56fda9236a4710f ]
      Quoting David Vrabel -
      "5780 cards cannot have jumbo frames and TSO enabled together.  When
      jumbo frames are enabled by setting the MTU, the TSO feature must be
      cleared.  This is done indirectly by calling netdev_update_features()
      which will call tg3_fix_features() to actually clear the flags.
      netdev_update_features() will also trigger a new netlink message for the
      feature change event which will result in a call to tg3_get_stats64()
      which deadlocks on the tg3 lock."
      tg3_set_mtu() does not need to be under the tg3 lock since converting
      the flags to use set_bit(). Move it out to after tg3_netif_stop().
      Reported-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Tested-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • John Ogness's avatar
      tcp: tsq: fix nonagle handling · 94ee16ae
      John Ogness authored
      [ Upstream commit bf06200e732de613a1277984bf34d1a21c2de03d ]
      Commit 46d3ceab ("tcp: TCP Small Queues") introduced a possible
      regression for applications using TCP_NODELAY.
      If TCP session is throttled because of tsq, we should consult
      tp->nonagle when TX completion is done and allow us to send additional
      segment, especially if this segment is not a full MSS.
      Otherwise this segment is sent after an RTO.
      [edumazet] : Cooked the changelog, added another fix about testing
      sk_wmem_alloc twice because TX completion can happen right before
      setting TSQ_THROTTLED bit.
      This problem is particularly visible with recent auto corking,
      but might also be triggered with low tcp_limit_output_bytes
      values or NIC drivers delaying TX completion by hundred of usec,
      and very low rtt.
      Thomas Glanzmann for example reported an iscsi regression, caused
      by tcp auto corking making this bug quite visible.
      Fixes: 46d3ceab ("tcp: TCP Small Queues")
      Signed-off-by: default avatarJohn Ogness <john.ogness@linutronix.de>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarThomas Glanzmann <thomas@glanzmann.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Bjørn Mork's avatar
      net: qmi_wwan: add Netgear Aircard 340U · 7f1b4122
      Bjørn Mork authored
      [ Upstream commit fbd3a77d813f211060f86cc7a2f8416caf0e03b1 ]
      This device was mentioned in an OpenWRT forum.  Seems to have a "standard"
      Sierra Wireless ifnumber to function layout:
       0: qcdm
       2: nmea
       3: modem
       8: qmi
       9: storage
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sabrina Dubroca's avatar
      netpoll: fix netconsole IPv6 setup · 8ca99951
      Sabrina Dubroca authored
      [ Upstream commit 00fe11b3c67dc670fe6391d22f1fe64e7c99a8ec ]
      Currently, to make netconsole start over IPv6, the source address
      needs to be specified. Without a source address, netpoll_parse_options
      assumes we're setting up over IPv4 and the destination IPv6 address is
      Check if the IP version has been forced by a source address before
      checking for a version mismatch when parsing the destination address.
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Acked-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Maciej Żenczykowski's avatar
      net: fix 'ip rule' iif/oif device rename · 14bc205c
      Maciej Żenczykowski authored
      [ Upstream commit 946c032e5a53992ea45e062ecb08670ba39b99e3 ]
      ip rules with iif/oif references do not update:
      (detach/attach) across interface renames.
      Signed-off-by: default avatarMaciej Żenczykowski <maze@google.com>
      CC: Willem de Bruijn <willemb@google.com>
      CC: Eric Dumazet <edumazet@google.com>
      CC: Chris Davis <chrismd@google.com>
      CC: Carlo Contavalli <ccontavalli@google.com>
      Google-Bug-Id: 12936021
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Geert Uytterhoeven's avatar
      ipv4: Fix runtime WARNING in rtmsg_ifa() · cb58d094
      Geert Uytterhoeven authored
      [ Upstream commit 63b5f152eb4a5bb79b9caf7ec37b4201d12f6e66 ]
      On m68k/ARAnyM:
      WARNING: CPU: 0 PID: 407 at net/ipv4/devinet.c:1599 0x316a99()
      Modules linked in:
      CPU: 0 PID: 407 Comm: ifconfig Not tainted
      3.13.0-atari-09263-g0c71d68014d1 #1378
      Stack from 10c4fdf0:
              10c4fdf0 002ffabb 000243e8 00000000 008ced6c 00024416 00316a99 0000063f
              00316a99 00000009 00000000 002501b4 00316a99 0000063f c0a86117 00000080
              c0a86117 00ad0c90 00250a5a 00000014 00ad0c90 00000000 00000000 00000001
              00b02dd0 00356594 00000000 00356594 c0a86117 eff6c9e4 008ced6c 00000002
              008ced60 0024f9b4 00250b52 00ad0c90 00000000 00000000 00252390 00ad0c90
              eff6c9e4 0000004f 00000000 00000000 eff6c9e4 8000e25c eff6c9e4 80001020
      Call Trace: [<000243e8>] warn_slowpath_common+0x52/0x6c
       [<00024416>] warn_slowpath_null+0x14/0x1a
       [<002501b4>] rtmsg_ifa+0xdc/0xf0
       [<00250a5a>] __inet_insert_ifa+0xd6/0x1c2
       [<0024f9b4>] inet_abc_len+0x0/0x42
       [<00250b52>] inet_insert_ifa+0xc/0x12
       [<00252390>] devinet_ioctl+0x2ae/0x5d6
      Adding some debugging code reveals that net_fill_ifaddr() fails in
          put_cacheinfo(skb, ifa->ifa_cstamp, ifa->ifa_tstamp,
                                    preferred, valid))
      nla_put complains:
          lib/nlattr.c:454: skb_tailroom(skb) = 12, nla_total_size(attrlen) = 20
      Apparently commit 5c766d64 ("ipv4:
      introduce address lifetime") forgot to take into account the addition of
      struct ifa_cacheinfo in inet_nlmsg_size(). Hence add it, like is already
      done for ipv6.
      Suggested-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Oliver Hartkopp's avatar
      can: add destructor for self generated skbs · 8e880418
      Oliver Hartkopp authored
      [ Upstream commit 0ae89beb283a0db5980d1d4781c7d7be2f2810d6 ]
      Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
      no explicit destructor which is enforced since Linux 3.11 with commit
      376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).
      This patch adds some helper functions to make sure that a destructor is
      properly defined when a sock reference is assigned to a CAN related skb.
      To create an unshared skb owned by the original sock a common helper function
      has been introduced to replace open coded functions to create CAN echo skbs.
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Tested-by: default avatarAndre Naujoks <nautsch2@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Richard Yao's avatar
      9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers · b9776f59
      Richard Yao authored
      [ Upstream commit b6f52ae2f0d32387bde2b89883e3b64d88b9bfe8 ]
      The 9p-virtio transport does zero copy on things larger than 1024 bytes
      in size. It accomplishes this by returning the physical addresses of
      pages to the virtio-pci device. At present, the translation is usually a
      bit shift.
      That approach produces an invalid page address when we read/write to
      vmalloc buffers, such as those used for Linux kernel modules. Any
      attempt to load a Linux kernel module from 9p-virtio produces the
      following stack.
      [<ffffffff814878ce>] p9_virtio_zc_request+0x45e/0x510
      [<ffffffff814814ed>] p9_client_zc_rpc.constprop.16+0xfd/0x4f0
      [<ffffffff814839dd>] p9_client_read+0x15d/0x240
      [<ffffffff811c8440>] v9fs_fid_readn+0x50/0xa0
      [<ffffffff811c84a0>] v9fs_file_readn+0x10/0x20
      [<ffffffff811c84e7>] v9fs_file_read+0x37/0x70
      [<ffffffff8114e3fb>] vfs_read+0x9b/0x160
      [<ffffffff81153571>] kernel_read+0x41/0x60
      [<ffffffff810c83ab>] copy_module_from_fd.isra.34+0xfb/0x180
      Subsequently, QEMU will die printing:
      qemu-system-x86_64: virtio: trying to map MMIO memory
      This patch enables 9p-virtio to correctly handle this case. This not
      only enables us to load Linux kernel modules off virtfs, but also
      enables ZFS file-based vdevs on virtfs to be used without killing QEMU.
      Special thanks to both Avi Kivity and Alexander Graf for their
      interpretation of QEMU backtraces. Without their guidence, tracking down
      this bug would have taken much longer. Also, special thanks to Linus
      Torvalds for his insightful explanation of why this should use
      is_vmalloc_addr() instead of is_vmalloc_or_module_addr():
      https://lkml.org/lkml/2014/2/8/272Signed-off-by: default avatarRichard Yao <ryao@gentoo.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Dumazet's avatar
      6lowpan: fix lockdep splats · 66c63ac0
      Eric Dumazet authored
      [ Upstream commit 20e7c4e80dcd01dad5e6c8b32455228b8fe9c619 ]
      When a device ndo_start_xmit() calls again dev_queue_xmit(),
      lockdep can complain because dev_queue_xmit() is re-entered and the
      spinlocks protecting tx queues share a common lockdep class.
      Same issue was fixed for bonding/l2tp/ppp in commits
      0daa2303 ("[PATCH] bonding: lockdep annotation")
      49ee4920 ("bonding: set qdisc_tx_busylock to avoid LOCKDEP splat")
      23d3b8bf ("net: qdisc busylock needs lockdep annotations ")
      303c07db ("ppp: set qdisc_tx_busylock to avoid LOCKDEP splat ")
      Reported-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Tested-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>