[00:25] ogasawara: heads-up on bug 893395 [00:25] Launchpad bug 893395 in linux "ext2 modular in precise but missing from fs-core-modules" [Undecided,New] https://launchpad.net/bugs/893395 [00:25] shame I missed today's upload === BenC__ is now known as BenC === ericm-Zzz is now known as ericm [04:41] cjwatson: pushed a fix for 893395, I'll upload once the current upload finishes building (eta 5hrs). will then get linux-meta uploaded as well. [08:25] morning .+ [08:27] morning [08:58] * apw waves weakly [11:24] smb`: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/kernel/guard-page/split-stack.c [11:25] smb`: do you remember if it relates to a CVE or a particular kernel option? === smb` is now known as smb [11:44] ppisati, it had to do with a cve, but I cannot remember exactly what/which [11:44] smb: found [11:44] smb: https://bugs.launchpad.net/ubuntu/jaunty/+source/linux-mvl-dove/+bug/646114 [11:45] Launchpad bug 646114 in linux "mlock on stack will create guard page gap" [Undecided,Fix released] === tkamppeter_ is now known as tkamppeter [11:45] ppisati, Well, I believe that was a problem introduced by the attempted fix for the other problem [11:47] The guard page thing was supposed to prevent some bad collision but unfortunately the way this was shown to user-space was one-off (or so) [11:48] Hm, actually might have been that if the area was spanning more than one vm area the guard page hole was presented for each area [11:48] which is a lie for anything but the lowest (if your stack grows downwards) [11:50] smb: ok, seems to be 28d2e371327c8961ae593e1a3e275df32b35dd7d maverick/master [11:53] ppisati, That was the fix. It started with 52423b90e1f5b1bdbbcc6e32f4d37ada29b790c4 [11:53] ppisati, CVE-2010-2240 [11:53] smb: The do_anonymous_page function in mm/memory.c in the Linux kernel before 2.6.27.52, 2.6.32.x before 2.6.32.19, 2.6.34.x before 2.6.34.4, and 2.6.35.x before 2.6.35.2 does not properly separate the stack and the heap, which allows context-dependent attackers to execute arbitrary code by writing to the bottom page of a shared memory segment, as demonstrated by a memory-exhaustion attack against the X.Org X server. (http://cve.mitre.org/c [11:55] cool, i'll import it [11:55] btw, does that mean that secuiry test routine were not run on arm branches? [11:56] but first, lunch! :) [11:56] ppisati, We do security on arm? :-P [11:57] Well it should be in there [11:57] well, it seems we just started to do security on arm... :) [11:57] The CVE required a whole bunch of changes but for Maverick those seem to be in from upstream stable [11:58] It turned out that the minimal invasive patch was a maximum pain in the butt [11:58] sounds like something to remember... :) [11:59] * smb does not think that anything minimal invasive exists in memory management... [12:00] smb: well, but you made my facebook status quote :) [12:01] * smb tries to hide [13:50] ppisati, so did someone in qa just bring up that security failure ? [13:51] ppisati, cirtainly in the early days we didn't record derivative branches as well as we do now, and so they had not CVE tracker entries and didn't get updated always; and once missed that was it [13:53] apw, bug 893190 (first reported on tracking bug 888569) [13:53] Launchpad bug 893190 in linux-ti-omap4 "Qa-testing failures for 2.6.35-903.27" [Undecided,New] https://launchpad.net/bugs/893190 [13:53] Launchpad bug 888569 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.35-903.27 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/888569 [13:53] so it must be new testing i suspect then, a good thing if a little late [13:54] herton, but if it is a missing CVE which simply is not applied to that branch, then its not a regression [13:54] indeed, I guess that's it also [13:54] herton, and we'd not necessarily want to hold the update. the previous release is as bad [13:55] apw, I was thinking about it as well, that's true, shouldn't hold if not a regression. If GrueMaster can confirm is not a regression, we could go forward with the update and release it [13:56] ppisati, is this just a cve we have missed on this branch, ie are the fixes simply missing? [13:56] herton, if that is a yes ^^ then its defnatly not a regression [13:56] let me know if so so i can get the security team to pull that entry back from retired for the matrix too [13:58] ok. There is more 1 test failure on the report, not sure if they are all missing cves, but if not a regression on all then ok [13:58] *more than 1 [13:59] ahh ok, so ppisati any cves we find missing via this testing i need the numbers for to reopen the CVEs [13:59] From past experience it can be worth looking at the failed test closely since some are doing statistical checks and sometimes those were to tightly checking [13:59] (like the stack randomization checks) [13:59] yep there is that, for the random placement checks they are poor [14:00] and can fail once in a while without being broken [14:00] Yep, I guess with less memory random place is less random than with more... [14:01] i believe that arm has less bits to be random with iirc [14:11] apw: would you be able to stand in for me at the release meeting on fri [14:12] ogasawara, sure, i think there is a change to how its done which you'd have to get me up to speed on [14:12] apw: yep, we send out our team specific bits to the ubuntu-release mailing list ahead of time. then the meeting is just any follow up Q&A for what we sent out. [14:13] ogasawara, and we chose the bugs for the list as well ? [14:13] apw: yep [14:13] how we been picking them [14:13] apw: apw: I'll go ahead and send out the email to ubuntu-release. that way you can just sit in on the meeting. [14:13] are we relying on jo for that, or do we have a tag [14:14] ogasawara, ok fair enough [14:14] apw: mainly relying on the rls-p-tracking tag [14:14] apw: but we're responsible for putting that on the bugs [14:14] apw: but since we've just uploaded a 3.2 kernel, I haven't been real aggressive with using the tag just yet as it's not clear if some of the bugs will resolve themselves with the newer kernel. [14:15] apw: but I've been keeping an eye on some, which I'll list in the email. [14:15] yeah for sure, till that mess is in and stable we're spinning wheels [14:16] apw: I also uploaded a new 3.2.0-1.3 to fix up bug 893395 [14:16] Launchpad bug 893395 in linux "ext2 modular in precise but missing from fs-core-modules" [Critical,Fix released] https://launchpad.net/bugs/893395 [14:16] apw: once that builds I'll hopefully want to upload linux-meta finally [14:16] tseliot: were you able to take a peek at wl? [14:17] ogasawara, yeah saw that on irc scroll back, a good decision me thinks [14:18] ogasawara: I'm working on it as we speak. I think I've found the change that causes the build to fail. I have to see if this is the only change though [14:18] tseliot: great, thanks. please keep us posted. [14:18] ogasawara: sure === ericm|ubuntu is now known as ericm-Zzz [14:38] jsalisbury: think you'll you be ready to pick up chairing the weekly IRC meeting next week? [14:48] ogasawara, apw: my patch at least allows the module to build. Now I only need to test it on a device with broadcom [14:48] sounds good [14:50] now remembering which one of the bazillion devices that I have around has broadcom is the main problem ;) [14:51] ogasawara, yes, next week is good for me [14:52] jsalisbury: and I haven't forgotten about the bug you pinged about yesterday, will get to it soon [14:53] ogasawara, cool. thanks [15:03] * herton -> lunch [15:29] * ogasawara back in 20 [15:40] apw: thanks for the dpms suggestion for the random freezes! [15:41] hey np [15:49] * tseliot has finally found a device with a broadcom chipset \o/ [15:54] herton: is this table accurate? https://wiki.ubuntu.com/Kernel/Dev/ABIPackages [15:55] herton: is that what you use, or do you have a more authoritative source? [15:56] mdeslaur, yes, it's the official source [15:56] herton: ok...can I correct everything that's inaccurate in it then? [15:56] mdeslaur, yep [16:00] ogasawara, we need to add a WI to update the above page and its friends when we are about to release, by kernel freeze we should know i'd think [16:00] ogasawara, with our standard ones like emailing out the config [16:02] apw, ogasawara: unfortunately the only laptop (that works) which has a broadcom card only uses the open driver. I think the laptop that I used for testing is the one with the dead monitor... [16:03] tseliot, if you have .debs i have brcm that works with wl i believe [16:03] apw: sure, for amd64? [16:03] sadly its 32bit [16:03] apw: ok, let me create a 32bit chroot then [16:05] tseliot, hang on [16:05] tseliot, its a dkms package, isn't it an _all ? [16:05] apw: no, as we only support i386 and amd64 [16:05] unfortunately [16:06] tseliot, but the package would be identicle, as in its not a binary package? [16:07] apw: the makefile is patched so that the right binary is used according to the architecture [16:07] tseliot, yeah i mean if i just force the xmd64 binary on it'll work right ? [16:07] there are separate binaries in the same package for the two archs [16:07] oh ick ok, i'll shut up now [16:08] ogasawara, is the meeting in an hour ? [16:08] apw: yep [16:08] you or joe? [16:08] apw: me. joe will take over next week. [16:09] apw: even if you force the installation I think dpkg --print-architecture would report the right architecture and things should be fine [16:09] apw: so it's probably worth trying [16:09] (the makefile is called by DKMS) [16:09] tseliot, can do if you point me to a binary [16:09] apw: sure let me upload the deb file [16:11] apw: http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu1_amd64.deb [16:12] apw: no, wait [16:12] it won't work [16:13] tseliot, /me waits [16:13] apw: some files are renamed when the package is built, therefore it's not gonna work [16:13] tseliot, ok [16:14] apw: hopefully my chroot will be ready in a few [16:14] ok [16:23] apw: the creation of an i386 chroot failed (because of perl...). I'm using my Lucid 32bit chroot [16:24] * tseliot keeps his fingers crossed [16:25] heheh [16:28] i didn't see the usual kernel meeting warning [16:28] it's still scheduler in 30mins, right? [16:29] *scheduled [16:29] ppisati, indeed should be, ogasawara did we miss a 1hr warning? [16:29] yah, got sidetrack and didn't spam the channel [16:30] np [16:30] ## [16:30] ## Kernel team meeting today @ 17:00 UTC [16:30] ## [16:30] eek [16:30] (that is in 30 minutes people) [16:30] he lives... [16:30] who me? [16:30] yes [16:30] :) [16:30] I've been grinding data all day [16:30] cking, i expect you have half a dozen reports for the thing right ? [16:31] I'm still working on it [16:31] I guess the meeting will take then a bit longer than usual... :) [16:32] * cking keeps on finding weird corner cases which need double checking [16:34] herton, apw. Not a regression, definately. I was just recently able to get the qrt kernel tests working on armel w/o a lot of false positives. [16:37] GrueMaster, ok cool, herton that sounds like we can at least release it [16:37] jsalisbury: just fyi, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/892675/comments/2 [16:37] Launchpad bug 892675 in linux "include/linux/usb.h missing" [Medium,Invalid] [16:37] ppisati, we do need to get a list of all the CVEs which are truly not fixed on there so i can get them active again [16:37] yep, GrueMaster can you tag it passing qa on the maverick ti-omap4 bug? ppisati opened a new bug to work on the failures [16:38] Will do. [16:38] ogasawara, thanks! [16:39] apw: so far, only 1 seems good and it's not a CVE [16:39] apw: it's a fix for the fix of a CVE [16:39] ahh, it should probabally have had a CVE number and didn't [16:40] apw: 2 of the failing tests seem not applicable to maverick/omap4 [16:40] apw: http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu1_i386.deb [16:40] apw: and now i'm looking atthe last one [16:40] ogasawara, as the reporter is mentioning /usr/include those would be the copies in linux-libc-dev, are they in there too ? [16:41] There is one test that is failing (/dev/mem) that needs more research, but I am not counting it in the test failure results yet. [16:41] ogasawara, and indeed on my precise install there is no /usr/include/linux/usb.h [16:42] hrm, /me double checks [16:43] ogasawara, that it _is_ in headers and not linux-libc-dev doesn't mean its meant to be in /usr/include of course [16:43] there is a process in the kernel to copy it over ... [16:43] ogasawara, i can take a look if you like [16:43] apw: sure, go for it [16:43] GrueMaster: SECCOMP and STRICT_DEVMEM are not applicable to that release [16:43] GrueMaster: i sent you a test kernel for the mlock split stuff [16:44] GrueMaster: and the only missing part are the PTRACE* checks [16:45] ppisati: Not seeing a kernel link [16:46] GrueMaster: i sent it in #ubuntu-arm [16:46] GrueMaster: anyway [16:46] GrueMaster: http://people.canonical.com/~ppisati/linux-image-2.6.35-903-omap4_2.6.35-903.27~mlockfix_armel.deb [16:46] GrueMaster: this should fix the [16:46] hi [16:46] GrueMaster: "Make sure the stack guard page does not split the stack on mlock ... FAIL" [16:46] GrueMaster: in test-kernel.py [16:47] I dont find iwlwifi / iwlagn modules in 3.2 ubuntu kernel [16:47] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/ [16:47] is that normal ? [16:48] (sorry if I am on the wrong channel) [16:51] HadiM: not sure about the mainline build (which is the url you posted), but I'm using the iwlwifi driver right now on a 3.2.0-1.2 Ubuntu kernel [16:52] modinfo iwlwifi [16:52] filename: /lib/modules/3.2.0-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko [16:52] 32bit or 64 ? [16:52] HadiM: 64 [16:52] ok same here [16:52] I double check the deb [16:54] in the url I gave you the kernel name is 3.2.0-030200rc2-generic/ [16:54] ogasawara, when you did the rebase did you notice anything about those changing name [16:54] and there is no iwlwifi dir in /lib/modules/3.2.0-030200rc2-generic/kernel/drivers/net/wireless/ [16:54] apw: not that I'm aware, but tgardner did the original v3.2-rc1 rebase [16:55] oh youre using the precise kernel build [16:55] HadiM: right [16:55] I suppose it is not the same as http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/ [16:55] thats strange [16:56] I will try the precise build on my oneiric [16:56] HadiM: that url is to the upstream vanilla v3.2-rc2 kernel. although I'm not sure why it would be missing there. [16:56] tseliot, on it [16:56] it is missing in 3.2 rc1 and rc2 for sure [16:56] apw: thanks [16:57] ppisati: Your kernel fixes that bug, but it must be an older spin. It is giving me a different mac on boot, and the eth0 is now usb0. [16:58] * apw notes a netbook is not the speedyiest [16:58] GrueMaster: no, i put the patches on top of maverick/omap4 tip [16:59] Well, system came up with a different mac, so not sure what is different. [16:59] * ppisati notes kernel.ubuntu.com is dead slow... [17:00] meeting time... [17:00] already [17:01] GrueMaster: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4 [17:01] GrueMaster: latest 4 patches are the fix [17:01] GrueMaster: and are on top of the rest [17:03] Well it is failing my testmac test, which enables/disables the ethernet port 10 times and compares mac addresses in between. I can't reach the system now until dns catches up with dhcp (I'm remote and the system is at home). [17:05] Wait, I think I see the problem. It isn't polling the die id. [17:07] Let me reboot to the proposed kernel and verify. [17:09] ppisati: Sorry, I guess I just never noticed it before. I don't think 2.6.35 polls the die id for the mac address. nevermind. [17:10] I usually run sru tests on it locally. [17:10] tseliot, not looking good on my machine here ... seems to partially think its a wired network and generally doesn't connect [17:11] ogasawara, followed along ok. I should be fine to take over next week. Will you update the runes file to include ckings power topic? Or should I do it when updating it from the agenda next week? [17:11] jsalisbury: I'll go ahead and update it [17:11] apw: did you reboot? [17:11] ogasawara, cool, thanks [17:11] tseliot, yep [17:12] jsalisbury: I'm also thinking it would probably be good for you to take over reporting the "[TOPIC] Release Metrics and Incoming Bugs" [17:12] ogasawara, sure [17:12] tseliot, also hand blacklisted the kernel modules which pick up this device otherwise [17:12] jsalisbury: it's just a copy and past of http://people.canonical.com/~kernel/reports/kt-meeting.txt [17:12] ogasawara, ok [17:13] jsalisbury: if there are any other bugs which you want us to look at as well, that's probably a good time time to raise them as well. [17:13] ogasawara, good idea. I can add a reminder about the hot list. [17:13] apw: I also updated the driver to a new release, so maybe we're facing 2 different problems here. I could write a patch against the old driver and see if it helps [17:14] tseliot, ok whatever you think [17:14] cirtainly something is odd cause nm is mistaking it for a wired port [17:17] tseliot, though i have no idea how nm knows what sort of port any port is [17:18] apw: this is all I did: http://pastebin.ubuntu.com/746118/ [17:19] yeah seems unlikely that would fookulize everything else, so we must suspect the new driver [17:20] apw: right (hopefully). Let's see if the old driver works [17:31] apw: is this any better? http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu5_i386.deb [17:42] * ppisati -> eod [17:43] tseliot, ok with that one, after a reboot i get what appears to be working wiki [17:43] wifi, done a bit of surfing so far, nothing hardcore [17:46] apw: \o/ [17:46] * apw watches a movie on it [17:47] apw: ok, I'll keep the old driver with my patch on top [17:48] tseliot, seems like a good first step to me [17:51] apw, ogasawara: ok, I've just uploaded the broadcom driver with my patch (in Precise) [17:51] tseliot: awesome, thanks [17:56] yw [17:56] apw: thanks for testing [17:57] tseliot, thanks for fixing :) at least we have a full set of binary drivers before the kernel goes live, that must be a first [17:57] apw: hehe, nice :) [19:42] is it possible to build an amd64-kernel on an i386-cpu without amd64-instructions? [19:43] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502/comments/118 then i can provide here the amd64 version too [19:43] Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed] [19:45] atm i am using skipabi=true skipmodule=true fakeroot debian/rules binary-iceroot and that is building i386 here [19:48] smb: thanks for your review, I've reverted the "UBUNTU: SAUCE: xen: Do not use pv spinlocks on HVM" patch on Precise master-next. I'll rebase it out of existence at the next rebase. [20:16] Hi. I have done a lot of kernel building, but not withinb Ubuntu. What I want to do is build logfs as a module and load it. [20:17] There are a lot of howtos, each different, and different for various versions. So here is what I did: [20:18] mkdir /opt/ubuntu-kernel-src [20:18] cd /opt/ubuntu-kernel-src [20:18] sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r) [20:18] apt-get source linux-image-$(uname -r) [20:18] cp /boot/config-2.6.38-12-generic-pae .config [20:19] make; make modules_install [20:20] That unfortunately builds and installs modules for 2.6.38.8 and not 2.6.38-12-generic-pae [20:20] Hints?? [20:20] cdhm, make oldconfig scripts prepare; make M=`pwd`/fs/logfs [20:21] cdhm, oh, first do 'fakeroot debian/rules prepare-generic-pae;cp debian/build/*/.confg .' [20:29] tgardner: So what's the order of operations... do the apt-gets, then do the fakeroot thing, then the make config, then make changes to .config to turn on CONFIG_LOGFS then make logfs. Is that correct? [20:31] cdhm, no, you want to change the CONFIG_LOGFS option in debian.master/config first, then the fakeroot thing [20:33] tgardner: Ok, so the order is:do the apt-gets, then nobble the debian.master/config then do the fakeroot thing, then regular make; make modules_install [20:36] cdhm, not regular make, e.g., 'cp debian/build/build-generic-pae/.config .;make oldconfig scripts prepare;make M=`pwd`/fs/logfs' [20:37] tgardner: So what then does the modules install? [20:37] cdhm, assuming you're running that kernel you can simply 'sudo insmod fs/logfs/logfs.o' [20:39] tgardner: Not that easy... logfs wants other modules installed too. Doing the depmod/install would be neater. [20:40] cdhm, well then perhaps you should just build the whole kernel and .deb, e.g., 'fakeroot debian/rules clean binary-generic-pae', then install the linux-image debian package that gets created. [20:42] So isn't there a middle ground without drinking the whole Debian KoolAid? [20:43] cdhm, not really. welcome to building kernels... [20:46] Hmmm. Building kernels for embedded is a lot more straight-forward with a quicker turnaround. [22:04] howdy! would anyone have an ETA for applying the fix indicated for bug #892615 to the Precise kernel? [22:04] Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615 [22:05] someone spotted an upstream commit that allegedly fixes it. [22:07] Q-FUNK, presumably it will show up in the normal course of development before 3.2 is released [22:31] tgardner: it currently flat out prevents the kernel from loading.