On Tue, 2018-08-14 at 14:41 -0400, J. Bruce Fields wrote:
> This version looks correct to me, and simpler. I'll be curious to hear
> whatever you learn from testing!
>
> --b.
>
Agreed. I'll go ahead and put this in linux-next with an eye toward
merging in v4.20 if we don't hit any major problem
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 transitivity in the blockin
V2, which added wake_non_conflicts() was more broken than V1 - as
Bruce explained there is no transitivity in the blocking relation
between locks.
So this series takes a simpler approach.
It still attached waiters between other waiters as necessary to ensure
that:
- a waiter is blocked by it's
On Sat, 2018-08-11 at 08:21 -0400, J. Bruce Fields wrote:
> 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:
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 s
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 think there's also a problem with multiple tasks
On Fri, 2018-08-10 at 11:47 -0400, J. Bruce Fields wrote:
> 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
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 think there's also a problem with multiple tasks sharing the same
> > > lock owner.
> > >
> > > So, all locks are excl
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 pathological posix locking
> > cases
> >
> >
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 "owner" gets a free pass, you can
>> *ne
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 confl
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.
>> >
>> > So, all locks are exclusive locks for the
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 four
> > tasks. Tasks 1 and 4 s
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 four
> tasks. Tasks 1 and 4 share the same owner, the others' owners are
> distinct.
>
> - Task
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.
This series adds "wake_non_conflicts()" to wake up
any waiters that are being added beneath a lock that they
don't actually conflict with, even though they conflict with a parent
which conflict with the top-level blocker.
Thanks for Bruce for highlighting this issue.
This series hasn't been tested
16 matches
Mail list logo