1. 07 Aug, 2017 18 commits
    • Ben Skeggs's avatar
      drm/nouveau/bar/gf100: fix access to upper half of BAR2 · ae8faca6
      Ben Skeggs authored
      commit 38bcb208 upstream.
      
      Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
      mapped over the end of VRAM, even when the rest of the BAR has been set
      to virtual mode.
      
      We inherited our initial value from RM, but I'm not aware of any reason
      we need to keep it that way.
      
      This fixes severe GPU hang/lockup issues revealed by Wayland on F26.
      
      Shout-out to NVIDIA for the quick response with the potential cause!
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae8faca6
    • Ilia Mirkin's avatar
      drm/nouveau/disp/nv50-: bump max chans to 21 · 34da5f74
      Ilia Mirkin authored
      commit a90e049c upstream.
      
      GP102's cursors go from chan 17..20. Increase the array size to hold
      their data properly.
      
      Fixes: e50fcff1 ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
      Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34da5f74
    • Sinclair Yeh's avatar
      drm/vmwgfx: Fix gcc-7.1.1 warning · e4177988
      Sinclair Yeh authored
      commit fcfffdd8 upstream.
      
      The current code does not look correct, and the reason for it is
      probably lost.  Since this now generates a compiler warning,
      fix it to what makes sense.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSinclair Yeh <syeh@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4177988
    • Ofer Heifetz's avatar
      md/raid5: add thread_group worker async_tx_issue_pending_all · fabc7dff
      Ofer Heifetz authored
      commit 7e96d559 upstream.
      
      Since thread_group worker and raid5d kthread are not in sync, if
      worker writes stripe before raid5d then requests will be waiting
      for issue_pendig.
      
      Issue observed when building raid5 with ext4, in some build runs
      jbd2 would get hung and requests were waiting in the HW engine
      waiting to be issued.
      
      Fix this by adding a call to async_tx_issue_pending_all in the
      raid5_do_work.
      Signed-off-by: default avatarOfer Heifetz <oferh@marvell.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fabc7dff
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Enable TM before accessing TM registers · d745f0f6
      Paul Mackerras authored
      commit e4705715 upstream.
      
      Commit 46a704f8 ("KVM: PPC: Book3S HV: Preserve userspace HTM state
      properly", 2017-06-15) added code to read transactional memory (TM)
      registers but forgot to enable TM before doing so.  The result is
      that if userspace does have live values in the TM registers, a KVM_RUN
      ioctl will cause a host kernel crash like this:
      
      [  181.328511] Unrecoverable TM Unavailable Exception f60 at d00000001e7d9980
      [  181.328605] Oops: Unrecoverable TM Unavailable Exception, sig: 6 [#1]
      [  181.328613] SMP NR_CPUS=2048
      [  181.328613] NUMA
      [  181.328618] PowerNV
      [  181.328646] Modules linked in: vhost_net vhost tap nfs_layout_nfsv41_files rpcsec_gss_krb5 nfsv4 dns_resolver nfs
      +fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat
      +nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun ebtable_filter ebtables
      +ip6table_filter ip6_tables iptable_filter bridge stp llc kvm_hv kvm nfsd ses enclosure scsi_transport_sas ghash_generic
      +auth_rpcgss gf128mul xts sg ctr nfs_acl lockd vmx_crypto shpchp ipmi_powernv i2c_opal grace ipmi_devintf i2c_core
      +powernv_rng sunrpc ipmi_msghandler ibmpowernv uio_pdrv_genirq uio leds_powernv powernv_op_panel ip_tables xfs sd_mod
      +lpfc ipr bnx2x libata mdio ptp pps_core scsi_transport_fc libcrc32c dm_mirror dm_region_hash dm_log dm_mod
      [  181.329278] CPU: 40 PID: 9926 Comm: CPU 0/KVM Not tainted 4.12.0+ #1
      [  181.329337] task: c000003fc6980000 task.stack: c000003fe4d80000
      [  181.329396] NIP: d00000001e7d9980 LR: d00000001e77381c CTR: d00000001e7d98f0
      [  181.329465] REGS: c000003fe4d837e0 TRAP: 0f60   Not tainted  (4.12.0+)
      [  181.329523] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
      [  181.329527]   CR: 24022448  XER: 00000000
      [  181.329608] CFAR: d00000001e773818 SOFTE: 1
      [  181.329608] GPR00: d00000001e77381c c000003fe4d83a60 d00000001e7ef410 c000003fdcfe0000
      [  181.329608] GPR04: c000003fe4f00000 0000000000000000 0000000000000000 c000003fd7954800
      [  181.329608] GPR08: 0000000000000001 c000003fc6980000 0000000000000000 d00000001e7e2880
      [  181.329608] GPR12: d00000001e7d98f0 c000000007b19000 00000001295220e0 00007fffc0ce2090
      [  181.329608] GPR16: 0000010011886608 00007fff8c89f260 0000000000000001 00007fff8c080028
      [  181.329608] GPR20: 0000000000000000 00000100118500a6 0000010011850000 0000010011850000
      [  181.329608] GPR24: 00007fffc0ce1b48 0000010011850000 00000000d673b901 0000000000000000
      [  181.329608] GPR28: 0000000000000000 c000003fdcfe0000 c000003fdcfe0000 c000003fe4f00000
      [  181.330199] NIP [d00000001e7d9980] kvmppc_vcpu_run_hv+0x90/0x6b0 [kvm_hv]
      [  181.330264] LR [d00000001e77381c] kvmppc_vcpu_run+0x2c/0x40 [kvm]
      [  181.330322] Call Trace:
      [  181.330351] [c000003fe4d83a60] [d00000001e773478] kvmppc_set_one_reg+0x48/0x340 [kvm] (unreliable)
      [  181.330437] [c000003fe4d83b30] [d00000001e77381c] kvmppc_vcpu_run+0x2c/0x40 [kvm]
      [  181.330513] [c000003fe4d83b50] [d00000001e7700b4] kvm_arch_vcpu_ioctl_run+0x114/0x2a0 [kvm]
      [  181.330586] [c000003fe4d83bd0] [d00000001e7642f8] kvm_vcpu_ioctl+0x598/0x7a0 [kvm]
      [  181.330658] [c000003fe4d83d40] [c0000000003451b8] do_vfs_ioctl+0xc8/0x8b0
      [  181.330717] [c000003fe4d83de0] [c000000000345a64] SyS_ioctl+0xc4/0x120
      [  181.330776] [c000003fe4d83e30] [c00000000000b004] system_call+0x58/0x6c
      [  181.330833] Instruction dump:
      [  181.330869] e92d0260 e9290b50 e9290108 792807e3 41820058 e92d0260 e9290b50 e9290108
      [  181.330941] 792ae8a4 794a1f87 408204f4 e92d0260 <7d4022a6> f9490ff0 e92d0260 7d4122a6
      [  181.331013] ---[ end trace 6f6ddeb4bfe92a92 ]---
      
      The fix is just to turn on the TM bit in the MSR before accessing the
      registers.
      
      Fixes: 46a704f8 ("KVM: PPC: Book3S HV: Preserve userspace HTM state properly")
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Tested-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d745f0f6
    • Herbert Xu's avatar
      crypto: authencesn - Fix digest_null crash · 9eb088e5
      Herbert Xu authored
      commit 41cdf7a4 upstream.
      
      When authencesn is used together with digest_null a crash will
      occur on the decrypt path.  This is because normally we perform
      a special setup to preserve the ESN, but this is skipped if there
      is no authentication.  However, on the post-authentication path
      it always expects the preservation to be in place, thus causing
      a crash when digest_null is used.
      
      This patch fixes this by also skipping the post-processing when
      there is no authentication.
      
      Fixes: 104880a6 ("crypto: authencesn - Convert to new AEAD...")
      Reported-by: default avatarJan Tluka <jtluka@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9eb088e5
    • Benjamin Coddington's avatar
      NFSv4.1: Fix a race where CB_NOTIFY_LOCK fails to wake a waiter · 7d2a3548
      Benjamin Coddington authored
      commit b7dbcc0e upstream.
      
      nfs4_retry_setlk() sets the task's state to TASK_INTERRUPTIBLE within the
      same region protected by the wait_queue's lock after checking for a
      notification from CB_NOTIFY_LOCK callback.  However, after releasing that
      lock, a wakeup for that task may race in before the call to
      freezable_schedule_timeout_interruptible() and set TASK_WAKING, then
      freezable_schedule_timeout_interruptible() will set the state back to
      TASK_INTERRUPTIBLE before the task will sleep.  The result is that the task
      will sleep for the entire duration of the timeout.
      
      Since we've already set TASK_INTERRUPTIBLE in the locked section, just use
      freezable_schedule_timout() instead.
      
      Fixes: a1d617d8 ("nfs: allow blocking locks to be awoken by lock callbacks")
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d2a3548
    • NeilBrown's avatar
      NFS: invalidate file size when taking a lock. · b087b8b1
      NeilBrown authored
      commit 442ce049 upstream.
      
      Prior to commit ca0daa27 ("NFS: Cache aggressively when file is open
      for writing"), NFS would revalidate, or invalidate, the file size when
      taking a lock.  Since that commit it only invalidates the file content.
      
      If the file size is changed on the server while wait for the lock, the
      client will have an incorrect understanding of the file size and could
      corrupt data.  This particularly happens when writing beyond the
      (supposed) end of file and can be easily be demonstrated with
      posix_fallocate().
      
      If an application opens an empty file, waits for a write lock, and then
      calls posix_fallocate(), glibc will determine that the underlying
      filesystem doesn't support fallocate (assuming version 4.1 or earlier)
      and will write out a '0' byte at the end of each 4K page in the region
      being fallocated that is after the end of the file.
      NFS will (usually) detect that these writes are beyond EOF and will
      expand them to cover the whole page, and then will merge the pages.
      Consequently, NFS will write out large blocks of zeroes beyond where it
      thought EOF was.  If EOF had moved, the pre-existing part of the file
      will be over-written.  Locking should have protected against this,
      but it doesn't.
      
      This patch restores the use of nfs_zap_caches() which invalidated the
      cached attributes.  When posix_fallocate() asks for the file size, the
      request will go to the server and get a correct answer.
      
      Fixes: ca0daa27 ("NFS: Cache aggressively when file is open for writing")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b087b8b1
    • Laurent Vivier's avatar
      powerpc/pseries: Fix of_node_put() underflow during reconfig remove · 6d3d93ca
      Laurent Vivier authored
      commit 4fd1bd44 upstream.
      
      As for commit 68baf692 ("powerpc/pseries: Fix of_node_put()
      underflow during DLPAR remove"), the call to of_node_put() must be
      removed from pSeries_reconfig_remove_node().
      
      dlpar_detach_node() and pSeries_reconfig_remove_node() both call
      of_detach_node(), and thus the node should not be released in both
      cases.
      
      Fixes: 0829f6d1 ("of: device_node kobject lifecycle fixes")
      Signed-off-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d3d93ca
    • Helge Deller's avatar
      parisc: Suspend lockup detectors before system halt · fa2aa76e
      Helge Deller authored
      commit 56188832 upstream.
      
      Some machines can't power off the machine, so disable the lockup detectors to
      avoid this watchdog BUG to show up every few seconds:
      watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-shutdow:1]
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa2aa76e
    • John David Anglin's avatar
      parisc: Extend disabled preemption in copy_user_page · f0d23fa6
      John David Anglin authored
      commit 56008c04 upstream.
      
      It's always bothered me that we only disable preemption in
      copy_user_page around the call to flush_dcache_page_asm.
      This patch extends this to after the copy.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0d23fa6
    • John David Anglin's avatar
      parisc: Prevent TLB speculation on flushed pages on CPUs that only support equivalent aliases · afe9fc01
      John David Anglin authored
      commit ae7a609c upstream.
      
      Helge noticed that we flush the TLB page in flush_cache_page but not in
      flush_cache_range or flush_cache_mm.
      
      For a long time, we have had random segmentation faults building
      packages on machines with PA8800/8900 processors.  These machines only
      support equivalent aliases.  We don't see these faults on machines that
      don't require strict coherency.  So, it appears TLB speculation
      sometimes leads to cache corruption on machines that require coherency.
      
      This patch adds TLB flushes to flush_cache_range and flush_cache_mm when
      coherency is required.  We only flush the TLB in flush_cache_page when
      coherency is required.
      
      The patch also optimizes flush_cache_range.  It turns out we always have
      the right context to use flush_user_dcache_range_asm and
      flush_user_icache_range_asm.
      
      The patch has been tested for some time on rp3440, rp3410 and A500-44.
      It's been boot tested on c8000.  No random segmentation faults were
      observed during testing.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afe9fc01
    • Daniel Dadap's avatar
      ALSA: hda - Add missing NVIDIA GPU codec IDs to patch table · 5f8bdd5e
      Daniel Dadap authored
      commit 74ec1181 upstream.
      
      Add codec IDs for several recently released, pending, and historical
      NVIDIA GPU audio controllers to the patch table, to allow the correct
      patch functions to be selected for them.
      Signed-off-by: default avatarDaniel Dadap <ddadap@nvidia.com>
      Reviewed-by: default avatarAndy Ritger <aritger@nvidia.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f8bdd5e
    • Andy Shevchenko's avatar
      ALSA: fm801: Initialize chip after IRQ handler is registered · 3d955095
      Andy Shevchenko authored
      commit 610e1ae9 upstream.
      
      The commit b56fa687 ("ALSA: fm801: detect FM-only card earlier")
      rearranged initialization calls, i.e. it makes snd_fm801_chip_init() to
      be called before we register interrupt handler and set PCI bus
      mastering.
      
      Somehow it prevents FM801-AU to work properly. Thus, partially revert
      initialization order changed by commit mentioned above.
      
      Fixes: b56fa687 ("ALSA: fm801: detect FM-only card earlier")
      Reported-by: default avatarÉmeric MASCHINO <emeric.maschino@gmail.com>
      Tested-by: default avatarÉmeric MASCHINO <emeric.maschino@gmail.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d955095
    • Jan Kara's avatar
      jfs: Don't clear SGID when inheriting ACLs · 3a79e1c8
      Jan Kara authored
      commit 9bcf66c7 upstream.
      
      When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
      set, DIR1 is expected to have SGID bit set (and owning group equal to
      the owning group of 'DIR0'). However when 'DIR0' also has some default
      ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
      'DIR1' to get cleared if user is not member of the owning group.
      
      Fix the problem by moving posix_acl_update_mode() out of
      __jfs_set_acl() into jfs_set_acl(). That way the function will not be
      called when inheriting ACLs which is what we want as it prevents SGID
      bit clearing and the mode has been properly set by posix_acl_create()
      anyway.
      
      Fixes: 07393101
      CC: jfs-discussion@lists.sourceforge.net
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Kleikamp <dave.kleikamp@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a79e1c8
    • Eric Dumazet's avatar
      net: reduce skb_warn_bad_offload() noise · 26d01aa8
      Eric Dumazet authored
      commit b2504a5d upstream.
      
      Dmitry reported warnings occurring in __skb_gso_segment() [1]
      
      All SKB_GSO_DODGY producers can allow user space to feed
      packets that trigger the current check.
      
      We could prevent them from doing so, rejecting packets, but
      this might add regressions to existing programs.
      
      It turns out our SKB_GSO_DODGY handlers properly set up checksum
      information that is needed anyway when packets needs to be segmented.
      
      By checking again skb_needs_check() after skb_mac_gso_segment(),
      we should remove these pesky warnings, at a very minor cost.
      
      With help from Willem de Bruijn
      
      [1]
      WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
      lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
       ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
       ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
       ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
      Call Trace:
       [<ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline]
       [<ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
       [<ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179
       [<ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542
       [<ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
       [<ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
       [<ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
       [<ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline]
       [<ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
       [<ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
       [<ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
       [<ffffffff83ad161d>] packet_snd net/packet/af_packet.c:2930 [inline]
       [<ffffffff83ad161d>] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955
       [<ffffffff834f0aaa>] sock_sendmsg_nosec net/socket.c:621 [inline]
       [<ffffffff834f0aaa>] sock_sendmsg+0xca/0x110 net/socket.c:631
       [<ffffffff834f329a>] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954
       [<ffffffff834f5e58>] __sys_sendmsg+0x138/0x300 net/socket.c:1988
       [<ffffffff834f604d>] SYSC_sendmsg net/socket.c:1999 [inline]
       [<ffffffff834f604d>] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
       [<ffffffff84371941>] entry_SYSCALL_64_fastpath+0x1f/0xc2
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov  <dvyukov@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Mark Salyzyn <salyzyn@android.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26d01aa8
    • Joel Fernandes's avatar
      pstore: Make spinlock per zone instead of global · d97aff4f
      Joel Fernandes authored
      commit 10970449 upstream.
      
      Currently pstore has a global spinlock for all zones. Since the zones
      are independent and modify different areas of memory, there's no need
      to have a global lock, so we should use a per-zone lock as introduced
      here. Also, when ramoops's ftrace use-case has a FTRACE_PER_CPU flag
      introduced later, which splits the ftrace memory area into a single zone
      per CPU, it will eliminate the need for locking. In preparation for this,
      make the locking optional.
      Signed-off-by: default avatarJoel Fernandes <joelaf@google.com>
      [kees: updated commit message]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Leo Yan <leo.yan@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d97aff4f
    • Yuejie Shi's avatar
      af_key: Add lock to key dump · 0f94b36d
      Yuejie Shi authored
      commit 89e357d8 upstream.
      
      A dump may come in the middle of another dump, modifying its dump
      structure members. This race condition will result in NULL pointer
      dereference in kernel. So add a lock to prevent that race.
      
      Fixes: 83321d6b ("[AF_KEY]: Dump SA/SP entries non-atomically")
      Signed-off-by: default avatarYuejie Shi <syjcnss@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarMark Salyzyn <salyzyn@android.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f94b36d
  2. 27 Jul, 2017 22 commits