| === 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 | ||
| ppisati | moin | 07:39 |
|---|---|---|
| apw | ppisati, moin | 09:30 |
| * apw whines about the rain ... again | 09:30 | |
| 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:44 |
| 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:46 |
| smb | apw, You probably need bilge pumps | 09:48 |
| apw | smb, sluice gates, probabally our own barrier | 09:51 |
| smb | apw, At least you are uphill in the downs. Most of the water goes downhill from there. :) | 09:52 |
| 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:53 |
| smb | apw, I see 5 and 12... | 09:54 |
| ikepanhc | good news is most of them are for apm hardware only | 09:54 |
| 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:55 |
| apw | ikepanhc, and any idea how many further patches those three batches are? | 09:56 |
| ikepanhc | apw: I can give you the exact number in few hours | 09:57 |
| apw | ikepanhc, no rush | 09:59 |
| 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:05 |
| 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 | 11:22 |
| === gerald is now known as Guest88206 | ||
| ikepanhc | apw: sure, no problem | 12:52 |
| brendand | cking, can you have a look at this fwts error message: http://paste.ubuntu.com/6994264/ | 13:04 |
| === edamato is now known as edu-afk | ||
| === Guest26924 is now known as fmasi | ||
| === caribou_ is now known as caribou | ||
| jsalisbury | ** | 16:27 |
| jsalisbury | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 16:27 |
| jsalisbury | ** | 16:27 |
| ppisati | what's the dpkg-buildpackage switch to pass down some opts to fdr? | 16:35 |
| jsalisbury | ## | 16:55 |
| jsalisbury | ## Kernel team meeting in 5 minutes - #ubuntu-meeting | 16:55 |
| jsalisbury | ## | 16:55 |
| 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? | 16:59 |
| 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:01 |
| 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:02 |
| stgraber | hallyn: do you have some references to those e-mails from Tejun? | 17:03 |
| hallyn | uh, gimme a few mins | 17:03 |
| apw | you have a small window (if you can convince me) to get it in the next upload, which was 10s away | 17:05 |
| hallyn | probably related to http://lkml.org/lkml/2013/4/8/912 | 17:06 |
| hallyn | stgraber: it was discussed several times at the plumbers sessions | 17:07 |
| 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:08 |
| 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:09 |
| 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:11 |
| 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 |
| === 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! | ||
| stgraber | ogra: if they did, they'd hit the exact same problem with pulseaudio | 17:12 |
| ogra | ah | 17:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| * 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| hallyn | I'll re-send the patch cc:ing linux-fsdevel@vger.kernel.org | 17:28 |
| 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:34 |
| 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:36 |
| hallyn | stgraber: the good news is if there is such a person we're about to hear from him or her | 17:37 |
| 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:44 |
| 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:45 |
| 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:47 |
| 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:48 |
| apw | so then i could look at all of my trusted. attrs i assume hmmm | 17:49 |
| 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:50 |
| apw | i suspect that is the right approach for its trusted bits, and not for everythign else, ugg | 17:51 |
| 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:07 |
| hallyn | ok | 18:08 |
| 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:20 |
| apw | jsalisbury, i say just go for it | 18:37 |
| jsalisbury | apw, ack | 18:40 |
| apw | ogasawara, ok ... fire in the hole | 19:04 |
| ogasawara | apw: ack, thanks. I'll keep an eye on it if you want to bail. | 19:05 |
| sforshee | jsalisbury: I kicked off a build before I left for lunch, looks like it's done now | 19:06 |
| jsalisbury | sforshee, ahh ok. I built one as well and posted a link to it in the bug. | 19:07 |
| sforshee | jsalisbury: in that case we'll use yours ;-) | 19:09 |
| 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:18 |
| rsalveti | apw: great, thanks | 19:19 |
| apw | i'll get the others done in a bit | 19:19 |
| === zz_mwhudson is now known as mwhudson | ||
| apw | rsalveti, ok flo uploading shortly as well, let me know how those go | 19:33 |
| rsalveti | will do, thanks | 19:35 |
| 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:05 |
| 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:06 |
| cetex | cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver still returns acpi-cpufreq | 21:08 |
| 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:06 |
| cetex | ah, right. | 23:08 |
| cetex | reboot. :) | 23:09 |
| cetex | nope, didn't do it. | 23:13 |
| Sarvatt | do you still have intel_pstate=enable after the acpi_osi? | 23:14 |
| 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:15 |
| cetex | though, i had it on the GRUB_CMDLINE_LINUX | 23:17 |
| cetex | entering exactly what you have.. | 23:17 |
| cetex | nope, no difference. | 23:20 |
| cetex | are you running the same kernel? | 23:20 |
| cetex | then comes the question. does pstate support the new haswell cpu's? | 23:21 |
| cetex | especially the i5-4300u | 23:21 |
| cetex | i'd believe it does, but since i can't seem to get it working.. | 23:24 |
| cetex | hm. maybe not. | 23:29 |
| 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:53 |
| cetex | right. | 23:55 |
| cetex | and as it seems, the latest for saucy is 3.12rc7 | 23:57 |
| cetex | should i go for a trusty kernel instead? | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!