* Re: [PATCH v4 19/28] docs: powerpc: convert docs to ReST and rename to *.rst
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Linas Vepstas, Russell Currey, Sam Bobroff, Oliver O'Halloran,
Bjorn Helgaas, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Frederic Barrat, Andrew Donnellan,
Manoj N. Kumar, Matthew R. Ochs, Uma Krishnan, Qiang Zhao,
Li Yang, Greg Kroah-Hartman, Jiri Slaby, linux-pci, linuxppc-dev,
linux-scsi, linux-arm-kernel, Andrew Donnellan
In-Reply-To: <63560c1ee7174952e148a353840a17969fe0be2d.1560361364.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 14:52:55 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert docs to ReST and add them to the arch-specific
> book.
>
> The conversion here was trivial, as almost every file there
> was already using an elegant format close to ReST standard.
>
> The changes were mostly to mark literal blocks and add a few
> missing section title identifiers.
>
> One note with regards to "--": on Sphinx, this can't be used
> to identify a list, as it will format it badly. This can be
> used, however, to identify a long hyphen - and "---" is an
> even longer one.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # cxl
This one fails to apply because ...
[...]
> diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
> index 83db42092935..acc21ecca322 100644
> --- a/Documentation/PCI/pci-error-recovery.rst
> +++ b/Documentation/PCI/pci-error-recovery.rst
> @@ -403,7 +403,7 @@ That is, the recovery API only requires that:
> .. note::
>
> Implementation details for the powerpc platform are discussed in
> - the file Documentation/powerpc/eeh-pci-error-recovery.txt
> + the file Documentation/powerpc/eeh-pci-error-recovery.rst
>
> As of this writing, there is a growing list of device drivers with
> patches implementing error recovery. Not all of these patches are in
> @@ -422,3 +422,24 @@ That is, the recovery API only requires that:
> - drivers/net/cxgb3
> - drivers/net/s2io.c
> - drivers/net/qlge
> +
> +>>> As of this writing, there is a growing list of device drivers with
> +>>> patches implementing error recovery. Not all of these patches are in
> +>>> mainline yet. These may be used as "examples":
> +>>>
> +>>> drivers/scsi/ipr
> +>>> drivers/scsi/sym53c8xx_2
> +>>> drivers/scsi/qla2xxx
> +>>> drivers/scsi/lpfc
> +>>> drivers/next/bnx2.c
> +>>> drivers/next/e100.c
> +>>> drivers/net/e1000
> +>>> drivers/net/e1000e
> +>>> drivers/net/ixgb
> +>>> drivers/net/ixgbe
> +>>> drivers/net/cxgb3
> +>>> drivers/net/s2io.c
> +>>> drivers/net/qlge
...of this, which has the look of a set of conflict markers that managed
to get committed...?
jon
^ permalink raw reply
* Re: [PATCH v4 00/28] Convert files to ReST - part 1
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Palmer Dabbelt, Albert Ou, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Greentime Hu,
Vincent Chen, linux-riscv, netdev, bpf
In-Reply-To: <cover.1560361364.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 14:52:36 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> This is mostly a rebase of the /33 series v3 I sent, on the top of the latest
> linux-next (next-20190612).
>
> Changes from v3:
>
> - dropped cpufreq conversion - documents are too outdated;
> - infiniband patch is not here anymore - as it should be merged via RDMA;
> - s390 patches were already merged;
> - Dropped Geert as Maintainer from fb/framebuffer.rst, as per his request;
> - Did a minor editorial change at popwerpc/cxl.rst per Andrew Donellan
> request;
> - Added acks/reviews;
> - trivial rebase fixups.
So I had to pull docs-next forward to -rc4, but then I was able to apply
this set except for parts 5, 6, 14, 18, and 19. Some progress made, but
this is somewhat painful work...
jon
^ permalink raw reply
* Re: [PATCH v5] docs: power: convert docs to ReST and rename to *.rst
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Sebastian Reichel, Rafael J. Wysocki, Viresh Kumar, Len Brown,
Pavel Machek, Nishanth Menon, Stephen Boyd, Liam Girdwood,
Mark Brown, Mathieu Poirier, Suzuki K Poulose, Harry Wei,
Alex Shi, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, x86, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Bjorn Helgaas, Johannes Berg,
David S. Miller, linux-pm, linux-arm-kernel, intel-gfx, dri-devel,
linux-pci, linux-wireless, netdev, Srivatsa S . Bhat
In-Reply-To: <72d1f8f360d395958dd0b49165fc51b58801f57e.1560420621.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019 07:10:36 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
So I can't apply this one due to conflicts in include/linux/pci.h. Bjorn,
perhaps the easiest thing is for you to take this one through your tree?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v4 14/28] docs: locking: convert docs to ReST and rename to *.rst
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Peter Zijlstra, Ingo Molnar, Will Deacon, Federico Vaga,
Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, dri-devel
In-Reply-To: <791f74dab9607d3d349b1e7fe5d0ab5abbb24081.1560361364.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 14:52:50 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert the locking documents to ReST and add them to the
> kernel development book where it belongs.
>
> Most of the stuff here is just to make Sphinx to properly
> parse the text file, as they're already in good shape,
> not requiring massive changes in order to be parsed.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Federico Vaga <federico.vaga@vaga.pv.it>
This patch contains linux-next changes and doesn't apply to docs-next.
Perhaps the best thing to do is to apply it to the locking tree?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] scripts/documentation-file-ref-check: ignore output dir
From: Jonathan Corbet @ 2019-06-14 20:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <093d01459be472a20894c5be6f9b937ff7fd7d47.1560421751.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019 07:29:17 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> When there's no Documentation/output directory, the script will
> complain about those missing references:
>
> Documentation/doc-guide/sphinx.rst: Documentation/output
> Documentation/doc-guide/sphinx.rst: Documentation/output
> Documentation/process/howto.rst: Documentation/output
> Documentation/translations/it_IT/doc-guide/sphinx.rst: Documentation/output
> Documentation/translations/it_IT/doc-guide/sphinx.rst: Documentation/output
> Documentation/translations/it_IT/process/howto.rst: Documentation/output
> Documentation/translations/ja_JP/howto.rst: Documentation/output
> Documentation/translations/ko_KR/howto.rst: Documentation/output
>
> Those are false positives, so add an ignore rule for them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] sphinx.rst: Add note about code snippets embedded in the text
From: Jonathan Corbet @ 2019-06-14 20:39 UTC (permalink / raw)
To: André Almeida; +Cc: linux-doc, linux-kernel, kernel
In-Reply-To: <20190611200316.30054-1-andrealmeid@collabora.com>
On Tue, 11 Jun 2019 17:03:16 -0300
André Almeida <andrealmeid@collabora.com> wrote:
> There's a paragraph that explains how to create fixed width text block,
> but it doesn't explains how to create fixed width text inline, although
> this feature is really used through the documentation. Fix that adding a
> quick note about it.
>
> Signed-off-by: André Almeida <andrealmeid@collabora.com>
Applied, thanks. But I do agree with Jani that we don't want to reproduce
the RST guide here.
jon
^ permalink raw reply
* Re: [RESEND PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Jonathan Corbet @ 2019-06-14 20:44 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: linuxppc-dev, arnd, bhupesh.linux, mpe, benh, paulus,
linux-kernel, linux-doc
In-Reply-To: <1560161019-3895-1-git-send-email-bhsharma@redhat.com>
On Mon, 10 Jun 2019 15:33:39 +0530
Bhupesh Sharma <bhsharma@redhat.com> wrote:
> powerpc architecture (both 64-bit and 32-bit) supports stack protector
> mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
> add stack protector support")].
>
> Update stackprotector arch support documentation to reflect the same.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> ---
> Resend, this time Cc'ing Jonathan and doc-list.
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-14 20:57 UTC (permalink / raw)
To: Yu-cheng Yu, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <b5a915602020a6ce26ea1254f7f60e239c91bc9f.camel@intel.com>
On 6/14/19 10:13 AM, Yu-cheng Yu wrote:
> On Fri, 2019-06-14 at 09:13 -0700, Dave Hansen wrote:
>> On 6/14/19 8:25 AM, Yu-cheng Yu wrote:
>>> The bitmap is very big.
>>
>> Really? It's actually, what, 8*4096=32k, so 1/32,768th of the size of
>> the libraries legacy libraries you load? Do our crash dumps really not
>> know how to represent or deal with sparse mappings?
>
> Ok, even the core dump is not physically big, its size still looks odd, right?
Hell if I know.
Could you please go try this in practice so that we're designing this
thing fixing real actual problems instead of phantoms that we're
anticipating?
> Could this also affect how much time for GDB to load it.
I don't know. Can you go find out for sure, please?
> I have a related question:
>
> Do we allow the application to read the bitmap, or any fault from the
> application on bitmap pages?
We have to allow apps to read it. Otherwise they can't execute
instructions.
We don't have to allow them to (popuating) fault on it. But, if we
don't, we need some kind of kernel interface to avoid the faults.
^ permalink raw reply
* INQUIRY -AGRA POLANDS
From: Mrkt dept @ 2019-06-14 20:33 UTC (permalink / raw)
To: Recipients
Hello Sir,
Greetings rom Agra Polands.
we have been building our international business since 1997, dealing with a wide range of luxury consumer goods in order to efficiently and effectively satisfy all our customers’ demands.
Kindly confirm if you be able to supply us with our desired items.
What is your Payment terms and Shipments?.
Regards
Riccardo Corbo
International Buyer & Analyst
Address:Via Trento, 7/F - Lomazzo (CO) - Italy VAT IT 12165160156
agra.poland@aol.com
^ permalink raw reply
* Re: [PATCH v5] docs: power: convert docs to ReST and rename to *.rst
From: Bjorn Helgaas @ 2019-06-14 21:14 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Sebastian Reichel,
Rafael J. Wysocki, Viresh Kumar, Len Brown, Pavel Machek,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown,
Mathieu Poirier, Suzuki K Poulose, Harry Wei, Alex Shi,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
Daniel Vetter, Johannes Berg, David S. Miller, linux-pm,
linux-arm-kernel, intel-gfx, dri-devel, linux-pci, linux-wireless,
netdev, Srivatsa S . Bhat
In-Reply-To: <20190614143631.7c99719f@lwn.net>
On Fri, Jun 14, 2019 at 02:36:31PM -0600, Jonathan Corbet wrote:
> On Thu, 13 Jun 2019 07:10:36 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > Convert the PM documents to ReST, in order to allow them to
> > build with Sphinx.
> >
> > The conversion is actually:
> > - add blank lines and identation in order to identify paragraphs;
> > - fix tables markups;
> > - add some lists markups;
> > - mark literal blocks;
> > - adjust title markups.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Mark Brown <broonie@kernel.org>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
>
> So I can't apply this one due to conflicts in include/linux/pci.h. Bjorn,
> perhaps the easiest thing is for you to take this one through your tree?
OK, I applied this to pci/docs for v5.3. I applied this entire patch,
but if you would prefer that I only apply the PCI-related parts, let
me know and I'll split those out.
Bjorn
^ permalink raw reply
* Re: [PATCH v4 19/28] docs: powerpc: convert docs to ReST and rename to *.rst
From: Bjorn Helgaas @ 2019-06-14 21:30 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Linas Vepstas,
Russell Currey, Sam Bobroff, Oliver O'Halloran,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Frederic Barrat, Andrew Donnellan, Manoj N. Kumar,
Matthew R. Ochs, Uma Krishnan, Qiang Zhao, Li Yang,
Greg Kroah-Hartman, Jiri Slaby, linux-pci, linuxppc-dev,
linux-scsi, linux-arm-kernel, Andrew Donnellan
In-Reply-To: <20190614143635.3aff154d@lwn.net>
On Fri, Jun 14, 2019 at 02:36:35PM -0600, Jonathan Corbet wrote:
> On Wed, 12 Jun 2019 14:52:55 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > Convert docs to ReST and add them to the arch-specific
> > book.
> >
> > The conversion here was trivial, as almost every file there
> > was already using an elegant format close to ReST standard.
> >
> > The changes were mostly to mark literal blocks and add a few
> > missing section title identifiers.
> >
> > One note with regards to "--": on Sphinx, this can't be used
> > to identify a list, as it will format it badly. This can be
> > used, however, to identify a long hyphen - and "---" is an
> > even longer one.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # cxl
>
> This one fails to apply because ...
>
> [...]
>
> > diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
> > index 83db42092935..acc21ecca322 100644
> > --- a/Documentation/PCI/pci-error-recovery.rst
> > +++ b/Documentation/PCI/pci-error-recovery.rst
> > @@ -403,7 +403,7 @@ That is, the recovery API only requires that:
> > .. note::
> >
> > Implementation details for the powerpc platform are discussed in
> > - the file Documentation/powerpc/eeh-pci-error-recovery.txt
> > + the file Documentation/powerpc/eeh-pci-error-recovery.rst
> >
> > As of this writing, there is a growing list of device drivers with
> > patches implementing error recovery. Not all of these patches are in
> > @@ -422,3 +422,24 @@ That is, the recovery API only requires that:
> > - drivers/net/cxgb3
> > - drivers/net/s2io.c
> > - drivers/net/qlge
> > +
> > +>>> As of this writing, there is a growing list of device drivers with
> > +>>> patches implementing error recovery. Not all of these patches are in
> > +>>> mainline yet. These may be used as "examples":
> > +>>>
> > +>>> drivers/scsi/ipr
> > +>>> drivers/scsi/sym53c8xx_2
> > +>>> drivers/scsi/qla2xxx
> > +>>> drivers/scsi/lpfc
> > +>>> drivers/next/bnx2.c
> > +>>> drivers/next/e100.c
> > +>>> drivers/net/e1000
> > +>>> drivers/net/e1000e
> > +>>> drivers/net/ixgb
> > +>>> drivers/net/ixgbe
> > +>>> drivers/net/cxgb3
> > +>>> drivers/net/s2io.c
> > +>>> drivers/net/qlge
>
> ...of this, which has the look of a set of conflict markers that managed
> to get committed...?
I don't see these conflict markers in my local branch or in
linux-next (next-20190614).
Let me know if I need to do something.
Bjorn
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-14 21:34 UTC (permalink / raw)
To: Dave Hansen, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <598edca7-c36a-a236-3b72-08b2194eb609@intel.com>
On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote:
> On 6/14/19 10:13 AM, Yu-cheng Yu wrote:
> > On Fri, 2019-06-14 at 09:13 -0700, Dave Hansen wrote:
> > > On 6/14/19 8:25 AM, Yu-cheng Yu wrote:
> > > > The bitmap is very big.
> > >
> > > Really? It's actually, what, 8*4096=32k, so 1/32,768th of the size of
> > > the libraries legacy libraries you load? Do our crash dumps really not
> > > know how to represent or deal with sparse mappings?
> >
> > Ok, even the core dump is not physically big, its size still looks odd,
> > right?
>
> Hell if I know.
>
> Could you please go try this in practice so that we're designing this
> thing fixing real actual problems instead of phantoms that we're
> anticipating?
>
> > Could this also affect how much time for GDB to load it.
>
> I don't know. Can you go find out for sure, please?
OK!
>
> > I have a related question:
> >
> > Do we allow the application to read the bitmap, or any fault from the
> > application on bitmap pages?
>
> We have to allow apps to read it. Otherwise they can't execute
> instructions.
What I meant was, if an app executes some legacy code that results in bitmap
lookup, but the bitmap page is not yet populated, and if we then populate that
page with all-zero, a #CP should follow. So do we even populate that zero page
at all?
I think we should; a #CP is more obvious to the user at least.
>
> We don't have to allow them to (popuating) fault on it. But, if we
> don't, we need some kind of kernel interface to avoid the faults.
The plan is:
* Move STACK_TOP (and vdso) down to give space to the bitmap.
* Reserve the bitmap space from (mm->start_stack + PAGE_SIZE) to cover a code
size of TASK_SIZE_LOW, which is (TASK_SIZE_LOW / PAGE_SIZE / 8).
* Mmap the space only when the app issues the first mark-legacy prctl. This
avoids the core-dump issue for most apps and the accounting problem that
MAP_NORESERVE probably won't solve completely.
* The bitmap is read-only. The kernel sets the bitmap with
get_user_pages_fast(FOLL_WRITE) and user_access_begin()/user_addess_end().
I will send out a RFC patch.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-14 22:06 UTC (permalink / raw)
To: Yu-cheng Yu, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <359e6f64d646d5305c52f393db5296c469630d11.camel@intel.com>
On 6/14/19 2:34 PM, Yu-cheng Yu wrote:
> On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote:
>>> I have a related question:
>>>
>>> Do we allow the application to read the bitmap, or any fault from the
>>> application on bitmap pages?
>>
>> We have to allow apps to read it. Otherwise they can't execute
>> instructions.
>
> What I meant was, if an app executes some legacy code that results in bitmap
> lookup, but the bitmap page is not yet populated, and if we then populate that
> page with all-zero, a #CP should follow. So do we even populate that zero page
> at all?
>
> I think we should; a #CP is more obvious to the user at least.
Please make an effort to un-Intel-ificate your messages as much as
possible. I'd really prefer that folks say "missing end branch fault"
rather than #CP. I had to Google "#CP".
I *think* you are saying that: The *only* lookups to this bitmap are on
"missing end branch" conditions. Normal, proper-functioning code
execution that has ENDBR instructions in it will never even look at the
bitmap. The only case when we reference the bitmap locations is when
the processor is about do do a "missing end branch fault" so that it can
be suppressed. Any population with the zero page would be done when
code had already encountered a "missing end branch" condition, and
populating with a zero-filled page will guarantee that a "missing end
branch fault" will result. You're arguing that we should just figure
this out at fault time and not ever reach the "missing end branch fault"
at all.
Is that right?
If so, that's an architecture subtlety that I missed until now and which
went entirely unmentioned in the changelog and discussion up to this
point. Let's make sure that nobody else has to walk that path by
improving our changelog, please.
In any case, I don't think this is worth special-casing our zero-fill
code, FWIW. It's not performance critical and not worth the complexity.
If apps want to handle the signals and abuse this to fill space up with
boring page table contents, they're welcome to. There are much easier
ways to consume a lot of memory.
>> We don't have to allow them to (popuating) fault on it. But, if we
>> don't, we need some kind of kernel interface to avoid the faults.
>
> The plan is:
>
> * Move STACK_TOP (and vdso) down to give space to the bitmap.
Even for apps with 57-bit address spaces?
> * Reserve the bitmap space from (mm->start_stack + PAGE_SIZE) to cover a code
> size of TASK_SIZE_LOW, which is (TASK_SIZE_LOW / PAGE_SIZE / 8).
The bitmap size is determined by CR4.LA57, not the app. If you place
the bitmap here, won't references to it for high addresses go into the
high address space?
Specifically, on a CR4.LA57=0 system, we have 48 bits of address space,
so 128TB for apps. You are proposing sticking the bitmap above the
stack which is near the top of that 128TB address space. But on a
5-level paging system with CR4.LA57=1, there could be valid data at
129GB. Is there something keeping that data from being mistaken for
being part of the bitmap?
Also, if you're limiting it to TASK_SIZE_LOW, please don't forget that
this is yet another thing that probably won't work with the vsyscall
page. Please make sure you consider it and mention it in your next post.
> * Mmap the space only when the app issues the first mark-legacy prctl. This
> avoids the core-dump issue for most apps and the accounting problem that
> MAP_NORESERVE probably won't solve completely.
What is this accounting problem?
^ permalink raw reply
* Re: [PATCH v4 01/18] kunit: test: add KUnit test runner core
From: Brendan Higgins @ 2019-06-14 23:22 UTC (permalink / raw)
To: Stephen Boyd
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190517185304.24EBE20848@mail.kernel.org>
On Fri, May 17, 2019 at 11:53 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:54)
> > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > new file mode 100644
> > index 0000000000000..e682ea0e1f9a5
> > --- /dev/null
> > +++ b/include/kunit/test.h
> > @@ -0,0 +1,162 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Base unit test (KUnit) API.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins <brendanhiggins@google.com>
> > + */
> > +
> > +#ifndef _KUNIT_TEST_H
> > +#define _KUNIT_TEST_H
> > +
> > +#include <linux/types.h>
> > +#include <linux/slab.h>
>
> Is this include used here?
Err, it is used in the very next commit in the sequence. Sorry, I will
add it in the commit that actually uses it in the next revision.
> > +
> > +struct kunit;
> > +
> > +/**
> > + * struct kunit_case - represents an individual test case.
> > + * @run_case: the function representing the actual test case.
> > + * @name: the name of the test case.
> > + *
> > + * A test case is a function with the signature, ``void (*)(struct kunit *)``
> > + * that makes expectations (see KUNIT_EXPECT_TRUE()) about code under test. Each
> > + * test case is associated with a &struct kunit_module and will be run after the
> > + * module's init function and followed by the module's exit function.
> > + *
> > + * A test case should be static and should only be created with the KUNIT_CASE()
> > + * macro; additionally, every array of test cases should be terminated with an
> > + * empty test case.
> > + *
> > + * Example:
> > + *
> > + * .. code-block:: c
> > + *
> > + * void add_test_basic(struct kunit *test)
> > + * {
> > + * KUNIT_EXPECT_EQ(test, 1, add(1, 0));
> > + * KUNIT_EXPECT_EQ(test, 2, add(1, 1));
> > + * KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
> > + * KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
> > + * KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
> > + * }
> > + *
> > + * static struct kunit_case example_test_cases[] = {
> > + * KUNIT_CASE(add_test_basic),
> > + * {},
>
> Nitpick: Please drop the comma on the sentinel so nobody gets ideas to
> add another entry after it.
Good idea. Will fix here and elsewhere.
> > + * };
> > + *
> > + */
> > +struct kunit_case {
> > + void (*run_case)(struct kunit *test);
> > + const char name[256];
>
> Maybe 256 can be a #define KUNIT_NAME_MAX_LEN? Or it could just be a
> const char pointer to a literal pool? Are unit tests making up names at
> runtime?
Yeah, sorry, I forgot why I did it this way in the first place. Will
fix in next revision.
> > +
> > + /* private: internal use only. */
> > + bool success;
> > +};
> > +
> > +/**
> > + * KUNIT_CASE - A helper for creating a &struct kunit_case
> > + * @test_name: a reference to a test case function.
> > + *
> > + * Takes a symbol for a function representing a test case and creates a
> > + * &struct kunit_case object from it. See the documentation for
> > + * &struct kunit_case for an example on how to use it.
> > + */
> > +#define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
> > +
> > +/**
> > + * struct kunit_module - describes a related collection of &struct kunit_case s.
> > + * @name: the name of the test. Purely informational.
> > + * @init: called before every test case.
> > + * @exit: called after every test case.
> > + * @test_cases: a null terminated array of test cases.
> > + *
> > + * A kunit_module is a collection of related &struct kunit_case s, such that
> > + * @init is called before every test case and @exit is called after every test
> > + * case, similar to the notion of a *test fixture* or a *test class* in other
> > + * unit testing frameworks like JUnit or Googletest.
> > + *
> > + * Every &struct kunit_case must be associated with a kunit_module for KUnit to
> > + * run it.
> > + */
> > +struct kunit_module {
> > + const char name[256];
> > + int (*init)(struct kunit *test);
> > + void (*exit)(struct kunit *test);
> > + struct kunit_case *test_cases;
>
> Can this variable be const? Or we expect test modules to adjust test_cases after
> the fact?
I understand why it would be nice to do it that way, but we store the
failed result on test cases; I don't think it really makes sense to
have another parallel data structure just for the results on each test
case.
> > +};
> > +
> > +/**
> > + * struct kunit - represents a running instance of a test.
> > + * @priv: for user to store arbitrary data. Commonly used to pass data created
> > + * in the init function (see &struct kunit_module).
> > + *
> > + * Used to store information about the current context under which the test is
> > + * running. Most of this data is private and should only be accessed indirectly
> > + * via public functions; the one exception is @priv which can be used by the
> > + * test writer to store arbitrary data.
> > + */
> > +struct kunit {
> > + void *priv;
> > +
> > + /* private: internal use only. */
> > + const char *name; /* Read only after initialization! */
> > + spinlock_t lock; /* Gaurds all mutable test state. */
> > + bool success; /* Protected by lock. */
> > +};
> > +
> > +void kunit_init_test(struct kunit *test, const char *name);
> > +
> > +int kunit_run_tests(struct kunit_module *module);
> > +
> > +/**
> > + * module_test() - used to register a &struct kunit_module with KUnit.
> > + * @module: a statically allocated &struct kunit_module.
> > + *
> > + * Registers @module with the test framework. See &struct kunit_module for more
> > + * information.
> > + */
> > +#define module_test(module) \
> > + static int module_kunit_init##module(void) \
> > + { \
> > + return kunit_run_tests(&module); \
> > + } \
> > + late_initcall(module_kunit_init##module)
>
> Maybe we need to introduce another initcall level after
> late_initcall_sync() for tests? I wonder if there will be tests that
> need to run after all other initcalls have run, including late sync
> initcalls.
Yeah, I have another patch ready to go to do that. I guess I just
figured that was something that could lead to a lot of bikeshedding
that I wanted to avoid in the initial patchset.
Nevertheless, I can add it in if you feel it is better to discuss now.
> > +
> > +void __printf(3, 4) kunit_printk(const char *level,
> > + const struct kunit *test,
> > + const char *fmt, ...);
> > +
> > +/**
> > + * kunit_info() - Prints an INFO level message associated with the current test.
> > + * @test: The test context object.
> > + * @fmt: A printk() style format string.
> > + *
> > + * Prints an info level message associated with the test module being run. Takes
> > + * a variable number of format parameters just like printk().
> > + */
> > +#define kunit_info(test, fmt, ...) \
> > + kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__)
> > +
> > +/**
> > + * kunit_warn() - Prints a WARN level message associated with the current test.
> > + * @test: The test context object.
> > + * @fmt: A printk() style format string.
> > + *
> > + * See kunit_info().
>
> Why? Just write out that it "Prints a warning level message".
>
> > + */
> > +#define kunit_warn(test, fmt, ...) \
> > + kunit_printk(KERN_WARNING, test, fmt, ##__VA_ARGS__)
> > +
> > +/**
> > + * kunit_err() - Prints an ERROR level message associated with the current test.
> > + * @test: The test context object.
> > + * @fmt: A printk() style format string.
> > + *
> > + * See kunit_info().
>
> Same comment.
>
> > + */
> > +#define kunit_err(test, fmt, ...) \
> > + kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__)
> > +
> > +#endif /* _KUNIT_TEST_H */
> > diff --git a/kunit/Kconfig b/kunit/Kconfig
> > new file mode 100644
> > index 0000000000000..64480092b2c24
> > --- /dev/null
> > +++ b/kunit/Kconfig
> > @@ -0,0 +1,16 @@
> > +#
> > +# KUnit base configuration
> > +#
> > +
> > +menu "KUnit support"
> > +
> > +config KUNIT
> > + bool "Enable support for unit tests (KUnit)"
> > + help
> > + Enables support for kernel unit tests (KUnit), a lightweight unit
> > + testing and mocking framework for the Linux kernel. These tests are
> > + able to be run locally on a developer's workstation without a VM or
> > + special hardware. For more information, please see
> > + Documentation/kunit/
>
> This moved and needs an update.
>
> > +
> > +endmenu
> > diff --git a/kunit/Makefile b/kunit/Makefile
> > new file mode 100644
> > index 0000000000000..5efdc4dea2c08
> > --- /dev/null
> > +++ b/kunit/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_KUNIT) += test.o
> > diff --git a/kunit/test.c b/kunit/test.c
> > new file mode 100644
> > index 0000000000000..86f65ba2bcf92
> > --- /dev/null
> > +++ b/kunit/test.c
> > @@ -0,0 +1,229 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Base unit test (KUnit) API.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins <brendanhiggins@google.com>
> > + */
> > +
> > +#include <linux/sched.h>
>
> This include gets removed later in the series, was it ever needed?
Nope, that was a mistake. Sorry.
> > +#include <linux/sched/debug.h>
> > +#include <kunit/test.h>
> > +
> > +static bool kunit_get_success(struct kunit *test)
> > +{
> > + unsigned long flags;
> > + bool success;
> > +
> > + spin_lock_irqsave(&test->lock, flags);
> > + success = test->success;
> > + spin_unlock_irqrestore(&test->lock, flags);
> > +
> > + return success;
> > +}
> > +
> > +static void kunit_set_success(struct kunit *test, bool success)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&test->lock, flags);
> > + test->success = success;
> > + spin_unlock_irqrestore(&test->lock, flags);
> > +}
> > +
> > +static int kunit_vprintk_emit(int level, const char *fmt, va_list args)
> > +{
> > + return vprintk_emit(0, level, NULL, 0, fmt, args);
> > +}
> > +
> > +static int kunit_printk_emit(int level, const char *fmt, ...)
> > +{
> > + va_list args;
> > + int ret;
> > +
> > + va_start(args, fmt);
> > + ret = kunit_vprintk_emit(level, fmt, args);
> > + va_end(args);
> > +
> > + return ret;
> > +}
> > +
> > +static void kunit_vprintk(const struct kunit *test,
> > + const char *level,
> > + struct va_format *vaf)
> > +{
> > + kunit_printk_emit(level[1] - '0', "\t# %s: %pV", test->name, vaf);
> > +}
> > +
> > +static bool kunit_has_printed_tap_version;
> > +
> > +static void kunit_print_tap_version(void)
> > +{
> > + if (!kunit_has_printed_tap_version) {
> > + kunit_printk_emit(LOGLEVEL_INFO, "TAP version 14\n");
> > + kunit_has_printed_tap_version = true;
> > + }
> > +}
> > +
> > +static size_t kunit_test_cases_len(struct kunit_case *test_cases)
> > +{
> > + struct kunit_case *test_case;
> > + size_t len = 0;
> > +
> > + for (test_case = test_cases; test_case->run_case; test_case++)
> > + len++;
> > +
> > + return len;
> > +}
> > +
> > +static void kunit_print_subtest_start(struct kunit_module *module)
> > +{
> > + kunit_print_tap_version();
> > + kunit_printk_emit(LOGLEVEL_INFO, "\t# Subtest: %s\n", module->name);
> > + kunit_printk_emit(LOGLEVEL_INFO,
> > + "\t1..%zd\n",
> > + kunit_test_cases_len(module->test_cases));
> > +}
> > +
> > +static void kunit_print_ok_not_ok(bool should_indent,
> > + bool is_ok,
> > + size_t test_number,
> > + const char *description)
> > +{
> > + const char *indent, *ok_not_ok;
> > +
> > + if (should_indent)
> > + indent = "\t";
> > + else
> > + indent = "";
> > +
> > + if (is_ok)
> > + ok_not_ok = "ok";
> > + else
> > + ok_not_ok = "not ok";
> > +
> > + kunit_printk_emit(LOGLEVEL_INFO,
> > + "%s%s %zd - %s\n",
> > + indent, ok_not_ok, test_number, description);
> > +}
> > +
> > +static bool kunit_module_has_succeeded(struct kunit_module *module)
> > +{
> > + struct kunit_case *test_case;
>
> This can be const?
Yep, nice catch.
> > + bool success = true;
> > +
> > + for (test_case = module->test_cases; test_case->run_case; test_case++)
> > + if (!test_case->success)
> > + success = false;
>
> Bail out early here on first "fail" with return false?
Will fix on next revision.
> > +
> > + return success;
> > +}
> > +
> > +size_t kunit_module_counter = 1;
> > +
> > +static void kunit_print_subtest_end(struct kunit_module *module)
> > +{
> > + kunit_print_ok_not_ok(false,
> > + kunit_module_has_succeeded(module),
> > + kunit_module_counter++,
> > + module->name);
> > +}
> > +
> > +static void kunit_print_test_case_ok_not_ok(struct kunit_case *test_case,
> > + size_t test_number)
> > +{
> > + kunit_print_ok_not_ok(true,
> > + test_case->success,
> > + test_number,
> > + test_case->name);
> > +}
> > +
> > +void kunit_init_test(struct kunit *test, const char *name)
> > +{
> > + spin_lock_init(&test->lock);
> > + test->name = name;
> > +}
> > +
> > +/*
> > + * Initializes and runs test case. Does not clean up or do post validations.
> > + */
> > +static void kunit_run_case_internal(struct kunit *test,
> > + struct kunit_module *module,
> > + struct kunit_case *test_case)
> > +{
> > + int ret;
> > +
> > + if (module->init) {
> > + ret = module->init(test);
> > + if (ret) {
> > + kunit_err(test, "failed to initialize: %d\n", ret);
> > + kunit_set_success(test, false);
> > + return;
> > + }
> > + }
> > +
> > + test_case->run_case(test);
> > +}
> > +
> > +/*
> > + * Performs post validations and cleanup after a test case was run.
> > + * XXX: Should ONLY BE CALLED AFTER kunit_run_case_internal!
> > + */
> > +static void kunit_run_case_cleanup(struct kunit *test,
> > + struct kunit_module *module,
> > + struct kunit_case *test_case)
>
> But test_case isn't used?
Whoops, will fix.
> > +{
> > + if (module->exit)
>
> Aha, so we don't need empty functions in the sysctl test.
Nope, sorry about that. That will be fixed in the next revision.
> > + module->exit(test);
> > +}
> > +
> > +/*
> > + * Performs all logic to run a test case.
> > + */
> > +static void kunit_run_case(struct kunit_module *module,
> > + struct kunit_case *test_case)
> > +{
> > + struct kunit test;
> > +
> > + kunit_init_test(&test, test_case->name);
> > + kunit_set_success(&test, true);
>
> Can kunit_init_test() also kunit_set_success() to true or false,
> depending on what is desired as the initial state?
>
> > +
> > + kunit_run_case_internal(&test, module, test_case);
> > + kunit_run_case_cleanup(&test, module, test_case);
>
> I find this odd, we have run_case_internal() that does two things, init
> and run_case, while case_cleanup() does one thing, call module->exit().
>
> Can we just inline all those functions in here so that it looks like
> this:
>
> int ret = 0;
>
> if (module->init) {
> ret = module->init(test);
> if (ret) {
> kunit_err(test, "failed to initialize: %d\n", ret);
> kunit_set_success(&test, false);
> }
> }
>
> if (!ret)
> test_case->run_case(&test);
>
> if (module->exit)
> module->exit(&test);
>
> return kunit_get_success(&test);
>
> Then I don't have to read two more functions to figure out the flow of
> running a test case.
Sorry about that. A lot more logic gets added to running test cases
later on in this patchset. This logic added "later" is actually older
than what's here, so I basically "unrefactored" something I had
already written to get this earlier patch.
In anycase, you are right; these little tiny functions don't make any
sense (yet); I will remove them in the next revision (and let the
later patch make these changes in a more organic looking way).
>
> > +
> > + test_case->success = kunit_get_success(&test);
> > +}
> > +
> > +int kunit_run_tests(struct kunit_module *module)
> > +{
> > + struct kunit_case *test_case;
> > + size_t test_case_count = 1;
>
> Might make sense to assign this to 0 first and then pre-increment so
> that test_case_count can't be 1 when there aren't any tests?
No, sorry, this is actually specified by the Test Anything Protocol
(TAP); it indexes it's tests starting at 1; not what I would have
done, but we (Greg, Frank, myself, and others) previously agreed that
KUnit should follow TAP[1].
Maybe the name of this variable is a bit misleading since it is the
"test number" or test index. Would `test_case_number` be better?
> > +
> > + kunit_print_subtest_start(module);
> > +
> > + for (test_case = module->test_cases; test_case->run_case; test_case++) {
> > + kunit_run_case(module, test_case);
> > + kunit_print_test_case_ok_not_ok(test_case, test_case_count++);
>
> Can this be pushed into kunit_run_case() and have that function take a
> test_case_count number? Maybe that would allow us to avoid storing
> test_case->success entirely? Assuming that kunit_run_case() returned a
> value like success or failure, then yes it would work.
Eh, I would prefer not to do that. I like keeping the
printing/reporting functions as orthogonal as possible; it kind of
mirrors the parsing logic on the test harness script side, and will
also be easier to pull out when I go back to improve the expectation
failure reporting when I get around to that later. Even if I never get
around to that, I think this will be much easier for me to maintain.
> unsigned int failed = 0;
>
> for (test_case = module->test_cases; test_case->run_case; test_case++) {
> failed |= kunit_run_case(module, test_case, ++test_case_count);
>
> kunit_print_ok_not_ok(false,
> !failed,
> kunit_module_counter++,
> module->name);
>
> > + kunit_print_subtest_end(module);
> > +
> > + return 0;
> > +}
[1] https://github.com/TestAnything/Specification/blob/tap-14-specification/specification.md#the-test-line
^ permalink raw reply
* Re: [PATCH v2 00/16] Add support to generate ABI documentation at admin-guide
From: Greg Kroah-Hartman @ 2019-06-15 6:15 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Rajat Jain, Bjorn Helgaas
In-Reply-To: <20190614150736.043cb2dd@coco.lan>
On Fri, Jun 14, 2019 at 03:07:36PM -0300, Mauro Carvalho Chehab wrote:
> Greg,
>
> In time: forgot to add a 00/16 patch... someone come to my desk while I was
> sending this... sorry for that.
>
> That's the second version of the doc ABI updated logic.
>
> Changes from version 1:
>
> - I updated my e-mail on older patches;
>
> - Two new ABI fix patches;
Both abi fix patches now queued up, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 14/14] docs: sphinx/kernel_abi.py: fix UTF-8 support
From: Greg Kroah-Hartman @ 2019-06-15 6:16 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <20190614132530.7a013757@coco.lan>
On Fri, Jun 14, 2019 at 01:25:30PM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 14 Jun 2019 18:18:37 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
> > On Thu, Jun 13, 2019 at 11:04:20PM -0300, Mauro Carvalho Chehab wrote:
> > > The parser breaks with UTF-8 characters with Sphinx 1.4.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > ---
> > > Documentation/sphinx/kernel_abi.py | 10 ++++++----
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py
> > > index 7fa7806532dc..460cee48a245 100644
> > > --- a/Documentation/sphinx/kernel_abi.py
> > > +++ b/Documentation/sphinx/kernel_abi.py
> > > @@ -1,4 +1,5 @@
> > > -# -*- coding: utf-8; mode: python -*-
> > > +# coding=utf-8
> > > +#
> >
> > Is this an emacs vs. vim fight?
>
> No. This is a python-specific thing:
>
> https://www.python.org/dev/peps/pep-0263/
Ah, thanks, didn't know that.
greg k-h
^ permalink raw reply
* Re: [PATCH v10 3/3] watchdog: make the device time out at open_deadline when open_timeout is used
From: Wim Van Sebroeck @ 2019-06-15 10:02 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Guenter Roeck, linux-watchdog@vger.kernel.org, Wim Van Sebroeck,
Jonathan Corbet, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, Esben Haabendal, Jerry Hoemann,
Rasmus Villemoes
In-Reply-To: <56280052-9437-9813-a24e-125abb876762@prevas.dk>
Hi Rasmus,
> > On Wed, Jun 05, 2019 at 02:06:44PM +0000, Rasmus Villemoes wrote:
> >> When the watchdog device is not open by userspace, the kernel takes
> >> care of pinging it. When the open_timeout feature is in use, we should
> >> ensure that the hardware fires close to open_timeout seconds after the
> >> kernel has assumed responsibility for the device.
> >>
> >> To do this, simply reuse the logic that is already in place for
> >> ensuring the same thing when userspace is responsible for regularly
> >> pinging the device:
> >>
> >> - When watchdog_active(wdd), this patch doesn't change anything.
> >>
> >> - When !watchdoc_active(wdd), the "virtual timeout" should be taken to
> >
> > s/watchdoc_active/watchdog_active/
> >
> > otherwise
> >
> > Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> Thanks! Wim, can you fix up if/when applying, or do you prefer I resend?
I'll fix up when applying. No need to resend a new patch for that.
Kind regards,
Wim.
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Andy Lutomirski @ 2019-06-15 15:30 UTC (permalink / raw)
To: Dave Hansen
Cc: Yu-cheng Yu, Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <5d7012f6-7ab9-fd3d-4a11-294258e48fb5@intel.com>
> On Jun 14, 2019, at 3:06 PM, Dave Hansen <dave.hansen@intel.com> wrote:
>
>> On 6/14/19 2:34 PM, Yu-cheng Yu wrote:
>> On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote:
>>>> I have a related question:
>>>>
>>>> Do we allow the application to read the bitmap, or any fault from the
>>>> application on bitmap pages?
>>>
>>> We have to allow apps to read it. Otherwise they can't execute
>>> instructions.
>>
>> What I meant was, if an app executes some legacy code that results in bitmap
>> lookup, but the bitmap page is not yet populated, and if we then populate that
>> page with all-zero, a #CP should follow. So do we even populate that zero page
>> at all?
>>
>> I think we should; a #CP is more obvious to the user at least.
>
> Please make an effort to un-Intel-ificate your messages as much as
> possible. I'd really prefer that folks say "missing end branch fault"
> rather than #CP. I had to Google "#CP".
>
> I *think* you are saying that: The *only* lookups to this bitmap are on
> "missing end branch" conditions. Normal, proper-functioning code
> execution that has ENDBR instructions in it will never even look at the
> bitmap. The only case when we reference the bitmap locations is when
> the processor is about do do a "missing end branch fault" so that it can
> be suppressed. Any population with the zero page would be done when
> code had already encountered a "missing end branch" condition, and
> populating with a zero-filled page will guarantee that a "missing end
> branch fault" will result. You're arguing that we should just figure
> this out at fault time and not ever reach the "missing end branch fault"
> at all.
>
> Is that right?
>
> If so, that's an architecture subtlety that I missed until now and which
> went entirely unmentioned in the changelog and discussion up to this
> point. Let's make sure that nobody else has to walk that path by
> improving our changelog, please.
>
> In any case, I don't think this is worth special-casing our zero-fill
> code, FWIW. It's not performance critical and not worth the complexity.
> If apps want to handle the signals and abuse this to fill space up with
> boring page table contents, they're welcome to. There are much easier
> ways to consume a lot of memory.
Isn’t it a special case either way? Either we look at CR2 and populate a page, or we look at CR2 and the “tracker” state and send a different signal. Admittedly the former is very common in the kernel.
>
>>> We don't have to allow them to (popuating) fault on it. But, if we
>>> don't, we need some kind of kernel interface to avoid the faults.
>>
>> The plan is:
>>
>> * Move STACK_TOP (and vdso) down to give space to the bitmap.
>
> Even for apps with 57-bit address spaces?
>
>> * Reserve the bitmap space from (mm->start_stack + PAGE_SIZE) to cover a code
>> size of TASK_SIZE_LOW, which is (TASK_SIZE_LOW / PAGE_SIZE / 8).
>
> The bitmap size is determined by CR4.LA57, not the app. If you place
> the bitmap here, won't references to it for high addresses go into the
> high address space?
>
> Specifically, on a CR4.LA57=0 system, we have 48 bits of address space,
> so 128TB for apps. You are proposing sticking the bitmap above the
> stack which is near the top of that 128TB address space. But on a
> 5-level paging system with CR4.LA57=1, there could be valid data at
> 129GB. Is there something keeping that data from being mistaken for
> being part of the bitmap?
>
I think we need to make the vma be full sized — it should cover the entire range that the CPU might access. If that means it spans the 48-bit boundary, so be it.
> Also, if you're limiting it to TASK_SIZE_LOW, please don't forget that
> this is yet another thing that probably won't work with the vsyscall
> page. Please make sure you consider it and mention it in your next post.
Why not? The vsyscall page is at a negative address.
>
>> * Mmap the space only when the app issues the first mark-legacy prctl. This
>> avoids the core-dump issue for most apps and the accounting problem that
>> MAP_NORESERVE probably won't solve
What happens if there’s another VMA there by the time you map it?
^ permalink raw reply
* Re: [PATCH v1 24/31] docs: iio: convert to ReST
From: Jonathan Cameron @ 2019-06-16 13:47 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio
In-Reply-To: <6b9df01697dde8b9bb9be9accf28d63ed821956d.1560364494.git.mchehab+samsung@kernel.org>
On Wed, 12 Jun 2019 15:38:27 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Rename the iio documentation files to ReST, add an
> index for them and adjust in order to produce a nice html
> output via the Sphinx build system.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Thanks, looks good to me. At some point we need to look at how
to tie together the various IIO docs as they are split between
here and the driver-api/iio/ directory. That split isn't currently
along particularly logical lines.
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Thanks for tidying this up!
Jonathan
> ---
> .../iio/{ep93xx_adc.txt => ep93xx_adc.rst} | 15 +++++-
> .../{iio_configfs.txt => iio_configfs.rst} | 52 +++++++++++--------
> Documentation/iio/index.rst | 12 +++++
> drivers/iio/Kconfig | 2 +-
> 4 files changed, 56 insertions(+), 25 deletions(-)
> rename Documentation/iio/{ep93xx_adc.txt => ep93xx_adc.rst} (71%)
> rename Documentation/iio/{iio_configfs.txt => iio_configfs.rst} (73%)
> create mode 100644 Documentation/iio/index.rst
>
> diff --git a/Documentation/iio/ep93xx_adc.txt b/Documentation/iio/ep93xx_adc.rst
> similarity index 71%
> rename from Documentation/iio/ep93xx_adc.txt
> rename to Documentation/iio/ep93xx_adc.rst
> index 23053e7817bd..4fd8dea3f6b8 100644
> --- a/Documentation/iio/ep93xx_adc.txt
> +++ b/Documentation/iio/ep93xx_adc.rst
> @@ -1,12 +1,16 @@
> -Cirrus Logic EP93xx ADC driver.
> +==============================
> +Cirrus Logic EP93xx ADC driver
> +==============================
>
> 1. Overview
> +===========
>
> The driver is intended to work on both low-end (EP9301, EP9302) devices with
> 5-channel ADC and high-end (EP9307, EP9312, EP9315) devices with 10-channel
> touchscreen/ADC module.
>
> 2. Channel numbering
> +====================
>
> Numbering scheme for channels 0..4 is defined in EP9301 and EP9302 datasheets.
> EP9307, EP9312 and EP9312 have 3 channels more (total 8), but the numbering is
> @@ -17,13 +21,20 @@ Assuming ep93xx_adc is IIO device0, you'd find the following entries under
>
> +-----------------+---------------+
> | sysfs entry | ball/pin name |
> - +-----------------+---------------+
> + +=================+===============+
> | in_voltage0_raw | YM |
> + +-----------------+---------------+
> | in_voltage1_raw | SXP |
> + +-----------------+---------------+
> | in_voltage2_raw | SXM |
> + +-----------------+---------------+
> | in_voltage3_raw | SYP |
> + +-----------------+---------------+
> | in_voltage4_raw | SYM |
> + +-----------------+---------------+
> | in_voltage5_raw | XP |
> + +-----------------+---------------+
> | in_voltage6_raw | XM |
> + +-----------------+---------------+
> | in_voltage7_raw | YP |
> +-----------------+---------------+
> diff --git a/Documentation/iio/iio_configfs.txt b/Documentation/iio/iio_configfs.rst
> similarity index 73%
> rename from Documentation/iio/iio_configfs.txt
> rename to Documentation/iio/iio_configfs.rst
> index 4e5f101837a8..ecbfdb3afef7 100644
> --- a/Documentation/iio/iio_configfs.txt
> +++ b/Documentation/iio/iio_configfs.rst
> @@ -1,6 +1,9 @@
> +===============================
> Industrial IIO configfs support
> +===============================
>
> 1. Overview
> +===========
>
> Configfs is a filesystem-based manager of kernel objects. IIO uses some
> objects that could be easily configured using configfs (e.g.: devices,
> @@ -10,20 +13,22 @@ See Documentation/filesystems/configfs/configfs.txt for more information
> about how configfs works.
>
> 2. Usage
> +========
>
> In order to use configfs support in IIO we need to select it at compile
> time via CONFIG_IIO_CONFIGFS config option.
>
> -Then, mount the configfs filesystem (usually under /config directory):
> +Then, mount the configfs filesystem (usually under /config directory)::
>
> -$ mkdir /config
> -$ mount -t configfs none /config
> + $ mkdir /config
> + $ mount -t configfs none /config
>
> At this point, all default IIO groups will be created and can be accessed
> under /config/iio. Next chapters will describe available IIO configuration
> objects.
>
> 3. Software triggers
> +====================
>
> One of the IIO default configfs groups is the "triggers" group. It is
> automagically accessible when the configfs is mounted and can be found
> @@ -31,40 +36,40 @@ under /config/iio/triggers.
>
> IIO software triggers implementation offers support for creating multiple
> trigger types. A new trigger type is usually implemented as a separate
> -kernel module following the interface in include/linux/iio/sw_trigger.h:
> +kernel module following the interface in include/linux/iio/sw_trigger.h::
>
> -/*
> - * drivers/iio/trigger/iio-trig-sample.c
> - * sample kernel module implementing a new trigger type
> - */
> -#include <linux/iio/sw_trigger.h>
> + /*
> + * drivers/iio/trigger/iio-trig-sample.c
> + * sample kernel module implementing a new trigger type
> + */
> + #include <linux/iio/sw_trigger.h>
>
>
> -static struct iio_sw_trigger *iio_trig_sample_probe(const char *name)
> -{
> + static struct iio_sw_trigger *iio_trig_sample_probe(const char *name)
> + {
> /*
> * This allocates and registers an IIO trigger plus other
> * trigger type specific initialization.
> */
> -}
> + }
>
> -static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
> -{
> + static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
> + {
> /*
> * This undoes the actions in iio_trig_sample_probe
> */
> -}
> + }
>
> -static const struct iio_sw_trigger_ops iio_trig_sample_ops = {
> + static const struct iio_sw_trigger_ops iio_trig_sample_ops = {
> .probe = iio_trig_sample_probe,
> .remove = iio_trig_sample_remove,
> -};
> + };
>
> -static struct iio_sw_trigger_type iio_trig_sample = {
> + static struct iio_sw_trigger_type iio_trig_sample = {
> .name = "trig-sample",
> .owner = THIS_MODULE,
> .ops = &iio_trig_sample_ops,
> -};
> + };
>
> module_iio_sw_trigger_driver(iio_trig_sample);
>
> @@ -73,21 +78,24 @@ iio-trig-sample module will create 'trig-sample' trigger type directory
> /config/iio/triggers/trig-sample.
>
> We support the following interrupt sources (trigger types):
> +
> * hrtimer, uses high resolution timers as interrupt source
>
> 3.1 Hrtimer triggers creation and destruction
> +---------------------------------------------
>
> Loading iio-trig-hrtimer module will register hrtimer trigger types allowing
> users to create hrtimer triggers under /config/iio/triggers/hrtimer.
>
> -e.g:
> +e.g::
>
> -$ mkdir /config/iio/triggers/hrtimer/instance1
> -$ rmdir /config/iio/triggers/hrtimer/instance1
> + $ mkdir /config/iio/triggers/hrtimer/instance1
> + $ rmdir /config/iio/triggers/hrtimer/instance1
>
> Each trigger can have one or more attributes specific to the trigger type.
>
> 3.2 "hrtimer" trigger types attributes
> +--------------------------------------
>
> "hrtimer" trigger type doesn't have any configurable attribute from /config dir.
> It does introduce the sampling_frequency attribute to trigger directory.
> diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
> new file mode 100644
> index 000000000000..0593dca89a94
> --- /dev/null
> +++ b/Documentation/iio/index.rst
> @@ -0,0 +1,12 @@
> +:orphan:
> +
> +==============
> +Industrial I/O
> +==============
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + iio_configfs
> +
> + ep93xx_adc
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 1d736a4952ab..5bd51853b15e 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -28,7 +28,7 @@ config IIO_CONFIGFS
> help
> This allows configuring various IIO bits through configfs
> (e.g. software triggers). For more info see
> - Documentation/iio/iio_configfs.txt.
> + Documentation/iio/iio_configfs.rst.
>
> config IIO_TRIGGER
> bool "Enable triggered sampling support"
^ permalink raw reply
* Re: [PATCH 14/14] docs: sphinx/kernel_abi.py: fix UTF-8 support
From: Markus Heiser @ 2019-06-16 15:43 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Greg Kroah-Hartman
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <20190614132530.7a013757@coco.lan>
Am 14.06.19 um 18:25 schrieb Mauro Carvalho Chehab:
> Em Fri, 14 Jun 2019 18:18:37 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>
>> On Thu, Jun 13, 2019 at 11:04:20PM -0300, Mauro Carvalho Chehab wrote:
>>> The parser breaks with UTF-8 characters with Sphinx 1.4.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>>> ---
>>> Documentation/sphinx/kernel_abi.py | 10 ++++++----
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py
>>> index 7fa7806532dc..460cee48a245 100644
>>> --- a/Documentation/sphinx/kernel_abi.py
>>> +++ b/Documentation/sphinx/kernel_abi.py
>>> @@ -1,4 +1,5 @@
>>> -# -*- coding: utf-8; mode: python -*-
>>> +# coding=utf-8
>>> +#
>>
>> Is this an emacs vs. vim fight?
>
> No. This is a python-specific thing:
>
> https://www.python.org/dev/peps/pep-0263/
No need to change, the emacs notation is also OK, see your link
"""or (using formats recognized by popular editors):"""
https://www.python.org/dev/peps/pep-0263/#defining-the-encoding
I prefer emacs notation, this is also evaluated by many other editors / tools.
-- Markus --
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Markus Heiser @ 2019-06-16 16:04 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Jani Nikula, Mauro Carvalho Chehab, Linux Doc Mailing List,
Greg Kroah-Hartman, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
linux-kernel
In-Reply-To: <20190614081546.64101411@lwn.net>
Am 14.06.19 um 16:15 schrieb Jonathan Corbet:
> On Fri, 14 Jun 2019 16:10:31 +0200
> Markus Heiser <markus.heiser@darmarit.de> wrote:
>
>> I agree with Jani. No matter how the decision ends, since I can't help here, I'd
>> rather not show up in the copyright.
>
> Is there something specific you are asking us to do here?
>
I have lost the overview, but there was a patch Mauro added a
kernel_abi.py. There was my name (Markus Heiser) listed with a
copyright notation.
I guess Mauro picked up some old RFC or an other old patch of
mine from 2016 and made some C&P .. whatever .. ATM I do not have
time to give any support on parsing ABI and I'am not interested
in holding copyrights on a C&P of a old source ;)
-- Markus --
^ permalink raw reply
* Re: [PATCH v4 00/14] ima: introduce IMA Digest Lists extension
From: Roberto Sassu @ 2019-06-17 6:56 UTC (permalink / raw)
To: zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-fsdevel, linux-doc,
linux-kernel, silviu.vlasceanu
In-Reply-To: <20190614175513.27097-1-roberto.sassu@huawei.com>
On 6/14/2019 7:54 PM, Roberto Sassu wrote:
> This patch set introduces a new IMA extension called IMA Digest Lists.
>
> At early boot, the extension preloads in kernel memory reference digest
> values, that can be compared with actual file digests when files are
> accessed in the system.
>
> The extension will open for new possibilities: PCR with predictable value,
> that can be used for sealing policies associated to data or TPM keys;
> appraisal based on reference digests already provided by Linux distribution
> vendors in the software packages.
>
> The first objective can be achieved because the PCR values does not depend
> on which and when files are measured: the extension measures digest lists
> sequentially and files whose digest is not in the digest list.
>
> The second objective can be reached because the extension is able to
> extract reference measurements from packages (with a user space tool) and
> use it as a source for appraisal verification as the reference came from
> the security.ima xattr. This approach will also reduce the overhead as only
> one signature is verified for many files (as opposed to one signature for
> each file with the current implementation).
>
> This version of the patch set provides a clear separation between current
> and new functionality. First, the new functionality must be explicitly
> enabled from the kernel command line. Second, results of operations
> performed by the extension can be distinguished from those obtained from
> the existing code: measurement entries created by the extension have a
> different PCR; mutable files appraised with the extension have a different
> security.ima type.
>
> The review of this patch set should start from patch 11 and 12, which
> modify the IMA-Measure and IMA-Appraise submodules to use digest lists.
> Patch 1 to 5 are prerequisites. Patch 6 to 10 adds support for digest
> lists. Finally, patch 13 introduces two new policies to measure/appraise
> rootfs and patch 14 adds the documentation (including a flow chart to
> show how IMA has been modified).
>
> The user space tools to configure digest lists are available at:
>
> https://github.com/euleros/digest-list-tools/releases/tag/v0.3
>
> The patch set applies on top of linux-integrity/next-queued-testing
> (73589972b987).
>
> It is necessary to apply also:
> https://patchwork.kernel.org/cover/10957495/
Another dependency is:
https://patchwork.kernel.org/cover/10979341/
Roberto
> To use appraisal, it is necessary to use a modified cpio and a modified
> dracut:
>
> https://github.com/euleros/cpio/tree/xattr-v1
> https://github.com/euleros/dracut/tree/digest-lists
>
> For now, please use it only in a testing environment.
>
>
> Changelog
>
> v3:
> - move ima_lookup_loaded_digest() and ima_add_digest_data_entry() from
> ima_queue.c to ima_digest_list.c
> - remove patch that introduces security.ima_algo
> - add version number and type modifiers to the compact list header
> - remove digest list metadata, all digest lists in the directory are
> accessed
> - move loading of signing keys to user space
> - add violation for both PCRs if they are selected
> - introduce two new appraisal modes
>
> v2:
> - add support for multiple hash algorithms
> - remove RPM parser from the kernel
> - add support for parsing digest lists in user space
>
> v1:
> - add support for immutable/mutable files
> - add support for appraisal with digest lists
>
>
> Roberto Sassu (14):
> ima: read hash algorithm from security.ima even if appraisal is not
> enabled
> ima: generalize ima_read_policy()
> ima: generalize ima_write_policy() and raise uploaded data size limit
> ima: generalize policy file operations
> ima: use ima_show_htable_value to show violations and hash table data
> ima: add parser of compact digest list
> ima: restrict upload of converted digest lists
> ima: prevent usage of digest lists that are not measured/appraised
> ima: introduce new securityfs files
> ima: load parser digests and execute the parser at boot time
> ima: add support for measurement with digest lists
> ima: add support for appraisal with digest lists
> ima: introduce new policies initrd and appraise_initrd
> ima: add Documentation/security/IMA-digest-lists.txt
>
> .../admin-guide/kernel-parameters.txt | 16 +-
> Documentation/security/IMA-digest-lists.txt | 226 +++++++++++++
> include/linux/evm.h | 6 +
> include/linux/fs.h | 1 +
> security/integrity/evm/evm_main.c | 2 +-
> security/integrity/iint.c | 1 +
> security/integrity/ima/Kconfig | 25 ++
> security/integrity/ima/Makefile | 1 +
> security/integrity/ima/ima.h | 32 +-
> security/integrity/ima/ima_api.c | 43 ++-
> security/integrity/ima/ima_appraise.c | 92 +++---
> security/integrity/ima/ima_digest_list.c | 309 ++++++++++++++++++
> security/integrity/ima/ima_digest_list.h | 69 ++++
> security/integrity/ima/ima_fs.c | 224 ++++++++-----
> security/integrity/ima/ima_init.c | 2 +-
> security/integrity/ima/ima_main.c | 81 ++++-
> security/integrity/ima/ima_policy.c | 29 +-
> security/integrity/integrity.h | 22 ++
> 18 files changed, 1018 insertions(+), 163 deletions(-)
> create mode 100644 Documentation/security/IMA-digest-lists.txt
> create mode 100644 security/integrity/ima/ima_digest_list.c
> create mode 100644 security/integrity/ima/ima_digest_list.h
>
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* PRODUCT INQUIRY FOR EXPORT SHIPMENT
From: Mark Maths @ 2019-06-17 7:08 UTC (permalink / raw)
To: Recipients
Dear Sales team,
In furtherance to our market research, we have reviewed all your products types and we have finally interested in your product for our market here in
United State for your production. We introduce ourselves as Emilxa Tram SRL, A general group of company located in the United State.
We are sourcing for new suppliers from your location
Kindly advice us if you accept new purchase orders, I will forward our PO for urgent order.
Waiting for your response to send order. Reply to ( purchase_m.maths@aol.com)
Best regards.
Mark Maths
Company Address:
Emilxa Tram SRL Company Limited
P.O. Box 978
Road Town
Tortola
British Virgin Islands
Contact information:
Tel: +1 (284) 493 7235
Email: purchase_m.maths@aol.com
https://meridianbvi.com/contact-us/
^ permalink raw reply
* [PATCH v5 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework
From: Brendan Higgins @ 2019-06-17 8:25 UTC (permalink / raw)
To: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, mcgrof,
peterz, robh, sboyd, shuah, tytso, yamada.masahiro
Cc: devicetree, dri-devel, kunit-dev, linux-doc, linux-fsdevel,
linux-kbuild, linux-kernel, linux-kselftest, linux-nvdimm,
linux-um, Alexander.Levin, Tim.Bird, amir73il, dan.carpenter,
daniel, jdike, joel, julia.lawall, khilman, knut.omang, logang,
mpe, pmladek, rdunlap, richard, rientjes, rostedt, wfg,
Brendan Higgins
## TL;DR
A not so quick follow-up to Stephen's suggestions on PATCH v4. Nothing
that really changes any functionality or usage with the minor exception
of a couple public functions that Stephen asked me to rename.
Nevertheless, a good deal of clean up and fixes. See changes below.
As for our current status, right now we got Reviewed-bys on all patches
except:
- [PATCH v5 08/18] objtool: add kunit_try_catch_throw to the noreturn
list
However, it would probably be good to get reviews/acks from the
subsystem maintainers on:
- [PATCH v5 06/18] kbuild: enable building KUnit
- [PATCH v5 08/18] objtool: add kunit_try_catch_throw to the noreturn
list
- [PATCH v5 15/18] Documentation: kunit: add documentation for KUnit
- [PATCH v5 17/18] kernel/sysctl-test: Add null pointer test for
sysctl.c:proc_dointvec()
- [PATCH v5 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC
SYSCTL section
Other than that, I think we should be good to go.
One last thing, I updated the background to include my thoughts on KUnit
vs. in kernel testing with kselftest in the background sections as
suggested by Frank in the discussion on PATCH v2.
## Background
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
(however, KUnit still allows you to run tests on test machines or in VMs
if you want[1]) and does not require tests to be written in userspace
running on a host kernel. Additionally, KUnit is fast: From invocation
to completion KUnit can run several dozen tests in under a second.
Currently, the entire KUnit test suite for KUnit runs in under a second
from the initial invocation (build time excluded).
KUnit is heavily inspired by JUnit, Python's unittest.mock, and
Googletest/Googlemock for C++. KUnit provides facilities for defining
unit test cases, grouping related test cases into test suites, providing
common infrastructure for running tests, mocking, spying, and much more.
### But wait! Doesn't kselftest support in kernel testing?!
In a previous version of this patchset Frank pointed out that kselftest
already supports writing a test that resides in the kernel using the
test module feature[2]. LWN did a really great summary on this
discussion here[3].
Kselftest has a feature that allows a test module to be loaded into a
kernel using the kselftest framework; this does allow someone to write
tests against kernel code not directly exposed to userland; however, it
does not provide much of a framework around how to structure the tests.
The kselftest test module feature just provides a header which has a
standardized way of reporting test failures, and then provides
infrastructure to load and run the tests using the kselftest test
harness.
The kselftest test module does not seem to be opinionated at all in
regards to how tests are structured, how they check for failures, how
tests are organized. Even in the method it provides for reporting
failures is pretty simple; it doesn't have any more advanced failure
reporting or logging features. Given what's there, I think it is fair to
say that it is not actually a framework, but a feature that makes it
possible for someone to do some checks in kernel space.
Furthermore, kselftest test module has very few users. I checked for all
the tests that use it using the following grep command:
grep -Hrn -e 'kselftest_module\.h'
and only got three results: lib/test_strscpy.c, lib/test_printf.c, and
lib/test_bitmap.c.
So despite kselftest test module's existence, there really is no feature
overlap between kselftest and KUnit, save one: that you can use either
to write an in-kernel test, but this is a very small feature in
comparison to everything that KUnit allows you to do. KUnit is a full
x-unit style unit testing framework, whereas kselftest looks a lot more
like an end-to-end/functional testing framework, with a feature that
makes it possible to write in-kernel tests.
### What's so special about unit testing?
A unit test is supposed to test a single unit of code in isolation,
hence the name. There should be no dependencies outside the control of
the test; this means no external dependencies, which makes tests orders
of magnitudes faster. Likewise, since there are no external dependencies,
there are no hoops to jump through to run the tests. Additionally, this
makes unit tests deterministic: a failing unit test always indicates a
problem. Finally, because unit tests necessarily have finer granularity,
they are able to test all code paths easily solving the classic problem
of difficulty in exercising error handling code.
### Is KUnit trying to replace other testing frameworks for the kernel?
No. Most existing tests for the Linux kernel are end-to-end tests, which
have their place. A well tested system has lots of unit tests, a
reasonable number of integration tests, and some end-to-end tests. KUnit
is just trying to address the unit test space which is currently not
being addressed.
### More information on KUnit
There is a bunch of documentation near the end of this patch set that
describes how to use KUnit and best practices for writing unit tests.
For convenience I am hosting the compiled docs here[4].
Additionally for convenience, I have applied these patches to a
branch[5]. The repo may be cloned with:
git clone https://kunit.googlesource.com/linux
This patchset is on the kunit/rfc/v5.2-rc4/v5 branch.
## Changes Since Last Version
Aside from a couple public function renames, there isn't really anything
in here that changes any functionality.
- Went through and fixed a couple of anti-patterns suggested by Stephen
Boyd. Things like:
- Dropping an else clause at the end of a function.
- Dropping the comma on the closing sentinel, `{}`, of a list.
- Inlines a bunch of functions in the test case running logic in patch
01/18 to make it more readable as suggested by Stephen Boyd
- Found and fixed bug in resource deallocation logic in patch 02/18. Bug
was discovered as a result of making a change suggested by Stephen
Boyd. This does not substantially change how any of the code works
conceptually.
- Renamed new_string_stream() to alloc_string_stream() as suggested by
Stephen Boyd.
- Made string-stream a KUnit managed object - based on a suggestion made
by Stephen Boyd.
- Renamed kunit_new_stream() to alloc_kunit_stream() as suggested by
Stephen Boyd.
- Removed the ability to set log level after allocating a kunit_stream,
as suggested by Stephen Boyd.
[1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kunit-on-non-uml-architectures
[2] https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html#test-module
[3] https://lwn.net/Articles/790235/
[4] https://google.github.io/kunit-docs/third_party/kernel/docs/
[5] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.2-rc4/v5
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* [PATCH v5 01/18] kunit: test: add KUnit test runner core
From: Brendan Higgins @ 2019-06-17 8:25 UTC (permalink / raw)
To: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, mcgrof,
peterz, robh, sboyd, shuah, tytso, yamada.masahiro
Cc: devicetree, dri-devel, kunit-dev, linux-doc, linux-fsdevel,
linux-kbuild, linux-kernel, linux-kselftest, linux-nvdimm,
linux-um, Alexander.Levin, Tim.Bird, amir73il, dan.carpenter,
daniel, jdike, joel, julia.lawall, khilman, knut.omang, logang,
mpe, pmladek, rdunlap, richard, rientjes, rostedt, wfg,
Brendan Higgins
In-Reply-To: <20190617082613.109131-1-brendanhiggins@google.com>
Add core facilities for defining unit tests; this provides a common way
to define test cases, functions that execute code which is under test
and determine whether the code under test behaves as expected; this also
provides a way to group together related test cases in test suites (here
we call them test_modules).
Just define test cases and how to execute them for now; setting
expectations on code will be defined later.
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
---
Changes Since Last Revision:
- Mostly minor fixes suggested by Stephen Boyd
- Biggest change inlines a bunch of functions in the test case running
logic to make it more readable as suggested by Stephen Boyd
---
include/kunit/test.h | 161 +++++++++++++++++++++++++++++++++
kunit/Kconfig | 17 ++++
kunit/Makefile | 1 +
kunit/test.c | 210 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 389 insertions(+)
create mode 100644 include/kunit/test.h
create mode 100644 kunit/Kconfig
create mode 100644 kunit/Makefile
create mode 100644 kunit/test.c
diff --git a/include/kunit/test.h b/include/kunit/test.h
new file mode 100644
index 0000000000000..8476b3d371cb9
--- /dev/null
+++ b/include/kunit/test.h
@@ -0,0 +1,161 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Base unit test (KUnit) API.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins <brendanhiggins@google.com>
+ */
+
+#ifndef _KUNIT_TEST_H
+#define _KUNIT_TEST_H
+
+#include <linux/types.h>
+
+struct kunit;
+
+/**
+ * struct kunit_case - represents an individual test case.
+ * @run_case: the function representing the actual test case.
+ * @name: the name of the test case.
+ *
+ * A test case is a function with the signature, ``void (*)(struct kunit *)``
+ * that makes expectations (see KUNIT_EXPECT_TRUE()) about code under test. Each
+ * test case is associated with a &struct kunit_module and will be run after the
+ * module's init function and followed by the module's exit function.
+ *
+ * A test case should be static and should only be created with the KUNIT_CASE()
+ * macro; additionally, every array of test cases should be terminated with an
+ * empty test case.
+ *
+ * Example:
+ *
+ * .. code-block:: c
+ *
+ * void add_test_basic(struct kunit *test)
+ * {
+ * KUNIT_EXPECT_EQ(test, 1, add(1, 0));
+ * KUNIT_EXPECT_EQ(test, 2, add(1, 1));
+ * KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
+ * KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
+ * KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
+ * }
+ *
+ * static struct kunit_case example_test_cases[] = {
+ * KUNIT_CASE(add_test_basic),
+ * {}
+ * };
+ *
+ */
+struct kunit_case {
+ void (*run_case)(struct kunit *test);
+ const char *name;
+
+ /* private: internal use only. */
+ bool success;
+};
+
+/**
+ * KUNIT_CASE - A helper for creating a &struct kunit_case
+ * @test_name: a reference to a test case function.
+ *
+ * Takes a symbol for a function representing a test case and creates a
+ * &struct kunit_case object from it. See the documentation for
+ * &struct kunit_case for an example on how to use it.
+ */
+#define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
+
+/**
+ * struct kunit_module - describes a related collection of &struct kunit_case s.
+ * @name: the name of the test. Purely informational.
+ * @init: called before every test case.
+ * @exit: called after every test case.
+ * @test_cases: a null terminated array of test cases.
+ *
+ * A kunit_module is a collection of related &struct kunit_case s, such that
+ * @init is called before every test case and @exit is called after every test
+ * case, similar to the notion of a *test fixture* or a *test class* in other
+ * unit testing frameworks like JUnit or Googletest.
+ *
+ * Every &struct kunit_case must be associated with a kunit_module for KUnit to
+ * run it.
+ */
+struct kunit_module {
+ const char name[256];
+ int (*init)(struct kunit *test);
+ void (*exit)(struct kunit *test);
+ struct kunit_case *test_cases;
+};
+
+/**
+ * struct kunit - represents a running instance of a test.
+ * @priv: for user to store arbitrary data. Commonly used to pass data created
+ * in the init function (see &struct kunit_module).
+ *
+ * Used to store information about the current context under which the test is
+ * running. Most of this data is private and should only be accessed indirectly
+ * via public functions; the one exception is @priv which can be used by the
+ * test writer to store arbitrary data.
+ */
+struct kunit {
+ void *priv;
+
+ /* private: internal use only. */
+ const char *name; /* Read only after initialization! */
+ spinlock_t lock; /* Gaurds all mutable test state. */
+ bool success; /* Protected by lock. */
+};
+
+void kunit_init_test(struct kunit *test, const char *name);
+
+int kunit_run_tests(struct kunit_module *module);
+
+/**
+ * module_test() - used to register a &struct kunit_module with KUnit.
+ * @module: a statically allocated &struct kunit_module.
+ *
+ * Registers @module with the test framework. See &struct kunit_module for more
+ * information.
+ */
+#define module_test(module) \
+ static int module_kunit_init##module(void) \
+ { \
+ return kunit_run_tests(&module); \
+ } \
+ late_initcall(module_kunit_init##module)
+
+void __printf(3, 4) kunit_printk(const char *level,
+ const struct kunit *test,
+ const char *fmt, ...);
+
+/**
+ * kunit_info() - Prints an INFO level message associated with the current test.
+ * @test: The test context object.
+ * @fmt: A printk() style format string.
+ *
+ * Prints an info level message associated with the test module being run. Takes
+ * a variable number of format parameters just like printk().
+ */
+#define kunit_info(test, fmt, ...) \
+ kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__)
+
+/**
+ * kunit_warn() - Prints a WARN level message associated with the current test.
+ * @test: The test context object.
+ * @fmt: A printk() style format string.
+ *
+ * Prints a warning level message.
+ */
+#define kunit_warn(test, fmt, ...) \
+ kunit_printk(KERN_WARNING, test, fmt, ##__VA_ARGS__)
+
+/**
+ * kunit_err() - Prints an ERROR level message associated with the current test.
+ * @test: The test context object.
+ * @fmt: A printk() style format string.
+ *
+ * Prints an error level message.
+ */
+#define kunit_err(test, fmt, ...) \
+ kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__)
+
+#endif /* _KUNIT_TEST_H */
diff --git a/kunit/Kconfig b/kunit/Kconfig
new file mode 100644
index 0000000000000..330ae83527c23
--- /dev/null
+++ b/kunit/Kconfig
@@ -0,0 +1,17 @@
+#
+# KUnit base configuration
+#
+
+menu "KUnit support"
+
+config KUNIT
+ bool "Enable support for unit tests (KUnit)"
+ help
+ Enables support for kernel unit tests (KUnit), a lightweight unit
+ testing and mocking framework for the Linux kernel. These tests are
+ able to be run locally on a developer's workstation without a VM or
+ special hardware when using UML. Can also be used on most other
+ architectures. For more information, please see
+ Documentation/dev-tools/kunit/.
+
+endmenu
diff --git a/kunit/Makefile b/kunit/Makefile
new file mode 100644
index 0000000000000..5efdc4dea2c08
--- /dev/null
+++ b/kunit/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_KUNIT) += test.o
diff --git a/kunit/test.c b/kunit/test.c
new file mode 100644
index 0000000000000..d05d254f1521f
--- /dev/null
+++ b/kunit/test.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Base unit test (KUnit) API.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins <brendanhiggins@google.com>
+ */
+
+#include <linux/sched/debug.h>
+#include <kunit/test.h>
+
+static bool kunit_get_success(struct kunit *test)
+{
+ unsigned long flags;
+ bool success;
+
+ spin_lock_irqsave(&test->lock, flags);
+ success = test->success;
+ spin_unlock_irqrestore(&test->lock, flags);
+
+ return success;
+}
+
+static void kunit_set_success(struct kunit *test, bool success)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&test->lock, flags);
+ test->success = success;
+ spin_unlock_irqrestore(&test->lock, flags);
+}
+
+static int kunit_vprintk_emit(int level, const char *fmt, va_list args)
+{
+ return vprintk_emit(0, level, NULL, 0, fmt, args);
+}
+
+static int kunit_printk_emit(int level, const char *fmt, ...)
+{
+ va_list args;
+ int ret;
+
+ va_start(args, fmt);
+ ret = kunit_vprintk_emit(level, fmt, args);
+ va_end(args);
+
+ return ret;
+}
+
+static void kunit_vprintk(const struct kunit *test,
+ const char *level,
+ struct va_format *vaf)
+{
+ kunit_printk_emit(level[1] - '0', "\t# %s: %pV", test->name, vaf);
+}
+
+static bool kunit_has_printed_tap_version;
+
+static void kunit_print_tap_version(void)
+{
+ if (!kunit_has_printed_tap_version) {
+ kunit_printk_emit(LOGLEVEL_INFO, "TAP version 14\n");
+ kunit_has_printed_tap_version = true;
+ }
+}
+
+static size_t kunit_test_cases_len(struct kunit_case *test_cases)
+{
+ struct kunit_case *test_case;
+ size_t len = 0;
+
+ for (test_case = test_cases; test_case->run_case; test_case++)
+ len++;
+
+ return len;
+}
+
+static void kunit_print_subtest_start(struct kunit_module *module)
+{
+ kunit_print_tap_version();
+ kunit_printk_emit(LOGLEVEL_INFO, "\t# Subtest: %s\n", module->name);
+ kunit_printk_emit(LOGLEVEL_INFO,
+ "\t1..%zd\n",
+ kunit_test_cases_len(module->test_cases));
+}
+
+static void kunit_print_ok_not_ok(bool should_indent,
+ bool is_ok,
+ size_t test_number,
+ const char *description)
+{
+ const char *indent, *ok_not_ok;
+
+ if (should_indent)
+ indent = "\t";
+ else
+ indent = "";
+
+ if (is_ok)
+ ok_not_ok = "ok";
+ else
+ ok_not_ok = "not ok";
+
+ kunit_printk_emit(LOGLEVEL_INFO,
+ "%s%s %zd - %s\n",
+ indent, ok_not_ok, test_number, description);
+}
+
+static bool kunit_module_has_succeeded(struct kunit_module *module)
+{
+ const struct kunit_case *test_case;
+ bool success = true;
+
+ for (test_case = module->test_cases; test_case->run_case; test_case++)
+ if (!test_case->success) {
+ success = false;
+ break;
+ }
+
+ return success;
+}
+
+static size_t kunit_module_counter = 1;
+
+static void kunit_print_subtest_end(struct kunit_module *module)
+{
+ kunit_print_ok_not_ok(false,
+ kunit_module_has_succeeded(module),
+ kunit_module_counter++,
+ module->name);
+}
+
+static void kunit_print_test_case_ok_not_ok(struct kunit_case *test_case,
+ size_t test_number)
+{
+ kunit_print_ok_not_ok(true,
+ test_case->success,
+ test_number,
+ test_case->name);
+}
+
+void kunit_init_test(struct kunit *test, const char *name)
+{
+ spin_lock_init(&test->lock);
+ test->name = name;
+ test->success = true;
+}
+
+/*
+ * Performs all logic to run a test case.
+ */
+static void kunit_run_case(struct kunit_module *module,
+ struct kunit_case *test_case)
+{
+ struct kunit test;
+ int ret = 0;
+
+ kunit_init_test(&test, test_case->name);
+
+ if (module->init) {
+ ret = module->init(&test);
+ if (ret) {
+ kunit_err(&test, "failed to initialize: %d\n", ret);
+ kunit_set_success(&test, false);
+ return;
+ }
+ }
+
+ if (!ret)
+ test_case->run_case(&test);
+
+ if (module->exit)
+ module->exit(&test);
+
+ test_case->success = kunit_get_success(&test);
+}
+
+int kunit_run_tests(struct kunit_module *module)
+{
+ struct kunit_case *test_case;
+ size_t test_case_count = 1;
+
+ kunit_print_subtest_start(module);
+
+ for (test_case = module->test_cases; test_case->run_case; test_case++) {
+ kunit_run_case(module, test_case);
+ kunit_print_test_case_ok_not_ok(test_case, test_case_count++);
+ }
+
+ kunit_print_subtest_end(module);
+
+ return 0;
+}
+
+void kunit_printk(const char *level,
+ const struct kunit *test,
+ const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ kunit_vprintk(test, level, &vaf);
+
+ va_end(args);
+}
--
2.22.0.410.gd8fdbe21b5-goog
^ 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