kernel April 2014

kernel@lists.fedoraproject.org

19 participants
15 discussions

WARNING ... drivers/gpu/drm/ttm/ttm_bo_vm.c...
by poma 10 Apr '14

10 Apr '14

... Command line: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x20rawhide\x20x86_64 xdriver=modesetting BOOT_IMAGE=vmlinuz Kernel command line: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x20rawhide\x20x86_64 xdriver=modesetting BOOT_IMAGE=vmlinuz ... ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1230 at drivers/gpu/drm/ttm/ttm_bo_vm.c:269 ttm_bo_vm_open+0x52/0x80 [ttm]() CPU: 1 PID: 1230 Comm: Xorg Not tainted 3.15.0-0.rc0.git9.1.fc21.x86_64 #1 Call Trace: [<ffffffff817db690>] dump_stack+0x4d/0x66 [<ffffffff81096b9d>] warn_slowpath_common+0x7d/0xa0 [<ffffffff81096cca>] warn_slowpath_null+0x1a/0x20 [<ffffffffa0250452>] ttm_bo_vm_open+0x52/0x80 [ttm] [<ffffffff810956fe>] copy_process.part.23+0x1b9e/0x1e90 [<ffffffff81095bb6>] do_fork+0xc6/0x4b0 [<ffffffff811de68f>] ? might_fault+0x5f/0xb0 [<ffffffff817ef695>] ? sysret_check+0x22/0x5d [<ffffffff81096026>] SyS_clone+0x16/0x20 [<ffffffff817efa49>] stub_clone+0x69/0x90 [<ffffffff817ef669>] ? system_call_fastpath+0x16/0x1b ---[ end trace bc31de8c9c4c4d52 ]--- ... https://bugzilla.redhat.com/show_bug.cgi?id=1085145 https://bugzilla.redhat.com/attachment.cgi?id=883813 poma

1 1

Patch inclusion/backport request (BZ #1084829)
by Paul Moore 09 Apr '14

09 Apr '14

Hello, I'd like to request a backport of the patch below, currently merged upstream and targeted for 3.15. The patch fixes a number of problems relating to SELinux and systemd-sysctl which are starting to appear for F20 in the RH bugzilla. One such example can be seen here: * https://bugzilla.redhat.com/show_bug.cgi?id=1084829 If there is anything I can do to help get this patch into Fedora let me know. Thanks, -Paul commit f64410ec665479d7b4b77b7519e814253ed0f686 Author: Paul Moore <pmoore(a)redhat.com> Date: Wed Mar 19 16:46:18 2014 -0400 selinux: correctly label /proc inodes in use before the policy is loaded This patch is based on an earlier patch by Eric Paris, he describes the problem below: "If an inode is accessed before policy load it will get placed on a list of inodes to be initialized after policy load. After policy load we call inode_doinit() which calls inode_doinit_with_dentry() on all inodes accessed before policy load. In the case of inodes in procfs that means we'll end up at the bottom where it does: /* Default to the fs superblock SID. */ isec->sid = sbsec->sid; if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) { if (opt_dentry) { isec->sclass = inode_mode_to_security_class(...) rc = selinux_proc_get_sid(opt_dentry, isec->sclass, &sid); if (rc) goto out_unlock; isec->sid = sid; } } Since opt_dentry is null, we'll never call selinux_proc_get_sid() and will leave the inode labeled with the label on the superblock. I believe a fix would be to mimic the behavior of xattrs. Look for an alias of the inode. If it can't be found, just leave the inode uninitialized (and pick it up later) if it can be found, we should be able to call selinux_proc_get_sid() ..." On a system exhibiting this problem, you will notice a lot of files in /proc with the generic "proc_t" type (at least the ones that were accessed early in the boot), for example: # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }' system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax However, with this patch in place we see the expected result: # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }' system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax Cc: Eric Paris <eparis(a)redhat.com> Signed-off-by: Paul Moore <pmoore(a)redhat.com> Acked-by: Eric Paris <eparis(a)redhat.com> security/selinux/hooks.c | 36 ++++++++++++++++++++++++++-------- 1 file changed, 27 insertions(+), 9 deletions(-) -- paul moore security and virtualization @ redhat

2 2

config-armv7-generic: USB_G_DBGP_PRINTK and USB_G_DBGP_SERIAL
by Paul Bolle 09 Apr '14

09 Apr '14

0) Building an rpm for (vanilla) v3.14, using the origin/f20 branch of kernel.git, triggers a warning (a couple of times): .config:5466:warning: override: USB_G_DBGP_SERIAL changes choice state 1) It turns out config-armv7-generic contains both CONFIG_USB_G_DBGP_PRINTK=y and CONFIG_USB_G_DBGP_SERIAL=y 2) But in drivers/usb/gadget/Kconfig we see (summarized): choice prompt "EHCI Debug Device mode" default USB_G_DBGP_SERIAL config USB_G_DBGP_PRINTK bool "printk" config USB_G_DBGP_SERIAL bool "serial" endchoice If I'm reading this correctly, this means that we need to choose between USB_G_DBGP_PRINTK and USB_G_DBGP_PRINTK. 3) Should we remove one of these two Kconfig macros? Or is the upstream Kconfig file incorrect and can both symbols be set simultaneously? Paul Bolle

3 4

Computer freeze at graphical login with 3.15-rc0-git kernels
by Fidel Leon 05 Apr '14

05 Apr '14

Hi, I'd like to ask for some assistance with 3.15-rc0.git kernels (for Rawhide). Both 3.15 versions: kernel-3.15.0-0.rc0.git2.1.fc21.i686 kernel-3.15.0-0.rc0.git7.1.fc21.i686 do freeze my computer at graphical login screen. Booting kernel-3.14.0-1.fc21.i686 works okay. Since my desktop completely freezes I can't anything like dmesg... Any clue? -- Fidel Leon fidelleon(a)mykolab.com GSM: +34 639 000 390 AA34 074D 4763 2203 C1B1 7DD7 2107 DB9A AD74 FB97

3 6

3.15 & Bonding
by poma 02 Apr '14

02 Apr '14

Are you all all right? New Tour de Bugs... /sys/devices/virtual/net/bond0/bonding/mode: active-backup 1 - systemd-networkd dmesg: BUG: sleeping function called from invalid context at mm/slub.c:965 in_atomic(): 1, irqs_disabled(): 0, pid: 593, name: systemd-network 2 locks held by systemd-network/593: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8169e57b>] rtnetlink_rcv+0x1b/0x40 #1: (&bond->curr_slave_lock){+...+.}, at: [<ffffffffa0487291>] bond_enslave+0xf31/0xf50 [bonding] CPU: 2 PID: 593 Comm: systemd-network Not tainted 3.15.0-0.rc0.git2.1.fc21.x86_64 #1 Call Trace: dump_stack+0x4d/0x66 __might_sleep+0x17e/0x230 kmem_cache_alloc_node+0x4a/0x390 [<ffffffff816779dd>] __alloc_skb+0x5d/0x2d0 [<ffffffff816a0bd8>] rtmsg_ifinfo+0x48/0x110 [<ffffffff810fa18d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8109dd45>] ? __local_bh_enable_ip+0x75/0xe0 [<ffffffffa0485ca7>] bond_change_active_slave+0x197/0x670 [bonding] [<ffffffffa0486264>] bond_select_active_slave+0xe4/0x1e0 [bonding] [<ffffffffa048729a>] bond_enslave+0xf3a/0xf50 [bonding] [<ffffffff8169fdf2>] do_setlink+0xa02/0xa70 [<ffffffff813f4fc6>] ? nla_parse+0x96/0xe0 [<ffffffff816a0da1>] rtnl_setlink+0xc1/0x130 [<ffffffff810a1739>] ? ns_capable+0x39/0x70 [<ffffffff8169e64b>] rtnetlink_rcv_msg+0xab/0x270 [<ffffffff8169e57b>] ? rtnetlink_rcv+0x1b/0x40 [<ffffffff8169e57b>] ? rtnetlink_rcv+0x1b/0x40 [<ffffffff8169e5a0>] ? rtnetlink_rcv+0x40/0x40 [<ffffffff816c3e29>] netlink_rcv_skb+0xa9/0xc0 [<ffffffff8169e58a>] rtnetlink_rcv+0x2a/0x40 [<ffffffff816c3420>] netlink_unicast+0x100/0x1e0 [<ffffffff816c3847>] netlink_sendmsg+0x347/0x770 [<ffffffff8166c78c>] sock_sendmsg+0x9c/0xe0 [<ffffffff811de22f>] ? might_fault+0x5f/0xb0 [<ffffffff811de278>] ? might_fault+0xa8/0xb0 [<ffffffff811de22f>] ? might_fault+0x5f/0xb0 [<ffffffff8166cd04>] SYSC_sendto+0x124/0x1d0 [<ffffffff81024879>] ? sched_clock+0x9/0x10 [<ffffffff810ddb75>] ? local_clock+0x25/0x30 [<ffffffff8111cfc9>] ? current_kernel_time+0x69/0xd0 [<ffffffff810fa0b5>] ? trace_hardirqs_on_caller+0x105/0x1d0 [<ffffffff810fa18d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8166dede>] SyS_sendto+0xe/0x10 [<ffffffff817e79a9>] system_call_fastpath+0x16/0x1b - NetworkManager dmesg: BUG: sleeping function called from invalid context at mm/slub.c:965 in_atomic(): 1, irqs_disabled(): 0, pid: 73, name: kworker/u16:5 4 locks held by kworker/u16:5/73: #0: ("%s"(bond_dev->name)){.+.+.+}, at: [<ffffffff810bbd14>] process_one_work+0x1b4/0x6f0 #1: ((&(&bond->mii_work)->work)){+.+.+.}, at: [<ffffffff810bbd14>] process_one_work+0x1b4/0x6f0 #2: (rtnl_mutex){+.+.+.}, at: [<ffffffff8169d9c5>] rtnl_trylock+0x15/0x20 #3: (&bond->curr_slave_lock){+...+.}, at: [<ffffffffa040d2bd>] bond_mii_monitor+0x51d/0x7f0 [bonding] CPU: 0 PID: 73 Comm: kworker/u16:5 Not tainted 3.15.0-0.rc0.git2.1.fc21.x86_64 #1 Workqueue: bond0 bond_mii_monitor [bonding] Call Trace: [<ffffffff817d3c00>] dump_stack+0x4d/0x66 [<ffffffff810d044e>] __might_sleep+0x17e/0x230 [<ffffffff8121034a>] kmem_cache_alloc_node+0x4a/0x390 [<ffffffff816779dd>] __alloc_skb+0x5d/0x2d0 [<ffffffff816a0bd8>] rtmsg_ifinfo+0x48/0x110 [<ffffffff810fa18d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8109dd45>] ? __local_bh_enable_ip+0x75/0xe0 [<ffffffffa0409ca7>] bond_change_active_slave+0x197/0x670 [bonding] [<ffffffffa040a264>] bond_select_active_slave+0xe4/0x1e0 [bonding] [<ffffffffa040d2c6>] bond_mii_monitor+0x526/0x7f0 [bonding] [<ffffffffa040cdf6>] ? bond_mii_monitor+0x56/0x7f0 [bonding] [<ffffffff810bbd80>] process_one_work+0x220/0x6f0 [<ffffffff810bbd14>] ? process_one_work+0x1b4/0x6f0 [<ffffffff810bc36b>] worker_thread+0x11b/0x3a0 [<ffffffff810bc250>] ? process_one_work+0x6f0/0x6f0 [<ffffffff810c473f>] kthread+0xff/0x120 [<ffffffff810c4640>] ? insert_kthread_work+0x80/0x80 [<ffffffff817e78fc>] ret_from_fork+0x7c/0xb0 [<ffffffff810c4640>] ? insert_kthread_work+0x80/0x80 - Ethernet Channel Bonding Driver, v3.7.1 woes https://bugzilla.redhat.com/show_bug.cgi?id=1083455 - 3.15.0-0.rc0.git2.1.fc21.x86_64 Bonding https://bugzilla.redhat.com/attachment.cgi?id=881690 poma

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel April 2014