Skip to content
Snippets Groups Projects
  1. May 18, 2021
  2. May 17, 2021
    • Jan Kara's avatar
      quota: Disable quotactl_path syscall · 5b9fedb3
      Jan Kara authored
      In commit fa8b9007 ("quota: wire up quotactl_path") we have wired up
      new quotactl_path syscall. However some people in LWN discussion have
      objected that the path based syscall is missing dirfd and flags argument
      which is mostly standard for contemporary path based syscalls. Indeed
      they have a point and after a discussion with Christian Brauner and
      Sascha Hauer I've decided to disable the syscall for now and update its
      API. Since there is no userspace currently using that syscall and it
      hasn't been released in any major release, we should be fine.
      
      CC: Christian Brauner <christian.brauner@ubuntu.com>
      CC: Sascha Hauer <s.hauer@pengutronix.de>
      Link: https://lore.kernel.org/lkml/20210512153621.n5u43jsytbik4yze@wittgenstein
      
      
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      5b9fedb3
  3. May 07, 2021
    • Masahiro Yamada's avatar
      treewide: remove editor modelines and cruft · fa60ce2c
      Masahiro Yamada authored
      The section "19) Editor modelines and other cruft" in
      Documentation/process/coding-style.rst clearly says, "Do not include any
      of these in source files."
      
      I recently receive a patch to explicitly add a new one.
      
      Let's do treewide cleanups, otherwise some people follow the existing code
      and attempt to upstream their favoriate editor setups.
      
      It is even nicer if scripts/checkpatch.pl can check it.
      
      If we like to impose coding style in an editor-independent manner, I think
      editorconfig (patch [1]) is a saner solution.
      
      [1] https://lore.kernel.org/lkml/20200703073143.423557-1-danny@kdrag0n.dev/
      
      Link: https://lkml.kernel.org/r/20210324054457.1477489-1-masahiroy@kernel.org
      
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: Miguel Ojeda <ojeda@kernel.org>	[auxdisplay]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fa60ce2c
    • David Hildenbrand's avatar
      mm: remove xlate_dev_kmem_ptr() · f2e762ba
      David Hildenbrand authored
      Since /dev/kmem has been removed, let's remove the xlate_dev_kmem_ptr()
      leftovers.
      
      Link: https://lkml.kernel.org/r/20210324102351.6932-3-david@redhat.com
      
      
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Brian Cain <bcain@codeaurora.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Cc: Mikulas Patocka <mpatocka@redhat.com>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Mike Rapoport <rppt@kernel.org>
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Cc: Luis Chamberlain <mcgrof@kernel.org>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
      Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
      Cc: Niklas Schnelle <schnelle@linux.ibm.com>
      Cc: Pierre Morel <pmorel@linux.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f2e762ba
    • David Hildenbrand's avatar
      drivers/char: remove /dev/kmem for good · bbcd53c9
      David Hildenbrand authored
      Patch series "drivers/char: remove /dev/kmem for good".
      
      Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and
      memory ballooning, I started questioning the existence of /dev/kmem.
      
      Comparing it with the /proc/kcore implementation, it does not seem to be
      able to deal with things like
      
      a) Pages unmapped from the direct mapping (e.g., to be used by secretmem)
        -> kern_addr_valid(). virt_addr_valid() is not sufficient.
      
      b) Special cases like gart aperture memory that is not to be touched
        -> mem_pfn_is_ram()
      
      Unless I am missing something, it's at least broken in some cases and might
      fault/crash the machine.
      
      Looks like its existence has been questioned before in 2005 and 2010 [1],
      after ~11 additional years, it might make sense to revive the discussion.
      
      CONFIG_DEVKMEM is only enabled in a single defconfig (on purpose or by
      mistake?).  All distributions disable it: in Ubuntu it has been disabled
      for more than 10 years, in Debian since 2.6.31, in Fedora at least
      starting with FC3, in RHEL starting with RHEL4, in SUSE starting from
      15sp2, and OpenSUSE has it disabled as well.
      
      1) /dev/kmem was popular for rootkits [2] before it got disabled
         basically everywhere. Ubuntu documents [3] "There is no modern user of
         /dev/kmem any more beyond attackers using it to load kernel rootkits.".
         RHEL documents in a BZ [5] "it served no practical purpose other than to
         serve as a potential security problem or to enable binary module drivers
         to access structures/functions they shouldn't be touching"
      
      2) /proc/kcore is a decent interface to have a controlled way to read
         kernel memory for debugging puposes. (will need some extensions to
         deal with memory offlining/unplug, memory ballooning, and poisoned
         pages, though)
      
      3) It might be useful for corner case debugging [1]. KDB/KGDB might be a
         better fit, especially, to write random memory; harder to shoot
         yourself into the foot.
      
      4) "Kernel Memory Editor" [4] hasn't seen any updates since 2000 and seems
         to be incompatible with 64bit [1]. For educational purposes,
         /proc/kcore might be used to monitor value updates -- or older
         kernels can be used.
      
      5) It's broken on arm64, and therefore, completely disabled there.
      
      Looks like it's essentially unused and has been replaced by better
      suited interfaces for individual tasks (/proc/kcore, KDB/KGDB). Let's
      just remove it.
      
      [1] https://lwn.net/Articles/147901/
      [2] https://www.linuxjournal.com/article/10505
      [3] https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fkmem_disabled
      [4] https://sourceforge.net/projects/kme/
      [5] https://bugzilla.redhat.com/show_bug.cgi?id=154796
      
      Link: https://lkml.kernel.org/r/20210324102351.6932-1-david@redhat.com
      Link: https://lkml.kernel.org/r/20210324102351.6932-2-david@redhat.com
      
      
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Alexander A. Klimov" <grandmaster@al2klimov.de>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Brian Cain <bcain@codeaurora.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Corentin Labbe <clabbe@baylibre.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Gregory Clement <gregory.clement@bootlin.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Hillf Danton <hdanton@sina.com>
      Cc: huang ying <huang.ying.caritas@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: James Troup <james.troup@canonical.com>
      Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Kairui Song <kasong@redhat.com>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Luis Chamberlain <mcgrof@kernel.org>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Mike Rapoport <rppt@kernel.org>
      Cc: Mikulas Patocka <mpatocka@redhat.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Niklas Schnelle <schnelle@linux.ibm.com>
      Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
      Cc: openrisc@lists.librecores.org
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "Pavel Machek (CIP)" <pavel@denx.de>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: Pierre Morel <pmorel@linux.ibm.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Robert Richter <rric@kernel.org>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: sparclinux@vger.kernel.org
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Theodore Dubois <tblodt@icloud.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: William Cohen <wcohen@redhat.com>
      Cc: Xiaoming Ni <nixiaoming@huawei.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bbcd53c9
    • Yury Norov's avatar
      arch: rearrange headers inclusion order in asm/bitops for m68k, sh and h8300 · bb8bc36e
      Yury Norov authored
      m68k and sh include bitmap/{find,le}.h prior to ffs/fls headers.  New
      fast-path implementation in find.h requires ffs/fls.  Reordering the
      headers inclusion sequence helps to prevent compile-time implicit function
      declaration error.
      
      [yury.norov@gmail.com: h8300: rearrange headers inclusion order in asm/bitops]
        Link: https://lkml.kernel.org/r/20210406183625.794227-1-yury.norov@gmail.com
      
      Link: https://lkml.kernel.org/r/20210401003153.97325-5-yury.norov@gmail.com
      
      
      Signed-off-by: default avatarYury Norov <yury.norov@gmail.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: Alexey Klimov <aklimov@redhat.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David Sterba <dsterba@suse.com>
      Cc: Dennis Zhou <dennis@kernel.org>
      Cc: Jianpeng Ma <jianpeng.ma@intel.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Stefano Brivio <sbrivio@redhat.com>
      Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
      Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
      Cc: Yoshinori Sato <ysato@users.osdn.me>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bb8bc36e
  4. May 05, 2021
    • Masahiro Yamada's avatar
      arch: use cross_compiling to check whether it is a cross build or not · 23243c1a
      Masahiro Yamada authored
      
      'cross_compiling' is defined by the top Makefile and available for
      arch Makefiles to check whether it is a cross build or not. A good
      thing is the variable name 'cross_compiling' is self-documenting.
      
      This is a simple replacement for m68k, mips, sh, for which $(ARCH)
      and $(SRCARCH) always match.
      
      No functional change is intended for xtensa, either.
      
      This is rather a fix for parisc because arch/parisc/Makefile defines
      UTS_MATCHINE depending on CONFIG_64BIT, therefore cc-cross-prefix
      is not working in Kconfig time.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: Helge Deller <deller@gmx.de>  # parisc
      Acked-by: Max Filippov <jcmvbkbc@gmail.com> # xtensa
      23243c1a
  5. Apr 30, 2021
  6. Apr 23, 2021
  7. Apr 22, 2021
  8. Apr 19, 2021
  9. Apr 16, 2021
  10. Apr 12, 2021
  11. Apr 11, 2021
  12. Apr 06, 2021
  13. Mar 17, 2021
  14. Mar 06, 2021
    • Geert Uytterhoeven's avatar
      m68k: Fix virt_addr_valid() W=1 compiler warnings · a65a802a
      Geert Uytterhoeven authored
      
      If CONFIG_DEBUG_SG=y, and CONFIG_MMU=y:
      
          include/linux/scatterlist.h: In function ‘sg_set_buf’:
          arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of pointer with null pointer [-Wextra]
            174 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET && (void *)(kaddr) < high_memory)
      	  |                                                 ^~
      
      or CONFIG_MMU=n:
      
          include/linux/scatterlist.h: In function ‘sg_set_buf’:
          arch/m68k/include/asm/page_no.h:33:50: warning: ordered comparison of pointer with null pointer [-Wextra]
             33 | #define virt_addr_valid(kaddr) (((void *)(kaddr) >= (void *)PAGE_OFFSET) && \
      	  |                                                  ^~
      
      Fix this by doing the comparison in the "unsigned long" instead of the
      "void *" domain.
      
      Note that for now this is only seen when compiling btrfs, due to commit
      e9aa7c28 ("btrfs: enable W=1 checks for btrfs"), but as people
      are doing more W=1 compile testing, it will start to show up elsewhere,
      too.
      
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarGreg Ungerer <gerg@linux-m68k.org>
      Link: https://lore.kernel.org/r/20210305084122.4118826-1-geert@linux-m68k.org
      a65a802a
  15. Feb 22, 2021
  16. Feb 21, 2021
  17. Feb 13, 2021
  18. Feb 07, 2021
  19. Jan 25, 2021
  20. Jan 24, 2021
    • Christian Brauner's avatar
      fs: add mount_setattr() · 2a186721
      Christian Brauner authored
      This implements the missing mount_setattr() syscall. While the new mount
      api allows to change the properties of a superblock there is currently
      no way to change the properties of a mount or a mount tree using file
      descriptors which the new mount api is based on. In addition the old
      mount api has the restriction that mount options cannot be applied
      recursively. This hasn't changed since changing mount options on a
      per-mount basis was implemented in [1] and has been a frequent request
      not just for convenience but also for security reasons. The legacy
      mount syscall is unable to accommodate this behavior without introducing
      a whole new set of flags because MS_REC | MS_REMOUNT | MS_BIND |
      MS_RDONLY | MS_NOEXEC | [...] only apply the mount option to the topmost
      mount. Changing MS_REC to apply to the whole mount tree would mean
      introducing a significant uapi change and would likely cause significant
      regressions.
      
      The new mount_setattr() syscall allows to recursively clear and set
      mount options in one shot. Multiple calls to change mount options
      requesting the same changes are idempotent:
      
      int mount_setattr(int dfd, const char *path, unsigned flags,
                        struct mount_attr *uattr, size_t usize);
      
      Flags to modify path resolution behavior are specified in the @flags
      argument. Currently, AT_EMPTY_PATH, AT_RECURSIVE, AT_SYMLINK_NOFOLLOW,
      and AT_NO_AUTOMOUNT are supported. If useful, additional lookup flags to
      restrict path resolution as introduced with openat2() might be supported
      in the future.
      
      The mount_setattr() syscall can be expected to grow over time and is
      designed with extensibility in mind. It follows the extensible syscall
      pattern we have used with other syscalls such as openat2(), clone3(),
      sched_{set,get}attr(), and others.
      The set of mount options is passed in the uapi struct mount_attr which
      currently has the following layout:
      
      struct mount_attr {
      	__u64 attr_set;
      	__u64 attr_clr;
      	__u64 propagation;
      	__u64 userns_fd;
      };
      
      The @attr_set and @attr_clr members are used to clear and set mount
      options. This way a user can e.g. request that a set of flags is to be
      raised such as turning mounts readonly by raising MOUNT_ATTR_RDONLY in
      @attr_set while at the same time requesting that another set of flags is
      to be lowered such as removing noexec from a mount tree by specifying
      MOUNT_ATTR_NOEXEC in @attr_clr.
      
      Note, since the MOUNT_ATTR_<atime> values are an enum starting from 0,
      not a bitmap, users wanting to transition to a different atime setting
      cannot simply specify the atime setting in @attr_set, but must also
      specify MOUNT_ATTR__ATIME in the @attr_clr field. So we ensure that
      MOUNT_ATTR__ATIME can't be partially set in @attr_clr and that @attr_set
      can't have any atime bits set if MOUNT_ATTR__ATIME isn't set in
      @attr_clr.
      
      The @propagation field lets callers specify the propagation type of a
      mount tree. Propagation is a single property that has four different
      settings and as such is not really a flag argument but an enum.
      Specifically, it would be unclear what setting and clearing propagation
      settings in combination would amount to. The legacy mount() syscall thus
      forbids the combination of multiple propagation settings too. The goal
      is to keep the semantics of mount propagation somewhat simple as they
      are overly complex as it is.
      
      The @userns_fd field lets user specify a user namespace whose idmapping
      becomes the idmapping of the mount. This is implemented and explained in
      detail in the next patch.
      
      [1]: commit 2e4b7fcd ("[PATCH] r/o bind mounts: honor mount writer counts at remount")
      
      Link: https://lore.kernel.org/r/20210121131959.646623-35-christian.brauner@ubuntu.com
      
      
      Cc: David Howells <dhowells@redhat.com>
      Cc: Aleksa Sarai <cyphar@cyphar.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-api@vger.kernel.org
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      2a186721
  21. Dec 29, 2020
  22. Dec 19, 2020
  23. Dec 15, 2020
    • Mike Rapoport's avatar
      m68k: deprecate DISCONTIGMEM · fcd353a3
      Mike Rapoport authored
      DISCONTIGMEM was intended to provide more efficient support for systems
      with holes in their physical address space that FLATMEM did.
      
      Yet, it's overhead in terms of the memory consumption seems to
      overweight the savings on the unused memory map.
      
      For a ARAnyM system with 16 MBytes of FastRAM configured, the memory
      usage reported after page allocator initialization is
      
        Memory: 23828K/30720K available (3206K kernel code, 535K rwdata, 936K rodata, 768K init, 193K bss, 6892K reserved, 0K cma-reserved)
      
      and with DISCONTIGMEM disabled and with relatively large hole in the memory
      map it is:
      
        Memory: 23864K/30720K available (3197K kernel code, 516K rwdata, 936K rodata, 764K init, 179K bss, 6856K reserved, 0K cma-reserved)
      
      Moreover, since m68k already has custom pfn_valid() it is possible to
      define HAVE_ARCH_PFN_VALID to enable freeing of unused memory map.  The
      minimal size of a hole that can be freed should not be less than
      MAX_ORDER_NR_PAGES so to achieve more substantial memory savings let
      m68k also define custom FORCE_MAX_ZONEORDER.
      
      With FORCE_MAX_ZONEORDER set to 9 memory usage becomes:
      
        Memory: 23880K/30720K available (3197K kernel code, 516K rwdata, 936K rodata, 764K init, 179K bss, 6840K reserved, 0K cma-reserved)
      
      Link: https://lkml.kernel.org/r/20201101170454.9567-14-rppt@kernel.org
      
      
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greg Ungerer <gerg@linux-m68k.org>
      Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Meelis Roos <mroos@linux.ee>
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fcd353a3
    • Mike Rapoport's avatar
      m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM · 4bfc848e
      Mike Rapoport authored
      The pg_data_map and pg_data_table arrays as well as page_to_pfn() and
      pfn_to_page() are required only for DISCONTIGMEM. Other memory models can
      use the generic definitions in asm-generic/memory_model.h.
      
      Link: https://lkml.kernel.org/r/20201101170454.9567-13-rppt@kernel.org
      
      
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greg Ungerer <gerg@linux-m68k.org>
      Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Meelis Roos <mroos@linux.ee>
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4bfc848e
    • Mike Rapoport's avatar
      m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM · 6b2ad8d7
      Mike Rapoport authored
      The pg_data_t node structures and their initialization currently depends on
      !CONFIG_SINGLE_MEMORY_CHUNK. Since they are required only for DISCONTIGMEM
      make this dependency explicit and replace usage of
      CONFIG_SINGLE_MEMORY_CHUNK with CONFIG_DISCONTIGMEM where appropriate.
      
      The CONFIG_SINGLE_MEMORY_CHUNK was implicitly disabled on the ColdFire MMU
      variant, although it always presumed a single memory bank. As there is no
      actual need for DISCONTIGMEM in this case, make sure that ColdFire MMU
      systems set CONFIG_SINGLE_MEMORY_CHUNK to 'y'.
      
      Link: https://lkml.kernel.org/r/20201101170454.9567-12-rppt@kernel.org
      
      
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greg Ungerer <gerg@linux-m68k.org>
      Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Meelis Roos <mroos@linux.ee>
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6b2ad8d7
  24. Dec 06, 2020
    • Arnd Bergmann's avatar
      m68k: m68328: remove duplicate code · 8b22820e
      Arnd Bergmann authored
      
      Building a kernel with multiple dragonball based boards
      enabled needlessly causes a link failure because of duplicate
      config_BSP() functions between the CPU versions.
      
      Avoid that merging the three almost identical files into one,
      and hiding the CPU configuration behind the board config.
      The pr_info() lines are consolidated in one place.
      
      It is still not possible to run a kernel configured for
      more than one board, but at least configurations that can
      be selected can also be built now.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Ungerer <gerg@linux-m68k.org>
      8b22820e
    • Arnd Bergmann's avatar
      m68k: m68328: move platform code to separate files · a734bbf6
      Arnd Bergmann authored
      
      The dragen2 and ucsimm/ucdimm files require a bit of
      custom code compared to the other dragonball platforms,
      move them into separate files as a preparation for a
      build fix.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Ungerer <gerg@linux-m68k.org>
      a734bbf6
    • Greg Ungerer's avatar
      m68knommu: align BSS section to 4-byte boundaries · 670d3965
      Greg Ungerer authored
      
      The kernel start up code for all of the nommu m68k types expects the BSS
      section to be on a 4-byte boundary, and to be a whole number of 32bit
      words. The BSS initialization loop sets 32bit sized quantities and has
      no provision for odd or unaligned accesses.
      
      The alignment and size of the BSS has historically worked out to be 4-byte
      aligned and sized - although no explicit alignment or size was specified in
      the linker script. So the BSS zeroing code worked as expected.
      
      A problem was first observed after commit 7273ad2b ("kbuild: link lib-y
      objects to vmlinux forcibly when CONFIG_MODULES=y"). Some kernel builds,
      depending on exact configuration, then tended to generate even sized BSS
      sections - which is valid on m68k - but our BSS init code could not handle
      properly.
      
      The simplest and smallest solution is to align and size the BSS
      appropriately.
      
      Signed-off-by: default avatarGreg Ungerer <gerg@linux-m68k.org>
      670d3965
  25. Nov 23, 2020
Loading