1. 18 Dec, 2015 40 commits
    • Jeff Layton's avatar
      nfs: if we have no valid attrs, then don't declare the attribute cache valid · 850c33c9
      Jeff Layton authored
      commit c812012f upstream.
      
      If we pass in an empty nfs_fattr struct to nfs_update_inode, it will
      (correctly) not update any of the attributes, but it then clears the
      NFS_INO_INVALID_ATTR flag, which indicates that the attributes are
      up to date. Don't clear the flag if the fattr struct has no valid
      attrs to apply.
      Reviewed-by: default avatarSteve French <steve.french@primarydata.com>
      Signed-off-by: default avatarJeff Layton <jeff.layton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      850c33c9
    • Alex Deucher's avatar
      drm/radeon: make some dpm errors debug only · 9e7c9471
      Alex Deucher authored
      commit 9c565e33 upstream.
      
      "Could not force DPM to low", etc. is usually harmless and
      just confuses users.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9e7c9471
    • Takashi Iwai's avatar
      ALSA: hda - Fix noise on Gigabyte Z170X mobo · 60c64a4a
      Takashi Iwai authored
      commit 0c25ad80 upstream.
      
      Gigabyte Z710X mobo with ALC1150 codec gets significant noises from
      the analog loopback routes even if their inputs are all muted.
      Simply kill the aamix for fixing it.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108301Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      60c64a4a
    • Alex Deucher's avatar
      drm/radeon: make rv770_set_sw_state failures non-fatal · bd18942f
      Alex Deucher authored
      commit 4e7697ed upstream.
      
      On some cards it takes a relatively long time for the change
      to take place.  Make a timeout non-fatal.
      
      bug:
      https://bugs.freedesktop.org/show_bug.cgi?id=76130Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bd18942f
    • Marc Zyngier's avatar
      arm64: KVM: Fix AArch32 to AArch64 register mapping · 580580d9
      Marc Zyngier authored
      commit c0f09634 upstream.
      
      When running a 32bit guest under a 64bit hypervisor, the ARMv8
      architecture defines a mapping of the 32bit registers in the 64bit
      space. This includes banked registers that are being demultiplexed
      over the 64bit ones.
      
      On exceptions caused by an operation involving a 32bit register, the
      HW exposes the register number in the ESR_EL2 register. It was so
      far understood that SW had to distinguish between AArch32 and AArch64
      accesses (based on the current AArch32 mode and register number).
      
      It turns out that I misinterpreted the ARM ARM, and the clue is in
      D1.20.1: "For some exceptions, the exception syndrome given in the
      ESR_ELx identifies one or more register numbers from the issued
      instruction that generated the exception. Where the exception is
      taken from an Exception level using AArch32 these register numbers
      give the AArch64 view of the register."
      
      Which means that the HW is already giving us the translated version,
      and that we shouldn't try to interpret it at all (for example, doing
      an MMIO operation from the IRQ mode using the LR register leads to
      very unexpected behaviours).
      
      The fix is thus not to perform a call to vcpu_reg32() at all from
      vcpu_reg(), and use whatever register number is supplied directly.
      The only case we need to find out about the mapping is when we
      actively generate a register access, which only occurs when injecting
      a fault in a guest.
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      580580d9
    • Hui Wang's avatar
      ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3 · 3f6427b8
      Hui Wang authored
      commit 8c69729b upstream.
      
      We have a machine Dell XPS 13 with the codec alc256, after resume back
      from S3, the headphone has noise when play sound.
      
      Through comparing with the coeff vaule before and after S3, we found
      restoring a coeff register will help remove noise.
      
      BugLink: https://bugs.launchpad.net/bugs/1519168
      Cc: Kailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3f6427b8
    • Benjamin Coddington's avatar
      nfs4: start callback_ident at idr 1 · 6e1402a2
      Benjamin Coddington authored
      commit c68a027c upstream.
      
      If clp->cl_cb_ident is zero, then nfs_cb_idr_remove_locked() skips removing
      it when the nfs_client is freed.  A decoding or server bug can then find
      and try to put that first nfs_client which would lead to a crash.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Fixes: d6870312 ("nfs4client: convert to idr_alloc()")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6e1402a2
    • Jan Kara's avatar
      vfs: Avoid softlockups with sendfile(2) · afee648d
      Jan Kara authored
      commit c2489e07 upstream.
      
      The following test program from Dmitry can cause softlockups or RCU
      stalls as it copies 1GB from tmpfs into eventfd and we don't have any
      scheduling point at that path in sendfile(2) implementation:
      
              int r1 = eventfd(0, 0);
              int r2 = memfd_create("", 0);
              unsigned long n = 1<<30;
              fallocate(r2, 0, 0, n);
              sendfile(r1, r2, 0, n);
      
      Add cond_resched() into __splice_from_pipe() to fix the problem.
      
      CC: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      afee648d
    • Jan Kara's avatar
      vfs: Make sendfile(2) killable even better · 387ecadf
      Jan Kara authored
      commit c725bfce upstream.
      
      Commit 296291cd (mm: make sendfile(2) killable) fixed an issue where
      sendfile(2) was doing a lot of tiny writes into a filesystem and thus
      was unkillable for a long time. However sendfile(2) can be (mis)used to
      issue lots of writes into arbitrary file descriptor such as evenfd or
      similar special file descriptors which never hit the standard filesystem
      write path and thus are still unkillable. E.g. the following example
      from Dmitry burns CPU for ~16s on my test system without possibility to
      be killed:
      
              int r1 = eventfd(0, 0);
              int r2 = memfd_create("", 0);
              unsigned long n = 1<<30;
              fallocate(r2, 0, 0, n);
              sendfile(r1, r2, 0, n);
      
      There are actually quite a few tests for pending signals in sendfile
      code however we data to write is always available none of them seems to
      trigger. So fix the problem by adding a test for pending signal into
      splice_from_pipe_next() also before the loop waiting for pipe buffers to
      be available. This should fix all the lockup issues with sendfile of the
      do-ton-of-tiny-writes nature.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      387ecadf
    • Al Viro's avatar
      fix sysvfs symlinks · 9d02cebd
      Al Viro authored
      commit 0ebf7f10 upstream.
      
      The thing got broken back in 2002 - sysvfs does *not* have inline
      symlinks; even short ones have bodies stored in the first block
      of file.  sysv_symlink() handles that correctly; unfortunately,
      attempting to look an existing symlink up will end up confusing
      them for inline symlinks, and interpret the block number containing
      the body as the body itself.
      
      Nobody has noticed until now, which says something about the level
      of testing sysvfs gets ;-/
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9d02cebd
    • Vineet Gupta's avatar
      ARC: dw2 unwind: Remove falllback linear search thru FDE entries · 57256089
      Vineet Gupta authored
      commit 2e22502c upstream.
      
      Fixes STAR 9000953410: "perf callgraph profiling causing RCU stalls"
      
      | perf record -g -c 15000 -e cycles /sbin/hackbench
      |
      | INFO: rcu_preempt self-detected stall on CPU
      | 1: (1 GPs behind) idle=609/140000000000002/0 softirq=2914/2915 fqs=603
      | Task dump for CPU 1:
      
      in-kernel dwarf unwinder has a fast binary lookup and a fallback linear
      search (which iterates thru each of ~11K entries) thus takes 2 orders of
      magnitude longer (~3 million cycles vs. 2000). Routines written in hand
      assembler lack dwarf info (as we don't support assembler CFI pseudo-ops
      yet) fail the unwinder binary lookup, hit linear search, failing
      nevertheless in the end.
      
      However the linear search is pointless as binary lookup tables are created
      from it in first place. It is impossible to have binary lookup fail while
      succeed the linear search. It is pure waste of cycles thus removed by
      this patch.
      
      This manifested as RCU stalls / NMI watchdog splat when running
      hackbench under perf with callgraph profiling. The triggering condition
      was perf counter overflowing in routine lacking dwarf info (like memset)
      leading to patheic 3 million cycle unwinder slow path and by the time it
      returned new interrupts were already pending (Timer, IPI) and taken
      rightaway. The original memset didn't make forward progress, system kept
      accruing more interrupts and more unwinder delayes in a vicious feedback
      loop, ultimately triggering the NMI diagnostic.
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      57256089
    • Michael Neuling's avatar
      powerpc/tm: Check for already reclaimed tasks · 2682034a
      Michael Neuling authored
      commit 7f821fc9 upstream.
      
      Currently we can hit a scenario where we'll tm_reclaim() twice.  This
      results in a TM bad thing exception because the second reclaim occurs
      when not in suspend mode.
      
      The scenario in which this can happen is the following.  We attempt to
      deliver a signal to userspace.  To do this we need obtain the stack
      pointer to write the signal context.  To get this stack pointer we
      must tm_reclaim() in case we need to use the checkpointed stack
      pointer (see get_tm_stackpointer()).  Normally we'd then return
      directly to userspace to deliver the signal without going through
      __switch_to().
      
      Unfortunatley, if at this point we get an error (such as a bad
      userspace stack pointer), we need to exit the process.  The exit will
      result in a __switch_to().  __switch_to() will attempt to save the
      process state which results in another tm_reclaim().  This
      tm_reclaim() now causes a TM Bad Thing exception as this state has
      already been saved and the processor is no longer in TM suspend mode.
      Whee!
      
      This patch checks the state of the MSR to ensure we are TM suspended
      before we attempt the tm_reclaim().  If we've already saved the state
      away, we should no longer be in TM suspend mode.  This has the
      additional advantage of checking for a potential TM Bad Thing
      exception.
      
      Found using syscall fuzzer.
      
      Fixes: fb09692e ("powerpc: Add reclaim and recheckpoint functions for context switching transactional memory processes")
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2682034a
    • Michael Neuling's avatar
      powerpc/tm: Block signal return setting invalid MSR state · 368d31a3
      Michael Neuling authored
      commit d2b9d2a5 upstream.
      
      Currently we allow both the MSR T and S bits to be set by userspace on
      a signal return.  Unfortunately this is a reserved configuration and
      will cause a TM Bad Thing exception if attempted (via rfid).
      
      This patch checks for this case in both the 32 and 64 bit signals
      code.  If both T and S are set, we mark the context as invalid.
      
      Found using a syscall fuzzer.
      
      Fixes: 2b0a576d ("powerpc: Add new transactional memory state to the signal context")
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      368d31a3
    • Takashi Iwai's avatar
      ALSA: hda - Apply HP headphone fixups more generically · 81763cad
      Takashi Iwai authored
      commit 196543d5 upstream.
      
      It turned out that many HP laptops suffer from the same problem as
      fixed in commit [c932b98c: ALSA: hda - Apply pin fixup for HP
      ProBook 6550b].  But, it's tiresome to list up all such PCI SSIDs, as
      there are really lots of HP machines.
      
      Instead, we do a bit more clever, try to check the supposedly dock and
      built-in headphone pins, and apply the fixup when both seem valid.
      This rule can be applied generically to all models using the same
      quirk, so we'll fix all in a shot.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107491Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      81763cad
    • Kees Cook's avatar
      mac: validate mac_partition is within sector · 8412886a
      Kees Cook authored
      commit 02e2a5bf upstream.
      
      If md->signature == MAC_DRIVER_MAGIC and md->block_size == 1023, a single
      512 byte sector would be read (secsize / 512). However the partition
      structure would be located past the end of the buffer (secsize % 512).
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8412886a
    • Takashi Iwai's avatar
      ALSA: hda - Add fixup for Acer Aspire One Cloudbook 14 · 70664601
      Takashi Iwai authored
      commit b9c2fa52 upstream.
      
      For making the speakers on Acer Aspire One Cloudbook 14 to work, we
      need the as same quirk as for another Chromebook.  This patch adds the
      corresponding fixup entry.
      Reported-by: default avatarPatrick <epictetus@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      70664601
    • James Hogan's avatar
      MIPS: KVM: Uninit VCPU in vcpu_create error path · b3a1f082
      James Hogan authored
      commit 585bb8f9 upstream.
      
      If either of the memory allocations in kvm_arch_vcpu_create() fail, the
      vcpu which has been allocated and kvm_vcpu_init'd doesn't get uninit'd
      in the error handling path. Add a call to kvm_vcpu_uninit() to fix this.
      
      Fixes: 669e846e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [ luis: backported to 3.16:
        - file rename: mips.c -> kvm_mips.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b3a1f082
    • James Hogan's avatar
      MIPS: KVM: Fix CACHE immediate offset sign extension · fe632007
      James Hogan authored
      commit c5c2a3b9 upstream.
      
      The immediate field of the CACHE instruction is signed, so ensure that
      it gets sign extended by casting it to an int16_t rather than just
      masking the low 16 bits.
      
      Fixes: e685c689 ("KVM/MIPS32: Privileged instruction/target branch emulation.")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [ luis: backported to 3.16:
        - file rename: emulate.c -> kvm_mips_emul.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fe632007
    • James Hogan's avatar
      MIPS: KVM: Fix ASID restoration logic · 9571c879
      James Hogan authored
      commit 002374f3 upstream.
      
      ASID restoration on guest resume should determine the guest execution
      mode based on the guest Status register rather than bit 30 of the guest
      PC.
      
      Fix the two places in locore.S that do this, loading the guest status
      from the cop0 area. Note, this assembly is specific to the trap &
      emulate implementation of KVM, so it doesn't need to check the
      supervisor bit as that mode is not implemented in the guest.
      
      Fixes: b680f70f ("KVM/MIPS32: Entry point for trampolining to...")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [ luis: backported to 3.16:
        - file rename: locore.S -> kvm_locore.S ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9571c879
    • Junichi Nomura's avatar
      dm: fix ioctl retry termination with signal · a6248845
      Junichi Nomura authored
      commit 5bbbfdf6 upstream.
      
      dm-mpath retries ioctl, when no path is readily available and the device
      is configured to queue I/O in such a case. If you want to stop the retry
      before multipathd decides to turn off queueing mode, you could send
      signal for the process to exit from the loop.
      
      However the check of fatal signal has not carried along when commit
      6c182cd8 ("dm mpath: fix ioctl deadlock when no paths") moved the
      loop from dm-mpath to dm core. As a result, we can't terminate such
      a process in the retry loop.
      
      Easy reproducer of the situation is:
      
        # dmsetup create mp --table '0 1024 multipath 0 0 0 0'
        # dmsetup message mp 0 'queue_if_no_path'
        # sg_inq /dev/mapper/mp
      
      then you should be able to terminate sg_inq by pressing Ctrl+C.
      
      Fixes: 6c182cd8 ("dm mpath: fix ioctl deadlock when no paths")
      Signed-off-by: default avatarJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Mikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a6248845
    • Mike Snitzer's avatar
      dm thin: restore requested 'error_if_no_space' setting on OODS to WRITE transition · 791620e8
      Mike Snitzer authored
      commit 172c2386 upstream.
      
      A thin-pool that is in out-of-data-space (OODS) mode may transition back
      to write mode -- without the admin adding more space to the thin-pool --
      if/when blocks are released (either by deleting thin devices or
      discarding provisioned blocks).
      
      But as part of the thin-pool's earlier transition to out-of-data-space
      mode the thin-pool may have set the 'error_if_no_space' flag to true if
      the no_space_timeout expires without more space having been made
      available.  That implementation detail, of changing the pool's
      error_if_no_space setting, needs to be reset back to the default that
      the user specified when the thin-pool's table was loaded.
      
      Otherwise we'll drop the user requested behaviour on the floor when this
      out-of-data-space to write mode transition occurs.
      Reported-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      Fixes: 2c43fd26 ("dm thin: fix missing out-of-data-space to write mode transition if blocks are released")
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      791620e8
    • Clemens Ladisch's avatar
      ALSA: usb-audio: work around CH345 input SysEx corruption · 8ff0d683
      Clemens Ladisch authored
      commit a91e627e upstream.
      
      One of the many faults of the QinHeng CH345 USB MIDI interface chip is
      that it does not handle received SysEx messages correctly -- every second
      event packet has a wrong code index number, which is the one from the last
      seen message, instead of 4.  For example, the two messages "FE F0 01 02 03
      04 05 06 07 08 09 0A 0B 0C 0D 0E F7" result in the following event
      packets:
      
      correct:       CH345:
      0F FE 00 00    0F FE 00 00
      04 F0 01 02    04 F0 01 02
      04 03 04 05    0F 03 04 05
      04 06 07 08    04 06 07 08
      04 09 0A 0B    0F 09 0A 0B
      04 0C 0D 0E    04 0C 0D 0E
      05 F7 00 00    05 F7 00 00
      
      A class-compliant driver must interpret an event packet with CIN 15 as
      having a single data byte, so the other two bytes would be ignored.  The
      message received by the host would then be missing two bytes out of six;
      in this example, "F0 01 02 03 06 07 08 09 0C 0D 0E F7".
      
      These corrupted SysEx event packages contain only data bytes, while the
      CH345 uses event packets with a correct CIN value only for messages with
      a status byte, so it is possible to distinguish between these two cases by
      checking for the presence of this status byte.
      
      (Other bugs in the CH345's input handling, such as the corruption resulting
      from running status, cannot be worked around.)
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8ff0d683
    • Clemens Ladisch's avatar
      ALSA: usb-audio: prevent CH345 multiport output SysEx corruption · 88a85146
      Clemens Ladisch authored
      commit 1ca8b201 upstream.
      
      The CH345 USB MIDI chip has two output ports.  However, they are
      multiplexed through one pin, and the number of ports cannot be reduced
      even for hardware that implements only one connector, so for those
      devices, data sent to either port ends up on the same hardware output.
      This becomes a problem when both ports are used at the same time, as
      longer MIDI commands (such as SysEx messages) are likely to be
      interrupted by messages from the other port, and thus to get lost.
      
      It would not be possible for the driver to detect how many ports the
      device actually has, except that in practice, _all_ devices built with
      the CH345 have only one port.  So we can just ignore the device's
      descriptors, and hardcode one output port.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      88a85146
    • Clemens Ladisch's avatar
    • Eric Sandeen's avatar
      xfs: allow inode allocations in post-growfs disk space · 168f9c1c
      Eric Sandeen authored
      commit 9de67c3b upstream.
      
      Today, if we perform an xfs_growfs which adds allocation groups,
      mp->m_maxagi is not properly updated when the growfs is complete.
      
      Therefore inodes will continue to be allocated only in the
      AGs which existed prior to the growfs, and the new space
      won't be utilized.
      
      This is because of this path in xfs_growfs_data_private():
      
      xfs_growfs_data_private
      	xfs_initialize_perag(mp, nagcount, &nagimax);
      		if (mp->m_flags & XFS_MOUNT_32BITINODES)
      			index = xfs_set_inode32(mp);
      		else
      			index = xfs_set_inode64(mp);
      
      		if (maxagi)
      			*maxagi = index;
      
      where xfs_set_inode* iterates over the (old) agcount in
      mp->m_sb.sb_agblocks, which has not yet been updated
      in the growfs path.  So "index" will be returned based on
      the old agcount, not the new one, and new AGs are not available
      for inode allocation.
      
      Fix this by explicitly passing the proper AG count (which
      xfs_initialize_perag() already has) down another level,
      so that xfs_set_inode* can make the proper decision about
      acceptable AGs for inode allocation in the potentially
      newly-added AGs.
      
      This has been broken since 3.7, when these two
      xfs_set_inode* functions were added in commit 2d2194f6.
      Prior to that, we looped over "agcount" not sb_agblocks
      in these calculations.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Acked-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      168f9c1c
    • Eric Dumazet's avatar
      ipv6: sctp: implement sctp_v6_destroy_sock() · dc182470
      Eric Dumazet authored
      commit 602dd62d upstream.
      
      Dmitry Vyukov reported a memory leak using IPV6 SCTP sockets.
      
      We need to call inet6_destroy_sock() to properly release
      inet6 specific fields.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dc182470
    • Konstantin Khlebnikov's avatar
      net/neighbour: fix crash at dumping device-agnostic proxy entries · 883fab64
      Konstantin Khlebnikov authored
      commit 6adc5fd6 upstream.
      
      Proxy entries could have null pointer to net-device.
      Signed-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Fixes: 84920c14 ("net: Allow ipv6 proxies and arp proxies be shown with iproute2")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      883fab64
    • Eric Dumazet's avatar
      ipv6: add complete rcu protection around np->opt · 93d2f250
      Eric Dumazet authored
      commit 45f6fad8 upstream.
      
      This patch addresses multiple problems :
      
      UDP/RAW sendmsg() need to get a stable struct ipv6_txoptions
      while socket is not locked : Other threads can change np->opt
      concurrently. Dmitry posted a syzkaller
      (http://github.com/google/syzkaller) program desmonstrating
      use-after-free.
      
      Starting with TCP/DCCP lockless listeners, tcp_v6_syn_recv_sock()
      and dccp_v6_request_recv_sock() also need to use RCU protection
      to dereference np->opt once (before calling ipv6_dup_options())
      
      This patch adds full RCU protection to np->opt
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      93d2f250
    • Michal Kubeček's avatar
      ipv6: distinguish frag queues by device for multicast and link-local packets · 6aba289f
      Michal Kubeček authored
      commit 264640fc upstream.
      
      If a fragmented multicast packet is received on an ethernet device which
      has an active macvlan on top of it, each fragment is duplicated and
      received both on the underlying device and the macvlan. If some
      fragments for macvlan are processed before the whole packet for the
      underlying device is reassembled, the "overlapping fragments" test in
      ip6_frag_queue() discards the whole fragment queue.
      
      To resolve this, add device ifindex to the search key and require it to
      match reassembling multicast packets and packets to link-local
      addresses.
      
      Note: similar patch has been already submitted by Yoshifuji Hideaki in
      
        http://patchwork.ozlabs.org/patch/220979/
      
      but got lost and forgotten for some reason.
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6aba289f
    • Aaro Koskinen's avatar
      broadcom: fix PHY_ID_BCM5481 entry in the id table · 85c09e71
      Aaro Koskinen authored
      commit 3c25a860 upstream.
      
      Commit fcb26ec5 ("broadcom: move all PHY_ID's to header")
      updated broadcom_tbl to use PHY_IDs, but incorrectly replaced 0x0143bca0
      with PHY_ID_BCM5482 (making a duplicate entry, and completely omitting
      the original). Fix that.
      
      Fixes: fcb26ec5 ("broadcom: move all PHY_ID's to header")
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      85c09e71
    • Nikolay Aleksandrov's avatar
      net: ip6mr: fix static mfc/dev leaks on table destruction · 658438d6
      Nikolay Aleksandrov authored
      commit 4c698046 upstream.
      
      Similar to ipv4, when destroying an mrt table the static mfc entries and
      the static devices are kept, which leads to devices that can never be
      destroyed (because of refcnt taken) and leaked memory. Make sure that
      everything is cleaned up on netns destruction.
      
      Fixes: 8229efda ("netns: ip6mr: enable namespace support in ipv6 multicast forwarding code")
      CC: Benjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      658438d6
    • Nikolay Aleksandrov's avatar
      net: ipmr: fix static mfc/dev leaks on table destruction · 85425a88
      Nikolay Aleksandrov authored
      commit 0e615e96 upstream.
      
      When destroying an mrt table the static mfc entries and the static
      devices are kept, which leads to devices that can never be destroyed
      (because of refcnt taken) and leaked memory, for example:
      unreferenced object 0xffff880034c144c0 (size 192):
        comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s)
        hex dump (first 32 bytes):
          98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....
          ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................
        backtrace:
          [<ffffffff815c1b9e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811ea6e0>] kmem_cache_alloc+0x190/0x300
          [<ffffffff815931cb>] ip_mroute_setsockopt+0x5cb/0x910
          [<ffffffff8153d575>] do_ip_setsockopt.isra.11+0x105/0xff0
          [<ffffffff8153e490>] ip_setsockopt+0x30/0xa0
          [<ffffffff81564e13>] raw_setsockopt+0x33/0x90
          [<ffffffff814d1e14>] sock_common_setsockopt+0x14/0x20
          [<ffffffff814d0b51>] SyS_setsockopt+0x71/0xc0
          [<ffffffff815cdbf6>] entry_SYSCALL_64_fastpath+0x16/0x7a
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      Make sure that everything is cleaned on netns destruction.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      85425a88
    • Daniel Borkmann's avatar
      net, scm: fix PaX detected msg_controllen overflow in scm_detach_fds · 2a441c03
      Daniel Borkmann authored
      commit 6900317f upstream.
      
      David and HacKurx reported a following/similar size overflow triggered
      in a grsecurity kernel, thanks to PaX's gcc size overflow plugin:
      
      (Already fixed in later grsecurity versions by Brad and PaX Team.)
      
      [ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314
                     cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;
      [ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ #7
      [ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]
      [ 1002.296153]  ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8
      [ 1002.296162]  ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8
      [ 1002.296169]  ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60
      [ 1002.296176] Call Trace:
      [ 1002.296190]  [<ffffffff818129ba>] dump_stack+0x45/0x57
      [ 1002.296200]  [<ffffffff8121f838>] report_size_overflow+0x38/0x60
      [ 1002.296209]  [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300
      [ 1002.296220]  [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930
      [ 1002.296228]  [<ffffffff81791c9f>] unix_stream_recvmsg+0x4f/0x60
      [ 1002.296236]  [<ffffffff8178dc00>] ? unix_set_peek_off+0x50/0x50
      [ 1002.296243]  [<ffffffff8168fac7>] sock_recvmsg+0x47/0x60
      [ 1002.296248]  [<ffffffff81691522>] ___sys_recvmsg+0xe2/0x1e0
      [ 1002.296257]  [<ffffffff81693496>] __sys_recvmsg+0x46/0x80
      [ 1002.296263]  [<ffffffff816934fc>] SyS_recvmsg+0x2c/0x40
      [ 1002.296271]  [<ffffffff8181a3ab>] entry_SYSCALL_64_fastpath+0x12/0x85
      
      Further investigation showed that this can happen when an *odd* number of
      fds are being passed over AF_UNIX sockets.
      
      In these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)),
      where i is the number of successfully passed fds, differ by 4 bytes due
      to the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary
      on 64 bit. The padding is used to align subsequent cmsg headers in the
      control buffer.
      
      When the control buffer passed in from the receiver side *lacks* these 4
      bytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will
      overflow in scm_detach_fds():
      
        int cmlen = CMSG_LEN(i * sizeof(int));  <--- cmlen w/o tail-padding
        err = put_user(SOL_SOCKET, &cm->cmsg_level);
        if (!err)
          err = put_user(SCM_RIGHTS, &cm->cmsg_type);
        if (!err)
          err = put_user(cmlen, &cm->cmsg_len);
        if (!err) {
          cmlen = CMSG_SPACE(i * sizeof(int));  <--- cmlen w/ 4 byte extra tail-padding
          msg->msg_control += cmlen;
          msg->msg_controllen -= cmlen;         <--- iff no tail-padding space here ...
        }                                            ... wrap-around
      
      F.e. it will wrap to a length of 18446744073709551612 bytes in case the
      receiver passed in msg->msg_controllen of 20 bytes, and the sender
      properly transferred 1 fd to the receiver, so that its CMSG_LEN results
      in 20 bytes and CMSG_SPACE in 24 bytes.
      
      In case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an
      issue in my tests as alignment seems always on 4 byte boundary. Same
      should be in case of native 32 bit, where we end up with 4 byte boundaries
      as well.
      
      In practice, passing msg->msg_controllen of 20 to recvmsg() while receiving
      a single fd would mean that on successful return, msg->msg_controllen is
      being set by the kernel to 24 bytes instead, thus more than the input
      buffer advertised. It could f.e. become an issue if such application later
      on zeroes or copies the control buffer based on the returned msg->msg_controllen
      elsewhere.
      
      Maximum number of fds we can send is a hard upper limit SCM_MAX_FD (253).
      
      Going over the code, it seems like msg->msg_controllen is not being read
      after scm_detach_fds() in scm_recv() anymore by the kernel, good!
      
      Relevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg())
      and unix_stream_recvmsg(). Both return back to their recvmsg() caller,
      and ___sys_recvmsg() places the updated length, that is, new msg_control -
      old msg_control pointer into msg->msg_controllen (hence the 24 bytes seen
      in the example).
      
      Long time ago, Wei Yongjun fixed something related in commit 1ac70e7a
      ("[NET]: Fix function put_cmsg() which may cause usr application memory
      overflow").
      
      RFC3542, section 20.2. says:
      
        The fields shown as "XX" are possible padding, between the cmsghdr
        structure and the data, and between the data and the next cmsghdr
        structure, if required by the implementation. While sending an
        application may or may not include padding at the end of last
        ancillary data in msg_controllen and implementations must accept both
        as valid. On receiving a portable application must provide space for
        padding at the end of the last ancillary data as implementations may
        copy out the padding at the end of the control message buffer and
        include it in the received msg_controllen. When recvmsg() is called
        if msg_controllen is too small for all the ancillary data items
        including any trailing padding after the last item an implementation
        may set MSG_CTRUNC.
      
      Since we didn't place MSG_CTRUNC for already quite a long time, just do
      the same as in 1ac70e7a to avoid an overflow.
      
      Btw, even man-page author got this wrong :/ See db939c9b26e9 ("cmsg.3: Fix
      error in SCM_RIGHTS code sample"). Some people must have copied this (?),
      thus it got triggered in the wild (reported several times during boot by
      David and HacKurx).
      
      No Fixes tag this time as pre 2002 (that is, pre history tree).
      Reported-by: default avatarDavid Sterba <dave@jikos.cz>
      Reported-by: default avatarHacKurx <hackurx@gmail.com>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: Emese Revfy <re.emese@gmail.com>
      Cc: Brad Spengler <spender@grsecurity.net>
      Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
      Cc: Eric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2a441c03
    • Eric Dumazet's avatar
      tcp: initialize tp->copied_seq in case of cross SYN connection · 9a81e0e1
      Eric Dumazet authored
      commit 142a2e7e upstream.
      
      Dmitry provided a syzkaller (http://github.com/google/syzkaller)
      generated program that triggers the WARNING at
      net/ipv4/tcp.c:1729 in tcp_recvmsg() :
      
      WARN_ON(tp->copied_seq != tp->rcv_nxt &&
              !(flags & (MSG_PEEK | MSG_TRUNC)));
      
      His program is specifically attempting a Cross SYN TCP exchange,
      that we support (for the pleasure of hackers ?), but it looks we
      lack proper tcp->copied_seq initialization.
      
      Thanks again Dmitry for your report and testings.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9a81e0e1
    • Eric Dumazet's avatar
      tcp: md5: fix lockdep annotation · d230c3a0
      Eric Dumazet authored
      commit 1b8e6a01 upstream.
      
      When a passive TCP is created, we eventually call tcp_md5_do_add()
      with sk pointing to the child. It is not owner by the user yet (we
      will add this socket into listener accept queue a bit later anyway)
      
      But we do own the spinlock, so amend the lockdep annotation to avoid
      following splat :
      
      [ 8451.090932] net/ipv4/tcp_ipv4.c:923 suspicious rcu_dereference_protected() usage!
      [ 8451.090932]
      [ 8451.090932] other info that might help us debug this:
      [ 8451.090932]
      [ 8451.090934]
      [ 8451.090934] rcu_scheduler_active = 1, debug_locks = 1
      [ 8451.090936] 3 locks held by socket_sockopt_/214795:
      [ 8451.090936]  #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff855c6ac1>] __netif_receive_skb_core+0x151/0xe90
      [ 8451.090947]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff85618143>] ip_local_deliver_finish+0x43/0x2b0
      [ 8451.090952]  #2:  (slock-AF_INET){+.-...}, at: [<ffffffff855acda5>] sk_clone_lock+0x1c5/0x500
      [ 8451.090958]
      [ 8451.090958] stack backtrace:
      [ 8451.090960] CPU: 7 PID: 214795 Comm: socket_sockopt_
      
      [ 8451.091215] Call Trace:
      [ 8451.091216]  <IRQ>  [<ffffffff856fb29c>] dump_stack+0x55/0x76
      [ 8451.091229]  [<ffffffff85123b5b>] lockdep_rcu_suspicious+0xeb/0x110
      [ 8451.091235]  [<ffffffff8564544f>] tcp_md5_do_add+0x1bf/0x1e0
      [ 8451.091239]  [<ffffffff85645751>] tcp_v4_syn_recv_sock+0x1f1/0x4c0
      [ 8451.091242]  [<ffffffff85642b27>] ? tcp_v4_md5_hash_skb+0x167/0x190
      [ 8451.091246]  [<ffffffff85647c78>] tcp_check_req+0x3c8/0x500
      [ 8451.091249]  [<ffffffff856451ae>] ? tcp_v4_inbound_md5_hash+0x11e/0x190
      [ 8451.091253]  [<ffffffff85647170>] tcp_v4_rcv+0x3c0/0x9f0
      [ 8451.091256]  [<ffffffff85618143>] ? ip_local_deliver_finish+0x43/0x2b0
      [ 8451.091260]  [<ffffffff856181b6>] ip_local_deliver_finish+0xb6/0x2b0
      [ 8451.091263]  [<ffffffff85618143>] ? ip_local_deliver_finish+0x43/0x2b0
      [ 8451.091267]  [<ffffffff85618d38>] ip_local_deliver+0x48/0x80
      [ 8451.091270]  [<ffffffff85618510>] ip_rcv_finish+0x160/0x700
      [ 8451.091273]  [<ffffffff8561900e>] ip_rcv+0x29e/0x3d0
      [ 8451.091277]  [<ffffffff855c74b7>] __netif_receive_skb_core+0xb47/0xe90
      
      Fixes: a8afca03 ("tcp: md5: protects md5sig_info with RCU")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d230c3a0
    • Bjørn Mork's avatar
      net: qmi_wwan: add XS Stick W100-2 from 4G Systems · 98296e85
      Bjørn Mork authored
      commit 68242a5a upstream.
      
      Thomas reports
      "
      4gsystems sells two total different LTE-surfsticks under the same name.
      ..
      The newer version of XS Stick W100 is from "omega"
      ..
      Under windows the driver switches to the same ID, and uses MI03\6 for
      network and MI01\6 for modem.
      ..
      echo "1c9e 9b01" > /sys/bus/usb/drivers/qmi_wwan/new_id
      echo "1c9e 9b01" > /sys/bus/usb-serial/drivers/option1/new_id
      
      T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=1c9e ProdID=9b01 Rev=02.32
      S:  Manufacturer=USB Modem
      S:  Product=USB Modem
      S:  SerialNumber=
      C:  #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      
      Now all important things are there:
      
      wwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at)
      
      There is also ttyUSB0, but it is not usable, at least not for at.
      
      The device works well with qmi and ModemManager-NetworkManager.
      "
      Reported-by: default avatarThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      98296e85
    • Neil Horman's avatar
      snmp: Remove duplicate OUTMCAST stat increment · 427aad52
      Neil Horman authored
      commit 41033f02 upstream.
      
      the OUTMCAST stat is double incremented, getting bumped once in the mcast code
      itself, and again in the common ip output path.  Remove the mcast bump, as its
      not needed
      
      Validated by the reporter, with good results
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: default avatarClaus Jensen <claus.jensen@microsemi.com>
      CC: Claus Jensen <claus.jensen@microsemi.com>
      CC: David Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      427aad52
    • Jason A. Donenfeld's avatar
      ip_tunnel: disable preemption when updating per-cpu tstats · 8625b2f8
      Jason A. Donenfeld authored
      commit b4fe85f9 upstream.
      
      Drivers like vxlan use the recently introduced
      udp_tunnel_xmit_skb/udp_tunnel6_xmit_skb APIs. udp_tunnel6_xmit_skb
      makes use of ip6tunnel_xmit, and ip6tunnel_xmit, after sending the
      packet, updates the struct stats using the usual
      u64_stats_update_begin/end calls on this_cpu_ptr(dev->tstats).
      udp_tunnel_xmit_skb makes use of iptunnel_xmit, which doesn't touch
      tstats, so drivers like vxlan, immediately after, call
      iptunnel_xmit_stats, which does the same thing - calls
      u64_stats_update_begin/end on this_cpu_ptr(dev->tstats).
      
      While vxlan is probably fine (I don't know?), calling a similar function
      from, say, an unbound workqueue, on a fully preemptable kernel causes
      real issues:
      
      [  188.434537] BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u8:0/6
      [  188.435579] caller is debug_smp_processor_id+0x17/0x20
      [  188.435583] CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.6 #2
      [  188.435607] Call Trace:
      [  188.435611]  [<ffffffff8234e936>] dump_stack+0x4f/0x7b
      [  188.435615]  [<ffffffff81915f3d>] check_preemption_disabled+0x19d/0x1c0
      [  188.435619]  [<ffffffff81915f77>] debug_smp_processor_id+0x17/0x20
      
      The solution would be to protect the whole
      this_cpu_ptr(dev->tstats)/u64_stats_update_begin/end blocks with
      disabling preemption and then reenabling it.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8625b2f8
    • Daniel Borkmann's avatar
      packet: infer protocol from ethernet header if unset · d9850f8e
      Daniel Borkmann authored
      commit c72219b7 upstream.
      
      In case no struct sockaddr_ll has been passed to packet
      socket's sendmsg() when doing a TX_RING flush run, then
      skb->protocol is set to po->num instead, which is the protocol
      passed via socket(2)/bind(2).
      
      Applications only xmitting can go the path of allocating the
      socket as socket(PF_PACKET, <mode>, 0) and do a bind(2) on the
      TX_RING with sll_protocol of 0. That way, register_prot_hook()
      is neither called on creation nor on bind time, which saves
      cycles when there's no interest in capturing anyway.
      
      That leaves us however with po->num 0 instead and therefore
      the TX_RING flush run sets skb->protocol to 0 as well. Eric
      reported that this leads to problems when using tools like
      trafgen over bonding device. I.e. the bonding's hash function
      could invoke the kernel's flow dissector, which depends on
      skb->protocol being properly set. In the current situation, all
      the traffic is then directed to a single slave.
      
      Fix it up by inferring skb->protocol from the Ethernet header
      when not set and we have ARPHRD_ETHER device type. This is only
      done in case of SOCK_RAW and where we have a dev->hard_header_len
      length. In case of ARPHRD_ETHER devices, this is guaranteed to
      cover ETH_HLEN, and therefore being accessed on the skb after
      the skb_store_bits().
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d9850f8e
    • Daniel Borkmann's avatar
      packet: always probe for transport header · 66a74d96
      Daniel Borkmann authored
      commit 8fd6c80d upstream.
      
      We concluded that the skb_probe_transport_header() should better be
      called unconditionally. Avoiding the call into the flow dissector has
      also not really much to do with the direct xmit mode.
      
      While it seems that only virtio_net code makes use of GSO from non
      RX/TX ring packet socket paths, we should probe for a transport header
      nevertheless before they hit devices.
      
      Reference: http://thread.gmane.org/gmane.linux.network/386173/Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      66a74d96