From: Blaisorblade <blaisorblade@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Andrew Morton <akpm@osdl.org>,
torvalds@osdl.org, jdike@addtoit.com,
linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] Re: [PATCH 07/10] uml: avoid fixing faults while atomic
Date: Thu, 22 Sep 2005 21:37:41 +0200 [thread overview]
Message-ID: <200509222137.41412.blaisorblade@yahoo.it> (raw)
In-Reply-To: <20050921134724.52603016.akpm@osdl.org>
On Wednesday 21 September 2005 22:47, Andrew Morton wrote:
> Blaisorblade <blaisorblade@yahoo.it> wrote:
> > On Wednesday 21 September 2005 21:49, Andrew Morton wrote:
> > > "Paolo 'Blaisorblade' Giarrusso" <blaisorblade@yahoo.it> wrote:
> > > > From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
> > > It has accidental side-effects,
> > > such as making copy_to_user() fail if inside spinlocks when
> > > CONFIG_PREEMPT=y.
> > Sorry, but should it ever succeed inside spinlocks? I mean, should it
> > ever call down() inside spinlocks? (We never do down_trylock, and ever if
> > we did the x86 trick, that wouldn't make the whole thing safe at all -
> > they still take the spinlock and potentially sleep. And it's legal only
> > if no spinlock is held).
> Not sure what you're asking here.
> copy_to/from_user() will fail inside spinlock if CONFIG_PREMPT=y and if the
> copy happens to cause a fault.
> Otherwise it will succeed inside spinlock,
> and it won't spew a sleeping-while-atomic warning, because that uses
> in_atomic() too.
> It might deadlock if we schedule away and try to retake
> the same lock.
Exactly - the point is: is it legal to call copy_from_user() while holding a
spinlock (which is my original question)? Or should copy_from_user try to
satisfy the fault, instead of seeing in_atomic() or something similar and
fail?
>From what you say, copy_*_user is called in such a way, but it's
deadlock-prone, when CONFIG_PREEMPT is disabled.
> > Even if spinlocks don't always trigger in_atomic() - which means that
> > we'd need to have a better fix for this.
> The patch you have will correctly cause copy_*_user()->pagefault to fail
> the copy if the caller has run inc_preempt_count(). It will not cause
> copy_*_user()->pagefault to fail inside spinlocks unless UML does
> inc_preempt_count() in its spinlock implementation.
No, it doesn't. But for that case, we're in the same situation as i386.
Consider even that while UML doesn't implement PREEMPT (but we'll fix that,
sooner or later) it does implement HIGHMEM, and answering to your original
question:
> So I think this change is only needed if UML implements kmap_atomic, as in
> arch/i386/mm/highmem.c, which it surely does not do?
Apart that anybody would make sure that atomic kmaps are indeed atomic, UML
doesn't use a "similar implementation" - it verbatim symlinks the i386 file
and builds it (see arch/um/sys-i386/Makefile and
arch/um/scripts/Makefile.rules if you want).
Hmm, that's something worth considering... at least when debugging is enabled,
for debugging purposes.
> > NACK, see above.
> Yup, the patch is needed for the futex code,
> and for general correct
> implementation of inc_preempt_count()'s intended effect.
Ok, that's enough I guess (and I just read what Linus said).
--
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
next prev parent reply other threads:[~2005-09-22 19:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 17:23 [PATCH 0/10] "Bigger" UML fixes for 2.6.14 Blaisorblade
2005-09-21 17:27 ` [PATCH 01/10] uml: don't remove umid files in conflict case Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 02/10] strlcat: use for uml umid.c Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 03/10] uml: don't redundantly mark pte as newpage in pte_modify Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 04/10] uml: fix hang in TT mode on fault Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 05/10] uml: fix condition in tlb flush Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 06/10] uml: run mconsole "sysrq" in process context Paolo 'Blaisorblade' Giarrusso
2005-09-21 20:50 ` [uml-devel] " Jeff Dike
2005-09-22 19:20 ` Blaisorblade
2005-09-22 20:37 ` Jeff Dike
2005-09-22 20:48 ` Blaisorblade
2005-09-23 7:40 ` Andrew Morton
2005-09-23 13:33 ` Jeff Dike
2005-09-25 21:34 ` Paul Jackson
2005-09-21 17:29 ` [PATCH 07/10] uml: avoid fixing faults while atomic Paolo 'Blaisorblade' Giarrusso
2005-09-21 19:49 ` Andrew Morton
2005-09-21 20:22 ` [uml-devel] " Blaisorblade
2005-09-21 20:47 ` Andrew Morton
2005-09-22 19:37 ` Blaisorblade [this message]
2005-09-22 19:58 ` Andrew Morton
2005-09-22 20:54 ` Linus Torvalds
2005-09-21 20:29 ` Linus Torvalds
2005-09-21 17:29 ` [PATCH 08/10] uml: Fix GFP_ flags usage Paolo 'Blaisorblade' Giarrusso
2005-09-21 19:19 ` Bill Davidsen
2005-09-21 20:52 ` [uml-devel] " Jeff Dike
2005-09-21 17:29 ` [PATCH 09/10] Uml: use GFP_ATOMIC for allocations under spinlocks Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:29 ` [PATCH 10/10] uml: replace printk with "stack-friendly" printf - to report console failure Paolo 'Blaisorblade' Giarrusso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200509222137.41412.blaisorblade@yahoo.it \
--to=blaisorblade@yahoo.it \
--cc=akpm@osdl.org \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).