This series fixes up a few issues with cdc-acm TIOCSSERIAL
implementation.
Johan
Johan Hovold (3):
Revert "USB: cdc-acm: fix rounding error in TIOCSSERIAL"
USB: cdc-acm: fix unprivileged TIOCCSERIAL
USB: cdc-acm: fix TIOCGSERIAL implementation
drivers/usb/class/cdc-acm.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
--
2.26.3
This reverts commit b401f8c4f492cbf74f3f59c9141e5be3071071bb.
The offending commit claimed that trying to set the values reported back
by TIOCGSERIAL as a regular user could result in an -EPERM error when HZ
is 250, but that was never the case.
With HZ=250, the default 0.5 second value of close_delay is converted to
125 jiffies when set and is converted back to 50 centiseconds by
TIOCGSERIAL as expected (not 12 cs as was claimed).
Comparing the internal current and new jiffies values is just fine to
determine if the value is about to change so drop the bogus workaround
(which was also backported to stable).
For completeness: With different default values for these parameters or
with a HZ value not divisible by two, the lack of rounding when setting
the default values in tty_port_init() could result in an -EPERM being
returned, but this is hardly something we need to worry about.
Cc: Anthony Mallet <[email protected]>
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
---
drivers/usb/class/cdc-acm.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 3fda1ec961d7..96e221803fa6 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -942,7 +942,6 @@ static int set_serial_info(struct tty_struct *tty, struct serial_struct *ss)
{
struct acm *acm = tty->driver_data;
unsigned int closing_wait, close_delay;
- unsigned int old_closing_wait, old_close_delay;
int retval = 0;
close_delay = msecs_to_jiffies(ss->close_delay * 10);
@@ -950,17 +949,11 @@ static int set_serial_info(struct tty_struct *tty, struct serial_struct *ss)
ASYNC_CLOSING_WAIT_NONE :
msecs_to_jiffies(ss->closing_wait * 10);
- /* we must redo the rounding here, so that the values match */
- old_close_delay = jiffies_to_msecs(acm->port.close_delay) / 10;
- old_closing_wait = acm->port.closing_wait == ASYNC_CLOSING_WAIT_NONE ?
- ASYNC_CLOSING_WAIT_NONE :
- jiffies_to_msecs(acm->port.closing_wait) / 10;
-
mutex_lock(&acm->port.mutex);
if (!capable(CAP_SYS_ADMIN)) {
- if ((ss->close_delay != old_close_delay) ||
- (ss->closing_wait != old_closing_wait))
+ if ((close_delay != acm->port.close_delay) ||
+ (closing_wait != acm->port.closing_wait))
retval = -EPERM;
else
retval = -EOPNOTSUPP;
--
2.26.3
TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
serial devices is only useful for setting the close_delay and
closing_wait parameters.
A non-privileged user has only ever been able to set the since long
deprecated ASYNC_SPD flags and trying to change any other *supported*
feature should result in -EPERM being returned. Setting the current
values for any supported features should return success.
Fix the cdc-acm implementation which instead indicated that the
TIOCSSERIAL ioctl was not even implemented when a non-privileged user
set the current values.
Fixes: ba2d8ce9db0a ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)")
Signed-off-by: Johan Hovold <[email protected]>
---
drivers/usb/class/cdc-acm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 96e221803fa6..43e31dad4831 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -955,8 +955,6 @@ static int set_serial_info(struct tty_struct *tty, struct serial_struct *ss)
if ((close_delay != acm->port.close_delay) ||
(closing_wait != acm->port.closing_wait))
retval = -EPERM;
- else
- retval = -EOPNOTSUPP;
} else {
acm->port.close_delay = close_delay;
acm->port.closing_wait = closing_wait;
--
2.26.3
On Wednesday 7 Apr 2021, at 12:28, Johan Hovold wrote:
> With HZ=250, the default 0.5 second value of close_delay is converted to
> 125 jiffies when set and is converted back to 50 centiseconds by
> TIOCGSERIAL as expected (not 12 cs as was claimed).
It was "12" (instead of 50) because the conversion gor TIOCGSERIAL was
initially broken, and that was fixed in the previous commit
633e2b2ded739a34bd0fb1d8b5b871f7e489ea29
> For completeness: With different default values for these parameters or
> with a HZ value not divisible by two, the lack of rounding when setting
> the default values in tty_port_init() could result in an -EPERM being
> returned, but this is hardly something we need to worry about.
The -EPERM is harmful when a regular user wants to update other
members of serial_struct without changing the close delays,
e.g. ASYNC_LOW_LATENCY, which is granted to regular users.
Best,
Anthony
On Wed, Apr 07, 2021 at 01:04:31PM +0200, Anthony Mallet wrote:
> On Wednesday 7 Apr 2021, at 12:28, Johan Hovold wrote:
> > With HZ=250, the default 0.5 second value of close_delay is converted to
> > 125 jiffies when set and is converted back to 50 centiseconds by
> > TIOCGSERIAL as expected (not 12 cs as was claimed).
>
> It was "12" (instead of 50) because the conversion gor TIOCGSERIAL was
> initially broken, and that was fixed in the previous commit
> 633e2b2ded739a34bd0fb1d8b5b871f7e489ea29
Right, so this patch is still just broken. The missing jiffies
conversion had already been added.
> > For completeness: With different default values for these parameters or
> > with a HZ value not divisible by two, the lack of rounding when setting
> > the default values in tty_port_init() could result in an -EPERM being
> > returned, but this is hardly something we need to worry about.
>
> The -EPERM is harmful when a regular user wants to update other
> members of serial_struct without changing the close delays,
> e.g. ASYNC_LOW_LATENCY, which is granted to regular users.
You're missing the point; -EPERM will *not* be returned -- and this
patch was never needed.
Johan
Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
> serial devices is only useful for setting the close_delay and
> closing_wait parameters.
>
> A non-privileged user has only ever been able to set the since long
> deprecated ASYNC_SPD flags and trying to change any other *supported*
> feature should result in -EPERM being returned. Setting the current
> values for any supported features should return success.
>
> Fix the cdc-acm implementation which instead indicated that the
> TIOCSSERIAL ioctl was not even implemented when a non-privileged user
> set the current values.
Hi,
the idea here was that you are setting something else, if you are
not changing a parameter that can be changed. That conclusion is
dubious, but at the same time, this implementation can change
only these two parameters. So can the test really be dropped
as opposed to be modified?
Regards
Oliver
On Thu, Apr 08, 2021 at 09:48:38AM +0200, Oliver Neukum wrote:
> Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
> > serial devices is only useful for setting the close_delay and
> > closing_wait parameters.
> >
> > A non-privileged user has only ever been able to set the since long
> > deprecated ASYNC_SPD flags and trying to change any other *supported*
> > feature should result in -EPERM being returned. Setting the current
> > values for any supported features should return success.
> >
> > Fix the cdc-acm implementation which instead indicated that the
> > TIOCSSERIAL ioctl was not even implemented when a non-privileged user
> > set the current values.
>
> Hi,
>
> the idea here was that you are setting something else, if you are
> not changing a parameter that can be changed. That conclusion is
> dubious, but at the same time, this implementation can change
> only these two parameters. So can the test really be dropped
> as opposed to be modified?
The de-facto standard for how to handle change requests for
non-supported features (e.g. changing the I/O port or IRQ) is to simply
ignore them and return 0.
For most (non-legacy) serial devices the only relevant parameters are
close_delay and closing_wait. And as we need to return -EPERM when a
non-privileged user tries to change these, we cannot drop the test.
(And returning -EOPNOTSUPP was never correct as the ioctl is indeed
supported.)
Johan
Am Donnerstag, den 08.04.2021, 11:42 +0200 schrieb Johan Hovold:
> On Thu, Apr 08, 2021 at 09:48:38AM +0200, Oliver Neukum wrote:
> > Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > > TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
> > > serial devices is only useful for setting the close_delay and
> > > closing_wait parameters.
> > >
> > > A non-privileged user has only ever been able to set the since long
> > > deprecated ASYNC_SPD flags and trying to change any other *supported*
> > > feature should result in -EPERM being returned. Setting the current
> > > values for any supported features should return success.
> > >
> > > Fix the cdc-acm implementation which instead indicated that the
> > > TIOCSSERIAL ioctl was not even implemented when a non-privileged user
> > > set the current values.
> >
> > Hi,
> >
> > the idea here was that you are setting something else, if you are
> > not changing a parameter that can be changed. That conclusion is
> > dubious, but at the same time, this implementation can change
> > only these two parameters. So can the test really be dropped
> > as opposed to be modified?
>
> The de-facto standard for how to handle change requests for
> non-supported features (e.g. changing the I/O port or IRQ) is to simply
> ignore them and return 0.
>
> For most (non-legacy) serial devices the only relevant parameters are
> close_delay and closing_wait. And as we need to return -EPERM when a
> non-privileged user tries to change these, we cannot drop the test.
>
> (And returning -EOPNOTSUPP was never correct as the ioctl is indeed
> supported.)
OK, thanks for clarification. Yes the fix makes sense.
Regards
Oliver