public inbox for [email protected]
 help / color / mirror / Atom feed
From: Dmitry Kadashev <[email protected]>
To: Al Viro <[email protected]>
Cc: Jens Axboe <[email protected]>,
	Christian Brauner <[email protected]>,
	Linus Torvalds <[email protected]>,
	linux-fsdevel <[email protected]>,
	io-uring <[email protected]>
Subject: Re: [PATCH 01/14] namei: prepare do_rmdir for refactoring
Date: Tue, 20 Jul 2021 13:52:43 +0700	[thread overview]
Message-ID: <CAOKbgA68Oa_vrD4nZw0puCiqHFFA_8PrkADrRmWgt=4WE6Wfqw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>

On Fri, Jul 16, 2021 at 2:49 AM Al Viro <[email protected]> wrote:
>
> On Thu, Jul 15, 2021 at 05:35:47PM +0700, Dmitry Kadashev wrote:
> > This is just a preparation for the move of the main rmdir logic to a
> > separate function to make the logic easier to follow.  This change
> > contains the flow changes so that the actual change to move the main
> > logic to a separate function does no change the flow at all.
> >
> > Two changes here:
> >
> > 1. Previously on filename_parentat() error the function used to exit
> > immediately, and now it will check the return code to see if ESTALE
> > retry is appropriate. The filename_parentat() does its own retries on
> > ESTALE, but this extra check should be completely fine.
> >
> > 2. The retry_estale() check is wrapped in unlikely(). Some other places
> > already have that and overall it seems to make sense.
>
> That's not the way to do it.
>
> static inline bool
> retry_estale(const long error, const unsigned int flags)
> {
>         return unlikely(error == -ESTALE && !(flags & LOOKUP_REVAL));
> }
>
> And strip the redundant unlikely in the callers.  Having that markup
> in callers makes sense only when different callers have different
> odds of positive result, which is very much not the case here.

Yeah, I thought about this, but wasn't sure about interplay of
inline+[un]likely(). But I see that it's used quite a bit throughout the
kernel code so I suppose it's fine. I'll use that next time, thanks.


--
Dmitry Kadashev

  reply	other threads:[~2021-07-20  6:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15 10:35 [PATCH 00/14] namei: clean up retry logic in various do_* functions Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 01/14] namei: prepare do_rmdir for refactoring Dmitry Kadashev
2021-07-15 19:49   ` Al Viro
2021-07-20  6:52     ` Dmitry Kadashev [this message]
2021-07-15 10:35 ` [PATCH 02/14] namei: clean up do_rmdir retry logic Dmitry Kadashev
2021-07-15 20:02   ` Al Viro
2021-07-15 10:35 ` [PATCH 03/14] namei: prepare do_unlinkat for refactoring Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 04/14] namei: clean up do_unlinkat retry logic Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 05/14] namei: prepare do_mkdirat for refactoring Dmitry Kadashev
2021-07-15 20:17   ` Al Viro
2021-07-20  6:59     ` Dmitry Kadashev
2021-07-20 13:55       ` Al Viro
2021-07-21 10:02         ` Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 06/14] namei: clean up do_mkdirat retry logic Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 07/14] namei: prepare do_mknodat for refactoring Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 08/14] namei: clean up do_mknodat retry logic Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 09/14] namei: prepare do_symlinkat for refactoring Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 10/14] namei: clean up do_symlinkat retry logic Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 11/14] namei: prepare do_linkat for refactoring Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 12/14] namei: clean up do_linkat retry logic Dmitry Kadashev
2021-07-15 10:35 ` [PATCH 13/14] namei: prepare do_renameat2 for refactoring Dmitry Kadashev
2021-07-15 10:36 ` [PATCH 14/14] namei: clean up do_renameat2 retry logic Dmitry Kadashev
2021-07-15 10:39 ` [PATCH 00/14] namei: clean up retry logic in various do_* functions Dmitry Kadashev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOKbgA68Oa_vrD4nZw0puCiqHFFA_8PrkADrRmWgt=4WE6Wfqw@mail.gmail.com' \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox