Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v3] proc_sysctl: fix oops caused by incorrect command
 parameters.
To:     Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
        "Andrew Morton" <akpm@linux-foundation.org>,
        <rdunlap@infradead.org>, <hkallweit1@gmail.com>
CC:     <linux-kernel@vger.kernel.org>, <mcgrof@kernel.org>,
        <keescook@chromium.org>, <yzaikin@google.com>,
        <adobriyan@gmail.com>, <linux-fsdevel@vger.kernel.org>,
        <andy.shevchenko@gmail.com>, <wangle6@huawei.com>
References: <20210112033155.91502-1-nixiaoming@huawei.com>
 <20210111203340.98dd3c8fa675b709bcf6d49e@linux-foundation.org>
 <89d1369e-f0a8-66f2-c0ea-3aac3a55e2c1@huawei.com>
 <20210111222845.67ceb4e3c7f64f267756e4e8@linux-foundation.org>
 <20210112072406.GF22493@dhcp22.suse.cz>
 <afa493f4-f8ab-4039-cb9d-f6b02b3ab1c1@suse.cz>
From:   Xiaoming Ni <nixiaoming@huawei.com>
Message-ID: <c88e7bd2-54e2-ab4a-f548-96fb0cc2e4d2@huawei.com>
Date:   Sun, 17 Jan 2021 10:59:37 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.0.1
MIME-Version: 1.0
In-Reply-To: <afa493f4-f8ab-4039-cb9d-f6b02b3ab1c1@suse.cz>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2021/1/12 19:42, Vlastimil Babka wrote:
> On 1/12/21 8:24 AM, Michal Hocko wrote:
>>>>>
>>>>> If we're going to do a separate "patch: make process_sysctl_arg()
>>>>> return an errno instead of 0" then fine, we can discuss that.  But it's
>>>>> conceptually a different work from fixing this situation.
>>>>> .
>>>>>
>>>> However, are the logs generated by process_sysctl_arg() clearer and more
>>>> accurate than parse_args()? Should the logs generated by
>>>> process_sysctl_arg() be deleted?
>>>
>>> I think the individual logs are very useful and should be retained.
>>
>> Yes, other sysfs specific error messages are likely useful. I just fail
>> to see why a missing value should be handled here when there is an
>> existing handling in the caller. Not sure whether a complete shadow
>> reporting in process_sysctl_arg is a deliberate decision or not.
>> Vlastimil?
> 
> Yes, it's a way to have more useful sysctl-specific reports than the generic
> ones. And I think I was inspired by some other existing code, but don't remember
> exactly. The options are:
> 
> 1) the current sysctl-specific reports, return 0 as the values are only consumed
> 2) be silent and return error, invent new error codes to have generic report be
> more useful for sysctl, but inevitably lose some nuances anyway
> 3) a mix where 2) is used for situations where generic report is sufficient
> enough, 1) where not
> 
> Patch v2 went with option 1), v3 with option 3). I think it's down to
> preferences. I would personally go with v2 and message similar to the existing
> ones, i.e.:
> 
> "Failed to set sysctl parameter '%s': no value given\n"
> 
> Also we seem to be silently doing nothing when strlen(val) == 0, i.e.
> "hung_task_panic=" was passed. Worth reporting the same error.
> 
> But v3 is fine with me as well. The generic error message works. We could just
> add "if (!len) return -EINVAL" below the strlen() call.
> 
> Also please Cc: stable.
> 
>> Anyway one way or the other, all I care about is to have a reporting in
>> place because this shouldn't be a silent failure.
>>


The current v2 is already in the linux-next branch and throws a new 
error: 
https://lore.kernel.org/lkml/cb54e349-7147-0a1f-a349-1e16ba603fce@infradead.org/

This bug has been mentioned in the previous discussion and has been 
fixed in the current v3 patch. 
https://lore.kernel.org/linux-fsdevel/202101111149.20A58E1@keescook/

What am I supposed to do now?
     - Resend V3?
     - Rewrite a new fix patch based on the current code of linux-next.
     - Develop a new V4 patch: Use V2 to discuss how to use the Patch4 
solution. 
https://lore.kernel.org/linux-fsdevel/bc098af4-c0cd-212e-d09d-46d617d0acab@huawei.com/#t

Thanks
Xiaoming Ni