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, >s_es_lru) {
> > + int ret;
> > +
> > /*
> > * If we have already reclaimed
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
>
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
On Fri, 9 Aug 2013 15:21:04 -0700 Kees Cook k...@outflux.net 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
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
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
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)
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
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
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.
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.
I
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.
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
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
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,
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
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
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
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
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
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 the
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 commit
Hi,
On Wed, 19 Jun 2013 11:44:04 +0400 Glauber Costa glom...@gmail.com 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
Hi Stephen,
On Jun 19, 2013, at 3:27 PM, Stephen Rothwell s...@canb.auug.org.au 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
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
On Wed, 19 Jun 2013 10:20:31 -0400 Theodore Ts'o ty...@mit.edu 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
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
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 plan.
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
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)
30 matches
Mail list logo
