<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/security/tomoyo, branch v6.7</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>lsm: constify 'bprm' parameter in security_bprm_committed_creds()</title>
<updated>2023-09-14T19:27:29+00:00</updated>
<author>
<name>Khadija Kamran</name>
<email>kamrankhadijadj@gmail.com</email>
</author>
<published>2023-08-23T08:16:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a721f7b8c3548e943e514a957f2a37f4763b9888'/>
<id>a721f7b8c3548e943e514a957f2a37f4763b9888</id>
<content type='text'>
Three LSMs register the implementations for the 'bprm_committed_creds()'
hook: AppArmor, SELinux and tomoyo. Looking at the function
implementations we may observe that the 'bprm' parameter is not changing.

Mark the 'bprm' parameter of LSM hook security_bprm_committed_creds() as
'const' since it will not be changing in the LSM hook.

Signed-off-by: Khadija Kamran &lt;kamrankhadijadj@gmail.com&gt;
[PM: minor merge fuzzing due to other constification patches]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Three LSMs register the implementations for the 'bprm_committed_creds()'
hook: AppArmor, SELinux and tomoyo. Looking at the function
implementations we may observe that the 'bprm' parameter is not changing.

Mark the 'bprm' parameter of LSM hook security_bprm_committed_creds() as
'const' since it will not be changing in the LSM hook.

Signed-off-by: Khadija Kamran &lt;kamrankhadijadj@gmail.com&gt;
[PM: minor merge fuzzing due to other constification patches]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tomoyo: remove unused function declaration</title>
<updated>2023-08-13T13:07:15+00:00</updated>
<author>
<name>GONG, Ruiqi</name>
<email>gongruiqi1@huawei.com</email>
</author>
<published>2023-08-11T13:32:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=254a8ed6aab39c869d99da97f25035ed15756337'/>
<id>254a8ed6aab39c869d99da97f25035ed15756337</id>
<content type='text'>
The last usage of tomoyo_check_flags() has been removed by commit
57c2590fb7fd ("TOMOYO: Update profile structure."). Clean up its
residual declaration.

Signed-off-by: GONG, Ruiqi &lt;gongruiqi1@huawei.com&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The last usage of tomoyo_check_flags() has been removed by commit
57c2590fb7fd ("TOMOYO: Update profile structure."). Clean up its
residual declaration.

Signed-off-by: GONG, Ruiqi &lt;gongruiqi1@huawei.com&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tomoyo: refactor deprecated strncpy</title>
<updated>2023-08-05T10:55:10+00:00</updated>
<author>
<name>Justin Stitt</name>
<email>justinstitt@google.com</email>
</author>
<published>2023-08-03T21:33:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7b9ef666f27afde43c047de2be2985b68ad9febe'/>
<id>7b9ef666f27afde43c047de2be2985b68ad9febe</id>
<content type='text'>
`strncpy` is deprecated for use on NUL-terminated destination strings [1].

A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on its destination buffer argument which is
_not_ the case for `strncpy`!

It should be noted that the destination buffer is zero-initialized and
had a max length of `sizeof(dest) - 1`. There is likely _not_ a bug
present in the current implementation. However, by switching to
`strscpy` we get the benefit of no longer needing the `- 1`'s from the
string copy invocations on top of `strscpy` being a safer interface all
together.

[1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
[2]: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html

Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt &lt;justinstitt@google.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
`strncpy` is deprecated for use on NUL-terminated destination strings [1].

A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on its destination buffer argument which is
_not_ the case for `strncpy`!

It should be noted that the destination buffer is zero-initialized and
had a max length of `sizeof(dest) - 1`. There is likely _not_ a bug
present in the current implementation. However, by switching to
`strscpy` we get the benefit of no longer needing the `- 1`'s from the
string copy invocations on top of `strscpy` being a safer interface all
together.

[1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
[2]: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html

Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt &lt;justinstitt@google.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tomoyo: add format attributes to functions</title>
<updated>2023-07-23T12:25:28+00:00</updated>
<author>
<name>Christian Göttsche</name>
<email>cgzones@googlemail.com</email>
</author>
<published>2023-07-19T14:00:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a959dbd98d1aeb51dec1cc7e5ada5d84ce16cbbc'/>
<id>a959dbd98d1aeb51dec1cc7e5ada5d84ce16cbbc</id>
<content type='text'>
Format attributes on functions taking format string can help compilers
detect argument type or count mismatches.

Please the compiler when building with W=1:

    security/tomoyo/audit.c: In function ‘tomoyo_init_log’:
    security/tomoyo/audit.c:290:9: error: function ‘tomoyo_init_log’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
      290 |         vsnprintf(buf + pos, len - pos, fmt, args);
          |         ^~~~~~~~~
    security/tomoyo/audit.c: In function ‘tomoyo_write_log2’:
    security/tomoyo/audit.c:376:9: error: function ‘tomoyo_write_log2’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
      376 |         buf = tomoyo_init_log(r, len, fmt, args);
          |         ^~~
    security/tomoyo/common.c: In function ‘tomoyo_addprintf’:
    security/tomoyo/common.c:193:9: error: function ‘tomoyo_addprintf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
      193 |         vsnprintf(buffer + pos, len - pos - 1, fmt, args);
          |         ^~~~~~~~~

Signed-off-by: Christian Göttsche &lt;cgzones@googlemail.com&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Format attributes on functions taking format string can help compilers
detect argument type or count mismatches.

Please the compiler when building with W=1:

    security/tomoyo/audit.c: In function ‘tomoyo_init_log’:
    security/tomoyo/audit.c:290:9: error: function ‘tomoyo_init_log’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
      290 |         vsnprintf(buf + pos, len - pos, fmt, args);
          |         ^~~~~~~~~
    security/tomoyo/audit.c: In function ‘tomoyo_write_log2’:
    security/tomoyo/audit.c:376:9: error: function ‘tomoyo_write_log2’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
      376 |         buf = tomoyo_init_log(r, len, fmt, args);
          |         ^~~
    security/tomoyo/common.c: In function ‘tomoyo_addprintf’:
    security/tomoyo/common.c:193:9: error: function ‘tomoyo_addprintf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
      193 |         vsnprintf(buffer + pos, len - pos - 1, fmt, args);
          |         ^~~~~~~~~

Signed-off-by: Christian Göttsche &lt;cgzones@googlemail.com&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mm/gup: remove vmas parameter from get_user_pages_remote()</title>
<updated>2023-06-09T23:25:26+00:00</updated>
<author>
<name>Lorenzo Stoakes</name>
<email>lstoakes@gmail.com</email>
</author>
<published>2023-05-17T19:25:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ca5e863233e8f6acd1792fd85d6bc2729a1b2c10'/>
<id>ca5e863233e8f6acd1792fd85d6bc2729a1b2c10</id>
<content type='text'>
The only instances of get_user_pages_remote() invocations which used the
vmas parameter were for a single page which can instead simply look up the
VMA directly. In particular:-

- __update_ref_ctr() looked up the VMA but did nothing with it so we simply
  remove it.

- __access_remote_vm() was already using vma_lookup() when the original
  lookup failed so by doing the lookup directly this also de-duplicates the
  code.

We are able to perform these VMA operations as we already hold the
mmap_lock in order to be able to call get_user_pages_remote().

As part of this work we add get_user_page_vma_remote() which abstracts the
VMA lookup, error handling and decrementing the page reference count should
the VMA lookup fail.

This forms part of a broader set of patches intended to eliminate the vmas
parameter altogether.

[akpm@linux-foundation.org: avoid passing NULL to PTR_ERR]
Link: https://lkml.kernel.org/r/d20128c849ecdbf4dd01cc828fcec32127ed939a.1684350871.git.lstoakes@gmail.com
Signed-off-by: Lorenzo Stoakes &lt;lstoakes@gmail.com&gt;
Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt; (for arm64)
Acked-by: David Hildenbrand &lt;david@redhat.com&gt;
Reviewed-by: Janosch Frank &lt;frankja@linux.ibm.com&gt; (for s390)
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Christian König &lt;christian.koenig@amd.com&gt;
Cc: Dennis Dalessandro &lt;dennis.dalessandro@cornelisnetworks.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Cc: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Cc: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Cc: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The only instances of get_user_pages_remote() invocations which used the
vmas parameter were for a single page which can instead simply look up the
VMA directly. In particular:-

- __update_ref_ctr() looked up the VMA but did nothing with it so we simply
  remove it.

- __access_remote_vm() was already using vma_lookup() when the original
  lookup failed so by doing the lookup directly this also de-duplicates the
  code.

We are able to perform these VMA operations as we already hold the
mmap_lock in order to be able to call get_user_pages_remote().

As part of this work we add get_user_page_vma_remote() which abstracts the
VMA lookup, error handling and decrementing the page reference count should
the VMA lookup fail.

This forms part of a broader set of patches intended to eliminate the vmas
parameter altogether.

[akpm@linux-foundation.org: avoid passing NULL to PTR_ERR]
Link: https://lkml.kernel.org/r/d20128c849ecdbf4dd01cc828fcec32127ed939a.1684350871.git.lstoakes@gmail.com
Signed-off-by: Lorenzo Stoakes &lt;lstoakes@gmail.com&gt;
Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt; (for arm64)
Acked-by: David Hildenbrand &lt;david@redhat.com&gt;
Reviewed-by: Janosch Frank &lt;frankja@linux.ibm.com&gt; (for s390)
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Christian König &lt;christian.koenig@amd.com&gt;
Cc: Dennis Dalessandro &lt;dennis.dalessandro@cornelisnetworks.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Cc: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Cc: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Cc: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'tomoyo-pr-20230424' of git://git.osdn.net/gitroot/tomoyo/tomoyo-test1</title>
<updated>2023-04-24T18:33:07+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-04-24T18:33:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5af4b523ba9be70372eafab02ebfb9babf77ec7d'/>
<id>5af4b523ba9be70372eafab02ebfb9babf77ec7d</id>
<content type='text'>
Pull tomoyo update from Tetsuo Handa:
 "One cleanup patch from Vlastimil Babka"

* tag 'tomoyo-pr-20230424' of git://git.osdn.net/gitroot/tomoyo/tomoyo-test1:
  tomoyo: replace tomoyo_round2() with kmalloc_size_roundup()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull tomoyo update from Tetsuo Handa:
 "One cleanup patch from Vlastimil Babka"

* tag 'tomoyo-pr-20230424' of git://git.osdn.net/gitroot/tomoyo/tomoyo-test1:
  tomoyo: replace tomoyo_round2() with kmalloc_size_roundup()
</pre>
</div>
</content>
</entry>
<entry>
<title>selinux: remove the runtime disable functionality</title>
<updated>2023-03-20T16:34:23+00:00</updated>
<author>
<name>Paul Moore</name>
<email>paul@paul-moore.com</email>
</author>
<published>2023-03-17T16:43:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f22f9aaf6c3d92ebd5ad9e67acc03afebaaeb289'/>
<id>f22f9aaf6c3d92ebd5ad9e67acc03afebaaeb289</id>
<content type='text'>
After working with the larger SELinux-based distros for several
years, we're finally at a place where we can disable the SELinux
runtime disable functionality.  The existing kernel deprecation
notice explains the functionality and why we want to remove it:

  The selinuxfs "disable" node allows SELinux to be disabled at
  runtime prior to a policy being loaded into the kernel.  If
  disabled via this mechanism, SELinux will remain disabled until
  the system is rebooted.

  The preferred method of disabling SELinux is via the "selinux=0"
  boot parameter, but the selinuxfs "disable" node was created to
  make it easier for systems with primitive bootloaders that did not
  allow for easy modification of the kernel command line.
  Unfortunately, allowing for SELinux to be disabled at runtime makes
  it difficult to secure the kernel's LSM hooks using the
  "__ro_after_init" feature.

It is that last sentence, mentioning the '__ro_after_init' hardening,
which is the real motivation for this change, and if you look at the
diffstat you'll see that the impact of this patch reaches across all
the different LSMs, helping prevent tampering at the LSM hook level.

From a SELinux perspective, it is important to note that if you
continue to disable SELinux via "/etc/selinux/config" it may appear
that SELinux is disabled, but it is simply in an uninitialized state.
If you load a policy with `load_policy -i`, you will see SELinux
come alive just as if you had loaded the policy during early-boot.

It is also worth noting that the "/sys/fs/selinux/disable" file is
always writable now, regardless of the Kconfig settings, but writing
to the file has no effect on the system, other than to display an
error on the console if a non-zero/true value is written.

Finally, in the several years where we have been working on
deprecating this functionality, there has only been one instance of
someone mentioning any user visible breakage.  In this particular
case it was an individual's kernel test system, and the workaround
documented in the deprecation notice ("selinux=0" on the kernel
command line) resolved the issue without problem.

Acked-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After working with the larger SELinux-based distros for several
years, we're finally at a place where we can disable the SELinux
runtime disable functionality.  The existing kernel deprecation
notice explains the functionality and why we want to remove it:

  The selinuxfs "disable" node allows SELinux to be disabled at
  runtime prior to a policy being loaded into the kernel.  If
  disabled via this mechanism, SELinux will remain disabled until
  the system is rebooted.

  The preferred method of disabling SELinux is via the "selinux=0"
  boot parameter, but the selinuxfs "disable" node was created to
  make it easier for systems with primitive bootloaders that did not
  allow for easy modification of the kernel command line.
  Unfortunately, allowing for SELinux to be disabled at runtime makes
  it difficult to secure the kernel's LSM hooks using the
  "__ro_after_init" feature.

It is that last sentence, mentioning the '__ro_after_init' hardening,
which is the real motivation for this change, and if you look at the
diffstat you'll see that the impact of this patch reaches across all
the different LSMs, helping prevent tampering at the LSM hook level.

From a SELinux perspective, it is important to note that if you
continue to disable SELinux via "/etc/selinux/config" it may appear
that SELinux is disabled, but it is simply in an uninitialized state.
If you load a policy with `load_policy -i`, you will see SELinux
come alive just as if you had loaded the policy during early-boot.

It is also worth noting that the "/sys/fs/selinux/disable" file is
always writable now, regardless of the Kconfig settings, but writing
to the file has no effect on the system, other than to display an
error on the console if a non-zero/true value is written.

Finally, in the several years where we have been working on
deprecating this functionality, there has only been one instance of
someone mentioning any user visible breakage.  In this particular
case it was an individual's kernel test system, and the workaround
documented in the deprecation notice ("selinux=0" on the kernel
command line) resolved the issue without problem.

Acked-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tomoyo: replace tomoyo_round2() with kmalloc_size_roundup()</title>
<updated>2023-03-01T14:46:12+00:00</updated>
<author>
<name>Vlastimil Babka</name>
<email>vbabka@suse.cz</email>
</author>
<published>2023-02-28T09:35:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c120c98486c2855d2ae266c2af63d26f61dfcc4e'/>
<id>c120c98486c2855d2ae266c2af63d26f61dfcc4e</id>
<content type='text'>
It seems tomoyo has had its own implementation of what
kmalloc_size_roundup() does today. Remove the function tomoyo_round2()
and replace it with kmalloc_size_roundup(). It provides more accurate
results and doesn't contain a while loop.

Signed-off-by: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It seems tomoyo has had its own implementation of what
kmalloc_size_roundup() does today. Remove the function tomoyo_round2()
and replace it with kmalloc_size_roundup(). It provides more accurate
results and doesn't contain a while loop.

Signed-off-by: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tomoyo: Update website link</title>
<updated>2023-01-13T14:11:38+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2023-01-13T14:11:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fa17087e244263627a01d6a9b76b8fdaf410de34'/>
<id>fa17087e244263627a01d6a9b76b8fdaf410de34</id>
<content type='text'>
SourceForge.JP was renamed to OSDN in May 2015.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SourceForge.JP was renamed to OSDN in May 2015.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tomoyo: Remove "select SRCU"</title>
<updated>2023-01-13T14:10:03+00:00</updated>
<author>
<name>Paul E. McKenney</name>
<email>paulmck@kernel.org</email>
</author>
<published>2023-01-13T14:08:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1ed8a46256771de283772d482403691807214cf7'/>
<id>1ed8a46256771de283772d482403691807214cf7</id>
<content type='text'>
Now that the SRCU Kconfig option is unconditionally selected, there is
no longer any point in selecting it.  Therefore, remove the "select SRCU"
Kconfig statements.

Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that the SRCU Kconfig option is unconditionally selected, there is
no longer any point in selecting it.  Therefore, remove the "select SRCU"
Kconfig statements.

Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
</pre>
</div>
</content>
</entry>
</feed>
