On Wed, Apr 12, 2023 at 03:21:34PM +0200, Pratyush Yadav wrote: > On Wed, Apr 12 2023, Yujie Liu wrote: > > > Hi Greg, Hi Pratyush, > > > > On Wed, Apr 05, 2023 at 04:22:58PM +0200, Greg KH wrote: > >> On Wed, Apr 05, 2023 at 03:33:20PM +0200, Pratyush Yadav wrote: > >> > On Wed, Apr 05 2023, Greg KH wrote: > >> > > >> > > On Wed, Apr 05, 2023 at 02:26:04PM +0200, Greg KH wrote: > >> > >> On Wed, Apr 05, 2023 at 01:47:52PM +0200, Pratyush Yadav wrote: > >> > >> > On Wed, Apr 05 2023, kernel test robot wrote: > >> > >> > > >> > >> > > Hi, > >> > >> > > > >> > >> > > Thanks for your patch. > >> > >> > > > >> > >> > > FYI: kernel test robot notices the stable kernel rule is not satisfied. > >> > >> > > > >> > >> > > Rule: 'Cc: stable@xxxxxxxxxxxxxxx' or 'commit <sha1> upstream.' > > > > Sorry the info at here is not accurate enough. We will improve the > > wording. > > > >> > >> > > >> > >> > I think the robot should also learn to look at the 'To:' header :-) > >> > >> > >> > >> Nope, the robot is correct, you submitted this incorrectly. > >> > > > >> > > Wait, maybe, I can't tell. > >> > > >> > My point is that it does not matter much if stable@xxxxxxxxxxxxxxx is in > >> > Cc or To. It gets the email regardless. In fact, that seems quite a > >> > common practice to me [0][1]. So I'd say it would be nice if the robot > >> > did not needlessly complain about this. > >> > > >> > [0] https://lore.kernel.org/stable/20230403140414.236685532@xxxxxxxxxxxxxxxxxxx/ > >> > [1] https://lore.kernel.org/stable/20230403140415.140110769@xxxxxxxxxxxxxxxxxxx/ > >> > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=87f93d82e0952da18af4d978e7d887b4c5326c0b > > > > This warning is not caused by "stable@xxxxxxxxxxxxxxx is in To or Cc". > > > > The document at [3] gives three options for sending patches to stable, > > and seems option 3 should apply on this patch: > > > > [3] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > > > > Option 3 > > > > Send the patch, after verifying that it follows the above rules, to stable@xxxxxxxxxxxxxxx. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish it to be applied to. > > > > The examples in link [0][1] have "upstream commit" in the changelog, but > > this patch doesn't, so the robot flags a warning. > > It is entirely possible for a patch for a stable tree to not have an > upstream commit. For example, I sent a patch recently [0] that was > caused by a buggy backport. The patch to fix it of course would not have > an upstream commit since upstream was correct from the get-go. The bot > should not complain about such patches. > > Funnily enough the bot did not complain there even though that patch > also does not have an upstream commit hash. But it puts > stable@xxxxxxxxxxxxxxx in Cc instead of To. > > [0] https://lore.kernel.org/all/20230411130210.113555-1-ptyadav@xxxxxxxxx/ > Thanks for the information. As for the patch at [0], the change log has: This assignment was present in the upstream commit 5891cd5ec46c2 ("net_sched: add __rcu annotation to netdev->qdisc") ... The robot wrongly considered the phrase "upstream commit ..." as upstream info. Sorry about this. We will keep improving the robot to understand various cases, but still coulnd't avoid sending false positives sometimes. We apologize if the robot makes any noise. We will fix the robot to correctly handle the cases discussed in this thread. Thanks. -- Best Regards, Yujie
