* Re: [PATCH v6] Documentation/checkpatch: Prefer stracpy over strcpy/strlcpy/strncpy.
From: Kees Cook @ 2019-07-25 18:50 UTC (permalink / raw)
To: NitinGote; +Cc: joe, corbet, akpm, apw, linux-doc, kernel-hardening
In-Reply-To: <20190725112219.6244-1-nitin.r.gote@intel.com>
On Thu, Jul 25, 2019 at 04:52:19PM +0530, NitinGote wrote:
> From: Nitin Gote <nitin.r.gote@intel.com>
>
> Added check in checkpatch.pl to deprecate strcpy(), strlcpy() and
> strncpy() in favor of stracpy().
stracpy() is preferred when the destination is a char array (rather than
a string pointer), so that likely needs to be clarified.
-Kees
>
> Updated Documentation/process/deprecated.rst for stracpy().
>
> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
> ---
> Change log:
> v5->v6
> - Used stracpy() instead of strscpy().
>
> v4->v5
> - Change the subject line as per review comment.
> - v5 is Reviewed-by: Kees Cook <keescook@chromium.org>
>
> v3->v4
> - Removed "c:func:" from deprecated.rst as per review comment.
>
> v2->v3
> - Avoided use of $check in implementation.
> - Incorporated trivial comments.
>
> v1->v2
> - For string related apis, created different %deprecated_string_api
> and these will get emitted at CHECK Level using command line option
> -f/--file to avoid bad patched from novice script users.
>
> Documentation/process/deprecated.rst | 10 +++++-----
> scripts/checkpatch.pl | 24 ++++++++++++++++++++++++
> 2 files changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index 49e0f64a3427..709662c71a1a 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -84,7 +84,7 @@ buffer. This could result in linear overflows beyond the
> end of the buffer, leading to all kinds of misbehaviors. While
> `CONFIG_FORTIFY_SOURCE=y` and various compiler flags help reduce the
> risk of using this function, there is no good reason to add new uses of
> -this function. The safe replacement is :c:func:`strscpy`.
> +this function. The safe replacement is stracpy().
>
> strncpy() on NUL-terminated strings
> -----------------------------------
> @@ -93,9 +93,9 @@ will be NUL terminated. This can lead to various linear read overflows
> and other misbehavior due to the missing termination. It also NUL-pads the
> destination buffer if the source contents are shorter than the destination
> buffer size, which may be a needless performance penalty for callers using
> -only NUL-terminated strings. The safe replacement is :c:func:`strscpy`.
> -(Users of :c:func:`strscpy` still needing NUL-padding will need an
> -explicit :c:func:`memset` added.)
> +only NUL-terminated strings. In this case, the safe replacement is
> +stracpy(). If, however, the destination buffer still needs NUL-padding,
> +the safe replacement is stracpy_pad().
>
> If a caller is using non-NUL-terminated strings, :c:func:`strncpy()` can
> still be used, but destinations should be marked with the `__nonstring
> @@ -107,7 +107,7 @@ strlcpy()
> :c:func:`strlcpy` reads the entire source buffer first, possibly exceeding
> the given limit of bytes to copy. This is inefficient and can lead to
> linear read overflows if a source string is not NUL-terminated. The
> -safe replacement is :c:func:`strscpy`.
> +safe replacement is stracpy().
>
> Variable Length Arrays (VLAs)
> -----------------------------
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 342c7c781ba5..dddf5adf1aac 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -605,6 +605,20 @@ foreach my $entry (keys %deprecated_apis) {
> }
> $deprecated_apis_search = "(?:${deprecated_apis_search})";
>
> +our %deprecated_string_apis = (
> + "strcpy" => "stracpy",
> + "strlcpy" => "stracpy",
> + "strncpy" => "stracpy - for non-NUL-terminated uses, strncpy dest should be __nonstring",
> +);
> +
> +#Create a search pattern for all these strings apis to speed up a loop below
> +our $deprecated_string_apis_search = "";
> +foreach my $entry (keys %deprecated_string_apis) {
> + $deprecated_string_apis_search .= '|' if ($deprecated_string_apis_search ne "");
> + $deprecated_string_apis_search .= $entry;
> +}
> +$deprecated_string_apis_search = "(?:${deprecated_string_apis_search})";
> +
> our $mode_perms_world_writable = qr{
> S_IWUGO |
> S_IWOTH |
> @@ -6446,6 +6460,16 @@ sub process {
> "Deprecated use of '$deprecated_api', prefer '$new_api' instead\n" . $herecurr);
> }
>
> +# check for string deprecated apis
> + if ($line =~ /\b($deprecated_string_apis_search)\b\s*\(/) {
> + my $deprecated_string_api = $1;
> + my $new_api = $deprecated_string_apis{$deprecated_string_api};
> + my $msg_level = \&WARN;
> + $msg_level = \&CHK if ($file);
> + &{$msg_level}("DEPRECATED_API",
> + "Deprecated use of '$deprecated_string_api', prefer '$new_api' instead\n" . $herecurr);
> + }
> +
> # check for various structs that are normally const (ops, kgdb, device_tree)
> # and avoid what seem like struct definitions 'struct foo {'
> if ($line !~ /\bconst\b/ &&
> --
> 2.17.1
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v6] Documentation/checkpatch: Prefer stracpy over strcpy/strlcpy/strncpy.
From: Joe Perches @ 2019-07-25 19:19 UTC (permalink / raw)
To: Kees Cook, NitinGote; +Cc: corbet, akpm, apw, linux-doc, kernel-hardening
In-Reply-To: <201907251149.B7FD8631@keescook>
On Thu, 2019-07-25 at 11:50 -0700, Kees Cook wrote:
> On Thu, Jul 25, 2019 at 04:52:19PM +0530, NitinGote wrote:
> > From: Nitin Gote <nitin.r.gote@intel.com>
> >
> > Added check in checkpatch.pl to deprecate strcpy(), strlcpy() and
> > strncpy() in favor of stracpy().
>
> stracpy() is preferred when the destination is a char array (rather than
> a string pointer), so that likely needs to be clarified.
[]
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> > @@ -605,6 +605,20 @@ foreach my $entry (keys %deprecated_apis) {
> > }
> > $deprecated_apis_search = "(?:${deprecated_apis_search})";
> >
> > +our %deprecated_string_apis = (
> > + "strcpy" => "stracpy",
> > + "strlcpy" => "stracpy",
> > + "strncpy" => "stracpy - for non-NUL-terminated uses, strncpy dest should be __nonstring",
> > +);
Maybe:
our %deprecated_string_apis = (
"strcpy" => "stracpy or strscpy",
"strlcpy" => "stracpy or strscpy",
"strncpy" => "stracpy or strscpy - for non-NUL-terminated uses, strncpy dest should be __nonstring",
);
^ permalink raw reply
* Re: [PATCH 0/4] Remove elevator kernel parameter
From: Marcos Paulo de Souza @ 2019-07-25 20:04 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-block, linux-doc
In-Reply-To: <20190714053453.1655-1-marcos.souza.org@gmail.com>
Hi Jens,
there are two reviewers for this patchset, can you take a look?
Thanks,
Marcos
On Sun, Jul 14, 2019 at 02:34:49AM -0300, Marcos Paulo de Souza wrote:
> After the first patch sent[1], together with some background from Jens[2], this
> patchset aims to remove completely elevator kernel parameter, since it is not
> being used since blk-mq was set by default.
>
> Along with elevator code, some documentation was also updated to remove elevator
> references.
>
> Please review, thanks.
>
> [1]: https://lkml.org/lkml/2019/7/12/1008
> [2]: https://lkml.org/lkml/2019/7/13/232
>
> Marcos Paulo de Souza (4):
> block: elevator.c: Remove now unused elevator= argument
> kernel-parameters.txt: Remove elevator argument
> Documenation: switching-sched: Remove notes about elevator argument
> Documentation:kernel-per-CPU-kthreads.txt: Remove reference to
> elevator=
>
> Documentation/admin-guide/kernel-parameters.txt | 6 ------
> Documentation/block/switching-sched.txt | 4 ----
> Documentation/kernel-per-CPU-kthreads.txt | 8 +++-----
> block/elevator.c | 14 --------------
> 4 files changed, 3 insertions(+), 29 deletions(-)
>
> --
> 2.22.0
>
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-07-25 20:21 UTC (permalink / raw)
To: Petr Mladek
Cc: Stephen Boyd, Jeff Dike, Kevin Hilman, Logan Gunthorpe,
Michael Ellerman, Daniel Vetter, Amir Goldstein, Frank Rowand,
Steven Rostedt, Kees Cook, David Rientjes, kunit-dev,
Kieran Bingham, Peter Zijlstra, Randy Dunlap, Joel Stanley,
Luis Chamberlain, Rob Herring, shuah, wfg, Greg KH, Julia Lawall,
linux-nvdimm, dri-devel, linux-um, Sasha Levin, Theodore Ts'o,
Richard Weinberger, Dan Carpenter, Knut Omang, Josh Poimboeuf,
Masahiro Yamada, Timothy Bird, devicetree,
open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <20190724073125.xyzfywctrcvg6fmh@pathway.suse.cz>
On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> > Quoting Brendan Higgins (2019-07-22 15:30:49)
> > > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > >
> > > >
> > > > What's the calling context of the assertions and expectations? I still
> > > > don't like the fact that string stream needs to allocate buffers and
> > > > throw them into a list somewhere because the calling context matters
> > > > there.
> > >
> > > The calling context is the same as before, which is anywhere.
> >
> > Ok. That's concerning then.
> >
> > >
> > > > I'd prefer we just wrote directly to the console/log via printk
> > > > instead. That way things are simple because we use the existing
> > > > buffering path of printk, but maybe there's some benefit to the string
> > > > stream that I don't see? Right now it looks like it builds a string and
> > > > then dumps it to printk so I'm sort of lost what the benefit is over
> > > > just writing directly with printk.
> > >
> > > It's just buffering it so the whole string gets printed uninterrupted.
> > > If we were to print out piecemeal to printk, couldn't we have another
> > > call to printk come in causing it to garble the KUnit message we are
> > > in the middle of printing?
> >
> > Yes, printing piecemeal by calling printk many times could lead to
> > interleaving of messages if something else comes in such as an interrupt
> > printing something. Printk has some support to hold "records" but I'm
> > not sure how that would work here because KERN_CONT talks about only
> > being used early on in boot code. I haven't looked at printk in detail
> > though so maybe I'm all wrong and KERN_CONT just works?
>
> KERN_CONT does not guarantee that the message will get printed
> together. The pieces get interleaved with messages printed in
> parallel.
>
> Note that KERN_CONT was originally really meant to be used only during
> boot. It was later used more widely and ended in the best effort category.
>
> There were several attempts to make it more reliable. But it was
> always either too complicated or error prone or both.
>
> You need to use your own buffering if you rely want perfect output.
> The question is if it is really worth the complexity. Also note that
> any buffering reduces the chance that the messages will reach
> the console.
Seems like that settles it then. Thanks!
> BTW: There is a work in progress on a lockless printk ring buffer.
> It will make printk() more secure regarding deadlocks. But it might
> make transparent handling of continuous lines even more tricky.
>
> I guess that local buffering, before calling printk(), will be
> even more important then. Well, it might really force us to create
> an API for it.
Cool! Can you CC me on that discussion?
> > Can printk be called once with whatever is in the struct? Otherwise if
> > this is about making printk into a structured log then maybe printk
> > isn't the proper solution anyway. Maybe a dev interface should be used
> > instead that can handle starting and stopping tests (via ioctl) in
> > addition to reading test results, records, etc. with read() and a
> > clearing of the records. Then the seqfile API works naturally. All of
> > this is a bit premature, but it looks like you're going down the path of
> > making something akin to ftrace that stores binary formatted
> > assertion/expectation records in a lockless ring buffer that then
> > formats those records when the user asks for them.
>
> IMHO, ftrace postpones the text formatting primary because it does not
> not want to slow down the traced code more than necessary. It is yet
> another layer and there should be some strong reason for it.
Noted. Yeah, I would prefer avoiding printing out the info at a separate time.
> > I can imagine someone wanting to write unit tests that check conditions
> > from a simulated hardirq context via irq works (a driver mock
> > framework?), so this doesn't seem far off.
>
> Note that stroring the messages into the printk log is basically safe in any
> context. It uses temporary per-CPU buffers for recursive messages and
> in NMI. The only problem is panic() when some CPU gets stuck with the
> lock taken. This will get solved by the lockless ringbuffer. Also
> the temporary buffers will not be necessary any longer.
Sure, I think Stephen's concern is all the supporting code that is
involved. Not printk specifically. It just means a lot more of KUnit
has to be IRQ safe.
> Much bigger problems are with consoles. There are many of them. It
> means a lot of code and more locks involved, including scheduler
> locks. Note that console lock is a semaphore.
That shouldn't affect us though, right? As long as we continue to use
the printk interface?
^ permalink raw reply
* Re: [PATCH 10/22] docs: openrisc: convert to ReST and add to documentation body
From: Stafford Horne @ 2019-07-25 21:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jonathan Corbet, Jonas Bonn, Stefan Kristiansson, linux-doc,
openrisc
In-Reply-To: <353497a08f6c01f2433174acbe35dc5991a51697.1563792334.git.mchehab+samsung@kernel.org>
On Mon, Jul 22, 2019 at 08:07:37AM -0300, Mauro Carvalho Chehab wrote:
> Manually convert the two openRisc documents to ReST, adding them
> to the Linux documentation body.
Thanks for doing this, the below looks fine.
Acked-by: Stafford Horne <shorne@gmail.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/index.rst | 1 +
> Documentation/openrisc/index.rst | 18 +++++++++++++
> .../openrisc/{README => openrisc_port.rst} | 25 +++++++++++++------
> Documentation/openrisc/{TODO => todo.rst} | 9 ++++---
> 4 files changed, 43 insertions(+), 10 deletions(-)
> create mode 100644 Documentation/openrisc/index.rst
> rename Documentation/openrisc/{README => openrisc_port.rst} (80%)
> rename Documentation/openrisc/{TODO => todo.rst} (78%)
>
^ permalink raw reply
* Re: [PATCH] Documentation/admin-guide: Embargoed hardware security issues
From: Jonathan Corbet @ 2019-07-25 21:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, security, linux-doc, Thomas Gleixner, Jiri Kosina,
Mauro Carvalho Chehab
In-Reply-To: <20190725130113.GA12932@kroah.com>
On Thu, 25 Jul 2019 15:01:13 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> To address the requirements of embargoed hardware issues, like Meltdown,
> Spectre, L1TF, etc. it is necessary to define and document a process for
> handling embargoed hardware security issues.
>
> Following the discussion at the maintainer summit 2018 in Edinburgh
> (https://lwn.net/Articles/769417/) the volunteered people have worked
> out a process and a Memorandum of Understanding. The latter addresses
> the fact that the Linux kernel community cannot sign NDAs for various
> reasons.
>
[...]
> Documentation/admin-guide/embargoed-hardware-issues.rst | 281 ++++++++++++++++
> Documentation/admin-guide/index.rst | 1
> 2 files changed, 282 insertions(+)
So I would argue that the admin guide (which is aimed at sysadmins) is the
wrong place for this document. It's process information and is best placed
in the process manual (Documentation/process) IMO. (Yes, I know
security-bugs.rst is in the admin guide; I remember there was a discussion
at the time and it ended up there, but I'm not really sure that's right
either).
> Note, this document has gone through numerous reviews by a number of
> kernel developers, developers at some of the Linux distros, as well as
> all of the lawyers from almost all open source-related companies. It's
> been sitting on my local drive with no comments for a few months now,
> and it's about time to get this out and merged properly.
>
> If anyone has any final comments, please let me know.
I do think it could benefit from a pass for basic language issues; I can do
that if such an effort would be welcome.
> If anyone from any company listed below wishes to add their name to the
> document, please send a follow-on patch and I will be glad to add it to
> the series. I had a number of "I'll sign up" type comments from
> different people, but I want something with a "s-o-b" to keep people on
> the hook for this, so I did not add their name to the file without that.
>
> thanks,
>
> greg k-h
>
>
>
> --- /dev/null
> +++ b/Documentation/admin-guide/embargoed-hardware-issues.rst
> @@ -0,0 +1,281 @@
> +.. _embargoedhardwareissues:
This label isn't used anywhere.
> +Embargoed hardware issues
> +=========================
> +
> +Scope
> +-----
> +
> +Hardware issues which result in security problems are a different category
> +of security bugs than pure software bugs which only affect the Linux
> +kernel.
> +
> +Hardware issues like Meltdown, Spectre, L1TF etc. must be treated
> +differently because they usually affect all Operating Systems (“OS“) and
Somebody may well complain about the "smart quotes" here; non-ascii stuff
has led to unhappiness in the past.
> +therefore need coordination across different OS vendors, distributions,
> +hardware vendors and other parties. For some of the issues, software
> +mitigations can depend on microcode or firmware updates, which need further
> +coordination.
> +
> +.. _Contact:
> +
> +Contact
> +-------
> +
> +The Linux kernel hardware security team is separate from the regular Linux
> +kernel security team.
> +
> +The team is only handling the coordination of embargoed hardware security
s/is only handling/only handles/
> +issues. Reports of pure software security bugs in the Linux kernel are not
> +handled by this team and the reporter will be guided to contact the regular
> +Linux kernel security team (:ref:`Documentation/admin-guide/
> +<securitybugs>`) instead.
> +
> +The team can be contacted by email at <hardware-security@kernel.org>. This
> +is a private list of security officers who will help you to coordinate an
> +issue according to our documented process.
> +
> +The list is encrypted and email to the list can be sent by either PGP or
> +S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME
> +certificate. The list's PGP key and S/MIME certificate are available from
> +https://www.kernel.org/....
Somebody needs to fill in some dots there...:)
> +While hardware security issues are often handled by the affected hardware
> +vendor, we welcome contact from researchers or individuals who identified a
who *have* identified
> +potential hardware flaw.
> +
> +Hardware security officers
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The current team of hardware security officers:
> +
> + - Linus Torvalds (Linux Foundation Fellow)
> + - Greg Kroah-Hartman (Linux Foundation Fellow)
> + - Thomas Gleixner (Linux Foundation Fellow)
> +
> +Operation of mailing-lists
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
I would de-hyphenate "mailing list" throughout. But that's me.
> +The encrypted mailing-lists which are used in our process are hosted on
> +Linux Foundation's IT infrastructure. By providing this service Linux
> +Foundation's director of IT Infrastructure security technically has the
> +ability to access the embargoed information, but is obliged to
> +confidentiality by his employment contract. Linux Foundation's director of
> +IT Infrastructure security is also responsible for the kernel.org
> +infrastructure.
> +
> +The Linux Foundation's current director of IT Infrastructure security is
> +Konstantin Ryabitsev.
> +
> +
> +Non-disclosure agreements
> +-------------------------
> +
> +The Linux kernel hardware security team is not a formal body and therefore
> +unable to enter into any non-disclosure agreements. The kernel community
> +is aware of the sensitive nature of such issues and offers a Memorandum of
> +Understanding instead.
> +
> +
> +Memorandum of Understanding
> +---------------------------
> +
> +The Linux kernel community has a deep understanding of the requirement to
> +keep hardware security issues under embargo for coordination between
> +different OS vendors, distributors, hardware vendors and other parties.
> +
> +The Linux kernel community has successfully handled hardware security
> +issues in the past and has the necessary mechanisms in place to allow
> +community compliant development under embargo restrictions.
> +
> +The Linux kernel community has a dedicated hardware security team for
> +initial contact, which oversees the process of handling such issues under
> +embargo rules.
> +
> +The hardware security team identifies the developers (domain experts) which
> +form the initial response team for a particular issue. The initial response
s/which form/who will form/
> +team can bring in further developers (domain experts) to address the issue
> +in the best technical way.
Does the reporter get any say in who can be in this group? That should
probably be made explicit either way.
> +All involved developers pledge to adhere to the embargo rules and to keep
> +the received information confidential. Violation of the pledge will lead to
> +immediate exclusion from the current issue and removal from all related
> +mailing-lists. In addition, the hardware security team will also exclude
> +the offender from future issues. The impact of this consequence is a highly
> +effective deterrent in our community. In case a violation happens the
> +hardware security team will inform the involved parties immediately. If you
> +or anyone becomes aware of a potential violation, please report it
> +immediately to the Hardware security officers.
> +
> +
> +Process
> +^^^^^^^
> +
> +Due to the globally distributed nature of Linux kernel development, face to
> +face meetings are almost impossible to address hardware security issues.
face-to-face
> +Phone conferences are hard to coordinate due to time zones and other
> +factors and should be only used when absolutely necessary. Encrypted email
> +has been proven to be the most effective and secure communication method
> +for these types of issues.
> +
> +Start of Disclosure
> +"""""""""""""""""""
> +
> +Disclosure starts by contacting the Linux kernel hardware security team by
> +email. This initial contact should contain a description of the problem and
> +a list of any known affected hardware. If your organization builds or
> +distributes the affected hardware, we encourage you to also consider what
> +other hardware could be affected.
> +
> +The hardware security team will provide a per incident specific encrypted
s/per incident specific/incident-specific/
> +mailing-list which will be used for initial discussion with the reporter,
> +further disclosure and coordination.
> +
> +The hardware security team will provide the disclosing party a list of
> +developers (domain experts) who should be informed initially about the
> +issue after confirming with the developers that they will adhere to this
> +Memorandum of Understanding and the documented process. These developers
> +form the initial response team and will be responsible for handling the
> +issue after initial contact. The hardware security team is supporting the
> +response team, but is not necessarily involved in the mitigation
> +development process.
Again, "should be informed" is conditional, suggesting that the reporter
might have some sort of veto power. But the actual policy is not clear.
> +While individual developers might be covered by a non-disclosure agreement
> +via their employer, they cannot enter individual non-disclosure agreements
> +in their role as Linux kernel developers. They will, however, adhere to
> +this documented process and the Memorandum of Understanding.
They will *agree to* adhere ... We expect that actual adherence will be
the case but there is no way (even if an NDA were involved) to guarantee
that.
> +Disclosure
> +""""""""""
> +
> +The disclosing party provides detailed information to the initial response
> +team via the specific encrypted mailing-list.
> +
> +From our experience the technical documentation of these issues is usually
> +a sufficient starting point and further technical clarification is best
> +done via email.
> +
> +Mitigation development
> +""""""""""""""""""""""
> +
> +The initial response team sets up an encrypted mailing-list or repurposes
> +an existing one if appropriate. The disclosing party should provide a list
> +of contacts for all other parties who have already been, or should be
> +informed about the issue. The response team contacts these parties so they
> +can name experts who should be subscribed to the mailing-list.
> +
> +Using a mailing-list is close to the normal Linux development process and
> +has been successfully used in developing mitigations for various hardware
> +security issues in the past.
> +
> +The mailing-list operates in the same way as normal Linux development.
> +Patches are posted, discussed and reviewed and if agreed on applied to a
> +non-public git repository which is only accessible to the participating
> +developers via a secure connection. The repository contains the main
> +development branch against the mainline kernel and backport branches for
> +stable kernel versions as necessary.
Do we want to envision a KPTI-like situation where the mitigation can be
developed publicly? Or perhaps just handle any such case if and when it
ever arises?
> +The initial response team will identify further experts from the Linux
> +kernel developer community as needed and inform the disclosing party about
> +their participation. Bringing in experts can happen at any time of the
> +development process and often needs to be handled in a timely manner.
> +
> +Coordinated release
> +"""""""""""""""""""
> +
> +The involved parties will negotiate the date and time where the embargo
> +ends. At that point the prepared mitigations are integrated into the
> +relevant kernel trees and published.
> +
> +While we understand that hardware security issues need coordinated embargo
> +time, the embargo time should be constrained to the minimum time which is
> +required for all involved parties to develop, test and prepare the
> +mitigations. Extending embargo time artificially to meet conference talk
> +dates or other non-technical reasons is creating more work and burden for
> +the involved developers and response teams as the patches need to be kept
> +up to date in order to follow the ongoing upstream kernel development,
> +which might create conflicting changes.
> +
> +CVE assignment
> +""""""""""""""
> +
> +Neither the hardware security team nor the initial response team assign
> +CVEs, nor are CVEs required for the development process. If CVEs are
> +provided by the disclosing party they can be used for documentation
> +purposes.
> +
> +Process ambassadors
> +-------------------
> +
> +For assistance with this process we have established ambassadors in various
> +organizations, who can answer questions about or provide guidance on the
> +reporting process and further handling. Ambassadors are not involved in the
> +disclosure of a particular issue, unless requested by a response team or by
> +an involved disclosed party. The current ambassadors list:
> +
> + ============== ========================================================
> + ARM
> + AMD
> + IBM
> + Intel
> + Qualcomm
> +
> + Microsoft
> + VMware
> + XEN
> +
> + Canonical
> + Debian
> + Oracle
> + Redhat
> + Suse Jiri Kosina <jkosina@suse.com>
> +
> + Amazon
> + Google
> + ============== ========================================================
Having companies without names seems a little weird. Unless perhaps you
have people teed up to add their names in follow-on patches?
> +If you want your organization to be added to the ambassadors list, please
> +contact the hardware security team. The nominated ambassador has to
> +understand and support our process fully and is ideally well connected in
> +the Linux kernel community.
> +
> +Encrypted mailing-lists
> +-----------------------
> +
> +We use encrypted mailing-lists for communication. The operating principle
> +of these lists is that email sent to the list is encrypted either with the
> +list's PGP key or with the list's S/MIME certificate. The mailing-list
> +software decrypts the email and re-encrypts it individually for each
> +subscriber with the subscriber's PGP key or S/MIME certificate. Details
> +about the mailing-list software and the setup which is used to ensure the
> +security of the lists and protection of the data can be found here:
> +https://www.kernel.org/....
That URL is also in need of completion.
The topic of encrypted mailing lists is visited several times in this
document; I wonder if that could be coalesced somehow?
> +List keys
> +^^^^^^^^^
> +
> +For initial contact see :ref:`Contact`. For incident specific mailing-lists
> +the key and S/MIME certificate are conveyed to the subscribers by email
> +sent from the specific list.
> +
> +Subscription to incident specific lists
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Subscription is handled by the response teams. Disclosed parties who want
> +to participate in the communication send a list of potential subscribers to
> +the response team so the response team can validate subscription requests.
> +
> +Each subscriber needs to send a subscription request to the response team
> +by email. The email must be signed with the subscriber's PGP key or S/MIME
> +certificate. If a PGP key is used, it must be available from a public key
> +server and is ideally connected to the Linux kernel's PGP web of trust. See
> +also: https://www.kernel.org/signature.html.
The "public key server" thing isn't working quite as well as it was; does
this requirement need to be revisited?
> +The response team verifies that the subscriber request is valid and adds
> +the subscriber to the list. After subscription the subscriber will receive
> +email from the mailing-list which is signed either with the list's PGP key
> +or the list's S/MIME certificate. The subscriber's email client can extract
> +the PGP key or the S/MIME certificate from the signature so the subscriber
> +can send encrypted email to the list.
> +
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -33,6 +33,7 @@ problems and bugs in particular.
>
> reporting-bugs
> security-bugs
> + embargoed-hardware-issues
> bug-hunting
> bug-bisect
> tainted-kernels
jon
^ permalink raw reply
* Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
From: linux-doc @ 2019-07-25 20:44 UTC (permalink / raw)
To: mP3htywKDlinux-doc
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
^ permalink raw reply
* Re: [PATCH v6] Documentation/checkpatch: Prefer stracpy over strcpy/strlcpy/strncpy.
From: Joe Perches @ 2019-07-25 22:57 UTC (permalink / raw)
To: NitinGote, keescook; +Cc: corbet, akpm, apw, linux-doc, kernel-hardening
In-Reply-To: <20190725112219.6244-1-nitin.r.gote@intel.com>
On Thu, 2019-07-25 at 16:52 +0530, NitinGote wrote:
> From: Nitin Gote <nitin.r.gote@intel.com>
>
> Added check in checkpatch.pl to deprecate strcpy(), strlcpy() and
> strncpy() in favor of stracpy().
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> +our %deprecated_string_apis = (
> + "strcpy" => "stracpy",
> + "strlcpy" => "stracpy",
> + "strncpy" => "stracpy - for non-NUL-terminated uses, strncpy dest should be __nonstring",
> +);
Maybe:
our %deprecated_string_apis = (
"strcpy" => "stracpy or strscpy",
"strlcpy" => "stracpy or strscpy",
"strncpy" => "stracpy or strscpy - for non-NUL-terminated uses, strncpy dest should be __nonstring",
);
^ permalink raw reply
* Re: [PATCH v1 1/2] mm/page_idle: Add support for per-pid page_idle using virtual indexing
From: Joel Fernandes @ 2019-07-26 0:06 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Minchan Kim, linux-kernel, vdavydov.dev, Brendan Gregg,
kernel-team, Alexey Dobriyan, Al Viro, Andrew Morton,
carmenjackson, Christian Hansen, Colin Ian King, dancol,
David Howells, fmayer, joaodias, Jonathan Corbet, Kees Cook,
Kirill Tkhai, linux-doc, linux-fsdevel, linux-mm, Michal Hocko,
Mike Rapoport, namhyung, sspatil
In-Reply-To: <c116f836-5a72-c6e6-498f-a904497ef557@yandex-team.ru>
On Thu, Jul 25, 2019 at 11:15:53AM +0300, Konstantin Khlebnikov wrote:
[snip]
> >>> Thanks for bringing up the swapping corner case.. Perhaps we can improve
> >>> the heap profiler to detect this by looking at bits 0-4 in pagemap. While it
> >>
> >> Yeb, that could work but it could add overhead again what you want to remove?
> >> Even, userspace should keep metadata to identify that page was already swapped
> >> in last period or newly swapped in new period.
> >
> > Yep.
> Between samples page could be read from swap and swapped out back multiple times.
> For tracking this swap ptes could be marked with idle bit too.
> I believe it's not so hard to find free bit for this.
>
> Refault\swapout will automatically clear this bit in pte even if
> page goes nowhere stays if swap-cache.
Could you clarify more about your idea? Do you mean swapout will clear the new
idle swap-pte bit if the page was accessed just before the swapout?
Instead, I thought of using is_swap_pte() to detect if the PTE belong to a
page that was swapped. And if so, then assume the page was idle. Sure we
would miss data that the page was accessed before the swap out in the
sampling window, however if the page was swapped out, then it is likely idle
anyway.
My current patch was just reporting swapped out pages as non-idle (idle bit
not set) which is wrong as Minchan pointed. So I added below patch on top of
this patch (still testing..) :
thanks,
- Joel
---8<-----------------------
diff --git a/mm/page_idle.c b/mm/page_idle.c
index 3667ed9cc904..46c2dd18cca8 100644
--- a/mm/page_idle.c
+++ b/mm/page_idle.c
@@ -271,10 +271,14 @@ struct page_idle_proc_priv {
struct list_head *idle_page_list;
};
+/*
+ * Add a page to the idle page list.
+ * page can also be NULL if pte was not present or swapped.
+ */
static void add_page_idle_list(struct page *page,
unsigned long addr, struct mm_walk *walk)
{
- struct page *page_get;
+ struct page *page_get = NULL;
struct page_node *pn;
int bit;
unsigned long frames;
@@ -290,9 +294,11 @@ static void add_page_idle_list(struct page *page,
return;
}
- page_get = page_idle_get_page(page);
- if (!page_get)
- return;
+ if (page) {
+ page_get = page_idle_get_page(page);
+ if (!page_get)
+ return;
+ }
pn = &(priv->page_nodes[priv->cur_page_node++]);
pn->page = page_get;
@@ -326,6 +332,15 @@ static int pte_page_idle_proc_range(pmd_t *pmd, unsigned long addr,
pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
for (; addr != end; pte++, addr += PAGE_SIZE) {
+ /*
+ * We add swapped pages to the idle_page_list so that we can
+ * reported to userspace that they are idle.
+ */
+ if (is_swap_pte(*pte)) {
+ add_page_idle_list(NULL, addr, walk);
+ continue;
+ }
+
if (!pte_present(*pte))
continue;
@@ -413,10 +428,12 @@ ssize_t page_idle_proc_generic(struct file *file, char __user *ubuff,
goto remove_page;
if (write) {
- page_idle_clear_pte_refs(page);
- set_page_idle(page);
+ if (page) {
+ page_idle_clear_pte_refs(page);
+ set_page_idle(page);
+ }
} else {
- if (page_really_idle(page)) {
+ if (!page || page_really_idle(page)) {
off = ((cur->addr) >> PAGE_SHIFT) - start_frame;
bit = off % BITMAP_CHUNK_BITS;
index = off / BITMAP_CHUNK_BITS;
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related
* Re: [PATCH v10 3/5] overlayfs: add __get xattr method
From: Amir Goldstein @ 2019-07-26 5:04 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, kernel-team, Miklos Szeredi, Jonathan Corbet,
Vivek Goyal, Eric W . Biederman, Randy Dunlap, Stephen Smalley,
overlayfs, linux-doc
In-Reply-To: <35b70147-25ad-4c29-3972-418ebee5e7b8@android.com>
On Thu, Jul 25, 2019 at 7:22 PM Mark Salyzyn <salyzyn@android.com> wrote:
>
> On 7/25/19 8:43 AM, Amir Goldstein wrote:
> > On Thu, Jul 25, 2019 at 6:03 PM Mark Salyzyn <salyzyn@android.com> wrote:
> >> On 7/24/19 10:48 PM, Amir Goldstein wrote:
> >>> On Wed, Jul 24, 2019 at 10:57 PM Mark Salyzyn <salyzyn@android.com> wrote:
> >>>> Because of the overlayfs getxattr recursion, the incoming inode fails
> >>>> to update the selinux sid resulting in avc denials being reported
> >>>> against a target context of u:object_r:unlabeled:s0.
> >>> This description is too brief for me to understand the root problem.
> >>> What's wring with the overlayfs getxattr recursion w.r.t the selinux
> >>> security model?
> >> __vfs_getxattr (the way the security layer acquires the target sid
> >> without recursing back to security to check the access permissions)
> >> calls get xattr method, which in overlayfs calls vfs_getxattr on the
> >> lower layer (which then recurses back to security to check permissions)
> >> and reports back -EACCES if there was a denial (which is OK) and _no_
> >> sid copied to caller's inode security data, bubbles back to the security
> >> layer caller, which reports an invalid avc: message for
> >> u:object_r:unlabeled:s0 (the uninitialized sid instead of the sid for
> >> the lower filesystem target). The blocked access is 100% valid, it is
> >> supposed to be blocked. This does however result in a cosmetic issue
> >> that makes it impossible to use audit2allow to construct a rule that
> >> would be usable to fix the access problem.
> >>
> > Ahhh you are talking about getting the security.selinux.* xattrs?
> > I was under the impression (Vivek please correct me if I wrong)
> > that overlayfs objects cannot have individual security labels and
>
> They can, and we _need_ them for Android's use cases, upper and lower
> filesystems.
>
> Some (most?) union filesystems (like Android's sdcardfs) set sepolicy
> from the mount options, we did not need this adjustment there of course.
>
> > the only way to label overlayfs objects is by mount options on the
> > entire mount? Or is this just for lower layer objects?
> >
> > Anyway, the API I would go for is adding a @flags argument to
> > get() which can take XATTR_NOSECURITY akin to
> > FMODE_NONOTIFY, GFP_NOFS, meant to avoid recursions.
>
> I do like it better (with the following 7 stages of grief below), best
> for the future.
>
> The change in this handler's API will affect all filesystem drivers
> (well, my change affects the ABI, so it is not as-if I saved the world
> from a module recompile) touching all filesystem sources with an even
> larger audience of stakeholders. Larger audience of stakeholders, the
> harder to get the change in ;-/. This is also concerning since I would
> like this change to go to stable 4.4, 4.9, 4.14 and 4.19 where this
> regression got introduced. I can either craft specific stable patches or
> just let it go and deal with them in the android-common distributions
> rather than seeking stable merged down. ABI/API breaks are a problem for
> stable anyway ...
>
Use the memalloc_nofs_save/restore design pattern will avoid all that
grief.
As a matter of fact, this issue could and should be handled inside security
subsystem without bothering any other subsystem.
LSM have per task context right? That context could carry the recursion
flags to know that the getxattr call is made by the security subsystem itself.
The problem is not limited to union filesystems.
In general its a stacking issue. ecryptfs is also a stacking fs, out-of-tree
shiftfs as well. But it doesn't end there.
A filesystem on top of a loop device inside another filesystem could
also maybe result in security hook recursion (not sure if in practice).
Thanks,
Amir.
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Petr Mladek @ 2019-07-26 8:31 UTC (permalink / raw)
To: Brendan Higgins
Cc: Jeff Dike, Kevin Hilman, Logan Gunthorpe, Michael Ellerman,
Daniel Vetter, Amir Goldstein, Frank Rowand, Steven Rostedt,
Kees Cook, David Rientjes, kunit-dev, Kieran Bingham,
Peter Zijlstra, Randy Dunlap, Joel Stanley, Luis Chamberlain,
Rob Herring, Stephen Boyd, shuah, wfg, Greg KH, Julia Lawall,
linux-nvdimm, dri-devel, linux-um, Sasha Levin, Theodore Ts'o,
Richard Weinberger, Dan Carpenter, Knut Omang, Josh Poimboeuf,
Masahiro Yamada, Timothy Bird, John Ogness, devicetree,
open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAFd5g47v3Mr4GEGOjqyYy9Jwwm+ow7ypbu9j88rxEN06QCzdxQ@mail.gmail.com>
On Thu 2019-07-25 13:21:12, Brendan Higgins wrote:
> On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> > > Quoting Brendan Higgins (2019-07-22 15:30:49)
> > > > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > > >
> > > > >
> > > > > What's the calling context of the assertions and expectations? I still
> > > > > don't like the fact that string stream needs to allocate buffers and
> > > > > throw them into a list somewhere because the calling context matters
> > > > > there.
> > > >
> > > > The calling context is the same as before, which is anywhere.
> > >
> > > Ok. That's concerning then.
> > >
> > > >
> > > > > I'd prefer we just wrote directly to the console/log via printk
> > > > > instead. That way things are simple because we use the existing
> > > > > buffering path of printk, but maybe there's some benefit to the string
> > > > > stream that I don't see? Right now it looks like it builds a string and
> > > > > then dumps it to printk so I'm sort of lost what the benefit is over
> > > > > just writing directly with printk.
> > > >
> > > > It's just buffering it so the whole string gets printed uninterrupted.
> > > > If we were to print out piecemeal to printk, couldn't we have another
> > > > call to printk come in causing it to garble the KUnit message we are
> > > > in the middle of printing?
> > >
> > > Yes, printing piecemeal by calling printk many times could lead to
> > > interleaving of messages if something else comes in such as an interrupt
> > > printing something. Printk has some support to hold "records" but I'm
> > > not sure how that would work here because KERN_CONT talks about only
> > > being used early on in boot code. I haven't looked at printk in detail
> > > though so maybe I'm all wrong and KERN_CONT just works?
> >
> > KERN_CONT does not guarantee that the message will get printed
> > together. The pieces get interleaved with messages printed in
> > parallel.
> >
> > Note that KERN_CONT was originally really meant to be used only during
> > boot. It was later used more widely and ended in the best effort category.
> >
> > There were several attempts to make it more reliable. But it was
> > always either too complicated or error prone or both.
> >
> > You need to use your own buffering if you rely want perfect output.
> > The question is if it is really worth the complexity. Also note that
> > any buffering reduces the chance that the messages will reach
> > the console.
>
> Seems like that settles it then. Thanks!
>
> > BTW: There is a work in progress on a lockless printk ring buffer.
> > It will make printk() more secure regarding deadlocks. But it might
> > make transparent handling of continuous lines even more tricky.
> >
> > I guess that local buffering, before calling printk(), will be
> > even more important then. Well, it might really force us to create
> > an API for it.
>
> Cool! Can you CC me on that discussion?
Adding John Oggness into CC.
John, please CC Brendan Higgins on the patchsets eventually switching
printk() into the lockless buffer. The test framework is going to
do its own buffering to keep the related messages together.
The lockless ringbuffer might make handling of related (partial)
lines worse or better. It might justify KUnit's extra buffering
or it might allow to get rid of it.
> > Note that stroring the messages into the printk log is basically safe in any
> > context. It uses temporary per-CPU buffers for recursive messages and
> > in NMI. The only problem is panic() when some CPU gets stuck with the
> > lock taken. This will get solved by the lockless ringbuffer. Also
> > the temporary buffers will not be necessary any longer.
>
> Sure, I think Stephen's concern is all the supporting code that is
> involved. Not printk specifically. It just means a lot more of KUnit
> has to be IRQ safe.
I see.
BTW: I wonder if KUnit could reuse the existing seq_buf implementation
for buffering messages.
I am sorry if it has already been proposed and rejected for some
reason. I might have missed it. Feel free to just point me to
same older mail.
> > Much bigger problems are with consoles. There are many of them. It
> > means a lot of code and more locks involved, including scheduler
> > locks. Note that console lock is a semaphore.
>
> That shouldn't affect us though, right? As long as we continue to use
> the printk interface?
I guess that it should not affect KUnit.
The only problem might be if the testing framework calls printk()
inside scheduler or console code. And only when the tested code
uses the same locks that will be used by the called printk().
To be honest I do not fully understand KUnit design. I am not
completely sure how the tested code is isolated from the running
system. Namely, I do not know if the tested code shares
the same locks with the system running the test.
Best Regards,
Petr
^ permalink raw reply
* [PATCH] docs: phy: Drop duplicate 'be made'
From: Guido Günther @ 2019-07-26 9:55 UTC (permalink / raw)
To: Jonathan Corbet, Mauro Carvalho Chehab, linux-doc, linux-kernel
Fix duplicate words.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
Noticed on next-20190725.
Documentation/driver-api/phy/phy.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst
index 457c3e0f86d6..8fc1ce0bb905 100644
--- a/Documentation/driver-api/phy/phy.rst
+++ b/Documentation/driver-api/phy/phy.rst
@@ -179,8 +179,8 @@ PHY Mappings
In order to get reference to a PHY without help from DeviceTree, the framework
offers lookups which can be compared to clkdev that allow clk structures to be
-bound to devices. A lookup can be made be made during runtime when a handle to
-the struct phy already exists.
+bound to devices. A lookup can be made during runtime when a handle to the
+struct phy already exists.
The framework offers the following API for registering and unregistering the
lookups::
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v1 1/2] mm/page_idle: Add support for per-pid page_idle using virtual indexing
From: Konstantin Khlebnikov @ 2019-07-26 11:16 UTC (permalink / raw)
To: Joel Fernandes
Cc: Minchan Kim, linux-kernel, vdavydov.dev, Brendan Gregg,
kernel-team, Alexey Dobriyan, Al Viro, Andrew Morton,
carmenjackson, Christian Hansen, Colin Ian King, dancol,
David Howells, fmayer, joaodias, Jonathan Corbet, Kees Cook,
Kirill Tkhai, linux-doc, linux-fsdevel, linux-mm, Michal Hocko,
Mike Rapoport, namhyung, sspatil
In-Reply-To: <20190726000654.GB66718@google.com>
On 26.07.2019 3:06, Joel Fernandes wrote:
> On Thu, Jul 25, 2019 at 11:15:53AM +0300, Konstantin Khlebnikov wrote:
> [snip]
>>>>> Thanks for bringing up the swapping corner case.. Perhaps we can improve
>>>>> the heap profiler to detect this by looking at bits 0-4 in pagemap. While it
>>>>
>>>> Yeb, that could work but it could add overhead again what you want to remove?
>>>> Even, userspace should keep metadata to identify that page was already swapped
>>>> in last period or newly swapped in new period.
>>>
>>> Yep.
>> Between samples page could be read from swap and swapped out back multiple times.
>> For tracking this swap ptes could be marked with idle bit too.
>> I believe it's not so hard to find free bit for this.
>>
>> Refault\swapout will automatically clear this bit in pte even if
>> page goes nowhere stays if swap-cache.
>
> Could you clarify more about your idea? Do you mean swapout will clear the new
> idle swap-pte bit if the page was accessed just before the swapout? >
> Instead, I thought of using is_swap_pte() to detect if the PTE belong to a
> page that was swapped. And if so, then assume the page was idle. Sure we
> would miss data that the page was accessed before the swap out in the
> sampling window, however if the page was swapped out, then it is likely idle
> anyway.
I mean page might be in swap when you mark pages idle and
then been accessed and swapped back before second pass.
I propose marking swap pte with idle bit which will be automatically
cleared by following swapin/swapout pair:
page alloc -> install page pte
page swapout -> install swap entry in pte
mark vm idle -> set swap-idle bit in swap pte
access/swapin -> install page pte (clear page idle if set)
page swapout -> install swap entry in pte (without swap idle bit)
scan vm idle -> see swap entry without idle bit -> page has been accessed since marking idle
One bit in pte is enough for tracking. This does not needs any propagation for
idle bits between page and swap, or marking pages as idle in swap cache.
>
> My current patch was just reporting swapped out pages as non-idle (idle bit
> not set) which is wrong as Minchan pointed. So I added below patch on top of
> this patch (still testing..) :
>
> thanks,
>
> - Joel
> ---8<-----------------------
>
> diff --git a/mm/page_idle.c b/mm/page_idle.c
> index 3667ed9cc904..46c2dd18cca8 100644
> --- a/mm/page_idle.c
> +++ b/mm/page_idle.c
> @@ -271,10 +271,14 @@ struct page_idle_proc_priv {
> struct list_head *idle_page_list;
> };
>
> +/*
> + * Add a page to the idle page list.
> + * page can also be NULL if pte was not present or swapped.
> + */
> static void add_page_idle_list(struct page *page,
> unsigned long addr, struct mm_walk *walk)
> {
> - struct page *page_get;
> + struct page *page_get = NULL;
> struct page_node *pn;
> int bit;
> unsigned long frames;
> @@ -290,9 +294,11 @@ static void add_page_idle_list(struct page *page,
> return;
> }
>
> - page_get = page_idle_get_page(page);
> - if (!page_get)
> - return;
> + if (page) {
> + page_get = page_idle_get_page(page);
> + if (!page_get)
> + return;
> + }
>
> pn = &(priv->page_nodes[priv->cur_page_node++]);
> pn->page = page_get;
> @@ -326,6 +332,15 @@ static int pte_page_idle_proc_range(pmd_t *pmd, unsigned long addr,
>
> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> + /*
> + * We add swapped pages to the idle_page_list so that we can
> + * reported to userspace that they are idle.
> + */
> + if (is_swap_pte(*pte)) {
> + add_page_idle_list(NULL, addr, walk);
> + continue;
> + }
> +
> if (!pte_present(*pte))
> continue;
>
> @@ -413,10 +428,12 @@ ssize_t page_idle_proc_generic(struct file *file, char __user *ubuff,
> goto remove_page;
>
> if (write) {
> - page_idle_clear_pte_refs(page);
> - set_page_idle(page);
> + if (page) {
> + page_idle_clear_pte_refs(page);
> + set_page_idle(page);
> + }
> } else {
> - if (page_really_idle(page)) {
> + if (!page || page_really_idle(page)) {
> off = ((cur->addr) >> PAGE_SHIFT) - start_frame;
> bit = off % BITMAP_CHUNK_BITS;
> index = off / BITMAP_CHUNK_BITS;
>
^ permalink raw reply
* Re: [PATCH] hung_task: Allow printing warnings every check interval
From: Tetsuo Handa @ 2019-07-26 11:29 UTC (permalink / raw)
To: Dmitry Safonov, linux-kernel
Cc: Dmitry Safonov, Andrew Morton, Dmitry Vyukov, Ingo Molnar,
Jonathan Corbet, Thomas Gleixner, Peter Zijlstra (Intel),
Vasiliy Khoruzhick, linux-doc, linux-fsdevel
In-Reply-To: <aa151251-d271-1e65-1cae-0d9da9764d56@arista.com>
On 2019/07/25 23:25, Dmitry Safonov wrote:
> Yes, also current distributions already using the counter to print
> warnings number of times and then silently ignore. I.e., on my Arch
> Linux setup:
> hung_task_warnings:10
You can propose changing the default value of hung_task_warnings to -1.
Current patch might be inconvenient because printk() from hung_task_warning(t, false)
fails to go to consoles when that "t" was blocked for more than "timeout" seconds, for
if (sysctl_hung_task_panic) {
console_verbose();
hung_task_show_lock = true;
hung_task_call_panic = true;
}
path which is intended to force printk() to go to consoles is ignored by
/* Don't print warings twice */
if (!sysctl_hung_task_interval_warnings)
hung_task_warning(t, true);
when panic() should be called. (The vmcore would contain the printk() output which
was not sent to consoles if kdump is configured. But vmcore is not always available.)
> Yes, that's why it's disabled by default (=0).
> I tend to agree that printing with KERN_DEBUG may be better, but in my
> point of view the patch isn't enough justification for patching
> sched_show_task() and show_stack().
You can propose sched_show_task_log_lvl() and show_stack_log_lvl() like show_trace_log_lvl().
I think that sysctl_hung_task_interval_warnings should not be decremented automatically.
I guess that that variable should become a boolean which controls whether to report threads
(with KERN_DEBUG level) which was blocked for more than sysctl_hung_task_check_interval_secs
seconds (or a tristate which also controls whether the report should be sent to consoles
(because KERN_DEBUG level likely prevents sending to consoles)), and
hung_task_warning(t, false) should be called like
if (time_is_after_jiffies(t->last_switch_time + timeout * HZ)) {
if (sysctl_hung_task_interval_warnings)
hung_task_warning(t, false);
return;
}
rather than
if (sysctl_hung_task_interval_warnings)
hung_task_warning(t, false);
if (time_is_after_jiffies(t->last_switch_time + timeout * HZ))
return;
.
^ permalink raw reply
* [PATCH v2 01/10] docs: pdf: add all Documentation/*/index.rst to PDF output
From: Mauro Carvalho Chehab @ 2019-07-26 11:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
In-Reply-To: <cover.1564139914.git.mchehab+samsung@kernel.org>
Currently, all index files should be manually added to the
latex_documents array at conf.py.
While this allows fine-tuning some LaTeX specific things, like
the name of the output file and the name of the document, it
is not uncommon to forget adding new documents there.
So, add a logic that will seek for all Documentation/*/index.rst.
If the index is not yet at latex_documents, it includes using
a reasonable default.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/conf.py | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 3b2397bcb565..13b5f711bddf 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -410,6 +410,21 @@ latex_documents = [
'The kernel development community', 'manual'),
]
+# Add all other index files from Documentation/ subdirectories
+for fn in os.listdir('.'):
+ doc = os.path.join(fn, "index")
+ if os.path.exists(doc + ".rst"):
+ has = False
+ for l in latex_documents:
+ if l[0] == doc:
+ has = True
+ break
+ if not has:
+ latex_documents.append((doc, fn + '.tex',
+ 'Linux %s Documentation' % fn.capitalize(),
+ 'The kernel development community',
+ 'manual'))
+
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
--
2.21.0
^ permalink raw reply related
* [PATCH v2 02/10] docs: conf.py: add CJK package needed by translations
From: Mauro Carvalho Chehab @ 2019-07-26 11:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
In-Reply-To: <cover.1564139914.git.mchehab+samsung@kernel.org>
In order to be able to output Asian symbols with XeLaTeX, we
need the xeCJK package, and a default font for CJK symbols.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/conf.py | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 13b5f711bddf..fa0a42b47e62 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -277,6 +277,10 @@ latex_elements = {
\\setromanfont{DejaVu Serif}
\\setmonofont{DejaVu Sans Mono}
+ % This is needed for translations
+ \\usepackage{xeCJK}
+ \\setCJKmainfont{Noto Sans CJK SC}
+
'''
}
--
2.21.0
^ permalink raw reply related
* [PATCH v2 09/10] docs: load_config.py: avoid needing a conf.py just due to LaTeX docs
From: Mauro Carvalho Chehab @ 2019-07-26 11:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
In-Reply-To: <cover.1564139914.git.mchehab+samsung@kernel.org>
Right now, for every directory that we need to have LaTeX output,
a conf.py file is required.
That causes an extra overhead and it is actually a hack, as
the latex_documents line there are usually a copy of the ones
that are there already at the main conf.py.
So, instead, re-use the global latex_documents var, just
adjusting the path to be relative ones.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/sphinx/load_config.py | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/sphinx/load_config.py b/Documentation/sphinx/load_config.py
index 301a21aa4f63..eeb394b39e2c 100644
--- a/Documentation/sphinx/load_config.py
+++ b/Documentation/sphinx/load_config.py
@@ -21,6 +21,29 @@ def loadConfig(namespace):
and os.path.normpath(namespace["__file__"]) != os.path.normpath(config_file) ):
config_file = os.path.abspath(config_file)
+ # Let's avoid one conf.py file just due to latex_documents
+ start = config_file.find('Documentation/')
+ if start >= 0:
+ start = config_file.find('/', start + 1)
+
+ end = config_file.rfind('/')
+ if start >= 0 and end > 0:
+ dir = config_file[start + 1:end]
+
+ print("source directory: %s" % dir)
+ new_latex_docs = []
+ latex_documents = namespace['latex_documents']
+
+ for l in latex_documents:
+ if l[0].find(dir + '/') == 0:
+ has = True
+ fn = l[0][len(dir) + 1:]
+ new_latex_docs.append((fn, l[1], l[2], l[3], l[4]))
+ break
+
+ namespace['latex_documents'] = new_latex_docs
+
+ # If there is an extra conf.py file, load it
if os.path.isfile(config_file):
sys.stdout.write("load additional sphinx-config: %s\n" % config_file)
config = namespace.copy()
@@ -29,4 +52,6 @@ def loadConfig(namespace):
del config['__file__']
namespace.update(config)
else:
- sys.stderr.write("WARNING: additional sphinx-config not found: %s\n" % config_file)
+ config = namespace.copy()
+ config['tags'].add("subproject")
+ namespace.update(config)
--
2.21.0
^ permalink raw reply related
* [PATCH v2 03/10] docs: conf.py: only use CJK if the font is available
From: Mauro Carvalho Chehab @ 2019-07-26 11:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
In-Reply-To: <cover.1564139914.git.mchehab+samsung@kernel.org>
If we try to build a book with asian characters with XeLaTeX
and the font is not available, it will produce an error.
So, instead, add a logic at conf.py to detect if the proper
font is installed.
This will avoid an error while building the document, although
the result may not be readable.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/conf.py | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index fa0a42b47e62..a8fe845832bc 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -16,6 +16,8 @@ import sys
import os
import sphinx
+from subprocess import check_output
+
# Get Sphinx version
major, minor, patch = sphinx.version_info[:3]
@@ -276,13 +278,20 @@ latex_elements = {
\\setsansfont{DejaVu Sans}
\\setromanfont{DejaVu Serif}
\\setmonofont{DejaVu Sans Mono}
+ '''
+}
+# At least one book (translations) may have Asian characters
+# with are only displayed if xeCJK is used
+
+cjk_cmd = check_output(['fc-list', '--format="%{family[0]}\n"']).decode('utf-8', 'ignore')
+if cjk_cmd.find("Noto Sans CJK SC") >= 0:
+ print ("enabling CJK for LaTeX builder")
+ latex_elements['preamble'] += '''
% This is needed for translations
\\usepackage{xeCJK}
\\setCJKmainfont{Noto Sans CJK SC}
-
'''
-}
# Fix reference escape troubles with Sphinx 1.4.x
if major == 1 and minor > 3:
--
2.21.0
^ permalink raw reply related
* [PATCH v2 10/10] docs: remove extra conf.py files
From: Mauro Carvalho Chehab @ 2019-07-26 11:31 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Jonathan Corbet, Herbert Xu,
David S. Miller, Maarten Lankhorst, Maxime Ripard, Sean Paul,
David Airlie, Daniel Vetter, Dmitry Torokhov, Yoshinori Sato,
Rich Felker, Jaroslav Kysela, Takashi Iwai, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, linux-doc,
linux-crypto, dri-devel, linux-input, netdev, linux-sh,
alsa-devel
In-Reply-To: <cover.1564139914.git.mchehab+samsung@kernel.org>
Now that the latex_documents are handled automatically, we can
remove those extra conf.py files.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/admin-guide/conf.py | 10 ----------
Documentation/core-api/conf.py | 10 ----------
Documentation/crypto/conf.py | 10 ----------
Documentation/dev-tools/conf.py | 10 ----------
Documentation/doc-guide/conf.py | 10 ----------
Documentation/driver-api/80211/conf.py | 10 ----------
Documentation/driver-api/conf.py | 10 ----------
Documentation/driver-api/pm/conf.py | 10 ----------
Documentation/filesystems/conf.py | 10 ----------
Documentation/gpu/conf.py | 10 ----------
Documentation/input/conf.py | 10 ----------
Documentation/kernel-hacking/conf.py | 10 ----------
Documentation/maintainer/conf.py | 10 ----------
Documentation/media/conf.py | 12 ------------
Documentation/networking/conf.py | 10 ----------
Documentation/process/conf.py | 10 ----------
Documentation/sh/conf.py | 10 ----------
Documentation/sound/conf.py | 10 ----------
Documentation/userspace-api/conf.py | 10 ----------
Documentation/vm/conf.py | 10 ----------
Documentation/x86/conf.py | 10 ----------
21 files changed, 212 deletions(-)
delete mode 100644 Documentation/admin-guide/conf.py
delete mode 100644 Documentation/core-api/conf.py
delete mode 100644 Documentation/crypto/conf.py
delete mode 100644 Documentation/dev-tools/conf.py
delete mode 100644 Documentation/doc-guide/conf.py
delete mode 100644 Documentation/driver-api/80211/conf.py
delete mode 100644 Documentation/driver-api/conf.py
delete mode 100644 Documentation/driver-api/pm/conf.py
delete mode 100644 Documentation/filesystems/conf.py
delete mode 100644 Documentation/gpu/conf.py
delete mode 100644 Documentation/input/conf.py
delete mode 100644 Documentation/kernel-hacking/conf.py
delete mode 100644 Documentation/maintainer/conf.py
delete mode 100644 Documentation/media/conf.py
delete mode 100644 Documentation/networking/conf.py
delete mode 100644 Documentation/process/conf.py
delete mode 100644 Documentation/sh/conf.py
delete mode 100644 Documentation/sound/conf.py
delete mode 100644 Documentation/userspace-api/conf.py
delete mode 100644 Documentation/vm/conf.py
delete mode 100644 Documentation/x86/conf.py
diff --git a/Documentation/admin-guide/conf.py b/Documentation/admin-guide/conf.py
deleted file mode 100644
index 86f738953799..000000000000
--- a/Documentation/admin-guide/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel User Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'linux-user.tex', 'Linux Kernel User Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/core-api/conf.py b/Documentation/core-api/conf.py
deleted file mode 100644
index db1f7659f3da..000000000000
--- a/Documentation/core-api/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Core-API Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'core-api.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/crypto/conf.py b/Documentation/crypto/conf.py
deleted file mode 100644
index 4335d251ddf3..000000000000
--- a/Documentation/crypto/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Crypto API'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'crypto-api.tex', 'Linux Kernel Crypto API manual',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/dev-tools/conf.py b/Documentation/dev-tools/conf.py
deleted file mode 100644
index 7faafa3f7888..000000000000
--- a/Documentation/dev-tools/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Development tools for the kernel"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'dev-tools.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/doc-guide/conf.py b/Documentation/doc-guide/conf.py
deleted file mode 100644
index fd3731182d5a..000000000000
--- a/Documentation/doc-guide/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Documentation Guide'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'kernel-doc-guide.tex', 'Linux Kernel Documentation Guide',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/driver-api/80211/conf.py b/Documentation/driver-api/80211/conf.py
deleted file mode 100644
index 4424b4b0b9c3..000000000000
--- a/Documentation/driver-api/80211/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux 802.11 Driver Developer's Guide"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', '80211.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/driver-api/conf.py b/Documentation/driver-api/conf.py
deleted file mode 100644
index 202726d20088..000000000000
--- a/Documentation/driver-api/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "The Linux driver implementer's API guide"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'driver-api.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/driver-api/pm/conf.py b/Documentation/driver-api/pm/conf.py
deleted file mode 100644
index a89fac11272f..000000000000
--- a/Documentation/driver-api/pm/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Device Power Management"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'pm.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/filesystems/conf.py b/Documentation/filesystems/conf.py
deleted file mode 100644
index ea44172af5c4..000000000000
--- a/Documentation/filesystems/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux Filesystems API"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'filesystems.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/gpu/conf.py b/Documentation/gpu/conf.py
deleted file mode 100644
index 1757b040fb32..000000000000
--- a/Documentation/gpu/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux GPU Driver Developer's Guide"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'gpu.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/input/conf.py b/Documentation/input/conf.py
deleted file mode 100644
index d2352fdc92ed..000000000000
--- a/Documentation/input/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "The Linux input driver subsystem"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'linux-input.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/kernel-hacking/conf.py b/Documentation/kernel-hacking/conf.py
deleted file mode 100644
index 3d8acf0f33ad..000000000000
--- a/Documentation/kernel-hacking/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Kernel Hacking Guides"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'kernel-hacking.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/maintainer/conf.py b/Documentation/maintainer/conf.py
deleted file mode 100644
index 81e9eb7a7884..000000000000
--- a/Documentation/maintainer/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Development Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'maintainer.tex', 'Linux Kernel Development Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/media/conf.py b/Documentation/media/conf.py
deleted file mode 100644
index 1f194fcd2cae..000000000000
--- a/Documentation/media/conf.py
+++ /dev/null
@@ -1,12 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-# SPDX-License-Identifier: GPL-2.0
-
-project = 'Linux Media Subsystem Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'media.tex', 'Linux Media Subsystem Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/networking/conf.py b/Documentation/networking/conf.py
deleted file mode 100644
index 40f69e67a883..000000000000
--- a/Documentation/networking/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux Networking Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'networking.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/process/conf.py b/Documentation/process/conf.py
deleted file mode 100644
index 1b01a80ad9ce..000000000000
--- a/Documentation/process/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Development Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'process.tex', 'Linux Kernel Development Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/sh/conf.py b/Documentation/sh/conf.py
deleted file mode 100644
index 1eb684a13ac8..000000000000
--- a/Documentation/sh/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "SuperH architecture implementation manual"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'sh.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/sound/conf.py b/Documentation/sound/conf.py
deleted file mode 100644
index 3f1fc5e74e7b..000000000000
--- a/Documentation/sound/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux Sound Subsystem Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'sound.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/userspace-api/conf.py b/Documentation/userspace-api/conf.py
deleted file mode 100644
index 2eaf59f844e5..000000000000
--- a/Documentation/userspace-api/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "The Linux kernel user-space API guide"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'userspace-api.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/vm/conf.py b/Documentation/vm/conf.py
deleted file mode 100644
index 3b0b601af558..000000000000
--- a/Documentation/vm/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux Memory Management Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'memory-management.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/x86/conf.py b/Documentation/x86/conf.py
deleted file mode 100644
index 33c5c3142e20..000000000000
--- a/Documentation/x86/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "X86 architecture specific documentation"
-
-tags.add("subproject")
-
-latex_documents = [
- ('index', 'x86.tex', project,
- 'The kernel development community', 'manual'),
-]
--
2.21.0
^ permalink raw reply related
* [PATCH 0/7] Fix broken references to files under Documentation/*
From: Mauro Carvalho Chehab @ 2019-07-26 11:47 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel, Atish Patra,
Łukasz Stelmach, Rob Herring
Solves most of the pending broken references upstream, except for two of
them:
$ ./scripts/documentation-file-ref-check
Documentation/riscv/boot-image-header.txt: Documentation/riscv/booting.txt
MAINTAINERS: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
As written at boot-image-header.txt, it is waiting for the addition of
a future file:
"The complete booting guide will be available at
Documentation/riscv/booting.txt."
The second is due to this patch, pending to be merged:
https://lore.kernel.org/patchwork/patch/994210/
I'm not a DT expert, but I can't see any issue with this patch, except
for a missing acked-by a DT maintainer, and a possible conversion to
yaml. IMO, the best fix for this would be to merge the DT patch.
Patch 1 was already submitted before, together with the v1 of
my PDF fix series.
Mauro Carvalho Chehab (7):
docs: fix broken doc references due to renames
docs: generic-counter.rst: fix broken references for ABI file
MAINTAINERS: fix reference to net phy ABI file
MAINTAINERS: fix a renamed DT reference
docs: cgroup-v1/blkio-controller.rst: remove a CFQ left over
docs: zh_CN: howto.rst: fix a broken reference
docs: dt: fix a sound binding broken reference
Documentation/RCU/rculist_nulls.txt | 2 +-
.../admin-guide/cgroup-v1/blkio-controller.rst | 6 ------
.../devicetree/bindings/arm/idle-states.txt | 2 +-
.../devicetree/bindings/sound/sun8i-a33-codec.txt | 2 +-
Documentation/driver-api/generic-counter.rst | 4 ++--
Documentation/locking/spinlocks.rst | 4 ++--
Documentation/memory-barriers.txt | 2 +-
.../translations/ko_KR/memory-barriers.txt | 2 +-
Documentation/translations/zh_CN/process/howto.rst | 2 +-
Documentation/watchdog/hpwdt.rst | 2 +-
MAINTAINERS | 14 +++++++-------
drivers/gpu/drm/drm_modes.c | 2 +-
drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +-
drivers/scsi/hpsa.c | 4 ++--
14 files changed, 22 insertions(+), 28 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH 6/7] docs: zh_CN: howto.rst: fix a broken reference
From: Mauro Carvalho Chehab @ 2019-07-26 11:47 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Harry Wei, Alex Shi, Jonathan Corbet,
linux-doc
In-Reply-To: <cover.1564140865.git.mchehab+samsung@kernel.org>
There's a broken reference there pointing to the long gone
DocBook dir.
While I don't read chinese, Google translator translates it
to:
"The generated documentation will be placed in
the Documentation/DocBook/ directory."
Well, we know that the output will be Documentation/output
dir. So, let's fix this one.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/translations/zh_CN/process/howto.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst
index 5b671178b17b..c4ff8356b88d 100644
--- a/Documentation/translations/zh_CN/process/howto.rst
+++ b/Documentation/translations/zh_CN/process/howto.rst
@@ -147,7 +147,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
关于补丁是什么以及如何将它打在不同内核开发分支上的好介绍
内核还拥有大量从代码自动生成的文档。它包含内核内部API的全面介绍以及如何
-妥善处理加锁的规则。生成的文档会放在 Documentation/DocBook/目录下。在内
+妥善处理加锁的规则。生成的文档会放在 Documentation/output/目录下。在内
核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册
页等不同格式的文档::
--
2.21.0
^ permalink raw reply related
* [PATCH 2/7] docs: generic-counter.rst: fix broken references for ABI file
From: Mauro Carvalho Chehab @ 2019-07-26 11:47 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, William Breathitt Gray, Jonathan Corbet,
linux-iio, linux-doc
In-Reply-To: <cover.1564140865.git.mchehab+samsung@kernel.org>
There are two references to the generic counter ABI, with was added
on a separate patch. Both point to a non-existing file.
Fix them.
Fixes: ea2b23b89579 ("counter: Documentation: Add Generic Counter sysfs documentation")
Fixes: 09e7d4ed8991 ("docs: Add Generic Counter interface documentation")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/driver-api/generic-counter.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
index 0c161b1a3be6..8382f01a53e3 100644
--- a/Documentation/driver-api/generic-counter.rst
+++ b/Documentation/driver-api/generic-counter.rst
@@ -233,7 +233,7 @@ Userspace Interface
Several sysfs attributes are generated by the Generic Counter interface,
and reside under the /sys/bus/counter/devices/counterX directory, where
counterX refers to the respective counter device. Please see
-Documentation/ABI/testing/sys-bus-counter-generic-sysfs for detailed
+Documentation/ABI/testing/sysfs-bus-counter for detailed
information on each Generic Counter interface sysfs attribute.
Through these sysfs attributes, programs and scripts may interact with
@@ -325,7 +325,7 @@ sysfs attributes, where Y is the unique ID of the respective Count:
For a more detailed breakdown of the available Generic Counter interface
sysfs attributes, please refer to the
-Documentation/ABI/testing/sys-bus-counter file.
+Documentation/ABI/testing/sysfs-bus-counter file.
The Signals and Counts associated with the Counter device are registered
to the system as well by the counter_register function. The
--
2.21.0
^ permalink raw reply related
* [PATCH 5/7] docs: cgroup-v1/blkio-controller.rst: remove a CFQ left over
From: Mauro Carvalho Chehab @ 2019-07-26 11:47 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Tejun Heo, Jens Axboe, Li Zefan,
Johannes Weiner, Jonathan Corbet, cgroups, linux-block, linux-doc
In-Reply-To: <cover.1564140865.git.mchehab+samsung@kernel.org>
changeset fb5772cbfe48 ("blkio-controller.txt: Remove references to CFQ")
removed cgroup references to CFQ, but it kept one left. Get rid of
it.
Fixes: fb5772cbfe48 ("blkio-controller.txt: Remove references to CFQ")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/admin-guide/cgroup-v1/blkio-controller.rst | 6 ------
1 file changed, 6 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
index 1d7d962933be..36d43ae7dc13 100644
--- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
+++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
@@ -130,12 +130,6 @@ Proportional weight policy files
dev weight
8:16 300
-- blkio.leaf_weight[_device]
- - Equivalents of blkio.weight[_device] for the purpose of
- deciding how much weight tasks in the given cgroup has while
- competing with the cgroup's child cgroups. For details,
- please refer to Documentation/block/cfq-iosched.txt.
-
- blkio.time
- disk time allocated to cgroup per device in milliseconds. First
two fields specify the major and minor number of the device and
--
2.21.0
^ permalink raw reply related
* [PATCH 1/7] docs: fix broken doc references due to renames
From: Mauro Carvalho Chehab @ 2019-07-26 11:47 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Paul E. McKenney, Josh Triplett,
Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes,
Jonathan Corbet, Rob Herring, Mark Rutland, Peter Zijlstra,
Ingo Molnar, Will Deacon, Alan Stern, Andrea Parri, Boqun Feng,
Nicholas Piggin, David Howells, Jade Alglave, Luc Maranget,
Akira Yokosawa, Daniel Lustig, Jerry Hoemann, Wim Van Sebroeck,
Guenter Roeck, Maarten Lankhorst, Maxime Ripard, Sean Paul,
David Airlie, Daniel Vetter, Ajay Gupta, Don Brace,
James E.J. Bottomley, Martin K. Petersen, rcu, linux-doc,
devicetree, linux-arch, linux-watchdog, dri-devel, linux-i2c,
esc.storagedev, linux-scsi, Wolfram Sang
In-Reply-To: <cover.1564140865.git.mchehab+samsung@kernel.org>
Some files got renamed but probably due to some merge conflicts,
a few references still point to the old locations.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de> # I2C part
Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com> # hpwdt.rst
---
Documentation/RCU/rculist_nulls.txt | 2 +-
Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
Documentation/locking/spinlocks.rst | 4 ++--
Documentation/memory-barriers.txt | 2 +-
Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
Documentation/watchdog/hpwdt.rst | 2 +-
MAINTAINERS | 10 +++++-----
drivers/gpu/drm/drm_modes.c | 2 +-
drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +-
drivers/scsi/hpsa.c | 4 ++--
10 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt
index 8151f0195f76..23f115dc87cf 100644
--- a/Documentation/RCU/rculist_nulls.txt
+++ b/Documentation/RCU/rculist_nulls.txt
@@ -1,7 +1,7 @@
Using hlist_nulls to protect read-mostly linked lists and
objects using SLAB_TYPESAFE_BY_RCU allocations.
-Please read the basics in Documentation/RCU/listRCU.txt
+Please read the basics in Documentation/RCU/listRCU.rst
Using special makers (called 'nulls') is a convenient way
to solve following problem :
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
index 326f29b270ad..2d325bed37e5 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -703,4 +703,4 @@ cpus {
https://www.devicetree.org/specifications/
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
- Documentation/arm64/booting.txt
+ Documentation/arm64/booting.rst
diff --git a/Documentation/locking/spinlocks.rst b/Documentation/locking/spinlocks.rst
index 098107fb7d86..e93ec6645238 100644
--- a/Documentation/locking/spinlocks.rst
+++ b/Documentation/locking/spinlocks.rst
@@ -82,7 +82,7 @@ itself. The read lock allows many concurrent readers. Anything that
**changes** the list will have to get the write lock.
NOTE! RCU is better for list traversal, but requires careful
- attention to design detail (see Documentation/RCU/listRCU.txt).
+ attention to design detail (see Documentation/RCU/listRCU.rst).
Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
time need to do any changes (even if you don't do it every time), you have
@@ -90,7 +90,7 @@ to get the write-lock at the very beginning.
NOTE! We are working hard to remove reader-writer spinlocks in most
cases, so please don't add a new one without consensus. (Instead, see
- Documentation/RCU/rcu.txt for complete information.)
+ Documentation/RCU/rcu.rst for complete information.)
----
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 045bb8148fe9..1adbb8a371c7 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -548,7 +548,7 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
[*] For information on bus mastering DMA and coherency please read:
- Documentation/PCI/pci.rst
+ Documentation/driver-api/pci/pci.rst
Documentation/DMA-API-HOWTO.txt
Documentation/DMA-API.txt
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index a33c2a536542..2774624ee843 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -569,7 +569,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
[*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다:
- Documentation/PCI/pci.rst
+ Documentation/driver-api/pci/pci.rst
Documentation/DMA-API-HOWTO.txt
Documentation/DMA-API.txt
diff --git a/Documentation/watchdog/hpwdt.rst b/Documentation/watchdog/hpwdt.rst
index c165d92cfd12..c824cd7f6e32 100644
--- a/Documentation/watchdog/hpwdt.rst
+++ b/Documentation/watchdog/hpwdt.rst
@@ -63,7 +63,7 @@ Last reviewed: 08/20/2018
and loop forever. This is generally not what a watchdog user wants.
For those wishing to learn more please see:
- Documentation/kdump/kdump.rst
+ Documentation/admin-guide/kdump/kdump.rst
Documentation/admin-guide/kernel-parameters.txt (panic=)
Your Linux Distribution specific documentation.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e2a525e22c0..51bdbd230174 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -899,7 +899,7 @@ L: linux-iio@vger.kernel.org
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/iio/adc/ad7124.c
-F: Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt
+F: Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
ANALOG DEVICES INC AD7606 DRIVER
M: Stefan Popa <stefan.popa@analog.com>
@@ -4190,7 +4190,7 @@ M: Jens Axboe <axboe@kernel.dk>
L: cgroups@vger.kernel.org
L: linux-block@vger.kernel.org
T: git git://git.kernel.dk/linux-block
-F: Documentation/cgroup-v1/blkio-controller.rst
+F: Documentation/admin-guide/cgroup-v1/blkio-controller.rst
F: block/blk-cgroup.c
F: include/linux/blk-cgroup.h
F: block/blk-throttle.c
@@ -6317,7 +6317,7 @@ FLEXTIMER FTM-QUADDEC DRIVER
M: Patrick Havelange <patrick.havelange@essensium.com>
L: linux-iio@vger.kernel.org
S: Maintained
-F: Documentation/ABI/testing/sysfs-bus-counter-ftm-quadddec
+F: Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec
F: Documentation/devicetree/bindings/counter/ftm-quaddec.txt
F: drivers/counter/ftm-quaddec.c
@@ -6856,7 +6856,7 @@ R: Sagi Shahar <sagis@google.com>
R: Jon Olson <jonolson@google.com>
L: netdev@vger.kernel.org
S: Supported
-F: Documentation/networking/device_drivers/google/gve.txt
+F: Documentation/networking/device_drivers/google/gve.rst
F: drivers/net/ethernet/google
GPD POCKET FAN DRIVER
@@ -12137,7 +12137,7 @@ M: Thomas Hellstrom <thellstrom@vmware.com>
M: "VMware, Inc." <pv-drivers@vmware.com>
L: virtualization@lists.linux-foundation.org
S: Supported
-F: Documentation/virt/paravirt_ops.txt
+F: Documentation/virt/paravirt_ops.rst
F: arch/*/kernel/paravirt*
F: arch/*/include/asm/paravirt*.h
F: include/linux/hypervisor.h
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 74a5739df506..80fcd5dc1558 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1686,7 +1686,7 @@ static int drm_mode_parse_cmdline_options(char *str, size_t len,
*
* Additionals options can be provided following the mode, using a comma to
* separate each option. Valid options can be found in
- * Documentation/fb/modedb.txt.
+ * Documentation/fb/modedb.rst.
*
* The intermediate drm_cmdline_mode structure is required to store additional
* options from the command line modline like the force-enable/disable flag.
diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c b/drivers/i2c/busses/i2c-nvidia-gpu.c
index cfc76b5de726..5a1235fd86bb 100644
--- a/drivers/i2c/busses/i2c-nvidia-gpu.c
+++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
@@ -364,7 +364,7 @@ static void gpu_i2c_remove(struct pci_dev *pdev)
/*
* We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
* correctly. Without it, lspci shows runtime pm status as "D0" for the card.
- * Documentation/power/pci.txt also insists for driver to provide this.
+ * Documentation/power/pci.rst also insists for driver to provide this.
*/
static __maybe_unused int gpu_i2c_suspend(struct device *dev)
{
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 43a6b5350775..eaf6177ac9ee 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7798,7 +7798,7 @@ static void hpsa_free_pci_init(struct ctlr_info *h)
hpsa_disable_interrupt_mode(h); /* pci_init 2 */
/*
* call pci_disable_device before pci_release_regions per
- * Documentation/PCI/pci.rst
+ * Documentation/driver-api/pci/pci.rst
*/
pci_disable_device(h->pdev); /* pci_init 1 */
pci_release_regions(h->pdev); /* pci_init 2 */
@@ -7881,7 +7881,7 @@ static int hpsa_pci_init(struct ctlr_info *h)
clean1:
/*
* call pci_disable_device before pci_release_regions per
- * Documentation/PCI/pci.rst
+ * Documentation/driver-api/pci/pci.rst
*/
pci_disable_device(h->pdev);
pci_release_regions(h->pdev);
--
2.21.0
^ permalink raw reply related
* [PATCH v2 23/26] docs: nios2: add it to the main Documentation body
From: Mauro Carvalho Chehab @ 2019-07-26 12:51 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
In-Reply-To: <cover.1564145354.git.mchehab+samsung@kernel.org>
Rename and add the nios2 documentation to the documentation
body.
The nios2 document is already on an ReST compatible format.
All it needs is that the title of the document to be promoted
one level.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/index.rst | 1 +
Documentation/nios2/{README => nios2.rst} | 1 +
2 files changed, 2 insertions(+)
rename Documentation/nios2/{README => nios2.rst} (96%)
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 1ff03833276a..d963db84fc42 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -150,6 +150,7 @@ implementation.
m68k/index
powerpc/index
mips/index
+ nios2/nios2
openrisc/index
parisc/index
riscv/index
diff --git a/Documentation/nios2/README b/Documentation/nios2/nios2.rst
similarity index 96%
rename from Documentation/nios2/README
rename to Documentation/nios2/nios2.rst
index 054a67d55563..43da3f7cee76 100644
--- a/Documentation/nios2/README
+++ b/Documentation/nios2/nios2.rst
@@ -1,3 +1,4 @@
+=================================
Linux on the Nios II architecture
=================================
--
2.21.0
^ permalink raw reply related
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