On 5/22/25 23:34, Shuah Khan wrote:
> Change the shortlog to indicate test clearly. Check a few logs
> for this file for examples. Here is how the correct format looks
> like:
>
> selftests: filesystems: fix "memebers" typo in mount-notify
>
> SZend v2 w
uggested by Amir Goldstein
> - Rename the test subdir to filesystems/fuse
> - Verify errno when connection is aborted
> - Apply changes suggested by Shuah Khan
> - Update commit message
> - Link to v2:
> https://lore.kernel.org/all/20250517012350.10317-2-chenlinx...@uniontech.com/
g_OBhmSY=q...@mail.gmail.com/
Cc: Amir Goldstein
Signed-off-by: Chen Linxuan
Acked-by: Shuah Khan
---
Changes in v3:
- Apply changes suggested by Amir Goldstein
- Rename the test subdir to filesystems/fuse
- Verify errno when connection is aborted
- Apply changes suggested by Shuah Khan
- Upd
include "overlayfs/wrappers.h"
> | ^~
>
> This is due to 0bd92b9fe538 ("selftests/filesystems: move wrapper.h out
> of overlayfs subdir") which was added in the vfs-6.16.selftests branch
> which was based on -rc5 and does not contain t
Corrects a spelling mistake "memebers" instead of "members" in
tools/testing/selftests/filesystems/mount-notify/mount-notify_test.c
Signed-off-by: Hendrik Hamerlinck
---
Changes since v1:
Improved commit message to be consistent with other commit messages.
.../selftes
On 5/13/25 08:48, Hendrik Hamerlinck wrote:
Corrects a spelling mistake "memebers" instead of "members" in
tools/testing/selftests/filesystems/mount-notify/mount-notify_test.c
Change the shortlog to indicate test clearly. Check a few logs
for this file for examples. Her
is due to 0bd92b9fe538 ("selftests/filesystems: move wrapper.h out
of overlayfs subdir") which was added in the vfs-6.16.selftests branch
which was based on -rc5 and does not contain the newly added test so
once things were merged into vfs.all in the build started failing - both
parent comm
Change spelling from rougly to roughly.
Signed-off-by: Chelsy Ratnawat
---
tools/testing/selftests/filesystems/file_stressor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/filesystems/file_stressor.c
b/tools/testing/selftests/filesystems
Remove duplicate header which is included twice.
Signed-off-by: Chen Ni
---
tools/testing/selftests/filesystems/utils.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/filesystems/utils.c
b/tools/testing/selftests/filesystems/utils.c
index e553c89c5b19..06419bf4ba19
On 14.03.25 13:10, David Hildenbrand wrote:
On 12.03.25 09:34, Brendan Jackman wrote:
On Tue, Mar 11, 2025 at 08:53:02PM +0100, David Hildenbrand wrote:
2. 9pfs seems to pass the f_type through from the host. So you can't
detect it this way anyway.
[3. I guess overlayfs & friends would also be
At some point I thought I was hitting the issue there too,
but I think I was mistaken, like just not reading the test logs
properly or something).
Ah, yes run_with_local_tmpfile() ... jep, I wrote that test, now my
memory comes back; we wanted to test with actual filesystems (e.g.,
ext4, xfs) easil
> > Even if it's a bug in QEMU, I think it is worth working around this
> > one way or another. QEMU by far the most practical way to run these
> > tests, and virtme-ng is probably the most popular/practical way to do
> > that.
>
> I'm afraid yes. Although allocating temp files form 9pfs is rather
On 12.03.25 09:34, Brendan Jackman wrote:
On Tue, Mar 11, 2025 at 08:53:02PM +0100, David Hildenbrand wrote:
2. 9pfs seems to pass the f_type through from the host. So you can't
detect it this way anyway.
[3. I guess overlayfs & friends would also be an issue here although
that doesn't affect m
On Tue, Mar 11, 2025 at 08:53:02PM +0100, David Hildenbrand wrote:
> > 2. 9pfs seems to pass the f_type through from the host. So you can't
> > detect it this way anyway.
> >
> > [3. I guess overlayfs & friends would also be an issue here although
> > that doesn't affect my usecase.]
> >
> > Anyw
On 11.03.25 14:00, Brendan Jackman wrote:
On Thu, 6 Mar 2025 at 15:40, David Hildenbrand wrote:
Yes, just skip 9pfs early, and mention in the commit message that 9pfs
has a history of being probematic with "use-after-unlink", maybe
mentioning the discussion I linked above.
Maybe something like
Some filesystems don't support ftruncate()ing unlinked files. They return
ENOENT. In that case, skip the test.
Signed-off-by: Brendan Jackman
---
tools/testing/selftests/mm/gup_longterm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftes
It seems that 9pfs does not allow truncating unlinked files, Mark Brown
has noted that NFS may also behave this way.
It doesn't seem quite right to call this a "bug" but it's probably a
special enough case that it makes sense for the test to just SKIP if it
happens.
Signed-off-by: Brendan Jackman
On Thu, 6 Mar 2025 at 15:40, David Hildenbrand wrote:
> Yes, just skip 9pfs early, and mention in the commit message that 9pfs
> has a history of being probematic with "use-after-unlink", maybe
> mentioning the discussion I linked above.
>
> Maybe something like this would work?
>
> diff --git a/t
On Thu, Mar 06, 2025 at 10:28:09AM +0100, David Hildenbrand wrote:
> On 28.02.25 17:54, Brendan Jackman wrote:
> > Some filesystems don't support funtract()ing unlinked files. They return
> > ENOENT. In that case, skip the test.
> >
>
> That's not documented
On 06.03.25 13:42, Brendan Jackman wrote:
On Thu, Mar 06, 2025 at 10:28:09AM +0100, David Hildenbrand wrote:
On 28.02.25 17:54, Brendan Jackman wrote:
Some filesystems don't support funtract()ing unlinked files. They return
ENOENT. In that case, skip the test.
That's not documen
On 28.02.25 17:54, Brendan Jackman wrote:
Some filesystems don't support funtract()ing unlinked files. They return
ENOENT. In that case, skip the test.
That's not documented in the man page, so is this a bug of these
filesystems?
What are examples for these weird filesystems?
Some filesystems don't support funtract()ing unlinked files. They return
ENOENT. In that case, skip the test.
Signed-off-by: Brendan Jackman
---
tools/testing/selftests/mm/gup_longterm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftes
It seems that 9pfs does not allow truncating unlinked files, Mark Brown
has noted that NFS may also behave this way.
It doesn't seem quite right to call this a "bug" but it's probably a
special enough case that it makes sense for the test to just SKIP if it
happens.
Signed-off-by: Brendan Jackman
On Mon, 24 Feb 2025 at 11:25, Brendan Jackman wrote:
>
> On Fri, 21 Feb 2025 at 19:26, Brendan Jackman wrote:
> >
> > It seems that 9pfs does not allow truncating unlinked files, Mark Brown
> > has noted that NFS may also behave this way.
>
> I have not investigated at all but I _think_ over the
On Fri, 21 Feb 2025 at 19:26, Brendan Jackman wrote:
>
> It seems that 9pfs does not allow truncating unlinked files, Mark Brown
> has noted that NFS may also behave this way.
I have not investigated at all but I _think_ over the weekend I saw
ftruncate() failure on a QEMU guest where /tmp was tm
./tools/testing/selftests/filesystems/utils.c: sys/types.h is included more
than once.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=19042
Signed-off-by: Jiapeng Chong
---
tools/testing/selftests/filesystems/utils.c | 1 -
1 file changed, 1 deletion(-)
diff
It seems that 9pfs does not allow truncating unlinked files, Mark Brown
has noted that NFS may also behave this way.
It doesn't seem quite right to call this a "bug" but it's probably a
special enough case that it makes sense for the test to just SKIP if it
happens.
Signed-off-by: Brendan Jackman
Some filesystems don't support funtract()ing unlinked files. They return
ENOENT. In that case, skip the test.
Signed-off-by: Brendan Jackman
---
tools/testing/selftests/mm/gup_longterm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftes
On 11/12/2024 01:10, Shuah Khan wrote:
> On 11/22/24 00:37, Li Zhijian wrote:
>> Compiled binary files should be added to .gitignore
>>
>> 'git status' complains:
>> Untracked files:
>> (use "git add ..." to include in what will be commit
Compiled binary files should be added to .gitignore
'git status' complains:
Untracked files:
(use "git add ..." to include in what will be committed)
filesystems/statmount/statmount_test_ns
Cc: Shuah Khan
Cc: Christian Brauner
Cc: Miklos Szeredi
Cc: Josef Bacik
On 11/22/24 00:37, Li Zhijian wrote:
Compiled binary files should be added to .gitignore
'git status' complains:
Untracked files:
(use "git add ..." to include in what will be committed)
filesystems/statmount/statmount_test_ns
Cc: Shuah Khan
Cc: Christian Brauner
Cc
On Fri, Nov 22, 2024 at 03:37:25PM +0800, Li Zhijian wrote:
> Compiled binary files should be added to .gitignore
>
> 'git status' complains:
> Untracked files:
> (use "git add ..." to include in what will be committed)
> filesystems/statmount/statm
Compiled binary files should be added to .gitignore
'git status' complains:
Untracked files:
(use "git add ..." to include in what will be committed)
filesystems/statmount/statmount_test_ns
Cc: Shuah Khan
Cc: Christian Brauner
Cc: Miklos Szeredi
Cc: Josef Bacik
Signe
Compiled binary files should be added to .gitignore
'git status' complains:
Untracked files:
(use "git add ..." to include in what will be committed)
filesystems/statmount/statmount_test_ns
Cc: Shuah Khan
Cc: Christian Brauner
Cc: Miklos Szeredi
Cc: Josef Bacik
Signe
On 8/16/24 07:11, Shuah Khan wrote:
On 8/10/24 07:53, Abhinav Jain wrote:
Add return value checks for read & write calls in test_listmount_ns
function. This patch resolves below compilation warnings:
```
statmount_test_ns.c: In function ‘test_listmount_ns’:
statmount_test_ns.c:322:17: warning:
On Wed, Dec 15, 2021 at 10:21:00AM +0800, Shiyang Ruan wrote:
>
>
> 在 2021/12/14 23:47, Christoph Hellwig 写道:
> > On Thu, Dec 02, 2021 at 04:48:54PM +0800, Shiyang Ruan wrote:
> > > Add these helper functions, and export them for filesystem use.
> >
> > What is the point of adding these wrappers
在 2021/12/14 23:47, Christoph Hellwig 写道:
On Thu, Dec 02, 2021 at 04:48:54PM +0800, Shiyang Ruan wrote:
Add these helper functions, and export them for filesystem use.
What is the point of adding these wrappers vs just calling the
underlying functions?
I added them so that they can be cal
On Thu, Dec 02, 2021 at 04:48:54PM +0800, Shiyang Ruan wrote:
> Add these helper functions, and export them for filesystem use.
What is the point of adding these wrappers vs just calling the
underlying functions?
Add these helper functions, and export them for filesystem use.
Signed-off-by: Shiyang Ruan
---
drivers/dax/super.c | 19 +++
include/linux/dax.h | 15 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index a19fcc0a54f3..ac
@@ FILESYSTEMS (VFS and infrastructure)
M: Alexander Viro
L: linux-fsde...@vger.kernel.org
S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
F: fs/*
F: include/linux/fs.h
F: include/linux/fs_types.h
--
2.26.2
Bhaskar Chowdhury writes:
> s/provisoned/provisioned/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> Documentation/filesystems/vfat.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/vfat.rst
> b/Documentation/f
On Fri, 19 Mar 2021, Bhaskar Chowdhury wrote:
s/provisoned/provisioned/
Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
---
Documentation/filesystems/vfat.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/vfat.rst
b
Bhaskar Chowdhury writes:
> s/provisoned/provisioned/
>
> Signed-off-by: Bhaskar Chowdhury
Looks good.
Acked-by: OGAWA Hirofumi
> ---
> Documentation/filesystems/vfat.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/f
s/provisoned/provisioned/
Signed-off-by: Bhaskar Chowdhury
---
Documentation/filesystems/vfat.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/vfat.rst
b/Documentation/filesystems/vfat.rst
index e85d74e91295..760a4d83fdf9 100644
--- a
with -m32, -mx32 and -m64 to cover all the
various compat and 32/64-bit time syscall implementations.
Signed-off-by: Willem de Bruijn
---
.../testing/selftests/filesystems/.gitignore | 1 +
tools/testing/selftests/filesystems/Makefile | 2 +-
.../selftests/filesystems/selectpoll.c
On Fri, 1 Jan 2021 22:52:13 +0100
Jonathan Neuschäfer wrote:
> The documentation for other filesystems is already included via
> filesystems/index.rst. Include ext4 in the same way and remove it
> from the top-level table of contents.
>
> Signed-off-by: Jona
On Sun, 10 Jan 2021 15:59:59 +0800
winnd...@163.com wrote:
> From: Liao Pingfang
>
> The struct name should be file_system_type instead of
> file_system_operations.
>
> Signed-off-by: Liao Pingfang
> ---
> Documentation/filesystems/vfs.rst | 2 +-
> 1 file changed,
From: Liao Pingfang
The struct name should be file_system_type instead of
file_system_operations.
Signed-off-by: Liao Pingfang
---
Documentation/filesystems/vfs.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/vfs.rst
b/Documentation
The documentation for other filesystems is already included via
filesystems/index.rst. Include ext4 in the same way and remove it
from the top-level table of contents.
Signed-off-by: Jonathan Neuschäfer
---
Documentation/filesystems/index.rst | 1 +
Documentation/index.rst | 11
xfs, f2fs and iso are common enough to have them everywhere.
Signed-off-by: Guido Günther
---
arch/arm64/configs/defconfig | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e42ba0c8f302..6f5f03237db6 100644
--- a/arch/arm64
an still try to do that?
>
> Oh Gods. Let's *not* make this some "random filesystem choice" where
> now semantics depends on what some filesystem decided to do, and
> different filesystems have very subtly different semantics.
>
> This all screams "please ke
e want
> >> to invent/refine meanings for the mask, we can still try to do that?
> >
> > Oh Gods. Let's *not* make this some "random filesystem choice" where
> > now semantics depends on what some filesystem decided to do, and
> > different filesystems
On 12/1/20 4:09 PM, Linus Torvalds wrote:
> So basically, the thing that argues against this patch is that it
> seems to just duplicate things inside filesystems, when the VFS layter
> already has the information.
>
> Now, if the VFS information was possibly stale or wrong, that
> Oh Gods. Let's *not* make this some "random filesystem choice" where
> now semantics depends on what some filesystem decided to do, and
> different filesystems have very subtly different semantics.
Well, I had hoped that refinement might start with the interface
d
choice" where
now semantics depends on what some filesystem decided to do, and
different filesystems have very subtly different semantics.
This all screams "please keep this in the VFS layer" so that we at
least have _one_ place where these kinds of decisions are made.
I suspect v
s then done for every filesystem -
> most of which don't support it. Not sure whether that's a big enough problem
> to worry about. The same is true of the automount test too, I suppose...
So I'd rather have it in one single place than spread out in the filesystems.
Especia
be properly set.
>>>
>>> So, move STATX_ATTR_DAX attribute setting to the individual dax-capable
>>> filesystems, and update the attributes_mask there as well.
>>>
>>> [1] 3209f68b3ca4 statx: Include a mask for stx_attributes in struct statx
>>>
Linus Torvalds wrote:
> And if IS_DAX() is correct, then why shouldn't this just be done in
> generic code? Why move it to every individual filesystem?
One way of looking at it is that the check is then done for every filesystem -
most of which don't support it. Not sure whether that's a big en
the filesystem which
> > actually sets S_DAX on the inode, and the filesystem is the place that
> > knows whether DAX is something that the "filesystem actually supports" [1]
> > so that the statx attributes_mask can be properly set.
> >
> > So, move STATX_ATTR_DAX att
lly sets S_DAX on the inode, and the filesystem is the place that
>> knows whether DAX is something that the "filesystem actually supports" [1]
>> so that the statx attributes_mask can be properly set.
>>
>> So, move STATX_ATTR_DAX attribute setting to the individual d
t
> knows whether DAX is something that the "filesystem actually supports" [1]
> so that the statx attributes_mask can be properly set.
>
> So, move STATX_ATTR_DAX attribute setting to the individual dax-capable
> filesystems, and update the attributes_mask there as well.
I&#
On 12/1/20 11:39 AM, Darrick J. Wong wrote:
>> diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
>> index 1414ab79eacf..56deda7042fd 100644
>> --- a/fs/xfs/xfs_iops.c
>> +++ b/fs/xfs/xfs_iops.c
>> @@ -575,10 +575,13 @@ xfs_vn_getattr(
>> stat->attributes |= STATX_ATTR_APPEND;
>>
e that
> knows whether DAX is something that the "filesystem actually supports" [1]
> so that the statx attributes_mask can be properly set.
>
> So, move STATX_ATTR_DAX attribute setting to the individual dax-capable
> filesystems, and update the attributes_mask there as wel
David Howells wrote:
> > - if (IS_DAX(inode))
> > - stat->attributes |= STATX_ATTR_DAX;
> > -
>
> This could probably be left in and not distributed amongst the filesytems
> provided that any filesystem that might turn it on sets the bit in the
> attributes_mask.
On further consider
Eric Sandeen wrote:
> - if (IS_DAX(inode))
> - stat->attributes |= STATX_ATTR_DAX;
> -
This could probably be left in and not distributed amongst the filesytems
provided that any filesystem that might turn it on sets the bit in the
attributes_mask.
I'm presuming that the core do
ts" [1]
so that the statx attributes_mask can be properly set.
So, move STATX_ATTR_DAX attribute setting to the individual dax-capable
filesystems, and update the attributes_mask there as well.
[1] 3209f68b3ca4 statx: Include a mask for stx_attributes in struct statx
Signed-off-by: Eric S
>
> This change has the side-effect of removing the capability of the root
> directory from being case-insensitive. It is not a backward
> incompatible change because there is no way to make the root directory
> CI at the moment (it is never empty). But this restriction seems
> artificial. Is ther
Eric Biggers writes:
> On Sun, Nov 22, 2020 at 01:12:18PM +0800, Gao Xiang wrote:
>> Hi all,
>>
>> On Thu, Nov 19, 2020 at 06:09:03AM +, Daniel Rosenberg wrote:
>> > This shifts the responsibility of setting up dentry operations from
>> > fscrypt to th
Eric Biggers writes:
> On Sat, Nov 21, 2020 at 11:45:41PM -0500, Gabriel Krisman Bertazi wrote:
>> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> > index 6633b20224d5..0288bedf46e1 100644
>> > --- a/fs/ext4/super.c
>> > +++ b/fs/ext4/super.c
>> > @@ -4968,11 +4968,6 @@ static int ext4_fill_s
operations from
> > > fscrypt to the individual filesystems, allowing them to have their own
> > > operations while still setting fscrypt's d_revalidate as appropriate.
> > >
> > > Most filesystems can just use generic_set_encrypted_ci_d_ops, unless
>
On Sun, Nov 22, 2020 at 01:12:18PM +0800, Gao Xiang wrote:
> Hi all,
>
> On Thu, Nov 19, 2020 at 06:09:03AM +, Daniel Rosenberg wrote:
> > This shifts the responsibility of setting up dentry operations from
> > fscrypt to the individual filesystems, allowing t
On Sat, Nov 21, 2020 at 11:45:41PM -0500, Gabriel Krisman Bertazi wrote:
> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > index 6633b20224d5..0288bedf46e1 100644
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> > @@ -4968,11 +4968,6 @@ static int ext4_fill_super(struct super_block *sb,
Hi all,
On Thu, Nov 19, 2020 at 06:09:03AM +, Daniel Rosenberg wrote:
> This shifts the responsibility of setting up dentry operations from
> fscrypt to the individual filesystems, allowing them to have their own
> operations while still setting fscrypt's d_revalidate
Daniel Rosenberg writes:
> This shifts the responsibility of setting up dentry operations from
> fscrypt to the individual filesystems, allowing them to have their own
> operations while still setting fscrypt's d_revalidate as appropriate.
>
> Most file
to have sigsetsize arg.
Signed-off-by: Willem de Bruijn
---
.../filesystems/epoll/epoll_wakeup_test.c | 72 +++
1 file changed, 72 insertions(+)
diff --git a/tools/testing/selftests/filesystems/epoll/epoll_wakeup_test.c
b/tools/testing/selftests/filesystems/epoll
This shifts the responsibility of setting up dentry operations from
fscrypt to the individual filesystems, allowing them to have their own
operations while still setting fscrypt's d_revalidate as appropriate.
Most filesystems can just use generic_set_encrypted_ci_d_ops, unless
they have thei
On Wed, Nov 18, 2020 at 06:42:44AM +, Daniel Rosenberg wrote:
> diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c
> index 1fbe6c24d705..cb3cfa6329ba 100644
> --- a/fs/crypto/fname.c
> +++ b/fs/crypto/fname.c
> @@ -570,7 +570,3 @@ int fscrypt_d_revalidate(struct dentry *dentry, unsigned
> int
From: Willem de Bruijn
Code coverage for the epoll_pwait2 syscall.
epoll62: Repeat basic test epoll1, but exercising the new syscall.
epoll63: Pass a timespec and exercise the timeout wakeup path.
Signed-off-by: Willem de Bruijn
---
.../filesystems/epoll/epoll_wakeup_test.c | 70
This shifts the responsibility of setting up dentry operations from
fscrypt to the individual filesystems, allowing them to have their own
operations while still setting fscrypt's d_revalidate as appropriate.
Most filesystems can just use generic_set_encrypted_ci_d_ops, unless
they have thei
On Tue, Nov 17, 2020 at 04:03:14AM +, Daniel Rosenberg wrote:
> diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
> index a8f7a43f031b..df2c66ca370e 100644
> --- a/include/linux/fscrypt.h
> +++ b/include/linux/fscrypt.h
> @@ -741,8 +741,9 @@ static inline int fscrypt_prepare_rename
On Tue, Nov 17, 2020 at 09:04:11AM -0800, Jaegeuk Kim wrote:
>
> I'd like to pick this patch series in f2fs/dev for -next, so please let me
> know
> if you have any concern.
No concern for me as far as ext4 is concerned, thanks!
- Ted
On 11/17, Theodore Y. Ts'o wrote:
> On Tue, Nov 17, 2020 at 04:03:14AM +, Daniel Rosenberg wrote:
> > This shifts the responsibility of setting up dentry operations from
> > fscrypt to the individual filesystems, allowing them to have their own
> > operations whi
On Tue, Nov 17, 2020 at 04:03:14AM +, Daniel Rosenberg wrote:
> This shifts the responsibility of setting up dentry operations from
> fscrypt to the individual filesystems, allowing them to have their own
> operations while still setting fscrypt's d_revalidate as appropri
This shifts the responsibility of setting up dentry operations from
fscrypt to the individual filesystems, allowing them to have their own
operations while still setting fscrypt's d_revalidate as appropriate.
Most filesystems can just use generic_set_encrypted_ci_d_ops, unless
they have thei
On Sun, 8 Nov 2020 14:24:14 +0100
Jonathan Neuschäfer wrote:
> Specifying the .rst extension doesn't cause any problems AFAICT, but
> it's uncommon.
>
> Fixes: 688f118e3139f ("docs: filesystems: convert
> ubifs-authentication.rst.txt to ReST")
&
I'll queue this fix into my tree.
Honza
> ---
> Documentation/filesystems/ext2.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/filesystems/ext2.rst
> b/Documentation/filesystems/ext2.rst
> index
Specifying the .rst extension doesn't cause any problems AFAICT, but
it's uncommon.
Fixes: 688f118e3139f ("docs: filesystems: convert ubifs-authentication.rst.txt
to ReST")
Signed-off-by: Jonathan Neuschäfer
---
Documentation/filesystems/index.rst | 2 +-
1 file change
This prevents the other headings like "Options" and "Specification" from
leaking out and being listed separately in the table of contents.
Signed-off-by: Jonathan Neuschäfer
---
Documentation/filesystems/ext2.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentat
sysfs *happens*
to be a (virtual) filesystem, so this is not really the right place.
It's jarring to be reading about filesystems in general and then come
across these specific details about PCI, and tagging...and then back to
general filesystems again.
Move sysfs-pci and sysfs-tagging to a loc
e a (virtual) filesystem, so this is not really the right place.
>
> It's jarring to be reading about filesystems in general and then come
> across these specific details about PCI, and tagging...and then back to
> general filesystems again.
>
> Move sysfs-pci and sysfs-tagging
to be reading about filesystems in general and then come
across these specific details about PCI, and tagging...and then back to
general filesystems again.
Move sysfs-pci and sysfs-tagging to a location under the sysfs topic.
Signed-off-by: John Hubbard
---
Hi,
I'm not sure if the "to
On Fri, 18 Sep 2020 19:03:11 -0700
Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix capitalization in two headings, correct one verb, and
> demote one heading to a section heading.
>
> Fixes: 791a17ee1973 ("docs: filesystems: convert mount_api.txt to ReST")
> Si
On Wed, Sep 23, 2020 at 01:01:50AM +, Daniel Rosenberg wrote:
> This shifts the responsibility of setting up dentry operations from
> fscrypt to the individual filesystems, allowing them to have their own
> operations while still setting fscrypt's d_revalidate as appropri
This shifts the responsibility of setting up dentry operations from
fscrypt to the individual filesystems, allowing them to have their own
operations while still setting fscrypt's d_revalidate as appropriate.
Most filesystems can just use generic_set_encrypted_ci_d_ops, unless
they have thei
From: Randy Dunlap
Fix capitalization in two headings, correct one verb, and
demote one heading to a section heading.
Fixes: 791a17ee1973 ("docs: filesystems: convert mount_api.txt to ReST")
Signed-off-by: Randy Dunlap
Cc: Mauro Carvalho Chehab
---
Documentation/filesystems/mou
On Sun, 30 Aug 2020 17:41:35 +0300
Denis Efremov wrote:
> Commit a4232963757e ("driver-core: Move kobj_to_dev from genhd.h to device.h")
> introduced kobj_to_dev() function.
>
> Signed-off-by: Denis Efremov
> ---
> Documentation/filesystems/sysf
Looks good,
Reviewed-by: Johannes Thumshirn
unlock_native_capacity is never called from check_disk_change(), and
while revalidate_disk can be called from it, it can also be called
from two other places at the moment.
Signed-off-by: Christoph Hellwig
---
Documentation/filesystems/locking.rst | 3 ---
1 file changed, 3 deletions(-)
diff
Commit a4232963757e ("driver-core: Move kobj_to_dev from genhd.h to device.h")
introduced kobj_to_dev() function.
Signed-off-by: Denis Efremov
---
Documentation/filesystems/sysfs.rst| 3 +--
Documentation/translations/zh_CN/filesystems/sysfs.txt | 3 +--
2 files
From: Eric Biggers
[ Upstream commit 0a12c4a8069607247cb8edc3b035a664e636fd9a ]
The minix filesystem reads its maximum file size from its on-disk
superblock. This value isn't necessarily a multiple of the block size.
When it's not, the V1 block mapping code doesn't allow mapping the last
possib
1 - 100 of 1146 matches
Mail list logo
