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] [day] [month] [year] [list]

Message-ID: <20080819074515.GC4387@verge.net.au>
Date:	Tue, 19 Aug 2008 17:45:16 +1000
From:	Simon Horman <horms@...ge.net.au>
To:	Sven Wegener <sven.wegener@...aler.net>
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 Tue, Aug 19, 2008 at 01:38:42AM +0200, Sven Wegener wrote:
> On Tue, 19 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.
> > 
> > this looks good to me. I have confirmed that it applies against lvs-2.6
> > (but not net-2.6 as changes that are already in lvs-2.6 are needed).
> 
> Yes, I've based it on your tree.
> 
> > One minor style question.  You have changed struct ip_vs_lblc_table to *tbl
> > in several places, (e.g. sizeof(*tbl) ). I think that I prefer things the
> > way that they were. Was there a reason for this change?
> 
> In this patch series, no. I prefer them like sizeof(*tbl) as it's more 
> robust, when changing the type of tbl. Changing the type of tbl and 
> forgeting the sizeof() in kmalloc will result in hard to track down bugs, 
> if the old type is still valid. Using sizeof(*tbl) will nearly always get 
> you the correct value you want, without keeping all the types in sizeof() 
> in sync. The compiler already knows the type of tbl, so no need to be 
> explicit about it, when allocating memory for it.

Hi Sven,

sorry about the noise on this. I have applied it to lvs-2.6.

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