You are not logged in.
I am running a custom 3.9 kernel and after update to systemd 203-1 from testing I get this:
WARNING: at drivers/gpu/drm/drm_crtc.c:82 drm_warn_on_modeset_not_all_locked+0x8d/0xc0()
I guess its related to:
http://www.spinics.net/lists/dri-devel/msg37954.html
Just a heads up, had to boot from usb flash and chroot and downgrade to systemd 202-2. Anybody else with this problem, Intel HD2000 here?
I know that kernel is not from the testing repo but I guess it should apply also (this one is pure mainline kernel, just stripped down for my configuration).
Last edited by combuster (2013-05-10 08:40:30)
Offline
I have [testing] enabled on my laptop and am experiencing no such problems; different video though (nvidia).
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
https://git.kernel.org/cgit/linux/kerne … b8657a58d8
I guess this should fix it, but I still don't have a clue why systemd 203 triggers this in my case, anyway that panic notifier is bogus as explained in the link in the first post, and AFAICT this patch addresses that very same issue. Pull request is for 3.10 but I really hope they will backport this to 3.9.1 (if not I'll do it myself if it doesn't brake the API too much ). For now I have to stay with systemd 202.
Thanks graysky, another archer reported that systemd upgrade went smoothly for him also, so for now I really hope this is an isolated case.
Offline
After compiling the kernel from Daniel Vetter's intel-drm tree regarding this commit in particular
http://cgit.freedesktop.org/~danvet/drm … 3778993a1d
I can see the real culprit for the kernel panic:
So a NULL pointer dereference bug triggered by systemd. Now I can search for relevant bug reports or submit one if there are none...
Offline
So a NULL pointer dereference bug triggered by systemd. Now I can search for relevant bug reports or submit one if there are none...
Really? Because it looks like something in SMACK is at fault here based on the trace. I can't possibly see how a userspace process could be considered directly responsible for a kernel panic.
Offline
Lennart said that also, so I've filed this on kernel bugzilla.
Why I was confused at the moment was because of the fact that I have never had a kernel panic after updating. It was in 99% of cases induced after a kernel upgrade. I havent had a clue where this report should be filed up against (ext4 was there because of the xattrs but I wasn't sure).
Offline
Got the same. Checked with selinux - it has a comment about the dget() call from which the NULL pointer came, that it can return NULL on boot - but smack doesn't seem to check dget()'s result before sending it off to a getxattr() call.
going to test the following change soon, I'm in a hurry to get my stuff working after a few update-breaks; and compiling a kernel takes ages here so I thought I'd drop off this paste here as the backtrace above was useful (my screen wasn't big enough to show the important parts of it )
--- security/smack/smack_lsm.c.old 2013-05-09 11:09:28.433490642 +0200
+++ security/smack/smack_lsm.c 2013-05-09 11:09:30.218428573 +0200
@@ -2589,6 +2589,8 @@ static void smack_d_instantiate(struct d
* Get the dentry for xattr.
*/
dp = dget(opt_dentry);
+ if (dp == NULL)
+ goto unlockandout;
fetched = smk_fetch(XATTR_NAME_SMACK, inode, dp);
if (fetched != NULL)
final = fetched;
(in SELinux it's `goto out_unlock' where the same as in smack's unlockandout part happens, and the function comes from selinux_d_instantiate, so I hope this is okay)
/me hurries off while the kernel is compiling for the next 2 hours...
Last edited by Blµb (2013-05-09 09:20:05)
You know you're paranoid when you start thinking random letters while typing a password.
A good post about vim
Python has no multithreading.
Offline
Your machine should be faster, I can't try this out for another four hours, but I'll test it as soon as I get home. Please post back with the results
/edit: Learned a lot from your posts guys, thnx big time
Last edited by combuster (2013-05-09 09:53:48)
Offline
Still panicking, just not necessarily in the getxattr call. When I find the time I'll look more into it.
You know you're paranoid when you start thinking random letters while typing a password.
A good post about vim
Python has no multithreading.
Offline
What about todays update to systemd 204? Warning: you have to edit the kernel line: init=/usr/lib/systemd/systemd
Last edited by Thorsten Reinbold (2013-05-09 17:06:06)
Offline
Offline
Ok, sorry. I haven't noticed your post about that.
Offline
Well I did what I could for now - I've disabled SMAC in kernel, recompiled and there's no panic. But I'll probably find the time tonight to look a bit closely at the panics (now I have a working kernel with systemd-204) and try to find the culprit. Also I'm there to confirm if any of the Blµb's patches work for me.
Offline
might be a good idea to update the topic title (remove the systemd part)
Also, you didn't actually need to recompile a kernel without smack just don't activate it (ie remove `security=smack' from the kernel commandline, unless you made the kernel default to it - I always let it default to DAC and specify the security system in grub.cfg for such reasons )
Tried to patch it in a different way too, didn't work - but I also have the problem that my screen's not big enough to show a full trace so the upper half (the actually important functions) are cut off, so I'd need to setup a VM to actually debug this.
You know you're paranoid when you start thinking random letters while typing a password.
A good post about vim
Python has no multithreading.
Offline
No need to, I've contacted Casey Schaufler and asked him to take a look at the bug report
https://bugzilla.kernel.org/show_bug.cgi?id=57791
Solution is there, I just need to test it as soon as I get off work (not for another 7-8hrs).
/edit: Good point about configuring default security protocol as a kernel parameter, didn't crossed my mind before, thnx!
Last edited by combuster (2013-05-10 08:45:43)
Offline
Blµb, is this patch working for you, I still get the panic...
Offline
Here is the one that works for me:
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index d52c780..2ceafae 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -59,7 +59,8 @@ static char *smk_fetch(const char *name, struct inode *ip, struct dentry *dp)
char *buffer;
char *result = NULL;
- if (ip->i_op->getxattr == NULL)
+ if (ip->i_op->getxattr == NULL || dp->d_inode == NULL ||
+ dp->d_fsdata == NULL)
return NULL;
buffer = kzalloc(SMK_LONGLABEL, GFP_KERNEL);
Blµb, how about you?
Offline
didn't get a chance to test yet, sorry, and this week's gonna be busy... but it looks okay, however do you use both patches or just that one? As then I'd still worry about the dp pointer being NULL at some point, though I don't know the surroundings well enough to be certain.
You know you're paranoid when you start thinking random letters while typing a password.
A good post about vim
Python has no multithreading.
Offline
That is for the cgroup dev's to solve, this is just a quick fixup for the smack.
The last patch is ok, it's essentially the same one just added check for fsdata. Casey wrote it pretty quick...
Offline