On Wed, Jun 30, 2021 at 09:08:43AM -0700, Darrick J. Wong wrote:
> On Wed, Jun 30, 2021 at 04:14:29PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> > index 1721fce2ec94..fee4fbadea0a 100644
> > --- a/fs/xfs/xfs_log_recover.c
> > +++ b/fs/xfs/xfs_log_recover.c
> > @@ -2062,7 +2062,7 @@ xlog_recover_add_to_cont_trans(
> > old_ptr = item->ri_buf[item->ri_cnt-1].i_addr;
> > old_len = item->ri_buf[item->ri_cnt-1].i_len;
> >
> > - ptr = krealloc(old_ptr, len + old_len, GFP_KERNEL | __GFP_NOFAIL);
> > + ptr = kvrealloc(old_ptr, old_len, len + old_len, GFP_KERNEL);
>
> kvrealloc can return null, so this needs to check for that and -ENOMEM,
> right? It'll suck that log recovery fails, but such is life.
Ok, looking through the code it seems that returning -ENOMEM here
is a non-destructive (i.e. retry-able) failure. It will simply stop
processing the log at the point this occurs and abort all pending
objects that haven't been processed. The error message is less than
stellar ("log mount/recovery failed: error %d") but at least no
other damage will be done. I'll update it.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
