Re: [PATCH] swap: redirty page if page write fails on swap file

[Will Huck]

Hi Jerome,
On 04/24/2013 05:57 PM, Jerome Marchand wrote:
> On 04/22/2013 10:37 PM, Andrew Morton wrote:
> > On Wed, 17 Apr 2013 14:11:55 +0200 Jerome Marchand <jmarchan@xxxxxxxxxx> wrote:
> >
> > > Since commit 62c230b, swap_writepage() calls direct_IO on swap files.
> > > However, in that case page isn't redirtied if I/O fails, and is therefore
> > > handled afterwards as if it has been successfully written to the swap
> > > file, leading to memory corruption when the page is eventually swapped
> > > back in.
> > > This patch sets the page dirty when direct_IO() fails. It fixes a memory
> > > corruption that happened while using swap-over-NFS.
> > >
> > > ...
> > >
> > > --- a/mm/page_io.c
> > > +++ b/mm/page_io.c
> > > @@ -222,6 +222,8 @@ int swap_writepage(struct page *page, struct writeback_control *wbc)
> > >   		if (ret == PAGE_SIZE) {
> > >   			count_vm_event(PSWPOUT);
> > >   			ret = 0;
> > > +		} else {
> > > +			set_page_dirty(page);
> > >   		}
> > >   		return ret;
> > >   	}
> > So what happens to the page now?  It remains dirty and the kernel later
> > tries to write it again?
> Yes. Also, AS_EIO or AS_ENOSPC is set to the address space flags (in this
> case, swapper_space).

After set AS_EIO or AS_ENOSPC, we can't touch swapper_space any more,  
correct?

> > And if that write also fails, the page is
> > effectively leaked until process exit?
> AFAICT, there is no special handling for that page afterwards, so if all
> subsequent attempts fail, it's indeed going to stay in memory until freed.
>
> Jerome
>
>
> > Aside: Mel, __swap_writepage() is fairly hair-raising.  It unlocks the
> > page before doing the IO and doesn't set PageWriteback().  Why such an
> > exception from normal handling?
> >
> > Also, what is protecting the page from concurrent reclaim or exit()
> > during the above swap_writepage()?
> >
> > Seems that the code needs a bunch of fixes or a bunch of comments
> > explaining why it is safe and why it has to be this way.
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>

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