| | Date | Fri, 2 Oct 2009 17:46:40 +0100 (BST) | | From | Hugh Dickins <> | | Subject | Re: [120/136] mm: munlock use follow_page |
| |
On Thu, 1 Oct 2009, Greg KH wrote: > 2.6.31-stable review patch. If anyone has any objections, please let us know. > > ------------------ > From: Hugh Dickins <hugh.dickins@tiscali.co.uk> > > commit 408e82b78bcc9f1b47c76e833c3df97f675947de upstream. > > Hiroaki Wakabayashi points out that when mlock() has been interrupted > by SIGKILL, the subsequent munlock() takes unnecessarily long because > its use of __get_user_pages() insists on faulting in all the pages > which mlock() never reached. > > It's worse than slowness if mlock() is terminated by Out Of Memory kill: > the munlock_vma_pages_all() in exit_mmap() insists on faulting in all the > pages which mlock() could not find memory for; so innocent bystanders are > killed too, and perhaps the system hangs. > > __get_user_pages() does a lot that's silly for munlock(): so remove the > munlock option from __mlock_vma_pages_range(), and use a simple loop of > follow_page()s in munlock_vma_pages_range() instead; ignoring absent > pages, and not marking present pages as accessed or dirty. > > (Change munlock() to only go so far as mlock() reached? That does not > work out, given the convention that mlock() claims complete success even > when it has to give up early - in part so that an underlying file can be > extended later, and those pages locked which earlier would give SIGBUS.)
Thanks a lot for including this fix in 2.6.31.2.
If I'd done my homework, I'd be asking you to include the equivalent in 2.6.30.9 (it's irrelevant to 2.6.27.36); but because of intervening changes, although it would appear to apply there, it would be wrong.
And it's more than a one-liner, so I'd need to retest properly. If there's ever a call for a 2.6.30.10, I ought to supply you with the proper patch; but for now, unless others disagree, let's not rush it for 2.6.30.9.
Hugh
|