lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 01 Nov 2006 09:24:04 +0000
From:	Richard Purdie <richard@...nedhand.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, Hugh Dickins <hugh@...itas.com>
Subject: Re: [PATCH, RFC/T] Fix handling of write failures to swap devices

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists