linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Cc: linux-can <linux-can@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH v2] can: netlink: prevent incoherent can configuration in case of early return
Date: Mon, 6 Sep 2021 16:30:57 +0200	[thread overview]
Message-ID: <20210906143057.zrpor5fkh67uqwi2@pengutronix.de> (raw)
In-Reply-To: <CAMZ6Rq+tNxU5ePDivMdwkbZK_hyao9hSyd0DrXnF503Qk1duqw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

On 06.09.2021 23:17:40, Vincent MAILHOL wrote:
> > > To prevent this from happening, we do a local copy of can_priv, work
> > > on it, an copy it at the very end of the function (i.e. only if all
> > > previous checks succeeded).
> >
> > I don't like the optimization of using a static priv. If it's too big to
> > be allocated on the stack, allocate it on the heap, i.e. using
> > kmemdup()/kfree().
> 
> The static declaration is only an issue of coding style, correct?

I don't know (but I haven't checked) if the coding style doc says
anything about that.

> Or is there an actual risk of doing so?

As you pointed out, this relies on the serialization of the changelink
callback by the networking stack. There's no sane way in C to track this
requirement in the networking stack, so I don't want to have any
roadblocks and/or potential bugs in the CAN code. Marking a variable as
static places it in the BSS section, right? This mean, the memory is
always "used", even if not setting the bitrate.

> This is for my understanding, I will remove the static
> declaration regardless of your answer.

tnx

> On my x86_64 machine, sizeof(priv) is 448 and if I declare priv on the stack:
> | $ objdump -d drivers/net/can/dev/netlink.o | ./scripts/checkstack.pl
> | 0x00000000000002100 can_changelink []:            1200
> 
> So I will allocate it on the heap.

Sounds reasonable.

> N.B. In above figures CONFIG_CAN_LEDS is *off* because that driver
> was tagged as broken in:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30f3b42147ba6f29bc95c1bba34468740762d91b

ok - BTW: I think we can remove LEDs support now, it's marked as broken
for more than 3 years.

> > > Once this done, there is no more need to have a temporary variable for
> > > a specific parameter. As such, the bittiming and data bittiming (bt
> > > and dbt) are directly written to the temporary priv variable.
> > >
> > > Finally, function can_calc_tdco() was retrieving can_priv from the
> > > net_device and directly modifying it. We changed the prototype so that
> > > it instead writes its changes into our temporary priv variable.
> >
> > Is it possible to split this into a separate patch, so that the part
> > without the tdco can be backported more easily to older kernels not
> > having tdco? The patch fixing the tdco would be the 2nd patch...
> 
> ACK. I will send a v3 with that split.

Thanks for helping taking care of the LTS kernels!

regards,
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 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2021-09-06 14:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03  7:17 [RESEND PATCH v2] can: netlink: prevent incoherent can configuration in case of early return Vincent Mailhol
2021-09-06  8:18 ` Marc Kleine-Budde
2021-09-06 14:17   ` Vincent MAILHOL
2021-09-06 14:30     ` Marc Kleine-Budde [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210906143057.zrpor5fkh67uqwi2@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).