WARNING ... drivers/gpu/drm/ttm/ttm_bo_vm.c...
by poma
...
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
8 years, 11 months
Patch inclusion/backport request (BZ #1084829)
by Paul Moore
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
8 years, 11 months
config-armv7-generic: USB_G_DBGP_PRINTK and USB_G_DBGP_SERIAL
by Paul Bolle
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
8 years, 11 months
Computer freeze at graphical login with 3.15-rc0-git kernels
by Fidel Leon
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
8 years, 11 months
3.15 & Bonding
by poma
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
8 years, 12 months