1. 20 Feb, 2015 40 commits
    • Johan Hovold's avatar
      gpio: sysfs: fix gpio attribute-creation race · a10ff58e
      Johan Hovold authored
      commit ebbeba12 upstream.
      
      Fix attribute-creation race with userspace by using the default group
      to create also the contingent gpio device attributes.
      
      Fixes: d8f388d8 ("gpio: sysfs interface")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [bwh: Backported to 3.2:
       - Adjust filenames, context
       - Use gpio_to_desc(), not gpiod_to_desc(), in gpio_is_visible()
       - gpio_is_visible() must return mode_t]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a10ff58e
    • Johan Hovold's avatar
      gpio: sysfs: fix gpio device-attribute leak · 91111b53
      Johan Hovold authored
      commit 0915e6fe upstream.
      
      The gpio device attributes were never destroyed when the gpio was
      unexported (or on export failures).
      
      Use device_create_with_groups() to create the default device attributes
      of the gpio class device. Note that this also fixes the
      attribute-creation race with userspace for these attributes.
      
      Remove contingent attributes in export error path and on unexport.
      
      Fixes: d8f388d8 ("gpio: sysfs interface")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [bwh: Backported to 3.2: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      91111b53
    • Ming Lei's avatar
      Fix circular locking dependency (3.3-rc2) · 2465975f
      Ming Lei authored
      commit 864533ce upstream.
      
      Hi,
      
      On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote:
      > Hi guys,
      >
      > I have just triggered the folllowing:
      >
      > [   84.860321] ======================================================
      > [   84.860321] [ INFO: possible circular locking dependency detected ]
      > [   84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
      > [   84.860321] -------------------------------------------------------
      > [   84.860321] bash/949 is trying to acquire lock:
      > [   84.860321]  (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
      > [   84.860321]
      > [   84.860321] but task is already holding lock:
      > [   84.860321]  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
      > [   84.911468]
      > [   84.911468] which lock already depends on the new lock.
      > [   84.911468]
      > [   84.920043]
      > [   84.920043] the existing dependency chain (in reverse order) is:
      > [   84.920043]
      > [   84.927886] -> #1 (s_active#22){++++.+}:
      > [   84.927886]        [<c008f640>] check_prevs_add+0xdc/0x150
      > [   84.927886]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
      > [   84.927886]        [<c0090cdc>] __lock_acquire+0x49c/0x980
      > [   84.951660]        [<c0091838>] lock_acquire+0x98/0x100
      > [   84.951660]        [<c016a8e8>] sysfs_deactivate+0xb0/0x100
      > [   84.962982]        [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
      > [   84.962982]        [<c016b8bc>] sysfs_remove_dir+0x84/0x98
      > [   84.962982]        [<c02590d8>] kobject_del+0x10/0x78
      > [   84.974670]        [<c02c29e8>] device_del+0x140/0x170
      > [   84.974670]        [<c02c2a24>] device_unregister+0xc/0x18
      > [   84.985382]        [<c0276894>] gpio_unexport+0xbc/0xdc
      > [   84.985382]        [<c02768c8>] gpio_free+0x14/0xfc
      > [   85.001708]        [<c0276a28>] unexport_store+0x78/0x8c
      > [   85.001708]        [<c02c5af8>] class_attr_store+0x18/0x24
      > [   85.007293]        [<c0169990>] sysfs_write_file+0x100/0x184
      > [   85.018981]        [<c0109d48>] vfs_write+0xb4/0x148
      > [   85.018981]        [<c0109fd0>] sys_write+0x40/0x70
      > [   85.018981]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
      > [   85.035003]
      > [   85.035003] -> #0 (sysfs_lock){+.+.+.}:
      > [   85.035003]        [<c008f54c>] check_prev_add+0x680/0x698
      > [   85.035003]        [<c008f640>] check_prevs_add+0xdc/0x150
      > [   85.052093]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
      > [   85.052093]        [<c0090cdc>] __lock_acquire+0x49c/0x980
      > [   85.052093]        [<c0091838>] lock_acquire+0x98/0x100
      > [   85.069885]        [<c047e280>] mutex_lock_nested+0x3c/0x2f4
      > [   85.069885]        [<c0275358>] gpio_value_store+0x24/0xcc
      > [   85.069885]        [<c02c18dc>] dev_attr_store+0x18/0x24
      > [   85.087158]        [<c0169990>] sysfs_write_file+0x100/0x184
      > [   85.087158]        [<c0109d48>] vfs_write+0xb4/0x148
      > [   85.098297]        [<c0109fd0>] sys_write+0x40/0x70
      > [   85.098297]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
      > [   85.109069]
      > [   85.109069] other info that might help us debug this:
      > [   85.109069]
      > [   85.117462]  Possible unsafe locking scenario:
      > [   85.117462]
      > [   85.117462]        CPU0                    CPU1
      > [   85.128417]        ----                    ----
      > [   85.128417]   lock(s_active#22);
      > [   85.128417]                                lock(sysfs_lock);
      > [   85.128417]                                lock(s_active#22);
      > [   85.142486]   lock(sysfs_lock);
      > [   85.151794]
      > [   85.151794]  *** DEADLOCK ***
      > [   85.151794]
      > [   85.151794] 2 locks held by bash/949:
      > [   85.158020]  #0:  (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
      > [   85.170349]  #1:  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
      > [   85.170349]
      > [   85.178588] stack backtrace:
      > [   85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
      > [   85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
      > [   85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
      > [   85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
      > [   85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
      > [   85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
      > [   85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
      > [   85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
      > [   85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
      > [   85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
      > [   85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
      > [   85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
      > [   85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
      > -bash: echo: write error: Operation not permitted
      >
      > the way to trigger is:
      >
      > root@legolas:~# cd /sys/class/gpio/
      > root@legolas:/sys/class/gpio# echo 2 > export
      > root@legolas:/sys/class/gpio# echo 2 > unexport
      > root@legolas:/sys/class/gpio# echo 2 > export
      > root@legolas:/sys/class/gpio# cd gpio2/
      > root@legolas:/sys/class/gpio/gpio2# echo 1 > value
      
      Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
      fix the problem.
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2465975f
    • Ryan Mallon's avatar
      gpiolib: Refactor gpio_export · 0bebb361
      Ryan Mallon authored
      commit fc4e2514 upstream.
      
      The gpio_export function uses nested if statements and the status
      variable to handle the failure cases. This makes the function logic
      difficult to follow. Refactor the code to abort immediately on failure
      using goto. This makes the code slightly longer, but significantly
      reduces the nesting and number of split lines and makes the code easier
      to read.
      Signed-off-by: default avatarRyan Mallon <rmallon@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0bebb361
    • Johan Hovold's avatar
      gpio: sysfs: fix gpio-chip device-attribute leak · 6f7c3121
      Johan Hovold authored
      commit 121b6a79 upstream.
      
      The gpio-chip device attributes were never destroyed when the device was
      removed.
      
      Fix by using device_create_with_groups() to create the device attributes
      of the chip class device.
      
      Note that this also fixes the attribute-creation race with userspace.
      
      Fixes: d8f388d8 ("gpio: sysfs interface")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6f7c3121
    • Guenter Roeck's avatar
      driver core: Introduce device_create_groups · df56561b
      Guenter Roeck authored
      commit 39ef3112 upstream.
      
      device_create_groups lets callers create devices as well as associated
      sysfs attributes with a single call. This avoids race conditions seen
      if sysfs attributes on new devices are created later.
      
      [fixed up comment block placement and add checks for printk buffer
      formats - gregkh]
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: Jean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      df56561b
    • Greg Kroah-Hartman's avatar
      sysfs.h: add ATTRIBUTE_GROUPS() macro · d4cf625c
      Greg Kroah-Hartman authored
      commit f2f37f58 upstream.
      
      To make it easier for driver subsystems to work with attribute groups,
      create the ATTRIBUTE_GROUPS macro to remove some of the repetitive
      typing for the most common use for attribute groups.
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d4cf625c
    • Oliver Hartkopp's avatar
      can: dev: fix crtlmode_supported check · 0d189b44
      Oliver Hartkopp authored
      commit 9b1087aa upstream.
      
      When changing flags in the CAN drivers ctrlmode the provided new content has to
      be checked whether the bits are allowed to be changed. The bits that are to be
      changed are given as a bitfield in cm->mask. Therefore checking against
      cm->flags is wrong as the content can hold any kind of values.
      
      The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
      detected command line options. To be robust against bogus user space
      applications additionally sanitize the provided flags with the provided mask.
      
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0d189b44
    • Steven Rostedt (Red Hat)'s avatar
      ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing · 3d8d6134
      Steven Rostedt (Red Hat) authored
      commit 237d28db upstream.
      
      If the function graph tracer traces a jprobe callback, the system will
      crash. This can easily be demonstrated by compiling the jprobe
      sample module that is in the kernel tree, loading it and running the
      function graph tracer.
      
       # modprobe jprobe_example.ko
       # echo function_graph > /sys/kernel/debug/tracing/current_tracer
       # ls
      
      The first two commands end up in a nice crash after the first fork.
      (do_fork has a jprobe attached to it, so "ls" just triggers that fork)
      
      The problem is caused by the jprobe_return() that all jprobe callbacks
      must end with. The way jprobes works is that the function a jprobe
      is attached to has a breakpoint placed at the start of it (or it uses
      ftrace if fentry is supported). The breakpoint handler (or ftrace callback)
      will copy the stack frame and change the ip address to return to the
      jprobe handler instead of the function. The jprobe handler must end
      with jprobe_return() which swaps the stack and does an int3 (breakpoint).
      This breakpoint handler will then put back the saved stack frame,
      simulate the instruction at the beginning of the function it added
      a breakpoint to, and then continue on.
      
      For function tracing to work, it hijakes the return address from the
      stack frame, and replaces it with a hook function that will trace
      the end of the call. This hook function will restore the return
      address of the function call.
      
      If the function tracer traces the jprobe handler, the hook function
      for that handler will not be called, and its saved return address
      will be used for the next function. This will result in a kernel crash.
      
      To solve this, pause function tracing before the jprobe handler is called
      and unpause it before it returns back to the function it probed.
      
      Some other updates:
      
      Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the
      code look a bit cleaner and easier to understand (various tries to fix
      this bug required this change).
      
      Note, if fentry is being used, jprobes will change the ip address before
      the function graph tracer runs and it will not be able to trace the
      function that the jprobe is probing.
      
      Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.orgAcked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      [bwh: Backported to 3.2: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3d8d6134
    • Johan Hovold's avatar
      gpio: fix memory and reference leaks in gpiochip_add error path · d0411190
      Johan Hovold authored
      commit 5539b3c9 upstream.
      
      Memory allocated and references taken by of_gpiochip_add and
      acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
      failure to find free gpio range).
      
      Fixes: 391c970c ("of/gpio: add default of_xlate function if device
      has a node pointer")
      Fixes: 664e3e5a ("gpio / ACPI: register to ACPI events
      automatically")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [bwh: Backported to 3.2:
       - Move call to of_gpiochip_add() into conditional section rather
         than rearranging gotos and labels which are in different places
         here
       - There's no ACPI support]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d0411190
    • Mathias Krause's avatar
      crypto: add missing crypto module aliases · fd191009
      Mathias Krause authored
      commit 3e14dcf7 upstream.
      
      Commit 5d26a105 ("crypto: prefix module autoloading with "crypto-"")
      changed the automatic module loading when requesting crypto algorithms
      to prefix all module requests with "crypto-". This requires all crypto
      modules to have a crypto specific module alias even if their file name
      would otherwise match the requested crypto algorithm.
      
      Even though commit 5d26a105 added those aliases for a vast amount of
      modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
      annotations to those files to make them get loaded automatically, again.
      This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
      with kernels v3.18 and below.
      
      Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
      won't work for crypto modules any more.
      
      Fixes: 5d26a105 ("crypto: prefix module autoloading with "crypto-"")
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      [bwh: Backported to 3.2:
       - Adjust filenames
       - Drop changes to algorithms and drivers we don't have]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      fd191009
    • Kees Cook's avatar
      crypto: include crypto- module prefix in template · bed7f528
      Kees Cook authored
      commit 4943ba16 upstream.
      
      This adds the module loading prefix "crypto-" to the template lookup
      as well.
      
      For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
      includes the "crypto-" prefix at every level, correctly rejecting "vfat":
      
      	net-pf-38
      	algif-hash
      	crypto-vfat(blowfish)
      	crypto-vfat(blowfish)-all
      	crypto-vfat
      Reported-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      [bwh: Backported to 3.2: drop changes to cmac and mcryptd which we don't have]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bed7f528
    • Kees Cook's avatar
      crypto: prefix module autoloading with "crypto-" · 9ffea4cb
      Kees Cook authored
      commit 5d26a105 upstream.
      
      This prefixes all crypto module loading with "crypto-" so we never run
      the risk of exposing module auto-loading to userspace via a crypto API,
      as demonstrated by Mathias Krause:
      
      https://lkml.org/lkml/2013/3/4/70Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      [bwh: Backported to 3.2:
       - Adjust filenames
       - Drop changes to algorithms and drivers we don't have
       - Add aliases to generic C implementations that didn't need them before]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9ffea4cb
    • Konstantin Khlebnikov's avatar
      mm: fix corner case in anon_vma endless growing prevention · 36323bf0
      Konstantin Khlebnikov authored
      commit b800c91a upstream.
      
      Fix for BUG_ON(anon_vma->degree) splashes in unlink_anon_vmas() ("kernel
      BUG at mm/rmap.c:399!") caused by commit 7a3ef208 ("mm: prevent
      endless growth of anon_vma hierarchy")
      
      Anon_vma_clone() is usually called for a copy of source vma in
      destination argument.  If source vma has anon_vma it should be already
      in dst->anon_vma.  NULL in dst->anon_vma is used as a sign that it's
      called from anon_vma_fork().  In this case anon_vma_clone() finds
      anon_vma for reusing.
      
      Vma_adjust() calls it differently and this breaks anon_vma reusing
      logic: anon_vma_clone() links vma to old anon_vma and updates degree
      counters but vma_adjust() overrides vma->anon_vma right after that.  As
      a result final unlink_anon_vmas() decrements degree for wrong anon_vma.
      
      This patch assigns ->anon_vma before calling anon_vma_clone().
      Signed-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Reported-and-tested-by: default avatarChris Clayton <chris2553@googlemail.com>
      Reported-and-tested-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      Reported-and-tested-by: default avatarChih-Wei Huang <cwhuang@android-x86.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Daniel Forrest <dan.forrest@ssec.wisc.edu>
      Cc: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.2: vma_adjust() didn't use a variable to propagate
       the error code from anon_vma_clone(); change that at the same time]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      36323bf0
    • Linus Torvalds's avatar
      mm: Don't count the stack guard page towards RLIMIT_STACK · ed19644d
      Linus Torvalds authored
      commit 690eac53 upstream.
      
      Commit fee7e49d ("mm: propagate error from stack expansion even for
      guard page") made sure that we return the error properly for stack
      growth conditions.  It also theorized that counting the guard page
      towards the stack limit might break something, but also said "Let's see
      if anybody notices".
      
      Somebody did notice.  Apparently android-x86 sets the stack limit very
      close to the limit indeed, and including the guard page in the rlimit
      check causes the android 'zygote' process problems.
      
      So this adds the (fairly trivial) code to make the stack rlimit check be
      against the actual real stack size, rather than the size of the vma that
      includes the guard page.
      Reported-and-tested-by: default avatarChih-Wei Huang <cwhuang@android-x86.org>
      Cc: Jay Foad <jay.foad@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ed19644d
    • Johan Hovold's avatar
      USB: console: fix potential use after free · 27e5ab9c
      Johan Hovold authored
      commit 32a4bf2e upstream.
      
      Use tty kref to release the fake tty in usb_console_setup to avoid use
      after free if the underlying serial driver has acquired a reference.
      
      Note that using the tty destructor release_one_tty requires some more
      state to be initialised.
      
      Fixes: 4a90f09b ("tty: usb-serial krefs")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      27e5ab9c
    • Songjun Wu's avatar
      usb: gadget: udc: atmel: fix possible oops when unloading module · 06be755d
      Songjun Wu authored
      commit 5fb694f9 upstream.
      
      When unloading the module 'g_hid.ko', the urb request will be dequeued and the
      completion routine will be excuted. If there is no urb packet, the urb request
      will not be added to the endpoint queue and the completion routine pointer in
      urb request is NULL.
      
      Accessing to this NULL function pointer will cause the Oops issue reported
      below.
      
      Add the code to check if the urb request is in the endpoint queue
      or not. If the urb request is not in the endpoint queue, a negative
      error code will be returned.
      
      Here is the Oops log:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = dedf0000
      [00000000] *pgd=3ede5831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 80000007 [#1] ARM
      Modules linked in: g_hid(-) usb_f_hid libcomposite
      CPU: 0 PID: 923 Comm: rmmod Not tainted 3.18.0+ #2
      Hardware name: Atmel SAMA5 (Device Tree)
      task: df6b1100 ti: dedf6000 task.ti: dedf6000
      PC is at 0x0
      LR is at usb_gadget_giveback_request+0xc/0x10
      pc : [<00000000>]    lr : [<c02ace88>]    psr: 60000093
      sp : dedf7eb0  ip : df572634  fp : 00000000
      r10: 00000000  r9 : df52e210  r8 : 60000013
      r7 : df6a9858  r6 : df52e210  r5 : df6a9858  r4 : df572600
      r3 : 00000000  r2 : ffffff98  r1 : df572600  r0 : df6a9868
      Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c53c7d  Table: 3edf0059  DAC: 00000015
      Process rmmod (pid: 923, stack limit = 0xdedf6230)
      Stack: (0xdedf7eb0 to 0xdedf8000)
      7ea0:                                     00000000 c02adbbc df572580 deced608
      7ec0: df572600 df6a9868 df572634 c02aed3c df577c00 c01b8608 00000000 df6be27c
      7ee0: 00200200 00100100 bf0162f4 c000e544 dedf6000 00000000 00000000 bf010c00
      7f00: bf0162cc bf00159c 00000000 df572980 df52e218 00000001 df5729b8 bf0031d0
      [..]
      [<c02ace88>] (usb_gadget_giveback_request) from [<c02adbbc>] (request_complete+0x64/0x88)
      [<c02adbbc>] (request_complete) from [<c02aed3c>] (usba_ep_dequeue+0x70/0x128)
      [<c02aed3c>] (usba_ep_dequeue) from [<bf010c00>] (hidg_unbind+0x50/0x7c [usb_f_hid])
      [<bf010c00>] (hidg_unbind [usb_f_hid]) from [<bf00159c>] (remove_config.isra.6+0x98/0x9c [libcomposite])
      [<bf00159c>] (remove_config.isra.6 [libcomposite]) from [<bf0031d0>] (__composite_unbind+0x34/0x98 [libcomposite])
      [<bf0031d0>] (__composite_unbind [libcomposite]) from [<c02acee0>] (usb_gadget_remove_driver+0x50/0x78)
      [<c02acee0>] (usb_gadget_remove_driver) from [<c02ad570>] (usb_gadget_unregister_driver+0x64/0x94)
      [<c02ad570>] (usb_gadget_unregister_driver) from [<bf0160c0>] (hidg_cleanup+0x10/0x34 [g_hid])
      [<bf0160c0>] (hidg_cleanup [g_hid]) from [<c0056748>] (SyS_delete_module+0x118/0x19c)
      [<c0056748>] (SyS_delete_module) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
      Code: bad PC value
      Signed-off-by: default avatarSongjun Wu <songjun.wu@atmel.com>
      [nicolas.ferre@atmel.com: reworked the commit message]
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Fixes: 914a3f3b ("USB: add atmel_usba_udc driver")
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      06be755d
    • Bo Shen's avatar
      usb: gadget: udc: atmel: fix possible IN hang issue · 0658cbbe
      Bo Shen authored
      commit 6785a103 upstream.
      
      When receive data, the RXRDY in status register set by hardware
      after a new packet has been stored in the endpoint FIFO. When it
      is copied from FIFO, this bit is cleared which make the FIFO can
      be accessed again.
      
      In the receive_data() function, this bit RXRDY has been cleared.
      So, after the receive_data() function return, this bit should
      not be cleared again, or else it may cause the accessing FIFO
      corrupt, which will make the data loss.
      
      Fixes: 914a3f3b (USB: add atmel_usba_udc driver)
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarBo Shen <voice.shen@atmel.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0658cbbe
    • Bo Shen's avatar
      usb: gadget: udc: atmel: change setting for DMA · 226685fb
      Bo Shen authored
      commit f40afddd upstream.
      
      According to the datasheet, when transfer using DMA, the control
      setting for IN packet only need END_BUF_EN, END_BUF_IE, CH_EN,
      while for OUT packet, need more two bits END_TR_EN and END_TR_IE
      to be configured.
      
      Fixes: 914a3f3b (USB: add atmel_usba_udc driver)
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarBo Shen <voice.shen@atmel.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      226685fb
    • Arseny Solokha's avatar
      OHCI: add a quirk for ULi M5237 blocking on reset · adca2524
      Arseny Solokha authored
      commit 56abcab8 upstream.
      
      Commit 8dccddbc ("OHCI: final fix for NVIDIA problems (I hope)")
      introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
      board. The code path that was previously specific to NVIDIA controllers
      had then become taken for all chips.
      
      However, the M5237 installed on the board wedges solid when accessing
      its base+OHCI_FMINTERVAL register, making it impossible to boot any
      kernel newer than 3.1.8 on this particular and apparently other similar
      machines.
      
      Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.
      
      The patch is suitable for the -next tree as well as all maintained
      kernels up to 3.2 inclusive.
      Signed-off-by: default avatarArseny Solokha <asolokha@kb.kras.ru>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      adca2524
    • Dan Carpenter's avatar
      HID: roccat: potential out of bounds in pyra_sysfs_write_settings() · d70eb262
      Dan Carpenter authored
      commit 606185b2 upstream.
      
      This is a static checker fix.  We write some binary settings to the
      sysfs file.  One of the settings is the "->startup_profile".  There
      isn't any checking to make sure it fits into the
      pyra->profile_settings[] array in the profile_activated() function.
      
      I added a check to pyra_sysfs_write_settings() in both places because
      I wasn't positive that the other callers were correct.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      [bwh: Backported to 3.2: pyra_sysfs_write_settings() doesn't define a
       settings variable, so write the cast-expression inline]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d70eb262
    • Johannes Weiner's avatar
      mm: protect set_page_dirty() from ongoing truncation · 0330c992
      Johannes Weiner authored
      commit 2d6d7f98 upstream.
      
      Tejun, while reviewing the code, spotted the following race condition
      between the dirtying and truncation of a page:
      
      __set_page_dirty_nobuffers()       __delete_from_page_cache()
        if (TestSetPageDirty(page))
                                           page->mapping = NULL
      				     if (PageDirty())
      				       dec_zone_page_state(page, NR_FILE_DIRTY);
      				       dec_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
          if (page->mapping)
            account_page_dirtied(page)
              __inc_zone_page_state(page, NR_FILE_DIRTY);
      	__inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
      
      which results in an imbalance of NR_FILE_DIRTY and BDI_RECLAIMABLE.
      
      Dirtiers usually lock out truncation, either by holding the page lock
      directly, or in case of zap_pte_range(), by pinning the mapcount with
      the page table lock held.  The notable exception to this rule, though,
      is do_wp_page(), for which this race exists.  However, do_wp_page()
      already waits for a locked page to unlock before setting the dirty bit,
      in order to prevent a race where clear_page_dirty() misses the page bit
      in the presence of dirty ptes.  Upgrade that wait to a fully locked
      set_page_dirty() to also cover the situation explained above.
      
      Afterwards, the code in set_page_dirty() dealing with a truncation race
      is no longer needed.  Remove it.
      Reported-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.2:
       - Adjust context
       - Use VM_BUG_ON() rather than VM_BUG_ON_PAGE()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0330c992
    • Miklos Szeredi's avatar
      mm: remove unused arg of set_page_dirty_balance() · 57b31943
      Miklos Szeredi authored
      commit ed6d7c8e upstream.
      
      There's only one caller of set_page_dirty_balance() and that will call it
      with page_mkwrite == 0.
      
      The page_mkwrite argument was unused since commit b827e496 "mm: close
      page_mkwrite races".
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      57b31943
    • Konstantin Khlebnikov's avatar
      mm: prevent endless growth of anon_vma hierarchy · 1d61507c
      Konstantin Khlebnikov authored
      commit 7a3ef208 upstream.
      
      Constantly forking task causes unlimited grow of anon_vma chain.  Each
      next child allocates new level of anon_vmas and links vma to all
      previous levels because pages might be inherited from any level.
      
      This patch adds heuristic which decides to reuse existing anon_vma
      instead of forking new one.  It adds counter anon_vma->degree which
      counts linked vmas and directly descending anon_vmas and reuses anon_vma
      if counter is lower than two.  As a result each anon_vma has either vma
      or at least two descending anon_vmas.  In such trees half of nodes are
      leafs with alive vmas, thus count of anon_vmas is no more than two times
      bigger than count of vmas.
      
      This heuristic reuses anon_vmas as few as possible because each reuse
      adds false aliasing among vmas and rmap walker ought to scan more ptes
      when it searches where page is might be mapped.
      
      Link: http://lkml.kernel.org/r/20120816024610.GA5350@evergreen.ssec.wisc.edu
      Fixes: 5beb4930 ("mm: change anon_vma linking to fix multi-process server scalability issue")
      [akpm@linux-foundation.org: fix typo, per Rik]
      Signed-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Reported-by: default avatarDaniel Forrest <dan.forrest@ssec.wisc.edu>
      Tested-by: default avatarMichal Hocko <mhocko@suse.cz>
      Tested-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      Reviewed-by: default avatarRik van Riel <riel@redhat.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.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1d61507c
    • Dmitry Torokhov's avatar
      Input: I8042 - add Acer Aspire 7738 to the nomux list · c5b96ce4
      Dmitry Torokhov authored
      commit 9333caea upstream.
      
      When KBC is in active multiplexing mode the touchpad on this laptop does
      not work.
      Reported-by: default avatarBilal Koc <koc.bilo@googlemail.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c5b96ce4
    • Ashay Jaiswal's avatar
      regulator: core: fix race condition in regulator_put() · 3a8a47c5
      Ashay Jaiswal authored
      commit 83b0302d upstream.
      
      The regulator framework maintains a list of consumer regulators
      for a regulator device and protects it from concurrent access using
      the regulator device's mutex lock.
      
      In the case of regulator_put() the consumer is removed and regulator
      device's parameters are updated without holding the regulator device's
      mutex. This would lead to a race condition between the regulator_put()
      and any function which traverses the consumer list or modifies regulator
      device's parameters.
      Fix this race condition by holding the regulator device's mutex in case
      of regulator_put.
      Signed-off-by: default avatarAshay Jaiswal <ashayj@codeaurora.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      [bwh: Backported to 3.2:
       - Adjust context
       - Don't touch the comment; __regulator_put() has not been split out of
         regulator_put() here]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3a8a47c5
    • Srihari Vijayaraghavan's avatar
      Input: i8042 - reset keyboard to fix Elantech touchpad detection · 1c5b4c2b
      Srihari Vijayaraghavan authored
      commit 148e9a71 upstream.
      
      On some laptops, keyboard needs to be reset in order to successfully detect
      touchpad (e.g., some Gigabyte laptop models with Elantech touchpads).
      Without resettin keyboard touchpad pretends to be completely dead.
      
      Based on the original patch by Mateusz Jończyk this version has been
      expanded to include DMI based detection & application of the fix
      automatically on the affected models of laptops. This has been confirmed to
      fix problem by three users already on three different models of laptops.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81331Signed-off-by: default avatarSrihari Vijayaraghavan <linux.bug.reporting@gmail.com>
      Acked-by: default avatarMateusz Jończyk <mat.jonczyk@o2.pl>
      Tested-by: default avatarSrihari Vijayaraghavan <linux.bug.reporting@gmail.com>
      Tested by: Zakariya Dehlawi <zdehlawi@gmail.com>
      Tested-by: default avatarGuillaum Bouchard <guillaum.bouchard@gmail.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1c5b4c2b
    • Sasha Levin's avatar
      time: settimeofday: Validate the values of tv from user · 1751fde0
      Sasha Levin authored
      commit 6ada1fc0 upstream.
      
      An unvalidated user input is multiplied by a constant, which can result in
      an undefined behaviour for large values. While this is validated later,
      we should avoid triggering undefined behaviour.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      [jstultz: include trivial milisecond->microsecond correction noticed
      by Andy]
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1751fde0
    • Andy Shevchenko's avatar
      sata_dwc_460ex: fix resource leak on error path · ee368a2c
      Andy Shevchenko authored
      commit 4aaa7187 upstream.
      
      DMA mapped IO should be unmapped on the error path in probe() and
      unconditionally on remove().
      
      Fixes: 62936009 ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ee368a2c
    • Linus Torvalds's avatar
      mm: propagate error from stack expansion even for guard page · 78eaa11a
      Linus Torvalds authored
      commit fee7e49d upstream.
      
      Jay Foad reports that the address sanitizer test (asan) sometimes gets
      confused by a stack pointer that ends up being outside the stack vma
      that is reported by /proc/maps.
      
      This happens due to an interaction between RLIMIT_STACK and the guard
      page: when we do the guard page check, we ignore the potential error
      from the stack expansion, which effectively results in a missing guard
      page, since the expected stack expansion won't have been done.
      
      And since /proc/maps explicitly ignores the guard page (commit
      d7824370: "mm: fix up some user-visible effects of the stack guard
      page"), the stack pointer ends up being outside the reported stack area.
      
      This is the minimal patch: it just propagates the error.  It also
      effectively makes the guard page part of the stack limit, which in turn
      measn that the actual real stack is one page less than the stack limit.
      
      Let's see if anybody notices.  We could teach acct_stack_growth() to
      allow an extra page for a grow-up/grow-down stack in the rlimit test,
      but I don't want to add more complexity if it isn't needed.
      Reported-and-tested-by: default avatarJay Foad <jay.foad@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      78eaa11a
    • Zidan Wang's avatar
      ASoC: wm8960: Fix capture sample rate from 11250 to 11025 · eba80b2f
      Zidan Wang authored
      commit 22ee76da upstream.
      
      wm8960 codec can't support sample rate 11250, it must be 11025.
      Signed-off-by: default avatarZidan Wang <b50113@freescale.com>
      Acked-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      eba80b2f
    • David Peterson's avatar
      USB: cp210x: add IDs for CEL USB sticks and MeshWorks devices · ee87640c
      David Peterson authored
      commit 1ae78a48 upstream.
      
      Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks
      devices.
      Signed-off-by: default avatarDavid Peterson <david.peterson@cel.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ee87640c
    • Michael S. Tsirkin's avatar
      virtio_pci: document why we defer kfree · c578662e
      Michael S. Tsirkin authored
      commit a1eb03f5 upstream.
      
      The reason we defer kfree until release function is because it's a
      general rule for kobjects: kfree of the reference counter itself is only
      legal in the release function.
      
      Previous patch didn't make this clear, document this in code.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c578662e
    • Sasha Levin's avatar
      virtio_pci: defer kfree until release callback · 119d5897
      Sasha Levin authored
      commit 63bd62a0 upstream.
      
      A struct device which has just been unregistered can live on past the
      point at which a driver decides to drop it's initial reference to the
      kobject gained on allocation.
      
      This implies that when releasing a virtio device, we can't free a struct
      virtio_device until the underlying struct device has been released,
      which might not happen immediately on device_unregister().
      
      Unfortunately, this is exactly what virtio pci does:
      it has an empty release callback, and frees memory immediately
      after unregistering the device.
      
      This causes an easy to reproduce crash if CONFIG_DEBUG_KOBJECT_RELEASE
      it enabled.
      
      To fix, free the memory only once we know the device is gone in the release
      callback.
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      119d5897
    • Wanlong Gao's avatar
      virtio: use dev_to_virtio wrapper in virtio · ddabe0f7
      Wanlong Gao authored
      commit 9bffdca8 upstream.
      
      Use dev_to_virtio wrapper in virtio to make code clearly.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Signed-off-by: default avatarWanlong Gao <gaowanlong@cn.fujitsu.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ddabe0f7
    • Andy Shevchenko's avatar
      spi: dw-mid: fix FIFO size · 48bcfa6c
      Andy Shevchenko authored
      commit 67bf9cda upstream.
      
      The FIFO size is 40 accordingly to the specifications, but this means 0x40,
      i.e. 64 bytes. This patch fixes the typo and enables FIFO size autodetection
      for Intel MID devices.
      
      Fixes: 7063c0d9 (spi/dw_spi: add DMA support)
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      48bcfa6c
    • Axel Lin's avatar
      spi: dw: Fix detecting FIFO depth · 250dbefd
      Axel Lin authored
      commit d297933c upstream.
      
      Current code tries to find the highest valid fifo depth by checking the value
      it wrote to DW_SPI_TXFLTR. There are a few problems in current code:
      1) There is an off-by-one in dws->fifo_len setting because it assumes the latest
         register write fails so the latest valid value should be fifo - 1.
      2) We know the depth could be from 2 to 256 from HW spec, so it is not necessary
         to test fifo == 257. In the case fifo is 257, it means the latest valid
         setting is fifo = 256. So after the for loop iteration, we should check
         fifo == 2 case instead of fifo == 257 if detecting the FIFO depth fails.
      This patch fixes above issues.
      Signed-off-by: default avatarAxel Lin <axel.lin@ingics.com>
      Reviewed-and-tested-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      250dbefd
    • Takashi Iwai's avatar
      ALSA: hda - Fix wrong gpio_dir & gpio_mask hint setups for IDT/STAC codecs · 4c30f3c9
      Takashi Iwai authored
      commit c507de88 upstream.
      
      stac_store_hints() does utterly wrong for masking the values for
      gpio_dir and gpio_data, likely due to copy&paste errors.  Fortunately,
      this feature is used very rarely, so the impact must be really small.
      Reported-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4c30f3c9
    • Ben Hutchings's avatar
      Revert "tcp: Apply device TSO segment limit earlier" · 64991747
      Ben Hutchings authored
      This reverts commit 9f871e88, which
      was commit 1485348d upstream.
      
      It can cause connections to stall when a PMTU event occurs.  This was
      fixed by commit 843925f3 ("tcp: Do not apply TSO segment limit to
      non-TSO packets") upstream, but that depends on other changes to TSO.
      
      The original issue this fixed was a performance regression for the sfc
      driver in extreme cases of TSO (skb with > 100 segments).  This is not
      really very important and it seems best to revert it rather than try
      to fix it up.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: netdev@vger.kernel.org
      Cc: linux-net-drivers@solarflare.com
      64991747
    • Preston Fick's avatar
      USB: cp210x: fix ID for production CEL MeshConnect USB Stick · 9fefe0d3
      Preston Fick authored
      commit 90441b4d upstream.
      
      Fixing typo for MeshConnect IDs. The original PID (0x8875) is not in
      production and is not needed. Instead it has been changed to the
      official production PID (0x8857).
      Signed-off-by: default avatarPreston Fick <pffick@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9fefe0d3