1. 20 Feb, 2015 40 commits
    • Andy Lutomirski's avatar
      x86, tls, ldt: Stop checking lm in LDT_empty · f62570cb
      Andy Lutomirski authored
      commit e30ab185 upstream.
      
      32-bit programs don't have an lm bit in their ABI, so they can't
      reliably cause LDT_empty to return true without resorting to memset.
      They shouldn't need to do this.
      
      This should fix a longstanding, if minor, issue in all 64-bit kernels
      as well as a potential regression in the TLS hardening code.
      
      Fixes: 41bdc785 x86/tls: Validate TLS entries to protect espfix
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: torvalds@linux-foundation.org
      Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.netSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f62570cb
    • K. Y. Srinivasan's avatar
      x86, hyperv: Mark the Hyper-V clocksource as being continuous · cea62dbd
      K. Y. Srinivasan authored
      commit 32c6590d upstream.
      
      The Hyper-V clocksource is continuous; mark it accordingly.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Acked-by: jasowang@redhat.com
      Cc: gregkh@linuxfoundation.org
      Cc: devel@linuxdriverproject.org
      Cc: olaf@aepfle.de
      Cc: apw@canonical.com
      Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cea62dbd
    • David Jeffery's avatar
      libata: prevent HSM state change race between ISR and PIO · a06e5037
      David Jeffery authored
      commit ce751452 upstream.
      
      It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to
      HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE
      and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().
      
      This problem is hard to reproduce making this patch hard to verify, but this
      fix will prevent the race.
      
      I have not been able to reproduce the problem, but here is a crash dump from
      a 2.6.32 kernel.
      
      On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE:
      
      crash> struct ata_port.hsm_task_state ffff881c1121c000
        hsm_task_state = 0
      
      Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(),
      which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value.
      
      PID: 11053  TASK: ffff8816e846cae0  CPU: 0   COMMAND: "sshd"
       #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b
       #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92
       #2 [ffff88008ba03a90] oops_end at ffffffff8152b510
       #3 [ffff88008ba03ac0] die at ffffffff81010e0b
       #4 [ffff88008ba03af0] do_trap at ffffffff8152ad74
       #5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95
       #6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b
          [exception RIP: ata_sff_hsm_move+317]
          RIP: ffffffff813a77ad  RSP: ffff88008ba03ca0  RFLAGS: 00010097
          RAX: 0000000000000000  RBX: ffff881c1121dc60  RCX: 0000000000000000
          RDX: ffff881c1121dd10  RSI: ffff881c1121dc60  RDI: ffff881c1121c000
          RBP: ffff88008ba03d00   R8: 0000000000000000   R9: 000000000000002e
          R10: 000000000001003f  R11: 000000000000009b  R12: ffff881c1121c000
          R13: 0000000000000000  R14: 0000000000000050  R15: ffff881c1121dd78
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd
       #8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e
       #9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0
      >--- <IRQ stack> ---
          [exception RIP: pipe_poll+48]
          RIP: ffffffff81192780  RSP: ffff880f26d459b8  RFLAGS: 00000246
          RAX: 0000000000000000  RBX: ffff880f26d459c8  RCX: 0000000000000000
          RDX: 0000000000000001  RSI: 0000000000000000  RDI: ffff881a0539fa80
          RBP: ffffffff8100bb8e   R8: ffff8803b23324a0   R9: 0000000000000000
          R10: ffff880f26d45dd0  R11: 0000000000000008  R12: ffffffff8109b646
          R13: ffff880f26d45948  R14: 0000000000000246  R15: 0000000000000246
          ORIG_RAX: ffffffffffffff10  CS: 0010  SS: 0018
          RIP: 00007f26017435c3  RSP: 00007fffe020c420  RFLAGS: 00000206
          RAX: 0000000000000017  RBX: ffffffff8100b072  RCX: 00007fffe020c45c
          RDX: 00007f2604a3f120  RSI: 00007f2604a3f140  RDI: 000000000000000d
          RBP: 0000000000000000   R8: 00007fffe020e570   R9: 0101010101010101
          R10: 0000000000000000  R11: 0000000000000246  R12: 00007fffe020e5f0
          R13: 00007fffe020e5f4  R14: 00007f26045f373c  R15: 00007fffe020e5e0
          ORIG_RAX: 0000000000000017  CS: 0033  SS: 002b
      
      Somewhere between the ata_sff_hsm_move() check and the ata_sff_host_intr() check, the value changed.
      On examining the other cpus to see what else was running, another cpu was running the error handler
      routines:
      
      PID: 326    TASK: ffff881c11014aa0  CPU: 1   COMMAND: "scsi_eh_1"
       #0 [ffff88008ba27e90] crash_nmi_callback at ffffffff8102fee6
       #1 [ffff88008ba27ea0] notifier_call_chain at ffffffff8152d515
       #2 [ffff88008ba27ee0] atomic_notifier_call_chain at ffffffff8152d57a
       #3 [ffff88008ba27ef0] notify_die at ffffffff810a154e
       #4 [ffff88008ba27f20] do_nmi at ffffffff8152b1db
       #5 [ffff88008ba27f50] nmi at ffffffff8152aaa0
          [exception RIP: _spin_lock_irqsave+47]
          RIP: ffffffff8152a1ff  RSP: ffff881c11a73aa0  RFLAGS: 00000006
          RAX: 0000000000000001  RBX: ffff881c1121deb8  RCX: 0000000000000000
          RDX: 0000000000000246  RSI: 0000000000000020  RDI: ffff881c122612d8
          RBP: ffff881c11a73aa0   R8: ffff881c17083800   R9: 0000000000000000
          R10: 0000000000000000  R11: 0000000000000000  R12: ffff881c1121c000
          R13: 000000000000001f  R14: ffff881c1121dd50  R15: ffff881c1121dc60
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0000
      >--- <NMI exception stack> ---
       #6 [ffff881c11a73aa0] _spin_lock_irqsave at ffffffff8152a1ff
       #7 [ffff881c11a73aa8] ata_exec_internal_sg at ffffffff81396fb5
       #8 [ffff881c11a73b58] ata_exec_internal at ffffffff81397109
       #9 [ffff881c11a73bd8] atapi_eh_request_sense at ffffffff813a34eb
      
      Before it tried to acquire a spinlock, ata_exec_internal_sg() called ata_sff_flush_pio_task().
      This function will set ap->hsm_task_state to HSM_ST_IDLE, and has no locking around setting this
      value. ata_sff_flush_pio_task() can then race with the interrupt handler and potentially set
      HSM_ST_IDLE at a fatal moment, which will trigger a kernel BUG.
      
      v2: Fixup comment in ata_sff_flush_pio_task()
      
      tj: Further updated comment.  Use ap->lock instead of shost lock and
          use the [un]lock_irq variant instead of the irqsave/restore one.
      Signed-off-by: default avatarDavid Milburn <dmilburn@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a06e5037
    • Michael Karcher's avatar
      scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore · b31512a1
      Michael Karcher authored
      commit 1caf6aaa upstream.
      
      Compiling SH with gcc-4.8 fails due to the -m32 option not being
      supported.
      
      From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783
      
            CC      init/main.o
          gcc-4.8: error: unrecognized command line option '-m32'
          ld: cannot find init/.tmp_mc_main.o: No such file or directory
          objcopy: 'init/.tmp_mx_main.o': No such file
          rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory
          rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory
      
      Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de
      Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de
      
      Cc: Matt Fleming <matt@console-pimps.org>
      Reported-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Signed-off-by: default avatarMichael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b31512a1
    • Dan Williams's avatar
      libata: allow sata_sil24 to opt-out of tag ordered submission · 4396fd99
      Dan Williams authored
      commit 72dd299d upstream.
      
      Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101
          "Since commit 8a4aeec8 "libata/ahci: accommodate tag ordered
          controllers" the access to the harddisk on the first SATA-port is
          failing on its first access. The access to the harddisk on the
          second port is working normal.
      
          When reverting the above commit, access to both harddisks is working
          fine again."
      
      Maintain tag ordered submission as the default, but allow sata_sil24 to
      continue with the old behavior.
      
      Cc: Tejun Heo <tj@kernel.org>
      Reported-by: default avatarRonny Hegewald <Ronny.Hegewald@online.de>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4396fd99
    • Jason Lee Cragg's avatar
      370a4f54
    • Daniel Borkmann's avatar
      net: sctp: fix race for one-to-many sockets in sendmsg's auto associate · 560473dd
      Daniel Borkmann authored
      commit 2061dcd6 upstream.
      
      I.e. one-to-many sockets in SCTP are not required to explicitly
      call into connect(2) or sctp_connectx(2) prior to data exchange.
      Instead, they can directly invoke sendmsg(2) and the SCTP stack
      will automatically trigger connection establishment through 4WHS
      via sctp_primitive_ASSOCIATE(). However, this in its current
      implementation is racy: INIT is being sent out immediately (as
      it cannot be bundled anyway) and the rest of the DATA chunks are
      queued up for later xmit when connection is established, meaning
      sendmsg(2) will return successfully. This behaviour can result
      in an undesired side-effect that the kernel made the application
      think the data has already been transmitted, although none of it
      has actually left the machine, worst case even after close(2)'ing
      the socket.
      
      Instead, when the association from client side has been shut down
      e.g. first gracefully through SCTP_EOF and then close(2), the
      client could afterwards still receive the server's INIT_ACK due
      to a connection with higher latency. This INIT_ACK is then considered
      out of the blue and hence responded with ABORT as there was no
      alive assoc found anymore. This can be easily reproduced f.e.
      with sctp_test application from lksctp. One way to fix this race
      is to wait for the handshake to actually complete.
      
      The fix defers waiting after sctp_primitive_ASSOCIATE() and
      sctp_primitive_SEND() succeeded, so that DATA chunks cooked up
      from sctp_sendmsg() have already been placed into the output
      queue through the side-effect interpreter, and therefore can then
      be bundeled together with COOKIE_ECHO control chunks.
      
      strace from example application (shortened):
      
      socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) = 3
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(0)=[], msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */, cmsg_type=, ...},
                 msg_flags=0}, 0) = 0 // graceful shutdown for SOCK_SEQPACKET via SCTP_EOF
      close(3) = 0
      
      tcpdump before patch (fooling the application):
      
      22:33:36.306142 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 3879023686] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3139201684]
      22:33:36.316619 IP 192.168.1.115.8888 > 192.168.1.114.41462: sctp (1) [INIT ACK] [init tag: 3345394793] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 3380109591]
      22:33:36.317600 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [ABORT]
      
      tcpdump after patch:
      
      14:28:58.884116 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 438593213] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3092969729]
      14:28:58.888414 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [INIT ACK] [init tag: 381429855] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 2141904492]
      14:28:58.888638 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [COOKIE ECHO] , (2) [DATA] (B)(E) [TSN: 3092969729] [...]
      14:28:58.893278 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 3092969729] [a_rwnd 106491] [#gap acks 0] [#dup tsns 0]
      14:28:58.893591 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969730] [...]
      14:28:59.096963 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969730] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0]
      14:28:59.097086 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969731] [...] , (2) [DATA] (B)(E) [TSN: 3092969732] [...]
      14:28:59.103218 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969732] [a_rwnd 106486] [#gap acks 0] [#dup tsns 0]
      14:28:59.103330 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN]
      14:28:59.107793 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SHUTDOWN ACK]
      14:28:59.107890 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN COMPLETE]
      
      Looks like this bug is from the pre-git history museum. ;)
      
      Fixes: 08707d54 ("lksctp-2_5_31-0_5_1.patch")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      560473dd
    • 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