Ma Ke <make24@xxxxxxxxxxx> writes: > Dan Carpenter<dan.carpenter@xxxxxxxxxx> wrote:. >> The Subject says RESEND but doesn't explain why you are resending.. >> You probably meant v2, but again it needs an explanation.. >> . >> On Fri, Aug 02, 2024 at 12:27:40PM +0800, Ma Ke wrote:. >> > This error path should return -EINVAL instead of success.. >> . >> Why do you feel that way? Have you tested it? What is the user visible. >> effect of this bug?. >> . >> I slightly feel hypocritical because I have send lots of commit messages. >> with exactly this commit message. The difference is that I only send. >> really easy patches where it's obvious what the intent was. A normal. >> kernel developer wouldn't need to leave their email client or view any. >> outside information to see that my patch is correct. If a patch is not. >> dead easy, I normally just report it. (Sometimes I report dead easy. >> bugs as well because I am lazy and maybe it's the end of my work day. >> or whatever).. >> . >> This patch on the other hand is more subtle and it's not clear why the. >> continue statements changed into returns.. >> . >> regards,. >> dan carpenter. > Thank you for your response to the vulnerability I submitted. Yes, we . > believe there is a similar issue. As described in [1], it gets pointers . > which are handled under the protection mechanism. If the path is error, it . > should return -EINVAL directly instead of success. The commit message should explain _why_ it should return an error. Currently there's no explanation neither in the commit message or in your email. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches https://docs.kernel.org/process/submitting-patches.html
