[05:54] <ohsix> sconklin: re #793796, i'm around if you want me to poke at stuff
[08:25]  * apw yawns
=== smb` is now known as smb
[08:28]  * smb joins apw
[08:29] <apw> i cannot be bothered to even drink my tea today
[08:30]  * smb realizes he forgot his coffee in the machine...
[08:30] <apw> smb doh doh doh
[08:31] <jk--> :)
=== jk-- is now known as jk-
[08:31] <smb> *slurp*
[08:35]  * apw waves to jk-
[08:35] <apw> just how many -'s do you have today
[08:36] <jk-> just the one now
[08:40] <jk-> apw/smb: OK if I target https://bugs.launchpad.net/800527 to maverick ?
[08:41] <smb> jk-, Not thinking so. Seems to be wrong number
[08:42] <smb> At least lp does not find anything
[08:42] <jk-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/800527
[08:42] <ubot2> Ubuntu bug 800527 in linux "cx23885: Incorrect argument passed to videobuf_dma_unmap" [Undecided,New]
[08:42] <smb> better :)
[08:43] <smb> Ok, why not. Seems to be maverick affected, right?
[08:43] <jk-> smb: yep, I've just never had to use the 'Nominate for a series' thing before, so wasn't sure what the etiquette/process is :)
[08:44] <smb> jk-, Ah, well if your not an uploader, you need one of us to accept the nomination.
[08:44] <apw> jk-: do we know why that original was applied even ?
[08:44] <smb> Or we do the whole thing for you
[08:44] <apw> jk-: it seems to be a sauce patch ?
[08:45] <jk-> apw: it was a backport of some updated IR stuff, and yes, SAUCE
[08:46]  * smb Yeah, I think I remember some discussion on that lirc stuff
[08:46] <apw> jk-: then it was done badly and fixing it seems appropriate, i assume we get bangs without
[08:47] <jk-> apw: no bangs seen so far
[08:47] <jk-> probably leaks though
[08:47] <jk-> the other change to cx23885-core.c causes bangs on a particular ASUS MB though
[08:48] <jk-> but that's not *really* the driver's fault
[08:49] <apw> jk-: sounds awsome
[08:49] <smb> jk-, I wonder whether at least in the bug report it would help to point out that the faulty change was due to some sauce and that therefor does not affect any upstream stable 
[08:50] <jk-> apw: yeah:
[08:50] <jk-> grep MSI /proc/interrupts
[08:50] <jk->  44:          0          0          0          0   PCI-MSI-edge      cx23885[0]
[08:52] <jk-> smb: noted
[08:52] <apw> smb, ... i like commas better
[08:52] <smb> apw, huh?
[08:53]  * smb thinks he misses some joke
[08:53] <apw> smb, playing with settings ... trying out weechat for a bit
[08:53] <apw> something i saw being used at the QA sprint, trying it out
[08:53] <smb> apw, heh, so is it worth learning a new client
[08:54] <apw> a question indeed.  it does the split window thing, and its actually a terminal program
[08:54] <apw> so it has some advantages over xchat
[08:54] <apw> but like all change, it is painful for the first person (me)
[08:54]  * smb thinks its painful for every person trying
[08:55] <apw> well less painful when someone can give you the one line you need to add specific new servers
[08:55] <apw> took me a long time to even work out how to add one
[08:55] <smb> True. Its more about the attachment to some style. Used to be ok with mud. Now have been using tb for so long...
[08:56] <apw> exactly
[08:56] <apw> has some nice features like hiding join part for people _unless_ they were talking recently when you might care
[08:56] <apw> and they are only filtered so you can hit a key to see them
[08:57] <apw> cking just appeared and dissappeared it seems ... network issues in his office perhaps
[08:57] <smb> See I do the opposite with xchat. Hide them all but for people on my sh.. err friends list. :-P
[08:58] <smb> Sounded like it
[08:58] <smb> Or we look scary this morning :)
[08:58] <apw> it would be funny if he can't get to his own wireless from the loft
[08:58] <smb> Hope cking does not find out the only thing not being perfect in the new office is the lan cables
[08:58] <apw> time for some ethernet over power adapters
[09:01] <cking> apw, heh, did have a wireless fail - laptop worked last night, this morning wireless did not
[09:01] <cking> I moved the latop 2 inches and it could then find the AP
[09:01] <smb> cking, Your neighbours started to use theirs. :)
[09:02] <cking> think I was not in a nodal point
[09:02] <apw> cking, i think you need some ethernet over power from your router to your desk
[09:03] <apw> then you can have a shiny local AP for your stuff up there
[09:03] <apw> get one of those 20 dollar ones
[09:03] <cking> apw, I've got that too, just wanted to make sure wireless worked before I hooked up my cheap and cheerful portable AP
[09:03] <apw> ahh good
[10:43] <Kano> hi, firmware 1.54 is too old for ath9k
[10:43] <Kano> http://paste.debian.net/120626
[11:16] <apw> Kano, does appear so, is that firmware update in upstream firmware tree?
[11:16] <Kano> i fetched it from
[11:17] <apw> don't suppose there is any hope you might file a bug
[11:17] <Kano> http://wireless.kernel.org/download/htc_fw/
[11:19] <Kano> no idea if it is somewhere else too
[11:51] <Kano> why is the module-init-tools depency still not removed from the daily/rc builds
[11:58] <apw> because i have not had time, have you had time?
[11:58] <Kano> apw: i use dpkg-deb/sed of course, i had to do take thetime 
[12:11] <ppisati> it seems there's a fix for the usb thing on omap
[12:41] <apw> ppisati, yeah?  what sort of fix, got a pointer
[13:26] <ppisati> apw: 1395401 linus tree
[13:30] <apw> ppisati, looks 'ok' i guess, i assume you are going to get some test kernels together with that applied?
[13:31] <ppisati> apw: doing it right now
[13:31] <ppisati> apw: so far omap4 works
[13:35] <ppisati> and indeed it works
[13:35] <apw> ppisati, very good
[14:03] <ogasawara> tgardner: I wasn't able to reproduce that build failure
[14:03] <apw> morning ogasawara 
[14:03] <tgardner> ogasawara, ok, I'll get back to it in a bit.
[14:03] <ogasawara> mornin
[14:08] <apw> tgardner, it is reported that ath9k needs updated firmware for oneiric: bug #800678
[14:08] <ubot2> Launchpad bug 800678 in linux-firmware "ath9k firmware out of date for kernel 3.0" [Undecided,New] https://launchpad.net/bugs/800678
[14:09] <tgardner> apw, is it upstream yet?
[14:10] <apw> tgardner, i haven't checked, i actualy hoped it was the sort of thing you knew off the top of your head :)
[14:10] <tgardner> apw, easy enough to check
[14:11] <tgardner> apw, hmm, nothing jumping out at me.
[14:11] <apw> there is a link to the firmware in the bug, but i have no idea of provenance
[14:12] <tgardner> apw, I suspect provenance is fine. Atheros needs to get it into Woodhouse's repo
[14:31]  * ogasawara back in 20
[14:45] <tgardner> apw, re: CVE-2010-4526. You indicate in the preamble email that it applies to Lucid/ti-omap4, but then you sent a patch for lucid/fsl-imx51. confused...
[14:45] <ubot2> tgardner: Race condition in the sctp_icmp_proto_unreachable function in net/sctp/input.c in Linux kernel 2.6.11-rc2 through 2.6.33 allows remote attackers to cause a denial of service (panic) via an ICMP unreachable message to a socket that is already locked by a user, which causes the socket to be freed and triggers list corruption, related to the sctp_wait_for_connect function. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4526)
[14:45] <apw> tgardner, sounds like i am confused ... /me checks
[14:46] <apw> there is no lucid ti-omap4 is there ?
[14:46] <tgardner> hence my confusion
[14:46] <tgardner> just wanted to be sure
[14:46] <ppisati> apw: no
[14:46] <ppisati> ti-omap4 starts in maverick
[14:46] <apw> tgardner, the cover letter is in error
[14:46] <tgardner> apw, ack
[14:47] <apw> tgardner, the titles of the patches are correcet
[14:47]  * apw hates all the silly names of arm things
[14:47]  * amitk too
[14:47] <ppisati> ouch
[14:47] <ppisati> actually i already have CVE-2010-4256 for maverick/ti-omap4
[14:47] <ubot2> ppisati: The pipe_fcntl function in fs/pipe.c in the Linux kernel before 2.6.37 does not properly determine whether a file is a named pipe, which allows local users to cause a denial of service via an F_SETPIPE_SZ fcntl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4256)
[14:47] <ppisati> on zinc
[14:49] <apw> ppisati, so much for me trying to include arm
[14:49] <apw> kees, we need our bug thing sorted out so we have somewhere to interlock updates
[14:49] <ppisati> apw: actually i've it only in mav/omap4
[14:49] <ppisati> apw: wait...
[14:49] <ppisati> yes
[14:50] <ppisati> fsl-imx51 doesn't need it
[14:50] <ppisati> apw: anyway, go ahead, no prob
[14:50]  * apw is still using the 'awsome' tracker, but seemingy i am on the only one
[14:50] <ppisati> ah right, i should have updated it
[14:50] <tgardner> ppisati --> beers to apw
[14:50] <apw> ppisati, no real blame, the process is in a massive mess while we wait on bugs being kept in sync
[14:51] <smb> tgardner, Sorry, I had been changing my mind about code cleanup just this morning
[14:51]  * ppisati updates the cve tracker...
[14:51] <tgardner> smb, s'alright. I think I have it figured out.
[14:51] <smb> On the positive side, this is much smaller
[14:51] <apw> ppisati, get your updates pushed up i recon, sooner rather than later
[14:52] <tgardner> smb, have you tested this final version ?
[14:52] <smb> tgardner, Just passed the point it would have crashed before when I sent it
[14:52] <tgardner> smb, ack
[14:53] <ppisati> apw: ok, i push it now
[14:53] <apw> ppisati, i don't mind a few extra pull requests, its mosrly the same amount of work -- reviewing the patches
[14:53] <ppisati> btw, whats status can i use for "i have it in one of my tree but not pushed yet"?
[14:53] <apw> ppisati, there isn't one, and thats why its a problem
[14:54] <apw> and why you and i are stepping on each other.  thats why we have yet a third place to track things
[14:54] <ppisati> apw: yeah, but i was confused ny the "pull req only when the window opens" aka this morning discussion
[14:54] <apw> we want to remove all that and make the bugs the primary copy
[14:54] <ppisati> yep
[14:54] <tgardner> ppisati, apw: its 'In Progress' until pushed to the main repo when it becomes 'Fix Committed'
[14:54] <apw> BUT that needs kees stuff to work
[14:54] <apw> tgardner, right on the bugs yes
[14:54] <ppisati> tgardner: uhm... i did that transition on launchpad but not on the cve tracker
[14:55] <ppisati> tgardner: i was looking for a "in progress" state there too
[14:55] <apw> but as i discovered yesterday searching for 'CVE-NNN-MMM' in launchpad does nto always find you a bug you know exists
[14:55] <apw> and its there that things go wrong, as we have an external list of bugs currently
[14:57] <ppisati> apw: yep, i use two search the cve page, and then walk there the list of lacunhpad bugs attached until i find the right one (usualy it has the same title as the CVE)
[14:57] <ppisati> s/two/to/
[14:58] <apw> ppisati, what search do you do, all mine make no sense and find nothing
[14:58] <apw> i hate launchpad search its almost useless
[14:59] <ppisati> apw: https://launchpad.net/bugs/cve/
[14:59] <apw> OH its the damned 'if the main task is closed i don't exist bug'
[14:59] <apw> thats why i've missed the bugs and crossed with you
[15:03] <apw> ppisati, have you got an example bug you are currently working on so is in an active state
[15:04] <apw> bah these searches just do not include bug tasks i can clearly see exist
[15:04]  * tgardner back in 10
[15:09] <ppisati> ok, i borked the git url
[15:09] <apw> ppisati, where ?
[15:10] <ppisati> apw: lucid/fsl-imx51 pull req, but i sent another email with the right url
[15:10] <apw> ppisati, ahh i see
[15:18]  * apw bounces to fix some niggling bustness
[15:19]  * ppisati -> out to buy a couple of usb cables
=== jjohansen is now known as jj-afk
=== cnd` is now known as cnd
[15:51] <tgardner> apw, the buglink for CVE-2010-4163 is wrong. isn't that messing up your status page ?
[15:51] <ubot2> tgardner: The blk_rq_map_user_iov function in block/blk-map.c in the Linux kernel before 2.6.36.2 allows local users to cause a denial of service (panic) via a zero-length I/O request in a device ioctl to a SCSI device. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4163)
[15:52] <tgardner> it should not be bug #690730
[15:52] <ubot2> Launchpad bug 690730 in linux "Maverick update to 2.6.35.10 stable upstream" [Undecided,Fix released] https://launchpad.net/bugs/690730
[15:53] <tgardner> or maybe its the result of your CVE checker script
[15:56] <apw> tgardner, the bug links matter not to the cve updater
[15:56] <apw> tgardner, commonly where i take a backport and cherry-pick that i will leave the BugLu
[15:56] <tgardner> apw, ack
[15:56] <apw> BugLink alone, and add anohter one at the bottom too
[15:57] <apw> tgardner, does it have two ?
[15:57] <tgardner> nope
[15:57] <apw> hrm, then i suspect i forgot it, thats naught
[15:57] <apw> naghty
[15:58] <apw> tgardner, is there a bug do you know
[15:58] <tgardner> apw, dunno, didn't check.
[15:59] <tgardner> it was something that we got via stable, so likely not
[15:59] <apw> tgardner, now i am confused, according to the Awsome tracker there is one, but you are assigned to the row
[16:00] <apw> bug #721441
[16:00] <tgardner> apw, maverick/ti-omap4 ?
[16:00] <ubot2> Launchpad bug 721441 in linux-ti-omap4 "CVE-2010-4162" [Undecided,In progress] https://launchpad.net/bugs/721441
[16:00] <apw> bah missed, bug #721504
[16:00] <ubot2> Launchpad bug 721504 in linux "CVE-2010-4163" [Undecided,Fix committed] https://launchpad.net/bugs/721504
[16:01] <apw> tgardner, if you are applying now do add it
[16:01] <tgardner> apw, can do
[16:03] <tgardner> apw, pushed maverick/ti-omap4. better now?
[16:05] <apw> tgardner, looks like you did only one of the pair of patches for -4163, not that i think it matters much
[16:06] <tgardner> apw, likely. I only noticed one commit in error before I lost interest
[16:07] <apw> tgardner, fyi the cve updater uses only upstream commit ids from the logs and the ubuntu tags to work out the release correlations
[16:07] <apw> thats why its important those are maintained, of course it is policy to so maintain them
[16:17] <apw> ppisati, thats looking pretty good, fix two more CVEs for arm and hardy will officially move into last place
[16:18] <apw> ppetraki, would it be useful to have a matrix of just the arm kernels? 
[16:19] <apw> ppisati, ^^ even
[16:21] <tgardner> ogasawara, what is the exact command you're using to build oneiric on tangerine ?
[16:21] <apw> tgardner, which build is failing for you ?
[16:22] <ogasawara> tgardner: I use the 'build-start --dist oneiric --branch master-next tangerine-amd64'
[16:22] <tgardner> its still the ubuntu/rtl8192se stuff. the 2.4 kernel part modifies CFLAGS which kbuild hates.
[16:22] <apw> tgardner, for amd64 yes?
[16:22] <tgardner> ogasawara, try it with 'kteam-tools/buildscripts/ukb-make --arch=amd64 --release=oneiric --branch=master-next --clean'
[16:22] <tgardner> apw, yes
[16:23] <apw> tgardner, and which flavour fails
[16:23] <tgardner> binary-generic
[16:23]  * apw lets his tools build it too, to see if its tools related
[16:24] <tgardner> apw, if I delete all of the Makefile code for 'KERNEL 2.4' then it works fine
[16:24]  * tgardner thinks the rtl8192se makefile is hideously fucked.
[16:24] <apw> ifeq ($(shell uname -r|cut -d. -f1,2), 2.6)
[16:24] <apw> ifeq ($(shell uname -r|cut -d. -f1,2), 2.6)
[16:25] <apw> tgardner, ^^ EEK
[16:25] <tgardner> uh huh, indeed
[16:25] <apw> so if your _host_ kernel is 3.0 it will fail
[16:25] <tgardner> 3.0-1-server
[16:26] <apw> so i suspect this will run on tangerine ok, and not on your local systems
[16:27] <tgardner> right, so I guess I'll fix that
[16:27] <apw> 2.6.35-25-server <- so tangerine indeed
[16:27] <apw> but that is utter spack, and should be based on the kernel version... though just making that like like
[16:28] <apw> ifeq (1, 1)
[16:28] <apw> would likley be just as appropriate as we know it is NOT 2.4
[16:28] <tgardner> now, I like that kind of fix :)
[16:28] <ppisati> apw: i'm ok with the big matrix
[16:28] <tgardner> !vi
[16:28] <ubot2> Text Editors: gedit (GNOME), Kate (KDE), mousepad (Xfce4) - Terminal-based: nano, vi/vim, emacs, ed - For HTML/CSS editors, see !html - For programming editors and IDE, see !code
[16:30] <apw> the things ubot2 knows ... i ask you
[16:43] <ppisati> bug 800758
[16:43] <ubot2> Launchpad bug 800758 in linux-ti-omap4 "CVE-2011-1082" [Undecided,New] https://launchpad.net/bugs/800758
[16:43] <ppisati> please accept the nominations
[16:43] <ppisati> apw: ^^^
[16:43]  * apw looks
[16:44] <apw> ppisati, done
=== cking_ is now known as cking
[16:50]  * cking wonders how many euros to take to dublin
[16:51] <tgardner> cking, enough to buy bus fare to the hotel
[16:52] <cking> tgardner, no beers or food in the evening?
[16:52] <maco> cking: how'd you get system tap going with ubuntu? last i checked the wiki it was like "fedora: install it. ubuntu: jump through hoops!"
[16:52] <tgardner> cking, I think there is an ATM in the hotel
[16:52] <maco> did the hoop-jumping reasons go away?
[16:52] <cking> maco, let me find the runes...
[16:54] <tgardner> lamont, are you still happy with the kernel herton built for you yesterday regarding bug #791512 ?
[16:54] <ubot2> Launchpad bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New] https://launchpad.net/bugs/791512
[16:54] <cking> maco, part of this README is relevant to getting systemtap installed: http://kernel.ubuntu.com/git?p=cking/pmdebug.git;a=blob;f=systemtap/README;h=56ca292345a02dea722ffee603ca598af5403356;hb=a86d419fc92da76abb6ff6731cf43667de5c14b2
[16:55] <lamont> tgardner: I have heard no complaints, and experienced no issues with it
[16:55] <tgardner> lamont, great. I'll add that to the bug.
[16:56] <lamont> tgardner: likewise, upstream(?)'s reply to the email does concern me more than I'd like to admit
[16:56] <ppisati> uhm... CVE-2011-1082 and CVE-2011-1083 point to the same fix
[16:56] <ubot2> ppisati: fs/eventpoll.c in the Linux kernel before 2.6.38 places epoll file descriptors within other epoll data structures without properly checking for (1) closed loops or (2) deep chains, which allows local users to cause a denial of service (deadlock or stack memory consumption) via a crafted application that makes epoll_create and epoll_ctl system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1082)
[16:56] <ubot2> ppisati: The epoll implementation in the Linux kernel 2.6.37.2 and earlier does not properly traverse a tree of epoll file descriptors, which allows local users to cause a denial of service (CPU consumption) via a crafted application that makes epoll_create and epoll_ctl system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1083)
[16:56] <tgardner> lamont, me too. I'm gonna have to do some deep code dive. empiracal evidence suggests there is something going on the Eric has overlooked.
[16:57] <cking> maco, you may find that building a .ddeb kernel is required if there isn't an appropriate kernel .ddeb :-(
[16:57] <lamont> tgardner: I hope so.  because random data stomping is (1) scary, and (2) a cheap copout
[16:57] <maco> cking: i feel like there should be an add-ddebs.deb that puts it in /etc/apt/sources.list.d/ and gets the key, like those rpms that install yum repos
[16:58] <tgardner> lamont, we have some initial findings that the same patch affects 3.6.38.8, so the random code stomping theory is likely specious.
[16:58] <maco> or the key should be included by default and the ddebs repo in sources.list but commented
[16:58] <maco> thatd be handy too
[16:58] <lamont> tgardner: very nice
[16:58] <apw> maco, i think we might be able to add it by default if that pool is made one of those 'opt in only' repos
[16:59] <cking> apw, is that a discussion point for the platform rally?
[17:01] <maco> apw: isnt commenting it out enough to make it count as "opt-in only"?
[17:01] <apw> maco, not sure, they are talking about having things like backports enabled all the itme, and then you only getting packages you explicitly install updated
[17:02] <apw> which would fit well for the ddebs i suspect
[17:02] <maco> apw: with pinning?
[17:02] <apw> maco, i think somehow its the default on the repo so you don't have to have anything locally, but functionally like the pinning yes
=== jj-afk is now known as jjohansen
[17:46] <broder> maco, apw: we definitely talked about turning on ddebs by default at uds in one of the sessions
[17:46] <broder> you shouldn't have to pin, though, since the packages all have different names
[17:47] <broder> no, wait, we talked about adding it by default, but commented out
[17:47] <broder> and including the key in the default keychain
[17:47] <maco> oh, cool, so what i just said
[17:47] <broder> let me go dig up the blueprint...
[17:48] <broder> http://summit.ubuntu.com/uds-o/meeting/foundations-o-dbgsym-integration/
[17:48] <broder> looks like...nobody ever actually turned it into a spec. hmm...
[18:27] <fowlduck> We have an Intel Xeon E5645 and we're not seeing the 2 threads per core in lscpu, cat /proc/cpuinfo, etc, despite the processor being capable of hyperthreading. Is there a way to determine what features are supported by the kernel? I'd like to check if hyperthreading is enabled but haven't a clue.
[18:27] <fowlduck> also, not sure if this is the appropriate place for this question
[18:29] <tgardner> fowlduck, hyper-threading is definitely enabled. what kernel  and HW are you using?
[18:31] <fowlduck> Intel Xeon E5645 and `uname -a` # => Linux 358015-domain 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[18:31] <mjg59> fowlduck: Your BIOS supports the processor?
[18:32] <mjg59> And put dmesg up somewhere
[18:32] <tgardner> yeah, this is likely a BIOS issue
[18:33] <fowlduck> http://pastie.org/private/hdib338al84ipuhgqetja
[18:33] <fowlduck> mjg59: I'm actually not even sure, we're using a bare-metal host that rhymes with shmackspace and don't have access to the BIOS 
[18:34] <mjg59> fowlduck: At a guess I'd say that hyperthreading is disabled in the bios
[18:34] <mjg59> The R710 should be new enough to handle those chips
[18:34] <tgardner> looks like a Dell Poweredge, and I know they are supported.
[18:35] <fowlduck> ok, great, we'll push this back to our host
[18:35] <fowlduck> thanks guys
[18:38] <tgardner> mjg59, fowlduck:     0.228857] Booting Node   0, Processors  #1 #2 #3 #4 #5
[18:38] <tgardner> [    1.126949] Brought up 6 CPUs
[18:38] <tgardner> [    1.126956] Total of 6 processors activated (28728.72 BogoMIPS).
[18:39] <mjg59> Yeah, that should mean that ACPI only gave us 6
[18:40] <tgardner> an R710 has 6 physical cpus ?
[18:40] <fowlduck> yep, it's a hex-core, so with HT it should show 12: http://ark.intel.com/Product.aspx?id=48768
[18:41] <tgardner> fowlduck, oh, 6 cores. I'm just a little slow today.
[18:42] <fowlduck> :)
[19:12]  * tgardner --> lunch
=== yofel_ is now known as yofel
[20:26]  * jjohansen -> lunch
=== Quintasan_ is now known as Quintasan
[20:51] <herton> tgardner: about that af_unix patch, after Eric responded I made this small testcase which that patch fixes: http://pastebin.ubuntu.com/630957/
[20:52] <herton> just in case it helps with something
[20:52] <herton> may be one of the applications lamont uses on that server has the same bug, recv before accept
[20:53] <herton> sconklin: ^^
[20:53] <tgardner> herton, looking...
[20:53] <sconklin> also looking
[20:54] <tgardner> herton, attach that to the bug with an appropriate explanation. I'd also summarize Eric's email about why the patch exists.
[20:54] <herton> ok
[20:55] <sconklin> It never occurred to me that doing a receive before accept could ever work in anything . . .
[20:55] <tgardner> herton, are you able to cause a kernel oops with that patch reverted ?
[20:55] <herton> testing here on natty worked, previous to 10.44
[20:55] <herton> on 10.44 it returns the ENOTCONN
[20:55] <sconklin> unless it's in some path that fails but another fallback path works
[20:55] <herton> tgardner: on my test machine it didn't oops
[20:55] <sconklin> oh, interesting
[20:57] <sconklin> Maybe cking knows whether SystemTap can be used to detect a userspace app that does this and point a finger
=== yofel_ is now known as yofel
[21:31]  * tgardner --> EOD