hat a lot of the other nfsctl
methods do.
--b.
commit ad5fdf47b4e3
Author: J. Bruce Fields
Date: Tue Nov 27 15:54:17 2018 -0500
nfsd4: fix crash on writing v4_end_grace before nfsd startup
Anatoly Trosinenko reports that this:
1) Checkout fresh master Linux branch (tested wi
Thanks for the report!
On Tue, Nov 27, 2018 at 02:01:02PM +0800, kernel test robot wrote:
> FYI, we noticed a -62.5% regression of will-it-scale.per_thread_ops due to
> commit:
>
>
> commit: 83b381078b5ecab098ebf6bc9548bb32af1dbf31 ("fs/locks: always
> delete_block after waiting.")
>
Thanks for the report!
On Tue, Nov 27, 2018 at 02:01:02PM +0800, kernel test robot wrote:
> FYI, we noticed a -62.5% regression of will-it-scale.per_thread_ops due to
> commit:
>
>
> commit: 83b381078b5ecab098ebf6bc9548bb32af1dbf31 ("fs/locks: always
> delete_block after waiting.")
>
On Fri, Nov 23, 2018 at 03:56:33PM +0800, Pan Bian wrote:
> The function dentry_connected calls dput(dentry) to drop the previously
> acquired reference to dentry. In this case, dentry can be released.
> After that, IS_ROOT(dentry) checks the condition
> (dentry == dentry->d_parent), which may
On Fri, Nov 23, 2018 at 03:56:33PM +0800, Pan Bian wrote:
> The function dentry_connected calls dput(dentry) to drop the previously
> acquired reference to dentry. In this case, dentry can be released.
> After that, IS_ROOT(dentry) checks the condition
> (dentry == dentry->d_parent), which may
On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
> Thanks for the explanation, Dmitry. I've added the tag to the patch in
> my tree. It should show up in linux-next soon.
>
> I still find it a little misleading to say that syzbot reported a bug
> when it actually found a bug inside an
On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
> Thanks for the explanation, Dmitry. I've added the tag to the patch in
> my tree. It should show up in linux-next soon.
>
> I still find it a little misleading to say that syzbot reported a bug
> when it actually found a bug inside an
Please pull:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20-1
Three nfsd bugfixes. None are new bugs, but they all take a little
effort to hit, which might explain why they weren't found sooner.
--b.
Frank Sorenson (1):
sunrpc: correct the computation for page_ptr when
Please pull:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20-1
Three nfsd bugfixes. None are new bugs, but they all take a little
effort to hit, which might explain why they weren't found sooner.
--b.
Frank Sorenson (1):
sunrpc: correct the computation for page_ptr when
ACK to the series.
It also passed my usual regression tests on top of 4.19. (I still have
some unrelated problems to sort out on 4.20.)
--b.
On Mon, Nov 12, 2018 at 12:14:48PM +1100, NeilBrown wrote:
> Changes:
> - field names improved as requested by Bruce.
>"fl_bl
ACK to the series.
It also passed my usual regression tests on top of 4.19. (I still have
some unrelated problems to sort out on 4.20.)
--b.
On Mon, Nov 12, 2018 at 12:14:48PM +1100, NeilBrown wrote:
> Changes:
> - field names improved as requested by Bruce.
>"fl_bl
On Mon, Nov 12, 2018 at 12:14:49PM +1100, NeilBrown wrote:
> When we find an existing lock which conflicts with a request,
> and the request wants to wait, we currently add the request
> to a list. When the lock is removed, the whole list is woken.
> This can cause the thundering-herd problem.
>
On Mon, Nov 12, 2018 at 12:14:49PM +1100, NeilBrown wrote:
> When we find an existing lock which conflicts with a request,
> and the request wants to wait, we currently add the request
> to a list. When the lock is removed, the whole list is woken.
> This can cause the thundering-herd problem.
>
On Mon, Nov 12, 2018 at 12:14:48PM +1100, NeilBrown wrote:
> struct file lock contains an 'fl_next' pointer which
> is used to point to the lock that this request is blocked
> waiting for. So rename it to fl_blocker.
>
> The fl_blocked list_head in an active lock is the head of a list of
>
On Mon, Nov 12, 2018 at 12:14:48PM +1100, NeilBrown wrote:
> struct file lock contains an 'fl_next' pointer which
> is used to point to the lock that this request is blocked
> waiting for. So rename it to fl_blocker.
>
> The fl_blocked list_head in an active lock is the head of a list of
>
On Fri, Nov 09, 2018 at 05:24:04PM +1100, NeilBrown wrote:
> Thanks pretty thorough - and even looks correct.
> I'll re-reading some time when it isn't late, and maybe make it into a
> comment in the code.
> I agree, this sort of documentation can be quite helpful.
OK. The idea looks sound to
On Fri, Nov 09, 2018 at 05:24:04PM +1100, NeilBrown wrote:
> Thanks pretty thorough - and even looks correct.
> I'll re-reading some time when it isn't late, and maybe make it into a
> comment in the code.
> I agree, this sort of documentation can be quite helpful.
OK. The idea looks sound to
On Fri, Nov 09, 2018 at 11:32:16AM +1100, NeilBrown wrote:
> On Thu, Nov 08 2018, J. Bruce Fields wrote:
>
> > On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
> >> struct file lock contains an 'fl_next' pointer which
> >> is used to point to the loc
On Fri, Nov 09, 2018 at 11:32:16AM +1100, NeilBrown wrote:
> On Thu, Nov 08 2018, J. Bruce Fields wrote:
>
> > On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
> >> struct file lock contains an 'fl_next' pointer which
> >> is used to point to the loc
On Fri, Nov 09, 2018 at 11:38:19AM +1100, NeilBrown wrote:
> On Thu, Nov 08 2018, J. Bruce Fields wrote:
>
> > On Mon, Nov 05, 2018 at 12:30:48PM +1100, NeilBrown wrote:
> >> When we find an existing lock which conflicts with a request,
> >> and the request w
On Fri, Nov 09, 2018 at 11:38:19AM +1100, NeilBrown wrote:
> On Thu, Nov 08 2018, J. Bruce Fields wrote:
>
> > On Mon, Nov 05, 2018 at 12:30:48PM +1100, NeilBrown wrote:
> >> When we find an existing lock which conflicts with a request,
> >> and the request w
On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
> Here is the respin on this series with the file_lock properly
> initlized for unlock requests.
> I found one that I had missed before - in locks_remove_flock()
> The change makes this code smaller!
>
> Original series description:
>
>
On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
> Here is the respin on this series with the file_lock properly
> initlized for unlock requests.
> I found one that I had missed before - in locks_remove_flock()
> The change makes this code smaller!
>
> Original series description:
>
>
On Mon, Nov 05, 2018 at 12:30:48PM +1100, NeilBrown wrote:
> When we find an existing lock which conflicts with a request,
> and the request wants to wait, we currently add the request
> to a list. When the lock is removed, the whole list is woken.
> This can cause the thundering-herd problem.
>
On Mon, Nov 05, 2018 at 12:30:48PM +1100, NeilBrown wrote:
> When we find an existing lock which conflicts with a request,
> and the request wants to wait, we currently add the request
> to a list. When the lock is removed, the whole list is woken.
> This can cause the thundering-herd problem.
>
On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
> struct file lock contains an 'fl_next' pointer which
> is used to point to the lock that this request is blocked
> waiting for. So rename it to fl_blocker.
>
> The fl_blocked list_head in an active lock is the head of a list of
>
On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
> struct file lock contains an 'fl_next' pointer which
> is used to point to the lock that this request is blocked
> waiting for. So rename it to fl_blocker.
>
> The fl_blocked list_head in an active lock is the head of a list of
>
Hello Dear
how are you doing today? my name is Bruce Blake, the manager foreign affairs in
City Finance Bank, we have a customer here in bank that has not accessed his
account for the past 18 years, after some research made about him we found out
he was a victim of the crashed mining company
Hello Dear
how are you doing today? my name is Bruce Blake, the manager foreign affairs in
City Finance Bank, we have a customer here in bank that has not accessed his
account for the past 18 years, after some research made about him we found out
he was a victim of the crashed mining company
Hello Dear
how are you doing today? my name is Bruce Blake, the manager foreign affairs in
City Finance Bank, we have a customer here in bank that has not accessed his
account for the past 18 years, after some research made about him we found out
he was a victim of the crashed mining company
Hello Dear
how are you doing today? my name is Bruce Blake, the manager foreign affairs in
City Finance Bank, we have a customer here in bank that has not accessed his
account for the past 18 years, after some research made about him we found out
he was a victim of the crashed mining company
Hello Dear
how are you doing today? my name is Bruce Blake, the manager foreign affairs in
City Finance Bank, we have a customer here in bank that has not accessed his
account for the past 18 years, after some research made about him we found out
he was a victim of the crashed mining company
Hello Dear
how are you doing today? my name is Bruce Blake, the manager foreign affairs in
City Finance Bank, we have a customer here in bank that has not accessed his
account for the past 18 years, after some research made about him we found out
he was a victim of the crashed mining company
On Tue, Oct 30, 2018 at 01:06:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 30, 2018 at 12:55 PM Linus Torvalds
> wrote:
> >
> > Pulled,
>
> Oh, I take that back. Semantic conflict with locking name change
> (recv_lock -> queue_lock) and new code in
>
>
On Tue, Oct 30, 2018 at 01:06:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 30, 2018 at 12:55 PM Linus Torvalds
> wrote:
> >
> > Pulled,
>
> Oh, I take that back. Semantic conflict with locking name change
> (recv_lock -> queue_lock) and new code in
>
>
Please pull nfsd changes for 4.20:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20
Olga added support for the NFSv4.2 asynchronous copy protocol. We
already supported COPY, by copying a limited amount of data and then
returning a short result, letting the client resend. The
Please pull nfsd changes for 4.20:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20
Olga added support for the NFSv4.2 asynchronous copy protocol. We
already supported COPY, by copying a limited amount of data and then
returning a short result, letting the client resend. The
On Thu, Oct 25, 2018 at 06:17:25PM +0300, Amir Goldstein wrote:
> On Thu, Oct 25, 2018 at 6:02 PM Bruce Fields wrote:
>
> > > > So I guess it has fallen between the cracks.
> > > > Feel free to send a patch to Jeff.
> > > >
> > > > Thanks,
&g
On Thu, Oct 25, 2018 at 06:17:25PM +0300, Amir Goldstein wrote:
> On Thu, Oct 25, 2018 at 6:02 PM Bruce Fields wrote:
>
> > > > So I guess it has fallen between the cracks.
> > > > Feel free to send a patch to Jeff.
> > > >
> > > > Thanks,
&g
s excellent scalability with lots of threads on lots of CPUs
>contending on a single file
> - avoids the problems that Bruce found
> - seems to work.
>
> Thanks,
> NeilBrown
>
>
> ---
>
> NeilBrown (9):
> fs/locks: rename some lists and pointers.
&
s excellent scalability with lots of threads on lots of CPUs
>contending on a single file
> - avoids the problems that Bruce found
> - seems to work.
>
> Thanks,
> NeilBrown
>
>
> ---
>
> NeilBrown (9):
> fs/locks: rename some lists and pointers.
&
.
> > >
> >
> > I did not send this patch to Jeff.
> > Jeff was CC'ed on the patch I sent to Miklos
> > and Miklos decided to only take the overlayfs bits:
> > https://marc.info/?l=linux-unionfs=153847248625015=2
> >
> > So I guess it has fallen between the cracks.
> > Feel free to send a patch to Jeff.
> >
> > Thanks,
> > Amir.
>
> Actually, this should probably go to Bruce, as he mostly takes care of
> lockd. Patch looks correct though.
Yes, if you could resend I'd be happy to handle it.--b.
.
> > >
> >
> > I did not send this patch to Jeff.
> > Jeff was CC'ed on the patch I sent to Miklos
> > and Miklos decided to only take the overlayfs bits:
> > https://marc.info/?l=linux-unionfs=153847248625015=2
> >
> > So I guess it has fallen between the cracks.
> > Feel free to send a patch to Jeff.
> >
> > Thanks,
> > Amir.
>
> Actually, this should probably go to Bruce, as he mostly takes care of
> lockd. Patch looks correct though.
Yes, if you could resend I'd be happy to handle it.--b.
Thanks, applying.--b.
On Tue, Oct 02, 2018 at 12:08:48PM +0200, Gustavo A. R. Silva wrote:
> Replace "fallthru" with a proper "fall through" annotation.
>
> Also, add an annotation were it is expected to fall through.
>
> These fixes are part of the ongoing efforts to enabling
>
Thanks, applying.--b.
On Tue, Oct 02, 2018 at 12:08:48PM +0200, Gustavo A. R. Silva wrote:
> Replace "fallthru" with a proper "fall through" annotation.
>
> Also, add an annotation were it is expected to fall through.
>
> These fixes are part of the ongoing efforts to enabling
>
On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> >
> > You attempt to open "C/../../etc/passwd" under
On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> >
> > You attempt to open "C/../../etc/passwd" under
Thanks, applying for 4.20.--b.
On Tue, Sep 25, 2018 at 11:22:53AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> fs/nfsd/vfs.c: In function 'nfsd_create':
> fs/nfsd/vfs.c:1279:16: warning:
> variable 'dirp' set but not used [-Wunused-but-set-variable]
>
>
Thanks, applying for 4.20.--b.
On Tue, Sep 25, 2018 at 11:22:53AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> fs/nfsd/vfs.c: In function 'nfsd_create':
> fs/nfsd/vfs.c:1279:16: warning:
> variable 'dirp' set but not used [-Wunused-but-set-variable]
>
>
On Wed, Sep 05, 2018 at 06:55:15AM -0400, Jeff Layton wrote:
> There is no requirement for a filesystem to flush data on close(). In
> fact, most local filesystems do not. NFS does, but that's because it has
> to in order to provide close-to-open cache consistency semantics.
And these days even
On Wed, Sep 05, 2018 at 06:55:15AM -0400, Jeff Layton wrote:
> There is no requirement for a filesystem to flush data on close(). In
> fact, most local filesystems do not. NFS does, but that's because it has
> to in order to provide close-to-open cache consistency semantics.
And these days even
On Tue, Sep 04, 2018 at 06:23:48PM +0200, Rogier Wolff wrote:
> On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
> > Well, I think the point was that in the above examples you'd prefer that
> > the read just fail--no need to keep the data. A bit marking the fi
On Tue, Sep 04, 2018 at 06:23:48PM +0200, Rogier Wolff wrote:
> On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
> > Well, I think the point was that in the above examples you'd prefer that
> > the read just fail--no need to keep the data. A bit marking the fi
On Tue, Sep 04, 2018 at 11:44:20AM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 22:56 +0800, 焦晓冬 wrote:
> > A practical and concrete example may be,
> > A disk cleaner program that first searches for garbage files that won't be
> > used
> > anymore and save the list in a file
On Tue, Sep 04, 2018 at 11:44:20AM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 22:56 +0800, 焦晓冬 wrote:
> > A practical and concrete example may be,
> > A disk cleaner program that first searches for garbage files that won't be
> > used
> > anymore and save the list in a file
Apologies, I messed up my pull request. The result was just a few
commits mentioned in the tag description but missing from the tip of the
branch, and I thought simplest was to make a new tag and a new pull
request with the additional commits, I hope that works OK. Thanks to
Chuck for noticing
Apologies, I messed up my pull request. The result was just a few
commits mentioned in the tag description but missing from the tip of the
branch, and I thought simplest was to make a new tag and a new pull
request with the additional commits, I hope that works OK. Thanks to
Chuck for noticing
):
nfsd: constify write_op[]
Gustavo A. R. Silva (2):
nfsd: Mark expected switch fall-through
nfsd: use true and false for boolean values
J. Bruce Fields (9):
nfsd4: extend reclaim period for reclaiming clients
nfsd4: return default lease period
nfsd: fix NFSv4
):
nfsd: constify write_op[]
Gustavo A. R. Silva (2):
nfsd: Mark expected switch fall-through
nfsd: use true and false for boolean values
J. Bruce Fields (9):
nfsd4: extend reclaim period for reclaiming clients
nfsd4: return default lease period
nfsd: fix NFSv4
On Mon, Aug 20, 2018 at 01:02:21PM +0200, Martin Wilck wrote:
> On Wed, 2018-08-08 at 14:29 -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 12:47:22PM -0400, Jeff Layton wrote:
> > > On Wed, 2018-08-08 at 11:51 +1000, NeilBrown wrote:
> > > > If you have
On Mon, Aug 20, 2018 at 01:02:21PM +0200, Martin Wilck wrote:
> On Wed, 2018-08-08 at 14:29 -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 12:47:22PM -0400, Jeff Layton wrote:
> > > On Wed, 2018-08-08 at 11:51 +1000, NeilBrown wrote:
> > > > If you have
On Sat, Aug 18, 2018 at 12:51:14AM -0500, Eric W. Biederman wrote:
> I was dismayed when I saw the syzbot report triggered someone to remove
> themselves from MAINTAINERS.
You're talking about my patch? I think you misread it, I'm not removing
myself from MAINTAINERS.
--b.
On Sat, Aug 18, 2018 at 12:51:14AM -0500, Eric W. Biederman wrote:
> I was dismayed when I saw the syzbot report triggered someone to remove
> themselves from MAINTAINERS.
You're talking about my patch? I think you misread it, I'm not removing
myself from MAINTAINERS.
--b.
On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> > wrote:
> >> Dmitry Vyukov writes:
> >>
> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce F
On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> > wrote:
> >> Dmitry Vyukov writes:
> >>
> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce F
On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> wrote:
> > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> >> syzbot has found a reproducer for the following crash on:
> >>
> >>
On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> wrote:
> > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> >> syzbot has found a reproducer for the following crash on:
> >>
> >>
On Wed, Aug 15, 2018 at 10:11:20AM +1000, Stephen Rothwell wrote:
> Hi Bruce,
>
> On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov wrote:
> >
> > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> > wrote:
> > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syz
On Wed, Aug 15, 2018 at 10:11:20AM +1000, Stephen Rothwell wrote:
> Hi Bruce,
>
> On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov wrote:
> >
> > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> > wrote:
> > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syz
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
> git tree: linux-next
I fetched linux-next but don't have 5ed5da74de9e.
I'm also not sure why
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
> git tree: linux-next
I fetched linux-next but don't have 5ed5da74de9e.
I'm also not sure why
This version looks correct to me, and simpler. I'll be curious to hear
whatever you learn from testing!
--b.
On Tue, Aug 14, 2018 at 01:56:51PM +1000, NeilBrown wrote:
>
> V2, which added wake_non_conflicts() was more broken than V1 - as
> Bruce explained there is no tra
This version looks correct to me, and simpler. I'll be curious to hear
whatever you learn from testing!
--b.
On Tue, Aug 14, 2018 at 01:56:51PM +1000, NeilBrown wrote:
>
> V2, which added wake_non_conflicts() was more broken than V1 - as
> Bruce explained there is no tra
On Sat, Aug 11, 2018 at 07:56:25AM -0400, Jeff Layton wrote:
> FWIW, I did a bit of testing with lockperf tests that I had written on
> an earlier rework of this code:
>
> https://git.samba.org/jlayton/linux.git/?p=jlayton/lockperf.git;a=summary
>
>
> The posix01 and flock01 tests in there
On Sat, Aug 11, 2018 at 07:56:25AM -0400, Jeff Layton wrote:
> FWIW, I did a bit of testing with lockperf tests that I had written on
> an earlier rework of this code:
>
> https://git.samba.org/jlayton/linux.git/?p=jlayton/lockperf.git;a=summary
>
>
> The posix01 and flock01 tests in there
On Sat, Aug 11, 2018 at 07:51:13AM -0400, Jeff Layton wrote:
> On Thu, 2018-08-09 at 20:29 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 10, 2018 at 08:12:43AM +1000, NeilBrown wrote:
> > > On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > >
> > > > I thi
On Sat, Aug 11, 2018 at 07:51:13AM -0400, Jeff Layton wrote:
> On Thu, 2018-08-09 at 20:29 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 10, 2018 at 08:12:43AM +1000, NeilBrown wrote:
> > > On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > >
> > > > I thi
On Fri, Aug 10, 2018 at 01:17:14PM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
>
> > On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> >> You're good at this game!
> >
> > Everybody's got to have a hobby, mine is pat
On Fri, Aug 10, 2018 at 01:17:14PM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
>
> > On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> >> You're good at this game!
> >
> > Everybody's got to have a hobby, mine is pat
On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> You're good at this game!
Everybody's got to have a hobby, mine is pathological posix locking
cases
> So, because a locker with the same "owner" gets a free pass, you can
> *never* say that any lock which conflicts with A also
On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> You're good at this game!
Everybody's got to have a hobby, mine is pathological posix locking
cases
> So, because a locker with the same "owner" gets a free pass, you can
> *never* say that any lock which conflicts with A also
On Fri, Aug 10, 2018 at 09:56:07AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > If we only cared about the former, and only in simple cases, we could
> > walk the entire list and skip waking up only the locks that conflict
> > with the first one
On Fri, Aug 10, 2018 at 09:56:07AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > If we only cared about the former, and only in simple cases, we could
> > walk the entire list and skip waking up only the locks that conflict
> > with the first one
On Fri, Aug 10, 2018 at 09:40:35AM +1000, NeilBrown wrote:
> caller_fl is first and sys_fl is second.
>
> if sys_fl, the second, is a read lock, and caller_fl, the first, is a
> write lock, they clearly conflict but any other lock that conflict
> with caller_fl (The write lock) would *not*
On Fri, Aug 10, 2018 at 09:40:35AM +1000, NeilBrown wrote:
> caller_fl is first and sys_fl is second.
>
> if sys_fl, the second, is a read lock, and caller_fl, the first, is a
> write lock, they clearly conflict but any other lock that conflict
> with caller_fl (The write lock) would *not*
On Fri, Aug 10, 2018 at 08:19:26AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > I think you could simplify the code a lot by maintaining the tree so
> > that it always satisfies the condition that waiters are always strictly
> > "weaker&q
On Fri, Aug 10, 2018 at 08:19:26AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
> > I think you could simplify the code a lot by maintaining the tree so
> > that it always satisfies the condition that waiters are always strictly
> > "weaker&q
On Fri, Aug 10, 2018 at 08:12:43AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
>
> > I think there's also a problem with multiple tasks sharing the same
> > lock owner.
> >
> > So, all locks are exclusive locks for the same range. We have
On Fri, Aug 10, 2018 at 08:12:43AM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
>
> > I think there's also a problem with multiple tasks sharing the same
> > lock owner.
> >
> > So, all locks are exclusive locks for the same range. We have
I think there's also a problem with multiple tasks sharing the same
lock owner.
So, all locks are exclusive locks for the same range. We have four
tasks. Tasks 1 and 4 share the same owner, the others' owners are
distinct.
- Task 1 gets a lock.
- Task 2 gets a conflicting lock.
I think there's also a problem with multiple tasks sharing the same
lock owner.
So, all locks are exclusive locks for the same range. We have four
tasks. Tasks 1 and 4 share the same owner, the others' owners are
distinct.
- Task 1 gets a lock.
- Task 2 gets a conflicting lock.
On Thu, Aug 09, 2018 at 12:04:41PM +1000, NeilBrown wrote:
> When we find an existing lock which conflicts with a request,
> and the request wants to wait, we currently add the request
> to a list. When the lock is removed, the whole list is woken.
> This can cause the thundering-herd problem.
>
On Thu, Aug 09, 2018 at 12:04:41PM +1000, NeilBrown wrote:
> When we find an existing lock which conflicts with a request,
> and the request wants to wait, we currently add the request
> to a list. When the lock is removed, the whole list is woken.
> This can cause the thundering-herd problem.
>
On Thu, Aug 09, 2018 at 12:04:41PM +1000, NeilBrown wrote:
> In a future patch we will need to differentiate between conflicts that
> are "transitive" and those that aren't.
> A "transitive" conflict is defined as one where any lock that
> conflicts with the first (newly requested) lock would
On Thu, Aug 09, 2018 at 12:04:41PM +1000, NeilBrown wrote:
> In a future patch we will need to differentiate between conflicts that
> are "transitive" and those that aren't.
> A "transitive" conflict is defined as one where any lock that
> conflicts with the first (newly requested) lock would
On Wed, Aug 08, 2018 at 06:50:06PM -0400, Jeff Layton wrote:
> That seems like a legit problem.
>
> One possible fix might be to have the waiter on (1,2) walk down the
> entire subtree and wake up any waiter that is waiting on a lock that
> doesn't conflict with the lock on which it's waiting.
>
On Wed, Aug 08, 2018 at 06:50:06PM -0400, Jeff Layton wrote:
> That seems like a legit problem.
>
> One possible fix might be to have the waiter on (1,2) walk down the
> entire subtree and wake up any waiter that is waiting on a lock that
> doesn't conflict with the lock on which it's waiting.
>
On Wed, Aug 08, 2018 at 04:09:12PM -0400, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > > If you have a many-core machine, and have many threads all wanting to
> &g
On Wed, Aug 08, 2018 at 04:09:12PM -0400, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > > If you have a many-core machine, and have many threads all wanting to
> &g
On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > If you have a many-core machine, and have many threads all wanting to
> > briefly lock a give file (udev is known to do this), you can get quite
>
201 - 300 of 3178 matches
Mail list logo
