On Tue, 16 Sep 2008 11:13:13 +0200 Thomas Klein <[EMAIL PROTECTED]> wrote:
> Sebastien Dugue wrote:
> > On Mon, 15 Sep 2008 17:18:27 +0200 Thomas Klein <[EMAIL PROTECTED]> wrote:
> >
> >> NACK!
> >>
> >> I regret but this patch is wrong. It is not sufficient to only lock
> >> the replacement of a
Sebastien Dugue wrote:
On Mon, 15 Sep 2008 17:18:27 +0200 Thomas Klein <[EMAIL PROTECTED]> wrote:
NACK!
I regret but this patch is wrong. It is not sufficient to only lock
the replacement of an old list with a new list. Building up those
lists is a 3-step process:
1. Count the number of entri
On Mon, 15 Sep 2008 17:18:27 +0200 Thomas Klein <[EMAIL PROTECTED]> wrote:
> NACK!
>
> I regret but this patch is wrong. It is not sufficient to only lock
> the replacement of an old list with a new list. Building up those
> lists is a 3-step process:
>
> 1. Count the number of entries a list wi
NACK!
I regret but this patch is wrong. It is not sufficient to only lock
the replacement of an old list with a new list. Building up those
lists is a 3-step process:
1. Count the number of entries a list will contain and allocate mem
2. Fill the list
3. Replace old list with updated list
It's
Sebastien Dugue wrote:
Looks like to me that the ehea_fw_handles.lock mutex and the
ehea_bcmc_regs.lock spinlock are taken much longer than necessary and could
as well be pushed inside the functions that need them
(ehea_update_firmware_handles() and ehea_update_bcmc_registrations())
rather than
Looks like to me that the ehea_fw_handles.lock mutex and the
ehea_bcmc_regs.lock spinlock are taken much longer than necessary and could
as well be pushed inside the functions that need them
(ehea_update_firmware_handles() and ehea_update_bcmc_registrations())
rather than at each callsite.
Signe
