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>
is disabled
Issue Scenario:
1) INI gEnableDFSMasterCap is set to 0
2) User tries to force start SAP on 160 MHz.
3) SAP starts on 160 MHz which contains DFS channels.
This is a violation since the DUT does not support DFS
master capability.
To fix this, stop the SAP bringup if atleast one of the
bonded channels is DFS.
CRs-Fixed: 4516874
Change-Id: Iaeb77d52059505bafb8a0d38386cb1790432b498
Ensure the "WIPHY_FLAG_DFS_OFFLOAD" flag is always set in
wiphy flag, regardless of DFS master capability ini.
This changes eliminates the need for supplicant to check
DFS flags for the SAP channel, as the DFS logic is
consistently offloaded to the driver.
CRs-Fixed: 3716167
Change-Id: I571f1cf15d268b85ad4de4d2f2a93d39f59b1231
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
If open request sent to classic fuse, backing_file is null.
In fuse_release_initialize, fput will trigger a crash.
Bug: 297831741
Signed-off-by: liujing40 <liujing40@xiaomi.corp-partner.google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:4d2ff573981f06ba09e1ddda8726bb73ff6a2c3f)
Merged-In: I2d54d99d62b54c39a6dc9064f8f62488433aff6f
Change-Id: I2d54d99d62b54c39a6dc9064f8f62488433aff6f
Look at the passthrough file and check to see if its mount is read-only.
Bug: 297482438
Signed-off-by: Lyon Wang <lyon.wang@mediatek.com>
Change-Id: I0f483c6bcb1effe395eee07b6d721f343840d115
(cherry picked from commit dbeed231965e1a01bf0d70ea5439fbfacc7c4aae)
If userspace tried to add a backing file in a fuse_dentry_revalidate
where there wasn't one originally, this would trigger a crash. Disallow
this operation for now.
Bug: 296013218
Fixes: 57f3ff964899 ("ANDROID: fuse-bpf v1.1")
Test: fuse_test passes, following script no longer crashes:
adb shell su root setenforce 0
adb shell su root chmod ug+w /data/media
adb shell su root rm /data/media/Android -rf
adb shell su root mkdir -p /storage/emulated/Android/data/test
adb shell su root ls -l /storage/emulated/Android/data/test
Change-Id: Id8a67c43d1edfa010403d5f17e31109b796998cf
Signed-off-by: liujinbao1 <liujinbao1@xiaomi.corp-partner.google.com>
(cherry picked from commit e89b1266f784b2271af2e72a5d04e3e39d0afcdc)
We were getting the inode with the parent inode info
Also change variable names to remove confusion
Also set bpf correctly in new inode
Bug: 293838958
Test: fuse_test, atest ScopedStorageDeviceTest,
atest CtsScopedStorageHostTest
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:12eb00420cad77d7b7fcfbd1088c921ae629e69d)
Merged-In: I0b6a6951599e0d211afd2243daacb98679503448
Change-Id: I0b6a6951599e0d211afd2243daacb98679503448
create_open would always take its parent directory's bpf for the created
object. Modify to use the bpf stored in fuse_dentry which is set by
lookup.
Bug: 291705489
Test: fuse_test passes, adb push file /sdcard/Android/data works
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I0a1ea2a291a8fdf67923f1827176b2ea96bd4c2d
Store the results of a negative lookup in the fuse_dentry so later
opcodes can use them to create files
Bug: 291705489
Test: fuse_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I725e714a1d6ce43f24431d07c24e96349ef1a55c
fuse_iget_backing returns an inode or null, not a ERR_PTR. So check it's
not NULL
Also make sure we put the inode if d_splice_alias fails
Bug: 293349757
Test: fuse_test runs
Signed_off_by: Paul Lawrence <paullawrence@google.com>
Change-Id: I1eadad32f80bab6730e461412b4b7ab4d6c56bf2
This adds passthrough only support for ioctls with fuse-bpf.
compat_ioctls will return -ENOTTY.
Bug: 279519292
Test: F2fsMiscTest#testAtomicWrite
Change-Id: Ia3052e465d87dc1d15ae13955fba8a7f93bc387b
Signed-off-by: Daniel Rosenberg <drosen@google.com>
This adds passthrough support for flock on fuse-bpf files. It does not
give any control via a bpf filter. The flock will act as though it was
taken on the lower file.
Bug: 289882899
Test: fuse_test -t32 (flock_test)
Change-Id: Iba0b9630766cedbd3195532c5e929891593cfe30
Signed-off-by: Daniel Rosenberg <drosen@google.com>
The existing fuse-bpf freeing logic would free the fuse_file struct
immediately. However, this would break readahead. Move freeing logic
to the same place as done in classic fuse.
Bug: 286287652
Test: fuse_test passes, android boots, cts tests run
Change-Id: If13519f0e956a8da0dc98e7ac4aed2036070e969
Signed-off-by: Paul Lawrence <paullawrence@google.com>
By putting and nulling fuse_inode's bpf field in fuse_evict_inode, we
left a race condition - this inode can still be active. Do not put the
bpf program until we are doing the final free in fuse_free_inode. This
was the root cause of the reported bug.
The backing inode cannot be put in fuse_free_inode, since put_inode can
sleep and this is called from an RCU handler. But the backing inode
cannot be freed until an RCU interval, so move the put_inode to the same
location as in overlayfs, which is destroy_inode.
Remove a path in fuse_handle_bpf_prog whereby bpf can be nulled out.
When we want to be able to null/change the bpf_prog in the future, we
will have to use a mutex or maybe RCU to protect existing users. But
until this time, ban this path.
Bug: 284450048
Test: fuse_test passes, Pixel 6 passes basic tests
Change-Id: Ie6844242f279a5b202eb021eac5a2dd3d08bf09d
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Fix case when an existing bpf prog is being removed
Tidy up code
Bug: 279363668
Test: Boots, can copy file to /sdcardfs/Android/data, fuse_test passes
Change-Id: If0e682f43cbeb62764a7a2be543b90cb974b0aa0
Signed-off-by: Paul Lawrence <paullawrence@google.com>
commit 2fdbb8dd01556e1501132b5ad3826e8f71e24a8b upstream.
fuse_finish_open() will be called with FUSE_NOWRITE set in case of atomic
O_TRUNC open(), so commit 76224355db75 ("fuse: truncate pagecache on
atomic_o_trunc") replaced invalidate_inode_pages2() by truncate_pagecache()
in such a case to avoid the A-A deadlock. However, we found another A-B-B-A
deadlock related to the case above, which will cause the xfstests
generic/464 testcase hung in our virtio-fs test environment.
For example, consider two processes concurrently open one same file, one
with O_TRUNC and another without O_TRUNC. The deadlock case is described
below, if open(O_TRUNC) is already set_nowrite(acquired A), and is trying
to lock a page (acquiring B), open() could have held the page lock
(acquired B), and waiting on the page writeback (acquiring A). This would
lead to deadlocks.
open(O_TRUNC)
----------------------------------------------------------------
fuse_open_common
inode_lock [C acquire]
fuse_set_nowrite [A acquire]
fuse_finish_open
truncate_pagecache
lock_page [B acquire]
truncate_inode_page
unlock_page [B release]
fuse_release_nowrite [A release]
inode_unlock [C release]
----------------------------------------------------------------
open()
----------------------------------------------------------------
fuse_open_common
fuse_finish_open
invalidate_inode_pages2
lock_page [B acquire]
fuse_launder_page
fuse_wait_on_page_writeback [A acquire & release]
unlock_page [B release]
----------------------------------------------------------------
Besides this case, all calls of invalidate_inode_pages2() and
invalidate_inode_pages2_range() in fuse code also can deadlock with
open(O_TRUNC).
Fix by moving the truncate_pagecache() call outside the nowrite protected
region. The nowrite protection is only for delayed writeback
(writeback_cache) case, where inode lock does not protect against
truncation racing with writes on the server. Write syscalls racing with
page cache truncation still get the inode lock protection.
This patch also changes the order of filemap_invalidate_lock()
vs. fuse_set_nowrite() in fuse_open_common(). This new order matches the
order found in fuse_file_fallocate() and fuse_do_setattr().
Reported-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
Tested-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
Fixes: e4648309b8 ("fuse: truncate pending writes on O_TRUNC")
Cc: <stable@vger.kernel.org>
Change-Id: I7e01c787503114b4cd671ef7283fb0a1143887a1
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Yang Bo <yb203166@antfin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ccc031e26afe60d2a5a3d93dabd9c978210825fb upstream.
The previous commit df8629af2934 ("fuse: always revalidate if exclusive
create") ensures that the dentries are revalidated on O_EXCL creates. This
commit complements it by also performing revalidation for rename target
dentries. Otherwise, a rename target file that only exists in kernel
dentry cache but not in the filesystem will result in EEXIST if
RENAME_NOREPLACE flag is used.
Change-Id: Ie26ba53d008737ff709081dda0ef3e07ade449a5
Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
Signed-off-by: Zhang Tianci <zhangtianci.1997@bytedance.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Yang Bo <yb203166@antfin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 484ce65715b06aead8c4901f01ca32c5a240bc71 upstream.
A READ request returning a short count is taken as indication of EOF, and
the cached file size is modified accordingly.
Fix the attribute version checking to allow for changes to fc->attr_version
on other inodes.
Change-Id: I03143ae182ed264aea806a02c5ff4edf0ae28239
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Yang Bo <yb203166@antfin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d534d31d6a45d71de61db22090b4820afb68fddc upstream.
Checking "fm" works because currently sb->s_fs_info is cleared on error
paths; however, sb->s_root is what generic_shutdown_super() checks to
determine whether the sb was fully initialized or not.
This change will allow cleanup of sb setup error paths.
Change-Id: Icc78860e8a64e279fb2717b1cc08d1b83160d733
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Yang Bo <yb203166@antfin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
