On Fri, Jan 05, 2018 at 11:49:41AM -0500, bfields wrote:
> On Mon, Jan 01, 2018 at 02:18:55AM -0800, Matthew Wilcox wrote:
> > On Sat, Dec 30, 2017 at 06:00:57PM -0500, Theodore Ts'o wrote:
> > > On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote:
> > > > On Sat, Dec 30, 2017 at 12:44:17
On Mon, Jan 01, 2018 at 02:18:55AM -0800, Matthew Wilcox wrote:
> On Sat, Dec 30, 2017 at 06:00:57PM -0500, Theodore Ts'o wrote:
> > On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote:
> > > On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote:
> > > >
> > > > I'm not sure I a
On 1/3/2018 5:10 PM, Byungchul Park wrote:
On 1/3/2018 4:05 PM, Theodore Ts'o wrote:
On Wed, Jan 03, 2018 at 11:10:37AM +0900, Byungchul Park wrote:
The point I was trying to drive home is that "all we have to do is
just classify everything well or just invalidate the right lock
Just to be su
On 1/3/2018 4:05 PM, Theodore Ts'o wrote:
On Wed, Jan 03, 2018 at 11:10:37AM +0900, Byungchul Park wrote:
The point I was trying to drive home is that "all we have to do is
just classify everything well or just invalidate the right lock
Just to be sure, we don't have to invalidate lock objects
On Wed, Jan 03, 2018 at 11:10:37AM +0900, Byungchul Park wrote:
> > The point I was trying to drive home is that "all we have to do is
> > just classify everything well or just invalidate the right lock
>
> Just to be sure, we don't have to invalidate lock objects at all but
> a problematic waiter
On 1/3/2018 11:58 AM, Dave Chinner wrote:
On Wed, Jan 03, 2018 at 11:28:44AM +0900, Byungchul Park wrote:
On 1/1/2018 7:18 PM, Matthew Wilcox wrote:
On Sat, Dec 30, 2017 at 06:00:57PM -0500, Theodore Ts'o wrote:
Also, what to do with TCP connections which are created in userspace
(with some au
On Wed, Jan 03, 2018 at 11:28:44AM +0900, Byungchul Park wrote:
> On 1/1/2018 7:18 PM, Matthew Wilcox wrote:
> >On Sat, Dec 30, 2017 at 06:00:57PM -0500, Theodore Ts'o wrote:
> >>Also, what to do with TCP connections which are created in userspace
> >>(with some authentication exchanges happening i
On 1/2/2018 1:00 AM, Theodore Ts'o wrote:
On Mon, Jan 01, 2018 at 02:18:55AM -0800, Matthew Wilcox wrote:
Clarification: all TCP connections that are used by kernel code would
need to be in their own separate lock class. All TCP connections used
only by userspace could be in their own shared lo
On 1/1/2018 7:18 PM, Matthew Wilcox wrote:
On Sat, Dec 30, 2017 at 06:00:57PM -0500, Theodore Ts'o wrote:
On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote:
On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote:
I'm not sure I agree with this part. What if we add a new T
On 12/31/2017 7:40 AM, Theodore Ts'o wrote:
On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote:
I'm not sure I agree with this part. What if we add a new TCP lock class
for connections which are used for filesystems/network block devices/...?
Yes, it'll be up to each user to set th
On 12/31/2017 12:40 AM, Theodore Ts'o wrote:
On Fri, Dec 29, 2017 at 10:16:24PM -0800, Matthew Wilcox wrote:
I disagree here. As Ted says, it's the interactions between the
subsystems that leads to problems. Everything's goig to work great
until somebody does something in a way that's never b
On 12/30/2017 3:16 PM, Matthew Wilcox wrote:
On Fri, Dec 29, 2017 at 04:28:51PM +0900, Byungchul Park wrote:
On Thu, Dec 28, 2017 at 10:51:46PM -0500, Theodore Ts'o wrote:
On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote:
(1) The best way: To classify all waiters correctly.
On Mon, Jan 01, 2018 at 02:18:55AM -0800, Matthew Wilcox wrote:
> > Clarification: all TCP connections that are used by kernel code would
> > need to be in their own separate lock class. All TCP connections used
> > only by userspace could be in their own shared lock class. You can't
> > use a on
On Sat, Dec 30, 2017 at 06:00:57PM -0500, Theodore Ts'o wrote:
> On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote:
> > On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote:
> > >
> > > I'm not sure I agree with this part. What if we add a new TCP lock class
> > > for connec
On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote:
> On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote:
> >
> > I'm not sure I agree with this part. What if we add a new TCP lock class
> > for connections which are used for filesystems/network block devices/...?
> > Yes,
On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote:
>
> I'm not sure I agree with this part. What if we add a new TCP lock class
> for connections which are used for filesystems/network block devices/...?
> Yes, it'll be up to each user to set the lockdep classification correctly,
> b
On Sat, Dec 30, 2017 at 10:40:41AM -0500, Theodore Ts'o wrote:
> On Fri, Dec 29, 2017 at 10:16:24PM -0800, Matthew Wilcox wrote:
> > > The problems come from wrong classification. Waiters either classfied
> > > well or invalidated properly won't bitrot.
> >
> > I disagree here. As Ted says, it's
On Fri, Dec 29, 2017 at 10:16:24PM -0800, Matthew Wilcox wrote:
>
> I think this is a terminology problem. To me (and, I suspect Ted), a
> waiter is a subject of a verb while a lock is an object. So Ted is asking
> whether we have to classify the users, while I think you're saying we
> have extr
On Fri, Dec 29, 2017 at 04:28:51PM +0900, Byungchul Park wrote:
> On Thu, Dec 28, 2017 at 10:51:46PM -0500, Theodore Ts'o wrote:
> > On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote:
> > >
> > >(1) The best way: To classify all waiters correctly.
> >
> > It's really not all wait
On 12/29/2017 5:09 PM, Amir Goldstein wrote:
On Fri, Dec 29, 2017 at 3:47 AM, Byungchul Park wrote:
On Wed, Dec 13, 2017 at 03:24:29PM +0900, Byungchul Park wrote:
Lockdep works, based on the following:
(1) Classifying locks properly
(2) Checking relationship between the classes
If (
On Fri, Dec 29, 2017 at 3:47 AM, Byungchul Park wrote:
> On Wed, Dec 13, 2017 at 03:24:29PM +0900, Byungchul Park wrote:
>> Lockdep works, based on the following:
>>
>>(1) Classifying locks properly
>>(2) Checking relationship between the classes
>>
>> If (1) is not good or (2) is not good
On Thu, Dec 28, 2017 at 10:51:46PM -0500, Theodore Ts'o wrote:
> On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote:
> >
> >(1) The best way: To classify all waiters correctly.
>
> It's really not all waiters, but all *locks*, no?
Thanks for your opinion. I will add my opinion on
On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote:
>
>(1) The best way: To classify all waiters correctly.
It's really not all waiters, but all *locks*, no?
> Ultimately the problems should be solved in this way. But it
> takes a lot of time so it's not easy to use t
On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote:
> On Wed, Dec 13, 2017 at 03:24:29PM +0900, Byungchul Park wrote:
> > Lockdep works, based on the following:
> >
> >(1) Classifying locks properly
> >(2) Checking relationship between the classes
> >
> > If (1) is not good or
On Wed, Dec 13, 2017 at 03:24:29PM +0900, Byungchul Park wrote:
> Lockdep works, based on the following:
>
>(1) Classifying locks properly
>(2) Checking relationship between the classes
>
> If (1) is not good or (2) is not good, then we
> might get false positives.
>
> For (1), we don't
On Thu, Dec 14, 2017 at 8:18 PM, Peter Zijlstra wrote:
> On Wed, Dec 13, 2017 at 10:07:11PM -0500, Theodore Ts'o wrote:
>> interpreted this as the lockdep maintainers saying, "hey, not my
>> fault, it's the subsystem maintainer's fault for not properly
>> classifying the locks" --- and thus dumpin
On Wed, Dec 13, 2017 at 10:07:11PM -0500, Theodore Ts'o wrote:
> interpreted this as the lockdep maintainers saying, "hey, not my
> fault, it's the subsystem maintainer's fault for not properly
> classifying the locks" --- and thus dumping the responsibility in the
> subsystem maintainers' laps.
L
On Thu, Dec 14, 2017 at 12:07 PM, Theodore Ts'o wrote:
> On Wed, Dec 13, 2017 at 04:13:07PM +0900, Byungchul Park wrote:
>>
>> Therefore, I want to say the fundamental problem
>> comes from classification, not cross-release
>> specific.
>
> You keep saying that it is "just" a matter of classificai
On Wed, Dec 13, 2017 at 04:13:07PM +0900, Byungchul Park wrote:
>
> Therefore, I want to say the fundamental problem
> comes from classification, not cross-release
> specific.
You keep saying that it is "just" a matter of classificaion.
However, it is not obvious how to do the classification in
On Wed, 2017-12-13 at 16:13 +0900, Byungchul Park wrote:
> In addition, I want to say that the current level of
> classification is much less than 100% but, since we
> have annotated well to suppress wrong reports by
> rough classifications, finally it does not come into
> view by original lockdep
On Wed, Dec 13, 2017 at 3:24 PM, Byungchul Park
wrote:
> Lockdep works, based on the following:
>
>(1) Classifying locks properly
>(2) Checking relationship between the classes
>
> If (1) is not good or (2) is not good, then we
> might get false positives.
>
> For (1), we don't have to cla
Lockdep works, based on the following:
(1) Classifying locks properly
(2) Checking relationship between the classes
If (1) is not good or (2) is not good, then we
might get false positives.
For (1), we don't have to classify locks 100%
properly but need as enough as lockdep works.
For (2)
32 matches
Mail list logo
