Messages in this thread | | | Date | Tue, 22 Dec 2020 17:35:33 -0800 | From | Andrew Morton <> | Subject | Re: [RFC PATCH 2/2] mm: readahead: handle LARGE input to get_init_ra_size() |
| |
On Sun, 20 Dec 2020 13:10:51 -0800 Randy Dunlap <rdunlap@infradead.org> wrote:
> Add a test to detect if the input ra request size has its high order > bit set (is negative when tested as a signed long). This would be a > really Huge readahead. > > If so, WARN() with the value and a stack trace so that we can see > where this is happening and then make further corrections later. > Then adjust the size value so that it is not so Huge (although > this may not be needed).
What motivates this change? Is there any reason to think this can happen?
Also, everything in there *should* be unsigned, because a negative readahead is semantically nonsensical. Is our handling of this inherently unsigned quantity incorrect somewhere?
> --- linux-5.10.1.orig/mm/readahead.c > +++ linux-5.10.1/mm/readahead.c > > ... > > @@ -303,14 +304,21 @@ void force_page_cache_ra(struct readahea > } > > /* > - * Set the initial window size, round to next power of 2 and square > + * Set the initial window size, round to next power of 2 > * for small size, x 4 for medium, and x 2 for large > * for 128k (32 page) max ra > * 1-8 page = 32k initial, > 8 page = 128k initial > */ > static unsigned long get_init_ra_size(unsigned long size, unsigned long max) > { > - unsigned long newsize = roundup_pow_of_two(size); > + unsigned long newsize; > + > + if ((signed long)size < 0) { /* high bit is set: ultra-large ra req */ > + WARN_ONCE(1, "%s: size=0x%lx\n", __func__, size); > + size = -size; /* really only need to flip the high/sign bit */ > + } > + > + newsize = roundup_pow_of_two(size);
Is there any way in which userspace can deliberately trigger warning? Via sys_readadhead() or procfs tuning or whatever?
I guess that permitting a user-triggerable WARN_ONCE() isn't a huuuuge problem - it isn't a DoS if it only triggers a single time. It does permit the malicious user to disable future valid warnings, but I don't see what incentive there would be for this. But still, it seems desirable to avoid it.
| |