Message ID | 2659836.1607940186@warthog.procyon.org.uk (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] keys: Collected minor fixes and cleanups | expand |
On Mon, Dec 14, 2020 at 2:04 AM David Howells <dhowells@redhat.com> wrote: > > Here's a set of minor fixes/cleanups that I've collected from various > people for the next merge window. This doesn't even build. And no, that's not because of some merge error on my part. Just to verify, I tried to build the head of what you sent me (commit 1b91ea77dfeb: "certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID") and it fails the same way. In file included from ./include/linux/cred.h:13, from security/integrity/ima/ima_mok.c:12: security/integrity/ima/ima_mok.c: In function ‘ima_mok_init’: ./include/linux/key.h:292:29: warning: passing argument 7 of ‘keyring_alloc’ makes pointer from integer without a cast [-Wint-conversion] .. ten more lines of warnings.. security/integrity/ima/ima_mok.c:36:26: error: too many arguments to function ‘keyring_alloc’ 36 | ima_blacklist_keyring = keyring_alloc(".ima_blacklist", | ^~~~~~~~~~~~~ so these "fixes" have clearly had absolutely zero testing, haven't been in linux-next, and are completely broken. The bug was introduced by commit 33c36b2053de ("certs: Fix blacklist flag type confusion"), which changed the IMA code without actually testing it. I suspect the fix is trivial (change the "," to "|"), but I will not be pulling this - or anything else that hasn't been in linux-next - from you this merge window. The pain just isn't worth it, but more importantly, you simply need to get your workflow in order, and not send me completely untested garbage that hasn't even been compiled. Linus
On Mon, Dec 14, 2020 at 12:49 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > I suspect the fix is trivial (change the "," to "|"), but I will not > be pulling this - or anything else that hasn't been in linux-next - > from you this merge window. It looks like Stephen Rothwell saw it in next yesterday, and fixed it up there in his merge. So somebody was aware of the problem. But unlike Stephen, I don't take broken code and just silently fix it up in the merge. I suspect Stephen might have thought it was a merge conflict fix, rather than just a broken branch. Stephen: that makes linux-next test coverage kind of pointless, if you just fix bugs in the branches you merge. You should reject things more aggressively, rather than make them "pass" in Linux-next. Linus
Hi Linus, On Mon, 14 Dec 2020 13:05:51 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Mon, Dec 14, 2020 at 12:49 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > I suspect the fix is trivial (change the "," to "|"), but I will not > > be pulling this - or anything else that hasn't been in linux-next - > > from you this merge window. > > It looks like Stephen Rothwell saw it in next yesterday, and fixed it > up there in his merge. > > So somebody was aware of the problem. But unlike Stephen, I don't take > broken code and just silently fix it up in the merge. > > I suspect Stephen might have thought it was a merge conflict fix, > rather than just a broken branch. > > Stephen: that makes linux-next test coverage kind of pointless, if you > just fix bugs in the branches you merge. You should reject things more > aggressively, rather than make them "pass" in Linux-next. I also reported it last Friday (https://lore.kernel.org/lkml/20201211155031.0e35abf2@canb.auug.org.au/) and so assumed it would be fixed before being sent to you ... I sometimes fix simple things up but mostly reject them - clearly that would not have made a difference here.
On Mon, Dec 14, 2020 at 12:49:27PM -0800, Linus Torvalds wrote: > The pain just isn't worth it, but more importantly, you simply need to > get your workflow in order, and not send me completely untested > garbage that hasn't even been compiled. I have now more bandwidth. It was mostly eaten by SGX, especially last few months. Starting from next week, I'll start proactively test keyring changes (I'm this week on vacation). I've been thinking that maybe a two-folded approach would make sense for keyring: 1. I would pick fixes to my linux-tpmdd where they would get quickly mirrored to linux-next. It's already taking changes for trusted keys, i.e. not solely for TPM changes. 2. Feature changes would go through David's tree. > Linus /Jarkko