-by: NeilBrown
---
fs/nfs/nfs4proc.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 8220a168282e..cd5a431c6583 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6284,7 +6284,8 @@ static struct nfs4_unlockdata
This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index a6c6d601286c..b8f33792a0a6
- seems to work.
Thanks,
NeilBrown
---
NeilBrown (9):
fs/locks: rename some lists and pointers.
fs/locks: split out __locks_wake_up_blocks().
NFS: use locks_copy_lock() to copy locks.
fs/locks: allow a lock request to block other requests.
fs/locks: always
- seems to work.
Thanks,
NeilBrown
---
NeilBrown (9):
fs/locks: rename some lists and pointers.
fs/locks: split out __locks_wake_up_blocks().
NFS: use locks_copy_lock() to copy locks.
fs/locks: allow a lock request to block other requests.
fs/locks: always
On Tue, Oct 23 2018, Theodore Y. Ts'o wrote:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>>
>> Yes, you could, and you can. But if it was Linus who was behaving
>> inappropriately, where did you go then? This is why I think whatever
>> "
On Tue, Oct 23 2018, Theodore Y. Ts'o wrote:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>>
>> Yes, you could, and you can. But if it was Linus who was behaving
>> inappropriately, where did you go then? This is why I think whatever
>> "
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote:
>
>> > If that's a clarification, I'm sorry to say that I understand you even
>> > less now.
>> > What are you proposing? Duopoly? How do you deal with disagreemen
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote:
>
>> > If that's a clarification, I'm sorry to say that I understand you even
>> > less now.
>> > What are you proposing? Duopoly? How do you deal with disagreemen
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>
>> >> If Linus is not true to his new-found sensitivity, we might need someone
>> >> (Greg?) to be a co-maintainer, able to accept patches when Linus has a
>>
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>
>> >> If Linus is not true to his new-found sensitivity, we might need someone
>> >> (Greg?) to be a co-maintainer, able to accept patches when Linus has a
>>
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>
>> Currently if a maintainer is rude to you, there is no where else that
>> you can go and *that* is why it hurts. It isn't the abuse so much as
>> the powerlessness associa
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>
>> Currently if a maintainer is rude to you, there is no where else that
>> you can go and *that* is why it hurts. It isn't the abuse so much as
>> the powerlessness associa
On Sun, Oct 21 2018, Theodore Y. Ts'o wrote:
> On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
>> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> > I call on you, Greg:
>> > - to abandon this divisive attempt to impose a "Co
On Sun, Oct 21 2018, Theodore Y. Ts'o wrote:
> On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
>> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> > I call on you, Greg:
>> > - to abandon this divisive attempt to impose a "Co
On Mon, Oct 22 2018, Theodore Y. Ts'o wrote:
> Neil,
>
> I disagree with your framing, and thus your analysis, and thus your
> proposed solution.
>
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> If, for example, Linus or Andrew said "if y
On Mon, Oct 22 2018, Theodore Y. Ts'o wrote:
> Neil,
>
> I disagree with your framing, and thus your analysis, and thus your
> proposed solution.
>
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> If, for example, Linus or Andrew said "if y
On Sun, Oct 21 2018, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> I call on you, Greg:
>> - to abandon this divisive attempt to impose a "Code of Conduct"
>> - to revert 8a104f8b5867c68
>> - to return to your cor
On Sun, Oct 21 2018, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> I call on you, Greg:
>> - to abandon this divisive attempt to impose a "Code of Conduct"
>> - to revert 8a104f8b5867c68
>> - to return to your cor
ide the community and who have recently joined.
What is the document that you would have liked to have read as you were
starting out? It is all too long ago for me to remember clearly, and so
much has changed.
Thanks,
NeilBrown
#Iobject #Iforgive #Iapologise #Isupportreversion
signature.asc
Description: PGP signature
ide the community and who have recently joined.
What is the document that you would have liked to have read as you were
starting out? It is all too long ago for me to remember clearly, and so
much has changed.
Thanks,
NeilBrown
#Iobject #Iforgive #Iapologise #Isupportreversion
signature.asc
Description: PGP signature
On Wed, Oct 17 2018, Andy Lutomirski wrote:
> On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote:
>>
>>
>> Was: Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task() to
>> in_{ia32,x32}_syscall()
>> On Tue, Apr 19 2016, tip-bot for Dmitry
On Wed, Oct 17 2018, Andy Lutomirski wrote:
> On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote:
>>
>>
>> Was: Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task() to
>> in_{ia32,x32}_syscall()
>> On Tue, Apr 19 2016, tip-bot for Dmitry
ON) && \
current_thread_info()->status & TS_COMPAT)
This came up in the (no out-of-tree) lustre filesystem where some code
needs to assume 32-bit mode in X86_32 syscalls, and 64-bit mode in kernel
threads.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
ON) && \
current_thread_info()->status & TS_COMPAT)
This came up in the (no out-of-tree) lustre filesystem where some code
needs to assume 32-bit mode in X86_32 syscalls, and 64-bit mode in kernel
threads.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
On Fri, Oct 05 2018, Al Viro wrote:
> On Fri, Oct 05, 2018 at 11:27:37AM +1000, NeilBrown wrote:
>>
>> The synchronize_rcu() in namespace_unlock() is called every time
>> a filesystem is unmounted. If a great many filesystems are mounted,
>> this can cause a noticabl
On Fri, Oct 05 2018, Al Viro wrote:
> On Fri, Oct 05, 2018 at 11:27:37AM +1000, NeilBrown wrote:
>>
>> The synchronize_rcu() in namespace_unlock() is called every time
>> a filesystem is unmounted. If a great many filesystems are mounted,
>> this can cause a noticabl
() to synchronize_rcu_expedited()
the umount time on a 4-cpu VM drop to 0.6 seconds
I think this 200-fold speed up is worth the slightly high system
impact of using synchronize_rcu_expedited().
Acked-by: Paul E. McKenney (from general rcu
perspective)
Signed-off-by: NeilBrown
---
I posted this last
() to synchronize_rcu_expedited()
the umount time on a 4-cpu VM drop to 0.6 seconds
I think this 200-fold speed up is worth the slightly high system
impact of using synchronize_rcu_expedited().
Acked-by: Paul E. McKenney (from general rcu
perspective)
Signed-off-by: NeilBrown
---
I posted this last
sed and
which actually affects coda is the check for use fcntl(F_SETFL) to set
O_NOATIME. I suspect that is irrelevant for coda.
I'll resubmit with the same code for both NFS and code - and probably
AFS.
Thanks,
NeilBrown
>
> Jan
>
> On October 4, 2018 10:10:13 AM EDT, David Howells wr
sed and
which actually affects coda is the check for use fcntl(F_SETFL) to set
O_NOATIME. I suspect that is irrelevant for coda.
I'll resubmit with the same code for both NFS and code - and probably
AFS.
Thanks,
NeilBrown
>
> Jan
>
> On October 4, 2018 10:10:13 AM EDT, David Howells wr
On Thu, Oct 04 2018, David Howells wrote:
> NeilBrown wrote:
>
>> diff --git a/fs/afs/security.c b/fs/afs/security.c
>> index 81dfedb7879f..ac2e39de8bff 100644
>> --- a/fs/afs/security.c
>> +++ b/fs/afs/security.c
>> @@ -349,6 +349,16 @@ int afs_perm
On Thu, Oct 04 2018, David Howells wrote:
> NeilBrown wrote:
>
>> diff --git a/fs/afs/security.c b/fs/afs/security.c
>> index 81dfedb7879f..ac2e39de8bff 100644
>> --- a/fs/afs/security.c
>> +++ b/fs/afs/security.c
>> @@ -349,6 +349,16 @@ int afs_perm
permissions.
Signed-off-by: NeilBrown
---
v1 of this patch had an obvious bug which, of course, I couldn't see
until after posting.
__MAY_UNUSED had the same value as MAY_ACT_AS_OWNER - so it wasn't
unused!
NeilBrown
fs/nfsd/vfs.h | 33 ++---
include/linux/fs.h | 2
permissions.
Signed-off-by: NeilBrown
---
v1 of this patch had an obvious bug which, of course, I couldn't see
until after posting.
__MAY_UNUSED had the same value as MAY_ACT_AS_OWNER - so it wasn't
unused!
NeilBrown
fs/nfsd/vfs.h | 33 ++---
include/linux/fs.h | 2
.
Signed-off-by: NeilBrown
---
fs/nfsd/vfs.c | 11 ++-
fs/nfsd/vfs.h | 14 +++---
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 55a099e47ba2..d89d23e6e2fe 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -2038,12 +2038,13
.
Signed-off-by: NeilBrown
---
fs/nfsd/vfs.c | 11 ++-
fs/nfsd/vfs.h | 14 +++---
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 55a099e47ba2..d89d23e6e2fe 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -2038,12 +2038,13
.
Signed-off-by: NeilBrown
---
fs/nfsd/vfs.h | 33 ++---
include/linux/fs.h |2 ++
2 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
index a7e107309f76..2b1c70d3757a 100644
--- a/fs/nfsd/vfs.h
+++ b/fs/nfsd/vfs.h
.
Signed-off-by: NeilBrown
---
fs/nfsd/vfs.h | 33 ++---
include/linux/fs.h |2 ++
2 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
index a7e107309f76..2b1c70d3757a 100644
--- a/fs/nfsd/vfs.h
+++ b/fs/nfsd/vfs.h
is to send the request to the server and see if it works.
The first patch introduces MAY_ACT_AS_OWNER and relies on the
filesystem to do the appropriate ownership test. This touches
several filesystems, hence the long 'Cc' list.
Following two patches are small code cleanups relating to this.
Thanks,
appropriate.
Fixes: 013cdf1088d7 ("nfs: use generic posix ACL infrastructure for v3 Posix
ACLs")
Signed-off-by: NeilBrown
---
fs/afs/security.c | 10 ++
fs/attr.c | 12 +---
fs/coda/dir.c | 10 ++
fs/fcntl.c |2 +-
fs/fuse/dir
is to send the request to the server and see if it works.
The first patch introduces MAY_ACT_AS_OWNER and relies on the
filesystem to do the appropriate ownership test. This touches
several filesystems, hence the long 'Cc' list.
Following two patches are small code cleanups relating to this.
Thanks,
appropriate.
Fixes: 013cdf1088d7 ("nfs: use generic posix ACL infrastructure for v3 Posix
ACLs")
Signed-off-by: NeilBrown
---
fs/afs/security.c | 10 ++
fs/attr.c | 12 +---
fs/coda/dir.c | 10 ++
fs/fcntl.c |2 +-
fs/fuse/dir
nWRT-like distros).
In libreCMC the patch has John listed as the Author, and I thought it
right to preserve that.
I believe the code comes from a code-dump made by Mediatek several years
ago. It can be found at git://github.com/mqmaker/linux.git.
The code there contains (in drivers/mmc/host/mtk-mmc/sd.c
nWRT-like distros).
In libreCMC the patch has John listed as the Author, and I thought it
right to preserve that.
I believe the code comes from a code-dump made by Mediatek several years
ago. It can be found at git://github.com/mqmaker/linux.git.
The code there contains (in drivers/mmc/host/mtk-mmc/sd.c
On Wed, Aug 22 2018, NeilBrown wrote:
>
> Oh dear.
> nfs4_alloc_lockdata contains:
> memcpy(>fl, fl, sizeof(p->fl));
>
> so any list_heads that are valid in fl will be invalid in p->fl.
>
> Maybe I should initialize the relevant list_heads at the start of
On Wed, Aug 22 2018, NeilBrown wrote:
>
> Oh dear.
> nfs4_alloc_lockdata contains:
> memcpy(>fl, fl, sizeof(p->fl));
>
> so any list_heads that are valid in fl will be invalid in p->fl.
>
> Maybe I should initialize the relevant list_heads at the start of
m --> ashmem_mutex
>>
>> Possible unsafe locking scenario:
>>
>>CPU0CPU1
>>
>> lock(ashmem_mutex);
>> lock(>mmap_sem);
>>
m --> ashmem_mutex
>>
>> Possible unsafe locking scenario:
>>
>>CPU0CPU1
>>
>> lock(ashmem_mutex);
>> lock(>mmap_sem);
>>
On Tue, Aug 21 2018, Jeff Layton wrote:
> On Tue, 2018-08-21 at 15:11 +1000, NeilBrown wrote:
>> On Thu, Aug 16 2018, NeilBrown wrote:
>>
>> > On Wed, Aug 15 2018, Jeff Layton wrote:
>> >
>> > > On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski
On Tue, Aug 21 2018, Jeff Layton wrote:
> On Tue, 2018-08-21 at 15:11 +1000, NeilBrown wrote:
>> On Thu, Aug 16 2018, NeilBrown wrote:
>>
>> > On Wed, Aug 15 2018, Jeff Layton wrote:
>> >
>> > > On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski
On Thu, Aug 16 2018, NeilBrown wrote:
> On Wed, Aug 15 2018, Jeff Layton wrote:
>
>> On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Bisect pointed commit ce3147990450a68b3f549088b30f087742a08b5d
>>> ("f
On Thu, Aug 16 2018, NeilBrown wrote:
> On Wed, Aug 15 2018, Jeff Layton wrote:
>
>> On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Bisect pointed commit ce3147990450a68b3f549088b30f087742a08b5d
>>> ("f
nk we need to insert a call to locks_wake_up_block() in
do_lock_file_wait() before it returns.
I cannot find a sequence that would make this necessary, but
it isn't surprising that there might be one.
I'll dig through the code a bit more later and make sure I understand
what is happening.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
nk we need to insert a call to locks_wake_up_block() in
do_lock_file_wait() before it returns.
I cannot find a sequence that would make this necessary, but
it isn't surprising that there might be one.
I'll dig through the code a bit more later and make sure I understand
what is happening.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
is requeued or discarded, all blocked requests are
woken.
- When deadlock-detection looks for the lock which blocks a
given request, we follow the chain of ->fl_blocker all
the way to the top.
Signed-off-by: NeilBrown
---
fs/locks.c | 43 +++
1 f
Wilck
Signed-off-by: NeilBrown
---
fs/locks.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index c7a372cebff1..af250afceff4 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -727,11 +727,25 @@ static void locks_delete_block
.
And convert some
return (foo);
to
return foo;
Signed-off-by: NeilBrown
---
fs/locks.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 9439eebd4eb9..c7a372cebff1 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -803,47
is requeued or discarded, all blocked requests are
woken.
- When deadlock-detection looks for the lock which blocks a
given request, we follow the chain of ->fl_blocker all
the way to the top.
Signed-off-by: NeilBrown
---
fs/locks.c | 43 +++
1 f
Wilck
Signed-off-by: NeilBrown
---
fs/locks.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index c7a372cebff1..af250afceff4 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -727,11 +727,25 @@ static void locks_delete_block
.
And convert some
return (foo);
to
return foo;
Signed-off-by: NeilBrown
---
fs/locks.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 9439eebd4eb9..c7a372cebff1 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -803,47
est on 72 cores, the lock
acquisitions per second drops from 1.8 million to 1.4 million with
this patch. For 100 processes, this patch still provides 1.4 million
while without this patch there are about 700,000.
NeilBrown
---
NeilBrown (5):
fs/locks: rename some lists and pointers.
est on 72 cores, the lock
acquisitions per second drops from 1.8 million to 1.4 million with
this patch. For 100 processes, this patch still provides 1.4 million
while without this patch there are about 700,000.
NeilBrown
---
NeilBrown (5):
fs/locks: rename some lists and pointers.
This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 322491e70e41..de0b9276f23d
fl_blocker instead
of fl_next.
Signed-off-by: NeilBrown
---
fs/cifs/file.c |2 +-
fs/locks.c | 40 ---
include/linux/fs.h |7 +--
include/trace/events/filelock.h | 16
4 files
This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 322491e70e41..de0b9276f23d
fl_blocker instead
of fl_next.
Signed-off-by: NeilBrown
---
fs/cifs/file.c |2 +-
fs/locks.c | 40 ---
include/linux/fs.h |7 +--
include/trace/events/filelock.h | 16
4 files
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 pathological posix locking
> cases
>
>> So, because a locker with the same "
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 pathological posix locking
> cases
>
>> So, because a locker with the same "
On Thu, Aug 09 2018, 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 think there's also a problem with multiple tasks sharing the same
>> > lock owner.
>> &
On Thu, Aug 09 2018, 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 think there's also a problem with multiple tasks sharing the same
>> > lock owner.
>> &
ink the tree approach should result in less
total CPU usage..
Thanks for the thought - taking this simple approach really hadn't
occurred to me. :-(
NeilBrown
signature.asc
Description: PGP signature
ink the tree approach should result in less
total CPU usage..
Thanks for the thought - taking this simple approach really hadn't
occurred to me. :-(
NeilBrown
signature.asc
Description: PGP signature
On Thu, Aug 09 2018, J. Bruce Fields wrote:
> 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"
On Thu, Aug 09 2018, J. Bruce Fields wrote:
> 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"
On Thu, Aug 09 2018, Jeff Layton wrote:
> On Thu, 2018-08-09 at 12:04 +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, th
On Thu, Aug 09 2018, Jeff Layton wrote:
> On Thu, 2018-08-09 at 12:04 +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, th
On Thu, Aug 09 2018, J. Bruce Fields wrote:
> 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, th
On Thu, Aug 09 2018, J. Bruce Fields wrote:
> 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, th
s 2 and 3 are threads in two other processes.
So 2 and 3 conflict with either 1 or 4 equally - why should task 3 be
woken?
I suspect you got the numbers bit mixed up, but in any case, the
"conflict()" function that is passed around takes ownership into account
when assessing if
s 2 and 3 are threads in two other processes.
So 2 and 3 conflict with either 1 or 4 equally - why should task 3 be
woken?
I suspect you got the numbers bit mixed up, but in any case, the
"conflict()" function that is passed around takes ownership into account
when assessing if
ferent owner.
So this enhancement should work equally for posix, flock, ofd and even
leases.
Thanks,
NeilBrown
>
> Frank
signature.asc
Description: PGP signature
ferent owner.
So this enhancement should work equally for posix, flock, ofd and even
leases.
Thanks,
NeilBrown
>
> Frank
signature.asc
Description: PGP signature
current code which only tests the
truth value of these functions will still work the same way.
And convert some
return (foo);
to
return foo;
Signed-off-by: NeilBrown
---
fs/locks.c | 64 ++--
1 file changed, 49 insertions(+), 15 deletio
. The rest of the herd can stay asleep.
Reported-and-tested-by: Martin Wilck
Signed-off-by: NeilBrown
---
fs/locks.c | 69 +++-
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index fc64016d01ee
This functionality will be useful in the next patch, so
split it out from __locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index d06658b2dc7a..fc64016d01ee 100644
. The rest of the herd can stay asleep.
Reported-and-tested-by: Martin Wilck
Signed-off-by: NeilBrown
---
fs/locks.c | 69 +++-
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index fc64016d01ee
This functionality will be useful in the next patch, so
split it out from __locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index d06658b2dc7a..fc64016d01ee 100644
current code which only tests the
truth value of these functions will still work the same way.
And convert some
return (foo);
to
return foo;
Signed-off-by: NeilBrown
---
fs/locks.c | 64 ++--
1 file changed, 49 insertions(+), 15 deletio
is removed, all blocked requests are woken.
- When deadlock-detection looks for the lock which blocks a
given request, we follow the chain of ->fl_blocker all
the way to the top.
Signed-off-by: NeilBrown
---
fs/locks.c | 58 --
1 f
is removed, all blocked requests are woken.
- When deadlock-detection looks for the lock which blocks a
given request, we follow the chain of ->fl_blocker all
the way to the top.
Signed-off-by: NeilBrown
---
fs/locks.c | 58 --
1 f
breakage?
Signed-off-by: NeilBrown
---
fs/cifs/file.c |2 +-
fs/locks.c | 40 ---
include/linux/fs.h |5 +++--
include/trace/events/filelock.h | 16
4 files changed, 33 insertions
breakage?
Signed-off-by: NeilBrown
---
fs/cifs/file.c |2 +-
fs/locks.c | 40 ---
include/linux/fs.h |5 +++--
include/trace/events/filelock.h | 16
4 files changed, 33 insertions
per second drops from 1.8 million to 1.4 million with
this patch. For 100 processes, this patch still provides 1.4 million
while without this patch there are about 700,000.
NeilBrown
---
NeilBrown (5):
fs/locks: rename some lists and pointers.
fs/locks: allow a lock request to block othe
per second drops from 1.8 million to 1.4 million with
this patch. For 100 processes, this patch still provides 1.4 million
while without this patch there are about 700,000.
NeilBrown
---
NeilBrown (5):
fs/locks: rename some lists and pointers.
fs/locks: allow a lock request to block othe
On Wed, Aug 08 2018, 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 a many-core machine, and have many threads all wanting to
>> > briefly lock a giv
On Wed, Aug 08 2018, 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 a many-core machine, and have many threads all wanting to
>> > briefly lock a giv
On Wed, Aug 08 2018, J. Bruce Fields wrote:
> 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 ma
On Wed, Aug 08 2018, J. Bruce Fields wrote:
> 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 ma
On Wed, Aug 08 2018, Frank Filz 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
On Wed, Aug 08 2018, Frank Filz 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
401 - 500 of 4892 matches
Mail list logo
