LWN: Comments on "5.4 Merge window, part 1"

5.4 Merge window, part 1

tbird20d — Wed, 02 Oct 2019 21:12:55 +0000

Presumably the submitted code is authored by the tool itself, presumably based on templates for certain kinds of fixes. While the tool has no human intent, it can certainly convey that the assertions in the DCO are true, with respect to the code it is submitting.

5.4 Merge window, part 1

BET-frogger — Mon, 30 Sep 2019 16:31:27 +0000

A quick `git log --author="kbuild test robot <lkp@intel.com>"` shows patches which are S-o-b'ed by the "kbuild test robot" since March 2019. Do we need a captcha next to the S-o-b now :) ?

5.4 Merge window, part 1

cesarb — Mon, 30 Sep 2019 16:27:41 +0000

To make things even more interesting, ARM can have three different base page sizes: 4KB, 16KB, and 64KB (this has led to some fun compatibility issues when packages autodetect and hardcode the page size during their build, for instance jemalloc: https://github.com/jemalloc/jemalloc/issues/467). In some distributions (for instance, current Fedora, if I read their kernel config correctly), the kernel is compiled to use 4KB pages; in other distributions (for instance, current RedHat, if I read their kernel config correctly), the kernel is compiled to use 64KB pages. The 52-bit addresses are only available when the kernel is compiled to use 64KB pages (which is probably why RedHat chose that option).

5.4 Merge window, part 1

BenHutchings — Mon, 30 Sep 2019 16:20:17 +0000

Computer programs aren't legal persons so I don't see how they can assert the Developer's Certificate of Origin.

5.4 Merge window, part 1

BET-frogger — Mon, 30 Sep 2019 08:54:33 +0000

> There is now support for the SAE J1939 protocol used in car and truck networks; see this commit for details. This work has the unique distinction of carrying a Signed-off-by tag from the "kbuild test robot" at Intel; which parts of the patch were authored by the robot is not entirely clear.

During development we posted the incremental patches regularly to the linux-can mailing list and the the whole code was available on the linux-can-next git repo on kernel.org. The kbuild test robot compiled the branch, noticed some problems and send patches (as every good developer should do :D). In order to merge the stack, we squashed all patches into one, carrying the S-o-b off all contributing entities. The whole development history is available at https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux....

The three patches the kbuild robot contributed are:

https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux...
https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux...
https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux...

Marc

5.4 Merge window, part 1

excors — Thu, 26 Sep 2019 10:00:06 +0000

> Who's making ARM systems with 4 TiB of RAM?

I guess you meant 2^52 = 4 PiB, not 4 TiB? The latter is easy: https://www.gigabyte.com/ARM-Server/R281-T94-rev-100 is a dual-socket ARM server which supports "Up to 16 DIMMS per socket, up to 4 TB of memory per system in dual socket configuration".

Then there's things like Optane DIMMs, which seem to go up to 512 GiB now, so you could physically fit 8 TiB of addressable memory per socket into that server (although I assume it won't actually work on non-Intel platforms).

The kernel is being increased from 48-bit which is 256 TiB, and it sounds like we're not too many years away from reaching that limit.

5.4 Merge window, part 1

jem — Thu, 26 Sep 2019 06:10:24 +0000

Well, obviously nobody, since there was no way of using it until now. Besides, 640k ought to be enough for anybody.

5.4 Merge window, part 1

naptastic — Thu, 26 Sep 2019 02:24:38 +0000

> The Arm64 architecture can now use 52-bit addresses on hardware that supports them.

Who's making ARM systems with 4 TiB of RAM?

5.4 Merge window, part 1

neilbrown — Tue, 24 Sep 2019 22:46:00 +0000

Hmm.... it seems that i_write_count has never been used for swap file ... I wonder why not. It is only used for executabled and DENY_WRITE mappings.
Funny how easy it is to remember things that aren't true!

5.4 Merge window, part 1

nivedita76 — Tue, 24 Sep 2019 03:02:54 +0000

Darrick Wong seems to have discovered as part of his immutable flag cleanup that some similar holes existed for swap files.

"I also discovered that userspace programs can write and create writable
memory mappings to active swap files. This is extremely bad because
this allows anyone with write privileges to corrupt system memory. The
final patch in this series closes off that hole, at least for swap
files."

5.4 Merge window, part 1

neilbrown — Tue, 24 Sep 2019 00:25:53 +0000

> The kernel will no longer allow user space to write to active swap files.

This surprises me. I thought that a negative i_writecount has always prevented user-space writes, and has always been set by swap-on. What has changed?