Re: ILP32 for ARM64 - testing with lmbench

2016-11-16 Thread Zhangjian (Bamvor) 

Hi, Maxim

On 2016/11/17 13:02, Maxim Kuvyrkov wrote:

Hi Bamvor,

I'm surprised that you see this much difference from ILP32 patches on SPEC 
CPU2006int at all.  The SPEC CPU2006 benchmarks spend almost no time in the 
kernel syscalls.  I can imagine memory, TLB, and cache handling in the kernel 
could affect CPU2006 benchmarks.  Do ILP32 patches touch code in those areas?

Other than that, it would be interesting to check what the variance is between 
the 3 iterations of benchmark runs.  Could you check what relative standard 
deviation is between the 3 iterations -- (STDEV(RUN1, RUN2, RUN3) / 
RUNselected)?

For reference, in my [non-ILP32] benchmarking I see 1.1% for 401.bzip2,  0.8% 
for 429.mcf, 0.2% for 456.hmmer, and 0.1% for 462.libquantum.

Here is my result:
ILP32_mergedILP32_unmerged
  401.bzip20.31%0.26%
  429.mcf  1.61%1.36%
  456.hmmer1.37%1.57%
  462.libquantum   0.29%0.28%

Regards

Bamvor



--
Maxim Kuvyrkov
www.linaro.org




On Nov 17, 2016, at 7:28 AM, Zhangjian (Bamvor)  
wrote:

Hi, all

I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively
and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found
that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is
enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer,
libquantum are the top four differences[1]. Note that bigger is better in
specint test.

In order to make sure the above results, I retest these four testcases in
reportable way(reference the command in the end). The result[2] show that
libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is in
significant.

The result of lmbench is not stable in my board. I plan to dig it later.

[1] The following test result is tested through --size=ref --iterations=3.
1.1 Test when aarch32_el0 is enabled.
   ILP32 disabledbase line
 400.perlbench100.00% 100%
 401.bzip2 99.35% 100%
 403.gcc  100.26% 100%
 429.mcf  102.75% 100%
 445.gobmk100.00% 100%
 456.hmmer 95.66% 100%
 458.sjeng100.00% 100%
 462.libquantum   100.00% 100%
 471.omnetpp  100.59% 100%
 473.astar 99.66% 100%
 483.xalancbmk 99.10% 100%

1.2 Test when aarch32_el0 is disabled
   ILP32 disabled base line
 400.perlbench100.22%  100%
 401.bzip2100.95%  100%
 403.gcc  100.20%  100%
 429.mcf  100.76%  100%
 445.gobmk100.36%  100%
 456.hmmer 97.94%  100%
 458.sjeng 99.73%  100%
 462.libquantum98.72%  100%
 471.omnetpp  100.86%  100%
 473.astar 99.15%  100%
 483.xalancbmk100.08%  100%

[2] The following test result is tested through: runspec --config=my.cfg 
--size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 mcf 
hmmer libquantum
2.1 Test when aarch32_el0 is enabled.
ILP32_enabled base line
 401.bzip2100.82%  100%
 429.mcf  100.18%  100%
 456.hmmer 99.64%  100%
 462.libquantum97.91%  100%

Regards

Bamvor

On 2016/10/28 20:46, Yury Norov wrote:

[Add Steve Ellcey, thanks for testing on ThunderX]

Lmbench-3.0-a9 testing is performed on ThunderX machine to check that
ILP32 series does not add performance regressions for LP64. Test
summary is in the table below. Our measurements doesn't show
significant performance regression of LP64 if ILP32 code is merged,
both enabled or disabled.

  ILP32 enabled   ILP32  disabled   Standard Kernel
null syscall   0.1066  0.11210.1121
  95.09%  100.00%

stat   1.3947  1.38141.3864
  100.60% 99.64%

fstat  0.4459  0.43440.4524
  98.56%  96.02%

open/close 4.0606  4.04114.0453
  100.38% 99.90%

read   0.4819  0.50140.5014
  96.11%  100.00%

Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX.
Other system details below.

Yury.

ubuntu@crb6:~$ uname -a
Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64

Re: ILP32 for ARM64 - testing with lmbench

2016-11-16 Thread Maxim Kuvyrkov 
Hi Bamvor,

I'm surprised that you see this much difference from ILP32 patches on SPEC 
CPU2006int at all.  The SPEC CPU2006 benchmarks spend almost no time in the 
kernel syscalls.  I can imagine memory, TLB, and cache handling in the kernel 
could affect CPU2006 benchmarks.  Do ILP32 patches touch code in those areas?

Other than that, it would be interesting to check what the variance is between 
the 3 iterations of benchmark runs.  Could you check what relative standard 
deviation is between the 3 iterations -- (STDEV(RUN1, RUN2, RUN3) / 
RUNselected)?

For reference, in my [non-ILP32] benchmarking I see 1.1% for 401.bzip2,  0.8% 
for 429.mcf, 0.2% for 456.hmmer, and 0.1% for 462.libquantum.

--
Maxim Kuvyrkov
www.linaro.org



> On Nov 17, 2016, at 7:28 AM, Zhangjian (Bamvor)  
> wrote:
> 
> Hi, all
> 
> I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively
> and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found
> that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is
> enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer,
> libquantum are the top four differences[1]. Note that bigger is better in
> specint test.
> 
> In order to make sure the above results, I retest these four testcases in
> reportable way(reference the command in the end). The result[2] show that
> libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is 
> in
> significant.
> 
> The result of lmbench is not stable in my board. I plan to dig it later.
> 
> [1] The following test result is tested through --size=ref --iterations=3.
> 1.1 Test when aarch32_el0 is enabled.
>ILP32 disabledbase line
>  400.perlbench100.00% 100%
>  401.bzip2 99.35% 100%
>  403.gcc  100.26% 100%
>  429.mcf  102.75% 100%
>  445.gobmk100.00% 100%
>  456.hmmer 95.66% 100%
>  458.sjeng100.00% 100%
>  462.libquantum   100.00% 100%
>  471.omnetpp  100.59% 100%
>  473.astar 99.66% 100%
>  483.xalancbmk 99.10% 100%
> 
> 1.2 Test when aarch32_el0 is disabled
>ILP32 disabled base line
>  400.perlbench100.22%  100%
>  401.bzip2100.95%  100%
>  403.gcc  100.20%  100%
>  429.mcf  100.76%  100%
>  445.gobmk100.36%  100%
>  456.hmmer 97.94%  100%
>  458.sjeng 99.73%  100%
>  462.libquantum98.72%  100%
>  471.omnetpp  100.86%  100%
>  473.astar 99.15%  100%
>  483.xalancbmk100.08%  100%
> 
> [2] The following test result is tested through: runspec --config=my.cfg 
> --size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 
> mcf hmmer libquantum
> 2.1 Test when aarch32_el0 is enabled.
> ILP32_enabled base line
>  401.bzip2100.82%  100%
>  429.mcf  100.18%  100%
>  456.hmmer 99.64%  100%
>  462.libquantum97.91%  100%
> 
> Regards
> 
> Bamvor
> 
> On 2016/10/28 20:46, Yury Norov wrote:
>> [Add Steve Ellcey, thanks for testing on ThunderX]
>> 
>> Lmbench-3.0-a9 testing is performed on ThunderX machine to check that
>> ILP32 series does not add performance regressions for LP64. Test
>> summary is in the table below. Our measurements doesn't show
>> significant performance regression of LP64 if ILP32 code is merged,
>> both enabled or disabled.
>> 
>>   ILP32 enabled   ILP32  disabled   Standard Kernel
>> null syscall   0.1066  0.11210.1121
>>   95.09%  100.00%
>> 
>> stat   1.3947  1.38141.3864
>>   100.60% 99.64%
>> 
>> fstat  0.4459  0.43440.4524
>>   98.56%  96.02%
>> 
>> open/close 4.0606  4.04114.0453
>>   100.38% 99.90%
>> 
>> read   0.4819  0.50140.5014
>>   96.11%  100.00%
>> 
>> Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX.
>> Other system details below.
>> 
>> Yury.
>> 
>> ubuntu@crb6:~$ uname -a
>> Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64 aarch64 
>> aarch64 GNU/Linux
>> 
>> ubuntu@crb6:~$ cat /proc/meminfo
>> MemTotal:   132011948 kB
>> MemFree:

Re: ILP32 for ARM64 - testing with lmbench

2016-11-16 Thread Zhangjian (Bamvor) 

Hi, all

I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively
and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found
that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is
enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer,
libquantum are the top four differences[1]. Note that bigger is better in
specint test.

In order to make sure the above results, I retest these four testcases in
reportable way(reference the command in the end). The result[2] show that
libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is in
significant.

The result of lmbench is not stable in my board. I plan to dig it later.

[1] The following test result is tested through --size=ref --iterations=3.
1.1 Test when aarch32_el0 is enabled.
ILP32 disabledbase line
  400.perlbench100.00% 100%
  401.bzip2 99.35% 100%
  403.gcc  100.26% 100%
  429.mcf  102.75% 100%
  445.gobmk100.00% 100%
  456.hmmer 95.66% 100%
  458.sjeng100.00% 100%
  462.libquantum   100.00% 100%
  471.omnetpp  100.59% 100%
  473.astar 99.66% 100%
  483.xalancbmk 99.10% 100%

1.2 Test when aarch32_el0 is disabled
ILP32 disabled base line
  400.perlbench100.22%  100%
  401.bzip2100.95%  100%
  403.gcc  100.20%  100%
  429.mcf  100.76%  100%
  445.gobmk100.36%  100%
  456.hmmer 97.94%  100%
  458.sjeng 99.73%  100%
  462.libquantum98.72%  100%
  471.omnetpp  100.86%  100%
  473.astar 99.15%  100%
  483.xalancbmk100.08%  100%

[2] The following test result is tested through: runspec --config=my.cfg 
--size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 mcf 
hmmer libquantum
2.1 Test when aarch32_el0 is enabled.
 ILP32_enabled base line
  401.bzip2100.82%  100%
  429.mcf  100.18%  100%
  456.hmmer 99.64%  100%
  462.libquantum97.91%  100%

Regards

Bamvor

On 2016/10/28 20:46, Yury Norov wrote:

[Add Steve Ellcey, thanks for testing on ThunderX]

Lmbench-3.0-a9 testing is performed on ThunderX machine to check that
ILP32 series does not add performance regressions for LP64. Test
summary is in the table below. Our measurements doesn't show
significant performance regression of LP64 if ILP32 code is merged,
both enabled or disabled.

   ILP32 enabled   ILP32  disabled   Standard Kernel
null syscall   0.1066  0.11210.1121
   95.09%  100.00%

stat   1.3947  1.38141.3864
   100.60% 99.64%

fstat  0.4459  0.43440.4524
   98.56%  96.02%

open/close 4.0606  4.04114.0453
   100.38% 99.90%

read   0.4819  0.50140.5014
   96.11%  100.00%

Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX.
Other system details below.

Yury.

ubuntu@crb6:~$ uname -a
Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64 aarch64 aarch64 
GNU/Linux

ubuntu@crb6:~$ cat /proc/meminfo
MemTotal:   132011948 kB
MemFree:131442672 kB
MemAvailable:   130695764 kB
Buffers:   15696 kB
Cached:88088 kB
SwapCached:0 kB
Active:82760 kB
Inactive:  41336 kB
Active(anon):  20880 kB
Inactive(anon): 8576 kB
Active(file):  61880 kB
Inactive(file):32760 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:  128920572 kB
SwapFree:   128920572 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 20544 kB
Mapped:19780 kB
Shmem:  9060 kB
Slab:  78804 kB
SReclaimable:  27372 kB
SUnreclaim:51432 kB
KernelStack:8336 kB
PageTables:  820 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:194926544 kB
Committed_AS: 256324 kB
VmallocTotal:   135290290112 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
AnonHugePages: 0 kB
ShmemHugePages:0 kB
ShmemPmdMapped:0 kB
CmaTotal:  0 kB

Целевые клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber: +79139230330 Telegram: +79139230330 Email: prodawez...@gmail.com

2016-11-16 Thread gioia.pl...@gmx.com 
Целевые клиентские базы Skype: prodawez390 Whatsapp: +79139230330 Viber:  
+79139230330 Telegram: +79139230330 Email: prodawez...@gmail.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

Re: [PATCH] parse-headers.pl: add documentation for this script

2016-11-16 Thread Mauro Carvalho Chehab 
Em Wed, 16 Nov 2016 16:35:24 -0700
Jonathan Corbet  escreveu:

> On Tue,  8 Nov 2016 06:27:08 -0200
> Mauro Carvalho Chehab  wrote:
> 
> > Provide a man page for parse-headers.pl, describing
> > how to use it.
> > 
> > The documentation on ReST format was generated via pod2rst:
> > 
> > http://search.cpan.org/~dowens/Pod-POM-View-Restructured-0.02/bin/pod2rst  
> 
> Gee, this is still sitting in my folder, somehow...:)  Sorry about that.

No problem!
> 
> Can I make one request?  I think this should be part of
> kernel-documentation rather than another top-level, standalone document.
> Any chance of doing that?

Yeah, sure!

I added it as a separate rst file due to to two reasons:

1) kernel-documentation.rst is becoming a big file with several different
stuff on it. IMHO, the best would be to create a directory for it,
add an index.rst on it, and split it into several files;

2) it is easier to call pod2rst to convert the perl POD documentation
into a separate rst file. Ok, I can always copy the content to some
other rst file, but it would be simpler to maintain as a separate .rst.

Provided that you're OK with the contents, I can put its contents
inside the kernel-documentation.rst. Yet, my preference would be to
break kernel-documentation.rst into separate files, like:

- kernel-documentation/index.rst
- kernel-documentation/sphinx.rst
- kernel-documentation/kernel-docs.rst
- kernel-documentation/parse-headers.rst

And add a kernel-documentation/conf.py, to allow building a PDF file
with it with SPHINXDIRS=kernel-documentation.

The side effect of such change is that we'll have a kernel-documentation.pdf
file and be able to build just this book in separate. Another advantage
is that we'll have one file per chapter, making easier to add new contents
to the book without touching on the other chapters.

What do you prefer?

Regards,
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

Re: [PATCH v3 6/6] [media] docs-rst: auto-generate PDF image files

2016-11-16 Thread Mauro Carvalho Chehab 
Em Wed, 16 Nov 2016 15:32:52 -0700
Jonathan Corbet  escreveu:

> On Mon, 14 Nov 2016 14:32:32 -0200
> Mauro Carvalho Chehab  wrote:
> 
> One nit...
> 
> > diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
> > index a7fb35291f6c..297b85c37ab9 100644
> > --- a/Documentation/media/Makefile
> > +++ b/Documentation/media/Makefile  
> 
> [...]
> 
> > +clean:
> > +   -rm $(IMGTGT) 2>/dev/null  
> 
> This puts out a failure message if those files aren't actually present.
> I'll tack on a patch adding "-f" there.

Sounds good to me.

> I can now build PDF files again!  That is a good thing.

Great!

> I do notice that it's kind of hard to *find* the PDF files among all the
> other cruft that the build process leaves there.  Assuming we actually
> want to keep that stuff around, maybe we could move the resulting PDF
> files into a separate "pdf" directory?

Agreed. Markus once mentioned that we could provide a Makefile for the
LaTeX handling, instead of letting Sphinx create its own, using something
like this, at the conf.py[1]. 

[1] https://lkml.org/lkml/2016/8/10/114

>From his e-mail:
"A good starting point might be to ship our own tex-Makefile:
 create a folder e.g. Documentation/sphinx-tex place your
 Makefile (a copy of Sphinx's Makefile) in. In conf.py set
 the 

  latex_additional_files = [
  "sphinx-text/Makefile"
  ]

In the sphinx-tex/Makefile set e.g.

  # Additional LaTeX options
  LATEXOPTS = -interaction=batchmode
  LATEX_ENV = max_print_line=120

  LATEX = $(LATEX_ENV) latex
  PDFLATEX = $(LATEX_ENV) pdflatex
  MAKEINDEX = $(LATEX_ENV) makeindex"

Perhaps we could do that, changing the %.pdf: %.tex target
to store the PDF files on a separate dir.

Btw, it also makes sense to do the same for html output, as Sphinx
build also keep some things that seem to be internal files together
with the html output, like:
Documentation/output/.buildinfo
Documentation/output/objects.inv
Documentation/output/.doctrees/

> 
> We're also not yet building all of the sub-books into PDF, will look into
> that.

You need to add a target for each book at the conf.py, and one conf.py
per sub-book, if you want to allow building them individually with
SPHINXDIRS. I'm wandering if is there a way to do it automatically.

> 
> Anyway, this series is applied, thanks!

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

Re: [PATCH] parse-headers.pl: add documentation for this script

2016-11-16 Thread Jonathan Corbet 
On Tue,  8 Nov 2016 06:27:08 -0200
Mauro Carvalho Chehab  wrote:

> Provide a man page for parse-headers.pl, describing
> how to use it.
> 
> The documentation on ReST format was generated via pod2rst:
>   
> http://search.cpan.org/~dowens/Pod-POM-View-Restructured-0.02/bin/pod2rst

Gee, this is still sitting in my folder, somehow...:)  Sorry about that.

Can I make one request?  I think this should be part of
kernel-documentation rather than another top-level, standalone document.
Any chance of doing that?

Thanks,

jon
--
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: [PATCH] kernel-doc: add support for one line inline struct member doc comments

2016-11-16 Thread Jonathan Corbet 
On Wed, 16 Nov 2016 17:26:16 +0200
Jani Nikula  wrote:

> Add support for one line inline comments:
> 
>   /**
>* struct foo - struct documentation
>*/
>   struct foo {
>   /** @bar: member documentation */
>   int bar;
>   };

Looks good, applied.

Thanks,

jon
--
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: [PATCH] docs/completion.txt: drop dangling reference to completions-design.txt

2016-11-16 Thread Jonathan Corbet 
On Tue, 15 Nov 2016 14:42:14 -0800
Brian Norris  wrote:

> Per the original author, the proposed document was never deemed
> necessary, and the important bits got merged into completion.txt. Let's
> just stop confusing readers by pointing at a nonexistent doc.

Makes sense, applied.

Thanks,

jon
--
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: [PATCH] Documentation: convert USB to new format

2016-11-16 Thread Jonathan Corbet 
On Mon, 14 Nov 2016 15:52:43 +0100
Oliver Neukum  wrote:

> This is a conversion of the USB documentation to the Sphinx format.
> No content was altered or reformatted.

Yay, another template file bites the dust.  Applied, thanks.

jon
--
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: [PATCH] Documentation: circular-buffers: use READ_ONCE()

2016-11-16 Thread Jonathan Corbet 
On Wed, 16 Nov 2016 11:12:49 +
Mark Rutland  wrote:

> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the circular buffer documentation uses the latter
> exclusively.
> 
> To point people in the right direction, and as a step towards the
> eventual removal of ACCESS_ONCE(), update the documentation to use
> READ_ONCE(), as ACCESS_ONCE() is only used in a reader context in the
> circular buffer documentation.

Applied to the docs tree, thanks.

jon
--
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: [PATCH] Documentation: atomic_ops: use {READ,WRITE}_ONCE()

2016-11-16 Thread Jonathan Corbet 
On Wed, 16 Nov 2016 11:13:59 +
Mark Rutland  wrote:

> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the atomic documentation uses the latter exclusively.
> 
> To point people in the right direction, and as a step towards the
> eventual removal of ACCESS_ONCE(), update the documentation to use the
> {READ,WRITE}_ONCE() macros as appropriate.

Applied to the docs tree, thanks.

jon
--
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] docs: Add more manuals to the PDF build

2016-11-16 Thread Jonathan Corbet 

There were a few manuals that weren't being built in PDF format, but
there's no reason not to...

Signed-off-by: Jonathan Corbet 
---
 Documentation/conf.py  | 6 ++
 Documentation/core-api/conf.py | 5 +
 Documentation/security/conf.py | 8 
 3 files changed, 19 insertions(+)
 create mode 100644 Documentation/security/conf.py

diff --git a/Documentation/conf.py b/Documentation/conf.py
index db78974aad26..ba38bcf485a9 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -342,6 +342,10 @@ if major == 1 and minor > 3:
 latex_documents = [
 ('admin-guide/index', 'linux-user.tex', 'Linux Kernel User Documentation',
  'The kernel development community', 'manual'),
+('core-api/index', 'core-api.tex', 'The kernel core API manual',
+ 'The kernel development community', 'manual'),
+('driver-api/index', 'driver-api.tex', 'The kernel driver API manual',
+ 'The kernel development community', 'manual'),
 ('kernel-documentation', 'kernel-documentation.tex', 'The Linux Kernel 
Documentation',
  'The kernel development community', 'manual'),
 ('process/index', 'development-process.tex', 'Linux Kernel Development 
Documentation',
@@ -350,6 +354,8 @@ latex_documents = [
  'The kernel development community', 'manual'),
 ('media/index', 'media.tex', 'Linux Media Subsystem Documentation',
  'The kernel development community', 'manual'),
+('security/index', 'security.tex', 'The kernel security subsystem manual',
+ 'The kernel development community', 'manual'),
 ]
 
 # The name of an image file (relative to this directory) to place at the top of
diff --git a/Documentation/core-api/conf.py b/Documentation/core-api/conf.py
index fed87ab7f486..db1f7659f3da 100644
--- a/Documentation/core-api/conf.py
+++ b/Documentation/core-api/conf.py
@@ -3,3 +3,8 @@
 project = "Core-API Documentation"
 
 tags.add("subproject")
+
+latex_documents = [
+('index', 'core-api.tex', project,
+ 'The kernel development community', 'manual'),
+]
diff --git a/Documentation/security/conf.py b/Documentation/security/conf.py
new file mode 100644
index ..472fc9a8eb67
--- /dev/null
+++ b/Documentation/security/conf.py
@@ -0,0 +1,8 @@
+project = "The kernel security subsystem manual"
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'security.tex', project,
+ 'The kernel development community', 'manual'),
+]
-- 
2.7.4

--
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: [PATCH v3 6/6] [media] docs-rst: auto-generate PDF image files

2016-11-16 Thread Jonathan Corbet 
On Mon, 14 Nov 2016 14:32:32 -0200
Mauro Carvalho Chehab  wrote:

One nit...

> diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
> index a7fb35291f6c..297b85c37ab9 100644
> --- a/Documentation/media/Makefile
> +++ b/Documentation/media/Makefile

[...]

> +clean:
> + -rm $(IMGTGT) 2>/dev/null

This puts out a failure message if those files aren't actually present.
I'll tack on a patch adding "-f" there.

I can now build PDF files again!  That is a good thing.

I do notice that it's kind of hard to *find* the PDF files among all the
other cruft that the build process leaves there.  Assuming we actually
want to keep that stuff around, maybe we could move the resulting PDF
files into a separate "pdf" directory?

We're also not yet building all of the sub-books into PDF, will look into
that.

Anyway, this series is applied, thanks!

jon
--
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: [Ksummit-discuss] Including images on Sphinx documents

2016-11-16 Thread Mauro Carvalho Chehab 
Hi Arnd,

Em Wed, 16 Nov 2016 17:03:47 +0100
Arnd Bergmann  escreveu:

> On Tuesday, November 8, 2016 8:50:36 AM CET Mauro Carvalho Chehab wrote:
> > It basically calls ImageMagick "convert" tool for all png and
> > pdf files currently at the documentation (they're all at media,
> > ATM).  
> 
> It looks like we still need to find a way to address the .gif files
> though, as they have the same problem as the .pdf files.

Actually, my last patch series removed all *.pdf images and converted
all .gif files under Documentation/media to PNG[1]. I also replaced some
images by .svg, but the remaining ones are more complex. I'm even not
sure if it makes sense to convert a few of them to vectorial graphics,
like on this case:
https://mchehab.fedorapeople.org/kernel_docs/media/_images/selection.png

>
> During the kernel summit, I looked around for any binary files in
> the kernel source tree, and except for the penguin logo, they are
> all in Documentation/media/uapi/v4l/, but they are not all pdf
> files, but also .png and .pdf.

>From what I understood from Linus, his problem is to carry on a
non-editable file at the Kernel tree. With that sense, a PNG file
is OK, as it is editable.

I had, in the past, problems with binary contents on either Mercurial
or git (before migrating to git, we used Mercurial for a while).
So, before Kernel 4.8, those .pdf, .png (and .gif) images were uuencoded,
in order to avoid troubles handling patches with them.

Nowadays, I don't see any issue handling binary images via e-mail or via git.

Btw, with that regards, SVG images are a lot worse to handle, as a single
line can easily have more than 998 characters, with makes some email
servers to reject patches with them. So, at the version 3 of my patch 
series, I had to use inkscape to ungroup some images, and to rewrite their
files, as otherwise, two patches were silently rejected by the VGER 
server.

[1] The reason to convert to PNG is that it means one less format to be
concerned with. Also, it doesn't make much sense to use two different
formats for bitmap images at the documentation.

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

Re: [RFC PATCH v3 08/20] x86: Add support for early encryption/decryption of memory

2016-11-16 Thread Tom Lendacky 
On 11/16/2016 4:46 AM, Borislav Petkov wrote:
> Btw, for your next submission, this patch can be split in two exactly
> like the commit message paragraphs are:

I think I originally had it that way, I don't know why I combined them.
I'll split them out.

> 
> On Wed, Nov 09, 2016 at 06:36:10PM -0600, Tom Lendacky wrote:
>> Add support to be able to either encrypt or decrypt data in place during
>> the early stages of booting the kernel. This does not change the memory
>> encryption attribute - it is used for ensuring that data present in either
>> an encrypted or un-encrypted memory area is in the proper state (for
>> example the initrd will have been loaded by the boot loader and will not be
>> encrypted, but the memory that it resides in is marked as encrypted).
> 
> Patch 2: users of the new memmap change
> 
>> The early_memmap support is enhanced to specify encrypted and un-encrypted
>> mappings with and without write-protection. The use of write-protection is
>> necessary when encrypting data "in place". The write-protect attribute is
>> considered cacheable for loads, but not stores. This implies that the
>> hardware will never give the core a dirty line with this memtype.
> 
> Patch 1: change memmap
> 
> This makes this aspect of the patchset much clearer and is better for
> bisection.
> 
>> Signed-off-by: Tom Lendacky 
>> ---
>>  arch/x86/include/asm/fixmap.h|9 +++
>>  arch/x86/include/asm/mem_encrypt.h   |   15 +
>>  arch/x86/include/asm/pgtable_types.h |8 +++
>>  arch/x86/mm/ioremap.c|   28 +
>>  arch/x86/mm/mem_encrypt.c|  102 
>> ++
>>  include/asm-generic/early_ioremap.h  |2 +
>>  mm/early_ioremap.c   |   15 +
>>  7 files changed, 179 insertions(+)
> 
> ...
> 
>> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
>> index d642cc5..06235b4 100644
>> --- a/arch/x86/mm/mem_encrypt.c
>> +++ b/arch/x86/mm/mem_encrypt.c
>> @@ -14,6 +14,9 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +#include 
>> +
>>  extern pmdval_t early_pmd_flags;
>>  
>>  /*
>> @@ -24,6 +27,105 @@ extern pmdval_t early_pmd_flags;
>>  unsigned long sme_me_mask __section(.data) = 0;
>>  EXPORT_SYMBOL_GPL(sme_me_mask);
>>  
>> +/* Buffer used for early in-place encryption by BSP, no locking needed */
>> +static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);
>> +
>> +/*
>> + * This routine does not change the underlying encryption setting of the
>> + * page(s) that map this memory. It assumes that eventually the memory is
>> + * meant to be accessed as encrypted but the contents are currently not
>> + * encrypted.
>> + */
>> +void __init sme_early_mem_enc(resource_size_t paddr, unsigned long size)
>> +{
>> +void *src, *dst;
>> +size_t len;
>> +
>> +if (!sme_me_mask)
>> +return;
>> +
>> +local_flush_tlb();
>> +wbinvd();
>> +
>> +/*
>> + * There are limited number of early mapping slots, so map (at most)
>> + * one page at time.
>> + */
>> +while (size) {
>> +len = min_t(size_t, sizeof(sme_early_buffer), size);
>> +
>> +/* Create a mapping for non-encrypted write-protected memory */
>> +src = early_memremap_dec_wp(paddr, len);
>> +
>> +/* Create a mapping for encrypted memory */
>> +dst = early_memremap_enc(paddr, len);
>> +
>> +/*
>> + * If a mapping can't be obtained to perform the encryption,
>> + * then encrypted access to that area will end up causing
>> + * a crash.
>> + */
>> +BUG_ON(!src || !dst);
>> +
>> +memcpy(sme_early_buffer, src, len);
>> +memcpy(dst, sme_early_buffer, len);
> 
> I still am missing the short explanation why we need the temporary buffer.

Ok, I'll add that.

> 
> 
> Oh, and we can save us the code duplication a little. Diff ontop of yours:

Yup, makes sense.  I'll incorporate this.

Thanks,
Tom

> 
> ---
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 06235b477d7c..50e2c4fc7338 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -36,7 +36,8 @@ static char sme_early_buffer[PAGE_SIZE] 
> __aligned(PAGE_SIZE);
>   * meant to be accessed as encrypted but the contents are currently not
>   * encrypted.
>   */
> -void __init sme_early_mem_enc(resource_size_t paddr, unsigned long size)
> +static void __init noinline
> +__mem_enc_dec(resource_size_t paddr, unsigned long size, bool enc)
>  {
>   void *src, *dst;
>   size_t len;
> @@ -54,15 +55,15 @@ void __init sme_early_mem_enc(resource_size_t paddr, 
> unsigned long size)
>   while (size) {
>   len = min_t(size_t, sizeof(sme_early_buffer), size);
>  
> - /* Create a mapping for non-encrypted write-protected memory */
> - src = early_memremap_dec_wp(paddr, len);
> + src = (enc

Re: [Ksummit-discuss] Including images on Sphinx documents

2016-11-16 Thread Arnd Bergmann 
On Tuesday, November 8, 2016 8:50:36 AM CET Mauro Carvalho Chehab wrote:
> > [...]
> > > And it may even require "--shell-escape" to be passed at the xelatex
> > > call if inkscape is not in the path, with seems to be a strong
> > > indication that SVG support is not native to texlive, but, instead,
> > > just a way to make LaTeX to call inkscape to do the image conversion.  
> > 
> > Please don't require --shell-escape as part of the TeX workflow.  If
> > LaTeX can't handle the desired image format natively, it needs
> > conversion in advance.
> 
> Agreed. I sent a patch series to linux-doc, doing the conversion in
> advance:
> https://marc.info/?l=linux-doc=147859902804144=2
> 
> Not sure why, but the archives don't have all patches yet.
> Anyway, the relevant one is this:
> 
> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=pdf-fixes=5d41c452c787f6a6c755a3855312435bc439acb8
> 
> It basically calls ImageMagick "convert" tool for all png and
> pdf files currently at the documentation (they're all at media,
> ATM).

It looks like we still need to find a way to address the .gif files
though, as they have the same problem as the .pdf files.

During the kernel summit, I looked around for any binary files in
the kernel source tree, and except for the penguin logo, they are
all in Documentation/media/uapi/v4l/, but they are not all pdf
files, but also .png and .pdf.

Arnd
--
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] kernel-doc: add support for one line inline struct member doc comments

2016-11-16 Thread Jani Nikula 
kernel-doc supports documenting struct members "inline" since
a4c6ebede2f9 ("scripts/kernel-doc Allow struct arguments documentation
in struct body"). This requires the inline kernel-doc comments to have
the opening and closing comment markers (/** and */ respectively) on
lines of their own, even for short comments. For example:

/**
 * struct foo - struct documentation
 */
struct foo {
/**
 * @bar: member documentation
 */
int bar;
};

Add support for one line inline comments:

/**
 * struct foo - struct documentation
 */
struct foo {
/** @bar: member documentation */
int bar;
};

Note that mixing of the two in one doc comment is not allowed; either
both comment markers must be on lines of their own, or both must be on
the one line. This limitation keeps both the comments more uniform, and
kernel-doc less complicated.

Cc: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 scripts/kernel-doc | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index e10378f769f9..030fc633acd4 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -421,6 +421,7 @@ my $doc_block = $doc_com . 'DOC:\s*(.*)?';
 my $doc_inline_start = '^\s*/\*\*\s*$';
 my $doc_inline_sect = '\s*\*\s*(@[\w\s]+):(.*)';
 my $doc_inline_end = '^\s*\*/\s*$';
+my $doc_inline_oneline = '^\s*/\*\*\s*(@[\w\s]+):\s*(.*)\s*\*/\s*$';
 my $export_symbol = '^\s*EXPORT_SYMBOL(_GPL)?\s*\(\s*(\w+)\s*\)\s*;';
 
 my %parameterdescs;
@@ -3024,7 +3025,16 @@ sub process_file($) {
}
}
} elsif ($state == STATE_PROTO) {   # scanning for function '{' 
(end of prototype)
-   if (/$doc_inline_start/) {
+   if (/$doc_inline_oneline/) {
+   $section = $1;
+   $contents = $2;
+   if ($contents ne "") {
+   $contents .= "\n";
+   dump_section($file, $section, xml_escape($contents));
+   $section = $section_default;
+   $contents = "";
+   }
+   } elsif (/$doc_inline_start/) {
$state = STATE_INLINE;
$inline_doc_state = STATE_INLINE_NAME;
} elsif ($decl_type eq 'function') {
-- 
2.1.4

--
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: [PATCH] Documentation: circular-buffers: use READ_ONCE()

2016-11-16 Thread Paul E. McKenney 
On Wed, Nov 16, 2016 at 11:12:49AM +, Mark Rutland wrote:
> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the circular buffer documentation uses the latter
> exclusively.
> 
> To point people in the right direction, and as a step towards the
> eventual removal of ACCESS_ONCE(), update the documentation to use
> READ_ONCE(), as ACCESS_ONCE() is only used in a reader context in the
> circular buffer documentation.
> 
> Signed-off-by: Mark Rutland 
> Cc: David Howells 
> Cc: Jonathan Corbet 
> Cc: Paul E. McKenney 
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org

Acked-by: Paul E. McKenney 

> ---
>  Documentation/circular-buffers.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/circular-buffers.txt 
> b/Documentation/circular-buffers.txt
> index 88951b1..4a824d2 100644
> --- a/Documentation/circular-buffers.txt
> +++ b/Documentation/circular-buffers.txt
> @@ -161,7 +161,7 @@ The producer will look something like this:
> 
>   unsigned long head = buffer->head;
>   /* The spin_unlock() and next spin_lock() provide needed ordering. */
> - unsigned long tail = ACCESS_ONCE(buffer->tail);
> + unsigned long tail = READ_ONCE(buffer->tail);
> 
>   if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
>   /* insert one item into the buffer */
> @@ -222,7 +222,7 @@ This will instruct the CPU to make sure the index is up 
> to date before reading
>  the new item, and then it shall make sure the CPU has finished reading the 
> item
>  before it writes the new tail pointer, which will erase the item.
> 
> -Note the use of ACCESS_ONCE() and smp_load_acquire() to read the
> +Note the use of READ_ONCE() and smp_load_acquire() to read the
>  opposition index.  This prevents the compiler from discarding and
>  reloading its cached value - which some compilers will do across
>  smp_read_barrier_depends().  This isn't strictly needed if you can
> -- 
> 1.9.1
> 

--
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: [PATCH] Documentation: atomic_ops: use {READ,WRITE}_ONCE()

2016-11-16 Thread Paul E. McKenney 
On Wed, Nov 16, 2016 at 11:13:59AM +, Mark Rutland wrote:
> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the atomic documentation uses the latter exclusively.
> 
> To point people in the right direction, and as a step towards the
> eventual removal of ACCESS_ONCE(), update the documentation to use the
> {READ,WRITE}_ONCE() macros as appropriate.
> 
> Signed-off-by: Mark Rutland 
> Cc: Boqun Feng 
> Cc: Jonathan Corbet 
> Cc: Paul E. McKenney 
> Cc: Peter Zijlstra 
> Cc: Will Deacon 
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org

Acked-by: Paul E. McKenney 

> ---
>  Documentation/atomic_ops.txt | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
> index c9d1cac..a1b9a54 100644
> --- a/Documentation/atomic_ops.txt
> +++ b/Documentation/atomic_ops.txt
> @@ -90,10 +90,10 @@ compiler optimizes the section accessing atomic_t 
> variables.
> 
>  Properly aligned pointers, longs, ints, and chars (and unsigned
>  equivalents) may be atomically loaded from and stored to in the same
> -sense as described for atomic_read() and atomic_set().  The ACCESS_ONCE()
> -macro should be used to prevent the compiler from using optimizations
> -that might otherwise optimize accesses out of existence on the one hand,
> -or that might create unsolicited accesses on the other.
> +sense as described for atomic_read() and atomic_set().  The READ_ONCE()
> +and WRITE_ONCE() macros should be used to prevent the compiler from using
> +optimizations that might otherwise optimize accesses out of existence on
> +the one hand, or that might create unsolicited accesses on the other.
> 
>  For example consider the following code:
> 
> @@ -112,7 +112,7 @@ the following:
>  If you don't want the compiler to do this (and you probably don't), then
>  you should use something like the following:
> 
> - while (ACCESS_ONCE(a) < 0)
> + while (READ_ONCE(a) < 0)
>   do_something();
> 
>  Alternatively, you could place a barrier() call in the loop.
> @@ -141,7 +141,7 @@ of registers: reloading from variable a could save a 
> flush to the
>  stack and later reload.  To prevent the compiler from attacking your
>  code in this manner, write the following:
> 
> - tmp_a = ACCESS_ONCE(a);
> + tmp_a = READ_ONCE(a);
>   do_something_with(tmp_a);
>   do_something_else_with(tmp_a);
> 
> @@ -166,14 +166,14 @@ that expected b to never have the value 42 if a was 
> zero.  To prevent
>  the compiler from doing this, write something like:
> 
>   if (a)
> - ACCESS_ONCE(b) = 9;
> + WRITE_ONCE(b, 9);
>   else
> - ACCESS_ONCE(b) = 42;
> + WRITE_ONCE(b, 42);
> 
>  Don't even -think- about doing this without proper use of memory barriers,
>  locks, or atomic operations if variable a can change at runtime!
> 
> -*** WARNING: ACCESS_ONCE() DOES NOT IMPLY A BARRIER! ***
> +*** WARNING: READ_ONCE() OR WRITE_ONCE() DO NOT IMPLY A BARRIER! ***
> 
>  Now, we move onto the atomic operation interfaces typically implemented with
>  the help of assembly code.
> -- 
> 1.9.1
> 

--
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: [PATCH] Documentation: circular-buffers: use READ_ONCE()

2016-11-16 Thread David Howells 
Mark Rutland  wrote:

> While the {READ,WRITE}_ONCE() macros should be used in preference to
> ACCESS_ONCE(), the circular buffer documentation uses the latter
> exclusively.
> 
> To point people in the right direction, and as a step towards the
> eventual removal of ACCESS_ONCE(), update the documentation to use
> READ_ONCE(), as ACCESS_ONCE() is only used in a reader context in the
> circular buffer documentation.
> 
> Signed-off-by: Mark Rutland 
> Cc: Jonathan Corbet 
> Cc: Paul E. McKenney 
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org

Acked-by: David Howells 
--
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: ILP32 for ARM64: testing with glibc testsuite

2016-11-16 Thread Maxim Kuvyrkov 
> On Nov 9, 2016, at 1:56 PM, Yury Norov  wrote:
> 
> On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote:
>> Hi all,
>> 
>> [add libc-alpha mail list]
>> 
>> For libc-alpha: this is the part of LKML submission with latest
>> patches for aarch64/ilp32.
>> https://www.spinics.net/lists/arm-kernel/msg537846.html
>> 
>> Glibc that I use has also included consolidation patches from Adhemerval
>> Zanella and me that are still not in the glibc master. The full series is:
>> https://github.com/norov/glibc/tree/ilp32-2.24-dev2
>> 
>> Below is the results of glibc testsuite run for aarch64/lp64
>> in different configurations. Column names meaning:
>> kvgv: kernel is vanilla, glibc is vanilla;
>> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config; 
>>  glibc is vanilla;
>> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is 
>> vanilla;
>> kege: kernel patches are applied and enabled, glibc patches are applied.
>> 
>> Only different lines are shown. Full results are in attached archive. 

Hi Yury,

The general requirement merging ILP32 glibc patches is that LP64 does not 
regress in any reasonable configuration.  This means that there should be 0 
regressions between kvgv and kvge -- i.e., glibc in LP64 mode with and without 
ILP32 patches does not regress on the vanilla kernel.  The kvge configuration 
is not in your testing matrix, and I suggest you make sure it has no 
regressions before fixing the more "advanced" configuration of kege.

Ideally, there should be no regressions between kvgv and kege configurations, 
but I don't consider this to a requirement for glibc acceptance of ILP32 
patches, since any regressions between kvge and kege configurations are likely 
to be on the kernel side.

Speculating on the kernel requirements for ILP32 kernel patchset, I think there 
should be 0 regressions between kvgv and kdgv configurations, where you have 
only 3 tests to investigate and fix.

[I do appreciate that there are progressions in your results as well, but the 
glibc policy is that they do not offset regressions.]

The above only concerns LP64 support in kernel and glibc.

Regarding ILP32 runtime, my opinion is that it is acceptable for ILP32 to have 
extra failures compared to LP64, since these are not regressions, but, rather, 
failures of a new configuration.  From a superficial glance is seems that ILP32 
linknamespace support requires attention, as well as stack unwinding (judging 
from NPTL failures).


--
Maxim Kuvyrkov
www.linaro.org



> 
> The same, plus ILP32 regressions:
> 
> Test  kvgvkdgvkegvkegeilp32
> conform/ISO/stdio.h/linknamespace PASSPASSPASSFAILFAIL
> conform/ISO11/stdio.h/linknamespace   PASSPASSPASSFAILFAIL
> conform/ISO99/stdio.h/linknamespace   PASSPASSPASSFAILFAIL
> conform/POSIX/stdio.h/linknamespace   PASSPASSPASSFAILFAIL
> conform/POSIX/sys/stat.h/linknamespacePASSPASSPASSFAIL
> FAIL
> conform/UNIX98/stdio.h/linknamespace  PASSPASSPASSFAILFAIL
> conform/XOPEN2K/stdio.h/linknamespace PASSPASSPASSFAILFAIL
> conform/XPG3/stdio.h/linknamespacePASSPASSPASSFAILFAIL
> conform/XPG4/stdio.h/linknamespacePASSPASSPASSFAILFAIL
> csu/tst-atomicPASSPASSPASSFAIL
> PASS
> elf/check-localpltPASSPASSPASSFAILFAIL
> iconvdata/mtrace-tst-loading  PASSFAILPASSPASSFAIL
> iconvdata/tst-loading PASSFAILPASSPASSPASS
> io/check-installed-headers-c  PASSPASSPASSFAILFAIL
> io/check-installed-headers-cxxPASSPASSPASSFAIL
> FAIL
> malloc/tst-malloc-backtrace   FAILPASSPASSPASSPASS
> malloc/tst-malloc-thread-exit FAILPASSPASSPASSPASS
> malloc/tst-malloc-usable  FAILPASSPASSPASSPASS
> malloc/tst-mallocfork FAILPASSPASSPASSPASS
> malloc/tst-mallocstateFAILPASSPASSPASS
> PASS
> malloc/tst-malloptFAILPASSPASSPASSPASS
> malloc/tst-mcheck FAILPASSPASSPASSPASS
> malloc/tst-memalign   FAILPASSPASSPASSPASS
> malloc/tst-obstackFAILPASSPASSPASSPASS
> malloc/tst-posix_memalign FAILPASSPASSPASSPASS
> malloc/tst-pvallocFAILPASSPASSPASSPASS
> malloc/tst-reallocFAILPASSPASSPASSPASS
> malloc/tst-scratch_buffer FAILPASSPASSPASSPASS
> malloc/tst-trim1  FAILPASSPASSPASSPASS
> nptl/tst-eintr4

[PATCH] Documentation: atomic_ops: use {READ,WRITE}_ONCE()

2016-11-16 Thread Mark Rutland 
While the {READ,WRITE}_ONCE() macros should be used in preference to
ACCESS_ONCE(), the atomic documentation uses the latter exclusively.

To point people in the right direction, and as a step towards the
eventual removal of ACCESS_ONCE(), update the documentation to use the
{READ,WRITE}_ONCE() macros as appropriate.

Signed-off-by: Mark Rutland 
Cc: Boqun Feng 
Cc: Jonathan Corbet 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 Documentation/atomic_ops.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index c9d1cac..a1b9a54 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -90,10 +90,10 @@ compiler optimizes the section accessing atomic_t variables.
 
 Properly aligned pointers, longs, ints, and chars (and unsigned
 equivalents) may be atomically loaded from and stored to in the same
-sense as described for atomic_read() and atomic_set().  The ACCESS_ONCE()
-macro should be used to prevent the compiler from using optimizations
-that might otherwise optimize accesses out of existence on the one hand,
-or that might create unsolicited accesses on the other.
+sense as described for atomic_read() and atomic_set().  The READ_ONCE()
+and WRITE_ONCE() macros should be used to prevent the compiler from using
+optimizations that might otherwise optimize accesses out of existence on
+the one hand, or that might create unsolicited accesses on the other.
 
 For example consider the following code:
 
@@ -112,7 +112,7 @@ the following:
 If you don't want the compiler to do this (and you probably don't), then
 you should use something like the following:
 
-   while (ACCESS_ONCE(a) < 0)
+   while (READ_ONCE(a) < 0)
do_something();
 
 Alternatively, you could place a barrier() call in the loop.
@@ -141,7 +141,7 @@ of registers: reloading from variable a could save a flush 
to the
 stack and later reload.  To prevent the compiler from attacking your
 code in this manner, write the following:
 
-   tmp_a = ACCESS_ONCE(a);
+   tmp_a = READ_ONCE(a);
do_something_with(tmp_a);
do_something_else_with(tmp_a);
 
@@ -166,14 +166,14 @@ that expected b to never have the value 42 if a was zero. 
 To prevent
 the compiler from doing this, write something like:
 
if (a)
-   ACCESS_ONCE(b) = 9;
+   WRITE_ONCE(b, 9);
else
-   ACCESS_ONCE(b) = 42;
+   WRITE_ONCE(b, 42);
 
 Don't even -think- about doing this without proper use of memory barriers,
 locks, or atomic operations if variable a can change at runtime!
 
-*** WARNING: ACCESS_ONCE() DOES NOT IMPLY A BARRIER! ***
+*** WARNING: READ_ONCE() OR WRITE_ONCE() DO NOT IMPLY A BARRIER! ***
 
 Now, we move onto the atomic operation interfaces typically implemented with
 the help of assembly code.
-- 
1.9.1

--
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] Documentation: circular-buffers: use READ_ONCE()

2016-11-16 Thread Mark Rutland 
While the {READ,WRITE}_ONCE() macros should be used in preference to
ACCESS_ONCE(), the circular buffer documentation uses the latter
exclusively.

To point people in the right direction, and as a step towards the
eventual removal of ACCESS_ONCE(), update the documentation to use
READ_ONCE(), as ACCESS_ONCE() is only used in a reader context in the
circular buffer documentation.

Signed-off-by: Mark Rutland 
Cc: David Howells 
Cc: Jonathan Corbet 
Cc: Paul E. McKenney 
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 Documentation/circular-buffers.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/circular-buffers.txt 
b/Documentation/circular-buffers.txt
index 88951b1..4a824d2 100644
--- a/Documentation/circular-buffers.txt
+++ b/Documentation/circular-buffers.txt
@@ -161,7 +161,7 @@ The producer will look something like this:
 
unsigned long head = buffer->head;
/* The spin_unlock() and next spin_lock() provide needed ordering. */
-   unsigned long tail = ACCESS_ONCE(buffer->tail);
+   unsigned long tail = READ_ONCE(buffer->tail);
 
if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
/* insert one item into the buffer */
@@ -222,7 +222,7 @@ This will instruct the CPU to make sure the index is up to 
date before reading
 the new item, and then it shall make sure the CPU has finished reading the item
 before it writes the new tail pointer, which will erase the item.
 
-Note the use of ACCESS_ONCE() and smp_load_acquire() to read the
+Note the use of READ_ONCE() and smp_load_acquire() to read the
 opposition index.  This prevents the compiler from discarding and
 reloading its cached value - which some compilers will do across
 smp_read_barrier_depends().  This isn't strictly needed if you can
-- 
1.9.1

--
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 PATCH v3 08/20] x86: Add support for early encryption/decryption of memory

2016-11-16 Thread Borislav Petkov 
Btw, for your next submission, this patch can be split in two exactly
like the commit message paragraphs are:

On Wed, Nov 09, 2016 at 06:36:10PM -0600, Tom Lendacky wrote:
> Add support to be able to either encrypt or decrypt data in place during
> the early stages of booting the kernel. This does not change the memory
> encryption attribute - it is used for ensuring that data present in either
> an encrypted or un-encrypted memory area is in the proper state (for
> example the initrd will have been loaded by the boot loader and will not be
> encrypted, but the memory that it resides in is marked as encrypted).

Patch 2: users of the new memmap change

> The early_memmap support is enhanced to specify encrypted and un-encrypted
> mappings with and without write-protection. The use of write-protection is
> necessary when encrypting data "in place". The write-protect attribute is
> considered cacheable for loads, but not stores. This implies that the
> hardware will never give the core a dirty line with this memtype.

Patch 1: change memmap

This makes this aspect of the patchset much clearer and is better for
bisection.

> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/fixmap.h|9 +++
>  arch/x86/include/asm/mem_encrypt.h   |   15 +
>  arch/x86/include/asm/pgtable_types.h |8 +++
>  arch/x86/mm/ioremap.c|   28 +
>  arch/x86/mm/mem_encrypt.c|  102 
> ++
>  include/asm-generic/early_ioremap.h  |2 +
>  mm/early_ioremap.c   |   15 +
>  7 files changed, 179 insertions(+)

...

> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index d642cc5..06235b4 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -14,6 +14,9 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +
>  extern pmdval_t early_pmd_flags;
>  
>  /*
> @@ -24,6 +27,105 @@ extern pmdval_t early_pmd_flags;
>  unsigned long sme_me_mask __section(.data) = 0;
>  EXPORT_SYMBOL_GPL(sme_me_mask);
>  
> +/* Buffer used for early in-place encryption by BSP, no locking needed */
> +static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);
> +
> +/*
> + * This routine does not change the underlying encryption setting of the
> + * page(s) that map this memory. It assumes that eventually the memory is
> + * meant to be accessed as encrypted but the contents are currently not
> + * encrypted.
> + */
> +void __init sme_early_mem_enc(resource_size_t paddr, unsigned long size)
> +{
> + void *src, *dst;
> + size_t len;
> +
> + if (!sme_me_mask)
> + return;
> +
> + local_flush_tlb();
> + wbinvd();
> +
> + /*
> +  * There are limited number of early mapping slots, so map (at most)
> +  * one page at time.
> +  */
> + while (size) {
> + len = min_t(size_t, sizeof(sme_early_buffer), size);
> +
> + /* Create a mapping for non-encrypted write-protected memory */
> + src = early_memremap_dec_wp(paddr, len);
> +
> + /* Create a mapping for encrypted memory */
> + dst = early_memremap_enc(paddr, len);
> +
> + /*
> +  * If a mapping can't be obtained to perform the encryption,
> +  * then encrypted access to that area will end up causing
> +  * a crash.
> +  */
> + BUG_ON(!src || !dst);
> +
> + memcpy(sme_early_buffer, src, len);
> + memcpy(dst, sme_early_buffer, len);

I still am missing the short explanation why we need the temporary buffer.


Oh, and we can save us the code duplication a little. Diff ontop of yours:

---
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 06235b477d7c..50e2c4fc7338 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -36,7 +36,8 @@ static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);
  * meant to be accessed as encrypted but the contents are currently not
  * encrypted.
  */
-void __init sme_early_mem_enc(resource_size_t paddr, unsigned long size)
+static void __init noinline
+__mem_enc_dec(resource_size_t paddr, unsigned long size, bool enc)
 {
void *src, *dst;
size_t len;
@@ -54,15 +55,15 @@ void __init sme_early_mem_enc(resource_size_t paddr, 
unsigned long size)
while (size) {
len = min_t(size_t, sizeof(sme_early_buffer), size);
 
-   /* Create a mapping for non-encrypted write-protected memory */
-   src = early_memremap_dec_wp(paddr, len);
+   src = (enc ? early_memremap_dec_wp(paddr, len)
+  : early_memremap_enc_wp(paddr, len));
 
-   /* Create a mapping for encrypted memory */
-   dst = early_memremap_enc(paddr, len);
+   dst = (enc ? early_memremap_enc(paddr, len)
+  : early_memremap_dec(paddr, len));