On Wed, 12 Apr 2017, Greg KH wrote: > On Tue, Apr 11, 2017 at 12:41:27PM -0400, Martin Brandenburg wrote: > > From: Mike Marshall <hubcap@xxxxxxxxxxxx> > > > > commit 05973c2efb40122f2a9ecde2d065f7ea5068d024 upstream. > > > > This patch is simlar to one Dan Carpenter sent me, cleans > > up some return codes and whitespace errors. There was one > > place where he thought inserting an error message into > > the ring buffer might be too chatty, I hope I convinced him > > othewise. As a consolation <g> I changed a truly chatty > > error message in another location into a debug message, > > system-admins had already yelled at me about that one... > > > > Signed-off-by: Mike Marshall <hubcap@xxxxxxxxxxxx> > > > > I have removed the return code and whitespace fixes as they do not cause > > a real bug. I keep the removal of an error message. This error shows > > up when a process dies before the OrangeFS userspace client responds. > > This happens all the time on production systems and fills up the ring > > buffer. > > No, please keep patches identical to what is in Linus's tree. That way > you don't mess something up, and any future patches over the next 2+ > years the kernel tree will be around apply cleanly. > > Almost every single time we "modify" a patch from what is in Linus's > tree it is broken. > > I've taken the original patch here for 4.9 and 4.10 stable trees. I based that on this line in stable-kernel-rules.rst - It cannot contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc). but I do see your point. Does that just mean pure trivial patches are inappropriate, but that if one or two trivial changes comes part and parcel with a more significant patch it should be kept? (Honestly what I removed are slightly more than trivial whitespace, though I wouldn't have sent them on their own if they didn't come with the logging change.) Martin > > thanks, > > greg k-h >
