lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 11 Apr 2008 09:40:08 +0300 (EEST) From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> To: Mark Lord <lkml@....ca> cc: David Miller <davem@...emloft.net>, jesper.juhl@...il.com, tilman@...p.cc, yoshfuji@...ux-ipv6.org, Jeff Garzik <jeff@...zik.org>, rjw@...k.pl, LKML <linux-kernel@...r.kernel.org>, Netdev <netdev@...r.kernel.org> Subject: Re: 2.6.25-rc8: FTP transfer errors On Thu, 10 Apr 2008, Mark Lord wrote: > David Miller wrote: > > From: Mark Lord <lkml@....ca> > > Date: Thu, 10 Apr 2008 20:27:14 -0400 > > > > > It's *your* bug -- you signed off on the commit. > > > > I sign off on basically every networking commit, does that mean I have > > to fix every networking bug and every networking bug is "mine"? > .. > > Absolutely, though to a varying degree. That's the responsibility > that goes with the role of a subsystem maintainer. I once had > such a role, and gave it up when I felt I could no longer keep up. > You still keep refering to it as "your (my) bug". > It's not. I had nothing to do with it, other than stumbling over it. This bug is perfect example where bisect clearly was useful :-). Nobody knew whose bug it actually was until your bisect gave directions. > When people stumble over a libata bug, I look hard to see if my code > could possibly cause it. Jeff looks even harder, because he's the > current subsystem dude for libata. > > I never suggest a user search through a mountain of unrelated commits > for something I've screwed up on. But it is ok for you to ask an innocent net developer to do that (even with your terms as I hadn't signed off _anything_ related to that one), hmm? ...You had this pretty demanding tone earlier: > Or I can ignore it, like the net developers, since I have a workaround. > And then we'll see what other apps are broken upon 2.6.25 final release. > > Really, folks. Bug reports are intended to *help* the developers, > not something to be thrown back in their faces. > > There do seem to have been a *lot* of changes around the tcp closing/close > code (as I see from diff'ing 2.6.24 against latest -git). > > *Somebody* is responsible for those changes. > That particular *somebody* ought to volunteer some help here, > reducing the mountain of commits to a big handful or two. ...and also... > > Anyways, here's five hours of free consulting for you ...Sure I could use similar words, but you might use the not-mine bug approach again to deflect... :-( ...No, I don't mind really :-). I well understand that I occassionally end up chasing things which are bugs that other people have caused, that's part of the game. > I give more directed help, patches to collect more relevant information, > and patches to try and resolve it. Now that you have, as stated earlier, first looked the diffs (tcp*.c stuff mainly I suppose?!?), and the bisected it and found the breaker, and even patch is available already... Seriously, knowing all what's now available, how could we have solved _this particular case_ without that very useful help (bisect) from your side? Yes, I went through the commit list (maybe you did as well), I'm not sure if Dave did as well. In addition, I checked a number of individual diffs too but this just isn't something very obvious (I have to admit though that I don't really understand all those namespace things, so I didn't even know how to look them too carefully). -- i. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists