On 6/13/22 15:48, Matthew Wilcox wrote: > On Mon, Jun 06, 2022 at 02:00:33PM -0700, John Johansen wrote: >> On 6/6/22 13:23, Matthew Wilcox wrote: >>> On Mon, Jun 06, 2022 at 12:19:36PM -0700, John Johansen wrote: >>>>> I suspect that part is that both Apparmor and IPC use the idr local lock. >>>>> >>>> bingo, >>>> >>>> apparmor moved its secids allocation from a custom radix tree to idr in >>>> >>>> 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids >>>> >>>> and ipc is using the idr for its id allocation as well >>>> >>>> I can easily lift the secid() allocation out of the ctx->lock but that >>>> would still leave it happening under the file_lock and not fix the problem. >>>> I think the quick solution would be for apparmor to stop using idr, reverting >>>> back at least temporarily to the custom radix tree. >>> >>> How about moving forward to the XArray that doesn't use that horrid >>> prealloc gunk? Compile tested only. >>> >> >> I'm not very familiar with XArray but it does seem like a good fit. We do try >> to keep the secid allocation dense, ideally no holes. Wrt the current locking >> issue I want to hear what Thomas has to say. Regardless I am looking into >> whether we should just switch to XArrays going forward. > > Nothing from Thomas ... shall we just go with this? Do you want a > commit message, etc for the patch? Hey Matthew, I have done testing with this and the patch looks good. We will certainly go this route going forward so a commit message, would be good. As for fixing the issue in current kernels. I am not opposed to pulling this back as fixes for 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids but I would like some other peoples opinions on doing that, because we don't understand why we are getting the current lock splat, and without understanding it is a fix by avoiding the issue rather than being sure the actual issue is fixed.
