[PATCH v3] fscrypt: add a documentation file for filesystem-level encryption

[Eric Biggers]

From: Eric Biggers 

Perhaps long overdue, add a documentation file for filesystem-level
encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
directory.  The new file is based loosely on the latest version of the
"EXT4 Encryption Design Document (public version)" Google Doc, but with
many improvements made, including:

- Reflect the reality that it is not specific to ext4 anymore.
- More thoroughly document the design and user-visible API/behavior.
- Replace outdated information, such as the outdated explanation of how
  encrypted filenames are hashed for indexed directories and how
  encrypted filenames are presented to userspace without the key.
  (This was changed just before release.)

For now the focus is on the design and user-visible API/behavior, not on
how to add encryption support to a filesystem --- since the internal API
is still pretty messy and any standalone documentation for it would
become outdated as things get refactored over time.

Reviewed-by: Michael Halcrow 
Signed-off-by: Eric Biggers 
---

Changes since v2:
- A few tweaks to address comments from Michael Halcrow and Joe Richey.

Changes since v1:
- Mention that using existing userspace tools is preferred
- Don't start an argument about the best way to get random numbers
- Make it clear that backup/restore of encrypted files without key is
  not supported yet
- Mention a reason why the encryption xattr should not be exposed
  via the xattr system calls

 Documentation/filesystems/fscrypt.rst | 610 ++
 Documentation/filesystems/index.rst   |  11 +
 MAINTAINERS   |   1 +
 3 files changed, 622 insertions(+)
 create mode 100644 Documentation/filesystems/fscrypt.rst

diff --git a/Documentation/filesystems/fscrypt.rst 
b/Documentation/filesystems/fscrypt.rst
new file mode 100644
index ..776ddc655f79
--- /dev/null
+++ b/Documentation/filesystems/fscrypt.rst
@@ -0,0 +1,610 @@
+=
+Filesystem-level encryption (fscrypt)
+=
+
+Introduction
+
+
+fscrypt is a library which filesystems can hook into to support
+transparent encryption of files and directories.
+
+Note: "fscrypt" in this document refers to the kernel-level portion,
+implemented in ``fs/crypto/``, as opposed to the userspace tool
+`fscrypt `_.  This document only
+covers the kernel-level portion.  For command-line examples of how to
+use encryption, see the documentation for the userspace tool `fscrypt
+`_.  Also, it is recommended to use
+the fscrypt userspace tool, or other existing userspace tools such as
+`fscryptctl `_ or `Android's key
+management system
+`_, over
+using the kernel's API directly.  Using existing tools reduces the
+chance of introducing your own security bugs.  (Nevertheless, for
+completeness this documentation covers the kernel's API anyway.)
+
+Unlike dm-crypt, fscrypt operates at the filesystem level rather than
+at the block device level.  This allows it to encrypt different files
+with different keys and to have unencrypted files on the same
+filesystem.  This is useful for multi-user systems where each user's
+data-at-rest needs to be cryptographically isolated from the others.
+However, except for filenames, fscrypt does not encrypt filesystem
+metadata.
+
+Unlike eCryptfs, which is a stacked filesystem, fscrypt is integrated
+directly into supported filesystems --- currently ext4, F2FS, and
+UBIFS.  This allows encrypted files to be read and written without
+caching both the decrypted and encrypted pages in the pagecache,
+thereby nearly halving the memory used and bringing it in line with
+unencrypted files.  Similarly, half as many dentries and inodes are
+needed.  eCryptfs also limits encrypted filenames to 143 bytes,
+causing application compatibility issues; fscrypt allows the full 255
+bytes (NAME_MAX).  Finally, unlike eCryptfs, the fscrypt API can be
+used by unprivileged users, with no need to mount anything.
+
+fscrypt does not support encrypting files in-place.  Instead, it
+supports marking an empty directory as encrypted.  Then, after
+userspace provides the key, all regular files, directories, and
+symbolic links created in that directory tree are transparently
+encrypted.
+
+Threat model
+
+
+Offline attacks
+---
+
+Provided that userspace chooses a strong encryption key, fscrypt
+protects the confidentiality of file contents and filenames in the
+event of a single point-in-time permanent offline compromise of the
+block device content.  fscrypt does not protect the confidentiality of
+non-filename metadata, e.g. file sizes, file permissions, file
+timestamps, and extended attributes.  Also, the existence and location
+of holes 

[PATCH] docs: clean up and add rest of CRC functions to kernel-api.rst

[Randy Dunlap]

From: Randy Dunlap 

Add the rest of the CRC library functions to kernel-api.

- try to clarify crc32() by adding '@' to a function parameter
- reorder kernel-api CRC functions to be less random
- add more CRC functions to kernel-api
- correct the function parameter names in several places

Signed-off-by: Randy Dunlap 
---
 Documentation/core-api/kernel-api.rst |   10 --
 lib/crc32.c   |2 +-
 lib/crc4.c|2 +-
 lib/crc8.c|   22 +++---
 4 files changed, 21 insertions(+), 15 deletions(-)

--- lnx-413.orig/Documentation/core-api/kernel-api.rst
+++ lnx-413/Documentation/core-api/kernel-api.rst
@@ -70,13 +70,16 @@ Command-line Parsing
 CRC Functions
 -
 
+.. kernel-doc:: lib/crc4.c
+   :export:
+
 .. kernel-doc:: lib/crc7.c
:export:
 
-.. kernel-doc:: lib/crc16.c
+.. kernel-doc:: lib/crc8.c
:export:
 
-.. kernel-doc:: lib/crc-itu-t.c
+.. kernel-doc:: lib/crc16.c
:export:
 
 .. kernel-doc:: lib/crc32.c
@@ -84,6 +87,9 @@ CRC Functions
 .. kernel-doc:: lib/crc-ccitt.c
:export:
 
+.. kernel-doc:: lib/crc-itu-t.c
+   :export:
+
 idr/ida Functions
 -
 
--- lnx-413.orig/lib/crc32.c
+++ lnx-413/lib/crc32.c
@@ -225,7 +225,7 @@ static u32 __attribute_const__ gf2_multi
 }
 
 /**
- * crc32_generic_shift - Append len 0 bytes to crc, in logarithmic time
+ * crc32_generic_shift - Append @len 0 bytes to crc, in logarithmic time
  * @crc: The original little-endian CRC (i.e. lsbit is x^31 coefficient)
  * @len: The number of bytes. @crc is multiplied by x^(8*@len)
  * @polynomial: The modulus used to reduce the result to 32 bits.
--- lnx-413.orig/lib/crc8.c
+++ lnx-413/lib/crc8.c
@@ -20,11 +20,11 @@
 #include 
 #include 
 
-/*
+/**
  * crc8_populate_msb - fill crc table for given polynomial in reverse bit 
order.
  *
- * table:  table to be filled.
- * polynomial: polynomial for which table is to be filled.
+ * @table: table to be filled.
+ * @polynomial:polynomial for which table is to be filled.
  */
 void crc8_populate_msb(u8 table[CRC8_TABLE_SIZE], u8 polynomial)
 {
@@ -42,11 +42,11 @@ void crc8_populate_msb(u8 table[CRC8_TAB
 }
 EXPORT_SYMBOL(crc8_populate_msb);
 
-/*
+/**
  * crc8_populate_lsb - fill crc table for given polynomial in regular bit 
order.
  *
- * table:  table to be filled.
- * polynomial: polynomial for which table is to be filled.
+ * @table: table to be filled.
+ * @polynomial:polynomial for which table is to be filled.
  */
 void crc8_populate_lsb(u8 table[CRC8_TABLE_SIZE], u8 polynomial)
 {
@@ -63,13 +63,13 @@ void crc8_populate_lsb(u8 table[CRC8_TAB
 }
 EXPORT_SYMBOL(crc8_populate_lsb);
 
-/*
+/**
  * crc8 - calculate a crc8 over the given input data.
  *
- * table: crc table used for calculation.
- * pdata: pointer to data buffer.
- * nbytes: number of bytes in data buffer.
- * crc:previous returned crc8 value.
+ * @table: crc table used for calculation.
+ * @pdata: pointer to data buffer.
+ * @nbytes: number of bytes in data buffer.
+ * @crc: previous returned crc8 value.
  */
 u8 crc8(const u8 table[CRC8_TABLE_SIZE], u8 *pdata, size_t nbytes, u8 crc)
 {
--- lnx-413.orig/lib/crc4.c
+++ lnx-413/lib/crc4.c
@@ -15,7 +15,7 @@ static const uint8_t crc4_tab[] = {
 
 /**
  * crc4 - calculate the 4-bit crc of a value.
- * @crc:  starting crc4
+ * @c:starting crc4
  * @x:value to checksum
  * @bits: number of bits in @x to checksum
  *


--
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 0/3] kbuild: generate intermediate C files instead of copying _shipped files

[Linus Torvalds]

On Fri, Sep 8, 2017 at 11:39 AM, Linus Torvalds
 wrote:
>
> Strange. Does anybody see what the pattern to the failure is?

Found it. Stupid special case for 'typeof()' that used
is_reserved_word() in ways I hadn't realized.

Fix committed.

 Linus
--
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: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

[Christopher Lameter]

On Thu, 7 Sep 2017, David Rientjes wrote:

> > It has *nothing* to do with zillions of tasks. Its amusing that the SGI
> > ghost is still haunting the discussion here. The company died a couple of
> > years ago finally (ok somehow HP has an "SGI" brand now I believe). But
> > there are multiple companies that have large NUMA configurations and they
> > all have configurations where they want to restrict allocations of a
> > process to subset of system memory. This is even more important now that
> > we get new forms of memory (NVDIMM, PCI-E device memory etc). You need to
> > figure out what to do with allocations that fail because the *allowed*
> > memory pools are empty.
> >
>
> We already had CONSTRAINT_CPUSET at the time, this was requested by Paul
> and acked by him in https://marc.info/?l=linux-mm=118306851418425.

Ok. Certainly there were scalability issues (lots of them) and the sysctl
may have helped there if set globally. But the ability to kill the
allocating tasks was primarily used in cpusets for constrained allocation.

The issue of scaling is irrelevant in the context of deciding what to do
about the sysctl. You can address the issue differently if it still
exists. The systems with super high NUMA nodes (hundreds to a
thousand) have somehow fallen out of fashion a bit. So I doubt that this
is still an issue. And no one of the old stakeholders is speaking up.

What is the current approach for an OOM occuring in a cpuset or cgroup
with a restricted numa node set?
--
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 0/2] Two cleanups for Sphinx conf.py

[Mauro Carvalho Chehab]

Em Fri, 8 Sep 2017 10:10:26 -0600
Jonathan Corbet  escreveu:

> On Sun,  3 Sep 2017 16:12:44 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > Those patches are just cleanups for Documentation/conf.py. 
> > 
> > The first one removes a package usage directive for a LateX package
> > that it is not used. 
> > 
> > The second one moves some LaTeX preamble code that it is used only
> > on Sphinx 1.4 and 1.5 to a separate if. On Sphinx 1.6, the macros there
> > are silently ignored. While the conf.py becomes a little bit more complex,
> > it clearly marks the backward-compatible code, with IMHO, it is a
> > good idea, specially as some day, we may drop support for older Sphinx
> > versions.
> > 
> > None of those patches are mandatory. Feel free to apply any time you
> > want (or discard them, if you don't thing it is worth).  
> 
> OK, these are applied (and the adjustbox one too).

Thanks!
> 
> PDF generation seems to work pretty well at the moment, with one
> exception: I don't get a table of contents in any of the files (just a
> blank page saying "Contents").  Are you seeing something different?

That depends on the version. With Sphinx 1.4, the CONTENTS page is
filled with a LaTeX 1-depth ToC (e. g. 2 levels).

With Sphinx 1.6, the first time make pdfdocs is called, it doesn't
produce a CONTENTS page. It does if it is called twice.

I suspect that the difference here is that, with Sphinx up to
version 1.5, the Makefile created under Documentation/output/latex
calls xelatex several times:

%.pdf: %.tex
$(PDFLATEX) $(LATEXOPTS) '$<'
$(PDFLATEX) $(LATEXOPTS) '$<'
$(PDFLATEX) $(LATEXOPTS) '$<'
-$(MAKEINDEX) -s python.ist '$(basename $<).idx'
$(PDFLATEX) $(LATEXOPTS) '$<'
$(PDFLATEX) $(LATEXOPTS) '$<'



With Sphinx 1.6, it calls it only once:

%.pdf: %.tex FORCE_MAKE
$(PDFLATEX) $(LATEXMKOPTS) '$<'

That seems another regression on Sphinx 1.6.

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: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files

[Linus Torvalds]

On Fri, Sep 8, 2017 at 11:01 AM, Linus Torvalds
 wrote:
>
> It doesn't seem to happen for every exported symbol, though. Odd.

Fascinating.

Picking one file at random that shows this, I did net/ceph/mon_client.c.

The version file that gets generated for that looks like this:

__crc_ceph_monc_want_map = 0x3389a57e;
__crc_ceph_monc_got_map = 0x707f45a2;
__crc_ceph_monc_renew_subs = 0x9842030a;
__crc_ceph_monc_wait_osdmap = 0xfe38746d;
__crc_ceph_monc_open_session = 0xc9ba8a19;
__crc_ceph_monc_do_statfs = 0xe878801b;
__crc_ceph_monc_get_version = 0xfaac6ce0;
__crc_ceph_monc_get_version_async = 0x3adefe28;
__crc_ceph_monc_blacklist_add = 0xee71d0ef;
__crc_ceph_monc_init = 0xfce99654;
__crc_ceph_monc_stop = 0xb0d197d0;
__crc_ceph_monc_validate_auth = 0xce1c6d69;

and with the gperf-removal patch, it is 100% identical _except_ that
the "__crc_ceph_monc_do_statfs" line is missing.

Same hashes for everything else. But one missing line. WTF?

What is special about that one particular function vs the other ones
in that file? I have absolutely no idea.

So the really odd thing here is how things clearly still _work_. The
parser works fine for everything else. And looking at the
gprof-removal patch it's not at all obvious how everything could work
fine except for some random thing.

Strange. Does anybody see what the pattern to the failure is?

Linus
--
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 0/3] kbuild: generate intermediate C files instead of copying _shipped files

[Linus Torvalds]

On Fri, Sep 8, 2017 at 10:22 AM, Linus Torvalds
 wrote:
>
> Of course, I only did a "make allmodconfig" to test the MODVERSIONS
> case, I didn't actually install the modules. Is that error perhaps
> only detected at install time?

Oh, I take that back. I just got a ton of warnings with my
allmodconfig after doing a "git clean -dqfx".

So I guess there is a dependency issue - my normal build test after
the merge didn't show any issues, simply because the change in
ksymoops didn't actually cause the version information to be
re-generated.

It doesn't seem to happen for every exported symbol, though. Odd.

Looking at it, but not making sense of it yet.

Linus
--
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] drm/todo: Add s/dev_*/DRM_DEV_*/ coversion to TODO

[Sean Paul]

On Fri, Sep 8, 2017 at 10:32 AM, Sean Paul  wrote:
> Now that we have the DRM_DEV_* variants, we should use them.
>
> Signed-off-by: Sean Paul 


Applied to -misc-next with danvet's R-b.

Sean

> ---
>  Documentation/gpu/todo.rst | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 22af55d06ab8..e3b622094bf4 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -177,6 +177,17 @@ following drivers still use ``struct_mutex``: ``msm``, 
> ``omapdrm`` and
>
>  Contact: Daniel Vetter, respective driver maintainers
>
> +Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
> +
> +
> +For drivers which could have multiple instances, it is necessary to
> +differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
> +don't do this, drivers used dev_info/warn/err to make this differentiation. 
> We
> +now have DRM_DEV_* variants of the drm print macros, so we can start to 
> convert
> +those drivers back to using drm-formwatted specific log messages.
> +
> +Contact: Sean Paul, Maintainer of the driver you plan to convert
> +
>  Core refactorings
>  =
>
> --
> 2.14.1.581.gf28d330327-goog
>
--
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 0/3] kbuild: generate intermediate C files instead of copying _shipped files

[Linus Torvalds]

On Thu, Sep 7, 2017 at 11:18 PM, Masahiro Yamada
 wrote:
>
> If CONFIG_MODVERSIONS is enabled,
> I notice lots of error messages.
> WARNING: EXPORT symbol "finish_open" [vmlinux] version generation
> failed, symbol will not be versioned
>
> So, I think something was broken in scripts/genksyms/.
>
> Of course, it was a trivial conversion, so it should not be hard to fix...

Indeed, hopefully it would be trivial, but I don't even see the error here.

Of course, I only did a "make allmodconfig" to test the MODVERSIONS
case, I didn't actually install the modules. Is that error perhaps
only detected at install time?

I did build and install a kernel with that patch, but that's my actual
"real" config for the machine, and it didn't have MODVERSIONS enabled.

Oh, how I hate modversions. But I'll take a look if I can see what I
did wrong in the "Trivial and Obvious(tm)" conversion.

  Linus
--
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 1/2] kokr/doc: Update memory-barriers.txt for read-to-write dependencies

[Jonathan Corbet]

On Wed,  6 Sep 2017 17:25:30 +0900
SeongJae Park  wrote:

> This commit applies upstream change, commit 66ce3a4dcb9f ("doc: Update
> memory-barriers.txt for read-to-write dependencies") to Korean
> translation.

I've applied these two.

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 0/2] Two cleanups for Sphinx conf.py

[Jonathan Corbet]

On Sun,  3 Sep 2017 16:12:44 -0300
Mauro Carvalho Chehab  wrote:

> Those patches are just cleanups for Documentation/conf.py. 
> 
> The first one removes a package usage directive for a LateX package
> that it is not used. 
> 
> The second one moves some LaTeX preamble code that it is used only
> on Sphinx 1.4 and 1.5 to a separate if. On Sphinx 1.6, the macros there
> are silently ignored. While the conf.py becomes a little bit more complex,
> it clearly marks the backward-compatible code, with IMHO, it is a
> good idea, specially as some day, we may drop support for older Sphinx
> versions.
> 
> None of those patches are mandatory. Feel free to apply any time you
> want (or discard them, if you don't thing it is worth).

OK, these are applied (and the adjustbox one too).

PDF generation seems to work pretty well at the moment, with one
exception: I don't get a table of contents in any of the files (just a
blank page saying "Contents").  Are you seeing something different?

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] drm/todo: Add s/dev_*/DRM_DEV_*/ coversion to TODO

[Sean Paul]

On Fri, Sep 8, 2017 at 11:44 AM, Daniel Vetter  wrote:
> On Fri, Sep 08, 2017 at 10:32:07AM -0400, Sean Paul wrote:
>> Now that we have the DRM_DEV_* variants, we should use them.
>>
>> Signed-off-by: Sean Paul 
>
> I think that's fairly ideal fodder for outreachy, assume we make sure the
> driver maintainer is ok with the resulting torrent of patches first :-)

I'll happily review patches that convert rockchip.

Sean

> -Daniel
>
>> ---
>>  Documentation/gpu/todo.rst | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>> index 22af55d06ab8..e3b622094bf4 100644
>> --- a/Documentation/gpu/todo.rst
>> +++ b/Documentation/gpu/todo.rst
>> @@ -177,6 +177,17 @@ following drivers still use ``struct_mutex``: ``msm``, 
>> ``omapdrm`` and
>>
>>  Contact: Daniel Vetter, respective driver maintainers
>>
>> +Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
>> +
>> +
>> +For drivers which could have multiple instances, it is necessary to
>> +differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
>> +don't do this, drivers used dev_info/warn/err to make this differentiation. 
>> We
>> +now have DRM_DEV_* variants of the drm print macros, so we can start to 
>> convert
>> +those drivers back to using drm-formwatted specific log messages.
>> +
>> +Contact: Sean Paul, Maintainer of the driver you plan to convert
>> +
>>  Core refactorings
>>  =
>>
>> --
>> 2.14.1.581.gf28d330327-goog
>>
>> --
>> 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
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
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] drm/todo: Add s/dev_*/DRM_DEV_*/ coversion to TODO

[Daniel Vetter]

On Fri, Sep 08, 2017 at 10:32:07AM -0400, Sean Paul wrote:
> Now that we have the DRM_DEV_* variants, we should use them.
> 
> Signed-off-by: Sean Paul 

I think that's fairly ideal fodder for outreachy, assume we make sure the
driver maintainer is ok with the resulting torrent of patches first :-)
-Daniel

> ---
>  Documentation/gpu/todo.rst | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 22af55d06ab8..e3b622094bf4 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -177,6 +177,17 @@ following drivers still use ``struct_mutex``: ``msm``, 
> ``omapdrm`` and
>  
>  Contact: Daniel Vetter, respective driver maintainers
>  
> +Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
> +
> +
> +For drivers which could have multiple instances, it is necessary to
> +differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
> +don't do this, drivers used dev_info/warn/err to make this differentiation. 
> We
> +now have DRM_DEV_* variants of the drm print macros, so we can start to 
> convert
> +those drivers back to using drm-formwatted specific log messages.
> +
> +Contact: Sean Paul, Maintainer of the driver you plan to convert
> +
>  Core refactorings
>  =
>  
> -- 
> 2.14.1.581.gf28d330327-goog
> 
> --
> 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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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] drm/todo: Add s/dev_*/DRM_DEV_*/ coversion to TODO

[Sean Paul]

Now that we have the DRM_DEV_* variants, we should use them.

Signed-off-by: Sean Paul 
---
 Documentation/gpu/todo.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 22af55d06ab8..e3b622094bf4 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -177,6 +177,17 @@ following drivers still use ``struct_mutex``: ``msm``, 
``omapdrm`` and
 
 Contact: Daniel Vetter, respective driver maintainers
 
+Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
+
+
+For drivers which could have multiple instances, it is necessary to
+differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
+don't do this, drivers used dev_info/warn/err to make this differentiation. We
+now have DRM_DEV_* variants of the drm print macros, so we can start to convert
+those drivers back to using drm-formwatted specific log messages.
+
+Contact: Sean Paul, Maintainer of the driver you plan to convert
+
 Core refactorings
 =
 
-- 
2.14.1.581.gf28d330327-goog

--
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 v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Steven Sistare]

On 9/6/2017 6:32 PM, Pavel Machek wrote:
> On Tue 2017-09-05 14:44:56, David Miller wrote:
>> From: Pavel Machek 
>> Date: Mon, 4 Sep 2017 18:25:30 +0200
>>
>>> Will gcc be able to compile code that uses these automatically? That
>>> does not sound easy to me. Can libc automatically use this in malloc()
>>> to prevent accessing freed data when buffers are overrun?
>>>
>>> Is this for benefit of JITs?
>>
>> Anything that can control mappings and the virtual address used to
>> access memory can use ADI.
>>
>> malloc() is of course one such case.  It can map memory with ADI
>> enabled, and return buffer addresses to malloc() callers with the
>> proper virtual address bits set to satisfy the ADI key checks.
>>
>> And by induction anything using malloc() for it's memory allocation
>> gets ADI protection as well.
> 
> I see; that's actually quite a nice trick.
> 
> I guess it does not protect against stack-based overflows, but should
> help against heap-based overflows, so it improves security a bit, too.
> 
> Nice, thanks for explanation.

ADI can also be used to protect the stack.  Modify ADI versions for
a 64B aligned portion of the register save area in the kernel spill
and fill handlers,  and accidental or malicious access to the area 
from userland will trap.  Other data on the stack can be corrupted, 
but one cannot linearly overflow into the next stack frame without 
tripping over the ADI canary.  There are a few other details to handle,
such as setjmp/longjmp and JITs that modify the stack, but that is the gist.  
This is not part of the current patch, but has been implemented on
Solaris.

ADI could protect other data on the stack, but that requires 
compiler code generation changes.

- Steve
--
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 0/3] kbuild: generate intermediate C files instead of copying _shipped files

[Masahiro Yamada]

Hi Linus,


Very sorry that I had not responded quickly.

When I was digging into tool version dependency,
as you pointed out, gperf is a problem (but seemed one time breakage
for gperf 3.1)
flex seemed very stable for a long time.
bison seemed a bit problem if old version is used.


But, I did not have enough time to take a closer look.
I thought I should respond after I tested more, but I has been pressed
by my daily tasks, then time passed...
Very sorry.



Today, I just noticed gperf usage got dropped from the kernel.

If CONFIG_MODVERSIONS is enabled,
I notice lots of error messages.
WARNING: EXPORT symbol "finish_open" [vmlinux] version generation
failed, symbol will not be


So, I think something was broken in scripts/genksyms/.

Of course, it was a trivial conversion, so it should not be hard to fix...



> gperf is clearly written by clowns that don't understand about
> compatibility issues - it would have been trivial for them to add some
> kind of marker define so that you could test for this directly rather
> than depend on some kind of autoconf "try to build and see if it
> fails" crap.


One idea may be to process the output of "gperf -v"
and embed GPERF_VERSION into the output .c files.

But, if you are unhappy with gperf breakage this time,
we can live without gperf.




> It's likely not even any slower, but who the hell knows.. Do we even
> care? It's almost certainly faster if you compare to generating that
> gperf code.
>

For scripts/kconfig/, I think we do not care at all
because we usually invoke it just once when we configure the build setting.


If we enable CONFIG_MODVERSIONS, scripts/genksyms/ is invoked
over and over again.

Sorry, I have not evaluated if
the perfect hash gives us noticeable advantage or not..



-- 
Best Regards
Masahiro Yamada
--
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