lkml.org 
[lkml]   [2017]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: About the try to remove cross-release feature entirely by Ingo
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 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 been tried before.
>
> The question what is classified *well* mean? At the extreme, we could
> put the locks for every single TCP connection into their own lockdep
> class. But that would blow the limits in terms of the number of locks
> out of the water super-quickly --- and it would destroy the ability
> for lockdep to learn what the proper locking order should be. Yet
> given Lockdep's current implementation, the only way to guarantee that
> there won't be any interactions between subsystems that cause false
> positives would be to categorizes locks for each TCP connection into
> their own class.

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,
but that's a relatively small number of places to add annotations,
and I don't see why it wouldn't work.

\
 
 \ /
  Last update: 2017-12-30 21:45    [W:0.061 / U:8.832 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site