RE: [PATCH 6/7] aacraid: unlock around kfree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Cool! Thanks for the information! Sounds like the patch will be
necessary. However, I have never seen the issue bite us, but who knows,
it may be the contributor to a system lockup after 8000 hours of uptime
... I'd prefer the paranoid delusion and a stable system!

As for the GFP_ATOMIC, the intent is to move the kmalloc w/GFP_ATOMIC
from inside the loop to outside the loop and perform a guestimate+ on
the possible pool requirements of the loop. Since this is an independent
thread, there will be no need to use GFP_NOIO. The code has been tested
for almost a year now in the Adaptec branch, and the guestimate was
tweaked in that time to be 100% reliable.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: Arjan van de Ven [mailto:arjan@xxxxxxxxxxxxx] 
Sent: Thursday, August 04, 2005 7:48 AM
To: Salyzyn, Mark
Cc: linux-scsi; Mark Haverkamp; James Bottomley
Subject: RE: [PATCH 6/7] aacraid: unlock around kfree

On Thu, 2005-08-04 at 07:33 -0400, Salyzyn, Mark wrote:
> Good to know. I went through one too many code reviews and had no
> defense against the request.
> 
> There is a follow-up to this one not yet submitted to MarkH where I
> endeavor to pre-allocate with kmalloc(,GFP_ATOMIC|GFP_KERNEL) a pool
> before entering a locked list traversal rather than risking making the
> calls with the locks held. The code is in an independent kernel thread
> handling deferred actions triggered by the interrupt. Am I barking up
> the wrong tree?

why do you need the GFP_ATOMIC if you allocate outside all locks?
Yes the idea is the right one; do a sleeping alloc outside all locks,
instead of a far more fragile atomic alloc inside locks.

Note: if you don't want the allocation to cause IO (which could recurse
into your driver) you need to use GFP_NOIO not GFP_KERNEL; the
difference is important for avoiding recursion-deadlocks


-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux