[10:43] <wgrant> apw: Could you be convinced to include "s390/kernel: fix ptrace peek/poke for floating point registers" (55a423b) in the next xenial kernel? Fixes a panic we ran into on the buildds today.
[10:43] <wgrant> (tested by building gdb; the panic was first seen in its test suite)
[10:44] <apw> wgrant, yep, i see from your ppa that that is a backport?  do you have the one you have tested, oculd you email it to me and i'll apply it
[10:45] <apw> wgrant, and if there is a bug number wang it in here
[10:46] <wgrant> apw: I haven't filed a bug, can do so in a bit if you need. The backport is trivial, but will find a patch.
[10:49] <wgrant> apw: http://paste.ubuntu.com/13665866/ is the diff.
[10:49] <wgrant> Looks identical to the git diff for me, but it didn't apply directly. Possibly line numbers too far off or something.
[10:50] <wgrant> Except they're the same.
[10:50] <wgrant> Weird.
[11:22] <apw> ack thanks
[11:24] <apw> wgrant, ok it cherry-picked for me, so ... wierd
[11:26] <apw> and that ... i recon ... is a cve if "overwrites the task structure"
[11:26] <apw> is correct
[11:26] <wgrant> apw: Oh yeah, it's totally exploitable.
[11:26] <wgrant> I probably just misapplied it, I was rushing.
[11:27] <apw> given we have a bad s390x package split as well pending on tip
[11:27] <apw> i think we should get that uploaded sooner rather than later
[11:27] <apw> though i would like this 4.3 to go out at least
[11:27] <apw> i assume this is affecting the bootstrap of main though .. right ?
[11:28] <wgrant> I have it installed on one buildd (z13-008), and it's only affected gdb so far.
[11:28] <wgrant> main is built, apart from various unrelated FTBFSes.
[11:28] <wgrant> I just manually threw gdb at the one with the fixed kernel.
[11:28] <apw> so you goosed gdb thorught hte fixed one, right
[11:28] <apw> ok then i will let this one migrate, i should have the final testing ok in about 2 hours
[11:28] <wgrant> Yep.
[11:28] <wgrant> Not super urgent.
[11:28] <apw> then i'll get this one uploaded
[15:54] <xnox> apw, yo =)
[15:54] <apw> xnox, hi
[15:54] <xnox> totally forgot, could you please cherrypick a patch that prevents buildds blowing up, on funny PIE builds? =)
[15:54] <xnox> apw, unless one of the other engineers already talked to you about it
[15:55] <apw> "s390/kernel: fix ptrace peek/poke for floating point registers"
[15:55] <apw> xnox, ^^ that ?
[15:55] <xnox> apw, yes that.
[15:55] <apw> xnox, is picked and will be in the next upload, i was under the impression only gdb had hit it thus far and had been handled ?
[15:56] <xnox> apw, yeah, wgrant quickly built a kernel and upgraded buildd8, so buildd 8 is a good one =)
[15:56] <xnox> but having that in the next kernel would be dandy. thank you =)
[15:56] <apw> heh is that why she is offline, held for special projects
[15:57] <apw> xnox, that and your split to make linux-virtual work are on deck for the next upload
[15:58] <xnox> apw, brilliant.
[16:04] <rtg> apw, I could turn the crank on that as soon as -1.10 is promoted
[16:04] <apw> yep, i've dropped the tag, just waiting
[16:04] <rtg> otherwise it might be a few days
[16:05] <apw> should be done within the hour in theory
[16:05] <apw> because you know friday is a classy day to release a kernel
[16:05] <rtg> apw, I'll check back in a bit
[16:05] <rtg> especially a new kernel release
[16:06] <apw> perhaps we should have waited till monday
[16:12] <rtg> apw, this way we'll have plenty of email to deal with first thing Monday morning
[16:13] <apw> rtg, i might be able to catch it before it copies out
[16:14] <rtg> apw, oh, let it go. I think its pretty stable
[16:14] <rtg> apw, after all, its got the cking stamp of approval
[16:15] <apw> yeah :
[16:15] <apw> :)
[16:15] <apw> who upgrades over teh weekend anyhow, thats a silly idea
[16:16] <cking> release often I say
[16:17] <apw> yeah i'd like it to be a lot cheaper to update but its really not
[16:54] <cristian_c> jsalisbury: hello
[16:55] <jsalisbury> cristian_c, hello.  I haven't had much time to look into the new issues yet.  It sounds like the regression is now fixed for you?
[16:56] <cristian_c> jsalisbury: yes, as I've stated in launchpad report
[16:56] <jsalisbury> cristian_c, ok.  I'll make some time to look at the other issue
[16:57] <cristian_c> jsalisbury: I've got a question
[16:57] <jsalisbury> cristian_c, sure
[16:58] <cristian_c> jsalisbury: last time, I've read fix went in 4.3-rc2
[16:59] <jsalisbury> cristian_c, the fix for the regression? or the fix for the new issue?
[16:59] <cristian_c> jsalisbury: but I've noticed that regression is disappeared already in 4.2.0-18
[16:59] <cristian_c> jsalisbury: about regression
[16:59] <jsalisbury> cristian_c, the fix was cc'd to upstream stable, so it's eventually going to make it's way into all the stable kernels
[16:59] <cristian_c> 4.2.0-16 is default kernel in 15.10
[17:00] <cristian_c> after first updates, kernel goes to 4.2.0-18 version number
[17:01] <cristian_c> jsalisbury: so, where can I find the commit (if it's public)
[17:01] <cristian_c> ?
[17:02] <jsalisbury> cristian_c, this is the commit:
[17:02] <jsalisbury> commit 8a1513b49321e503fd6c8b6793e3b1f9a8a3285b
[17:02] <jsalisbury> Author: Kyle Evans <kvans32@gmail.com>
[17:02] <jsalisbury> Date:   Fri Sep 11 10:40:17 2015 -0500
[17:02] <jsalisbury>     hp-wmi: limit hotkey enable
[17:02] <cristian_c> ok, thank you very much
[17:03] <jsalisbury> cristian_c, you can get it out of linus' tree or any of the stable trees, but it will have a different SHA1
[17:03] <jsalisbury> in the stable trees
[17:03] <cristian_c> ok
[23:20] <ccope> when do updates from the upstream kernel get backported to LTS kernel backport packages?
[23:21] <ccope> specifically, I need https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0480334 in linux-image-generic-lts-utopic for trusty
[23:26] <henrix> ccope: hmm... i see.  so, that commit is meant to be applied to stable kernels >= v3.18, thus it will never be applied to the corresponding stable kernel (3.16.7-ckt)
[23:27] <henrix> ccope: however, the utopic kernel actually backported overlayfs so that commit may actually be applicable to that kernel
[23:29] <henrix> ccope: my suggestion would be to open a bug against that kernel, requesting that specific commit to be included
[23:29] <henrix> (feel free to assign that bug to me ;-) )
[23:31] <ccope> henrix, ok cool, thanks!
[23:55] <ccope> henrix, i'm unable to assign you but the bug is here: https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1523000
[23:59] <henrix> ccope: ack, thanks.  i'll assign it to myself later