Re: [PATCH 2/2] [media] doc-rst: increase depth of the main index
Hi Mauro, Am 13.07.2016 um 15:52 schrieb Mauro Carvalho Chehab : > It is useful to have an index with all the book contents somewhere, > as it makes easier to seek for something. So, increase maxdepth > to 5 for the main index at the beginning of the book. > > While here, remove the genindex content, as it is bogus. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/media/media_uapi.rst | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/Documentation/media/media_uapi.rst > b/Documentation/media/media_uapi.rst > index 527c6deb1a19..5e872c8297b0 100644 > --- a/Documentation/media/media_uapi.rst > +++ b/Documentation/media/media_uapi.rst > @@ -15,8 +15,10 @@ the license is included in the chapter entitled "GNU Free > Documentation > License". > > > +.. contents:: > + Since there is a ".. toctree" with maxdepth, you don't need this ".. contents::" directive. The ".. contents::" directive is helpfull if you want to show the contents (e.g.) on top of a file which has no toctree in. -- Markus -- > .. toctree:: > -:maxdepth: 1 > +:maxdepth: 5 > > intro > uapi/v4l/v4l2 > @@ -26,10 +28,3 @@ License". > uapi/cec/cec-api > uapi/gen-errors > uapi/fdl-appendix > - > -.. only:: html > - > - Retrieval > - = > - > - * :ref:`genindex` > -- > 2.7.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Requirements for man page generation
Hi Jonathan, hi all, I want to contribute a modified version of my man-page builder, but before we should elaborate what we need in more detail. We have two use-cases from which we want to create man page. * create man-pages from kernel-doc comments and * create man-pages from "handwritten" reST documents For the "handwritten", sphinx-doc brings the "man" builder described in [1]. [1] http://www.sphinx-doc.org/en/stable/config.html#confval-man_pages Mauro and I figured out, that [1] has some drawbacks: 1. you need a separate file for each man-page (see "startdocname" [1]) 2. you need to touch the conf.py every time you mark a content as man-page. 3. The "NAME" section is created by the builder and could not be a part of your reST document (see "name" [1]) Thats why we recommend a simple markup (a directive) to mark reST content as content from which a man-page should be build. E.g: --- ** ioctl VIDIOC_G_AUDOUT, VIDIOC_S_AUDOUT ** .. kernel-man: :man-name: videoc_audout :man-sec: 2 :author: John Sample :address: john.sam...@example.org Name VIDIOC_G_AUDOUT - VIDIOC_S_AUDOUT - Query or select the current audio output Return == ... --- The man-name and man-sec is used to build the filename "videoc_audout.2" and is also inserted in the .TH (title line), e.g: --- .TH "VIDIOC_AUDOUT" "2" "July 06, 2016" "Linux" "Linux Programmer's Manual" --- The date in the .TH will be the build date and the last two fields are always "Linux" and "Linux Programmer's Manual" (see man-page7) My first question is, do we really need author and address and when we need it, how should we handle these items? The man-pages7 says: Use of an AUTHORS section is strongly discouraged ... if you write or significantly amend a page, add a copyright notice as a comment in the source file ... If you are the author of a device driver and want to include an address for reporting bugs, place this under the BUGS section. I think there are many other question, we have to answer, e.g. how this is married with the kernel-doc comments, but at first it might be the best, we focus on "handwritten" man-pages. Later, we can discuss how this markup will be produced by the kernel-doc parser. I have many other thoughts about man pages and I will remark them when the discussion running, but at first I want to now from you all: What are your suggestions about man page generation? Thanks for any remark ... -- Markus -- References: * linux man pages: https://www.kernel.org/doc/man-pages/ * man-page(7): http://man7.org/linux/man-pages/man7/man-pages.7.html -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Requirements for man page generation
Em Thu, 14 Jul 2016 13:45:00 +0200
Markus Heiser escreveu:
> Hi Jonathan, hi all,
>
> I want to contribute a modified version of my man-page builder,
> but before we should elaborate what we need in more detail.
> We have two use-cases from which we want to create man page.
>
> * create man-pages from kernel-doc comments and
> * create man-pages from "handwritten" reST documents
>
> For the "handwritten", sphinx-doc brings the "man" builder described in [1].
>
> [1] http://www.sphinx-doc.org/en/stable/config.html#confval-man_pages
>
> Mauro and I figured out, that [1] has some drawbacks:
>
> 1. you need a separate file for each man-page (see "startdocname" [1])
> 2. you need to touch the conf.py every time you mark a content
>as man-page.
This will never scale. At media, we have already hundreds of
stuff that would be better fit as a man page.
> 3. The "NAME" section is created by the builder and could not
>be a part of your reST document (see "name" [1])
>
> Thats why we recommend a simple markup (a directive) to mark reST
> content as content from which a man-page should be build. E.g:
>
> ---
> **
> ioctl VIDIOC_G_AUDOUT, VIDIOC_S_AUDOUT
> **
>
> .. kernel-man:
>:man-name: videoc_audout
I guess it would be interesting to allow specifying multiple
man pages. In this specific example, two ioctls are documented
the same way. I guess it would make sense to produce two man
pages, so, if the user asks for:
$ man vidioc_g_audout
or
$ man vidioc_s_audout
it will see the contents of this man page.
>:man-sec: 2
>:author: John Sample
>:address: john.sam...@example.org
>
> Name
>
>
> VIDIOC_G_AUDOUT - VIDIOC_S_AUDOUT - Query or select the current audio output
>
> Return
> ==
> ...
> ---
>
> The man-name and man-sec is used to build the filename "videoc_audout.2"
> and is also inserted in the .TH (title line), e.g:
>
> ---
> .TH "VIDIOC_AUDOUT" "2" "July 06, 2016" "Linux" "Linux Programmer's Manual"
> ---
>
> The date in the .TH will be the build date and the last two fields
> are always "Linux" and "Linux Programmer's Manual" (see man-page7)
>
> My first question is, do we really need author and address and when we
> need it, how should we handle these items?
>
> The man-pages7 says:
>
> Use of an AUTHORS section is strongly discouraged ...
> if you write or significantly amend a page, add
> a copyright notice as a comment in the source file ...
> If you are the author of a device driver and want to
> include an address for reporting bugs, place this under
> the BUGS section.
For the media stuff (both the uAPI and kernel-docs), I don't
think it is needed, at least for the things we have there right now.
Currently, we document only the kAPI and uAPI stuff (e. g. the
subsystem core), with has multiple authors. So, if one wants
to check the copyrights, he would need to go to the Kernel's tree.
If we're willing to document single drivers (I'm now talking
only about kernel-docs), then having an AUTHOR could be interesting.
Yet, IMHO, the best would be, instead, to look into the MAINTAINERS
file and get the emails of the ones responsible for maintaining the
driver (usually a mailing list), using a logic similar to:
./scripts/get_maintainers.pl
> I think there are many other question, we have to answer, e.g.
> how this is married with the kernel-doc comments, but at first
> it might be the best, we focus on "handwritten" man-pages.
> Later, we can discuss how this markup will be produced by
> the kernel-doc parser.
Agreed. Once we have an extension capable of generating man pages
based on a tag inside the rst file, it shouldn't be hard to automate
kernel-doc to use it.
>
> I have many other thoughts about man pages and I will remark
> them when the discussion running, but at first I want to now
> from you all:
>
> What are your suggestions about man page generation?
One thing that it needs to address is that the flat-tables should
also be converted somehow to groff format. Groff has a table
preprocessor (tbl). With that, outputting some thing like:
.TS
tab(;) allbox;
l l
l ld
r ^
l rd.
;foobar
T{
.br
T};foo
r;
T{
.br
T};bar
\^;\^
.TE
(example copied from tbl man page)
will produce this table with:
$ man ./foo
┌─┬┐
│ │ foobar │
├─┼┤
│ ││
│ ││
├─┤│
│ r │ foo│
├─┼┤
│ ││
│ │bar │
└─┴┘
Yet, I'm not sure how portable is to use such preprocessor.
>
> Thanks for any remark ...
>
> -- Markus --
>
> References:
>
> * linux man pages: https://www.kernel.org/doc/man-pages/
> * man-page(7): http://man7.org/linux/man-pages/man7/man-pages.7.html
--
Thanks,
Mauro
--
To
Re: [RFC] Requirements for man page generation
Am 14.07.2016 um 16:19 schrieb Mauro Carvalho Chehab :
> Em Thu, 14 Jul 2016 13:45:00 +0200
> Markus Heiser escreveu:
>
>> Hi Jonathan, hi all,
>>
>> I want to contribute a modified version of my man-page builder,
>> but before we should elaborate what we need in more detail.
>> We have two use-cases from which we want to create man page.
>>
>> * create man-pages from kernel-doc comments and
>> * create man-pages from "handwritten" reST documents
>>
>> For the "handwritten", sphinx-doc brings the "man" builder described in [1].
>>
>> [1] http://www.sphinx-doc.org/en/stable/config.html#confval-man_pages
>>
>> Mauro and I figured out, that [1] has some drawbacks:
>>
>> 1. you need a separate file for each man-page (see "startdocname" [1])
>> 2. you need to touch the conf.py every time you mark a content
>> as man-page.
>
> This will never scale. At media, we have already hundreds of
> stuff that would be better fit as a man page.
>
>> 3. The "NAME" section is created by the builder and could not
>> be a part of your reST document (see "name" [1])
>>
>> Thats why we recommend a simple markup (a directive) to mark reST
>> content as content from which a man-page should be build. E.g:
>>
>> ---
>> **
>> ioctl VIDIOC_G_AUDOUT, VIDIOC_S_AUDOUT
>> **
>>
>> .. kernel-man:
>> :man-name: videoc_audout
>
> I guess it would be interesting to allow specifying multiple
> man pages. In this specific example, two ioctls are documented
> the same way. I guess it would make sense to produce two man
> pages, so, if the user asks for:
>
> $ man vidioc_g_audout
> or
> $ man vidioc_s_audout
>
> it will see the contents of this man page.
OK, should not be hard to implement.
>> :man-sec: 2
>> :author: John Sample
>> :address: john.sam...@example.org
>>
>> Name
>>
>>
>> VIDIOC_G_AUDOUT - VIDIOC_S_AUDOUT - Query or select the current audio output
>>
>> Return
>> ==
>> ...
>> ---
>>
>> The man-name and man-sec is used to build the filename "videoc_audout.2"
>> and is also inserted in the .TH (title line), e.g:
>>
>> ---
>> .TH "VIDIOC_AUDOUT" "2" "July 06, 2016" "Linux" "Linux Programmer's Manual"
>> ---
>>
>> The date in the .TH will be the build date and the last two fields
>> are always "Linux" and "Linux Programmer's Manual" (see man-page7)
>>
>> My first question is, do we really need author and address and when we
>> need it, how should we handle these items?
>>
>> The man-pages7 says:
>>
>> Use of an AUTHORS section is strongly discouraged ...
>> if you write or significantly amend a page, add
>> a copyright notice as a comment in the source file ...
>> If you are the author of a device driver and want to
>> include an address for reporting bugs, place this under
>> the BUGS section.
>
> For the media stuff (both the uAPI and kernel-docs), I don't
> think it is needed, at least for the things we have there right now.
>
> Currently, we document only the kAPI and uAPI stuff (e. g. the
> subsystem core), with has multiple authors. So, if one wants
> to check the copyrights, he would need to go to the Kernel's tree.
>
> If we're willing to document single drivers (I'm now talking
> only about kernel-docs), then having an AUTHOR could be interesting.
>
> Yet, IMHO, the best would be, instead, to look into the MAINTAINERS
> file and get the emails of the ones responsible for maintaining the
> driver (usually a mailing list), using a logic similar to:
> ./scripts/get_maintainers.pl
May I misunderstood you: how should this work? ... I mean, the
reST file is somewhere under Documentation/ ... this might work
for kernel-doc generated man pages, where the source file is parsed.
>> I think there are many other question, we have to answer, e.g.
>> how this is married with the kernel-doc comments, but at first
>> it might be the best, we focus on "handwritten" man-pages.
>> Later, we can discuss how this markup will be produced by
>> the kernel-doc parser.
>
> Agreed. Once we have an extension capable of generating man pages
> based on a tag inside the rst file, it shouldn't be hard to automate
> kernel-doc to use it.
>
>>
>> I have many other thoughts about man pages and I will remark
>> them when the discussion running, but at first I want to now
>> from you all:
>>
>> What are your suggestions about man page generation?
>
> One thing that it needs to address is that the flat-tables should
> also be converted somehow to groff format. Groff has a table
> preprocessor (tbl). With that, outputting some thing like:
>
> .TS
> tab(;) allbox;
> l l
> l ld
> r ^
> l rd.
> ;foobar
> T{
>
> .br
>
> T};foo
> r;
> T{
>
> .br
>
> T};bar
> \^;\^
> .TE
>
> (example copied from tbl man page)
>
> will produce this table with:
>
>
[PATCH 09/10] ARM: dts: Add Arria10 DMA EDAC devicetree entry
From: Thor Thayer
Add the device tree entries needed to support the Altera DMA
FIFO buffer EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
---
arch/arm/boot/dts/socfpga_arria10.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 228f663..a506ec0 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -644,6 +644,14 @@
interrupts = <5 IRQ_TYPE_LEVEL_HIGH>,
<37 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ dma-ecc@ff8c8000 {
+ compatible = "altr,socfpga-dma-ecc";
+ reg = <0xff8c8000 0x400>;
+ altr,ecc-parent = <&pdma>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>,
+<42 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
rst: rstmgr@ffd05000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] EDAC, altera: Add Arria10 DMA EDAC support
From: Thor Thayer
Add Altera Arria10 DMA FIFO memory EDAC support.
Signed-off-by: Thor Thayer
---
drivers/edac/Kconfig |7 +++
drivers/edac/altera_edac.c | 34 +-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 47378b3..d1fd57a 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -405,6 +405,13 @@ config EDAC_ALTERA_NAND
Support for error detection and correction on the
Altera NAND FIFO Memory for Altera SoCs.
+config EDAC_ALTERA_DMA
+ bool "Altera DMA FIFO ECC"
+ depends on EDAC_ALTERA=y && PL330_DMA=y
+ help
+ Support for error detection and correction on the
+ Altera DMA FIFO Memory for Altera SoCs.
+
config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on EDAC_MM_EDAC && ARCH_ZYNQ
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 35d87d1..6e4afbc 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1312,6 +1312,33 @@ early_initcall(socfpga_init_nand_ecc);
#endif /* CONFIG_EDAC_ALTERA_NAND */
+/** DMA Device Functions **/
+
+#ifdef CONFIG_EDAC_ALTERA_DMA
+
+static const struct edac_device_prv_data a10_dmaecc_data = {
+ .setup = altr_check_ecc_deps,
+ .ce_clear_mask = ALTR_A10_ECC_SERRPENA,
+ .ue_clear_mask = ALTR_A10_ECC_DERRPENA,
+ .dbgfs_name = "altr_trigger",
+ .ecc_enable_mask = ALTR_A10_COMMON_ECC_EN_CTL,
+ .ecc_en_ofst = ALTR_A10_ECC_CTRL_OFST,
+ .ce_set_mask = ALTR_A10_ECC_TSERRA,
+ .ue_set_mask = ALTR_A10_ECC_TDERRA,
+ .set_err_ofst = ALTR_A10_ECC_INTTEST_OFST,
+ .ecc_irq_handler = altr_edac_a10_ecc_irq,
+ .inject_fops = &altr_edac_a10_device_inject_fops,
+};
+
+static int __init socfpga_init_dma_ecc(void)
+{
+ return altr_init_a10_ecc_device_type("altr,socfpga-dma-ecc");
+}
+
+early_initcall(socfpga_init_dma_ecc);
+
+#endif /* CONFIG_EDAC_ALTERA_DMA */
+
/* Arria10 EDAC Device Functions */
static const struct of_device_id altr_edac_a10_device_of_match[] = {
#ifdef CONFIG_EDAC_ALTERA_L2C
@@ -1328,6 +1355,9 @@ static const struct of_device_id
altr_edac_a10_device_of_match[] = {
#ifdef CONFIG_EDAC_ALTERA_NAND
{ .compatible = "altr,socfpga-nand-ecc", .data = &a10_nandecc_data },
#endif
+#ifdef CONFIG_EDAC_ALTERA_DMA
+ { .compatible = "altr,socfpga-dma-ecc", .data = &a10_dmaecc_data },
+#endif
{},
};
MODULE_DEVICE_TABLE(of, altr_edac_a10_device_of_match);
@@ -1621,7 +1651,9 @@ static int altr_edac_a10_probe(struct platform_device
*pdev)
(of_device_is_compatible(child,
"altr,socfpga-eth-mac-ecc")) ||
(of_device_is_compatible(child,
- "altr,socfpga-nand-ecc")))
+ "altr,socfpga-nand-ecc")) ||
+(of_device_is_compatible(child,
+ "altr,socfpga-dma-ecc")))
altr_edac_a10_device_add(edac, child);
else if (of_device_is_compatible(child,
"altr,sdram-edac-a10"))
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] Documentation: dt: socfpga: Add Arria10 DMA EDAC binding
From: Thor Thayer
Add the device tree bindings needed to support the Altera DMA
FIFO buffer EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
---
.../bindings/arm/altera/socfpga-eccmgr.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
index 1bcbab2..ad8245b 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
@@ -98,6 +98,14 @@ Required Properties:
- interrupts : Should be single bit error interrupt, then double bit error
interrupt, in this order.
+DMA FIFO ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-dma-ecc"
+- reg : Address and size for ECC block registers.
+- altr,ecc-parent : phandle to parent DMA node.
+- interrupts : Should be single bit error interrupt, then double bit error
+ interrupt, in this order.
+
Example:
eccmgr: eccmgr@ffd06000 {
@@ -164,4 +172,12 @@ Example:
interrupts = <12 IRQ_TYPE_LEVEL_HIGH>,
<44 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ dma-ecc@ff8c8000 {
+ compatible = "altr,socfpga-dma-ecc";
+ reg = <0xff8c8000 0x400>;
+ altr,ecc-parent = <&pdma>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>,
+<42 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] Documentation: dt: socfpga: Add Arria10 USB EDAC binding
From: Thor Thayer
Add the device tree bindings needed to support the Altera USB
FIFO buffer EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
---
.../bindings/arm/altera/socfpga-eccmgr.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
index ad8245b..3ffeb12 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
@@ -106,6 +106,14 @@ Required Properties:
- interrupts : Should be single bit error interrupt, then double bit error
interrupt, in this order.
+USB FIFO ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-usb-ecc"
+- reg : Address and size for ECC block registers.
+- altr,ecc-parent : phandle to parent USB node.
+- interrupts : Should be single bit error interrupt, then double bit error
+ interrupt, in this order.
+
Example:
eccmgr: eccmgr@ffd06000 {
@@ -179,5 +187,12 @@ Example:
altr,ecc-parent = <&pdma>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH>,
<42 IRQ_TYPE_LEVEL_HIGH>;
+
+ usb0-ecc@ff8c8800 {
+ compatible = "altr,socfpga-usb-ecc";
+ reg = <0xff8c8800 0x400>;
+ altr,ecc-parent = <&usb0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>,
+<34 IRQ_TYPE_LEVEL_HIGH>;
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] Add NAND, DMA, USB, and QSPI EDAC
From: Thor Thayer This patch series adds the NAND, DMA, USB and QSPI FIFO EDAC modules. Thor Thayer (10): Documentation: dt: socfpga: Add Arria10 NAND EDAC binding Documentation: dt: socfpga: Add Arria10 DMA EDAC binding Documentation: dt: socfpga: Add Arria10 USB EDAC binding Documentation: dt: socfpga: Add Arria10 QSPI EDAC binding EDAC, altera: Add Arria10 NAND EDAC support EDAC, altera: Add Arria10 DMA EDAC support EDAC, altera: Add Arria10 USB EDAC support EDAC, altera: Add Arria10 QSPI EDAC support ARM: dts: Add Arria10 DMA EDAC devicetree entry ARM: dts: Add Arria10 USB EDAC devicetree entry .../bindings/arm/altera/socfpga-eccmgr.txt | 79 arch/arm/boot/dts/socfpga_arria10.dtsi | 16 +++ drivers/edac/Kconfig | 28 + drivers/edac/altera_edac.c | 130 +++- 4 files changed, 252 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] ARM: dts: Add Arria10 USB EDAC devicetree entry
From: Thor Thayer
Add the device tree entries needed to support the Altera USB
FIFO buffer EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
---
arch/arm/boot/dts/socfpga_arria10.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index a506ec0..bd548ab 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -652,6 +652,14 @@
interrupts = <10 IRQ_TYPE_LEVEL_HIGH>,
<42 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ usb0-ecc@ff8c8800 {
+ compatible = "altr,socfpga-usb-ecc";
+ reg = <0xff8c8800 0x400>;
+ altr,ecc-parent = <&usb0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>,
+<34 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
rst: rstmgr@ffd05000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] EDAC, altera: Add Arria10 NAND EDAC support
From: Thor Thayer
Add Altera Arria10 NAND FIFO memory EDAC support.
Signed-off-by: Thor Thayer
---
drivers/edac/Kconfig |7 +++
drivers/edac/altera_edac.c | 34 +-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index d0c1dab..47378b3 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -398,6 +398,13 @@ config EDAC_ALTERA_ETHERNET
Support for error detection and correction on the
Altera Ethernet FIFO Memory for Altera SoCs.
+config EDAC_ALTERA_NAND
+ bool "Altera NAND FIFO ECC"
+ depends on EDAC_ALTERA=y && MTD_NAND_DENALI
+ help
+ Support for error detection and correction on the
+ Altera NAND FIFO Memory for Altera SoCs.
+
config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on EDAC_MM_EDAC && ARCH_ZYNQ
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 2398d07..35d87d1 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1285,6 +1285,33 @@ early_initcall(socfpga_init_ethernet_ecc);
#endif /* CONFIG_EDAC_ALTERA_ETHERNET */
+/** NAND Device Functions **/
+
+#ifdef CONFIG_EDAC_ALTERA_NAND
+
+static const struct edac_device_prv_data a10_nandecc_data = {
+ .setup = altr_check_ecc_deps,
+ .ce_clear_mask = ALTR_A10_ECC_SERRPENA,
+ .ue_clear_mask = ALTR_A10_ECC_DERRPENA,
+ .dbgfs_name = "altr_trigger",
+ .ecc_enable_mask = ALTR_A10_COMMON_ECC_EN_CTL,
+ .ecc_en_ofst = ALTR_A10_ECC_CTRL_OFST,
+ .ce_set_mask = ALTR_A10_ECC_TSERRA,
+ .ue_set_mask = ALTR_A10_ECC_TDERRA,
+ .set_err_ofst = ALTR_A10_ECC_INTTEST_OFST,
+ .ecc_irq_handler = altr_edac_a10_ecc_irq,
+ .inject_fops = &altr_edac_a10_device_inject_fops,
+};
+
+static int __init socfpga_init_nand_ecc(void)
+{
+ return altr_init_a10_ecc_device_type("altr,socfpga-nand-ecc");
+}
+
+early_initcall(socfpga_init_nand_ecc);
+
+#endif /* CONFIG_EDAC_ALTERA_NAND */
+
/* Arria10 EDAC Device Functions */
static const struct of_device_id altr_edac_a10_device_of_match[] = {
#ifdef CONFIG_EDAC_ALTERA_L2C
@@ -1298,6 +1325,9 @@ static const struct of_device_id
altr_edac_a10_device_of_match[] = {
{ .compatible = "altr,socfpga-eth-mac-ecc",
.data = &a10_enetecc_data },
#endif
+#ifdef CONFIG_EDAC_ALTERA_NAND
+ { .compatible = "altr,socfpga-nand-ecc", .data = &a10_nandecc_data },
+#endif
{},
};
MODULE_DEVICE_TABLE(of, altr_edac_a10_device_of_match);
@@ -1589,7 +1619,9 @@ static int altr_edac_a10_probe(struct platform_device
*pdev)
else if ((of_device_is_compatible(child,
"altr,socfpga-a10-ocram-ecc")) ||
(of_device_is_compatible(child,
- "altr,socfpga-eth-mac-ecc")))
+ "altr,socfpga-eth-mac-ecc")) ||
+(of_device_is_compatible(child,
+ "altr,socfpga-nand-ecc")))
altr_edac_a10_device_add(edac, child);
else if (of_device_is_compatible(child,
"altr,sdram-edac-a10"))
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] EDAC, altera: Add Arria10 USB EDAC support
From: Thor Thayer
Add Altera Arria10 USB FIFO memory EDAC support.
Signed-off-by: Thor Thayer
---
drivers/edac/Kconfig |7 +++
drivers/edac/altera_edac.c | 34 +-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index d1fd57a..1966068 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -412,6 +412,13 @@ config EDAC_ALTERA_DMA
Support for error detection and correction on the
Altera DMA FIFO Memory for Altera SoCs.
+config EDAC_ALTERA_USB
+ bool "Altera USB FIFO ECC"
+ depends on EDAC_ALTERA=y && USB_DWC2
+ help
+ Support for error detection and correction on the
+ Altera USB FIFO Memory for Altera SoCs.
+
config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on EDAC_MM_EDAC && ARCH_ZYNQ
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 6e4afbc..439d6cb 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1339,6 +1339,33 @@ early_initcall(socfpga_init_dma_ecc);
#endif /* CONFIG_EDAC_ALTERA_DMA */
+/** USB Device Functions **/
+
+#ifdef CONFIG_EDAC_ALTERA_USB
+
+static const struct edac_device_prv_data a10_usbecc_data = {
+ .setup = altr_check_ecc_deps,
+ .ce_clear_mask = ALTR_A10_ECC_SERRPENA,
+ .ue_clear_mask = ALTR_A10_ECC_DERRPENA,
+ .dbgfs_name = "altr_trigger",
+ .ecc_enable_mask = ALTR_A10_COMMON_ECC_EN_CTL,
+ .ecc_en_ofst = ALTR_A10_ECC_CTRL_OFST,
+ .ce_set_mask = ALTR_A10_ECC_TSERRA,
+ .ue_set_mask = ALTR_A10_ECC_TDERRA,
+ .set_err_ofst = ALTR_A10_ECC_INTTEST_OFST,
+ .ecc_irq_handler = altr_edac_a10_ecc_irq,
+ .inject_fops = &altr_edac_a10_device_inject_fops,
+};
+
+static int __init socfpga_init_usb_ecc(void)
+{
+ return altr_init_a10_ecc_device_type("altr,socfpga-usb-ecc");
+}
+
+early_initcall(socfpga_init_usb_ecc);
+
+#endif /* CONFIG_EDAC_ALTERA_USB */
+
/* Arria10 EDAC Device Functions */
static const struct of_device_id altr_edac_a10_device_of_match[] = {
#ifdef CONFIG_EDAC_ALTERA_L2C
@@ -1358,6 +1385,9 @@ static const struct of_device_id
altr_edac_a10_device_of_match[] = {
#ifdef CONFIG_EDAC_ALTERA_DMA
{ .compatible = "altr,socfpga-dma-ecc", .data = &a10_dmaecc_data },
#endif
+#ifdef CONFIG_EDAC_ALTERA_USB
+ { .compatible = "altr,socfpga-usb-ecc", .data = &a10_usbecc_data },
+#endif
{},
};
MODULE_DEVICE_TABLE(of, altr_edac_a10_device_of_match);
@@ -1653,7 +1683,9 @@ static int altr_edac_a10_probe(struct platform_device
*pdev)
(of_device_is_compatible(child,
"altr,socfpga-nand-ecc")) ||
(of_device_is_compatible(child,
- "altr,socfpga-dma-ecc")))
+ "altr,socfpga-dma-ecc")) ||
+(of_device_is_compatible(child,
+ "altr,socfpga-usb-ecc")))
altr_edac_a10_device_add(edac, child);
else if (of_device_is_compatible(child,
"altr,sdram-edac-a10"))
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] Documentation: dt: socfpga: Add Arria10 QSPI EDAC binding
From: Thor Thayer
Add the device tree bindings needed to support the Altera QSPI
FIFO buffer EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
---
.../bindings/arm/altera/socfpga-eccmgr.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
index 3ffeb12..ee66df0 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
@@ -114,6 +114,14 @@ Required Properties:
- interrupts : Should be single bit error interrupt, then double bit error
interrupt, in this order.
+QSPI FIFO ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-qspi-ecc"
+- reg : Address and size for ECC block registers.
+- altr,ecc-parent : phandle to parent QSPI node.
+- interrupts : Should be single bit error interrupt, then double bit error
+ interrupt, in this order.
+
Example:
eccmgr: eccmgr@ffd06000 {
@@ -195,4 +203,12 @@ Example:
interrupts = <2 IRQ_TYPE_LEVEL_HIGH>,
<34 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ qspi-ecc@ff8c8400 {
+ compatible = "altr,socfpga-qspi-ecc";
+ reg = <0xff8c8400 0x400>;
+ altr,ecc-parent = <&qspi>;
+ interrupts = <14 IRQ_TYPE_LEVEL_HIGH>,
+<46 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] EDAC, altera: Add Arria10 QSPI EDAC support
From: Thor Thayer
Add Altera Arria10 QSPI FIFO memory EDAC support.
Signed-off-by: Thor Thayer
---
drivers/edac/Kconfig |7 +++
drivers/edac/altera_edac.c | 34 +-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 1966068..72752f4 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -419,6 +419,13 @@ config EDAC_ALTERA_USB
Support for error detection and correction on the
Altera USB FIFO Memory for Altera SoCs.
+config EDAC_ALTERA_QSPI
+ bool "Altera QSPI FIFO ECC"
+ depends on EDAC_ALTERA=y && SPI_CADENCE_QUADSPI
+ help
+ Support for error detection and correction on the
+ Altera QSPI FIFO Memory for Altera SoCs.
+
config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on EDAC_MM_EDAC && ARCH_ZYNQ
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 439d6cb..b2900df 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1366,6 +1366,33 @@ early_initcall(socfpga_init_usb_ecc);
#endif /* CONFIG_EDAC_ALTERA_USB */
+/** QSPI Device Functions **/
+
+#ifdef CONFIG_EDAC_ALTERA_QSPI
+
+static const struct edac_device_prv_data a10_qspiecc_data = {
+ .setup = altr_check_ecc_deps,
+ .ce_clear_mask = ALTR_A10_ECC_SERRPENA,
+ .ue_clear_mask = ALTR_A10_ECC_DERRPENA,
+ .dbgfs_name = "altr_trigger",
+ .ecc_enable_mask = ALTR_A10_COMMON_ECC_EN_CTL,
+ .ecc_en_ofst = ALTR_A10_ECC_CTRL_OFST,
+ .ce_set_mask = ALTR_A10_ECC_TSERRA,
+ .ue_set_mask = ALTR_A10_ECC_TDERRA,
+ .set_err_ofst = ALTR_A10_ECC_INTTEST_OFST,
+ .ecc_irq_handler = altr_edac_a10_ecc_irq,
+ .inject_fops = &altr_edac_a10_device_inject_fops,
+};
+
+static int __init socfpga_init_qspi_ecc(void)
+{
+ return altr_init_a10_ecc_device_type("altr,socfpga-qspi-ecc");
+}
+
+early_initcall(socfpga_init_qspi_ecc);
+
+#endif /* CONFIG_EDAC_ALTERA_QSPI */
+
/* Arria10 EDAC Device Functions */
static const struct of_device_id altr_edac_a10_device_of_match[] = {
#ifdef CONFIG_EDAC_ALTERA_L2C
@@ -1388,6 +1415,9 @@ static const struct of_device_id
altr_edac_a10_device_of_match[] = {
#ifdef CONFIG_EDAC_ALTERA_USB
{ .compatible = "altr,socfpga-usb-ecc", .data = &a10_usbecc_data },
#endif
+#ifdef CONFIG_EDAC_ALTERA_QSPI
+ { .compatible = "altr,socfpga-qspi-ecc", .data = &a10_qspiecc_data },
+#endif
{},
};
MODULE_DEVICE_TABLE(of, altr_edac_a10_device_of_match);
@@ -1685,7 +1715,9 @@ static int altr_edac_a10_probe(struct platform_device
*pdev)
(of_device_is_compatible(child,
"altr,socfpga-dma-ecc")) ||
(of_device_is_compatible(child,
- "altr,socfpga-usb-ecc")))
+ "altr,socfpga-usb-ecc")) ||
+(of_device_is_compatible(child,
+ "altr,socfpga-qspi-ecc")))
altr_edac_a10_device_add(edac, child);
else if (of_device_is_compatible(child,
"altr,sdram-edac-a10"))
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] Documentation: dt: socfpga: Add Arria10 NAND EDAC binding
From: Thor Thayer
Add the device tree bindings needed to support the Altera NAND
FIFO buffers EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
---
.../bindings/arm/altera/socfpga-eccmgr.txt | 32
1 file changed, 32 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
index b545856..1bcbab2 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
@@ -90,6 +90,14 @@ Required Properties:
- interrupts : Should be single bit error interrupt, then double bit error
interrupt, in this order.
+NAND FIFO ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-nand-ecc"
+- reg : Address and size for ECC block registers.
+- altr,ecc-parent : phandle to parent NAND node.
+- interrupts : Should be single bit error interrupt, then double bit error
+ interrupt, in this order.
+
Example:
eccmgr: eccmgr@ffd06000 {
@@ -132,4 +140,28 @@ Example:
interrupts = <5 IRQ_TYPE_LEVEL_HIGH>,
<37 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ nand-buf-ecc@ff8c2000 {
+ compatible = "altr,socfpga-nand-ecc";
+ reg = <0xff8c2000 0x400>;
+ altr,ecc-parent = <&nand>;
+ interrupts = <11 IRQ_TYPE_LEVEL_HIGH>,
+<43 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ nand-rd-ecc@ff8c2400 {
+ compatible = "altr,socfpga-nand-ecc";
+ reg = <0xff8c2400 0x400>;
+ altr,ecc-parent = <&nand>;
+ interrupts = <13 IRQ_TYPE_LEVEL_HIGH>,
+<45 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ nand-wr-ecc@ff8c2800 {
+ compatible = "altr,socfpga-nand-ecc";
+ reg = <0xff8c2800 0x400>;
+ altr,ecc-parent = <&nand>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>,
+<44 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Requirements for man page generation
Em Thu, 14 Jul 2016 17:41:47 +0200
Markus Heiser escreveu:
> Am 14.07.2016 um 16:19 schrieb Mauro Carvalho Chehab
> :
> > If we're willing to document single drivers (I'm now talking
> > only about kernel-docs), then having an AUTHOR could be interesting.
> >
> > Yet, IMHO, the best would be, instead, to look into the MAINTAINERS
> > file and get the emails of the ones responsible for maintaining the
> > driver (usually a mailing list), using a logic similar to:
> > ./scripts/get_maintainers.pl
>
> May I misunderstood you: how should this work? ... I mean, the
> reST file is somewhere under Documentation/ ... this might work
> for kernel-doc generated man pages, where the source file is parsed.
Yes, I'm talking about using it for kernel-doc processed man pages.
It could call get_maintainers.pl to retrieve just the entires at
MAINTAINERS.
> >> What are your suggestions about man page generation?
> >
> > One thing that it needs to address is that the flat-tables should
> > also be converted somehow to groff format. Groff has a table
> > preprocessor (tbl). With that, outputting some thing like:
> >
> > .TS
> > tab(;) allbox;
> > l l
> > l ld
> > r ^
> > l rd.
> > ;foobar
> > T{
> >
> > .br
> >
> > T};foo
> > r;
> > T{
> >
> > .br
> >
> > T};bar
> > \^;\^
> > .TE
> >
> > (example copied from tbl man page)
> >
> > will produce this table with:
> >
> > $ man ./foo
> >
> > ┌─┬┐
> > │ │ foobar │
> > ├─┼┤
> > │ ││
> > │ ││
> > ├─┤│
> > │ r │ foo│
> > ├─┼┤
> > │ ││
> > │ │bar │
> > └─┴┘
> >
> > Yet, I'm not sure how portable is to use such preprocessor.
>
> About portability, the tbl man page says:
>
> The output generated by GNU tbl cannot
> be processed with Unix troff; it must be
> processed with GNU troff.
Yes, I know, but I suspect that the original Unix troff has
long gone on Linux distributions.
> About reST tables:
>
> The output of tables is independent from the reST markup you
> used to describe the table ... ASCII art tables and flat-tables
> result in the same (internal) node-tree. So it does not matter
> if you define a cell spanning with ASCII art or with the
> flat-table directive.
That's good news.
> The problem is, that the underlying man page translator does not
> support row or cell spanning:
>
> https://github.com/docutils/docutils/blob/master/docutils/docutils/writers/manpage.py#L615
I see.
> I think I could extend the Translator to support row and
> cell spanning, but as far as I can estimate from here, this
> this will need some efforts.
I'm almost sure we don't use row spanning. Not sure how many
pages use cell spanning among the ones that describe ioctls,
but I guess that at least cell spanning would be required.
Btw, I'm a not python programmer, but it seems that even a
simple table will be badly formatted, as it seems that it
only adds the text document without actually trying to convert
the table into something more readable... it seems the code
only does:
self.context.append(len(self.body))
I would be expecting it to add some tags, like using .TP,
in order to indent the table.
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 00/12] support "task_isolation" mode
Here is a respin of the task-isolation patch set. This primarily reflects feedback from Frederic and Peter Z. Changes since v12: - Rebased on v4.7-rc7. - New default "strict" model for task isolation - tasks exit the kernel from the initial prctl() to userspace, and can only legally exit by calling prctl() again to turn off isolation. Any other kernel entry results in a SIGKILL by default. - New optional "relaxed" mode, where the application can receive some signal other than SIGKILL, or no signal at all, when it re-enters the kernel. Since by default task isolation is now strict, there is no longer an additional "STRICT" mode, but rather a new "NOSIG" mode that builds on top of the "USERSIG" support for setting a signal other than SIGKILL to be delivered to the process. The "NOSIG" mode also relaxes the required criteria for entering task isolation mode; we just issue a warning if the affinity isn't set right, and we don't fail with EAGAIN if the kernel isn't ready to stop the tick. Running your task-isolation application in this "NOSIG" mode is also necessary when debugging, since otherwise hitting breakpoints, etc., will cause a fatal signal to be sent to the process. Frederic has suggested we might want to defer this functionality until later, but (in addition to the debuggability aspect) there is some thought that it might be useful for e.g. HPC, so I have just broken out the additional semantics into a single separate patch at the end of the series. - Function naming has been changed and comments have been added to try to clarify the role of the task-isolation reporting on kernel entries that do NOT cause signals. This hopefully clarifies why we only invoke the renamed task_isolation_quiet_exception() in a few places, since all the other places generate signals anyway. [PeterZ] - The task_isolation_debug() call now has an inline piece that checks to see if the target is a task_isolation cpu before actually calling. [PeterZ] - In _task_isolation_debug(), we use the new task_struct_trylock() call that is in linux-next now; for now I just have a static copy of the function, which I will switch to using the version from linux-next in the next rebasing. [PeterZ] - We now pass a string describing the interrupt up from task_isolation_debug() so there is more information on where the interrupt came from beyond just the stack backtrace. [PeterZ] - I added task_isolation_debug() hooks to smp_sched_reschedule() on x86, which was missing before, and removed the hooks in the tile send_IPI_*() routines, since there were already hooks in the callers. Likewise I moved the hook for arm64 from the generic smp_cross_call() routine to the only caller that wasn't already hooked, smp_send_reschedule(). The commit message clarifies the rationale for where hooks are placed. - I moved the page fault reporting so that it only reports in the case that we are not also sending a SIGSEGV/SIGBUS, for consistency with other uses of task_isolation_quiet_exception(). The previous (v12) patch series is here: https://lkml.kernel.org/g/1459877922-15512-1-git-send-email-cmetc...@mellanox.com This version of the patch series has been tested on arm64 and tilegx, and build-tested on x86. It remains true that the 1 Hz tick needs to be disabled for this patch series to be able to achieve its primary goal of enabling truly tick-free operation, but that is ongoing orthogonal work. Frederick, do you have a sense of what is left to be done there? I can certainly try to contribute to that effort as well. The series is available at: git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git dataplane Chris Metcalf (12): vmstat: add quiet_vmstat_sync function vmstat: add vmstat_idle function lru_add_drain_all: factor out lru_add_drain_needed task_isolation: add initial support task_isolation: track asynchronous interrupts arch/x86: enable task isolation functionality arm64: factor work_pending state machine to C arch/arm64: enable task isolation functionality arch/tile: enable task isolation functionality arm, tile: turn off timer tick for oneshot_stopped state task_isolation: support CONFIG_TASK_ISOLATION_ALL task_isolation: add user-settable notification signal Documentation/kernel-parameters.txt| 16 ++ arch/arm64/Kconfig | 1 + arch/arm64/include/asm/thread_info.h | 5 +- arch/arm64/kernel/entry.S | 12 +- arch/arm64/kernel/ptrace.c | 15 +- arch/arm64/kernel/signal.c | 42 +++- arch/arm64/kernel/smp.c| 2 + arch/arm64/mm/fault.c | 8 +- arch/tile/Kconfig | 1 + arch/tile/include/asm/thread_info.h| 4 +- arch/tile/kernel/process.c | 9 + arch/tile/kernel/ptrace.c | 7 + arch/tile/kernel/single_step.c | 7 + arch/tile/kernel/smp.c
[PATCH v13 12/12] task_isolation: add user-settable notification signal
By default, if a task in task isolation mode re-enters the kernel,
it is terminated with SIGKILL. With this commit, the application
can choose what signal to receive on a task isolation violation
by invoking prctl() with PR_TASK_ISOLATION_ENABLE, or'ing in the
PR_TASK_ISOLATION_USERSIG bit, and setting the specific requested
signal by or'ing in PR_TASK_ISOLATION_SET_SIG(sig).
This mode allows for catching the notification signal; for example,
in a production environment, it might be helpful to log information
to the application logging mechanism before exiting. Or, the
application might choose to re-enable task isolation and return to
continue execution.
As a special case, the user may set the signal to 0, which means
that no signal will be delivered. In this mode, the application
may freely enter the kernel for syscalls and synchronous exceptions
such as page faults, but each time it will be held in the kernel
before returning to userspace until the kernel has quiesced timer
ticks or other potential future interruptions, just like it does
on return from the initial prctl() call. Note that in this mode,
the task can be migrated away from its initial task_isolation core,
and if it is migrated to a non-isolated core it will lose task
isolation until it is migrated back to an isolated core.
In addition, in this mode we no longer require the affinity to
be set correctly on entry (though we warn on the console if it's
not right), and we don't bother to notify the user that the kernel
isn't ready to quiesce either (since we'll presumably be in and
out of the kernel multiple times with task isolation enabled anyway).
The PR_TASK_ISOLATION_NOSIG define is provided as a convenience
wrapper to express this semantic.
Signed-off-by: Chris Metcalf
---
include/uapi/linux/prctl.h | 5
kernel/isolation.c | 62 ++
2 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 2a49d0d2940a..7af6eb51c1dc 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -201,5 +201,10 @@ struct prctl_mm_map {
#define PR_SET_TASK_ISOLATION 48
#define PR_GET_TASK_ISOLATION 49
# define PR_TASK_ISOLATION_ENABLE (1 << 0)
+# define PR_TASK_ISOLATION_USERSIG (1 << 1)
+# define PR_TASK_ISOLATION_SET_SIG(sig)(((sig) & 0x7f) << 8)
+# define PR_TASK_ISOLATION_GET_SIG(bits) (((bits) >> 8) & 0x7f)
+# define PR_TASK_ISOLATION_NOSIG \
+ (PR_TASK_ISOLATION_USERSIG | PR_TASK_ISOLATION_SET_SIG(0))
#endif /* _LINUX_PRCTL_H */
diff --git a/kernel/isolation.c b/kernel/isolation.c
index 5e6cd67dfb0c..aca5de5e2e05 100644
--- a/kernel/isolation.c
+++ b/kernel/isolation.c
@@ -85,6 +85,15 @@ static bool can_stop_my_full_tick_now(void)
return ret;
}
+/* Get the signal number that will be sent for a particular set of flag bits.
*/
+static int task_isolation_sig(int flags)
+{
+ if (flags & PR_TASK_ISOLATION_USERSIG)
+ return PR_TASK_ISOLATION_GET_SIG(flags);
+ else
+ return SIGKILL;
+}
+
/*
* This routine controls whether we can enable task-isolation mode.
* The task must be affinitized to a single task_isolation core, or
@@ -92,16 +101,30 @@ static bool can_stop_my_full_tick_now(void)
* stop the nohz_full tick (e.g., no other schedulable tasks currently
* running, no POSIX cpu timers currently set up, etc.); if not, we
* return EAGAIN.
+ *
+ * If we will not be strictly enforcing kernel re-entry with a signal,
+ * we just generate a warning printk if there is a bad affinity set
+ * on entry (since after all you can always change it again after you
+ * call prctl) and we don't bother failing the prctl with -EAGAIN
+ * since we assume you will go in and out of kernel mode anyway.
*/
int task_isolation_set(unsigned int flags)
{
if (flags != 0) {
+ int sig = task_isolation_sig(flags);
+
if (cpumask_weight(tsk_cpus_allowed(current)) != 1 ||
!task_isolation_possible(raw_smp_processor_id())) {
/* Invalid task affinity setting. */
- return -EINVAL;
+ if (sig)
+ return -EINVAL;
+ else
+ pr_warn("%s/%d: enabling non-signalling task
isolation\n"
+ "and not bound to a single task
isolation core\n",
+ current->comm, current->pid);
}
- if (!can_stop_my_full_tick_now()) {
+
+ if (sig && !can_stop_my_full_tick_now()) {
/* System not yet ready for task isolation. */
return -EAGAIN;
}
@@ -160,11 +183,11 @@ void task_isolation_enter(void)
}
static void task_isolation_deliver_signal(struct task_struct *task,
-
[PATCH v13 11/12] task_isolation: support CONFIG_TASK_ISOLATION_ALL
This option, similar to NO_HZ_FULL_ALL, simplifies configuring
a system to boot by default with all cores except the boot core
running in task isolation mode.
Signed-off-by: Chris Metcalf
---
init/Kconfig | 10 ++
kernel/isolation.c | 6 ++
2 files changed, 16 insertions(+)
diff --git a/init/Kconfig b/init/Kconfig
index fc71444f9c30..0b8384c76571 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -810,6 +810,16 @@ config TASK_ISOLATION
You should say "N" unless you are intending to run a
high-performance userspace driver or similar task.
+config TASK_ISOLATION_ALL
+ bool "Provide task isolation on all CPUs by default (except CPU 0)"
+ depends on TASK_ISOLATION
+ help
+If the user doesn't pass the task_isolation boot option to
+define the range of task isolation CPUs, consider that all
+CPUs in the system are task isolation by default.
+Note the boot CPU will still be kept outside the range to
+handle timekeeping duty, etc.
+
config BUILD_BIN2C
bool
default n
diff --git a/kernel/isolation.c b/kernel/isolation.c
index a9fd4709825a..5e6cd67dfb0c 100644
--- a/kernel/isolation.c
+++ b/kernel/isolation.c
@@ -43,8 +43,14 @@ int __init task_isolation_init(void)
{
/* For offstack cpumask, ensure we allocate an empty cpumask early. */
if (!saw_boot_arg) {
+#ifdef CONFIG_TASK_ISOLATION_ALL
+ alloc_cpumask_var(&task_isolation_map, GFP_KERNEL);
+ cpumask_copy(task_isolation_map, cpu_possible_mask);
+ cpumask_clear_cpu(smp_processor_id(), task_isolation_map);
+#else
zalloc_cpumask_var(&task_isolation_map, GFP_KERNEL);
return 0;
+#endif
}
/*
--
2.7.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 05/12] task_isolation: track asynchronous interrupts
This commit adds support for tracking asynchronous interrupts
delivered to task-isolation tasks, e.g. IPIs or IRQs. Just
as for exceptions and syscalls, when this occurs we arrange to
deliver a signal to the task so that it knows it has been
interrupted. If the task is interrupted by an NMI, we can't
safely deliver a signal, so we just dump out a console stack.
We also support a new "task_isolation_debug" flag which forces
the console stack to be dumped out regardless. We try to catch
the original source of the interrupt, e.g. if an IPI is dispatched
to a task-isolation task, we dump the backtrace of the remote
core that is sending the IPI, rather than just dumping out a
trace showing the core received an IPI from somewhere.
Calls to task_isolation_debug() can be placed in the
platform-independent code when that results in fewer lines
of code changes, as for example is true of the users of the
arch_send_call_function_*() APIs. Or, they can be placed in the
per-architecture code when there are many callers, as for example
is true of the smp_send_reschedule() call.
A further cleanup might be to create an intermediate layer, so that
for example smp_send_reschedule() is a single generic function that
just calls arch_smp_send_reschedule(), allowing generic code to be
called every time smp_send_reschedule() is invoked. But for now,
we just update either callers or callees as makes most sense.
Signed-off-by: Chris Metcalf
---
Documentation/kernel-parameters.txt| 8
include/linux/context_tracking_state.h | 6 +++
include/linux/isolation.h | 13 ++
kernel/irq_work.c | 5 ++-
kernel/isolation.c | 74 ++
kernel/sched/core.c| 42 +++
kernel/signal.c| 7
kernel/smp.c | 6 ++-
kernel/softirq.c | 33 +++
9 files changed, 192 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 3db9bea08ed6..15fe7f029f8b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3900,6 +3900,14 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
also sets up nohz_full and isolcpus mode for the
listed set of cpus.
+ task_isolation_debug[KNL]
+ In kernels built with CONFIG_TASK_ISOLATION
+ and booted in task_isolation= mode, this
+ setting will generate console backtraces when
+ the kernel is about to interrupt a task that
+ has requested PR_TASK_ISOLATION_ENABLE and is
+ running on a task_isolation core.
+
tcpmhash_entries= [KNL,NET]
Set the number of tcp_metrics_hash slots.
Default value is 8192 or 16384 depending on total
diff --git a/include/linux/context_tracking_state.h
b/include/linux/context_tracking_state.h
index 1d34fe68f48a..4e2c4b900b82 100644
--- a/include/linux/context_tracking_state.h
+++ b/include/linux/context_tracking_state.h
@@ -39,8 +39,14 @@ static inline bool context_tracking_in_user(void)
{
return __this_cpu_read(context_tracking.state) == CONTEXT_USER;
}
+
+static inline bool context_tracking_cpu_in_user(int cpu)
+{
+ return per_cpu(context_tracking.state, cpu) == CONTEXT_USER;
+}
#else
static inline bool context_tracking_in_user(void) { return false; }
+static inline bool context_tracking_cpu_in_user(int cpu) { return false; }
static inline bool context_tracking_active(void) { return false; }
static inline bool context_tracking_is_enabled(void) { return false; }
static inline bool context_tracking_cpu_is_enabled(void) { return false; }
diff --git a/include/linux/isolation.h b/include/linux/isolation.h
index d9288b85b41f..02728b1f8775 100644
--- a/include/linux/isolation.h
+++ b/include/linux/isolation.h
@@ -46,6 +46,17 @@ extern void _task_isolation_quiet_exception(const char *fmt,
...);
_task_isolation_quiet_exception(fmt, ## __VA_ARGS__); \
} while (0)
+extern void _task_isolation_debug(int cpu, const char *type);
+#define task_isolation_debug(cpu, type)
\
+ do {\
+ if (task_isolation_possible(cpu)) \
+ _task_isolation_debug(cpu, type); \
+ } while (0)
+
+extern void task_isolation_debug_cpumask(const struct cpumask *,
+const char *type);
+extern void task_isolation_debug_task(int cpu, struct task_struct *p,
+ const char *type);
#else
static inline void task_isolation_init(void) { }
static inl
[PATCH v13 04/12] task_isolation: add initial support
The existing nohz_full mode is designed as a "soft" isolation mode that makes tradeoffs to minimize userspace interruptions while still attempting to avoid overheads in the kernel entry/exit path, to provide 100% kernel semantics, etc. However, some applications require a "hard" commitment from the kernel to avoid interruptions, in particular userspace device driver style applications, such as high-speed networking code. This change introduces a framework to allow applications to elect to have the "hard" semantics as needed, specifying prctl(PR_SET_TASK_ISOLATION, PR_TASK_ISOLATION_ENABLE) to do so. Subsequent commits will add additional flags and additional semantics. The kernel must be built with the new TASK_ISOLATION Kconfig flag to enable this mode, and the kernel booted with an appropriate task_isolation=CPULIST boot argument, which enables nohz_full and isolcpus as well. The "task_isolation" state is then indicated by setting a new task struct field, task_isolation_flag, to the value passed by prctl(), and also setting a TIF_TASK_ISOLATION bit in thread_info flags. When task isolation is enabled for a task, and it is returning to userspace on a task isolation core, it calls the new task_isolation_ready() / task_isolation_enter() routines to take additional actions to help the task avoid being interrupted in the future. The task_isolation_ready() call is invoked when TIF_TASK_ISOLATION is set in prepare_exit_to_usermode() or its architectural equivalent, and forces the loop to retry if the system is not ready. It is called with interrupts disabled and inspects the kernel state to determine if it is safe to return into an isolated state. In particular, if it sees that the scheduler tick is still enabled, it reports that it is not yet safe. Each time through the loop of TIF work to do, if TIF_TASK_ISOLATION is set, we call the new task_isolation_enter() routine. This takes any actions that might avoid a future interrupt to the core, such as a worker thread being scheduled that could be quiesced now (e.g. the vmstat worker) or a future IPI to the core to clean up some state that could be cleaned up now (e.g. the mm lru per-cpu cache). In addition, it reqeusts rescheduling if the scheduler dyntick is still running. Once the task has returned to userspace after issuing the prctl(), if it enters the kernel again via system call, page fault, or any of a number of other synchronous traps, the kernel will kill it with SIGKILL. For system calls, this test is performed immediately before the SECCOMP test and causes the syscall to return immediately with ENOSYS. To allow the state to be entered and exited, the syscall checking test ignores the prctl() syscall so that we can clear the bit again later, and ignores exit/exit_group to allow exiting the task without a pointless signal killing you as you try to do so. A new /sys/devices/system/cpu/task_isolation pseudo-file is added, parallel to the comparable nohz_full file. Separate patches that follow provide these changes for x86, tile, and arm64. Signed-off-by: Chris Metcalf --- Documentation/kernel-parameters.txt | 8 ++ drivers/base/cpu.c | 18 +++ include/linux/isolation.h | 60 ++ include/linux/sched.h | 3 + include/linux/tick.h| 2 + include/uapi/linux/prctl.h | 5 + init/Kconfig| 27 + kernel/Makefile | 1 + kernel/fork.c | 3 + kernel/isolation.c | 217 kernel/signal.c | 8 ++ kernel/sys.c| 9 ++ kernel/time/tick-sched.c| 36 +++--- 13 files changed, 384 insertions(+), 13 deletions(-) create mode 100644 include/linux/isolation.h create mode 100644 kernel/isolation.c diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 82b42c958d1c..3db9bea08ed6 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3892,6 +3892,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted. neutralize any effect of /proc/sys/kernel/sysrq. Useful for debugging. + task_isolation= [KNL] + In kernels built with CONFIG_TASK_ISOLATION=y, set + the specified list of CPUs where cpus will be able + to use prctl(PR_SET_TASK_ISOLATION) to set up task + isolation mode. Setting this boot flag implicitly + also sets up nohz_full and isolcpus mode for the + listed set of cpus. + tcpmhash_entries= [KNL,NET] Set the number of tcp_metrics_hash slots. Default value is 8192 or 16384 depending on total diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index 691eeea2f1
Re: [PATCH v13 00/12] support "task_isolation" mode
On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf wrote: > Here is a respin of the task-isolation patch set. This primarily > reflects feedback from Frederic and Peter Z. I still think this is the wrong approach, at least at this point. The first step should be to instrument things if necessary and fix the obvious cases where the kernel gets entered asynchronously. Only once there's a credible reason to believe it can work well should any form of strictness be applied. As an example, enough vmalloc/vfree activity will eventually cause flush_tlb_kernel_range to be called and *boom*, there goes your shiny production dataplane application. Once virtually mapped kernel stacks happen, the frequency with which this happens will only increase. On very brief inspection, __kmem_cache_shutdown will be a problem on some workloads as well. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] dax: some small updates to dax.txt documentation
These are originally from Matthew Wilcox and were part of his huge "mm,fs,dax: Change ->pmd_fault to ->huge_fault" patch that was part of PUD support. I'm breaking these small changes out as they stand on their own and add useful information to Documentation/filesystems/dax.txt. Signed-off-by: Ross Zwisler --- Documentation/filesystems/dax.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt index ce4587d..0c16a22 100644 --- a/Documentation/filesystems/dax.txt +++ b/Documentation/filesystems/dax.txt @@ -49,6 +49,7 @@ These block devices may be used for inspiration: - axonram: Axon DDR2 device driver - brd: RAM backed block device driver - dcssblk: s390 dcss block device driver +- pmem: NVDIMM persistent memory driver Implementation Tips for Filesystem Writers @@ -75,8 +76,9 @@ calls to get_block() (for example by a page-fault racing with a read() or a write()) work correctly. These filesystems may be used for inspiration: -- ext2: the second extended filesystem, see Documentation/filesystems/ext2.txt -- ext4: the fourth extended filesystem, see Documentation/filesystems/ext4.txt +- ext2: see Documentation/filesystems/ext2.txt +- ext4: see Documentation/filesystems/ext4.txt +- xfs: see Documentation/filesystems/xfs.txt Handling Media Errors -- 2.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] dax: remote unused fault wrappers
Remove the unused wrappers dax_fault() and dax_pmd_fault(). After this
removal, rename __dax_fault() and __dax_pmd_fault() to dax_fault() and
dax_pmd_fault() respectively, and update all callers.
The dax_fault() and dax_pmd_fault() wrappers were initially intended to
capture some filesystem independent functionality around page faults
(calling sb_start_pagefault() & sb_end_pagefault(), updating file
mtime and ctime). However, the following commits:
commit 5726b27b09cc ("ext2: Add locking for DAX faults")
commit ea3d7209ca01 ("ext4: fix races between page faults and hole punching")
Added locking to the ext2 and ext4 filesystems after these common
operations but before __dax_fault() and __dax_pmd_fault() were called.
This means that these wrappers are no longer used, and are unlikely to be
used in the future. XFS has had locking analogous to what was recently
added to ext2 and ext4 since DAX support was initially introduced by:
commit 6b698edeeef0 ("xfs: add DAX file operations support")
Signed-off-by: Ross Zwisler
---
fs/dax.c| 73 ++---
fs/ext2/file.c | 4 +--
fs/ext4/file.c | 4 +--
fs/xfs/xfs_file.c | 6 ++---
include/linux/dax.h | 5
5 files changed, 21 insertions(+), 71 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index e207f8f..432b9e6 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -819,16 +819,16 @@ static int dax_insert_mapping(struct address_space
*mapping,
}
/**
- * __dax_fault - handle a page fault on a DAX file
+ * dax_fault - handle a page fault on a DAX file
* @vma: The virtual memory area where the fault occurred
* @vmf: The description of the fault
* @get_block: The filesystem method used to translate file offsets to blocks
*
* When a page fault occurs, filesystems may call this helper in their
- * fault handler for DAX files. __dax_fault() assumes the caller has done all
+ * fault handler for DAX files. dax_fault() assumes the caller has done all
* the necessary locking for the page fault to proceed successfully.
*/
-int __dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
+int dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
get_block_t get_block)
{
struct file *file = vma->vm_file;
@@ -913,33 +913,6 @@ int __dax_fault(struct vm_area_struct *vma, struct
vm_fault *vmf,
return VM_FAULT_SIGBUS | major;
return VM_FAULT_NOPAGE | major;
}
-EXPORT_SYMBOL(__dax_fault);
-
-/**
- * dax_fault - handle a page fault on a DAX file
- * @vma: The virtual memory area where the fault occurred
- * @vmf: The description of the fault
- * @get_block: The filesystem method used to translate file offsets to blocks
- *
- * When a page fault occurs, filesystems may call this helper in their
- * fault handler for DAX files.
- */
-int dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
- get_block_t get_block)
-{
- int result;
- struct super_block *sb = file_inode(vma->vm_file)->i_sb;
-
- if (vmf->flags & FAULT_FLAG_WRITE) {
- sb_start_pagefault(sb);
- file_update_time(vma->vm_file);
- }
- result = __dax_fault(vma, vmf, get_block);
- if (vmf->flags & FAULT_FLAG_WRITE)
- sb_end_pagefault(sb);
-
- return result;
-}
EXPORT_SYMBOL_GPL(dax_fault);
#if defined(CONFIG_TRANSPARENT_HUGEPAGE)
@@ -967,7 +940,16 @@ static void __dax_dbg(struct buffer_head *bh, unsigned
long address,
#define dax_pmd_dbg(bh, address, reason) __dax_dbg(bh, address, reason,
"dax_pmd")
-int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address,
+/**
+ * dax_pmd_fault - handle a PMD fault on a DAX file
+ * @vma: The virtual memory area where the fault occurred
+ * @vmf: The description of the fault
+ * @get_block: The filesystem method used to translate file offsets to blocks
+ *
+ * When a page fault occurs, filesystems may call this helper in their
+ * pmd_fault handler for DAX files.
+ */
+int dax_pmd_fault(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmd, unsigned int flags, get_block_t get_block)
{
struct file *file = vma->vm_file;
@@ -1119,7 +1101,7 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned
long address,
*
* The PMD path doesn't have an equivalent to
* dax_pfn_mkwrite(), though, so for a read followed by a
-* write we traverse all the way through __dax_pmd_fault()
+* write we traverse all the way through dax_pmd_fault()
* twice. This means we can just skip inserting a radix tree
* entry completely on the initial read and just wait until
* the write to insert a dirty entry.
@@ -1148,33 +1130,6 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned
long address,
result = VM_FAULT_FALLBACK;
goto out;
}
-EXPORT_SYMBOL_GPL(__dax
Re: [PATCH v13 00/12] support "task_isolation" mode
On 7/14/2016 5:03 PM, Andy Lutomirski wrote:
On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf wrote:
Here is a respin of the task-isolation patch set. This primarily
reflects feedback from Frederic and Peter Z.
I still think this is the wrong approach, at least at this point. The
first step should be to instrument things if necessary and fix the
obvious cases where the kernel gets entered asynchronously.
Note, however, that the task_isolation_debug mode is a very convenient
way of discovering what is going on when things do go wrong for task isolation.
Only once
there's a credible reason to believe it can work well should any form
of strictness be applied.
I'm not sure what criteria you need for this, though. Certainly we've been
shipping our version of task isolation to customers since 2008, and there
are quite a few customer applications in production that are working well.
I'd argue that's a credible reason.
As an example, enough vmalloc/vfree activity will eventually cause
flush_tlb_kernel_range to be called and *boom*, there goes your shiny
production dataplane application.
Well, that's actually a refinement that I did not inflict on this patch series.
In our code base, we have a hook for kernel TLB flushes that defers such
flushes for cores that are running in userspace, because, after all, they
don't yet care about such flushes. Instead, we atomically set a flag that
is checked on entry to the kernel, and that causes the TLB flush to occur
at that point.
On very brief inspection, __kmem_cache_shutdown will be a problem on
some workloads as well.
That looks like it should be amenable to a version of the same fix I pushed
upstream in 5fbc461636c32efd ("mm: make lru_add_drain_all() selective").
You would basically check which cores have non-empty caches, and only
interrupt those cores. For extra credit, you empty the cache on your local cpu
when you are entering task isolation mode. Now you don't get interrupted.
To be fair, I've never seen this particular path cause an interruption. And I
think this speaks to the fact that there really can't be a black and white
decision about when you have removed enough possible interrupt paths.
It really does depend on what else is running on your machine in addition
to the task isolation code, and that will vary from application to application.
And, as the kernel evolves, new ways of interrupting task isolation cores
will get added and need to be dealt with. There really isn't a perfect time
you can wait for and then declare that all the asynchronous entry cases
have been dealt with and now things are safe for task isolation.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
