All of lore.kernel.org
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: add warning for invalid kernel page faults
Date: Mon, 28 Sep 2009 11:27:10 +0100	[thread overview]
Message-ID: <20090928102710.GG6715@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20090928101625.GE30271@localhost>

On Mon, Sep 28, 2009 at 01:16:25PM +0300, Imre Deak wrote:
> On Mon, Sep 28, 2009 at 12:04:42PM +0200, ext Russell King - ARM Linux wrote:
> > On Mon, Sep 28, 2009 at 01:00:48PM +0300, Imre Deak wrote:
> > > On Mon, Sep 28, 2009 at 11:55:16AM +0200, ext Russell King - ARM Linux wrote:
> > > > On Mon, Sep 28, 2009 at 12:48:24PM +0300, Imre Deak wrote:
> > > > > To easier detect code that can trigger the above error, add a check
> > > > > also for the case where mmap_sem is acquired. As this has an overhead
> > > > > make it a VM debug warning.
> > > > 
> > > > It _is_ already easy.  I'm not sure why you want even more noise, and
> > > > why you want to break the page fault handling.  From the warning you
> > > > received in your previous post, it said:
> > > 
> > > The problem is that it happens very rarely. Only if at the time of the
> > > fault the mmap_sem happens to be held. With the change the error would
> > > be apparent at the first fault the offending instruction generates.
> > 
> > Actually... I don't agree that your code can have any change what so
> > ever.
> > 
> > Condition 1:
> >                 if (!user_mode(regs) && !search_exception_tables(regs->ARM_pc))
> >                         goto no_context;
> > 
> >                 down_read(&mm->mmap_sem);
> > +#ifdef CONFIG_DEBUG_VM
> > 
> > Condition 2:
> > 
> > +               if (!user_mode(regs) &&
> > +                   !search_exception_tables(regs->ARM_pc)) {
> > +                       static unsigned long last_warn_jiffies;
> > 
> > Condition 1 and condition 2 are identical.  They do not change on whether
> > the mmap_sem is held or not.  So please explain to me how you actually
> > get to printing any of your new warnings.
> 
> With the change it's:
> 
> Condition 1:
> 
> if (!down_read_trylock(&mm->mmap_sem)) {
> 	if (!user_mode(regs) && !search_exception_tables(regs->ARM_pc))
> 		goto no_context;
> 	down_read(&mm->mmap_sem);
> } else {
> #ifdef CONFIG_DEBUG_VM
> 
> Condition 2:
> 	if (!user_mode(regs) && !search_exception_tables(regs->ARM_pc))
> 
> 
> So in condition 2, we managed to acquire mmap_sem, which will be the
> majority of the cases for kernel mode faults. In condition 1, we didn't
> since it was held by another thread.

Now you're talking about different code - the bit I quoted was what was
in your submitted patch, without deletion of intervening lines.  There
was no else clause in your patch.

Please, go back and look at your original patch.

  reply	other threads:[~2009-09-28 10:27 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-28  9:29 arm_syscall cacheflush breakage on VIPT platforms Imre Deak
2009-09-28  9:41 ` Russell King - ARM Linux
2009-09-28  9:54   ` Imre Deak
2009-09-28  9:59     ` Russell King - ARM Linux
2009-09-28 10:10       ` Imre Deak
2009-09-28 10:28         ` Russell King - ARM Linux
2009-09-28 11:00           ` Imre Deak
2009-09-28 16:54       ` Catalin Marinas
2009-09-28  9:48 ` [PATCH] ARM: add warning for invalid kernel page faults Imre Deak
2009-09-28  9:55   ` Russell King - ARM Linux
2009-09-28 10:00     ` Imre Deak
2009-09-28 10:04       ` Russell King - ARM Linux
2009-09-28 10:16         ` Imre Deak
2009-09-28 10:27           ` Russell King - ARM Linux [this message]
2009-09-28 11:01             ` Imre Deak
2009-09-28 11:05               ` [PATCH v2] " Imre Deak
2009-09-28 11:26               ` [PATCH] " Russell King - ARM Linux
2009-09-28 11:33                 ` Imre Deak
2009-09-28 11:34                   ` Russell King - ARM Linux
2009-09-29 10:07                     ` [PATCH v3] ARM: add debug check " Imre Deak
2009-09-28 12:49 ` arm_syscall cacheflush breakage on VIPT platforms Jamie Lokier
2009-09-28 13:16   ` Imre Deak
2009-09-28 13:19     ` Jamie Lokier
2009-09-28 13:25       ` Russell King - ARM Linux
2009-09-28 13:56         ` Jamie Lokier
2009-09-28 13:31       ` Imre Deak
2009-09-28 13:42         ` Russell King - ARM Linux
2009-09-28 13:55           ` Aguirre Rodriguez, Sergio Alberto
2009-09-28 14:07             ` Jamie Lokier
2009-09-28 14:10           ` Laurent Pinchart
2009-09-28 14:15             ` Jamie Lokier
2009-09-28 14:22               ` Laurent Pinchart
2009-09-28 14:50                 ` Jamie Lokier
2009-09-28 16:28                   ` Imre Deak
2009-09-28 19:35                     ` Jamie Lokier
2009-09-29  9:10                       ` Imre Deak
2009-09-28 20:18               ` Steven Walter
2009-09-29  0:50                 ` Jamie Lokier
2009-09-28 14:20             ` Bill Gatliff
2009-09-28 13:23     ` Russell King - ARM Linux

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=20090928102710.GG6715@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 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.