There is an issue in clang's ThinLTO caching (enabled for the kernel via
'--thinlto-cache-dir') with .incbin, which the kernel occasionally uses
to include data within the kernel, such as the .config file for
/proc/config.gz. For example, when changing the .config and rebuilding
vmlinux, the copy of .config in vmlinux does not match the copy of
.config in the build folder:
$ echo 'CONFIG_LTO_NONE=n
CONFIG_LTO_CLANG_THIN=y
CONFIG_IKCONFIG=y
CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux
...
$ grep CONFIG_HEADERS_INSTALL .config
CONFIG_HEADERS_INSTALL=y
$ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
CONFIG_HEADERS_INSTALL=y
$ scripts/config -d HEADERS_INSTALL
$ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux
...
UPD kernel/config_data
GZIP kernel/config_data.gz
CC kernel/configs.o
...
LD vmlinux
...
$ grep CONFIG_HEADERS_INSTALL .config
# CONFIG_HEADERS_INSTALL is not set
$ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
CONFIG_HEADERS_INSTALL=y
Without '--thinlto-cache-dir' or when using full LTO, this issue does
not occur.
Benchmarking incremental builds on a few different machines with and
without the cache shows a 20% increase in incremental build time without
the cache when measured by touching init/main.c and running 'make all'.
ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host:
Benchmark 1: With ThinLTO cache
Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s]
Range (min … max): 56.109 s … 56.594 s 10 runs
Benchmark 2: Without ThinLTO cache
Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s]
Range (min … max): 67.059 s … 68.556 s 10 runs
Summary
With ThinLTO cache ran
1.20 ± 0.01 times faster than Without ThinLTO cache
ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host:
Benchmark 1: With ThinLTO cache
Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s]
Range (min … max): 85.447 s … 86.244 s 10 runs
Benchmark 2: Without ThinLTO cache
Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s]
Range (min … max): 103.286 s … 104.124 s 10 runs
Summary
With ThinLTO cache ran
1.21 ± 0.00 times faster than Without ThinLTO cache
While it is unfortunate to take this performance improvement off the
table, correctness is more important. If/when this is fixed in LLVM, it
can potentially be brought back in a conditional manner. Alternatively,
a developer can just disable LTO if doing incremental compiles quickly
is important, as a full compile cycle can still take over a minute even
with the cache and it is unlikely that LTO will result in functional
differences for a kernel change.
Cc: stable@vger.kernel.org
Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO")
Reported-by: Yifan Hong <elsk@google.com>
Closes: https://github.com/ClangBuiltLinux/linux/issues/2021
Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Change-Id: I5e416fd740e48f2e3920d9d6917a600f179e4885
When doing non-clean builds and switching between CONFIG_LTO=n and
CONFIG_LTO=y, the build system (correctly) didn't notice that assembly
and LTO-excluded C object files were rewritten in place by objtool (to
add the .orc_unwind* sections), since their build command lines were the
same between CONFIG_LTO=y and CONFIG_LTO=n. The objtool step would fail:
vmlinux.o: warning: objtool: file already has .orc_unwind section, skipping
make: *** [Makefile:1194: vmlinux] Error 255
Avoid this by making sure the build will see a difference between an LTO
and non-LTO build (by including "-fno-lto" in KBUILD_*FLAGS). This will
get ignored when CC_FLAGS_LTO is present, and will not be included at
all when CONFIG_LTO=n.
Change-Id: I7b6a3221d0972ad13db0d138c66f3789eec60062
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Commit 27f2a4db76e8 ("Makefile: fix GDB warning with CONFIG_RELR")
added --use-android-relr-tags to fix a GDB warning
BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn'
The GDB warning has been fixed in version 11.2.
The DT_ANDROID_RELR tag was deprecated since DT_RELR was standardized.
Thus, --use-android-relr-tags should be removed. While making the
change, try -z pack-relative-relocs, which is supported since LLD 15.
Keep supporting --pack-dyn-relocs=relr as well for older LLD versions.
There is no indication of obsolescence for --pack-dyn-relocs=relr.
As of today, GNU ld supports the latter option for x86 and powerpc64
ports and has no intention to support --pack-dyn-relocs=relr. In the
absence of the glibc symbol version GLIBC_ABI_DT_RELR,
--pack-dyn-relocs=relr and -z pack-relative-relocs are identical in
ld.lld.
GNU ld and newer versions of LLD report warnings (instead of errors) for
unknown -z options. Only errors lead to non-zero exit codes. Therefore,
we should test --pack-dyn-relocs=relr before testing
-z pack-relative-relocs.
Link: https://github.com/ClangBuiltLinux/linux/issues/1057
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a619b58721f0a03fd91c27670d3e4c2fb0d88f1e
Signed-off-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Change-Id: Ib4ca450ed863e16651a8725c721e7e0389c992ae
kgsl-3d0 is dummy device which don't need cmo
return success along with suppressing warnings for dummy clients.
Change-Id: I4ddcee898931cf017e21c8ecbfec863b4566d962
Signed-off-by: Srinivasarao Pathipati <quic_c_spathi@quicinc.com>
This reverts msm-5.10 commit b84bd97e37f8ac3a0f3194ebcbb1fa962e42cd73.
Warnings for direct dma clients during cache operations are now being
handled by dma-buf driver. Instead of doing dma_buf_unmap_attachment
early if we do it in destroy path, it helps in saving cycles and
improving performance during app launch.
Change-Id: Ic66dd3b66136318abf59685f95fee17890377fd4
Signed-off-by: Pankaj Gupta <quic_gpankaj@quicinc.com>
Signed-off-by: Archana Sriram <quic_c_apsrir@quicinc.com>
This breaks camera on ibiza but required on newer devices.
This conditionally reverts commit 4fbb1700ef.
Change-Id: Iec7e8d593bb37b637d1f876228bf73b0944e01ff
* sm8350/lineage-20:
disp: msm: Avoid UB in VBIF register shift calculation
disp: msm: Fix division by zero during ESD recovery
disp: msm: dsi: Nullify display modes after kfree
devfreq: Fix suspend callback for non-zero min_freq
devfreq: Fix PM callbacks to support zero frequency
devfreq: Allow zero values in opp table
devfreq: govener_memlat: fix cpu_hotplug_lock recursive lock warning
devfreq: governor_memlat: avoid deadlock due to cpu_grp->mons_lock usage
devfreq: governor_bw_hwmon: fix deadlock warning due to state_lock usage
msm: kgsl: Fix UBSAN warnings
msm: kgsl: Use kthread instead of workqueue for event work
BACKPORT: msm: kgsl: Avoid unmap after kgsl system suspend
fixup! BACKPORT: kbuild: check the minimum assembler version in Kconfig
Change-Id: I2f722ad0f53673157f841eaf0ef032e4f5b1703d
Left-shifting a 32-bit integer by 32 bits or more results in UB. The
common values for vbif_xin_id[] are {10, 11} which means reg_shift
becomes 40/44. For IDs >= 8, the shift is meant to be relative to the
second 32-bit register, not to the first. Fix this issue by masking the
ID so that it will properly describe the intended shift.
Change-Id: Icd530a3bb7cfd9d087e2aecc763d24f775e20466
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
The 'display->modes' pointer must be set to NULL immediately
after calling kfree on it to prevent potential double-free
vulnerabilities or use-after-free issues.
This change ensures robust memory management by clearing the
pointer to previously freed memory, aligning with best practices
for kernel memory deallocation.
Change-Id: I4fd939bc6ee5f3d9c506f0c311a9400f366e7fd2
Signed-off-by: Vedant Yevale <vyevale@qti.qualcomm.com>
(cherry picked from commit 1d3c5a477ea8f6aca1158209e1b87209c21c61f5)
With commit commit 921884ca1498 ("devfreq: Fix PM
callbacks to support zero frequency"), suspend_freq
of zero is considered valid.
However, the devfreq_set_target is called with zero frequency.
To avoid this, do not call devfreq_set_target if the
suspend_freq is less than the minimun allowed frequency.
Change-Id: I506165d28395eb67138ae2dac53e842357809bbb
Signed-off-by: Shreyas K K <shrekk@codeaurora.org>
It is perfectly valid for a device to have a zero frequency, usually
it denotes a power collapse. To support this, fix the PM suspend
callback to allow the suspend_freq to be zero.
Change-Id: Id10f95b59b219e82e0695f80361aa6b35cdc5137
Signed-off-by: Shreyas K K <shrekk@codeaurora.org>
commit ab8f58ad72 ("PM / devfreq: Set
min/max_freq when adding the devfreq device") introduces a change
where an error in finding the ceil or floor is returned as a
zero frequency. This return of zero is treated as error condition
from the callsites.
It is perfectly valid for a device to have a zero frequency, usually
it denotes a power collapse. This valid return of zero frequency ends
up being treated as an error condition.
Fix it.
Change-Id: I5eb6fa622d6fe09207746b96dce05d0b58b233dc
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Shreyas K K <shrekk@codeaurora.org>
Possible unsafe locking scenario:
CPU0
----
lock(cpu_hotplug_lock.rw_sem);
lock(cpu_hotplug_lock.rw_sem);
*** DEADLOCK ***
Below code under start_hwmon may cause this recursive locking.
get_online_cpus();
for_each_cpu(cpu, cpu_possible_mask) {
if (!cpumask_test_cpu(cpu, cpu_online_mask))
per_cpu(cpu_is_hp, cpu) = true;
}
ret = memlat_event_cpu_hp_init();
put_online_cpus();
get_online_cpus() acquires cpu_hotplug_lock.rw_sem lock.
Then memlat_event_cpu_hp_init() -> __cpuhp_setup_state() tries
to acquire the same lock again.
Use cpuslocked version of __cpuhp_setup_state() to avoid this warning.
Change-Id: Ied9fe53d02c74816f38c1efe954cea91f9831cc7
Signed-off-by: Abhishek Shah <abhshah@codeaurora.org>
lockdep is detecting possible circular locking dependency
due to cpu_grp->mons_lock mutex as shown below:
Chain exists of:
&cpu_grp->mons_lock --> state_lock#3 --> devfreq_list_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(devfreq_list_lock);
lock(state_lock#3);
lock(devfreq_list_lock);
lock(&cpu_grp->mons_lock);
*** DEADLOCK ***
Below is partial call stacks (in reverse order) showing relevant
locking paths:
Call stack for CPU0:
start_hwmon+0x6c/0x5d0 [may acquire &cpu_grp->mons_lock]
devfreq_memlat_ev_handler+0x2f4/0x3f8
devfreq_add_device+0x418/0x538 [may acquire devfreq_list_lock]
devfreq_add_icc+0x41c/0x528
devfreq_icc_probe+0x20/0x30
Call stack for CPU1:
devfreq_add_governor+0x3c/0x260 [may acquire devfreq_list_lock]
register_memlat+0x84/0x100
memlat_mon_probe+0x414/0x550 [may acquire &cpu_grp->mons_lock]
arm_memlat_mon_driver_probe+0x120/0x3b8
Practically, this race is not possible, since devfreq_add_device first
tries to find the governor, and only if it is succeeds,
devfreq_memlat_ev_handler is called. And the governor would be found
only if devfreq_add_governor has added it priorly.
We have mechanism(initcall_level) in place to make sure that
governor is added before devfreq_add_device happens.
In attempt to quiet the lockdep warning, below fix is adopted:
cpu_grp gets allocated by memlat_cpu_grp_probe, but it is used by its
multiple memlat_mon children's memlat_mon_probe. cpu_grp->mons_lock is
used to prevent race between them for access to cpu_grp and members.
Use a new lock - cpu_grp->init_mons_lock - for the probe routine,
and continue using cpu_grp->mons_lock in other routines.
Change-Id: Ie59c28de0a40914fb120a305067ef0fe504a4455
Signed-off-by: Abhishek Shah <abhshah@codeaurora.org>
lockdep is detecting possible circular locking dependency
due to state_lock mutex as shown below:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(devfreq_list_lock);
lock(state_lock#2);
lock(devfreq_list_lock);
lock(state_lock#2);
*** DEADLOCK ***
Below is partial call stacks (in reverse order) showing relevant
locking paths:
Call stack for CPU0:
devfreq_bw_hwmon_ev_handler+0x4c/0x5e0 [may acquire &state_lock]
devfreq_add_device+0x418/0x538 [may acquire &devfreq_list_lock]
devfreq_add_icc+0x41c/0x528
devfreq_icc_probe+0x20/0x30
Call stack for CPU1:
devfreq_add_governor+0x3c/0x260 [may acquire &devfreq_list_lock]
register_bw_hwmon+0x1e8/0x248 [may acquire &state_lock]
bimc_bwmon_driver_probe+0x310/0x408
Practically, this race is not possible, since devfreq_add_device first
tries to find the governor, and only if it is succeeds,
devfreq_bw_hwmon_ev_handler is called. And the governor would be found
only if devfreq_add_governor has added it priorly.
We have mechanism(initcall_level) in place to make sure that
governor is added before devfreq_add_device happens.
In attempt to quiet the lockdep warning, below fix is adopted:
Since state_lock mutex has different purpose, introduce a new
event_handle_lock mutex for devfreq_bw_hwmon_ev_handler
to avoid this warning.
Change-Id: I53c4514aa2357bf39e9405683f5e73ada0160ba5
Signed-off-by: Abhishek Shah <abhshah@codeaurora.org>
Currently a workqueue is being used to process the event work. In
certain scenarios like when most of CPU cores are busy, there can be a
significant delay between the actual timestamp retire event and when the
work is processed by the events workqueue as workqueues cannot have RT
priority. Hence use kthread instead of workqueue for event work.
Change-Id: Ib1ec7fa1ec3a133d03104c9a029dcc4c06180609
Signed-off-by: Puranam V G Tejaswi <quic_pvgtejas@quicinc.com>
Signed-off-by: Pankaj Gupta <quic_gpankaj@quicinc.com>
Smmu driver cannot safely handle unmap request after smmu device is
system suspended. So ensure kgsl doesn't initiate an unmap request
after kgsl system suspend as smmu device suspend happens after gpu's.
Kgsl does unmap from the following paths:
1. Userspace unmap calls
2. Mementry workqueue
3. During reclaim
(1) is not a concern as userspace will be collapse before driver
suspend. So we need to ensure that mementry/events workqueues are
flushed and we don't participate in reclaim to take care off
(2) & (3) before kgsl system suspend completes.
[mkbestas]: Ignore kgsl_reclaim parts that don't exist in 5.4
Change-Id: Ibe2c8f5a90fd4d8d4cf212f17c04c52873738e36
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Since minimum assembler version checking is not required in 5.10, it should not be required in 4.19 either.
Change-Id: I333454a3dffb4798295adf9b3038ebc9acda948e
* sm8350/lineage-20:
msm: vidc/cvp: fix callback type for msm_vidc/cvp_callback
msm: vidc/cvp: fix function type for hfi_cmd_response_callback
msm: vidc/cvp: Fix handle_cmd_response parameter type
Change-Id: I653aa4fac07801578e806b639e91d9361db5fe36
Bug: 202785178
Test: test_fuse passes on linux, feature works on cuttlefish
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: If5d56aa5ff5bf5ee660073ac8f1ef1573a74cfd1
This reverts commit cb8dc8a108.
As pointed out on gerrit[1]:
> This revert is wrong. `android12-5.4` doesn't have
> "sysctl: pass kernel pointers to ->proc_handler" but this kernel does.
[1] - https://review.lineageos.org/c/LineageOS/android_kernel_qcom_sm8350/+/482457
Change-Id: I72cd996f6739a67cf78141843e2d933f19e2e92b
Signed-off-by: Alexander Martinz <amartinz@shiftphones.com>
Manual manipulation of vma->vm_file and file reference counts in
fuse_backing_mmap() is error-prone.
Open-code the logic of vma_set_file() using swap() to safely
transfer the file reference and ensure proper reference counting
during VMA setup, as vma_set_file() is not available in this
kernel version.
Bug: 498749316
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
Cherrypick-From: https://android-review.googlesource.com/q/commit:5c3d7b8761264e2a2deb121020bb933273b240ba
Merged-In: I22ba0618f9fde6b698aeeeff2005830c4392969c
Change-Id: I22ba0618f9fde6b698aeeeff2005830c4392969c
[dhavale: as mentioned in updated commit message, this patch is adjusted
to account for lack of vma_set_file() helper ]
[ Upstream commit 26e5c67deb2e1f42a951f022fdf5b9f7eb747b01 ]
I observed a hang when running generic/323 against a fuseblk server.
This test opens a file, initiates a lot of AIO writes to that file
descriptor, and closes the file descriptor before the writes complete.
Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for
responses from the fuseblk server:
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse]
[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse]
[<0>] fuse_do_getattr+0xfc/0x1f0 [fuse]
[<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse]
[<0>] aio_read+0x130/0x1e0
[<0>] io_submit_one+0x542/0x860
[<0>] __x64_sys_io_submit+0x98/0x1a0
[<0>] do_syscall_64+0x37/0xf0
[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
But the /weird/ part is that the fuseblk server threads are waiting for
responses from itself:
[<0>] request_wait_answer+0x1fe/0x2a0 [fuse]
[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse]
[<0>] fuse_file_put+0x9a/0xd0 [fuse]
[<0>] fuse_release+0x36/0x50 [fuse]
[<0>] __fput+0xec/0x2b0
[<0>] task_work_run+0x55/0x90
[<0>] syscall_exit_to_user_mode+0xe9/0x100
[<0>] do_syscall_64+0x43/0xf0
[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
The fuseblk server is fuse2fs so there's nothing all that exciting in
the server itself. So why is the fuse server calling fuse_file_put?
The commit message for the fstest sheds some light on that:
"By closing the file descriptor before calling io_destroy, you pretty
much guarantee that the last put on the ioctx will be done in interrupt
context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx.
The completion of the FUSE_WRITE command from userspace causes the fuse
server to call the AIO completion function. The completion puts the
struct file, queuing a delayed fput to the fuse server task. When the
fuse server task returns to userspace, it has to run the delayed fput,
which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads
is a bad idea because a client program can initiate enough simultaneous
AIOs such that all the fuse server threads end up in delayed_fput, and
now there aren't any threads left to handle the queued fuse commands.
Fix this by only using asynchronous fputs when closing files, and leave
a comment explaining why.
Change-Id: I78be67f615f1318447e2fdad9ebfb34e60857b95
Cc: stable@vger.kernel.org # v2.6.38
Fixes: 5a18ec176c ("fuse: fix hang of single threaded fuseblk filesystem")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
[ added isdir parameter to fuse_file_put() call ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The .ioctl and .compat_ioctl file operations have the same prototype so
they can both point to the same function, which works great almost all
the time when all the commands are compatible.
One exception is the s390 architecture, where a compat pointer is only
31 bit wide, and converting it into a 64-bit pointer requires calling
compat_ptr(). Most drivers here will never run in s390, but since we now
have a generic helper for it, it's easy enough to use it consistently.
I double-checked all these drivers to ensure that all ioctl arguments
are used as pointers or are ignored, but are not interpreted as integer
values.
Acked-by: Jason Gunthorpe <jgg@mellanox.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: David Sterba <dsterba@suse.com>
Acked-by: Darren Hart (VMware) <dvhart@infradead.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Change-Id: I7c19d15ea2d2e48a30e726ca0a5b8ee915e6bbe7
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In writeback cache mode mtime/ctime updates are cached, and flushed to the
server using the ->write_inode() callback.
Closing the file will result in a dirty inode being immediately written,
but in other cases the inode can remain dirty after all references are
dropped. This result in the inode being written back from reclaim, which
can deadlock on a regular allocation while the request is being served.
The usual mechanisms (GFP_NOFS/PF_MEMALLOC*) don't work for FUSE, because
serving a request involves unrelated userspace process(es).
Instead do the same as for dirty pages: make sure the inode is written
before the last reference is gone.
- fallocate(2)/copy_file_range(2): these call file_update_time() or
file_modified(), so flush the inode before returning from the call
- unlink(2), link(2) and rename(2): these call fuse_update_ctime(), so
flush the ctime directly from this helper
fuse_flush_time_update(inode) was skipped to call in __fuse_copy_file_range()
because of huge dependent changes.
Change-Id: I102dab1992c9ed2b5e89606265b3d3aa9c1cdb8a
Reported-by: chenguanyou <chenguanyou@xiaomi.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Git-commit: 5c791fe1e2a4f401f819065ea4fc0450849f1818
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Pradeep P V K <quic_pragalla@quicinc.com>
The feature flag should only advertise fuse-bpf if fuse-bpf is a
supported feature
Bug: 372951405
Test: Compile with CONFIG_FUSE_BPF unset
Change-Id: I0049a3075f78576499168b8ebb6e833ccd18db0f
Signed-off-by: Daniel Rosenberg <drosen@google.com>
[ Upstream commit 525bd65aa759ec320af1dc06e114ed69733e9e23 ]
As was done in
0200679fc795 ("tmpfs: verify {g,u}id mount options correctly")
we need to validate that the requested uid and/or gid is representable in
the filesystem's idmapping.
Cribbing from the above commit log,
The contract for {g,u}id mount options and {g,u}id values in general set
from userspace has always been that they are translated according to the
caller's idmapping. In so far, fuse has been doing the correct thing.
But since fuse is mountable in unprivileged contexts it is also
necessary to verify that the resulting {k,g}uid is representable in the
namespace of the superblock.
Fixes: c30da2e981 ("fuse: convert to use the new mount API")
Cc: stable@vger.kernel.org # 5.4+
Change-Id: Ic3734ff9039e40ae029872bf334f6d3448ef8845
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Link: https://lore.kernel.org/r/8f07d45d-c806-484d-a2e3-7a2199df1cd2@redhat.com
Reviewed-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
This is a follow-up to commit a20fb465b5b0cb0be63c5e552ad58017d7d1818c that
fixes missing instances where s/fc/fsc wasn't performed which breaks compilation
with CONFIG_FUSE_BPF enabled.
Change-Id: I1d5543efc56c180e0416d09a393139fe8e9667b5
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
[ Upstream commit 68ca1b49e430f6534d0774a94147a823e3b8b26e ]
The root inode has a fixed nodeid and generation (1, 0).
Prior to the commit 15db16837a35 ("fuse: fix illegal access to inode with
reused nodeid") generation number on lookup was ignored. After this commit
lookup with the wrong generation number resulted in the inode being
unhashed. This is correct for non-root inodes, but replacing the root
inode is wrong and results in weird behavior.
Fix by reverting to the old behavior if ignoring the generation for the
root inode, but issuing a warning in dmesg.
Reported-by: Antonio SJ Musumeci <trapexit@spawn.link>
Closes: https://lore.kernel.org/all/CAOQ4uxhek5ytdN8Yz2tNEOg5ea4NkBb4nk0FGPjPk_9nz-VG3g@mail.gmail.com/
Fixes: 15db16837a35 ("fuse: fix illegal access to inode with reused nodeid")
Cc: <stable@vger.kernel.org> # v5.14
Change-Id: I83231b08b813b2acead0c3af078b6933b6895d6e
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fuse_lseek_backing was returning the offset as an int, which would then
be treated as an ERR if in the range 4G-4096 and 4G.
Although the call would appear to work correctly, the file position
would be incorrect according to a subsequent fseek with SEEK_CUR.
Based on a change by chenyuwen <chenyuwen1@meizu.com> who found and
fixed this issue.
Bug: 319219307
Change-Id: I3aef5fb22751a72ce2bd7674ee081956a89fc752
Signed-off-by: chenyuwen <chenyuwen1@meizu.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug: 292925770
Test: fuse_test run. The following steps on Android also now pass:
Create /data/123 and /data/media/0/Android/data/45 directories
Mount /data/123 directory to /data/media/0/Android/data/45 directory
Create 1.txt under the /data/123 directory
File 1.txt should appear in /storage/emulated/0/Android/data/45
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:9323938705b42cb4dd863d5cf8022ba8f2282952)
Merged-In: I1fe27d743ca2981e624a9aa87d9ab6deb313aadc
Change-Id: I1fe27d743ca2981e624a9aa87d9ab6deb313aadc
commit 7f8ed28d1401320bcb02dda81b3c23ab2dc5a6d8 upstream.
fuse_dax_conn_free() will be called when fuse_fill_super_common() fails
after fuse_dax_conn_alloc(). Then deactivate_locked_super() in
virtio_fs_get_tree() will call virtio_kill_sb() to release the discarded
superblock. This will call fuse_dax_conn_free() again in fuse_conn_put(),
resulting in a possible double free.
Fixes: 1dd539577c42 ("virtiofs: add a mount option to enable dax")
Change-Id: I5aabc81ad4f96078c612f2ec1c9077f21f4ffae4
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Cc: <stable@vger.kernel.org> # v5.10
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
readpages will be triggered on the fuse fs in passthrough mode though
system calls like fadvise. If the daemon isn't aware of the file, this
will likely cause a hang.
For the moment, simply ignore fadvise in this situation
Bug: 301201239
Test: fuse_test, atest ScopedStorageDeviceTest both pass
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:ac9071df3ba6715219a16a44d4711f041b0c25de)
Merged-In: I524a84aeeb1b1593e51264fcc37f7cfa66757168
Change-Id: I524a84aeeb1b1593e51264fcc37f7cfa66757168
