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.0808190128260.12259@titan.stealer.net>
Date:	Tue, 19 Aug 2008 01:38:42 +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 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.

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