On Thu, Apr 14, 2022 at 05:12:09PM -0400, Paul Moore wrote: > On Thu, Apr 14, 2022 at 4:56 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Thu, Apr 14, 2022 at 04:38:13PM -0400, Paul Moore wrote: > > > Jokes aside, I'm sorry that caught you out, but thanks for reporting > > > it. I thought I tested all the combinations, but obviously I missed > > > one. The obvious fix is to move the ssleep() call out of > > > checkreqprot_set() and into sel_write_checkreqprot(); you'll still get > > > the error message on the console, but you'll only hit the sleep when > > > toggling the flag after boot, at runtime. It's similar to the runtime > > > disable deprecation. I'll work up a patch as soon as I'm done with > > > this email. > > > > Sounds good. > > > > > However, a couple of quick questions: this looks like a custom/hand > > > built kernel, yes? If so, is this an old kernel config that you just > > > keep updating via 'make oldconfig' or something similar? > > > > Yes, exactly, I've got scripts that take a known old kernel config and > > run make oldconfig. > > > > > I'm asking > > > not to critique your kernel config choice (although this particular > > > Kconfig knob *is* going away), but rather I want to make sure there > > > isn't somebody/something out there still enabling this for a large > > > user base. > > > > Got it, no, these are just systems I set up for nightly regression > > testing of the kernel's NFS client and server. > > Okay, thanks, that's good to know. > > Since you're already building your own kernel you should be able to > just add the patch I just posted to your pile, it should solve your > immediate problem. Yep, confirmed that I can boot after applying that. > I would also strongly encourage you to drop that > Kconfig tweak too. OK, done, thanks. --b.
