=== gerald is now known as Guest77029 === mwhudson is now known as zz_mwhudson === BruceMa is now known as BruceMa-721 === BruceMa-721 is now known as BruceMa === gerald is now known as Guest5704 [07:39] moin [09:30] ppisati, moin [09:30] * apw whines about the rain ... again [09:44] apw, Could send you a sunshine picture from outside my window. :-P [09:44] But don't worry, we are supposed to get rain again as well... soonish [09:46] smb, sounds better than the lashing rain we have ... again [09:46] i am going to hav to upgrade the gutters for monsoons [09:48] apw, You probably need bilge pumps [09:51] smb, sluice gates, probabally our own barrier [09:52] apw, At least you are uphill in the downs. Most of the water goes downhill from there. :) [09:53] ikepanhc, those two blocks of apm code, are they everything one needs to make those boards work on 3.13 ? [09:53] apw: I am afraid not. there are more coming for ethernet pcie kvm and rtc [09:54] apw, I see 5 and 12... [09:54] good news is most of them are for apm hardware only [09:55] smb, yeah two blocks, not two patches [09:55] apw, Ah right. /me should read [09:55] i could be clearer, but what is the fun in that [09:56] ikepanhc, and any idea how many further patches those three batches are? [09:57] apw: I can give you the exact number in few hours [09:59] ikepanhc, no rush [11:05] 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] apw, not from my side right now [11:05] same here [11:22] 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 === gerald is now known as Guest88206 [12:52] apw: sure, no problem [13:04] cking, can you have a look at this fwts error message: http://paste.ubuntu.com/6994264/ === edamato is now known as edu-afk === Guest26924 is now known as fmasi === caribou_ is now known as caribou [16:27] ** [16:27] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [16:27] ** [16:35] what's the dpkg-buildpackage switch to pass down some opts to fdr? [16:55] ## [16:55] ## Kernel team meeting in 5 minutes - #ubuntu-meeting [16:55] ## [16:59] 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] hallyn, well it was on in saucy, so its a longterm on... so we'd need a good reason [17:01] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284731 [17:01] Launchpad bug 1284731 in linux (Ubuntu) "Please turn off CONFIG_RT_GROUP_SCHED in all our kernels" [Undecided,New] [17:01] apw: the reason was that we never actually used those cgroups before trusty so never had the problem before then :) [17:02] now that we do, rtkit just fails for everyone [17:02] stgraber, so we never used it in S even though it was on [17:02] do you have the link to the upstream discussion which says they are bad for security? [17:03] hallyn: do you have some references to those e-mails from Tejun? [17:03] uh, gimme a few mins [17:05] you have a small window (if you can convince me) to get it in the next upload, which was 10s away [17:06] probably related to http://lkml.org/lkml/2013/4/8/912 [17:07] stgraber: it was discussed several times at the plumbers sessions [17:08] 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] as we didn't get to plumbers we don't have that background [17:09] smb may have been there? hm [17:09] which happens to be the case since we delegate write acccess to the user for /user/.user/cX.session/ [17:09] 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] 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] the good news is that it is fixed for systemd :P [17:12] so we just need to do the switch before release and can keep it on [17:12] 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] ogra: no, that's wrong [17:12] stgraber, i thought lennart fixed it ? [17:12] thats what the fedora bugs suggest [17:12] 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 === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 4th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:12] ogra: if they did, they'd hit the exact same problem with pulseaudio [17:12] ah [17:13] ogra, which touch kernels need this [17:13] http://lwn.net/Articles/576049/ [17:13] 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] so it's only "starving your siblings" [17:13] apw, all of them ... flo, mako, manta, grouper, hammerhead and maguro (not sure how long we will still use the latter though) [17:14] stgraber, aha ... [17:14] 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] yeah [17:14] stgraber, and did we ever decide that letting pulse should have it [17:14] stgraber: so why not have logind not create cpu cgroups? [17:15] hammerhead never heard of it [17:15] apw, i think thats only in a PPA yet ... nexus5 [17:15] rsalveti, ^^^^ [17:15] hallyn: because I kind of like unprivileged lxc to work and be able to set cpu cgroup restrictions [17:15] ok that is nothing at all to do with moi then, as we don't even have a branch for it [17:15] cpu or cpuset? [17:16] apw, i guess you will get one soon :) [17:16] stgraber: cpu tracks, but i dont' think it restricts anything [17:16] hallyn: both. Cpu gives you cpu.shares, cpuset gives you cpuset.cpus [17:16] ogra: yup, I got the tree, but only in a ppa for now [17:16] ogra, till i do :) [17:16] apw, but yeah, not urgent now [17:16] rsalveti, ok ... if i spin kernels for these madmen :) all to the PPA ? [17:16] "the PPA" == "the CKT PPA" [17:16] stgraber: i was thinking cpu.shares was only tracking. i *really* don't see why these are combined in one cgroup [17:16] apw: yeah, please [17:17] hallyn: cpu.shares sure is writable, that's the only way you can restrict cputime AFAIK [17:17] ogra: so you were right in the end [17:17] 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] hahah :-) [17:18] hallyn, none of those links make much sense, in that they don't indicate the security issue to my mind [17:18] 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] but i know more about cgroups than i ever wanted to know since today :) [17:18] apw: mind you, cgmanager doesn't give you that write access, so it's moot there. [17:19] hallyn: except we're not using cgmanager yet [17:19] i thought we have a majorly clever cgroup manager with the lennart API and the world was going to be purfect [17:19] stgraber: lol. "I am" :) sorry, i forgot [17:19] apw: ha ha ha ;) [17:20] stgraber: so is logind not using cgmanager when it is available? then logind is also doign the right thing [17:20] bc /sys/fs/cgroup/cpu/user/1000.user/c2.session/cpu.* is not owned by me [17:20] 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] 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] 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] ok i'll change this, and set fire to your hair if it mattered and you fibbed to me [17:22] free haircut [17:23] apw: is the overlayfs xattr bit going to be landing in trusty btw? [17:23] hallyn, wasn't it in -12 ? [17:23] stgraber: well we need some sort of solution - even if it is just having a separate cgroup subsytem for rt [17:23] 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] apw: hm, i checked a few days ago in master-next and didn't see it. [17:23] lemme re-fetch [17:24] 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] 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] apw: fs/xattr.c doesn't seem to have the change, no [17:25] hallyn: depend on rt, sure, ubuntustudio comes to mind, but depending on the cgroup bits of rt, I doubt it [17:25] hallyn: well, besides whoever got those in the kernel in the first place [17:26] hallyn, did yu get any further with that upstream [17:26] apw: no. I cc:d Miklos on the patch, he never replied [17:28] I'll re-send the patch cc:ing linux-fsdevel@vger.kernel.org [17:34] 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] 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] stgraber: the good news is if there is such a person we're about to hear from him or her [17:44] 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] 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] hallyn, and can you cc: me on it this time when you send it as well, makes it easier to find [17:47] 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] apw: sorry thought you were on the list [17:47] on my To list i mean [17:48] do you not have to be priviledged to make the user mappings though? [17:48] (bc i copy/pasted from last email, and why would i not have it in there?) [17:48] yes, though you can be uid -1 without any privilege... [17:48] or map uid 0 in namespace to your host uid [17:49] so then i could look at all of my trusted. attrs i assume hmmm [17:50] i suspect then they are going to make a new bit, like trusted.X. which is ok to use this way [17:50] apw: there is still something to your earlier idea of having overlayfs override_creds() also change the cred->userns [17:51] i suspect that is the right approach for its trusted bits, and not for everythign else, ugg [18:07] 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] hallyn, do you have a nice little recipe for me to test with, could you email it to me [18:07] apw: ok, thanks [18:08] ok [18:20] 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] Launchpad bug 1282302 in linux (Ubuntu) "deadlock when unmounting nfs shares in trusty" [High,Confirmed] https://launchpad.net/bugs/1282302 [18:37] jsalisbury, i say just go for it [18:40] apw, ack [19:04] ogasawara, ok ... fire in the hole [19:05] apw: ack, thanks. I'll keep an eye on it if you want to bail. [19:06] jsalisbury: I kicked off a build before I left for lunch, looks like it's done now [19:07] sforshee, ahh ok. I built one as well and posted a link to it in the bug. [19:09] jsalisbury: in that case we'll use yours ;-) [19:18] ogasawara, i have every confidence in it building across the board :) [19:18] 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] apw: great, thanks [19:19] i'll get the others done in a bit === zz_mwhudson is now known as mwhudson [19:33] rsalveti, ok flo uploading shortly as well, let me know how those go [19:35] will do, thanks [21:05] 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] 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] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver still returns acpi-cpufreq [23:06] 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] thats what i'm using right now and it works [23:08] ah, right. [23:09] reboot. :) [23:13] nope, didn't do it. [23:14] do you still have intel_pstate=enable after the acpi_osi? [23:15] 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] though, i had it on the GRUB_CMDLINE_LINUX [23:17] entering exactly what you have.. [23:20] nope, no difference. [23:20] are you running the same kernel? [23:21] then comes the question. does pstate support the new haswell cpu's? [23:21] especially the i5-4300u [23:24] i'd believe it does, but since i can't seem to get it working.. [23:29] hm. maybe not. [23:53] 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] right. [23:57] and as it seems, the latest for saucy is 3.12rc7 [23:57] should i go for a trusty kernel instead?