On Thu, 3 Jul 2014, Vlastimil Babka wrote:
> On 07/02/2014 09:11 PM, Hugh Dickins wrote:
> >
> > --- 3.16-rc3+/mm/shmem.c 2014-07-02 03:31:12.956546569 -0700
> > +++ linux/mm/shmem.c 2014-07-02 03:34:13.172550852 -0700
> > @@ -467,23 +467,20 @@ static void shmem_undo_range(struct inod
> > return;
> >
> > index = start;
> > - for ( ; ; ) {
> > + while (index < end) {
> > cond_resched();
> >
> > pvec.nr = find_get_entries(mapping, index,
> > min(end - index, (pgoff_t)PAGEVEC_SIZE),
> > pvec.pages, indices);
> > if (!pvec.nr) {
> > - if (index == start || unfalloc)
> > + /* If all gone or hole-punch or unfalloc, we're done
> > */
> > + if (index == start || end != -1)
> > break;
> > + /* But if truncating, restart to make sure all gone
> > */
> > index = start;
> > continue;
> > }
> > - if ((index == start || unfalloc) && indices[0] >= end) {
> > - pagevec_remove_exceptionals(&pvec);
> > - pagevec_release(&pvec);
> > - break;
> > - }
> > mem_cgroup_uncharge_start();
> > for (i = 0; i < pagevec_count(&pvec); i++) {
> > struct page *page = pvec.pages[i];
> > @@ -495,8 +492,12 @@ static void shmem_undo_range(struct inod
> > if (radix_tree_exceptional_entry(page)) {
> > if (unfalloc)
> > continue;
> > - nr_swaps_freed += !shmem_free_swap(mapping,
> > - index, page);
> > + if (shmem_free_swap(mapping, index, page)) {
> > + /* Swap was replaced by page: retry
> > */
> > + index--;
> > + break;
> > + }
> > + nr_swaps_freed++;
> > continue;
>
> Ugh, a warning to anyone trying to backport this. This hunk can match both
> instances of the same code in the function, and I've just seen patch picking
> the wrong one.
Thanks for the warning.
Yes, as it ends up, there are only two hunks: so if the first fails
to apply (and down the releases there may be various trivial reasons
why it would fail to apply cleanly, although easily edited by hand),
patch might very well choose the first match to apply the second hunk.
I'm expecting to have to do (or at least to check) each -stable by
hand as it comes by. I did just check mmotm, and it came out fine.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
