[07:39] <ppisati> moin
[09:30] <apw> ppisati, moin
[09:30]  * apw whines about the rain ... again
[09:44] <smb> apw, Could send you a sunshine picture from outside my window. :-P
[09:44] <smb> But don't worry, we are supposed to get rain again as well... soonish
[09:46] <apw> smb, sounds better than the lashing rain we have ... again
[09:46] <apw> i am going to hav to upgrade the gutters for monsoons
[09:48] <smb> apw, You probably need bilge pumps
[09:51] <apw> smb, sluice gates, probabally our own barrier
[09:52] <smb> apw, At least you are uphill in the downs. Most of the water goes downhill from there. :)
[09:53] <apw> ikepanhc, those two blocks of apm code, are they everything one needs to make those boards work on 3.13 ?
[09:53] <ikepanhc> apw: I am afraid not. there are more coming for ethernet pcie kvm and rtc
[09:54] <smb> apw, I see 5 and 12...
[09:54] <ikepanhc> good news is most of them are for apm hardware only
[09:55] <apw> smb, yeah two blocks, not two patches
[09:55] <smb> apw, Ah right. /me should read
[09:55] <apw> i could be clearer, but what is the fun in that
[09:56] <apw> ikepanhc, and any idea how many further patches those three batches are?
[09:57] <ikepanhc> apw: I can give you the exact number in few hours
[09:59] <apw> ikepanhc, no rush
[11:05] <apw> smb, cking, ppisati, i have a request to spin a kernel sooner rather than later (to build in some boot essential bits); anything on deck i shoudl be waiting on?
[11:05] <smb> apw, not from my side right now
[11:05] <cking> same here
[11:22] <apw> ikepanhc, as and when you have a complete "stack" of all of those 5 sets i'd love a branch to look at, doenst have to be ready to submit to us, just so i can start looking at how frigtening it is
[12:52] <ikepanhc> apw: sure, no problem
[13:04] <brendand> cking, can you have a look at this fwts error message: http://paste.ubuntu.com/6994264/
[16:27] <jsalisbury> **
[16:27] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:27] <jsalisbury> **
[16:35] <ppisati> what's the dpkg-buildpackage switch to pass down some opts to fdr?
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes - #ubuntu-meeting
[16:55] <jsalisbury> ##
[16:59] <hallyn> rtg: ogasawara: hi, stgraber and I were wondering, is it possible to turn off CONFIG_RT_GROUP_SCHED for all trusty kernels?  is there anyone who is using it  /depending on it?
[17:01] <apw> hallyn, well it was on in saucy, so its a longterm on... so we'd need a good reason
[17:01] <stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284731
[17:01] <ubot2> Launchpad bug 1284731 in linux (Ubuntu) "Please turn off CONFIG_RT_GROUP_SCHED in all our kernels" [Undecided,New]
[17:01] <stgraber> apw: the reason was that we never actually used those cgroups before trusty so never had the problem before then :)
[17:02] <stgraber> now that we do, rtkit just fails for everyone
[17:02] <apw> stgraber, so we never used it in S even though it was on
[17:02] <apw> do you have the link to the upstream discussion which says they are bad for security?
[17:03] <stgraber> hallyn: do you have some references to those e-mails from Tejun?
[17:03] <hallyn> uh, gimme a few mins
[17:05] <apw> you have a small window (if you can convince me) to get it in the next upload, which was 10s away
[17:06] <hallyn> probably related to http://lkml.org/lkml/2013/4/8/912
[17:07] <hallyn> stgraber: it was discussed several times at the plumbers sessions
[17:08] <hallyn> it was a way in which a task in cgroup /a/b/c which had delegated write access to it scgroup could affect cgroups which were not just its decendents
[17:09] <apw> as we didn't get to plumbers we don't have that background
[17:09] <hallyn> smb may have been there?  hm
[17:09] <stgraber> which happens to be the case since we delegate write acccess to the user for /user/<uid>.user/cX.session/
[17:09] <ogra> apw, we definitely need it off on all phone kernels since pulse is critical there and needs RT functionality (which this option breaks)
[17:11] <stgraber> apw: so yeah, the main point is that rt_* is fundamentaly broken at the moment. For any other key, if you mkdir a sub-cgroup, you'll get the same value as your parent and can then choose to set a lower value if you want to restrict your tasks. That all works for everything, except for rt_*
[17:11] <ogra> the good news is that it is fixed for systemd :P 
[17:12] <ogra> so we just need to do the switch before release and can keep it on 
[17:12] <stgraber> apw: rt_* requires you to manually set that value, however apparently the hierarchy doesn't quite work with it, so if you have a/b and a/c and set a value for a/ nothing seems to prevent a/b + a/c to be <= a
[17:12] <stgraber> ogra: no, that's wrong
[17:12] <ogra> stgraber, i thought lennart fixed it ? 
[17:12] <ogra> thats what the fedora bugs suggest
[17:12] <stgraber> ogra: systemd doesn't fix this at all, Fedora has the exact same bug it's just that they don't set a cpu cgroup by default in their user sessions
[17:12] <stgraber> ogra: if they did, they'd hit the exact same problem with pulseaudio
[17:12] <ogra> ah
[17:13] <apw> ogra, which touch kernels need this
[17:13] <hallyn> http://lwn.net/Articles/576049/
[17:13] <stgraber> ogra: what Lennart did in systemd is prevent rtkit itself from being broken because of that cgroup stuff but he didn't do anything to prevent pulseaudio from being broken
[17:13] <hallyn> so it's only "starving your siblings"
[17:13] <ogra> apw, all of them ... flo, mako, manta, grouper, hammerhead and maguro (not sure how long we will still use the latter though)
[17:14] <ogra> stgraber, aha ... 
[17:14] <stgraber> apw: touch needs it urgently but the exact same applies to desktop. My laptop is reporting rtkit failures whenever I start pulseaudio an pulseaudio sure doesn't get rt prio
[17:14] <ogra> yeah
[17:14] <apw> stgraber, and did we ever decide that letting pulse should have it
[17:14] <hallyn> stgraber: so why not have logind not create cpu cgroups?
[17:15] <apw> hammerhead never heard of it
[17:15] <ogra> apw, i think thats only in a PPA yet ... nexus5
[17:15] <ogra> rsalveti, ^^^^
[17:15] <stgraber> hallyn: because I kind of like unprivileged lxc to work and be able to set cpu cgroup restrictions
[17:15] <apw> ok that is nothing at all to do with moi then, as we don't even have a branch for it
[17:15] <hallyn> cpu or cpuset?
[17:16] <ogra> apw, i guess you will get one soon :)
[17:16] <hallyn> stgraber: cpu tracks, but i dont' think it restricts anything
[17:16] <stgraber> hallyn: both. Cpu gives you cpu.shares, cpuset gives you cpuset.cpus
[17:16] <rsalveti> ogra: yup, I got the tree, but only in a ppa for now
[17:16] <apw> ogra, till i do :)
[17:16] <ogra> apw, but yeah, not urgent now
[17:16] <apw> rsalveti, ok ... if i spin kernels for these madmen :)  all to the PPA ?
[17:16] <apw> "the PPA" == "the CKT PPA" 
[17:16] <hallyn> stgraber: i was thinking cpu.shares was only tracking.  i *really* don't see why these are combined in one cgroup
[17:16] <rsalveti> apw: yeah, please
[17:17] <stgraber> hallyn: cpu.shares sure is writable, that's the only way you can restrict cputime AFAIK
[17:17] <rsalveti> ogra: so you were right in the end
[17:17] <ogra> rsalveti, indeed ... i am most of the time, i just cant prove it until someone else does :)
[17:18]  * ogra trusts his guts :)
[17:18] <rsalveti> hahah :-)
[17:18] <apw> hallyn, none of those links make much sense, in that they don't indicate the security issue to my mind
[17:18] <hallyn> apw: so if you have a cgroup /user/1000.user/c2.session, and you can write to cpu.rt-runtime_us, you can starve /user/1000.user/c3.session...
[17:18] <ogra> but i know more about cgroups than i ever wanted to know since today :)
[17:18] <hallyn> apw: mind you, cgmanager doesn't give you that write access, so it's moot there.
[17:19] <stgraber> hallyn: except we're not using cgmanager yet
[17:19] <apw> i thought we have a majorly clever cgroup manager with the lennart API and the world was going to be purfect
[17:19] <hallyn> stgraber: lol.  "I am" :)  sorry, i forgot
[17:19] <stgraber> apw: ha ha ha ;)
[17:20] <hallyn> stgraber: so is logind not using cgmanager when it is available?  then logind is also doign the right thing
[17:20] <hallyn> bc /sys/fs/cgroup/cpu/user/1000.user/c2.session/cpu.* is not owned by me
[17:20] <stgraber> hallyn: it's not yet, I haven't finished that work and until cgmanager is in main, I can't possibly land that work
[17:21] <hallyn> so anyway, I can't make either decision, but I do think the best option is to shut off that blasted RT CGROUP option, and the second best option is to have upstart put pulseaudio into /console cpu cgroup
[17:21] <stgraber> hallyn: I'm just not sure how you'd want upstart to move something to /console, upstart isn't privileged and is already inside the user's cgroup, it can't possibly do that
[17:22] <apw> ok i'll change this, and set fire to your hair if it mattered and you fibbed to me
[17:22] <hallyn> free haircut
[17:23] <hallyn> apw: is the overlayfs xattr bit going to be landing in trusty btw?
[17:23] <apw> hallyn, wasn't it in -12 ?
[17:23] <hallyn> stgraber: well we need some sort of solution - even if it is just having a separate cgroup subsytem for rt
[17:23] <stgraber> apw: I need a haircut anyway ;) Anyway, I'd be very interested to know of anyone who actually depends on the current behaviour, because that sounds like depending on a bug to me... and a quick grep through all the usual suspects didn't get me any result for those cgroup keys, so I'm pretty sure nobody cares.
[17:23] <hallyn> apw: hm, i checked a few days ago in master-next and didn't see it.
[17:23] <hallyn> lemme re-fetch
[17:24] <stgraber> hallyn: long term, having rt be sane would be nice, or have it in its own separate controller that we can blacklist and ignore ;)
[17:24] <hallyn> stgraber: ^ tbh i fjeer there is someone out there who does depend on rt for some project they haven't told us about
[17:25] <hallyn> apw: fs/xattr.c doesn't seem to have the change, no
[17:25] <stgraber> hallyn: depend on rt, sure, ubuntustudio comes to mind, but depending on the cgroup bits of rt, I doubt it
[17:25] <stgraber> hallyn: well, besides whoever got those in the kernel in the first place
[17:26] <apw> hallyn, did yu get any further with that upstream
[17:26] <hallyn> apw: no.  I cc:d Miklos on the patch, he never replied
[17:28] <hallyn> I'll re-send the patch cc:ing linux-fsdevel@vger.kernel.org
[17:34] <hallyn> stgraber: but getting back to the rt cgroup splitting up point - everything in kernel is long-term, so if we want that long-term we shoudl probably be talkign to Tejun/ml now
[17:36] <stgraber> hallyn: well, to be honnest, I don't really care about the rt cgroup at all, so long as it doesn't get in my way ;) It'd probably be best for someone who actually uses the thing to argue about doing things right...
[17:37] <hallyn> stgraber: the good news is if there is such a person we're about to hear from him or her
[17:44] <apw> hallyn, so i am trying to understnad why this xattr change in the core isn't applicable to all of them, ie why it is not just ns_capable
[17:45] <apw> hallyn, either way you should be using:  strcmp(name + sizeof(XATTR_TRUSTED_PREFIX) - 1, "lov") == 0) style matching as you know the first bit is trusted. already
[17:47] <apw> hallyn, and can you cc: me on it this time when you send it as well, makes it easier to find
[17:47] <hallyn> apw: well I suspect there are some $bigcorps using trusted.* as secret cookies in filesystems which they shouldn't be able to bypass
[17:47] <hallyn> apw: sorry thought you were on the list
[17:47] <hallyn> on my To list i mean
[17:48] <apw> do you not have to be priviledged to make the user mappings though?
[17:48] <hallyn> (bc i copy/pasted from last email, and why would i not have it in there?)
[17:48] <hallyn> yes, though you can be uid -1 without any privilege...
[17:48] <hallyn> or map uid 0 in namespace to your host uid
[17:49] <apw> so then i could look at all of my trusted. attrs i assume hmmm
[17:50] <apw> i suspect then they are going to make a new bit, like trusted.X. which is ok to use this way
[17:50] <hallyn> apw: there is still something to your earlier idea of having overlayfs override_creds() also change the cred->userns
[17:51] <apw> i suspect that is the right approach for its trusted bits, and not for everythign else, ugg
[18:07] <apw> hallyn, i think i'll leave xattr out of this one as i am rushing it, and try this other approach first thing
[18:07] <apw> hallyn, do you have a nice little recipe for me to test with, could you email it to me
[18:07] <hallyn> apw: ok, thanks
[18:08] <hallyn> ok
[18:20] <jsalisbury> sforshee, you want me to build a test kernel with commit  c297c8b reverted for bug 1282302 ?  Or are you already taking care of it?
[18:20] <ubot2> Launchpad bug 1282302 in linux (Ubuntu) "deadlock when unmounting nfs shares in trusty" [High,Confirmed] https://launchpad.net/bugs/1282302
[18:37] <apw> jsalisbury, i say just go for it
[18:40] <jsalisbury> apw, ack
[19:04] <apw> ogasawara, ok ... fire in the hole
[19:05] <ogasawara> apw: ack, thanks.  I'll keep an eye on it if you want to bail.
[19:06] <sforshee> jsalisbury: I kicked off a build before I left for lunch, looks like it's done now
[19:07] <jsalisbury> sforshee, ahh ok.  I built one as well and posted a link to it in the bug.
[19:09] <sforshee> jsalisbury: in that case we'll use yours ;-)
[19:18] <apw> ogasawara, i have every confidence in it building across the board :)
[19:18] <apw> rsalveti, ok i have uploaded linux-mako to the CKT PPA for you, if you could let me know if that stops the fires
[19:19] <rsalveti> apw: great, thanks
[19:19] <apw> i'll get the others done in a bit
[19:33] <apw> rsalveti, ok flo uploading shortly as well, let me know how those go
[19:35] <rsalveti> will do, thanks
[21:05] <cetex> uhm. i have an issue. i'd like to try the intel_pstate driver instead of the acpi-cpufreq one, but when i add the line "intel_pstate=true" to my /etc/default/grub's "GRUB_CMDLINE_LINUX" line, i still end up with acpi-cpufreq as my scaling_driver
[21:06] <cetex> i've run update-grub2, and on /proc/cmdline i see: BOOT_IMAGE=/vmlinuz-3.11.0-17-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro "acpi_osi=!Windows 2012" intel_pstate=enable quiet splash vt.handoff=7
[21:08] <cetex> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver still returns acpi-cpufreq
[23:06] <Sarvatt> cetex: i think your quoting of acpi_osi is making it stop reading the later stuff, try GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=enable acpi_osi=\"!Windows 2012\""
[23:06] <Sarvatt> thats what i'm using right now and it works
[23:08] <cetex> ah, right.
[23:09] <cetex> reboot. :)
[23:13] <cetex> nope, didn't do it.
[23:14] <Sarvatt> do you still have intel_pstate=enable after the acpi_osi?
[23:15] <cetex> BOOT_IMAGE=/vmlinuz-3.11.0-17-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro intel_pstate=enable "acpi_osi=!Windows 2012" quiet splash vt.handoff=7
[23:17] <cetex> though, i had it on the GRUB_CMDLINE_LINUX
[23:17] <cetex> entering exactly what you have..
[23:20] <cetex> nope, no difference.
[23:20] <cetex> are you running the same kernel?
[23:21] <cetex> then comes the question. does pstate support the new haswell cpu's?
[23:21] <cetex> especially the i5-4300u
[23:24] <cetex> i'd believe it does, but since i can't seem to get it working..
[23:29] <cetex> hm. maybe not.
[23:53] <Sarvatt> cetex: oh thats probably the problem, it does work on 3.11 for me but i'm on ivybridge, haswell was added in 3.12
[23:55] <cetex> right.
[23:57] <cetex> and as it seems, the latest for saucy is 3.12rc7
[23:57] <cetex> should i go for a trusty kernel instead?