Re: [PATCH v3 00/47] filelock: split file leases out of struct file_lock

ow since this set is a bit different from the last. > > I'd like to get this into linux-next soon and we can see about merging > it for v6.9, unless anyone has major objections. For all patches: Reviewed-by: NeilBrown Thanks Jeff - I think this is a good and useful change and while it

Re: [PATCH v3 34/47] 9p: adapt to breakup of struct file_lock

ilp, fl); > > - if ((IS_SETLK(cmd) || IS_SETLKW(cmd)) && fl->fl_type != F_UNLCK) { > + if ((IS_SETLK(cmd) || IS_SETLKW(cmd)) && fl->c.flc_type != F_UNLCK) { Should this have already been changed to lock_is_unlock() ??? NeilBrown > filemap_write_and_wait(

Re: [PATCH v2 00/41] filelock: split struct file_lock into file_lock and file_lease structs

those are probably a good idea, through don't really help much with reducing the need for accessor functions. I don't suppose we could just leave the #defines in place? Probably not a good idea. Maybe spell "fl_core" as "c"? lk->c.flc_flags ??? And I wonder if we could have a new fl_flag for 'FOREIGN' locks rather than encoding that flag in the sign of the pid. That seems a bit ... clunky? NeilBrown

Re: [PATCH 00/20] filelock: split struct file_lock into file_lock and file_lease structs

sn't address that, and I'm new > enough at this that I don't have that context. For me, the big win was in the last patch where we got separate lock_manager_operations and lease_manager_operations. There is zero overlap between the two. This highlights that one one level these are different things with different behaviours. NeilBrown

Re: [PATCH 20/20] filelock: split leases out of struct file_lock

ock" and "lease" both start with 'l' as we now have two quite different fields in different structures with the same name - fl_lmops. NeilBrown

Re: [PATCH 13/20] filelock: convert __locks_insert_block, conflict and deadlock checks to use file_lock_core

can't reasonably detect deadlocks with >* FL_OFDLCK locks, since they aren't owned by a process, per-se. >*/ > - if (IS_OFDLCK(flc)) > + if (IS_OFDLCK(caller)) > return 0; return false; Thanks, NeilBrown

Re: [PATCH 12/20] filelock: make __locks_delete_block and __locks_wake_up_blocks take file_lock_core

_member); > + fl = file_lock(waiter); fl = list_first_entry(>fl_core.fl_blocked_requests, struct file_lock, fl_core.fl_blocked_member); waiter = >fl_core; achieves the same result without needing file_lock(). If you

Re: [PATCH 11/20] filelock: convert the IS_* macros to take file_lock_core

it would me, I would simply discard these macros and open-code the tests. I don't think IS_FLOCK() is easier to read for someone who knows the code, and I think IS_LEASE() is actually harder to read for someone who doesn't know the code, as that it does it not really obvious. But this is just

Re: [PATCH 01/20] filelock: split common fields into struct file_lock_core

you prefer your approach, please leave it that way. The only clear benefit of my approach is that you don't need to squash patches together, and that is probably not a big deal. Thanks, NeilBrown

Re: [PATCH v2 12/12] docs: path-lookup: update symlink description

`` so that ``trailing_symlink()`` gets called and the > + like for a non-creating open: ``lookup_last()`` or ``open_last_lookup()`` > + returns a non ``Null`` value, and ``link_path_walk()`` gets called and the "NULL", not "Null". This those changes, Reviewed-

Re: [PATCH v2 11/12] docs: path-lookup: update get_link() ->follow_link description

ace to point to that target. ``->get_link()`` then > +returns ``0``. Again there is no final component and ``pick_link()`` Why did you change NULL to 0? ->get_link returns a pointer. Without that change: Reviewed-by: NeilBrown Thanks, NeilBrown > +returns NULL. > > Following the symlink in the final component > > -- > 2.30.2 signature.asc Description: PGP signature

Re: [PATCH v2 10/12] docs: path-lookup: update WALK_GET, WALK_PUT desc

ch tells whether to release the current symlink after it > has > +been followed. ``WALK_MORE`` is tested first, leading to a call to > +``put_link()``. I don't think that "tested first" sentence is relevant any more. Thanks, NeilBrown > > Symlinks with no final component > > -- > 2.30.2 signature.asc Description: PGP signature

Re: [PATCH v2 09/12] docs: path-lookup: no get_link()

urning new path ``name``. "which returns the link from the filesystem." With those changes (assuming you agree with them) Reviewed-by: NeilBrown Thanks, NeilBrown > +Providing that operation is successful, the old path ``name`` is placed on > the > +stack, and the new value

Re: [PATCH v2 08/12] docs: path-lookup: update i_op->put_link and cookie description

> +``struct delayed_called`` will be passed to get_link, I'd put a ":", not "," at the end of above line. > +file systems can set their own put_link function and argument through > +``set_delayed_call``. Later on, when vfs wants to put link, it will call () after funct

Re: [PATCH v2 07/12] docs: path-lookup: i_op->follow_link replaced with i_op->get_link

On Tue, Mar 16 2021, Fox Chen wrote: > follow_link has been replaced by get_link() which can be > called in RCU mode. > > see commit: commit 6b2553918d8b ("replace ->follow_link() with > new method that could stay in RCU mode") > > Signed-off-by: Fox Chen

Re: [PATCH v2 06/12] docs: path-lookup: Add macro name to symlink limit description

On Tue, Mar 16 2021, Fox Chen wrote: > Add macro name MAXSYMLINKS to the symlink limit description, so > that it is consistent with path name length description above. > > Signed-off-by: Fox Chen Reviewed-by: NeilBrown Thanks, NeilBrown > --- > Documentation/filesystems/p

Re: [PATCH v2 05/12] docs: path-lookup: remove filename_mountpoint

hree: > > "These four correspond roughly to the three path_*() functions" > > Signed-off-by: Fox Chen Reviewed-by: NeilBrown Thanks, NeilBrown > --- > Documentation/filesystems/path-lookup.rst | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH v2 04/12] docs: path-lookup: update do_last() part

kup_last() through walk_component(). But saying that here might be duplicating earlier text. I think the key point in the para is that convention of returning a 'char *name' if a symlink was found. The rest might now be redundant. I think this needs a larger revision. Thanks, NeilBrown >

Re: [PATCH v2 03/12] docs: path-lookup: update path_mountpoint() part

skips that step. This is > -important when unmounting a filesystem that is inaccessible, such as > +It is worth noting that when flag ``LOOKUP_MOUNTPOINT`` is set, > +``path_lookupat()`` will unset LOOKUP_JUMPED in nameidata so that in the > further I would say "subsequent&q

Re: [PATCH v2 02/12] docs: path-lookup: update path_to_nameidata() part

lic link, step_into() calls pick_link() to deal with it, otherwise it installs the new struct path into the struct nameidata, and drops the unneeded references. With those changes, Reviewed-by: NeilBrown Thanks, NeilBrown > > This "hand-over-hand" sequencing of getting a reference to the new > dentry before dropping the reference to the previous dentry may > -- > 2.30.2 signature.asc Description: PGP signature

Re: [PATCH v2 01/12] docs: path-lookup: update follow_managed() part

``walk_component()`` creates a new > +As the last step of ``walk_component()``, ``step_into()`` will be called > either > +directly from walk_component() or from handle_dots(). It calls > +``handle_mount()``, to check and handle mount points, in which a new Typo - it is "handle_mounts",

Re: [PATCH v2 00/12] docs: path-lookup: Update pathlookup docs

uctant to > apply them without your ack... No I haven't, I'm sorry. And I'm on leave at the moment so my attention is mostly elsewhere. However I'll try to make time to have a look sometime in the next week or so. Thanks for the prompt. NeilBrown signature.asc Description: PGP signature

Re: [PATCH] drivers/block: Goodbye BLK_DEV_UMEM

On Tue, Mar 23 2021, Davidlohr Bueso wrote: > I'm also Ccing Neil, who is one of the authors. Thanks! I have no objection to the removal. The driver served its purpose at the time, but technology has moved on. Add Acked-by: NeilBrown if you like (not necessary). Thanks, NeilBr

Re: [PATCH v2] block: fix trace completion for chained bio

hain_endio() handling to the end, after all of that. So the function would end. if (bio->bi_end_io == bio_chain_endio) { bio = __bio_chain_endio(bio); goto again; } else if (bio->bi_end_io) bio->bi_end_io(bio); Jens: can you see any reason why that functions must only be cal

Re: [PATCH 0/3] Fix some seq_file users that were recently broken

On Fri, Feb 05 2021, Andrew Morton wrote: > On Fri, 05 Feb 2021 11:36:30 +1100 NeilBrown wrote: > >> A recent change to seq_file broke some users which were using seq_file >> in a non-"standard" way ... though the "standard" isn't documented, so >> th

[PATCH 0/3] Fix some seq_file users that were recently broken

se three patches: 1/ document and explain the problem 2/ fix the problem user in x86 3/ fix the problem user in net/sctp I suspect the patches should each go through the relevant subsystems, but I'm including akpm as the original went through him. Thanks, NeilBrown --- NeilBrown (3): seq_fi

[PATCH 3/3] net: fix iteration for sctp transport seq_files

fs/seq_file.c: simplify seq_file iteration code and interface") Reported-by: Xin Long Signed-off-by: NeilBrown --- net/sctp/proc.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/net/sctp/proc.c b/net/sctp/proc.c index f7da88ae20a5..982a87b3e11f 100

[PATCH 2/3] x86: fix seq_file iteration for pat/memtype.c

and interface") Cc: Xin Long Signed-off-by: NeilBrown --- arch/x86/mm/pat/memtype.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c index 8f665c352bf0..ca311aaa67b8 100644 --- a/arch/x86/mm/pat/memtype.c +++ b

[PATCH 1/3] seq_file: document how per-entry resources are managed.

arly state the required behaviour. Other patches will fix the few problematic users. Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Cc: Xin Long Signed-off-by: NeilBrown --- Documentation/filesystems/seq_file.rst |6 ++ 1 file chang

Re: [PATCH] list: add more extensive double add check

n point. This patch just extends it somewhat. I myself have never had, or heard of, a bug due to double insertion so I'm no strongly in favour of this patch for that reason. But I *am* in favour of making the platform more resilient in general, and if others have experienced this sort of bug,

Re: [PATCH 00/12] docs: path-lookup: Update pathlookup docs

art of why I haven't put much effort into the document - re-telling a story can be a lot of work. NeilBrown signature.asc Description: PGP signature

Re: [PATCH 07/12] docs: path-lookup: i_op->follow_link replaced with i_op->get_link

rest of the text. It talks about "dropping down to REF-walk", so you could write "dropping out of RCU-walk", but not just "dropping RCU-walk". NeilBrown > +looked at previously, ``->get_link()`` would need to be careful that > all the data structures it references

Re: [PATCH 04/12] docs: path-lookup: update do_last() part

perly and the loop repeats, calling This implies that do_open() is inside the loop (in path_openat()). But it isn't, it comes after the loop. (I haven't closely examined this rest of this patch). NeilBrown > +``link_path_walk()`` again. This could loop as many as 40 times if the last > +comp

Re: [PATCH 08/12] docs: path-lookup: update i_op->put_link and cookie description

es sense any more. I think it was meant to introduce the final part of the "significant complexity", but now that significant complexity is gone. At least, I assume it is gone. I haven't checked to code to see if maybe it has just been moved. NeilBrown > +``do_delayed_call`` to in

Re: [PATCH 03/12] docs: path-lookup: update path_mountpoint() part

ing/able to spend on the task. IF you do stick with this approach: it is "path_lookupat", not "path_lookup_at". NeilBrown > > Finally ``path_openat()`` is used for the ``open()`` system call; it > contains, in support functions starting with "``do_last()``", all the > -- > 2.30.0 signature.asc Description: PGP signature

Re: [PATCH 02/12] docs: path-lookup: update path_to_nameidata() parth

ription any more correct. Possibly you need to change the hero of the story from walk_component() to step_into(), but that is just a guess. NeilBrown > > This "hand-over-hand" sequencing of getting a reference to the new > -- > 2.30.0 signature.asc Description: PGP signature

Re: [PATCH 01/12] docs: path-lookup: update follow_managed() part

he VFS has a concept of "managed" dentries which is reflected in function names like "traverse_mounts()" makes no sense at all. Again, I cannot offer any quick fix. NeilBrown > potentially interesting things about these dentries corresponding > to three different flags that might be set in ``dentry->d_flags``: > > -- > 2.30.0 signature.asc Description: PGP signature

Re: [PATCH 1/3] vfs: Do not ignore return code from s_op->sync_fs

dev(sb->s_bdev, wait); > + ret = sb->s_op->sync_fs(sb, wait); > + ret2 = __sync_blockdev(sb->s_bdev, wait); > + > + return ret ? ret : ret2; I'm surprised that the compiler didn't complain that 'ret' might be used uninitialized. NeilBrown > } > > /* > -- > 2.25.4 signature.asc Description: PGP signature

Re: [PATCH 3/3] overlayfs: Check writeback errors w.r.t upper in ->syncfs()

ould be "return_error" - or whatever is appropriate. NeilBrown signature.asc Description: PGP signature

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

On Thu, Nov 26 2020, Hillf Danton wrote: > On Fri, 20 Nov 2020 15:33:27 +1100 NeilBrown wrote: >> >>My first idea was to add WQ_CPU_INTENSIVE to the nfsiod workqueue, but >>Trond wondered what was special about NFS. Many filesystems call iput >>from a workqueue, so fi

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

On Wed, Nov 25 2020, t...@kernel.org wrote: > Hello, > > On Fri, Nov 20, 2020 at 10:23:44AM +1100, NeilBrown wrote: >> On Mon, Nov 09 2020, t...@kernel.org wrote: >> >> >Given that nothing on >> > t

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

On Fri, Nov 20 2020, Hillf Danton wrote: > On Fri, 20 Nov 2020 10:07:56 +1100 NeilBrown wrote: >>On Wed, Nov 18 2020, Hillf Danton wrote: >>> On Wed, 18 Nov 2020 16:11:44 +1100 NeilBrown wrote: >>>> On Wed, Nov 18 2020, Hillf Danton wrote: >>>>

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

t handling write-completion in a CM-wq is a poor choice? Would it be better to us WQ_HIGHPRI?? Is there any rule-of-thumb that can be used to determine when WQ_HIGHPRI is appropriate? Thanks, NeilBrown signature.asc Description: PGP signature

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

On Wed, Nov 18 2020, Hillf Danton wrote: > On Wed, 18 Nov 2020 16:11:44 +1100 NeilBrown wrote: >> On Wed, Nov 18 2020, Hillf Danton wrote: >> ... >> I don't think this is a good idea. > > Let me add a few more words. > >> cond_resched() is expected to be

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

On Wed, Nov 18 2020, Hillf Danton wrote: > On Wed, 18 Nov 2020 09:16:09 +1100 >> From: NeilBrown >> Date: Mon, 9 Nov 2020 13:37:17 +1100 > > What is the brand of your wall clock? The gap between the Date tag > above and 18 Nov is longer than a week. I guess 'git commit

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

t be as easy to code, and I'm not at all sure of the benefit. So: I propose the patch below. Thoughts? Thanks, NeilBrown From: NeilBrown Date: Mon, 9 Nov 2020 13:37:17 +1100 Subject: [PATCH] workqueue: warn when cond_resched called from concurrency-managed worker Several workers in conc

Re: [PATCH] NFS: only invalidate dentrys that are clearly invalid.

On Mon, Nov 16 2020, Trond Myklebust wrote: > On Mon, 2020-11-16 at 16:12 +1100, NeilBrown wrote: >> On Mon, Nov 16 2020, Trond Myklebust wrote: >> >> > On Mon, 2020-11-16 at 16:00 +1100, NeilBrown wrote: >> > > On Mon, Nov 16 2020, Trond Myklebust wrote:

Re: [PATCH] NFS: only invalidate dentrys that are clearly invalid.

On Mon, Nov 16 2020, Trond Myklebust wrote: > On Mon, 2020-11-16 at 16:00 +1100, NeilBrown wrote: >> On Mon, Nov 16 2020, Trond Myklebust wrote: >> >> > On Mon, 2020-11-16 at 15:43 +1100, NeilBrown wrote: >> > > On Mon, Nov 16 2020, Trond Myklebust wrote:

Re: [PATCH] NFS: only invalidate dentrys that are clearly invalid.

On Mon, Nov 16 2020, Trond Myklebust wrote: > On Mon, 2020-11-16 at 15:43 +1100, NeilBrown wrote: >> On Mon, Nov 16 2020, Trond Myklebust wrote: >> >> > On Mon, 2020-11-16 at 13:59 +1100, NeilBrown wrote: >> > > >> > > Prior to commit 5ceb9d7fd

Re: [PATCH] NFS: only invalidate dentrys that are clearly invalid.

On Mon, Nov 16 2020, Trond Myklebust wrote: > On Mon, 2020-11-16 at 13:59 +1100, NeilBrown wrote: >> >> Prior to commit 5ceb9d7fdaaf ("NFS: Refactor >> nfs_lookup_revalidate()") >> and error from nfs_lookup_verify_inode() other than -ESTALE would >> res

[PATCH] NFS: only invalidate dentrys that are clearly invalid.

t;NFS: Refactor nfs_lookup_revalidate()") Signed-off-by: NeilBrown --- fs/nfs/dir.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index cb52db9a0cfb..d24acf556e9e 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1350,7 +1350,7 @@ nfs_

Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.

o cpu-intensive??? I wonder how long workers typically run - do many run long enough that the scheduler might want to ask them to take a break? Thanks, NeilBrown signature.asc Description: PGP signature

[PATCH rfc] workqueue: honour cond_resched() more effectively.

sive tasks need to call cond_resched(). This would allow other workers to be scheduled. The following patch achieves this I believe. Signed-off-by: NeilBrown --- include/linux/sched.h | 7 ++- include/linux/workqueue.h | 2 ++ kernel/sched/core.c | 4 kernel/workqueue.c

[PATCH] workqueue: export apply_workqueue_attrs()

when it isn't exported, but that loop-hole has now been removed. So: time to export the function again. Signed-off-by: NeilBrown --- kernel/workqueue.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 437935e7a199..ab593b20fb94 100644 --- a/kern

Re: [mm/writeback] 8d92890bd6: will-it-scale.per_process_ops -15.3% regression

something to a different cache line and change some contention? That would be easy enough to test: just re-add NR_UNSTABLE_NFS. I have no experience reading will-it-scale results, but 15% does seem like a lot. NeilBrown signature.asc Description: PGP signature

Re: [PATCH] fsync.2: ERRORS: add EIO and ENOSPC

onal ones almost certainly will... Maybe. I think it is a useful distinction, but to be consistent it would be best to make it in all (section 2) man pages. Maybe not all at once though. It is really up to Michael if that is a direction he is interesting in following. NeilBrown > > -- > Jeff Layton signature.asc Description: PGP signature

Re: [PATCH] fsync.2: ERRORS: add EIO and ENOSPC

for some errors, but the > vast majority just toss out the data whenever there is a writeback > problem. ...and any filesystem that doesn't behave that way is wasting effort, because nothing else can be assumed. Regarding your "NOTES" addition, I don't feel comfortable with the "clean" language. I would prefer something like: When fsync() reports a failure (EIO, ENOSPC, EDQUOT) it must be assumed that any write requests initiated since the previous successful fsync was initiated may have failed, and that any cached data may have been lost. A future fsync() will not attempt to write out the same data again. If recovery is possible and desired, the application must repeat all the writes that may have failed. If the regions of a file that were written to prior to a failed fsync() are read, the content reported may not reflect the stored content, and subsequent reads may revert to the stored content at any time. NeilBrown > > > -- > Jeff Layton signature.asc Description: PGP signature

Re: [PATCH] fsync.2: ERRORS: add EIO and ENOSPC

I would say there *is* something special about those errors, though it isn't *very* special, and it isn't *just* those errors. EDQUOT should be included in the list. NeilBrown > All errors are the same in this regard. Basically, issuing a new fsync > after a failed one doesn't do any good. Y

Re: Minor RST rant

ays supposed it to be my own fault--because I will not take the trouble of practising." :-) NeilBrown > >> to remove excessive markup where it's gone too far [1]. >> >> You can see how this renders in html at >> https://www.kernel.org/doc/html/latest/filesyst

Re: Minor RST rant

In kernel-doc comments they are preceded by a '%'. Would that make the text more readable for you? Does our doc infrastructure honour that in .rst documents? Thanks, NeilBrown signature.asc Description: PGP signature

Re: [PATCH 09/23] md: rewrite md_setup_drive to avoid ioctls

name); > return; > } > - if (ksys_ioctl(fd, SET_ARRAY_INFO, 0) == -EBUSY) { > - printk(KERN_WARNING > -"md: Ignoring md=%d, already autodetected. (Use > raid=noautodetect)\n", > -

Re: [PATCH 08/23] md: simplify md_setup_drive

On Tue, Jul 14 2020, Christoph Hellwig wrote: > Move the loop over the possible arrays into the caller to remove a level > of indentation for the whole function. > > Signed-off-by: Christoph Hellwig > Acked-by: Song Liu Nice Reviewed-by: NeilBrown Thanks, NeilBrown > --

Re: [PATCH 06/23] md: remove the autoscan partition re-read

On Tue, Jul 14 2020, Christoph Hellwig wrote: > devfs is long gone, and autoscan works just fine without this these days. > > Signed-off-by: Christoph Hellwig > Acked-by: Song Liu Happy to see this go! Reviewed-by: NeilBrown Thanks, NeilBrown > --- > drivers/md/md

Re: [PATCH 05/23] md: replace the RAID_AUTORUN ioctl with a direct function call

his ioctl from user-space, but I cannot find a copy of that online, so I cannot be sure not that it really matters. Reviewed-by: NeilBrown Thanks, NeilBrown > > Signed-off-by: Christoph Hellwig > Acked-by: Song Liu > --- > drivers/md/md-autodetect.c | 10 ++ > driv

Re: [PATCH 03/23] init: remove the bstat helper

On Tue, Jul 14 2020, Christoph Hellwig wrote: > The only caller of the bstat function becomes cleaner and simpler when > open coding the function. > > Signed-off-by: Christoph Hellwig > Acked-by: Song Liu Reviewed-by: NeilBrown Nice! NeilBrown > --- > ini

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

doesn't mean anything, in that you can use it to refer to any thing. (i.e. it is almost semantically equivalent to "thing"). Look in /sys/devices. Everything in there is a device, and (nearly) every thing is in there. NeilBrown > > On Sat., Jul. 4, 2020, 16:19 Dan Williams, w

Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology

doesn't mean anything, in that you can use it to refer to any thing. (i.e. it is almost semantically equivalent to "thing"). Look in /sys/devices. Everything in there is a device, and (nearly) every thing is in there. NeilBrown > > On Sat., Jul. 4, 2020, 16:19 Dan Williams, w

[PATCH 2/2] MM: Discard NR_UNSTABLE_NFS, use NR_WRITEBACK instead.

istics virtual-files, the entry is retained, but the value is hard-coded as zero. static trace points and warning printks which mentioned this counter no longer report it. Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Acked-by: Trond Myklebust Acked-by: Michal Hocko # for MM parts S

[PATCH 1/2] MM: replace PF_LESS_THROTTLE with PF_LOCAL_THROTTLE

now different from the behaviour of nfsd and loop tasks. I don't know what is wanted for realtime. Reviewed-by: Jan Kara Acked-by: Chuck Lever (for nfsd change) Signed-off-by: NeilBrown --- drivers/block/loop.c | 2 +- fs/nfsd/vfs.c | 9 + include/linux/sched.h | 3 ++-

Writeback fixes for NFS

Hi Andrew, could you please queue these two patches (following). I think they have sufficient review and no remaining complaints. Thanks, NeilBrown signature.asc Description: PGP signature

[PATCH 2/2 V4] MM: Discard NR_UNSTABLE_NFS, use NR_WRITEBACK instead.

istics virtual-files, the entry is retained, but the value is hard-coded as zero. static trace points and warning printks which mentioned this counter no longer report it. Reviewed-by: Christoph Hellwig Acked-by: Trond Myklebust Acked-by: Michal Hocko # for MM parts Signed-off-by: NeilBrown -

[PATCH 1/2 V4] MM: replace PF_LESS_THROTTLE with PF_LOCAL_THROTTLE

now different from the behaviour of nfsd and loop tasks. I don't know what is wanted for realtime. Acked-by: Chuck Lever (for nfsd change) Signed-off-by: NeilBrown --- drivers/block/loop.c | 2 +- fs/nfsd/vfs.c | 9 + include/linux/sched.h | 3 ++- kernel/sys.c

Re: [PATCH 1/2 V3] MM: replace PF_LESS_THROTTLE with PF_LOCAL_THROTTLE

Thoughts? Patches follow - I've address the comment formatting issue. Thanks, NeilBrown signature.asc Description: PGP signature

Re: [PATCH 0/5] cachefiles, nfs: Fixes

her for your consideration. NeilBrown From: NeilBrown Date: Tue, 12 May 2020 08:32:25 +1000 Subject: [PATCH] cachefiles: fix inverted ASSERTion. bmap() returns a negative result precisely when a_ops->bmap is NULL. A recent patch converted ASSERT(inode->i_mapping->a_ops->bmap); t

[PATCH] SUNRPC: fix use-after-free in rpc_free_client_work()

dir(). Reported-by: syzbot+22b5ef302c7c40d94...@syzkaller.appspotmail.com Fixes: 7c4310ff5642 ("SUNRPC: defer slow parts of rpc_free_client() to a workqueue.") Signed-off-by: NeilBrown --- net/sunrpc/clnt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sunrpc

Re: [PATCH AUTOSEL 5.4 26/35] SUNRPC: defer slow parts of rpc_free_client() to a workqueue.

On Thu, May 07 2020, Sasha Levin wrote: > From: NeilBrown > > [ Upstream commit 7c4310ff56422ea43418305d22bbc5fe19150ec4 ] This one is buggy - it introduces a use-after-free. Best delay it for now. NeilBrown > > The rpciod workqueue is on the write-out path for freeing dir

Re: [PATCH] sunrpc: fix crash when cache_head become valid before update

give Neil a chance to look it > over if he wants. Yes, it makes sense to me. But I'm not sure that is worth much. The original fix got a Reviewed-by from me but was wrong. Acked-by: NeilBrown 'Acked' is weaker than 'reviewed' - isn't it? :-) NeilBrown signature.asc Description: PGP signature

Re: Bisected: Kernel 4.14 + has 3 times higher write IO latency than Kernel 4.4 with raid1

On Fri, Aug 16 2019, Jinpu Wang wrote: > On Wed, Aug 7, 2019 at 2:35 PM Jinpu Wang wrote: >> >> On Wed, Aug 7, 2019 at 8:36 AM Jinpu Wang wrote: >> > >> > On Wed, Aug 7, 2019 at 1:40 AM NeilBrown wrote: >> > > >> > > On Tue, Aug 06 20

Re: Bisected: Kernel 4.14 + has 3 times higher write IO latency than Kernel 4.4 with raid1

On Tue, Aug 06 2019, Jinpu Wang wrote: > On Tue, Aug 6, 2019 at 9:54 AM Jinpu Wang wrote: >> >> On Tue, Aug 6, 2019 at 1:46 AM NeilBrown wrote: >> > >> > On Mon, Aug 05 2019, Jinpu Wang wrote: >> > >> > > Hi Neil, >> >

Re: Bisected: Kernel 4.14 + has 3 times higher write IO latency than Kernel 4.4 with raid1

)) return; should normally return when doing lots of IO - I'd like to know which condition causes it to not return. Thanks, NeilBrown signature.asc Description: PGP signature

Re: seq_file: fix problem when seeking mid-record.

y seen "Possible unwrapped commit description (prefer a maximum 75 chars per line)\n" warnings from checkpatch, but one closer look that doesn't apply to Fixes: lines (among other special cases). Maybe Andrew will fix it up for me when it applies (please!) Thanks, NeilBrown signature.asc Description: PGP signature

[PATCH] seq_file: fix problem when seeking mid-record.

terface") Cc: sta...@vger.kernel.org (v4.19+) Signed-off-by: NeilBrown --- Hi Andrew: as you applied the offending patch for me, maybe you could queue up this fix too. Thanks, NeilBrown fs/seq_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/seq_file.c

Re: [BUG] lseek on /proc/meminfo is broken in 4.19.59 maybe due to commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")

. I think it is correct, but I need to look it over more carefully in the morning, and see if I can explain why it is correct. Thanks for the report. NeilBrown diff --git a/fs/seq_file.c b/fs/seq_file.c index 04f09689cd6d..1600034a929b 100644 --- a/fs/seq_file.c +++ b/fs/seq_file.c @@ -119,6 +119,

[PATCH 1/2] staging: mt7621-dts: update sdhci config.

The mtk-sd driver has been updated to support the IP in the mt7621, so update our configuration to work with it. Signed-off-by: NeilBrown --- drivers/staging/mt7621-dts/mt7621.dtsi | 41 +++- 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/drivers

[PATCH 0/2] staging: update mt7621 dts for some recent driver changes

to work with mt7621 hardware and the mt7621-eth driver was removed from staging. The second patch enhances the mt7621.dtsi to better support this driver and particularly to allow the second network port to be used in at least one of its possible configurations. Thanks, NeilBrown --- NeilBrown (2

[PATCH 2/2] staging: mt7621-dts: add support for second network interface

interface to mt7621.dtsi and add a gbpc2.dts which makes use of this. This allows the second interface to be used. I don't fully understand how to configure this interface - the documentation is thin - so there could well be room for improvement here. Signed-off-by: NeilBrown --- drivers/staging

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Fri, May 03 2019, J. Bruce Fields wrote: > On Thu, May 02, 2019 at 12:02:33PM +1000, NeilBrown wrote: >> On Tue, Dec 06 2016, J. Bruce Fields wrote: >> >> > On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: >> >> On Tue, Dec 6, 201

[PATCH 3/4] mmc: mtk-sd: enable internal card-detect logic.

n't marked non-removable and doesn't have a cd-gpio configured, and if use_internal_cd is set, then assume the internal cd logic should be used as recommended by Documentation/devicetree/bindings/mmc/mmc.txt Signed-off-by: NeilBrown --- drivers/mmc/host/mtk-s

[PATCH 1/4] mmc: mtk-sd: don't hard-code interrupt trigger type

. Also IRQF_ONESHOT is not needed - it is used for threaded interrupt handlers, and this driver does not used a threaded interrupt handler. So remove that setting. Signed-off-by: NeilBrown --- drivers/mmc/host/mtk-sd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers

[PATCH 2/4] mmc: mtk-sd: add support for config found in mt7620 family SOCs.

mt7620 family MIPS SOCs contain the mtk-sd silicon. Add support for this. Signed-off-by: NeilBrown --- Documentation/devicetree/bindings/mmc/mtk-sd.txt |1 + drivers/mmc/host/mtk-sd.c| 12 2 files changed, 13 insertions(+) diff --git a/Documentation

[PATCH 0/4] mtk-sd enhancement to support MT7621 - V2

The MT7621 MIPS-based SOC contains an sdhci unit that is much the same as the units supported by mtk-sd.c. These patches enhance the driver so that I can use it on my MT7621 board (gnubee.org). This series have been revised based on feedback from Chaotian. Thanks, NeilBrown --- NeilBrown (4

[PATCH 4/4] mmc: mtk-sd: select REGULATOR

The mtk-sd driver requires a regulator to be present, even if it is the "fixed" regulator. So select REGULATOR to make it hard to build unusable configurations. Signed-off-by: NeilBrown --- drivers/mmc/host/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/ho

Re: [PATCH 4/5] mmc: mtk-sd: enable internal card-detect logic.

On Thu, Apr 18 2019, Chaotian Jing wrote: > On Tue, 2019-04-16 at 14:47 +1000, NeilBrown wrote: >> The mtk-sd silicon has integrated card-detect logic that is >> enabled, at least, on the MT7621 as used in the GNUBEE NAS. >> >> If the sdhci isn't marked non-removab

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Thu, May 02 2019, Andreas Gruenbacher wrote: > On Thu, 2 May 2019 at 05:57, NeilBrown wrote: >> On Wed, May 01 2019, Amir Goldstein wrote: >> > On Wed, May 1, 2019 at 10:03 PM NeilBrown wrote: >> >> On Tue, Dec 06 2016, J. Bruce Fields wrote: >> >>

Re: [PATCH] OVL: add honoracl=off mount option.

On Thu, May 02 2019, Amir Goldstein wrote: > On Thu, May 2, 2019 at 12:35 AM NeilBrown wrote: >> >> >> If the upper and lower layers use incompatible ACL formats, it is not >> possible to copy the ACL xttr from one to the other, so overlayfs >> cannot work with t

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Thu, May 02 2019, Miklos Szeredi wrote: > On Thu, May 2, 2019 at 10:05 AM Andreas Gruenbacher > wrote: >> >> On Thu, 2 May 2019 at 05:57, NeilBrown wrote: >> > On Wed, May 01 2019, Amir Goldstein wrote: >> > > On Wed, May 1, 2019 at 10:03 PM NeilBrown

[PATCH] OVL: add honoracl=off mount option.

. Signed-off-by: NeilBrown --- Documentation/filesystems/overlayfs.txt | 24 fs/overlayfs/copy_up.c | 9 +++-- fs/overlayfs/dir.c | 2 +- fs/overlayfs/overlayfs.h| 2 +- fs/overlayfs/ovl_entry.h

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

On Wed, May 01 2019, Amir Goldstein wrote: > On Wed, May 1, 2019 at 10:03 PM NeilBrown wrote: >> >> On Tue, Dec 06 2016, J. Bruce Fields wrote: >> >> > On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: >> >> On Tue, Dec

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

ended attributes with the "system." prefix. These are used for storing ACL information and this is sometimes not compatible between different filesystem types (e.g. ext4 and NFSv4). Standard Unix ownership permission flags (rwx) *are* copied so this option does not risk giving away inappropriate permissions unless the lowerfs uses unusual ACLs. Miklos: would you find that acceptable? Thanks, NeilBrown signature.asc Description: PGP signature

Re: [PATCH] md: properly lock and unlock in rdev_attr_store()

NULL which would cause problems. This could be fixed by changing struct mddev *mddev = rdev->mddev; to struct mddev *mddev = READ_ONCE(rdev->mddev); That is the only change that might be useful here. NeilBrown > > drivers/md/md.c | 4 +++- > 1 file changed, 3 insertions(+), 1

  1   2   3   4   5   6   7   8   9   10   >