* [uml-devel] GFP_ATOMIC/GFP_KERNEL broken for use by block devices!!
@ 2005-10-22 16:38 Blaisorblade
2005-10-24 23:03 ` [uml-devel] " Jeff Dike
0 siblings, 1 reply; 3+ messages in thread
From: Blaisorblade @ 2005-10-22 16:38 UTC (permalink / raw)
To: Jeff Dike; +Cc: user-mode-linux-devel
Jeff, remember I asked you not to merge the UBD rewrite for now? Well, I found
one more (and bigger) reason for it, though I don't understand it fully.
Quoting from Arjan Van der Ven, "How not to write kernel driver":
In the write path of a filesystem, using
GFP_KERNEL or GFP_ATOMIC will lead to deadlocks
eventually. [...] GFP_NOFS is there for a reason, as is GFP_NOIO for block
device drivers.
Though there's no explaination of this, I can guess that GFP_KERNEL could
cause the kernel to enter the same (or another, but that shouldn't matter)
block device to free some memory. Not sure what's the problem with GFP_ATOMIC
though.
However, GFP_NO{FS,IO} both imply !ATOMIC (they include __GFP_WAIT), so we
cannot use any of them for our purposes.
Which means that we _must_ ask for help from somebody else.
Anyhow, before merging the patches I'd _really_ like if they were reviewed by
somebody as Jens Axboe or the such, afterwards merged to -mm, and only after
that merged into mainline.
Please, send some feedback on this email as soon as you read - think to
replacing UDP with TCP, ok ;-) ?
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* [uml-devel] Re: GFP_ATOMIC/GFP_KERNEL broken for use by block devices!!
2005-10-22 16:38 [uml-devel] GFP_ATOMIC/GFP_KERNEL broken for use by block devices!! Blaisorblade
@ 2005-10-24 23:03 ` Jeff Dike
2005-10-24 23:30 ` Blaisorblade
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Dike @ 2005-10-24 23:03 UTC (permalink / raw)
To: Blaisorblade; +Cc: user-mode-linux-devel
On Sat, Oct 22, 2005 at 06:38:16PM +0200, Blaisorblade wrote:
> In the write path of a ???lesystem, using
> GFP_KERNEL or GFP_ATOMIC will lead to deadlocks
> eventually. [...] GFP_NOFS is there for a reason, as is GFP_NOIO for block
> device drivers.
I know about this, and this is another reason I'm not sending it in. I
don't really understand it either. If GFP_ATOMIC can block, then I don't
know what good it is.
> Which means that we _must_ ask for help from somebody else.
Yup.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* [uml-devel] Re: GFP_ATOMIC/GFP_KERNEL broken for use by block devices!!
2005-10-24 23:03 ` [uml-devel] " Jeff Dike
@ 2005-10-24 23:30 ` Blaisorblade
0 siblings, 0 replies; 3+ messages in thread
From: Blaisorblade @ 2005-10-24 23:30 UTC (permalink / raw)
To: Jeff Dike; +Cc: user-mode-linux-devel
On Tuesday 25 October 2005 01:03, Jeff Dike wrote:
> On Sat, Oct 22, 2005 at 06:38:16PM +0200, Blaisorblade wrote:
> > In the write path of a ???lesystem, using
> > GFP_KERNEL or GFP_ATOMIC will lead to deadlocks
> > eventually. [...] GFP_NOFS is there for a reason, as is GFP_NOIO for
> > block device drivers.
>
> I know about this, and this is another reason I'm not sending it in.
I didn't know and you didn't mention, so I thought I'd better add about this.
> I
> don't really understand it either.
> If GFP_ATOMIC can block, then I don't
> know what good it is.
I _don't_ think it can block. I understand why GFP_KERNEL is broken there, but
not why GFP_ATOMIC can't be used. The only pointer I found so far is that
__GFP_HIGH allows the kernel to use up more memory without doing reclaim (see
mm/page_alloc.c, calls to zone_watermark_ok).
> > Which means that we _must_ ask for help from somebody else.
>
> Yup.
>
> Jeff
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-10-24 23:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-22 16:38 [uml-devel] GFP_ATOMIC/GFP_KERNEL broken for use by block devices!! Blaisorblade
2005-10-24 23:03 ` [uml-devel] " Jeff Dike
2005-10-24 23:30 ` Blaisorblade
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.