Re: [PATCH v9 12/13] Documentation: Rename and update intel_rdt_ui.txt to resctrl_ui.txt
On Wed 2018-11-21 20:28:47, Moger, Babu wrote:
> Rename intel_rdt_ui.txt to generic resctrl_ui.txt and update the
> documentation for AMD.
>
> Signed-off-by: Babu Moger
> ---
> Documentation/x86/{intel_rdt_ui.txt => resctrl_ui.txt} | 9
Other filenames in the directory use "-".
Plus, this is not really about _user_interface.
resctl.txt would be a better name.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] Documentation: dev-tools: Fix typos in index.rst
On Thu, 22 Nov 2018 10:34:56 -0500 Shreyans Devendra Doshi <0xinfosec...@gmail.com> wrote: > Fixes a spelling error and removes an extra whitespace character. > > Signed-off-by: Shreyans Devendra Doshi <0xinfosec...@gmail.com> I've applied this for the typo fix, but let me echo Willy's comments about the whitespace change. There is no official policy on spaces after periods in kernel documentation, and I have no interest in adding one; I'll not be accepting patches making such changes in the future. Thanks, jon
Re: [PATCH] Documentation: dev-tools: Fix typos in index.rst
On 11/25/18 11:28 AM, Jonathan Corbet wrote: > On Thu, 22 Nov 2018 10:34:56 -0500 > Shreyans Devendra Doshi <0xinfosec...@gmail.com> wrote: > >> Fixes a spelling error and removes an extra whitespace character. >> >> Signed-off-by: Shreyans Devendra Doshi <0xinfosec...@gmail.com> > > I've applied this for the typo fix, but let me echo Willy's comments about > the whitespace change. There is no official policy on spaces after > periods in kernel documentation, and I have no interest in adding one; > I'll not be accepting patches making such changes in the future. Ack that. thanks, -- ~Randy
Re: [PATCH v2 1/2] Documentation/admin-guide: introduce perf-security.rst file
On Wed, 21 Nov 2018 12:14:14 +0300 Alexey Budankov wrote: > +For the purpose of performing security checks Linux implementation splits > +processes into two categories [6]_ : a) privileged processes (whose effective > +user ID is 0, referred to as superuser or root), and b) unprivileged > processes > +(whose effective UID is nonzero). Is that really what's going on here? If I understand things correctly, it's looking for CAP_SYS_PTRACE rather than a specific UID; am I missing something here? (Also, you would want "*the* Linux implementation" in the first sentence above). One other thing: > +(whose effective UID is nonzero). Privileged processes bypass all kernel > +security permission checks so perf_events performance monitoring is fully > +available to privileged processes without *access*, *scope* and *resource* > +restrictions. Could I ask for a slight toning down of the markup here? There's a lot of *emphasis* here that isn't really needed and tends to get in the way. Thanks, jon
Re: [PATCH] Add /proc/pid_generation
On Wed 2018-11-21 18:06:33, Matthew Wilcox wrote: > On Wed, Nov 21, 2018 at 12:38:20PM -0800, Daniel Colascione wrote: > > On Wed, Nov 21, 2018 at 12:31 PM Matthew Wilcox wrote: > > > > > > On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote: > > > > This change adds a per-pid-namespace 64-bit generation number, > > > > incremented on PID rollover, and exposes it via a new proc file > > > > /proc/pid_generation. By examining this file before and after /proc > > > > enumeration, user code can detect the potential reuse of a PID and > > > > restart the task enumeration process, repeating until it gets a > > > > coherent snapshot. > > > > > > > > PID rollover ought to be rare, so in practice, scan repetitions will > > > > be rare. > > > > > > Then why does it need to be 64-bit? > > > > [Resending because of accidental HTML. I really need to switch to a > > better email client.] > > > > Because 64 bits is enough for anyone. :-) A u64 is big enough that > > we'll never observe an overflow on a running system, and PID > > namespaces are rare enough that we won't miss the four extra bytes we > > use by upgrading from a u32. And after reading about some security > > problems caused by too-clever handling of 32-bit rollover, I'd rather > > the code be obviously correct than save a trivial amount of space. > > I don't think you understand how big 4 billion is. If it happens once a > second, it will take 136 years for a 2^32 count to roll over. How often > does a PID roll over happen? Well, the cost of 64-bit vs. 32-bit is really small here... I'd go with 64bits. If you have 1000 CPUs, rollovers may be faster.. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 1/1] scripts/kernel-doc: Fix struct and struct field attribute processing
On Thu, 22 Nov 2018 13:06:04 +0200 Sakari Ailus wrote: > The kernel-doc attempts to clear the struct and struct member attributes > from the API documentation it produces. It falls short of the job in the > following respects: > > - extra whitespaces are left where __attribute__((...)) was removed, > > - only a single attribute is removed per struct, > > - attributes (such as aligned) containing numbers were not removed, > > - attributes are only cleared from struct fields, not structs themselves. > > This patch addresses these issues by removing the attributes. > > Signed-off-by: Sakari Ailus That does indeed seem to improve things. I'm waiting for the pile of regexes to fall over and hurt somebody, but I guess we're not there yet. Applied, thanks. jon
