1. 27 Aug, 2015 40 commits
    • Nikolay Borisov's avatar
      ext4: avoid deadlocks in the writeback path by using sb_getblk_gfp · a2fd4ed8
      Nikolay Borisov authored
      commit c45653c3 upstream.
      
      Switch ext4 to using sb_getblk_gfp with GFP_NOFS added to fix possible
      deadlocks in the page writeback path.
      Signed-off-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a2fd4ed8
    • Nikolay Borisov's avatar
      bufferhead: Add _gfp version for sb_getblk() · cb1e4748
      Nikolay Borisov authored
      commit bd7ade3c upstream.
      
      sb_getblk() is used during ext4 (and possibly other FSes) writeback
      paths. Sometimes such path require allocating memory and guaranteeing
      that such allocation won't block. Currently, however, there is no way
      to provide user flags for sb_getblk which could lead to deadlocks.
      
      This patch implements a sb_getblk_gfp with the only difference it can
      accept user-provided GFP flags.
      Signed-off-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cb1e4748
    • Gioh Kim's avatar
      fs/buffer.c: support buffer cache allocations with gfp modifiers · a68299ad
      Gioh Kim authored
      commit 3b5e6454 upstream.
      
      A buffer cache is allocated from movable area because it is referred
      for a while and released soon.  But some filesystems are taking buffer
      cache for a long time and it can disturb page migration.
      
      New APIs are introduced to allocate buffer cache with user specific
      flag.  *_gfp APIs are for user want to set page allocation flag for
      page cache allocation.  And *_unmovable APIs are for the user wants to
      allocate page cache from non-movable area.
      Signed-off-by: default avatarGioh Kim <gioh.kim@lge.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      [ luis: 3.16 prereq for:
        bd7ade3c "bufferhead: Add _gfp version for sb_getblk()" ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a68299ad
    • Christoph Hellwig's avatar
      megaraid_sas: use raw_smp_processor_id() · 9eb4ac21
      Christoph Hellwig authored
      commit 16b8528d upstream.
      
      We only want to steer the I/O completion towards a queue, but don't
      actually access any per-CPU data, so the raw_ version is fine to use
      and avoids the warnings when using smp_processor_id().
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reported-by: default avatarAndy Lutomirski <luto@kernel.org>
      Tested-by: default avatarAndy Lutomirski <luto@kernel.org>
      Acked-by: default avatarSumit Saxena <sumit.saxena@avagotech.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      [ luis: backported to 3.16:
        - dropped changes to megasas_build_dcdb_fusion() ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9eb4ac21
    • Chad Dupuis's avatar
      qla2xxx: Mark port lost when we receive an RSCN for it. · 06fc8830
      Chad Dupuis authored
      commit ef86cb20 upstream.
      Signed-off-by: default avatarChad Dupuis <chad.dupuis@qlogic.com>
      Signed-off-by: default avatarSaurav Kashyap <saurav.kashyap@qlogic.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      06fc8830
    • Linus Torvalds's avatar
      Fix firmware loader uevent buffer NULL pointer dereference · 13552197
      Linus Torvalds authored
      commit 6f957724 upstream.
      
      The firmware class uevent function accessed the "fw_priv->buf" buffer
      without the proper locking and testing for NULL.  This is an old bug
      (looks like it goes back to 2012 and commit 1244691c: "firmware
      loader: introduce firmware_buf"), but for some reason it's triggering
      only now in 4.2-rc1.
      
      Shuah Khan is trying to bisect what it is that causes this to trigger
      more easily, but in the meantime let's just fix the bug since others are
      hitting it too (at least Ingo reports having seen it as well).
      Reported-and-tested-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Acked-by: default avatarMing Lei <ming.lei@canonical.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      13552197
    • Florian Westphal's avatar
      net: gso: use feature flag argument in all protocol gso handlers · 7685e48d
      Florian Westphal authored
      commit 1e16aa3d upstream.
      
      skb_gso_segment() has a 'features' argument representing offload features
      available to the output path.
      
      A few handlers, e.g. GRE, instead re-fetch the features of skb->dev and use
      those instead of the provided ones when handing encapsulation/tunnels.
      
      Depending on dev->hw_enc_features of the output device skb_gso_segment() can
      then return NULL even when the caller has disabled all GSO feature bits,
      as segmentation of inner header thinks device will take care of segmentation.
      
      This e.g. affects the tbf scheduler, which will silently drop GRE-encap GSO skbs
      that did not fit the remaining token quota as the segmentation does not work
      when device supports corresponding hw offload capabilities.
      
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: used davem's backport to 3.14 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7685e48d
    • Ivan Vecera's avatar
      bna: fix interrupts storm caused by erroneous packets · e95b4bd0
      Ivan Vecera authored
      commit ade4dc3e upstream.
      
      The commit "e29aa339 bna: Enable Multi Buffer RX" moved packets counter
      increment from the beginning of the NAPI processing loop after the check
      for erroneous packets so they are never accounted. This counter is used
      to inform firmware about number of processed completions (packets).
      As these packets are never acked the firmware fires IRQs for them again
      and again.
      
      Fixes: e29aa339 ("bna: Enable Multi Buffer RX")
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Acked-by: default avatarRasesh Mody <rasesh.mody@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e95b4bd0
    • Eric Dumazet's avatar
      udp: fix dst races with multicast early demux · fd6a8a15
      Eric Dumazet authored
      commit 10e2eb87 upstream.
      
      Multicast dst are not cached. They carry DST_NOCACHE.
      
      As mentioned in commit f8864972 ("ipv4: fix dst race in
      sk_dst_get()"), these dst need special care before caching them
      into a socket.
      
      Caching them is allowed only if their refcnt was not 0, ie we
      must use atomic_inc_not_zero()
      
      Also, we must use READ_ONCE() to fetch sk->sk_rx_dst, as mentioned
      in commit d0c294c5 ("tcp: prevent fetching dst twice in early demux
      code")
      
      Fixes: 421b3885 ("udp: ipv4: Add udp early demux")
      Tested-by: default avatarGregory Hoggarth <Gregory.Hoggarth@alliedtelesis.co.nz>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarGregory Hoggarth <Gregory.Hoggarth@alliedtelesis.co.nz>
      Reported-by: default avatarAlex Gartrell <agartrell@fb.com>
      Cc: Michal Kubeček <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: used davem's backport to 3.14 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fd6a8a15
    • Dan Carpenter's avatar
      rds: fix an integer overflow test in rds_info_getsockopt() · a7fc16ef
      Dan Carpenter authored
      commit 468b732b upstream.
      
      "len" is a signed integer.  We check that len is not negative, so it
      goes from zero to INT_MAX.  PAGE_SIZE is unsigned long so the comparison
      is type promoted to unsigned long.  ULONG_MAX - 4095 is a higher than
      INT_MAX so the condition can never be true.
      
      I don't know if this is harmful but it seems safe to limit "len" to
      INT_MAX - 4095.
      
      Fixes: a8c879a7 ('RDS: Info and stats')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a7fc16ef
    • Florian Westphal's avatar
      netlink: don't hold mutex in rcu callback when releasing mmapd ring · d92e2723
      Florian Westphal authored
      commit 0470eb99 upstream.
      
      Kirill A. Shutemov says:
      
      This simple test-case trigers few locking asserts in kernel:
      
      int main(int argc, char **argv)
      {
              unsigned int block_size = 16 * 4096;
              struct nl_mmap_req req = {
                      .nm_block_size          = block_size,
                      .nm_block_nr            = 64,
                      .nm_frame_size          = 16384,
                      .nm_frame_nr            = 64 * block_size / 16384,
              };
              unsigned int ring_size;
      	int fd;
      
      	fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
              if (setsockopt(fd, SOL_NETLINK, NETLINK_RX_RING, &req, sizeof(req)) < 0)
                      exit(1);
              if (setsockopt(fd, SOL_NETLINK, NETLINK_TX_RING, &req, sizeof(req)) < 0)
                      exit(1);
      
      	ring_size = req.nm_block_nr * req.nm_block_size;
      	mmap(NULL, 2 * ring_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
      	return 0;
      }
      
      +++ exited with 0 +++
      BUG: sleeping function called from invalid context at /home/kas/git/public/linux-mm/kernel/locking/mutex.c:616
      in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
      3 locks held by init/1:
       #0:  (reboot_mutex){+.+...}, at: [<ffffffff81080959>] SyS_reboot+0xa9/0x220
       #1:  ((reboot_notifier_list).rwsem){.+.+..}, at: [<ffffffff8107f379>] __blocking_notifier_call_chain+0x39/0x70
       #2:  (rcu_callback){......}, at: [<ffffffff810d32e0>] rcu_do_batch.isra.49+0x160/0x10c0
      Preemption disabled at:[<ffffffff8145365f>] __delay+0xf/0x20
      
      CPU: 1 PID: 1 Comm: init Not tainted 4.1.0-00009-gbddf4c4818e0 #253
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Debian-1.8.2-1 04/01/2014
       ffff88017b3d8000 ffff88027bc03c38 ffffffff81929ceb 0000000000000102
       0000000000000000 ffff88027bc03c68 ffffffff81085a9d 0000000000000002
       ffffffff81ca2a20 0000000000000268 0000000000000000 ffff88027bc03c98
      Call Trace:
       <IRQ>  [<ffffffff81929ceb>] dump_stack+0x4f/0x7b
       [<ffffffff81085a9d>] ___might_sleep+0x16d/0x270
       [<ffffffff81085bed>] __might_sleep+0x4d/0x90
       [<ffffffff8192e96f>] mutex_lock_nested+0x2f/0x430
       [<ffffffff81932fed>] ? _raw_spin_unlock_irqrestore+0x5d/0x80
       [<ffffffff81464143>] ? __this_cpu_preempt_check+0x13/0x20
       [<ffffffff8182fc3d>] netlink_set_ring+0x1ed/0x350
       [<ffffffff8182e000>] ? netlink_undo_bind+0x70/0x70
       [<ffffffff8182fe20>] netlink_sock_destruct+0x80/0x150
       [<ffffffff817e484d>] __sk_free+0x1d/0x160
       [<ffffffff817e49a9>] sk_free+0x19/0x20
      [..]
      
      Cong Wang says:
      
      We can't hold mutex lock in a rcu callback, [..]
      
      Thomas Graf says:
      
      The socket should be dead at this point. It might be simpler to
      add a netlink_release_ring() function which doesn't require
      locking at all.
      Reported-by: default avatar"Kirill A. Shutemov" <kirill@shutemov.name>
      Diagnosed-by: default avatarCong Wang <cwang@twopensource.com>
      Suggested-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d92e2723
    • dingtianhong's avatar
      bonding: correct the MAC address for "follow" fail_over_mac policy · 268b4001
      dingtianhong authored
      commit a951bc1e upstream.
      
      The "follow" fail_over_mac policy is useful for multiport devices that
      either become confused or incur a performance penalty when multiple
      ports are programmed with the same MAC address, but the same MAC
      address still may happened by this steps for this policy:
      
      1) echo +eth0 > /sys/class/net/bond0/bonding/slaves
         bond0 has the same mac address with eth0, it is MAC1.
      
      2) echo +eth1 > /sys/class/net/bond0/bonding/slaves
         eth1 is backup, eth1 has MAC2.
      
      3) ifconfig eth0 down
         eth1 became active slave, bond will swap MAC for eth0 and eth1,
         so eth1 has MAC1, and eth0 has MAC2.
      
      4) ifconfig eth1 down
         there is no active slave, and eth1 still has MAC1, eth2 has MAC2.
      
      5) ifconfig eth0 up
         the eth0 became active slave again, the bond set eth0 to MAC1.
      
      Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same
      MAC address, it will break this policy for ACTIVE_BACKUP mode.
      
      This patch will fix this problem by finding the old active slave and
      swap them MAC address before change active slave.
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Tested-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: used davem's backport to 3.14 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      268b4001
    • Eric Dumazet's avatar
      ipv6: lock socket in ip6_datagram_connect() · f3106f51
      Eric Dumazet authored
      commit 03645a11 upstream.
      
      ip6_datagram_connect() is doing a lot of socket changes without
      socket being locked.
      
      This looks wrong, at least for udp_lib_rehash() which could corrupt
      lists because of concurrent udp_sk(sk)->udp_portaddr_hash accesses.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f3106f51
    • Herbert Xu's avatar
      net: Fix skb_set_peeked use-after-free bug · 22c2093a
      Herbert Xu authored
      commit a0a2a660 upstream.
      
      The commit 738ac1eb ("net: Clone
      skb before setting peeked flag") introduced a use-after-free bug
      in skb_recv_datagram.  This is because skb_set_peeked may create
      a new skb and free the existing one.  As it stands the caller will
      continue to use the old freed skb.
      
      This patch fixes it by making skb_set_peeked return the new skb
      (or the old one if unchanged).
      
      Fixes: 738ac1eb ("net: Clone skb before setting peeked flag")
      Reported-by: default avatarBrenden Blanco <bblanco@plumgrid.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarBrenden Blanco <bblanco@plumgrid.com>
      Reviewed-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      22c2093a
    • Herbert Xu's avatar
      net: Fix skb csum races when peeking · bd0900e5
      Herbert Xu authored
      commit 89c22d8c upstream.
      
      When we calculate the checksum on the recv path, we store the
      result in the skb as an optimisation in case we need the checksum
      again down the line.
      
      This is in fact bogus for the MSG_PEEK case as this is done without
      any locking.  So multiple threads can peek and then store the result
      to the same skb, potentially resulting in bogus skb states.
      
      This patch fixes this by only storing the result if the skb is not
      shared.  This preserves the optimisations for the few cases where
      it can be done safely due to locking or other reasons, e.g., SIOCINQ.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bd0900e5
    • Herbert Xu's avatar
      net: Clone skb before setting peeked flag · a3989452
      Herbert Xu authored
      commit 738ac1eb upstream.
      
      Shared skbs must not be modified and this is crucial for broadcast
      and/or multicast paths where we use it as an optimisation to avoid
      unnecessary cloning.
      
      The function skb_recv_datagram breaks this rule by setting peeked
      without cloning the skb first.  This causes funky races which leads
      to double-free.
      
      This patch fixes this by cloning the skb and replacing the skb
      in the list when setting skb->peeked.
      
      Fixes: a59322be ("[UDP]: Only increment counter on first peek/recv")
      Reported-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a3989452
    • Julian Anastasov's avatar
      net: call rcu_read_lock early in process_backlog · 3121822f
      Julian Anastasov authored
      commit 2c17d27c upstream.
      
      Incoming packet should be either in backlog queue or
      in RCU read-side section. Otherwise, the final sequence of
      flush_backlog() and synchronize_net() may miss packets
      that can run without device reference:
      
      CPU 1                  CPU 2
                             skb->dev: no reference
                             process_backlog:__skb_dequeue
                             process_backlog:local_irq_enable
      
      on_each_cpu for
      flush_backlog =>       IPI(hardirq): flush_backlog
                             - packet not found in backlog
      
                             CPU delayed ...
      synchronize_net
      - no ongoing RCU
      read-side sections
      
      netdev_run_todo,
      rcu_barrier: no
      ongoing callbacks
                             __netif_receive_skb_core:rcu_read_lock
                             - too late
      free dev
                             process packet for freed dev
      
      Fixes: 6e583ce5 ("net: eliminate refcounting in backlog queue")
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: used davem's backport to 3.18 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3121822f
    • Oleg Nesterov's avatar
      net: pktgen: fix race between pktgen_thread_worker() and kthread_stop() · f99d8ce5
      Oleg Nesterov authored
      commit fecdf8be upstream.
      
      pktgen_thread_worker() is obviously racy, kthread_stop() can come
      between the kthread_should_stop() check and set_current_state().
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Reported-by: default avatarMarcelo Leitner <mleitner@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f99d8ce5
    • Stephen Smalley's avatar
      net/tipc: initialize security state for new connection socket · 400f1f4f
      Stephen Smalley authored
      commit fdd75ea8 upstream.
      
      Calling connect() with an AF_TIPC socket would trigger a series
      of error messages from SELinux along the lines of:
      SELinux: Invalid class 0
      type=AVC msg=audit(1434126658.487:34500): avc:  denied  { <unprintable> }
        for pid=292 comm="kworker/u16:5" scontext=system_u:system_r:kernel_t:s0
        tcontext=system_u:object_r:unlabeled_t:s0 tclass=<unprintable>
        permissive=0
      
      This was due to a failure to initialize the security state of the new
      connection sock by the tipc code, leaving it with junk in the security
      class field and an unlabeled secid.  Add a call to security_sk_clone()
      to inherit the security state from the parent socket.
      Reported-by: default avatarTim Shearer <tim.shearer@overturenetworks.com>
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: default avatarPaul Moore <paul@paul-moore.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      400f1f4f
    • Daniel Borkmann's avatar
      rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver · 39347e75
      Daniel Borkmann authored
      commit 4f7d2cdf upstream.
      
      Jason Gunthorpe reported that since commit c02db8c6 ("rtnetlink: make
      SR-IOV VF interface symmetric"), we don't verify IFLA_VF_INFO attributes
      anymore with respect to their policy, that is, ifla_vfinfo_policy[].
      
      Before, they were part of ifla_policy[], but they have been nested since
      placed under IFLA_VFINFO_LIST, that contains the attribute IFLA_VF_INFO,
      which is another nested attribute for the actual VF attributes such as
      IFLA_VF_MAC, IFLA_VF_VLAN, etc.
      
      Despite the policy being split out from ifla_policy[] in this commit,
      it's never applied anywhere. nla_for_each_nested() only does basic nla_ok()
      testing for struct nlattr, but it doesn't know about the data context and
      their requirements.
      
      Fix, on top of Jason's initial work, does 1) parsing of the attributes
      with the right policy, and 2) using the resulting parsed attribute table
      from 1) instead of the nla_for_each_nested() loop (just like we used to
      do when still part of ifla_policy[]).
      
      Reference: http://thread.gmane.org/gmane.linux.network/368913
      Fixes: c02db8c6 ("rtnetlink: make SR-IOV VF interface symmetric")
      Reported-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
      Cc: Greg Rose <gregory.v.rose@intel.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Rony Efraim <ronye@mellanox.com>
      Cc: Vlad Zolotarov <vladz@cloudius-systems.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarVlad Zolotarov <vladz@cloudius-systems.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: used davem's backport to 3.18 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      39347e75
    • Dave Airlie's avatar
      drm/radeon: fix hotplug race at startup · 87fdee8a
      Dave Airlie authored
      commit 7f98ca45 upstream.
      
      We apparantly get a hotplug irq before we've initialised
      modesetting,
      
      [drm] Loading R100 Microcode
      BUG: unable to handle kernel NULL pointer dereference at   (null)
      IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91
      *pde = 00000000
      Oops: 0002 [#1]
      Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
      CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf674028 #111
      Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
      Workqueue: events radeon_hotplug_work_func [radeon]
      task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
      EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0
      EIP is at __mutex_lock_slowpath+0x23/0x91
      EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
      ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
       DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
      Stack:
       f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
       f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
       c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
      Call Trace:
       [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7
       [<c125f162>] ? mutex_lock+0x9/0xa
       [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
       [<c1034741>] ? process_one_work+0xfc/0x194
       [<c1034b58>] ? worker_thread+0x18d/0x218
       [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5
       [<c103742a>] ? kthread+0x7b/0x80
       [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30
       [<c10373af>] ? init_completion+0x18/0x18
      Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63
      Reported-and-Tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      87fdee8a
    • Jan Kara's avatar
      fsnotify: fix oops in fsnotify_clear_marks_by_group_flags() · 138a1115
      Jan Kara authored
      commit 8f2f3eb5 upstream.
      
      fsnotify_clear_marks_by_group_flags() can race with
      fsnotify_destroy_marks() so that when fsnotify_destroy_mark_locked()
      drops mark_mutex, a mark from the list iterated by
      fsnotify_clear_marks_by_group_flags() can be freed and thus the next
      entry pointer we have cached may become stale and we dereference free
      memory.
      
      Fix the problem by first moving marks to free to a special private list
      and then always free the first entry in the special list.  This method
      is safe even when entries from the list can disappear once we drop the
      lock.
      Signed-off-by: default avatarJan Kara <jack@suse.com>
      Reported-by: default avatarAshish Sangwan <a.sangwan@samsung.com>
      Reviewed-by: default avatarAshish Sangwan <a.sangwan@samsung.com>
      Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      138a1115
    • Joseph Qi's avatar
      ocfs2: fix BUG in ocfs2_downconvert_thread_do_work() · b3c6e774
      Joseph Qi authored
      commit 209f7512 upstream.
      
      The "BUG_ON(list_empty(&osb->blocked_lock_list))" in
      ocfs2_downconvert_thread_do_work can be triggered in the following case:
      
      ocfs2dc has firstly saved osb->blocked_lock_count to local varibale
      processed, and then processes the dentry lockres.  During the dentry
      put, it calls iput and then deletes rw, inode and open lockres from
      blocked list in ocfs2_mark_lockres_freeing.  And this causes the
      variable `processed' to not reflect the number of blocked lockres to be
      processed, which triggers the BUG.
      Signed-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b3c6e774
    • Marcus Gelderie's avatar
      ipc: modify message queue accounting to not take kernel data structures into account · 1e10a0a1
      Marcus Gelderie authored
      commit de54b9ac upstream.
      
      A while back, the message queue implementation in the kernel was
      improved to use btrees to speed up retrieval of messages, in commit
      d6629859 ("ipc/mqueue: improve performance of send/recv").
      
      That patch introducing the improved kernel handling of message queues
      (using btrees) has, as a by-product, changed the meaning of the QSIZE
      field in the pseudo-file created for the queue.  Before, this field
      reflected the size of the user-data in the queue.  Since, it also takes
      kernel data structures into account.  For example, if 13 bytes of user
      data are in the queue, on my machine the file reports a size of 61
      bytes.
      
      There was some discussion on this topic before (for example
      https://lkml.org/lkml/2014/10/1/115).  Commenting on a th lkml, Michael
      Kerrisk gave the following background
      (https://lkml.org/lkml/2015/6/16/74):
      
          The pseudofiles in the mqueue filesystem (usually mounted at
          /dev/mqueue) expose fields with metadata describing a message
          queue. One of these fields, QSIZE, as originally implemented,
          showed the total number of bytes of user data in all messages in
          the message queue, and this feature was documented from the
          beginning in the mq_overview(7) page. In 3.5, some other (useful)
          work happened to break the user-space API in a couple of places,
          including the value exposed via QSIZE, which now includes a measure
          of kernel overhead bytes for the queue, a figure that renders QSIZE
          useless for its original purpose, since there's no way to deduce
          the number of overhead bytes consumed by the implementation.
          (The other user-space breakage was subsequently fixed.)
      
      This patch removes the accounting of kernel data structures in the
      queue.  Reporting the size of these data-structures in the QSIZE field
      was a breaking change (see Michael's comment above).  Without the QSIZE
      field reporting the total size of user-data in the queue, there is no
      way to deduce this number.
      
      It should be noted that the resource limit RLIMIT_MSGQUEUE is counted
      against the worst-case size of the queue (in both the old and the new
      implementation).  Therefore, the kernel overhead accounting in QSIZE is
      not necessary to help the user understand the limitations RLIMIT imposes
      on the processes.
      Signed-off-by: default avatarMarcus Gelderie <redmnic@gmail.com>
      Acked-by: default avatarDoug Ledford <dledford@redhat.com>
      Acked-by: default avatarMichael Kerrisk <mtk.manpages@gmail.com>
      Acked-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: John Duffy <jb_duffy@btinternet.com>
      Cc: Arto Bendiken <arto@bendiken.net>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1e10a0a1
    • David Daney's avatar
      MIPS: Make set_pte() SMP safe. · a7c6bc31
      David Daney authored
      commit 46011e6e upstream.
      
      On MIPS the GLOBAL bit of the PTE must have the same value in any
      aligned pair of PTEs.  These pairs of PTEs are referred to as
      "buddies".  In a SMP system is is possible for two CPUs to be calling
      set_pte() on adjacent PTEs at the same time.  There is a race between
      setting the PTE and a different CPU setting the GLOBAL bit in its
      buddy PTE.
      
      This race can be observed when multiple CPUs are executing
      vmap()/vfree() at the same time.
      
      Make setting the buddy PTE's GLOBAL bit an atomic operation to close
      the race condition.
      
      The case of CONFIG_64BIT_PHYS_ADDR && CONFIG_CPU_MIPS32 is *not*
      handled.
      Signed-off-by: default avatarDavid Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10835/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a7c6bc31
    • Michal Hocko's avatar
      mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations · fa507c49
      Michal Hocko authored
      commit ecf5fc6e upstream.
      
      Nikolay has reported a hang when a memcg reclaim got stuck with the
      following backtrace:
      
      PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
        #0 __schedule at ffffffff815ab152
        #1 schedule at ffffffff815ab76e
        #2 schedule_timeout at ffffffff815ae5e5
        #3 io_schedule_timeout at ffffffff815aad6a
        #4 bit_wait_io at ffffffff815abfc6
        #5 __wait_on_bit at ffffffff815abda5
        #6 wait_on_page_bit at ffffffff8111fd4f
        #7 shrink_page_list at ffffffff81135445
        #8 shrink_inactive_list at ffffffff81135845
        #9 shrink_lruvec at ffffffff81135ead
       #10 shrink_zone at ffffffff811360c3
       #11 shrink_zones at ffffffff81136eff
       #12 do_try_to_free_pages at ffffffff8113712f
       #13 try_to_free_mem_cgroup_pages at ffffffff811372be
       #14 try_charge at ffffffff81189423
       #15 mem_cgroup_try_charge at ffffffff8118c6f5
       #16 __add_to_page_cache_locked at ffffffff8112137d
       #17 add_to_page_cache_lru at ffffffff81121618
       #18 pagecache_get_page at ffffffff8112170b
       #19 grow_dev_page at ffffffff811c8297
       #20 __getblk_slow at ffffffff811c91d6
       #21 __getblk_gfp at ffffffff811c92c1
       #22 ext4_ext_grow_indepth at ffffffff8124565c
       #23 ext4_ext_create_new_leaf at ffffffff81246ca8
       #24 ext4_ext_insert_extent at ffffffff81246f09
       #25 ext4_ext_map_blocks at ffffffff8124a848
       #26 ext4_map_blocks at ffffffff8121a5b7
       #27 mpage_map_one_extent at ffffffff8121b1fa
       #28 mpage_map_and_submit_extent at ffffffff8121f07b
       #29 ext4_writepages at ffffffff8121f6d5
       #30 do_writepages at ffffffff8112c490
       #31 __filemap_fdatawrite_range at ffffffff81120199
       #32 filemap_flush at ffffffff8112041c
       #33 ext4_alloc_da_blocks at ffffffff81219da1
       #34 ext4_rename at ffffffff81229b91
       #35 ext4_rename2 at ffffffff81229e32
       #36 vfs_rename at ffffffff811a08a5
       #37 SYSC_renameat2 at ffffffff811a3ffc
       #38 sys_renameat2 at ffffffff811a408e
       #39 sys_rename at ffffffff8119e51e
       #40 system_call_fastpath at ffffffff815afa89
      
      Dave Chinner has properly pointed out that this is a deadlock in the
      reclaim code because ext4 doesn't submit pages which are marked by
      PG_writeback right away.
      
      The heuristic was introduced by commit e62e384e ("memcg: prevent OOM
      with too many dirty pages") and it was applied only when may_enter_fs
      was specified.  The code has been changed by c3b94f44 ("memcg:
      further prevent OOM with too many dirty pages") which has removed the
      __GFP_FS restriction with a reasoning that we do not get into the fs
      code.  But this is not sufficient apparently because the fs doesn't
      necessarily submit pages marked PG_writeback for IO right away.
      
      ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
      submit the bio.  Instead it tries to map more pages into the bio and
      mpage_map_one_extent might trigger memcg charge which might end up
      waiting on a page which is marked PG_writeback but hasn't been submitted
      yet so we would end up waiting for something that never finishes.
      
      Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
      before we go to wait on the writeback.  The page fault path, which is
      the only path that triggers memcg oom killer since 3.12, shouldn't
      require GFP_NOFS and so we shouldn't reintroduce the premature OOM
      killer issue which was originally addressed by the heuristic.
      
      As per David Chinner the xfs is doing similar thing since 2.6.15 already
      so ext4 is not the only affected filesystem.  Moreover he notes:
      
      : For example: IO completion might require unwritten extent conversion
      : which executes filesystem transactions and GFP_NOFS allocations. The
      : writeback flag on the pages can not be cleared until unwritten
      : extent conversion completes. Hence memory reclaim cannot wait on
      : page writeback to complete in GFP_NOFS context because it is not
      : safe to do so, memcg reclaim or otherwise.
      
      [tytso@mit.edu: corrected the control flow]
      Fixes: c3b94f44 ("memcg: further prevent OOM with too many dirty pages")
      Reported-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ luis: backported to 3.16: used Hugh's backport for 4.1 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fa507c49
    • Takashi Sakamoto's avatar
      ALSA: fireworks/firewire-lib: add support for recent firmware quirk · 741c0a27
      Takashi Sakamoto authored
      commit 18f5ed36 upstream.
      
      Fireworks uses TSB43CB43(IceLynx-Micro) as its IEC 61883-1/6 interface.
      This chip includes ARM7 core, and loads and runs program. The firmware
      is stored in on-board memory and loaded every powering-on from it.
      
      Echo Audio ships several versions of firmwares for each model. These
      firmwares have each quirk and the quirk changes a sequence of packets.
      
      As long as I investigated, AudioFire2/AudioFire4/AudioFirePre8 have a
      quirk to transfer a first packet with 0x02 in its dbc field. This causes
      ALSA Fireworks driver to detect discontinuity. In this case, firmware
      version 5.7.0, 5.7.3 and 5.8.0 are used.
      
      Payload  CIP      CIP
      quadlets header1  header2
      02       00050002 90ffffff <-
      42       0005000a 90013000
      42       00050012 90014400
      42       0005001a 90015800
      02       0005001a 90ffffff
      42       00050022 90019000
      42       0005002a 9001a400
      42       00050032 9001b800
      02       00050032 90ffffff
      42       0005003a 9001d000
      42       00050042 9001e400
      42       0005004a 9001f800
      02       0005004a 90ffffff
      (AudioFire2 with firmware version 5.7.)
      
      $ dmesg
      snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02
      
      These models, AudioFire8 (since Jul 2009 ) and Gibson Robot Interface
      Pack series uses the same ARM binary as their firmware. Thus, this
      quirk may be observed among them.
      
      This commit adds a new member for AMDTP structure. This member represents
      the value of dbc field in a first AMDTP packet. Drivers can set it with
      a preferred value according to model's quirk.
      Tested-by: default avatarJohannes Oertei <johannes.oertel@uni-due.de>
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      741c0a27
    • Gavin Shan's avatar
      drivers/usb: Delete XHCI command timer if necessary · e42673ce
      Gavin Shan authored
      commit ffe5adcb upstream.
      
      When xhci_mem_cleanup() is called, it's possible that the command
      timer isn't initialized and scheduled. For those cases, to delete
      the command timer causes soft-lockup as below stack dump shows.
      
      The patch avoids deleting the command timer if it's not scheduled
      with the help of timer_pending().
      
      NMI watchdog: BUG: soft lockup - CPU#40 stuck for 23s! [kworker/40:1:8140]
            :
      NIP [c000000000150b30] lock_timer_base.isra.34+0x90/0xa0
      LR [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
      Call Trace:
      [c000000f67c975e0] [c0000000015b84f8] mon_ops+0x0/0x8 (unreliable)
      [c000000f67c97620] [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
      [c000000f67c97660] [c000000000150cf0] del_timer_sync+0x60/0x80
      [c000000f67c97690] [c00000000070ac0c] xhci_mem_cleanup+0x5c/0x5e0
      [c000000f67c97740] [c00000000070c2e8] xhci_mem_init+0x1158/0x13b0
      [c000000f67c97860] [c000000000700978] xhci_init+0x88/0x110
      [c000000f67c978e0] [c000000000701644] xhci_gen_setup+0x2b4/0x590
      [c000000f67c97970] [c0000000006d4410] xhci_pci_setup+0x40/0x190
      [c000000f67c979f0] [c0000000006b1af8] usb_add_hcd+0x418/0xba0
      [c000000f67c97ab0] [c0000000006cb15c] usb_hcd_pci_probe+0x1dc/0x5c0
      [c000000f67c97b50] [c0000000006d3ba4] xhci_pci_probe+0x64/0x1f0
      [c000000f67c97ba0] [c0000000004fe9ac] local_pci_probe+0x6c/0x130
      [c000000f67c97c30] [c0000000000e5ce8] work_for_cpu_fn+0x38/0x60
      [c000000f67c97c60] [c0000000000eacb8] process_one_work+0x198/0x470
      [c000000f67c97cf0] [c0000000000eb6ac] worker_thread+0x37c/0x5a0
      [c000000f67c97d80] [c0000000000f2730] kthread+0x110/0x130
      [c000000f67c97e30] [c000000000009660] ret_from_kernel_thread+0x5c/0x7c
      Reported-by: default avatarPriya M. A <priyama2@in.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e42673ce
    • Mathias Nyman's avatar
      xhci: fix off by one error in TRB DMA address boundary check · c2310948
      Mathias Nyman authored
      commit 7895086a upstream.
      
      We need to check that a TRB is part of the current segment
      before calculating its DMA address.
      
      Previously a ring segment didn't use a full memory page, and every
      new ring segment got a new memory page, so the off by one
      error in checking the upper bound was never seen.
      
      Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
      didn't catch the case when a TRB was the first element of the next segment.
      
      This is triggered if the virtual memory pages for a ring segment are
      next to each in increasing order where the ring buffer wraps around and
      causes errors like:
      
      [  106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
      [  106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0
      
      The trb-end address is one outside the end-seg address.
      Tested-by: default avatarArkadiusz Miśkiewicz <arekm@maven.pl>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c2310948
    • James Hogan's avatar
      MIPS: Flush RPS on kernel entry with EVA · 13e6068e
      James Hogan authored
      commit 3aff47c0 upstream.
      
      When EVA is enabled, flush the Return Prediction Stack (RPS) present on
      some MIPS cores on entry to the kernel from user mode.
      
      This is important specifically for interAptiv with EVA enabled,
      otherwise kernel mode RPS mispredicts may trigger speculative fetches of
      user return addresses, which may be sensitive in the kernel address
      space due to EVA's overlapping user/kernel address spaces.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10812/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      13e6068e
    • James Hogan's avatar
      MIPS: show_stack: Fix stack trace with EVA · 4df98498
      James Hogan authored
      commit 1e77863a upstream.
      
      The show_stack() function deals exclusively with kernel contexts, but if
      it gets called in user context with EVA enabled, show_stacktrace() will
      attempt to access the stack using EVA accesses, which will either read
      other user mapped data, or more likely cause an exception which will be
      handled by __get_user().
      
      This is easily reproduced using SysRq t to show all task states, which
      results in the following stack dump output:
      
       Stack : (Bad stack address)
      
      Fix by setting the current user access mode to kernel around the call to
      show_stacktrace(). This causes __get_user() to use normal loads to read
      the kernel stack.
      
      Now we get the correct output, like this:
      
       Stack : 00000000 80168960 00000000 004a0000 00000000 00000000 8060016c 1f3abd0c
                 1f172cd8 8056f09c 7ff1e450 8014fc3c 00000001 806dd0b0 0000001d 00000002
                 1f17c6a0 1f17c804 1f17c6a0 8066f6e0 00000000 0000000a 00000000 00000000
                 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
                 00000000 00000000 00000000 00000000 00000000 0110e800 1f3abd6c 1f17c6a0
                 ...
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10778/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4df98498
    • James Hogan's avatar
      MIPS: do_mcheck: Fix kernel code dump with EVA · cf387a0e
      James Hogan authored
      commit 55c723e1 upstream.
      
      If a machine check exception is raised in kernel mode, user context,
      with EVA enabled, then the do_mcheck handler will attempt to read the
      code around the EPC using EVA load instructions, i.e. as if the reads
      were from user mode. This will either read random user data if the
      process has anything mapped at the same address, or it will cause an
      exception which is handled by __get_user, resulting in this output:
      
       Code: (Bad address in epc)
      
      Fix by setting the current user access mode to kernel if the saved
      register context indicates the exception was taken in kernel mode. This
      causes __get_user to use normal loads to read the kernel code.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10777/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cf387a0e
    • James Hogan's avatar
      MIPS: Malta: Don't reinitialise RTC · 0c9edbfa
      James Hogan authored
      commit 106eccb4 upstream.
      
      On Malta, since commit a87ea88d ("MIPS: Malta: initialise the RTC at
      boot"), the RTC is reinitialised and forced into binary coded decimal
      (BCD) mode during init, even if the bootloader has already initialised
      it, and may even have already put it into binary mode (as YAMON does).
      This corrupts the current time, can result in the RTC seconds being an
      invalid BCD (e.g. 0x1a..0x1f) for up to 6 seconds, as well as confusing
      YAMON for a while after reset, enough for it to report timeouts when
      attempting to load from TFTP (it actually uses the RTC in that code).
      
      Therefore only initialise the RTC to the extent that is necessary so
      that Linux avoids interfering with the bootloader setup, while also
      allowing it to estimate the CPU frequency without hanging, without a
      bootloader necessarily having done anything with the RTC (for example
      when the kernel is loaded via EJTAG).
      
      The divider control is configured for a 32KHZ reference clock if
      necessary, and the SET bit of the RTC_CONTROL register is cleared if
      necessary without changing any other bits (this bit will be set when
      coming out of reset if the battery has been disconnected).
      
      Fixes: a87ea88d ("MIPS: Malta: initialise the RTC at boot")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Reviewed-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10739/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0c9edbfa
    • Felix Fietkau's avatar
      MIPS: Fix sched_getaffinity with MT FPAFF enabled · 7b89a55a
      Felix Fietkau authored
      commit 1d62d737 upstream.
      
      p->thread.user_cpus_allowed is zero-initialized and is only filled on
      the first sched_setaffinity call.
      
      To avoid adding overhead in the task initialization codepath, simply OR
      the returned mask in sched_getaffinity with p->cpus_allowed.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10740/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7b89a55a
    • Krzysztof Kozlowski's avatar
      thermal: exynos: Disable the regulator on probe failure · 2ab73952
      Krzysztof Kozlowski authored
      commit 5f09a5cb upstream.
      
      During probe the regulator (if present) was enabled but not disabled in
      case of failure. So an unsuccessful probe lead to enabling the
      regulator which was actually not needed because the device was not
      enabled.
      
      Additionally each deferred probe lead to increase of regulator enable
      count so it would not be effectively disabled during removal of the
      device.
      
      Test HW: Exynos4412 - Trats2 board
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 498d22f6 ("thermal: exynos: Support for TMU regulator defined at device tree")
      Reviewed-by: default avatarJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Tested-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2ab73952
    • NeilBrown's avatar
      md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies · 83365516
      NeilBrown authored
      commit 423f04d6 upstream.
      
      raid1_end_read_request() assumes that the In_sync bits are consistent
      with the ->degaded count.
      raid1_spare_active updates the In_sync bit before the ->degraded count
      and so exposes an inconsistency, as does error()
      So extend the spinlock in raid1_spare_active() and error() to hide those
      inconsistencies.
      
      This should probably be part of
        Commit: 34cab6f4 ("md/raid1: fix test for 'was read error from
        last working device'.")
      as it addresses the same issue.  It fixes the same bug and should go
      to -stable for same reasons.
      
      Fixes: 76073054 ("md/raid1: clean up read_balance.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      83365516
    • NeilBrown's avatar
      md/bitmap: return an error when bitmap superblock is corrupt. · b1dd5485
      NeilBrown authored
      commit b97e9257 upstream
          Use separate bitmaps for each nodes in the cluster
      
      bitmap_read_sb() validates the bitmap superblock that it reads in.
      If it finds an inconsistency like a bad magic number or out-of-range
      version number, it prints an error and returns, but it incorrectly
      returns zero, so the array is still assembled with the (invalid) bitmap.
      
      This means it could try to use a bitmap with a new version number which
      it therefore does not understand.
      
      This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
      So the patch is suitable for any -stable kernel in that range.
      
      Fixes: 27581e5a ("md/bitmap: centralise allocation of bitmap file pages.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Reported-by: default avatarGuoQing Jiang <gqjiang@suse.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b1dd5485
    • Ilya Dryomov's avatar
      rbd: fix copyup completion race · 1d3120e0
      Ilya Dryomov authored
      commit 2761713d upstream.
      
      For write/discard obj_requests that involved a copyup method call, the
      opcode of the first op is CEPH_OSD_OP_CALL and the ->callback is
      rbd_img_obj_copyup_callback().  The latter frees copyup pages, sets
      ->xferred and delegates to rbd_img_obj_callback(), the "normal" image
      object callback, for reporting to block layer and putting refs.
      
      rbd_osd_req_callback() however treats CEPH_OSD_OP_CALL as a trivial op,
      which means obj_request is marked done in rbd_osd_trivial_callback(),
      *before* ->callback is invoked and rbd_img_obj_copyup_callback() has
      a chance to run.  Marking obj_request done essentially means giving
      rbd_img_obj_callback() a license to end it at any moment, so if another
      obj_request from the same img_request is being completed concurrently,
      rbd_img_obj_end_request() may very well be called on such prematurally
      marked done request:
      
      <obj_request-1/2 reply>
      handle_reply()
        rbd_osd_req_callback()
          rbd_osd_trivial_callback()
          rbd_obj_request_complete()
          rbd_img_obj_copyup_callback()
          rbd_img_obj_callback()
                                          <obj_request-2/2 reply>
                                          handle_reply()
                                            rbd_osd_req_callback()
                                              rbd_osd_trivial_callback()
            for_each_obj_request(obj_request->img_request) {
              rbd_img_obj_end_request(obj_request-1/2)
              rbd_img_obj_end_request(obj_request-2/2) <--
            }
      
      Calling rbd_img_obj_end_request() on such a request leads to trouble,
      in particular because its ->xfferred is 0.  We report 0 to the block
      layer with blk_update_request(), get back 1 for "this request has more
      data in flight" and then trip on
      
          rbd_assert(more ^ (which == img_request->obj_request_count));
      
      with rhs (which == ...) being 1 because rbd_img_obj_end_request() has
      been called for both requests and lhs (more) being 1 because we haven't
      got a chance to set ->xfferred in rbd_img_obj_copyup_callback() yet.
      
      To fix this, leverage that rbd wants to call class methods in only two
      cases: one is a generic method call wrapper (obj_request is standalone)
      and the other is a copyup (obj_request is part of an img_request).  So
      make a dedicated handler for CEPH_OSD_OP_CALL and directly invoke
      rbd_img_obj_copyup_callback() from it if obj_request is part of an
      img_request, similar to how CEPH_OSD_OP_READ handler invokes
      rbd_img_obj_request_read_callback().
      
      Since rbd_img_obj_copyup_callback() is now being called from the OSD
      request callback (only), it is renamed to rbd_osd_copyup_callback().
      
      Cc: Alex Elder <elder@linaro.org>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      [idryomov@gmail.com: backport to < 3.18: context]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1d3120e0
    • Dirk Behme's avatar
      USB: sierra: add 1199:68AB device ID · 48162cbf
      Dirk Behme authored
      commit 74472233 upstream.
      
      Add support for the Sierra Wireless AR8550 device with
      USB descriptor 0x1199, 0x68AB.
      
      It is common with MC879x modules 1199:683c/683d which
      also are composite devices with 7 interfaces (0..6)
      and also MDM62xx based as the AR8550.
      
      The major difference are only the interface attributes
      02/02/01 on interfaces 3 and 4 on the AR8550. They are
      vendor specific ff/ff/ff on MC879x modules.
      
      lsusb reports:
      
      Bus 001 Device 004: ID 1199:68ab Sierra Wireless, Inc.
      Device Descriptor:
        bLength                18
        bDescriptorType         1
        bcdUSB               2.00
        bDeviceClass            0 (Defined at Interface level)
        bDeviceSubClass         0
        bDeviceProtocol         0
        bMaxPacketSize0        64
        idVendor           0x1199 Sierra Wireless, Inc.
        idProduct          0x68ab
        bcdDevice            0.06
        iManufacturer           3 Sierra Wireless, Incorporated
        iProduct                2 AR8550
        iSerial                 0
        bNumConfigurations      1
        Configuration Descriptor:
          bLength                 9
          bDescriptorType         2
          wTotalLength          198
          bNumInterfaces          7
          bConfigurationValue     1
          iConfiguration          1 Sierra Configuration
          bmAttributes         0xe0
            Self Powered
            Remote Wakeup
          MaxPower                0mA
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        0
            bAlternateSetting       0
            bNumEndpoints           2
            bInterfaceClass       255 Vendor Specific Class
            bInterfaceSubClass    255 Vendor Specific Subclass
            bInterfaceProtocol    255 Vendor Specific Protocol
            iInterface              0
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x81  EP 1 IN
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x01  EP 1 OUT
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        1
            bAlternateSetting       0
            bNumEndpoints           2
            bInterfaceClass       255 Vendor Specific Class
            bInterfaceSubClass    255 Vendor Specific Subclass
            bInterfaceProtocol    255 Vendor Specific Protocol
            iInterface              0
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x82  EP 2 IN
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x02  EP 2 OUT
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        2
            bAlternateSetting       0
            bNumEndpoints           2
            bInterfaceClass       255 Vendor Specific Class
            bInterfaceSubClass    255 Vendor Specific Subclass
            bInterfaceProtocol    255 Vendor Specific Protocol
            iInterface              0
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x83  EP 3 IN
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x03  EP 3 OUT
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        3
            bAlternateSetting       0
            bNumEndpoints           3
            bInterfaceClass         2 Communications
            bInterfaceSubClass      2 Abstract (modem)
            bInterfaceProtocol      1 AT-commands (v.25ter)
            iInterface              0
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x84  EP 4 IN
              bmAttributes            3
                Transfer Type            Interrupt
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0040  1x 64 bytes
              bInterval               5
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x85  EP 5 IN
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x04  EP 4 OUT
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        4
            bAlternateSetting       0
            bNumEndpoints           3
            bInterfaceClass         2 Communications
            bInterfaceSubClass      2 Abstract (modem)
            bInterfaceProtocol      1 AT-commands (v.25ter)
            iInterface              0
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x86  EP 6 IN
              bmAttributes            3
                Transfer Type            Interrupt
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0040  1x 64 bytes
              bInterval               5
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x87  EP 7 IN
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x05  EP 5 OUT
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        5
            bAlternateSetting       0
            bNumEndpoints           3
            bInterfaceClass       255 Vendor Specific Class
            bInterfaceSubClass    255 Vendor Specific Subclass
            bInterfaceProtocol    255 Vendor Specific Protocol
            iInterface              0
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x88  EP 8 IN
              bmAttributes            3
                Transfer Type            Interrupt
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0040  1x 64 bytes
              bInterval               5
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x89  EP 9 IN
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x06  EP 6 OUT
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        6
            bAlternateSetting       0
            bNumEndpoints           3
            bInterfaceClass       255 Vendor Specific Class
            bInterfaceSubClass    255 Vendor Specific Subclass
            bInterfaceProtocol    255 Vendor Specific Protocol
            iInterface              0
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x8a  EP 10 IN
              bmAttributes            3
                Transfer Type            Interrupt
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0040  1x 64 bytes
              bInterval               5
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x8b  EP 11 IN
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x07  EP 7 OUT
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0200  1x 512 bytes
              bInterval              32
      Device Qualifier (for other device speed):
        bLength                10
        bDescriptorType         6
        bcdUSB               2.00
        bDeviceClass            0 (Defined at Interface level)
        bDeviceSubClass         0
        bDeviceProtocol         0
        bMaxPacketSize0        64
        bNumConfigurations      1
      Device Status:     0x0001
        Self Powered
      Signed-off-by: default avatarDirk Behme <dirk.behme@de.bosch.com>
      Cc: Lars Melin <larsm17@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      48162cbf
    • Herbert Xu's avatar
      crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer · 57ece698
      Herbert Xu authored
      commit f898c522 upstream.
      
      This patch removes a bogus BUG_ON in the ablkcipher path that
      triggers when the destination buffer is different from the source
      buffer and is scattered.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      57ece698