Re: [PATCH net-next 2/2] can: can327: publish tty->disc_data only after register_candev()

[Chaosheng Qu <chaosheng.qu.linux@gmail.com>]

Hi sashiko,

The mechanism is the same one I confirmed in the reply to 1/2, but I do not
think the outcome is: can327 does not restart its transmit queue from
`write_wakeup`.

`can327_ldisc_tx_worker()` only drains `elm->txleft` and clears
`TTY_DO_WRITE_WAKEUP` once the buffer is empty -- there is no
`netif_wake_queue()` in it. The queue is restarted from
`can327_handle_prompt()`, after the `ATMA` read command has been answered and
the controller is back in the default state, and again from the
`CAN327_TX_DO_CAN_DATA` branch of `can327_parse_rxbuf()`. Both run off the
receive path, and receive is not blocked by `ldisc_sem`: `flush_to_ldisc()`
takes no ldisc reference at all, it stops at the `buf->priority` check while the
ldisc is being changed, and `tty_set_ldisc()` restarts it with
`tty_buffer_restart_work()` after the unlock. So a wakeup lost inside
`can327_ldisc_open()` delays the queue restart until the next prompt is parsed,
but does not strand it.

What the patch is actually for is the failure path: when `register_candev()`
fails, `can327_ldisc_open()` returns without ever setting `tty->disc_data`, so
the `can327_ldisc_tx_wakeup()` that dereferences it unchecked can never be
reached with a stale pointer. Before the patch the pointer was published above
`register_candev()` and `free_candev()` dropped it out from under the tty.

On the suggestion to defer the registration: as in the 1/2 reply, `.open()`
cannot release `ldisc_sem` -- `tty_set_ldisc()` holds it across
`tty_ldisc_open()` and unlocks only after `.open()` returns -- so "after the
semaphore is released" can only be reached via a work item, at the cost of
`.open()` no longer being able to fail on registration.

Thanks,

Chaosheng