On Thu, Jun 6, 2024 at 2:07 PM Kees Cook <kees@xxxxxxxxxx> wrote: > On Thu, Jun 06, 2024 at 12:36:03PM -0400, Paul Moore wrote: > > It's in the queue, I've been swamped lately as you'll likely notice I > > haven't really had a chance to process patches yet during this cycle. > > I get that you're busy, and I understand that situation -- I get swamped > too. The latency on LSM patch review has been very high lately, and I'm > hoping there's some way we could help. I assume other folks could jump > in and help with the queue[1], but I'm not sure if that would satisfy > your requirements? Other subsystems have been switching more and more to > a group maintainership system, etc. Are there other people you'd be > comfortable sharing the load with? (Currently James and Serge are also > listed as "M:" in MAINTAINERS, but I don't think the 3 of you have a > shared git.kernel.org tree, for example...) We already have a fairly distributed model with each LSM sending directly to Linus; the issue we are seeing now is an odd combination of multiple things: 1) $DAYJOB has had a sudden explosion of high priority internal work which has siphoned away a good chunk of my time 2) we have seen an historically unusual amount of development at the LSM layer itself (as opposed to the individual LSMs) 3) we had a long holiday weekend here in the US and I decided to do what normal people do and not spend all weekend arguing with people on the Internet. Without going into details on #1, let's just say it is transient and not something I expect to be a long term issue (if it does become a long term issue I'll start looking for a new $DAYJOB). I suspect issue #2 is a byproduct of some of the efforts around reinvigorating LSM development, clearing up some long standing warts, etc. and also not something I expect to last for an extended period of time. Issue #3 is a direct result of ... well, far too many threads like this, both from well and poorly intentioned authors. As an aside, things like this typically work better if you have another email setup so you can do the good-cop/bad-cop bit more convincingly. > And yes, there are a lot of patches up for review. I'm antsy about this > series in particular because I'm worried inaction is going to create > larger problems for the LSM as a whole. We've already had Linus drop > in and tell us to do better; I'd really like to avoid having him make > unilateral changes to the LSM, especially when we have a solution on > deck that has been reviewed by many people. You'll note that I'm one of those "many people" that has reviewed it (and had my feedback ignored for several rounds). I simply haven't had the chance to review the latest revision. In my opinion the LSM's largest issue has nothing to do with code, and everything to do with the mentality that a hardware flaw is a LSM bug. If that same mentality wants to ignore decades of work, in a construct it insisted on, and break the user experience for billions of users (and entire usage scenarios) in order to satisfy some misdirected need, then I seriously doubt one patchset is going to solve anything. > I will go back to being anxious/patient... ;) "do better" ;) -- paul-moore.com
