> -----Original Message----- > From: Vincent MAILHOL <mailhol.vincent@xxxxxxxxxx> > Sent: 2020年10月21日 14:24 > To: Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx>; Oliver Hartkopp > <socketcan@xxxxxxxxxxxx>; linux-can@xxxxxxxxxxxxxxx > Cc: kernel@xxxxxxxxxxxxxx; Vincent Mailhol <mailhol.vincent@xxxxxxxxxx>; > Stéphane Grosjean <s.grosjean@xxxxxxxxxxxxxxx> > Subject: Re: [net-rfc 04/16] can: dev: can_get_len(): add a helper function to > get the correct length of Classical frames > > > > From a first thought I would see a new flag CAN_CTRLMODE_RAW_DLC in > > > the netlink interface of IFLA_CAN_CTRLMODE for the CAN controller driver. > > > > > > This could switch the sanitizing AND the CAN controller can properly > > > expose its ability to support this mode. > > > > Absolutely yes. In my first message, I mentioned the idea of managing > > that through socket option, glad that we now share the same idea. > > Actually, I just realized that I replied to you too quickly. I was not exactly > thinking of the same thing here so let me correct what I previously said. > > IFLA_CAN_CTRLMODE is at the netlink level. My idea is to have it, in addition, > at the socket level. Example: add CAN_RAW_RAW_DLC in > include/uapi/linux/can/raw.h. > > The reason is that if we only manage it at the netlink level, some application > not aware of the RAW_DLC issue might run into some buffer overflow issue. > Unless an application directly requests it, the current behaviour should be > maintained (rationale: do not break userland). Hi Vincent Mailhol, I wonder if it's appropriate to ask this question here, why this RAW_DLC issue might run into some buffer overflow issue? Will it cause frames dropped finally? Best Regards, Joakim Zhang > So the full picture will be to have both the CAN_CTRLMODE_RAW_DLC at > netlink level and CAN_RAW_RAW_DLC at the socket level (in the exact same > way we have both CAN_CTRLMODE_FD and CAN_RAW_FD_FRAMES for > CAN-FD). > > > Yours sincerely, > Vincent Mailhol
