mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: ZhengYuan Huang <gality369@gmail.com>
Cc: dsterba@suse.com, clm@fb.com, linux-btrfs@vger.kernel.org,
	linux-kernel@vger.kernel.org, baijiaju1990@gmail.com,
	r33s3n6@gmail.com, zzzccc427@gmail.com, stable@vger.kernel.org
Subject: Re: [PATCH v2] btrfs: reject root items with drop_progress and zero drop_level
Date: Thu, 12 Mar 2026 14:46:29 +1030	[thread overview]
Message-ID: <a478f7a7-5255-4039-9ace-7d2b410db602@suse.com> (raw)
In-Reply-To: <CAOmEq9UusAbrMLSMkca+DEPff9hXokAvVn3V4acQ0EvSp67HLQ@mail.gmail.com>



在 2026/3/12 12:40, ZhengYuan Huang 写道:
> Thanks a lot for the explanation. I think I now understand the
> intended use of the
> Fixes: tag.
> 
> I still have one question, though. In this case, scripts/checkpatch.pl
> warns that a
> Fixes: tag should be added, which seems inconsistent with the submission
> guidelines you pointed me to.

If you check the checkpatch.pl itself, the logic in it is pretty simple 
and can give false alerts.

It just checks if the commit message has BUG: or KASAN/UBSAN lines.

So it's false alert prune.

> 
> My understanding had been that patches should generally be sent only
> after passing
> checkpatch.pl cleanly,

No, that is only a script which has its limits.
Checkpatch is good for its code style checks, but not always correct on 
other suggestions.

Sometimes even its code style checks may conflict with the rules inside 
each subsystem.


> so I wanted to ask: is this kind of warning acceptable in
> practice,

Yes, unless you believe a simple perl script can be as good as human 
common sense.

> or does it mean my local checkpatch.pl is outdated?

Since you're already using the latest rc kernel, I believe you're 
already using the latest checkpatch.

Thanks,
Qu

> If it is outdated,
> should I generally use the latest checkpatch.pl when checking patches
> before submission?
> 
> Thanks again,
> ZhengYuan Huang


  reply	other threads:[~2026-03-12  4:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-12  0:14 ZhengYuan Huang
2026-03-12  0:23 ` Qu Wenruo
2026-03-12  1:07   ` Qu Wenruo
2026-03-12  2:10     ` ZhengYuan Huang
2026-03-12  4:16       ` Qu Wenruo [this message]
2026-03-12  4:27         ` ZhengYuan Huang

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=a478f7a7-5255-4039-9ace-7d2b410db602@suse.com \
    --to=wqu@suse.com \
    --cc=baijiaju1990@gmail.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=gality369@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=r33s3n6@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=zzzccc427@gmail.com \
    /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

all inboxes | Powered by JetHome®