Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1496044 > unrolled thread

Re: [PATCH v5 1/5] firmware: document user mode helper lock usage

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 1/5] firmware: document user mode helper lock usage "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-10-05 22:50 +0200
    Re: [PATCH v5 1/5] firmware: document user mode helper lock usage "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-10-10 20:50 +0200

#1496044 — Re: [PATCH v5 1/5] firmware: document user mode helper lock usage

On Fri, Sep 23, 2016 at 10:13:44AM +0200, Daniel Wagner wrote:
> On 09/22/2016 04:36 AM, Ming Lei wrote:
> >On Sat, Sep 10, 2016 at 6:14 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> >>On Fri, Sep 09, 2016 at 02:12:20PM +0200, Daniel Wagner wrote:
> >>>From: Daniel Wagner <daniel.wagner@bmw-carit.de>
> >>>
> >>>The lock is also used to generate warnings when a direct
> >>>firmware load is requested too early.
> >>
> >>I've determined the firmware cache lets us bail out of this
> >>consideration now. If Ming agrees with the logic we don't need this
> >>patch and you can continue as you had intended. Sorry for the trouble.
> >
> >IMO it is helpful to add comment about using the lock for direct loading,
> >and we can sort it out in future if anyone want to improve it.
> >
> >So for this patch, I am fine.
> 
> Sorry, I am a bit confused now. What is the consensus here:
> 
>  a) add a comment to _request_firmware() as in this patch #1 v5

The adding a comment note from Daniel was that the UMH lock is *not*
needed on the direct firmware loading case, he's lazy to remove it
now so he'll just add a comment.

>  b) move the umh locking to fw_load_from_user_helper() as in
>     patch #1 v4

This is fine and IMHO the non-lazy approach.

To be clear -- I did my own vetting of the removal of the lock by
inspecting the original purpose of the UMH lock being added on the
history Linux git tree, having a secondary review of that would be
appreciated as well.

  Luis

[toc] | [next] | [standalone]

#1498480

On Fri, Oct 07, 2016 at 08:16:29AM +0200, Daniel Wagner wrote:
> > > Sorry, I am a bit confused now. What is the consensus here:
> > > 
> > >  a) add a comment to _request_firmware() as in this patch #1 v5
> > 
> > The adding a comment note from Daniel was that the UMH lock is *not*
> > needed on the direct firmware loading case, he's lazy to remove it
> > now so he'll just add a comment.
> 
> IIRC, we hadn't really settle on what the right solution is or I couldn't
> parse it. That is why I am asking specifically which version is the right
> thing. Don't worry I don't want to shortcut here :)

The removal of the lock from the general case is the right thing, I however
wanted Ming to also acknowledge this change, I suppose he can do so if you
supply a respin, or you can wait.

  Luis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web