Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]

On 2015-08-25 12:44, Sean Fu wrote:
> On Tue, Aug 25, 2015 at 10:15 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Tue, 25 Aug 2015 15:50:18 +0800
>> Sean Fu <fxinrong@gmail.com> wrote:
>>
>>> On Tue, Aug 25, 2015 at 10:24 AM, Eric W. Biederman
>>> <ebiederm@xmission.com> wrote:
>>>>
>>>>
>>>> On August 24, 2015 6:57:57 PM MDT, Sean Fu <fxinrong@gmail.com> wrote:
>>>>> An application from HuaWei which works fine on 2.6 encounters this
>>>>> issue on 3.0 or later kernel.
>>>>
>>>> My sympathies.  Being stuck with a 3rd party application you can barely talk about that has been broken for 5years and no one reported it.
>>>>
>>>> Ordinarily we would fix a regression like this. As it has been 5years the challenge now is how do we tell if there are applications that depend on the current behavior.
>>>>
>>>> Before we can change the behavior back we need a convincing argument that we won't cause a regression in another application by making the change.
>>>>
>>>> I do not see how such an argument can be made.  So you have my sympathies but I do not see how we can help you.
>>> We should consider this patch basing on my following arguments.
>>> 1 Different version kernel should keep consistent on this behavior.
>>
>> The thing is, the above argument is against the patch. The behavior
>> changed 2 years ago, and nobody noticed. Changing it back only causes
>> more inconsistent behavior.
> It is impossible to cause more inconsistent behavior.
> it just enhance compatibility(support "xx...x\0").
> This patch just modify "proc_wspace_sep" array. and "proc_wspace_sep" is static.
> Only "proc_get_long" used this array, "proc_get_long" is also static.
> There are only 4 place to call "proc_get_long" in kernel/sysctl.c.
> I will prove that these 4 callers have no bad impact later.
Except that it is userspace we're worrying about here, not stuff 
internal to the kernel.
>
>>
>>
>>> 2 This writting behavior on proc file should be same with writting on
>>> regular file as possible as we can.
>>
>> Writing to a proc file causes kernel actions. Writing to a regular file
>> just saves data. That's not an argument here.
>>
>>> 3 This patch does not have any potential compatibility risk with 3rd
>>> party application.
>>
>> How do you know that?
> I will prove that all other write usage is not impacted later.
Except that you can only really do this for programs that you have 
access to, and by definition you can not have access to every program 
ever written that writes to /proc.

If you were going to do this, it would need to be itself controlled by 
another sysctl to toggle the behavior, which would need to default to 
the current behavior.
>
> Thanks for all reply.
>
> Sean
>>
>> -- Steve
>>
>>> 4 Support writting "1...\0" to proc file.
>>>
>>>>
>>>> Eric
>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]