On Fri, May 06, 2022 at 05:58:22PM +0800, Chen, Rong A wrote: > > > On 5/6/2022 4:46 PM, Kalle Valo wrote: > > Dan Carpenter <[email protected]> writes: > > > > > On Thu, May 05, 2022 at 09:29:40AM +0800, Carl Huang wrote: > > > > Hi Kalle, > > > > > > > > Is the below the same fix that you have already applied to ath.git? > > > > > > > > [-next] ath11k: fix missing unlock on error in ath11k_wow_op_resume() - > > > > Patchwork (kernel.org) > > > > <https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/ > > > > > > > > > > > That looks good. It's sort of annoying for me to send a bug report a > > > month after the fix has been applied... Sorry about that. > > > > My ath.git tree is not included in linux-wireless builds so there's also > > a delay before linux-next sees the fix. > > Hi, > > Sorry for the overdue report , we'll take a look to prevent the same > problem arising again. > > > > > > 1) These are kbuild warnings. The zero day bot generates the > > > warnings and I look them over and hit send. I don't know why the kbuild > > > bot seems to get confused by -mm. The subject says 408/8237 which is > > > pretty crazy. Maybe I should just ignore the -mm patches? > > > > Yeah, I have been also wondering about using -mm for ath11k reports. > > Does anyone know why that's happening? > > We don't have a filter to ignore some warnings from specific branches, > we can create one to only report ath11k issues if found in ath.git, > please remind me if there are other rules. >
The problem is really specific to the -mm tree. They always have look like they're a part of a 1000+ series of patches. There was another one today: [kbuild] [linux-next:master 5904/9357] kernel/bpf/verifier.c:5331 process_kptr_func() warn: passing zero to 'PTR_ERR' That warning is a false positive but a high quality false positive. A lot of the "passing valid pointers" to PTR_ERR() bugs are caused because Smatch thinks some arches have signed pointers. I'm not sure what's up with that... :/ My bad. Those are on me. > > > > > 2) The blamed patch came from a git tree but it had a Link tag to > > > lore.kernel.org so we could have used that as an In-Reply-to tag. > > > In an ideal world, all the bug reports for a patch would go to a > > > standard location. > > > > > > Link: > > > https://lore.kernel.org/r/[email protected] > > > > Yeah, that would be nice. > > We have already linked the bug reports to the patch if the patch hasn't > been applied, I'm not sure is it possible to find the link of patch if > it's already applied in a branch. You could git do: git show 90bf5c8d0f7ecddf96fc1cd9434af4e157b51970 | grep "Link: https://lore.kernel.org/r/"; Some of the links are to freedesktop which also has the msgid. Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] We're really trying to discourage links to other websites because it's not under our control and it will break. And you wouldn't have the CC list either... But I still think it's useful. regards, dan carpenter _______________________________________________ kbuild mailing list -- [email protected] To unsubscribe send an email to [email protected]
