Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

[Sasha Levin]

Hi.

[This is an automated email]

This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 13.1846)

The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, 

v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
    3920ad4951e2 ("usbip: vhc_hcd: prevent module being removed while device are attached")
    a38711a88b7e ("usbip: auto retry for concurrent attach")

v4.4.126: Failed to apply! Possible dependencies:
    0775a9cbc694 ("usbip: vhci extension: modifications to vhci driver")
    3920ad4951e2 ("usbip: vhc_hcd: prevent module being removed while device are attached")
    a38711a88b7e ("usbip: auto retry for concurrent attach")


Please let us know if you'd like to have this patch included in a stable tree.

--
Thanks.
Sasha

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

[Shuah Khan]

On 04/05/2018 10:42 AM, Sasha Levin wrote:
> Hi.
> 
> [This is an automated email]
> 
> This commit has been processed by the -stable helper bot and determined
> to be a high probability candidate for -stable trees. (score: 13.1846)
> 
> The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126, 
> 
> v4.15.15: Build OK!
> v4.14.32: Build OK!
> v4.9.92: Failed to apply! Possible dependencies:
>     3920ad4951e2 ("usbip: vhc_hcd: prevent module being removed while device are attached"> 
> v4.4.126: Failed to apply! Possible dependencies:
>     0775a9cbc694 ("usbip: vhci extension: modifications to vhci driver")
>     3920ad4951e2 ("usbip: vhc_hcd: prevent module being removed while device are attached")

This patch will not go into Linus's tree. Please don't pull it into stables.

thanks,
-- Shuah

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

[Sasha Levin]

On Thu, Apr 05, 2018 at 10:54:59AM -0600, Shuah Khan wrote:
>On 04/05/2018 10:42 AM, Sasha Levin wrote:
>> Hi.
>>
>> [This is an automated email]
>>
>> This commit has been processed by the -stable helper bot and determined
>> to be a high probability candidate for -stable trees. (score: 13.1846)
>>
>> The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
>>
>> v4.15.15: Build OK!
>> v4.14.32: Build OK!
>> v4.9.92: Failed to apply! Possible dependencies:
>>     3920ad4951e2 ("usbip: vhc_hcd: prevent module being removed while device are attached">
>> v4.4.126: Failed to apply! Possible dependencies:
>>     0775a9cbc694 ("usbip: vhci extension: modifications to vhci driver")
>>     3920ad4951e2 ("usbip: vhc_hcd: prevent module being removed while device are attached")
>
>This patch will not go into Linus's tree. Please don't pull it into stables.

Commits indeed won't be picked up unless they make it to Linus' tree
(per the -stable rules). I'll clarify that in future mails, thank you!

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

[Greg KH]

On Thu, Apr 05, 2018 at 04:42:46PM +0000, Sasha Levin wrote:
> Hi.
> 
> [This is an automated email]

Why are you running this against patches that are not yet in Linus's
tree?  That feels odd.  Only about 1/3 of the patches posted end up
being merged (at best), so don't do extra work by running this on
patches that might not even be merged at all.

thanks,

greg k-h

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

[Sasha Levin]

On Thu, Apr 05, 2018 at 09:11:02PM +0200, Greg KH wrote:
>On Thu, Apr 05, 2018 at 04:42:46PM +0000, Sasha Levin wrote:
>> Hi.
>>
>> [This is an automated email]
>
>Why are you running this against patches that are not yet in Linus's
>tree?  That feels odd.  Only about 1/3 of the patches posted end up
>being merged (at best), so don't do extra work by running this on
>patches that might not even be merged at all.

Sorry for late response, this got flagged as spam :/

I was testing out a different approach, that attempts to address the
following issues:

 - When we send a review request for a patch, it usually happens weeks
   after the patch went upstream. At that point developers have moved
   on, and we're less likely to get a helpful response.

 - Some patches are tagged for particular stable trees, but don't end up
   applying/failing build on them. Usually when you send your rejection
   mails for these patches, we see no response. This might mean that
   kernels that need a particular bugfix get missed because of things
   like trivial dependencies.

 - I was planning to integrate a larger set of testing to be done for
   these patches both on mainline, and on stable kernels. Like the XFS
   example, we could run xfstests for any given patch both on mainline
   and on any older stable trees this patch applied to, This would both
   help mainline development, and would encourage devs to address any
   issues it causes on stable kernels as well.