January 2016 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] Stacktrace "Found insecure W+X mapping at address" analysis for Kernel 4.4
by Bjoern Voigt 24 Jan '16

24 Jan '16

When I install Kernel 4.4.0-4.gf0efa01-default from [Kernel_stable repository] on openSUSE 42.1 x86_64 I get the following stacktrace on every startup on one of my PCs. Original Leap 42.1 Kernel 4.1.* works without problems. Could someone give me a hint for resolving the issue with Kernel 4.4? [ 1.214430] ------------[ cut here ]------------ [ 1.214435] WARNING: CPU: 2 PID: 1 at ../arch/x86/mm/dump_pagetables.c:225 note_page+0x5e1/0x780() [ 1.214437] x86/mm: Found insecure W+X mapping at address ffff880000048000/0xffff880000048000 [ 1.214437] Modules linked in: [ 1.214440] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-4.gf0efa01-default #1 [ 1.214441] Hardware name: Gigabyte Technology Co., Ltd. H97-HD3/H97-HD3, BIOS F8 09/18/2015 [ 1.214442] ffffffff81a454a0 ffff88017eddfd58 ffffffff8137f629 ffff88017eddfda0 [ 1.214444] ffff88017eddfd90 ffffffff8107d132 ffff88017eddfe98 8000000000000163 [ 1.214445] 0000000000000004 0000000000000000 0000000000000000 ffff88017eddfdf0 [ 1.214446] Call Trace: [ 1.214452] [<ffffffff8101a095>] try_stack_unwind+0x175/0x190 [ 1.214456] [<ffffffff81018fe9>] dump_trace+0x69/0x3a0 [ 1.214458] [<ffffffff8101a0fb>] show_trace_log_lvl+0x4b/0x60 [ 1.214460] [<ffffffff8101942c>] show_stack_log_lvl+0x10c/0x180 [ 1.214461] [<ffffffff8101a195>] show_stack+0x25/0x50 [ 1.214464] [<ffffffff8137f629>] dump_stack+0x4b/0x72 [ 1.214467] [<ffffffff8107d132>] warn_slowpath_common+0x82/0xc0 [ 1.214470] [<ffffffff8107d1bc>] warn_slowpath_fmt+0x4c/0x50 [ 1.214471] [<ffffffff8106e2b1>] note_page+0x5e1/0x780 [ 1.214474] [<ffffffff8106e73e>] ptdump_walk_pgd_level_core+0x2ee/0x420 [ 1.214476] [<ffffffff8106e8a7>] ptdump_walk_pgd_level_checkwx+0x17/0x20 [ 1.214478] [<ffffffff81064b2f>] mark_rodata_ro+0xef/0x100 [ 1.214482] [<ffffffff8169d71d>] kernel_init+0x1d/0xe0 [ 1.214485] [<ffffffff816aa40f>] ret_from_fork+0x3f/0x70 [ 1.215462] DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70 [ 1.215463] Leftover inexact backtrace: [ 1.215465] [<ffffffff8169d700>] ? rest_init+0x90/0x90 [ 1.215466] ---[ end trace e18e66e4ee2688bd ]--- [ 1.219853] x86/mm: Checked W+X mappings: FAILED, 192385 W+X pages found. [ 1.221344] random: systemd urandom read with 27 bits of entropy available Greetings, Björn -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1

[opensuse-kernel] fyi, kernel 4.4.0 OOPS: "x86/mm: Found insecure W+X mapping at address ..."
by suse.dev＠fea.st 22 Jan '16

22 Jan '16

Upgraded Leap kernel 4.3 -> 4.4. Now get a kernel trace on boot. Posted upstream: http://www.gossamer-threads.com/lists/linux/kernel/2349962 just fyi-ing here. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 5

[opensuse-kernel] Tumbleweed snapshaot 20160116+ failed with no nvme module available
by Bruno Friedmann 22 Jan '16

22 Jan '16

Some regression with the arrival of 4.4.0 in TW https://bugzilla.opensuse.org/show_bug.cgi?id=963114 What was the most strange things, last week I was using 4.4.0 from K:S and it was working on a installed TW (installed with the previous 4.3) Someone has a clue about what's happened here ? and why nvme is missing. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 5

[opensuse-kernel] Proper procedures & install locations for grub2 updates when booting Opensuse Leap to RAID1 on EFI hardware?
by suse.dev＠fea.st 21 Jan '16

21 Jan '16

I'm grub2-booting OpenSUSE Leap Xen on UEFI hardware, with /boot & OS on GPT RAID1 array. I'd like to know what the contents of /boot/grub/device.map /etc/default/grub_installdevice should be in this GRUB2+EFI config to ensure correct grub2 installation to the right location, and to take best advantage of the 2-drive &/or RAID redundancy. And, what the procedure _should_ be after each /etc/default/grub change -- should it be mkinitrd -v update-bootloader --reinit each time? My configuration is as follows: My grub2, kernel & xen are current, uname -rm 4.4.0-3.g0567b9b-default x86_64 rpm -qa | egrep -i "xen-4|grub2-2" xen-4.6.0_06-403.4.x86_64 grub2-2.02~beta2-76.1.x86_64 I've got two drives /dev/sde, /dev/sdf They're partitioned as Device Start End Sectors Size Type /dev/sde1 2048 4095 2048 1M BIOS boot /dev/sde2 4096 618495 614400 300M EFI System /dev/sde3 618496 2715646 2097151 1024M Linux RAID /dev/sde4 2715648 1953525134 1950809487 930.2G Linux RAID Device Start End Sectors Size Type /dev/sdf1 2048 4095 2048 1M BIOS boot /dev/sdf2 4096 618495 614400 300M EFI System /dev/sdf3 618496 2715646 2097151 1024M Linux RAID /dev/sdf4 2715648 1953525134 1950809487 930.2G Linux RAID I've got two RAID1 arrays configured cat /proc/mdstat Personalities : [raid1] [raid10] md0 : active raid1 sde3[0] sdf3[1] 1048512 blocks super 1.0 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md1 : active raid1 sdf4[1] sde4[0] 975404544 blocks super 1.0 [2/2] [UU] bitmap: 1/8 pages [4KB], 65536KB chunk /dev/md0 holds "/boot mount | grep md0 /dev/md0 on /boot type ext4 (rw,noatime,journal_checksum,data=ordered) and /dev/md1 holds the OS etc pvs PV VG Fmt Attr PSize PFree /dev/md1 VG_X001 lvm2 a-- 930.19g 813.50g lvs | grep X001 LV_ROOT VG_X001 -wi-ao---- 20.00g LV_SWAP VG_X001 -wi-ao---- 2.00g LV_HOME VG_X001 -wi-ao---- 10.00g ... fstab mounts by UUID, where blkid /dev/md/x001\:0 -s UUID /dev/md/x001:0: UUID="3e40f30f-87ba-421c-9470-9d793536968a" and blkid /dev/sde2 /dev/sdf2 -s UUID -s TYPE -s PARTLABEL /dev/sde2: UUID="986E-2DB9" TYPE="vfat" PARTLABEL="EFI System Partition" /dev/sdf2: UUID="77A6-EB3D" TYPE="vfat" PARTLABEL="EFI System Partition" so cat /etc/fstab /dev/disk/by-uuid/3e40f30f-87ba-421c-9470-9d793536968a /boot ext4 noatime,acl,user_xattr,journal_checksum,barrier=1 0 2 UUID=986E-2DB9 /boot/efi vfat umask=0002,utf8=true,x-systemd.automount,noauto 0 2 ... When I make changes to /etc/default/grub, and exec grub2-mkconfig -o /boot/grub2/grub.cfg /boot/efi is populated/updated correctly /usr/bin/tree /boot/efi/EFI/opensuse/ /boot/efi/EFI/opensuse/ |- grub.xen-files |- grubx64.efi |- initrd-4.4.0-3.g0567b9b-default |- vmlinuz-4.4.0-3.g0567b9b-default |- xen-4.6.0_06-403.cfg |- xen-4.6.0_06-403.efi efi vars are updated efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0001 Boot0000* opensuse HD(2,1000,96000,6196ccc5-1e27-48e6-8372-2e64118e5d03)File(\EFI\OPENSUSE\GRUBX64.EFI) Boot0001* UEFI: Built-in EFI Shell Vendor(5023b95c-db26-429b-a648-bd47664c8012,)..BO and the system boots correctly. Atm, neither /boot/grub2/device.map /etc/defaults/grub_installdevice exist on this server. Where is grub2 actually being installed, by default? Since this is GPT, IIUC we're not installing to an MBR. How do we ensure that *both* EFI boot partitions are being used -- i.e., not just /dev/sde2, but /dev/sdf2 as well? What are the correct update procedures after /etc/default/grub changes? Thanks. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] Use pvops-enabled kernel for Xen (fate#315712)
by Michal Marek 20 Jan '16

20 Jan '16

Hi, you have probably noticed that the SUSE virtualization developers have been working on porting features from the kernel-source patches.xen series to the upstream Xen implementation. This mostly works nowadays, so at the SUSE Labs Conference last month, we agreed to finally get rid of kernel-xen in Factory and instead use kernel-default with CONFIG_XEN (the mainline option) enabled. I prepared a branch on github https://github.com/michal42/kernel-source stable-noxen which does exactly this. Test packages are building here: https://build.opensuse.org/project/show/home:michal-m:kernel-stable-noxen The kernel boots and works on my machine, both on bare metal and under the hypervisor (*), but there is some integration work to be done before it can be submitted to Factory: - The installer needs to cope with kernel-xen not available and choose kernel-default. Something like the attached patch should fix it (untested). - perl-Bootloader: Right now, it creates a Xen multiboot entry if the kernel is named -xen, otherwise it creates a regular linux entry. Create both entries if the Xen hypervisor is installed? - kernel-xen needs to be dropped from the patterns, but that's trivial - We have been building a kernel-obs-build-xen package for the OBS workers, which now disappears. Of course, there is lot more work to be done in making the xen -> pvops transition seamless in all corner cases. But that should not be a barrier to pushing the kernel to factory. (*) With the -default kernel, I do not see the kernel messages on the serial console with kernel /boot/xen.gz com1=115200 console=com1,vga module /boot/vmlinuz-4.2.2-0.g980fcdb-default ... console=tty0 console=ttyS0,115200 while I see them with kernel-xen. Michal

6 16

[opensuse-kernel] [PATCH] Remove patches.fixes/ptrace-getsiginfo
by Andreas Schwab 14 Jan '16

14 Jan '16

This has been fixed in 2.6.26 by e16b278. --- patches.fixes/ptrace-getsiginfo | 79 ----------------------------------------- series.conf | 1 - 2 files changed, 80 deletions(-) delete mode 100644 patches.fixes/ptrace-getsiginfo diff --git a/patches.fixes/ptrace-getsiginfo b/patches.fixes/ptrace-getsiginfo deleted file mode 100644 index 64e91b7..0000000 --- a/patches.fixes/ptrace-getsiginfo +++ /dev/null @@ -1,79 +0,0 @@ -From: Andreas Schwab <schwab(a)suse.de> -Subject: Add compat handler for PTRACE_GETSIGINFO -Patch-mainline: not yet - -Current versions of gdb require a working implementation of -PTRACE_GETSIGINFO for proper watchpoint support. Since struct siginfo -contains pointers it must be converted when passed to a 32-bit debugger. - -Signed-off-by: Andreas Schwab <schwab(a)suse.de> ---- - arch/powerpc/kernel/ppc32.h | 2 ++ - arch/powerpc/kernel/ptrace32.c | 27 +++++++++++++++++++++++++++ - 2 files changed, 29 insertions(+) - ---- a/arch/powerpc/kernel/ppc32.h -+++ b/arch/powerpc/kernel/ppc32.h -@@ -136,4 +136,6 @@ struct ucontext32 { - struct mcontext32 uc_mcontext; - }; - -+extern int copy_siginfo_to_user32(struct compat_siginfo __user *d, siginfo_t *s); -+ - #endif /* _PPC64_PPC32_H */ ---- a/arch/powerpc/kernel/ptrace32.c -+++ b/arch/powerpc/kernel/ptrace32.c -@@ -28,12 +28,15 @@ - #include <linux/security.h> - #include <linux/signal.h> - #include <linux/compat.h> -+#include <linux/elf.h> - - #include <asm/uaccess.h> - #include <asm/page.h> - #include <asm/pgtable.h> - #include <asm/switch_to.h> - -+#include "ppc32.h" -+ - /* - * does not yet catch signals sent when the child dies. - * in exit.c or in signal.c. -@@ -69,6 +72,27 @@ static long compat_ptrace_old(struct tas - #define FPRHALF(i) (((i) - PT_FPR0) & 1) - #define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) * 2 + FPRHALF(i) - -+static int compat_ptrace_getsiginfo(struct task_struct *child, compat_siginfo_t __user *data) -+{ -+ siginfo_t lastinfo; -+ int error = -ESRCH; -+ -+ read_lock(&tasklist_lock); -+ if (likely(child->sighand != NULL)) { -+ error = -EINVAL; -+ spin_lock_irq(&child->sighand->siglock); -+ if (likely(child->last_siginfo != NULL)) { -+ lastinfo = *child->last_siginfo; -+ error = 0; -+ } -+ spin_unlock_irq(&child->sighand->siglock); -+ } -+ read_unlock(&tasklist_lock); -+ if (!error) -+ return copy_siginfo_to_user32(data, &lastinfo); -+ return error; -+} -+ - long compat_arch_ptrace(struct task_struct *child, compat_long_t request, - compat_ulong_t caddr, compat_ulong_t cdata) - { -@@ -296,6 +320,9 @@ long compat_arch_ptrace(struct task_stru - 0, PT_REGS_COUNT * sizeof(compat_long_t), - compat_ptr(data)); - -+ case PTRACE_GETSIGINFO: -+ return compat_ptrace_getsiginfo(child, compat_ptr(data)); -+ - case PTRACE_GETFPREGS: - case PTRACE_SETFPREGS: - case PTRACE_GETVRREGS: diff --git a/series.conf b/series.conf index 5de663c..3985281 100644 --- a/series.conf +++ b/series.conf @@ -128,7 +128,6 @@ patches.drivers/ppc64-adb patches.suse/suse-ppc64-branding patches.arch/ppc-prom-nodisplay.patch -+needs_update patches.fixes/ptrace-getsiginfo ######################################################## # powerpc/little endian -- 2.7.0 -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] Please raise disk size constraints for kernel builds
by Stefan Bruens 11 Jan '16

11 Jan '16

Hi, builds of kernel packages occasionally fail due to unsufficient disk space. Happens for kernel-default,-vanilla,-... on 64bit archs. Used resources on for Kernel:stable/Kernel:HEAD (MBytes) Kernel:stable standard x86_64 kernel-vanilla Disk: 16273, Memory: 728, Time: 20519 Kernel:HEAD standard x86_64 kernel-debug Disk: 16279, Memory: 758, Time: 24744 Kernel:HEAD standard x86_64 kernel-default Disk: 16232, Memory: 1260, Time: 5804 Kernel:HEAD standard x86_64 kernel-pv Disk: 16366, Memory: 1263, Time: 4837 Kernel:HEAD standard x86_64 kernel-vanilla Disk: 16860, Memory: 751, Time: 17809 Kernel:HEAD PPC ppc64 kernel-vanilla Disk: 15142, Memory: 1117, Time: 6345 Kernel:HEAD ARM aarch64 kernel-vanilla Disk: 15214, Memory: 746, Time: 10565 Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 6

[opensuse-kernel] [PATCH] rpm/constraints.in: Increase disk space requirements
by Stefan Brüns 11 Jan '16

11 Jan '16

32 bit archs need about 14 GByte disk space for kernel binary packages, 18 GByte are required for 64 bit archs. Non-binary packages are fine with 3GByte. Signed-off-by: Stefan Brüns <stefan.bruens(a)rwth-aachen.de> --- rpm/constraints.in | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/rpm/constraints.in b/rpm/constraints.in index 181a62e..8dafbe9 100644 --- a/rpm/constraints.in +++ b/rpm/constraints.in @@ -1,18 +1,15 @@ <constraints> <hardware> <disk> - <size unit="G">7</size> + <size unit="G">3</size> </disk> </hardware> <overwrite> <conditions> - <arch>i586</arch> - <arch>x86_64</arch> @BINARY_PACKAGES_XML@ </conditions> <hardware> - <processors>8</processors> <disk> <size unit="G">14</size> </disk> @@ -21,15 +18,15 @@ <overwrite> <conditions> - <arch>ppc</arch> + <arch>aarch64</arch> <arch>ppc64</arch> <arch>ppc64le</arch> + <arch>x86_64</arch> @BINARY_PACKAGES_XML@ </conditions> <hardware> - <processors>4</processors> <disk> - <size unit="G">14</size> + <size unit="G">18</size> </disk> </hardware> </overwrite> @@ -38,6 +35,29 @@ <conditions> <arch>i586</arch> <arch>x86_64</arch> +@BINARY_PACKAGES_XML@ + </conditions> + <hardware> + <processors>8</processors> + </hardware> + </overwrite> + + <overwrite> + <conditions> + <arch>ppc</arch> + <arch>ppc64</arch> + <arch>ppc64le</arch> +@BINARY_PACKAGES_XML@ + </conditions> + <hardware> + <processors>4</processors> + </hardware> + </overwrite> + + <overwrite> + <conditions> + <arch>i586</arch> + <arch>x86_64</arch> <package>kernel-obs-qa</package> </conditions> <sandbox>kvm</sandbox> -- 2.1.4 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] Re: [opensuse-factory] SSD erased after fstrim
by Andrei Borzenkov 07 Jan '16

07 Jan '16

07.01.2016 10:14, Andrei Borzenkov пишет: > 07.01.2016 00:49, Jan Engelhardt пишет: >> >> On Wednesday 2016-01-06 21:56, Frank Kunz wrote: >> >>> When the problem can be fixed by reinstall the bootloader only >>> it looks a bit that the fstrim command is not aware of the bootloader >>> installation location and therefore it is getting trimmed. My setup has >>> the bootloader installed in the root partition. >> >> Of course - that makes total sense. The filesystem basically has no idea >> what you are doing with unreferenced sectors outside its purview. > > btrfs explicitly reserves space for bootloader; if btrfs then "trims" > this space, it is a serious bug in btrfs. I actually expect any > filesystem to trim only space it has allocated and knows about. > http://git.kernel.org/cgit/linux/kernel/git/fdmanana/linux.git/commit/?h=in… -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1