- 20 Feb, 2023 30 commits
-
-
Jeff Layton authored
...and remove some now-useless NULL pointer checks in its callers. Suggested-by:
NeilBrown <neilb@suse.de> Signed-off-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com>
-
Dai Ngo authored
Currently nfsd4_setup_inter_ssc returns the vfsmount of the source server's export when the mount completes. After the copy is done nfsd4_cleanup_inter_ssc is called with the vfsmount of the source server and it searches nfsd_ssc_mount_list for a matching entry to do the clean up. The problems with this approach are (1) the need to search the nfsd_ssc_mount_list and (2) the code has to handle the case where the matching entry is not found which looks ugly. The enhancement is instead of nfsd4_setup_inter_ssc returning the vfsmount, it returns the nfsd4_ssc_umount_item which has the vfsmount embedded in it. When nfsd4_cleanup_inter_ssc is called it's passed with the nfsd4_ssc_umount_item directly to do the clean up so no searching is needed and there is no need to handle the 'not found' case. Signed-off-by:
Dai Ngo <dai.ngo@oracle.com> Signed-off-by:
Olga Kornievskaia <kolga@netapp.com>
-
Chuck Lever authored
Now the entire RPC Call header parsing path is handled via struct xdr_stream-based decoders. Reviewed-by:
-
Chuck Lever authored
Clean up: With xdr_stream decoding, the @argv parameter is no longer used. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
Clean up: Saving the RPC program number in two places is unnecessary. Reviewed-by:
-
Chuck Lever authored
Clean up: Group these together for legibility. Reviewed-by:
-
Chuck Lever authored
Now that each ->accept method has been converted to use xdr_stream, the svcxdr_init_decode() calls can be hoisted back up into the generic RPC server code. The dprintk in svc_authenticate() is removed, since trace_svc_authenticate() reports the same information. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
Micro-optimizations: 1. The value of rqstp->rq_auth_stat is replaced no matter which arm of the switch is taken, so the initial assignment can be safely removed. 2. Avoid checking the value of gc->gc_proc twice in the I/O (RPC_GSS_PROC_DATA) path. The cost is a little extra code redundancy. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
Clean up: To help orient readers, name the stack variables to match the XDR field names. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
Clean up: To help orient readers, name the stack variables to match the XDR field names. For readability, I'm also going to rename the unwrap and wrap functions in a consistent manner, starting with unwrap_integ_data(). Reviewed-by:
-
Chuck Lever authored
Clean up / code de-duplication - this functionality is already available in the generic XDR layer. Reviewed-by:
-
Chuck Lever authored
The entire RPC_GSS_PROC_INIT path is converted over to xdr_stream for decoding the Call credential and verifier. Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
gss_read_verf() is already short. Fold it into its only caller. Reviewed-by:
-
Chuck Lever authored
gss_read_common_verf() is now just a wrapper for dup_netobj(), thus it can be replaced with direct calls to dup_netobj(). Reviewed-by:
-
Chuck Lever authored
Pre-requisite to replacing gss_read_common_verf(). Reviewed-by:
-
Chuck Lever authored
Since upcalls are infrequent, ensure the compiler places the upcall mechanism out-of-line from the I/O path. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Since the server-side of the Linux kernel SunRPC implementation ignores the contents of the Call's machinename field, there's no need for its RPC_AUTH_UNIX authenticator to reject names that are larger than UNX_MAXNODENAME. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
RFC 5531 defines the body of an RPC Call message like this: struct call_body { unsigned int rpcvers; unsigned int prog; unsigned int vers; unsigned int proc; opaque_auth cred; opaque_auth verf; /* procedure-specific parameters start here */ }; In the current server code, decoding a struct opaque_auth type is open-coded in several places, and is thus difficult to harden everywhere. Introduce a helper for decoding an opaque_auth within the context of a xdr_stream. This helper can be shared with all authentication flavor implemenations, even on the client-side. Done as part of hardening the server-side RPC header decoding paths. Reviewed-by: -
Chuck Lever authored
Refactor: So that the overhaul of each ->accept method can be done in separate smaller patches, temporarily move the svcxdr_init_decode() call into those methods. Reviewed-by:
-
Chuck Lever authored
Now that all vs_dispatch functions invoke svcxdr_init_decode(), it is common code and can be pushed down into the generic RPC server. Reviewed-by:
-
Richard Weinberger authored
Now with NFSD being able to cross into auto mounts, the check can be removed. Signed-off-by:
Richard Weinberger <richard@nod.at> Reviewed-by:
Ian Kent <raven@themaw.net> Reviewed-by:
Anna Schumaker <Anna.Schumaker@Netapp.com>
-
Richard Weinberger authored
This function is only used by NFSD to cross mount points. If a mount point is of type auto mount, follow_down() will not uncover it. Add LOOKUP_AUTOMOUNT to the lookup flags to have ->d_automount() called when NFSD walks down the mount tree. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Richard Weinberger authored
Currently nfsd_mountpoint() tests for mount points using d_mountpoint(), this works only when a mount point is already uncovered. In our case the mount point is of type auto mount and can be coverted. i.e. ->d_automount() was not called. Using d_managed() nfsd_mountpoint() can test whether a mount point is either already uncovered or can be uncovered later. Signed-off-by:
-
- 19 Feb, 2023 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fix from Thomas Gleixner: "A single fix for x86. Revert the recent change to the MTRR code which aimed to support SEV-SNP guests on Hyper-V. It caused a regression on XEN Dom0 kernels. The underlying issue of MTTR (mis)handling in the x86 code needs some deeper investigation and is definitely not 6.2 material" * tag 'x86-urgent-2023-02-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mtrr: Revert 90b926e6 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case")
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Thomas Gleixner: "A fix for a long standing issue in the alarmtimer code. Posix-timers armed with a short interval with an ignored signal result in an unpriviledged DoS. Due to the ignored signal the timer switches into self rearm mode. This issue had been "fixed" before but a rework of the alarmtimer code 5 years ago lost that workaround. There is no real good solution for this issue, which is also worked around in the core posix-timer code in the same way, but it certainly moved way up on the ever growing todo list" * tag 'timers-urgent-2023-02-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: alarmtimer: Prevent starvation by small intervals and SIG_IGN
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fix from Thomas Gleixner: "A single build fix for the PCI/MSI infrastructure. The addition of the new alloc/free interfaces in this cycle forgot to add stub functions for pci_msix_alloc_irq_at() and pci_msix_free_irq() for the CONFIG_PCI_MSI=n case" * tag 'irq-urgent-2023-02-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: PCI/MSI: Provide missing stubs for CONFIG_PCI_MSI=n
-
- 18 Feb, 2023 4 commits
-
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull kvm/x86 fixes from Paolo Bonzini: - zero all padding for KVM_GET_DEBUGREGS - fix rST warning - disable vPMU support on hybrid CPUs * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: initialize all of the kvm_debugregs structure before sending it to userspace perf/x86: Refuse to export capabilities for hybrid PMUs KVM: x86/pmu: Disable vPMU support on hybrid CPUs (host PMUs) Documentation/hw-vuln: Fix rST warning
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull arm64 regression fix from Will Deacon: "Apologies for the _extremely_ late pull request here, but we had a 'perf' (i.e. CPU PMU) regression on the Apple M1 reported on Wednesday [1] which was introduced by bd275681 ("perf: Rewrite core context handling") during the merge window. Mark and I looked into this and noticed an additional problem caused by the same patch, where the 'CHAIN' event (used to combine two adjacent 32-bit counters into a single 64-bit counter) was not being filtered correctly. Mark posted a series on Thursday [2] which addresses both of these regressions and I queued it the same day. The changes are small, self-contained and have been confirmed to fix the original regression. Summary: - Fix 'perf' regression for non-standard CPU PMU hardware (i.e. Apple M1)" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: perf: reject CHAIN events at creation time arm_pmu: fix event CPU filtering
-
git://git.kernel.dk/linuxLinus Torvalds authored
Pull block fix from Jens Axboe: "I guess this is what can happen when you prep things early for going away, something else comes in last minute. This one fixes another regression in 6.2 for NVMe, from this release, and hence we should probably get it submitted for 6.2. Still waiting for the original reporter (see bugzilla linked in the commit) to test this, but Keith managed to setup and recreate the issue and tested the patch that way" * tag 'block-6.2-2023-02-17' of git://git.kernel.dk/linux: nvme-pci: refresh visible attrs for cmb attributes
-
Linus Torvalds authored
Merge tag 'mm-hotfixes-stable-2023-02-17-15-16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "Six hotfixes. Five are cc:stable: four for MM, one for nilfs2. Also a MAINTAINERS update" * tag 'mm-hotfixes-stable-2023-02-17-15-16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: nilfs2: fix underflow in second superblock position calculations hugetlb: check for undefined shift on 32 bit architectures mm/migrate: fix wrongly apply write bit after mkdirty on sparc64 MAINTAINERS: update FPU EMULATOR web page mm/MADV_COLLAPSE: set EAGAIN on unexpected page refcount mm/filemap: fix page end in filemap_get_read_batch
-
- 17 Feb, 2023 2 commits
-
-
Ryusuke Konishi authored
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second superblock, underflows when the argument device size is less than 4096 bytes. Therefore, when using this macro, it is necessary to check in advance that the device size is not less than a lower limit, or at least that underflow does not occur. The current nilfs2 implementation lacks this check, causing out-of-bound block access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024) In addition, when trying to resize the filesystem to a size below 4096 bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number of segments to nilfs_sufile_resize(), corrupting parameters such as the number of segments in superblocks. This causes excessive loop iterations in nilfs_sufile_resize() during a subsequent resize ioctl, causing semaphore ns_segctor_sem to block for a long time and hang the writer thread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> ... Call Trace: <TASK> folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ... This fixes these issues by inserting appropriate minimum device size checks or anti-underflow checks, depending on where the macro is used. Link: https://lkml.kernel.org/r/0000000000004e1dfa05f4a48e6b@google.com Link: https://lkml.kernel.org/r/20230214224043.24141-1-konishi.ryusuke@gmail.comSigned-off-by:Ryusuke Konishi <konishi.ryusuke@gmail.com> Reported-by: <syzbot+f0c4082ce5ebebdac63b@syzkaller.appspotmail.com> Tested-by:
Andrew Morton <akpm@linux-foundation.org>
-
Mike Kravetz authored
Users can specify the hugetlb page size in the mmap, shmget and memfd_create system calls. This is done by using 6 bits within the flags argument to encode the base-2 logarithm of the desired page size. The routine hstate_sizelog() uses the log2 value to find the corresponding hugetlb hstate structure. Converting the log2 value (page_size_log) to potential hugetlb page size is the simple statement: 1UL << page_size_log Because only 6 bits are used for page_size_log, the left shift can not be greater than 63. This is fine on 64 bit architectures where a long is 64 bits. However, if a value greater than 31 is passed on a 32 bit architecture (where long is 32 bits) the shift will result in undefined behavior. This was generally not an issue as the result of the undefined shift had to exactly match hugetlb page size to proceed. Recent improvements in runtime checking have resulted in this undefined behavior throwing errors such as reported below. Fix by comparing page_size_log to BITS_PER_LONG before doing shift. Link: https://lkml.kernel.org/r/20230216013542.138708-1-mike.kravetz@oracle.com Link: https://lore.kernel.org/lkml/CA+G9fYuei_Tr-vN9GS7SfFyU1y9hNysnf=PB7kT0=yv4MiPgVg@mail.gmail.com/ Fixes: 42d7395f ("mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB") Signed-off-by:
Mike Kravetz <mike.kravetz@oracle.com> Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Reviewed-by:
Jesper Juhl <jesperjuhl76@gmail.com> Acked-by:
Muchun Song <songmuchun@bytedance.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
-
