| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fs/ntfs3: Add missing header and guards to lib/ headers size_t needs header. Add missing header guards so that compiler will only include these ones. Signed-off-by: Kari Argillander <kari.argillander@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> | 4 年前 | |
fs: add CONFIG_BUFFER_HEAD Add a new config option that controls building the buffer_head code, and select it from all file systems and stacking drivers that need it. For the block device nodes and alternative iomap based buffered I/O path is provided when buffer_head support is not enabled, and iomap needs a a small tweak to define the IOMAP_F_BUFFER_HEAD flag to 0 to not call into the buffer_head code when it doesn't exist. Otherwise this is just Kconfig and ifdef changes. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20230801172201.1923299-7-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> | 2 年前 | |
fs/ntfs3: Add Kconfig, Makefile and doc This adds Kconfig, Makefile and doc Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> | 4 年前 | |
fs/ntfs3: drop preallocated clusters for sparse and compressed files stable inclusion from stable-v6.6.128 commit ad0d779cdc26fef4f3915e631692b853978df19a category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ad0d779cdc26fef4f3915e631692b853978df19a -------------------------------- commit ad0d779cdc26fef4f3915e631692b853978df19a upstream. [ Upstream commit 3a6aba7f3cf2b46816e08548c254d98de9c74eba ] Do not keep preallocated clusters for sparsed and compressed files. Preserving preallocation in these cases causes fsx failures when running with sparse files and preallocation enabled. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST stable inclusion from stable-v6.6.128 commit 8d8c70b57dbeda3eb165c0940b97e85373ca9354 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8d8c70b57dbeda3eb165c0940b97e85373ca9354 -------------------------------- commit 8d8c70b57dbeda3eb165c0940b97e85373ca9354 upstream. [ Upstream commit 06909b2549d631a47fcda249d34be26f7ca1711d ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability. Co-developed-by: Seunghun Han <kkamagui@gmail.com> Signed-off-by: Seunghun Han <kkamagui@gmail.com> Co-developed-by: Jihoon Kwon <kjh010315@gmail.com> Signed-off-by: Jihoon Kwon <kjh010315@gmail.com> Signed-off-by: Jaehun Gou <p22gone@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
fs/ntfs3: Add ntfs_bitmap_weight_le function and refactoring Added ntfs_bitmap_weight_le function. Changed argument types of bits/bitmap functions. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> | 3 年前 | |
fs/ntfs3: Fix a resource leak bug in wnd_extend() stable inclusion from stable-v6.6.113 commit f7fed2af0ad82f2112d16569f2187879f2f4b301 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8637 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f7fed2af0ad82f2112d16569f2187879f2f4b301 -------------------------------- commit d68318471aa2e16222ebf492883e05a2d72b9b17 upstream. Add put_bh() to decrease the refcount of 'bh' after the job is finished, preventing a resource leak. Fixes: 3f3b442b5ad2 ("fs/ntfs3: Add bitmap") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit f7fed2af0ad82f2112d16569f2187879f2f4b301) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 3 个月前 | |
fs/ntfs3. Add forward declarations for structs to debug.h Add forward declarations for structs so that we can include this file without warnings even without linux/fs.h Signed-off-by: Kari Argillander <kari.argillander@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> | 4 年前 | |
ntfs: ->d_compare() must not block stable inclusion from stable-v6.6.141 commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=02ecc0978c459fd90bb24b2a946dd16d43e68fe5 -------------------------------- commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 upstream. [ Upstream commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce ] ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
fs/ntfs3: prevent infinite loops caused by the next valid being the same stable inclusion from stable-v6.6.128 commit 71c8b966ec56e13c02388c1312910588bb49be7a category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=71c8b966ec56e13c02388c1312910588bb49be7a -------------------------------- commit 71c8b966ec56e13c02388c1312910588bb49be7a upstream. [ Upstream commit 27b75ca4e51e3e4554dc85dbf1a0246c66106fd3 ] When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+bcf9e1868c1a0c7e04f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bcf9e1868c1a0c7e04f1 Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
ntfs: Do not overwrite uptodate pages stable inclusion from stable-v6.6.120 commit 49c2ef075dbec895ae39d108e1bc9abad57f207a category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8839 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=49c2ef075dbec895ae39d108e1bc9abad57f207a -------------------------------- commit 68f6bd128e75a032432eda9d16676ed2969a1096 upstream. When reading a compressed file, we may read several pages in addition to the one requested. The current code will overwrite pages in the page cache with the data from disc which can definitely result in changes that have been made being lost. For example if we have four consecutie pages ABCD in the file compressed into a single extent, on first access, we'll bring in ABCD. Then we write to page B. Memory pressure results in the eviction of ACD. When we attempt to write to page C, we will overwrite the data in page B with the data currently on disk. I haven't investigated the decompression code to check whether it's OK to overwrite a clean page or whether it might be possible to see corrupt data. Out of an abundance of caution, decline to overwrite uptodate pages, not just dirty pages. Fixes: 4342306f0f0d (fs/ntfs3: Add file operations and implementation) Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: stable@vger.kernel.org Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 49c2ef075dbec895ae39d108e1bc9abad57f207a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 2 个月前 | |
fs/ntfs3: validate rec->used in journal-replay file record check stable inclusion from stable-v6.6.136 commit f90b8a1798b750755a9e9aee66678f0a1820bbaf category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f90b8a1798b750755a9e9aee66678f0a1820bbaf -------------------------------- commit 0ca0485e4b2e837ebb6cbd4f2451aba665a03e4b upstream. check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") which checked different values in this same switch statement. Cc: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable <stable@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
ntfs: ->d_compare() must not block stable inclusion from stable-v6.6.141 commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=02ecc0978c459fd90bb24b2a946dd16d43e68fe5 -------------------------------- commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 upstream. [ Upstream commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce ] ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
fs: ntfs3: check return value of indx_find to avoid infinite loop stable inclusion from stable-v6.6.128 commit 68e32694be231c1cdb99b7637a657314e88e1a96 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=68e32694be231c1cdb99b7637a657314e88e1a96 -------------------------------- commit 68e32694be231c1cdb99b7637a657314e88e1a96 upstream. [ Upstream commit 1732053c8a6b360e2d5afb1b34fe9779398b072c ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation. Co-developed-by: Seunghun Han <kkamagui@gmail.com> Signed-off-by: Seunghun Han <kkamagui@gmail.com> Co-developed-by: Jihoon Kwon <kjh010315@gmail.com> Signed-off-by: Jihoon Kwon <kjh010315@gmail.com> Signed-off-by: Jaehun Gou <p22gone@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
ntfs: ->d_compare() must not block stable inclusion from stable-v6.6.141 commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=02ecc0978c459fd90bb24b2a946dd16d43e68fe5 -------------------------------- commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 upstream. [ Upstream commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce ] ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
fs/ntfs3: Check if more than chunk-size bytes are written stable inclusion from stable-v6.6.60 commit 5f21e3e60982cd7353998b4f59f052134fd47d64 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB44K1 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5f21e3e60982cd7353998b4f59f052134fd47d64 -------------------------------- [ Upstream commit 9931122d04c6d431b2c11b5bb7b10f28584067f0 ] A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off. Signed-off-by: Andrew Ballance <andrewjballance@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Wen Zhiwei <wenzhiwei@kylinos.cn> | 1 年前 | |
ntfs: ->d_compare() must not block stable inclusion from stable-v6.6.141 commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=02ecc0978c459fd90bb24b2a946dd16d43e68fe5 -------------------------------- commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 upstream. [ Upstream commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce ] ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
fs/ntfs3: Prevent integer overflow in hdr_first_de() stable inclusion from stable-v6.6.87 commit f6d44b1aa46d317e52c21fb9314cfb20dd69e7b0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID6BMS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f6d44b1aa46d317e52c21fb9314cfb20dd69e7b0 -------------------------------- [ Upstream commit 6bb81b94f7a9cba6bde9a905cef52a65317a8b04 ] The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow. Fixes: 60ce8dfde035 ("fs/ntfs3: Fix wrong if in hdr_first_de") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit f6d44b1aa46d317e52c21fb9314cfb20dd69e7b0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 7 个月前 | |
fs/ntfs3: Support timestamps prior to epoch stable inclusion from stable-v6.6.120 commit f5c2a7cb2f007304eed7fafc119b28530de09d4e category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8839 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f5c2a7cb2f007304eed7fafc119b28530de09d4e -------------------------------- [ Upstream commit 5180138604323895b5c291eca6aa7c20be494ade ] Before it used an unsigned 64-bit type, which prevented proper handling of timestamps earlier than 1970-01-01. Switch to a signed 64-bit type to support pre-epoch timestamps. The issue was caught by xfstests. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit f5c2a7cb2f007304eed7fafc119b28530de09d4e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 2 个月前 | |
fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr() mainline inclusion from mainline-v6.12-rc3 commit 2afd4d267e6dbaec8d3ccd4f5396cb84bc67aa2e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBPC5A CVE: CVE-2024-52560 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2afd4d267e6dbaec8d3ccd4f5396cb84bc67aa2e -------------------------------- Extended the mi_enum_attr() function interface with an additional parameter, struct ntfs_inode *ni, to allow marking the inode as bad as soon as an error is detected. Reported-by: syzbot+73d8fc29ec7cba8286fa@syzkaller.appspotmail.com Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Conflicts: fs/ntfs3/record.c [Context Changed] Signed-off-by: Yongjian Sun <sunyongjian1@huawei.com> | 1 年前 | |
| 16 天前 | ||
fs/ntfs3: terminate the cached volume label after UTF-8 conversion stable inclusion from stable-v6.6.141 commit 0b11fcbe80a59acdf58337d80ebb5f72201d73d6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0b11fcbe80a59acdf58337d80ebb5f72201d73d6 -------------------------------- commit 0b11fcbe80a59acdf58337d80ebb5f72201d73d6 upstream. [ Upstream commit a6cd43fe9b083fa23fe1595666d5738856cb261a ] ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL. If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator. Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 | |
fs/ntfs3: Add option "nocase" This commit adds mount option and additional functions. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> | 3 年前 | |
ntfs: ->d_compare() must not block stable inclusion from stable-v6.6.141 commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=02ecc0978c459fd90bb24b2a946dd16d43e68fe5 -------------------------------- commit 02ecc0978c459fd90bb24b2a946dd16d43e68fe5 upstream. [ Upstream commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce ] ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 25 天前 |