[07:34] <ppisati> moin
[07:34] <zequence> apw: I did in deed have trouble booting -lowlatency on one of my PCs. Going to try some more this evening.
[07:38] <apw> zequence, ok thanks
[07:38] <apw> ppisati, moin
[07:38] <apw> (if you can call this un-loved hour morning)
[08:19]  * smb looks amazed at the blazing brightness outside his window
[08:19] <smb> apw, If it isn't morning its lunchtime already
[08:31] <apw> smb, i can work with that :)
[08:34] <smb> apw, Heh, it better is not. Otherwise there is another morning gone without much progress
[08:34] <apw> smb, but think what a lot you can fit in in the afternoon ...
[09:12] <apw> henrix, hey .. i am doing a real dirty on the kernel cve tree, so please don't push it to our output tree
[09:13] <apw> henrix, you can add thnigs and push them, just ignore the output :)
[09:19] <henrix> apw: ack :)
[09:32] <lag> cking: So close ... :)
[09:32] <cking> lag, i obviously need more coffee
[09:33] <cking> normally I get it right first time :-/
[09:33] <lag> cking: Submit one more time and I'll added to my -fixes branch - should be in by -rc3
[09:33] <cking> lag, which mailing list do I need to send it to so I don't screw it up
[09:35] <cking> is there an arm specific one?
[09:35] <lag> cking: I usually do; `git show {sha1|HEAD} | ./scripts/get_maintainer.pl` and paste in the maintainers and the lists
[09:35] <lag> cking: There isn't, but LKML is always a must
[09:36] <cking> oh, bummer, I missed the the lkml one 'cos I can't cut n paste, doh
[09:36] <lag> cking: What do you mean?
[09:36] <cking> i mean I'm being stupid today
[09:36] <lag> cking: :)
[09:37] <cking> overly lagged
[09:39] <cking> lag, btw, I'm still trying to get that Amiga video out working, I need to spend some dosh on a correct video convertor
[09:40] <lag> cking: The original one, or one you've written?
[09:40] <lag> cking: I had the original one working on my normal TV
[09:40] <lag> cking: Is your TV digital only?
[09:41] <cking> lag, I don't have a TV, so I am trying to get it to work on a bog standard monitor using nefarious tricks
[09:45] <apw> henrix, ok things are back to normal, you can 'trust' the autotriager's branch again
[09:46] <henrix> apw: great, thanks
[09:57] <lag> cking: Ah, that'll explain it then - as long as you're having fun with it still :)
[09:58] <cking> oh yeah, much appreciated to have this great bit of kit to tinker with :-)
[12:12] <apw> henrix, ok ... i would like to 'break' the tracker again, are we in a safe place for that ?
[12:12] <henrix> apw: yep, haven't been touching it for a while 
[12:12] <apw> henrix, ta
[13:06] <henrix> apw: is it safe for me to edit the cvetracker?
[13:06] <apw> henrix, should be indeed
[13:06] <henrix> apw: cool, thanks
[13:07] <apw> i'm about to get a heap of unretires so we can do some analysis
[13:07] <apw> so let me know when you are done
[13:10] <apw> henrix, ^
[13:11] <henrix> apw: ok, go ahead. i'm still working on a cve, so it may take a while before i push anything
[13:11] <apw> henrix, :), this is likely to just explode :)
[13:12] <henrix> apw: heh.  anyway, i'll ping you later when i actually need to push something
[13:12] <henrix> so, feel free to explode the world :)
[13:13] <apw> henrix, thanks ... it is going to be a while running i suspect
[13:13] <henrix> ack
[13:20] <smb> apw, bugger, so at least only backporting those changes was not sufficient to resolve the hang. next round I am adding the folding back directly to that kvm loop
[13:21] <apw> smb, bah, well the little if is a good measure of the issue
[13:21] <smb> yeah
[13:23] <henrix> apw: just fyi, looks like i don't need to touch cvetracker afterall
[13:27] <apw> henrix, handy 
[14:08]  * rtg just completely messed up a linux-firmware upload
[14:08] <apw> rtg, ooops, how so
[14:09] <rtg> apw, forgot to re-fetch before rebasing, then force pushed.
[14:09] <rtg> the archive hates me now
[14:10] <apw> rtg, oh crap
[14:11] <rtg> hmm, I'll get on top of it in a bit
[14:11] <apw> rtg, does a git log -g origin/master (or whattever) have anything useful in it
[14:11] <apw> rtg, and if you have the "commits" which it listed when you pushed on your buffer
[14:12] <apw> rtg, like "XXXX...YYYY" which is said when you pushed, thne that XXXX will still be in the repo on zinc
[14:12] <apw> and on zinc you cna branch   git branch FOO XXXX
[14:12] <apw> and then fetch XXX and recover it
[14:13] <rtg> apw, grandmother,... eggs, .... :)
[14:13] <apw> habit :)
[14:18] <smb> apw, Oh well, neither approach was an improvement. Actually even the first backport made it happen a lot quicker... I am pretty sure we know the kind of breakage ... just not exactly the remedy... Have to fuzz around with it more
[14:22] <apw> smb, odd indeed
[14:22] <apw> smb, i guess there must be an irq in there at least
[14:23] <smb> apw, Yeah, trying the BUG path next
[15:12] <bjf> ppisati, can you verify bug 1258174 ?
[15:12] <ubot2`> Launchpad bug 1258174 in linux (Ubuntu Saucy) "wl12xx borked after one up/down cycle" [Medium,Confirmed] https://launchpad.net/bugs/1258174
[15:13] <ppisati> bjf: yep
[15:14] <bjf> jsalisbury, is bug 1254091 something you can verify or pester the bug reporter to do so ?
[15:14] <ubot2`> Launchpad bug 1254091 in linux (Ubuntu Saucy) "intel_pstate no_turbo patch from upstream" [Medium,In progress] https://launchpad.net/bugs/1254091
[15:27] <smb> apw, argh, got fooled by #define hell again. I was using preempt_fold_need_resched() in my first attempt, which looked to be exactly the if and set I wanted... Unfortunately only if CONFIG_PREEMPT is set. Otherwise its doing nothing (which may be an error that Peter still is doing). Now that I spelled it out and added a BUG_ON(preempt_count) in that loop it is actually running
[15:28] <jsalisbury> bjf, I don't think I can verify, so I'll ping the bug reporter.
[15:28] <bjf> jsalisbury, thanks
[15:31] <jsalisbury> bjf, I just emailed him directly
[15:32] <bjf> plars, the btrfs failure i see on other systems occasionally
[15:32] <plars> I'm looking at https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1267469 and got 3 failures on the regression tests. I think all these line up with some known issues from the past, but if someone has an opinion on them, please let me know
[15:32] <ubot2`> Launchpad bug 1267469 in Kernel SRU Workflow "linux-ti-omap4: 3.2.0-1443.62 -proposed tracker" [Medium,In progress]
[15:33] <plars> bjf: maybe just a too-aggressive timeout?
[15:33] <bjf> plars, the kernel-security.py issue is something the security team needs to look at. i've seen this showing up on other series and systems. i know there have been changes to that test
[15:34] <bjf> plars, the 3rd one security should look at as well
[15:34] <bjf> jjohansen, sbeattie ^
[15:41] <rtg> bjf, doesn't this look like a test script bug ? http://kernel.ubuntu.com/testing/test-results/kili__3.13.0-8.27__2014-02-08_18-48-00/xfstests/results/xfstests.btrfs/debug/xfstests.btrfs.DEBUG.html
[15:42] <rtg> I've run into the same issue when making BTRFS file systems
[15:42] <bjf> rtg, yes though i thought i'd fixed that particular issue long ago
[15:43] <bjf> rtg, and i don't think i see it all the time which is also odd
[15:43] <rtg> hmm
[15:43] <rtg> I think the failure is BTRFS specific.
[15:43] <rtg> other file systems don't seem to care
[15:44] <rtg> at least, that has been my experience
[15:44] <bjf> rtg, it is. it's when i do the initial btrfs filesystem creation. if there is already a filessytem on the drive the mkfs wants a -f (but only for btrfs)
[15:45] <rtg> bjf, why not do '-f' for all ?
[15:45] <bjf> rtg, or it's that all the other mkfs tools will take a -f but btrfs doesn't
[15:47] <bjf> rtg, it's a flag only mkfs.btrfs recognizes (i just looked)
[15:47] <rtg> bjf, what a PITA
[15:49] <jsalisbury> ##
[15:49] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC in the #ubuntu-meeting channel.
[15:49] <jsalisbury> ##
[15:51] <sbeattie> bjf: where's the omap4 git tree?
[15:51] <bjf> sbeattie, that's in the ti-omap4 branch of the precise repo
[15:53] <jsalisbury> smb, If you have a chance, can you review bug 1278531 ?  I'm not sure if it's related to the other kvm bugs you're already looking it.
[15:53] <ubot2`> Launchpad bug 1278531 in linux (Ubuntu) "nested kvm on saucy kernel hangs" [Medium,Confirmed] https://launchpad.net/bugs/1278531
[15:53] <jsalisbury> s/it/at/
[15:53] <smb> jsalisbury, Yeah, its the bug I asked hallyn to open yesterday
[15:53] <smb> It is sort of on my todo
[15:53] <jsalisbury> smb, cool, thanks
[15:59] <rtg> apw, did you ever get a response from #security about unprivileged overlayfs mounts ?
[16:00] <apw> rtg, yeah they seemed fairly happy it would not be a problem, but reserved the right to nix it later
[16:01] <rtg> apw, shall I just apply it then ?
[16:01] <apw> i think serge started an upstream discussion too, i wonder what happened there
[16:01] <rtg> hallyn, ^^
[16:02] <bjf> rtg, i may have fixed that btrfs test issue. if you see it again let me know
[16:02] <rtg> bjf, ack
[16:06] <smb> apw, Bah, of course ... I was missing another fixup :/  215393bc1fab3d61a5a296838bdffce22f27ffda
[16:06] <hallyn> apw: did you not get eric's reply?
[16:07] <hallyn> he suggests looking through viro's reviews for ideas where overlayfs may be a security risk.  though i'd say again those will be no less valid if only root can mount it
[16:07] <hallyn> but i haven't had a chance to look
[16:09] <apw> hallyn, yeah, that
[16:11] <hallyn> apw: which? :)  have you ever read through viro's review of overlayfs in the past?
[16:11] <apw> some of them indeed, not recently
[16:11] <smb> hallyn, while you are here... is there a server-team meeting today?
[16:12] <smb> Nm, I think they are wondering the same on #ubuntu-server
[16:13] <hallyn> smb: yeah.  i think most of the team is still recovering from capetown
[16:18] <stgraber> ah good, I was just about to start nagging again about userns overlayfs but I see hallyn beat me to it ;)
[16:19] <hallyn> stgraber: d'oh did i not cc: you on that email yesterday?
[16:19] <stgraber> hallyn: I think you did, or Eric did, anyway I got it
[16:20] <stgraber> though it doesn't really give us a clear go ahead or no way (as was expected) so we still need someone to make the call one way or another
[16:20] <hallyn> some of it felt a touch patronizing, but whatever :)
[16:20] <stgraber> and once that's done I can start looking at the implications for LXC
[16:21] <stgraber> I'm starting to think about what to do with arkose as it's horribly broken at the moment. In an ideal world I'd have it be entirely unprivileged but I need overlayfs for that, though I may end up just canning the whole thing for 14.04 and get it out of the archive (got too much to do by release and that one is low prio)
[16:24] <apw> henrix, i assume you have stopped 3.8 stable now ?
[16:24] <henrix> apw: nop, 3.8 is still maintained until Aug by kamal
[16:25] <bjf> ah! so we can blame kamal
[16:25] <henrix> apw: 3.5 will EOL next month
[16:25] <rtg> hallyn, stgraber: I'm gonna apply it for now. lets see what shakes out.
[16:25] <apw> that slacker
[16:25]  * ppisati stares at the number of fixes that we accumulated in S...
[16:25]  * kamal ducks
[16:25] <bjf> apw, so maybe it's just lagging a little
[16:26] <apw> yeah, perhaps indeed
[16:26] <stgraber> rtg: thanks. I'll grab the kernel as soon as it's done building (or just do a local build, depending on when I'm done with something else) and then will look at what needs to happen on the LXC side.
[16:27] <stgraber> hallyn: given the above, I'll postpone beta5 until we have unsupported snapshot and ephemeral upstream, can hopefully happen later today/tomorrow.
[16:27] <hallyn> stgraber: sigh, i guess i'll postponed seccomp again then
[16:28] <hallyn> stgraber: but in any case i need to go track down viro's overlayfs review <cringe>
[16:28] <rtg> apw, am gonna upload this so the lxc folks can mess around. do you have anything else on tap ?
[16:28] <apw> rtg, nope go for it
[16:29] <rtg> apw, ack
[16:29] <stgraber> hallyn: in theory we just need to change the geteuid() checks in the API to only trigger when !overlayfs and !dir. start-ephemeral will be a bit more fun but I'll take care of that one (may end up rebasing on clone() in the process)
[16:30] <apw> kamal, so it sounds like lts-raring might be lagging v3.8 stable ?
[16:30] <kamal> so it looks to me like lts-backport-raring is quite a bit behind my 3.8-stable repo
[16:30] <apw> jinx
[16:30] <kamal> lts-backport-raring is at 3.8.13.14, but I've released up to 3.8.13.17   (and .18 is in -review now)
[16:32] <ppisati> bjf: done
[16:33] <kamal> and my 3.8-stable does contain the fix for CVE-2014-1438
[16:33] <kamal> ... as of 3.8.13.15
[16:34] <hallyn> stgraber: yes that sufficed for my testing that it would work :)  but i want to make sure it's done as cleanly as possible
[16:35] <hallyn> rtg: thanks!
[16:35] <kamal> (correction: that one was fixed in 3.8.13.16)
[16:35] <kamal> similarly, CVE-2013-7263 is fixed in 3.8.13.15
[16:36] <apw> arges, http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[16:36] <kamal> apw, bjf: why is lts-backport-raring so far behind?
[16:38] <bjf> kamal, looking. however, remember that this cycle has dragged on and on
[16:40] <apw> bjf, yeah i don't think anyone is really to blame this cycle the point release and the emergency kernels and the quick saucy respin for the point release, has just thrown a massive spanner in the works
[16:41] <bjf> kamal, it will catch up in the upcoming cycle
[16:44] <arges> smb:  bug 1273386
[16:44] <ubot2`> Launchpad bug 1273386 in neutron "Neutron namespace metadata proxy triggers kernel crash on Ubuntu 12.04/3.2 kernel" [Critical,Triaged] https://launchpad.net/bugs/1273386
[16:52] <rtg> ppisati, can you have a look at the Lucid patch on the kteam list from henrix ? My arm assembler skills are remedial at best.
[16:52]  * apw likes that idea
[16:52] <ppisati> rtg: i'll do
[16:52] <rtg> thanks
[16:53] <henrix> ppisati: sorry :)
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC in the #ubuntu-meeting channel.
[16:56] <jsalisbury> ##
[16:58] <ppisati> henrix: quick question - why are we backporting code for an arch that we don't support anymore for that kernel/release?
[16:59] <ppisati> henrix: in L we had ealy omap code, mvl-dove (and i probably have the only board left around) and imx51, and all of them are EOL now
[16:59] <henrix> ppisati: good question.  i thought we were still supporting it...
[16:59] <ppisati> henrix: in P yes, in L no
[16:59] <ppisati> IIRC
[16:59] <ppisati> bjf: ^?
[17:00] <ppisati> at least, i don't rebase anymore omap/dove for that release
[17:00] <rtg> oh, does that mean I can NAK it ?
[17:00] <apw> henrix, should it come out that we are not doing it you ought to be able to move that ignored (arch not present) and the triager ought to leave it alone (ought to)
[17:01] <henrix> ppisati: i can see we still build armel on the ppa
[17:01] <bjf> ppisati, i know we support it for P (because someone gets nasty when i mention it) but i agree that we are out of support for it in L
[17:01] <apw> henrix, does that build linux-image, or does it only build linux-libc-dev
[17:02] <henrix> apw: linux-image
[17:02] <henrix> apw: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/5417031
[17:02] <henrix> (just an example)
[17:02] <apw> oh that is only versatile ... ugg
[17:03] <apw> that is the board simulator ... noone is running that in production
[17:03] <apw> and if they are ... please no
[17:04] <rtg> apw, henrix: so I think its safe to _not_ apply that patch, right ? especially given sforshee's analysis.
[17:05] <henrix> rtg: well, if we *really* don't support armel anymore, then yeah, its safe.  anyone knows where can we confirm this?
[17:06] <rtg> henrix, all of the arm flavours were only supported for 18 months
[17:06] <rtg> from Lucid I mean
[17:07] <henrix> ack
[17:11] <hallyn> apw: do you happen to know if http://lkml.org/lkml/2013/3/12/385  (v16) was the latest overlayfs requeset for inclusion?  :)
[17:15] <henrix> apw: i'm pushing cvetracker with the 'ignored' on lucid
[17:18] <hallyn> stgraber: http://lkml.org/lkml/2013/3/13/524   (top paragraph :
[17:37] <apw> henrix, ack, i'll watch it to see if it does anything to it
[17:37] <henrix> apw: it did, the cve is now gone :)
[17:44] <apw> henrix, that means it did't switch it back at least :)
[17:45] <henrix> heh, true
[17:47] <hallyn> apw: of course the btrfs subvolume snapshot ioctl would seem as innocuous as an overlayfs mount :)  but i'll hold off on pursuing that :)
[17:53] <apw> hallyn, no comment :)
[19:33] <hallyn> stgraber: ok so it's not as ideal as i'd thought - the unpriv user canont delete existing entries
[19:34] <hallyn> presumably because he can't created trusted.8 xattrs?
[19:35] <hallyn> yeah  Feb 11 20:34:15 ubuntu kernel: [ 6002.515500] overlayfs: ERROR - failed to whiteout 'boot.log'
[19:42] <apw> cannot create things in the upper layer, why so ?  you can put xattrs on your own files can't you ?
[19:42] <apw> and they would always be in the upper layer?
[19:49] <stgraber> hallyn: that could be a problem :)
[19:51] <cristian_c> Hello, I've submitted a bug report (regarding a kernel bug) on launchpad almost two years ago
[19:51] <cristian_c> recently, the bug status has been set to Triaged and I was told to read this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel. I've read it but I've got some doubts yet. A dev has told me to contact the kernel team for preparing a faultless upstream report
[19:52] <cristian_c> the first question: 1) Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
[19:54] <cristian_c> I've tested the 3.14-rc1 kernel too, what have I to do?
[19:54] <cristian_c> second question: 2) While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
[19:55] <jsalisbury> cristian_c, did the 3.14-rc1 kernel also exhibit the bug?
[19:56] <hallyn> stgraber: yeah, now Viro does want to get rid of the xattr-based whiteouts;  i'm not sure whether that will happen and whether it would be cherrypicked into trusty at some point
[19:56] <cristian_c> jsalisbury, the 3.14-rc1 has confirmed the regression, compared to other kernel tried
[19:56] <hallyn> stgraber: if not, then perhaps we should drop this pursuit :(
[19:56] <cristian_c> this is not the original bug anymore
[19:57] <jsalisbury> cristian_c, Ok, just to confirm this is bug 972604 ?  If so, I'll review the bug and post an update.
[19:57] <ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged] https://launchpad.net/bugs/972604
[19:57] <jsalisbury> cristian_c, it may want to open an upstream report.
[19:58] <cristian_c> jsalisbury, in the report is suggested that (opening an upstream report)
[19:59] <jsalisbury> cristian_c, I think that is a good next step, since you tested the mainline kernel.
[20:03] <sbeattie> bjf: in whatever script you're using to import QRT, can you record what commit revision you've grabbed, and emit it as part of the QRT run?
[20:03] <cristian_c> jsalisbury, ok, and regarding the second question?
[20:04] <bjf> sbeattie, yes. if you look in the tar file there is a scripts/bzr.log.  and yes, i'm aware that i screwed the pooch again on updating the tests.
[20:04] <bjf> sbeattie, i'll rework my scripts so that doesn't happen again
[20:04] <sbeattie> bjf: okay, thanks.
[20:05] <bjf> sbeattie, very sorry
[20:06] <cristian_c> jsalisbury, exactly, what have I to do, regarding the second question?
[20:32] <cristian_c> ok I've seen
[20:33] <cristian_c> tags:	 added: needs-bisect
[20:57] <stgraber> hallyn: so speaking of overlayfs using xattr to store file removals, why can't the user do that? are they using one of the restricted attr categories?
[20:58] <hallyn> stgraber: from fs/xattr.c:           * The trusted.* namespace can only be accessed by privileged users.
[20:59] <hallyn> stgraber: so we would need to make that targeted (inode_capable(ionde, CAP_SYS_ADMIN)) to allow it
[20:59] <hallyn> now i think that should be ok...
[20:59] <zequence> apw: I'm fairly sure my problem with linux-lowlatency on trusty is a particular wifi driver. It's a d-link usb device (going to check which one). Without it, the kernel boots fine. As soon as I plug it in, the kernel freezes and I have to use the reset button to restart the computer.
[21:00] <JokesOnYou77> Hi all.  I'm interested in looking at the ubuntu kernel and I was wondering if anyone here has a recommendation for the most readable kernel version (ubuntu or pure linux), best comments best flow organization, to start getting familiar with the kernel?
[21:00] <zequence> apw: -generic is not having the same problem
[21:00] <stgraber> hallyn: that or use the user.* namespace which doesn't come with the CAP_SYS_ADMIN restriction. Though yours would be cleaner (if there's no downside to it)
[21:01] <zequence> apw: The driver is rt73usb. Going to do a bug report
[21:01] <hallyn> stgraber: i think we need the cap_sys_admin restriction (targeted at least) for sanity
[21:01] <hallyn> i'm not sure.  hm.
[21:01] <stgraber> hallyn: well, if you're not allowed to write to the file you won't be able to set the attr, if you are allowed to write to it, then you can remove it and so probably should be allowed to write to the attr
[21:01] <stgraber> or am I missing something?
[21:02] <hallyn> stgraber: yes, teh point of a trusted attr is that the user cant' write it even if he owns the file
[21:02] <zequence> JokesOnYou77: You mean, getting familiar with the code?
[21:03] <stgraber> hallyn: right, so the problem with using user.* is that a user could manually change the attr to un-remove the file, possibly exposing data that was otherwise hidden to them by the overlay?
[21:04] <JokesOnYou77> zequence, the code and the kernel itself.  I have no prior experience in kernel development so I thought I'd look at an early, simpler, version to try and get a feel for it.
[21:04] <hallyn> stgraber: yeah i'm not sure.
[21:04] <hallyn> I'm hoping apw has thought all this through :)
[21:06] <zequence> JokesOnYou77: I don't code the kernel myself, but I would probably start with one aspect of it. Like, making your own kernel modules, or something like that.
[21:07] <zequence> JokesOnYou77: Or, learning how to debug it, using the tools it has. And maybe learning how they are coded
[21:08] <JokesOnYou77> zequence, ok.  I'm looking at http://kernelnewbies.org/ now, I'll take a look at your suggestions.  Thanks
[21:11] <zequence> JokesOnYou77: Nice. I might have a look at that too :)
[23:41] <miseria> "la esclavitud la reemplazo un pobre salario minimo, el jornalero es victima de explotacion y tirania de la oligarquia" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*