1. 16 Mar, 2017 40 commits
    • Michal Hocko's avatar
      mm, fs: check for fatal signals in do_generic_file_read() · be16e27d
      Michal Hocko authored
      commit 5abf186a upstream.
      
      do_generic_file_read() can be told to perform a large request from
      userspace.  If the system is under OOM and the reading task is the OOM
      victim then it has an access to memory reserves and finishing the full
      request can lead to the full memory depletion which is dangerous.  Make
      sure we rather go with a short read and allow the killed task to
      terminate.
      
      Link: http://lkml.kernel.org/r/20170201092706.9966-3-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      be16e27d
    • Eric Dumazet's avatar
      net: use a work queue to defer net_disable_timestamp() work · 8c41674b
      Eric Dumazet authored
      commit 5fa8bbda upstream.
      
      Dmitry reported a warning [1] showing that we were calling
      net_disable_timestamp() -> static_key_slow_dec() from a non
      process context.
      
      Grabbing a mutex while holding a spinlock or rcu_read_lock()
      is not allowed.
      
      As Cong suggested, we now use a work queue.
      
      It is possible netstamp_clear() exits while netstamp_needed_deferred
      is not zero, but it is probably not worth trying to do better than that.
      
      netstamp_needed_deferred atomic tracks the exact number of deferred
      decrements.
      
      [1]
      [ INFO: suspicious RCU usage. ]
      4.10.0-rc5+ #192 Not tainted
      -------------------------------
      ./include/linux/rcupdate.h:561 Illegal context switch in RCU read-side
      critical section!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 0
      2 locks held by syz-executor14/23111:
       #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>] lock_sock
      include/net/sock.h:1454 [inline]
       #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>]
      rawv6_sendmsg+0x1e65/0x3ec0 net/ipv6/raw.c:919
       #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>] nf_hook
      include/linux/netfilter.h:201 [inline]
       #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>]
      __ip6_local_out+0x258/0x840 net/ipv6/output_core.c:160
      
      stack backtrace:
      CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
      01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:15 [inline]
       dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
       lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4452
       rcu_preempt_sleep_check include/linux/rcupdate.h:560 [inline]
       ___might_sleep+0x560/0x650 kernel/sched/core.c:7748
       __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
       mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
       atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
       __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
       static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
       net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
       sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
       __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
       sk_destruct+0x47/0x80 net/core/sock.c:1460
       __sk_free+0x57/0x230 net/core/sock.c:1468
       sock_wfree+0xae/0x120 net/core/sock.c:1645
       skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
       skb_release_all+0x15/0x60 net/core/skbuff.c:668
       __kfree_skb+0x15/0x20 net/core/skbuff.c:684
       kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
       inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
       inet_frag_put include/net/inet_frag.h:133 [inline]
       nf_ct_frag6_gather+0x1106/0x3840
      net/ipv6/netfilter/nf_conntrack_reasm.c:617
       ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
       nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
       nf_hook include/linux/netfilter.h:212 [inline]
       __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
       ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
       ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
       ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
       rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
       rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:645
       sock_write_iter+0x326/0x600 net/socket.c:848
       do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
       do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
       vfs_writev+0x87/0xc0 fs/read_write.c:911
       do_writev+0x110/0x2c0 fs/read_write.c:944
       SYSC_writev fs/read_write.c:1017 [inline]
       SyS_writev+0x27/0x30 fs/read_write.c:1014
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      RIP: 0033:0x445559
      RSP: 002b:00007f6f46fceb58 EFLAGS: 00000292 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000445559
      RDX: 0000000000000001 RSI: 0000000020f1eff0 RDI: 0000000000000005
      RBP: 00000000006e19c0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000700000
      R13: 0000000020f59000 R14: 0000000000000015 R15: 0000000000020400
      BUG: sleeping function called from invalid context at
      kernel/locking/mutex.c:752
      in_atomic(): 1, irqs_disabled(): 0, pid: 23111, name: syz-executor14
      INFO: lockdep is turned off.
      CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
      01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:15 [inline]
       dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
       ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780
       __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
       mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
       atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
       __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
       static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
       net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
       sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
       __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
       sk_destruct+0x47/0x80 net/core/sock.c:1460
       __sk_free+0x57/0x230 net/core/sock.c:1468
       sock_wfree+0xae/0x120 net/core/sock.c:1645
       skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
       skb_release_all+0x15/0x60 net/core/skbuff.c:668
       __kfree_skb+0x15/0x20 net/core/skbuff.c:684
       kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
       inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
       inet_frag_put include/net/inet_frag.h:133 [inline]
       nf_ct_frag6_gather+0x1106/0x3840
      net/ipv6/netfilter/nf_conntrack_reasm.c:617
       ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
       nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
       nf_hook include/linux/netfilter.h:212 [inline]
       __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
       ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
       ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
       ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
       rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
       rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:645
       sock_write_iter+0x326/0x600 net/socket.c:848
       do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
       do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
       vfs_writev+0x87/0xc0 fs/read_write.c:911
       do_writev+0x110/0x2c0 fs/read_write.c:944
       SYSC_writev fs/read_write.c:1017 [inline]
       SyS_writev+0x27/0x30 fs/read_write.c:1014
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      RIP: 0033:0x445559
      
      Fixes: b90e5794 ("net: dont call jump_label_dec from irq context")
      Suggested-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8c41674b
    • J. Bruce Fields's avatar
      svcrpc: fix oops in absence of krb5 module · 7b1b3a3a
      J. Bruce Fields authored
      commit 034dd34f upstream.
      
      Olga Kornievskaia says: "I ran into this oops in the nfsd (below)
      (4.10-rc3 kernel). To trigger this I had a client (unsuccessfully) try
      to mount the server with krb5 where the server doesn't have the
      rpcsec_gss_krb5 module built."
      
      The problem is that rsci.cred is copied from a svc_cred structure that
      gss_proxy didn't properly initialize.  Fix that.
      
      [120408.542387] general protection fault: 0000 [#1] SMP
      ...
      [120408.565724] CPU: 0 PID: 3601 Comm: nfsd Not tainted 4.10.0-rc3+ #16
      [120408.567037] Hardware name: VMware, Inc. VMware Virtual =
      Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
      [120408.569225] task: ffff8800776f95c0 task.stack: ffffc90003d58000
      [120408.570483] RIP: 0010:gss_mech_put+0xb/0x20 [auth_rpcgss]
      ...
      [120408.584946]  ? rsc_free+0x55/0x90 [auth_rpcgss]
      [120408.585901]  gss_proxy_save_rsc+0xb2/0x2a0 [auth_rpcgss]
      [120408.587017]  svcauth_gss_proxy_init+0x3cc/0x520 [auth_rpcgss]
      [120408.588257]  ? __enqueue_entity+0x6c/0x70
      [120408.589101]  svcauth_gss_accept+0x391/0xb90 [auth_rpcgss]
      [120408.590212]  ? try_to_wake_up+0x4a/0x360
      [120408.591036]  ? wake_up_process+0x15/0x20
      [120408.592093]  ? svc_xprt_do_enqueue+0x12e/0x2d0 [sunrpc]
      [120408.593177]  svc_authenticate+0xe1/0x100 [sunrpc]
      [120408.594168]  svc_process_common+0x203/0x710 [sunrpc]
      [120408.595220]  svc_process+0x105/0x1c0 [sunrpc]
      [120408.596278]  nfsd+0xe9/0x160 [nfsd]
      [120408.597060]  kthread+0x101/0x140
      [120408.597734]  ? nfsd_destroy+0x60/0x60 [nfsd]
      [120408.598626]  ? kthread_park+0x90/0x90
      [120408.599448]  ret_from_fork+0x22/0x30
      
      Fixes: 1d658336 "SUNRPC: Add RPC based upcall mechanism for RPCGSS auth"
      Cc: Simo Sorce <simo@redhat.com>
      Reported-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Tested-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7b1b3a3a
    • Marcel J.E. Mol's avatar
      USB: serial: pl2303: add ATEN device ID · 0e52e510
      Marcel J.E. Mol authored
      commit d07830db upstream.
      
      Seems that ATEN serial-to-usb devices using pl2303 exist with
      different device ids. This patch adds a missing device ID so it
      is recognised by the driver.
      Signed-off-by: default avatarMarcel J.E. Mol <marcel@mesa.nl>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0e52e510
    • Gabriel Krisman Bertazi's avatar
      mmc: sdhci: Ignore unexpected CARD_INT interrupts · e1844528
      Gabriel Krisman Bertazi authored
      commit 161e6d44 upstream.
      
      One of our kernelCI boxes hanged at boot because a faulty eSDHC device
      was triggering spurious CARD_INT interrupts for SD cards, causing CMD52
      reads, which are not allowed for SD devices.  This adds a sanity check
      to the interruption path, preventing that illegal command from getting
      sent if the CARD_INT interruption should be disabled.
      
      This quirk allows that particular machine to resume boot despite the
      faulty hardware, instead of getting hung dealing with thousands of
      mishandled interrupts.
      Suggested-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarGabriel Krisman Bertazi <krisman@collabora.co.uk>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e1844528
    • Ilia Mirkin's avatar
      drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrieval · 83133f1b
      Ilia Mirkin authored
      commit 24bf7ae3 upstream.
      
      Based on the xf86-video-nv code, NFORCE (NV1A) and NFORCE2 (NV1F) have a
      different way of retrieving clocks. See the
      nv_hw.c:nForceUpdateArbitrationSettings function in the original code
      for how these clocks were accessed.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54587Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      83133f1b
    • Dave Martin's avatar
      ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write · 8b2ceb6b
      Dave Martin authored
      commit 228dbbfb upstream.
      
      Ensure that if userspace supplies insufficient data to
      PTRACE_SETREGSET to fill all the registers, the thread's old
      registers are preserved.
      
      Fixes: 5be6f62b ("ARM: 6883/1: ptrace: Migrate to regsets framework")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8b2ceb6b
    • Peter Zijlstra's avatar
      perf/core: Fix PERF_RECORD_MMAP2 prot/flags for anonymous memory · d57d09e7
      Peter Zijlstra authored
      commit 0b3589be upstream.
      
      Andres reported that MMAP2 records for anonymous memory always have
      their protection field 0.
      
      Turns out, someone daft put the prot/flags generation code in the file
      branch, leaving them unset for anonymous memory.
      Reported-by: default avatarAndres Freund <andres@anarazel.de>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Don Zickus <dzickus@redhat.com
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@gmail.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@kernel.org
      Cc: anton@ozlabs.org
      Cc: namhyung@kernel.org
      Fixes: f972eb63 ("perf: Pass protection and flags bits through mmap2 interface")
      Link: http://lkml.kernel.org/r/20170126221508.GF6536@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d57d09e7
    • Oliver Hartkopp's avatar
      can: bcm: fix hrtimer/tasklet termination in bcm op removal · 1689c3c0
      Oliver Hartkopp authored
      commit a06393ed upstream.
      
      When removing a bcm tx operation either a hrtimer or a tasklet might run.
      As the hrtimer triggers its associated tasklet and vice versa we need to
      take care to mutually terminate both handlers.
      Reported-by: default avatarMichael Josenhans <michael.josenhans@web.de>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Tested-by: default avatarMichael Josenhans <michael.josenhans@web.de>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1689c3c0
    • Helge Deller's avatar
      parisc: Don't use BITS_PER_LONG in userspace-exported swab.h header · 06ed1096
      Helge Deller authored
      commit 2ad5d52d upstream.
      
      In swab.h the "#if BITS_PER_LONG > 32" breaks compiling userspace programs if
      BITS_PER_LONG is #defined by userspace with the sizeof() compiler builtin.
      
      Solve this problem by using __BITS_PER_LONG instead.  Since we now
      #include asm/bitsperlong.h avoid further potential userspace pollution
      by moving the #define of SHIFT_PER_LONG to bitops.h which is not
      exported to userspace.
      
      This patch unbreaks compiling qemu on hppa/parisc.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      06ed1096
    • Vineet Gupta's avatar
      ARC: [arcompact] handle unaligned access delay slot corner case · e15d8e5a
      Vineet Gupta authored
      commit 9aed02fe upstream.
      
      After emulating an unaligned access in delay slot of a branch, we
      pretend as the delay slot never happened - so return back to actual
      branch target (or next PC if branch was not taken).
      
      Curently we did this by handling STATUS32.DE, we also need to clear the
      BTA.T bit, which is disregarded when returning from original misaligned
      exception, but could cause weirdness if it took the interrupt return
      path (in case interrupt was acive too)
      
      One ARC700 customer ran into this when enabling unaligned access fixup
      for kernel mode accesses as well
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e15d8e5a
    • Arnd Bergmann's avatar
      ISDN: eicon: silence misleading array-bounds warning · dd5d0193
      Arnd Bergmann authored
      commit 950eabbd upstream.
      
      With some gcc versions, we get a warning about the eicon driver,
      and that currently shows up as the only remaining warning in one
      of the build bots:
      
      In file included from ../drivers/isdn/hardware/eicon/message.c:30:0:
      eicon/message.c: In function 'mixer_notify_update':
      eicon/platform.h:333:18: warning: array subscript is above array bounds [-Warray-bounds]
      
      The code is easily changed to open-code the unusual PUT_WORD() line
      causing this to avoid the warning.
      
      Link: http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.45/Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dd5d0193
    • Chuck Lever's avatar
      nfs: Fix "Don't increment lock sequence ID after NFS4ERR_MOVED" · 36e0a737
      Chuck Lever authored
      commit 406dab84 upstream.
      
      Lock sequence IDs are bumped in decode_lock by calling
      nfs_increment_seqid(). nfs_increment_sequid() does not use the
      seqid_mutating_err() function fixed in commit 059aa734 ("Don't
      increment lock sequence ID after NFS4ERR_MOVED").
      
      Fixes: 059aa734 ("Don't increment lock sequence ID after ...")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarXuan Qi <xuan.qi@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      36e0a737
    • Eric Dumazet's avatar
      sysctl: fix proc_doulongvec_ms_jiffies_minmax() · 328dca1a
      Eric Dumazet authored
      commit ff9f8a7c upstream.
      
      We perform the conversion between kernel jiffies and ms only when
      exporting kernel value to user space.
      
      We need to do the opposite operation when value is written by user.
      
      Only matters when HZ != 1000
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      328dca1a
    • Ander Conselvan de Oliveira's avatar
      drm/i915: Don't leak edid in intel_crt_detect_ddc() · daff9f84
      Ander Conselvan de Oliveira authored
      commit c34f0786 upstream.
      
      In the path where intel_crt_detect_ddc() detects a CRT, if would return
      true without freeing the edid.
      
      Fixes: a2bd1f54 ("drm/i915: check whether we actually received an edid in detect_ddc")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Signed-off-by: default avatarAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1484922525-6131-1-git-send-email-ander.conselvan.de.oliveira@intel.com
      (cherry picked from commit c96b63a6)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      daff9f84
    • Lukáš Lalinský's avatar
      USB: Add quirk for WORLDE easykey.25 MIDI keyboard · 5879e88c
      Lukáš Lalinský authored
      commit d9b2997e upstream.
      
      Add a quirk for WORLDE easykey.25 MIDI keyboard (idVendor=0218,
      idProduct=0401). The device reports that it has config string
      descriptor at index 3, but when the system selects the configuration
      and tries to get the description, it returns a -EPROTO error,
      the communication restarts and this keeps repeating over and over again.
      Not requesting the string descriptor makes the device work correctly.
      
      Relevant info from Wireshark:
      
      [...]
      
      CONFIGURATION DESCRIPTOR
          bLength: 9
          bDescriptorType: 0x02 (CONFIGURATION)
          wTotalLength: 101
          bNumInterfaces: 2
          bConfigurationValue: 1
          iConfiguration: 3
          Configuration bmAttributes: 0xc0  SELF-POWERED  NO REMOTE-WAKEUP
              1... .... = Must be 1: Must be 1 for USB 1.1 and higher
              .1.. .... = Self-Powered: This device is SELF-POWERED
              ..0. .... = Remote Wakeup: This device does NOT support remote wakeup
          bMaxPower: 50  (100mA)
      
      [...]
      
           45 0.369104       host                  2.38.0                USB      64     GET DESCRIPTOR Request STRING
      
      [...]
      
      URB setup
          bmRequestType: 0x80
              1... .... = Direction: Device-to-host
              .00. .... = Type: Standard (0x00)
              ...0 0000 = Recipient: Device (0x00)
          bRequest: GET DESCRIPTOR (6)
          Descriptor Index: 0x03
          bDescriptorType: 0x03
          Language Id: English (United States) (0x0409)
          wLength: 255
      
           46 0.369255       2.38.0                host                  USB      64     GET DESCRIPTOR Response STRING[Malformed Packet]
      
      [...]
      
      Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
      USB URB
          [Source: 2.38.0]
          [Destination: host]
          URB id: 0xffff88021f62d480
          URB type: URB_COMPLETE ('C')
          URB transfer type: URB_CONTROL (0x02)
          Endpoint: 0x80, Direction: IN
          Device: 38
          URB bus id: 2
          Device setup request: not relevant ('-')
          Data: present (0)
          URB sec: 1484896277
          URB usec: 455031
          URB status: Protocol error (-EPROTO) (-71)
          URB length [bytes]: 0
          Data length [bytes]: 0
          [Request in: 45]
          [Time from request: 0.000151000 seconds]
          Unused Setup Header
          Interval: 0
          Start frame: 0
          Copy of Transfer Flags: 0x00000200
          Number of ISO descriptors: 0
      [Malformed Packet: USB]
          [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
              [Malformed Packet (Exception occurred)]
              [Severity level: Error]
              [Group: Malformed]
      Signed-off-by: default avatarLukáš Lalinský <lukas@oxygene.sk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5879e88c
    • Keno Fischer's avatar
      mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp · 303681d5
      Keno Fischer authored
      commit 8310d48b upstream.
      
      In commit 19be0eaf ("mm: remove gup_flags FOLL_WRITE games from
      __get_user_pages()"), the mm code was changed from unsetting FOLL_WRITE
      after a COW was resolved to setting the (newly introduced) FOLL_COW
      instead.  Simultaneously, the check in gup.c was updated to still allow
      writes with FOLL_FORCE set if FOLL_COW had also been set.
      
      However, a similar check in huge_memory.c was forgotten.  As a result,
      remote memory writes to ro regions of memory backed by transparent huge
      pages cause an infinite loop in the kernel (handle_mm_fault sets
      FOLL_COW and returns 0 causing a retry, but follow_trans_huge_pmd bails
      out immidiately because `(flags & FOLL_WRITE) && !pmd_write(*pmd)` is
      true.
      
      While in this state the process is stil SIGKILLable, but little else
      works (e.g.  no ptrace attach, no other signals).  This is easily
      reproduced with the following code (assuming thp are set to always):
      
          #include <assert.h>
          #include <fcntl.h>
          #include <stdint.h>
          #include <stdio.h>
          #include <string.h>
          #include <sys/mman.h>
          #include <sys/stat.h>
          #include <sys/types.h>
          #include <sys/wait.h>
          #include <unistd.h>
      
          #define TEST_SIZE 5 * 1024 * 1024
      
          int main(void) {
            int status;
            pid_t child;
            int fd = open("/proc/self/mem", O_RDWR);
            void *addr = mmap(NULL, TEST_SIZE, PROT_READ,
                              MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
            assert(addr != MAP_FAILED);
            pid_t parent_pid = getpid();
            if ((child = fork()) == 0) {
              void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
                                 MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
              assert(addr2 != MAP_FAILED);
              memset(addr2, 'a', TEST_SIZE);
              pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
              return 0;
            }
            assert(child == waitpid(child, &status, 0));
            assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
            return 0;
          }
      
      Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously
      to the update in gup.c in the original commit.  The same pattern exists
      in follow_devmap_pmd.  However, we should not be able to reach that
      check with FOLL_COW set, so add WARN_ONCE to make sure we notice if we
      ever do.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Link: http://lkml.kernel.org/r/20170106015025.GA38411@juliacomputing.comSigned-off-by: default avatarKeno Fischer <keno@juliacomputing.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Hugh Dickins <hughd@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16:
       - Drop change to follow_devmap_pmd()
       - pmd_dirty() is not available; check the page flags as in older
         backports of can_follow_write_pte()
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      303681d5
    • Liping Zhang's avatar
      netfilter: nft_log: restrict the log prefix length to 127 · f338af4f
      Liping Zhang authored
      commit 5ce6b04c upstream.
      
      First, log prefix will be truncated to NF_LOG_PREFIXLEN-1, i.e. 127,
      at nf_log_packet(), so the extra part is useless.
      
      Second, after adding a log rule with a very very long prefix, we will
      fail to dump the nft rules after this _special_ one, but acctually,
      they do exist. For example:
        # name_65000=$(printf "%0.sQ" {1..65000})
        # nft add rule filter output log prefix "$name_65000"
        # nft add rule filter output counter
        # nft add rule filter output counter
        # nft list chain filter output
        table ip filter {
            chain output {
                type filter hook output priority 0; policy accept;
            }
        }
      
      So now, restrict the log prefix length to NF_LOG_PREFIXLEN-1.
      
      Fixes: 96518518 ("netfilter: add nftables")
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      [bwh: Backported to 3.16: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f338af4f
    • Kinglong Mee's avatar
      SUNRPC: cleanup ida information when removing sunrpc module · 929d9d79
      Kinglong Mee authored
      commit c929ea0b upstream.
      
      After removing sunrpc module, I get many kmemleak information as,
      unreferenced object 0xffff88003316b1e0 (size 544):
        comm "gssproxy", pid 2148, jiffies 4294794465 (age 4200.081s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffffb0cfb58a>] kmemleak_alloc+0x4a/0xa0
          [<ffffffffb03507fe>] kmem_cache_alloc+0x15e/0x1f0
          [<ffffffffb0639baa>] ida_pre_get+0xaa/0x150
          [<ffffffffb0639cfd>] ida_simple_get+0xad/0x180
          [<ffffffffc06054fb>] nlmsvc_lookup_host+0x4ab/0x7f0 [lockd]
          [<ffffffffc0605e1d>] lockd+0x4d/0x270 [lockd]
          [<ffffffffc06061e5>] param_set_timeout+0x55/0x100 [lockd]
          [<ffffffffc06cba24>] svc_defer+0x114/0x3f0 [sunrpc]
          [<ffffffffc06cbbe7>] svc_defer+0x2d7/0x3f0 [sunrpc]
          [<ffffffffc06c71da>] rpc_show_info+0x8a/0x110 [sunrpc]
          [<ffffffffb044a33f>] proc_reg_write+0x7f/0xc0
          [<ffffffffb038e41f>] __vfs_write+0xdf/0x3c0
          [<ffffffffb0390f1f>] vfs_write+0xef/0x240
          [<ffffffffb0392fbd>] SyS_write+0xad/0x130
          [<ffffffffb0d06c37>] entry_SYSCALL_64_fastpath+0x1a/0xa9
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      I found, the ida information (dynamic memory) isn't cleanup.
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Fixes: 2f048db4 ("SUNRPC: Add an identifier for struct rpc_clnt")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      929d9d79
    • Eric Dumazet's avatar
      ip6_tunnel: must reload ipv6h in ip6ip6_tnl_xmit() · 66c33101
      Eric Dumazet authored
      commit 21b995a9 upstream.
      
      Since ip6_tnl_parse_tlv_enc_lim() can call pskb_may_pull(),
      we must reload any pointer that was related to skb->head
      (or skb->data), or risk use after free.
      
      Fixes: c12b395a ("gre: Support GRE over IPv6")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Dmitry Kozlov <xeb@mail.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context, indentation]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      66c33101
    • Chuck Lever's avatar
      nfs: Don't increment lock sequence ID after NFS4ERR_MOVED · 04fe04e7
      Chuck Lever authored
      commit 059aa734 upstream.
      
      Xuan Qi reports that the Linux NFSv4 client failed to lock a file
      that was migrated. The steps he observed on the wire:
      
      1. The client sent a LOCK request to the source server
      2. The source server replied NFS4ERR_MOVED
      3. The client switched to the destination server
      4. The client sent the same LOCK request to the destination
         server with a bumped lock sequence ID
      5. The destination server rejected the LOCK request with
         NFS4ERR_BAD_SEQID
      
      RFC 3530 section 8.1.5 provides a list of NFS errors which do not
      bump a lock sequence ID.
      
      However, RFC 3530 is now obsoleted by RFC 7530. In RFC 7530 section
      9.1.7, this list has been updated by the addition of NFS4ERR_MOVED.
      Reported-by: default avatarXuan Qi <xuan.qi@oracle.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      04fe04e7
    • Bjørn Mork's avatar
      USB: serial: option: add device ID for HP lt2523 (Novatel E371) · 5d06a226
      Bjørn Mork authored
      commit 5d03a2fd upstream.
      
      Yet another laptop vendor rebranded Novatel E371.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5d06a226
    • Darren Stevens's avatar
      powerpc: Add missing error check to prom_find_boot_cpu() · 3a3ab4a7
      Darren Stevens authored
      commit af2b7fa1 upstream.
      
      prom_init.c calls 'instance-to-package' twice, but the return
      is not checked during prom_find_boot_cpu(). The result is then
      passed to prom_getprop(), which could be PROM_ERROR. Add a return check
      to prevent this.
      
      This was found on a pasemi system, where CFE doesn't have a working
      'instance-to package' prom call.
      
      Before Commit 5c0484e2 ('powerpc: Endian safe trampoline') the area
      around addr 0 was mostly 0's and this doesn't cause a problem. Once the
      macro 'FIXUP_ENDIAN' has been added to head_64.S, the low memory area
      now has non-zero values, which cause the prom_getprop() call
      to hang.
      
      mpe: Also confirmed that under SLOF if 'instance-to-package' did fail
      with PROM_ERROR we would crash in SLOF. So the bug is not specific to
      CFE, it's just that other open firmwares don't trigger it because they
      have a working 'instance-to-package'.
      
      Fixes: 5c0484e2 ("powerpc: Endian safe trampoline")
      Signed-off-by: default avatarDarren Stevens <darren@stevens-zone.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3a3ab4a7
    • Ard Biesheuvel's avatar
      crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes · a2fcebf0
      Ard Biesheuvel authored
      commit 11e3b725 upstream.
      
      Update the ARMv8 Crypto Extensions and the plain NEON AES implementations
      in CBC and CTR modes to return the next IV back to the skcipher API client.
      This is necessary for chaining to work correctly.
      
      Note that for CTR, this is only done if the request is a round multiple of
      the block size, since otherwise, chaining is impossible anyway.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a2fcebf0
    • Salvatore Benedetto's avatar
      crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg · 3ae51b03
      Salvatore Benedetto authored
      commit d6040764 upstream.
      
      Make sure CRYPTO_ALG_DEAD bit is cleared before proceeding with
      the algorithm registration. This fixes qat-dh registration when
      driver is restarted
      Signed-off-by: default avatarSalvatore Benedetto <salvatore.benedetto@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3ae51b03
    • John Brooks's avatar
      iio: dht11: Use usleep_range instead of msleep for start signal · cac7b00f
      John Brooks authored
      commit 5c113b5e upstream.
      
      The DHT22 (AM2302) datasheet specifies that the LOW start pulse should not
      exceed 20ms. However, observations with an oscilloscope of an RPi Model 2B
      (rev 1.1) communicating with a DHT22 sensor showed that the driver was
      consistently sending start pulses longer than 20ms:
      
      Kernel 4.7.10-v7+ (n=132):
          Minimum pulse length: 20.20ms
          Maximum:              29.84ms
          Mean:                 24.96ms
          StDev:                2.82ms
          Sensor response rate: 100%
          Read success rate:    76%
      
      On kernel 4.8, the start pulse was so long that the sensor would not even
      respond 97% of the time:
      
      Kernel 4.8.16-v7+ (n=100):
          Minimum pulse length: 30.4ms
          Maximum:              74.4ms
          Mean:                 39.3ms
          StDev:                10.2ms
          Sensor response rate: 3%
          Read success rate:    3%
      
      The driver would return ETIMEDOUT and write log messages like this:
      
      [   51.430987] dht11 dht11@0: Only 1 signal edges detected
      [   66.311019] dht11 dht11@0: Only 0 signal edges detected
      
      Replacing msleep(18) with usleep_range(18000, 20000) made the pulse length
      sane again and restored responsiveness:
      
      Kernel 4.8.16-v7+ with usleep_range (n=123):
          Minimum pulse length: 18.16ms
          Maximum:              20.20ms
          Mean:                 19.85ms
          StDev:                0.51ms
          Sensor response rate: 100%
          Read success rate:    84%
      Signed-off-by: default avatarJohn Brooks <john@fastquake.com>
      Reviewed-by: default avatarHarald Geyer <harald@ccbib.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cac7b00f
    • Andy Shevchenko's avatar
      platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT · 15a1b0cb
      Andy Shevchenko authored
      commit 5a00b6c2 upstream.
      
      The commit 1c6c6952 ("genirq: Reject bogus threaded irq requests")
      starts refusing misconfigured interrupt handlers. This makes
      intel_mid_powerbtn not working anymore.
      
      Add a mandatory flag to a threaded IRQ request in the driver.
      
      Fixes: 1c6c6952 ("genirq: Reject bogus threaded irq requests")
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      15a1b0cb
    • Anton Blanchard's avatar
      powerpc: Ignore reserved field in DCSR and PVR reads and writes · a583f481
      Anton Blanchard authored
      commit 178f3582 upstream.
      
      IBM bit 31 (for the rest of us - bit 0) is a reserved field in the
      instruction definition of mtspr and mfspr. Hardware is encouraged to
      (and does) ignore it.
      
      As a result, if userspace executes an mtspr DSCR with the reserved bit
      set, we get a DSCR facility unavailable exception. The kernel fails to
      match against the expected value/mask, and we silently return to
      userspace to try and re-execute the same mtspr DSCR instruction. We
      loop forever until the process is killed.
      
      We should do something here, and it seems mirroring what hardware does
      is the better option vs killing the process. While here, relax the
      matching of mfspr PVR too.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a583f481
    • Dave Martin's avatar
      powerpc/ptrace: Preserve previous fprs/vsrs on short regset write · bbe824c5
      Dave Martin authored
      commit 99dfe80a upstream.
      
      Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
      to fill all the registers, the thread's old registers are preserved.
      
      Fixes: c6e6771b ("powerpc: Introduce VSX thread_struct and CONFIG_VSX")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bbe824c5
    • Fabien Parent's avatar
      ARM: dts: da850-evm: fix read access to SPI flash · 9e78d6e7
      Fabien Parent authored
      commit 43849785 upstream.
      
      Read access to the SPI flash are broken on da850-evm, i.e. the data
      read is not what is actually programmed on the flash.
      According to the datasheet for the M25P64 part present on the da850-evm,
      if the SPI frequency is higher than 20MHz then the READ command is not
      usable anymore and only the FAST_READ command can be used to read data.
      
      This commit specifies in the DTS that we should use FAST_READ command
      instead of the READ command.
      Tested-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarFabien Parent <fparent@baylibre.com>
      [nsekhar@ti.com: subject line adjustment]
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9e78d6e7
    • Josef Bacik's avatar
      nbd: only set MSG_MORE when we have more to send · c72a18bc
      Josef Bacik authored
      commit d61b7f97 upstream.
      
      A user noticed that write performance was horrible over loopback and we
      traced it to an inversion of when we need to set MSG_MORE.  It should be
      set when we have more bvec's to send, not when we are on the last bvec.
      This patch made the test go from 20 iops to 78k iops.
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Fixes: 429a787b ("nbd: fix use-after-free of rq/bio in the xmit path")
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c72a18bc
    • Jens Axboe's avatar
      nbd: fix use-after-free of rq/bio in the xmit path · cd38b7d5
      Jens Axboe authored
      commit 429a787b upstream.
      
      For writes, we can get a completion in while we're still iterating
      the request and bio chain. If that happens, we're reading freed
      memory and we can crash.
      
      Break out after the last segment and avoid having the iterator
      read freed memory.
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cd38b7d5
    • Alexey Kodanev's avatar
      tcp: initialize max window for a new fastopen socket · 91bb15ef
      Alexey Kodanev authored
      commit 0dbd7ff3 upstream.
      
      Found that if we run LTP netstress test with large MSS (65K),
      the first attempt from server to send data comparable to this
      MSS on fastopen connection will be delayed by the probe timer.
      
      Here is an example:
      
           < S  seq 0:0 win 43690 options [mss 65495 wscale 7 tfo cookie] length 32
           > S. seq 0:0 ack 1 win 43690 options [mss 65495 wscale 7] length 0
           < .  ack 1 win 342 length 0
      
      Inside tcp_sendmsg(), tcp_send_mss() returns max MSS in 'mss_now',
      as well as in 'size_goal'. This results the segment not queued for
      transmition until all the data copied from user buffer. Then, inside
      __tcp_push_pending_frames(), it breaks on send window test and
      continues with the check probe timer.
      
      Fragmentation occurs in tcp_write_wakeup()...
      
      +0.2 > P. seq 1:43777 ack 1 win 342 length 43776
           < .  ack 43777, win 1365 length 0
           > P. seq 43777:65001 ack 1 win 342 options [...] length 21224
           ...
      
      This also contradicts with the fact that we should bound to the half
      of the window if it is large.
      
      Fix this flaw by correctly initializing max_window. Before that, it
      could have large values that affect further calculations of 'size_goal'.
      
      Fixes: 168a8f58 ("tcp: TCP Fast Open Server - main code path")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      91bb15ef
    • Mark Rutland's avatar
      arm64: avoid returning from bad_mode · 38299d13
      Mark Rutland authored
      commit 7d9e8f71 upstream.
      
      Generally, taking an unexpected exception should be a fatal event, and
      bad_mode is intended to cater for this. However, it should be possible
      to contain unexpected synchronous exceptions from EL0 without bringing
      the kernel down, by sending a SIGILL to the task.
      
      We tried to apply this approach in commit 9955ac47 ("arm64:
      don't kill the kernel on a bad esr from el0"), by sending a signal for
      any bad_mode call resulting from an EL0 exception.
      
      However, this also applies to other unexpected exceptions, such as
      SError and FIQ. The entry paths for these exceptions branch to bad_mode
      without configuring the link register, and have no kernel_exit. Thus, if
      we take one of these exceptions from EL0, bad_mode will eventually
      return to the original user link register value.
      
      This patch fixes this by introducing a new bad_el0_sync handler to cater
      for the recoverable case, and restoring bad_mode to its original state,
      whereby it calls panic() and never returns. The recoverable case
      branches to bad_el0_sync with a bl, and returns to userspace via the
      usual ret_to_user mechanism.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 9955ac47 ("arm64: don't kill the kernel on a bad esr from el0")
      Reported-by: default avatarMark Salter <msalter@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      [bwh: Backported to 3.16:
       - Leave type out of the log message as we don't have esr_get_class_string()
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      38299d13
    • Aleksander Morgado's avatar
      USB: serial: qcserial: add Dell DW5570 QDL · aa686b91
      Aleksander Morgado authored
      commit 24d615a6 upstream.
      
      The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by
      default boot with vid 0x413c and pid 0x81a3. When triggered QDL download
      mode, the device switches to pid 0x81a6 and provides the standard TTY
      used for firmware upgrade.
      Signed-off-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      aa686b91
    • Eric Dumazet's avatar
      net: fix harmonize_features() vs NETIF_F_HIGHDMA · 50349a48
      Eric Dumazet authored
      commit 7be2c82c upstream.
      
      Ashizuka reported a highmem oddity and sent a patch for freescale
      fec driver.
      
      But the problem root cause is that core networking stack
      must ensure no skb with highmem fragment is ever sent through
      a device that does not assert NETIF_F_HIGHDMA in its features.
      
      We need to call illegal_highdma() from harmonize_features()
      regardless of CSUM checks.
      
      Fixes: ec5f0615 ("net: Kill link between CSUM and SG features.")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Pravin Shelar <pshelar@ovn.org>
      Reported-by: default avatar"Ashizuka, Yuusuke" <ashiduka@jp.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      50349a48
    • Dave Martin's avatar
      arm64/ptrace: Reject attempts to set incomplete hardware breakpoint fields · 85f884fa
      Dave Martin authored
      commit ad9e202a upstream.
      
      We cannot preserve partial fields for hardware breakpoints, because
      the values written by userspace to the hardware breakpoint
      registers can't subsequently be recovered intact from the hardware.
      
      So, just reject attempts to write incomplete fields with -EINVAL.
      
      Fixes: 478fcb2c ("arm64: Debugging support")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarWill Deacon <Will.Deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      85f884fa
    • Dave Martin's avatar
      arm64/ptrace: Avoid uninitialised struct padding in fpr_set() · eeee1368
      Dave Martin authored
      commit aeb1f39d upstream.
      
      This patch adds an explicit __reserved[] field to user_fpsimd_state
      to replace what was previously unnamed padding.
      
      This ensures that data in this region are propagated across
      assignment rather than being left possibly uninitialised at the
      destination.
      
      Fixes: 60ffc30d ("arm64: Exception handling")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarWill Deacon <Will.Deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      eeee1368
    • Dave Martin's avatar
      arm64/ptrace: Preserve previous registers for short regset write · 522de0c9
      Dave Martin authored
      commit 9a17b876 upstream.
      
      Ensure that if userspace supplies insufficient data to
      PTRACE_SETREGSET to fill all the registers, the thread's old
      registers are preserved.
      
      Fixes: 478fcb2c ("arm64: Debugging support")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarWill Deacon <Will.Deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      522de0c9
    • Jeff Layton's avatar
      ceph: fix bad endianness handling in parse_reply_info_extra · 09fb9012
      Jeff Layton authored
      commit 6df8c9d8 upstream.
      
      sparse says:
      
          fs/ceph/mds_client.c:291:23: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:293:28: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:294:28: warning: restricted __le32 degrades to integer
          fs/ceph/mds_client.c:296:28: warning: restricted __le32 degrades to integer
      
      The op value is __le32, so we need to convert it before comparing it.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      09fb9012