Re: [PATCH] SUNRPC: Add a check for gss_release_msg

From: Leon Romanovsky
Date: Wed Apr 21 2021 - 10:12:46 EST


On Wed, Apr 21, 2021 at 03:50:58PM +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> On Wed, Apr 21, 2021 at 04:34:00PM +0300, Leon Romanovsky wrote:
> > On Wed, Apr 21, 2021 at 03:21:15PM +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> > > On Wed, Apr 21, 2021 at 01:11:03PM +0000, Trond Myklebust wrote:
> > > > On Wed, 2021-04-21 at 15:19 +0300, Leon Romanovsky wrote:
> > > > > On Wed, Apr 21, 2021 at 11:58:08AM +0000, Shelat, Abhi wrote:
> > > > > > > >
> > > > > > > > > > They introduce kernel bugs on purpose. Yesterday, I took a
> > > > > > > > > > look on 4
> > > > > > > > > > accepted patches from Aditya and 3 of them added various
> > > > > > > > > > severity security
> > > > > > > > > > "holes".
> > > > > > > > >
> > > > > > > > > All contributions by this group of people need to be
> > > > > > > > > reverted, if they
> > > > > > > > > have not been done so already, as what they are doing is
> > > > > > > > > intentional
> > > > > > > > > malicious behavior and is not acceptable and totally
> > > > > > > > > unethical.  I'll
> > > > > > > > > look at it after lunch unless someone else wants to do it…
> > > > > > > >
> > > > > >
> > > > > > <snip>
> > > > > >
> > > > > > Academic research should NOT waste the time of a community.
> > > > > >
> > > > > > If you believe this behavior deserves an escalation, you can
> > > > > > contact the Institutional Review Board (irb@xxxxxxx) at UMN to
> > > > > > investigate whether this behavior was harmful; in particular,
> > > > > > whether the research activity had an appropriate IRB review, and
> > > > > > what safeguards prevent repeats in other communities.
> > > > >
> > > > > The huge advantage of being "community" is that we don't need to do
> > > > > all
> > > > > the above and waste our time to fill some bureaucratic forms with
> > > > > unclear
> > > > > timelines and results.
> > > > >
> > > > > Our solution to ignore all @umn.edu contributions is much more
> > > > > reliable
> > > > > to us who are suffering from these researchers.
> > > > >
> > > >
> > > > <shrug>That's an easy thing to sidestep by just shifting to using a
> > > > private email address.</shrug>
> > >
> > > If they just want to be jerks, yes. But they can't then use that type
> > > of "hiding" to get away with claiming it was done for a University
> > > research project as that's even more unethical than what they are doing
> > > now.
> > >
> > > > There really is no alternative for maintainers other than to always be
> > > > sceptical of patches submitted by people who are not known and trusted
> > > > members of the community, and to scrutinise those patches with more
> > > > care.
> > >
> > > Agreed, and when we notice things like this that were determined to be
> > > bad, we have the ability to easily go back and rip the changes out and
> > > we can slowly add them back if they are actually something we want to
> > > do.
> > >
> > > Which is what I just did:
> > > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@xxxxxxxxxxxxxxxxxxx/
> >
> > Greg,
> >
> > Did you push your series to the public git? I would like to add you a
> > couple of reverts.
>
> Yes, it can be found here:
> git@xxxxxxxxxxxxxxxxxxx:/pub/scm/linux/kernel/git/gregkh/driver-core.git umn.edu-reverts
>
> You can send reverts in email if you want, whatever works best.
>
> > And do you have a list of not reverted commits? It will save us from
> > doing same comparison of reverted/not reverted over and over.
>
> Below is the list that didn't do a simple "revert" that I need to look
> at. I was going to have my interns look into this, there's no need to
> bother busy maintainers with it unless you really want to, as I can't
> tell anyone what to work on :)

Ohh, you have interns, so even better.

Thanks

>
> thanks,
>
> greg k-h
>
> -------------------------
> # commits that need to be looked at as a clean revert did not work
> 990a1162986e
> 58d0c864e1a7
> a068aab42258
> 8816cd726a4f
> c705f9fc6a17
> 8b6fc114beeb
> 169f9acae086
> 8da96730331d
> f4f5748bfec9
> e08f0761234d
> cb5173594d50
> 06d5d6b7f994
> d9350f21e5fe
> 6f0ce4dfc5a3
> f0d14edd2ba4
> 46953f97224d
> 3c77ff8f8bae
> 0aab8e4df470
> 8e949363f017
> f8ee34c3e77a
> fd21b79e541e
> 766460852cfa
> 41f00e6e9e55
> 78540a259b05
> 208c6e8cff1b
> 7ecced0934e5
> 48f40b96de2c
> 9aabb68568b4
> 2cc12751cf46
> 534c89c22e26
> 6a8ca24590a2
> d70d70aec963
> d7737d425745
> 3a10e3dd52e8
> d6cb77228e3a
> 517ccc2aa50d
> 07660ca679da
> 0fff9bd47e13
> 6ade657d6125
> 2795e8c25161
> 4ec850e5dfec
> 035a14e71f27
> 10010493c126
> 4280b73092fe
> 5910fa0d0d98
> 40619f7dd3ef
> 0a54ea9f481f
> 44fabd8cdaaa
> 02cc53e223d4
> c99776cc4018
> 7fc93f3285b1
> 6ae16dfb61bc
> 9c6260de505b
> eb8950861c1b
> 46273cf7e009
> 89dfd0083751
> c9c63915519b
> cd07e3701fa6
> 15b3048aeed8
> 7172122be6a4
> 47db7873136a
> 58f5bbe331c5
> 6b995f4eec34
> 8af03d1ae2e1
> f16b613ca8b3
> 6009d1fe6ba3
> 8e03477cb709
> dc487321b1e6