aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-06-07Merge branch 'pm-x86'Rafael J. Wysocki7-24/+63
* pm-x86: x86/power: Fix 'nosmt' vs hibernation triple fault during resume x86: intel_epb: Do not build when CONFIG_PM is unset
2019-06-07drm/meson: fix G12A primary plane disablingNeil Armstrong3-4/+5
The G12A Primary plane was disabled by writing in the OSD1 configuration registers, but this caused the plane blender to stall instead of continuing to blend only the overlay plane. Fix this by disabling the OSD1 plane in the blender registers, and also enabling it back using the same register. Fixes: 490f50c109d1 ("drm/meson: Add G12A support for OSD1 Plane") Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Kevin Hilman <[email protected]> [narmstrong: fixed nit in commit log] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-07drm/meson: fix primary plane disablingNeil Armstrong2-5/+3
The primary plane disable logic is flawed, when the primary plane is disabled, it is re-enabled in the vsync irq when another plane is updated. Handle the plane disabling correctly by handling the primary plane enable flag in the primary plane update & disable callbacks. Fixes: 490f50c109d1 ("drm/meson: Add G12A support for OSD1 Plane") Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Kevin Hilman <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-07drm/meson: fix G12A HDMI PLL settings for 4K60 1000/1001 variationsNeil Armstrong1-2/+11
The Amlogic G12A HDMI PLL needs some specific settings to lock with different fractional values for the 5,4GHz mode. Handle the 1000/1001 variation fractional case here to avoid having the PLL in an non lockable state. Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup") Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Kevin Hilman <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-07block, bfq: add weight symlink to the bfq.weight cgroup parameterAngelo Ruocco1-2/+4
Many userspace tools and services use the proportional-share policy of the blkio/io cgroups controller. The CFQ I/O scheduler implemented this policy for the legacy block layer. To modify the weight of a group in case CFQ was in charge, the 'weight' parameter of the group must be modified. On the other hand, the BFQ I/O scheduler implements the same policy in blk-mq, but, with BFQ, the parameter to modify has a different name: bfq.weight (forced choice until legacy block was present, because two different policies cannot share a common parameter in cgroups). Due to CFQ legacy, most if not all userspace configurations still use the parameter 'weight', and for the moment do not seem likely to be changed. But, when CFQ went away with legacy block, such a parameter ceased to exist. So, a simple workaround has been proposed [1] to make all configurations work: add a symlink, named weight, to bfq.weight. This commit adds such a symlink. [1] https://lkml.org/lkml/2019/4/8/555 Suggested-by: Johannes Thumshirn <[email protected]> Signed-off-by: Angelo Ruocco <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-06-07cgroup: let a symlink too be created with a cftype fileAngelo Ruocco2-4/+32
This commit enables a cftype to have a symlink (of any name) that points to the file associated with the cftype. Signed-off-by: Angelo Ruocco <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-06-07Merge branch 'linux-5.2' of git://github.com/skeggsb/linux into drm-fixesDave Airlie15-98/+242
" This is a bit more than I'd like to be pushing at this point in a cycle, but it's a fairly important issue. There's been numerous reports of more recent GP10[2467] boards failing to load, and I've worked with NVIDIA FW engineers and tracked this down to the FW we've been using not properly supporting the boards in question. I've pushed an update to linux-firmware with the new FW version, which unfortunately contains API changes vs the older firmware. This series teaches the ACR subsystem inside nouveau enough to be able to deal with supporting multiple incompatible FW revisions, and adds support to the relevant chipsets for loading the newer FW revision, if it's available." Signed-off-by: Dave Airlie <[email protected]> From: Ben Skeggs <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7pG+vur0Kn_TyU3ainnkvJVw07upnnaQNOToF+kzQtDQ@mail.gmail.com
2019-06-07powerpc/64s: __find_linux_pte() synchronization vs pmdp_invalidate()Nicholas Piggin1-2/+14
The change to pmdp_invalidate() to mark the pmd with _PAGE_INVALID broke the synchronisation against lock free lookups, __find_linux_pte()'s pmd_none() check no longer returns true for such cases. Fix this by adding a check for this condition as well. Fixes: da7ad366b497 ("powerpc/mm/book3s: Update pmd_present to look at _PAGE_PRESENT bit") Cc: [email protected] # v4.20+ Suggested-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Reviewed-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-06-07powerpc/64s: Fix THP PMD collapse serialisationNicholas Piggin2-0/+33
Commit 1b2443a547f9 ("powerpc/book3s64: Avoid multiple endian conversion in pte helpers") changed the actual bitwise tests in pte_access_permitted by using pte_write() and pte_present() helpers rather than raw bitwise testing _PAGE_WRITE and _PAGE_PRESENT bits. The pte_present() change now returns true for PTEs which are !_PAGE_PRESENT and _PAGE_INVALID, which is the combination used by pmdp_invalidate() to synchronize access from lock-free lookups. pte_access_permitted() is used by pmd_access_permitted(), so allowing GUP lock free access to proceed with such PTEs breaks this synchronisation. This bug has been observed on a host using the hash page table MMU, with random crashes and corruption in guests, usually together with bad PMD messages in the host. Fix this by adding an explicit check in pmd_access_permitted(), and documenting the condition explicitly. The pte_write() change should be okay, and would prevent GUP from falling back to the slow path when encountering savedwrite PTEs, which matches what x86 (that does not implement savedwrite) does. Fixes: 1b2443a547f9 ("powerpc/book3s64: Avoid multiple endian conversion in pte helpers") Cc: [email protected] # v4.20+ Signed-off-by: Nicholas Piggin <[email protected]> Reviewed-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-06-07powerpc: Fix kexec failure on book3s/32Christophe Leroy2-1/+6
In the old days, _PAGE_EXEC didn't exist on 6xx aka book3s/32. Therefore, allthough __mapin_ram_chunk() was already mapping kernel text with PAGE_KERNEL_TEXT and the rest with PAGE_KERNEL, the entire memory was executable. Part of the memory (first 512kbytes) was mapped with BATs instead of page table, but it was also entirely mapped as executable. In commit 385e89d5b20f ("powerpc/mm: add exec protection on powerpc 603"), we started adding exec protection to some 6xx, namely the 603, for pages mapped via pagetables. Then, in commit 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX"), the exec protection was extended to BAT mapped memory, so that really only the kernel text could be executed. The problem here is that kexec is based on copying some code into upper part of memory then executing it from there in order to install a fresh new kernel at its definitive location. However, the code is position independant and first part of it is just there to deactivate the MMU and jump to the second part. So it is possible to run this first part inplace instead of running the copy. Once the MMU is off, there is no protection anymore and the second part of the code will just run as before. Reported-by: Aaro Koskinen <[email protected]> Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX") Cc: [email protected] # v5.1+ Signed-off-by: Christophe Leroy <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2019-06-07drm/nouveau/secboot/gp10[2467]: support newer FW to fix SEC2 failures on ↵Ben Skeggs5-6/+18
some boards Some newer boards with these chipsets aren't compatible with the prior version of the SEC2 FW, and fail to load as a result. This newer FW is actually the one we already use on >=GP108. Unfortunately, there are interface differences in GP108's FW, making it impossible to simply move files around in linux-firmware to solve this. We need to be able to keep compatibility with all linux-firmware/kernel combinations, which means supporting both firmwares. Signed-off-by: Ben Skeggs <[email protected]>
2019-06-07drm/nouveau/secboot: enable loading of versioned LS PMU/SEC2 ACR msgqueue FWBen Skeggs1-14/+14
Some chipsets will be switching to updated SEC2 LS firmware, so we need to plumb that through. Signed-off-by: Ben Skeggs <[email protected]>
2019-06-07drm/nouveau/secboot: split out FW version-specific LS function pointersBen Skeggs6-41/+141
It's not enough to have per-falcon structures anymore, we have multiple versions of some firmware now that have interface differences. Signed-off-by: Ben Skeggs <[email protected]>
2019-06-07drm/nouveau/secboot: pass max supported FW version to LS load funcsBen Skeggs6-21/+32
Will be passed to the FW loader function as an upper bound on the supported FW version to attempt to load. Signed-off-by: Ben Skeggs <[email protected]>
2019-06-07drm/nouveau/core: support versioned firmware loadingBen Skeggs2-6/+31
We have a need for this now with updated SEC2 LS FW images that have an incompatible interface from the previous version. Signed-off-by: Ben Skeggs <[email protected]>
2019-06-07drm/nouveau/core: pass subdev into nvkm_firmware_get, rather than deviceBen Skeggs6-18/+14
It'd be nice to have FW loading debug messages to appear for the relevant subsystem, when enabled. Signed-off-by: Ben Skeggs <[email protected]>
2019-06-06block: free sched's request pool in blk_cleanup_queueMing Lei6-6/+52
In theory, IO scheduler belongs to request queue, and the request pool of sched tags belongs to the request queue too. However, the current tags allocation interfaces are re-used for both driver tags and sched tags, and driver tags is definitely host wide, and doesn't belong to any request queue, same with its request pool. So we need tagset instance for freeing request of sched tags. Meantime, blk_mq_free_tag_set() often follows blk_cleanup_queue() in case of non-BLK_MQ_F_TAG_SHARED, this way requires that request pool of sched tags to be freed before calling blk_mq_free_tag_set(). Commit 47cdee29ef9d94e ("block: move blk_exit_queue into __blk_release_queue") moves blk_exit_queue into __blk_release_queue for simplying the fast path in generic_make_request(), then causes oops during freeing requests of sched tags in __blk_release_queue(). Fix the above issue by move freeing request pool of sched tags into blk_cleanup_queue(), this way is safe becasue queue has been frozen and no any in-queue requests at that time. Freeing sched tags has to be kept in queue's release handler becasue there might be un-completed dispatch activity which might refer to sched tags. Cc: Bart Van Assche <[email protected]> Cc: Christoph Hellwig <[email protected]> Fixes: 47cdee29ef9d94e485eb08f962c74943023a5271 ("block: move blk_exit_queue into __blk_release_queue") Tested-by: Yi Zhang <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-06-07Merge tag 'drm-intel-fixes-2019-06-06' of ↵Dave Airlie5-7/+46
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Include gvt-fixes-2019-06-05 Signed-off-by: Dave Airlie <[email protected]> From: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-07Merge branch 'malidp-fixes' of git://linux-arm.org/linux-ld into drm-fixesDave Airlie10-29/+44
Assorted set of patches for Arm DRM drivers that I maintain in my tree. Signed-off-by: Dave Airlie <[email protected]> From: Liviu Dudau <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-06Merge branch 'parisc-5.2-3' of ↵Linus Torvalds14-28/+50
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: - Fix crashes when accessing PCI devices on some machines like C240 and J5000. The crashes were triggered because we replaced cache flushes by nops in the alternative coding where we shouldn't for some machines. - Dave fixed a race in the usage of the sr1 space register when used to load the coherence index. - Use the hardware lpa instruction to to load the physical address of kernel virtual addresses in the iommu driver code. - The kernel may fail to link when CONFIG_MLONGCALLS isn't set. Solve that by rearranging functions in the final vmlinux executeable. - Some defconfig cleanups and removal of compiler warnings. * 'parisc-5.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix crash due alternative coding for NP iopdir_fdc bit parisc: Use lpa instruction to load physical addresses in driver code parisc: configs: Remove useless UEVENT_HELPER_PATH parisc: Use implicit space register selection for loading the coherence index of I/O pdirs parisc: Fix compiler warnings in float emulation code parisc/slab: cleanup after /proc/slab_allocators removal parisc: Allow building 64-bit kernel without -mlong-calls compiler option parisc: Kconfig: remove ARCH_DISCARD_MEMBLOCK
2019-06-06Merge branch 'linus' of ↵Linus Torvalds2-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes a regression that breaks the jitterentropy RNG and a potential memory leak in hmac" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: hmac - fix memory leak in hmac_init_tfm() crypto: jitterentropy - change back to module_init()
2019-06-06Merge tag 'xfs-5.2-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds2-3/+11
Pull xfs fixes from Darrick Wong: "Here are a couple more bug fixes for 5.2. Changes since last update: - Fix some forgotten strings in a log debugging function - Fix incorrect unit conversion in online fsck code" * tag 'xfs-5.2-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: inode btree scrubber should calculate im_boffset correctly xfs: fix broken log reservation debugging
2019-06-06Merge tag 'gfs2-v5.2.fixes' of ↵Linus Torvalds6-31/+15
git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 Pull gfs2 fix from Andreas Gruenbacher: "A revert for a patch that turned out to be broken" * tag 'gfs2-v5.2.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2: Revert "gfs2: Replace gl_revokes with a GLF flag"
2019-06-06Merge tag 'ovl-fixes-5.2-rc4' of ↵Linus Torvalds8-22/+249
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs Pull overlayfs fixes from Miklos Szeredi: "Here's one fix for a class of bugs triggered by syzcaller, and one that makes xfstests fail less" * tag 'ovl-fixes-5.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs: ovl: doc: add non-standard corner cases ovl: detect overlapping layers ovl: support the FS_IOC_FS[SG]ETXATTR ioctls
2019-06-06Merge tag 'fuse-fixes-5.2-rc4' of ↵Linus Torvalds2-12/+38
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse Pull fuse fixes from Miklos Szeredi: "This fixes a leaked inode lock in an error cleanup path and a data consistency issue with copy_file_range(). It also adds a new flag for the WRITE request that allows userspace filesystems to clear suid/sgid bits on the file if necessary" * tag 'fuse-fixes-5.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse: fuse: extract helper for range writeback fuse: fix copy_file_range() in the writeback case fuse: add FUSE_WRITE_KILL_PRIV fuse: fallocate: fix return with locked inode
2019-06-06Merge tag 'nfs-for-5.2-2' of git://git.linux-nfs.org/projects/anna/linux-nfsLinus Torvalds3-37/+28
Pull NFS client fixes from Anna Schumaker: "These are mostly stable bugfixes found during testing, many during the recent NFS bake-a-thon. Stable bugfixes: - SUNRPC: Fix regression in umount of a secure mount - SUNRPC: Fix a use after free when a server rejects the RPCSEC_GSS credential - NFSv4.1: Again fix a race where CB_NOTIFY_LOCK fails to wake a waiter - NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled Other bugfixes: - xprtrdma: Use struct_size() in kzalloc()" * tag 'nfs-for-5.2-2' of git://git.linux-nfs.org/projects/anna/linux-nfs: NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled NFSv4.1: Again fix a race where CB_NOTIFY_LOCK fails to wake a waiter SUNRPC: Fix a use after free when a server rejects the RPCSEC_GSS credential SUNRPC fix regression in umount of a secure mount xprtrdma: Use struct_size() in kzalloc()
2019-06-06vfio/mdev: Synchronize device create/remove with parent removalParav Pandit2-18/+56
In following sequences, child devices created while removing mdev parent device can be left out, or it may lead to race of removing half initialized child mdev devices. issue-1: -------- cpu-0 cpu-1 ----- ----- mdev_unregister_device() device_for_each_child() mdev_device_remove_cb() mdev_device_remove() create_store() mdev_device_create() [...] device_add() parent_remove_sysfs_files() /* BUG: device added by cpu-0 * whose parent is getting removed * and it won't process this mdev. */ issue-2: -------- Below crash is observed when user initiated remove is in progress and mdev_unregister_driver() completes parent unregistration. cpu-0 cpu-1 ----- ----- remove_store() mdev_device_remove() active = false; mdev_unregister_device() parent device removed. [...] parents->ops->remove() /* * BUG: Accessing invalid parent. */ This is similar race like create() racing with mdev_unregister_device(). BUG: unable to handle kernel paging request at ffffffffc0585668 PGD e8f618067 P4D e8f618067 PUD e8f61a067 PMD 85adca067 PTE 0 Oops: 0000 [#1] SMP PTI CPU: 41 PID: 37403 Comm: bash Kdump: loaded Not tainted 5.1.0-rc6-vdevbus+ #6 Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016 RIP: 0010:mdev_device_remove+0xfa/0x140 [mdev] Call Trace: remove_store+0x71/0x90 [mdev] kernfs_fop_write+0x113/0x1a0 vfs_write+0xad/0x1b0 ksys_write+0x5a/0xe0 do_syscall_64+0x5a/0x210 entry_SYSCALL_64_after_hwframe+0x49/0xbe Therefore, mdev core is improved as below to overcome above issues. Wait for any ongoing mdev create() and remove() to finish before unregistering parent device. This continues to allow multiple create and remove to progress in parallel for different mdev devices as most common case. At the same time guard parent removal while parent is being accessed by create() and remove() callbacks. create()/remove() and unregister_device() are synchronized by the rwsem. Refactor device removal code to mdev_device_remove_common() to avoid acquiring unreg_sem of the parent. Fixes: 7b96953bc640 ("vfio: Mediated device Core driver") Signed-off-by: Parav Pandit <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Alex Williamson <[email protected]>
2019-06-06vfio/mdev: Avoid creating sysfs remove file on stale device removalParav Pandit1-3/+1
If device is removal is initiated by two threads as below, mdev core attempts to create a syfs remove file on stale device. During this flow, below [1] call trace is observed. cpu-0 cpu-1 ----- ----- mdev_unregister_device() device_for_each_child mdev_device_remove_cb mdev_device_remove user_syscall remove_store() mdev_device_remove() [..] unregister device(); /* not found in list or * active=false. */ sysfs_create_file() ..Call trace Now that mdev core follows correct device removal sequence of the linux bus model, remove shouldn't fail in normal cases. If it fails, there is no point of creating a stale file or checking for specific error status. kernel: WARNING: CPU: 2 PID: 9348 at fs/sysfs/file.c:327 sysfs_create_file_ns+0x7f/0x90 kernel: CPU: 2 PID: 9348 Comm: bash Kdump: loaded Not tainted 5.1.0-rc6-vdevbus+ #6 kernel: Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016 kernel: RIP: 0010:sysfs_create_file_ns+0x7f/0x90 kernel: Call Trace: kernel: remove_store+0xdc/0x100 [mdev] kernel: kernfs_fop_write+0x113/0x1a0 kernel: vfs_write+0xad/0x1b0 kernel: ksys_write+0x5a/0xe0 kernel: do_syscall_64+0x5a/0x210 kernel: entry_SYSCALL_64_after_hwframe+0x49/0xbe Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Parav Pandit <[email protected]> Signed-off-by: Alex Williamson <[email protected]>
2019-06-06pktgen: do not sleep with the thread lock held.Paolo Abeni1-0/+11
Currently, the process issuing a "start" command on the pktgen procfs interface, acquires the pktgen thread lock and never release it, until all pktgen threads are completed. The above can blocks indefinitely any other pktgen command and any (even unrelated) netdevice removal - as the pktgen netdev notifier acquires the same lock. The issue is demonstrated by the following script, reported by Matteo: ip -b - <<'EOF' link add type dummy link add type veth link set dummy0 up EOF modprobe pktgen echo reset >/proc/net/pktgen/pgctrl { echo rem_device_all echo add_device dummy0 } >/proc/net/pktgen/kpktgend_0 echo count 0 >/proc/net/pktgen/dummy0 echo start >/proc/net/pktgen/pgctrl & sleep 1 rmmod veth Fix the above releasing the thread lock around the sleep call. Additionally we must prevent racing with forcefull rmmod - as the thread lock no more protects from them. Instead, acquire a self-reference before waiting for any thread. As a side effect, running rmmod pktgen while some thread is running now fails with "module in use" error, before this patch such command hanged indefinitely. Note: the issue predates the commit reported in the fixes tag, but this fix can't be applied before the mentioned commit. v1 -> v2: - no need to check for thread existence after flipping the lock, pktgen threads are freed only at net exit time - Fixes: 6146e6a43b35 ("[PKTGEN]: Removes thread_{un,}lock() macros.") Reported-and-tested-by: Matteo Croce <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-06Merge tag 'for-rc-adfs' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds4-129/+89
Pull ADFS cleanups/fixes from Russell King: "As a result of some of Al Viro's great work, here are a few cleanups with fixes for adfs: - factor out filename comparison, so we can be sure that adfs_compare() (used for namei compare) and adfs_match() (used for lookup) have the same behaviour. - factor out filename lowering (which is not the same as tolower() which will lower top-bit-set characters) to ensure that we have the same behaviour when comparing filenames as when we hash them. - factor out the object fixups, so we are applying all fixups to directory objects in the same way, independent of the disk format. - factor out the object name fixup (into the previously factored out function) to ensure that filenames are appropriately translated - for example, adfs allows '/' in filenames, which being the Unix path separator, need to be translated to a different character, which is normally '.' (DOS 8.3 filenames represent the . as a / on adfs, so this is the expected reverse translation.) - remove filename truncation; Al asked about this and apparently the decision is to remove it. In any case, adfs's truncation was buggy, so this rids us of that bug by removing the truncation feature. - we now have only one location which adds the "filetype" suffix to the filename, so there's no point that code being out of line. - since we translate '/' into '.', an adfs filename of "/" or "//" would end up being translated to "." and ".." which have special meanings. In this case, change the first character to "^" to avoid these special directory names being abused" * tag 'for-rc-adfs' of git://git.armlinux.org.uk/~rmk/linux-arm: fs/adfs: fix filename fixup handling for "/" and "//" names fs/adfs: move append_filetype_suffix() into adfs_object_fixup() fs/adfs: remove truncated filename hashing fs/adfs: factor out filename fixup fs/adfs: factor out object fixups fs/adfs: factor out filename case lowering fs/adfs: factor out filename comparison
2019-06-06net: mvpp2: Use strscpy to handle stat stringsMaxime Chevallier1-2/+2
Use a safe strscpy call to copy the ethtool stat strings into the relevant buffers, instead of a memcpy that will be accessing out-of-bound data. Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics") Signed-off-by: Maxime Chevallier <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-06net: rds: fix memory leak in rds_ib_flush_mr_poolZhu Yanjun1-4/+6
When the following tests last for several hours, the problem will occur. Server: rds-stress -r 1.1.1.16 -D 1M Client: rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M -T 30 The following will occur. " Starting up.... tsks tx/s rx/s tx+rx K/s mbi K/s mbo K/s tx us/c rtt us cpu % 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 " >From vmcore, we can find that clean_list is NULL. >From the source code, rds_mr_flushd calls rds_ib_mr_pool_flush_worker. Then rds_ib_mr_pool_flush_worker calls " rds_ib_flush_mr_pool(pool, 0, NULL); " Then in function " int rds_ib_flush_mr_pool(struct rds_ib_mr_pool *pool, int free_all, struct rds_ib_mr **ibmr_ret) " ibmr_ret is NULL. In the source code, " ... list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail); if (ibmr_ret) *ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode); /* more than one entry in llist nodes */ if (clean_nodes->next) llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list); ... " When ibmr_ret is NULL, llist_entry is not executed. clean_nodes->next instead of clean_nodes is added in clean_list. So clean_nodes is discarded. It can not be used again. The workqueue is executed periodically. So more and more clean_nodes are discarded. Finally the clean_list is NULL. Then this problem will occur. Fixes: 1bc144b62524 ("net, rds, Replace xlist in net/rds/xlist.h with llist") Signed-off-by: Zhu Yanjun <[email protected]> Acked-by: Santosh Shilimkar <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-06Merge branch 'ipv6-fix-EFAULT-on-sendto-with-icmpv6-and-hdrincl'David S. Miller1-7/+18
Olivier Matz says: ==================== ipv6: fix EFAULT on sendto with icmpv6 and hdrincl The following code returns EFAULT (Bad address): s = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6); setsockopt(s, SOL_IPV6, IPV6_HDRINCL, 1); sendto(ipv6_icmp6_packet, addr); /* returns -1, errno = EFAULT */ The problem is fixed in the second patch. The first one aligns the code to ipv4, to avoid a race condition in the second patch. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-06-06ipv6: fix EFAULT on sendto with icmpv6 and hdrinclOlivier Matz1-5/+8
The following code returns EFAULT (Bad address): s = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6); setsockopt(s, SOL_IPV6, IPV6_HDRINCL, 1); sendto(ipv6_icmp6_packet, addr); /* returns -1, errno = EFAULT */ The IPv4 equivalent code works. A workaround is to use IPPROTO_RAW instead of IPPROTO_ICMPV6. The failure happens because 2 bytes are eaten from the msghdr by rawv6_probe_proto_opt() starting from commit 19e3c66b52ca ("ipv6 equivalent of "ipv4: Avoid reading user iov twice after raw_probe_proto_opt""), but at that time it was not a problem because IPV6_HDRINCL was not yet introduced. Only eat these 2 bytes if hdrincl == 0. Fixes: 715f504b1189 ("ipv6: add IPV6_HDRINCL option for raw sockets") Signed-off-by: Olivier Matz <[email protected]> Acked-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-06ipv6: use READ_ONCE() for inet->hdrincl as in ipv4Olivier Matz1-2/+10
As it was done in commit 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg") and commit 20b50d79974e ("net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()") for ipv4, copy the value of inet->hdrincl in a local variable, to avoid introducing a race condition in the next commit. Signed-off-by: Olivier Matz <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-06-06x86/fpu: Use fault_in_pages_writeable() for pre-faultingHugh Dickins1-9/+2
Since commit d9c9ce34ed5c8 ("x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails") get_user_pages_unlocked() pre-faults user's memory if a write generates a page fault while the handler is disabled. This works in general and uncovered a bug as reported by Mike Rapoport¹. It has been pointed out that this function may be fragile and a simple pre-fault as in fault_in_pages_writeable() would be a better solution. Better as in taste and simplicity: that write (as performed by the alternative function) performs exactly the same faulting of memory as before. This was suggested by Hugh Dickins and Andrew Morton. Use fault_in_pages_writeable() for pre-faulting user's stack. [ bigeasy: Write commit message. ] [ bp: Massage some. ] ¹ https://lkml.kernel.org/r/[email protected] Fixes: d9c9ce34ed5c8 ("x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe() fails") Suggested-by: Andrew Morton <[email protected]> Signed-off-by: Hugh Dickins <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Tested-by: Chris Wilson <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Dave Hansen <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jann Horn <[email protected]> Cc: linux-mm <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Pavel Machek <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: x86-ml <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-06-06nvme-rdma: use dynamic dma mapping per commandMax Gurtovoy1-17/+36
Commit 87fd125344d6 ("nvme-rdma: remove redundant reference between ib_device and tagset") caused a kernel panic when disconnecting from an inaccessible controller (disconnect during re-connection). -- nvme nvme0: Removing ctrl: NQN "testnqn1" nvme_rdma: nvme_rdma_exit_request: hctx 0 queue_idx 1 BUG: unable to handle kernel paging request at 0000000080000228 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI ... Call Trace: blk_mq_exit_hctx+0x5c/0xf0 blk_mq_exit_queue+0xd4/0x100 blk_cleanup_queue+0x9a/0xc0 nvme_rdma_destroy_io_queues+0x52/0x60 [nvme_rdma] nvme_rdma_shutdown_ctrl+0x3e/0x80 [nvme_rdma] nvme_do_delete_ctrl+0x53/0x80 [nvme_core] nvme_sysfs_delete+0x45/0x60 [nvme_core] kernfs_fop_write+0x105/0x180 vfs_write+0xad/0x1a0 ksys_write+0x5a/0xd0 do_syscall_64+0x55/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fa215417154 -- The reason for this crash is accessing an already freed ib_device for performing dma_unmap during exit_request commands. The root cause for that is that during re-connection all the queues are destroyed and re-created (and the ib_device is reference counted by the queues and freed as well) but the tagset stays alive and all the DMA mappings (that we perform in init_request) kept in the request context. The original commit fixed a different bug that was introduced during bonding (aka nic teaming) tests that for some scenarios change the underlying ib_device and caused memory leakage and possible segmentation fault. This commit is a complementary commit that also changes the wrong DMA mappings that were saved in the request context and making the request sqe dma mappings dynamic with the command lifetime (i.e. mapped in .queue_rq and unmapped in .complete). It also fixes the above crash of accessing freed ib_device during destruction of the tagset. Fixes: 87fd125344d6 ("nvme-rdma: remove redundant reference between ib_device and tagset") Reported-by: Jim Harris <[email protected]> Suggested-by: Sagi Grimberg <[email protected]> Tested-by: Jim Harris <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Max Gurtovoy <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]>
2019-06-06nvme: Fix u32 overflow in the number of namespace list calculationJaesoo Lee1-1/+2
The Number of Namespaces (nn) field in the identify controller data structure is defined as u32 and the maximum allowed value in NVMe specification is 0xFFFFFFFEUL. This change fixes the possible overflow of the DIV_ROUND_UP() operation used in nvme_scan_ns_list() by casting the nn to u64. Signed-off-by: Jaesoo Lee <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]>
2019-06-06vfio/mdev: Improve the create/remove sequenceParav Pandit3-71/+27
This patch addresses below two issues and prepares the code to address 3rd issue listed below. 1. mdev device is placed on the mdev bus before it is created in the vendor driver. Once a device is placed on the mdev bus without creating its supporting underlying vendor device, mdev driver's probe() gets triggered. However there isn't a stable mdev available to work on. create_store() mdev_create_device() device_register() ... vfio_mdev_probe() [...] parent->ops->create() vfio_ap_mdev_create() mdev_set_drvdata(mdev, matrix_mdev); /* Valid pointer set above */ Due to this way of initialization, mdev driver who wants to use the mdev, doesn't have a valid mdev to work on. 2. Current creation sequence is, parent->ops_create() groups_register() Remove sequence is, parent->ops->remove() groups_unregister() However, remove sequence should be exact mirror of creation sequence. Once this is achieved, all users of the mdev will be terminated first before removing underlying vendor device. (Follow standard linux driver model). At that point vendor's remove() ops shouldn't fail because taking the device off the bus should terminate any usage. 3. When remove operation fails, mdev sysfs removal attempts to add the file back on already removed device. Following call trace [1] is observed. [1] call trace: kernel: WARNING: CPU: 2 PID: 9348 at fs/sysfs/file.c:327 sysfs_create_file_ns+0x7f/0x90 kernel: CPU: 2 PID: 9348 Comm: bash Kdump: loaded Not tainted 5.1.0-rc6-vdevbus+ #6 kernel: Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016 kernel: RIP: 0010:sysfs_create_file_ns+0x7f/0x90 kernel: Call Trace: kernel: remove_store+0xdc/0x100 [mdev] kernel: kernfs_fop_write+0x113/0x1a0 kernel: vfs_write+0xad/0x1b0 kernel: ksys_write+0x5a/0xe0 kernel: do_syscall_64+0x5a/0x210 kernel: entry_SYSCALL_64_after_hwframe+0x49/0xbe Therefore, mdev core is improved in following ways. 1. Split the device registration/deregistration sequence so that some things can be done between initialization of the device and hooking it up to the bus respectively after deregistering it from the bus but before giving up our final reference. In particular, this means invoking the ->create() and ->remove() callbacks in those new windows. This gives the vendor driver an initialized mdev device to work with during creation. At the same time, a bus driver who wish to bind to mdev driver also gets initialized mdev device. This follows standard Linux kernel bus and device model. 2. During remove flow, first remove the device from the bus. This ensures that any bus specific devices are removed. Once device is taken off the mdev bus, invoke remove() of mdev from the vendor driver. 3. The driver core device model provides way to register and auto unregister the device sysfs attribute groups at dev->groups. Make use of dev->groups to let core create the groups and eliminate code to avoid explicit groups creation and removal. To ensure, that new sequence is solid, a below stack dump of a process is taken who attempts to remove the device while device is in use by vfio driver and user application. This stack dump validates that vfio driver guards against such device removal when device is in use. cat /proc/21962/stack [<0>] vfio_del_group_dev+0x216/0x3c0 [vfio] [<0>] mdev_remove+0x21/0x40 [mdev] [<0>] device_release_driver_internal+0xe8/0x1b0 [<0>] bus_remove_device+0xf9/0x170 [<0>] device_del+0x168/0x350 [<0>] mdev_device_remove_common+0x1d/0x50 [mdev] [<0>] mdev_device_remove+0x8c/0xd0 [mdev] [<0>] remove_store+0x71/0x90 [mdev] [<0>] kernfs_fop_write+0x113/0x1a0 [<0>] vfs_write+0xad/0x1b0 [<0>] ksys_write+0x5a/0xe0 [<0>] do_syscall_64+0x5a/0x210 [<0>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<0>] 0xffffffffffffffff This prepares the code to eliminate calling device_create_file() in subsequent patch. Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Parav Pandit <[email protected]> Signed-off-by: Alex Williamson <[email protected]>
2019-06-06SoC: rt274: Fix internal jack assignment in set_jack callbackAmadeusz Sławiński1-1/+2
When we call snd_soc_component_set_jack(component, NULL, NULL) we should set rt274->jack to passed jack, so when interrupt is triggered it calls snd_soc_jack_report(rt274->jack, ...) with proper value. This fixes problem in machine where in register, we call snd_soc_register(component, &headset, NULL), which just calls rt274_mic_detect via callback. Now when machine driver is removed "headset" will be gone, so we need to tell codec driver that it's gone with: snd_soc_register(component, NULL, NULL), but we also need to be able to handle NULL jack argument here gracefully. If we don't set it to NULL, next time the rt274_irq runs it will call snd_soc_jack_report with first argument being invalid pointer and there will be Oops. Signed-off-by: Amadeusz Sławiński <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-06ALSA: hdac: fix memory release for SST and SOF driversAmadeusz Sławiński1-1/+0
During the integration of HDaudio support, we changed the way in which we get hdev in snd_hdac_ext_bus_device_init() to use one preallocated with devm_kzalloc(), however it still left kfree(hdev) in snd_hdac_ext_bus_device_exit(). It leads to oopses when trying to rmmod and modprobe. Fix it, by just removing kfree call. SOF also uses some of the snd_hdac_ functions for HDAudio support but allocated the memory with kzalloc. A matching fix is provided separately to align all users of the snd_hdac_ library. Fixes: 6298542fa33b ("ALSA: hdac: remove memory allocation from snd_hdac_ext_bus_device_init") Reviewed-by: Takashi Iwai <[email protected]> Signed-off-by: Amadeusz Sławiński <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-06ASoC: SOF: Intel: hda: use the defined ppcap functionsZhu Yingjiang1-7/+3
There are already defined ppcap and ppcap interrupt functions, use the already defined functions for easy code read. Fixes: 8a300c8fb17 ("ASoC: SOF: Intel: Add HDA controller for Intel DSP") Reviewed-by: Takashi Iwai <[email protected]> Signed-off-by: Zhu Yingjiang <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-06ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_cardTzung-Bi Shih1-17/+10
Kernel crashes when an ASoC component rebinding. The dai_link->platforms has been reset to NULL by soc_cleanup_platform() in soc_cleanup_card_resources() when un-registering component. However, it has no chance to re-allocate the dai_link->platforms when registering the component again. Move the DAI pre-links initiation from snd_soc_register_card() to snd_soc_instantiate_card() to make sure all DAI pre-links get initiated when component rebinding. As an example, by using the following commands: - echo -n max98357a > /sys/bus/platform/drivers/max98357a/unbind - echo -n max98357a > /sys/bus/platform/drivers/max98357a/bind Got the error message: "Unable to handle kernel NULL pointer dereference at virtual address". The call trace: snd_soc_is_matching_component+0x30/0x6c soc_bind_dai_link+0x16c/0x240 snd_soc_bind_card+0x1e4/0xb10 snd_soc_add_component+0x270/0x300 snd_soc_register_component+0x54/0x6c Signed-off-by: Tzung-Bi Shih <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-06ASoC: Intel: cht_bsw_rt5672: fix kernel oops with platform_name overridePierre-Louis Bossart1-1/+1
The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: f403906da05cd ("ASoC: Intel: cht_bsw_rt5672: platform name fixup support") Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-06ASoC: Intel: cht_bsw_nau8824: fix kernel oops with platform_name overridePierre-Louis Bossart1-1/+1
The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: 4506db8043341 ("ASoC: Intel: cht_bsw_nau8824: platform name fixup support") Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-06ASoC: Intel: bytcht_es8316: fix kernel oops with platform_name overridePierre-Louis Bossart1-1/+1
The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: e4bc6b1195f64 ("ASoC: Intel: bytcht_es8316: platform name fixup support") Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-06ASoC: Intel: cht_bsw_max98090: fix kernel oops with platform_name overridePierre-Louis Bossart1-1/+1
The platform override code uses devm_ functions to allocate memory for the new name but the card device is not initialized. Fix by moving the init earlier. Fixes: 7e7e24d7c7ff0 ("ASoC: Intel: cht_bsw_max98090_ti: platform name fixup support") Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2019-06-06Revert "gfs2: Replace gl_revokes with a GLF flag"Bob Peterson6-31/+15
Commit 73118ca8baf7 introduced a glock reference counting bug in gfs2_trans_remove_revoke. Given that, replacing gl_revokes with a GLF flag is no longer useful, so revert that commit. Signed-off-by: Bob Peterson <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2019-06-06Merge tag 'misc-habanalabs-fixes-2019-06-06' of ↵Greg Kroah-Hartman3-9/+16
git://people.freedesktop.org/~gabbayo/linux into char-misc-linus Oded writes: This tag contains the following fixes: - Fix the code that checks whether we can use 2MB page size when mapping memory in the ASIC's MMU. The current code had a "hole" which happened in architectures other then x86-64. - Fix the debugfs interface to read/write from/to the device using device virtual addresses. There was a bug in the translation regarding addresses that were mapped using 2MB page size. - Fix a bug in the debug/profiling code, where the code didn't read the full address but only the lower 32-bits of the address. * tag 'misc-habanalabs-fixes-2019-06-06' of git://people.freedesktop.org/~gabbayo/linux: habanalabs: Read upper bits of trace buffer from RWPHI habanalabs: Fix virtual address access via debugfs for 2MB pages habanalabs: fix bug in checking huge page optimization
2019-06-06arm64: Silence gcc warnings about arch ABI driftDave Martin1-0/+1
Since GCC 9, the compiler warns about evolution of the platform-specific ABI, in particular relating for the marshaling of certain structures involving bitfields. The kernel is a standalone binary, and of course nobody would be so stupid as to expose structs containing bitfields as function arguments in ABI. (Passing a pointer to such a struct, however inadvisable, should be unaffected by this change. perf and various drivers rely on that.) So these warnings do more harm than good: turn them off. We may miss warnings about future ABI drift, but that's too bad. Future ABI breaks of this class will have to be debugged and fixed the traditional way unless the compiler evolves finer-grained diagnostics. Signed-off-by: Dave Martin <[email protected]> Signed-off-by: Will Deacon <[email protected]>