Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted because UEFI/BIOS does not run with SME active. In order to access > this data properly it needs to be mapped decrypted. > > The early_memremap()

Re: [PATCH v5 14/32] efi: Add an EFI table address match function

On Tue, Apr 18, 2017 at 04:18:48PM -0500, Tom Lendacky wrote: > Add a function that will determine if a supplied physical address matches > the address of an EFI table. > > Signed-off-by: Tom Lendacky > --- > drivers/firmware/efi/efi.c | 33

Re: [PATCH 00/17] convert/reorganize Documentation/security/

On Mon, May 15, 2017 at 10:26 AM, Jonathan Corbet wrote: > On Sat, 13 May 2017 04:51:36 -0700 > Kees Cook wrote: > >> This ReSTifies everything under Documentation/security/, and reorganizes >> some of it (mainly the LSMs) under /admin-guide/ per Jon's

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

Em Mon, 15 May 2017 13:49:19 +0200 Peter Zijlstra escreveu: > On Mon, May 15, 2017 at 01:29:58PM +0300, Jani Nikula wrote: > > On Mon, 15 May 2017, Peter Zijlstra wrote: > > > The intention is to aid readability. Making comments worse so that some >

Re: [PATCH 06/17] doc: security: minor cleanups to build kernel-doc

On Mon, 15 May 2017 09:17:25 +1000 (AEST) James Morris wrote: > On Sat, 13 May 2017, Kees Cook wrote: > > > These fixes were needed to parse lsm_hooks.h kernel-doc. More work is > > needed, but this is the first step. > > > > Cc: Casey Schaufler > >

Re: [PATCH 0/5] Convert more books to ReST

On Mon, 15 May 2017 14:09:12 +0200 Boris Brezillon wrote: > > mtd: adjust kernel-docs to avoid Sphinx/kerneldoc warnings > > Not sure how you plan to merge these changes, but if it goes through > a single tree I'll probably need an immutable topic branch,

Re: [PATCH 01/36] docs-rst: convert kernel-hacking to ReST

On Fri, 12 May 2017 10:59:44 -0300 Mauro Carvalho Chehab wrote: > Documentation/DocBook/Makefile|2 +- > Documentation/DocBook/kernel-hacking.tmpl | 1312 > - > Documentation/conf.py |2 + >

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, May 15, 2017 at 01:49:19PM +0200, Peter Zijlstra wrote: > On Mon, May 15, 2017 at 01:29:58PM +0300, Jani Nikula wrote: > > On Mon, 15 May 2017, Peter Zijlstra wrote: > > > The intention is to aid readability. Making comments worse so that some > > > retarded script

Re: [PATCH 21/36] fs: locks: Fix some troubles at kernel-doc comments

On Sat, May 13, 2017 at 06:14:06AM -0300, Mauro Carvalho Chehab wrote: > Hi Jeff, > > Em Fri, 12 May 2017 10:02:56 -0400 > Jeff Layton escreveu: > > > On Fri, 2017-05-12 at 11:00 -0300, Mauro Carvalho Chehab wrote: > > > There are a few syntax violations that cause

Re: [PATCH 06/17] doc: security: minor cleanups to build kernel-doc

On Sun, May 14, 2017 at 5:00 PM, Casey Schaufler wrote: > On 5/13/2017 4:51 AM, Kees Cook wrote: >> These fixes were needed to parse lsm_hooks.h kernel-doc. More work is >> needed, but this is the first step. >> >> Cc: Casey Schaufler >>

Re: [PATCH 13/17] doc: ReSTify Smack.txt

On 5/13/2017 4:51 AM, Kees Cook wrote: > Adjusts for ReST markup and moves under LSM admin guide. > > Cc: Casey Schaufler > Signed-off-by: Kees Cook Acked-by: Casey Schaufler Thank you. > --- > .../Smack.txt =>

Re: [PATCH] mm, docs: update memory.stat description with workingset* entries

On Thu, May 11, 2017 at 08:18:13PM +0100, Roman Gushchin wrote: > Commit 4b4cea91691d ("mm: vmscan: fix IO/refault regression in > cache workingset transition") introduced three new entries in memory > stat file: > - workingset_refault, > - workingset_activate, > -

[PATCH 5/6] Documentation: howto: Remove outdated info about bugzilla mailing lists

The mailing list archives[1,2] show no activity since September 2011. [1]: https://lists.linuxfoundation.org/pipermail/bugme-new/ [2]: https://lists.linuxfoundation.org/pipermail/bugme-janitors/ Signed-off-by: Jonathan Neuschäfer --- Documentation/process/howto.rst | 8

[PATCH 4/6] Documentation: Remove outdated info about -git patches

Since the 3.2 cycle, there were no -git patches/tarballs on kernel.org. Signed-off-by: Jonathan Neuschäfer --- Documentation/process/applying-patches.rst | 40 +- Documentation/process/howto.rst| 9 --- 2 files changed, 1

[PATCH 3/6] Documentation: kernel-docs: Remove "Here is its" at the end of lines

Before commit 9e03ea7f683e ("Documentation/kernel-docs.txt: convert it to ReST markup"), it read: Description: Linux Journal Kernel Korner article. Here is its abstract: "..." In Sphinx' HTML formatting, however, the "Here is its" doesn't make sense anymore, because the "Abstract:"

[PATCH 2/6] Documentation: kernel-docs: Move vfs.txt under "Docs at the Linux Kernel tree"

It's unneccessary to point to an external mirror of the Documentation directory. Also, drop the date field, because in-kernel documentation is continually updated. Signed-off-by: Jonathan Neuschäfer --- Documentation/process/kernel-docs.rst | 23 +++ 1

[PATCH 6/6] Documentation: mono: Update links and s/CVS/Git/

The old URLs redirect to the new ones, so just update them in mono.rst. Signed-off-by: Jonathan Neuschäfer --- Documentation/admin-guide/mono.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/mono.rst

[PATCH 1/6] Documentation: coding-style: Escape \n\t to fix HTML rendering

Without this patch, Sphinx renders the sentence as follows, thus hiding the backslashes: [...] end each string except the last with nt to properly indent the next instruction [...] Signed-off-by: Jonathan Neuschäfer ---

[RFC PATCH v2 02/17] cgroup: add @flags to css_task_iter_start() and implement CSS_TASK_ITER_PROCS

From: Tejun Heo css_task_iter currently always walks all tasks. With the scheduled cgroup v2 thread support, the iterator would need to handle multiple types of iteration. As a preparation, add @flags to css_task_iter_start() and implement CSS_TASK_ITER_PROCS. If the flag is

[RFC PATCH v2 04/17] cgroup: implement CSS_TASK_ITER_THREADED

From: Tejun Heo cgroup v2 is in the process of growing thread granularity support. Once thread mode is enabled, the root cgroup of the subtree serves as the proc_cgrp to which the processes of the subtree conceptually belong and domain-level resource consumptions not tied to any

[RFC PATCH v2 01/17] cgroup: reorganize cgroup.procs / task write path

From: Tejun Heo Currently, writes "cgroup.procs" and "cgroup.tasks" files are all handled by __cgroup_procs_write() on both v1 and v2. This patch reoragnizes the write path so that there are common helper functions that different write paths use. While this somewhat increases

[RFC PATCH v2 03/17] cgroup: introduce cgroup->proc_cgrp and threaded css_set handling

From: Tejun Heo cgroup v2 is in the process of growing thread granularity support. Once thread mode is enabled, the root cgroup of the subtree serves as the proc_cgrp to which the processes of the subtree conceptually belong and domain-level resource consumptions not tied to any

[RFC PATCH v2 09/17] cgroup: Keep accurate count of tasks in each css_set

The reference count in the css_set data structure was used as a proxy of the number of tasks attached to that css_set. However, that count is actually not an accurate measure especially with thread mode support. So a new variable task_count is added to the css_set to keep track of the actual task

[RFC PATCH v2 05/17] cgroup: implement cgroup v2 thread support

From: Tejun Heo This patch implements cgroup v2 thread support. The goal of the thread mode is supporting hierarchical accounting and control at thread granularity while staying inside the resource domain model which allows coordination across different resource controllers and

[RFC PATCH v2 06/17] cgroup: Fix reference counting bug in cgroup_procs_write()

The cgroup_procs_write_start() took a reference to the task structure which was not properly released within cgroup_procs_write() and so on. So a put_task_struct() call is added to cgroup_procs_write_finish() to match the get_task_struct() in cgroup_procs_write_start() to fix this reference

[RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file

The debug cgroup currently resides within cgroup-v1.c and is enabled only for v1 cgroup. To enable the debug cgroup also for v2, it makes sense to put the code into its own file as it will no longer be v1 specific. The only change in this patch is the expansion of cgroup_task_count() within the

[RFC PATCH v2 10/17] cgroup: Make debug cgroup support v2 and thread mode

Besides supporting cgroup v2 and thread mode, the following changes are also made: 1) current_* cgroup files now resides only at the root as we don't need duplicated files of the same function all over the cgroup hierarchy. 2) The cgroup_css_links_read() function is modified to report

[RFC PATCH v2 14/17] cgroup: Enable printing of v2 controllers' cgroup hierarchy

This patch add a new debug control file on the cgroup v2 root directory to print out the cgroup hierarchy for each of the v2 controllers. Signed-off-by: Waiman Long --- kernel/cgroup/debug.c | 141 ++ 1 file changed, 141

[RFC PATCH v2 13/17] cgroup: Allow fine-grained controllers control in cgroup v2

For cgroup v1, different controllers can be binded to different cgroup hierarchies optimized for their own use cases. That is not currently the case for cgroup v2 where combining all these controllers into the same hierarchy will probably require more levels than is needed by each individual

[RFC PATCH v2 07/17] cgroup: Prevent kill_css() from being called more than once

The kill_css() function may be called more than once under the condition that the css was killed but not physically removed yet followed by the removal of the cgroup that is hosting the css. This patch prevents any harmm from being done when that happens. Signed-off-by: Waiman Long

[RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

The current thread mode semantics aren't sufficient to fully support threaded controllers like cpu. The main problem is that when thread mode is enabled at root (mainly for performance reason), all the non-threaded controllers cannot be supported at all. To alleviate this problem, the roles of

[RFC PATCH v2 17/17] sched: Make cpu/cpuacct threaded controllers

Make cpu and cpuacct cgroup controllers usable within a threaded cgroup. Signed-off-by: Waiman Long --- kernel/sched/core.c| 1 + kernel/sched/cpuacct.c | 1 + 2 files changed, 2 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b041081..479f69e

[RFC PATCH v2 12/17] cgroup: Remove cgroup v2 no internal process constraint

The rationale behind the cgroup v2 no internal process constraint is to avoid resouorce competition between internal processes and child cgroups. However, not all controllers have problem with internal process competiton. Enforcing this rule may lead to unnatural process hierarchy and unneeded

[RFC PATCH v2 15/17] sched: Misc preps for cgroup unified hierarchy interface

From: Tejun Heo Make the following changes in preparation for the cpu controller interface implementation for the unified hierarchy. This patch doesn't cause any functional differences. * s/cpu_stats_show()/cpu_cfs_stats_show()/ * s/cpu_files/cpu_legacy_files/ * Separate out

[RFC PATCH v2 16/17] sched: Implement interface for cgroup unified hierarchy

From: Tejun Heo While the cpu controller doesn't have any functional problems, there are a couple interface issues which can be addressed in the v2 interface. * cpuacct being a separate controller. This separation is artificial and rather pointless as demonstrated by most

[RFC PATCH v2 00/17] cgroup: Major changes to cgroup v2 core

v1->v2: - Add a new pass-through mode to allow each controller its own unique virtual hierarchy. - Add a new control file "cgroup.resource_control" to enable the user creation of separate control knobs for internal process anywhere in the v2 hierarchy instead of doing that

Re: [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing

On 05/14/2017 06:30 PM, Chris Packham wrote: When enabled temperature smoothing allows ramping the fan speed over a configurable period of time instead of jumping to the new speed instantaneously. Signed-off-by: Chris Packham Applied to -next. --- Changes

Re: [PATCH v4 1/3] hwmon: (adt7475) fan stall prevention

On 05/14/2017 06:30 PM, Chris Packham wrote: By default adt7475 will stop the fans (pwm duty cycle 0%) when the temperature drops past Tmin - hysteresis. Some systems want to keep the fans moving even when the temperature drops so add new sysfs attributes that configure the enhanced acoustics

Re: [PATCH 24/36] fs: jbd2: escape a string with special chars on a kernel-doc

On Fri 12-05-17 11:00:07, Mauro Carvalho Chehab wrote: > kernel-doc will try to interpret a foo() string, except if > properly escaped. > > Signed-off-by: Mauro Carvalho Chehab Looks good. You can add: Reviewed-by: Jan Kara

Re: [PATCH 19/36] fs: jbd2: make jbd2_journal_start() kernel-doc parseable

On Fri 12-05-17 11:00:02, Mauro Carvalho Chehab wrote: > kernel-doc script expects that a function documentation to > be just before the function, otherwise it will be ignored. > > So, move the kernel-doc markup to the right place. > > Signed-off-by: Mauro Carvalho Chehab

Re: [PATCH 0/5] Convert more books to ReST

On Sat, 13 May 2017 08:10:53 -0300 Mauro Carvalho Chehab wrote: > This patch series convert the following books to ReST: > - librs > - mtdnand > - sh > > And it is based on my previous series of conversion patches. > > After this series, there will

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, 15 May 2017, Peter Zijlstra wrote: > On Mon, May 15, 2017 at 01:29:58PM +0300, Jani Nikula wrote: >> On Mon, 15 May 2017, Peter Zijlstra wrote: >> > The intention is to aid readability. Making comments worse so that some >> > retarded script

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, May 15, 2017 at 01:29:58PM +0300, Jani Nikula wrote: > On Mon, 15 May 2017, Peter Zijlstra wrote: > > The intention is to aid readability. Making comments worse so that some > > retarded script can generate better html or whatnot is just that, > > retarded. > > > >

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, 15 May 2017, Peter Zijlstra wrote: > The intention is to aid readability. Making comments worse so that some > retarded script can generate better html or whatnot is just that, > retarded. > > Code matters, generated documentation not so much. I'll take a comment >

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, May 15, 2017 at 06:00:46AM -0300, Mauro Carvalho Chehab wrote: > > Well, I don't mind the '-' thing before return values too much, but the > > below chunk is just pure drivel. It makes a perfectly good comment > > worse. > > > > --- a/kernel/locking/mutex.c > > +++

Re: [PATCH 10/13] sound: fix the comments that refers to kernel-doc

On Sun, 14 May 2017 17:38:44 +0200, Mauro Carvalho Chehab wrote: > > The markup inside the #if 0 comment actually refers to a > kernel-doc markup. As we're getting rid of DocBook update it. > > Signed-off-by: Mauro Carvalho Chehab I guess you prefer taking it from

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

Em Mon, 15 May 2017 09:03:48 +0200 Peter Zijlstra escreveu: > On Fri, May 12, 2017 at 03:19:17PM -0700, Darren Hart wrote: > > On Sat, May 13, 2017 at 12:11:09AM +0200, Peter Zijlstra wrote: > > > > And I really _really_ hate to see that rest crap spread here. Can't we >

Re: [PATCH 28/36] docs-rst: convert s390-drivers DocBook to ReST

On Fri, 12 May 2017 11:00:11 -0300 Mauro Carvalho Chehab wrote: > Use pandoc to convert documentation to ReST by calling > Documentation/sphinx/tmplcvt script. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/DocBook/Makefile

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Fri, May 12, 2017 at 03:19:17PM -0700, Darren Hart wrote: > On Sat, May 13, 2017 at 12:11:09AM +0200, Peter Zijlstra wrote: > > And I really _really_ hate to see that rest crap spread here. Can't we > > just delete all that nonsense and go back to 80 column 7bit ASCII ? > > > > Depending on