| Message ID | 20180817023307.GA32726@nautica |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | [GIT,PULL] 9p updates for 4.19 | expand |
So this pull request confuses me, and that's not a good thing. On Thu, Aug 16, 2018 at 7:33 PM Dominique Martinet <asmadeus@codewreck.org> wrote: > > Pull request for inclusion in 4.19 for 9p So when I pull the tag, I get a different message, talking about This tag is the same as 9p-for-4.19 without the two MAINTAINERS patches but I never saw a first version. And it comes from a github address, with a pgp key that I've not seen before, and without me having been told about said maintainership updates. And while the key has a lot of signatures, none of them are any that I have recognized previously from kernel development. I'm sure it's all ok, but honestly, there's no way I can pull this without a bit more clarification. Linus
Linus Torvalds wrote on Fri, Aug 17, 2018: > So this pull request confuses me, and that's not a good thing. I'll hopefully do better next time! Thank you for taking the time to explain. > On Thu, Aug 16, 2018 at 7:33 PM Dominique Martinet > <asmadeus@codewreck.org> wrote: > > > > Pull request for inclusion in 4.19 for 9p > > So when I pull the tag, I get a different message, talking about > > This tag is the same as 9p-for-4.19 without the two MAINTAINERS patches > > but I never saw a first version. I thought the the same thing (that you never saw the first version) when I wrote the request-pull email and adjusted the text -- I wasn't aware the tag should have the same text as the mail but will pay attention to that in the future, it does make sense. For the background, I had used 9p-for-4.19 in a mail to v9fs-developer asking for testing earlier this week, it is still in the repo as another signed tag if you'd like to confirm. I removed the "MAINTAINERS patches" when Andrew picked them up shortly after the original mail and made the second tag back then. > And it comes from a github address, with a pgp key that I've not seen > before, and without me having been told about said maintainership > updates. And while the key has a lot of signatures, none of them are > any that I have recognized previously from kernel development. I agree on this point, and will have a different key with at least some kernel developers signatures for 4.20 (which will be confusing again as my key changes, but at least it shold have people you recognize). I cannot say anything other than "I was not sufficiently prepared" for 4.19 and used whatever key I normally use after checking on pathfinder that it was still "closeish" to you. On the maintainership update, while it wasn't direct I believe Andrew brought it up when adding me to the Cc of a 9p security report after you added the current maintainers recently -- but, well, yes, it's not like being told directly. He has the MAINTAINER file update and am sure will send it to you shortly so if preferable I can wait until he sends them to you and send this PR (with a better tag) again at this point? Thank you,
On Fri, Aug 17, 2018 at 2:37 PM Dominique Martinet <asmadeus@codewreck.org> wrote: > > I thought the the same thing (that you never saw the first version) when > I wrote the request-pull email and adjusted the text -- I wasn't aware > the tag should have the same text as the mail but will pay attention to > that in the future, it does make sense. The tag doesn't have to have the same text, it's just that when you send it to me, and I get a message saying "this is the second version", and I haven't seen a first one, that makes me go "Hmm." > > And it comes from a github address, with a pgp key that I've not seen > > before, and without me having been told about said maintainership > > updates. And while the key has a lot of signatures, none of them are > > any that I have recognized previously from kernel development. > > I agree on this point, and will have a different key with at least some > kernel developers signatures for 4.20 I don't reall yneed to absolutely have some signature chain for the keys - but I do want to know that it's not some maintainership fight brewing, and I'd *really* like to see explicit acknowledgement from people about this all. The pgp signature is useful even without the chain of other people signing it, since it's still going to mean (going forward) that the same person who controls the key is sending me pull requests. So it's worth it even without the absolute chain. But the first time I pull is special. For me, the MAINTAINERS file currently still says [torvalds@i7 linux]$ ./scripts/get_maintainer.pl fs/9p/ Eric Van Hensbergen <ericvh@gmail.com> (maintainer:9P FILE SYSTEM) Ron Minnich <rminnich@sandia.gov> (maintainer:9P FILE SYSTEM) Latchesar Ionkov <lucho@ionkov.net> (maintainer:9P FILE SYSTEM) v9fs-developer@lists.sourceforge.net (open list:9P FILE SYSTEM) linux-kernel@vger.kernel.org (open list) and I realize that in practice it's been not very maintained and most of the patches have just been going through Andrew (actually, _most_ patches haven't really been about 9p at all, but have been about updating 9p for non-9p work). So I would basically want to see Andrew and/or others be on record of saying "yup, this looks good, go ahead and pull from Dominique". Then, next time you send me a pull request, it will be "all systems normal", and I won't care about who has signed your key, I'll care a lot more about "it's the same key as the last time, or at least the new key is signed by the old key I already recognize for 9p". That's the main issue for me. Linus
On Fri, 17 Aug 2018 15:35:15 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > So I would basically want to see Andrew and/or others be on record of > saying "yup, this looks good, go ahead and pull from Dominique". Please do. I'll actually be sending you the MAINTAINERS update in about 55 seconds.
On Fri, Aug 17, 2018 at 3:41 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > Please do. I'll actually be sending you the MAINTAINERS update in > about 55 seconds. Heh. Ok, that resolves my biggest issue with the pull request. Linus
On Fri, Aug 17, 2018 at 4:41 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Fri, Aug 17, 2018 at 3:41 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > Please do. I'll actually be sending you the MAINTAINERS update in > > about 55 seconds. > > Heh. Ok, that resolves my biggest issue with the pull request. .. and with that patch-bomb from Andrew out of the way, I've now merged the 9p pull request. It's going through my basic build tests before I push it out, but expect that in minutes. Linus
Hi Linus, 9p has seen some recent surge of activity recently and I've stepped up to help maintaining 9p; please let me know if there are things to improve in how I do things. In particular, the gpg key I used to sign the tag is getting rather old (1024 bit dsa is considered weak nowadays) and I will have a newer key ready for 4.20, but I didn't think I would be able to gather signatures for 4.19 so went for this one for now. Sorry for that. I've rebased the branch at the start of the week to add some stable Cc but all the patches have been in linux-next for two weeks, and all transports have been tested since the rebase (thanks to Stefano Stabellini for xen!) The following changes since commit 94710cac0ef4ee177a63b5227664b38c95bbf703: Linux 4.18 (2018-08-12 13:41:04 -0700) are available in the Git repository at: git://github.com/martinetd/linux tags/9p-for-4.19-2 for you to fetch changes up to edcd9d977354304cb85aee61c2b96809edce41ed: net/9p/trans_virtio.c: add null terminal for mount tag (2018-08-13 09:34:58 +0900) ---------------------------------------------------------------- Pull request for inclusion in 4.19 for 9p Contains mostly fixes (6 to be backported to stable) and a few changes, here is the breakdown: * Rework how fids are attributed by replacing some custom tracking in a list by an idr (f28cdf0430fc) * For packet-based transports (virtio/rdma) validate that the packet length matches what the header says (f984579a01d8) * A few race condition fixes found by syzkaller (9f476d7c540c, 430ac66eb4c5) * Missing argument check when NULL device is passed in sys_mount (10aa14527f45) * A few virtio fixes (23cba9cbde0b, 31934da81036, d28c756caee6) * Some spelling and style fixes ---------------------------------------------------------------- Chirantan Ekbote (1): 9p/net: Fix zero-copy path in the 9p virtio transport Colin Ian King (1): fs/9p/v9fs.c: fix spelling mistake "Uknown" -> "Unknown" Jean-Philippe Brucker (1): net/9p: fix error path of p9_virtio_probe Matthew Wilcox (4): 9p: Fix comment on smp_wmb 9p: Change p9_fid_create calling convention 9p: Replace the fidlist with an IDR 9p: Embed wait_queue_head into p9_req_t Souptick Joarder (1): fs/9p/vfs_file.c: use new return type vm_fault_t Stephen Hemminger (1): 9p: fix whitespace issues Tomas Bortoli (5): net/9p/client.c: version pointer uninitialized net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree() net/9p/trans_fd.c: fix race by holding the lock 9p: validate PDU length 9p: fix multiple NULL-pointer-dereferences jiangyiwen (2): net/9p/virtio: Fix hard lockup in req_done 9p/virtio: fix off-by-one error in sg list bounds check piaojun (5): net/9p/client.c: add missing '\n' at the end of p9_debug() 9p/net/protocol.c: return -ENOMEM when kmalloc() failed net/9p/trans_virtio.c: fix some spell mistakes in comments fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed net/9p/trans_virtio.c: add null terminal for mount tag fs/9p/v9fs.c | 2 +- fs/9p/vfs_file.c | 2 +- fs/9p/xattr.c | 6 ++- include/net/9p/client.h | 11 ++--- net/9p/client.c | 119 ++++++++++++++++++++---------------------------- net/9p/protocol.c | 2 +- net/9p/trans_fd.c | 22 ++++++--- net/9p/trans_rdma.c | 4 ++ net/9p/trans_virtio.c | 66 ++++++++++++++++----------- net/9p/trans_xen.c | 3 ++ net/9p/util.c | 1 - 11 files changed, 122 insertions(+), 116 deletions(-)