On Mon, Apr 24, 2023 at 09:22:55AM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Apr 24, 2023 at 1:22???AM Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > > @@ -1295,10 +1296,13 @@ static inline int folio_wait_bit_common(struct folio *folio, int bit_nr,
> > > /* Loop until we've been woken or interrupted */
> > > flags = smp_load_acquire(&wait->flags);
> > > if (!(flags & WQ_FLAG_WOKEN)) {
> > > + if (!timeout)
> > > + break;
> > > +
> >
> > An io_schedule_timeout of 0 is valid so why the special handling? It's
> > negative timeouts that cause schedule_timeout() to complain.
>
> It's not expected that the caller passes in a timeout of 0 here. The
> test here actually handles the case that the previous call to
> io_schedule_timeout() returned 0. In my patch, after the call to
> io_schedule_timeout() we unconditionally "continue" and end up back at
> the top of the loop. The next time through the loop if we don't see
> the WOKEN flag then we'll check for the two "error" conditions
> (timeout or signal pending) and break for either of them.
Ah, I see!
>
> To make it clearer, I'll add this comment for the next version:
>
> /* Break if the last io_schedule_timeout() said no time left */
Yes please.
--
Mel Gorman
SUSE Labs
