=== bjf is now known as bjf[afk] [00:01] hey guys - just dropping in to ask about a bug [00:01] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/586897 [00:01] Launchpad bug 586897 in linux-2.6 (Debian) (and 2 other projects) "stex driver (Promise SuperTrak 8350/4650,etc) produces drastic I/O errors/corruption with 10.04 or later (affects: 3) (heat: 18)" [Unknown,Unknown] [00:02] there has been a fix committed to the kernel tree apparently - it's a fairly serious bug (as it's a fairly common card) and I'd just like to pass on the fact that it's fix now for possible backport to the lucid kernel and inclusion on new installation media for lucid(10.04.2) and natty [00:11] chrismsnz, do you have a link to the discussion or a SHA1 I can use? [00:12] the kernel discussion? [00:12] where they discussed the issue on the LKML [00:12] this was in linux-scsi: http://marc.info/?l=linux-scsi&m=129021716922966&w=2 [00:12] or a SHA1 of the fix as it exists in the kernel tree [00:13] i may have another one, stand by [00:14] here is lkml: http://www.linux-archive.org/device-mapper-development/459117-data-corruption-stex-promise-hw-raid-driver-device-mapper.html [00:14] ah, that actually looks like dm-devel D: [00:14] chrismsnz, looks like that is still an ongoing discussion [00:15] yeah [00:15] from the rest of the thread, this is still being discussed [00:15] sorry JFo: here is the actuall diff: http://marc.info/?l=dm-devel&m=129070330506836&w=2 [00:15] k [00:16] yeah, that is his proposed change [00:16] the conversation looks like they are trying still to determine the best way to address the problem [00:16] hmm [00:16] wait a sec... [00:17] nevermind [00:17] I read the patch wrong [00:17] :) [00:17] * JFo is tired [00:17] * jjohansen steps away for a bit === jjohansen is now known as jj-afk [00:18] chrismsnz, let me have a look at this tomorrow and I will see where it stands and talk to the team about its possible inclusion based on the current state [00:18] i can't see where it was committed :\ [00:18] okidoki - feel free to drop in on/update the bug there were a couple others watching it too [00:18] yeah, the last message in the thread seems to indicate it is still in flux [00:18] when you have some answers, I mean :) [00:19] http://marc.info/?t=129070303200002&r=1&w=2 [00:19] looking there ^ [00:19] ok [00:19] will do [05:20] Hi everybody ! [05:20] I've just received a new kernel update on my server [05:21] Someone could tell me how to print the changelog in a terminal ? [05:23] LOL... yeah ok.. aptitude changelog... I'm a bit a looser this night [05:23] sorry === LibertyZero is now known as _LibertyZero_ === smb` is now known as smb [08:50] * apw marvels at the funny white stuff falling from the sky [08:51] apw, Has it made its way to your place then? :) [08:51] * smb waits for messages of chaos from the island === jj-afk is now known as jjohansen [08:55] smb, yep, i expect we'll be closed before long [08:55] snow again, but they just had some last year [08:55] at least fibre works under water [08:56] jjohansen, this is _settling_ thoug [08:56] apw, The bits could freeze [08:56] heheh [08:56] apw, And did you not have the settling last year too? [08:56] my bits could freeze [08:56] smb, yeah we did, but this is the very first we've seen and its settling [08:57] Ah you mean with an inserted "this year" ;9 [08:57] :) [08:58] Though I try to remember when it was that I barely made it there in between strike and snow... [08:59] * smb remembers walking in the snow in London and he usually does not remember that long [09:04] * smb wonders whether cking can hear him through all that snow [09:05] smb, heh yea, /me goes out to see how deep it is [09:06] apw, Hope we see you again [09:12] 1 cm of snow here [09:12] cking, Wasn't it 1 inch a minute ago? :) [09:16] heh, my initial guess was inaccurate and based on defunct non-metric measurements [09:17] cking, Interesting question: do you think metric and convert or the other way round? [09:20] smb, I was educated in metric but I think in both imperial and metric and select the one that gives me best 1 unit measurements, e.g. if it's ~2.5cm, I call it an inch, if it's ~30cm I call it a foot, but if it's ~3 foot I call it a meter [09:24] apw: I'm looking at the kernel delta assigned to me - the nouveau noaccel quirking patches. We should drop those and see if anything breaks. [09:25] RAOF, He may still have some fun in the snow at the moment [09:26] Mmm, snow. [09:27] You know that strange pieces of fluffly frozen water [09:28] Not *all* of Australia is tropical or sub-tropical :P [09:29] We have such wonders in Tasmania, also. [09:30] smb, http://www.amd64.org/support/microcode.html [09:31] cking, ta [09:32] RAOF, Yeah, probably we always think of AUS as far far south. Must be hot there. :) [09:32] Heh. [09:52] * smb looks around for apw [10:04] RAOF, heh, i was going to ask you abut those tosay [10:04] had to pop to pick something up, which took longer than i imagined [10:05] seems its is slippy slidey out there under foot [10:05] apw, We were about to send the rescue team. :-P [10:06] smb, thanks :) [10:08] :) [10:08] RAOF, ok those are gone from the next upload [10:09] RAOF, we also have this one: UBUNTU: SAUCE: i915 -- disable powersave by default [10:09] i seem to remember that one was to stop some odd screen quivering we were seeing [10:09] Yeah. [10:11] want to think about that one with your X buddies and make a recommendation on it? [10:11] Sarvatt knows more about that; I'll ping him tomorrow. [10:12] RAOF, i have marked your task done for the ubuntu delta :) [10:12] Ta. [10:23] apw, Is there any way to get from the generic release status to the personal item summary? I fail to see it if there is [10:23] smb, there is not, i know of now way to get there. i tend to use the personal _bit_ of the overall burndown myself [10:24] smb, http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.html [10:24] and scroll down to your name (the second occurance) [10:24] apw, Cool. Actually, couldn't we just add that link to the natty links? [10:25] we might be able to i guess [10:25] apw, I can do that if it is ok with you [10:25] smb, i am not sure there is an overall cycle personal version, which seems wrong [10:27] apw, Oh actually it is there [10:27] smb, hmmm where ? [10:27] Just called "overall burndown chart" [10:27] Under milestonded features [10:27] stoned [10:28] oh that link is there yes, but i pointed you tot [10:28] to that one earlier ... [10:31] apw, Like a few minutes ago. :) But I could not even guess from the title that this is the team based list. And yes, you seem to have sent me a link to a personal burndown page as well which seems to be produced by the same stuff. now I just need to find how to get there [10:33] there are no links to the u/ prefixes as far as i know yet, i wonder why the names in the main pages do not go there [10:33] i may propose changing those links to that [10:33] Yeah, that would be more helpful than the launchpad blueprint assignment page [10:38] apw, One thing to improve imo would be to include the previous tasks at least in the overall page (which is naturally named ubuntu-11.04 instead of natty *grrr*) [10:39] ubuntu-11.04 is not overall, it is the stuff for the release milestone [10:39] stuff milestoned after the beta [10:39] there seems to be a missing global one under just your name which there in the other views [10:39] the u/ stuff is very new, and a little broken i think [10:40] Ah ok. === ogra_ac_ is now known as ogra_ac [10:51] apw, i guess you have seen cooloney's mail [10:52] ogra_ac: i've talked with apw already, heh [10:52] (i dont expect any other outcome from our tests to be honest) [10:52] ah cool [10:52] i just want to know whats the way forward now that we have positive results [10:52] ogra_ac: i might need a xM machine for testing. [10:52] ogra_ac, indeed [10:52] ogra_ac: i just have a beagle c3 [10:53] ogra_ac, i really have little idea of the scope of omap3, ie what boards you expect it to work on other than beagle [10:53] cooloney, i actually expect their kernel to run better on XM [10:53] ogra_ac, to put it another way i am not sure what our acceptance criteria will be [10:53] apw, well, we can only put one bootloader into the images by default anyway [10:54] so i would expect beagle to be the default and for others we might provide u-boot binaries that you can easil exchange on the created SD card [10:55] apw, i would keep the supported set of boards as narrow as we can, everything you can do additionally through replacing bootloaders would be optional and unsupported (also untested) by us [10:55] ogra_ac, so it is fair to say that 'works on beagle satisfactorly' is the criteria [10:55] yes [10:55] ogra_ac, ok cool, is someone from your side going to try the swapping in of this kernle into the CD image and give it a test ? [10:56] there are requirements for IGEP2 boards, buit imho thats really up to linaro (i.e. if it works at release time its fine, i wouldnt do SRUs for them) [10:56] apw, as soon as we a) have images again and b) gruemaster has his setup ready [10:56] i'll bring it up in the arm IRC meeting today [10:56] ogra_ac, excellent, did the meta shenaegens sort you out image wise [10:57] partially [10:57] there are other packages blocking atm [10:57] we have a bunch of dektop packages that depend on kde which currently doesnt build at all on arm [10:57] s/depend/build depend/ [10:58] we're sorting that remaining stuff this week [10:58] ogra_ac, thats a little annoying, i wonder why we'd want to install kde requiring apps by default on the gnome images [10:58] ogra_ac, but the kernel is out of your way [10:58] *build depend* ... we dont install any kde stuff [10:59] but i.e. transmission builds a kde client from the same source [10:59] ogra_ac, ahh i see, now that does make sense [10:59] so it is ftbfs currently because kdelibs doesnt exist [10:59] i will unseed it from our image for A1 [10:59] similar stuff happens to ubuntuone [11:00] such is the life of an A1 CD [11:00] heh, yeah [11:07] apw: how can I get the source for this kernel? (the source package is empty): http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.11-lucid/ [11:08] tseliot, that is not easy, back there the source packages were broken, later we have included the patches so you can recreate it more easily [11:09] i may have the branch in the repository though [11:09] the master source for it would be v2.6.32.11 from the stable tree of course [11:09] tseliot, what do you need to use it for, so i can work out what the best way to help you is [11:10] apw: a friend of mine needs the sources for that vanilla kernel with the ubuntu packaging scripts [11:13] tseliot, ok i've pushed the patches that are on that branch into the result directory like the later versions [11:13] so he'd need v2.6.32.11 and then apply the 4 patches there [11:14] apw: what branch is that? [11:15] tseliot, ignore the branch, the builder leaves some mess arround for debugging which i looked at is all [11:15] i've pushed the delta to the results directory [11:17] apw: ah, ok, so he should get the vanilla kernel from upstream and apply those patches. Thanks [11:19] tseliot, yes that is exactly what the build system does, well it generates the patches but you get the idea [11:19] apw: I've learnt something new :) [11:20] tseliot, some of the older ones are missing the patches cause we thought the source packages were useful, but they arn't and actually the patches are simpler so we switched over relativly recently [11:21] if i have the build branches i can convert an old result, as i have for this one, but its not worth the effort unless someone whines [11:22] apw: yes, I agree [11:54] apw: cooloney: ogra_ac: I have a beagle-xm and can test if everything works fine [11:54] but it should, as it's already being used by linaro's image [11:54] rsalveti, that would be helpful [11:54] rsalveti: great, man [11:54] we need to know if jasper behaves etc [11:54] if they are merging the ubuntu sauce on top of the tree, it should work basically the way we're expecting [11:54] thats a part that cooloney cant test with rootstock images [11:54] rsalveti: yeah i think so. [11:55] cooloney: did you change the config or used the default one? [11:55] rsalveti: it contains all the ubuntu delta sauce patches [11:55] rsalveti: i didn't change any code in there tree. [11:55] rsalveti: it just works [11:55] ogra_ac: we can easily test with jasper at the moment we have any image around [11:55] then we can just replace the important pieces and we're ok [11:55] rsalveti: you can build it from their source code. [11:55] cooloney: cool [11:56] cooloney: sure [11:56] rsalveti, there are images from the 19th [11:56] cooloney: would be good to compare the config options with our omap3 debs [11:56] for jasper testing that should suffice [11:56] (i think X wont start on these though) [11:56] ogra_ac: cool, if nothing that important changed since then, I think we're ok [11:57] ok, np [11:57] rsalveti: yeah, will do it soon. [11:57] but it should work basically the same way, don't expect much of new features, but new bugs could be around :-) [11:57] they merged most of our omap specific patches and ubuntu sauce [11:59] ogra_ac: and for now let's just produce beagle compatible images, should be enough for most omap 3 boards around [11:59] beagle and beagle xm should work with same kernel and boot loader [11:59] then for igep we just build instructions, should be fine [12:00] yes [12:00] thats what i said above [12:00] with beagle being the QAed and officially supported platform [12:02] yeah [12:03] what we need to make sure is that john doesnt cut down the config [12:03] (i know he planned to) [12:04] otherwise we need our own config [12:04] i.e. we want all usb dvb drivers, all usb wlan drivers etc etc [12:04] everything you could potentially plug in [12:13] Darn, channel is logged? Where is my privacy? :P [12:14] OK .. joke aside ... [12:15] I'm on Ubuntu GNU/Linux. Today my updatemanager tells me to upgrade kernel for security reasons. CVE-2010-3848, CVE-2010-3849 and CVE-2010-3850 ... but these are only proposed .. and secret (reserved) .. anyone know about those? [12:15] Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848) [12:15] Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3849) [12:15] Dabian: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3850) [12:15] ubot2: Thats what I am say'in, d'oh! [12:15] Dabian: Error: I am only a bot, please don't think I'm intelligent :) [12:15] I dont, lol. :) [12:16] better patched than vulnerable? [12:16] maco: Question is .. vunerable to what? [12:16] Usually I like to know what kinda patches I'm installing. :) [12:16] you could view the source [12:17] get the current and previous source packages off of launchpad and diff them [12:17] Can I apt-source a vunerable package? [12:17] or look at the git trees on kernel.ubuntu.com [12:17] apt-get source package=version [12:17] the latter looks more convenient, I guess git trees have diff? [12:18] yep [12:20] maco: Do you know where I find the main branch? [12:20] the one thats named ubuntu.maverick or ubuntu.lucid (whatever you're on) would be it [12:20] maverick is the perfect ten, right? [12:21] with no developers' names attached [12:21] yeah [12:22] There is no developer named "ubuntu"? [12:22] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=summary [12:22] right just found it [12:22] Leann is also mentioned as the last comitter. [12:23] hmm .. bad Leann .. using goto :P [12:24] :D [12:25] Hmm .. I dont understand why he doesn't make the check earlier in the code? [12:26] he who what? [12:26] Leann .. when he patch this. [12:26] He might have a good reason, I'm not expirienced kernel developer. [12:26] er..."leann" is a woman's name [12:27] In russia? [12:27] no, she's not russian [12:27] OH .. cool, we have female kernel-devs now? B) [12:27] yeah...theyve existed for a long while... [12:28] Cool [12:28] im a lady with a patch in the kernel too :P [12:28] Neat :) [12:28] Ahh .. Mackenzie :) [12:29] I think I recognice your name from Ubuntu-Women? :) [12:29] yes [12:29] i imagine she checks it there in order to keep the check near the reason its needed... ie, the fact that saddr is about to show up on the right side of an = [12:29] Its been a while since I have been active there. (As if I were ever active there, but I used to follow the mailing-list some) [12:30] maco: Yeah .. the code seems a bit bit complicated though .. I think I'll copy it to emacs to get a better view. [12:34] maco: Funni thing is ... there is already a check in the code for saddr. [12:34] Oh .. now I get it .. its legal to call this with saddr that is NULL. [12:36] Thats probably why she doesn't check earlier. [12:39] the other time in that struct that saddr shows up to the right of a = is inside a if (saddr == NULL) {} else { /* right here */ } -- so that one is checked [12:39] s/struct/function/ cant read [12:41] hm though line 506... [12:42] yeah [12:43] ogasawara: when you're around, is there a possibility of a null-pointer dereference down at line 506 on [ubuntu/ubuntu-maverick.git] / net / econet / af_econet.c like the one you fixed up above it? === jjohansen is now known as jj-afk [12:48] maco: I fear you might be right, if CONFIG_ECONET_NATIVE is not defined, then Leanns check is never passed. [12:50] maco: (Otherwise we return in line 414) [12:50] her check takes place inside an if() anyway [12:50] Yeah .. if the that if is false, then CONFIG_ECONET_NATIVE wont be defined. [12:51] I am babling. [12:51] CONFIG_* comes from outside [12:51] Its the if that is deciding, you're right. [12:51] hmm? the define takes place elsewhere [12:51] But if the if is false, her check is skipped. [12:51] im referring to this: if (dev->type == ARPHRD_ECONET) [12:51] maco: Exactly .. thats the culpit. :) [12:52] the null pointer dereference she catches is inside that if. there's another case of that pointer being used after the if ends. thats teh one im worried about [12:52] maco: just before the #if. [12:52] (Which is not significant here) [12:52] maco: Right. [12:52] i dont know where youre looking now... [12:52] maco: I just confused both of us, I agree with you. :) [12:53] hah ok [12:53] apw: down at line 506...is that one ok? [12:53] apw: or were you just interjecting about the macros without looking at what we are? [12:54] maco: He was just pointing out that I was babbling, I think. :) [12:54] ze :) [12:54] you got it right this time [12:54] lol [12:54] Dabian's statement was that the CONFIG_ would change based on an if, which doesn't sound right, not looked at the code no [12:55] I have no idea what ARPHRD is. :) [12:55] apw: oh ok. i think Dabian just mixed up #ifdef and #define [12:55] apw: You're right. I confused the #if with the "if". [12:55] ah [12:56] Well, actualy I assumed that both if and #if would act the same, which is even worse, lol. [12:59] If the #if is false [13:00] ahh never mind. [13:02] maco: I think you found a problem, unless we know that if saddr == NULL then udpsock == NULL. [13:02] Dabian: the line im pointing to is not inside an if statement at all [13:03] maco .. no [13:03] maco but look at line 420 [13:03] maco: I assume that line has to be passed before you reach line 506 [13:03] ah because it returns [13:03] :) [13:04] But I am not sure we know that udpsock is NULL, if saddr is NULL. [13:04] I'm not a kernel developer. [13:05] I just find it interesting to look at the code sometimes. :) [13:08] maco: In any case, I would probably do something like: [13:08] eb = (struct ec_cb *)&skb->cb; [13:08] if(saddr == NULL) [13:08] kernel_panick("Line 506, af_econet - saddr == NULL"); [13:08] [13:08] before "eb->cookie = saddr->cookie;", just to be sure. [13:08] (Not sure of the syntax for kernel_panic). [13:14] maco: To me it looks like udpsock comes from outside the function, so I am guessing you found a real problem. [13:16] saddr, on the other hand, comes from "msg->msg_name" which is passed as argument to the function, in line 266. [13:26] sconklin, you might want to review this above conv as it may indicate a further issue with one of our CVEs [13:28] apw: Nice that ARM is better secured than other platforms for once though, right? :) [13:28] apw, ogasawara was driving those. But yes, all of those did touch econet [13:28] But no arm release was done [13:28] Dabian, heh yeah by mostly being unbootable on any actual h/w :) [13:28] lol [13:29] Dabian, The whole conversation is too big to quickly read. Is what you see on arm or something else? [13:30] smb: It was maco that pointed out that line ... (lemme check) might lead to null-pointer problem. [13:30] smb: line 506 on http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=net/econet/af_econet.c;h=174c106ec95ac04a0c46a3cf8cf5d499bdfe390a;hb=00a70d00666bbe8e7035f582ac5674827e351870 [13:30] Thanks :) [13:31] smb: further up at 357 ogasawara checked for null before dereferencing that saddr pointer. at 506 it's dereferenced again without a null check. the first null check took place inside an if though, so may not have been run when 506 is reached [13:32] (And 506 is apparently reached, unless udpsock is NULL). [13:32] maco, Sounds about right. I just need a minute to grab the changes to have the whole picture [13:32] (udpsock seems to be external) [13:33] I was just wondering about the arm statement [13:33] smb: i think Dabian is watching -meeting [13:33] and my brain refuses to keep the two smb's straight -_- [13:33] There is only one on my side. :) [13:34] smb: The first check, which is committed, only concerns platforms with ARM hardware, I guses, according to the "#IF". [13:34] What is -meeting? [13:34] different channel [13:34] Dabian: can you use line numbers? [13:34] Dabian, Ah, well arm was those topic branches not released (at least for Lucid, but there is Maverick with at least one arm inside the master) [13:35] Sure. === doko_ is now known as doko [13:35] smb: But the problem maco points out, applies to all platforms, as far as I can tell. [13:35] there are 3 places saddr is used. 315, 362, 506 [13:36] what makes you think any of them are arm-specific? [13:36] maco: Lemme find the line number. I might be wrong though. :) [13:37] line 341: #ifdef CONFIG_ECONET_NATIVE [13:37] [13:37] I think only ARM has native econet? [13:37] oh. no idea about that [13:37] I am just guessing. [13:38] maco: Line 506 is outside that "if" though. [13:38] (#if, even) [13:38] yes [13:39] So while Leanns fix maybe applies to ARM only, yours is general. [13:39] Its inside the line 417: #ifdef CONFIG_ECONET_AUNUDP [13:39] [13:41] Actually I do not really see that line which does not check for NULL getting added. Rather seemed to be there before [13:41] smb: 506 [13:41] But its a bit hard from the patch and a function that stretches on for miles [13:41] smb: yes it was thre before. she added a check for near line 357, and im worried that she should also have added one to 06 [13:41] *506 [13:42] smb: Yeah .. the code is pretty long, I wonder if the function could be refactored. [13:43] maco, Maybe. I am not that good to understand the flow that quickly. :) [13:43] Give me a minute [13:44] Dabian, not for a backported fix, minimum changes only [13:45] smb: Its actually not as hard as you think. The problem is if the "if" at line 339 is false (dev->type != ARPHRD_ECONET), then code-flow skips Leanns check in line 358, and if udpsock != NULL (checked in line 420), the code will hit line 506, with a possible null-value in saddr. [13:46] (Assuming the "#ifdef"'s allow it). [13:46] its just a single C function thats got as many lines as my senior project did of python :P [13:48] apw: Right .. but maybe an idea for development branch. :) [13:48] So ok, yes, for that other case /#ifdef it seems missing [13:49] But has so before [13:49] smb: Which doesn't make it right, though. :) [13:49] Nope [13:49] The question is just whether it is in the class of security oh my god [13:49] I think maco found a new problem, of same natuer. [13:49] or just "normal" it crashes [13:50] smb: from leann's commit message on her change it seems like a normal-it-crashes with unknown security implications [13:50] maco, The thing is that all three were passed down as a bundle of sorts [13:51] 3 cve's though? [13:51] maco, You found a true other case of brokeness. I just would avoid a security update for it if possible [13:51] ok [13:51] Which would be required if we broke something new [13:52] so how to handle discovery of brokenness? [13:52] smb: When crashing and network is involved .. I'd say we're close to a security issue. Question is if its remotely exploidable, I guses? [13:52] Dabian, Right. I would not be sure at the moment. [13:53] On the other hand that econet protocol is not loaded by default and I don't know the use of it either. [13:53] maco, I'd probably go and contact the original author about it [13:54] smb: Then again, i guess even if its only locally exploitable, it will still be security issue, unless you need priviledges to call the function. [13:54] Err [13:54] Which was in this case Leann. [13:54] heh [13:55] Guess she sent that somewhere. So maybe we ask her where === yofel_ is now known as yofel [14:01] maco, smb: Just wandering in . . . econet is essentially unmaintained, so these patches were arrived at through a group effort [14:01] maco, sconklin Ijust checked Linus upstream. [14:02] Seems that what went there is different and exists early [14:02] Instead of checking for NULL multiple times [14:04] Heh .. that was my original idea, to exit early. [14:04] But I don't know what the code actually does. [14:05] It seems like its possible to do "something" useful, even if saddr is NULL, but I am not sure what. [14:06] smb: I guess that explains why the code missed the check later in the code. [14:06] i was guessing it was more to do with the spaghetti... [14:06] Dabian, I think (but I cannot say for sure) that we may have a patch that evolved later before hitting upstream [14:08] "a patch that evolved later, before hitting upstream"? (Im not native english, what does this mean?) [14:09] Dabian, It means it changed [14:09] And in Linus tree there is a different change that we have now [14:09] smb: As in .. you made a patch, but changed it before shipping it upstream? [14:10] As in we got the patch from someone (at least the other two) and maybe found the issue and told it the other person and on the way to upstream it changed even more but nobody told us [14:10] We just now see it in Linus tree [14:11] Ahh ok ... so .. you got Linus.A code .. patched it to Linus.Ap1 .. sending it upstream, when Linus.B code is available, the changes dosen't match the Linus.Ap1 code. [14:12] Hmm .. I guess this means we have to check the Linus.B code, to see if it checks correctly? [14:12] and if it does, then eventually adopt it? [14:13] As far as I see it is safer as it does the check right at the beginning of the function and immediately returns with an error if saddr is NULL [14:14]