linux-kernel - Re: [PATCH 1/2] SHM_UNLOCK: fix long unpreemptible section

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] [day] [month] [year] [list]

Date:	Wed, 18 Jan 2012 15:26:51 -0800 (PST)
From:	Hugh Dickins <hughd@...gle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Rik van Riel <riel@...hat.com>,
	Shaohua Li <shaohua.li@...el.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Michel Lespinasse <walken@...gle.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	stable@...r.kernel.org
Subject: Re: [PATCH 1/2] SHM_UNLOCK: fix long unpreemptible section

On Wed, 18 Jan 2012, Andrew Morton wrote:
> On Sat, 14 Jan 2012 16:18:43 -0800 (PST)
> Hugh Dickins <hughd@...gle.com> wrote:
> 
> > scan_mapping_unevictable_pages() is used to make SysV SHM_LOCKed pages
> > evictable again once the shared memory is unlocked.  It does this with
> > pagevec_lookup()s across the whole object (which might occupy most of
> > memory), and takes 300ms to unlock 7GB here.  A cond_resched() every
> > PAGEVEC_SIZE pages would be good.
>... 
> Is -stable backporting really warranted?  AFAICT the only thing we're
> fixing here is a long latency glitch during a rare operation on large
> machines.  Usually it will be on only one CPU, too.

True: I'm not sure if it amounts to -stable material or not.
I see you've taken out its Cc: stable line: that's fine by me, but...

> "[PATCH 2/2] SHM_UNLOCK: fix Unevictable pages stranded after swap"
> does loko like -stable material, so omitting 1/1 will probably screw
> things up :(

Sort of, but they both(?) needed respinning for -stable anyway.
Even against 3.2, there's some little change in vmscan.c that generates
a reject.  Greg has now closed down 3.1.N (which would have been tiresome
to port to, because it was still supporting a second caller of check_move),
and by your argument above it's not worth porting 1/2 back to 2.6.32.  So
I think 2/2 can just go into 3.2.N, dragging 1/2 along in its slipstream
(if you can have a slipstream in front of you).

I ordered them that way because 1/2 fixes an old, and 2/2 a recent, bug.

> > Resend in the hope that it can get into 3.3.
> 
> That we can do ;)

Thank you!

> > +#else
> > +void scan_mapping_unevictable_pages(struct address_space *mapping)
> > +{
> > +}
> > +#endif /* CONFIG_SHMEM */
> 
> Inlining the CONFIG_SHMEM=n stub would have been mroe efficient.

True, though in 2/2 it morphs into shmem_unlock_mapping() over
in shmem.c, and we seem to have the convention that TINY's !SHMEM
stubs live as non-inline functions there - probably no good reason
for that, just reflects their historical origins in tiny-shmem.c.
A grand saving to make some other time ;)

Hugh
--
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/