On Thu, Mar 06, 2014 at 10:05:00AM -0800, Greg Kroah-Hartman wrote: > On Thu, Mar 06, 2014 at 06:13:38PM +0100, Francis Moreau wrote: > > 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. > > I don't think you understand the quantity of patches involved here. > Just look at all of the patches that go into the "latest" stable > release. It's averaging over 100 patches a week. About 30-40 of them > aer relevant for the 3.4 kernel, so that means you would have to do > research on 60-70 patches a week. > > Who would be willing to look at that stream? Again, I sure don't... Also realize that the huge majority of those patches are not relevant. The number of relevant patches after 1 year falls off very dramatically. greg k-h -- 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