linux-kernel - Re: [PATCH v3] can, tty: elmcan CAN/ldisc driver for ELM327 based OBD-II adapters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220314220408.hn4vdohtjdbfoaqo@pengutronix.de>
Date:   Mon, 14 Mar 2022 23:04:08 +0100
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Vincent Mailhol <vincent.mailhol@...il.com>
Cc:     Max Staudt <max@...as.org>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        linux-can@...r.kernel.org, Oliver Neukum <oneukum@...e.com>,
        linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>
Subject: Re: [PATCH v3] can, tty: elmcan CAN/ldisc driver for ELM327 based
 OBD-II adapters

On 09.03.2022 22:49:49, Vincent Mailhol wrote:
> > But rx_offload needs the mailbox_read function, even if it's a dummy,
> > because can_rx_offload_add_fifo() checks:
> >
> >         if (!offload->mailbox_read)
> >                 return -EINVAL;
> 
> I think that there should not be a dummy functions like this one.
> 
> Either we agree that using can_rx_offload without implementing
> the mailbox_read() is OK and in that case, the can_rx_offload
> framework should be modified to allow mailbox_read() to be a NULL
> pointer.
> 
> Either it is not the case and you use the more classic
> netif_rx().
> 
> And I do not have the answer. I haven't studied can_rx_offload
> enough to be a judge here. Sorry.
> 
> @Marc, any thoughts?

Use can_rx_offload_add_manual() instead.

> > > > +/* Send a can_frame to a TTY. */
> > > > +static netdev_tx_t elmcan_netdev_start_xmit(struct sk_buff *skb,
> > > > +                                           struct net_device *dev)
> > > > +{
> > > > +       struct elmcan *elm = netdev_priv(dev);
> > > > +       struct can_frame *frame = (struct can_frame *)skb->data;
> > > > +
> > > > +       if (skb->len != sizeof(struct can_frame))
> > > > +               goto out;
> > >
> > > Isn’t this aleardy guaranteed by the upper layers?
> >
> > Copy-pasta from slcan.c - will look into it.
> 
> Also give a look at can_dropped_invalid_skb().

ACK

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)