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 will
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
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 an old list with a
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
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.
