netdev - Re: [PATCH] ipvs: Fix race conditions in lblc scheduler

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LNX.1.10.0808181507070.12259@titan.stealer.net>
Date:	Mon, 18 Aug 2008 17:47:53 +0200 (CEST)
From:	Sven Wegener <sven.wegener@...aler.net>
To:	Simon Horman <horms@...ge.net.au>
cc:	netdev@...r.kernel.org, lvs-devel@...r.kernel.org,
	wensong@...ux-vs.org, ja@....bg
Subject: Re: [PATCH] ipvs: Fix race conditions in lblc scheduler

On Mon, 18 Aug 2008, Simon Horman wrote:

> On Mon, Aug 18, 2008 at 12:52:08AM +0200, Sven Wegener wrote:
> > We can't access the cache entry outside of our critical read-locked region,
> > because someone may free that entry. And we also need to check in the critical
> > region wether the destination is still available, i.e. it's not in the trash.
> > If we drop our reference counter, the destination can be purged from the trash
> > at any time. Our caller only guarantees that no destination is moved to the
> > trash, while we are scheduling. Also there is no need for our own rwlock,
> > there is already one in the service structure for use in the schedulers.
> 
> I need to look over these changes with a fresh set of eyes in the morning
> - sorry that I didn't do that earlier today.  I am very much in favour of
> the changes that we made last week, and this patch at least looks a lot
> like the changes we discussed.  Do you think these should be pushed
> into 2.6.27? Or perhaps even stable? They are real races, right?

The lblc patch is nearly identical to the last one posted. The lblcr is 
new, but follows the same logic.

They are real races, but are quite unlikely to hit. The lblc and lblcr are 
rarely used schedulers, because they only make sense in fwmark-based 
configurations. The chance of them causing major issues is unlikely, 
because for one you need to catch a destination that is in the trash and 
someone needs to purge it at the same time, which is only possible if that 
someone from user space is moving another destination to the trash and 
then the destination also needs to have all references dropped to be 
purgeable. And the other race is that removing a cache entry races with 
someone accessing that cache entry. For the normal expire time removal it 
means that someone has to access an entry, which hasn't been used for a 
long time. In the end I think it's not urgent to get them in.

Sven
--
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