[01:54] <psusi> how can you get the inode given the file *?
[01:56] <ohsix> stat(fileno()) ?
[01:56] <psusi> no, in the kernel... I have the struct file *, but need struct inode *
[03:05] <vanhoof> psusi: got to be a way, can get the info w/ ls -i
[05:17] <egon> How do you find what kernel diffs have been applied to a specific kernel? I'm finding things in bzr/launchpad isn't matching what's in git, and doesn't seem to match what's in the source package.
[06:15] <kenrhad> Hello
[06:15] <kenrhad> anyone online?
[06:21] <RAOF> !ask > kenrhad 
[06:21] <ubot2> kenrhad, please see my private message
[06:22] <jk-> RAOF knows all the tricks
[06:22]  * RAOF is the master
[06:24] <kenrhad> I have started to learn C programming by myself (K&R 2nd ed). So far I am reading ch 4. I enjoy programming so far. The harder the problem the best. I'm not good at math though.
[06:25] <kenrhad> I would like to know how much C programming should I learn before I could try to learn something about the linux kernel.
[06:25] <RAOF> I don't think there's any reason to know *any* C before trying to learn about the kernel; you can pick up both at the same time.
[06:25] <kenrhad> ? How can I get involve? The kernel is so big that I dont even know where to start :(
[06:26] <RAOF> That's a bit of a motivational question, so there's not really a single answer.
[06:27] <RAOF> *I* tend to investigate problems I run into, and read the graphics development mailing lists.
[06:28] <kenrhad> mmmm I dont want anything about graphics. Not now though. I want know basics. Before I could learn calculus, I need algebra, trigonometric and other stuff :)
[06:28] <kenrhad> This questions seems to be kind of complicated.
[06:29] <RAOF> Programming really doesn't have the same sort of structure as mathematics.
[06:30] <kenrhad> I have a copy of the first linux kernel, But i cant be sure what am I really reading. I cant understand assembler. Only C.
[06:31] <RAOF> Very little of the current kernel is assembler; you'll be much better off looking at the current kernel.
[06:31] <kenrhad> I've been thinking about finding someone with experience in programmming with the kernel. But I havent found anyone.
[06:33] <kenrhad> I want to learn what are the things the fuctions that are first executed once you turn on the PC. putting things in memory etc.
[06:38] <kenrhad> Well i will be back later on. My mind is tired right now. Good night everyone
[09:40] <aquarius> hey, kernel peeps. A bot added a comment to one of my bugs (via bjf) saying "Test with newer development kernel (3.2.0-5.11)". I don't know whether that means to test with a newer version in Ubuntu or to test with a newer mainline kernel build
[10:37] <brendand> aguarius - looks like an ubuntu kernel to me.
[10:39] <brendand> aquarius - what's the bug number?
[10:40] <aquarius> brendand, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904261
[10:40] <ubot2> Launchpad bug 904261 in linux "Lenovo U300s does not suspend" [Medium,Incomplete]
[10:41] <brendand> aquarius - should be enough just to do an apt-get dist-upgrade
[10:41] <brendand> run uname -a to make sure it matches
[10:42] <aquarius> brendand, ok -- I'm certainly happy to do that! I didn't know whether it meant a new *mainline* kernel, since I was asked to test with that before. (It might be useful to update the message from the bot slightly to make that clear?)
[10:42] <brendand> aquarius - there's a different message for mainline builds
[10:43] <brendand> it could be clearer maybe
[10:43] <aquarius> brendand, dist-upgrading is not showing a new linux upgrade (although there is one for linux-firmware?)
[10:44] <brendand> aquarius - looks like comment #2 asked for a mainline kernel test : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904261/comments/2
[10:44] <ubot2> Launchpad bug 904261 in linux "Lenovo U300s does not suspend" [Medium,Incomplete]
[10:45] <aquarius> brendand, yep, and I did that test -- I was just confused about the bot message. (I'm sure there is a separate message for mainline kernel re-testing, and I bet that that's clear that it means a mainline kernel; I'm just suggesting poking this bot's message slightly :))
[10:54]  * ppisati is always amused how slow rmk's git tree is...
[10:54] <aquarius> OK, I'm now confused. Bug #904261 says that there's a new version of the kernel available, and adds a tag kernel-request-3.2.0-5.11 , but afaict there is no kernel 3.2.0-5.11 available; I've fully dist-upgraded, and uname -a says I'm still on 3.2.0-4 (and there's no 3.2.0-5 in apt-cache search linux-image either). Do I need an early-releases kernel PPA or something?
[10:54] <ubot2> Launchpad bug 904261 in linux "Lenovo U300s does not suspend" [Medium,Incomplete] https://launchpad.net/bugs/904261
[11:05] <apw> aquarius, that is a very new upload, and hasn't actually made it all the way through to being published
[11:13] <aquarius> apw, ah, cool, I can wait, then! Might it be a good idea to delay the bot updating bugs with a message to test the new kernel until the new kernel's available to everyone?
[11:14] <apw> yeah thats a reasonable statement
[11:17] <apw> ogasawara, i bumped precise linux-meta and uploaded
[11:24] <ppisati> apw: while there, can you bump linux-meta-omap4? thanks
[11:24] <apw> ppisati, heh, sure
[11:28] <apw> ppisati, what does Tilt-tracking mean ?
[11:29] <apw> ppisati, and the changelogs look much better with the rebase changelog in, thanks
[11:31] <apw> ppisati, ahh they are still building, so i can't upload it yet ... they should finish in the next minutes though so i will get it up as soon as they are accepted
[11:34] <ppisati> apw: tilt-tracking is the TI BSP stuff
[11:34] <ppisati> apw: TI Landing Tree
[11:35] <apw> ppisati, ok so that is maintaining an upstream pointer so we know what you have included, nice
[12:07] <apw> aquarius, which debugging pages have we pointed you to before ?
[12:08] <aquarius> apw, https://wiki.ubuntu.com/DebuggingKernelSuspend
[12:08] <cking> aquarius, I have an "experimental" set of systemtap scripts that enable one to debug S3 a little deeper: https://wiki.ubuntu.com/Kernel/Reference/S3SystemTapDebug
[12:08] <apw> cking, is that linked to our basic debug page do you know??
[12:09] <cking> apw, suppose it should be, I just wanted hwe to see how valueable it was before it was widely spread about
[12:09] <aquarius> cking, aha, that sounds useful
[12:09] <apw> cking, then we can ask aquarius to evaluate that for us :)
[12:09] <cking> aquarius, "your mileage may vary" on this :-)
[12:33] <herton> cking, interesting, that could help with bug 904569 as well
[12:33] <ubot2> Launchpad bug 904569 in linux "Linux 3.0.0-15-generic-pae causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Confirmed] https://launchpad.net/bugs/904569
[12:34] <cking> herton, yes, it's worth a go
[13:10] <aquarius> cking, blimey, the debug kernel is 653MB. I see what you mean on that s3 page about how it might take some time :)
[13:11] <cking> aquarius, yep, and the script may not show up much more than we know anyway, but it's worth a punt
[13:12] <aquarius> cking, after I've finished, should i remove this debug kernel again? (specifically: is it actually a debug *kernel*? or is it symbols and stuff that are OK to keep around, I'll just not use them?)
[13:13] <cking> it's debug symbols really, so you can remove it as it takes up *lots* of space
[13:13] <aquarius> cking, and just to be clear, my system never enters a suspended state afaict; it's not that it suspends OK but fails to resume. So I don't know whether "it tries to suspend and fails but just sits there at a black screen" counts as a "hang" for the purposes of locatehang?
[13:14] <cking> yep, locatehang will show us roughly where we got to before it hung
[13:14] <aquarius> cool, ok
[13:14] <aquarius> will try the stuff on the page, then
[13:15] <lamont> does it make any sense that a machine would suddenly decide that traffic bound for 127.A.B.C over lo should magically use the same IP as the source IP?
[13:15] <lamont> (lucid kernel)
[13:16] <aquarius> cking, so (assuming that the script doesn't do something different from "normal" suspend), I shoudl sudo "./s3test -s", it'll get as far as the lit-up black screen and then sit there, I powercycle the machine, then run locatehang, and attach locatehang and s3*.log to the bug report?
[13:16] <cking> aquarius, yes, exactly
[13:16] <aquarius> roger wilco
[13:17] <cking> I'd be interested to see if locatehang gives any sane data
[13:17] <aquarius> all this stuff about flashing keyboard LEDs is for you guys to debug stuff, not for me, right? :)
[13:19] <aquarius> cking, http://paste.ubuntu.com/772182/ is the output - SystemTap failed to execute, apparently
[13:19] <aquarius> cking, s3-error.log is at http://paste.ubuntu.com/772184/
[13:20] <aquarius> "fatal error: asm/i8253.h: No such file or directory" seems to be the relevant bit of the error log
[13:20] <cking> aquarius, which kernel are you using?
[13:20] <aquarius> Linux faith 3.2.0-4-generic #10-Ubuntu SMP Sat Dec 10 17:46:09 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[13:20] <aquarius> is uname 0a
[13:20] <aquarius> er, -a
[13:20] <cking> ah, never tried it for that. I need to fix the scripts then :-(
[13:21] <aquarius> is that not the kernel I should be using? :(
[13:21] <cking> the kernel is fine, the s3 script is out of date already 
[13:23]  * cking looks at fixing it. may take a while
[13:24] <cking> aquarius, can you tweak the s3.stp so that "#include asm/i8253.h" is "#include linux/i8253.h" instead?
[13:25] <aquarius> # include <linux/i8253.h>
[13:25] <aquarius> yes?
[13:25] <cking> yes
[13:25] <aquarius> (that is: it has the angle brackets in)
[13:26] <aquarius> cool
[13:26]  * aquarius is not a C person :)
[13:26] <cking> I made a mistake, so thanks for spotting it
[13:26] <aquarius> do I need to recompile it or anything?
[13:26] <cking> nope, just re-run the s3 script
[13:26] <cking> it does all the messy building for you
[13:26] <aquarius> trying
[13:26] <cking> fingers crossed
[13:27] <aquarius> failed again
[13:27] <apw> ppisati, linux-meta-ti-omap4 uploaded
[13:27] <ogra_> yay
[13:27] <aquarius> cking, looks like the same identical error in s3-error.log
[13:28] <cking> aquarius, I'm going to have to fix this, it may not be today, is that OK?
[13:28] <apw> tgardner, i have just uploaded linux-meta-ti-omap4
[13:28] <aquarius> cking, ok, no worries.
[13:28] <aquarius> cking, well, I'd like my laptop to suspend, but saying "no it's not OK you have to fix it now! Now!" is not likely to get me the response I'd like ;-)
[13:29] <cking> well, I may need to re-work that script to make it work with the newer kernel, so it I need to get a machine set up to hack on this
[13:29] <aquarius> cking, thanks for the help so far; let me know when you'd like me to test again and I'm happy to do so!
[13:29] <cking> ping me monday
[13:31]  * cking sorts out a machine to test this out...
[13:33] <mjg59> aquarius: Send one to me. Sorted.
[13:33] <cking> :-)
[13:33] <aquarius> mjg59, I've just eaten all my spare cash buying *mine*. I applaud your approach, but I am budget-constrained from following it :)
[13:33]  * cking spots mjg59 trying to collect more broken hardware
[13:33] <aquarius> I'd drop by and buy you a pint if you hadn't fled the country
[13:40] <mjg59> Actually about to get on a plane back to it
[13:43] <cking> welcome back to old blighty then
[14:02] <ogasawara> apw: thanks for doing meta
[14:33] <apw> ogasawara, np
[14:34]  * ogasawara needs more coffee to wrap brain around ipv6 patch
[14:34] <tgardner> ogasawara, I actually built and tested it.
[14:35] <ogasawara> tgardner: and it's working for you?
[14:36] <tgardner> as far as I could tell
[14:36] <tgardner> well, it at least flipped the sysctl values as expected. I didn't check for the effect on the ipv6 address
[14:37] <tgardner> ogasawara, has your sharp eye detected a flaw ?
[14:37] <ogasawara> tgardner: not at the moment, but I'm still digesting
[14:38] <apw> ogasawara, i have published the ti-omap4 upload (email and voices)
[14:38] <ogasawara> apw: thanks
[15:11]  * herton -> lunch
[15:15]  * cking --> grabs a coffee to warm up
[15:20] <ogasawara> tgardner: re ipv6 -> http://kerneltrap.org/mailarchive/linux-netdev/2008/10/13/3628434
[15:21] <ogasawara> tgardner: sounds like this is intended behavior and the docs may need updating
[15:21] <ogasawara> tgardner: will respond in email
[15:23] <tgardner> ogasawara, it looks like dave might accept an update to the implementation as well as doc updates.
[15:23] <tgardner> jeez, thats a 3 yr old discussion
[15:25] <ogasawara> tgardner: yep, which makes me think if the change were to have been implemented, it would have been done by now.
[15:26]  * ogasawara back in 20
[16:22] <tgardner> cyphermox, did you see ogasawara's comments above ^^
[16:22] <cyphermox> nah, checking now
[16:22] <ogasawara> cyphermox: will send email now too
[16:25] <cyphermox> thanks for finding this, that's precisely what I was looking for but I couldn't get far enough I guess
[16:25] <ogasawara> cyphermox: dave does mentioned that either they need to tweak the docs or the implementation to match
[16:26] <cyphermox> yeah
[16:26] <cyphermox> and I sent an email on netdev last week, "what changes to we make" basically
[16:26] <ogasawara> cyphermox: but considering the thread is 3yrs old, I'd have thought if the implementation were to have been tweaked it would have been done by now
[16:26] <cyphermox> doc, or implementation?
[16:26] <cyphermox> ok
[16:26] <ogasawara> cyphermox: cool, any response?
[16:26] <cyphermox> no
[16:26] <tgardner> cyphermox, the docs need updating at any rate
[16:27] <cyphermox> hence why I was making a patch, and hoping to send it and at worst, having it rejected outright
[16:27] <ogasawara> cyphermox: yep, that was my same thoughts.  doesn't hurt sending it.  you'll at least get a definite answer.
[16:27] <cyphermox> tgardner: now that I think of it though, the changes you've made; does it take into account the value "2" you might want
[16:28] <cyphermox> (actually, it's the most likely value if you want to enable use_tempaddr and use it )
[16:28] <tgardner> 2? i thought the only inputs were 0 or 1
[16:28] <cyphermox> ogasawara: I was just a little naive thinking it would be a one  or two-day thing and I could get away with it quickly ;)
[16:28] <cyphermox> tgardner: yeah.
[16:28] <tgardner> what does 2 imlpy ?
[16:28] <cyphermox> 2 = enable *and use by default* privacy addresses
[16:29] <cyphermox> 1 is just enable them, so they are generated
[16:29] <tgardner> well then, my patch wrecks tat assumption
[16:29] <cyphermox> ok
[16:29] <cyphermox> I wasn't just dreaming, but haven't had time to apply and build it
[16:30] <cyphermox> essentially what I'm trying to achieve is that for instance here on my laptop, eth0 comes up very early, before sysctls are applied (so before the default is set to 2); but I want all interfaces to get the value
[16:31] <ogasawara> cyphermox:  I think we should wait to see what upstream has to say before you/we spend more time on this.  if you don't hear back from your original inquiry, then maybe send the patch and see if that triggers a response.
[16:31] <cyphermox> a kernel patch is pretty much the only way I found that makes sense to do this; because modifying the initramfs depends on having an initramfs, which isn't always true, and it seems to be coming up that early
[16:32] <cyphermox> ogasawara: you mean more than 10 days?
[16:32] <cyphermox> I sent my original email on the 10th or so
[16:32] <cyphermox> err, 6th, sorry
[16:32] <cyphermox> there's a rather large volume of messages on netdev, I'm afraid it only got lost in the flow
[16:35] <ogasawara> cyphermox: a patch might get more notice/feedback then
[16:40] <cyphermox> ok
[16:43] <pgraner> apw, ping
[16:43] <apw> pgraner, pong
[16:44] <pgraner> apw, can you look at apport.linux.image* on chinstrap://~leworks
[16:44] <pgraner> apw, specifically the dmesg
[16:44] <apw> pgraner, can't read it
[16:45] <pgraner> apw, one sec he's putting the txt file
[16:49] <pgraner> apw, same place called albali-demesg.txt
[16:50] <pgraner> apw, there are a ton of odd machine check errors and other stuff that I think is causing the box to have piss poor performance
[16:50] <pgraner> apw, wanted to get your take on it
[16:51] <apw> pgraner, what is this thing running?  i thought those messages got suppressed
[16:51] <apw> pgraner, those are the turbo event things
[16:51] <aquarius> cking, thanks for the script! I've run it now; same failure to suspend (as expected), s3*.log were all 0 bytes, and locatehang printed something. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904261/ (final comment) for the output
[16:51] <ubot2> Launchpad bug 904261 in linux "Lenovo U300s does not suspend" [Medium,Triaged]
[16:51] <pgraner> apw, this is 11.10 on a Romley box
[16:51] <pgraner> apw, Intel SDP
[16:51] <apw> pgraner, 11.10 with the latest kernel ?
[16:52] <Toad> apw, kernel is 3.0.0-14-server
[16:52] <cking> aquarius, looks like it never came back out of S3 into the kernel
[16:52] <pgraner> apw, Toad is the new lab admin
[16:52] <aquarius> cking, I'm not sure what that means
[16:53] <cking> it's stuck somewhere but not in the kernel perhaps
[16:53] <aquarius> cking, the machine never shuts down when asked to suspend; it's not failing to resume, it's failing to suspend in the first place, unless I've completely misunderstood what's going on
[16:53] <cking> ah, OK, that's easier for me to diagnose
[16:54] <apw> Toad, hey welcome aboard
[16:54] <cking> aquarius, let me hack some code for you to try out one more test.
[16:54] <aquarius> cking, I tell it to suspend (the normal way, or with your script) -- the screen goes black (but it's a lit-up black, not a turned-off black) and then just sitsthere like that forever, and the machine doesn't power off. I have to powercycle it by holding down the power button for 5s to turn it off
[16:54] <Toad> apw, thx
[16:55] <cking> aquarius, yep, I can see it's written to the PM1 control registers to put it to suspend and then that's about as much as the kernel can do, it seems to have got stuck for some unknown reason.
[16:56] <aquarius> cking, ah, so we do everything right, we then say "ok, hardware, we've done everything - now suspend yourself!" and the hardware then... doesn't?
[16:56] <cking> aquarius, does shutdown get stuck too?
[16:56] <aquarius> cking, nope, shutdown works fine
[16:56] <aquarius> I'd be being way, way more whiny if i had to hard-power-off the machine to get it to shut down :)
[16:57] <cking> aquarius, so I'm not entirely sure. I've seen broken H/W where we do the S3 transition and S5 (power off) hang, but this is different. I really am not sure now.
[16:58] <aquarius> hrm :(
[16:58] <aquarius> any other information I can provide?
[16:59] <cking> aquarius, I don't think so, we may need to involve alexhung as he's out BIOS guru
[16:59] <cking> he may have an idea
[16:59] <cking> s/out/our
[17:00] <aquarius> and asleep, to boot, I suspect, since it's 1am there :) I can ping him over the weekend or Monday or whatever?
[17:01] <cking> monday morning is best, he is about until ~noon UK time
[17:01] <apw> Toad, pgraner, ok those imply we are jumping into and out of turbo alll the time and slowing ourselves down with all the logging
[17:02] <apw> it seems the machine has a lot of cpus and packages and that triggers a deluge
[17:02] <cking> aquarius, I've updated the bug and subscribed alex
[17:02] <apw> it is likely they should be rate limited, as they are not helpful in vast quantities
[17:02] <aquarius> cking, thanks, pal
[17:02] <pgraner> apw, anything we can do on the box to test it?
[17:03] <cking> aquarius, it's a new issue that I've not seen, but at least we know where it's going wrong now
[17:03] <tgardner> apw, pgraner: it might have already been fixed upstream
[17:03] <pgraner> tgardner, yea this is on a qa box that is making it unusable
[17:03] <tgardner> plug in a 3.2 kernel
[17:03] <bjf> aquarius: was this suspending/resuming find on oneiric ?
[17:03] <bjf> s/find/fine/
[17:04] <apw> tgardner, its not in precise ... so i suspect not
[17:04] <pgraner> tgardner, I can't put a 3.2 kernel, they all need to be running the same thing for consistency 
[17:04] <aquarius> bjf, I don't know. The machine's brand new (released only a week ago or so), I bought it on Sunday, and installed precise on it :)
[17:04] <bjf> aquarius: ok, thanks
[17:04] <tgardner> pgraner, just for debugging purposes. if fixed, then we can figure out what needs backporting
[17:05] <pgraner> tgardner, ok, thats fair, Toad can slap one one, you want mainline or the precise kernel?
[17:05] <tgardner> precise is likely easiest
[17:05] <pgraner> tgardner, ack
[17:10] <pgraner> tgardner, apw: bouncing the box now, will let you know
[17:11] <apw> pgraner, i don't expect it'll help
[17:12] <pgraner> apw, me either but will make Grumpy happy 
[17:13] <tgardner> what would the stable team suggest, huh ?
[17:15] <pgraner> tgardner, don't know didn't talk to them, apparently they are awol in the channel
[17:16] <tgardner> pgraner, wait until Monday. ain't nobody gonna be around.
[17:16] <tgardner> including you
[17:21] <pgraner> tgardner, now we get panics with that kernel
[17:21] <tgardner> pgraner, full on wedge me kind of panics ?
[17:21] <Toad> apw,tgardner,praner,  pastebin link for new kernel output: http://pastebin.ubuntu.com/772431/
[17:21] <cking> aquarius, think you've filed the first bug on the planet against that H/W. Did S3 work with Windows?
[17:22] <pgraner> tgardner, no NMI watchdog stuff
[17:22] <aquarius> cking, don't know. The machine came with windows on it, but I just installed Ubuntu. :)
[17:23] <tgardner> pgraner, its a good thing you've got lots of CPUs, otherwise you wouldn't have gotten this trace. 
[17:24] <pgraner> tgardner, ok smart guy fix it
[17:25] <tgardner> pgraner, what rev HW is this? production quality ? did it work with older kernels, and does it still ?
[17:25] <pgraner> tgardner, this is the sister box to the magners box in Lex
[17:26] <pgraner> tgardner, its running the same silicon rev afaik
[17:26] <tgardner> have we looked at magners ?
[17:26] <pgraner> tgardner, I have that new board and cpus to put in magners but haven't yet
[17:26] <pgraner> tgardner, Toad is checking it now
[17:26] <tgardner> that was .2, right ?
[17:27] <egon> I've been getting RCU panics on a bunch of machines running 2.6.35-30-server
[17:27] <egon> And I think I've tracked down the bug, but I'm having a hard time finding how a certain version of a file got into the kernel source package
[17:27] <egon> since it doesn't match what's in bzr or in hit
[17:27] <egon> er, git
[17:28] <tgardner> pgraner, Toad: magners is full of iptables cruft. but no MCE entries.
[17:28] <cking> pgraner, can you see the message "Thermal monitoring handled by SMI" in any of the kernel logs?
[17:29] <tgardner> egon, see if you can catch herton
[17:29] <herton> egon, what file is it?
[17:30] <pgraner> cking, nope
[17:31] <pgraner> tgardner, looks like albali is a silicon rev behind magners
[17:31] <Toad> cking, these are the on thermal messages [  130.035254]  [<ffffffff8102c5bf>] intel_thermal_interrupt+0x12f/0x160
[17:31] <Toad> [  130.035258]  [<ffffffff8102c641>] smp_thermal_interrupt+0x21/0x40
[17:31] <Toad> [  130.035262]  [<ffffffff8165bb9e>] thermal_interrupt+0x6e/0x80
[17:31] <Toad> [  130.048404]  [<ffffffff8102af7b>] mce_log_therm_throt_event+0x2b/0x40
[17:32] <Toad> cking, that's on albali
[17:32] <tgardner> pgraner, maybe you should apply the upgrade before we pursue it too much further.
[17:32] <pgraner> tgardner, won't happen this trip
[17:33] <tgardner> pgraner, come on, its only noon thirty there. are you off for beers already ?
[17:33] <Toad> tgardner, we're waiting on shipments of other hardware to show up.
[17:34] <tgardner> Toad, kind of getting down to the wire timewise
[17:34] <tgardner> is albali in the DC ?
[17:34] <Toad> story of my life. Yes albali is inn the DC
[17:35] <tgardner> ah, and you're in lex
[17:35] <Toad> true
[17:35] <tgardner> that makes all the difference. I retract any previous snideness
[17:41]  * cking --> back in 30
[17:43] <egon> herton: af_unix.c
[17:45] <herton> egon, so what's the specifics, does it not match against what is in git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git? What version of the linux-source are you using, etc.
[17:46] <egon> herton: It's 2.6.35-31.63 .. It has some of the new cred code, but not all of it.
[17:47] <egon> in git, the cred code is added in 109f6e39fa07c48f580125f531f46cb7c245b528
[17:47] <egon> unix_scm_to_skb is added in 7361c36c5224519b258219fe3d0e8abc865d8134
[17:48] <egon> and in the source package, it's missing half of the changes
[17:48] <egon> so you end up with calls to get_cred, and no calls to put_cred
[17:48] <egon> which is, from what I gather, causing a cred leak, and eventually a panic
[17:52] <herton> egon, 109f6e39fa07c48f580125f531f46cb7c245b528 isn't applied on 2.6.35 or any stable after it, but 7361c36c5224519b258219fe3d0e8abc865d8134 came applied through an stable update, may be 7361c36c5224519b258219fe3d0e8abc865d8134 shouldn't have been applied on 2.6.35.y upstream?
[17:54] <herton> 7361c36c5224519b258219fe3d0e8abc865d8134 is "af_unix: Allow credentials to work across user and pid namespaces", that came in 2.6.35.11
[17:55] <egon> Yeah, okay.. So, without 109f, I think you end up with a leaking cred.
[17:56] <herton> egon, you can try to apply/cherry pick 109f on the maverick sources and test, or revert 7361c36c, and test
[17:56] <egon> yeah, the problem is that the bug took 140 days to show up.
[17:57] <egon> I'm not sure how to force it.
[17:59] <egon> herton: so you're looking in bzr somewhere? I couldn't find how 7361 got into the kernel.
[18:00] <herton> egon, 7361 is commit bfbf519e4599ab27c97592a2923377597d15a973 on git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
[18:01] <egon> herton: ahh! so what's being tracked in bzr?
[18:02] <herton> I don't know, I don't use bzr for the kernel, just look directly in the git repo
[18:03] <bjf> herton, egon, that commit came in via a stable upstream release
[18:04] <herton> bjf, 7361c36c5224519b258219fe3d0e8abc865d8134 upstream, bfbf519e4599ab27c97592a2923377597d15a973 in our maverick tree
[18:04] <bjf> yes, i'm just saying that egon is asking how it got into our tree and it came in via a stable upstream release
[18:04] <herton> bjf, nevermind, I read what instead of that :P
[18:05] <bjf> heh
[18:06] <herton> yes, it came in 2.6.35.11 stable update
[18:09] <mkedwards> a couple of questions for people who know their way around ubuntu's kernel packages.  Context:  I'm trying to test an iwlagn fix equivalent to https://lkml.org/lkml/2011/12/13/297 ported to the current oneiric kernel.
[18:09] <egon> upstream is debian, or linus?
[18:09] <bjf> egon, upstream is linus
[18:09] <bjf> egon, there are also upstream stable maintainers
[18:10] <bjf> egon, which are also !debian and !linus
[18:10] <mkedwards> one: it appears that the abi listings (generic.modules, for instance) are sorted in a Unicode locale rather than C/ASCII
[18:11] <bjf> egon, the upstream stable maintainer for 2.6.35 is/was Andi Kleen
[18:11] <egon> bjf, herton : so I'm trying to trackdown whatever is causing a kernel panic "CRED: put_cred_rcu() sees %p with usage %d", which comes from kernel/cred.c, and the only place in the kernel that calls get_cred() and not put_cred() is in net/unix/af_unix.c
[18:11] <mkedwards> which is fine, except that my dpkg-buildpackage run seems to have used a C locale, even though LANG=en_US.UTF-8 is set in the environment
[18:11] <egon> It looks like one changeset got applied without the previous changeset being applied
[18:11] <bjf> egon, that could be
[18:12] <mkedwards> has anyone else been bitten by this?
[18:40]  * ppisati -> EOD
[19:19]  * tgardner -> lunch
[21:53] <cyphermox> ogasawara:  tgardner: patch is sent
[21:53] <cyphermox> thanks for your help
[21:53] <ogasawara> cyphermox: cool, keep us posted
[21:57] <tgardner> cyphermox, ack