Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-08-09 Thread Andrew Morton
On Fri, 9 Aug 2013 15:21:04 -0700 Kees Cook wrote: > Hi, > > On Wed, Aug 07, 2013 at 03:19:03PM +1000, Stephen Rothwell wrote: > > Hi Andrew, > > > > list_for_each_safe(cur, tmp, &sbi->s_es_lru) { > > + int ret; > > + > > /* > > * If we have already recla

Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-08-09 Thread Kees Cook
Hi, On Wed, Aug 07, 2013 at 03:19:03PM +1000, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm tree got a conflict in > fs/ext4/extents_status.c between commit 49c6efc7b80e ("ext4: add new > ioctl EXT4_IOC_PRECACHE_EXTENTS") from the ext4 tree and commit > "fs-convert

linux-next: manual merge of the akpm tree with the ext4 tree

2013-08-06 Thread Stephen Rothwell
Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in fs/ext4/extents_status.c between commit 49c6efc7b80e ("ext4: add new ioctl EXT4_IOC_PRECACHE_EXTENTS") from the ext4 tree and commit "fs-convert-fs-shrinkers-to-new-scan-count-api-fix" from the akpm tree. I fixed it up (see be

linux-next: manual merge of the akpm tree with the ext4 tree

2013-08-06 Thread Stephen Rothwell
Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in fs/ext4/extents_status.c between commit 49c6efc7b80e ("ext4: add new ioctl EXT4_IOC_PRECACHE_EXTENTS") from the ext4 tree and commit "fs: convert fs shrinkers to new scan/count API" from the akpm tree. I fixed it up (see below

linux-next: manual merge of the akpm tree with the ext4 tree

2013-07-15 Thread Stephen Rothwell
Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in fs/ext4/extents_status.c between commit decae3aab047 ("ext4: make the extent_status code more robust against ENOMEM failures") from the ext4 tree and commit "fs-convert-fs-shrinkers-to-new-scan-count-api-fix" from the akpm tree

linux-next: manual merge of the akpm tree with the ext4 tree

2013-07-15 Thread Stephen Rothwell
Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in fs/ext4/extents_status.c between commit decae3aab047 ("ext4: make the extent_status code more robust against ENOMEM failures") from the ext4 tree and commit "fs: convert fs shrinkers to new scan/count API" from the akpm tree.

Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-06-19 Thread Glauber Costa
On Wed, Jun 19, 2013 at 02:59:17PM -0400, Theodore Ts'o wrote: > On Wed, Jun 19, 2013 at 10:06:35AM -0700, Andrew Morton wrote: > > > > Merge the ext4 change early, please. The core shrinker changes aren't > > 100% certain at this time - first they need to stop oopsing ;) > > Ack, sounds like a

Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-06-19 Thread Theodore Ts'o
On Wed, Jun 19, 2013 at 10:06:35AM -0700, Andrew Morton wrote: > > Merge the ext4 change early, please. The core shrinker changes aren't > 100% certain at this time - first they need to stop oopsing ;) Ack, sounds like a plan. Are they oopsing often enough that they are likely to interfere with

Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-06-19 Thread Andrew Morton
On Wed, 19 Jun 2013 10:20:31 -0400 "Theodore Ts'o" wrote: > Is there some way we can avoid this conflict during the next merge > window? Given that this is an API change, it may not be possible. > Failing that, what's the best merge strategy; should we try to make > sure your change goes first,

Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-06-19 Thread Theodore Ts'o
Is there some way we can avoid this conflict during the next merge window? Given that this is an API change, it may not be possible. Failing that, what's the best merge strategy; should we try to make sure your change goes first, and then I can defer the ext4 pull request until a little bit later

Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-06-19 Thread Zheng Liu
Hi Stephen, On Jun 19, 2013, at 3:27 PM, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm tree got a conflict in > fs/ext4/extents_status.c between commit 6480bad916be ("ext4: improve > extent cache shrink mechanism to avoid to burn CPU time") from the ext > tree an

Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-06-19 Thread Stephen Rothwell
Hi, On Wed, 19 Jun 2013 11:44:04 +0400 Glauber Costa wrote: > > I believe the resolution is okay, at least from our PoV. Thanks for checking. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpBSc9vjcXZb.pgp Description: PGP signature

Re: linux-next: manual merge of the akpm tree with the ext4 tree

2013-06-19 Thread Glauber Costa
On Wed, Jun 19, 2013 at 05:27:21PM +1000, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm tree got a conflict in > fs/ext4/extents_status.c between commit 6480bad916be ("ext4: improve > extent cache shrink mechanism to avoid to burn CPU time") from the ext > tree and

linux-next: manual merge of the akpm tree with the ext4 tree

2013-06-19 Thread Stephen Rothwell
Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in fs/ext4/extents_status.c between commit 6480bad916be ("ext4: improve extent cache shrink mechanism to avoid to burn CPU time") from the ext tree and commit 1f42d0934b4e ("fs: convert fs shrinkers to new scan/count API") from th

linux-next: manual merge of the akpm tree with the ext4 tree

2012-07-15 Thread Stephen Rothwell
Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in fs/ext4/bitmap.c between commit f6fb99cadcd4 ("ext4: pass a char * to ext4_count_free() instead of a buffer_head ptr") from the ext4 tree and commit "ext4: use memweight()" from the akpm tree. I fixed it up (I hope - see below