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 authentication exchanges happening in userspace), and then
passed into kernel space for use in kernel space, is an interesting
question.
Yes! I'd love to have a lockdep expert weigh in here. I believe it's
legitimate to change a lock's class after it's been used, essentially
destroying it and reinitialising it. If not, it should be because it's
a reasonable design for an object to need different lock classes for
different phases of its existance.
I also think it should be done ultimately. And I think it's very much
hard since it requires to change the dependency graph of lockdep but
anyway possible. It's up to lockdep maintainer's will though..
We used to do this in XFS to work around the fact that the memory
reclaim context "locks" were too stupid to understand that an object
referenced and locked above memory allocation could not be
accessed below in memory reclaim because memory reclaim only accesses
/unreferenced objects/. We played whack-a-mole with lockdep for
years to get most of the false positives sorted out.
Hence for a long time we had to re-initialise the lock context for
the XFS inode iolock in ->evict_inode() so we could lock it for
reclaim processing. Eventually we ended up completely reworking the
inode reclaim locking in XFS primarily to get rid of all the nasty
lockdep hacks we had strewn throughout the code. It was ~2012 we
got rid of the last inode re-init code, IIRC. Yeah:
commit 4f59af758f9092bc7b266ca919ce6067170e5172
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed Jul 4 11:13:33 2012 -0400
xfs: remove iolock lock classes
Now that we never take the iolock during inode reclaim we don't need
to play games with lock classes.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Rich Johnston <rjohnston@xxxxxxx>
Signed-off-by: Ben Myers <bpm@xxxxxxx>
We still have problems with lockdep false positives w.r.t. memory
allocation contexts, mainly with code that can be called from
both above and below memory allocation contexts. We've finally
got __GFP_NOLOCKDEP to be able to annotate memory allocation points
within such code paths, but that doesn't help with locks....
Byungchul, lockdep has a long, long history of having sharp edges
and being very unfriendly to developers. We've all been scarred by
lockdep at one time or another and so there's a fair bit of
resistance to repeating past mistakes and allowing lockdep to
inflict more scars on us....
As I understand what you suffered from.. I don't really want to
force it forward strongly.
So far, all problems have been handled by myself including the
final one e.i. the completion in submit_bio_wait() with the
invalidation if it's allowed. But yes, who knows the future? In
the future, that terrible thing you mentioned might or might
not happen because of cross-release.
I just felt like someone was misunderstanding what the problem
came from, what the problem was, how we could avoid it, why
cross-release should be removed and so on..
I believe the 3 ways I suggested can help, but I don't want to
strongly insist if all of you don't think so.
Thanks a lot anyway for your opinion.
--
Thanks,
Byungchul
