Re: set_page_dirty vs set_page_dirty_lock

[Nick Piggin]

Michael S. Tsirkin wrote:
> Quoting Nick Piggin <nickpiggin@xxxxxxxxxxxx>:

> > I think you can do that - provided you ensure the page mapping hasn't
> > disappeared after locking it.
>
>
> Ugh. I dont really know how to do that.
> Isnt this sufficient?
>
> if (TestSetPageLocked(page))
> 	schedule_work(...)
> set_page_dirty(page)
> unlock_page(page)
>
> Thats all there seems to be set_page_dirty_lock does if it is called when
> PG_Locked bit is clear.

Oh yeah you are right - set_page_dirty does the check for you. Sorry
for the misinformation.

> > However, I think you should try to the simplest way first.
>
>
> Thanks, Nick, thats what I have now, this already works for me here
> https://openib.org/svn/gen2/trunk/src/linux-kernel/infiniband/ulp/sdp/sdp_iocb.c
> I'm looking at ways to improve performance, though.

Oh good :)

> > > If that works, I can mostly do things directly,
> > > although I'm still stuck with the problem of an app performing
> > > a fork + write into the same page while I'm doing DMA there.
> > >
> > > I am currently solving this by doing a second get_user_pages after
> > > DMA is done and comparing the page lists, but this, of course,
> > > needs a task context ...
> >
> > Usually we don't care about these kinds of races happening. So long
> > as it doesn't oops the kernel or hang the hardware, it is up to
> > userspace not to do stuff like that.
>
>
> Note that I am, even, not necessarily talking about full pages
> here: an application could be writing to one part of a page
> while hardware DMAs another part of it.
> So the app is not necessarily buggy.

Sorry, I might have misunderstdood: what's the race? And how does
a second get_user_pages solve it?

> It seems to me people really dont want to change their applications.
> They just want to load a library and have it go faster.
> Given that I'm implementing a socket protocol, we are talking about
> an awful lot of applications that currently work fine on top of TCP.

Understandable.

Nick

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/