Re: mmotm 2009-01-05-12-50 uploaded (ubifs)

Re: mmotm 2009-01-05-12-50 uploaded (ubifs)

[Randy Dunlap]

akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2009-01-05-12-50 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> 
> and will soon be available at
> 
>    git://git.zen-sources.org/zen/mmotm.git


mmotm-2009-0105-1250/fs/ubifs/super.c:435: error: 'WB_SYNC_HOLD' undeclared (first use in this function)


~Randy

Re: mmotm 2009-01-05-12-50 uploaded (ubifs)

[Andrew Morton]

On Mon, 05 Jan 2009 14:09:25 -0800
Randy Dunlap <randy.dunlap@oracle.com> wrote:

> akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2009-01-05-12-50 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> > 
> > and will soon be available at
> > 
> >    git://git.zen-sources.org/zen/mmotm.git
> 
> 
> mmotm-2009-0105-1250/fs/ubifs/super.c:435: error: 'WB_SYNC_HOLD' undeclared (first use in this function)
> 

It's amazing how much shiny new code turns up during the merge window
and screws things up.


commit 304d427cd99eb645b44b08d77e70ce308e6bcd8c
Author:     Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
AuthorDate: Sun Dec 28 08:04:17 2008 +0200
Commit:     Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
CommitDate: Wed Dec 31 14:13:24 2008 +0200

    UBIFS: fix file-system synchronization
    
    Argh. The ->sync_fs call is called _before_ all inodes are flushed.
    This means we first sync write buffers and commit, then all
    inodes are synced, and we end up with unflushed write buffers!
    
    Fix this by forcing synching all indoes from 'ubifs_sync_fs()'.
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 1309783..4713017 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -35,6 +35,7 @@
 #include <linux/seq_file.h>
 #include <linux/mount.h>
 #include <linux/math64.h>
+#include <linux/writeback.h>
 #include "ubifs.h"
 
 /*
@@ -431,6 +432,23 @@ static int ubifs_sync_fs(struct super_block *sb, int wait)
 	struct ubifs_info *c = sb->s_fs_info;
 	int i, ret = 0, err;
 	long long bud_bytes;
+	struct writeback_control wbc = {
+		.sync_mode   = wait ? WB_SYNC_ALL : WB_SYNC_HOLD,
+		.range_start = 0,
+		.range_end   = LLONG_MAX,
+		.nr_to_write = LONG_MAX,
+	};
+
+	/*
+	 * VFS calls '->sync_fs()' before synchronizing all dirty inodes and
+	 * pages, so synchronize them first, then commit the journal. Strictly
+	 * speaking, it is not necessary to commit the journal here,
+	 * synchronizing write-buffers would be enough. But committing makes
+	 * UBIFS free space predictions much more accurate, so we want to let
+	 * the user be able to get more accurate results of 'statfs()' after
+	 * they synchronize the file system.
+	 */
+	generic_sync_sb_inodes(sb, &wbc);
 
 	if (c->jheads) {
 		for (i = 0; i < c->jhead_cnt; i++) {


WB_SYNC_HOLD got removed by
http://userweb.kernel.org/~akpm/mmotm/broken-out/fs-remove-wb_sync_hold.patch

I think I'll just switch that to WB_SYNC_NONE.  The `wait==0' mode is
just an advisory thing to help the fs shove lots of data into the
queues.  If some gets missed then it'll be picked up on the second
->sync_fs call, with wait==1.

Re: mmotm 2009-01-05-12-50 uploaded (ubifs)

[Artem Bityutskiy]

On Mon, 2009-01-05 at 14:24 -0800, Andrew Morton wrote:
> WB_SYNC_HOLD got removed by
> http://userweb.kernel.org/~akpm/mmotm/broken-out/fs-remove-wb_sync_hold.patch
> 
> I think I'll just switch that to WB_SYNC_NONE.  The `wait==0' mode is
> just an advisory thing to help the fs shove lots of data into the
> queues.  If some gets missed then it'll be picked up on the second
> ->sync_fs call, with wait==1.

Sorry for the problems caused by this patch. Here is a fix for your
convenience. Will you send it to Linus or I should do this?

From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Subject: [PATCH] UBIFS: do not use WB_SYNC_HOLD

WB_SYNC_HOLD is going to be zapped so we should not use it. Use
%WB_SYNC_NONE instead. Here is what akpm said:

"I think I'll just switch that to WB_SYNC_NONE.  The `wait==0' mode is
just an advisory thing to help the fs shove lots of data into the
queues.  If some gets missed then it'll be picked up on the second
->sync_fs call, with wait==1."

Thanks to Randy Dunlap <randy.dunlap@oracle.com> for catching this.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
 fs/ubifs/super.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 0d7564b..89556ee 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -432,12 +432,19 @@ static int ubifs_sync_fs(struct super_block *sb, int wait)
 	int i, err;
 	struct ubifs_info *c = sb->s_fs_info;
 	struct writeback_control wbc = {
-		.sync_mode   = wait ? WB_SYNC_ALL : WB_SYNC_HOLD,
+		.sync_mode   = wait ? WB_SYNC_ALL : WB_SYNC_NONE,
 		.range_start = 0,
 		.range_end   = LLONG_MAX,
 		.nr_to_write = LONG_MAX,
 	};
 
+	/*
+	 * Note by akpm about WB_SYNC_NONE used above: zero @wait is just an
+	 * advisory thing to help the file system shove lots of data into the
+	 * queues. If some gets missed then it'll be picked up on the second
+	 * '->sync_fs()' call, with non-zero @wait.
+	 */
+
 	if (sb->s_flags & MS_RDONLY)
 		return 0;
 
-- 
1.6.0.6

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: mmotm 2009-01-05-12-50 uploaded (ubifs)

[Andrew Morton]

On Tue, 06 Jan 2009 14:11:44 +0200 Artem Bityutskiy <dedekind@infradead.org> wrote:

> On Mon, 2009-01-05 at 14:24 -0800, Andrew Morton wrote:
> > WB_SYNC_HOLD got removed by
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/fs-remove-wb_sync_hold.patch
> > 
> > I think I'll just switch that to WB_SYNC_NONE.  The `wait==0' mode is
> > just an advisory thing to help the fs shove lots of data into the
> > queues.  If some gets missed then it'll be picked up on the second
> > ->sync_fs call, with wait==1.
> 
> Sorry for the problems caused by this patch. Here is a fix for your
> convenience. Will you send it to Linus or I should do this?
> 
> From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> Subject: [PATCH] UBIFS: do not use WB_SYNC_HOLD

I can take care of that, thanks.

Re: mmotm 2009-01-05-12-50 uploaded

[Jiri Slaby]

On 01/05/2009 09:50 PM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2009-01-05-12-50 has been uploaded

Hi,

it fails to build here due to this link error:
drivers/built-in.o: In function `alloc_iommu':
(.text+0xf1bf): undefined reference to `iommu_calculate_agaw'

CONFIG_INTR_REMAP "depends" now on CONFIG_DMAR. Could you fix it, Weidong Han?

regards,
--js

Re: mmotm 2009-01-05-12-50 uploaded

[Jiri Kosina]

On Mon, 5 Jan 2009, Jiri Slaby wrote:

> > The mm-of-the-moment snapshot 2009-01-05-12-50 has been uploaded
> it fails to build here due to this link error:
> drivers/built-in.o: In function `alloc_iommu':
> (.text+0xf1bf): undefined reference to `iommu_calculate_agaw'

This is not a problem of mmotom, the same applies for Linus' tree. The 
patch exists [1], but it seems to be queued in Ingo's tree still.

[1] http://lkml.org/lkml/2009/1/4/35

-- 
Jiri Kosina
SUSE Labs

Re: mmotm 2009-01-05-12-50 uploaded

[Jiri Slaby]

Jiri Kosina wrote:
> On Mon, 5 Jan 2009, Jiri Slaby wrote:
> 
>>> The mm-of-the-moment snapshot 2009-01-05-12-50 has been uploaded
>> it fails to build here due to this link error:
>> drivers/built-in.o: In function `alloc_iommu':
>> (.text+0xf1bf): undefined reference to `iommu_calculate_agaw'
> 
> This is not a problem of mmotom, the same applies for Linus' tree. The 
> patch exists [1], but it seems to be queued in Ingo's tree still.
> 
> [1] http://lkml.org/lkml/2009/1/4/35

Ok, thanks Jiri.

[PATCH mm/next] libfc: uses/select CRC32

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

libfc uses crc32 functions, so cause it to be built
via select:

drivers/built-in.o: In function `fc_frame_crc_check':
(.text+0x75dae): undefined reference to `crc32_le'
drivers/built-in.o: In function `fc_fcp_recv':
fc_fcp.c:(.text+0x7b919): undefined reference to `crc32_le'
fc_fcp.c:(.text+0x7b9d5): undefined reference to `crc32_le'
fc_fcp.c:(.text+0x7ba54): undefined reference to `crc32_le'

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 drivers/scsi/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- mmotm-2009-0105-1250.orig/drivers/scsi/Kconfig
+++ mmotm-2009-0105-1250/drivers/scsi/Kconfig
@@ -609,6 +609,7 @@ config SCSI_FLASHPOINT
 config LIBFC
 	tristate "LibFC module"
 	select SCSI_FC_ATTRS
+	select CRC32
 	---help---
 	  Fibre Channel library module
 

Re: [PATCH mm/next] libfc: uses/select CRC32

[Ingo Molnar]

* Randy Dunlap <randy.dunlap@oracle.com> wrote:

> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> libfc uses crc32 functions, so cause it to be built
> via select:
> 
> drivers/built-in.o: In function `fc_frame_crc_check':
> (.text+0x75dae): undefined reference to `crc32_le'
> drivers/built-in.o: In function `fc_fcp_recv':
> fc_fcp.c:(.text+0x7b919): undefined reference to `crc32_le'
> fc_fcp.c:(.text+0x7b9d5): undefined reference to `crc32_le'
> fc_fcp.c:(.text+0x7ba54): undefined reference to `crc32_le'
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>

Hm, is there a reason why this fix has not gone upstream? I'm still 
stumbling across it in build tests with a latest -git base.

	Ingo