On Thu, 2005-08-04 at 08:04 -0400, Salyzyn, Mark wrote:
> 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
H 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-a
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
7:07 PM
To: Mark Haverkamp
Cc: linux-scsi; Salyzyn, Mark
Subject: Re: [PATCH 6/7] aacraid: unlock around kfree
On Wed, 2005-08-03 at 15:39 -0700, Mark Haverkamp wrote:
> kfree has the possibility of sleeping. It is generally considered poor
> manners to hold on to a lock with the possibilit
On Wed, 2005-08-03 at 15:39 -0700, Mark Haverkamp wrote:
> kfree has the possibility of sleeping. It is generally considered poor
> manners to hold on to a lock with the possibility of a system call
> induced sleep.
Erm, this isn't true ... we'd have no end of driver issues if kfree
could block.
Received from Mark Salyzyn from Adaptec:
kfree has the possibility of sleeping. It is generally considered poor
manners to hold on to a lock with the possibility of a system call
induced sleep.
Applies to scsi-misc-2.6 git tree
Signed-off-by: Mark Haverkamp <[EMAIL PROTECTED]>
Index: scsi-misc-
6 matches
Mail list logo
