linux-kernel - Re: [PATCH] x86_64 ia32 syscall restart fix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Feb 2008 14:42:12 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86_64 ia32 syscall restart fix

And here I thought I was so good for using coherent English sentences
with proper punctuation and capitalization, not to mention actually
explaining the issues of the change.  I must admit I've been a little
bewildered in the past when Ingo has changed my log entries to be
ungrammatical, eschew standard punctuation, and with an apparent
vendetta on the shift key, not to mention sometimes removed half the
relevant technical detail to boot.

I suppose I shouldn't be surprised at being harangued for making my log
entries too informative.  People love to remove clauses out of the
middle of my code comments too--so they can match the norm of run-on
sentences, I guess.

Most log entries I see are short.  But they really don't explain the
problem being fixed so I know enough about it without digging out some
long mailing list threads.  If that's your preference, then I guess we'll
just have to keep having Ingo remove the text I write.  At least it will
be in the archives from my posting.  (Reading it is the only way I'll
remember myself what details mattered, after a week has gone by.)

If what you want is formulaic log text that always puts blank lines in
between bug description, change description, and change justification, I
can do that.  If there is any place that documents the conventions you
want in log entries, I've overlooked it.

As Ingo alluded to, most of the time my number one focus is to record all
the important facts and decisions before I go back to something else or
knock off for the night.  I hate nothing more than looking at an old
change of mine and not being able to figure out what some of the logic
behind it was.  If there's one thing I can rely on, it's that I'll forget
what I knew the first time until I spend hours the second time
recapitulating the same debugging to find out that I may have had some
sense after all six months back.

Anyway, if the worst push-back on my submissions is a handful
of foreigners telling me how to write English, then I guess
things are ... as they should be. ;-)

As to the question of tagging for backports, I am not really clear on
what the intended criteria are.  Take this bug for example.  It is a
consistent behavior that has existed since the dawn of time (I've only
actually checked back to 2.6.9).  It's wrong, but can't be a surprise
on any system based on a stable release.  It's a regression of the
64-bit kernel vs the native 32-bit kernel, but not a version-to-version
regression.  The fix is straightforward to backport and has very low
risk.  How does all that translate into whether a given stable version
wants a backport or not?

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/