On Thu, Nov 14, 2024 at 01:21:41PM -0600, Aaron Rainbolt wrote:
> binary you get after compiling and linking. It looks to me like this
> patch will prevent users from compiling Tuxedo's modules for personal
> use on their own systems though. I personally dislike that for ethical
> reasons - I shou
On Wed, Sep 25, 2024 at 08:48:16PM +0200, Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 25 Sep 2024 20:36:35 +0200
>
> Assign the return value from a copy_to_user() call to an additional
> local variable so that a kvfree() call and return statement can be
> omitted accordingly.
Ugly
On Wed, Aug 07, 2024 at 09:35:45AM -0400, Steven Rostedt wrote:
> Perhaps:
>
> diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
> index f704d8348357..ab6d6c3d835d 100644
> --- a/fs/tracefs/internal.h
> +++ b/fs/tracefs/internal.h
> @@ -10,12 +10,12 @@ enum {
> };
>
> struct tracefs_
On Wed, Jan 31, 2024 at 09:26:42PM -0500, Steven Rostedt wrote:
> > Huh? Just return NULL and be done with that - you'll get an
> > unhashed negative dentry and let the caller turn that into
> > -ENOENT...
>
> We had a problem here with just returning NULL. It leaves the negative
> dentry around
On Wed, Jan 31, 2024 at 01:49:22PM -0500, Steven Rostedt wrote:
> @@ -329,32 +320,29 @@ static struct dentry *create_file(const char *name,
> umode_t mode,
>
> ti = get_tracefs(inode);
> ti->flags |= TRACEFS_EVENT_INODE;
> - d_instantiate(dentry, inode);
> +
> + d_add(dentry
On Tue, Jan 30, 2024 at 07:39:55PM -0800, Linus Torvalds wrote:
> Why don't we, btw? It would be so much better if we did the
> d_release() from __d_free(). We have all that smarts in fs/dcache.c to
> decide if we need to RCU-delay it or not, and then we don't let
> filesystems use it.
Because we
On Tue, Jan 30, 2024 at 06:37:49PM -0800, Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 17:12, Al Viro wrote:
> >
> > > + *
> > > + * Note that d_revalidate is called potentially under RCU,
> > > + * so it can't take the eventfs mutex etc. It's f
On Tue, Jan 30, 2024 at 11:03:55AM -0800, Linus Torvalds wrote:
> +void eventfs_d_release(struct dentry *dentry)
> {
> - struct eventfs_inode *ei;
> -
> - mutex_lock(&eventfs_mutex);
> - ei = dentry->d_fsdata;
> - if (ei) {
> - dentry->d_fsdata = NULL;
> -
On Tue, Jan 30, 2024 at 11:03:54AM -0800, Linus Torvalds wrote:
> inode = tracefs_get_inode(dentry->d_sb);
> if (unlikely(!inode))
> - return eventfs_failed_creating(dentry);
> + return ERR_PTR(-ENOMEM);
That belongs in the lookup crapectomy patch - bisect haza
On Tue, Jan 30, 2024 at 11:03:52AM -0800, Linus Torvalds wrote:
> {
> struct eventfs_inode *ei;
>
> - mutex_lock(&eventfs_mutex);
> do {
> // The parent is stable because we do not do renames
> dentry = dentry->d_parent;
> @@ -247,7 +246,6 @@ static st
On Tue, Jan 30, 2024 at 06:55:36PM -0500, Steven Rostedt wrote:
> Actually it's the tracefs_start_creating() locks the inode, the
> eventfs_start_creating() doesn't.
Right.
> >
> > > if (unlikely(!inode))
> > > return eventfs_failed_creating(dentry);
> >
> > ... and that still un
On Tue, Jan 30, 2024 at 11:03:52AM -0800, Linus Torvalds wrote:
> The dentry lookup for eventfs files was very broken, and had lots of
> signs of the old situation where the filesystem names were all created
> statically in the dentry tree, rather than being looked up dynamically
> based on the eve
On Sun, Jan 28, 2024 at 08:36:12PM -0800, Linus Torvalds wrote:
[snip]
apologies for being MIA on that, will post tomorrow morning once I get some
sleep...
On Wed, Jan 03, 2024 at 09:25:06PM -0500, Steven Rostedt wrote:
> 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 */
> >
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 pa
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 == dentry->d
On Wed, Jan 03, 2024 at 01:54:36PM -0800, Linus Torvalds wrote:
> Again: UNTESTED, and meant as a "this is another way to avoid messing
> with the dentry tree manually, and just using the VFS interfaces we
> already have"
That would break chown(), though. From conversation back in November:
17:
On Tue, Oct 31, 2023 at 02:47:03PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Looking at how dentry is removed via the tracefs system, I found that
> eventfs does not do everything that it did under tracefs. The tracefs
> removal of a dentry calls simple_recursive_removal(
On Fri, Sep 15, 2023 at 03:28:14PM +0100, Al Viro wrote:
> On Fri, Sep 15, 2023 at 04:12:07PM +0200, Christian Brauner wrote:
> > + static void some_fs_kill_sb(struct super_block *sb)
> > + {
> > + struct some_fs_info *info = sb->s_fs_info;
> > +
&
On Fri, Sep 15, 2023 at 04:12:07PM +0200, Christian Brauner wrote:
> + static void some_fs_kill_sb(struct super_block *sb)
> + {
> + struct some_fs_info *info = sb->s_fs_info;
> +
> + kill_*_super(sb);
> + kfree(info);
> + }
> +
> +It's best practice
On Thu, Sep 14, 2023 at 05:58:05PM +0100, Al Viro wrote:
> Incidentally, I'm going to add a (belated by 10 years) chunk in porting.rst
> re making sure that anything in superblock that might be needed by methods
> called in RCU mode should *not* be freed without an RCU delay... Sh
On Thu, Sep 14, 2023 at 04:02:25PM +0200, Christian Brauner wrote:
> Yes, you're right that making the superblock and not the filesytem type
> the bd_holder changes the logic and we are aware of that of course. And
> it requires changes such as moving additional block device closing from
> where s
On Thu, Sep 14, 2023 at 03:37:05AM +0100, Al Viro wrote:
> On Thu, Sep 14, 2023 at 12:27:12AM +0100, Al Viro wrote:
> > On Wed, Sep 13, 2023 at 08:09:57AM -0300, Christoph Hellwig wrote:
> > > Releasing an anon dev_t is a very common thing when freeing a
> > > supe
On Thu, Sep 14, 2023 at 12:27:12AM +0100, Al Viro wrote:
> On Wed, Sep 13, 2023 at 08:09:57AM -0300, Christoph Hellwig wrote:
> > Releasing an anon dev_t is a very common thing when freeing a
> > super_block, as that's done for basically any not block based file
> >
On Wed, Sep 13, 2023 at 08:10:07AM -0300, Christoph Hellwig wrote:
> -static void affs_kill_sb(struct super_block *sb)
> +static void affs_free_sb(struct super_block *sb)
> {
> struct affs_sb_info *sbi = AFFS_SB(sb);
> - kill_block_super(sb);
> +
> + block_free_sb(sb);
> if (s
On Wed, Sep 13, 2023 at 08:10:05AM -0300, Christoph Hellwig wrote:
> Currently super_blocks are shut down using the ->kill_sb method, which
> must call generic_shutdown_super, but allows the file system to
> add extra work before or after the call to generic_shutdown_super.
>
> File systems tend t
On Wed, Sep 13, 2023 at 08:10:03AM -0300, Christoph Hellwig wrote:
> When ->fill_super fails, ->kill_sb is called which already cleans up
> the inodes and zgroups.
Ugh... The use of "->" strongly suggests that you are talking about
a method; 'fill_super' here actually refers to callback passed to
On Wed, Sep 13, 2023 at 08:09:59AM -0300, Christoph Hellwig wrote:
> diff --git a/fs/super.c b/fs/super.c
> index bbe55f0651cca4..5c685b4944c2d6 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -787,7 +787,7 @@ struct super_block *sget_fc(struct fs_context *fc,
> struct super_block *s = NUL
On Wed, Sep 13, 2023 at 08:09:57AM -0300, Christoph Hellwig wrote:
> Releasing an anon dev_t is a very common thing when freeing a
> super_block, as that's done for basically any not block based file
> system (modulo the odd mtd special case). So instead of requiring
> a special ->kill_sb helper a
On Tue, Jun 14, 2022 at 01:53:50AM +0100, Al Viro wrote:
> FWIW, I've got quite a bit of cleanups in the local tree; reordering and
> cleaning that queue up at the moment, will post tonight or tomorrow.
>
> I've looked into doing allocations page-by-page (instead
On Tue, Jun 14, 2022 at 07:36:19AM +0100, David Howells wrote:
> Al Viro wrote:
>
> > What's wrong with
> > p_occupancy = pipe_occupancy(head, tail);
> > if (p_occupancy >= pipe->max_usage)
> > return 0;
> >
On Mon, Jun 13, 2022 at 11:28:34PM +0100, Al Viro wrote:
> On Mon, Jun 13, 2022 at 10:54:36AM -0700, Linus Torvalds wrote:
> > On Sun, Jun 12, 2022 at 5:10 PM Al Viro wrote:
> > >
> > > Unlike other copying operations on ITER_PIPE, copy_mc_to_iter() can
> > > r
On Tue, Jun 14, 2022 at 12:25:03AM +0100, Al Viro wrote:
> The more I'm looking at that thing, the more it smells like a bug;
> it had the same 3 callers since the time it had been introduced.
>
> 1) pipe_get_pages(). We are about to try and allocate up to that
> many pipe
On Mon, Jun 13, 2022 at 11:28:34PM +0100, Al Viro wrote:
> Dave, could you explain what's going on there? Note that pipe_write()
> does *not* use that thing at all; it's only splice (i.e. ITER_PIPE
> stuff) that is using it.
>
> What's wrong with
>
On Mon, Jun 13, 2022 at 10:54:36AM -0700, Linus Torvalds wrote:
> On Sun, Jun 12, 2022 at 5:10 PM Al Viro wrote:
> >
> > Unlike other copying operations on ITER_PIPE, copy_mc_to_iter() can
> > result in a short copy. In that case we need to trim the unused
> > buffer
/iov_iter.c for now and move it later,
but I don't see the point going that way...
Fixes: ca146f6f091e "lib/iov_iter: Fix pipe handling in _copy_to_iter_mcsafe()"
Signed-off-by: Al Viro
---
diff --git a/include/linux/pipe_fs_i.h b/include/linux/pipe_fs_i.h
index cb0fd633a610..4ea49
On Tue, Apr 20, 2021 at 11:39:04AM +0200, Lukas Bulwahn wrote:
> Dear Qing,
>
> ./scripts/spdxcheck.py reports:
>
> arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi: 1:28 Invalid
> License ID: GPL-3.0
>
> You have contributed this file with commit b1a792601f26 ("MIPS:
> Loongson64: DeviceTree
On Tue, Apr 20, 2021 at 04:32:33PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 20, 2021 at 3:37 PM wrote:
> >
> > From: Guo Ren
> >
> > $ grep strlen_user * -r
> > arch/csky/include/asm/uaccess.h:#define strlen_user(str) strnlen_user(str,
> > 32767)
> > arch/csky/lib/usercopy.c: * strlen_user: - G
On Tue, Apr 06, 2021 at 07:09:12PM -0500, Aditya Pakki wrote:
> --- a/net/rds/send.c
> +++ b/net/rds/send.c
> @@ -665,7 +665,7 @@ static void rds_send_remove_from_sock(struct list_head
> *messages, int status)
> unlock_and_drop:
> spin_unlock_irqrestore(&rm->m_rs_lock, flags);
>
On Sat, Apr 17, 2021 at 03:11:49PM -0700, Linus Torvalds wrote:
> On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote:
> >
> > No, wait - we have non-NULL buf->prev_reclen, so we'll hit
> > with buf->error completely ignored. Nevermind.
>
> Yeah, I'm pretty
On Sat, Apr 17, 2021 at 08:30:42PM +, Al Viro wrote:
> and that thing is still there. However, it does *NOT* do what it might
> appear to be doing; it ends up with getdents() returning -EINVAL instead.
> What we need is
> buf->error = -EINTR;
> i
[tytso Cc'd]
On Sat, Apr 17, 2021 at 06:09:44PM +0000, Al Viro wrote:
> > Al - fairly trivial patch applied, comments?
>
> Should be fine... FWIW, I've a patch in the same area, making those suckers
> return bool. Seeing that they are only ever called via dir_emit()
is very much an example of the same issue that put_cmsg() has in
> net-next: unsafe user copies should be fully guarded and not have some
> "but this would never happen because callers would never do anything
> bad".
>
> Al - fairly trivial patch applied, comments?
Shoul
On Sat, Apr 17, 2021 at 12:04:16AM +0200, Willy Tarreau wrote:
> Yep but I kept it just to have comparable output code since in C
> you'd simply use "goto leave" and not have this function call to
> do the cleanup.
... or use any number of other technics; the real question was how
much of cleanup
On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> We have to loop only to copy u64 values.
> After this first loop, we copy at most one u32, one u16 and one byte.
Does it actually yield a better code?
FWIW, this
void bar(unsigned);
void foo(unsigned n)
{
On Fri, Apr 16, 2021 at 07:47:32PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 7:05 PM Linus Torvalds
> wrote:
> >
> > Typical Rust error handling should match the regular kernel
> > IS_ERR/ERR_PTR/PTR_ERR model fairly well, although the syntax is
> > fairly different (and it's not limite
On Sat, Apr 17, 2021 at 01:20:12AM +0800, Chung-Chiang Cheng wrote:
> hfsplus uses the case-insensitive filenames by default, but VFS negative
> dentries are incompatible with case-insensitive. For example, the
> following instructions will get a cached filename 'aaa' which isn't
> expected. There
On Fri, Apr 16, 2021 at 05:53:03PM +0800, Zhongjun Tan wrote:
> @@ -710,13 +711,14 @@ static int smack_sb_eat_lsm_opts(char *options, void
> **mnt_opts)
> token = match_opt_prefix(from, len, &arg);
> if (token != Opt_error) {
> arg = kmemdup_nul(
On Fri, Apr 16, 2021 at 03:22:16AM +0100, Wedson Almeida Filho wrote:
> > HTML is not a valid documentation format. Heck, markdown itself is
> > barely readable.
>
> Are you stating [what you perceive as] a fact or just venting? If the former,
> would you mind enlightening us with some evidence?
ce() choose between
it and receive_fd() according to what userland had passed to it in
flags]
Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro
diff --git a/fs/file.c b/fs/file.c
index f3a4bac2cbe9..d8ccb95a7f41 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -1068,8 +1068,6
On Thu, Mar 25, 2021 at 09:22:09AM +0100, Christoph Hellwig wrote:
> receive_fd_replace shares almost no code with the general case, so split
> it out. Also remove the "Bump the sock usage counts" comment from
> both copies, as that is now what __receive_sock actually does.
Nice, except that you'
On Thu, Apr 15, 2021 at 12:24:13PM +0200, Jan Kara wrote:
> On Thu 15-04-21 17:43:32, Chao Yu wrote:
> > 9902af79c01a ("parallel lookups: actual switch to rwsem") changes inode
> > lock from mutex to rwsem, however, we forgot to adjust lock for
> > DIO_LOCKING flag in do_blockdev_direct_IO(),
The
On Thu, Apr 15, 2021 at 07:56:05AM +0200, Christoph Hellwig wrote:
> binfmt_flat tends to go through Greg's uclinux tree, adding him and
> the list.
FWIW, my involvement with binfmt_flat had been pretty much nil -
the least trivial had been "binfmt_flat: flat_{get,put}_addr_from_rp()
shoul
On Mon, Apr 12, 2021 at 03:07:56PM +0200, Miklos Szeredi wrote:
> Hi Al,
>
> Fixed fileattr branch pushed to:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git fileattr_v6
Merged and pushed out...
On Mon, Apr 12, 2021 at 11:53:02AM +, Bence Csókás wrote:
> While the preamble field _is_ technically big-endian, its value is always
> 0x2A2A,
> which is the same in either endianness, therefore it should be u16 instead.
Just replace the assignment with htons(0x2A2A) and be done with that -
On Wed, Apr 14, 2021 at 03:00:48AM +, Al Viro wrote:
> Ugh... So when dput() drives the refcount down to 0 you hit lock_parent()
> and only then bother to check if the sucker had been negative in the
On Wed, Apr 14, 2021 at 03:41:10AM +, Al Viro wrote:
> > + if (!d_is_tail_negative(dentry)) {
> > + parent = lock_parent(dentry);
> > + if (!parent)
> > + return;
>
> Wait a minute. It's not a good environment fo
From: Florian Fainelli
Older 32-bit only Broadcom STB chips used a NS16550A compatible UART,
the 8250_bcm7271.c driver can drive those UARTs just fine provided that
we let it match the appropriate compatible string.
Signed-off-by: Florian Fainelli
Reviewed-by: Al Cooper
---
drivers/tty
On Thu, Jan 21, 2021 at 06:49:45PM +0530, Gautham Ananthakrishna wrote:
> + spin_lock(&victim->d_lock);
> + parent = lock_parent(victim);
> +
> + rcu_read_unlock();
Similar story. As soon as you hit that rcu_read_unlock(), the memory
pointed to by victim might be reused. If you have
On Thu, Jan 21, 2021 at 06:49:40PM +0530, Gautham Ananthakrishna wrote:
> +static void sweep_negative(struct dentry *dentry)
> +{
> + struct dentry *parent;
> +
> + if (!d_is_tail_negative(dentry)) {
> + parent = lock_parent(dentry);
> + if (!parent)
> +
On Thu, Jan 21, 2021 at 06:49:40PM +0530, Gautham Ananthakrishna wrote:
> From: Konstantin Khlebnikov
>
> For disk filesystems result of every negative lookup is cached, content of
> directories is usually cached too. Production of negative dentries isn't
> limited with disk speed. It's really ea
On Thu, Jan 21, 2021 at 06:49:39PM +0530, Gautham Ananthakrishna wrote:
> We tested this patch set recently and found it limiting negative dentry to a
> small part of total memory. The following is the test result we ran on two
> types of servers, one is 256G memory with 24 CPUS and another is 3T
On Fri, Apr 09, 2021 at 01:52:11AM +, Al Viro wrote:
> On Wed, Apr 07, 2021 at 09:22:52PM +0200, Miklos Szeredi wrote:
> > Hi Al,
> >
> > Please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git fileattr_v4
> >
>
On Wed, Apr 07, 2021 at 09:22:52PM +0200, Miklos Szeredi wrote:
> Hi Al,
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git fileattr_v4
>
> Convert all (with the exception of CIFS) filesystems from handling
> FS_IOC_[GS]ETFLAGS
On Fri, Apr 09, 2021 at 09:15:06AM +0800, Ian Kent wrote:
> + parent = kernfs_dentry_node(dentry->d_parent);
> + if (parent) {
> + const void *ns = NULL;
> +
> + if (kernfs_ns_enabled(parent))
> + ns = kernf
On Thu, Apr 08, 2021 at 03:04:07PM +0100, David Howells wrote:
> Add an iterator, ITER_XARRAY, that walks through a set of pages attached to
> an xarray, starting at a given page and offset and walking for the
> specified amount of bytes. The iterator supports transparent huge pages.
>
> The iter
On Thu, Apr 08, 2021 at 01:49:35PM -0700, Daniel Xu wrote:
> Ah right, sorry. Nobody will clean up the super_block.
>
> > IOW, NAK. The objects you are playing with have non-trivial lifecycle
> > and poking into the guts of data structures without bothering to
> > understand it is not a good ide
On Wed, Apr 07, 2021 at 02:46:11PM -0700, Daniel Xu wrote:
> +static void fini_seq_pagecache(void *priv_data)
> +{
> + struct bpf_iter_seq_pagecache_info *info = priv_data;
> + struct radix_tree_iter iter;
> + struct super_block *sb;
> + void **slot;
> +
> + radix_tree_for_each
LOOKUP_MOUNTPOINT: we are cleaning "jumped" flag too late (2021-04-06
20:33:00 -0400)
Al Viro (1):
LOOKUP_MOUNTPOINT: we are cleaning "jumped" flag too late
fs/namei.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
-0400)
--------
Al Viro (2):
hostfs: fix memory handling in follow_link()
Make sure nd->path.mnt and nd->path.dentry are always valid pointers
fs/hostfs/hostfs_kern.c | 7 +++
fs/namei.c | 6 --
2 files changed, 7 inse
On Tue, Apr 06, 2021 at 02:15:01PM +, Al Viro wrote:
> I'm referring to the fact that your diff is with an already modified
> path_lookupat()
> _and_ those modifications have managed to introduce a bug your patch reverts.
> No terminate_walk() paired with that path_in
On Tue, Apr 06, 2021 at 03:22:05PM +0200, Christian Brauner wrote:
> Why is a another function in charge of checking the return value of an
> initialization function. If something like path_init() fails why is the
> next caller responsible for rejecting it's return value and then we're
> passing t
On Tue, Apr 06, 2021 at 02:35:05PM +0200, Christian Brauner wrote:
> And while we're at it might I bring up the possibility of an additional
> cleanup of how we currently call path_init().
> Right now we pass the return value from path_init() directly into e.g.
> link_path_walk() which as a first
> -Original Message-
> From: Leo Yan
> Sent: 03 April 2021 08:24
> To: Arnaldo Carvalho de Melo ; John Garry
> ; Will Deacon ; Mathieu Poirier
> ; James Clark ; Al Grant
> ; Peter Zijlstra ; Ingo Molnar
> ; Mark Rutland ; Alexander
> Shishkin ; Jiri Ols
On Tue, Apr 06, 2021 at 01:38:39AM +, Al Viro wrote:
> On Mon, Apr 05, 2021 at 10:07:37PM +0200, Christian Brauner wrote:
>
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index 216f16e74351..82344f1139ff 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/
y allocated objects.
2) non-NULL while we are successfully walking
3) NULL when we are not walking at all
4) contributing to refcounts whenever non-NULL outside of RCU mode.
Hopefully-fixes: 6c6ec2b0a3e0 ("fs: add support for LOOKUP_CACHED")
Signed-off-by: Al Viro
---
dif
On Mon, Apr 05, 2021 at 06:23:49PM +, Al Viro wrote:
> On Mon, Apr 05, 2021 at 07:08:01PM +0200, Christian Brauner wrote:
>
> > Ah dentry count of -127 looks... odd.
>
> dead + 1...
>
> void lockref_mark_dead(struct lockref *lockref)
> {
> ass
On Mon, Apr 05, 2021 at 07:08:01PM +0200, Christian Brauner wrote:
> Ah dentry count of -127 looks... odd.
dead + 1...
void lockref_mark_dead(struct lockref *lockref)
{
assert_spin_locked(&lockref->lock);
lockref->count = -128;
}
IOW, a leaked (uncounted) reference to dentry, th
On Mon, Apr 05, 2021 at 01:44:37PM +0200, Christian Brauner wrote:
> On Sun, Apr 04, 2021 at 08:17:21PM +0000, Al Viro wrote:
> > On Sun, Apr 04, 2021 at 06:50:10PM +, Al Viro wrote:
> >
> > > > Yeah, I have at least namei.o
> > > >
On Sun, Apr 04, 2021 at 06:50:10PM +, Al Viro wrote:
> > Yeah, I have at least namei.o
> >
> > https://drive.google.com/file/d/1AvO1St0YltIrA86DXjp1Xg3ojtS9owGh/view?usp=sharing
>
> *grumble*
>
> Is it reproducible without KASAN? Would be much easie
On Sun, Apr 04, 2021 at 07:05:13PM +0200, Christian Brauner wrote:
> On Sun, Apr 04, 2021 at 04:44:06PM +0000, Al Viro wrote:
> > On Sun, Apr 04, 2021 at 06:40:40PM +0200, Christian Brauner wrote:
> >
> > > > Very interesting. What happens if you call loop() twice?
On Sun, Apr 04, 2021 at 06:40:40PM +0200, Christian Brauner wrote:
> > Very interesting. What happens if you call loop() twice? And now I wonder
> > whether it's root or cwd, actually... Hmm...
> >
> > How about this:
> > fd = open("/proc/self/mountinfo", 0);
> > mkdir("./newroot/foo",
On Sun, Apr 04, 2021 at 01:34:45PM +0200, Christian Brauner wrote:
> Sorry for not replying to your earlier mail but I've been debugging this
> too. My current theory is that it's related to LOOKUP_ROOT_GRABBED when
> LOOKUP_CACHED is specified _possibly_ with an interaction how
> create_io_thread
On Sun, Apr 04, 2021 at 02:34:08AM +, Al Viro wrote:
> I really wonder what mount is it happening to. BTW, how painful would
> it be to teach syzcaller to turn those cascades of
> NONFAILING(*(uint8_t*)0x2080 = 0x12);
> NONFAILING(*(uint8_t*)0x
On Thu, Apr 01, 2021 at 07:11:12PM +, Al Viro wrote:
> > I _think_ I see what the issue is. It seems that an assumption made in
> > this commit might be wrong and we're missing a mnt_add_count() bump that
> > we would otherwise have gotten if we've moved the f
On Thu, Apr 01, 2021 at 12:17:44PM -0700, Roy Yang wrote:
> Both Android and Chrome OS really want this feature; For Container-Optimized
> OS, we have customers
> interested in the defense too.
>
> Thank you very much.
>
> Change-Id: I1eb1b726007aa8f9c374b934cc1c690fb4924aa3
You forgot
handling into
> the unlazy helpers themselves.
>
> Al, does that sound plausible?
mnt_add_count() on _what_? Failure in legitimize_links() ends up with
nd->path.mnt zeroed, in both callers. So which vfsmount would be
affected?
Rules:
in RCU mode: no mounts pinned
out of
On Tue, Mar 30, 2021 at 10:09:29PM +0100, Matthew Wilcox wrote:
> That's a very Intel-centric way of looking at it. Other architectures
> support a multitude of page sizes, from the insane ia64 (4k, 8k, 16k, then
> every power of four up to 4GB) to more reasonable options like (4k, 32k,
> 256k, 2
On Wed, Mar 31, 2021 at 07:16:45PM -0700, Manish Varma wrote:
> timerfd doesn't create any wakelocks, but eventpoll can. When it does,
> it names them after the underlying file descriptor, and since all
> timerfd file descriptors are named "[timerfd]" (which saves memory on
> systems like desktops
e'
> > ./fs/namespace.c:1379: warning: Excess function parameter 'mnt' description
> > in 'may_umount_tree'
> > ./fs/namespace.c:1950: warning: Function parameter or member 'path' not
> > described in 'clone_private_mount'
>
On Wed, Mar 31, 2021 at 07:33:50PM +0200, Mickaël Salaün wrote:
> > +static inline u64 unmask_layers(
> > + const struct landlock_ruleset *const domain,
> > + const struct path *const path, const u32 access_request,
> > + u64 layer_mask)
> > +{
> > + const struct la
x27;d be nice
> if there were some way to make future openat() calls be unable to
> resolve outside the chroot, but I view that as an enhancement.
>
> But, as it stands, I think this makes sense and I stand by my
> Reviewed-by tag. If Al is too busy to take it, and James would rather
On Tue, Mar 30, 2021 at 06:31:00PM +, Al Viro wrote:
> On Tue, Mar 30, 2021 at 06:17:15PM +0200, Christoph Hellwig wrote:
> > On Wed, Mar 31, 2021 at 12:15:37AM +1030, Joel Stanley wrote:
> > > overlayfs using jffs2 as the upper filesystem would fail in some cases
> >
On Tue, Mar 30, 2021 at 06:17:15PM +0200, Christoph Hellwig wrote:
> On Wed, Mar 31, 2021 at 12:15:37AM +1030, Joel Stanley wrote:
> > overlayfs using jffs2 as the upper filesystem would fail in some cases
> > since moving to v5.10. The test case used was to run 'touch' on a file
> > that exists in
On Thu, Mar 25, 2021 at 08:37:40PM +0100, Miklos Szeredi wrote:
> Add stacking for the fileattr operations.
>
> Add hack for calling security_file_ioctl() for now. Probably better to
> have a pair of specific hooks for these operations.
Umm... Shouldn't you remove the old code from their ->ioct
On Thu, Mar 25, 2021 at 08:37:38PM +0100, Miklos Szeredi wrote:
> +int vfs_fileattr_get(struct dentry *dentry, struct fileattr *fa)
> +{
> + struct inode *inode = d_inode(dentry);
> +
> + if (d_is_special(dentry))
> + return -ENOTTY;
FWIW - why? For uses via ioctl() you simpl
On Sun, Mar 28, 2021 at 11:43:54AM -0300, André Almeida wrote:
> +/**
> + * d_clear_dir_neg_dentries - Remove negative dentries in an inode
> + * @dir: Directory to clear negative dentries
> + *
> + * For directories with negative dentries that are becoming case-insensitive
> + * dirs, we need to
On Fri, Mar 26, 2021 at 02:50:11PM +0100, Christian Brauner wrote:
> @@ -632,6 +632,7 @@ EXPORT_SYMBOL(close_fd); /* for ksys_close() */
> static inline void __range_cloexec(struct files_struct *cur_fds,
> unsigned int fd, unsigned int max_fd)
> {
> + unsigned
On Fri, Mar 26, 2021 at 11:33:58AM +0100, Peter Zijlstra wrote:
> +again:
> + rcu_read_lock();
> + str = rcu_dereference(*(char **)file->private_data);
> + len = strlen(str) + 1;
> +
> + if (!copy || copy_len < len) {
> + rcu_read_unlock();
> + kfree(copy);
On Fri, Mar 26, 2021 at 07:03:47PM +0200, Andy Shevchenko wrote:
> The bitmap.h header is used in a lot of code around the kernel.
> Besides that it includes kernel.h which sometimes makes a loop.
How much of the kernel does *not* end up pulling kernel.h anyway,
making all subsequent includes fast
1 - 100 of 4197 matches
Mail list logo
