[06:11] <eruditehermit> hey
[06:11] <eruditehermit> is there a ubuntu kernel guy around?
[07:16] <ppisati> morning
[07:18] <eruditehermit> morning
[08:13] <smb> morning
[09:00] <test___> abogani: ping
[12:40] <fairuz> Hi
[12:40] <fairuz> kernel modules are preemptable?
[12:41] <fairuz> i mean is it possible to have half of function done by cpu0 and the other half by cpu1?
[13:02] <apw> fairuz, only if there is a lock in the path, otherwise no
[13:02] <fairuz> apw: ok thanks
[13:03] <fairuz> hm wait, should the lock make sure only cpu do the job?
[13:04] <apw> unless you specifically turn on PREEMPT which noone does, then a kernel therad only gives up the CPU when it is reday
[13:04] <apw> ie, when it sleeps or calles cpu_relax or simila
[13:05] <fairuz> apw: ok understood now
[13:30] <fairuz> Hi, is there any equivalent of sched_setaffinity in kernel space?
[13:31] <fairuz> or it doesn't make sense at all
[13:38] <apw> fairuz, i believe there is indeed such a thing no idea what its called, as process contexts are process contexts
[13:47] <fairuz> I don't if this an appropriate question but I try nevertheless. On SMP processors, if we write to a coprocessor register of a CPU, the value will not disappear as long as the CPU is online right?
[14:00] <tjaalton> when will the -9 ABI kernel get pushed to natty-updates?
[14:03] <smb> tjaalton, There seem to be two patches that might have been reverted (though I think in the end at least the ath9k may stay) and sconklin was looking into that. So I would expect it to be soon (about next week maybe)
[14:03] <smb> Or wait
[14:03] <apw> tjaalton, i think we've moved to 3 week cycle now so 3 weeks after it first appeared
[14:04] <smb> reverting would mean first week is over so it might be before the verification week...
[14:04] <tjaalton> smb: ok thanks, I think it should fix the radeon regression that Luca reported here earlier this week
[14:04] <tjaalton> I'll ask him to confirm
[14:05] <smb> Yeah. I am not so sure anymore. :-P
[14:18] <smoser> is it expected that 2.6.32-32.62  will flow soon from -proposed to -updates ?
[14:19] <smb> smoser, That would be expected sooner. And probably I get through with the latest ec2 kernel change into the same as that contains the tsc fix
[14:19] <smoser> smb, ?
[14:20] <smoser> there is a -proposed kernel thats been there for 3 weeks (also a -ec2 varient)
[14:20] <smoser> i would not expect that new changes would get in at this point.
[14:20] <smoser> or maybe i just dont understnad the kernel sru process.
[14:20] <smoser> i'd surely be happy if your tsc fix would get in soon.
[14:21] <smb> Only because it is very simple, Steve was in a good mood and I did some regression testing. It should not be the normal flow
[14:22] <smb> I will have to take any beating too if anything goes wrong. :-P
[14:26] <smoser> smb, so what would be time frame for getting into -updates then?
[14:28] <smb> smoser, That sounded like being just about to (probably this week). But I cannot promise that the updated ec2 kernel goes through. I have to talk with Steve first.
[14:30] <jjohansen> sconklin: for what its worth, I am with smb on the new ec2 kernel sooner is better, and I kicked off an instance for testing too
[14:30] <smb> jjohansen, You found the kernels on tangerine?
[14:31] <jjohansen> smb: uh no didn't look, I built one
[14:32] <smb> jjohansen, Works the same. Just I could have saved you that effort. :)
[14:33] <jjohansen> smb: but where is the fun in that? :)
[14:33] <smb> I got a finalized git tree locally and the source package ready to upload. But I wanted sconklin s ok first
[14:34]  * jjohansen has to run to an appointment, back in a bit
[14:45]  * ogasawara back in 20
[14:48] <sconklin> smb: just arrived - sure, go ahead and upload. I didn't realizer that the patch was only on the ec2 branch, so it won't even affect the certification that's already taken place, and we should get these kernels out this week. I'm going to respin Natty with one revert today.
[14:54] <smb> sconklin, Ok, so I push out the git tree (finalizing) and upload to our ppa
[14:57] <sconklin> smb: good deal
[15:02] <smoser> smb, great.  I will push to get refreshed images out as soon as kernel enters -updates.
[15:03] <smb> smoser, Sure, cool. Shall I ping you when it happens or do you track that
[15:08] <smoser> smb, i really wish i had something that tracked that.
[15:09] <smoser> the ultimate scenario would be for something to be notified (or poll) for new kernel in -updates, build an image, automated test it... then send me an email with the changes so i could just sign and forward it on.
[15:09] <smoser> did you want to write that for me ?
[15:10] <smb> smoser, Apart from probably needing some "how do I build those images" tuition, the tracking part maybe can be padded together from rmadison and some shell glue
[15:11] <smoser> yeah, there isn't anything technicall difficult, just tying together lots of bits.  i have a start at a program that gets the changes between two images.
[15:11] <smb> smoser, I try to come up with something that can be run from a cronjob and maybe we can try the rest in Dublin
[15:11] <smoser> but it doesn't realize kernel changes because of the package name change.
[15:15] <bjf> moin y'all
[15:15] <ogasawara> bjf: welcome back!  hope you've recovered.
[15:15] <smb> welome o bjf. How is life?
[15:15] <JFo> moin bjf 
[15:15] <bjf> i'm much better, though dealing with a bit of a head cold i brought back from uds
[15:16] <bjf> the other issue seems to be completely resolved
[15:16] <JFo> glad to hear it
[15:16] <smb> good news
[15:19] <JFo> oh btw bjf, the regression-potential report doesn't seem to be updating. is there something I need to do to it?
[15:19] <bjf> JFo, i'll look into it
[15:20] <JFo> thank you sir, not critical, just wanted to mention. :-)
[15:27] <bjf> JFo, http://people.canonical.com/~kernel/reports/regressions-potential-report.html looks right to me, or are you referring to another report ?
[15:28] <JFo> bjf, yep, that is the one, but the numbers are wrong. I removed the tag from the first few before UDS and the number is still the same.
[15:28] <JFo> and those bugs are still showing
[15:31] <bjf> hmmm, will force an update
[15:31] <JFo> ok
[15:32] <JFo> like I said, not critical, the LP search will work for me too if you have other fish to fry
[15:32] <JFo> just wanted to mention it in case it was supposed to be updating regularly
[15:33] <bjf> JFo, it is, there is probably a bug in there somewhere
[15:33] <JFo> cool :)
[16:13] <herton> bjf: what you do about embargoed CVEs? I mean, how to identify it etc., so not end up putting accidentaly before time a backport/patch at ubuntu-kernel open mailing list
[16:13] <bjf> herton, so, for embargoed CVEs, you will get plenty of warning that a CVE is embargoed and we can discuss that then, but really you don't do anything different except maybe not send the patch email to the mailing list
[16:14] <bjf> herton, the two that i pointed you at, CVE-2011-1593 and CVE-2011-1169, neither are embargoed
[16:14] <ubot2> bjf: Multiple integer overflows in the next_pidmap function in kernel/pid.c in the Linux kernel before 2.6.38.4 allow local users to cause a denial of service (system crash) via a crafted (1) getdents or (2) readdir system call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1593)
[16:14] <ubot2> bjf: Array index error in the asihpi_hpi_ioctl function in sound/pci/asihpi/hpioctl.c in the AudioScience HPI driver in the Linux kernel before 2.6.38.1 might allow local users to cause a denial of service (memory corruption) or possibly gain privileges via a crafted adapter index value that triggers access to an invalid kernel pointer. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1169)
[16:14] <herton> ok
[16:15] <bjf> herton, note that you do not need to do dapper
[16:15] <herton> yep, steve told me too, seems dapper has his own magic that everyone hates :)
[16:16] <herton> and it's going EOL
[16:16] <bjf> herton, really it's because it's going EOL and we've identified the CVEs that were required, hopefully, we've done the last dapper kernel
[16:19] <herton> bjf: I requested access to the CVE spreadsheet, not sure who approves that
[16:20] <bjf> herton, looking
[16:21] <bjf> herton, should be open to all "canonical" people
[16:22] <bjf> sconklin, ^ this ring any bells with you ?
[16:22] <kapare> Hi there! I have weird dmesg that keep poping ups since upgrade to 11.04:::::::
[16:22] <kapare> type=1400 audit(1305730611.637:128211): apparmor="DENIED" operation="exec" parent=5778 profile="/usr/sbin/libvirtd" name="/usr/local/bin/qemu-system-x86_64" pid=5903 comm="libvirtd" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
[16:22] <herton> bjf: hmm strange, here I got that I must be approved, may be because my openid/primary email is herton@gmail.com
[16:22] <sconklin> herton: I'll look but make sure that you were logged into google with your canonical address not a personal one
[16:23] <jdstrand> kapare: you need to add /usr/local/bin/qemu-system-x86_64 /etc/apparmor.d/abstractions/libvirt-qemu
[16:23] <jjohansen> kapare: that means the libvirtd profile is prevent the access
[16:23] <jjohansen> kapare: the best way to deal with that is ubuntu-bug apparmor
[16:23] <jdstrand> kapare: you probably did it before the upgrade, got prompted during the upgrade for the conffile change, and accepted the defaults
[16:24] <herton> sconklin: yeah, I think it's because I'm logged also on gmail, hang on
[16:24] <jdstrand> jjohansen: I doubt I would fix that bug tbh
[16:24] <tgardner> herton, I've found the same issue. I generally have to do a complete flush first.
[16:24] <bjf> sconklin, nice catch, i miss the obvious 
[16:24] <jdstrand> jjohansen: /usr/local path for qemu. I mean *maybe*, but that is a local change
[16:25] <jjohansen> jdstrand: right, but in general denied messages should be filed as a bug
[16:25] <sconklin> That CVE spreadsheet will die soon when new processes are in place.
[16:26] <jjohansen> jdstrand: yep
[16:27] <herton> sconklin: worked now, so seems was the gmail logged in
[16:27] <sconklin> ok
[16:27] <kapare> jdstrand, thx what specific access requires these files? I may have click default by mistakes but doesn't remeber that part ;)
[16:27] <jdstrand> jjohansen: sure
[16:28] <jdstrand> kapare: you can model it after what is already in there. eg: '/usr/local/bin/qemu-system-x86_64 rmix,'
[16:28] <herton> my launchpad account is tied to gmail account too, so this adds to the confusioin...
[16:28] <herton> *confusion
[16:29] <kapare> jjohansen: you mean the irc channel or enter a bug un lauchpad? about the ubuntu-bug apparmor
[16:30] <jdstrand> kapare: jjohansen is right that in general you would want to file a bug. in this case, I happen to know there was already a bug filed on this, and you know how to proceed, so I don't think it is required. for next time, 'ubuntu-bug apparmor'
[16:30] <jjohansen> kapare: enter a bug in launchpad, by opening a terminal and typing "ubuntu-bug apparmor", that will collect the denied messages etc and automatically attach them to the bug report
[16:30] <jdstrand> hehe
[16:30] <jdstrand> jjohansen: we really should get on the same page here
[16:30] <jdstrand> jjohansen: there is already a bug on this
[16:30] <jjohansen> kapare: jdstrand, is right, just clarifying the use of ubuntu-bug
[16:31] <jjohansen> jdstrand: yep, sorry just trying to clarify the process, not saying to open a bug
[16:31] <jdstrand> no worries
[16:31]  * jdstrand slowly backs away from #ubuntu-kernel
[16:32] <jdstrand> thing is-- really hit the sweet spot for me-- libvirt *and* apparmor, how could I resist? ;P
[16:32] <herton> bjf, sconklin: ok, for start I'll take CVE-2011-1593
[16:32] <ubot2> herton: Multiple integer overflows in the next_pidmap function in kernel/pid.c in the Linux kernel before 2.6.38.4 allow local users to cause a denial of service (system crash) via a crafted (1) getdents or (2) readdir system call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1593)
[16:33] <sconklin> herton: ok, please feel free to ask about anything
[16:41] <JFo> food... bbiab
[16:44] <kapare> jdstrand,  /usr/local/bin/qemu-system-x86_64 is already there I searching on lauchpad but did found yet the bug associated to it ...
[16:46] <kapare> jjohansen, didn't know about the terminal part will try this right away
[16:47] <jjohansen> kapare: please don't, or at least try it and abandon it half way through before the bug actually gets created
[16:47] <jdstrand> kapare: the bug is 510213
[16:47] <jjohansen> kapare: as jdstrand said he actually already has a bug on this particular one, so it won't help
[16:48] <jjohansen> kapare: but in general please do as its the best way for us to track, and the best way to get a response about your problem
[16:48] <jdstrand> kapare: I forgot you also have to add the path to /etc/apparmor.d/usr.sbin.libvirtd
[16:48] <jjohansen> kapare: dropping into the channel is hit or miss as it depends on who is online at the time
[16:49] <kapare> jjohansen, ;) will abandon it but nice report it generates
[16:49] <jjohansen> kapare: yep, its real useful
[16:49] <jdstrand> kapare: see the bug I mentioned for details
[16:50] <kapare> jdstrand, I'm reading it right now
[16:51] <jdstrand> kapare: incidentally, since this is not a kernel issue, it should probably be moved to #ubuntu-security
[16:51] <jdstrand> (if more discussion is needed)
[16:52] <jjohansen> jdstrand: err you mean #ubuntu-hardened?
[16:52] <jdstrand> jjohansen: one or the other redirects to the other
[16:52] <jdstrand> I forget which
[16:53] <jdstrand> we try to promote #ubuntu-security though in general, since it is easier to find
[16:53] <jjohansen> jdstrand: #ubuntu-security requires an invite it seems
[16:53] <kapare> jjohansen, jdstrand thx will try to add /etc directories and see if message disappear do I need to restart apparmor?
[16:53] <jdstrand> it might if you are already in #ubuntu-hardened
[16:53] <jjohansen> jdstrand: oh, hadn't thought of that
[16:54] <jdstrand> kapare: I think you mean /usr/local/bin/..., but no, you don't need to restart apparmor. just do 'sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.libvirtd'
[16:54] <jjohansen> jdstrand: yep that is what was happening
[16:55] <jdstrand> jjohansen: incidentally, while the parser is technically userspace, since it is actually a plumbing layer/kernel interface type thing for the tools, I moved parser stuff to 'Kernel'parser' rather than 'Userspace' in the bp
[16:55] <jjohansen> jdstrand: makes sense
[16:55] <jdstrand> jjohansen: I think that more accurately conveys what is happening-- ie, kernel changes require parser changes
[16:56] <jdstrand> and vice versa
[16:56] <jjohansen> yep
[16:56] <jdstrand> (well, not always, but you know what I mean)
[16:56] <jjohansen> hehe yeah
[16:56] <jdstrand> so that should make the distinction between the work items and who does what a little more clear hopefully
[17:45] <herton> bjf: https://bugs.launchpad.net/bugs/784727 (nominations need to be set)
[17:45] <ubot2> Launchpad bug 784727 in linux-ti-omap4 "CVE-2011-1593" [Undecided,New]
[17:46] <bjf> herton, working it now
[17:46] <herton> And if a nomination after approved is not applicable, the thing to do is set to invalid right?
[17:47] <bjf> yes, though for karmic, i declined it
[17:48] <bjf> i should have done that for dapper as well, but you can just mark it "invalid
[17:48] <bjf> herton, should be good to go
[17:49] <herton> ok, thanks. Where create-cve-tracker gets the list from releases (karmic, natty, etc.)? Didn't look, but may be we should remove karmic already
[17:52] <jjohansen> running an errand, back in a bit
[17:52] <bjf> herton, it gets that information directly from LaunchPad, so LaunchPad still thinks karmic is supported
[18:51] <Qwc> *knock knock*
[18:53] <Qwc> Hi m8s, does a kernel ppa exist for 10.10 with the latest 2.6.38 or 2.6.39rc ? because i've got a serious problem with my xeon E5420, the kernel shipped with natty panics at boot or on starting kde
[18:54] <jjohansen> Qwc: natty is pretty much the latest 2.6.38 kernel
[18:54] <jjohansen> Qwc: there are mainline build kernels for 2.6.39
[18:55] <tgardner> not to mention the 2.6.39 kernel. see https://launchpad.net/ubuntu/+source/linux
[18:55] <Qwc> hmm, wtf? my apt refuses to install ... *gaa* ... okay checking that again (trice now)
[19:06]  * tgardner --> lunch
[19:14] <Qwc> okay, well got the 2.6.39rc5 now ... bbl, after reboot and some testing ;)
[19:30] <Qwc> just a little question, which is the latest kernel the nvidia proprietary driver plays with ? o.O
[19:31] <jjohansen> Qwc: probably most recent natty kernel, I know .39 breaks the ati fglrx driver and I suspect it is the same for the nvidia proprietary driver as well
[19:32] <Qwc> ah k, i suspect the kernel from the 10.10 repo doesn't understand both of them, huh?
[19:32] <Qwc> -kernel +nvidia
[19:35] <Qwc> hope i'll get not too much dependencies when i download the .deb from natty -.-
[19:36] <Qwc> i could update the complete dist straight away from a running .39 kernel but working nvidia driver is essential. 
[19:38] <Qwc> dammit, my gentoo years are too far ago now... 
[19:41] <Qwc> m8s! please keep your fingers crossed, that the .38 kernel does not panic on my damn machine! ;)
[19:48] <herton> hardy master-next is failing to build, probably is the last applied ldm patch:
[19:48] <herton> /home/herton/kernels/ubuntu-hardy/fs/partitions/ldm.c: In function 'ldm_parse_vmdb':
[19:48] <herton> /home/herton/kernels/ubuntu-hardy/fs/partitions/ldm.c:256: error: 'FALSE' undeclared (first use in this function)
[19:48] <herton> /home/herton/kernels/ubuntu-hardy/fs/partitions/ldm.c:256: error: (Each undeclared identifier is reported only once
[19:48] <herton> /home/herton/kernels/ubuntu-hardy/fs/partitions/ldm.c:256: error: for each function it appears in.)
[20:01]  * jjohansen -> lunch
[20:01] <Kano> hi, why is not rc7 build for 64 bit?
[20:01] <Kano> but daily has 64 bit
[20:38] <bjf> herton looking
[20:46] <bjf> herton, doing a test build, this will take a bit
[20:47] <herton> bjf: no worries, I reverted the two ldm patches here for now to test build my backport
[20:53] <Qwc> well m8s, the kernel paniced ... btw. where can i find the "panic-log", does it exist?
[20:54] <Qwc> dmesg doesnt log that ...
[20:56] <Qwc> well, then i have to wait for 11.10... -.-
[21:02] <bjf> herton, same error here, will investigate and get it fixed up
[21:12] <herton> ok
[22:05] <apw> Kano, probabally cause someone fixed the compiler failure in -rc7
[22:30] <bjf> herton, hardy master-next is fixed
[22:31] <herton> bjf: nice. Other thing now, about FixingCVEs text, should I care about item 9. Update the Security Team's CVE tracking... ?
[22:31] <bjf> herton, lets hold off on that until you have that CVE applied to all the kernel trees
[22:32] <herton> ok
[22:45]  * herton --> eod