On Sun, Mar 21, 2021 at 01:26:26AM +0530, Bhaskar Chowdhury wrote: > > s/filesytem/filesystem/ > s/instrumention/instrumentation/ > > Signed-off-by: Bhaskar Chowdhury <[email protected]>
Looks good to me, Reviewed-by: Darrick J. Wong <[email protected]> --D > --- > fs/xfs/xfs_log_recover.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c > index 97f31308de03..ffa4f6f2f31e 100644 > --- a/fs/xfs/xfs_log_recover.c > +++ b/fs/xfs/xfs_log_recover.c > @@ -2736,7 +2736,7 @@ xlog_recover_process_one_iunlink( > * of log space. > * > * This behaviour is bad for latency on single CPU and non-preemptible > kernels, > - * and can prevent other filesytem work (such as CIL pushes) from running. > This > + * and can prevent other filesystem work (such as CIL pushes) from running. > This > * can lead to deadlocks if the recovery process runs out of log reservation > * space. Hence we need to yield the CPU when there is other kernel work > * scheduled on this CPU to ensure other scheduled work can run without undue > @@ -3404,7 +3404,7 @@ xlog_recover( > > /* > * Delay log recovery if the debug hook is set. This is debug > - * instrumention to coordinate simulation of I/O failures with > + * instrumentation to coordinate simulation of I/O failures with > * log recovery. > */ > if (xfs_globals.log_recovery_delay) { > -- > 2.26.2 >
