> On Dec 3, 2021, at 10:19 AM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>
> On Fri, Dec 03, 2021 at 03:17:30PM +0000, Chuck Lever III wrote:
>>
>>
>>> On Dec 3, 2021, at 6:25 AM, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
>>>
>>> On Tue, Nov 30, 2021 at 08:19:47PM +0000, Chuck Lever III wrote:
>>>>>
>>>>> -DEFINE_SPINLOCK(nfsd_notifier_lock);
>>>>> +static DEFINE_SPINLOCK(nfsd_notifier_lock);
>>>>> static int nfsd_inetaddr_event(struct notifier_block *this, unsigned long event,
>>>>> void *ptr)
>>>>> {
>>>>>
>>>>
>>>> Thanks! This was pushed to the tip of the for-next branch at
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
>>>>
>>>> I removed the Fixes: line because a backport is unnecessary, and
>>>> the commit ID is not yet permanent.
>>>
>>> Removing the tag, makes it more complicated for backporters. Before
>>> they could tell automatically from the Fixes tag that backporting was
>>> not necessary.
>>>
>>> On the other hand, does this patch really need a Fixes tag since it's
>>> not a runtime bug? Different maintainers take different sides in that
>>> argument.
>>>
>>> If the patch needed a fixes tag then a lot of maintainers have scripts
>>> to update the tag during a rebase. There are also automated tool run on
>>> linux-next which emails a warning when the Fixes tags point to an
>>> invalid hash.
>>
>> Hi Dan, the patch fixes a bug in my for-next branch, not in mainline.
>> There's really no need for a Fixes: tag.
>
> Assuming it doesn't get folded into the fixed patch before going
> upstream, it'd be useful information to have there.
I'm sorry, but I don't see how that information is useful for a
fixing a patch that is in the same merge set. I'll fold it in.
--
Chuck Lever
