netdev - Re: [stable 2.6.32.y PATCH 0/6] net: fixes for cached dsts are never invalidated

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121019202244.GH8315@kvack.org>
Date:	Fri, 19 Oct 2012 16:22:44 -0400
From:	Benjamin LaHaise <bcrl@...ck.org>
To:	Willy Tarreau <w@....eu>
Cc:	David Miller <davem@...emloft.net>, stable@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [stable 2.6.32.y PATCH 0/6] net: fixes for cached dsts are never invalidated

On Fri, Oct 19, 2012 at 10:14:31PM +0200, Willy Tarreau wrote:
...
> So maybe in the end we should just merge d11a4dc18 that Ben found to be
> the least invasive one fixing the issues, and we'd be in sync with the
> rest of the stable branches, even if, as you noted a few days ago, it's
> only a partial fix for the issue.
> 
> Ben, what's your opinion on this ? I know it's never fun to do backports
> and not merge them later, but I trust David more than anyone else on the
> network part, so if he decided that while incomplete, the patch above
> was all that was needed for other stable branches, maybe we should just
> stay on the safe side and do the same ?

There is a caveat to the minimally invasive fix: doing so will result in 
cached routes always being lookup up when the check occurs.  This could 
potentially result in a performance regression from some users.  The 
tradeoffs here are really murky.

		-ben
-- 
"Thought is the essence of where you are now."
--
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