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] tty: Remove dead termiox code
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Jann Horn <jannh@google.com>, linux-kernel@vger.kernel.org
References: <20201203020331.2394754-1-jannh@google.com>
 <5cca5126-60ba-d123-0f7d-47fdbac4c4db@kernel.org>
 <X8nwnXQKOYWBWBZ+@kroah.com>
 <93834a92-b342-aaee-c400-2883d5df0cdc@kernel.org>
 <X8n1JiDS8ZVA6e6o@kroah.com>
From:   Jiri Slaby <jirislaby@kernel.org>
Message-ID: <8e993706-46e2-cbed-265f-1ba63cc9274d@kernel.org>
Date:   Fri, 4 Dec 2020 09:51:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <X8n1JiDS8ZVA6e6o@kroah.com>
Content-Type: text/plain; charset=iso-8859-2; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 04. 12. 20, 9:36, Greg Kroah-Hartman wrote:
> On Fri, Dec 04, 2020 at 09:20:39AM +0100, Jiri Slaby wrote:
>> On 04. 12. 20, 9:17, Greg Kroah-Hartman wrote:
>>> On Fri, Dec 04, 2020 at 08:22:41AM +0100, Jiri Slaby wrote:
>>>> On 03. 12. 20, 3:03, Jann Horn wrote:
>>>>> set_termiox() and the TCGETX handler bail out with -EINVAL immediately
>>>>> if ->termiox is NULL, but there are no code paths that can set
>>>>> ->termiox to a non-NULL pointer; and no such code paths seem to have
>>>>> existed since the termiox mechanism was introduced back in
>>>>> commit 1d65b4a088de ("tty: Add termiox") in v2.6.28.
>>>>> Similarly, no driver actually implements .set_termiox; and it looks like
>>>>> no driver ever has.
>>>>
>>>> Nice!
>>>>
>>>>> Delete this dead code; but leave the definition of struct termiox in the
>>>>> UAPI headers intact.

Note this ^^^^^. He is talking about _not_ touching the definition in 
the UAPI header. Does the rest below makes more sense now?

>>>> I am thinking -- can/should we mark the structure as deprecated so that
>>>> userspace stops using it eventually?
>>>
>>> If it doesn't do anything, how can userspace even use it today?  :)
>>
>> Well, right. I am in favor to remove it, BUT: what if someone tries that
>> ioctl and bails out if EINVAL is returned. I mean: if they define a local
>> var of that struct type and pass it to the ioctl, we would break the build
>> by removing the struct completely. Even if the code didn't do anything
>> useful, it still could be built. So is this very potential breakage OK?
> 
> I'm sorry, but I don't understand.  This is a kernel-internal-only
> structure, right?  If someone today tries to call these ioctls, they
> will get a -EINVAL error as no serial driver in the tree supports them.
> 
> If we remove the structure (i.e. what this patch does), and someone
> makes an ioctl call, they will still get the same -EINVAL error they did
> before.
> 
> So nothing has changed as far as userspace can tell.
> 
> Now if they have an out-of-tree serial driver that does implement this
> call, then yes, they will have problems, but that's not our problem,
> that is theirs for not ever submitting their code.  We don't support
> in-kernel apis with no in-kernel users.
> 
> Or am I still confused?
> 
> thanks,
> 
> greg k-h
> 


-- 
js