[arch-dev-public] Linux 3.14 in [testing]
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing]. This release brings some changes to the configuration. * Disabled LSMs There was a long discussion about it, but in the end there were some concerns and I do not see the point in supporting a feature in the kernel that we do not provide userspace support for. I also disabled audit, since it is enabled by default and there is no kernel switch to change that. I hate that it annoys users who don't use it - and we don't support it in our base system either (our systemd has no audit support, just as it has no SMACK or SELinux support). I kept YAMA, since it's not actually a real LSM, but only provides the very useful ptrace scope protection - which can be disabled easily if so desired. * Disabled x32 I disabled the x32 support - we are not providing any x32 userspace and there is no point for Arch in doing so. Given that the x32 syscalls already had one major security flaw, I don't see why this should be enabled. * Disabled userspace firmware helper support The fallback firmware helper is now disabled. This forced me to disable the "Dell BIOS uprgade via sysfs" support, but as far as I can see, that was broken anyway and nobody used it. * Made some drivers modular Some more drivers that were built-in are now modules. Nothing exciting, just random stuff. * Enabled infiniband modules I added the (modular) support for infiniband, as it was requested in a bug report and it's only modules. * Changed some kernel hacking options (not a lot) I changed some things in the kernel hacking section, but can't remember exactly what. I did not have the time to research why option XYZ was needed or not, so I didn't feel like switching things around a lot. * Removed some differences between 32 and 64 bit config Some drivers were enabled in 32 and disabled in 64, or vice versa. I think I fixed all those. * Removed criu patch I removed the patch that allows CONFIG_CHECKPOINT_RESTORE without CONFIG_EXPERT. If this option is supposed to be used by end users, then it should not be labelled CONFIG_EXPERT. As long as it is, I will assume it is something evil. * Added the 'simple' framebuffer driver This driver tries to take over the firmware's framebuffer instead of enabling the kernel's own generic vesa, uvesa of efi framebuffer. The non-generic drivers obviously still take precedence and will disable simplefb. ===================================================================== We still apply the following patches: * Change default log level from 7 to 4 Merging our patch to make that configurable upstream somehow lead to nothing, since nobody cared. * Bluetooth: allocate static minor for vhci It's not yet in 3.14, but I won't have those stupid bug reports complaining about a harmless message anymore. I'm keeping this patch until 3.15 is here. * module: allow multiple calls to MODULE_DEVICE_TABLE() per module * module: remove MODULE_GENERIC_TABLE Fixes to module alias setup needed for the i8042 controller aliases to work right. This is needed since i8042 is now modular, but upstream is slow. * Revert "syscalls.h: use gcc alias instead of assembler i686 won't work without it. Still waiting for anything from upstream. Got a messsage from the patch author to resend my original message, but no reaction again since then. See https://lkml.org/lkml/2014/1/26/22 for details. ===================================================================== Bugs I've seen so far: * The cirrus kms driver for qemu fails when booted with OVMF firmware. Works with the standard qemu BIOS. No idea what's going on here.
Am 02.04.2014 00:20, schrieb Thomas Bächler:
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing].
Okay, pushed everything to [testing] and [community-testing]. The community/rt3562sta did not build. I am not interested in fixing this crap, so either its maintainer takes care of it shortly, or I'll drop it when I move this out of testing.
Am 02.04.2014 00:44, schrieb Thomas Bächler:
Am 02.04.2014 00:20, schrieb Thomas Bächler:
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing].
Okay, pushed everything to [testing] and [community-testing].
Okay, sent this to the wrong list at first. Two problems: 1) findmnt/libmount broken with 3.14 - fixing that now. 2) util-linux/switch_root has problems (this seems like the same issue), see https://bbs.archlinux.org/viewtopic.php?pid=1399663
On Apr 2, 2014 5:56 AM, "Thomas Bächler" <thomas@archlinux.org> wrote:
Am 02.04.2014 00:44, schrieb Thomas Bächler:
Am 02.04.2014 00:20, schrieb Thomas Bächler:
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing].
Okay, pushed everything to [testing] and [community-testing].
Okay, sent this to the wrong list at first.
Two problems:
1) findmnt/libmount broken with 3.14 - fixing that now. 2) util-linux/switch_root has problems (this seems like the same issue),
Crap. Forgot about this. It's already fixed upstream (thanks to an Arch user). I don't have a reference to the commit, but I can take care of this if you don't find it before me.
Am 02.04.2014 13:17, schrieb Dave Reisner:
On Apr 2, 2014 5:56 AM, "Thomas Bächler" <thomas@archlinux.org> wrote:
Am 02.04.2014 00:44, schrieb Thomas Bächler:
Am 02.04.2014 00:20, schrieb Thomas Bächler:
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing].
Okay, pushed everything to [testing] and [community-testing].
Okay, sent this to the wrong list at first.
Two problems:
1) findmnt/libmount broken with 3.14 - fixing that now. 2) util-linux/switch_root has problems (this seems like the same issue),
Crap. Forgot about this. It's already fixed upstream (thanks to an Arch user). I don't have a reference to the commit, but I can take care of this if you don't find it before me.
The commit for 1) was 6c373810f5b1d32824371e9dff6ee5a006388f98. This is already applied in testing/util-linux. For 2), I don't see a fix upstream. It looks like a similar issue - apparently, st_dev for rootfs no longer has major 0 and minor 1 - maybe this also changed to 0?
On Wed, Apr 02, 2014 at 01:21:32PM +0200, Thomas Bächler wrote:
Am 02.04.2014 13:17, schrieb Dave Reisner:
On Apr 2, 2014 5:56 AM, "Thomas Bächler" <thomas@archlinux.org> wrote:
Am 02.04.2014 00:44, schrieb Thomas Bächler:
Am 02.04.2014 00:20, schrieb Thomas Bächler:
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing].
Okay, pushed everything to [testing] and [community-testing].
Okay, sent this to the wrong list at first.
Two problems:
1) findmnt/libmount broken with 3.14 - fixing that now. 2) util-linux/switch_root has problems (this seems like the same issue),
Crap. Forgot about this. It's already fixed upstream (thanks to an Arch user). I don't have a reference to the commit, but I can take care of this if you don't find it before me.
The commit for 1) was 6c373810f5b1d32824371e9dff6ee5a006388f98. This is already applied in testing/util-linux.
For 2), I don't see a fix upstream. It looks like a similar issue - apparently, st_dev for rootfs no longer has major 0 and minor 1 - maybe this also changed to 0?
Seems you're right: [rootfs /]# cat /proc/self/mountinfo 0 0 0:0 / / rw - rootfs rootfs rw 14 0 0:2 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw 15 0 0:13 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sys rw 16 0 0:4 / /dev rw,nosuid,relatime - devtmpfs dev rw,size=508412k,nr_inodes=127103,mode=755 17 0 0:14 / /run rw,nosuid,nodev,relatime - tmpfs run rw,mode=755 I mentioned this to Karel on IRC and offered a few possible solutions d
Am 02.04.2014 16:00, schrieb Dave Reisner:
For 2), I don't see a fix upstream. It looks like a similar issue - apparently, st_dev for rootfs no longer has major 0 and minor 1 - maybe this also changed to 0?
Seems you're right:
[rootfs /]# cat /proc/self/mountinfo 0 0 0:0 / / rw - rootfs rootfs rw 14 0 0:2 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw 15 0 0:13 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sys rw 16 0 0:4 / /dev rw,nosuid,relatime - devtmpfs dev rw,size=508412k,nr_inodes=127103,mode=755 17 0 0:14 / /run rw,nosuid,nodev,relatime - tmpfs run rw,mode=755
I mentioned this to Karel on IRC and offered a few possible solutions
Did you mention that we could do what busybox does ([1]) and check with statfs whether we are on either tmpfs or ramfs? [1] http://git.busybox.net/busybox/tree/util-linux/switch_root.c#n100
On Wed, Apr 02, 2014 at 04:21:04PM +0200, Thomas Bächler wrote:
Am 02.04.2014 16:00, schrieb Dave Reisner:
For 2), I don't see a fix upstream. It looks like a similar issue - apparently, st_dev for rootfs no longer has major 0 and minor 1 - maybe this also changed to 0?
Seems you're right:
[rootfs /]# cat /proc/self/mountinfo 0 0 0:0 / / rw - rootfs rootfs rw 14 0 0:2 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw 15 0 0:13 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sys rw 16 0 0:4 / /dev rw,nosuid,relatime - devtmpfs dev rw,size=508412k,nr_inodes=127103,mode=755 17 0 0:14 / /run rw,nosuid,nodev,relatime - tmpfs run rw,mode=755
I mentioned this to Karel on IRC and offered a few possible solutions
Did you mention that we could do what busybox does ([1]) and check with statfs whether we are on either tmpfs or ramfs?
[1] http://git.busybox.net/busybox/tree/util-linux/switch_root.c#n100
Yes, that was one possibility. I'm testing a patch now.
In data mercoledì 2 aprile 2014 00:44:42, Thomas Bächler ha scritto:
The community/rt3562sta did not build. I am not interested in fixing this crap, so either its maintainer takes care of it shortly, or I'll drop it when I move this out of testing.
Package fixed. -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423
Am 03.04.2014 12:33, schrieb Massimiliano Torromeo:
In data mercoledì 2 aprile 2014 00:44:42, Thomas Bächler ha scritto:
The community/rt3562sta did not build. I am not interested in fixing this crap, so either its maintainer takes care of it shortly, or I'll drop it when I move this out of testing.
Package fixed.
Much appreciated.
On 2 April 2014 01:20, Thomas Bächler <thomas@archlinux.org> wrote:
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing].
Has anyone else experienced hangs in Firefox with the latest kernel? If I attach gdb to the firefox process it gets unstuck right after detaching gdb. The top of the backtrace contains: #0 0x00007f3c3676704f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00007f3c2f4bd460 in PR_WaitCondVar () from /usr/lib/libnspr4.so strace also shows the following syscall: futex(0x7f1bfe573d8c, FUTEX_WAIT_PRIVATE, 366, NULL
Am 03.04.2014 05:24, schrieb Evangelos Foutras:
On 2 April 2014 01:20, Thomas Bächler <thomas@archlinux.org> wrote:
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing].
Has anyone else experienced hangs in Firefox with the latest kernel?
None that I can remember.
On 03/04/14 11:10, Thomas Bächler wrote:
Am 03.04.2014 05:24, schrieb Evangelos Foutras:
On 2 April 2014 01:20, Thomas Bächler <thomas@archlinux.org> wrote:
It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing].
Has anyone else experienced hangs in Firefox with the latest kernel?
None that I can remember.
I came across the following post on LKML which seems to discuss a race condition that is possibly causing the Firefox hangs on my laptop: https://lkml.org/lkml/2014/4/8/80 Let's hope for a fix soon.
On Thu, Apr 10, 2014 at 3:34 PM, Evangelos Foutras <evangelos@foutrelis.com> wrote:
I came across the following post on LKML which seems to discuss a race condition that is possibly causing the Firefox hangs on my laptop:
https://lkml.org/lkml/2014/4/8/80
Let's hope for a fix soon.
Just as a hint, stopping (SIGSTOP) and continuing (SIGCONT) Firefox resolves a hang.
participants (5)
-
Dave Reisner
-
Evangelos Foutras
-
Jan Alexander Steffens
-
Massimiliano Torromeo
-
Thomas Bächler