Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Luis R. Rodriguez
On Wed, Aug 03, 2016 at 09:32:41PM +0200, Greg KH wrote:
> On Wed, Aug 03, 2016 at 07:06:07PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Aug 03, 2016 at 05:04:39PM +0200, Greg KH wrote:
> > > On Wed, Aug 03, 2016 at 04:50:14PM +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> > > > > On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > > > > > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > > > > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > > > > > The firmware API has had some issues a while ago, some of this 
> > > > > > > > is
> > > > > > > > not well documented, and its still hard to grasp. This documents
> > > > > > > > some of these issues, adds SmPL grammar rules to enable us to 
> > > > > > > > hunt
> > > > > > > > for issues, and annotations to help us with our effort to 
> > > > > > > > finally
> > > > > > > > compartamentalize that pesky usermode helper.
> > > > > > > > 
> > > > > > > > Previously this was just one patch, the grammar rule to help
> > > > > > > > find request firmware API users on init or probe, this series
> > > > > > > > extends that effort with usermode helper grammar rules, and some
> > > > > > > > annotations and documentation on the firmware_class driver to
> > > > > > > > avoid further issues. Documenting the usermode helper and making
> > > > > > > > it clear why we cannot remove it is important for analysis for
> > > > > > > > the next series which adds the new flexible sysdata firmware 
> > > > > > > > API.
> > > > > > > > 
> > > > > > > > This series depends on the coccicheck series which enables
> > > > > > > > annotations on coccinelle patches to require a specific
> > > > > > > > version of coccinelle [0], as such coordination with Michal is
> > > > > > > > in order.
> > > > > > > 
> > > > > > > Michal is out until July 11, and upon further thought such 
> > > > > > > coordination
> > > > > > > is not need, the annotation is in place as comments and as such
> > > > > > > merging this now won't have any negative effects other than the 
> > > > > > > version
> > > > > > > check. Also the patches in question for the coccicheck change are 
> > > > > > > all
> > > > > > > acked now and I expect them to be merged anyway.
> > > > > > > 
> > > > > > > Which tree should firmware changes go through ?
> > > > > > > 
> > > > > > > > This series is also further extended next with the new sydata
> > > > > > > > API, the full set of changes is available on my linux-next tree 
> > > > > > > > [1].
> > > > > > > > 
> > > > > > > > Perhaps now a good time to discuss -- if 0-day should enable 
> > > > > > > > the rule
> > > > > > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be 
> > > > > > > > called on
> > > > > > > > every 0-day iteration, it runs rather fast and it should help 
> > > > > > > > police
> > > > > > > > against avoiding futher explicit users of the usermode helper.
> > > > > > > 
> > > > > > > And if we are going to merge this anyone oppose enabling hunting
> > > > > > > for further explicit users of the usermode helper using grammar 
> > > > > > > through
> > > > > > > 0-day ?
> > > > > > 
> > > > > > *Poke*
> > > > > 
> > > > > *Re-poke*
> > > > 
> > > > Re-re-poke.
> > > > 
> > > > The scripts/coccicheck changes are now merged on Linus' tree, so these 
> > > > patches
> > > > have no other pending changes upstream.
> > > > 
> > > > Who's tree can this go through or is this too late now?
> > > 
> > > It's way too late for 4.8-rc1, it will have to go into a maintainer tree
> > > after 4.8-rc1 is out.
> > 
> > OK thanks, what maintainer tree should this go through ? firmware_class 
> > changes
> > seem to sporadically go through different maintainers, and often some 
> > changes
> > go in without much review. Not sure if this is helping.
> 
> I usually take them, after they are acked by the firmware maintainer.  I
> haven't looked to see if this series is, if it is, I can easily take
> them.

That's the thing Ming is busy it seems so this series nor the changes that
actually went through Andrew were ACKed (and I actually NACK'd the changes that
eventually did go through Andrew after I saw them appear on linux-next), so I'm
adding myself to the MAINTAINERS list to help with this.

> But again, I can't do anything until after 4.8-rc1 is out, and then I
> get to start working through my huge backlog due to a vacation and
> conference travel I did last month.

Understood. Will post once 4.8-rc1 is out.

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Luis R. Rodriguez
On Wed, Aug 03, 2016 at 09:32:41PM +0200, Greg KH wrote:
> On Wed, Aug 03, 2016 at 07:06:07PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Aug 03, 2016 at 05:04:39PM +0200, Greg KH wrote:
> > > On Wed, Aug 03, 2016 at 04:50:14PM +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> > > > > On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > > > > > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > > > > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > > > > > The firmware API has had some issues a while ago, some of this 
> > > > > > > > is
> > > > > > > > not well documented, and its still hard to grasp. This documents
> > > > > > > > some of these issues, adds SmPL grammar rules to enable us to 
> > > > > > > > hunt
> > > > > > > > for issues, and annotations to help us with our effort to 
> > > > > > > > finally
> > > > > > > > compartamentalize that pesky usermode helper.
> > > > > > > > 
> > > > > > > > Previously this was just one patch, the grammar rule to help
> > > > > > > > find request firmware API users on init or probe, this series
> > > > > > > > extends that effort with usermode helper grammar rules, and some
> > > > > > > > annotations and documentation on the firmware_class driver to
> > > > > > > > avoid further issues. Documenting the usermode helper and making
> > > > > > > > it clear why we cannot remove it is important for analysis for
> > > > > > > > the next series which adds the new flexible sysdata firmware 
> > > > > > > > API.
> > > > > > > > 
> > > > > > > > This series depends on the coccicheck series which enables
> > > > > > > > annotations on coccinelle patches to require a specific
> > > > > > > > version of coccinelle [0], as such coordination with Michal is
> > > > > > > > in order.
> > > > > > > 
> > > > > > > Michal is out until July 11, and upon further thought such 
> > > > > > > coordination
> > > > > > > is not need, the annotation is in place as comments and as such
> > > > > > > merging this now won't have any negative effects other than the 
> > > > > > > version
> > > > > > > check. Also the patches in question for the coccicheck change are 
> > > > > > > all
> > > > > > > acked now and I expect them to be merged anyway.
> > > > > > > 
> > > > > > > Which tree should firmware changes go through ?
> > > > > > > 
> > > > > > > > This series is also further extended next with the new sydata
> > > > > > > > API, the full set of changes is available on my linux-next tree 
> > > > > > > > [1].
> > > > > > > > 
> > > > > > > > Perhaps now a good time to discuss -- if 0-day should enable 
> > > > > > > > the rule
> > > > > > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be 
> > > > > > > > called on
> > > > > > > > every 0-day iteration, it runs rather fast and it should help 
> > > > > > > > police
> > > > > > > > against avoiding futher explicit users of the usermode helper.
> > > > > > > 
> > > > > > > And if we are going to merge this anyone oppose enabling hunting
> > > > > > > for further explicit users of the usermode helper using grammar 
> > > > > > > through
> > > > > > > 0-day ?
> > > > > > 
> > > > > > *Poke*
> > > > > 
> > > > > *Re-poke*
> > > > 
> > > > Re-re-poke.
> > > > 
> > > > The scripts/coccicheck changes are now merged on Linus' tree, so these 
> > > > patches
> > > > have no other pending changes upstream.
> > > > 
> > > > Who's tree can this go through or is this too late now?
> > > 
> > > It's way too late for 4.8-rc1, it will have to go into a maintainer tree
> > > after 4.8-rc1 is out.
> > 
> > OK thanks, what maintainer tree should this go through ? firmware_class 
> > changes
> > seem to sporadically go through different maintainers, and often some 
> > changes
> > go in without much review. Not sure if this is helping.
> 
> I usually take them, after they are acked by the firmware maintainer.  I
> haven't looked to see if this series is, if it is, I can easily take
> them.

That's the thing Ming is busy it seems so this series nor the changes that
actually went through Andrew were ACKed (and I actually NACK'd the changes that
eventually did go through Andrew after I saw them appear on linux-next), so I'm
adding myself to the MAINTAINERS list to help with this.

> But again, I can't do anything until after 4.8-rc1 is out, and then I
> get to start working through my huge backlog due to a vacation and
> conference travel I did last month.

Understood. Will post once 4.8-rc1 is out.

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Greg KH
On Wed, Aug 03, 2016 at 07:06:07PM +0200, Luis R. Rodriguez wrote:
> On Wed, Aug 03, 2016 at 05:04:39PM +0200, Greg KH wrote:
> > On Wed, Aug 03, 2016 at 04:50:14PM +0200, Luis R. Rodriguez wrote:
> > > On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> > > > On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > > > > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > > > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > > > > The firmware API has had some issues a while ago, some of this is
> > > > > > > not well documented, and its still hard to grasp. This documents
> > > > > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > > > > for issues, and annotations to help us with our effort to finally
> > > > > > > compartamentalize that pesky usermode helper.
> > > > > > > 
> > > > > > > Previously this was just one patch, the grammar rule to help
> > > > > > > find request firmware API users on init or probe, this series
> > > > > > > extends that effort with usermode helper grammar rules, and some
> > > > > > > annotations and documentation on the firmware_class driver to
> > > > > > > avoid further issues. Documenting the usermode helper and making
> > > > > > > it clear why we cannot remove it is important for analysis for
> > > > > > > the next series which adds the new flexible sysdata firmware API.
> > > > > > > 
> > > > > > > This series depends on the coccicheck series which enables
> > > > > > > annotations on coccinelle patches to require a specific
> > > > > > > version of coccinelle [0], as such coordination with Michal is
> > > > > > > in order.
> > > > > > 
> > > > > > Michal is out until July 11, and upon further thought such 
> > > > > > coordination
> > > > > > is not need, the annotation is in place as comments and as such
> > > > > > merging this now won't have any negative effects other than the 
> > > > > > version
> > > > > > check. Also the patches in question for the coccicheck change are 
> > > > > > all
> > > > > > acked now and I expect them to be merged anyway.
> > > > > > 
> > > > > > Which tree should firmware changes go through ?
> > > > > > 
> > > > > > > This series is also further extended next with the new sydata
> > > > > > > API, the full set of changes is available on my linux-next tree 
> > > > > > > [1].
> > > > > > > 
> > > > > > > Perhaps now a good time to discuss -- if 0-day should enable the 
> > > > > > > rule
> > > > > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be 
> > > > > > > called on
> > > > > > > every 0-day iteration, it runs rather fast and it should help 
> > > > > > > police
> > > > > > > against avoiding futher explicit users of the usermode helper.
> > > > > > 
> > > > > > And if we are going to merge this anyone oppose enabling hunting
> > > > > > for further explicit users of the usermode helper using grammar 
> > > > > > through
> > > > > > 0-day ?
> > > > > 
> > > > > *Poke*
> > > > 
> > > > *Re-poke*
> > > 
> > > Re-re-poke.
> > > 
> > > The scripts/coccicheck changes are now merged on Linus' tree, so these 
> > > patches
> > > have no other pending changes upstream.
> > > 
> > > Who's tree can this go through or is this too late now?
> > 
> > It's way too late for 4.8-rc1, it will have to go into a maintainer tree
> > after 4.8-rc1 is out.
> 
> OK thanks, what maintainer tree should this go through ? firmware_class 
> changes
> seem to sporadically go through different maintainers, and often some changes
> go in without much review. Not sure if this is helping.

I usually take them, after they are acked by the firmware maintainer.  I
haven't looked to see if this series is, if it is, I can easily take
them.

But again, I can't do anything until after 4.8-rc1 is out, and then I
get to start working through my huge backlog due to a vacation and
conference travel I did last month.

thanks,

greg k-h


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Greg KH
On Wed, Aug 03, 2016 at 07:06:07PM +0200, Luis R. Rodriguez wrote:
> On Wed, Aug 03, 2016 at 05:04:39PM +0200, Greg KH wrote:
> > On Wed, Aug 03, 2016 at 04:50:14PM +0200, Luis R. Rodriguez wrote:
> > > On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> > > > On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > > > > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > > > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > > > > The firmware API has had some issues a while ago, some of this is
> > > > > > > not well documented, and its still hard to grasp. This documents
> > > > > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > > > > for issues, and annotations to help us with our effort to finally
> > > > > > > compartamentalize that pesky usermode helper.
> > > > > > > 
> > > > > > > Previously this was just one patch, the grammar rule to help
> > > > > > > find request firmware API users on init or probe, this series
> > > > > > > extends that effort with usermode helper grammar rules, and some
> > > > > > > annotations and documentation on the firmware_class driver to
> > > > > > > avoid further issues. Documenting the usermode helper and making
> > > > > > > it clear why we cannot remove it is important for analysis for
> > > > > > > the next series which adds the new flexible sysdata firmware API.
> > > > > > > 
> > > > > > > This series depends on the coccicheck series which enables
> > > > > > > annotations on coccinelle patches to require a specific
> > > > > > > version of coccinelle [0], as such coordination with Michal is
> > > > > > > in order.
> > > > > > 
> > > > > > Michal is out until July 11, and upon further thought such 
> > > > > > coordination
> > > > > > is not need, the annotation is in place as comments and as such
> > > > > > merging this now won't have any negative effects other than the 
> > > > > > version
> > > > > > check. Also the patches in question for the coccicheck change are 
> > > > > > all
> > > > > > acked now and I expect them to be merged anyway.
> > > > > > 
> > > > > > Which tree should firmware changes go through ?
> > > > > > 
> > > > > > > This series is also further extended next with the new sydata
> > > > > > > API, the full set of changes is available on my linux-next tree 
> > > > > > > [1].
> > > > > > > 
> > > > > > > Perhaps now a good time to discuss -- if 0-day should enable the 
> > > > > > > rule
> > > > > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be 
> > > > > > > called on
> > > > > > > every 0-day iteration, it runs rather fast and it should help 
> > > > > > > police
> > > > > > > against avoiding futher explicit users of the usermode helper.
> > > > > > 
> > > > > > And if we are going to merge this anyone oppose enabling hunting
> > > > > > for further explicit users of the usermode helper using grammar 
> > > > > > through
> > > > > > 0-day ?
> > > > > 
> > > > > *Poke*
> > > > 
> > > > *Re-poke*
> > > 
> > > Re-re-poke.
> > > 
> > > The scripts/coccicheck changes are now merged on Linus' tree, so these 
> > > patches
> > > have no other pending changes upstream.
> > > 
> > > Who's tree can this go through or is this too late now?
> > 
> > It's way too late for 4.8-rc1, it will have to go into a maintainer tree
> > after 4.8-rc1 is out.
> 
> OK thanks, what maintainer tree should this go through ? firmware_class 
> changes
> seem to sporadically go through different maintainers, and often some changes
> go in without much review. Not sure if this is helping.

I usually take them, after they are acked by the firmware maintainer.  I
haven't looked to see if this series is, if it is, I can easily take
them.

But again, I can't do anything until after 4.8-rc1 is out, and then I
get to start working through my huge backlog due to a vacation and
conference travel I did last month.

thanks,

greg k-h


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Luis R. Rodriguez
On Wed, Aug 03, 2016 at 05:04:39PM +0200, Greg KH wrote:
> On Wed, Aug 03, 2016 at 04:50:14PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> > > On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > > > The firmware API has had some issues a while ago, some of this is
> > > > > > not well documented, and its still hard to grasp. This documents
> > > > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > > > for issues, and annotations to help us with our effort to finally
> > > > > > compartamentalize that pesky usermode helper.
> > > > > > 
> > > > > > Previously this was just one patch, the grammar rule to help
> > > > > > find request firmware API users on init or probe, this series
> > > > > > extends that effort with usermode helper grammar rules, and some
> > > > > > annotations and documentation on the firmware_class driver to
> > > > > > avoid further issues. Documenting the usermode helper and making
> > > > > > it clear why we cannot remove it is important for analysis for
> > > > > > the next series which adds the new flexible sysdata firmware API.
> > > > > > 
> > > > > > This series depends on the coccicheck series which enables
> > > > > > annotations on coccinelle patches to require a specific
> > > > > > version of coccinelle [0], as such coordination with Michal is
> > > > > > in order.
> > > > > 
> > > > > Michal is out until July 11, and upon further thought such 
> > > > > coordination
> > > > > is not need, the annotation is in place as comments and as such
> > > > > merging this now won't have any negative effects other than the 
> > > > > version
> > > > > check. Also the patches in question for the coccicheck change are all
> > > > > acked now and I expect them to be merged anyway.
> > > > > 
> > > > > Which tree should firmware changes go through ?
> > > > > 
> > > > > > This series is also further extended next with the new sydata
> > > > > > API, the full set of changes is available on my linux-next tree [1].
> > > > > > 
> > > > > > Perhaps now a good time to discuss -- if 0-day should enable the 
> > > > > > rule
> > > > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called 
> > > > > > on
> > > > > > every 0-day iteration, it runs rather fast and it should help police
> > > > > > against avoiding futher explicit users of the usermode helper.
> > > > > 
> > > > > And if we are going to merge this anyone oppose enabling hunting
> > > > > for further explicit users of the usermode helper using grammar 
> > > > > through
> > > > > 0-day ?
> > > > 
> > > > *Poke*
> > > 
> > > *Re-poke*
> > 
> > Re-re-poke.
> > 
> > The scripts/coccicheck changes are now merged on Linus' tree, so these 
> > patches
> > have no other pending changes upstream.
> > 
> > Who's tree can this go through or is this too late now?
> 
> It's way too late for 4.8-rc1, it will have to go into a maintainer tree
> after 4.8-rc1 is out.

OK thanks, what maintainer tree should this go through ? firmware_class changes
seem to sporadically go through different maintainers, and often some changes
go in without much review. Not sure if this is helping.

For instance Stephen Boyd's commit a098ecd2fa7db8fa4f ("firmware: support
loading into a pre-allocated buffer") when in through Andrew and I saw no
formal ACK from the maintainer. Meanwhile this series lingered just as long,
had IMHO less controversial changes, but went no where. I am adding myself to
the list of maintainers for firmware_class in this series to help with this as
I've already been helping with review and I'd like to help with maintenance but
its not clear if the current tree setup helps. I don't think setting up a tree
just for firmware_class makes sense.. but not sure what to do about the tree
situation.  Would setting on going through you through a driver-core branch be
best?  How can we make things better ? Your advice is appreciated.

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Luis R. Rodriguez
On Wed, Aug 03, 2016 at 05:04:39PM +0200, Greg KH wrote:
> On Wed, Aug 03, 2016 at 04:50:14PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> > > On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > > > The firmware API has had some issues a while ago, some of this is
> > > > > > not well documented, and its still hard to grasp. This documents
> > > > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > > > for issues, and annotations to help us with our effort to finally
> > > > > > compartamentalize that pesky usermode helper.
> > > > > > 
> > > > > > Previously this was just one patch, the grammar rule to help
> > > > > > find request firmware API users on init or probe, this series
> > > > > > extends that effort with usermode helper grammar rules, and some
> > > > > > annotations and documentation on the firmware_class driver to
> > > > > > avoid further issues. Documenting the usermode helper and making
> > > > > > it clear why we cannot remove it is important for analysis for
> > > > > > the next series which adds the new flexible sysdata firmware API.
> > > > > > 
> > > > > > This series depends on the coccicheck series which enables
> > > > > > annotations on coccinelle patches to require a specific
> > > > > > version of coccinelle [0], as such coordination with Michal is
> > > > > > in order.
> > > > > 
> > > > > Michal is out until July 11, and upon further thought such 
> > > > > coordination
> > > > > is not need, the annotation is in place as comments and as such
> > > > > merging this now won't have any negative effects other than the 
> > > > > version
> > > > > check. Also the patches in question for the coccicheck change are all
> > > > > acked now and I expect them to be merged anyway.
> > > > > 
> > > > > Which tree should firmware changes go through ?
> > > > > 
> > > > > > This series is also further extended next with the new sydata
> > > > > > API, the full set of changes is available on my linux-next tree [1].
> > > > > > 
> > > > > > Perhaps now a good time to discuss -- if 0-day should enable the 
> > > > > > rule
> > > > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called 
> > > > > > on
> > > > > > every 0-day iteration, it runs rather fast and it should help police
> > > > > > against avoiding futher explicit users of the usermode helper.
> > > > > 
> > > > > And if we are going to merge this anyone oppose enabling hunting
> > > > > for further explicit users of the usermode helper using grammar 
> > > > > through
> > > > > 0-day ?
> > > > 
> > > > *Poke*
> > > 
> > > *Re-poke*
> > 
> > Re-re-poke.
> > 
> > The scripts/coccicheck changes are now merged on Linus' tree, so these 
> > patches
> > have no other pending changes upstream.
> > 
> > Who's tree can this go through or is this too late now?
> 
> It's way too late for 4.8-rc1, it will have to go into a maintainer tree
> after 4.8-rc1 is out.

OK thanks, what maintainer tree should this go through ? firmware_class changes
seem to sporadically go through different maintainers, and often some changes
go in without much review. Not sure if this is helping.

For instance Stephen Boyd's commit a098ecd2fa7db8fa4f ("firmware: support
loading into a pre-allocated buffer") when in through Andrew and I saw no
formal ACK from the maintainer. Meanwhile this series lingered just as long,
had IMHO less controversial changes, but went no where. I am adding myself to
the list of maintainers for firmware_class in this series to help with this as
I've already been helping with review and I'd like to help with maintenance but
its not clear if the current tree setup helps. I don't think setting up a tree
just for firmware_class makes sense.. but not sure what to do about the tree
situation.  Would setting on going through you through a driver-core branch be
best?  How can we make things better ? Your advice is appreciated.

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Greg KH
On Wed, Aug 03, 2016 at 04:50:14PM +0200, Luis R. Rodriguez wrote:
> On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> > On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > > The firmware API has had some issues a while ago, some of this is
> > > > > not well documented, and its still hard to grasp. This documents
> > > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > > for issues, and annotations to help us with our effort to finally
> > > > > compartamentalize that pesky usermode helper.
> > > > > 
> > > > > Previously this was just one patch, the grammar rule to help
> > > > > find request firmware API users on init or probe, this series
> > > > > extends that effort with usermode helper grammar rules, and some
> > > > > annotations and documentation on the firmware_class driver to
> > > > > avoid further issues. Documenting the usermode helper and making
> > > > > it clear why we cannot remove it is important for analysis for
> > > > > the next series which adds the new flexible sysdata firmware API.
> > > > > 
> > > > > This series depends on the coccicheck series which enables
> > > > > annotations on coccinelle patches to require a specific
> > > > > version of coccinelle [0], as such coordination with Michal is
> > > > > in order.
> > > > 
> > > > Michal is out until July 11, and upon further thought such coordination
> > > > is not need, the annotation is in place as comments and as such
> > > > merging this now won't have any negative effects other than the version
> > > > check. Also the patches in question for the coccicheck change are all
> > > > acked now and I expect them to be merged anyway.
> > > > 
> > > > Which tree should firmware changes go through ?
> > > > 
> > > > > This series is also further extended next with the new sydata
> > > > > API, the full set of changes is available on my linux-next tree [1].
> > > > > 
> > > > > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > > > > every 0-day iteration, it runs rather fast and it should help police
> > > > > against avoiding futher explicit users of the usermode helper.
> > > > 
> > > > And if we are going to merge this anyone oppose enabling hunting
> > > > for further explicit users of the usermode helper using grammar through
> > > > 0-day ?
> > > 
> > > *Poke*
> > 
> > *Re-poke*
> 
> Re-re-poke.
> 
> The scripts/coccicheck changes are now merged on Linus' tree, so these patches
> have no other pending changes upstream.
> 
> Who's tree can this go through or is this too late now?

It's way too late for 4.8-rc1, it will have to go into a maintainer tree
after 4.8-rc1 is out.

thanks,

greg k-h


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Greg KH
On Wed, Aug 03, 2016 at 04:50:14PM +0200, Luis R. Rodriguez wrote:
> On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> > On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > > The firmware API has had some issues a while ago, some of this is
> > > > > not well documented, and its still hard to grasp. This documents
> > > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > > for issues, and annotations to help us with our effort to finally
> > > > > compartamentalize that pesky usermode helper.
> > > > > 
> > > > > Previously this was just one patch, the grammar rule to help
> > > > > find request firmware API users on init or probe, this series
> > > > > extends that effort with usermode helper grammar rules, and some
> > > > > annotations and documentation on the firmware_class driver to
> > > > > avoid further issues. Documenting the usermode helper and making
> > > > > it clear why we cannot remove it is important for analysis for
> > > > > the next series which adds the new flexible sysdata firmware API.
> > > > > 
> > > > > This series depends on the coccicheck series which enables
> > > > > annotations on coccinelle patches to require a specific
> > > > > version of coccinelle [0], as such coordination with Michal is
> > > > > in order.
> > > > 
> > > > Michal is out until July 11, and upon further thought such coordination
> > > > is not need, the annotation is in place as comments and as such
> > > > merging this now won't have any negative effects other than the version
> > > > check. Also the patches in question for the coccicheck change are all
> > > > acked now and I expect them to be merged anyway.
> > > > 
> > > > Which tree should firmware changes go through ?
> > > > 
> > > > > This series is also further extended next with the new sydata
> > > > > API, the full set of changes is available on my linux-next tree [1].
> > > > > 
> > > > > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > > > > every 0-day iteration, it runs rather fast and it should help police
> > > > > against avoiding futher explicit users of the usermode helper.
> > > > 
> > > > And if we are going to merge this anyone oppose enabling hunting
> > > > for further explicit users of the usermode helper using grammar through
> > > > 0-day ?
> > > 
> > > *Poke*
> > 
> > *Re-poke*
> 
> Re-re-poke.
> 
> The scripts/coccicheck changes are now merged on Linus' tree, so these patches
> have no other pending changes upstream.
> 
> Who's tree can this go through or is this too late now?

It's way too late for 4.8-rc1, it will have to go into a maintainer tree
after 4.8-rc1 is out.

thanks,

greg k-h


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Luis R. Rodriguez
On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > The firmware API has had some issues a while ago, some of this is
> > > > not well documented, and its still hard to grasp. This documents
> > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > for issues, and annotations to help us with our effort to finally
> > > > compartamentalize that pesky usermode helper.
> > > > 
> > > > Previously this was just one patch, the grammar rule to help
> > > > find request firmware API users on init or probe, this series
> > > > extends that effort with usermode helper grammar rules, and some
> > > > annotations and documentation on the firmware_class driver to
> > > > avoid further issues. Documenting the usermode helper and making
> > > > it clear why we cannot remove it is important for analysis for
> > > > the next series which adds the new flexible sysdata firmware API.
> > > > 
> > > > This series depends on the coccicheck series which enables
> > > > annotations on coccinelle patches to require a specific
> > > > version of coccinelle [0], as such coordination with Michal is
> > > > in order.
> > > 
> > > Michal is out until July 11, and upon further thought such coordination
> > > is not need, the annotation is in place as comments and as such
> > > merging this now won't have any negative effects other than the version
> > > check. Also the patches in question for the coccicheck change are all
> > > acked now and I expect them to be merged anyway.
> > > 
> > > Which tree should firmware changes go through ?
> > > 
> > > > This series is also further extended next with the new sydata
> > > > API, the full set of changes is available on my linux-next tree [1].
> > > > 
> > > > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > > > every 0-day iteration, it runs rather fast and it should help police
> > > > against avoiding futher explicit users of the usermode helper.
> > > 
> > > And if we are going to merge this anyone oppose enabling hunting
> > > for further explicit users of the usermode helper using grammar through
> > > 0-day ?
> > 
> > *Poke*
> 
> *Re-poke*

Re-re-poke.

The scripts/coccicheck changes are now merged on Linus' tree, so these patches
have no other pending changes upstream.

Who's tree can this go through or is this too late now?
Andrew can these go through your tree?

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-08-03 Thread Luis R. Rodriguez
On Thu, Jul 28, 2016 at 02:41:48AM +0200, Luis R. Rodriguez wrote:
> On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > > The firmware API has had some issues a while ago, some of this is
> > > > not well documented, and its still hard to grasp. This documents
> > > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > > for issues, and annotations to help us with our effort to finally
> > > > compartamentalize that pesky usermode helper.
> > > > 
> > > > Previously this was just one patch, the grammar rule to help
> > > > find request firmware API users on init or probe, this series
> > > > extends that effort with usermode helper grammar rules, and some
> > > > annotations and documentation on the firmware_class driver to
> > > > avoid further issues. Documenting the usermode helper and making
> > > > it clear why we cannot remove it is important for analysis for
> > > > the next series which adds the new flexible sysdata firmware API.
> > > > 
> > > > This series depends on the coccicheck series which enables
> > > > annotations on coccinelle patches to require a specific
> > > > version of coccinelle [0], as such coordination with Michal is
> > > > in order.
> > > 
> > > Michal is out until July 11, and upon further thought such coordination
> > > is not need, the annotation is in place as comments and as such
> > > merging this now won't have any negative effects other than the version
> > > check. Also the patches in question for the coccicheck change are all
> > > acked now and I expect them to be merged anyway.
> > > 
> > > Which tree should firmware changes go through ?
> > > 
> > > > This series is also further extended next with the new sydata
> > > > API, the full set of changes is available on my linux-next tree [1].
> > > > 
> > > > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > > > every 0-day iteration, it runs rather fast and it should help police
> > > > against avoiding futher explicit users of the usermode helper.
> > > 
> > > And if we are going to merge this anyone oppose enabling hunting
> > > for further explicit users of the usermode helper using grammar through
> > > 0-day ?
> > 
> > *Poke*
> 
> *Re-poke*

Re-re-poke.

The scripts/coccicheck changes are now merged on Linus' tree, so these patches
have no other pending changes upstream.

Who's tree can this go through or is this too late now?
Andrew can these go through your tree?

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-27 Thread Luis R. Rodriguez
On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > The firmware API has had some issues a while ago, some of this is
> > > not well documented, and its still hard to grasp. This documents
> > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > for issues, and annotations to help us with our effort to finally
> > > compartamentalize that pesky usermode helper.
> > > 
> > > Previously this was just one patch, the grammar rule to help
> > > find request firmware API users on init or probe, this series
> > > extends that effort with usermode helper grammar rules, and some
> > > annotations and documentation on the firmware_class driver to
> > > avoid further issues. Documenting the usermode helper and making
> > > it clear why we cannot remove it is important for analysis for
> > > the next series which adds the new flexible sysdata firmware API.
> > > 
> > > This series depends on the coccicheck series which enables
> > > annotations on coccinelle patches to require a specific
> > > version of coccinelle [0], as such coordination with Michal is
> > > in order.
> > 
> > Michal is out until July 11, and upon further thought such coordination
> > is not need, the annotation is in place as comments and as such
> > merging this now won't have any negative effects other than the version
> > check. Also the patches in question for the coccicheck change are all
> > acked now and I expect them to be merged anyway.
> > 
> > Which tree should firmware changes go through ?
> > 
> > > This series is also further extended next with the new sydata
> > > API, the full set of changes is available on my linux-next tree [1].
> > > 
> > > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > > every 0-day iteration, it runs rather fast and it should help police
> > > against avoiding futher explicit users of the usermode helper.
> > 
> > And if we are going to merge this anyone oppose enabling hunting
> > for further explicit users of the usermode helper using grammar through
> > 0-day ?
> 
> *Poke*

*Re-poke*

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-27 Thread Luis R. Rodriguez
On Wed, Jul 13, 2016 at 11:47:52PM +0200, Luis R. Rodriguez wrote:
> On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> > On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > > The firmware API has had some issues a while ago, some of this is
> > > not well documented, and its still hard to grasp. This documents
> > > some of these issues, adds SmPL grammar rules to enable us to hunt
> > > for issues, and annotations to help us with our effort to finally
> > > compartamentalize that pesky usermode helper.
> > > 
> > > Previously this was just one patch, the grammar rule to help
> > > find request firmware API users on init or probe, this series
> > > extends that effort with usermode helper grammar rules, and some
> > > annotations and documentation on the firmware_class driver to
> > > avoid further issues. Documenting the usermode helper and making
> > > it clear why we cannot remove it is important for analysis for
> > > the next series which adds the new flexible sysdata firmware API.
> > > 
> > > This series depends on the coccicheck series which enables
> > > annotations on coccinelle patches to require a specific
> > > version of coccinelle [0], as such coordination with Michal is
> > > in order.
> > 
> > Michal is out until July 11, and upon further thought such coordination
> > is not need, the annotation is in place as comments and as such
> > merging this now won't have any negative effects other than the version
> > check. Also the patches in question for the coccicheck change are all
> > acked now and I expect them to be merged anyway.
> > 
> > Which tree should firmware changes go through ?
> > 
> > > This series is also further extended next with the new sydata
> > > API, the full set of changes is available on my linux-next tree [1].
> > > 
> > > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > > every 0-day iteration, it runs rather fast and it should help police
> > > against avoiding futher explicit users of the usermode helper.
> > 
> > And if we are going to merge this anyone oppose enabling hunting
> > for further explicit users of the usermode helper using grammar through
> > 0-day ?
> 
> *Poke*

*Re-poke*

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Fengguang Wu

On Thu, Jul 14, 2016 at 05:08:12AM +0200, Luis R. Rodriguez wrote:

On Thu, Jul 14, 2016 at 10:23:36AM +0800, Fengguang Wu wrote:

On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:
>On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
>>Hi Luis,
>>
>>On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
>>>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
The firmware API has had some issues a while ago, some of this is
not well documented, and its still hard to grasp. This documents
some of these issues, adds SmPL grammar rules to enable us to hunt
for issues, and annotations to help us with our effort to finally
compartamentalize that pesky usermode helper.

Previously this was just one patch, the grammar rule to help
find request firmware API users on init or probe, this series
extends that effort with usermode helper grammar rules, and some
annotations and documentation on the firmware_class driver to
avoid further issues. Documenting the usermode helper and making
it clear why we cannot remove it is important for analysis for
the next series which adds the new flexible sysdata firmware API.

This series depends on the coccicheck series which enables
annotations on coccinelle patches to require a specific
version of coccinelle [0], as such coordination with Michal is
in order.
>>>
>>>Michal is out until July 11, and upon further thought such coordination
>>>is not need, the annotation is in place as comments and as such
>>>merging this now won't have any negative effects other than the version
>>>check. Also the patches in question for the coccicheck change are all
>>>acked now and I expect them to be merged anyway.
>>>
>>>Which tree should firmware changes go through ?
>>
This series is also further extended next with the new sydata
API, the full set of changes is available on my linux-next tree [1].

Perhaps now a good time to discuss -- if 0-day should enable the rule
scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
every 0-day iteration, it runs rather fast and it should help police
against avoiding futher explicit users of the usermode helper.
>>>
>>>And if we are going to merge this anyone oppose enabling hunting
>>>for further explicit users of the usermode helper using grammar through
>>>0-day ?
>>
>>When *.cocci scripts lands upstream they'll be auto picked up by the
>>0-day bot to guard new patches/commits.
>
>Great thanks!
>
>>Are there further steps 0-day should do for request_firmware-upstream.cocci?
>
>It just requires coccinelle >= 1.0.5.

That looks easy.


Nice!


When do you estimate the script will land upstream?


Well, this series has gone by a while now without any complaints, so
I was poking to see if they can be merged now.


OK.


So we can make sure upgrade coccinelle before that time.


There is another series which modernizes coccicheck [0] for which I just poked
at as a well [1], one change which may be of importance to you is groks the
Requires: tag on top of an SmPL patch, with that we simply just skip an SmPL
patch if the version of coccinelle is older than the one specified, with that
in place you can just upgrade when you want -- you'd just gain support for more
SmPL patches when you do. Without that coccinelle would not work (fail) on the
SmPL patch when tried. For this reason I originally had suggested perhaps
this series should be carried by Michal.

[0] 
https://lkml.kernel.org/r/1467238499-10889-1-git-send-email-mcg...@kernel.org
[1] https://lkml.kernel.org/r/20160713214539.ge6...@wotan.suse.de


It's glad to know these improvements. We'll watch their progress and
keep up in time. :)

Thanks,
Fengguang


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Fengguang Wu

On Thu, Jul 14, 2016 at 05:08:12AM +0200, Luis R. Rodriguez wrote:

On Thu, Jul 14, 2016 at 10:23:36AM +0800, Fengguang Wu wrote:

On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:
>On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
>>Hi Luis,
>>
>>On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
>>>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
The firmware API has had some issues a while ago, some of this is
not well documented, and its still hard to grasp. This documents
some of these issues, adds SmPL grammar rules to enable us to hunt
for issues, and annotations to help us with our effort to finally
compartamentalize that pesky usermode helper.

Previously this was just one patch, the grammar rule to help
find request firmware API users on init or probe, this series
extends that effort with usermode helper grammar rules, and some
annotations and documentation on the firmware_class driver to
avoid further issues. Documenting the usermode helper and making
it clear why we cannot remove it is important for analysis for
the next series which adds the new flexible sysdata firmware API.

This series depends on the coccicheck series which enables
annotations on coccinelle patches to require a specific
version of coccinelle [0], as such coordination with Michal is
in order.
>>>
>>>Michal is out until July 11, and upon further thought such coordination
>>>is not need, the annotation is in place as comments and as such
>>>merging this now won't have any negative effects other than the version
>>>check. Also the patches in question for the coccicheck change are all
>>>acked now and I expect them to be merged anyway.
>>>
>>>Which tree should firmware changes go through ?
>>
This series is also further extended next with the new sydata
API, the full set of changes is available on my linux-next tree [1].

Perhaps now a good time to discuss -- if 0-day should enable the rule
scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
every 0-day iteration, it runs rather fast and it should help police
against avoiding futher explicit users of the usermode helper.
>>>
>>>And if we are going to merge this anyone oppose enabling hunting
>>>for further explicit users of the usermode helper using grammar through
>>>0-day ?
>>
>>When *.cocci scripts lands upstream they'll be auto picked up by the
>>0-day bot to guard new patches/commits.
>
>Great thanks!
>
>>Are there further steps 0-day should do for request_firmware-upstream.cocci?
>
>It just requires coccinelle >= 1.0.5.

That looks easy.


Nice!


When do you estimate the script will land upstream?


Well, this series has gone by a while now without any complaints, so
I was poking to see if they can be merged now.


OK.


So we can make sure upgrade coccinelle before that time.


There is another series which modernizes coccicheck [0] for which I just poked
at as a well [1], one change which may be of importance to you is groks the
Requires: tag on top of an SmPL patch, with that we simply just skip an SmPL
patch if the version of coccinelle is older than the one specified, with that
in place you can just upgrade when you want -- you'd just gain support for more
SmPL patches when you do. Without that coccinelle would not work (fail) on the
SmPL patch when tried. For this reason I originally had suggested perhaps
this series should be carried by Michal.

[0] 
https://lkml.kernel.org/r/1467238499-10889-1-git-send-email-mcg...@kernel.org
[1] https://lkml.kernel.org/r/20160713214539.ge6...@wotan.suse.de


It's glad to know these improvements. We'll watch their progress and
keep up in time. :)

Thanks,
Fengguang


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Luis R. Rodriguez
On Thu, Jul 14, 2016 at 10:23:36AM +0800, Fengguang Wu wrote:
> On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:
> >On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
> >>Hi Luis,
> >>
> >>On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> >>>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> The firmware API has had some issues a while ago, some of this is
> not well documented, and its still hard to grasp. This documents
> some of these issues, adds SmPL grammar rules to enable us to hunt
> for issues, and annotations to help us with our effort to finally
> compartamentalize that pesky usermode helper.
> 
> Previously this was just one patch, the grammar rule to help
> find request firmware API users on init or probe, this series
> extends that effort with usermode helper grammar rules, and some
> annotations and documentation on the firmware_class driver to
> avoid further issues. Documenting the usermode helper and making
> it clear why we cannot remove it is important for analysis for
> the next series which adds the new flexible sysdata firmware API.
> 
> This series depends on the coccicheck series which enables
> annotations on coccinelle patches to require a specific
> version of coccinelle [0], as such coordination with Michal is
> in order.
> >>>
> >>>Michal is out until July 11, and upon further thought such coordination
> >>>is not need, the annotation is in place as comments and as such
> >>>merging this now won't have any negative effects other than the version
> >>>check. Also the patches in question for the coccicheck change are all
> >>>acked now and I expect them to be merged anyway.
> >>>
> >>>Which tree should firmware changes go through ?
> >>
> This series is also further extended next with the new sydata
> API, the full set of changes is available on my linux-next tree [1].
> 
> Perhaps now a good time to discuss -- if 0-day should enable the rule
> scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> every 0-day iteration, it runs rather fast and it should help police
> against avoiding futher explicit users of the usermode helper.
> >>>
> >>>And if we are going to merge this anyone oppose enabling hunting
> >>>for further explicit users of the usermode helper using grammar through
> >>>0-day ?
> >>
> >>When *.cocci scripts lands upstream they'll be auto picked up by the
> >>0-day bot to guard new patches/commits.
> >
> >Great thanks!
> >
> >>Are there further steps 0-day should do for request_firmware-upstream.cocci?
> >
> >It just requires coccinelle >= 1.0.5.
> 
> That looks easy. 

Nice!

> When do you estimate the script will land upstream?

Well, this series has gone by a while now without any complaints, so
I was poking to see if they can be merged now.

> So we can make sure upgrade coccinelle before that time.

There is another series which modernizes coccicheck [0] for which I just poked
at as a well [1], one change which may be of importance to you is groks the
Requires: tag on top of an SmPL patch, with that we simply just skip an SmPL
patch if the version of coccinelle is older than the one specified, with that
in place you can just upgrade when you want -- you'd just gain support for more
SmPL patches when you do. Without that coccinelle would not work (fail) on the
SmPL patch when tried. For this reason I originally had suggested perhaps
this series should be carried by Michal.

[0] 
https://lkml.kernel.org/r/1467238499-10889-1-git-send-email-mcg...@kernel.org
[1] https://lkml.kernel.org/r/20160713214539.ge6...@wotan.suse.de

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Luis R. Rodriguez
On Thu, Jul 14, 2016 at 10:23:36AM +0800, Fengguang Wu wrote:
> On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:
> >On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
> >>Hi Luis,
> >>
> >>On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> >>>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> The firmware API has had some issues a while ago, some of this is
> not well documented, and its still hard to grasp. This documents
> some of these issues, adds SmPL grammar rules to enable us to hunt
> for issues, and annotations to help us with our effort to finally
> compartamentalize that pesky usermode helper.
> 
> Previously this was just one patch, the grammar rule to help
> find request firmware API users on init or probe, this series
> extends that effort with usermode helper grammar rules, and some
> annotations and documentation on the firmware_class driver to
> avoid further issues. Documenting the usermode helper and making
> it clear why we cannot remove it is important for analysis for
> the next series which adds the new flexible sysdata firmware API.
> 
> This series depends on the coccicheck series which enables
> annotations on coccinelle patches to require a specific
> version of coccinelle [0], as such coordination with Michal is
> in order.
> >>>
> >>>Michal is out until July 11, and upon further thought such coordination
> >>>is not need, the annotation is in place as comments and as such
> >>>merging this now won't have any negative effects other than the version
> >>>check. Also the patches in question for the coccicheck change are all
> >>>acked now and I expect them to be merged anyway.
> >>>
> >>>Which tree should firmware changes go through ?
> >>
> This series is also further extended next with the new sydata
> API, the full set of changes is available on my linux-next tree [1].
> 
> Perhaps now a good time to discuss -- if 0-day should enable the rule
> scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> every 0-day iteration, it runs rather fast and it should help police
> against avoiding futher explicit users of the usermode helper.
> >>>
> >>>And if we are going to merge this anyone oppose enabling hunting
> >>>for further explicit users of the usermode helper using grammar through
> >>>0-day ?
> >>
> >>When *.cocci scripts lands upstream they'll be auto picked up by the
> >>0-day bot to guard new patches/commits.
> >
> >Great thanks!
> >
> >>Are there further steps 0-day should do for request_firmware-upstream.cocci?
> >
> >It just requires coccinelle >= 1.0.5.
> 
> That looks easy. 

Nice!

> When do you estimate the script will land upstream?

Well, this series has gone by a while now without any complaints, so
I was poking to see if they can be merged now.

> So we can make sure upgrade coccinelle before that time.

There is another series which modernizes coccicheck [0] for which I just poked
at as a well [1], one change which may be of importance to you is groks the
Requires: tag on top of an SmPL patch, with that we simply just skip an SmPL
patch if the version of coccinelle is older than the one specified, with that
in place you can just upgrade when you want -- you'd just gain support for more
SmPL patches when you do. Without that coccinelle would not work (fail) on the
SmPL patch when tried. For this reason I originally had suggested perhaps
this series should be carried by Michal.

[0] 
https://lkml.kernel.org/r/1467238499-10889-1-git-send-email-mcg...@kernel.org
[1] https://lkml.kernel.org/r/20160713214539.ge6...@wotan.suse.de

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Fengguang Wu

On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:

On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:

Hi Luis,

On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
>>The firmware API has had some issues a while ago, some of this is
>>not well documented, and its still hard to grasp. This documents
>>some of these issues, adds SmPL grammar rules to enable us to hunt
>>for issues, and annotations to help us with our effort to finally
>>compartamentalize that pesky usermode helper.
>>
>>Previously this was just one patch, the grammar rule to help
>>find request firmware API users on init or probe, this series
>>extends that effort with usermode helper grammar rules, and some
>>annotations and documentation on the firmware_class driver to
>>avoid further issues. Documenting the usermode helper and making
>>it clear why we cannot remove it is important for analysis for
>>the next series which adds the new flexible sysdata firmware API.
>>
>>This series depends on the coccicheck series which enables
>>annotations on coccinelle patches to require a specific
>>version of coccinelle [0], as such coordination with Michal is
>>in order.
>
>Michal is out until July 11, and upon further thought such coordination
>is not need, the annotation is in place as comments and as such
>merging this now won't have any negative effects other than the version
>check. Also the patches in question for the coccicheck change are all
>acked now and I expect them to be merged anyway.
>
>Which tree should firmware changes go through ?

>>This series is also further extended next with the new sydata
>>API, the full set of changes is available on my linux-next tree [1].
>>
>>Perhaps now a good time to discuss -- if 0-day should enable the rule
>>scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
>>every 0-day iteration, it runs rather fast and it should help police
>>against avoiding futher explicit users of the usermode helper.
>
>And if we are going to merge this anyone oppose enabling hunting
>for further explicit users of the usermode helper using grammar through
>0-day ?

When *.cocci scripts lands upstream they'll be auto picked up by the
0-day bot to guard new patches/commits.


Great thanks!


Are there further steps 0-day should do for request_firmware-upstream.cocci?


It just requires coccinelle >= 1.0.5.


That looks easy. When do you estimate the script will land upstream?
So we can make sure upgrade coccinelle before that time.

Thanks,
Fengguang


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Fengguang Wu

On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:

On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:

Hi Luis,

On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
>>The firmware API has had some issues a while ago, some of this is
>>not well documented, and its still hard to grasp. This documents
>>some of these issues, adds SmPL grammar rules to enable us to hunt
>>for issues, and annotations to help us with our effort to finally
>>compartamentalize that pesky usermode helper.
>>
>>Previously this was just one patch, the grammar rule to help
>>find request firmware API users on init or probe, this series
>>extends that effort with usermode helper grammar rules, and some
>>annotations and documentation on the firmware_class driver to
>>avoid further issues. Documenting the usermode helper and making
>>it clear why we cannot remove it is important for analysis for
>>the next series which adds the new flexible sysdata firmware API.
>>
>>This series depends on the coccicheck series which enables
>>annotations on coccinelle patches to require a specific
>>version of coccinelle [0], as such coordination with Michal is
>>in order.
>
>Michal is out until July 11, and upon further thought such coordination
>is not need, the annotation is in place as comments and as such
>merging this now won't have any negative effects other than the version
>check. Also the patches in question for the coccicheck change are all
>acked now and I expect them to be merged anyway.
>
>Which tree should firmware changes go through ?

>>This series is also further extended next with the new sydata
>>API, the full set of changes is available on my linux-next tree [1].
>>
>>Perhaps now a good time to discuss -- if 0-day should enable the rule
>>scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
>>every 0-day iteration, it runs rather fast and it should help police
>>against avoiding futher explicit users of the usermode helper.
>
>And if we are going to merge this anyone oppose enabling hunting
>for further explicit users of the usermode helper using grammar through
>0-day ?

When *.cocci scripts lands upstream they'll be auto picked up by the
0-day bot to guard new patches/commits.


Great thanks!


Are there further steps 0-day should do for request_firmware-upstream.cocci?


It just requires coccinelle >= 1.0.5.


That looks easy. When do you estimate the script will land upstream?
So we can make sure upgrade coccinelle before that time.

Thanks,
Fengguang


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Luis R. Rodriguez
On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
> Hi Luis,
> 
> On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> >On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> >>The firmware API has had some issues a while ago, some of this is
> >>not well documented, and its still hard to grasp. This documents
> >>some of these issues, adds SmPL grammar rules to enable us to hunt
> >>for issues, and annotations to help us with our effort to finally
> >>compartamentalize that pesky usermode helper.
> >>
> >>Previously this was just one patch, the grammar rule to help
> >>find request firmware API users on init or probe, this series
> >>extends that effort with usermode helper grammar rules, and some
> >>annotations and documentation on the firmware_class driver to
> >>avoid further issues. Documenting the usermode helper and making
> >>it clear why we cannot remove it is important for analysis for
> >>the next series which adds the new flexible sysdata firmware API.
> >>
> >>This series depends on the coccicheck series which enables
> >>annotations on coccinelle patches to require a specific
> >>version of coccinelle [0], as such coordination with Michal is
> >>in order.
> >
> >Michal is out until July 11, and upon further thought such coordination
> >is not need, the annotation is in place as comments and as such
> >merging this now won't have any negative effects other than the version
> >check. Also the patches in question for the coccicheck change are all
> >acked now and I expect them to be merged anyway.
> >
> >Which tree should firmware changes go through ?
> 
> >>This series is also further extended next with the new sydata
> >>API, the full set of changes is available on my linux-next tree [1].
> >>
> >>Perhaps now a good time to discuss -- if 0-day should enable the rule
> >>scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> >>every 0-day iteration, it runs rather fast and it should help police
> >>against avoiding futher explicit users of the usermode helper.
> >
> >And if we are going to merge this anyone oppose enabling hunting
> >for further explicit users of the usermode helper using grammar through
> >0-day ?
> 
> When *.cocci scripts lands upstream they'll be auto picked up by the
> 0-day bot to guard new patches/commits.

Great thanks!

> Are there further steps 0-day should do for request_firmware-upstream.cocci?

It just requires coccinelle >= 1.0.5.

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Luis R. Rodriguez
On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
> Hi Luis,
> 
> On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> >On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> >>The firmware API has had some issues a while ago, some of this is
> >>not well documented, and its still hard to grasp. This documents
> >>some of these issues, adds SmPL grammar rules to enable us to hunt
> >>for issues, and annotations to help us with our effort to finally
> >>compartamentalize that pesky usermode helper.
> >>
> >>Previously this was just one patch, the grammar rule to help
> >>find request firmware API users on init or probe, this series
> >>extends that effort with usermode helper grammar rules, and some
> >>annotations and documentation on the firmware_class driver to
> >>avoid further issues. Documenting the usermode helper and making
> >>it clear why we cannot remove it is important for analysis for
> >>the next series which adds the new flexible sysdata firmware API.
> >>
> >>This series depends on the coccicheck series which enables
> >>annotations on coccinelle patches to require a specific
> >>version of coccinelle [0], as such coordination with Michal is
> >>in order.
> >
> >Michal is out until July 11, and upon further thought such coordination
> >is not need, the annotation is in place as comments and as such
> >merging this now won't have any negative effects other than the version
> >check. Also the patches in question for the coccicheck change are all
> >acked now and I expect them to be merged anyway.
> >
> >Which tree should firmware changes go through ?
> 
> >>This series is also further extended next with the new sydata
> >>API, the full set of changes is available on my linux-next tree [1].
> >>
> >>Perhaps now a good time to discuss -- if 0-day should enable the rule
> >>scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> >>every 0-day iteration, it runs rather fast and it should help police
> >>against avoiding futher explicit users of the usermode helper.
> >
> >And if we are going to merge this anyone oppose enabling hunting
> >for further explicit users of the usermode helper using grammar through
> >0-day ?
> 
> When *.cocci scripts lands upstream they'll be auto picked up by the
> 0-day bot to guard new patches/commits.

Great thanks!

> Are there further steps 0-day should do for request_firmware-upstream.cocci?

It just requires coccinelle >= 1.0.5.

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Fengguang Wu

Hi Luis,

On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:

On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:

The firmware API has had some issues a while ago, some of this is
not well documented, and its still hard to grasp. This documents
some of these issues, adds SmPL grammar rules to enable us to hunt
for issues, and annotations to help us with our effort to finally
compartamentalize that pesky usermode helper.

Previously this was just one patch, the grammar rule to help
find request firmware API users on init or probe, this series
extends that effort with usermode helper grammar rules, and some
annotations and documentation on the firmware_class driver to
avoid further issues. Documenting the usermode helper and making
it clear why we cannot remove it is important for analysis for
the next series which adds the new flexible sysdata firmware API.

This series depends on the coccicheck series which enables
annotations on coccinelle patches to require a specific
version of coccinelle [0], as such coordination with Michal is
in order.


Michal is out until July 11, and upon further thought such coordination
is not need, the annotation is in place as comments and as such
merging this now won't have any negative effects other than the version
check. Also the patches in question for the coccicheck change are all
acked now and I expect them to be merged anyway.

Which tree should firmware changes go through ?



This series is also further extended next with the new sydata
API, the full set of changes is available on my linux-next tree [1].

Perhaps now a good time to discuss -- if 0-day should enable the rule
scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
every 0-day iteration, it runs rather fast and it should help police
against avoiding futher explicit users of the usermode helper.


And if we are going to merge this anyone oppose enabling hunting
for further explicit users of the usermode helper using grammar through
0-day ?


When *.cocci scripts lands upstream they'll be auto picked up by the
0-day bot to guard new patches/commits. Are there further steps 0-day
should do for request_firmware-upstream.cocci?

Thanks,
Fengguang



[0] 
https://lkml.kernel.org/r/1466116292-21843-1-git-send-email-mcg...@kernel.org
[1] 
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2

Luis R. Rodriguez (5):
  MAINTAINERS: extend firmware_class maintainer list
  firmware: annotate thou shalt not request fw on init or probe
  firmware: update usermode helper docs and add SmPL report
  firmware: add usermode helper DECLARE_FW_LOADER_USER() annotation
  firmware: fix fw cache to avoid usermode helper on suspend

 Documentation/firmware_class/README|  59 +-
 MAINTAINERS|   1 +
 drivers/base/Kconfig   |   2 +-
 drivers/base/firmware_class.c  |   2 +-
 drivers/firmware/dell_rbu.c|   1 +
 drivers/leds/leds-lp55xx-common.c  |   1 +
 include/linux/firmware.h   |   7 ++
 .../request_firmware-avoid-init-probe-init.cocci   | 130 +
 .../coccinelle/api/request_firmware-usermode.cocci |  44 +++
 9 files changed, 240 insertions(+), 7 deletions(-)
 create mode 100644 
scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
 create mode 100644 scripts/coccinelle/api/request_firmware-usermode.cocci

--
2.8.2




--
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Fengguang Wu

Hi Luis,

On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:

On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:

The firmware API has had some issues a while ago, some of this is
not well documented, and its still hard to grasp. This documents
some of these issues, adds SmPL grammar rules to enable us to hunt
for issues, and annotations to help us with our effort to finally
compartamentalize that pesky usermode helper.

Previously this was just one patch, the grammar rule to help
find request firmware API users on init or probe, this series
extends that effort with usermode helper grammar rules, and some
annotations and documentation on the firmware_class driver to
avoid further issues. Documenting the usermode helper and making
it clear why we cannot remove it is important for analysis for
the next series which adds the new flexible sysdata firmware API.

This series depends on the coccicheck series which enables
annotations on coccinelle patches to require a specific
version of coccinelle [0], as such coordination with Michal is
in order.


Michal is out until July 11, and upon further thought such coordination
is not need, the annotation is in place as comments and as such
merging this now won't have any negative effects other than the version
check. Also the patches in question for the coccicheck change are all
acked now and I expect them to be merged anyway.

Which tree should firmware changes go through ?



This series is also further extended next with the new sydata
API, the full set of changes is available on my linux-next tree [1].

Perhaps now a good time to discuss -- if 0-day should enable the rule
scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
every 0-day iteration, it runs rather fast and it should help police
against avoiding futher explicit users of the usermode helper.


And if we are going to merge this anyone oppose enabling hunting
for further explicit users of the usermode helper using grammar through
0-day ?


When *.cocci scripts lands upstream they'll be auto picked up by the
0-day bot to guard new patches/commits. Are there further steps 0-day
should do for request_firmware-upstream.cocci?

Thanks,
Fengguang



[0] 
https://lkml.kernel.org/r/1466116292-21843-1-git-send-email-mcg...@kernel.org
[1] 
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2

Luis R. Rodriguez (5):
  MAINTAINERS: extend firmware_class maintainer list
  firmware: annotate thou shalt not request fw on init or probe
  firmware: update usermode helper docs and add SmPL report
  firmware: add usermode helper DECLARE_FW_LOADER_USER() annotation
  firmware: fix fw cache to avoid usermode helper on suspend

 Documentation/firmware_class/README|  59 +-
 MAINTAINERS|   1 +
 drivers/base/Kconfig   |   2 +-
 drivers/base/firmware_class.c  |   2 +-
 drivers/firmware/dell_rbu.c|   1 +
 drivers/leds/leds-lp55xx-common.c  |   1 +
 include/linux/firmware.h   |   7 ++
 .../request_firmware-avoid-init-probe-init.cocci   | 130 +
 .../coccinelle/api/request_firmware-usermode.cocci |  44 +++
 9 files changed, 240 insertions(+), 7 deletions(-)
 create mode 100644 
scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
 create mode 100644 scripts/coccinelle/api/request_firmware-usermode.cocci

--
2.8.2




--
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Luis R. Rodriguez
On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > The firmware API has had some issues a while ago, some of this is
> > not well documented, and its still hard to grasp. This documents
> > some of these issues, adds SmPL grammar rules to enable us to hunt
> > for issues, and annotations to help us with our effort to finally
> > compartamentalize that pesky usermode helper.
> > 
> > Previously this was just one patch, the grammar rule to help
> > find request firmware API users on init or probe, this series
> > extends that effort with usermode helper grammar rules, and some
> > annotations and documentation on the firmware_class driver to
> > avoid further issues. Documenting the usermode helper and making
> > it clear why we cannot remove it is important for analysis for
> > the next series which adds the new flexible sysdata firmware API.
> > 
> > This series depends on the coccicheck series which enables
> > annotations on coccinelle patches to require a specific
> > version of coccinelle [0], as such coordination with Michal is
> > in order.
> 
> Michal is out until July 11, and upon further thought such coordination
> is not need, the annotation is in place as comments and as such
> merging this now won't have any negative effects other than the version
> check. Also the patches in question for the coccicheck change are all
> acked now and I expect them to be merged anyway.
> 
> Which tree should firmware changes go through ?
> 
> > This series is also further extended next with the new sydata
> > API, the full set of changes is available on my linux-next tree [1].
> > 
> > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > every 0-day iteration, it runs rather fast and it should help police
> > against avoiding futher explicit users of the usermode helper.
> 
> And if we are going to merge this anyone oppose enabling hunting
> for further explicit users of the usermode helper using grammar through
> 0-day ?

*Poke*

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-13 Thread Luis R. Rodriguez
On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> > The firmware API has had some issues a while ago, some of this is
> > not well documented, and its still hard to grasp. This documents
> > some of these issues, adds SmPL grammar rules to enable us to hunt
> > for issues, and annotations to help us with our effort to finally
> > compartamentalize that pesky usermode helper.
> > 
> > Previously this was just one patch, the grammar rule to help
> > find request firmware API users on init or probe, this series
> > extends that effort with usermode helper grammar rules, and some
> > annotations and documentation on the firmware_class driver to
> > avoid further issues. Documenting the usermode helper and making
> > it clear why we cannot remove it is important for analysis for
> > the next series which adds the new flexible sysdata firmware API.
> > 
> > This series depends on the coccicheck series which enables
> > annotations on coccinelle patches to require a specific
> > version of coccinelle [0], as such coordination with Michal is
> > in order.
> 
> Michal is out until July 11, and upon further thought such coordination
> is not need, the annotation is in place as comments and as such
> merging this now won't have any negative effects other than the version
> check. Also the patches in question for the coccicheck change are all
> acked now and I expect them to be merged anyway.
> 
> Which tree should firmware changes go through ?
> 
> > This series is also further extended next with the new sydata
> > API, the full set of changes is available on my linux-next tree [1].
> > 
> > Perhaps now a good time to discuss -- if 0-day should enable the rule
> > scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> > every 0-day iteration, it runs rather fast and it should help police
> > against avoiding futher explicit users of the usermode helper.
> 
> And if we are going to merge this anyone oppose enabling hunting
> for further explicit users of the usermode helper using grammar through
> 0-day ?

*Poke*

  Luis


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-06 Thread Luis R. Rodriguez
On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> The firmware API has had some issues a while ago, some of this is
> not well documented, and its still hard to grasp. This documents
> some of these issues, adds SmPL grammar rules to enable us to hunt
> for issues, and annotations to help us with our effort to finally
> compartamentalize that pesky usermode helper.
> 
> Previously this was just one patch, the grammar rule to help
> find request firmware API users on init or probe, this series
> extends that effort with usermode helper grammar rules, and some
> annotations and documentation on the firmware_class driver to
> avoid further issues. Documenting the usermode helper and making
> it clear why we cannot remove it is important for analysis for
> the next series which adds the new flexible sysdata firmware API.
> 
> This series depends on the coccicheck series which enables
> annotations on coccinelle patches to require a specific
> version of coccinelle [0], as such coordination with Michal is
> in order.

Michal is out until July 11, and upon further thought such coordination
is not need, the annotation is in place as comments and as such
merging this now won't have any negative effects other than the version
check. Also the patches in question for the coccicheck change are all
acked now and I expect them to be merged anyway.

Which tree should firmware changes go through ?

> This series is also further extended next with the new sydata
> API, the full set of changes is available on my linux-next tree [1].
> 
> Perhaps now a good time to discuss -- if 0-day should enable the rule
> scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> every 0-day iteration, it runs rather fast and it should help police
> against avoiding futher explicit users of the usermode helper.

And if we are going to merge this anyone oppose enabling hunting
for further explicit users of the usermode helper using grammar through
0-day ?

  Luis

> 
> [0] 
> https://lkml.kernel.org/r/1466116292-21843-1-git-send-email-mcg...@kernel.org
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2
> 
> Luis R. Rodriguez (5):
>   MAINTAINERS: extend firmware_class maintainer list
>   firmware: annotate thou shalt not request fw on init or probe
>   firmware: update usermode helper docs and add SmPL report
>   firmware: add usermode helper DECLARE_FW_LOADER_USER() annotation
>   firmware: fix fw cache to avoid usermode helper on suspend
> 
>  Documentation/firmware_class/README|  59 +-
>  MAINTAINERS|   1 +
>  drivers/base/Kconfig   |   2 +-
>  drivers/base/firmware_class.c  |   2 +-
>  drivers/firmware/dell_rbu.c|   1 +
>  drivers/leds/leds-lp55xx-common.c  |   1 +
>  include/linux/firmware.h   |   7 ++
>  .../request_firmware-avoid-init-probe-init.cocci   | 130 
> +
>  .../coccinelle/api/request_firmware-usermode.cocci |  44 +++
>  9 files changed, 240 insertions(+), 7 deletions(-)
>  create mode 100644 
> scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
>  create mode 100644 scripts/coccinelle/api/request_firmware-usermode.cocci
> 
> -- 
> 2.8.2
> 
> 

-- 
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg


Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

2016-07-06 Thread Luis R. Rodriguez
On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> The firmware API has had some issues a while ago, some of this is
> not well documented, and its still hard to grasp. This documents
> some of these issues, adds SmPL grammar rules to enable us to hunt
> for issues, and annotations to help us with our effort to finally
> compartamentalize that pesky usermode helper.
> 
> Previously this was just one patch, the grammar rule to help
> find request firmware API users on init or probe, this series
> extends that effort with usermode helper grammar rules, and some
> annotations and documentation on the firmware_class driver to
> avoid further issues. Documenting the usermode helper and making
> it clear why we cannot remove it is important for analysis for
> the next series which adds the new flexible sysdata firmware API.
> 
> This series depends on the coccicheck series which enables
> annotations on coccinelle patches to require a specific
> version of coccinelle [0], as such coordination with Michal is
> in order.

Michal is out until July 11, and upon further thought such coordination
is not need, the annotation is in place as comments and as such
merging this now won't have any negative effects other than the version
check. Also the patches in question for the coccicheck change are all
acked now and I expect them to be merged anyway.

Which tree should firmware changes go through ?

> This series is also further extended next with the new sydata
> API, the full set of changes is available on my linux-next tree [1].
> 
> Perhaps now a good time to discuss -- if 0-day should enable the rule
> scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> every 0-day iteration, it runs rather fast and it should help police
> against avoiding futher explicit users of the usermode helper.

And if we are going to merge this anyone oppose enabling hunting
for further explicit users of the usermode helper using grammar through
0-day ?

  Luis

> 
> [0] 
> https://lkml.kernel.org/r/1466116292-21843-1-git-send-email-mcg...@kernel.org
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160616-sysdata-v2
> 
> Luis R. Rodriguez (5):
>   MAINTAINERS: extend firmware_class maintainer list
>   firmware: annotate thou shalt not request fw on init or probe
>   firmware: update usermode helper docs and add SmPL report
>   firmware: add usermode helper DECLARE_FW_LOADER_USER() annotation
>   firmware: fix fw cache to avoid usermode helper on suspend
> 
>  Documentation/firmware_class/README|  59 +-
>  MAINTAINERS|   1 +
>  drivers/base/Kconfig   |   2 +-
>  drivers/base/firmware_class.c  |   2 +-
>  drivers/firmware/dell_rbu.c|   1 +
>  drivers/leds/leds-lp55xx-common.c  |   1 +
>  include/linux/firmware.h   |   7 ++
>  .../request_firmware-avoid-init-probe-init.cocci   | 130 
> +
>  .../coccinelle/api/request_firmware-usermode.cocci |  44 +++
>  9 files changed, 240 insertions(+), 7 deletions(-)
>  create mode 100644 
> scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
>  create mode 100644 scripts/coccinelle/api/request_firmware-usermode.cocci
> 
> -- 
> 2.8.2
> 
> 

-- 
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg