From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
Oliver Neukum <oneukum@suse.com>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCHv13 2/3] usb: USB Type-C connector class
Date: Wed, 30 Nov 2016 11:19:10 +0200 [thread overview]
Message-ID: <20161130091910.GD32668@kuha.fi.intel.com> (raw)
In-Reply-To: <20161129162744.GA2255@kroah.com>
Hi Greg,
On Tue, Nov 29, 2016 at 05:27:44PM +0100, Greg KH wrote:
> > +struct typec_cable {
> > + struct device dev;
> > + enum typec_plug_type type;
> > + u32 vdo;
> > + unsigned int usb_pd:1;
> > + unsigned int active:1;
> > + unsigned int sop_pp_controller:1;
> > +
> > + struct typec_plug plug[2];
>
> WTF???
>
> Think about what this structure now represents. You have 3 different
> reference counted objects, all embedded in the same structure. Who
> "owns" the lifecycle of it? What happens if plug[1]'s reference count
> is grabbed a bunch by someone reading a lot of files for it, and then
> the "larger" typec_cable.dev reference count is decremented to 0 because
> the core is done with it. oops, boom, ick, splat, and if you are lucky
> the device reboots itself, if not, someone just got root and read your
> bank account information...
I have to ask. How could that happen since the cable is the parent?
> I'm being harsh here because this is really really really badly designed
Don't worry about it, I can handle it. In fact, one could argue that I
like getting slapped by you based on the comments I keep getting, but
I assure you that is not the case ;-)
> code. Go back and think about your data structures, what they are
> trying to represent, and _WHO_ owns and controls them. The typec core
> should be the one that allocates and manages the lifecycle of them, not
> some random external entity where you just hope and pray that they got
> it right (hint, they can not as they do not know what the core did with
> the reference counts.)
>
> Right now you are almost there, the typec core registers and tries to
> manage the structures, but it doesn't allocate/free them, and that's the
> big problem, because really, with a structure that has 3 different
> reference counts, no one can. That's an impossibility.
>
> This needs a lot more work, sorry.
I was trying to cut corners, which clearly was wrong. I know what I
need to do. All the parts simply need to be registered normally. No
shortcuts.
> I'm now going to require that you get other internal Intel developers to
> sign off on this code before I review it again. You have resources at
> your disposal that others do not with your internal mailing lists
> containing senior kernel developers. Use it and don't waste the
> community's time to do basic code review that they should be doing
> instead.
Fair enough.
> How did we get to a v13 of this patch series without anyone else even
> seeing this? That's worrysome as well...
I guess for somebody writing the port drivers my awesome shortcut felt
kinda nice. All they would have to do is announce connection when it
happens, and the class then tried figured out everything for them,
what needs to be created and so on. But yes, that is wrong!
But man, v14! I have got to be breaking the record with this one.
Thanks,
--
heikki
next prev parent reply other threads:[~2016-11-30 9:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 12:21 [PATCHv13 0/3] USB Type-C Connector class Heikki Krogerus
2016-11-24 12:21 ` [PATCHv13 1/3] lib/string: add sysfs_match_string helper Heikki Krogerus
2016-12-07 23:54 ` [PATCHv13,1/3] " Guenter Roeck
2016-12-08 7:29 ` Heikki Krogerus
2016-11-24 12:21 ` [PATCHv13 2/3] usb: USB Type-C connector class Heikki Krogerus
2016-11-29 16:27 ` Greg KH
2016-11-30 9:19 ` Heikki Krogerus [this message]
2016-12-02 18:04 ` Guenter Roeck
2016-12-02 18:22 ` Greg KH
2016-12-07 9:11 ` Heikki Krogerus
2016-12-07 9:46 ` Oliver Neukum
2016-12-07 12:52 ` Heikki Krogerus
2016-12-15 11:50 ` Heikki Krogerus
2016-12-15 12:06 ` Oliver Neukum
2016-12-15 15:01 ` Guenter Roeck
2016-12-19 14:45 ` [RFC PATCH] " Heikki Krogerus
2016-12-19 17:22 ` Guenter Roeck
2016-12-20 14:23 ` Heikki Krogerus
2016-11-24 12:21 ` [PATCHv13 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY Heikki Krogerus
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=20161130091910.GD32668@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=oneukum@suse.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.