<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/m68k/kernel, branch v6.9</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'lsm-pr-20240105' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm</title>
<updated>2024-01-09T20:57:46+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-01-09T20:57:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac'/>
<id>063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac</id>
<content type='text'>
Pull security module updates from Paul Moore:

 - Add three new syscalls: lsm_list_modules(), lsm_get_self_attr(), and
   lsm_set_self_attr().

   The first syscall simply lists the LSMs enabled, while the second and
   third get and set the current process' LSM attributes. Yes, these
   syscalls may provide similar functionality to what can be found under
   /proc or /sys, but they were designed to support multiple,
   simultaneaous (stacked) LSMs from the start as opposed to the current
   /proc based solutions which were created at a time when only one LSM
   was allowed to be active at a given time.

   We have spent considerable time discussing ways to extend the
   existing /proc interfaces to support multiple, simultaneaous LSMs and
   even our best ideas have been far too ugly to support as a kernel
   API; after +20 years in the kernel, I felt the LSM layer had
   established itself enough to justify a handful of syscalls.

   Support amongst the individual LSM developers has been nearly
   unanimous, with a single objection coming from Tetsuo (TOMOYO) as he
   is worried that the LSM_ID_XXX token concept will make it more
   difficult for out-of-tree LSMs to survive. Several members of the LSM
   community have demonstrated the ability for out-of-tree LSMs to
   continue to exist by picking high/unused LSM_ID values as well as
   pointing out that many kernel APIs rely on integer identifiers, e.g.
   syscalls (!), but unfortunately Tetsuo's objections remain.

   My personal opinion is that while I have no interest in penalizing
   out-of-tree LSMs, I'm not going to penalize in-tree development to
   support out-of-tree development, and I view this as a necessary step
   forward to support the push for expanded LSM stacking and reduce our
   reliance on /proc and /sys which has occassionally been problematic
   for some container users. Finally, we have included the linux-api
   folks on (all?) recent revisions of the patchset and addressed all of
   their concerns.

 - Add a new security_file_ioctl_compat() LSM hook to handle the 32-bit
   ioctls on 64-bit systems problem.

   This patch includes support for all of the existing LSMs which
   provide ioctl hooks, although it turns out only SELinux actually
   cares about the individual ioctls. It is worth noting that while
   Casey (Smack) and Tetsuo (TOMOYO) did not give explicit ACKs to this
   patch, they did both indicate they are okay with the changes.

 - Fix a potential memory leak in the CALIPSO code when IPv6 is disabled
   at boot.

   While it's good that we are fixing this, I doubt this is something
   users are seeing in the wild as you need to both disable IPv6 and
   then attempt to configure IPv6 labeled networking via
   NetLabel/CALIPSO; that just doesn't make much sense.

   Normally this would go through netdev, but Jakub asked me to take
   this patch and of all the trees I maintain, the LSM tree seemed like
   the best fit.

 - Update the LSM MAINTAINERS entry with additional information about
   our process docs, patchwork, bug reporting, etc.

   I also noticed that the Lockdown LSM is missing a dedicated
   MAINTAINERS entry so I've added that to the pull request. I've been
   working with one of the major Lockdown authors/contributors to see if
   they are willing to step up and assume a Lockdown maintainer role;
   hopefully that will happen soon, but in the meantime I'll continue to
   look after it.

 - Add a handful of mailmap entries for Serge Hallyn and myself.

* tag 'lsm-pr-20240105' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: (27 commits)
  lsm: new security_file_ioctl_compat() hook
  lsm: Add a __counted_by() annotation to lsm_ctx.ctx
  calipso: fix memory leak in netlbl_calipso_add_pass()
  selftests: remove the LSM_ID_IMA check in lsm/lsm_list_modules_test
  MAINTAINERS: add an entry for the lockdown LSM
  MAINTAINERS: update the LSM entry
  mailmap: add entries for Serge Hallyn's dead accounts
  mailmap: update/replace my old email addresses
  lsm: mark the lsm_id variables are marked as static
  lsm: convert security_setselfattr() to use memdup_user()
  lsm: align based on pointer length in lsm_fill_user_ctx()
  lsm: consolidate buffer size handling into lsm_fill_user_ctx()
  lsm: correct error codes in security_getselfattr()
  lsm: cleanup the size counters in security_getselfattr()
  lsm: don't yet account for IMA in LSM_CONFIG_COUNT calculation
  lsm: drop LSM_ID_IMA
  LSM: selftests for Linux Security Module syscalls
  SELinux: Add selfattr hooks
  AppArmor: Add selfattr hooks
  Smack: implement setselfattr and getselfattr hooks
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull security module updates from Paul Moore:

 - Add three new syscalls: lsm_list_modules(), lsm_get_self_attr(), and
   lsm_set_self_attr().

   The first syscall simply lists the LSMs enabled, while the second and
   third get and set the current process' LSM attributes. Yes, these
   syscalls may provide similar functionality to what can be found under
   /proc or /sys, but they were designed to support multiple,
   simultaneaous (stacked) LSMs from the start as opposed to the current
   /proc based solutions which were created at a time when only one LSM
   was allowed to be active at a given time.

   We have spent considerable time discussing ways to extend the
   existing /proc interfaces to support multiple, simultaneaous LSMs and
   even our best ideas have been far too ugly to support as a kernel
   API; after +20 years in the kernel, I felt the LSM layer had
   established itself enough to justify a handful of syscalls.

   Support amongst the individual LSM developers has been nearly
   unanimous, with a single objection coming from Tetsuo (TOMOYO) as he
   is worried that the LSM_ID_XXX token concept will make it more
   difficult for out-of-tree LSMs to survive. Several members of the LSM
   community have demonstrated the ability for out-of-tree LSMs to
   continue to exist by picking high/unused LSM_ID values as well as
   pointing out that many kernel APIs rely on integer identifiers, e.g.
   syscalls (!), but unfortunately Tetsuo's objections remain.

   My personal opinion is that while I have no interest in penalizing
   out-of-tree LSMs, I'm not going to penalize in-tree development to
   support out-of-tree development, and I view this as a necessary step
   forward to support the push for expanded LSM stacking and reduce our
   reliance on /proc and /sys which has occassionally been problematic
   for some container users. Finally, we have included the linux-api
   folks on (all?) recent revisions of the patchset and addressed all of
   their concerns.

 - Add a new security_file_ioctl_compat() LSM hook to handle the 32-bit
   ioctls on 64-bit systems problem.

   This patch includes support for all of the existing LSMs which
   provide ioctl hooks, although it turns out only SELinux actually
   cares about the individual ioctls. It is worth noting that while
   Casey (Smack) and Tetsuo (TOMOYO) did not give explicit ACKs to this
   patch, they did both indicate they are okay with the changes.

 - Fix a potential memory leak in the CALIPSO code when IPv6 is disabled
   at boot.

   While it's good that we are fixing this, I doubt this is something
   users are seeing in the wild as you need to both disable IPv6 and
   then attempt to configure IPv6 labeled networking via
   NetLabel/CALIPSO; that just doesn't make much sense.

   Normally this would go through netdev, but Jakub asked me to take
   this patch and of all the trees I maintain, the LSM tree seemed like
   the best fit.

 - Update the LSM MAINTAINERS entry with additional information about
   our process docs, patchwork, bug reporting, etc.

   I also noticed that the Lockdown LSM is missing a dedicated
   MAINTAINERS entry so I've added that to the pull request. I've been
   working with one of the major Lockdown authors/contributors to see if
   they are willing to step up and assume a Lockdown maintainer role;
   hopefully that will happen soon, but in the meantime I'll continue to
   look after it.

 - Add a handful of mailmap entries for Serge Hallyn and myself.

* tag 'lsm-pr-20240105' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: (27 commits)
  lsm: new security_file_ioctl_compat() hook
  lsm: Add a __counted_by() annotation to lsm_ctx.ctx
  calipso: fix memory leak in netlbl_calipso_add_pass()
  selftests: remove the LSM_ID_IMA check in lsm/lsm_list_modules_test
  MAINTAINERS: add an entry for the lockdown LSM
  MAINTAINERS: update the LSM entry
  mailmap: add entries for Serge Hallyn's dead accounts
  mailmap: update/replace my old email addresses
  lsm: mark the lsm_id variables are marked as static
  lsm: convert security_setselfattr() to use memdup_user()
  lsm: align based on pointer length in lsm_fill_user_ctx()
  lsm: consolidate buffer size handling into lsm_fill_user_ctx()
  lsm: correct error codes in security_getselfattr()
  lsm: cleanup the size counters in security_getselfattr()
  lsm: don't yet account for IMA in LSM_CONFIG_COUNT calculation
  lsm: drop LSM_ID_IMA
  LSM: selftests for Linux Security Module syscalls
  SELinux: Add selfattr hooks
  AppArmor: Add selfattr hooks
  Smack: implement setselfattr and getselfattr hooks
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'vfs-6.8.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs</title>
<updated>2024-01-08T18:57:34+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-01-08T18:57:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8c9440fea77440772542d6dbcb5c36182495c164'/>
<id>8c9440fea77440772542d6dbcb5c36182495c164</id>
<content type='text'>
Pull vfs mount updates from Christian Brauner:
 "This contains the work to retrieve detailed information about mounts
  via two new system calls. This is hopefully the beginning of the end
  of the saga that started with fsinfo() years ago.

  The LWN articles in [1] and [2] can serve as a summary so we can avoid
  rehashing everything here.

  At LSFMM in May 2022 we got into a room and agreed on what we want to
  do about fsinfo(). Basically, split it into pieces. This is the first
  part of that agreement. Specifically, it is concerned with retrieving
  information about mounts. So this only concerns the mount information
  retrieval, not the mount table change notification, or the extended
  filesystem specific mount option work. That is separate work.

  Currently mounts have a 32bit id. Mount ids are already in heavy use
  by libmount and other low-level userspace but they can't be relied
  upon because they're recycled very quickly. We agreed that mounts
  should carry a unique 64bit id by which they can be referenced
  directly. This is now implemented as part of this work.

  The new 64bit mount id is exposed in statx() through the new
  STATX_MNT_ID_UNIQUE flag. If the flag isn't raised the old mount id is
  returned. If it is raised and the kernel supports the new 64bit mount
  id the flag is raised in the result mask and the new 64bit mount id is
  returned. New and old mount ids do not overlap so they cannot be
  conflated.

  Two new system calls are introduced that operate on the 64bit mount
  id: statmount() and listmount(). A summary of the api and usage can be
  found on LWN as well (cf. [3]) but of course, I'll provide a summary
  here as well.

  Both system calls rely on struct mnt_id_req. Which is the request
  struct used to pass the 64bit mount id identifying the mount to
  operate on. It is extensible to allow for the addition of new
  parameters and for future use in other apis that make use of mount
  ids.

  statmount() mimicks the semantics of statx() and exposes a set flags
  that userspace may raise in mnt_id_req to request specific information
  to be retrieved. A statmount() call returns a struct statmount filled
  in with information about the requested mount. Supported requests are
  indicated by raising the request flag passed in struct mnt_id_req in
  the @mask argument in struct statmount.

  Currently we do support:

   - STATMOUNT_SB_BASIC:
     Basic filesystem info

   - STATMOUNT_MNT_BASIC
     Mount information (mount id, parent mount id, mount attributes etc)

   - STATMOUNT_PROPAGATE_FROM
     Propagation from what mount in current namespace

   - STATMOUNT_MNT_ROOT
     Path of the root of the mount (e.g., mount --bind /bla /mnt returns /bla)

   - STATMOUNT_MNT_POINT
     Path of the mount point (e.g., mount --bind /bla /mnt returns /mnt)

   - STATMOUNT_FS_TYPE
     Name of the filesystem type as the magic number isn't enough due to submounts

  The string options STATMOUNT_MNT_{ROOT,POINT} and STATMOUNT_FS_TYPE
  are appended to the end of the struct. Userspace can use the offsets
  in @fs_type, @mnt_root, and @mnt_point to reference those strings
  easily.

  The struct statmount reserves quite a bit of space currently for
  future extensibility. This isn't really a problem and if this bothers
  us we can just send a follow-up pull request during this cycle.

  listmount() is given a 64bit mount id via mnt_id_req just as
  statmount(). It takes a buffer and a size to return an array of the
  64bit ids of the child mounts of the requested mount. Userspace can
  thus choose to either retrieve child mounts for a mount in batches or
  iterate through the child mounts. For most use-cases it will be
  sufficient to just leave space for a few child mounts. But for big
  mount tables having an iterator is really helpful. Iterating through a
  mount table works by setting @param in mnt_id_req to the mount id of
  the last child mount retrieved in the previous listmount() call"

Link: https://lwn.net/Articles/934469 [1]
Link: https://lwn.net/Articles/829212 [2]
Link: https://lwn.net/Articles/950569 [3]

* tag 'vfs-6.8.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
  add selftest for statmount/listmount
  fs: keep struct mnt_id_req extensible
  wire up syscalls for statmount/listmount
  add listmount(2) syscall
  statmount: simplify string option retrieval
  statmount: simplify numeric option retrieval
  add statmount(2) syscall
  namespace: extract show_path() helper
  mounts: keep list of mounts in an rbtree
  add unique mount ID
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull vfs mount updates from Christian Brauner:
 "This contains the work to retrieve detailed information about mounts
  via two new system calls. This is hopefully the beginning of the end
  of the saga that started with fsinfo() years ago.

  The LWN articles in [1] and [2] can serve as a summary so we can avoid
  rehashing everything here.

  At LSFMM in May 2022 we got into a room and agreed on what we want to
  do about fsinfo(). Basically, split it into pieces. This is the first
  part of that agreement. Specifically, it is concerned with retrieving
  information about mounts. So this only concerns the mount information
  retrieval, not the mount table change notification, or the extended
  filesystem specific mount option work. That is separate work.

  Currently mounts have a 32bit id. Mount ids are already in heavy use
  by libmount and other low-level userspace but they can't be relied
  upon because they're recycled very quickly. We agreed that mounts
  should carry a unique 64bit id by which they can be referenced
  directly. This is now implemented as part of this work.

  The new 64bit mount id is exposed in statx() through the new
  STATX_MNT_ID_UNIQUE flag. If the flag isn't raised the old mount id is
  returned. If it is raised and the kernel supports the new 64bit mount
  id the flag is raised in the result mask and the new 64bit mount id is
  returned. New and old mount ids do not overlap so they cannot be
  conflated.

  Two new system calls are introduced that operate on the 64bit mount
  id: statmount() and listmount(). A summary of the api and usage can be
  found on LWN as well (cf. [3]) but of course, I'll provide a summary
  here as well.

  Both system calls rely on struct mnt_id_req. Which is the request
  struct used to pass the 64bit mount id identifying the mount to
  operate on. It is extensible to allow for the addition of new
  parameters and for future use in other apis that make use of mount
  ids.

  statmount() mimicks the semantics of statx() and exposes a set flags
  that userspace may raise in mnt_id_req to request specific information
  to be retrieved. A statmount() call returns a struct statmount filled
  in with information about the requested mount. Supported requests are
  indicated by raising the request flag passed in struct mnt_id_req in
  the @mask argument in struct statmount.

  Currently we do support:

   - STATMOUNT_SB_BASIC:
     Basic filesystem info

   - STATMOUNT_MNT_BASIC
     Mount information (mount id, parent mount id, mount attributes etc)

   - STATMOUNT_PROPAGATE_FROM
     Propagation from what mount in current namespace

   - STATMOUNT_MNT_ROOT
     Path of the root of the mount (e.g., mount --bind /bla /mnt returns /bla)

   - STATMOUNT_MNT_POINT
     Path of the mount point (e.g., mount --bind /bla /mnt returns /mnt)

   - STATMOUNT_FS_TYPE
     Name of the filesystem type as the magic number isn't enough due to submounts

  The string options STATMOUNT_MNT_{ROOT,POINT} and STATMOUNT_FS_TYPE
  are appended to the end of the struct. Userspace can use the offsets
  in @fs_type, @mnt_root, and @mnt_point to reference those strings
  easily.

  The struct statmount reserves quite a bit of space currently for
  future extensibility. This isn't really a problem and if this bothers
  us we can just send a follow-up pull request during this cycle.

  listmount() is given a 64bit mount id via mnt_id_req just as
  statmount(). It takes a buffer and a size to return an array of the
  64bit ids of the child mounts of the requested mount. Userspace can
  thus choose to either retrieve child mounts for a mount in batches or
  iterate through the child mounts. For most use-cases it will be
  sufficient to just leave space for a few child mounts. But for big
  mount tables having an iterator is really helpful. Iterating through a
  mount table works by setting @param in mnt_id_req to the mount id of
  the last child mount retrieved in the previous listmount() call"

Link: https://lwn.net/Articles/934469 [1]
Link: https://lwn.net/Articles/829212 [2]
Link: https://lwn.net/Articles/950569 [3]

* tag 'vfs-6.8.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
  add selftest for statmount/listmount
  fs: keep struct mnt_id_req extensible
  wire up syscalls for statmount/listmount
  add listmount(2) syscall
  statmount: simplify string option retrieval
  statmount: simplify numeric option retrieval
  add statmount(2) syscall
  namespace: extract show_path() helper
  mounts: keep list of mounts in an rbtree
  add unique mount ID
</pre>
</div>
</content>
</entry>
<entry>
<title>wire up syscalls for statmount/listmount</title>
<updated>2023-12-14T10:49:17+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2023-10-25T14:02:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d8b0f5465012538cc4bb10ddc4affadbab73465b'/>
<id>d8b0f5465012538cc4bb10ddc4affadbab73465b</id>
<content type='text'>
Wire up all archs.

Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Link: https://lore.kernel.org/r/20231025140205.3586473-7-mszeredi@redhat.com
Reviewed-by: Ian Kent &lt;raven@themaw.net&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Wire up all archs.

Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Link: https://lore.kernel.org/r/20231025140205.3586473-7-mszeredi@redhat.com
Reviewed-by: Ian Kent &lt;raven@themaw.net&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m68k, kexec: fix the incorrect ifdeffery and build dependency of CONFIG_KEXEC</title>
<updated>2023-12-13T01:20:17+00:00</updated>
<author>
<name>Baoquan He</name>
<email>bhe@redhat.com</email>
</author>
<published>2023-12-08T07:30:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9bad6b75fca1b38b08d94e93f49a90cda44702b9'/>
<id>9bad6b75fca1b38b08d94e93f49a90cda44702b9</id>
<content type='text'>
The select of KEXEC for CRASH_DUMP in kernel/Kconfig.kexec will be
dropped, then compiling errors will be triggered if below config items are
set:

===
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_CRASH_DUMP=y
===

Here, change the dependency of buinding machine_kexec.o relocate_kernel.o
and the ifdeffery in asm/kexe.h to CONFIG_KEXEC_CORE.

Link: https://lkml.kernel.org/r/20231208073036.7884-3-bhe@redhat.com
Signed-off-by: Baoquan He &lt;bhe@redhat.com&gt;
Cc: Eric DeVolder &lt;eric_devolder@yahoo.com&gt;
Cc: Ignat Korchagin &lt;ignat@cloudflare.com&gt;
Cc: kernel test robot &lt;lkp@intel.com&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&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 select of KEXEC for CRASH_DUMP in kernel/Kconfig.kexec will be
dropped, then compiling errors will be triggered if below config items are
set:

===
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_CRASH_DUMP=y
===

Here, change the dependency of buinding machine_kexec.o relocate_kernel.o
and the ifdeffery in asm/kexe.h to CONFIG_KEXEC_CORE.

Link: https://lkml.kernel.org/r/20231208073036.7884-3-bhe@redhat.com
Signed-off-by: Baoquan He &lt;bhe@redhat.com&gt;
Cc: Eric DeVolder &lt;eric_devolder@yahoo.com&gt;
Cc: Ignat Korchagin &lt;ignat@cloudflare.com&gt;
Cc: kernel test robot &lt;lkp@intel.com&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>LSM: wireup Linux Security Module syscalls</title>
<updated>2023-11-13T03:54:42+00:00</updated>
<author>
<name>Casey Schaufler</name>
<email>casey@schaufler-ca.com</email>
</author>
<published>2023-09-12T20:56:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5f42375904b08890f2e8e7cd955c5bf0c2c0d05a'/>
<id>5f42375904b08890f2e8e7cd955c5bf0c2c0d05a</id>
<content type='text'>
Wireup lsm_get_self_attr, lsm_set_self_attr and lsm_list_modules
system calls.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: linux-api@vger.kernel.org
Reviewed-by: Mickaël Salaün &lt;mic@digikod.net&gt;
[PM: forward ported beyond v6.6 due merge window changes]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Wireup lsm_get_self_attr, lsm_set_self_attr and lsm_list_modules
system calls.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: linux-api@vger.kernel.org
Reviewed-by: Mickaël Salaün &lt;mic@digikod.net&gt;
[PM: forward ported beyond v6.6 due merge window changes]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'm68knommu-for-v6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu</title>
<updated>2023-11-03T01:31:01+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-11-03T01:31:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8c04bddc27d60df8ca5cb5bea40374c3ca1d75fc'/>
<id>8c04bddc27d60df8ca5cb5bea40374c3ca1d75fc</id>
<content type='text'>
Pull m68knommu updates from Greg Ungerer:
 "A few changes, most of them related to fixing warnings when compiling
  with "W=1". These follow up Geert's recent changes for M68K for this
  too. These ones complete the fixes for the nommu and ColdFire specific
  code.

  Also a couple of other fixes to improve ROM default addressing and
  compiling for the Cleopatra boards.

  Summary:

   - improve default Kconfig ROM section settings

   - fix compilation for some Cleopatra boards

   - fixes and cleanups for warnings compiling with 'W=1'"

* tag 'm68knommu-for-v6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
  m68k: 68000: fix warning in timer code
  m68k: 68000: fix warnings in 68000 interrupt handling
  m68k: coldfire: remove unused variable in MMU code
  m68k: coldfire: fix warnings in uboot argument processing
  m68k: coldfire: make mcf_maskimr() static
  m68k: coldfire: ensure gpio prototypes visible
  m68k: coldfire: add and use "vectors.h"
  m68knommu: fix compilation for ColdFire/Cleopatra boards
  m68knommu: improve config ROM setting defaults
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull m68knommu updates from Greg Ungerer:
 "A few changes, most of them related to fixing warnings when compiling
  with "W=1". These follow up Geert's recent changes for M68K for this
  too. These ones complete the fixes for the nommu and ColdFire specific
  code.

  Also a couple of other fixes to improve ROM default addressing and
  compiling for the Cleopatra boards.

  Summary:

   - improve default Kconfig ROM section settings

   - fix compilation for some Cleopatra boards

   - fixes and cleanups for warnings compiling with 'W=1'"

* tag 'm68knommu-for-v6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
  m68k: 68000: fix warning in timer code
  m68k: 68000: fix warnings in 68000 interrupt handling
  m68k: coldfire: remove unused variable in MMU code
  m68k: coldfire: fix warnings in uboot argument processing
  m68k: coldfire: make mcf_maskimr() static
  m68k: coldfire: ensure gpio prototypes visible
  m68k: coldfire: add and use "vectors.h"
  m68knommu: fix compilation for ColdFire/Cleopatra boards
  m68knommu: improve config ROM setting defaults
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'asm-generic-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic</title>
<updated>2023-11-02T01:28:33+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-11-02T01:28:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1e0c505e13162a2abe7c984309cfe2ae976b428d'/>
<id>1e0c505e13162a2abe7c984309cfe2ae976b428d</id>
<content type='text'>
Pull ia64 removal and asm-generic updates from Arnd Bergmann:

 - The ia64 architecture gets its well-earned retirement as planned,
   now that there is one last (mostly) working release that will be
   maintained as an LTS kernel.

 - The architecture specific system call tables are updated for the
   added map_shadow_stack() syscall and to remove references to the
   long-gone sys_lookup_dcookie() syscall.

* tag 'asm-generic-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
  hexagon: Remove unusable symbols from the ptrace.h uapi
  asm-generic: Fix spelling of architecture
  arch: Reserve map_shadow_stack() syscall number for all architectures
  syscalls: Cleanup references to sys_lookup_dcookie()
  Documentation: Drop or replace remaining mentions of IA64
  lib/raid6: Drop IA64 support
  Documentation: Drop IA64 from feature descriptions
  kernel: Drop IA64 support from sig_fault handlers
  arch: Remove Itanium (IA-64) architecture
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ia64 removal and asm-generic updates from Arnd Bergmann:

 - The ia64 architecture gets its well-earned retirement as planned,
   now that there is one last (mostly) working release that will be
   maintained as an LTS kernel.

 - The architecture specific system call tables are updated for the
   added map_shadow_stack() syscall and to remove references to the
   long-gone sys_lookup_dcookie() syscall.

* tag 'asm-generic-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
  hexagon: Remove unusable symbols from the ptrace.h uapi
  asm-generic: Fix spelling of architecture
  arch: Reserve map_shadow_stack() syscall number for all architectures
  syscalls: Cleanup references to sys_lookup_dcookie()
  Documentation: Drop or replace remaining mentions of IA64
  lib/raid6: Drop IA64 support
  Documentation: Drop IA64 from feature descriptions
  kernel: Drop IA64 support from sig_fault handlers
  arch: Remove Itanium (IA-64) architecture
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'dma-mapping-6.7-2023-10-30' of git://git.infradead.org/users/hch/dma-mapping</title>
<updated>2023-11-01T23:15:54+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-11-01T23:15:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=009fbfc97b6367762efa257f1478ec86d37949f9'/>
<id>009fbfc97b6367762efa257f1478ec86d37949f9</id>
<content type='text'>
Pull dma-mapping updates from Christoph Hellwig:

 - get rid of the fake support for coherent DMA allocation on coldfire
   with caches (Christoph Hellwig)

 - add a few Kconfig dependencies so that Kconfig catches the use of
   invalid configurations (Christoph Hellwig)

 - fix a type in dma-debug output (Chuck Lever)

 - rewrite a comment in swiotlb (Sean Christopherson)

* tag 'dma-mapping-6.7-2023-10-30' of git://git.infradead.org/users/hch/dma-mapping:
  dma-debug: Fix a typo in a debugging eye-catcher
  swiotlb: rewrite comment explaining why the source is preserved on DMA_FROM_DEVICE
  m68k: remove unused includes from dma.c
  m68k: don't provide arch_dma_alloc for nommu/coldfire
  net: fec: use dma_alloc_noncoherent for data cache enabled coldfire
  m68k: use the coherent DMA code for coldfire without data cache
  dma-direct: warn when coherent allocations aren't supported
  dma-direct: simplify the use atomic pool logic in dma_direct_alloc
  dma-direct: add a CONFIG_ARCH_HAS_DMA_ALLOC symbol
  dma-direct: add dependencies to CONFIG_DMA_GLOBAL_POOL
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull dma-mapping updates from Christoph Hellwig:

 - get rid of the fake support for coherent DMA allocation on coldfire
   with caches (Christoph Hellwig)

 - add a few Kconfig dependencies so that Kconfig catches the use of
   invalid configurations (Christoph Hellwig)

 - fix a type in dma-debug output (Chuck Lever)

 - rewrite a comment in swiotlb (Sean Christopherson)

* tag 'dma-mapping-6.7-2023-10-30' of git://git.infradead.org/users/hch/dma-mapping:
  dma-debug: Fix a typo in a debugging eye-catcher
  swiotlb: rewrite comment explaining why the source is preserved on DMA_FROM_DEVICE
  m68k: remove unused includes from dma.c
  m68k: don't provide arch_dma_alloc for nommu/coldfire
  net: fec: use dma_alloc_noncoherent for data cache enabled coldfire
  m68k: use the coherent DMA code for coldfire without data cache
  dma-direct: warn when coherent allocations aren't supported
  dma-direct: simplify the use atomic pool logic in dma_direct_alloc
  dma-direct: add a CONFIG_ARCH_HAS_DMA_ALLOC symbol
  dma-direct: add dependencies to CONFIG_DMA_GLOBAL_POOL
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'm68k-for-v6.7-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k</title>
<updated>2023-11-01T20:13:07+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-11-01T20:13:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=979ff1e5af8a46f75a69ffa86209f8650547f42f'/>
<id>979ff1e5af8a46f75a69ffa86209f8650547f42f</id>
<content type='text'>
Pull m68k updates from Geert Uytterhoeven:

 - misc aesthetical improvements for the floating point emulator

 - remove the last user of strlcpy()

 - use kernel's generic libgcc functions

 - misc fixes for W=1 builds

 - misc indentation fixes

 - misc fixes and improvements

 - defconfig updates

* tag 'm68k-for-v6.7-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: (72 commits)
  m68k: lib: Include &lt;linux/libgcc.h&gt; for __muldi3()
  m68k: fpsp040: Fix indentation by 5 spaces
  m68k: Fix indentation by 2 or 5 spaces in &lt;asm/page_mm.h&gt;
  m68k: kernel: Fix indentation by 7 spaces in traps.c
  m68k: sun3: Fix indentation by 5 or 7 spaces
  m68k: Fix indentation by 7 spaces in &lt;asm/io_mm.h&gt;
  m68k: defconfig: Update virt_defconfig for v6.6-rc3
  m68k: defconfig: Update defconfigs for v6.6-rc1
  m68k: io: Mark mmio read addresses as const
  m68k: Replace GPL 2.0+ README.legal boilerplate with SPDX
  m68k: sun3: Change led_pattern[] to unsigned char
  m68k: Add missing types to asm/irq.h
  m68k: sun3/3x: Add and use "sun3.h"
  m68k: sun3x: Make dvma_print() static
  m68k: sun3x: Make sun3x_halt() static
  m68k: sun3x: Do not mark dvma_map_iommu() inline
  m68k: sun3x: Fix signature of sun3_leds()
  m68k: sun3: Make sun3_platform_init() static
  m68k: sun3: Make print_pte() static
  m68k: sun3: Annotate prom_printf() with __printf()
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull m68k updates from Geert Uytterhoeven:

 - misc aesthetical improvements for the floating point emulator

 - remove the last user of strlcpy()

 - use kernel's generic libgcc functions

 - misc fixes for W=1 builds

 - misc indentation fixes

 - misc fixes and improvements

 - defconfig updates

* tag 'm68k-for-v6.7-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: (72 commits)
  m68k: lib: Include &lt;linux/libgcc.h&gt; for __muldi3()
  m68k: fpsp040: Fix indentation by 5 spaces
  m68k: Fix indentation by 2 or 5 spaces in &lt;asm/page_mm.h&gt;
  m68k: kernel: Fix indentation by 7 spaces in traps.c
  m68k: sun3: Fix indentation by 5 or 7 spaces
  m68k: Fix indentation by 7 spaces in &lt;asm/io_mm.h&gt;
  m68k: defconfig: Update virt_defconfig for v6.6-rc3
  m68k: defconfig: Update defconfigs for v6.6-rc1
  m68k: io: Mark mmio read addresses as const
  m68k: Replace GPL 2.0+ README.legal boilerplate with SPDX
  m68k: sun3: Change led_pattern[] to unsigned char
  m68k: Add missing types to asm/irq.h
  m68k: sun3/3x: Add and use "sun3.h"
  m68k: sun3x: Make dvma_print() static
  m68k: sun3x: Make sun3x_halt() static
  m68k: sun3x: Do not mark dvma_map_iommu() inline
  m68k: sun3x: Fix signature of sun3_leds()
  m68k: sun3: Make sun3_platform_init() static
  m68k: sun3: Make print_pte() static
  m68k: sun3: Annotate prom_printf() with __printf()
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>m68k: coldfire: fix warnings in uboot argument processing</title>
<updated>2023-10-22T22:22:22+00:00</updated>
<author>
<name>Greg Ungerer</name>
<email>gerg@kernel.org</email>
</author>
<published>2023-09-12T12:29:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3b4497668f721513eb7287f6bb0c4d651759c7c4'/>
<id>3b4497668f721513eb7287f6bb0c4d651759c7c4</id>
<content type='text'>
When building with W=1:

      CC      arch/m68k/kernel/uboot.o
    arch/m68k/kernel/uboot.c: In function ‘parse_uboot_commandline’:
    arch/m68k/kernel/uboot.c:68:36: warning: variable ‘uboot_initrd_end’ set but not used [-Wunused-but-set-variable]
      unsigned long uboot_initrd_start, uboot_initrd_end;
                                        ^~~~~~~~~~~~~~~~
    arch/m68k/kernel/uboot.c:68:16: warning: variable ‘uboot_initrd_start’ set but not used [-Wunused-but-set-variable]
      unsigned long uboot_initrd_start, uboot_initrd_end;
                    ^~~~~~~~~~~~~~~~~~
    arch/m68k/kernel/uboot.c:66:16: warning: variable ‘uboot_kbd’ set but not used [-Wunused-but-set-variable]
      unsigned long uboot_kbd;
                    ^~~~~~~~~
    arch/m68k/kernel/uboot.c: At top level:
    arch/m68k/kernel/uboot.c:90:13: warning: no previous prototype for ‘process_uboot_commandline’ [-Wmissing-prototypes]
     __init void process_uboot_commandline(char *commandp, int size)
                 ^~~~~~~~~~~~~~~~~~~~~~~~~

A couple of issues here. Firstly we already have a bootinfo.h that has a
prototype for process_uboot_commandline(), we should include that.
Secondly uboot_kbd is not used at all and can be removed. Thirdly the
conditional code based on CONFIG_BLK_DEV_INITRD means that sometimes
uboot_initrd_start and uboot_initrd_end are not needed. Make their
declaration and asignment conditional on CONFIG_BLK_DEV_INITRD same as
the code that uses them.

Signed-off-by: Greg Ungerer &lt;gerg@linux-m68k.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When building with W=1:

      CC      arch/m68k/kernel/uboot.o
    arch/m68k/kernel/uboot.c: In function ‘parse_uboot_commandline’:
    arch/m68k/kernel/uboot.c:68:36: warning: variable ‘uboot_initrd_end’ set but not used [-Wunused-but-set-variable]
      unsigned long uboot_initrd_start, uboot_initrd_end;
                                        ^~~~~~~~~~~~~~~~
    arch/m68k/kernel/uboot.c:68:16: warning: variable ‘uboot_initrd_start’ set but not used [-Wunused-but-set-variable]
      unsigned long uboot_initrd_start, uboot_initrd_end;
                    ^~~~~~~~~~~~~~~~~~
    arch/m68k/kernel/uboot.c:66:16: warning: variable ‘uboot_kbd’ set but not used [-Wunused-but-set-variable]
      unsigned long uboot_kbd;
                    ^~~~~~~~~
    arch/m68k/kernel/uboot.c: At top level:
    arch/m68k/kernel/uboot.c:90:13: warning: no previous prototype for ‘process_uboot_commandline’ [-Wmissing-prototypes]
     __init void process_uboot_commandline(char *commandp, int size)
                 ^~~~~~~~~~~~~~~~~~~~~~~~~

A couple of issues here. Firstly we already have a bootinfo.h that has a
prototype for process_uboot_commandline(), we should include that.
Secondly uboot_kbd is not used at all and can be removed. Thirdly the
conditional code based on CONFIG_BLK_DEV_INITRD means that sometimes
uboot_initrd_start and uboot_initrd_end are not needed. Make their
declaration and asignment conditional on CONFIG_BLK_DEV_INITRD same as
the code that uses them.

Signed-off-by: Greg Ungerer &lt;gerg@linux-m68k.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
