r *name, struct dentry *parent,
const struct inode_operations *ops)
{
+ struct tracefs_inode *ti;
struct dentry *dentry = tracefs_start_creating(name, parent);
struct inode *inode;
@@ -651,6 +670,9 @@ static struct dentry *__create_d
inode.c
> > @@ -223,13 +223,41 @@ static const struct inode_operations
> > tracefs_file_inode_operations = {
> > .setattr= tracefs_setattr,
> > };
> >
> > +/* Copied from get_next_ino() but adds allocation for multiple inodes */
> > +#def
= {
.setattr= tracefs_setattr,
};
+/* Copied from get_next_ino() but adds allocation for multiple inodes */
+#define LAST_INO_BATCH 1024
+#define LAST_INO_MASK (~(LAST_INO_BATCH - 1))
+static DEFINE_PER_CPU(unsigned int, last_ino);
+
+unsigned int tracefs_get_next_ino(int files
From: "Steven Rostedt (Google)"
Linus suggested to use the same inode numbers to make it easier to
implement getdents(), as it was creating inodes just for generating a
unique and consistent inode number. Linus suggested to just use the same
inode for all files and directori
On Mon, Jan 22, 2024 at 02:02:28PM -0800, Linus Torvalds wrote:
> On Mon, 22 Jan 2024 at 13:59, Darrick J. Wong wrote:
> >
> > though I don't think
> > leaking raw kernel pointers is an awesome idea.
>
> Yeah, I wasn't all that comfortable even with trying to hash it
> (because I think
On Mon, 22 Jan 2024 at 13:59, Darrick J. Wong wrote:
>
> though I don't think
> leaking raw kernel pointers is an awesome idea.
Yeah, I wasn't all that comfortable even with trying to hash it
(because I think the number of source bits is small enough that even
with a crypto hash, it's
On Tue, Jan 16, 2024 at 05:55:32PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The dentries and inodes are created in the readdir for the sole purpose of
> getting a consistent inode number. Linus stated that is unnecessary, and
> that all inode
On Mon, Jan 22, 2024 at 03:27:48PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The eventfs inodes and directories are allocated when referenced. But this
> leaves the issue of keeping consistent inode numbers and the number is
> only saved in t
From: "Steven Rostedt (Google)"
The eventfs inodes and directories are allocated when referenced. But this
leaves the issue of keeping consistent inode numbers and the number is
only saved in the inode structure itself. When the inode is no longer
referenced, it can be freed. Whe
From: "Steven Rostedt (Google)"
The original eventfs code added a wrapper around the dcache_readdir open
callback and created all the dentries and inodes at open, and increment
their ref count. A wrapper was added around the dcache_readdir release
function to decrement all the
[ subject is still wrong, but is to match v2, see patch 2 for correct subject ]
Changes since v2:
https://lore.kernel.org/all/20240116211217.968123...@goodmis.org/
Implemented Linus's suggestion to just change the iterate_shared to
use the hard coded inodes.
Steven Rostedt (Google) (2
From: "Steven Rostedt (Google)"
The dentries and inodes are created in the readdir for the sole purpose of
getting a consistent inode number. Linus stated that is unnecessary, and
that all inodes can have the same inode number. For a virtual file system
they are pretty meaningless.
I
[ subject is wrong, but is to match v1, see patch 2 for correct subject ]
Fix reading dir again, this time without creating dentries and inodes.
Changes since v1:
https://lore.kernel.org/linux-trace-kernel/20240116114711.7e863...@gandalf.local.home
Steven Rostedt (Google) (2):
eventfs
From: "Steven Rostedt (Google)"
The dentries and inodes are created in the readdir for the sole purpose of
getting a consistent inode number. Linus stated that is unnecessary, and
that all inodes can have the same inode number. For a virtual file system
they are pretty meaningless.
I
On Tue, 16 Jan 2024 10:53:36 -0800
Linus Torvalds wrote:
> Let's at least *try* to move towards a better and simpler world, in other
> words.
OK, but I did just finish the below. I'll save it for another time if the
single inode becomes an issue.
I cropped it to just 31 bits, so I'm not sure
On Tue, 16 Jan 2024 10:21:49 -0800
Linus Torvalds wrote:
> Here's a clue: just fix your inode numbers.
>
> I can think of many ways to do it. Here's a couple:
>
> - use a fixed inode number for all inodes. It's fine. Really. You might
> confuse some programs that still do g
On Tue, 16 Jan 2024 13:12:28 -0500
Steven Rostedt wrote:
> Maybe I can just use a hash to generate he inode numbers from the name?
> Hopefully there will be no collisions. Then I don't need the dentry
> creation at all.
Maybe I could use a hash of the address of the meta data to create the
; formatting ]
>
> No.
>
> Christ, you're making things worse again
>
> The reason for the bug is that you're still messing with the dentries at
> readdir() time.
I may have deleted the comment, but the only reason I created the
inodes/destries is to keep the consistent inode n
From: "Steven Rostedt (Google)"
The original eventfs code added a wrapper around the dcache_readdir open
callback and created all the dentries and inodes at open, and increment
their ref count. A wrapper was added around the dcache_readdir release
function to decrement all the
On Fri, 12 Jan 2024 08:53:44 -0500
Steven Rostedt wrote:
> > // We managed to open the directory so we have permission to list
> > // directory entries in "xfs".
> > fd = open("/sys/kernel/tracing/events/xfs");
> >
> > // Remove ownership so we can't open the directory anymore
> >
On Fri, 12 Jan 2024 09:27:24 +0100
Christian Brauner wrote:
> On Thu, Jan 11, 2024 at 04:53:19PM -0500, Steven Rostedt wrote:
> > On Thu, 11 Jan 2024 22:01:32 +0100
> > Christian Brauner wrote:
> >
> > > What I'm pointing out in the current logic is that the caller is
> > > taxed twice:
> >
On Thu, Jan 11, 2024 at 04:53:19PM -0500, Steven Rostedt wrote:
> On Thu, 11 Jan 2024 22:01:32 +0100
> Christian Brauner wrote:
>
> > What I'm pointing out in the current logic is that the caller is
> > taxed twice:
> >
> > (1) Once when the VFS has done inode_permission(MAY_EXEC, "xfs")
> >
On Thu, 11 Jan 2024 22:01:32 +0100
Christian Brauner wrote:
> What I'm pointing out in the current logic is that the caller is
> taxed twice:
>
> (1) Once when the VFS has done inode_permission(MAY_EXEC, "xfs")
> (2) And again when you call lookup_one_len() in eventfs_start_creating()
>
need to know about the new
> > tracefs instance including the ownership and the mode of all inodes in
> > /sys/kernel/tracing/instances/foo/events/* and below precisely because
> > ownership is always inherited from the parent dentry and recorded in the
> > metadata struct e
On Wed, 10 Jan 2024 10:52:51 -0500
Steven Rostedt wrote:
> On Wed, 10 Jan 2024 08:07:46 -0500
> Steven Rostedt wrote:
>
> > Or are you saying that I don't need the ".permission" callback, because
> > eventfs does it when it creates the inodes? But for eventfs t
On Wed, 10 Jan 2024 10:52:51 -0500
Steven Rostedt wrote:
> I'll apply this patch too, as it appears to work with this code.
I meant "appears to work without this code".
-- Steve
On Wed, 10 Jan 2024 08:07:46 -0500
Steven Rostedt wrote:
> Or are you saying that I don't need the ".permission" callback, because
> eventfs does it when it creates the inodes? But for eventfs to know what
> the permissions changes are, it uses .getattr and .setattr.
OK, if
On Wed, 10 Jan 2024 12:45:36 +0100
Christian Brauner wrote:
> So say you do:
>
> mkdir /sys/kernel/tracing/instances/foo
>
> After this has returned we know everything we need to know about the new
> tracefs instance including the ownership and the mode of all inodes in
>
gt; > > I don't think so.
> >
> > I'm very well aware that the dentries and inode aren't created during
> > mkdir but the completely directory layout is determined. You're just
> > splicing in dentries and inodes during lookup and readdir.
> >
> > If mkdi
eventfs was so
>
> Every instance/foo/ tracefs instances also contains an events directory
> and thus a eventfs portion. Eventfs is just a subtree of tracefs. It's
> not a separate filesystem. Both eventfs and tracefs are on the same
> single, system wide superblock.
>
> > th
inode aren't created during
> mkdir but the completely directory layout is determined. You're just
> splicing in dentries and inodes during lookup and readdir.
>
> If mkdir /sys/kernel/tracing/instances/foo has succeeded and you later
> do a lookup/readdir on
>
> ls -al /sys/kernel/
subtree of tracefs. It's
not a separate filesystem. Both eventfs and tracefs are on the same
single, system wide superblock.
> that the instance directories wouldn't recreate the same 10thousands
> event inodes and dentries for every mkdir done.
I know but that's irrelevant to what I'm trying
e you a new dentry.
> >
> > Usually this call would have to be changed to lookup_one() and the
> > idmapping be handed down to it. But I think that's irrelevant here.
> >
> > Lookup generally doesn't need to be aware of idmappings at all. The
> > permission checking is
s without that. Although one rationale to do eventfs was so
that the instance directories wouldn't recreate the same 10thousands
event inodes and dentries for every mkdir done.
-- Steve
have in some circumstances. TL;DR nothing to do
> here as well.
The reason ownership is inherited from the parent is because the inodes
are created at boot up before user space starts.
eventfs inodes are created on demand after user space so it needs to
either check the "default"
On Sun, Jan 07, 2024 at 06:42:33PM +0100, Christian Brauner wrote:
> On Sun, Jan 07, 2024 at 01:42:39PM +0100, Christian Brauner wrote:
> > > > So tracefs supports remounting with different uid/gid mount options and
> > > > then actually wades through _all
On Sun, Jan 07, 2024 at 01:42:39PM +0100, Christian Brauner wrote:
> > > So tracefs supports remounting with different uid/gid mount options and
> > > then actually wades through _all_ of the inodes and changes their
> > > ownership internally? What's the us
> > So tracefs supports remounting with different uid/gid mount options and
> > then actually wades through _all_ of the inodes and changes their
> > ownership internally? What's the use-case for this? Containers?
>
> No, in fact tracing doesn't work well with contain
as the default
> > ownership for the files and directories beneath it.
> >
> > Link:
> > https://lore.kernel.org/linux-trace-kernel/CAHk-=wjvdgkjdxbbvln2wbznqp4ush46e3gqj9m7ug6dpx2...@mail.gmail.com/
> >
> > Signed-off-by: Steven Rostedt (Google)
> > -
gt; Link:
> https://lore.kernel.org/linux-trace-kernel/CAHk-=wjvdgkjdxbbvln2wbznqp4ush46e3gqj9m7ug6dpx2...@mail.gmail.com/
>
> Signed-off-by: Steven Rostedt (Google)
> ---
So tracefs supports remounting with different uid/gid mount options and
then actually wades through _all_ of
e structure; never NULL, root of a (sub)tree
has it pointing to itself. Might be negative, might refer to a filesystem
object
(file, directory, symlink, etc.).
inode: filesystem object (file, directory, etc.). Always belongs to
specific filesystem instance. Non-directory inodes might have any
const struct inode_operations *ops)
{
+ struct tracefs_inode *ti;
struct dentry *dentry = tracefs_start_creating(name, parent);
struct inode *inode;
@@ -651,6 +670,9 @@ static struct dentry *__create_dir(const char *name, struct
dentry *parent,
inode->i_ui
On Thu, 4 Jan 2024 01:48:37 +
Al Viro wrote:
> On Wed, Jan 03, 2024 at 08:32:46PM -0500, Steven Rostedt wrote:
>
> > + /* Get the tracefs root from the parent */
> > + inode = d_inode(dentry->d_parent);
> > + inode = d_inode(inode->i_sb->s_root);
>
> That makes no sense. First of
On Thu, 4 Jan 2024 01:59:10 +
Al Viro wrote:
> On Wed, Jan 03, 2024 at 08:32:46PM -0500, Steven Rostedt wrote:
>
> > +static struct inode *instance_inode(struct dentry *parent, struct inode
> > *inode)
> > +{
> > + struct tracefs_inode *ti;
> > + struct inode *root_inode;
> > +
> > +
On Wed, Jan 03, 2024 at 08:32:46PM -0500, Steven Rostedt wrote:
> +static struct inode *instance_inode(struct dentry *parent, struct inode
> *inode)
> +{
> + struct tracefs_inode *ti;
> + struct inode *root_inode;
> +
> + root_inode = d_inode(inode->i_sb->s_root);
> +
> + /* If
On Wed, Jan 03, 2024 at 08:32:46PM -0500, Steven Rostedt wrote:
> + /* Get the tracefs root from the parent */
> + inode = d_inode(dentry->d_parent);
> + inode = d_inode(inode->i_sb->s_root);
That makes no sense. First of all, for any positive dentry we have
dentry->d_sb ==
*ops)
{
+ struct tracefs_inode *ti;
struct dentry *dentry = tracefs_start_creating(name, parent);
struct inode *inode;
@@ -651,6 +677,9 @@ static struct dentry *__create_dir(const char *name, struct
dentry *parent,
inode->i_uid = d_inode(dentry->d_pa
69 flags=0x2010200(slab|head|node)
> > > [ 10.062433] Call Trace:
> > > [ 10.062673] dump_stack_lvl+0x34/0x44
> > > [ 10.062865] slab_err+0x90/0xd0
> > > [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0
> > > [ 10.063848] kmem_cache_destroy
ack_lvl+0x34/0x44
> > [ 10.062865] slab_err+0x90/0xd0
> > [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0
> > [ 10.063848] kmem_cache_destroy+0x4a/0x110
> > [ 10.064058] __x64_sys_delete_module+0x265/0x300
> >
> > This is caused by dax_fs_exit() not flushing
; [ 10.063848] kmem_cache_destroy+0x4a/0x110
> [ 10.064058] __x64_sys_delete_module+0x265/0x300
>
> This is caused by dax_fs_exit() not flushing inodes before destroy cache.
> To fix this issue, call rcu_barrier() before destroy cache.
I don't doubt that this fixes the bug. Howev
Looks good,
Reviewed-by: Christoph Hellwig
_fs_exit() not flushing inodes before destroy cache.
To fix this issue, call rcu_barrier() before destroy cache.
Signed-off-by: Tong Zhang
---
drivers/dax/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index e3029389d809..6bd565fe2e63 100644
--- a
On Fri, Feb 05, 2021 at 01:23:13PM -0800, Andrew Morton wrote:
> On Fri, 5 Feb 2021 14:55:43 -0600 Seth Forshee
> wrote:
>
> > On Fri, Feb 05, 2021 at 12:41:57PM -0800, Andrew Morton wrote:
> > > On Fri, 5 Feb 2021 14:21:59 -0600 Seth Forshee
> > > wrote:
> > >
> > > > Currently there seems
On Fri, 5 Feb 2021 14:55:43 -0600 Seth Forshee
wrote:
> On Fri, Feb 05, 2021 at 12:41:57PM -0800, Andrew Morton wrote:
> > On Fri, 5 Feb 2021 14:21:59 -0600 Seth Forshee
> > wrote:
> >
> > > Currently there seems to be an assumption in tmpfs that 64-bit
> > > architectures also have a
On Fri, Feb 05, 2021 at 12:41:57PM -0800, Andrew Morton wrote:
> On Fri, 5 Feb 2021 14:21:59 -0600 Seth Forshee
> wrote:
>
> > Currently there seems to be an assumption in tmpfs that 64-bit
> > architectures also have a 64-bit ino_t. This is not true; s390 at
> > least has a 32-bit ino_t. With
On Fri, 5 Feb 2021 14:21:59 -0600 Seth Forshee
wrote:
> Currently there seems to be an assumption in tmpfs that 64-bit
> architectures also have a 64-bit ino_t. This is not true; s390 at
> least has a 32-bit ino_t. With CONFIG_TMPFS_INODE64=y tmpfs
> mounts will get 64-bit inode numbers and
4
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3733,7 +3733,7 @@ static int shmem_fill_super(struct super_block *sb,
struct fs_context *fc)
ctx->blocks = shmem_default_max_blocks();
if (!(ctx->seen & SHMEM_SEEN_INODES))
ctx->ino
On Sat, Jan 30, 2021 at 11:06:40AM -0600, Tyler Hicks wrote:
> Hey Jeffrey and Dan - thanks for the patch! Unfortunately, I think this
> would allow the eCryptfs inode's nlink count to get out of sync with the
> lower inode's nlink count in the case of direct manipulation to the
> lower
On 2020-12-18 13:07:30, Jeffrey Mitchell wrote:
> On asynchronous base filesystems like NFS, eCryptFS leaves inodes for
> deleted files in the cache until unmounting. Change call in
> ecryptfs_do_unlink() from set_nlink() to drop_nlink() in order to reliably
> evict inodes from th
From: Josef Bacik
[ Upstream commit e076ab2a2ca70a0270232067cd49f76cd92efe64 ]
Commit 38d715f494f2 ("btrfs: use btrfs_start_delalloc_roots in
shrink_delalloc") cleaned up how we do delalloc shrinking by utilizing
some infrastructure we have in place to flush inodes that we use
> >
> > > Daniel Colascione (3):
> > > fs: add LSM-supporting anon-inode interface
> > > selinux: teach SELinux about anonymous inodes
> > > userfaultfd: use secure anon inodes for userfaultfd
> > >
> > > Lokesh Gidra (1):
> > >
isky. This patch series allows SELinux to manage userfaultfd
> > file descriptors and in the future, other kinds of
> > anonymous-inode-based file descriptor.
>
> ...
>
> > Daniel Colascione (3):
> > fs: add LSM-supporting anon-inode interface
> > selinux: te
d in the future, other kinds of
> anonymous-inode-based file descriptor.
...
> Daniel Colascione (3):
> fs: add LSM-supporting anon-inode interface
> selinux: teach SELinux about anonymous inodes
> userfaultfd: use secure anon inodes for userfaultfd
>
>
From: Daniel Colascione
This change gives userfaultfd file descriptors a real security
context, allowing policy to act on them.
Signed-off-by: Daniel Colascione
[LG: Remove owner inode from userfaultfd_ctx]
[LG: Use anon_inode_getfd_secure() instead of anon_inode_getfile_secure()
in
policy authors can
apply policy types to anonymous inodes by providing name-based
transition rules keyed off the anonymous inode internal name (
"[userfaultfd]" in the case of userfaultfd(2) file descriptors) and
applying policy to the new SIDs thus produced.
With SELinux managed u
these anonymous inodes by
adding a name-based type_transition rule that assigns a new security
type to anonymous-inode files created in some domain. The name used
for the name-based transition is the name associated with the
anonymous inode for file listings --- e.g., "[userfaultfd]" or
&q
> > > the previous patches to give SELinux the ability to control
> > > > > anonymous-inode files that are created using the new
> > > > > anon_inode_getfd_secure() function.
> > > > >
> > > > > A SELinux policy author detects and controls these a
new
> > > > anon_inode_getfd_secure() function.
> > > >
> > > > A SELinux policy author detects and controls these anonymous inodes by
> > > > adding a name-based type_transition rule that assigns a new security
> > > > type to anonymous-i
ure introduced in
> > > the previous patches to give SELinux the ability to control
> > > anonymous-inode files that are created using the new
> > > anon_inode_getfd_secure() function.
> > >
> > > A SELinux policy author detects and controls these anon
anon_inodes and LSM infrastructure introduced in
> > > the previous patches to give SELinux the ability to control
> > > anonymous-inode files that are created using the new
> > > anon_inode_getfd_secure() function.
> > >
> > > A SELinux policy author detects and cont
on_inode_getfd_secure() function.
>
> A SELinux policy author detects and controls these anonymous inodes by
> adding a name-based type_transition rule that assigns a new security
> type to anonymous-inode files created in some domain. The name used
> for the name-bas
to control
> > anonymous-inode files that are created using the new
> > anon_inode_getfd_secure() function.
> >
> > A SELinux policy author detects and controls these anonymous inodes by
> > adding a name-based type_transition rule that assigns a new security
> &
From: Daniel Colascione
This change gives userfaultfd file descriptors a real security
context, allowing policy to act on them.
Signed-off-by: Daniel Colascione
[LG: Remove owner inode from userfaultfd_ctx]
[LG: Use anon_inode_getfd_secure() instead of anon_inode_getfile_secure()
in
these anonymous inodes by
adding a name-based type_transition rule that assigns a new security
type to anonymous-inode files created in some domain. The name used
for the name-based transition is the name associated with the
anonymous inode for file listings --- e.g., "[userfaultfd]" or
&q
policy authors can
apply policy types to anonymous inodes by providing name-based
transition rules keyed off the anonymous inode internal name (
"[userfaultfd]" in the case of userfaultfd(2) file descriptors) and
applying policy to the new SIDs thus produced.
With SELinux managed u
_getfd_secure() function.
> > > >
> > > > A SELinux policy author detects and controls these anonymous inodes by
> > > > adding a name-based type_transition rule that assigns a new security
> > > > type to anonymous-inode files created in some domain.
ure introduced in
> > > the previous patches to give SELinux the ability to control
> > > anonymous-inode files that are created using the new
> > > anon_inode_getfd_secure() function.
> > >
> > > A SELinux policy author detects and controls these anon
From: "Eric W. Biederman"
[ Upstream commit 7bc3e6e55acf065500a24621f3b313e7e5998acf ]
Rework the flushing of proc to use a list of directory inodes that
need to be flushed.
The list is kept on struct pid not on struct task_struct, as there is
a fixed connection between proc inode
From: "Eric W. Biederman"
[ Upstream commit 7bc3e6e55acf065500a24621f3b313e7e5998acf ]
Rework the flushing of proc to use a list of directory inodes that
need to be flushed.
The list is kept on struct pid not on struct task_struct, as there is
a fixed connection between proc inode
to control
> > anonymous-inode files that are created using the new
> > anon_inode_getfd_secure() function.
> >
> > A SELinux policy author detects and controls these anonymous inodes by
> > adding a name-based type_transition rule that assigns a new security
> > t
inode_getfd_secure() function.
>
> A SELinux policy author detects and controls these anonymous inodes by
> adding a name-based type_transition rule that assigns a new security
> type to anonymous-inode files created in some domain. The name used
> for the name-based
RFS critical (device (efault)): regular/prealloc extent
found for non-regular inode 256
[ 9415.131428] BTRFS: selftest: fs/btrfs/tests/inode-tests.c:904 expected a
real extent, got 0
This happens because the test inodes are created without ever initializing
the i_mode field of the inode, and neit
RFS critical (device (efault)): regular/prealloc extent
found for non-regular inode 256
[ 9415.131428] BTRFS: selftest: fs/btrfs/tests/inode-tests.c:904 expected a
real extent, got 0
This happens because the test inodes are created without ever initializing
the i_mode field of the inode, and neit
RFS critical (device (efault)): regular/prealloc extent
found for non-regular inode 256
[ 9415.131428] BTRFS: selftest: fs/btrfs/tests/inode-tests.c:904 expected a
real extent, got 0
This happens because the test inodes are created without ever initializing
the i_mode field of the inode, and neit
From: Jan Kara
commit 46e294efc355c48d1dd4d58501aa56dac461792a upstream.
Xattr code using inodes with large xattr data can end up dropping last
inode reference (and thus deleting the inode) from places like
ext4_xattr_set_entry(). That function is called with transaction started
and so
From: Jan Kara
commit 46e294efc355c48d1dd4d58501aa56dac461792a upstream.
Xattr code using inodes with large xattr data can end up dropping last
inode reference (and thus deleting the inode) from places like
ext4_xattr_set_entry(). That function is called with transaction started
and so
From: Jan Kara
commit 46e294efc355c48d1dd4d58501aa56dac461792a upstream.
Xattr code using inodes with large xattr data can end up dropping last
inode reference (and thus deleting the inode) from places like
ext4_xattr_set_entry(). That function is called with transaction started
and so
From: Jan Kara
commit 46e294efc355c48d1dd4d58501aa56dac461792a upstream.
Xattr code using inodes with large xattr data can end up dropping last
inode reference (and thus deleting the inode) from places like
ext4_xattr_set_entry(). That function is called with transaction started
and so
From: Filipe Manana
[ Upstream commit 4d6221d7d83141d58ece6560e9cfd4cc92eab044 ]
When logging an inode and we are checking if we need to log ancestors that
are new, if the previous transaction is still committing we have a time
window where we can unnecessarily log ancestor inodes that were
ase filesystems like NFS, eCryptFS leaves inodes for
> deleted files in the cache until unmounting. Change call in
> ecryptfs_do_unlink() from set_nlink() to drop_nlink() in order to reliably
> evict inodes from the cache even on top of NFS.
>
> Signed-off-by: Dan Robertson
>
On asynchronous base filesystems like NFS, eCryptFS leaves inodes for
deleted files in the cache until unmounting. Change call in
ecryptfs_do_unlink() from set_nlink() to drop_nlink() in order to reliably
evict inodes from the cache even on top of NFS.
Signed-off-by: Dan Robertson
Signed-off
the header fs/bfs/bfs.h, which explains it:
> > >
> > > /* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up
> > > to 513 inclusive.
> > >In actual fact, attempting to create the 512th inode (i.e. inode
> > > No. 513 or file No. 511)
&
ortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+2435de7315366e15f...@syzkaller.appspotmail.com
>
> BFS-fs: bfs_fill_super(): WARNING: filesystem loop1 was created with 5
ducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+1a219abc12077a390...@syzkaller.appspotmail.com
>
> BFS-fs: bfs_fill_super(): WARNING: filesystem loop4 was created with 512
> inodes, the real maximum is 51
a2dcbd030eadbf0aa9b660efe864ff08af6e18b)
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ae3ff0bb2a0133596...@syzkaller.appspotmail.com
>
> BFS-fs: bfs_fill_super
ortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+293714df4fe354fae...@syzkaller.appspotmail.com
>
> BFS-fs: bfs_fill_super(): WARNING: filesystem loop3 was created with 5
otmail.com
>
> BFS-fs: bfs_fill_super(): WARNING: filesystem loop0 was created with 512
> inodes, the real maximum is 511, mounting anywa
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot e
the issue, please add the following tag to the commit:
Reported-by: syzbot+02c44c7f92e70a737...@syzkaller.appspotmail.com
BFS-fs: bfs_fill_super(): WARNING: filesystem loop0 was created with 512
inodes, the real maximum is 511, mounting anywa
---
This report is generated by a bot. It may contain errors
From: "Eric W. Biederman"
[ Upstream commit 7bc3e6e55acf065500a24621f3b313e7e5998acf ]
Rework the flushing of proc to use a list of directory inodes that
need to be flushed.
The list is kept on struct pid not on struct task_struct, as there is
a fixed connection between proc inode
kaller.appspot.com/x/.config?x=b81aff78c272da44
> > >>>>>> dashboard link:
> > >>>>>> https://syzkaller.appspot.com/bug?extid=3fd34060f26e766536ff
> > >>>>>> compiler: gcc (GCC) 10.1.0-syz 20200507
> > >>>>>>
> &g
1 - 100 of 1898 matches
Mail list logo
