Re: [PATCH] docs/core-api: make mm-api.rst more structured

[Jonathan Corbet]

On Wed, 28 Nov 2018 16:45:44 +0200
Mike Rapoport  wrote:

> The mm-api.rst covers variety of memory management APIs under "More Memory
> Management Functions" section. The descriptions included there are in a
> random order there are quite a few of them which makes the section too
> long.
> 
> Regrouping the documentation by subject and splitting the long "More Memory
> Management Functions" section into several smaller sections makes the
> generated html more usable.
> 
> Signed-off-by: Mike Rapoport 

Applied, thanks.

jon

Re: [PATCH v2 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

[David Hildenbrand]

On 06.12.18 01:26, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
> 
> Generally speaking, we leverage the two global lock:
> 
>   * device_hotplug_lock
>   * mem_hotplug_lock
> 
> to serialise the process.
> 
> While for the long term, we are willing to have more fine-grained lock
> to provide higher scalability.
> 
> This patch divides Locking Internal section based on these two global
> locks to help readers to understand it. Also it adds some new finding to
> enrich it.
> 
> [David: words arrangement]
> 
> Signed-off-by: Wei Yang 
> ---
> v2: adjustment based on David and Mike comment
> ---
>  Documentation/core-api/memory-hotplug.rst | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/core-api/memory-hotplug.rst 
> b/Documentation/core-api/memory-hotplug.rst
> index de7467e48067..51d477ad4b80 100644
> --- a/Documentation/core-api/memory-hotplug.rst
> +++ b/Documentation/core-api/memory-hotplug.rst
> @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification 
> queue.
>  Locking Internals
>  =
>  
> +In addition to fine grained locks like pgdat_resize_lock, there are three 
> locks
> +involved
> +
> +- device_hotplug_lock
> +- mem_hotplug_lock
> +- device_lock
> +
> +Currently, they are twisted together for all kinds of reasons. The following
> +part is divided into device_hotplug_lock and mem_hotplug_lock parts
> +respectively to describe those tricky situations.
> +
> +device_hotplug_lock
> +-
> +
>  When adding/removing memory that uses memory block devices (i.e. ordinary 
> RAM),
>  the device_hotplug_lock should be held to:
>  
> @@ -111,13 +125,20 @@ As the device is visible to user space before taking 
> the device_lock(), this
>  can result in a lock inversion.
>  
>  onlining/offlining of memory should be done via device_online()/
> -device_offline() - to make sure it is properly synchronized to actions
> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
> online_type)
> +device_offline() - to make sure it is properly synchronized to actions via
> +sysfs. Even if mem_hotplug_lock is used to protect the process, because of 
> the
> +lock inversion described above, holding device_hotplug_lock is still advised
> +(to e.g. protect online_type)
> +
> +mem_hotplug_lock
> +-
>  
>  When adding/removing/onlining/offlining memory or adding/removing
>  heterogeneous/device memory, we should always hold the mem_hotplug_lock in
>  write mode to serialise memory hotplug (e.g. access to global/zone
> -variables).
> +variables). Currently, we take advantage of this to serialise sparsemem's
> +mem_section handling in sparse_add_one_section() and
> +sparse_remove_one_section().
>  
>  In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
>  mode allows for a quite efficient get_online_mems/put_online_mems
> 

Reviewed-by: David Hildenbrand 

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

[Mike Rapoport]

On Thu, Dec 06, 2018 at 08:26:22AM +0800, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
> 
> Generally speaking, we leverage the two global lock:
> 
>   * device_hotplug_lock
>   * mem_hotplug_lock
> 
> to serialise the process.
> 
> While for the long term, we are willing to have more fine-grained lock
> to provide higher scalability.
> 
> This patch divides Locking Internal section based on these two global
> locks to help readers to understand it. Also it adds some new finding to
> enrich it.
> 
> [David: words arrangement]
> 
> Signed-off-by: Wei Yang 

Reviewd-by: Mike Rapoport 

> ---
> v2: adjustment based on David and Mike comment
> ---
>  Documentation/core-api/memory-hotplug.rst | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/core-api/memory-hotplug.rst 
> b/Documentation/core-api/memory-hotplug.rst
> index de7467e48067..51d477ad4b80 100644
> --- a/Documentation/core-api/memory-hotplug.rst
> +++ b/Documentation/core-api/memory-hotplug.rst
> @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification 
> queue.
>  Locking Internals
>  =
>  
> +In addition to fine grained locks like pgdat_resize_lock, there are three 
> locks
> +involved
> +
> +- device_hotplug_lock
> +- mem_hotplug_lock
> +- device_lock
> +
> +Currently, they are twisted together for all kinds of reasons. The following
> +part is divided into device_hotplug_lock and mem_hotplug_lock parts
> +respectively to describe those tricky situations.
> +
> +device_hotplug_lock
> +-
> +
>  When adding/removing memory that uses memory block devices (i.e. ordinary 
> RAM),
>  the device_hotplug_lock should be held to:
>  
> @@ -111,13 +125,20 @@ As the device is visible to user space before taking 
> the device_lock(), this
>  can result in a lock inversion.
>  
>  onlining/offlining of memory should be done via device_online()/
> -device_offline() - to make sure it is properly synchronized to actions
> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
> online_type)
> +device_offline() - to make sure it is properly synchronized to actions via
> +sysfs. Even if mem_hotplug_lock is used to protect the process, because of 
> the
> +lock inversion described above, holding device_hotplug_lock is still advised
> +(to e.g. protect online_type)
> +
> +mem_hotplug_lock
> +-
>  
>  When adding/removing/onlining/offlining memory or adding/removing
>  heterogeneous/device memory, we should always hold the mem_hotplug_lock in
>  write mode to serialise memory hotplug (e.g. access to global/zone
> -variables).
> +variables). Currently, we take advantage of this to serialise sparsemem's
> +mem_section handling in sparse_add_one_section() and
> +sparse_remove_one_section().
>  
>  In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
>  mode allows for a quite efficient get_online_mems/put_online_mems
> -- 
> 2.15.1
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

[Wei Yang]

On Wed, Dec 05, 2018 at 01:13:10PM +0100, Michal Hocko wrote:
>On Wed 05-12-18 10:34:26, Wei Yang wrote:
>> Currently locking for memory hotplug is a little complicated.
>> 
>> Generally speaking, we leverage the two global lock:
>> 
>>   * device_hotplug_lock
>>   * mem_hotplug_lock
>> 
>> to serialise the process.
>> 
>> While for the long term, we are willing to have more fine-grained lock
>> to provide higher scalability.
>> 
>> This patch divides Locking Internal section based on these two global
>> locks to help readers to understand it. Also it adds some new finding to
>> enrich it.
>> 
>> [David: words arrangement]
>> 
>> Signed-off-by: Wei Yang 
>
>For a love of mine I cannot find the locking description by Oscar. Maybe
>it never existed and I just made it up ;) But if it is not imaginary
>then my recollection is that it was much more comprehensive. If not then
>even this is a good start.

Thanks.

If Oscar has already has some work on it, this could be a complement to
his work :-)

>
>> ---
>>  Documentation/core-api/memory-hotplug.rst | 27 ---
>>  1 file changed, 24 insertions(+), 3 deletions(-)
>> 
>> diff --git a/Documentation/core-api/memory-hotplug.rst 
>> b/Documentation/core-api/memory-hotplug.rst
>> index de7467e48067..95662b283328 100644
>> --- a/Documentation/core-api/memory-hotplug.rst
>> +++ b/Documentation/core-api/memory-hotplug.rst
>> @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification 
>> queue.
>>  Locking Internals
>>  =
>>  
>> +There are three locks involved in memory-hotplug, two global lock and one 
>> local
>> +lock:
>> +
>> +- device_hotplug_lock
>> +- mem_hotplug_lock
>> +- device_lock
>> +
>> +Currently, they are twisted together for all kinds of reasons. The following
>> +part is divided into device_hotplug_lock and mem_hotplug_lock parts
>> +respectively to describe those tricky situations.
>> +
>> +device_hotplug_lock
>> +-
>> +
>>  When adding/removing memory that uses memory block devices (i.e. ordinary 
>> RAM),
>>  the device_hotplug_lock should be held to:
>>  
>> @@ -111,13 +125,20 @@ As the device is visible to user space before taking 
>> the device_lock(), this
>>  can result in a lock inversion.
>>  
>>  onlining/offlining of memory should be done via device_online()/
>> -device_offline() - to make sure it is properly synchronized to actions
>> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
>> online_type)
>> +device_offline() - to make sure it is properly synchronized to actions via
>> +sysfs. Even mem_hotplug_lock is used to protect the process, because of the
>> +lock inversion described above, holding device_hotplug_lock is still advised
>> +(to e.g. protect online_type)
>> +
>> +mem_hotplug_lock
>> +-
>>  
>>  When adding/removing/onlining/offlining memory or adding/removing
>>  heterogeneous/device memory, we should always hold the mem_hotplug_lock in
>>  write mode to serialise memory hotplug (e.g. access to global/zone
>> -variables).
>> +variables). Currently, we take advantage of this to serialise sparsemem's
>> +mem_section handling in sparse_add_one_section() and
>> +sparse_remove_one_section().
>>  
>>  In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
>>  mode allows for a quite efficient get_online_mems/put_online_mems
>> -- 
>> 2.15.1
>> 
>
>-- 
>Michal Hocko
>SUSE Labs

-- 
Wei Yang
Help you, Help me

Re: [PATCH 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

[Michal Hocko]

On Wed 05-12-18 10:34:26, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
> 
> Generally speaking, we leverage the two global lock:
> 
>   * device_hotplug_lock
>   * mem_hotplug_lock
> 
> to serialise the process.
> 
> While for the long term, we are willing to have more fine-grained lock
> to provide higher scalability.
> 
> This patch divides Locking Internal section based on these two global
> locks to help readers to understand it. Also it adds some new finding to
> enrich it.
> 
> [David: words arrangement]
> 
> Signed-off-by: Wei Yang 

For a love of mine I cannot find the locking description by Oscar. Maybe
it never existed and I just made it up ;) But if it is not imaginary
then my recollection is that it was much more comprehensive. If not then
even this is a good start.

> ---
>  Documentation/core-api/memory-hotplug.rst | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/core-api/memory-hotplug.rst 
> b/Documentation/core-api/memory-hotplug.rst
> index de7467e48067..95662b283328 100644
> --- a/Documentation/core-api/memory-hotplug.rst
> +++ b/Documentation/core-api/memory-hotplug.rst
> @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification 
> queue.
>  Locking Internals
>  =
>  
> +There are three locks involved in memory-hotplug, two global lock and one 
> local
> +lock:
> +
> +- device_hotplug_lock
> +- mem_hotplug_lock
> +- device_lock
> +
> +Currently, they are twisted together for all kinds of reasons. The following
> +part is divided into device_hotplug_lock and mem_hotplug_lock parts
> +respectively to describe those tricky situations.
> +
> +device_hotplug_lock
> +-
> +
>  When adding/removing memory that uses memory block devices (i.e. ordinary 
> RAM),
>  the device_hotplug_lock should be held to:
>  
> @@ -111,13 +125,20 @@ As the device is visible to user space before taking 
> the device_lock(), this
>  can result in a lock inversion.
>  
>  onlining/offlining of memory should be done via device_online()/
> -device_offline() - to make sure it is properly synchronized to actions
> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
> online_type)
> +device_offline() - to make sure it is properly synchronized to actions via
> +sysfs. Even mem_hotplug_lock is used to protect the process, because of the
> +lock inversion described above, holding device_hotplug_lock is still advised
> +(to e.g. protect online_type)
> +
> +mem_hotplug_lock
> +-
>  
>  When adding/removing/onlining/offlining memory or adding/removing
>  heterogeneous/device memory, we should always hold the mem_hotplug_lock in
>  write mode to serialise memory hotplug (e.g. access to global/zone
> -variables).
> +variables). Currently, we take advantage of this to serialise sparsemem's
> +mem_section handling in sparse_add_one_section() and
> +sparse_remove_one_section().
>  
>  In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
>  mode allows for a quite efficient get_online_mems/put_online_mems
> -- 
> 2.15.1
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/2] admin-guide/memory-hotplug.rst: remove locking internal part from admin-guide

[Michal Hocko]

On Wed 05-12-18 10:34:25, Wei Yang wrote:
> Locking Internal section exists in core-api documentation, which is more
> suitable for this.
> 
> This patch removes the duplication part here.
> 
> Signed-off-by: Wei Yang 

Yes this doesn't really make any sense in an admin guide. It is a pure
implementation detail nobody should be relying on.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

[Wei Yang]

On Wed, Dec 05, 2018 at 10:40:45AM +0200, Mike Rapoport wrote:
>On Wed, Dec 05, 2018 at 10:34:26AM +0800, Wei Yang wrote:
>> Currently locking for memory hotplug is a little complicated.
>> 
>> Generally speaking, we leverage the two global lock:
>> 
>>   * device_hotplug_lock
>>   * mem_hotplug_lock
>> 
>> to serialise the process.
>> 
>> While for the long term, we are willing to have more fine-grained lock
>> to provide higher scalability.
>> 
>> This patch divides Locking Internal section based on these two global
>> locks to help readers to understand it. Also it adds some new finding to
>> enrich it.
>> 
>> [David: words arrangement]
>> 
>> Signed-off-by: Wei Yang 
>> ---
>>  Documentation/core-api/memory-hotplug.rst | 27 ---
>>  1 file changed, 24 insertions(+), 3 deletions(-)
>> 
>> diff --git a/Documentation/core-api/memory-hotplug.rst 
>> b/Documentation/core-api/memory-hotplug.rst
>> index de7467e48067..95662b283328 100644
>> --- a/Documentation/core-api/memory-hotplug.rst
>> +++ b/Documentation/core-api/memory-hotplug.rst
>> @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification 
>> queue.
>>  Locking Internals
>>  =
>> 
>> +There are three locks involved in memory-hotplug, two global lock and one 
>> local
>
>typo:  ^locks
>

Thanks :-)

>> +lock:
>> +
>> +- device_hotplug_lock
>> +- mem_hotplug_lock
>> +- device_lock
>> +
>> +Currently, they are twisted together for all kinds of reasons. The following
>> +part is divided into device_hotplug_lock and mem_hotplug_lock parts
>> +respectively to describe those tricky situations.
>> +
>> +device_hotplug_lock
>> +-
>> +
>>  When adding/removing memory that uses memory block devices (i.e. ordinary 
>> RAM),
>>  the device_hotplug_lock should be held to:
>> 
>> @@ -111,13 +125,20 @@ As the device is visible to user space before taking 
>> the device_lock(), this
>>  can result in a lock inversion.
>> 
>>  onlining/offlining of memory should be done via device_online()/
>> -device_offline() - to make sure it is properly synchronized to actions
>> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
>> online_type)
>> +device_offline() - to make sure it is properly synchronized to actions via
>> +sysfs. Even mem_hotplug_lock is used to protect the process, because of the
>
>I think it should be "Even if mem_hotplug_lock ..."
>

Ah, my poor English, will fix it in next version. :-)

>> +lock inversion described above, holding device_hotplug_lock is still advised
>> +(to e.g. protect online_type)
>> +
>> +mem_hotplug_lock
>> +-
>> 
>>  When adding/removing/onlining/offlining memory or adding/removing
>>  heterogeneous/device memory, we should always hold the mem_hotplug_lock in
>>  write mode to serialise memory hotplug (e.g. access to global/zone
>> -variables).
>> +variables). Currently, we take advantage of this to serialise sparsemem's
>> +mem_section handling in sparse_add_one_section() and
>> +sparse_remove_one_section().
>> 
>>  In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
>>  mode allows for a quite efficient get_online_mems/put_online_mems
>> -- 
>> 2.15.1
>> 
>
>-- 
>Sincerely yours,
>Mike.

-- 
Wei Yang
Help you, Help me

Re: [PATCH 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

[Wei Yang]

On Wed, Dec 05, 2018 at 09:08:47AM +0100, David Hildenbrand wrote:
>On 05.12.18 03:34, Wei Yang wrote:
>> Currently locking for memory hotplug is a little complicated.
>> 
>> Generally speaking, we leverage the two global lock:
>> 
>>   * device_hotplug_lock
>>   * mem_hotplug_lock
>> 
>> to serialise the process.
>> 
>> While for the long term, we are willing to have more fine-grained lock
>> to provide higher scalability.
>> 
>> This patch divides Locking Internal section based on these two global
>> locks to help readers to understand it. Also it adds some new finding to
>> enrich it.
>> 
>> [David: words arrangement]
>> 
>> Signed-off-by: Wei Yang 
>> ---
>>  Documentation/core-api/memory-hotplug.rst | 27 ---
>>  1 file changed, 24 insertions(+), 3 deletions(-)
>> 
>> diff --git a/Documentation/core-api/memory-hotplug.rst 
>> b/Documentation/core-api/memory-hotplug.rst
>> index de7467e48067..95662b283328 100644
>> --- a/Documentation/core-api/memory-hotplug.rst
>> +++ b/Documentation/core-api/memory-hotplug.rst
>> @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification 
>> queue.
>>  Locking Internals
>>  =
>>  
>> +There are three locks involved in memory-hotplug, two global lock and one 
>> local
>> +lock:
>> +
>> +- device_hotplug_lock
>> +- mem_hotplug_lock
>> +- device_lock
>> +
>
>Do we really only ever use these three and not anything else when
>adding/removing/onlining/offlining memory?
>
>(I am thinking e.g. about pgdat_resize_lock)

Yes there are more than those three, pgdat_resize_lock is one of them.

>
>If so, you should phrase that maybe more generally Or add more details :)

Yep, while I don't get a whole picture about the pgdat_resize_lock. The
usage of this lock scatter in many places.

>
>"In addition to fine grained locks like pgdat_resize_lock, there are
>three locks involved ..."
>

Sounds better :-)

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] admin-guide/memory-hotplug.rst: remove locking internal part from admin-guide

[Wei Yang]

On Wed, Dec 05, 2018 at 10:30:13AM +0200, Mike Rapoport wrote:
>On Wed, Dec 05, 2018 at 09:03:24AM +0100, David Hildenbrand wrote:
>> On 05.12.18 03:34, Wei Yang wrote:
>> > Locking Internal section exists in core-api documentation, which is more
>> > suitable for this.
>> > 
>> > This patch removes the duplication part here.
>> > 
>> > Signed-off-by: Wei Yang 
>> > ---
>> >  Documentation/admin-guide/mm/memory-hotplug.rst | 40 
>> > -
>> >  1 file changed, 40 deletions(-)
>> > 
>> > diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst 
>> > b/Documentation/admin-guide/mm/memory-hotplug.rst
>> > index 5c4432c96c4b..241f4ce1e387 100644
>> > --- a/Documentation/admin-guide/mm/memory-hotplug.rst
>> > +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
>> > @@ -392,46 +392,6 @@ Need more implementation yet
>> >   - Notification completion of remove works by OS to firmware.
>> >   - Guard from remove if not yet.
>
>[ ... ]
>
>> >  Future Work
>> >  ===
>> >  
>> > 
>> 
>> I reported this yesterday to Jonathan and Mike
>> 
>> https://lkml.org/lkml/2018/12/3/340
>
>Somehow I've missed it...
> 
>> Anyhow
>> 
>> Reviewed-by: David Hildenbrand 
>
>Acked-by: Mike Rapoport 
>

Thanks :-)

>> 
>> -- 
>> 
>> Thanks,
>> 
>> David / dhildenb
>> 
>
>-- 
>Sincerely yours,
>Mike.

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] admin-guide/memory-hotplug.rst: remove locking internal part from admin-guide

[Wei Yang]

On Wed, Dec 05, 2018 at 09:03:24AM +0100, David Hildenbrand wrote:
>On 05.12.18 03:34, Wei Yang wrote:
>> Locking Internal section exists in core-api documentation, which is more
>> suitable for this.
>> 
>> This patch removes the duplication part here.
>> 
>> Signed-off-by: Wei Yang 
>> ---
>>  Documentation/admin-guide/mm/memory-hotplug.rst | 40 
>> -
>>  1 file changed, 40 deletions(-)
>> 
>> diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst 
>> b/Documentation/admin-guide/mm/memory-hotplug.rst
>> index 5c4432c96c4b..241f4ce1e387 100644
>> --- a/Documentation/admin-guide/mm/memory-hotplug.rst
>> +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
>> @@ -392,46 +392,6 @@ Need more implementation yet
>>   - Notification completion of remove works by OS to firmware.
>>   - Guard from remove if not yet.
>>  
>> -
>> -Locking Internals
>> -=
>> -
>> -When adding/removing memory that uses memory block devices (i.e. ordinary 
>> RAM),
>> -the device_hotplug_lock should be held to:
>> -
>> -- synchronize against online/offline requests (e.g. via sysfs). This way, 
>> memory
>> -  block devices can only be accessed (.online/.state attributes) by user
>> -  space once memory has been fully added. And when removing memory, we
>> -  know nobody is in critical sections.
>> -- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and 
>> PPC)
>> -
>> -Especially, there is a possible lock inversion that is avoided using
>> -device_hotplug_lock when adding memory and user space tries to online that
>> -memory faster than expected:
>> -
>> -- device_online() will first take the device_lock(), followed by
>> -  mem_hotplug_lock
>> -- add_memory_resource() will first take the mem_hotplug_lock, followed by
>> -  the device_lock() (while creating the devices, during bus_add_device()).
>> -
>> -As the device is visible to user space before taking the device_lock(), this
>> -can result in a lock inversion.
>> -
>> -onlining/offlining of memory should be done via device_online()/
>> -device_offline() - to make sure it is properly synchronized to actions
>> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
>> online_type)
>> -
>> -When adding/removing/onlining/offlining memory or adding/removing
>> -heterogeneous/device memory, we should always hold the mem_hotplug_lock in
>> -write mode to serialise memory hotplug (e.g. access to global/zone
>> -variables).
>> -
>> -In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
>> -mode allows for a quite efficient get_online_mems/put_online_mems
>> -implementation, so code accessing memory can protect from that memory
>> -vanishing.
>> -
>> -
>>  Future Work
>>  ===
>>  
>> 
>
>I reported this yesterday to Jonathan and Mike
>
>https://lkml.org/lkml/2018/12/3/340
>

Ah, Thanks :-)

>
>Anyhow
>
>Reviewed-by: David Hildenbrand 
>
>-- 
>
>Thanks,
>
>David / dhildenb

-- 
Wei Yang
Help you, Help me

Re: [PATCH 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

[Mike Rapoport]

On Wed, Dec 05, 2018 at 10:34:26AM +0800, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
> 
> Generally speaking, we leverage the two global lock:
> 
>   * device_hotplug_lock
>   * mem_hotplug_lock
> 
> to serialise the process.
> 
> While for the long term, we are willing to have more fine-grained lock
> to provide higher scalability.
> 
> This patch divides Locking Internal section based on these two global
> locks to help readers to understand it. Also it adds some new finding to
> enrich it.
> 
> [David: words arrangement]
> 
> Signed-off-by: Wei Yang 
> ---
>  Documentation/core-api/memory-hotplug.rst | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/core-api/memory-hotplug.rst 
> b/Documentation/core-api/memory-hotplug.rst
> index de7467e48067..95662b283328 100644
> --- a/Documentation/core-api/memory-hotplug.rst
> +++ b/Documentation/core-api/memory-hotplug.rst
> @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification 
> queue.
>  Locking Internals
>  =
> 
> +There are three locks involved in memory-hotplug, two global lock and one 
> local

typo:  ^locks

> +lock:
> +
> +- device_hotplug_lock
> +- mem_hotplug_lock
> +- device_lock
> +
> +Currently, they are twisted together for all kinds of reasons. The following
> +part is divided into device_hotplug_lock and mem_hotplug_lock parts
> +respectively to describe those tricky situations.
> +
> +device_hotplug_lock
> +-
> +
>  When adding/removing memory that uses memory block devices (i.e. ordinary 
> RAM),
>  the device_hotplug_lock should be held to:
> 
> @@ -111,13 +125,20 @@ As the device is visible to user space before taking 
> the device_lock(), this
>  can result in a lock inversion.
> 
>  onlining/offlining of memory should be done via device_online()/
> -device_offline() - to make sure it is properly synchronized to actions
> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
> online_type)
> +device_offline() - to make sure it is properly synchronized to actions via
> +sysfs. Even mem_hotplug_lock is used to protect the process, because of the

I think it should be "Even if mem_hotplug_lock ..."

> +lock inversion described above, holding device_hotplug_lock is still advised
> +(to e.g. protect online_type)
> +
> +mem_hotplug_lock
> +-
> 
>  When adding/removing/onlining/offlining memory or adding/removing
>  heterogeneous/device memory, we should always hold the mem_hotplug_lock in
>  write mode to serialise memory hotplug (e.g. access to global/zone
> -variables).
> +variables). Currently, we take advantage of this to serialise sparsemem's
> +mem_section handling in sparse_add_one_section() and
> +sparse_remove_one_section().
> 
>  In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
>  mode allows for a quite efficient get_online_mems/put_online_mems
> -- 
> 2.15.1
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 1/2] admin-guide/memory-hotplug.rst: remove locking internal part from admin-guide

[Mike Rapoport]

On Wed, Dec 05, 2018 at 09:03:24AM +0100, David Hildenbrand wrote:
> On 05.12.18 03:34, Wei Yang wrote:
> > Locking Internal section exists in core-api documentation, which is more
> > suitable for this.
> > 
> > This patch removes the duplication part here.
> > 
> > Signed-off-by: Wei Yang 
> > ---
> >  Documentation/admin-guide/mm/memory-hotplug.rst | 40 
> > -
> >  1 file changed, 40 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst 
> > b/Documentation/admin-guide/mm/memory-hotplug.rst
> > index 5c4432c96c4b..241f4ce1e387 100644
> > --- a/Documentation/admin-guide/mm/memory-hotplug.rst
> > +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
> > @@ -392,46 +392,6 @@ Need more implementation yet
> >   - Notification completion of remove works by OS to firmware.
> >   - Guard from remove if not yet.

[ ... ]

> >  Future Work
> >  ===
> >  
> > 
> 
> I reported this yesterday to Jonathan and Mike
> 
> https://lkml.org/lkml/2018/12/3/340

Somehow I've missed it...
 
> Anyhow
> 
> Reviewed-by: David Hildenbrand 

Acked-by: Mike Rapoport 

> 
> -- 
> 
> Thanks,
> 
> David / dhildenb
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

[David Hildenbrand]

On 05.12.18 03:34, Wei Yang wrote:
> Currently locking for memory hotplug is a little complicated.
> 
> Generally speaking, we leverage the two global lock:
> 
>   * device_hotplug_lock
>   * mem_hotplug_lock
> 
> to serialise the process.
> 
> While for the long term, we are willing to have more fine-grained lock
> to provide higher scalability.
> 
> This patch divides Locking Internal section based on these two global
> locks to help readers to understand it. Also it adds some new finding to
> enrich it.
> 
> [David: words arrangement]
> 
> Signed-off-by: Wei Yang 
> ---
>  Documentation/core-api/memory-hotplug.rst | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/core-api/memory-hotplug.rst 
> b/Documentation/core-api/memory-hotplug.rst
> index de7467e48067..95662b283328 100644
> --- a/Documentation/core-api/memory-hotplug.rst
> +++ b/Documentation/core-api/memory-hotplug.rst
> @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification 
> queue.
>  Locking Internals
>  =
>  
> +There are three locks involved in memory-hotplug, two global lock and one 
> local
> +lock:
> +
> +- device_hotplug_lock
> +- mem_hotplug_lock
> +- device_lock
> +

Do we really only ever use these three and not anything else when
adding/removing/onlining/offlining memory?

(I am thinking e.g. about pgdat_resize_lock)

If so, you should phrase that maybe more generally Or add more details :)

"In addition to fine grained locks like pgdat_resize_lock, there are
three locks involved ..."


> +Currently, they are twisted together for all kinds of reasons. The following
> +part is divided into device_hotplug_lock and mem_hotplug_lock parts
> +respectively to describe those tricky situations.
> +
> +device_hotplug_lock
> +-
> +
>  When adding/removing memory that uses memory block devices (i.e. ordinary 
> RAM),
>  the device_hotplug_lock should be held to:
>  
> @@ -111,13 +125,20 @@ As the device is visible to user space before taking 
> the device_lock(), this
>  can result in a lock inversion.
>  
>  onlining/offlining of memory should be done via device_online()/
> -device_offline() - to make sure it is properly synchronized to actions
> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
> online_type)
> +device_offline() - to make sure it is properly synchronized to actions via
> +sysfs. Even mem_hotplug_lock is used to protect the process, because of the
> +lock inversion described above, holding device_hotplug_lock is still advised
> +(to e.g. protect online_type)
> +
> +mem_hotplug_lock
> +-
>  
>  When adding/removing/onlining/offlining memory or adding/removing
>  heterogeneous/device memory, we should always hold the mem_hotplug_lock in
>  write mode to serialise memory hotplug (e.g. access to global/zone
> -variables).
> +variables). Currently, we take advantage of this to serialise sparsemem's
> +mem_section handling in sparse_add_one_section() and
> +sparse_remove_one_section().
>  
>  In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
>  mode allows for a quite efficient get_online_mems/put_online_mems
> 


-- 

Thanks,

David / dhildenb

Re: [PATCH 1/2] admin-guide/memory-hotplug.rst: remove locking internal part from admin-guide

[David Hildenbrand]

On 05.12.18 03:34, Wei Yang wrote:
> Locking Internal section exists in core-api documentation, which is more
> suitable for this.
> 
> This patch removes the duplication part here.
> 
> Signed-off-by: Wei Yang 
> ---
>  Documentation/admin-guide/mm/memory-hotplug.rst | 40 
> -
>  1 file changed, 40 deletions(-)
> 
> diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst 
> b/Documentation/admin-guide/mm/memory-hotplug.rst
> index 5c4432c96c4b..241f4ce1e387 100644
> --- a/Documentation/admin-guide/mm/memory-hotplug.rst
> +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
> @@ -392,46 +392,6 @@ Need more implementation yet
>   - Notification completion of remove works by OS to firmware.
>   - Guard from remove if not yet.
>  
> -
> -Locking Internals
> -=
> -
> -When adding/removing memory that uses memory block devices (i.e. ordinary 
> RAM),
> -the device_hotplug_lock should be held to:
> -
> -- synchronize against online/offline requests (e.g. via sysfs). This way, 
> memory
> -  block devices can only be accessed (.online/.state attributes) by user
> -  space once memory has been fully added. And when removing memory, we
> -  know nobody is in critical sections.
> -- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and 
> PPC)
> -
> -Especially, there is a possible lock inversion that is avoided using
> -device_hotplug_lock when adding memory and user space tries to online that
> -memory faster than expected:
> -
> -- device_online() will first take the device_lock(), followed by
> -  mem_hotplug_lock
> -- add_memory_resource() will first take the mem_hotplug_lock, followed by
> -  the device_lock() (while creating the devices, during bus_add_device()).
> -
> -As the device is visible to user space before taking the device_lock(), this
> -can result in a lock inversion.
> -
> -onlining/offlining of memory should be done via device_online()/
> -device_offline() - to make sure it is properly synchronized to actions
> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect 
> online_type)
> -
> -When adding/removing/onlining/offlining memory or adding/removing
> -heterogeneous/device memory, we should always hold the mem_hotplug_lock in
> -write mode to serialise memory hotplug (e.g. access to global/zone
> -variables).
> -
> -In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
> -mode allows for a quite efficient get_online_mems/put_online_mems
> -implementation, so code accessing memory can protect from that memory
> -vanishing.
> -
> -
>  Future Work
>  ===
>  
> 

I reported this yesterday to Jonathan and Mike

https://lkml.org/lkml/2018/12/3/340


Anyhow

Reviewed-by: David Hildenbrand 

-- 

Thanks,

David / dhildenb

RE,

[Ms Sharifah Ahmad Mustahfa]

--
Hello,

First of all i will like to apologies for my manner of communication 
because you do not know me personally, its due to the fact that i have a 
very important proposal for you.

Re: Did You Receive My Last Mail?

[Reem Al-Hashimi]

Hello,

My name is ms. Reem Al-Hashimi. The UAE minister of state for international 
cooparation. I got your contact from an email database from your country. I 
have a financial transaction i would like to discuss with you. Please reply to 
reem2...@daum.net, for more details if you are interested.

Regards,

Ms. Reem Al-Hashimi

Re: [PATCH 1/1] scripts/kernel-doc: Fix struct and struct field attribute processing

[Jonathan Corbet]

On Thu, 22 Nov 2018 13:06:04 +0200
Sakari Ailus  wrote:

> The kernel-doc attempts to clear the struct and struct member attributes
> from the API documentation it produces. It falls short of the job in the
> following respects:
> 
> - extra whitespaces are left where __attribute__((...)) was removed,
> 
> - only a single attribute is removed per struct,
> 
> - attributes (such as aligned) containing numbers were not removed,
> 
> - attributes are only cleared from struct fields, not structs themselves.
> 
> This patch addresses these issues by removing the attributes.
> 
> Signed-off-by: Sakari Ailus 

That does indeed seem to improve things.  I'm waiting for the pile of
regexes to fall over and hurt somebody, but I guess we're not there yet.
Applied, thanks.

jon

RE,

[Miss Sharifah Ahmad Mustahfa]

Hello,

First of all i will like to apologies for my manner of communication because 
you do not know me personally, its due to the fact that i have a very important 
proposal for you.

RE,

[Miss Sharifah Ahmad Mustahfa]

Hello,

First of all i will like to apologies for my manner of communication because 
you do not know me personally, its due to the fact that i have a very important 
proposal for you.

RE,

[Miss Sharifah Ahmad Mustahfa]

Hello,

First of all i will like to apologies for my manner of communication because 
you do not know me personally, its due to the fact that i have a very important 
proposal for you.

RE,

[Miss Sharifah Ahmad Mustahfa]

Hello,

First of all i will like to apologies for my manner of communication because 
you do not know me personally, its due to the fact that i have a very important 
proposal for you.

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 11/14/2018 1:04 PM, Casey Schaufler wrote:
> On 10/24/2018 1:12 PM, Kees Cook wrote:
>> On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler  
>> wrote:
>>> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
 On 10/23/2018 11:50 AM, Kees Cook wrote:

> Did you poke around at my combined series?
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
 I hope to do that on the plane later today.
>>> I had a chance to poke at the combined series and it
>>> all seems to work as advertised.
>> /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;)
>>
>> -Kees
>>
> Now that we have next-general updated I'm porting these forward.

I have ported Kees' set forward to 4.20-rc2:
https://github.com/cschaufler/lsm-stacking.git#after-kees-4.20-rc2

There's one bug fix in ordered_lsm_parse() but otherwise just mechanical.

The infrastructure blob management required for TOMOYO, Landlock
and SARA is available:
https://github.com/cschaufler/lsm-stacking.git#blobs-4.20-rc2

There's nothing new here, although I had to make a few changes to
account for Kees' changes in the preceding patches. I will post the
patches shortly.

The full stacking changes based on this are still in the works. Netfilter
has added a whole new use of secmarks and I'm working to make the individual
patches smaller for easier review.

Re: [PATCH v2] docs/admin-guide/mm/concepts.rst: grammar and style fixups

[Jonathan Corbet]

On Sun, 11 Nov 2018 11:24:23 +0200
Mike Rapoport  wrote:

> Signed-off-by: Mike Rapoport 
> Reviewed-by: Randy Dunlap 
> ---
> 
> v2: address Matthew's feedback
> 
>  Documentation/admin-guide/mm/concepts.rst | 51 
> ---
>  1 file changed, 26 insertions(+), 25 deletions(-)

Applied, thanks.

jon

Re: [PATCH] docs/mm: update kmalloc kernel-doc description

[Jonathan Corbet]

On Sun, 11 Nov 2018 18:48:44 +0200
Mike Rapoport  wrote:

> Add references to GFP documentation and the memory-allocation.rst and remove
> GFP_USER, GFP_DMA and GFP_NOIO descriptions.
> 
> While on it slightly change the formatting so that the list of GFP flags
> will be rendered as "description" in the generated html.
> 
> Signed-off-by: Mike Rapoport 
> ---
> 
> Probably this should go via the -mm tree as it touches include/linux/slab.h

A week and some later it's not there - Andrew is even slower than me, it
seems! :)  So I went ahead and applied it, fixing the conflict over the
addition of the memory_allocation label while I was at it.

Thanks,

jon

Re: [PATCH] Link the memory allocation guide from the MM docs

[Jonathan Corbet]

On Mon, 19 Nov 2018 08:00:49 -0800
Matthew Wilcox  wrote:

> I just went looking for the memory allocation guide in the MM docs instead
> of in the core API.  For the benefit of the next person who makes that
> mistake, link to it from the MM docs.
> 
> Signed-off-by: Matthew Wilcox 

Applied, thanks.

jon

Re: [PATCH] Link the memory allocation guide from the MM docs

[Mike Rapoport]

On Mon, Nov 19, 2018 at 08:00:49AM -0800, Matthew Wilcox wrote:
> I just went looking for the memory allocation guide in the MM docs instead
> of in the core API.  For the benefit of the next person who makes that
> mistake, link to it from the MM docs.
> 
> Signed-off-by: Matthew Wilcox 

Acked-by: Mike Rapoport 

> 
> diff --git a/Documentation/core-api/memory-allocation.rst 
> b/Documentation/core-api/memory-allocation.rst
> index f8bb9aa120c4..8954a88ff5b7 100644
> --- a/Documentation/core-api/memory-allocation.rst
> +++ b/Documentation/core-api/memory-allocation.rst
> @@ -1,3 +1,5 @@
> +.. _memory-allocation:
> +
>  ===
>  Memory Allocation Guide
>  ===
> diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst
> index c4ded22197ca..2b3ab3a1ccf3 100644
> --- a/Documentation/vm/index.rst
> +++ b/Documentation/vm/index.rst
> @@ -2,7 +2,9 @@
>  Linux Memory Management Documentation
>  =
>  
> -This is a collection of documents about Linux memory management (mm) 
> subsystem.
> +This is a collection of documents about the Linux memory management (mm)
> +subsystem.  If you are looking for advice on simply allocating memory,
> +see the :ref:`memory-allocation`.
>  
>  User guides for MM features
>  ===
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v2] Document /proc/pid PID reuse behavior

[Daniel Colascione]

On Mon, Nov 19, 2018 at 2:54 AM, Pavel Machek  wrote:
> On Mon 2018-11-05 13:22:05, Daniel Colascione wrote:
>> State explicitly that holding a /proc/pid file descriptor open does
>> not reserve the PID. Also note that in the event of PID reuse, these
>> open file descriptors refer to the old, now-dead process, and not the
>> new one that happens to be named the same numeric PID.
>>
>> Signed-off-by: Daniel Colascione 
>> ---
>>  Documentation/filesystems/proc.txt | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> Moved paragraphed to start of /proc/pid section; added signed-off-by.
>>
>> diff --git a/Documentation/filesystems/proc.txt 
>> b/Documentation/filesystems/proc.txt
>> index 12a5e6e693b6..0b14460f721d 100644
>> --- a/Documentation/filesystems/proc.txt
>> +++ b/Documentation/filesystems/proc.txt
>> @@ -125,6 +125,13 @@ process running on the system, which is named after the 
>> process ID (PID).
>>  The link  self  points  to  the  process reading the file system. Each 
>> process
>>  subdirectory has the entries listed in Table 1-1.
>>
>> +Note that an open a file descriptor to /proc/ or to any of its
>> +contained files or subdirectories does not prevent  being reused
>> +for some other process in the event that  exits. Operations on
>
> "does not" -> "may not"?
>
> We want to leave this unspecified, so that we can change it in future.

No. "Does not". I'm sick and tired of procfs behavior being vague and
unspecified to the point where even kernel developers have an
incorrect mental model of how it all works. With Christian Brauner's
good work in place and hopefully my own work to follow, we're moving
firmly in the direction of procfs handles being struct pid references.
Instead of waffling further, let's just buy into this model and do the
best job we can of making it work well.

Re: [PATCH v1 2/8] mm: convert PG_balloon to PG_offline

[David Hildenbrand]

>  
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 50ce1bddaf56..f91da3d0a67e 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -670,7 +670,7 @@ PAGEFLAG_FALSE(DoubleMap)
>  #define PAGE_TYPE_BASE   0xf000
>  /* Reserve   0x007f to catch underflows of page_mapcount */
>  #define PG_buddy 0x0080
> -#define PG_balloon   0x0100
> +#define PG_offline   0x0100
>  #define PG_kmemcg0x0200
>  #define PG_table 0x0400
>  
> @@ -700,10 +700,13 @@ static __always_inline void __ClearPage##uname(struct 
> page *page)   \
>  PAGE_TYPE_OPS(Buddy, buddy)
>  
>  /*
> - * PageBalloon() is true for pages that are on the balloon page list
> - * (see mm/balloon_compaction.c).
> + * PageOffline() indicates that the pages is logically offline although the

s/pages/page/

:)


-- 

Thanks,

David / dhildenb

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 10/24/2018 1:12 PM, Kees Cook wrote:
> On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler  
> wrote:
>> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
>>> On 10/23/2018 11:50 AM, Kees Cook wrote:
>>>
 Did you poke around at my combined series?
 https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
>>> I hope to do that on the plane later today.
>> I had a chance to poke at the combined series and it
>> all seems to work as advertised.
> /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;)
>
> -Kees
>
Now that we have next-general updated I'm porting these forward.

Re: [PATCH v2] doc: tracing: Fix a number of typos

[Jonathan Corbet]

On Thu,  1 Nov 2018 09:57:17 -0400
Amir Livneh  wrote:

> Trivial fixes to spelling mistakes in ftrace.rst
> 
> v2: tripple -> triple
> 
> Signed-off-by: Amir Livneh 

Applied, thanks.

jon

Re: [PATCH] docs/admin-guide/mm/concepts.rst: grammar fixups

[Mike Rapoport]

On Mon, Nov 05, 2018 at 11:29:27PM -0800, Randy Dunlap wrote:
> On 11/5/18 10:35 PM, Mike Rapoport wrote:
> > On Mon, Nov 05, 2018 at 01:12:40PM -0800, Matthew Wilcox wrote:
> >> On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
> >>> @@ -21,10 +21,10 @@ Virtual Memory Primer
> >>>  The physical memory in a computer system is a limited resource and
> >>>  even for systems that support memory hotplug there is a hard limit on
> >>>  the amount of memory that can be installed. The physical memory is not
> >>> -necessary contiguous, it might be accessible as a set of distinct
> >>> +necessary contiguous; it might be accessible as a set of distinct
> >>
> >> necessarily
> >>
> >>>  address ranges. Besides, different CPU architectures, and even
> >>> -different implementations of the same architecture have different view
> >>> -how these address ranges defined.
> >>> +different implementations of the same architecture have different views
> >>> +of how these address ranges defined.
> >>
> >> "are defined"?
> >>
> >>>  Each physical memory page can be mapped as one or more virtual
> >>>  pages. These mappings are described by page tables that allow
> >>> -translation from virtual address used by programs to real address in
> >>> -the physical memory. The page tables organized hierarchically.
> >>> +translation from a virtual address used by programs to the real
> >>> +address in the physical memory. The page tables are organized
> >>> +hierarchically.
> >>
> >> I don't like the term "real address".  Can we say "physical address in 
> >> memory" here, or "address of physical memory" or something?
> >  
> > I didn't really like it as well, but I couldn't think of any better
> > adjective to emphasize that address in the physical memory is "the real
> > thing".
> > 
> > Maybe the best would be to drop "real" and make it 
> > 
> > "translation from a virtual address used by programs to the 
> > address in the physical memory"
> 
> physical memory address ?

Works for me, thanks!
 
> 
> -- 
> ~Randy
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH] docs/admin-guide/mm/concepts.rst: grammar fixups

[Randy Dunlap]

On 11/5/18 10:35 PM, Mike Rapoport wrote:
> On Mon, Nov 05, 2018 at 01:12:40PM -0800, Matthew Wilcox wrote:
>> On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
>>> @@ -21,10 +21,10 @@ Virtual Memory Primer
>>>  The physical memory in a computer system is a limited resource and
>>>  even for systems that support memory hotplug there is a hard limit on
>>>  the amount of memory that can be installed. The physical memory is not
>>> -necessary contiguous, it might be accessible as a set of distinct
>>> +necessary contiguous; it might be accessible as a set of distinct
>>
>> necessarily
>>
>>>  address ranges. Besides, different CPU architectures, and even
>>> -different implementations of the same architecture have different view
>>> -how these address ranges defined.
>>> +different implementations of the same architecture have different views
>>> +of how these address ranges defined.
>>
>> "are defined"?
>>
>>>  Each physical memory page can be mapped as one or more virtual
>>>  pages. These mappings are described by page tables that allow
>>> -translation from virtual address used by programs to real address in
>>> -the physical memory. The page tables organized hierarchically.
>>> +translation from a virtual address used by programs to the real
>>> +address in the physical memory. The page tables are organized
>>> +hierarchically.
>>
>> I don't like the term "real address".  Can we say "physical address in 
>> memory" here, or "address of physical memory" or something?
>  
> I didn't really like it as well, but I couldn't think of any better
> adjective to emphasize that address in the physical memory is "the real
> thing".
> 
> Maybe the best would be to drop "real" and make it 
> 
> "translation from a virtual address used by programs to the 
> address in the physical memory"

physical memory address ?


-- 
~Randy

Re: [PATCH] docs/admin-guide/mm/concepts.rst: grammar fixups

[Mike Rapoport]

On Mon, Nov 05, 2018 at 01:12:40PM -0800, Matthew Wilcox wrote:
> On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
> > @@ -21,10 +21,10 @@ Virtual Memory Primer
> >  The physical memory in a computer system is a limited resource and
> >  even for systems that support memory hotplug there is a hard limit on
> >  the amount of memory that can be installed. The physical memory is not
> > -necessary contiguous, it might be accessible as a set of distinct
> > +necessary contiguous; it might be accessible as a set of distinct
> 
> necessarily
> 
> >  address ranges. Besides, different CPU architectures, and even
> > -different implementations of the same architecture have different view
> > -how these address ranges defined.
> > +different implementations of the same architecture have different views
> > +of how these address ranges defined.
> 
> "are defined"?
> 
> >  Each physical memory page can be mapped as one or more virtual
> >  pages. These mappings are described by page tables that allow
> > -translation from virtual address used by programs to real address in
> > -the physical memory. The page tables organized hierarchically.
> > +translation from a virtual address used by programs to the real
> > +address in the physical memory. The page tables are organized
> > +hierarchically.
> 
> I don't like the term "real address".  Can we say "physical address in 
> memory" here, or "address of physical memory" or something?
 
I didn't really like it as well, but I couldn't think of any better
adjective to emphasize that address in the physical memory is "the real
thing".

Maybe the best would be to drop "real" and make it 

"translation from a virtual address used by programs to the 
address in the physical memory"


> > -page filled with zeroes. When the program performs a write, regular
> > +page filled with zeroes. When the program performs a write, a regular
> >  physical page will be allocated to hold the written data. The page
> >  will be marked dirty and if the kernel will decide to repurpose it,
> >  the dirty page will be swapped out.
> 
> "if the kernel will decide to repurpose it" is awkward.  How about
> 
> if the kernel decides to repurpose it"?
> 
> >  OOM killer
> >  ==
> >  
> > -It may happen, that on a loaded machine memory will be exhausted. When
> > +It may happen that on a loaded machine memory will be exhausted. When
> >  the kernel detects that the system runs out of memory (OOM) it invokes
> >  `OOM killer`.
> > Its mission is simple: all it has to do is to select a
> >  task to sacrifice for the sake of the overall system health. The
> 
> It is possible for the kernel to be unable to reclaim enough memory to
> continue to operate.  In order to save the rest of the system, it invokes
> the `OOM killer` to sacrifice one task.

How about:

It is possible that on a loaded machine memory will be exhausted and the
kernel will be unable to reclaim enough memory to continue to operate. In
order to save the rest of the system, it invokes the `OOM killer`.

The `OOM killer` selects a task to sacrifice for the sake of the overall
system health. The selected task is killed in a hope that after it exits
enough memory will be freed to continue normal operation.


-- 
Sincerely yours, Mike.

Re: [PATCH] docs/admin-guide/mm/concepts.rst: grammar fixups

[Matthew Wilcox]

On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
> @@ -21,10 +21,10 @@ Virtual Memory Primer
>  The physical memory in a computer system is a limited resource and
>  even for systems that support memory hotplug there is a hard limit on
>  the amount of memory that can be installed. The physical memory is not
> -necessary contiguous, it might be accessible as a set of distinct
> +necessary contiguous; it might be accessible as a set of distinct

necessarily

>  address ranges. Besides, different CPU architectures, and even
> -different implementations of the same architecture have different view
> -how these address ranges defined.
> +different implementations of the same architecture have different views
> +of how these address ranges defined.

"are defined"?

>  Each physical memory page can be mapped as one or more virtual
>  pages. These mappings are described by page tables that allow
> -translation from virtual address used by programs to real address in
> -the physical memory. The page tables organized hierarchically.
> +translation from a virtual address used by programs to the real
> +address in the physical memory. The page tables are organized
> +hierarchically.

I don't like the term "real address".  Can we say "physical address in memory" 
here, or "address of physical memory" or something?

> -page filled with zeroes. When the program performs a write, regular
> +page filled with zeroes. When the program performs a write, a regular
>  physical page will be allocated to hold the written data. The page
>  will be marked dirty and if the kernel will decide to repurpose it,
>  the dirty page will be swapped out.

"if the kernel will decide to repurpose it" is awkward.  How about

if the kernel decides to repurpose it"?

>  OOM killer
>  ==
>  
> -It may happen, that on a loaded machine memory will be exhausted. When
> +It may happen that on a loaded machine memory will be exhausted. When
>  the kernel detects that the system runs out of memory (OOM) it invokes
>  `OOM killer`.
> Its mission is simple: all it has to do is to select a
>  task to sacrifice for the sake of the overall system health. The

It is possible for the kernel to be unable to reclaim enough memory to
continue to operate.  In order to save the rest of the system, it invokes
the `OOM killer` to sacrifice one task.

Re: [PATCH] docs/admin-guide/mm/concepts.rst: grammar fixups

[Randy Dunlap]

On 11/5/18 11:58 AM, Mike Rapoport wrote:
> From: Mike Rapoport 
> 
> Signed-off-by: Mike Rapoport 
> Cc: Randy Dunlap 
> ---
> 
> There was a couple of grammar fixes Randy suggested a while ago, but it
> seems I've never sent them out. 
> 
>  Documentation/admin-guide/mm/concepts.rst | 39 
> ---
>  1 file changed, 20 insertions(+), 19 deletions(-)

Hi Mike,

one nit:

> @@ -121,8 +122,8 @@ Nodes
>  Many multi-processor machines are NUMA - Non-Uniform Memory Access -
>  systems. In such systems the memory is arranged into banks that have
>  different access latency depending on the "distance" from the
> -processor. Each bank is referred as `node` and for each node Linux
> -constructs an independent memory management subsystem. A node has it's
> +processor. Each bank is referred as a `node` and for each node Linux

is referred to as a

> +constructs an independent memory management subsystem. A node has its
>  own set of zones, lists of free and used pages and various statistics
>  counters. You can find more details about NUMA in
>  :ref:`Documentation/vm/numa.rst ` and in

Reviewed-by: Randy Dunlap 

thanks.
-- 
~Randy

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Linus Torvalds]

On Mon, Nov 5, 2018 at 5:15 AM Martin Schwidefsky
 wrote:
>
> This patch would work for me:

Thanks, applied,

 Linus

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Steven Rostedt]

On Mon, 5 Nov 2018 14:15:35 +0100
Martin Schwidefsky  wrote:
>  
> Follow-up question: the __no_sanitize_address_or_inline define has the 
> 'notrace'
> option that is missing for __no_kasan_or_inline. We need that option for
> __load_psw_mask, if we do the replacement all users of __no_kasan_or_inline
> would get the option as well. This affects __read_once_size_nocheck and
> read_word_at_a_time. Do these function have to be traceable ?

Some history on why I added notrace to inline. It was to make things
more consistent. Since gcc wont add a fentry/mcount call to inlined
functions, having those functions show up in the trace depending on
whether or not gcc honored the "inline" tag made things confusing. And
it even once caused a crash when local_irq_save() stopped being
inlined.

I added notrace to inline so that if you mark something as inline, it
would not show up in the trace regardless of gcc deciding to inline the
function or not.

> 
> This patch would work for me:
> --
> >From 4aaa09fe4b54e930edabac86606dee979b12647c Mon Sep 17 00:00:00 2001  
> From: Martin Schwidefsky 
> Date: Mon, 5 Nov 2018 07:36:28 +0100
> Subject: [PATCH] compiler: remove __no_sanitize_address_or_inline again
> 
> The __no_sanitize_address_or_inline and __no_kasan_or_inline defines
> are almost identical. The only difference is that __no_kasan_or_inline
> does not have the 'notrace' attribute.
> 
> To be able to replace __no_sanitize_address_or_inline with the older
> definition, add 'notrace' to __no_kasan_or_inline and change to two
> users of __no_sanitize_address_or_inline in the s390 code.
> 
> The 'notrace' option is necessary for e.g. the __load_psw_mask function
> in arch/s390/include/asm/processor.h. Without the option it is possible
> to trace __load_psw_mask which leads to kernel stack overflow.

Acked-by: Steven Rostedt (VMware) 

-- Steve

> 
> Signed-off-by: Martin Schwidefsky 
> ---
>  arch/s390/include/asm/processor.h |  4 ++--
>  include/linux/compiler-gcc.h  | 12 
>  include/linux/compiler.h  |  2 +-
>  3 files changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/s390/include/asm/processor.h 
> b/arch/s390/include/asm/processor.h
> index 302795c47c06..81038ab357ce 100644
> --- a/arch/s390/include/asm/processor.h
> +++ b/arch/s390/include/asm/processor.h
> @@ -236,7 +236,7 @@ static inline unsigned long current_stack_pointer(void)
>   return sp;
>  }
>  
> -static __no_sanitize_address_or_inline unsigned short stap(void)
> +static __no_kasan_or_inline unsigned short stap(void)
>  {
>   unsigned short cpu_address;
>  
> @@ -330,7 +330,7 @@ static inline void __load_psw(psw_t psw)
>   * Set PSW mask to specified value, while leaving the
>   * PSW addr pointing to the next instruction.
>   */
> -static __no_sanitize_address_or_inline void __load_psw_mask(unsigned long 
> mask)
> +static __no_kasan_or_inline void __load_psw_mask(unsigned long mask)
>  {
>   unsigned long addr;
>   psw_t psw;
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index c0f5db3a9621..2010493e1040 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -143,18 +143,6 @@
>  #define KASAN_ABI_VERSION 3
>  #endif
>  
> -/*
> - * Because __no_sanitize_address conflicts with inlining:
> - *   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
> - * we do one or the other. 
> - */
> -#ifdef CONFIG_KASAN
> -#define __no_sanitize_address_or_inline  
> \
> - __no_sanitize_address __maybe_unused notrace
> -#else
> -#define __no_sanitize_address_or_inline inline
> -#endif
> -
>  #if GCC_VERSION >= 50100
>  #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
>  #endif
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 18c80cfa4fc4..06396c1cf127 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -189,7 +189,7 @@ void __read_once_size(const volatile void *p, void *res, 
> int size)
>   *   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
>   * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
>   */
> -# define __no_kasan_or_inline __no_sanitize_address __maybe_unused
> +# define __no_kasan_or_inline __no_sanitize_address notrace __maybe_unused
>  #else
>  # define __no_kasan_or_inline __always_inline
>  #endif

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Martin Schwidefsky]

On Mon, 5 Nov 2018 07:02:56 +0100
Martin Schwidefsky  wrote:

> On Fri, 2 Nov 2018 09:09:32 -0700
> Linus Torvalds  wrote:
> 
> > On Fri, Nov 2, 2018 at 2:43 AM Andrey Ryabinin  
> > wrote:  
> > >
> > > You're right, version checks shouldn't matter here. But 
> > > __no_sanitize_address_or_inline
> > > shouldn't have been added in the first place, because we already have 
> > > almost the same
> > >__no_kasan_or_inline:
> > 
> > Ahh, very good.
> > 
> > Vasily, Martin - since __no_sanitize_address_or_inline was added just
> > for s390, would you mind replacing it with __no_kasan_or_inline
> > instead, and testing that in whatever failed before?
> > 
> > Then we can just remove that unnecessary symbol #define entirely..  
> 
> Ok, will do.
 
Follow-up question: the __no_sanitize_address_or_inline define has the 'notrace'
option that is missing for __no_kasan_or_inline. We need that option for
__load_psw_mask, if we do the replacement all users of __no_kasan_or_inline
would get the option as well. This affects __read_once_size_nocheck and
read_word_at_a_time. Do these function have to be traceable ?

This patch would work for me:
--
>From 4aaa09fe4b54e930edabac86606dee979b12647c Mon Sep 17 00:00:00 2001
From: Martin Schwidefsky 
Date: Mon, 5 Nov 2018 07:36:28 +0100
Subject: [PATCH] compiler: remove __no_sanitize_address_or_inline again

The __no_sanitize_address_or_inline and __no_kasan_or_inline defines
are almost identical. The only difference is that __no_kasan_or_inline
does not have the 'notrace' attribute.

To be able to replace __no_sanitize_address_or_inline with the older
definition, add 'notrace' to __no_kasan_or_inline and change to two
users of __no_sanitize_address_or_inline in the s390 code.

The 'notrace' option is necessary for e.g. the __load_psw_mask function
in arch/s390/include/asm/processor.h. Without the option it is possible
to trace __load_psw_mask which leads to kernel stack overflow.

Signed-off-by: Martin Schwidefsky 
---
 arch/s390/include/asm/processor.h |  4 ++--
 include/linux/compiler-gcc.h  | 12 
 include/linux/compiler.h  |  2 +-
 3 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/arch/s390/include/asm/processor.h 
b/arch/s390/include/asm/processor.h
index 302795c47c06..81038ab357ce 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -236,7 +236,7 @@ static inline unsigned long current_stack_pointer(void)
return sp;
 }
 
-static __no_sanitize_address_or_inline unsigned short stap(void)
+static __no_kasan_or_inline unsigned short stap(void)
 {
unsigned short cpu_address;
 
@@ -330,7 +330,7 @@ static inline void __load_psw(psw_t psw)
  * Set PSW mask to specified value, while leaving the
  * PSW addr pointing to the next instruction.
  */
-static __no_sanitize_address_or_inline void __load_psw_mask(unsigned long mask)
+static __no_kasan_or_inline void __load_psw_mask(unsigned long mask)
 {
unsigned long addr;
psw_t psw;
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index c0f5db3a9621..2010493e1040 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -143,18 +143,6 @@
 #define KASAN_ABI_VERSION 3
 #endif
 
-/*
- * Because __no_sanitize_address conflicts with inlining:
- *   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
- * we do one or the other. 
- */
-#ifdef CONFIG_KASAN
-#define __no_sanitize_address_or_inline
\
-   __no_sanitize_address __maybe_unused notrace
-#else
-#define __no_sanitize_address_or_inline inline
-#endif
-
 #if GCC_VERSION >= 50100
 #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
 #endif
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 18c80cfa4fc4..06396c1cf127 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -189,7 +189,7 @@ void __read_once_size(const volatile void *p, void *res, 
int size)
  * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
  * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
  */
-# define __no_kasan_or_inline __no_sanitize_address __maybe_unused
+# define __no_kasan_or_inline __no_sanitize_address notrace __maybe_unused
 #else
 # define __no_kasan_or_inline __always_inline
 #endif
-- 
2.16.4
-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Martin Schwidefsky]

On Fri, 2 Nov 2018 09:09:32 -0700
Linus Torvalds  wrote:

> On Fri, Nov 2, 2018 at 2:43 AM Andrey Ryabinin  
> wrote:
> >
> > You're right, version checks shouldn't matter here. But 
> > __no_sanitize_address_or_inline
> > shouldn't have been added in the first place, because we already have 
> > almost the same
> >__no_kasan_or_inline:  
> 
> Ahh, very good.
> 
> Vasily, Martin - since __no_sanitize_address_or_inline was added just
> for s390, would you mind replacing it with __no_kasan_or_inline
> instead, and testing that in whatever failed before?
> 
> Then we can just remove that unnecessary symbol #define entirely..

Ok, will do.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Andrey Ryabinin]

On 11/02/2018 07:11 PM, Linus Torvalds wrote:
> On Fri, Nov 2, 2018 at 6:16 AM Andrey Ryabinin  
> wrote:
>>
>> On 11/02/2018 04:46 AM, Linus Torvalds wrote:
>>>
>>> So I _think_ the KASAN config should have a
>>>
>>> depends on CC_IS_GCC && GCC_VERSION >= 40902
>>>
>>> on it, but maybe there is something I'm missing.
>>
>> I'd rather use cc-option instead of version check, since we also support 
>> clang.
> 
> That would be even better, but I thought the requirement for 4.9.2
> came not from the option existing, but because of some bugs getting
> fixed?

It looks unusual but -fsanitize=kernel-address really showed up only in 4.9.2.
It was actually backported from 5.0 branch to 4.9 for whatever reason.

> 
> But if we can do it without version checks, that would be lovely.
> 
> Linus
> 

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Linus Torvalds]

On Fri, Nov 2, 2018 at 6:16 AM Andrey Ryabinin  wrote:
>
> On 11/02/2018 04:46 AM, Linus Torvalds wrote:
> >
> > So I _think_ the KASAN config should have a
> >
> > depends on CC_IS_GCC && GCC_VERSION >= 40902
> >
> > on it, but maybe there is something I'm missing.
>
> I'd rather use cc-option instead of version check, since we also support 
> clang.

That would be even better, but I thought the requirement for 4.9.2
came not from the option existing, but because of some bugs getting
fixed?

But if we can do it without version checks, that would be lovely.

Linus

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Linus Torvalds]

On Fri, Nov 2, 2018 at 2:43 AM Andrey Ryabinin  wrote:
>
> You're right, version checks shouldn't matter here. But 
> __no_sanitize_address_or_inline
> shouldn't have been added in the first place, because we already have almost 
> the same
>__no_kasan_or_inline:

Ahh, very good.

Vasily, Martin - since __no_sanitize_address_or_inline was added just
for s390, would you mind replacing it with __no_kasan_or_inline
instead, and testing that in whatever failed before?

Then we can just remove that unnecessary symbol #define entirely..

Thanks,

 Linus

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Andrey Ryabinin]

On 11/02/2018 04:46 AM, Linus Torvalds wrote:
> On Thu, Nov 1, 2018 at 10:06 AM Linus Torvalds
>  wrote:
>>
>> The logic for using __no_sanitize_address *used* to be
>>
>> #if GCC_VERSION >= 40902
> 
> Ok, looking around, I think this has less to do with the attribute
> being recognized, and simply just being because KASAN itself wants
> gcc-4.9.2.
> 
> I'm actually not seeing that KASAN dependency in the Kconfig scripts
> (and it probably _should_ be now that we can just add compiler version
> dependencies there), but that explains why the gcc version check is
> different from "gcc supports the attribute".
> 
> Anyway, I decided to do the merge by just getting rid of the
> GCC_VERSION check around __no_sanitize_address_or_inline entirely. If
> you enable KASAN, then a function with that marking just won't be
> marked inline.
> 
> End result: pulled. I'm as confused as you are as to why
> __no_sanitize_address_or_inline is in the gcc header, but I guess it
> ends up being the same issue: KASAN depends on gcc even if that
> dependency doesn't seem to be spelled out in lib/Kconfig.kasan.
> 
> So I _think_ the KASAN config should have a
> 
> depends on CC_IS_GCC && GCC_VERSION >= 40902
> 
> on it, but maybe there is something I'm missing.
> 

I'd rather use cc-option instead of version check, since we also support clang.

It should be possible to express compiler requirements for subfeatures
like stack/inline instrumentation in Kconfig. But that would be not that 
trivial, 
see the scripts/Makefile.kasan

> But from a pull standpoint, I don't want to mess with those
> (unrelated) issues, so I just kept the merge resolution as simple and
> straightforward as possible.
> 
> Miguel, please do double-check the merge (it's not pushed out yet, I'm
> doing the usual build tests etc first).
> 
> Linus
> 

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Miguel Ojeda]

On Fri, Nov 2, 2018 at 2:52 AM Linus Torvalds
 wrote:
>
> Anyway, I decided to do the merge by just getting rid of the
> GCC_VERSION check around __no_sanitize_address_or_inline entirely. If
> you enable KASAN, then a function with that marking just won't be
> marked inline.

I was a bit confused when reading the gcc bug reports, i.e. why gcc
did *not* complain in 4.9 but it did in 5.1 (when it was supposed to
complain also in 4.9). It turns out that gcc 5.1 takes into account
who is the actual caller due to this change:

+  cgraph_node *caller = e->caller->global.inlined_to
+   ? e->caller->global.inlined_to : e->caller;
...
-  else if (!sanitize_attrs_match_for_inline_p (e->caller->decl, callee->decl))
+  else if (!sanitize_attrs_match_for_inline_p (caller->decl, callee->decl))

change; e.g. this:

#define really_inline inline __attribute__((always_inline))
#define no_sanitize __attribute__((no_sanitize_address))

really_inline void f() {}
really_inline void g() { f(); }
no_sanitize void h() { g(); }

Complains in gcc 4.9 -O0, 5.1 -O0 and 5.1 -O2; but *not* in 4.9 -O2.
https://godbolt.org/z/kNApqk

Anyway, this is orthogonal but in case it clarifies that for someone else...

> Miguel, please do double-check the merge (it's not pushed out yet, I'm
> doing the usual build tests etc first).

I was sleeping, didn't manage to see it (in your GitHub, I guess?).

I did the merge myself, and arrived at the same thing as you. I
quickly inspected the rest and seems fine. By the way, I spotted an
extra space at:

+ * we do one or the other.

Cheers,
Miguel

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Andrey Ryabinin]

On 11/01/2018 08:06 PM, Linus Torvalds wrote:
> On Mon, Oct 22, 2018 at 3:59 AM Miguel Ojeda
>  wrote:
>>
>> Here it is the Compiler Attributes series/tree, which tries to disentangle
>> the include/linux/compiler*.h headers and bring them up to date.
> 
> I've finally emptied the "normal" pull queues, and am looking at the
> odd ones that I felt I needed to review more in-depth.
> 
> This looked fine to me, and I already pulled, but when looking at the
> conflict for __no_sanitize_address_or_inline, I also noticed that you
> actually changed the gcc version logic.
> 
> The logic for using __no_sanitize_address *used* to be
> 
> #if GCC_VERSION >= 40902
> 
> but you have changed it to
> 
>   # define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
> 
> so now it's gcc-4.8+ rather than gcc-4.9.2+.

As you said in other email - "this has less to do with the attribute
being recognized, and simply just being because KASAN itself wants
gcc-4.9.2."

gcc < 4.9.2 simply doesn't have -fsanitize=kernel-address.
But no_sanitize attribute originally comes with user space ASAN 
(-fsanitize=address)
which exist in earlier GCCs like 4.8.
Checking against 4.8 gcc should be fine. If we compile the kernel with gcc 4.8
it will be compiled without instrumentation, so the attribute won't have any 
effect.

> 
> I'm not sure how much that matters (maybe the original check for 4.9.2
> was just a random pick by Andrey? Added to cc), but together with the
> movement to  that looks like it also
> wouldn't want the CONFIG_KASAN tests, I wonder what the right merge
> resolution would be.
> 
> Yes, I see the resolution in linux-next, and I think that one is odd
> and dubious, and now it *mixes* that old test of gcc-4.9.2 with the
> different test in compiler-attributes.
> 
> I'm _inclined_ to just do
> 
> #ifdef CONFIG_KASAN
>  #define __no_sanitize_address_or_inline \
>   __no_sanitize_address __maybe_unused notrace
> #else
>  #define __no_sanitize_address_or_inline inline
> #endif
> 
> without any compiler versions at all, because I don't think it matters
> (maybe we won't get address sanitation, and we will not get inlining
> either, but do we care?).

You're right, version checks shouldn't matter here. But 
__no_sanitize_address_or_inline
shouldn't have been added in the first place, because we already have almost 
the same __no_kasan_or_inline:

#ifdef CONFIG_KASAN
/*
 * We can't declare function 'inline' because __no_sanitize_address confilcts
 * with inlining. Attempt to inline it may cause a build failure.
 *  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
 * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
 */
# define __no_kasan_or_inline __no_sanitize_address __maybe_unused
#else
# define __no_kasan_or_inline __always_inline
#endif

There are small differences like absence of notrace, but notrace could be added
to the function together with __no_kasan_or_inline.
And inline is *not* redefined to __always_inline  only on x86 when 
CONFIG_OPTIMIZE_INLINING=y

So there is absolutely no reason to have both __no_kasan_or_inline and 
__no_sanitize_address_or_inline.

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Linus Torvalds]

On Thu, Nov 1, 2018 at 10:06 AM Linus Torvalds
 wrote:
>
> The logic for using __no_sanitize_address *used* to be
>
> #if GCC_VERSION >= 40902

Ok, looking around, I think this has less to do with the attribute
being recognized, and simply just being because KASAN itself wants
gcc-4.9.2.

I'm actually not seeing that KASAN dependency in the Kconfig scripts
(and it probably _should_ be now that we can just add compiler version
dependencies there), but that explains why the gcc version check is
different from "gcc supports the attribute".

Anyway, I decided to do the merge by just getting rid of the
GCC_VERSION check around __no_sanitize_address_or_inline entirely. If
you enable KASAN, then a function with that marking just won't be
marked inline.

End result: pulled. I'm as confused as you are as to why
__no_sanitize_address_or_inline is in the gcc header, but I guess it
ends up being the same issue: KASAN depends on gcc even if that
dependency doesn't seem to be spelled out in lib/Kconfig.kasan.

So I _think_ the KASAN config should have a

depends on CC_IS_GCC && GCC_VERSION >= 40902

on it, but maybe there is something I'm missing.

But from a pull standpoint, I don't want to mess with those
(unrelated) issues, so I just kept the merge resolution as simple and
straightforward as possible.

Miguel, please do double-check the merge (it's not pushed out yet, I'm
doing the usual build tests etc first).

Linus

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Miguel Ojeda]

On Thu, Nov 1, 2018 at 6:06 PM Linus Torvalds
 wrote:
>
> I'm not sure how much that matters (maybe the original check for 4.9.2
> was just a random pick by Andrey? Added to cc), but together with the
> movement to  that looks like it also
> wouldn't want the CONFIG_KASAN tests, I wonder what the right merge
> resolution would be.

Good catch. I don't recall any special logic when I did that change,
so most likely I simply did like for the rest of the attributes and
took a look at when it was first supported (and documentation in gcc's
docs) in order to implement __has_attribute by hand.

But indeed, it *may* be that there is an (undocumented) problem
between 4.8 <= gcc < 4.9.2 with it. If so, we should document it down
and fix it. Andrey?

> Yes, I see the resolution in linux-next, and I think that one is odd
> and dubious, and now it *mixes* that old test of gcc-4.9.2 with the
> different test in compiler-attributes.

I missed that conflict completely, my bad (I did not miss all of them,
at least; one required fixing).

Hm at a quick look, why is it only on compiler-gcc.h? It should
either have a corresponding #define elsewhere or just be put directly
in another common header, no? (Adding Vasily & Martin to CC.)

> But I'm also unsure whether you meant for the "__has_attribute()" test
> to be usable outside the linux/compiler_attributes.h file, in which
> case I could just do
>
>   #if defined(CONFIG_KASAN) && __has_attribute(__no_sanitize_address__)
>
> instead.

I think that (using __has_attribute() outside) may be a good idea: I
wanted to keep compiler_attributes.h as simple as possible by avoiding
#ifdefs inside that header (except for __has_attribute itself), as an
attempt to avoid going back to the mess of #ifdefs we had previously.
Basically, keeping the attributes in compiler_attributes.h that do not
depend on complex logic. So using __has_attribute *outside* the header
actually goes well with that principle, because it helps keeping stuff
out of it if they depend on other config options; without having to
rely on GCC_VERSION either.

[By the way, in case it clarifies: note that "optional" in that file
actually is a bit of a misnomer. I meant to say "optional" as in "not
supported by all compilers, so conditionally defined" ("optionally"
defined); rather than "optional" in the sense of "code still works
without the attribute". It caught Rasmus in one of his patches sent a
few days ago on top of this tree, so I want to change it or explain it
to avoid confusion.]

Cheers,
Miguel

Re: [PATCH] doc: tracing: Fix a number of typos

[Will Korteland]

On 2018-10-31 14:16, Amir Livneh wrote:
> @@ -2978,7 +2978,7 @@ The following commands are supported:
>When the function is hit, it will dump the contents of the ftrace
>ring buffer to the console. This is useful if you need to debug
>something, and want to dump the trace when a certain function
> -  is hit. Perhaps its a function that is called before a tripple
> +  is hit. Perhaps it's a function that is called before a tripple
>fault happens and does not allow you to get a regular dump.
>  
>  - cpudump:

"tripple" -> "triple", while you're at it?

- Will

Re: [PATCH v10 4/9] dt-bindings: i3c: Document core bindings

[Rob Herring]

On Fri, 26 Oct 2018 16:43:28 +0200, Boris Brezillon wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
> 
> Document this generic representation.
> 
> Cc: Rob Herring 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v10:
> - Fix mistakes in the example (reported by Rob)
> 
> Changes in v9:
> - Rework the way we encode the I2C vs I3C device in the reg property
>   so that we don't need the funky macros to define and I3C or I2C dev
> - Drop Rob's Reviewed-by
> 
> Changes in v8:
> - None
> 
> Changes in v7:
> - None
> 
> Changes in v6:
> - None
> 
> Changes in v5:
> - Add Rob's R-b
> 
> Changes in v4:
> - Clarify the fact that static address == I3C address and dynamic
>   address == I3C address
> - Use i2c-scl-hz in the example
> 
> Changes in v3:
> - Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz
> - Rework the way we expose the provisional ID and LVR information
> - Rename dynamic-address into assigned-address
> - Enforce the I3C master node name
> 
> Changes in v2:
> - Define how to describe I3C devices in the DT and when it should be
>   used. Note that the parsing of I3C devices is not yet implemented in
>   the framework. Will be added when someone really needs it.
> ---
>  Documentation/devicetree/bindings/i3c/i3c.txt | 139 ++
>  1 file changed, 139 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
> 

Reviewed-by: Rob Herring 

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Kees Cook]

On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler  wrote:
> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
>> On 10/23/2018 11:50 AM, Kees Cook wrote:
>>
>>> Did you poke around at my combined series?
>>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
>> I hope to do that on the plane later today.
>
> I had a chance to poke at the combined series and it
> all seems to work as advertised.

/me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;)

-Kees

-- 
Kees Cook

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 10/23/2018 12:05 PM, Casey Schaufler wrote:
> On 10/23/2018 11:50 AM, Kees Cook wrote:
>
>> Did you poke around at my combined series?
>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
> I hope to do that on the plane later today.

I had a chance to poke at the combined series and it
all seems to work as advertised. 

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 10/23/2018 11:50 AM, Kees Cook wrote:
> On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler  
> wrote:
>> On 10/12/2018 12:01 PM, Kees Cook wrote:
>>> On Friday, October 12, 2018 3:19 AM, John Johansen
>>>  wrote:
 It isn't perfect but it manages consistency across distros as best as
 can be achieved atm.
>>> Yeah, this is why I'm okay with the current series: it provides as
>>> consistent a view as possible, but leaves room for future improvements
>>> (like adding "+" or "!" or "all" or whatever).
>>>
>>> I'm curious to see what SELinux folks think of v5, though. I *think* I
>>> addressed all the concerns there, even Paul's "I want my distro
>>> default to not have extreme stacking" case too.
>>>
>>> -Kees
>> Looks like I should go on vacation more often. :)
>>
>> I am generally opposed to fancy specification languages.
>> I support the explicit lsm= list specification because you
>> don't have to know any context to create a boot line that
>> will work, and be as close to what you've specified as possible
>> for the kernel configuration. One need look no further than
>> the mechanisms for setting POSIX ACLs for an example of
>> how to ensure a feature isn't used.
>>
>> Had we the foresight to make security= take a list of
>> modules when Yama was added we might have avoided some of
>> this brouhaha, but there was no reason to expect that stacking
>> was ever going to happen back then.
> This sounds like an "Ack" for you? :) I'll harass everyone in person
> in a couple days.

Acked-by: Casey Schaufler 

> Did you poke around at my combined series?
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing

I hope to do that on the plane later today.

> -Kees

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Nick Desaulniers]

On Mon, Oct 22, 2018 at 11:15 AM Bernd Petrovitsch
 wrote:
>
> Hi all!
>
> On 22/10/18 19:54, Nick Desaulniers wrote:
> > On Mon, Oct 22, 2018 at 10:50 AM Bernd Petrovitsch
> >  wrote:
> [...]
> >> PS: clang++ errors with "fallthrough annotation in unreachable code" if
> >> [[fallthrough]] is after an assert(). clang-devs there, please, the
> >> fallthrough doesn't really generated code (I hope;-).
> [...]
> > Can you send me a link to a simple reproducer in godbolt (godbolt.org)
> > and we'll take a look?
>
> Does https://godbolt.org/z/2Y4zIo do it - I'm a godbolt-newbie?

Moving the kernel folks to bcc, since we don't need to be discussing
C++ on LKML.
https://godbolt.org/z/B1fo9Z shows that this works as intended, for
cases that cannot be statically proven.  I guess I'm looking for a
more realistic code sample to show why putting a `break;` statement
there is untenable?

>
> For
>   snip  
> #include 
>
> int main(void)
> {
>   switch (1) {
>   default:
> assert(0);
> [[fallthrough]];
>   case 1:
> ;
>   }
>   return 0;
> }
>   snip  
> Just "clang++ -Wimplicit-fallthrough -Werror" it .
>
> MfG,
> Bernd
> --
> "I dislike type abstraction if it has no real reason. And saving
> on typing is not a good reason - if your typing speed is the main
> issue when you're coding, you're doing something seriously wrong."
> - Linus Torvalds



-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] doc: fix a typo in adding-syscalls.rst

[Jonathan Corbet]

On Thu, 18 Oct 2018 17:47:50 +0200
cor...@poussif.eu wrote:

> There was a typo in adding-syscalls.rst that could mislead developers
> to add a C filename in a makefile instead of an object filename.
> This error, while not keeping developers from contributing could slow
> the development process down by introducing build errors.
> 
> Signed-off-by: Guillaume Dore 

Applied, thanks.

jon

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Jonathan Corbet]

On Mon, 15 Oct 2018 02:55:49 -0700
Christoph Hellwig  wrote:

> > OK, I've had a long conversation with the LF lawyer, and she said clearly
> > that we really should not be introducing CC-SA material into the kernel
> > source tree.  It's a pain; I really do like CC-SA better for
> > documentation, but it's not GPL-compatible, and that creates a problem for
> > the processed docs.  
> 
> That was exactly my concern with this patchset.
> 
> Btw, I think we have the same issue with idr.rst, and unless we can
> relicense it we should drop it from the tree, as it actually includes
> kernel source files.

...and a significant DOC section at that, not just function prototypes.

I'd already asked Willy [CC'd] about this once, haven't gotten an answer
yet.  Hopefully we can address this once he comes back around.

Thanks,

jon

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Christoph Hellwig]

On Thu, Oct 11, 2018 at 11:27:35AM -0600, Jonathan Corbet wrote:
> On Sat, 6 Oct 2018 10:51:54 +1000
> Dave Chinner  wrote:
> 
> > Can you let us know whether the CC-by-SA 4.0 license is acceptible
> > or not? That's really the only thing that we need clarified at this
> > point - if it's OK I'll to pull this into the XFS tree for the 4.20
> > merge window. If not, we'll go back to the drawing board
> 
> OK, I've had a long conversation with the LF lawyer, and she said clearly
> that we really should not be introducing CC-SA material into the kernel
> source tree.  It's a pain; I really do like CC-SA better for
> documentation, but it's not GPL-compatible, and that creates a problem for
> the processed docs.

That was exactly my concern with this patchset.

Btw, I think we have the same issue with idr.rst, and unless we can
relicense it we should drop it from the tree, as it actually includes
kernel source files.

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Dave Chinner]

On Thu, Oct 11, 2018 at 11:27:35AM -0600, Jonathan Corbet wrote:
> On Sat, 6 Oct 2018 10:51:54 +1000 Dave Chinner
>  wrote:
> 
> > Can you let us know whether the CC-by-SA 4.0 license is
> > acceptible or not? That's really the only thing that we need
> > clarified at this point - if it's OK I'll to pull this into the
> > XFS tree for the 4.20 merge window. If not, we'll go back to the
> > drawing board
> 
> OK, I've had a long conversation with the LF lawyer, and she said
> clearly that we really should not be introducing CC-SA material
> into the kernel source tree.  It's a pain; I really do like CC-SA
> better for documentation, but it's not GPL-compatible, and that
> creates a problem for the processed docs.

Ok, thanks for following upon this, Jon. We'll just keep it all in
the existing external repo and work out what to do from there.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Jonathan Corbet]

On Sat, 6 Oct 2018 10:51:54 +1000
Dave Chinner  wrote:

> Can you let us know whether the CC-by-SA 4.0 license is acceptible
> or not? That's really the only thing that we need clarified at this
> point - if it's OK I'll to pull this into the XFS tree for the 4.20
> merge window. If not, we'll go back to the drawing board

OK, I've had a long conversation with the LF lawyer, and she said clearly
that we really should not be introducing CC-SA material into the kernel
source tree.  It's a pain; I really do like CC-SA better for
documentation, but it's not GPL-compatible, and that creates a problem for
the processed docs.

Sorry,

jon

Re: [PATCH 2/2] docs/vm: split memory hotplug notifier description to Documentation/core-api

[Mike Rapoport]

On Sun, Oct 07, 2018 at 08:46:40AM -0600, Jonathan Corbet wrote:
> On Fri,  5 Oct 2018 01:11:01 +0300
> Mike Rapoport  wrote:
> 
> > The memory hotplug notifier description is about kernel internals rather
> > than admin/user visible API. Place it appropriately.
> > 
> > Signed-off-by: Mike Rapoport 
> 
> One little nit...
> 
> >  Documentation/admin-guide/mm/memory-hotplug.rst| 83 
> > -
> >  Documentation/core-api/index.rst   |  2 +
> >  Documentation/core-api/memory-hotplug-notifier.rst | 84 
> > ++
> >  3 files changed, 86 insertions(+), 83 deletions(-)
> >  create mode 100644 Documentation/core-api/memory-hotplug-notifier.rst
> > 
> > diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst 
> > b/Documentation/admin-guide/mm/memory-hotplug.rst
> > index a33090c..0b9c83e 100644
> > --- a/Documentation/admin-guide/mm/memory-hotplug.rst
> > +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
> > @@ -31,7 +31,6 @@ be changed often.
> >  6.1 Memory offline and ZONE_MOVABLE
> >  6.2. How to offline memory
> >7. Physical memory remove
> > -  8. Memory hotplug event notifier
> >9. Future Work List
> 
> That leaves a gap in the numbering here.
> 
> In general, the best solution to this sort of issue is to take the TOC out
> entirely and let Sphinx worry about generating it.  People tend not to
> think about updating the TOC when they make changes elsewhere, so it often
> goes out of sync with the rest of the document anyway.
> 
> I'll apply these, but please feel free to send a patch to fix this up.

Sure, below
 
> Thanks,
> 
> jon
> 

>From 45ef951bd04e9d440a0158f991a188fc8ca6e7d4 Mon Sep 17 00:00:00 2001
From: Mike Rapoport 
Date: Sun, 7 Oct 2018 19:29:00 +0300
Subject: [PATCH] docs/admin-guide: memory-hotplug: remove table of contents

Remove "manual" table of contents and leave only the ReST tag so that
Sphinx will take care of TOC generation.

Signed-off-by: Mike Rapoport 
---
 Documentation/admin-guide/mm/memory-hotplug.rst | 21 -
 1 file changed, 21 deletions(-)

diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst 
b/Documentation/admin-guide/mm/memory-hotplug.rst
index 0b9c83e..25157ae 100644
--- a/Documentation/admin-guide/mm/memory-hotplug.rst
+++ b/Documentation/admin-guide/mm/memory-hotplug.rst
@@ -13,27 +13,6 @@ be changed often.
 
 .. contents:: :local:
 
-.. CONTENTS
-
-  1. Introduction
-1.1 Purpose of memory hotplug
-1.2. Phases of memory hotplug
-1.3. Unit of Memory online/offline operation
-  2. Kernel Configuration
-  3. sysfs files for memory hotplug
-  4. Physical memory hot-add phase
-4.1 Hardware(Firmware) Support
-4.2 Notify memory hot-add event by hand
-  5. Logical Memory hot-add phase
-5.1. State of memory
-5.2. How to online memory
-  6. Logical memory remove
-6.1 Memory offline and ZONE_MOVABLE
-6.2. How to offline memory
-  7. Physical memory remove
-  9. Future Work List
-
-
 .. note::
 
 (1) x86_64's has special implementation for memory hotplug.
-- 
2.7.4

Re: [PATCH] docs: improve readability for people with poorer eyesight

[Jonathan Corbet]

On Thu, 4 Oct 2018 18:06:03 -0700
"Darrick J. Wong"  wrote:

> o my eyesight still hasn't fully recovered, so in the meantime it's
> been difficult to read the online documentation.  Here's some stylesheet
> overrides I've been using to make it easier for me to read them:
> https://djwong.org/docs/kdoc/index.html
> 
> ---
> From: Darrick J. Wong 
> 
> My eyesight is not in good shape, which means that I have difficulty
> reading the online Linux documentation.  Specifically, body text is
> oddly small compared to list items and the contrast of various text
> elements is too low for me to be able to see easily.
> 
> Therefore, alter the HTML theme overrides to make the text larger and
> increase the contrast for better visibility, and trust the typeface
> choices of the reader's browser.
> 
> For the PDF output, increase the text size, use a sans-serif typeface
> for sans-serif text, and use a serif typeface for "roman" serif text.
> 
> Signed-off-by: Darrick J. Wong 

I've been wanting to find some time to work on our stylesheets for years;
what we have now is far from ideal (or attractive) IMO.  This is a good
step in the right direction - applied, thanks.

jon

Re: [PATCH 2/2] docs/vm: split memory hotplug notifier description to Documentation/core-api

[Jonathan Corbet]

On Fri,  5 Oct 2018 01:11:01 +0300
Mike Rapoport  wrote:

> The memory hotplug notifier description is about kernel internals rather
> than admin/user visible API. Place it appropriately.
> 
> Signed-off-by: Mike Rapoport 

One little nit...

>  Documentation/admin-guide/mm/memory-hotplug.rst| 83 -
>  Documentation/core-api/index.rst   |  2 +
>  Documentation/core-api/memory-hotplug-notifier.rst | 84 
> ++
>  3 files changed, 86 insertions(+), 83 deletions(-)
>  create mode 100644 Documentation/core-api/memory-hotplug-notifier.rst
> 
> diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst 
> b/Documentation/admin-guide/mm/memory-hotplug.rst
> index a33090c..0b9c83e 100644
> --- a/Documentation/admin-guide/mm/memory-hotplug.rst
> +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
> @@ -31,7 +31,6 @@ be changed often.
>  6.1 Memory offline and ZONE_MOVABLE
>  6.2. How to offline memory
>7. Physical memory remove
> -  8. Memory hotplug event notifier
>9. Future Work List

That leaves a gap in the numbering here.

In general, the best solution to this sort of issue is to take the TOC out
entirely and let Sphinx worry about generating it.  People tend not to
think about updating the TOC when they make changes elsewhere, so it often
goes out of sync with the rest of the document anyway.

I'll apply these, but please feel free to send a patch to fix this up.

Thanks,

jon

Re: [PATCH 2/2] docs: promote the ext4 data structures book to top level

[Jonathan Corbet]

On Fri, 5 Oct 2018 19:49:52 -0400
"Theodore Y. Ts'o"  wrote:

> On Thu, Oct 04, 2018 at 05:59:44PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong 
> > 
> > Move the ext4 data structures book to Documentation/filesystems/ext4/
> > since the administrative information moved elsewhere.
> > 
> > Signed-off-by: Darrick J. Wong   
> 
> Thanks, applied and pushed out to the ext4.git tree.
> 
> Randy, Jon: the original patch didn't make it past vger.kernel.org
> because it was too large (it was moving a lot of files around).  It
> looked fine to me, but if you want to take a look it should be on the
> dev branch of the ext4.git tree.

FWIW, from a quick look it seems fine to me.

   Acked-by: Jonathan Corbet 

(though I expect it's too late to add that).

jon

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Jonathan Corbet]

On Sat, 6 Oct 2018 06:29:51 -0700
Matthew Wilcox  wrote:

> I had an informal chat with Bradley Kuhn at LinuxCon Japan about using
> CC-BY-SA-4.0 and he indicated that I was probably better off using the
> GPL-2(+) for documentation.  I've changed the XArray documentation from
> CC-BY-SA-4.0 to GPL-2+.

Would you consider doing the same for Documentation/core-api/idr.rst?
That's the only CC-SA SPDX tag in the kernel now, and it's a clear
example of just what I'm worried about: it pulls in a nice DOC section
from the code when you run Sphinx on it, so we're not just talking
function prototypes here.  I was likely to come knocking on your door
after my upcoming conversation anyway...:)

Thanks,

jon

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Matthew Wilcox]

On Sat, Oct 06, 2018 at 10:51:54AM +1000, Dave Chinner wrote:
> On Wed, Oct 03, 2018 at 09:18:11PM -0700, Darrick J. Wong wrote:
> > Hi all,
> > 
> > This series converts the existing in-kernel xfs documentation to rst
> > format, links it in with the rest of the kernel's rst documetation, and
> > then begins pulling in the contents of the Data Structures & Algorithms
> > book from the xfs-documentation git tree.  No changes are made to the
> > text during the import process except to fix things that the conversion
> > process (asciidoctor + pandoc) didn't do correctly.  The goal of this
> > series is to tie together the XFS code with the on-disk format
> > documentation for the features supported by the code.
> > 
> > I've built the docs and put them here, in case you hate reading rst:
> > https://djwong.org/docs/kdoc/admin-guide/xfs.html
> > https://djwong.org/docs/kdoc/filesystems/xfs-data-structures/index.html
> > 
> > I've posted a branch here because the png import patch is huge:
> > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=docs-4.20-merge
> > 
> > The patchset should apply cleanly against 4.19-rc6.  Comments and
> > questions are, as always, welcome.
> 
> Jon,
> 
> Can you let us know whether the CC-by-SA 4.0 license is acceptible
> or not? That's really the only thing that we need clarified at this
> point - if it's OK I'll to pull this into the XFS tree for the 4.20
> merge window. If not, we'll go back to the drawing board

This is (obviously) not legal advice.

I had an informal chat with Bradley Kuhn at LinuxCon Japan about using
CC-BY-SA-4.0 and he indicated that I was probably better off using the
GPL-2(+) for documentation.  I've changed the XArray documentation from
CC-BY-SA-4.0 to GPL-2+.

YMMV, defer to the LF lawyer, but I thought it worth providing a data
point.

Re: [PATCH v5 00/15] Compiler Attributes

[Miguel Ojeda]

On Sat, Oct 6, 2018 at 9:13 AM Sedat Dilek  wrote:
>
> Hi Miguel,
>
> In my testoings I am booting in QEMU and on bare metal.
> Both tests were successful.

Wow! I only wanted to confirm it booted and/or run for a while -- but
having more information is always good. Thanks a *lot*!

I will add a reference to your email in the commits.

Cheers,
Miguel

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Dave Chinner]

On Fri, Oct 05, 2018 at 07:01:20PM -0600, Jonathan Corbet wrote:
> On Sat, 6 Oct 2018 10:51:54 +1000
> Dave Chinner  wrote:
> 
> > Can you let us know whether the CC-by-SA 4.0 license is acceptible
> > or not? That's really the only thing that we need clarified at this
> > point - if it's OK I'll to pull this into the XFS tree for the 4.20
> > merge window. If not, we'll go back to the drawing board
> 
> I remain pretty concerned about it, to tell the truth.  Rather than
> continue to guess, though, I've called for help, and will be talking with
> the LF lawyer about this next Thursday.  Before then, I can't say anything
> except "I don't think this works..."
> 
> Will let you know what I hear.

Thanks for the update, Jon. I'll put this on the backburner until I
hear back from you.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Jonathan Corbet]

On Sat, 6 Oct 2018 10:51:54 +1000
Dave Chinner  wrote:

> Can you let us know whether the CC-by-SA 4.0 license is acceptible
> or not? That's really the only thing that we need clarified at this
> point - if it's OK I'll to pull this into the XFS tree for the 4.20
> merge window. If not, we'll go back to the drawing board

I remain pretty concerned about it, to tell the truth.  Rather than
continue to guess, though, I've called for help, and will be talking with
the LF lawyer about this next Thursday.  Before then, I can't say anything
except "I don't think this works..."

Will let you know what I hear.

jon

Re: [PATCH v2 00/22] xfs-4.20: major documentation surgery

[Dave Chinner]

On Wed, Oct 03, 2018 at 09:18:11PM -0700, Darrick J. Wong wrote:
> Hi all,
> 
> This series converts the existing in-kernel xfs documentation to rst
> format, links it in with the rest of the kernel's rst documetation, and
> then begins pulling in the contents of the Data Structures & Algorithms
> book from the xfs-documentation git tree.  No changes are made to the
> text during the import process except to fix things that the conversion
> process (asciidoctor + pandoc) didn't do correctly.  The goal of this
> series is to tie together the XFS code with the on-disk format
> documentation for the features supported by the code.
> 
> I've built the docs and put them here, in case you hate reading rst:
> https://djwong.org/docs/kdoc/admin-guide/xfs.html
> https://djwong.org/docs/kdoc/filesystems/xfs-data-structures/index.html
> 
> I've posted a branch here because the png import patch is huge:
> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=docs-4.20-merge
> 
> The patchset should apply cleanly against 4.19-rc6.  Comments and
> questions are, as always, welcome.

Jon,

Can you let us know whether the CC-by-SA 4.0 license is acceptible
or not? That's really the only thing that we need clarified at this
point - if it's OK I'll to pull this into the XFS tree for the 4.20
merge window. If not, we'll go back to the drawing board

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] docs: improve readability for people with poorer eyesight

[Dave Chinner]

On Thu, Oct 04, 2018 at 06:06:03PM -0700, Darrick J. Wong wrote:
> Hi,
> 
> So my eyesight still hasn't fully recovered, so in the meantime it's
> been difficult to read the online documentation.  Here's some stylesheet
> overrides I've been using to make it easier for me to read them:
> https://djwong.org/docs/kdoc/index.html
> 
> ---
> From: Darrick J. Wong 
> 
> My eyesight is not in good shape, which means that I have difficulty
> reading the online Linux documentation.  Specifically, body text is
> oddly small compared to list items and the contrast of various text
> elements is too low for me to be able to see easily.
> 
> Therefore, alter the HTML theme overrides to make the text larger and
> increase the contrast for better visibility, and trust the typeface
> choices of the reader's browser.
> 
> For the PDF output, increase the text size, use a sans-serif typeface
> for sans-serif text, and use a serif typeface for "roman" serif text.
> 
> Signed-off-by: Darrick J. Wong 

This fixes problems I noticed when trying to review the built html
documentation - the inconsistent font sizes on my high-dpi monitor
made it almost impossible to read even though I have no eyesight
problems

Acked-by: Dave Chinner 

-Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 2/2] docs: promote the ext4 data structures book to top level

[Theodore Y. Ts'o]

On Thu, Oct 04, 2018 at 05:59:44PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong 
> 
> Move the ext4 data structures book to Documentation/filesystems/ext4/
> since the administrative information moved elsewhere.
> 
> Signed-off-by: Darrick J. Wong 

Thanks, applied and pushed out to the ext4.git tree.

Randy, Jon: the original patch didn't make it past vger.kernel.org
because it was too large (it was moving a lot of files around).  It
looked fine to me, but if you want to take a look it should be on the
dev branch of the ext4.git tree.

- Ted

Re: [PATCH 0/2] ext4: even more documentation fixes

[Randy Dunlap]

On 10/5/18 8:22 AM, Theodore Y. Ts'o wrote:
> On Thu, Oct 04, 2018 at 07:48:31PM -0700, Randy Dunlap wrote:
>> Hi Darrick,
>>
>> I don't see patch 2/2 anywhere (my inbox, email archives)...
> 
> Probably because it's moving a lot of files around, so the diffs were 276k.

Oh, yeah.  Thanks.

-- 
~Randy

Re: [PATCH 0/2] ext4: even more documentation fixes

[Theodore Y. Ts'o]

On Thu, Oct 04, 2018 at 07:48:31PM -0700, Randy Dunlap wrote:
> Hi Darrick,
> 
> I don't see patch 2/2 anywhere (my inbox, email archives)...

Probably because it's moving a lot of files around, so the diffs were 276k.



> 
> -- 
> ~Randy

Re: [PATCH 0/2] ext4: even more documentation fixes

[Randy Dunlap]

On 10/4/18 5:59 PM, Darrick J. Wong wrote:
> Hi all,
> 
> This series fixes some problems that were brought up during review for
> the XFS documentation which I hadn't known about when pushing the ext4
> documentation during the 4.19 cycle.
> 
> The first patch moves the ext4 mount option and sysfs knob information
> into the Linux administration guide.
> 
> The second patch moves the ext4 Data Structures & Algorithms book up a
> level since it's a self-contained documentation book.
> 
> I've built the docs and put them here, in case you hate reading rst:
> https://djwong.org/docs/kdoc/filesystems/ext4/index.html
> 
> The patchset should apply cleanly against 4.19-rc6.  Comments and
> questions are, as always, welcome.

Hi Darrick,

I don't see patch 2/2 anywhere (my inbox, email archives)...

-- 
~Randy

Re: [PATCH v5 00/15] Compiler Attributes

[Miguel Ojeda]

Hi Sedat,

On Mon, Sep 24, 2018 at 10:46 AM Sedat Dilek  wrote:
>
> [ Please CC me I am not subcribed to this ML ]
>
> Quote from :
>
> Tested-by: Sedat Dilek  (against Linux
> v4.19-rc5 and built with LLVM/Clang v7)

Thanks a lot for testing! Which configuration roughly (e.g.
allmodconfig)? Did you boot it & run it for a while?

Cheers,
Miguel

Re: [PATCH] doc: Fix acronym "FEKEK" in ecryptfs

[Jonathan Corbet]

On Mon, 17 Sep 2018 11:34:48 +0200
Felix Eckhofer  wrote:

> "FEFEK" was incorrectly used as acronym for "File Encryption Key
> Encryption Key". This replaces all occurences with "FEKEK".
> 
> Signed-off-by: Felix Eckhofer 
> ---
>  Documentation/security/keys/ecryptfs.rst | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Applied, thanks.

jon

Re: [PATCH] Documentation: filesystems: remove reminiscences of POHMELFS

[Evgeniy Polyakov]

20.09.2018, 16:11, "Greg Kroah-Hartman" :

>>  Since likely any delopment of the filesystem is halted, the change removes
>>  the abandoned POHMELFS documentation from the kernel tree.
>>
>>  Signed-off-by: Vladimir Zapolskiy 
>
> I've taken this through the staging tree as that is where this code used
> to live. Thanks for the cleanup.

Thank you for picking it up

Re: [PATCH] Documentation: filesystems: remove reminiscences of POHMELFS

[Greg Kroah-Hartman]

On Wed, Sep 12, 2018 at 03:44:19PM +0300, Vladimir Zapolskiy wrote:
> The POHMELFS filesystem was removed in 2012 by commit 67435319866f8
> ("staging: pohmelfs: remove drivers/staging/pohmelfs") promising that
> a newer version will be included to the kernel, but unfortunately
> it didn't happen.
> 
> Since likely any delopment of the filesystem is halted, the change removes
> the abandoned POHMELFS documentation from the kernel tree.
> 
> Signed-off-by: Vladimir Zapolskiy 

I've taken this through the staging tree as that is where this code used
to live.  Thanks for the cleanup.

greg k-h

Re: [PATCH 00/19] mtd: rawnand: API cleanup (2nd batch)

[Miquel Raynal]

Hi Boris,

Boris Brezillon  wrote on Mon, 17 Sep 2018
10:29:39 +0200:

> On Sat, 15 Sep 2018 19:54:40 +0200
> Miquel Raynal  wrote:
> 
> > Hi Boris,
> > 
> > Boris Brezillon  wrote on Fri,  7 Sep 2018
> > 00:38:32 +0200:
> >   
> > > Hello,
> > > 
> > > This is the 2nd batch of API cleanup patches. This time we move
> > > deprecated hooks/fields to the nand_legacy struct, and then move some
> > > of the code found in nand_base.c into separate source/header files.
> > > 
> > > With this new organization, new comers should more easily identify the
> > > bits they can use in their NAND controller drivers and those that are
> > > only meant for core code. It also shrink a bit nand_base.c which was
> > > over 6000 lines of code.
> > > 
> > > Note that existing coding style issues (reported by checkpatch) in arch
> > > or driver code are intentionally not fixed to keep the series focused
> > > on the API/core cleanup.
> > > 
> > > Regards,
> > > 
> > > Boris
> > > 
> > > Boris Brezillon (19):
> > >   mtd: rawnand: Leave chip->IO_ADDR_{R,W} to NULL when unused
> > >   mtd: rawnand: Create a legacy struct and move ->IO_ADDR_{R,W} there
> > >   mtd: rawnand: Deprecate ->{read,write}_{byte,buf}() hooks
> > >   mtd: rawnand: Deprecate ->cmd_ctrl() and ->cmdfunc()
> > >   mtd: rawnand: Deprecate ->dev_ready() and ->waitfunc()
> > >   mtd: rawnand: Deprecate ->block_{bad,markbad}() hooks
> > >   mtd: rawnand: Deprecate ->erase()
> > >   mtd: rawnand: Deprecate ->{set,get}_features() hooks
> > >   mtd: rawnand: Deprecate ->chip_delay
> > >   mtd: rawnand: Move function prototypes after struct declarations
> > >   mtd: rawnand: Get rid of nand_flash_dev forward declation
> > >   mtd: rawnand: Get rid of the duplicate nand_chip forward declaration
> > >   mtd: rawnand: Get rid of a few unused definitions
> > >   mtd: rawnand: Move platform_nand_xxx definitions out of rawnand.h
> > >   mtd: rawnand: Inline onfi_get_async_timing_mode()
> > >   mtd: rawnand: Keep all internal stuff private
> > >   mtd: rawnand: Move legacy code to nand_legacy.c
> > >   mtd: rawnand: Move ONFI code to nand_onfi.c
> > >   mtd: rawnand: Move JEDEC code to nand_jedec.c
> > > 
> > >  Documentation/driver-api/mtdnand.rst |   30 +-
> > >  arch/arm/mach-ep93xx/snappercl15.c   |8 +-
> > >  arch/arm/mach-ep93xx/ts72xx.c|9 +-
> > >  arch/arm/mach-imx/mach-qong.c|6 +-
> > >  arch/arm/mach-ixp4xx/ixdp425-setup.c |2 +-
> > >  arch/arm/mach-omap1/board-fsample.c  |3 +-
> > >  arch/arm/mach-omap1/board-h2.c   |3 +-
> > >  arch/arm/mach-omap1/board-h3.c   |2 +-
> > >  arch/arm/mach-omap1/board-nand.c |2 +-
> > >  arch/arm/mach-omap1/board-perseus2.c |3 +-
> > >  arch/arm/mach-orion5x/ts78xx-setup.c |9 +-
> > >  arch/arm/mach-pxa/balloon3.c |5 +-
> > >  arch/arm/mach-pxa/em-x270.c  |9 +-
> > >  arch/arm/mach-pxa/palmtx.c   |5 +-
> > >  arch/mips/alchemy/devboards/db1200.c |9 +-
> > >  arch/mips/alchemy/devboards/db1300.c |9 +-
> > >  arch/mips/alchemy/devboards/db1550.c |9 +-
> > >  arch/mips/netlogic/xlr/platform-flash.c  |3 +-
> > >  arch/mips/pnx833x/common/platform.c  |5 +-
> > >  arch/mips/rb532/devices.c|5 +-
> > >  arch/sh/boards/mach-migor/setup.c|8 +-
> > >  drivers/mtd/nand/raw/Makefile|4 +-
> > >  drivers/mtd/nand/raw/ams-delta.c |   22 +-
> > >  drivers/mtd/nand/raw/atmel/nand-controller.c |   22 +-
> > >  drivers/mtd/nand/raw/au1550nd.c  |   43 +-
> > >  drivers/mtd/nand/raw/bcm47xxnflash/ops_bcm4706.c |   22 +-
> > >  drivers/mtd/nand/raw/brcmnand/brcmnand.c |   15 +-
> > >  drivers/mtd/nand/raw/cafe_nand.c |   22 +-
> > >  drivers/mtd/nand/raw/cmx270_nand.c   |   28 +-
> > >  drivers/mtd/nand/raw/cs553x_nand.c   |   42 +-
> > >  drivers/mtd/nand/raw/davinci_nand.c  |   34 +-
> > >  drivers/mtd/nand/raw/denali.c|   23 +-
> > >  drivers/mtd/nand/raw/diskonchip.c|   50 +-
> > >  drivers/mtd/nand/raw/fsl_elbc_nand.c |   18 +-
> > >  drivers/mtd/nand/raw/fsl_ifc_nand.c  |   24 +-
> > >  drivers/mtd/nand/raw/fsl_upm.c   |   30 +-
> > >  drivers/mtd/nand/raw/fsmc_nand.c |1 -
> > >  drivers/mtd/nand/raw/gpio.c  |   16 +-
> > >  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c   |   22 +-
> > >  drivers/mtd/nand/raw/hisi504_nand.c  |   18 +-
> > >  drivers/mtd/nand/raw/internals.h |  114 ++
> > >  drivers/mtd/nand/raw/jz4740_nand.c   |   14 +-
> > >  drivers/mtd/nand/raw/jz4780_nand.c

Re: [PATCH 00/19] mtd: rawnand: API cleanup (2nd batch)

[Boris Brezillon]

On Sat, 15 Sep 2018 19:54:40 +0200
Miquel Raynal  wrote:

> Hi Boris,
> 
> Boris Brezillon  wrote on Fri,  7 Sep 2018
> 00:38:32 +0200:
> 
> > Hello,
> > 
> > This is the 2nd batch of API cleanup patches. This time we move
> > deprecated hooks/fields to the nand_legacy struct, and then move some
> > of the code found in nand_base.c into separate source/header files.
> > 
> > With this new organization, new comers should more easily identify the
> > bits they can use in their NAND controller drivers and those that are
> > only meant for core code. It also shrink a bit nand_base.c which was
> > over 6000 lines of code.
> > 
> > Note that existing coding style issues (reported by checkpatch) in arch
> > or driver code are intentionally not fixed to keep the series focused
> > on the API/core cleanup.
> > 
> > Regards,
> > 
> > Boris
> > 
> > Boris Brezillon (19):
> >   mtd: rawnand: Leave chip->IO_ADDR_{R,W} to NULL when unused
> >   mtd: rawnand: Create a legacy struct and move ->IO_ADDR_{R,W} there
> >   mtd: rawnand: Deprecate ->{read,write}_{byte,buf}() hooks
> >   mtd: rawnand: Deprecate ->cmd_ctrl() and ->cmdfunc()
> >   mtd: rawnand: Deprecate ->dev_ready() and ->waitfunc()
> >   mtd: rawnand: Deprecate ->block_{bad,markbad}() hooks
> >   mtd: rawnand: Deprecate ->erase()
> >   mtd: rawnand: Deprecate ->{set,get}_features() hooks
> >   mtd: rawnand: Deprecate ->chip_delay
> >   mtd: rawnand: Move function prototypes after struct declarations
> >   mtd: rawnand: Get rid of nand_flash_dev forward declation
> >   mtd: rawnand: Get rid of the duplicate nand_chip forward declaration
> >   mtd: rawnand: Get rid of a few unused definitions
> >   mtd: rawnand: Move platform_nand_xxx definitions out of rawnand.h
> >   mtd: rawnand: Inline onfi_get_async_timing_mode()
> >   mtd: rawnand: Keep all internal stuff private
> >   mtd: rawnand: Move legacy code to nand_legacy.c
> >   mtd: rawnand: Move ONFI code to nand_onfi.c
> >   mtd: rawnand: Move JEDEC code to nand_jedec.c
> > 
> >  Documentation/driver-api/mtdnand.rst |   30 +-
> >  arch/arm/mach-ep93xx/snappercl15.c   |8 +-
> >  arch/arm/mach-ep93xx/ts72xx.c|9 +-
> >  arch/arm/mach-imx/mach-qong.c|6 +-
> >  arch/arm/mach-ixp4xx/ixdp425-setup.c |2 +-
> >  arch/arm/mach-omap1/board-fsample.c  |3 +-
> >  arch/arm/mach-omap1/board-h2.c   |3 +-
> >  arch/arm/mach-omap1/board-h3.c   |2 +-
> >  arch/arm/mach-omap1/board-nand.c |2 +-
> >  arch/arm/mach-omap1/board-perseus2.c |3 +-
> >  arch/arm/mach-orion5x/ts78xx-setup.c |9 +-
> >  arch/arm/mach-pxa/balloon3.c |5 +-
> >  arch/arm/mach-pxa/em-x270.c  |9 +-
> >  arch/arm/mach-pxa/palmtx.c   |5 +-
> >  arch/mips/alchemy/devboards/db1200.c |9 +-
> >  arch/mips/alchemy/devboards/db1300.c |9 +-
> >  arch/mips/alchemy/devboards/db1550.c |9 +-
> >  arch/mips/netlogic/xlr/platform-flash.c  |3 +-
> >  arch/mips/pnx833x/common/platform.c  |5 +-
> >  arch/mips/rb532/devices.c|5 +-
> >  arch/sh/boards/mach-migor/setup.c|8 +-
> >  drivers/mtd/nand/raw/Makefile|4 +-
> >  drivers/mtd/nand/raw/ams-delta.c |   22 +-
> >  drivers/mtd/nand/raw/atmel/nand-controller.c |   22 +-
> >  drivers/mtd/nand/raw/au1550nd.c  |   43 +-
> >  drivers/mtd/nand/raw/bcm47xxnflash/ops_bcm4706.c |   22 +-
> >  drivers/mtd/nand/raw/brcmnand/brcmnand.c |   15 +-
> >  drivers/mtd/nand/raw/cafe_nand.c |   22 +-
> >  drivers/mtd/nand/raw/cmx270_nand.c   |   28 +-
> >  drivers/mtd/nand/raw/cs553x_nand.c   |   42 +-
> >  drivers/mtd/nand/raw/davinci_nand.c  |   34 +-
> >  drivers/mtd/nand/raw/denali.c|   23 +-
> >  drivers/mtd/nand/raw/diskonchip.c|   50 +-
> >  drivers/mtd/nand/raw/fsl_elbc_nand.c |   18 +-
> >  drivers/mtd/nand/raw/fsl_ifc_nand.c  |   24 +-
> >  drivers/mtd/nand/raw/fsl_upm.c   |   30 +-
> >  drivers/mtd/nand/raw/fsmc_nand.c |1 -
> >  drivers/mtd/nand/raw/gpio.c  |   16 +-
> >  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c   |   22 +-
> >  drivers/mtd/nand/raw/hisi504_nand.c  |   18 +-
> >  drivers/mtd/nand/raw/internals.h |  114 ++
> >  drivers/mtd/nand/raw/jz4740_nand.c   |   14 +-
> >  drivers/mtd/nand/raw/jz4780_nand.c   |   10 +-
> >  drivers/mtd/nand/raw/lpc32xx_mlc.c   |   12 +-
> >  drivers/mtd/nand/raw/lpc32xx_slc.c   |   26 +-
> >  drivers/mtd/nand/raw/mpc5121_nfc.c   |   14 +-
> >  drivers/mtd/nand/raw/mtk_nand.c  

Re: [PATCH 00/19] mtd: rawnand: API cleanup (2nd batch)

[Miquel Raynal]

Hi Boris,

Boris Brezillon  wrote on Fri,  7 Sep 2018
00:38:32 +0200:

> Hello,
> 
> This is the 2nd batch of API cleanup patches. This time we move
> deprecated hooks/fields to the nand_legacy struct, and then move some
> of the code found in nand_base.c into separate source/header files.
> 
> With this new organization, new comers should more easily identify the
> bits they can use in their NAND controller drivers and those that are
> only meant for core code. It also shrink a bit nand_base.c which was
> over 6000 lines of code.
> 
> Note that existing coding style issues (reported by checkpatch) in arch
> or driver code are intentionally not fixed to keep the series focused
> on the API/core cleanup.
> 
> Regards,
> 
> Boris
> 
> Boris Brezillon (19):
>   mtd: rawnand: Leave chip->IO_ADDR_{R,W} to NULL when unused
>   mtd: rawnand: Create a legacy struct and move ->IO_ADDR_{R,W} there
>   mtd: rawnand: Deprecate ->{read,write}_{byte,buf}() hooks
>   mtd: rawnand: Deprecate ->cmd_ctrl() and ->cmdfunc()
>   mtd: rawnand: Deprecate ->dev_ready() and ->waitfunc()
>   mtd: rawnand: Deprecate ->block_{bad,markbad}() hooks
>   mtd: rawnand: Deprecate ->erase()
>   mtd: rawnand: Deprecate ->{set,get}_features() hooks
>   mtd: rawnand: Deprecate ->chip_delay
>   mtd: rawnand: Move function prototypes after struct declarations
>   mtd: rawnand: Get rid of nand_flash_dev forward declation
>   mtd: rawnand: Get rid of the duplicate nand_chip forward declaration
>   mtd: rawnand: Get rid of a few unused definitions
>   mtd: rawnand: Move platform_nand_xxx definitions out of rawnand.h
>   mtd: rawnand: Inline onfi_get_async_timing_mode()
>   mtd: rawnand: Keep all internal stuff private
>   mtd: rawnand: Move legacy code to nand_legacy.c
>   mtd: rawnand: Move ONFI code to nand_onfi.c
>   mtd: rawnand: Move JEDEC code to nand_jedec.c
> 
>  Documentation/driver-api/mtdnand.rst |   30 +-
>  arch/arm/mach-ep93xx/snappercl15.c   |8 +-
>  arch/arm/mach-ep93xx/ts72xx.c|9 +-
>  arch/arm/mach-imx/mach-qong.c|6 +-
>  arch/arm/mach-ixp4xx/ixdp425-setup.c |2 +-
>  arch/arm/mach-omap1/board-fsample.c  |3 +-
>  arch/arm/mach-omap1/board-h2.c   |3 +-
>  arch/arm/mach-omap1/board-h3.c   |2 +-
>  arch/arm/mach-omap1/board-nand.c |2 +-
>  arch/arm/mach-omap1/board-perseus2.c |3 +-
>  arch/arm/mach-orion5x/ts78xx-setup.c |9 +-
>  arch/arm/mach-pxa/balloon3.c |5 +-
>  arch/arm/mach-pxa/em-x270.c  |9 +-
>  arch/arm/mach-pxa/palmtx.c   |5 +-
>  arch/mips/alchemy/devboards/db1200.c |9 +-
>  arch/mips/alchemy/devboards/db1300.c |9 +-
>  arch/mips/alchemy/devboards/db1550.c |9 +-
>  arch/mips/netlogic/xlr/platform-flash.c  |3 +-
>  arch/mips/pnx833x/common/platform.c  |5 +-
>  arch/mips/rb532/devices.c|5 +-
>  arch/sh/boards/mach-migor/setup.c|8 +-
>  drivers/mtd/nand/raw/Makefile|4 +-
>  drivers/mtd/nand/raw/ams-delta.c |   22 +-
>  drivers/mtd/nand/raw/atmel/nand-controller.c |   22 +-
>  drivers/mtd/nand/raw/au1550nd.c  |   43 +-
>  drivers/mtd/nand/raw/bcm47xxnflash/ops_bcm4706.c |   22 +-
>  drivers/mtd/nand/raw/brcmnand/brcmnand.c |   15 +-
>  drivers/mtd/nand/raw/cafe_nand.c |   22 +-
>  drivers/mtd/nand/raw/cmx270_nand.c   |   28 +-
>  drivers/mtd/nand/raw/cs553x_nand.c   |   42 +-
>  drivers/mtd/nand/raw/davinci_nand.c  |   34 +-
>  drivers/mtd/nand/raw/denali.c|   23 +-
>  drivers/mtd/nand/raw/diskonchip.c|   50 +-
>  drivers/mtd/nand/raw/fsl_elbc_nand.c |   18 +-
>  drivers/mtd/nand/raw/fsl_ifc_nand.c  |   24 +-
>  drivers/mtd/nand/raw/fsl_upm.c   |   30 +-
>  drivers/mtd/nand/raw/fsmc_nand.c |1 -
>  drivers/mtd/nand/raw/gpio.c  |   16 +-
>  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c   |   22 +-
>  drivers/mtd/nand/raw/hisi504_nand.c  |   18 +-
>  drivers/mtd/nand/raw/internals.h |  114 ++
>  drivers/mtd/nand/raw/jz4740_nand.c   |   14 +-
>  drivers/mtd/nand/raw/jz4780_nand.c   |   10 +-
>  drivers/mtd/nand/raw/lpc32xx_mlc.c   |   12 +-
>  drivers/mtd/nand/raw/lpc32xx_slc.c   |   26 +-
>  drivers/mtd/nand/raw/mpc5121_nfc.c   |   14 +-
>  drivers/mtd/nand/raw/mtk_nand.c  |   12 +-
>  drivers/mtd/nand/raw/mxc_nand.c  |   20 +-
>  drivers/mtd/nand/raw/nand_amd.c  |2 +-
>  drivers/mtd/nand/raw/nand_base.c | 1260 
> +++---
>  

Re: [PATCH] Documentation: fix image_size default value

[Rafael J. Wysocki]

On Saturday, September 1, 2018 6:51:15 AM CEST Vladimir D. Seleznev wrote:
> This commit updates the default value of /sys/power/image_size in
> the documentation.
> 
> Since ac5c24ec1e983313ef0015258fba6f630e54e7cn the `image_size' value is
> set to about 2/5 of RAM, according to kernel/power/snapshot.c:
> 
>   image_size = ((totalram_pages * 2) / 5) * PAGE_SIZE;
> 
> but this change was not reflected everywhere in the documentation.
> 
> Signed-off-by: Vladimir D. Seleznev 
> ---
>  Documentation/ABI/testing/sysfs-power | 2 +-
>  Documentation/power/swsusp.txt| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-power 
> b/Documentation/ABI/testing/sysfs-power
> index 2f813d644c69..18b7dc929234 100644
> --- a/Documentation/ABI/testing/sysfs-power
> +++ b/Documentation/ABI/testing/sysfs-power
> @@ -99,7 +99,7 @@ Description:
>   this file, the suspend image will be as small as possible.
>  
>   Reading from this file will display the current image size
> - limit, which is set to 500 MB by default.
> + limit, which is set to around 2/5 of available RAM by default.
>  
>  What:/sys/power/pm_trace
>  Date:August 2006
> diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
> index cc87adf44c0a..236d1fb13640 100644
> --- a/Documentation/power/swsusp.txt
> +++ b/Documentation/power/swsusp.txt
> @@ -56,7 +56,7 @@ If you want to limit the suspend image size to N bytes, do
>  
>  echo N > /sys/power/image_size
>  
> -before suspend (it is limited to 500 MB by default).
> +before suspend (it is limited to around 2/5 of available RAM by default).
>  
>  . The resume process checks for the presence of the resume device,
>  if found, it then checks the contents for the hibernation image signature.
> 

Applied, thanks!

Re: nodocs in 4.19-rcX

[Randy Dunlap]

On 9/11/18 8:25 AM, Jonathan Corbet wrote:
> On Mon, 10 Sep 2018 15:51:20 -0700
> Randy Dunlap  wrote:
> 
>> 4.19-rc contains some users of :nodocs: but that is not recognized yet,
>> so we get:
>>
>> lnx-419-rc3/Documentation/core-api/boot-time-mm.rst:78: ERROR: Error in 
>> "kernel-doc" directive:
>> unknown option: "nodocs".
>>
>> .. kernel-doc:: mm/bootmem.c
>>:nodocs:
>>
>> lnx-419-rc3/Documentation/core-api/boot-time-mm.rst:91: ERROR: Error in 
>> "kernel-doc" directive:
>> unknown option: "nodocs".
>>
>> .. kernel-doc:: mm/memblock.c
>>:nodocs:
>>
>>
>> Do you plan to merge the patch(es) for :nodocs: ?
> 
> :nodocs" was v1 of the patch set:
> 
>   
> https://lwn.net/ml/linux-doc/1529328996-16247-1-git-send-email-rppt%40linux.vnet.ibm.com/
> 
> In the end, I merged v3, which changed things (and did not contain
> the :nodocs: directive:
> 
>   
> https://lwn.net/ml/linux-doc/1530306311-10510-1-git-send-email-rppt%40linux.vnet.ibm.com/

Yes, I found that later.

which uses (for the record)
   :functions:
with an empty functions list -- to exclude "DOC:" sections.

> So I'm guessing that anything that snuck in with :nodocs: didn't get
> updated.  Somehow I missed that.  Adding CC: Mike, since his
> fingerprints are on all aspects of this...:)

thanks.

-- 
~Randy

Re: nodocs in 4.19-rcX

[Jonathan Corbet]

On Mon, 10 Sep 2018 15:51:20 -0700
Randy Dunlap  wrote:

> 4.19-rc contains some users of :nodocs: but that is not recognized yet,
> so we get:
> 
> lnx-419-rc3/Documentation/core-api/boot-time-mm.rst:78: ERROR: Error in 
> "kernel-doc" directive:
> unknown option: "nodocs".
> 
> .. kernel-doc:: mm/bootmem.c
>:nodocs:
> 
> lnx-419-rc3/Documentation/core-api/boot-time-mm.rst:91: ERROR: Error in 
> "kernel-doc" directive:
> unknown option: "nodocs".
> 
> .. kernel-doc:: mm/memblock.c
>:nodocs:
> 
> 
> Do you plan to merge the patch(es) for :nodocs: ?

:nodocs" was v1 of the patch set:

  
https://lwn.net/ml/linux-doc/1529328996-16247-1-git-send-email-rppt%40linux.vnet.ibm.com/

In the end, I merged v3, which changed things (and did not contain
the :nodocs: directive:

  
https://lwn.net/ml/linux-doc/1530306311-10510-1-git-send-email-rppt%40linux.vnet.ibm.com/

So I'm guessing that anything that snuck in with :nodocs: didn't get
updated.  Somehow I missed that.  Adding CC: Mike, since his
fingerprints are on all aspects of this...:)

jon

Re: [PATCH 2/2] MAINTAINERS: add i2c to the excludes for Documentation

[Jonathan Corbet]

On Fri,  7 Sep 2018 12:30:22 +0200
Wolfram Sang  wrote:

> I'll handle these myself but thanks for providing the fallback!
> 
> Signed-off-by: Wolfram Sang 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2698ee553008..39c39dd6fba6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4487,6 +4487,7 @@ F:  scripts/kernel-doc
>  X:   Documentation/ABI/
>  X:   Documentation/acpi/
>  X:   Documentation/devicetree/
> +X:   Documentation/i2c/
>  X:   Documentation/media/
>  X:   Documentation/power/
>  X:   Documentation/spi/

Both patches applied, thanks.  Looking forward to less email! :)

jon

Re: [PATCH 19/19] mtd: rawnand: Move JEDEC code to nand_jedec.c

[Boris Brezillon]

On Fri, 7 Sep 2018 10:40:44 +0200
Ladislav Michl  wrote:

> Hi Boris,
> 
> this patchseries is really amazing clean up. Thank you!

I'm glad I'm not the only one to find it useful :-).

> 
> On Fri, Sep 07, 2018 at 12:38:51AM +0200, Boris Brezillon wrote:
> > This moves ONFI related code to nand_onfi.c and ONFI related
> > struct/macros to include/linux/mtd/onfi.h.  
> 
> Seems above commit log comes from previous patch.

Oops, will fix that.

Thanks,

Boris

Re: [PATCH 19/19] mtd: rawnand: Move JEDEC code to nand_jedec.c

[Ladislav Michl]

Hi Boris,

this patchseries is really amazing clean up. Thank you!

On Fri, Sep 07, 2018 at 12:38:51AM +0200, Boris Brezillon wrote:
> This moves ONFI related code to nand_onfi.c and ONFI related
> struct/macros to include/linux/mtd/onfi.h.

Seems above commit log comes from previous patch.

Re: Italian translations and broken links

[Jonathan Corbet]

On Fri, 24 Aug 2018 13:51:18 +0200
Federico Vaga  wrote:

> Since there are many documents, this take time and perhaps we can already 
> push 
> the ones which are ready.
> 
> My big dilemma is (which is more general): what about broken references? Do 
> we 
> keep broken links which we know they will be correct in the future? Or, do we 
> remove all broken links and we add them back only when they work (if we 
> remember)?

We want the kernel to be as close to release-ready as it can be at any
time, that includes the docs.  So please no broken links.  It's a bit
more work to keep things coherent, but it's what we need to do in the
long run.

Thanks,

jon

Re: Italian translations and broken links

[Federico Vaga]

Answer to this email address, I did a mistake :)

On Friday, August 24, 2018 1:51:18 PM CEST Federico Vaga wrote:
> Hi Jon,
> 
> just one question about how do you prefer us to proceed. We are translating
> the process directory.
> My idea was to complete it and then push it. This because the documents in
> here have links to other documents in the same directory. In order to
> cleanly build it I wanted to translate the full directory and then propose
> a patch.
> 
> Since there are many documents, this take time and perhaps we can already
> push the ones which are ready.
> 
> My big dilemma is (which is more general): what about broken references? Do
> we keep broken links which we know they will be correct in the future? Or,
> do we remove all broken links and we add them back only when they work (if
> we remember)?
> 
> Thanks :)

Re: [PATCH v2 0/5] FireWire: clean up kernel-doc, add Documentation chapter

[Randy Dunlap]

On 06/16/2018 04:55 PM, Randy Dunlap wrote:
> On 04/15/2018 07:10 PM, Takashi Sakamoto wrote:
>> Hi,
>>
>> On Apr 14 2018 10:27, Randy Dunlap wrote:
>>> This patch series cleans up kernel-doc warnings in several
>>> FireWire source files and then adds a Documentation driver-api
>>> chapter for FireWire.
>>>
>>> [PATCH v3 1/5] FireWire: clean up firewire-cdev.h kernel-doc
>>> [PATCH v3 2/5] FireWire: clean up core-iso.c kernel-doc
>>> [PATCH v3 3/5] FireWire: clean up core-transaction.c kernel-doc
>>> [PATCH v3 4/5] FireWire: add a Documentation driver-api chapter
>>> [PATCH v3 5/5] FireWire: add driver-api Introduction section
>>>
>>>   Documentation/driver-api/firewire.rst |   50 +++-
>>>   Documentation/driver-api/index.rst    |    1
>>>   drivers/firewire/core-iso.c   |    7 +++
>>>   drivers/firewire/core-transaction.c   |   10 
>>>   include/uapi/linux/firewire-cdev.h    |   22 ++
>>>   5 files changed, 81 insertions(+), 9 deletions(-)
>>
>> I reviewed all of the five patches.
>>
>> Reviewed-by: Takashi Sakamoto 
>>
>> We're on development cycle for v4.18. Your patchset will be merged into
>> mainline in next merge window by pull request from Stefan.
> 

Hi Stefan,

Do you plan to merge these Firewire documentation patches in the
current merge window?

thanks,
-- 
~Randy

Re: [PATCH] Remove gendered language from management style documentation

[Jonathan Corbet]

On Tue,  7 Aug 2018 19:47:51 +0100
Fox Foster  wrote:

> This small commit replaces gendered pronouns for neutral ones.
> 
> Signed-off-by: Fox Foster 

Applied, thanks.

jon

Re: [PATCH v2] scripts/kernel-doc: Escape all literal braces in regexes

[Jonathan Corbet]

On Sun, 5 Aug 2018 17:41:09 +0100
Ben Hutchings  wrote:

> Commit 720ac2ef479d ("PATCH scripts/kernel-doc") fixed the two
> instances of literal braces that Perl 5.28 warns about, but there are
> still more than it doesn't warn about.
> 
> Escape all left braces that are treated as literal characters.  Also
> escape literal right braces, for consistency and to avoid confusing
> bracket-matching in text editors.
> 
> Signed-off-by: Ben Hutchings 

Applied (with the commit hash corrected), 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: Bug#905116: [PATCH v2] scripts/kernel-doc: Escape all literal braces in regexes

[Ben Hutchings]

On Mon, 2018-08-06 at 07:14 -0600, Jonathan Corbet wrote:
> On Sun, 5 Aug 2018 17:41:09 +0100
> Ben Hutchings  wrote:
> 
> > Commit 720ac2ef479d ("PATCH scripts/kernel-doc") fixed the two
> > instances of literal braces that Perl 5.28 warns about, but there are
> > still more than it doesn't warn about.
> 
> So where can I find this commit of which you speak?  I can't find it in
> mainline, -next, or -stable...  
> 
> The patch looks good, I'd like to get it in this coming merge window if
> possible.

Sorry, that was the wrong commit hash.  I mean commit 701b3a3c0ac4.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2] scripts/kernel-doc: Escape all literal braces in regexes

[Jonathan Corbet]

On Sun, 5 Aug 2018 17:41:09 +0100
Ben Hutchings  wrote:

> Commit 720ac2ef479d ("PATCH scripts/kernel-doc") fixed the two
> instances of literal braces that Perl 5.28 warns about, but there are
> still more than it doesn't warn about.

So where can I find this commit of which you speak?  I can't find it in
mainline, -next, or -stable...  

The patch looks good, I'd like to get it in this coming merge window if
possible.

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 v1] doc: translation for block queue into Chinese

[Jonathan Corbet]

On Fri, 27 Jul 2018 10:41:19 +0800
Norman  wrote:

> Translate block/queue-sysfs.txt into Chinese
> 
> Signed-off-by: Norman Kern 

Unfortunately, this patch has been white-space mangled by your mailer.
Please fix your mailer (Documentation/process/email-clients.rst has
useful hints to that end) then resend.

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] zh_CN:translation for block queue into Chinese

[Norman]

Hi, Jonathan
I didn't mean to translate it into markdown, I just feel it looks better
in markdown. I pay more attention on the contents but not the format and
I just want to translate all block module docs into Chinese.
I'll convert the format into plain text format and resend.

Thanks for your advice,

Norman


On 2018/7/23 23:36, Jonathan Corbet wrote:

On Fri, 20 Jul 2018 10:27:06 +0800
Norman  wrote:


Translate block/queue-sysfs.txt into Chinese

Signed-off-by: Norman Kern 
---
   .../translations/zh_CN/block/queue-sysfs.md    | 205
+

So...are you translating this into markdown format?  Please don't do
that, we don't need another documentation format in the kernel.  If you
want to convert this document to structured markup, the ideal approach
would be to convert the source document to RST first, then translate the
result.

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] zh_CN:translation for block queue into Chinese

[Jonathan Corbet]

On Fri, 20 Jul 2018 10:27:06 +0800
Norman  wrote:

> Translate block/queue-sysfs.txt into Chinese
> 
> Signed-off-by: Norman Kern 
> ---
>   .../translations/zh_CN/block/queue-sysfs.md    | 205 
> +

So...are you translating this into markdown format?  Please don't do
that, we don't need another documentation format in the kernel.  If you
want to convert this document to structured markup, the ideal approach
would be to convert the source document to RST first, then translate the
result.

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: [RFC PATCH 00/13] ext4: major documentation surgery

[Theodore Y. Ts'o]

On Sat, Jul 21, 2018 at 11:19:54AM -0700, Darrick J. Wong wrote:
> 
> I pondered that -- maybe leave all the ext4 stuff clustered together,
> but link to it from the actual user/admin guide section?
>

Yeah, I think it makes keep the ext4 (and in the future, xfs, btrfs,
f2fs, etc.) files clustered together.  Is it considered OK for
individual .rst files to be linked from multiple places?

I could also see us wanting to change up the pdf boundaries.  I doubt
someone would want a single pdf with details of the VFS layer, ext4
mount options, ext4 on-disk format, xfs mount options, xfs on-disk
format, btrfs mount options, etc., all in a single "book".

> > I'm not sure what the best way to do that might be, but maybe some of
> > the folks on the linux-doc list will have some suggestions.
> 
> I was thinking about having a separate top-level Filesystems section
> where we could put user/admin guides, on-disk documentation, etc. and
> leave the FS API section alone.

I wonder if part of the problem is calling it "the API section".
Maybe we should be calling it Kernel Internals, or something like
that?

- Ted

P.S.  Oh, and we probably want to move "The Linux Journalling API" out
of index.rst, and into a separate jbd2.rst file, and give some context
that it is the journalling layer used by ext4 and ocfs2, but it's
certainly not the only Journalling API in the kernel.

--
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 00/13] ext4: major documentation surgery

[Darrick J. Wong]

On Sat, Jul 21, 2018 at 10:19:46AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Jul 10, 2018 at 10:16:42AM -0700, Darrick J. Wong wrote:
> > Hi all,
> > 
> > This series converts the existing in-kernel ext4 documentation to rst
> > format, links it in with the rest of the kernel's rst documetation, and
> > then begins pulling in the contents of the on-disk layout page in the
> > wiki.  No changes are made to the text during the import process except
> > to flatten the nested tables in the old wiki page, which were very
> > difficult to maintain.
> > 
> > I've built the docs and put them here, in case you hate reading rst:
> > https://djwong.org/docs/kdoc/filesystems/ext4/index.html
> 
> I've applied these patches, but I think we still need to do some work
> figuring out how to integrate the ext4 documentation into the
> Linux-doc tree as a whole.
> 
> At the moment they are dropped in the middle of the "Kernel API
> Documentation", by virtue of where the files are located.  Most of the
> ext4.rst file probably should be moved into the user's and
> administrator's guide.

I pondered that -- maybe leave all the ext4 stuff clustered together,
but link to it from the actual user/admin guide section?

> I'm not sure where the best place to put the ondisk documentation.
> It's probably not the user's and administrator's guide, but the Kernel
> API Documentation doesn't seem like the right place.
> 
> But it should also make sense when people are browing the
> Documentation source directories, too.
> 
> I'm not sure what the best way to do that might be, but maybe some of
> the folks on the linux-doc list will have some suggestions.

I was thinking about having a separate top-level Filesystems section
where we could put user/admin guides, on-disk documentation, etc. and
leave the FS API section alone.

--D

> Cheers,
> 
>   - Ted
> 
--
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: MY NAME IS MRS BELLA YOSTIN MOHAMMAD

[Mrs Bella Yostin Mohammad]

Hello Dear.
My Name is Mrs. Bella Yostin Mohammad, I got your contact from a
business directory search and I decided to contact you directly. well
am originally from South Africa, but based in London, i am searching
for a reliable and honest and understanding person to go into
partnership in investing or to guide me in setting up a lucrative
business in the Middle east countries or the Arab countries,UAE or
OMAN and Kuwait, my plan is for my Son to fly to your country to meet
with you for the discussion and process of the investment.

So am only soliciting for your guidance for partnership or to help me
in investing in any lucrative business if you are interested.

My Idea of business is to invest into Tourism business or Medical
business or Real Estates business, this is my plan and i will be happy
if you will help in explaining more of either of this business which
is better for me to invest into in your country.all i want is to
invest into a good business that will bring higher profit.

like i explained above my plan is to send my Son down to meet with you
so both of you will meet face to face and discuss more so we will know
how to go about the process for the investment..

If you are willing to assist you will never regret assisting i and my son.
mean why if you are interested reply back to me with your mobile
number so that you and my son can discuss more in details.
And also for my Son to make his arrangement to fly down to your
country to meet with you over discussing about the investment.
I look forward for your reply.
Thanks with regards
Mrs. Bella Yostin Mohammad
--
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 00/13] ext4: major documentation surgery

[Theodore Y. Ts'o]

On Tue, Jul 10, 2018 at 10:16:42AM -0700, Darrick J. Wong wrote:
> Hi all,
> 
> This series converts the existing in-kernel ext4 documentation to rst
> format, links it in with the rest of the kernel's rst documetation, and
> then begins pulling in the contents of the on-disk layout page in the
> wiki.  No changes are made to the text during the import process except
> to flatten the nested tables in the old wiki page, which were very
> difficult to maintain.
> 
> I've built the docs and put them here, in case you hate reading rst:
> https://djwong.org/docs/kdoc/filesystems/ext4/index.html

I've applied these patches, but I think we still need to do some work
figuring out how to integrate the ext4 documentation into the
Linux-doc tree as a whole.

At the moment they are dropped in the middle of the "Kernel API
Documentation", by virtue of where the files are located.  Most of the
ext4.rst file probably should be moved into the user's and
administrator's guide.

I'm not sure where the best place to put the ondisk documentation.
It's probably not the user's and administrator's guide, but the Kernel
API Documentation doesn't seem like the right place.

But it should also make sense when people are browing the
Documentation source directories, too.

I'm not sure what the best way to do that might be, but maybe some of
the folks on the linux-doc list will have some suggestions.

Cheers,

- Ted

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