[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080617175535.638e54c5@linux360.ro>
Date: Tue, 17 Jun 2008 17:55:35 +0300
From: Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To: Mathieu Desnoyers <compudj@...stal.dyndns.org>
Cc: Jens Axboe <jens.axboe@...cle.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Tom Zanussi <tzanussi@...il.com>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, righi.andrea@...il.com
Subject: Re: [PATCH 2/3] relay: Fix race condition which occurs when reading
across CPUs.
On Tue, 17 Jun 2008 09:50:31 -0400
Mathieu Desnoyers <compudj@...stal.dyndns.org> wrote:
> Yeah, although using set affinity with CPU hotplug is broken by
> design.
>
> Mathieu
Never thought about this, but it does make sense. I presume this
affects relay reading as well, right? Quote from sched_setaffinity(2):
> EINVAL The affinity bit mask mask contains no processors that are phys-
> ically on the system, or cpusetsize is smaller than the size of
> the affinity mask used by the kernel.
We have 2 situations:
1. CPUs do _not_ get reordered --- the mask is then invalid, will it be
invalidated by the kernel even if set prior to the hotplug event?
2. CPUs get reordered after hotplug events. Assume this ([CPU logical <physical>]):
CPU 0 <0>, CPU 1 <1>, CPU 2 <2> => CPU 0 <0>, CPU 1 <2>
relay filenames likely change, but the underlying fds are preserved.
If the threads get migrated, this means we end up reading cross-CPU, AFAICS.
Do we ignore this and hope no one uses relay apps while triggering CPU
hotplug events?
Eduard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists