* [PATCH v2] Allow to exclude specific file types in LoadPin
From: Ke Wu @ 2019-05-30 19:22 UTC (permalink / raw)
To: Kees Cook, Jonathan Corbet, James Morris, Serge E. Hallyn
Cc: linux-doc, linux-kernel, linux-security-module, Ke Wu
In-Reply-To: <20190529224350.6460-1-mikewu@google.com>
Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
make sure loaded kernel module and kernel image are trusted. This
patch adds a kernel command line option "loadpin.exclude" which
allows to exclude specific file types from LoadPin. This is useful
when people want to use different mechanisms to verify module and
kernel image while still use LoadPin to protect the integrity of
other files kernel loads.
Signed-off-by: Ke Wu <mikewu@google.com>
---
Changelog since v1:
- Mark ignore_read_file_id with __ro_after_init.
- Mark parse_exclude() with __init.
- Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
Documentation/admin-guide/LSM/LoadPin.rst | 10 ++++++
security/loadpin/loadpin.c | 38 +++++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
index 32070762d24c..716ad9b23c9a 100644
--- a/Documentation/admin-guide/LSM/LoadPin.rst
+++ b/Documentation/admin-guide/LSM/LoadPin.rst
@@ -19,3 +19,13 @@ block device backing the filesystem is not read-only, a sysctl is
created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
a mutable filesystem means pinning is mutable too, but having the
sysctl allows for easy testing on systems with a mutable filesystem.)
+
+It's also possible to exclude specific file types from LoadPin using kernel
+command line option "``loadpin.exclude``". By default, all files are
+included, but they can be excluded using kernel command line option such
+as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
+different mechanisms such as ``CONFIG_MODULE_SIG`` and
+``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
+still use LoadPin to protect the integrity of other files kernel loads. The
+full list of valid file types can be found in ``kernel_read_file_str``
+defined in ``include/linux/fs.h``.
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 055fb0a64169..d5f064644c54 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -45,6 +45,8 @@ static void report_load(const char *origin, struct file *file, char *operation)
}
static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
+static char *exclude_read_files[READING_MAX_ID];
+static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
static struct super_block *pinned_root;
static DEFINE_SPINLOCK(pinned_root_spinlock);
@@ -129,6 +131,13 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
struct super_block *load_root;
const char *origin = kernel_read_file_id_str(id);
+ /* If the file id is excluded, ignore the pinning. */
+ if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
+ ignore_read_file_id[id]) {
+ report_load(origin, file, "pinning-excluded");
+ return 0;
+ }
+
/* This handles the older init_module API that has a NULL file. */
if (!file) {
if (!enforce) {
@@ -187,10 +196,37 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
};
+static void __init parse_exclude(void)
+{
+ int i, j;
+ char *cur;
+
+ for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
+ cur = exclude_read_files[i];
+ if (!cur)
+ break;
+ if (*cur == '\0')
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(kernel_read_file_str); j++) {
+ if (strcmp(cur, kernel_read_file_str[j]) == 0) {
+ pr_info("excluding: %s\n",
+ kernel_read_file_str[j]);
+ ignore_read_file_id[j] = 1;
+ /*
+ * Can not break, because one read_file_str
+ * may map to more than on read_file_id.
+ */
+ }
+ }
+ }
+}
+
static int __init loadpin_init(void)
{
pr_info("ready to pin (currently %senforcing)\n",
enforce ? "" : "not ");
+ parse_exclude();
security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
return 0;
}
@@ -203,3 +239,5 @@ DEFINE_LSM(loadpin) = {
/* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
module_param(enforce, int, 0);
MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
+module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
+MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* Re: [PATCH 18/22] docs: security: trusted-encrypted.rst: fix code-block tag
From: James Morris @ 2019-05-30 19:43 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mimi Zohar, James Bottomley, Jarkko Sakkinen,
linux-integrity, keyrings
In-Reply-To: <9c8e63bba3c3735573ab107ffd65131db10e1d2e.1559171394.git.mchehab+samsung@kernel.org>
On Wed, 29 May 2019, Mauro Carvalho Chehab wrote:
> The code-block tag is at the wrong place, causing those
> warnings:
>
> Documentation/security/keys/trusted-encrypted.rst:112: WARNING: Literal block expected; none found.
> Documentation/security/keys/trusted-encrypted.rst:121: WARNING: Unexpected indentation.
> Documentation/security/keys/trusted-encrypted.rst:122: WARNING: Block quote ends without a blank line; unexpected unindent.
> Documentation/security/keys/trusted-encrypted.rst:123: WARNING: Block quote ends without a blank line; unexpected unindent.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 2/2] Docs: hwmon: pmbus: Add PXE1610 driver
From: Guenter Roeck @ 2019-05-30 19:44 UTC (permalink / raw)
To: Vijay Khemka
Cc: Jean Delvare, Jonathan Corbet, linux-hwmon@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
joel@jms.id.au, linux-aspeed@lists.ozlabs.org, Sai Dasari,
Greg Kroah-Hartman
In-Reply-To: <27E78CF3-FAE7-4B6F-ABD7-77F4AE1CD633@fb.com>
On Thu, May 30, 2019 at 06:51:52PM +0000, Vijay Khemka wrote:
>
>
> On 5/29/19, 6:05 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
>
> On 5/29/19 3:35 PM, Vijay Khemka wrote:
> > Added support for Infenion PXE1610 driver
> >
> > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > ---
> > Documentation/hwmon/pxe1610 | 84 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 84 insertions(+)
> > create mode 100644 Documentation/hwmon/pxe1610
> >
> > diff --git a/Documentation/hwmon/pxe1610 b/Documentation/hwmon/pxe1610
> > new file mode 100644
> > index 000000000000..b5c83edf027a
> > --- /dev/null
> > +++ b/Documentation/hwmon/pxe1610
> > @@ -0,0 +1,84 @@
> > +Kernel driver pxe1610
> > +=====================
> > +
> > +Supported chips:
> > + * Infinion PXE1610
> > + Prefix: 'pxe1610'
> > + Addresses scanned: -
> > + Datasheet: Datasheet is not publicly available.
> > +
> > + * Infinion PXE1110
> > + Prefix: 'pxe1110'
> > + Addresses scanned: -
> > + Datasheet: Datasheet is not publicly available.
> > +
> > + * Infinion PXM1310
> > + Prefix: 'pxm1310'
> > + Addresses scanned: -
> > + Datasheet: Datasheet is not publicly available.
> > +
> > +Author: Vijay Khemka <vijaykhemka@fb.com>
> > +
> > +
> > +Description
> > +-----------
> > +
> > +PXE1610 is a Multi-rail/Multiphase Digital Controllers and
> > +it is compliant to Intel VR13 DC-DC converter specifications.
> > +
>
> And the others ?
> This supports VR12 as well and I don't see this controller supports any other VR versions.
>
The point here is that there is no description of the other controllers.
> > +
> > +Usage Notes
> > +-----------
> > +
> > +This driver can be enabled with kernel config CONFIG_SENSORS_PXE1610
> > +set to 'y' or 'm'(for module).
> > +
> The above does not really add value.
> Ok, I will remove it.
>
> > +This driver does not probe for PMBus devices. You will have
> > +to instantiate devices explicitly.
> > +
> > +Example: the following commands will load the driver for an PXE1610
> > +at address 0x70 on I2C bus #4:
> > +
> > +# modprobe pxe1610
> > +# echo pxe1610 0x70 > /sys/bus/i2c/devices/i2c-4/new_device
> > +
> > +It can also be instantiated by declaring in device tree if it is
> > +built as a kernel not as a module.
> > +
>
> I assume you mean "built into the kernel".
> Why would devicetree based instantiation not work if the driver is built
> as module ?
> Will correct statement here.
>
> > +
> > +Sysfs attributes
> > +----------------
> > +
> > +curr1_label "iin"
> > +curr1_input Measured input current
> > +curr1_alarm Current high alarm
> > +
> > +curr[2-4]_label "iout[1-3]"
> > +curr[2-4]_input Measured output current
> > +curr[2-4]_crit Critical maximum current
> > +curr[2-4]_crit_alarm Current critical high alarm
> > +
> > +in1_label "vin"
> > +in1_input Measured input voltage
> > +in1_crit Critical maximum input voltage
> > +in1_crit_alarm Input voltage critical high alarm
> > +
> > +in[2-4]_label "vout[1-3]"
> > +in[2-4]_input Measured output voltage
> > +in[2-4]_lcrit Critical minimum output voltage
> > +in[2-4]_lcrit_alarm Output voltage critical low alarm
> > +in[2-4]_crit Critical maximum output voltage
> > +in[2-4]_crit_alarm Output voltage critical high alarm
> > +
> > +power1_label "pin"
> > +power1_input Measured input power
> > +power1_alarm Input power high alarm
> > +
> > +power[2-4]_label "pout[1-3]"
> > +power[2-4]_input Measured output power
> > +
> > +temp[1-3]_input Measured temperature
> > +temp[1-3]_crit Critical high temperature
> > +temp[1-3]_crit_alarm Chip temperature critical high alarm
> > +temp[1-3]_max Maximum temperature
> > +temp[1-3]_max_alarm Chip temperature high alarm
> >
>
>
>
^ permalink raw reply
* [PATCH RFC] Rough draft document on merging and rebasing
From: Jonathan Corbet @ 2019-05-30 19:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, linux-doc
This is a first attempt at following through on last month's discussion
about common merging and rebasing errors. The hope here is to document
existing best practices rather than trying to define new ones. I've
certainly failed somewhere along the way; please set me straight and I'll
try to do better next time.
Thanks,
jon
-------------
docs: Add a document on repository management
Every merge window seems to involve at least one episode where subsystem
maintainers don't manage their trees as Linus would like. Document the
expectations so that at least he has something to point people to.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/maintainer/index.rst | 1 +
Documentation/maintainer/repo-hygiene.rst | 195 ++++++++++++++++++++++
2 files changed, 196 insertions(+)
create mode 100644 Documentation/maintainer/repo-hygiene.rst
diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst
index 2a14916930cb..48c1d56253d8 100644
--- a/Documentation/maintainer/index.rst
+++ b/Documentation/maintainer/index.rst
@@ -10,5 +10,6 @@ additions to this manual.
:maxdepth: 2
configure-git
+ repo-hygiene
pull-requests
diff --git a/Documentation/maintainer/repo-hygiene.rst b/Documentation/maintainer/repo-hygiene.rst
new file mode 100644
index 000000000000..0a738ea51d65
--- /dev/null
+++ b/Documentation/maintainer/repo-hygiene.rst
@@ -0,0 +1,195 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Repository hygiene: rebasing and merging
+========================================
+
+Maintaining a subsystem, as a general rule, requires a familiarity with the
+Git source-code management system. Git is a powerful tool with a lot of
+features; as is often the case with such tools, there are right and wrong
+ways to use those features. This document looks in particular at the use
+of rebasing and merging. Maintainers often get in trouble when they use
+those tools incorrectly, but avoiding problems is not actually all that
+hard.
+
+One thing to be aware of in general is that, unlike many other projects,
+the kernel community is not scared by seeing merge commits in its
+development history. Indeed, given the scale of the project, avoiding
+merges would be nearly impossible. Some problems encountered by
+maintainers results from a desire to avoid merges, while others come from
+merging a little too often.
+
+Rebasing
+========
+
+"Rebasing" is the process of changing the history of a series of commits
+within a repository. At its simplest, a rebase could change the starting
+point of a patch series from one point to another. Other uses include
+fixing (or deleting) broken commits, adding tags to commits, or changing
+the order in which commits are applied. Used properly, rebasing can yield
+a cleaner and clearer development history; used improperly, it can obscure
+that history and introduce bugs.
+
+There are a few rules of thumb that can help developers to avoid the worst
+perils of rebasing:
+
+ - History that has been exposed to the world beyond your private system
+ should not be rebased. Others may have pulled a copy of your tree and
+ built on it; rebasing your tree will create pain for them. If work is
+ in need of rebasing, that is usually a sign that it is not yet ready to
+ be committed to a public repository.
+
+ - Do not rebase a branch that contains history created by others. If you
+ have pulled changes from another developer's repository, you are now a
+ custodian of their history. You should not change it.
+
+ - Do not rebase without a good reason to do so. Just being on a newer
+ base or avoiding a merge with an upstream repository is not generally a
+ good reason.
+
+ - If you must rebase a repository, do not pick some random kernel commit
+ as the new base. The kernel is often in a relatively unstable state
+ between release points; basing development on one of those points
+ increases the chances of running into surprising bugs. When a patch
+ series must move to a new base, pick a stable point (such as one of
+ the -rc releases) to move to.
+
+ - Realize the rebasing a patch series changes the environment in which it
+ was developed and, likely, invalidates much of the testing that was
+ done. A rebased patch series should, as a general rule, be treated like
+ new code and retested from the beginning.
+
+A frequent cause of merge-window trouble is when Linus is presented with a
+patch series that has clearly been rebased, often to a random commit,
+shortly before the pull request was sent. The chances of such a series
+having been adequately tested are relatively low - as are the chances of
+the pull request being acted upon.
+
+If, instead, rebasing is limited to private trees, commits are based on a
+well-known starting point, and they are well tested, the potential for
+trouble is low.
+
+Merging
+=======
+
+Merging is a common operation in the kernel development process; the 5.1
+development cycle included 1,126 merge commits - nearly 9% of the total.
+Kernel work is accumulated in over 100 different subsystem trees, each of
+which may contain multiple topic branches; each branch is usually developed
+independently of the others. So naturally, at least merge will be required
+before any given branch finds its way into an upstream repository.
+
+Many projects require that branches in pull requests be based on the
+current trunk so that no merge commits appear in the history. The kernel
+is not such a project; any rebasing of branches to avoid merges will, as
+described above, lead to certain trouble.
+
+Subsystem maintainers find themselves having to do two types of merges:
+from lower-level subsystem trees and from others, either sibling trees or
+the mainline. The best practices to follow differ in those two situations.
+
+Merging from lower-level trees
+------------------------------
+
+Larger subsystems tend to have multiple levels of maintainers, with the
+lower-level maintainers sending pull requests to the higher levels. Acting
+on such a pull request will almost certainly generate a merge commit; that
+is as it should be. In fact, subsystem maintainers may want to use
+the --no-ff flag to force the addition of a merge commit in the rare cases
+where one would not normally be created so that the reasons for the merge
+can be recorded. The changelog for the merge should, for any kind of
+merge, say *why* the merge is being done. For a lower-level tree, "why" is
+usually a summary of the changes that will come with that pull.
+
+Maintainers at all levels should be using signed tags on their pull
+requests, and upstream maintainers should verify the tags when pulling
+branches. Failure to do so threatens the security of the development
+process as a whole.
+
+As per the rules outlined above, once you have merged somebody else's
+history into your tree, you cannot rebase that branch, even if you
+otherwise would be able to.
+
+Merging from sibling or upstream trees
+--------------------------------------
+
+While merges from downstream are common and unremarkable, merges from other
+trees tend to be a red flag when it comes time to push a branch upstream.
+Such merges need to be carefully thought about and well justified, or
+there's a good chance that a subsequent pull request will be rejected.
+
+It is natural to want to merge the master branch into a repository; it can
+help to make sure that there are no conflicts with parallel development and
+generally gives a warm, fuzzy feeling of being up-to-date. But this
+temptation should be avoided almost all of the time.
+
+Why is that? Merges with upstream will muddy the development history of
+your own branch. They will significantly increase your chances of
+encountering bugs from elsewhere in the community and make it hard to
+ensure that the work you are managing is stable and ready for upstream.
+Frequent merges can also obscure problems with the development process in
+your tree; they can hide interactions with other trees that should not be
+happening (often) in a well-managed branch.
+
+One of the most frequent causes of merge-related trouble is when a
+maintainer merges with the upstream in order to resolve merge conflicts
+before sending a pull request. Again, this temptation is easy enough to
+understand, but it should absolutely be avoided. This is especially true
+for the final pull request: Linus is adamant that he would much rather see
+merge conflicts than unnecessary back merges. Seeing the conflicts lets
+him know where potential problem areas are. He does a lot of merges (382
+in the 5.1 development cycle) and has gotten quite good at conflict
+resolution - often better than the developers involved.
+
+So what should a maintainer do when there is a conflict between their
+subsystem branch and the mainline? The most important step is to warn
+Linus in the pull request that the conflict will happen; if nothing else,
+that demonstrates an awareness of how your branch fits into the whole. For
+especially difficult conflicts, create and push a *separate* branch to show
+how you would resolve things. Mention that branch in your pull request,
+but the pull request itself should be for the unmerged branch.
+
+Even in the absence of known conflicts, doing a test merge before sending a
+pull request is a good idea. It may alert you to problems that you somehow
+didn't see from linux-next and helps to understand exactly what you are
+asking upstream to do.
+
+Another reason for doing merges of upstream or another subsystem tree is to
+resolve dependencies. These dependency issues do happen at times, and
+sometimes a cross-merge with another tree is the best way to resolve them;
+as always, in such situations, the merge commit should explain why the
+merge has been done. Take a moment to do it right; people will read those
+changelogs.
+
+Often, though, dependency issues indicate that a change of approach is
+needed. Merging another subsystem tree to resolve a dependency risks
+bringing in other bugs. If that subsystem tree fails to be pulled
+upstream, whatever problems it had will block the merging of your tree as
+well. Possible alternatives include agreeing with the maintainer to carry
+both sets of changes in one of the trees or creating a special branch
+dedicated to the dependent commits. If the dependency is related to major
+infrastructural changes, the right solution might be to hold the dependent
+commits for one development cycle so that those changes have time to
+stabilize in the mainline.
+
+Finally
+=======
+
+It is relatively common to merge with the mainline toward the beginning of
+the development cycle in order to pick up changes and fixes done elsewhere
+in the tree. As always, such a merge should pick a well-known release
+point rather than some random spot. If your upstream-bound branch has
+emptied entirely into the mainline during the merge window, you can pull it
+forward with a command like::
+
+ git merge v5.2-rc1^0
+
+The "^0" will cause Git to do a fast-forward merge (which should be
+possible in this situation), thus avoiding the addition of a spurious merge
+commit.
+
+The guidelines laid out above are just that: guidelines. There will always
+be situations that call out for a different solution, and these guidelines
+should not prevent developers from doing the right thing when the need
+arises. But one should always think about whether the need has truly
+arisen and be prepared to explain why something abnormal needs to be done.
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: James Morris @ 2019-05-30 20:11 UTC (permalink / raw)
To: Ke Wu
Cc: Kees Cook, Jonathan Corbet, Serge E. Hallyn, linux-doc,
linux-kernel, linux-security-module
In-Reply-To: <20190530192208.99773-1-mikewu@google.com>
On Thu, 30 May 2019, Ke Wu wrote:
> Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> make sure loaded kernel module and kernel image are trusted. This
> patch adds a kernel command line option "loadpin.exclude" which
> allows to exclude specific file types from LoadPin. This is useful
> when people want to use different mechanisms to verify module and
> kernel image while still use LoadPin to protect the integrity of
> other files kernel loads.
>
> Signed-off-by: Ke Wu <mikewu@google.com>
> ---
> Changelog since v1:
> - Mark ignore_read_file_id with __ro_after_init.
> - Mark parse_exclude() with __init.
> - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
Looks good!
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH] doc:it_IT: documentation alignment
From: Federico Vaga @ 2019-05-30 20:14 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Federico Vaga, linux-doc, linux-kernel, Mauro Carvalho Chehab
In-Reply-To: <20190530201455.12412-1-federico.vaga@vaga.pv.it>
Documentation alignment for the following changes:
a700767a7682 (doc/docs-next) docs: requirements.txt: recommend Sphinx 1.7.9
Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
---
.../translations/it_IT/doc-guide/sphinx.rst | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst b/Documentation/translations/it_IT/doc-guide/sphinx.rst
index 793b5cc33403..1739cba8863e 100644
--- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
+++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
@@ -35,8 +35,7 @@ Installazione Sphinx
====================
I marcatori ReST utilizzati nei file in Documentation/ sono pensati per essere
-processati da ``Sphinx`` nella versione 1.3 o superiore. Se desiderate produrre
-un documento PDF è raccomandato l'utilizzo di una versione superiore alle 1.4.6.
+processati da ``Sphinx`` nella versione 1.3 o superiore.
Esiste uno script che verifica i requisiti Sphinx. Per ulteriori dettagli
consultate :ref:`it_sphinx-pre-install`.
@@ -68,13 +67,13 @@ pacchettizzato dalla vostra distribuzione.
utilizzando LaTeX. Per una corretta interpretazione, è necessario aver
installato texlive con i pacchetti amdfonts e amsmath.
-Riassumendo, se volete installare la versione 1.4.9 di Sphinx dovete eseguire::
+Riassumendo, se volete installare la versione 1.7.9 di Sphinx dovete eseguire::
- $ virtualenv sphinx_1.4
- $ . sphinx_1.4/bin/activate
- (sphinx_1.4) $ pip install -r Documentation/sphinx/requirements.txt
+ $ virtualenv sphinx_1.7.9
+ $ . sphinx_1.7.9/bin/activate
+ (sphinx_1.7.9) $ pip install -r Documentation/sphinx/requirements.txt
-Dopo aver eseguito ``. sphinx_1.4/bin/activate``, il prompt cambierà per
+Dopo aver eseguito ``. sphinx_1.7.9/bin/activate``, il prompt cambierà per
indicare che state usando il nuovo ambiente. Se aprite un nuova sessione,
prima di generare la documentazione, dovrete rieseguire questo comando per
rientrare nell'ambiente virtuale.
@@ -120,8 +119,8 @@ l'installazione::
You should run:
sudo dnf install -y texlive-luatex85
- /usr/bin/virtualenv sphinx_1.4
- . sphinx_1.4/bin/activate
+ /usr/bin/virtualenv sphinx_1.7.9
+ . sphinx_1.7.9/bin/activate
pip install -r Documentation/sphinx/requirements.txt
Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468.
--
2.21.0
^ permalink raw reply related
* [PATCH] doc:it_IT: fix file references
From: Federico Vaga @ 2019-05-30 20:14 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Federico Vaga, linux-doc, linux-kernel, Mauro Carvalho Chehab
Fix italian translation file references based on
`scripts/documentation-file-ref-check` output.
Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
---
.../it_IT/admin-guide/kernel-parameters.rst | 12 ++++++++++++
.../translations/it_IT/process/adding-syscalls.rst | 2 +-
.../translations/it_IT/process/coding-style.rst | 2 +-
Documentation/translations/it_IT/process/howto.rst | 2 +-
.../translations/it_IT/process/magic-number.rst | 2 +-
.../it_IT/process/stable-kernel-rules.rst | 4 ++--
6 files changed, 18 insertions(+), 6 deletions(-)
create mode 100644 Documentation/translations/it_IT/admin-guide/kernel-parameters.rst
diff --git a/Documentation/translations/it_IT/admin-guide/kernel-parameters.rst b/Documentation/translations/it_IT/admin-guide/kernel-parameters.rst
new file mode 100644
index 000000000000..0e36d82a92be
--- /dev/null
+++ b/Documentation/translations/it_IT/admin-guide/kernel-parameters.rst
@@ -0,0 +1,12 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/admin-guide/kernel-parameters.rst <kernelparameters>`
+
+.. _it_kernelparameters:
+
+I parametri da linea di comando del kernel
+==========================================
+
+.. warning::
+
+ TODO ancora da tradurre
diff --git a/Documentation/translations/it_IT/process/adding-syscalls.rst b/Documentation/translations/it_IT/process/adding-syscalls.rst
index e0a64b0688a7..c3a3439595a6 100644
--- a/Documentation/translations/it_IT/process/adding-syscalls.rst
+++ b/Documentation/translations/it_IT/process/adding-syscalls.rst
@@ -39,7 +39,7 @@ vostra interfaccia.
un qualche modo opaca.
- Se dovete esporre solo delle informazioni sul sistema, un nuovo nodo in
- sysfs (vedere ``Documentation/translations/it_IT/filesystems/sysfs.txt``) o
+ sysfs (vedere ``Documentation/filesystems/sysfs.txt``) o
in procfs potrebbe essere sufficiente. Tuttavia, l'accesso a questi
meccanismi richiede che il filesystem sia montato, il che potrebbe non
essere sempre vero (per esempio, in ambienti come namespace/sandbox/chroot).
diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst
index 5ef534c95e69..a6559d25a23d 100644
--- a/Documentation/translations/it_IT/process/coding-style.rst
+++ b/Documentation/translations/it_IT/process/coding-style.rst
@@ -696,7 +696,7 @@ nella stringa di titolo::
...
Per la documentazione completa sui file di configurazione, consultate
-il documento Documentation/translations/it_IT/kbuild/kconfig-language.txt
+il documento Documentation/kbuild/kconfig-language.txt
11) Strutture dati
diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst
index 9903ac7c566b..44e6077730e8 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -131,7 +131,7 @@ Di seguito una lista di file che sono presenti nei sorgente del kernel e che
"Linux kernel patch submission format"
http://linux.yyz.us/patch-format.html
- :ref:`Documentation/process/translations/it_IT/stable-api-nonsense.rst <it_stable_api_nonsense>`
+ :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst <it_stable_api_nonsense>`
Questo file descrive la motivazioni sottostanti la conscia decisione di
non avere un API stabile all'interno del kernel, incluso cose come:
diff --git a/Documentation/translations/it_IT/process/magic-number.rst b/Documentation/translations/it_IT/process/magic-number.rst
index 5281d53e57ee..ed1121d0ba84 100644
--- a/Documentation/translations/it_IT/process/magic-number.rst
+++ b/Documentation/translations/it_IT/process/magic-number.rst
@@ -1,6 +1,6 @@
.. include:: ../disclaimer-ita.rst
-:Original: :ref:`Documentation/process/magic-numbers.rst <magicnumbers>`
+:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
.. _it_magicnumbers:
diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
index 48e88e5ad2c5..4f206cee31a7 100644
--- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
+++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
@@ -33,7 +33,7 @@ Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
- Non deve includere alcuna correzione "banale" (correzioni grammaticali,
pulizia dagli spazi bianchi, eccetera).
- Deve rispettare le regole scritte in
- :ref:`Documentation/translation/it_IT/process/submitting-patches.rst <it_submittingpatches>`
+ :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
- Questa patch o una equivalente deve esistere già nei sorgenti principali di
Linux
@@ -43,7 +43,7 @@ Procedura per sottomettere patch per i sorgenti -stable
- Se la patch contiene modifiche a dei file nelle cartelle net/ o drivers/net,
allora seguite le linee guida descritte in
- :ref:`Documentation/translation/it_IT/networking/netdev-FAQ.rst <it_netdev-FAQ>`;
+ :ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst <it_netdev-FAQ>`;
ma solo dopo aver verificato al seguente indirizzo che la patch non sia
già in coda:
https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive=
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 06/22] doc: it_IT: fix reference to magic-number.rst
From: Federico Vaga @ 2019-05-30 20:15 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Alessia Mantegazza
In-Reply-To: <76713fe801e082e54e4412331d14495f2620ee59.1559171394.git.mchehab+samsung@kernel.org>
On Thursday, May 30, 2019 1:23:37 AM CEST Mauro Carvalho Chehab wrote:
> There's a typo at the referred file.
I am about to send a patch that fixes all issues found by
documentation-file-ref-check in Documentation/translations/it_IT.
Of course I fixed this as well.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/translations/it_IT/process/magic-number.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/translations/it_IT/process/magic-number.rst
> b/Documentation/translations/it_IT/process/magic-number.rst index
> 5281d53e57ee..ed1121d0ba84 100644
> --- a/Documentation/translations/it_IT/process/magic-number.rst
> +++ b/Documentation/translations/it_IT/process/magic-number.rst
> @@ -1,6 +1,6 @@
> .. include:: ../disclaimer-ita.rst
>
> -:Original: :ref:`Documentation/process/magic-numbers.rst <magicnumbers>`
> +:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
>
> :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
>
> .. _it_magicnumbers:
^ permalink raw reply
* [lwn:docs-next 25/31] htmldocs: /bin/bash: ./scripts/sphinx-pre-install: No such file or directory
From: kbuild test robot @ 2019-05-30 20:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: kbuild-all, linux-doc, linux-media, Jonathan Corbet
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
tree: git://git.lwn.net/linux-2.6 docs-next
head: a700767a7682d9bd237e927253274859aee075e7
commit: 9b88ad5464af1bf7228991f1c46a9a13484790a4 [25/31] scripts/sphinx-pre-install: always check if version is compatible with build
reproduce: make htmldocs
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> /bin/bash: ./scripts/sphinx-pre-install: No such file or directory
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 7240 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/1] sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
From: bsegall @ 2019-05-30 20:44 UTC (permalink / raw)
To: Dave Chiluk
Cc: Phil Auld, Peter Oskolkov, Peter Zijlstra, Ingo Molnar, cgroups,
linux-kernel, Brendan Gregg, Kyle Anderson, Gabriel Munos,
John Hammond, Cong Wang, Jonathan Corbet, linux-doc, pjt
In-Reply-To: <CAC=E7cU9GetuKVQE1HxXsSuOKgyxezXUmSH2ZDHOrLio_YZi1g@mail.gmail.com>
Dave Chiluk <chiluk+linux@indeed.com> writes:
> On Wed, May 29, 2019 at 02:05:55PM -0700, bsegall@google.com wrote:
>> Dave Chiluk <chiluk+linux@indeed.com> writes:
>>
>> Yeah, having run the test, stranding only 1 ms per cpu rather than 5
>> doesn't help if you only have 10 ms of quota and even 10 threads/cpus.
>> The slack timer isn't important in this test, though I think it probably
>> should be changed.
> My min_cfs_rq_runtime was already set to 1ms.
Yeah, I meant min_cfs_rq_runtime vs the 5ms if the slack stuff was
broken.
>
> Additionally raising the amount of quota from 10ms to 50ms or even
> 100ms, still results in throttling without full quota usage.
>
>> Decreasing min_cfs_rq_runtime helps, but would mean that we have to pull
>> quota more often / always. The worst case here I think is where you
>> run/sleep for ~1ns, so you wind up taking the lock twice every
>> min_cfs_rq_runtime: once for assign and once to return all but min,
>> which you then use up doing short run/sleep. I suppose that determines
>> how much we care about this overhead at all.
> I'm not so concerned about how inefficiently the user-space application
> runs, as that's up to the invidual developer.
Increasing scheduler overhead is something we generally try to prevent
is what I was worried about.
> The fibtest testcase, is
> purely my approximation of what a java application with lots of worker
> threads might do, as I didn't have a great deterministic java
> reproducer, and I feared posting java to LKML. I'm more concerned with
> the fact that the user requested 10ms/period or 100ms/period and they
> hit throttling while simultaneously not seeing that amount of cpu usage.
> i.e. on an 8 core machine if I
> $ ./runfibtest 1
> Iterations Completed(M): 1886
> Throttled for: 51
> CPU Usage (msecs) = 507
> $ ./runfibtest 8
> Iterations Completed(M): 1274
> Throttled for: 52
> CPU Usage (msecs) = 380
>
> You see that in the 8 core case where we have 7 do nothing threads on
> cpu's 1-7, we see only 380 ms of usage, and 52 periods of throttling
> when we should have received ~500ms of cpu usage.
>
> Looking more closely at the __return_cfs_rq_runtime logic I noticed
> if (cfs_b->quota != RUNTIME_INF &&
> cfs_rq->runtime_expires == cfs_b->runtime_expires) {
>
> Which is awfully similar to the logic that was fixed by 512ac999. Is it
> possible that we are just not ever returning runtime back to the cfs_b
> because of the runtime_expires comparison here?
The relevant issue that patch fixes is that the old conditional was
backwards. Also lowering min_cfs_rq_runtime to 0 fixes your testcase, so
it's working.
>
>> Removing expiration means that in the worst case period and quota can be
>> effectively twice what the user specified, but only on very particular
>> workloads.
> I'm only removing expiration of slices that have already been assigned
> to individual cfs_rq. My understanding is that there is at most one
> cfs_rq per cpu, and each of those can have at most one slice of
> available runtime. So the worst case burst is slice_ms * cpus. Please
> help me understand how you get to twice user specified quota and period
> as it's not obvious to me *(I've only been looking at this for a few
> months).
The reason that this effect is so significant is because slice_ms * cpus
is roughly 100% of the quota. So yes, it's roughly the same thing.
Unfortunately if there are more spare cpus on the system just doubling
quota and period (keeping the same ratio) would not fix your issue,
while removing expiration does while also potentially having that effect.
>
>> I think we should at least think about instead lowering
>> min_cfs_rq_runtime to some smaller value
> Do you mean lower than 1ms?
Yes
^ permalink raw reply
* Re: [PATCH 2/2] Docs: hwmon: pmbus: Add PXE1610 driver
From: Vijay Khemka @ 2019-05-30 20:44 UTC (permalink / raw)
To: Guenter Roeck
Cc: Jean Delvare, Jonathan Corbet, linux-hwmon@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
joel@jms.id.au, linux-aspeed@lists.ozlabs.org, Sai Dasari,
Greg Kroah-Hartman
In-Reply-To: <20190530194441.GA12310@roeck-us.net>
On 5/30/19, 12:45 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
On Thu, May 30, 2019 at 06:51:52PM +0000, Vijay Khemka wrote:
>
>
> On 5/29/19, 6:05 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
>
> On 5/29/19 3:35 PM, Vijay Khemka wrote:
> > Added support for Infenion PXE1610 driver
> >
> > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > ---
> > Documentation/hwmon/pxe1610 | 84 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 84 insertions(+)
> > create mode 100644 Documentation/hwmon/pxe1610
> >
> > diff --git a/Documentation/hwmon/pxe1610 b/Documentation/hwmon/pxe1610
> > new file mode 100644
> > index 000000000000..b5c83edf027a
> > --- /dev/null
> > +++ b/Documentation/hwmon/pxe1610
> > @@ -0,0 +1,84 @@
> > +Kernel driver pxe1610
> > +=====================
> > +
> > +Supported chips:
> > + * Infinion PXE1610
> > + Prefix: 'pxe1610'
> > + Addresses scanned: -
> > + Datasheet: Datasheet is not publicly available.
> > +
> > + * Infinion PXE1110
> > + Prefix: 'pxe1110'
> > + Addresses scanned: -
> > + Datasheet: Datasheet is not publicly available.
> > +
> > + * Infinion PXM1310
> > + Prefix: 'pxm1310'
> > + Addresses scanned: -
> > + Datasheet: Datasheet is not publicly available.
> > +
> > +Author: Vijay Khemka <vijaykhemka@fb.com>
> > +
> > +
> > +Description
> > +-----------
> > +
> > +PXE1610 is a Multi-rail/Multiphase Digital Controllers and
> > +it is compliant to Intel VR13 DC-DC converter specifications.
> > +
>
> And the others ?
> This supports VR12 as well and I don't see this controller supports any other VR versions.
>
The point here is that there is no description of the other controllers.
Ok, I get it, mainly all 3 controllers are from same family of Infineon controller but I will add details here.
> > +
> > +Usage Notes
> > +-----------
> > +
> > +This driver can be enabled with kernel config CONFIG_SENSORS_PXE1610
> > +set to 'y' or 'm'(for module).
> > +
> The above does not really add value.
> Ok, I will remove it.
>
> > +This driver does not probe for PMBus devices. You will have
> > +to instantiate devices explicitly.
> > +
> > +Example: the following commands will load the driver for an PXE1610
> > +at address 0x70 on I2C bus #4:
> > +
> > +# modprobe pxe1610
> > +# echo pxe1610 0x70 > /sys/bus/i2c/devices/i2c-4/new_device
> > +
> > +It can also be instantiated by declaring in device tree if it is
> > +built as a kernel not as a module.
> > +
>
> I assume you mean "built into the kernel".
> Why would devicetree based instantiation not work if the driver is built
> as module ?
> Will correct statement here.
>
> > +
> > +Sysfs attributes
> > +----------------
> > +
> > +curr1_label "iin"
> > +curr1_input Measured input current
> > +curr1_alarm Current high alarm
> > +
> > +curr[2-4]_label "iout[1-3]"
> > +curr[2-4]_input Measured output current
> > +curr[2-4]_crit Critical maximum current
> > +curr[2-4]_crit_alarm Current critical high alarm
> > +
> > +in1_label "vin"
> > +in1_input Measured input voltage
> > +in1_crit Critical maximum input voltage
> > +in1_crit_alarm Input voltage critical high alarm
> > +
> > +in[2-4]_label "vout[1-3]"
> > +in[2-4]_input Measured output voltage
> > +in[2-4]_lcrit Critical minimum output voltage
> > +in[2-4]_lcrit_alarm Output voltage critical low alarm
> > +in[2-4]_crit Critical maximum output voltage
> > +in[2-4]_crit_alarm Output voltage critical high alarm
> > +
> > +power1_label "pin"
> > +power1_input Measured input power
> > +power1_alarm Input power high alarm
> > +
> > +power[2-4]_label "pout[1-3]"
> > +power[2-4]_input Measured output power
> > +
> > +temp[1-3]_input Measured temperature
> > +temp[1-3]_crit Critical high temperature
> > +temp[1-3]_crit_alarm Chip temperature critical high alarm
> > +temp[1-3]_max Maximum temperature
> > +temp[1-3]_max_alarm Chip temperature high alarm
> >
>
>
>
^ permalink raw reply
* Re: [PATCH] docs cgroups: add another example size for hugetlb
From: Tejun Heo @ 2019-05-30 21:04 UTC (permalink / raw)
To: Odin Ugedal
Cc: Li Zefan, Johannes Weiner, Jonathan Corbet,
open list:CONTROL GROUP (CGROUP), open list:DOCUMENTATION,
open list
In-Reply-To: <20190529222425.30879-1-odin@ugedal.com>
On Thu, May 30, 2019 at 12:24:25AM +0200, Odin Ugedal wrote:
> Add another example to clarify that HugePages smaller than 1MB will
> be displayed using "KB", with an uppercased K (eg. 20KB), and not the
> normal SI prefix kilo (small k).
>
> Because of a misunderstanding/copy-paste error inside runc
> (see https://github.com/opencontainers/runc/pull/2065), it tried
> accessing the cgroup control file of a 64kB HugePage using
> "hugetlb.64kB._____" instead of the correct "hugetlb.64KB._____".
>
> Adding a new example will make it clear how sizes smaller than 1MB are
> handled.
>
> Signed-off-by: Odin Ugedal <odin@ugedal.com>
Applied to cgroup/for-5.2-fixes.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: Kees Cook @ 2019-05-30 21:42 UTC (permalink / raw)
To: Ke Wu, James Morris
Cc: Jonathan Corbet, Serge E. Hallyn, linux-doc, linux-kernel,
linux-security-module
In-Reply-To: <20190530192208.99773-1-mikewu@google.com>
On Thu, May 30, 2019 at 12:22:08PM -0700, Ke Wu wrote:
> Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> make sure loaded kernel module and kernel image are trusted. This
> patch adds a kernel command line option "loadpin.exclude" which
> allows to exclude specific file types from LoadPin. This is useful
> when people want to use different mechanisms to verify module and
> kernel image while still use LoadPin to protect the integrity of
> other files kernel loads.
>
> Signed-off-by: Ke Wu <mikewu@google.com>
Thanks for the updates!
Acked-by: Kees Cook <keescook@chromium.org>
James, I don't have anything else planned for loadpin this cycle. Do you
want me to push this to Linus in the next cycle, or do you want to take
it into one of your trees?
Thanks!
-Kees
> ---
> Changelog since v1:
> - Mark ignore_read_file_id with __ro_after_init.
> - Mark parse_exclude() with __init.
> - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
>
>
> Documentation/admin-guide/LSM/LoadPin.rst | 10 ++++++
> security/loadpin/loadpin.c | 38 +++++++++++++++++++++++
> 2 files changed, 48 insertions(+)
>
> diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
> index 32070762d24c..716ad9b23c9a 100644
> --- a/Documentation/admin-guide/LSM/LoadPin.rst
> +++ b/Documentation/admin-guide/LSM/LoadPin.rst
> @@ -19,3 +19,13 @@ block device backing the filesystem is not read-only, a sysctl is
> created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
> a mutable filesystem means pinning is mutable too, but having the
> sysctl allows for easy testing on systems with a mutable filesystem.)
> +
> +It's also possible to exclude specific file types from LoadPin using kernel
> +command line option "``loadpin.exclude``". By default, all files are
> +included, but they can be excluded using kernel command line option such
> +as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
> +different mechanisms such as ``CONFIG_MODULE_SIG`` and
> +``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
> +still use LoadPin to protect the integrity of other files kernel loads. The
> +full list of valid file types can be found in ``kernel_read_file_str``
> +defined in ``include/linux/fs.h``.
> diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
> index 055fb0a64169..d5f064644c54 100644
> --- a/security/loadpin/loadpin.c
> +++ b/security/loadpin/loadpin.c
> @@ -45,6 +45,8 @@ static void report_load(const char *origin, struct file *file, char *operation)
> }
>
> static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
> +static char *exclude_read_files[READING_MAX_ID];
> +static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
> static struct super_block *pinned_root;
> static DEFINE_SPINLOCK(pinned_root_spinlock);
>
> @@ -129,6 +131,13 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
> struct super_block *load_root;
> const char *origin = kernel_read_file_id_str(id);
>
> + /* If the file id is excluded, ignore the pinning. */
> + if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
> + ignore_read_file_id[id]) {
> + report_load(origin, file, "pinning-excluded");
> + return 0;
> + }
> +
> /* This handles the older init_module API that has a NULL file. */
> if (!file) {
> if (!enforce) {
> @@ -187,10 +196,37 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
> LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
> };
>
> +static void __init parse_exclude(void)
> +{
> + int i, j;
> + char *cur;
> +
> + for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
> + cur = exclude_read_files[i];
> + if (!cur)
> + break;
> + if (*cur == '\0')
> + continue;
> +
> + for (j = 0; j < ARRAY_SIZE(kernel_read_file_str); j++) {
> + if (strcmp(cur, kernel_read_file_str[j]) == 0) {
> + pr_info("excluding: %s\n",
> + kernel_read_file_str[j]);
> + ignore_read_file_id[j] = 1;
> + /*
> + * Can not break, because one read_file_str
> + * may map to more than on read_file_id.
> + */
> + }
> + }
> + }
> +}
> +
> static int __init loadpin_init(void)
> {
> pr_info("ready to pin (currently %senforcing)\n",
> enforce ? "" : "not ");
> + parse_exclude();
> security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
> return 0;
> }
> @@ -203,3 +239,5 @@ DEFINE_LSM(loadpin) = {
> /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
> module_param(enforce, int, 0);
> MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
> +module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
> +MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
--
Kees Cook
^ permalink raw reply
* Re: [lwn:docs-next 25/31] htmldocs: /bin/bash: ./scripts/sphinx-pre-install: No such file or directory
From: Jonathan Corbet @ 2019-05-30 21:32 UTC (permalink / raw)
To: kbuild test robot
Cc: Mauro Carvalho Chehab, kbuild-all, linux-doc, linux-media
In-Reply-To: <201905310424.Zhlxo3ky%lkp@intel.com>
On Fri, 31 May 2019 04:19:29 +0800
kbuild test robot <lkp@intel.com> wrote:
> tree: git://git.lwn.net/linux-2.6 docs-next
> head: a700767a7682d9bd237e927253274859aee075e7
> commit: 9b88ad5464af1bf7228991f1c46a9a13484790a4 [25/31] scripts/sphinx-pre-install: always check if version is compatible with build
> reproduce: make htmldocs
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> /bin/bash: ./scripts/sphinx-pre-install: No such file or directory
For this one, I'm guessing we need something like the following...disagree?
jon
--------
diff --git a/Documentation/Makefile b/Documentation/Makefile
index e889e7cb8511..c98188994322 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -23,7 +23,7 @@ ifeq ($(HAVE_SPHINX),0)
.DEFAULT:
$(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.)
@echo
- @./scripts/sphinx-pre-install
+ @$(srctree)/scripts/sphinx-pre-install
@echo " SKIP Sphinx $@ target."
else # HAVE_SPHINX
^ permalink raw reply related
* Re: [PATCH 22/22] docs: fix broken documentation links
From: Michael S. Tsirkin @ 2019-05-30 22:49 UTC (permalink / raw)
To: Federico Vaga
Cc: Linux Doc Mailing List, linux-kernel, x86, linux-acpi, linux-edac,
netdev, devicetree, linux-pci, linux-arm-kernel, linux-amlogic,
linux-arm-msm, linux-gpio, linux-i2c, linuxppc-dev, xen-devel,
platform-driver-x86, devel, kvm, virtualization, devel, linux-mm,
linux-security-module, linux-kselftest
In-Reply-To: <1574052.9PXfBvmXpz@harkonnen>
On Thu, May 30, 2019 at 10:17:32PM +0200, Federico Vaga wrote:
> On Thursday, May 30, 2019 1:23:53 AM CEST Mauro Carvalho Chehab wrote:
> > Mostly due to x86 and acpi conversion, several documentation
> > links are still pointing to the old file. Fix them.
>
> For the Italian documentation I just send I patch to fix them in a dedicated
> patch
Acked-by: Michael S. Tsirkin <mst@redhat.com>
for the vhost change.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/acpi/dsd/leds.txt | 2 +-
> > Documentation/admin-guide/kernel-parameters.rst | 6 +++---
> > Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++--------
> > Documentation/admin-guide/ras.rst | 2 +-
> > .../devicetree/bindings/net/fsl-enetc.txt | 7 +++----
> > .../bindings/pci/amlogic,meson-pcie.txt | 2 +-
> > .../bindings/regulator/qcom,rpmh-regulator.txt | 2 +-
> > Documentation/devicetree/booting-without-of.txt | 2 +-
> > Documentation/driver-api/gpio/board.rst | 2 +-
> > Documentation/driver-api/gpio/consumer.rst | 2 +-
> > .../firmware-guide/acpi/enumeration.rst | 2 +-
> > .../firmware-guide/acpi/method-tracing.rst | 2 +-
> > Documentation/i2c/instantiating-devices | 2 +-
> > Documentation/sysctl/kernel.txt | 4 ++--
> > .../translations/it_IT/process/howto.rst | 2 +-
> > .../it_IT/process/stable-kernel-rules.rst | 4 ++--
> > .../translations/zh_CN/process/4.Coding.rst | 2 +-
> > Documentation/x86/x86_64/5level-paging.rst | 2 +-
> > Documentation/x86/x86_64/boot-options.rst | 4 ++--
> > .../x86/x86_64/fake-numa-for-cpusets.rst | 2 +-
> > MAINTAINERS | 6 +++---
> > arch/arm/Kconfig | 2 +-
> > arch/arm64/kernel/kexec_image.c | 2 +-
> > arch/powerpc/Kconfig | 2 +-
> > arch/x86/Kconfig | 16 ++++++++--------
> > arch/x86/Kconfig.debug | 2 +-
> > arch/x86/boot/header.S | 2 +-
> > arch/x86/entry/entry_64.S | 2 +-
> > arch/x86/include/asm/bootparam_utils.h | 2 +-
> > arch/x86/include/asm/page_64_types.h | 2 +-
> > arch/x86/include/asm/pgtable_64_types.h | 2 +-
> > arch/x86/kernel/cpu/microcode/amd.c | 2 +-
> > arch/x86/kernel/kexec-bzimage64.c | 2 +-
> > arch/x86/kernel/pci-dma.c | 2 +-
> > arch/x86/mm/tlb.c | 2 +-
> > arch/x86/platform/pvh/enlighten.c | 2 +-
> > drivers/acpi/Kconfig | 10 +++++-----
> > drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
> > .../fieldbus/Documentation/fieldbus_dev.txt | 4 ++--
> > drivers/vhost/vhost.c | 2 +-
> > include/acpi/acpi_drivers.h | 2 +-
> > include/linux/fs_context.h | 2 +-
> > include/linux/lsm_hooks.h | 2 +-
> > mm/Kconfig | 2 +-
> > security/Kconfig | 2 +-
> > tools/include/linux/err.h | 2 +-
> > tools/objtool/Documentation/stack-validation.txt | 4 ++--
> > tools/testing/selftests/x86/protection_keys.c | 2 +-
> > 48 files changed, 77 insertions(+), 78 deletions(-)
> >
> > diff --git a/Documentation/acpi/dsd/leds.txt
> > b/Documentation/acpi/dsd/leds.txt index 81a63af42ed2..cc58b1a574c5 100644
> > --- a/Documentation/acpi/dsd/leds.txt
> > +++ b/Documentation/acpi/dsd/leds.txt
> > @@ -96,4 +96,4 @@ where
> >
> > <URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-da
> > ta-extension-UUID-v1.1.pdf>, referenced 2019-02-21.
> >
> > -[7] Documentation/acpi/dsd/data-node-reference.txt
> > +[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > diff --git a/Documentation/admin-guide/kernel-parameters.rst
> > b/Documentation/admin-guide/kernel-parameters.rst index
> > 0124980dca2d..8d3273e32eb1 100644
> > --- a/Documentation/admin-guide/kernel-parameters.rst
> > +++ b/Documentation/admin-guide/kernel-parameters.rst
> > @@ -167,7 +167,7 @@ parameter is applicable::
> > X86-32 X86-32, aka i386 architecture is enabled.
> > X86-64 X86-64 architecture is enabled.
> > More X86-64 boot options can be found in
> > - Documentation/x86/x86_64/boot-options.txt
> .
> > + Documentation/x86/x86_64/boot-options.rst.
> > X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
> > X86_UV SGI UV support is enabled.
> > XEN Xen support is enabled
> > @@ -181,10 +181,10 @@ In addition, the following text indicates that the
> > option:: Parameters denoted with BOOT are actually interpreted by the boot
> > loader, and have no meaning to the kernel directly.
> > Do not modify the syntax of boot loader parameters without extreme
> > -need or coordination with <Documentation/x86/boot.txt>.
> > +need or coordination with <Documentation/x86/boot.rst>.
> >
> > There are also arch-specific kernel-parameters not documented here.
> > -See for example <Documentation/x86/x86_64/boot-options.txt>.
> > +See for example <Documentation/x86/x86_64/boot-options.rst>.
> >
> > Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
> > a trailing = on the name of any parameter states that that parameter will
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt index
> > 138f6664b2e2..4a02d1346635 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -53,7 +53,7 @@
> > ACPI_DEBUG_PRINT statements, e.g.,
> > ACPI_DEBUG_PRINT((ACPI_DB_INFO, ...
> > The debug_level mask defaults to "info".
> See
> > - Documentation/acpi/debug.txt for more
> information about
> > + Documentation/firmware-guide/acpi/debug.rst
> for more information about
> > debug layers and levels.
> >
> > Enable processor driver info messages:
> > @@ -963,7 +963,7 @@
> > for details.
> >
> > nompx [X86] Disables Intel Memory Protection
> Extensions.
> > - See Documentation/x86/intel_mpx.txt for
> more
> > + See Documentation/x86/intel_mpx.rst for
> more
> > information about the feature.
> >
> > nopku [X86] Disable Memory Protection Keys CPU
> feature found
> > @@ -1189,7 +1189,7 @@
> > that is to be dynamically loaded by Linux.
> If there are
> > multiple variables with the same name but
> with different
> > vendor GUIDs, all of them will be loaded.
> See
> > - Documentation/acpi/ssdt-overlays.txt for
> details.
> > + Documentation/admin-guide/acpi/ssdt-
> overlays.rst for details.
> >
> >
> > eisa_irq_edge= [PARISC,HW]
> > @@ -2383,7 +2383,7 @@
> >
> > mce [X86-32] Machine Check Exception
> >
> > - mce=option [X86-64] See Documentation/x86/x86_64/boot-
> options.txt
> > + mce=option [X86-64] See Documentation/x86/x86_64/boot-
> options.rst
> >
> > md= [HW] RAID subsystems devices and level
> > See Documentation/admin-guide/md.rst.
> > @@ -2439,7 +2439,7 @@
> > set according to the
> > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
> kernel config
> > option.
> > - See Documentation/memory-hotplug.txt.
> > + See Documentation/admin-guide/mm/memory-
> hotplug.rst.
> >
> > memmap=exactmap [KNL,X86] Enable setting of an exact
> > E820 memory map, as specified by the user.
> > @@ -2528,7 +2528,7 @@
> > mem_encrypt=on: Activate
> SME
> > mem_encrypt=off: Do not activate SME
> >
> > - Refer to Documentation/x86/amd-memory-
> encryption.txt
> > + Refer to Documentation/virtual/kvm/amd-
> memory-encryption.rst
> > for details on when memory encryption can
> be activated.
> >
> > mem_sleep_default= [SUSPEND] Default system suspend mode:
> > @@ -3528,7 +3528,7 @@
> > See Documentation/blockdev/paride.txt.
> >
> > pirq= [SMP,APIC] Manual mp-table setup
> > - See Documentation/x86/i386/IO-APIC.txt.
> > + See Documentation/x86/i386/IO-APIC.rst.
> >
> > plip= [PPT,NET] Parallel port network link
> > Format: { parport<nr> | timid | 0 }
> > @@ -5054,7 +5054,7 @@
> > Can be used multiple times for multiple
> devices.
> >
> > vga= [BOOT,X86-32] Select a particular video
> mode
> > - See Documentation/x86/boot.txt and
> > + See Documentation/x86/boot.rst and
> > Documentation/svga.txt.
> > Use vga=ask for menu.
> > This is actually a boot loader parameter;
> the value is
> > diff --git a/Documentation/admin-guide/ras.rst
> > b/Documentation/admin-guide/ras.rst index c7495e42e6f4..2b20f5f7380d 100644
> > --- a/Documentation/admin-guide/ras.rst
> > +++ b/Documentation/admin-guide/ras.rst
> > @@ -199,7 +199,7 @@ Architecture (MCA)\ [#f3]_.
> > mode).
> >
> > .. [#f3] For more details about the Machine Check Architecture (MCA),
> > - please read Documentation/x86/x86_64/machinecheck at the Kernel tree.
> > + please read Documentation/x86/x86_64/machinecheck.rst at the Kernel tree.
> >
> > EDAC - Error Detection And Correction
> > *************************************
> > diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt
> > b/Documentation/devicetree/bindings/net/fsl-enetc.txt index
> > c812e25ae90f..25fc687419db 100644
> > --- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
> > +++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
> > @@ -16,8 +16,8 @@ Required properties:
> > In this case, the ENETC node should include a "mdio" sub-node
> > that in turn should contain the "ethernet-phy" node describing the
> > external phy. Below properties are required, their bindings
> > -already defined in ethernet.txt or phy.txt, under
> > -Documentation/devicetree/bindings/net/*.
> > +already defined in Documentation/devicetree/bindings/net/ethernet.txt or
> > +Documentation/devicetree/bindings/net/phy.txt.
> >
> > Required:
> >
> > @@ -51,8 +51,7 @@ Example:
> > connection:
> >
> > In this case, the ENETC port node defines a fixed link connection,
> > -as specified by "fixed-link.txt", under
> > -Documentation/devicetree/bindings/net/*.
> > +as specified by Documentation/devicetree/bindings/net/fixed-link.txt.
> >
> > Required:
> >
> > diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> > b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt index
> > 12b18f82d441..efa2c8b9b85a 100644
> > --- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> > @@ -3,7 +3,7 @@ Amlogic Meson AXG DWC PCIE SoC controller
> > Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI
> > core. It shares common functions with the PCIe DesignWare core driver and
> > inherits common properties defined in
> > -Documentation/devicetree/bindings/pci/designware-pci.txt.
> > +Documentation/devicetree/bindings/pci/designware-pcie.txt.
> >
> > Additional properties are described here:
> >
> > diff --git
> > a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> > b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt index
> > 7ef2dbe48e8a..14d2eee96b3d 100644
> > --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> > +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> > @@ -97,7 +97,7 @@ Second Level Nodes - Regulators
> > sent for this regulator including those which are
> for a
> > strictly lower power state.
> >
> > -Other properties defined in Documentation/devicetree/bindings/regulator.txt
> > +Other properties defined in
> > Documentation/devicetree/bindings/regulator/regulator.txt may also be used.
> > regulator-initial-mode and regulator-allowed-modes may be specified for
> > VRM regulators using mode values from
> > include/dt-bindings/regulator/qcom,rpmh-regulator.h.
> > regulator-allow-bypass diff --git
> > a/Documentation/devicetree/booting-without-of.txt
> > b/Documentation/devicetree/booting-without-of.txt index
> > e86bd2f64117..60f8640f2b2f 100644
> > --- a/Documentation/devicetree/booting-without-of.txt
> > +++ b/Documentation/devicetree/booting-without-of.txt
> > @@ -277,7 +277,7 @@ it with special cases.
> > the decompressor (the real mode entry point goes to the same 32bit
> > entry point once it switched into protected mode). That entry point
> > supports one calling convention which is documented in
> > - Documentation/x86/boot.txt
> > + Documentation/x86/boot.rst
> > The physical pointer to the device-tree block (defined in chapter II)
> > is passed via setup_data which requires at least boot protocol 2.09.
> > The type filed is defined as
> > diff --git a/Documentation/driver-api/gpio/board.rst
> > b/Documentation/driver-api/gpio/board.rst index b37f3f7b8926..ce91518bf9f4
> > 100644
> > --- a/Documentation/driver-api/gpio/board.rst
> > +++ b/Documentation/driver-api/gpio/board.rst
> > @@ -101,7 +101,7 @@ with the help of _DSD (Device Specific Data), introduced
> > in ACPI 5.1:: }
> >
> > For more information about the ACPI GPIO bindings see
> > -Documentation/acpi/gpio-properties.txt.
> > +Documentation/firmware-guide/acpi/gpio-properties.rst.
> >
> > Platform Data
> > -------------
> > diff --git a/Documentation/driver-api/gpio/consumer.rst
> > b/Documentation/driver-api/gpio/consumer.rst index
> > 5e4d8aa68913..fdecb6d711db 100644
> > --- a/Documentation/driver-api/gpio/consumer.rst
> > +++ b/Documentation/driver-api/gpio/consumer.rst
> > @@ -437,7 +437,7 @@ case, it will be handled by the GPIO subsystem
> > automatically. However, if the _DSD is not present, the mappings between
> > GpioIo()/GpioInt() resources and GPIO connection IDs need to be provided by
> > device drivers.
> >
> > -For details refer to Documentation/acpi/gpio-properties.txt
> > +For details refer to Documentation/firmware-guide/acpi/gpio-properties.rst
> >
> >
> > Interacting With the Legacy GPIO Subsystem
> > diff --git a/Documentation/firmware-guide/acpi/enumeration.rst
> > b/Documentation/firmware-guide/acpi/enumeration.rst index
> > 850be9696931..1252617b520f 100644
> > --- a/Documentation/firmware-guide/acpi/enumeration.rst
> > +++ b/Documentation/firmware-guide/acpi/enumeration.rst
> > @@ -339,7 +339,7 @@ a code like this::
> > There are also devm_* versions of these functions which release the
> > descriptors once the device is released.
> >
> > -See Documentation/acpi/gpio-properties.txt for more information about the
> > +See Documentation/firmware-guide/acpi/gpio-properties.rst for more
> > information about the _DSD binding related to GPIOs.
> >
> > MFD devices
> > diff --git a/Documentation/firmware-guide/acpi/method-tracing.rst
> > b/Documentation/firmware-guide/acpi/method-tracing.rst index
> > d0b077b73f5f..0aa7e2c5d32a 100644
> > --- a/Documentation/firmware-guide/acpi/method-tracing.rst
> > +++ b/Documentation/firmware-guide/acpi/method-tracing.rst
> > @@ -68,7 +68,7 @@ c. Filter out the debug layer/level matched logs when the
> > specified
> >
> > Where:
> > 0xXXXXXXXX/0xYYYYYYYY
> > - Refer to Documentation/acpi/debug.txt for possible debug layer/level
> > + Refer to Documentation/firmware-guide/acpi/debug.rst for possible
> > debug layer/level masking values.
> > \PPPP.AAAA.TTTT.HHHH
> > Full path of a control method that can be found in the ACPI namespace.
> > diff --git a/Documentation/i2c/instantiating-devices
> > b/Documentation/i2c/instantiating-devices index 0d85ac1935b7..5a3e2f331e8c
> > 100644
> > --- a/Documentation/i2c/instantiating-devices
> > +++ b/Documentation/i2c/instantiating-devices
> > @@ -85,7 +85,7 @@ Method 1c: Declare the I2C devices via ACPI
> > -------------------------------------------
> >
> > ACPI can also describe I2C devices. There is special documentation for this
> > -which is currently located at Documentation/acpi/enumeration.txt. +which
> > is currently located at Documentation/firmware-guide/acpi/enumeration.rst.
> >
> >
> > Method 2: Instantiate the devices explicitly
> > diff --git a/Documentation/sysctl/kernel.txt
> > b/Documentation/sysctl/kernel.txt index f0c86fbb3b48..92f7f34b021a 100644
> > --- a/Documentation/sysctl/kernel.txt
> > +++ b/Documentation/sysctl/kernel.txt
> > @@ -155,7 +155,7 @@ is 0x15 and the full version number is 0x234, this file
> > will contain the value 340 = 0x154.
> >
> > See the type_of_loader and ext_loader_type fields in
> > -Documentation/x86/boot.txt for additional information.
> > +Documentation/x86/boot.rst for additional information.
> >
> > ==============================================================
> >
> > @@ -167,7 +167,7 @@ The complete bootloader version number. In the example
> > above, this file will contain the value 564 = 0x234.
> >
> > See the type_of_loader and ext_loader_ver fields in
> > -Documentation/x86/boot.txt for additional information.
> > +Documentation/x86/boot.rst for additional information.
> >
> > ==============================================================
> >
> > diff --git a/Documentation/translations/it_IT/process/howto.rst
> > b/Documentation/translations/it_IT/process/howto.rst index
> > 9903ac7c566b..44e6077730e8 100644
> > --- a/Documentation/translations/it_IT/process/howto.rst
> > +++ b/Documentation/translations/it_IT/process/howto.rst
> > @@ -131,7 +131,7 @@ Di seguito una lista di file che sono presenti nei
> > sorgente del kernel e che "Linux kernel patch submission format"
> > http://linux.yyz.us/patch-format.html
> >
> > - :ref:`Documentation/process/translations/it_IT/stable-api-nonsense.rst
> > <it_stable_api_nonsense>` +
> > :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst
> > <it_stable_api_nonsense>`
> >
> > Questo file descrive la motivazioni sottostanti la conscia decisione di
> > non avere un API stabile all'interno del kernel, incluso cose come: diff
> > --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> > b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index
> > 48e88e5ad2c5..4f206cee31a7 100644
> > --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> > +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> > @@ -33,7 +33,7 @@ Regole sul tipo di patch che vengono o non vengono
> > accettate nei sorgenti - Non deve includere alcuna correzione "banale"
> > (correzioni grammaticali, pulizia dagli spazi bianchi, eccetera).
> > - Deve rispettare le regole scritte in
> > - :ref:`Documentation/translation/it_IT/process/submitting-patches.rst
> > <it_submittingpatches>` +
> > :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
> > <it_submittingpatches>` - Questa patch o una equivalente deve esistere già
> > nei sorgenti principali di Linux
> >
> > @@ -43,7 +43,7 @@ Procedura per sottomettere patch per i sorgenti -stable
> >
> > - Se la patch contiene modifiche a dei file nelle cartelle net/ o
> > drivers/net, allora seguite le linee guida descritte in
> > - :ref:`Documentation/translation/it_IT/networking/netdev-FAQ.rst
> > <it_netdev-FAQ>`; +
> > :ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst
> > <it_netdev-FAQ>`; ma solo dopo aver verificato al seguente indirizzo che la
> > patch non sia già in coda:
> >
> > https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=
> > *&q=&archive= diff --git
> > a/Documentation/translations/zh_CN/process/4.Coding.rst
> > b/Documentation/translations/zh_CN/process/4.Coding.rst index
> > 5301e9d55255..8bb777941394 100644
> > --- a/Documentation/translations/zh_CN/process/4.Coding.rst
> > +++ b/Documentation/translations/zh_CN/process/4.Coding.rst
> > @@ -241,7 +241,7 @@ scripts/coccinelle目录下已经打包了相当多的内核“语义补丁”
> >
> > 任何添加新用户空间界面的代码（包括新的sysfs或/proc文件）都应该包含该界面的
> > 文档，该文档使用户空间开发人员能够知道他们在使用什么。请参阅
> > -Documentation/abi/readme，了解如何格式化此文档以及需要提供哪些信息。
> > +Documentation/ABI/README，了解如何格式化此文档以及需要提供哪些信息。
> >
> > 文件 :ref:`Documentation/admin-guide/kernel-parameters.rst
> > <kernelparameters>` 描述了内核的所有引导时间参数。任何添加新参数的补丁都应该向该文件添加适当的
> > diff --git a/Documentation/x86/x86_64/5level-paging.rst
> > b/Documentation/x86/x86_64/5level-paging.rst index
> > ab88a4514163..44856417e6a5 100644
> > --- a/Documentation/x86/x86_64/5level-paging.rst
> > +++ b/Documentation/x86/x86_64/5level-paging.rst
> > @@ -20,7 +20,7 @@ physical address space. This "ought to be enough for
> > anybody" ©. QEMU 2.9 and later support 5-level paging.
> >
> > Virtual memory layout for 5-level paging is described in
> > -Documentation/x86/x86_64/mm.txt
> > +Documentation/x86/x86_64/mm.rst
> >
> >
> > Enabling 5-level paging
> > diff --git a/Documentation/x86/x86_64/boot-options.rst
> > b/Documentation/x86/x86_64/boot-options.rst index
> > 2f69836b8445..6a4285a3c7a4 100644
> > --- a/Documentation/x86/x86_64/boot-options.rst
> > +++ b/Documentation/x86/x86_64/boot-options.rst
> > @@ -9,7 +9,7 @@ only the AMD64 specific ones are listed here.
> >
> > Machine check
> > =============
> > -Please see Documentation/x86/x86_64/machinecheck for sysfs runtime
> > tunables. +Please see Documentation/x86/x86_64/machinecheck.rst for sysfs
> > runtime tunables.
> >
> > mce=off
> > Disable machine check
> > @@ -89,7 +89,7 @@ APICs
> > Don't use the local APIC (alias for i386 compatibility)
> >
> > pirq=...
> > - See Documentation/x86/i386/IO-APIC.txt
> > + See Documentation/x86/i386/IO-APIC.rst
> >
> > noapictimer
> > Don't set up the APIC timer
> > diff --git a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> > b/Documentation/x86/x86_64/fake-numa-for-cpusets.rst index
> > 74fbb78b3c67..04df57b9aa3f 100644
> > --- a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> > +++ b/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> > @@ -18,7 +18,7 @@ For more information on the features of cpusets, see
> > Documentation/cgroup-v1/cpusets.txt.
> > There are a number of different configurations you can use for your needs.
> > For more information on the numa=fake command line option and its various
> > ways of -configuring fake nodes, see
> > Documentation/x86/x86_64/boot-options.txt. +configuring fake nodes, see
> > Documentation/x86/x86_64/boot-options.rst.
> >
> > For the purposes of this introduction, we'll assume a very primitive NUMA
> > emulation setup of "numa=fake=4*512,". This will split our system memory
> > into diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5cfbea4ce575..a38d7273705a 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3874,7 +3874,7 @@
> > F: Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.txt
> > F: Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt
> > F: Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt
> > F: Documentation/devicetree/bindings/sound/cirrus,lochnagar.txt
> > -F: Documentation/hwmon/lochnagar
> > +F: Documentation/hwmon/lochnagar.rst
> >
> > CISCO FCOE HBA DRIVER
> > M: Satish Kharat <satishkh@cisco.com>
> > @@ -11272,7 +11272,7 @@ NXP FXAS21002C DRIVER
> > M: Rui Miguel Silva <rmfrfs@gmail.com>
> > L: linux-iio@vger.kernel.org
> > S: Maintained
> > -F: Documentation/devicetree/bindings/iio/gyroscope/fxas21002c.txt
> > +F: Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt
> > F: drivers/iio/gyro/fxas21002c_core.c
> > F: drivers/iio/gyro/fxas21002c.h
> > F: drivers/iio/gyro/fxas21002c_i2c.c
> > @@ -13043,7 +13043,7 @@ M: Niklas Cassel <niklas.cassel@linaro.org>
> > L: netdev@vger.kernel.org
> > S: Maintained
> > F: drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> > -F: Documentation/devicetree/bindings/net/qcom,dwmac.txt
> > +F: Documentation/devicetree/bindings/net/qcom,ethqos.txt
> >
> > QUALCOMM GENERIC INTERFACE I2C DRIVER
> > M: Alok Chauhan <alokc@codeaurora.org>
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 8869742a85df..0f220264cc23 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1263,7 +1263,7 @@ config SMP
> > uniprocessor machines. On a uniprocessor machine, the kernel
> > will run faster if you say N here.
> >
> > - See also <file:Documentation/x86/i386/IO-APIC.txt>,
> > + See also <file:Documentation/x86/i386/IO-APIC.rst>,
> > <file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO
> available at
> > <http://tldp.org/HOWTO/SMP-HOWTO.html>.
> >
> > diff --git a/arch/arm64/kernel/kexec_image.c
> > b/arch/arm64/kernel/kexec_image.c index 07bf740bea91..31cc2f423aa8 100644
> > --- a/arch/arm64/kernel/kexec_image.c
> > +++ b/arch/arm64/kernel/kexec_image.c
> > @@ -53,7 +53,7 @@ static void *image_load(struct kimage *image,
> >
> > /*
> > * We require a kernel with an unambiguous Image header. Per
> > - * Documentation/booting.txt, this is the case when image_size
> > + * Documentation/arm64/booting.txt, this is the case when
> image_size
> > * is non-zero (practically speaking, since v3.17).
> > */
> > h = (struct arm64_image_header *)kernel;
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 8c1c636308c8..e868d2bd48b8 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -898,7 +898,7 @@ config PPC_MEM_KEYS
> > page-based protections, but without requiring modification of
> the
> > page tables when an application changes protection domains.
> >
> > - For details, see Documentation/vm/protection-keys.rst
> > + For details, see Documentation/x86/protection-keys.rst
> >
> > If unsure, say y.
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 2bbbd4d1ba31..78fdf2dd71d1 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -395,7 +395,7 @@ config SMP
> > Y to "Enhanced Real Time Clock Support", below. The "Advanced
> Power
> > Management" code will be disabled if you say Y here.
> >
> > - See also <file:Documentation/x86/i386/IO-APIC.txt>,
> > + See also <file:Documentation/x86/i386/IO-APIC.rst>,
> > <file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO
> available at
> > <http://www.tldp.org/docs.html#howto>.
> >
> > @@ -1290,7 +1290,7 @@ config MICROCODE
> > the Linux kernel.
> >
> > The preferred method to load microcode from a detached initrd is
> > described - in Documentation/x86/microcode.txt. For that you
> need to
> > enable + in Documentation/x86/microcode.rst. For that you need to enable
> > CONFIG_BLK_DEV_INITRD in order for the loader to be able to scan the initrd
> > for microcode blobs.
> >
> > @@ -1329,7 +1329,7 @@ config MICROCODE_OLD_INTERFACE
> > It is inadequate because it runs too late to be able to properly
> > load microcode on a machine and it needs special tools. Instead,
> you
> > should've switched to the early loading method with the initrd
> or
> > - builtin microcode by now: Documentation/x86/microcode.txt
> > + builtin microcode by now: Documentation/x86/microcode.rst
> >
> > config X86_MSR
> > tristate "/dev/cpu/*/msr - Model-specific register support"
> > @@ -1478,7 +1478,7 @@ config X86_5LEVEL
> > A kernel with the option enabled can be booted on machines that
> > support 4- or 5-level paging.
> >
> > - See Documentation/x86/x86_64/5level-paging.txt for more
> > + See Documentation/x86/x86_64/5level-paging.rst for more
> > information.
> >
> > Say N if unsure.
> > @@ -1626,7 +1626,7 @@ config ARCH_MEMORY_PROBE
> > depends on X86_64 && MEMORY_HOTPLUG
> > help
> > This option enables a sysfs memory/probe interface for testing.
> > - See Documentation/memory-hotplug.txt for more information.
> > + See Documentation/admin-guide/mm/memory-hotplug.rst for more
> > information. If you are unsure how to answer this question, answer N.
> >
> > config ARCH_PROC_KCORE_TEXT
> > @@ -1783,7 +1783,7 @@ config MTRR
> > You can safely say Y even if your machine doesn't have MTRRs,
> you'll
> > just add about 9 KB to your kernel.
> >
> > - See <file:Documentation/x86/mtrr.txt> for more information.
> > + See <file:Documentation/x86/mtrr.rst> for more information.
> >
> > config MTRR_SANITIZER
> > def_bool y
> > @@ -1895,7 +1895,7 @@ config X86_INTEL_MPX
> > process and adds some branches to paths used during
> > exec() and munmap().
> >
> > - For details, see Documentation/x86/intel_mpx.txt
> > + For details, see Documentation/x86/intel_mpx.rst
> >
> > If unsure, say N.
> >
> > @@ -1911,7 +1911,7 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
> > page-based protections, but without requiring modification of
> the
> > page tables when an application changes protection domains.
> >
> > - For details, see Documentation/x86/protection-keys.txt
> > + For details, see Documentation/x86/protection-keys.rst
> >
> > If unsure, say y.
> >
> > diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> > index f730680dc818..59f598543203 100644
> > --- a/arch/x86/Kconfig.debug
> > +++ b/arch/x86/Kconfig.debug
> > @@ -156,7 +156,7 @@ config IOMMU_DEBUG
> > code. When you use it make sure you have a big enough
> > IOMMU/AGP aperture. Most of the options enabled by this can
> > be set more finegrained using the iommu= command line
> > - options. See Documentation/x86/x86_64/boot-options.txt for more
> > + options. See Documentation/x86/x86_64/boot-options.rst for more
> > details.
> >
> > config IOMMU_LEAK
> > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> > index 850b8762e889..90d791ca1a95 100644
> > --- a/arch/x86/boot/header.S
> > +++ b/arch/x86/boot/header.S
> > @@ -313,7 +313,7 @@ start_sys_seg: .word SYSSEG
> # obsolete and meaningless,
> > but just
> >
> > type_of_loader: .byte 0 # 0 means ancient
> bootloader, newer
> > # bootloaders know
> to change this.
> > - # See
> Documentation/x86/boot.txt for
> > + # See
> Documentation/x86/boot.rst for
> > # assigned ids
> >
> > # flags, unused bits must be zero (RFU) bit within loadflags
> > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> > index 11aa3b2afa4d..33f9fc38d014 100644
> > --- a/arch/x86/entry/entry_64.S
> > +++ b/arch/x86/entry/entry_64.S
> > @@ -8,7 +8,7 @@
> > *
> > * entry.S contains the system-call and fault low-level handling routines.
> > *
> > - * Some of this is documented in Documentation/x86/entry_64.txt
> > + * Some of this is documented in Documentation/x86/entry_64.rst
> > *
> > * A note on terminology:
> > * - iret frame: Architecture defined interrupt frame from SS to RIP
> > diff --git a/arch/x86/include/asm/bootparam_utils.h
> > b/arch/x86/include/asm/bootparam_utils.h index f6f6ef436599..101eb944f13c
> > 100644
> > --- a/arch/x86/include/asm/bootparam_utils.h
> > +++ b/arch/x86/include/asm/bootparam_utils.h
> > @@ -24,7 +24,7 @@ static void sanitize_boot_params(struct boot_params
> > *boot_params) * IMPORTANT NOTE TO BOOTLOADER AUTHORS: do not simply clear
> > * this field. The purpose of this field is to guarantee
> > * compliance with the x86 boot spec located in
> > - * Documentation/x86/boot.txt . That spec says that the
> > + * Documentation/x86/boot.rst . That spec says that the
> > * *whole* structure should be cleared, after which only the
> > * portion defined by struct setup_header (boot_params->hdr)
> > * should be copied in.
> > diff --git a/arch/x86/include/asm/page_64_types.h
> > b/arch/x86/include/asm/page_64_types.h index 793c14c372cb..288b065955b7
> > 100644
> > --- a/arch/x86/include/asm/page_64_types.h
> > +++ b/arch/x86/include/asm/page_64_types.h
> > @@ -48,7 +48,7 @@
> >
> > #define __START_KERNEL_map _AC(0xffffffff80000000, UL)
> >
> > -/* See Documentation/x86/x86_64/mm.txt for a description of the memory map.
> > */ +/* See Documentation/x86/x86_64/mm.rst for a description of the memory
> > map. */
> >
> > #define __PHYSICAL_MASK_SHIFT 52
> >
> > diff --git a/arch/x86/include/asm/pgtable_64_types.h
> > b/arch/x86/include/asm/pgtable_64_types.h index 88bca456da99..52e5f5f2240d
> > 100644
> > --- a/arch/x86/include/asm/pgtable_64_types.h
> > +++ b/arch/x86/include/asm/pgtable_64_types.h
> > @@ -103,7 +103,7 @@ extern unsigned int ptrs_per_p4d;
> > #define PGDIR_MASK (~(PGDIR_SIZE - 1))
> >
> > /*
> > - * See Documentation/x86/x86_64/mm.txt for a description of the memory map.
> > + * See Documentation/x86/x86_64/mm.rst for a description of the memory
> > map. *
> > * Be very careful vs. KASLR when changing anything here. The KASLR address
> > * range must not overlap with anything except the KASAN shadow area, which
> > diff --git a/arch/x86/kernel/cpu/microcode/amd.c
> > b/arch/x86/kernel/cpu/microcode/amd.c index e1f3ba19ba54..06d4e67f31ab
> > 100644
> > --- a/arch/x86/kernel/cpu/microcode/amd.c
> > +++ b/arch/x86/kernel/cpu/microcode/amd.c
> > @@ -61,7 +61,7 @@ static u8 amd_ucode_patch[PATCH_MAX_SIZE];
> >
> > /*
> > * Microcode patch container file is prepended to the initrd in cpio
> > - * format. See Documentation/x86/microcode.txt
> > + * format. See Documentation/x86/microcode.rst
> > */
> > static const char
> > ucode_path[] __maybe_unused = "kernel/x86/microcode/AuthenticAMD.bin";
> > diff --git a/arch/x86/kernel/kexec-bzimage64.c
> > b/arch/x86/kernel/kexec-bzimage64.c index 22f60dd26460..b07e7069b09e 100644
> > --- a/arch/x86/kernel/kexec-bzimage64.c
> > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > @@ -416,7 +416,7 @@ static void *bzImage64_load(struct kimage *image, char
> > *kernel, efi_map_offset = params_cmdline_sz;
> > efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16);
> >
> > - /* Copy setup header onto bootparams. Documentation/x86/boot.txt
> */
> > + /* Copy setup header onto bootparams. Documentation/x86/boot.rst */
> > setup_header_size = 0x0202 + kernel[0x0201] - setup_hdr_offset;
> >
> > /* Is there a limit on setup header size? */
> > diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> > index dcd272dbd0a9..f62b498b18fb 100644
> > --- a/arch/x86/kernel/pci-dma.c
> > +++ b/arch/x86/kernel/pci-dma.c
> > @@ -70,7 +70,7 @@ void __init pci_iommu_alloc(void)
> > }
> >
> > /*
> > - * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
> > + * See <Documentation/x86/x86_64/boot-options.rst> for the iommu kernel
> > * parameter documentation.
> > */
> > static __init int iommu_setup(char *p)
> > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> > index 7f61431c75fb..400c1ba033aa 100644
> > --- a/arch/x86/mm/tlb.c
> > +++ b/arch/x86/mm/tlb.c
> > @@ -711,7 +711,7 @@ void native_flush_tlb_others(const struct cpumask
> > *cpumask, }
> >
> > /*
> > - * See Documentation/x86/tlb.txt for details. We choose 33
> > + * See Documentation/x86/tlb.rst for details. We choose 33
> > * because it is large enough to cover the vast majority (at
> > * least 95%) of allocations, and is small enough that we are
> > * confident it will not cause too much overhead. Each single
> > diff --git a/arch/x86/platform/pvh/enlighten.c
> > b/arch/x86/platform/pvh/enlighten.c index 1861a2ba0f2b..c0a502f7e3a7 100644
> > --- a/arch/x86/platform/pvh/enlighten.c
> > +++ b/arch/x86/platform/pvh/enlighten.c
> > @@ -86,7 +86,7 @@ static void __init init_pvh_bootparams(bool xen_guest)
> > }
> >
> > /*
> > - * See Documentation/x86/boot.txt.
> > + * See Documentation/x86/boot.rst.
> > *
> > * Version 2.12 supports Xen entry point but we will use default
> x86/PC
> > * environment (i.e. hardware_subarch 0).
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index 283ee94224c6..2438f37f2ca1 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -333,7 +333,7 @@ config ACPI_CUSTOM_DSDT_FILE
> > depends on !STANDALONE
> > help
> > This option supports a custom DSDT by linking it into the
> kernel.
> > - See Documentation/acpi/dsdt-override.txt
> > + See Documentation/admin-guide/acpi/dsdt-override.rst
> >
> > Enter the full path name to the file which includes the AmlCode
> > or dsdt_aml_code declaration.
> > @@ -355,7 +355,7 @@ config ACPI_TABLE_UPGRADE
> > This option provides functionality to upgrade arbitrary ACPI
> tables
> > via initrd. No functional change if no ACPI tables are passed
> via
> > initrd, therefore it's safe to say Y.
> > - See Documentation/acpi/initrd_table_override.txt for details
> > + See Documentation/admin-guide/acpi/initrd_table_override.rst for
> details
> >
> > config ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD
> > bool "Override ACPI tables from built-in initrd"
> > @@ -365,7 +365,7 @@ config ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD
> > This option provides functionality to override arbitrary ACPI
> tables
> > from built-in uncompressed initrd.
> >
> > - See Documentation/acpi/initrd_table_override.txt for details
> > + See Documentation/admin-guide/acpi/initrd_table_override.rst for
> details
> >
> > config ACPI_DEBUG
> > bool "Debug Statements"
> > @@ -374,7 +374,7 @@ config ACPI_DEBUG
> > output and increases the kernel size by around 50K.
> >
> > Use the acpi.debug_layer and acpi.debug_level kernel command-
> line
> > - parameters documented in Documentation/acpi/debug.txt and
> > + parameters documented in Documentation/firmware-guide/acpi/
> debug.rst and
> > Documentation/admin-guide/kernel-parameters.rst to control the type and
> > amount of debug output.
> >
> > @@ -445,7 +445,7 @@ config ACPI_CUSTOM_METHOD
> > help
> > This debug facility allows ACPI AML methods to be inserted and/
> or
> > replaced without rebooting the system. For details refer to:
> > - Documentation/acpi/method-customizing.txt.
> > + Documentation/firmware-guide/acpi/method-customizing.rst.
> >
> > NOTE: This option is security sensitive, because it allows
> arbitrary
> > kernel memory to be written to by root (uid=0) users, allowing
> them
> > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
> > b/drivers/net/ethernet/faraday/ftgmac100.c index b17b79e612a3..ac6280ad43a1
> > 100644
> > --- a/drivers/net/ethernet/faraday/ftgmac100.c
> > +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> > @@ -1075,7 +1075,7 @@ static int ftgmac100_mii_probe(struct ftgmac100 *priv,
> > phy_interface_t intf) }
> >
> > /* Indicate that we support PAUSE frames (see comment in
> > - * Documentation/networking/phy.txt)
> > + * Documentation/networking/phy.rst)
> > */
> > phy_support_asym_pause(phydev);
> >
> > diff --git a/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> > b/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt index
> > 56af3f650fa3..89fb8e14676f 100644
> > --- a/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> > +++ b/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> > @@ -54,8 +54,8 @@ a limited few common behaviours and properties. This
> > allows us to define a simple interface consisting of a character device and
> > a set of sysfs files:
> >
> > See:
> > -Documentation/ABI/testing/sysfs-class-fieldbus-dev
> > -Documentation/ABI/testing/fieldbus-dev-cdev
> > +drivers/staging/fieldbus/Documentation/ABI/sysfs-class-fieldbus-dev
> > +drivers/staging/fieldbus/Documentation/ABI/fieldbus-dev-cdev
> >
> > Note that this simple interface does not provide a way to modify adapter
> > configuration settings. It is therefore useful only for adapters that get
> > their diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 1e3ed41ae1f3..69938dbae2d0 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -1694,7 +1694,7 @@ EXPORT_SYMBOL_GPL(vhost_dev_ioctl);
> >
> > /* TODO: This is really inefficient. We need something like get_user()
> > * (instruction directly accesses the data, with an exception table entry
> > - * returning -EFAULT). See Documentation/x86/exception-tables.txt.
> > + * returning -EFAULT). See Documentation/x86/exception-tables.rst.
> > */
> > static int set_bit_to_user(int nr, void __user *addr)
> > {
> > diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> > index de1804aeaf69..98e3db7a89cd 100644
> > --- a/include/acpi/acpi_drivers.h
> > +++ b/include/acpi/acpi_drivers.h
> > @@ -25,7 +25,7 @@
> > #define ACPI_MAX_STRING 80
> >
> > /*
> > - * Please update drivers/acpi/debug.c and Documentation/acpi/debug.txt
> > + * Please update drivers/acpi/debug.c and
> > Documentation/firmware-guide/acpi/debug.rst * if you add to this list.
> > */
> > #define ACPI_BUS_COMPONENT 0x00010000
> > diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h
> > index 1f966670c8dc..623eb58560b9 100644
> > --- a/include/linux/fs_context.h
> > +++ b/include/linux/fs_context.h
> > @@ -85,7 +85,7 @@ struct fs_parameter {
> > * Superblock creation fills in ->root whereas reconfiguration begins with
> > this * already set.
> > *
> > - * See Documentation/filesystems/mounting.txt
> > + * See Documentation/filesystems/mount_api.txt
> > */
> > struct fs_context {
> > const struct fs_context_operations *ops;
> > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> > index 47f58cfb6a19..df1318d85f7d 100644
> > --- a/include/linux/lsm_hooks.h
> > +++ b/include/linux/lsm_hooks.h
> > @@ -77,7 +77,7 @@
> > * state. This is called immediately after commit_creds().
> > *
> > * Security hooks for mount using fs_context.
> > - * [See also Documentation/filesystems/mounting.txt]
> > + * [See also Documentation/filesystems/mount_api.txt]
> > *
> > * @fs_context_dup:
> > * Allocate and attach a security structure to sc->security. This
> pointer
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index ee8d1f311858..6e5fb81bde4b 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -165,7 +165,7 @@ config MEMORY_HOTPLUG_DEFAULT_ONLINE
> > onlining policy (/sys/devices/system/memory/auto_online_blocks)
> which
> > determines what happens to newly added memory regions. Policy
> setting
> > can always be changed at runtime.
> > - See Documentation/memory-hotplug.txt for more information.
> > + See Documentation/admin-guide/mm/memory-hotplug.rst for more
> > information.
> >
> > Say Y here if you want all hot-plugged memory blocks to appear
> in
> > 'online' state by default.
> > diff --git a/security/Kconfig b/security/Kconfig
> > index aeac3676dd4d..6d75ed71970c 100644
> > --- a/security/Kconfig
> > +++ b/security/Kconfig
> > @@ -62,7 +62,7 @@ config PAGE_TABLE_ISOLATION
> > ensuring that the majority of kernel addresses are not mapped
> > into userspace.
> >
> > - See Documentation/x86/pti.txt for more details.
> > + See Documentation/x86/pti.rst for more details.
> >
> > config SECURITY_INFINIBAND
> > bool "Infiniband Security Hooks"
> > diff --git a/tools/include/linux/err.h b/tools/include/linux/err.h
> > index 2f5a12b88a86..25f2bb3a991d 100644
> > --- a/tools/include/linux/err.h
> > +++ b/tools/include/linux/err.h
> > @@ -20,7 +20,7 @@
> > * Userspace note:
> > * The same principle works for userspace, because 'error' pointers
> > * fall down to the unused hole far from user space, as described
> > - * in Documentation/x86/x86_64/mm.txt for x86_64 arch:
> > + * in Documentation/x86/x86_64/mm.rst for x86_64 arch:
> > *
> > * 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per
> > mm hole caused by [48:63] sign extension * ffffffffffe00000 -
> > ffffffffffffffff (=2 MB) unused hole
> > diff --git a/tools/objtool/Documentation/stack-validation.txt
> > b/tools/objtool/Documentation/stack-validation.txt index
> > 4dd11a554b9b..de094670050b 100644
> > --- a/tools/objtool/Documentation/stack-validation.txt
> > +++ b/tools/objtool/Documentation/stack-validation.txt
> > @@ -21,7 +21,7 @@ instructions). Similarly, it knows how to follow switch
> > statements, for which gcc sometimes uses jump tables.
> >
> > (Objtool also has an 'orc generate' subcommand which generates debuginfo
> > -for the ORC unwinder. See Documentation/x86/orc-unwinder.txt in the
> > +for the ORC unwinder. See Documentation/x86/orc-unwinder.rst in the
> > kernel tree for more details.)
> >
> >
> > @@ -101,7 +101,7 @@ b) ORC (Oops Rewind Capability) unwind table generation
> > band. So it doesn't affect runtime performance and it can be
> > reliable even when interrupts or exceptions are involved.
> >
> > - For more details, see Documentation/x86/orc-unwinder.txt.
> > + For more details, see Documentation/x86/orc-unwinder.rst.
> >
> > c) Higher live patching compatibility rate
> >
> > diff --git a/tools/testing/selftests/x86/protection_keys.c
> > b/tools/testing/selftests/x86/protection_keys.c index
> > 5d546dcdbc80..798a5ddeee55 100644
> > --- a/tools/testing/selftests/x86/protection_keys.c
> > +++ b/tools/testing/selftests/x86/protection_keys.c
> > @@ -1,6 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > - * Tests x86 Memory Protection Keys (see
> > Documentation/x86/protection-keys.txt) + * Tests x86 Memory Protection Keys
> > (see Documentation/x86/protection-keys.rst) *
> > * There are examples in here of:
> > * * how to set protection keys on memory
>
>
>
^ permalink raw reply
* Re: [PATCH 15/22] docs: it: license-rules.rst: get rid of warnings
From: Federico Vaga @ 2019-05-30 20:23 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <d4cbc22108a75339d1c1e18cbc6b6463e93ea782.1559171394.git.mchehab+samsung@kernel.org>
On Thursday, May 30, 2019 1:23:46 AM CEST Mauro Carvalho Chehab wrote:
> There's a wrong identation on a code block, and it tries to use
> a reference that was not defined at the Italian translation.
>
> Documentation/translations/it_IT/process/license-rules.rst:329: WARNING:
> Literal block expected; none found.
> Documentation/translations/it_IT/process/license-rules.rst:332: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:339: WARNING:
> Block quote ends without a blank line; unexpected unindent.
> Documentation/translations/it_IT/process/license-rules.rst:341: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:305: WARNING:
> Unknown target name: "metatags".
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../it_IT/process/license-rules.rst | 28 +++++++++----------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/translations/it_IT/process/license-rules.rst
> b/Documentation/translations/it_IT/process/license-rules.rst index
> f058e06996dc..06abeb7dd307 100644
> --- a/Documentation/translations/it_IT/process/license-rules.rst
> +++ b/Documentation/translations/it_IT/process/license-rules.rst
> @@ -303,7 +303,7 @@ essere categorizzate in:
> LICENSES/dual
>
> I file in questa cartella contengono il testo completo della rispettiva
> - licenza e i suoi `Metatags`_. I nomi dei file sono identici agli
> + licenza e i suoi `Metatags`. I nomi dei file sono identici agli
Remove 's' instead of '_' and then the link is correct
`Metatag`_
> identificatori di licenza SPDX che dovrebbero essere usati nei file
> sorgenti.
>
> @@ -326,19 +326,19 @@ essere categorizzate in:
>
> Esempio del formato del file::
>
> - Valid-License-Identifier: MPL-1.1
> - SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> - Usage-Guide:
> - Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for - dual-licensed files where the other license is GPL2 compatible. -
> If you end up using this it MUST be used together with a GPL2
> compatible - license using "OR".
> - To use the Mozilla Public License version 1.1 put the following SPDX
> - tag/value pair into a comment according to the placement guidelines in
> - the licensing rules documentation:
> - SPDX-License-Identifier: MPL-1.1
> - License-Text:
> - Full license text
> + Valid-License-Identifier: MPL-1.1
> + SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> + Usage-Guide:
> + Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for + dual-licensed files where the other license is GPL2 compatible.
> + If you end up using this it MUST be used together with a GPL2
> compatible + license using "OR".
> + To use the Mozilla Public License version 1.1 put the following SPDX
> + tag/value pair into a comment according to the placement guidelines
> in + the licensing rules documentation:
> + SPDX-License-Identifier: MPL-1.1
> + License-Text:
> + Full license text
^ permalink raw reply
* [PATCH v2 1/2] hwmon: pmbus: Add Infineon PXE1610 VR driver
From: Vijay Khemka @ 2019-05-30 23:11 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Jonathan Corbet, linux-hwmon,
linux-doc, linux-kernel
Cc: vijaykhemka, joel, linux-aspeed, sdasari, Greg Kroah-Hartman
Added pmbus driver for the new device Infineon pxe1610
voltage regulator. It also supports similar family device
PXE1110 and PXM1310.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
Changes in v2:
incorporated all the feedback from Guenter Roeck <linux@roeck-us.net>
drivers/hwmon/pmbus/Kconfig | 9 +++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/pxe1610.c | 139 ++++++++++++++++++++++++++++++++++
3 files changed, 149 insertions(+)
create mode 100644 drivers/hwmon/pmbus/pxe1610.c
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 30751eb9550a..338ef9b5a395 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -154,6 +154,15 @@ config SENSORS_MAX8688
This driver can also be built as a module. If so, the module will
be called max8688.
+config SENSORS_PXE1610
+ tristate "Infineon PXE1610"
+ help
+ If you say yes here you get hardware monitoring support for Infineon
+ PXE1610.
+
+ This driver can also be built as a module. If so, the module will
+ be called pxe1610.
+
config SENSORS_TPS40422
tristate "TI TPS40422"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 2219b9300316..b0fbd017a91a 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
obj-$(CONFIG_SENSORS_MAX8688) += max8688.o
+obj-$(CONFIG_SENSORS_PXE1610) += pxe1610.o
obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
obj-$(CONFIG_SENSORS_TPS53679) += tps53679.o
obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
diff --git a/drivers/hwmon/pmbus/pxe1610.c b/drivers/hwmon/pmbus/pxe1610.c
new file mode 100644
index 000000000000..ebe3f023f840
--- /dev/null
+++ b/drivers/hwmon/pmbus/pxe1610.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hardware monitoring driver for Infineon PXE1610
+ *
+ * Copyright (c) 2019 Facebook Inc
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include "pmbus.h"
+
+#define PXE1610_NUM_PAGES 3
+
+/* Identify chip parameters. */
+static int pxe1610_identify(struct i2c_client *client,
+ struct pmbus_driver_info *info)
+{
+ if (pmbus_check_byte_register(client, 0, PMBUS_VOUT_MODE)) {
+ u8 vout_mode;
+ int ret;
+
+ /* Read the register with VOUT scaling value.*/
+ ret = pmbus_read_byte_data(client, 0, PMBUS_VOUT_MODE);
+ if (ret < 0)
+ return ret;
+
+ vout_mode = ret & GENMASK(4, 0);
+
+ switch (vout_mode) {
+ case 1:
+ info->vrm_version = vr12;
+ break;
+ case 2:
+ info->vrm_version = vr13;
+ break;
+ default:
+ return -ENODEV;
+ }
+ }
+
+ return 0;
+}
+
+static struct pmbus_driver_info pxe1610_info = {
+ .pages = PXE1610_NUM_PAGES,
+ .format[PSC_VOLTAGE_IN] = linear,
+ .format[PSC_VOLTAGE_OUT] = vid,
+ .format[PSC_CURRENT_IN] = linear,
+ .format[PSC_CURRENT_OUT] = linear,
+ .format[PSC_TEMPERATURE] = linear,
+ .format[PSC_POWER] = linear,
+ .func[0] = PMBUS_HAVE_VIN
+ | PMBUS_HAVE_VOUT | PMBUS_HAVE_IIN
+ | PMBUS_HAVE_IOUT | PMBUS_HAVE_PIN
+ | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
+ | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT
+ | PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP,
+ .func[1] = PMBUS_HAVE_VIN
+ | PMBUS_HAVE_VOUT | PMBUS_HAVE_IIN
+ | PMBUS_HAVE_IOUT | PMBUS_HAVE_PIN
+ | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
+ | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT
+ | PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP,
+ .func[2] = PMBUS_HAVE_VIN
+ | PMBUS_HAVE_VOUT | PMBUS_HAVE_IIN
+ | PMBUS_HAVE_IOUT | PMBUS_HAVE_PIN
+ | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
+ | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT
+ | PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP,
+ .identify = pxe1610_identify,
+};
+
+static int pxe1610_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct pmbus_driver_info *info;
+ u8 buf[I2C_SMBUS_BLOCK_MAX];
+ int ret;
+
+ if (!i2c_check_functionality(
+ client->adapter,
+ I2C_FUNC_SMBUS_READ_BYTE_DATA
+ | I2C_FUNC_SMBUS_READ_WORD_DATA
+ | I2C_FUNC_SMBUS_READ_BLOCK_DATA))
+ return -ENODEV;
+
+ /*
+ * By default this device doesn't boot to page 0, so set page 0
+ * to access all pmbus registers.
+ */
+ i2c_smbus_write_byte_data(client, PMBUS_PAGE, 0);
+
+ /* Read Manufacturer id */
+ ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to read PMBUS_MFR_ID\n");
+ return ret;
+ }
+ if (ret != 2 || strncmp(buf, "XP", 2)) {
+ dev_err(&client->dev, "MFR_ID unrecognized\n");
+ return -ENODEV;
+ }
+
+ info = devm_kmemdup(&client->dev, &pxe1610_info,
+ sizeof(struct pmbus_driver_info),
+ GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ return pmbus_do_probe(client, id, info);
+}
+
+static const struct i2c_device_id pxe1610_id[] = {
+ {"pxe1610", 0},
+ {"pxe1110", 0},
+ {"pxm1310", 0},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, pxe1610_id);
+
+static struct i2c_driver pxe1610_driver = {
+ .driver = {
+ .name = "pxe1610",
+ },
+ .probe = pxe1610_probe,
+ .remove = pmbus_do_remove,
+ .id_table = pxe1610_id,
+};
+
+module_i2c_driver(pxe1610_driver);
+
+MODULE_AUTHOR("Vijay Khemka <vijaykhemka@fb.com>");
+MODULE_DESCRIPTION("PMBus driver for Infineon PXE1610, PXE1110 and PXM1310");
+MODULE_LICENSE("GPL");
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] Docs: hwmon: pmbus: Add PXE1610 driver
From: Vijay Khemka @ 2019-05-30 23:11 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Jonathan Corbet, linux-hwmon,
linux-doc, linux-kernel
Cc: vijaykhemka, joel, linux-aspeed, sdasari, Greg Kroah-Hartman
In-Reply-To: <20190530231159.222188-1-vijaykhemka@fb.com>
Added support for Infenion PXE1610 driver
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
Changes in v2:
incorporated all the feedback from Guenter Roeck <linux@roeck-us.net>
Documentation/hwmon/pxe1610 | 90 +++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
create mode 100644 Documentation/hwmon/pxe1610
diff --git a/Documentation/hwmon/pxe1610 b/Documentation/hwmon/pxe1610
new file mode 100644
index 000000000000..24825db8736f
--- /dev/null
+++ b/Documentation/hwmon/pxe1610
@@ -0,0 +1,90 @@
+Kernel driver pxe1610
+=====================
+
+Supported chips:
+ * Infinion PXE1610
+ Prefix: 'pxe1610'
+ Addresses scanned: -
+ Datasheet: Datasheet is not publicly available.
+
+ * Infinion PXE1110
+ Prefix: 'pxe1110'
+ Addresses scanned: -
+ Datasheet: Datasheet is not publicly available.
+
+ * Infinion PXM1310
+ Prefix: 'pxm1310'
+ Addresses scanned: -
+ Datasheet: Datasheet is not publicly available.
+
+Author: Vijay Khemka <vijaykhemka@fb.com>
+
+
+Description
+-----------
+
+PXE1610/PXE1110 are Multi-rail/Multiphase Digital Controllers
+and compliant to
+ -- Intel VR13 DC-DC converter specifications.
+ -- Intel SVID protocol.
+Used for Vcore power regulation for Intel VR13 based microprocessors
+ -- Servers, Workstations, and High-end desktops
+
+PXM1310 is a Multi-rail Controllers and it is compliant to
+ -- Intel VR13 DC-DC converter specifications.
+ -- Intel SVID protocol.
+Used for DDR3/DDR4 Memory power regulation for Intel VR13 and
+IMVP8 based systems
+
+
+Usage Notes
+-----------
+
+This driver does not probe for PMBus devices. You will have
+to instantiate devices explicitly.
+
+Example: the following commands will load the driver for an PXE1610
+at address 0x70 on I2C bus #4:
+
+# modprobe pxe1610
+# echo pxe1610 0x70 > /sys/bus/i2c/devices/i2c-4/new_device
+
+It can also be instantiated by declaring in device tree
+
+
+Sysfs attributes
+----------------
+
+curr1_label "iin"
+curr1_input Measured input current
+curr1_alarm Current high alarm
+
+curr[2-4]_label "iout[1-3]"
+curr[2-4]_input Measured output current
+curr[2-4]_crit Critical maximum current
+curr[2-4]_crit_alarm Current critical high alarm
+
+in1_label "vin"
+in1_input Measured input voltage
+in1_crit Critical maximum input voltage
+in1_crit_alarm Input voltage critical high alarm
+
+in[2-4]_label "vout[1-3]"
+in[2-4]_input Measured output voltage
+in[2-4]_lcrit Critical minimum output voltage
+in[2-4]_lcrit_alarm Output voltage critical low alarm
+in[2-4]_crit Critical maximum output voltage
+in[2-4]_crit_alarm Output voltage critical high alarm
+
+power1_label "pin"
+power1_input Measured input power
+power1_alarm Input power high alarm
+
+power[2-4]_label "pout[1-3]"
+power[2-4]_input Measured output power
+
+temp[1-3]_input Measured temperature
+temp[1-3]_crit Critical high temperature
+temp[1-3]_crit_alarm Chip temperature critical high alarm
+temp[1-3]_max Maximum temperature
+temp[1-3]_max_alarm Chip temperature high alarm
--
2.17.1
^ permalink raw reply related
* Re: [PATCH RFC] Rough draft document on merging and rebasing
From: Randy Dunlap @ 2019-05-31 0:45 UTC (permalink / raw)
To: Jonathan Corbet, Linus Torvalds; +Cc: LKML, linux-doc
In-Reply-To: <20190530135317.3c8d0d7b@lwn.net>
On 5/30/19 12:53 PM, Jonathan Corbet wrote:
> + git merge v5.2-rc1^0
That line is presented in my email client (Thunderbird) as
git merge v5.2-rc1{superscript 0}
Could you escape/quote it to prevent that?
> +
> +The "^0" will cause Git to do a fast-forward merge (which should be
> +possible in this situation), thus avoiding the addition of a spurious merge
> +commit.
--
~Randy
^ permalink raw reply
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: James Morris @ 2019-05-31 0:59 UTC (permalink / raw)
To: Kees Cook
Cc: Ke Wu, Jonathan Corbet, Serge E. Hallyn, linux-doc, linux-kernel,
linux-security-module
In-Reply-To: <201905301440.1DC01275@keescook>
On Thu, 30 May 2019, Kees Cook wrote:
> On Thu, May 30, 2019 at 12:22:08PM -0700, Ke Wu wrote:
> > Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> > make sure loaded kernel module and kernel image are trusted. This
> > patch adds a kernel command line option "loadpin.exclude" which
> > allows to exclude specific file types from LoadPin. This is useful
> > when people want to use different mechanisms to verify module and
> > kernel image while still use LoadPin to protect the integrity of
> > other files kernel loads.
> >
> > Signed-off-by: Ke Wu <mikewu@google.com>
>
> Thanks for the updates!
>
> Acked-by: Kees Cook <keescook@chromium.org>
>
> James, I don't have anything else planned for loadpin this cycle. Do you
> want me to push this to Linus in the next cycle, or do you want to take
> it into one of your trees?
You should push it directly to Linus.
>
> Thanks!
>
> -Kees
>
> > ---
> > Changelog since v1:
> > - Mark ignore_read_file_id with __ro_after_init.
> > - Mark parse_exclude() with __init.
> > - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
> >
> >
> > Documentation/admin-guide/LSM/LoadPin.rst | 10 ++++++
> > security/loadpin/loadpin.c | 38 +++++++++++++++++++++++
> > 2 files changed, 48 insertions(+)
> >
> > diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
> > index 32070762d24c..716ad9b23c9a 100644
> > --- a/Documentation/admin-guide/LSM/LoadPin.rst
> > +++ b/Documentation/admin-guide/LSM/LoadPin.rst
> > @@ -19,3 +19,13 @@ block device backing the filesystem is not read-only, a sysctl is
> > created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
> > a mutable filesystem means pinning is mutable too, but having the
> > sysctl allows for easy testing on systems with a mutable filesystem.)
> > +
> > +It's also possible to exclude specific file types from LoadPin using kernel
> > +command line option "``loadpin.exclude``". By default, all files are
> > +included, but they can be excluded using kernel command line option such
> > +as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
> > +different mechanisms such as ``CONFIG_MODULE_SIG`` and
> > +``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
> > +still use LoadPin to protect the integrity of other files kernel loads. The
> > +full list of valid file types can be found in ``kernel_read_file_str``
> > +defined in ``include/linux/fs.h``.
> > diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
> > index 055fb0a64169..d5f064644c54 100644
> > --- a/security/loadpin/loadpin.c
> > +++ b/security/loadpin/loadpin.c
> > @@ -45,6 +45,8 @@ static void report_load(const char *origin, struct file *file, char *operation)
> > }
> >
> > static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
> > +static char *exclude_read_files[READING_MAX_ID];
> > +static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
> > static struct super_block *pinned_root;
> > static DEFINE_SPINLOCK(pinned_root_spinlock);
> >
> > @@ -129,6 +131,13 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
> > struct super_block *load_root;
> > const char *origin = kernel_read_file_id_str(id);
> >
> > + /* If the file id is excluded, ignore the pinning. */
> > + if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
> > + ignore_read_file_id[id]) {
> > + report_load(origin, file, "pinning-excluded");
> > + return 0;
> > + }
> > +
> > /* This handles the older init_module API that has a NULL file. */
> > if (!file) {
> > if (!enforce) {
> > @@ -187,10 +196,37 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
> > LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
> > };
> >
> > +static void __init parse_exclude(void)
> > +{
> > + int i, j;
> > + char *cur;
> > +
> > + for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
> > + cur = exclude_read_files[i];
> > + if (!cur)
> > + break;
> > + if (*cur == '\0')
> > + continue;
> > +
> > + for (j = 0; j < ARRAY_SIZE(kernel_read_file_str); j++) {
> > + if (strcmp(cur, kernel_read_file_str[j]) == 0) {
> > + pr_info("excluding: %s\n",
> > + kernel_read_file_str[j]);
> > + ignore_read_file_id[j] = 1;
> > + /*
> > + * Can not break, because one read_file_str
> > + * may map to more than on read_file_id.
> > + */
> > + }
> > + }
> > + }
> > +}
> > +
> > static int __init loadpin_init(void)
> > {
> > pr_info("ready to pin (currently %senforcing)\n",
> > enforce ? "" : "not ");
> > + parse_exclude();
> > security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
> > return 0;
> > }
> > @@ -203,3 +239,5 @@ DEFINE_LSM(loadpin) = {
> > /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
> > module_param(enforce, int, 0);
> > MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
> > +module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
> > +MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");
> > --
> > 2.22.0.rc1.257.g3120a18244-goog
> >
>
>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: Kees Cook @ 2019-05-31 2:23 UTC (permalink / raw)
To: Ke Wu
Cc: James Morris, Jonathan Corbet, Serge E. Hallyn, linux-doc,
linux-kernel, linux-security-module
In-Reply-To: <alpine.LRH.2.21.1905310611190.26428@namei.org>
On Fri, May 31, 2019 at 06:11:44AM +1000, James Morris wrote:
> On Thu, 30 May 2019, Ke Wu wrote:
>
> > Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> > make sure loaded kernel module and kernel image are trusted. This
> > patch adds a kernel command line option "loadpin.exclude" which
> > allows to exclude specific file types from LoadPin. This is useful
> > when people want to use different mechanisms to verify module and
> > kernel image while still use LoadPin to protect the integrity of
> > other files kernel loads.
> >
> > Signed-off-by: Ke Wu <mikewu@google.com>
> > ---
> > Changelog since v1:
> > - Mark ignore_read_file_id with __ro_after_init.
> > - Mark parse_exclude() with __init.
> > - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
>
> Looks good!
>
> Reviewed-by: James Morris <jamorris@linux.microsoft.com>
Thanks! Applied to my for-next/loadpin branch at
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
and should be visible in linux-next in a few days.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: Ke Wu @ 2019-05-31 5:54 UTC (permalink / raw)
To: Kees Cook
Cc: James Morris, Jonathan Corbet, Serge E. Hallyn, linux-doc,
linux-kernel, linux-security-module
In-Reply-To: <201905301921.AE6D8D1@keescook>
Thanks for pushing the patch!
On Thu, May 30, 2019 at 7:23 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 31, 2019 at 06:11:44AM +1000, James Morris wrote:
> > On Thu, 30 May 2019, Ke Wu wrote:
> >
> > > Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> > > make sure loaded kernel module and kernel image are trusted. This
> > > patch adds a kernel command line option "loadpin.exclude" which
> > > allows to exclude specific file types from LoadPin. This is useful
> > > when people want to use different mechanisms to verify module and
> > > kernel image while still use LoadPin to protect the integrity of
> > > other files kernel loads.
> > >
> > > Signed-off-by: Ke Wu <mikewu@google.com>
> > > ---
> > > Changelog since v1:
> > > - Mark ignore_read_file_id with __ro_after_init.
> > > - Mark parse_exclude() with __init.
> > > - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
> >
> > Looks good!
> >
> > Reviewed-by: James Morris <jamorris@linux.microsoft.com>
>
> Thanks! Applied to my for-next/loadpin branch at
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
> and should be visible in linux-next in a few days.
>
> --
> Kees Cook
--
Ke Wu | Software Engineer | mikewu@google.com | Google Inc.
^ permalink raw reply
* Re: [PATCH 12/22] gpu: i915.rst: Fix references to renamed files
From: Jani Nikula @ 2019-05-31 7:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard, Sean Paul,
intel-gfx, dri-devel
In-Reply-To: <5ecde05364284f6845b651297fd9ce8225af2bcd.1559171394.git.mchehab+samsung@kernel.org>
On Wed, 29 May 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
>
> Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/gpu/i915.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 055df45596c1..38fefeb99bba 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
> Workarounds
> -----------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/selftest_workarounds.c
> :doc: Hardware workarounds
Thanks for the patch. The basename should remain the same here.
I can pick up the updated version via drm-intel.
BR,
Jani.
>
> Display Hardware Handling
> @@ -379,10 +379,10 @@ User Batchbuffer Execution
> Logical Rings, Logical Ring Contexts and Execlists
> --------------------------------------------------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :doc: Logical Rings, Logical Ring Contexts and Execlists
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :internal:
>
> Global GTT views
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH 12/22] gpu: i915.rst: Fix references to renamed files
From: Joonas Lahtinen @ 2019-05-31 9:02 UTC (permalink / raw)
To: Linux Doc Mailing List, Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Jani Nikula, Rodrigo Vivi, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard, Sean Paul,
intel-gfx, dri-devel
In-Reply-To: <5ecde05364284f6845b651297fd9ce8225af2bcd.1559171394.git.mchehab+samsung@kernel.org>
Quoting Mauro Carvalho Chehab (2019-05-30 02:23:43)
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
>
> Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/gpu/i915.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 055df45596c1..38fefeb99bba 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
> Workarounds
> -----------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/selftest_workarounds.c
This should be gt/intel_workarounds.c
Do you want me to merge this, or do you plan on merging through
documentation tree?
Regards, Joonas
^ permalink raw reply
* Re: [PATCH 2/3] x86: Move CPU feature test out of uaccess region
From: Marco Elver @ 2019-05-31 9:57 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Peter Zijlstra, Andrey Ryabinin, Dmitry Vyukov,
Alexander Potapenko, Andrey Konovalov, Mark Rutland,
Jonathan Corbet, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
the arch/x86 maintainers, Arnd Bergmann, Josh Poimboeuf,
open list:DOCUMENTATION, LKML, linux-arch, kasan-dev
In-Reply-To: <EE911EC6-344B-4EB2-90A4-B11E8D96BEDC@zytor.com>
On Wed, 29 May 2019 at 16:29, <hpa@zytor.com> wrote:
>
> On May 29, 2019 7:15:00 AM PDT, Marco Elver <elver@google.com> wrote:
> >This patch is a pre-requisite for enabling KASAN bitops
> >instrumentation:
> >moves boot_cpu_has feature test out of the uaccess region, as
> >boot_cpu_has uses test_bit. With instrumentation, the KASAN check would
> >otherwise be flagged by objtool.
> >
> >This approach is preferred over adding the explicit kasan_check_*
> >functions to the uaccess whitelist of objtool, as the case here appears
> >to be the only one.
> >
> >Signed-off-by: Marco Elver <elver@google.com>
> >---
> >v1:
> >* This patch replaces patch: 'tools/objtool: add kasan_check_* to
> > uaccess whitelist'
> >---
> > arch/x86/ia32/ia32_signal.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> >diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
> >index 629d1ee05599..12264e3c9c43 100644
> >--- a/arch/x86/ia32/ia32_signal.c
> >+++ b/arch/x86/ia32/ia32_signal.c
> >@@ -333,6 +333,7 @@ int ia32_setup_rt_frame(int sig, struct ksignal
> >*ksig,
> > void __user *restorer;
> > int err = 0;
> > void __user *fpstate = NULL;
> >+ bool has_xsave;
> >
> > /* __copy_to_user optimizes that into a single 8 byte store */
> > static const struct {
> >@@ -352,13 +353,19 @@ int ia32_setup_rt_frame(int sig, struct ksignal
> >*ksig,
> > if (!access_ok(frame, sizeof(*frame)))
> > return -EFAULT;
> >
> >+ /*
> >+ * Move non-uaccess accesses out of uaccess region if not strictly
> >+ * required; this also helps avoid objtool flagging these accesses
> >with
> >+ * instrumentation enabled.
> >+ */
> >+ has_xsave = boot_cpu_has(X86_FEATURE_XSAVE);
> > put_user_try {
> > put_user_ex(sig, &frame->sig);
> > put_user_ex(ptr_to_compat(&frame->info), &frame->pinfo);
> > put_user_ex(ptr_to_compat(&frame->uc), &frame->puc);
> >
> > /* Create the ucontext. */
> >- if (boot_cpu_has(X86_FEATURE_XSAVE))
> >+ if (has_xsave)
> > put_user_ex(UC_FP_XSTATE, &frame->uc.uc_flags);
> > else
> > put_user_ex(0, &frame->uc.uc_flags);
>
> This was meant to use static_cpu_has(). Why did that get dropped?
I couldn't find any mailing list thread referring to why this doesn't
use static_cpu_has, do you have any background?
static_cpu_has also solves the UACCESS warning.
If you confirm it is safe to change to static_cpu_has(), I will change
this patch. Note that I should then also change
arch/x86/kernel/signal.c to mirror the change for 32bit (although
KASAN is not supported for 32bit x86).
Thanks,
-- Marco
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox