Re: [3.4.x] missing patches for 3.4.x

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/06/2014 05:45 PM, Greg Kroah-Hartman wrote:
> On Thu, Mar 06, 2014 at 05:42:49PM +0100, Francis Moreau wrote:
>> On 03/05/2014 07:54 PM, Greg Kroah-Hartman wrote:
>>> On Sat, Feb 22, 2014 at 06:45:46PM +0800, Rui Xiang wrote:
>>>> Hi Greg,
>>>>
>>>> These are a bunch of commits from the list of upstream commits
>>>> that have been backported to 3.2 but missing from 3.4.
>>>>
>>>> For the 14 commits,
>>>>  - 12 commits were marked for stable but can't be applied cleanly to
>>>>    3.4.x.
>>>>  - 1 commit is not a bug fix, but a prerequisite for a commit which 
>>>>    had been backported to 3.4.x without this commit. So it needn't to be
>>>>    applied.
>>>>  - 1 commit has no stable tag. I've found out why it was backported
>>>>    to 3.2.x, and I'm sure it should be applied to 3.4.x.
>>>>
>>>> Please cherry-pick these commits from 3.2.x:
>>>>
>>>> ccebcc74c81d  nilfs2: fix issue with race condition of competition between segments for dirty blocks
>>>> b5f9e3533584  fuse: readdir: check for slash in names
>>>> 941781515755  fuse: hotfix truncate_pagecache() issue
>>>> be47dfad8e39  libceph: unregister request in __map_request failed and nofail == false
>>>> eb4a22ba43d9  cifs: don't instantiate new dentries in readdir for inodes that need to be revalidated immediately
>>>> 21544884d7d5  ncpfs: fix rmdir returns Device or resource busy
>>>> 164ed4383ca6  ext4/jbd2: don't wait (forever) for stale tid caused by wraparound
>>>> 2ff3ae3932b9  UBIFS: fix double free of ubifs_orphan objects
>>>> 3e411534ea3b  ext4: fix possible use-after-free with AIO
>>>> f6f82cba2ccb  cifs: adjust sequence number downward after signing NT_CANCEL request
>>>>
>>>> There are 3 other commits that need some adjustments. I'll send
>>>> out the backports.
>>>
>>> Thanks so much for this, I've now included these commits, and the 3
>>> other.
>>>
>>
>> Just out of curiosity, why are those commits missing from the 3.4.x
>> stable tree but not from the 3.2.x one ?
> 
> Because they required manual backporting to the 3.4.x kernel, and Ben
> did that work.  With my workload, I can't take the time to backport
> every stable patch to the 3.4.x tree, I rely on the subsystem
> maintainers and others, to do this work.
> 

Thanks for clarifying.

Maybe you should put a list of commits which need to be backported (in
hold state). It might be better than possibly forgetting them.

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]