From: Richard Purdie <richard@openedhand.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Hugh Dickins <hugh@veritas.com>
Subject: Re: [PATCH, RFC/T] Fix handling of write failures to swap devices
Date: Wed, 01 Nov 2006 09:24:04 +0000 [thread overview]
Message-ID: <1162373044.5564.7.camel@localhost.localdomain> (raw)
In-Reply-To: <45483020.9010607@yahoo.com.au>
On Wed, 2006-11-01 at 16:26 +1100, Nick Piggin wrote:
> > I can't work out the code path it happens in and until I do, I'm not
> > sure how I can track it down...
>
> Is your driver scribbling on the page memory when it encounters a write
> error, or is the SIGBUS coming from a subsequent pagefault attempt on
> that address? Stick a WARN_ON(1) in the VM_FAULT_SIGBUS case in
> arch/arm/mm/fault.c to check.
I'm 100% certain the driver doesn't touch the memory page. It would be a
serious problem if it did as I'd see see memory corruption in the cases
where the page wasn't read from disk but read from the swap cache (I
don't).
The error therefore has to be coming from a pagefault attempt on the
address...
> >>Still, something must be triggering it somewhere.
> >
> >
> > Something must be but I wish I knew what/where...
>
> Let's try to find out :)
I'll see if I can work it out...
> Yes, I mean the other side of the writepage, ie. when page reclaim is
> about to attempt to swap it out.
>
> The attached (very untested, in need of splitting up) patch attempts to
> solve these problems. Note that it is probably not going to prevent your
> SIGBUS, so that will have to be found and fixed individually.
>
> In the meantime, I'll run this through some testing when I get half a
> chance.
Right, this is a nicer way to do it. I would have preferred to do
something like this in the first place but didn't as I didn't think I
could use PageError as a marker...
I'll try and work out why PageError is causing the problems and also
give the patch some testing.
Thanks,
Richard
next prev parent reply other threads:[~2006-11-01 9:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-27 7:59 [PATCH, RFC/T] Fix handling of write failures to swap devices Richard Purdie
2006-10-27 8:22 ` Nick Piggin
2006-10-27 8:44 ` Richard Purdie
2006-10-28 4:55 ` Nick Piggin
2006-10-28 10:43 ` Richard Purdie
2006-10-28 12:10 ` Nick Piggin
2006-10-30 11:55 ` Richard Purdie
2006-11-01 5:26 ` Nick Piggin
2006-11-01 9:24 ` Richard Purdie [this message]
2006-11-02 23:26 ` Richard Purdie
2006-12-13 11:43 ` Richard Purdie
2006-11-01 5:36 ` Nick Piggin
2006-11-01 9:32 ` Richard Purdie
2006-10-27 9:35 ` Richard Purdie
2006-10-27 21:19 ` Andrew Morton
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=1162373044.5564.7.camel@localhost.localdomain \
--to=richard@openedhand.com \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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