9 ms·
The latest patch adds a null check around a call to gss_release_msg. The commit message says “ The patch adds a check to avoid a potential double free.” Accord
by shash 5y ago
The latest patch adds a null check around a call to gss_release_msg. The commit message says “ The patch adds a check to avoid a potential double free.”
According to other people in the conversation, this is already taken care of by reference counting (https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fieldses.org/#t https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fie... ) and the patch apparently does nothing. The commit doesn’t reference any specific tool they’re using, or any bug they faced.
Looks innocuous, but I guess past behaviour from this group left enough of a bad taste for Greg KH to be suspicious.
- StefanKarpinski 5y agoA later message claims (outraged at being accused of submitting intentionally broken code to the kernel, despite having previously done exactly that) that the patch was generated by a static analysis tool. Ok, what tool? How did you run it? The message where he claims this has since been deleted (by who? Edit: probably never sent to the list, see below) but here is a message from Greg KH which quotes it: https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/#r https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah... You can see that Greg KH is skeptical that the patch was generated by a tool. It’s also unclear to me if the patch is actually harmless or not. It would be good to get some definitive clarity on that but the lkml discussion of it seems inconclusive. I would add that the student’s tone in this message feels really familiar as an open source maintainer: this is the tone of someone doing something they know is bad being called out on it and trying to deflect with outrage. The last time I got that tone, it was someone who had created multiple sock puppet accounts to try to discredit my project and force moderators to reverse or apologize for a (completely justified and mild) moderation action. So I can’t help but feel that something fishy is going on here and the UMN research group still isn’t being honest about it.
- kam 5y agoMy understanding is that the "not found" messages were never archived, rather than deleted. Likely they were not CC'd to the list, and the replies added the list back to CC.
- StefanKarpinski 5y agoThanks for explaining that!
- cygx 5y agoCf https://lore.kernel.org/linux-nfs/YIUMYYcf%2FVW4a28k@kroah.com/ https://lore.kernel.org/linux-nfs/YIUMYYcf%2FVW4a28k@kroah.c... Apparently, they sent html mails, which the list refuses to deliver.
- denton-scratch 5y agoMy experience of GKH's work isn't generally very favourable; but my estination of him has been increased by this repair. He's created work for himself, but it needed doing. Credit where it's due.
- ufmace 5y ago> Looks innocuous, but I guess past behaviour from this group left enough of a bad taste for Greg KH to be suspicious. The idea of the kind of research they previously did is to submit patch requests with some kind of trick or hidden agenda first, then do some analysis of the results, and then later on publish a paper explaining what they did. Now here they are again submitting a weird looking and seemingly poorly conceived patch. Who knows what they're really doing? Perhaps they're working on some kind of new paper, with who know what purpose. Maybe they'd find out in 6 months. Maybe it's a failed line of research similar to the previous ones which they won't actually publish. Or maybe they just have no idea what they're doing. Either way, it seems like a waste of time at best. The mass ban and revert sounds like an appropriate move.