From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: kernel-janitors@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [patch] f2fs: dereferencing an ERR_PTR
Date: Fri, 24 May 2013 03:46:08 +0000 [thread overview]
Message-ID: <1369367168.10521.13.camel@kjgkr> (raw)
In-Reply-To: <20130523101240.GG30128@mwanda>
[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]
2013-05-23 (목), 13:12 +0300, Dan Carpenter:
> Btw, Linus's new Sparse changes don't like the f2fs's NEW_ADDR
> macro.
>
> #define NEW_ADDR -1U
>
> We use it like this:
>
> block_t src, dest;
>
> if (src != dest && dest != NEW_ADDR && dest != NULL_ADDR) {
>
> block_t is 64 bits so probably the macro should probably be:
>
> #define NEW_ADDR ((block_t)-1)
Hi,
Agreed that it needs to synchronize on-disk and in-memory block address
types, __le32 and u64.
How about the below patch?
>
> I'm not able to test this so there may be some reason why changing
> this breaks something. In that case we could do:
>
> #define NEW_ADDR ((u32)(block_t)-1) /* explanation */
>
> regards,
> dan carpenter
>
From ded3c78fcb6dd8c39a8664471544942e51ff9faf Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Date: Fri, 24 May 2013 12:41:04 +0900
Subject: [PATCH] f2fs: align data types between on-disk and in-memory
block
addresses
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
The on-disk block address is defined as __le32, but in-memory block
address,
block_t, does as u64.
Let's synchronize them to 32 bits.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
---
fs/f2fs/f2fs.h | 5 ++++-
include/linux/f2fs_fs.h | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7b05029..92fd4e9 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -37,7 +37,10 @@
typecheck(unsigned long long, b) && \
((long long)((a) - (b)) > 0))
-typedef u64 block_t;
+typedef u32 block_t; /*
+ * should not change u32, since it is the on-disk block
+ * address format, __le32.
+ */
typedef u32 nid_t;
struct f2fs_mount_info {
diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
index df6fab8..383d5e3 100644
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -20,8 +20,8 @@
#define F2FS_BLKSIZE 4096 /* support only 4KB block */
#define F2FS_MAX_EXTENSION 64 /* # of extension entries */
-#define NULL_ADDR 0x0U
-#define NEW_ADDR -1U
+#define NULL_ADDR ((block_t)0) /* used as block_t addresses */
+#define NEW_ADDR ((block_t)-1) /* used as block_t addresses */
#define F2FS_ROOT_INO(sbi) (sbi->root_ino_num)
#define F2FS_NODE_INO(sbi) (sbi->node_ino_num)
--
1.8.1.3.566.gaa39828
--
Jaegeuk Kim
Samsung
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: kernel-janitors@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [patch] f2fs: dereferencing an ERR_PTR
Date: Fri, 24 May 2013 12:46:08 +0900 [thread overview]
Message-ID: <1369367168.10521.13.camel@kjgkr> (raw)
In-Reply-To: <20130523101240.GG30128@mwanda>
[-- Attachment #1.1: Type: text/plain, Size: 2587 bytes --]
2013-05-23 (목), 13:12 +0300, Dan Carpenter:
> Btw, Linus's new Sparse changes don't like the f2fs's NEW_ADDR
> macro.
>
> #define NEW_ADDR -1U
>
> We use it like this:
>
> block_t src, dest;
>
> if (src != dest && dest != NEW_ADDR && dest != NULL_ADDR) {
>
> block_t is 64 bits so probably the macro should probably be:
>
> #define NEW_ADDR ((block_t)-1)
Hi,
Agreed that it needs to synchronize on-disk and in-memory block address
types, __le32 and u64.
How about the below patch?
>
> I'm not able to test this so there may be some reason why changing
> this breaks something. In that case we could do:
>
> #define NEW_ADDR ((u32)(block_t)-1) /* explanation */
>
> regards,
> dan carpenter
>
From ded3c78fcb6dd8c39a8664471544942e51ff9faf Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Date: Fri, 24 May 2013 12:41:04 +0900
Subject: [PATCH] f2fs: align data types between on-disk and in-memory
block
addresses
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
The on-disk block address is defined as __le32, but in-memory block
address,
block_t, does as u64.
Let's synchronize them to 32 bits.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
---
fs/f2fs/f2fs.h | 5 ++++-
include/linux/f2fs_fs.h | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7b05029..92fd4e9 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -37,7 +37,10 @@
typecheck(unsigned long long, b) && \
((long long)((a) - (b)) > 0))
-typedef u64 block_t;
+typedef u32 block_t; /*
+ * should not change u32, since it is the on-disk block
+ * address format, __le32.
+ */
typedef u32 nid_t;
struct f2fs_mount_info {
diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
index df6fab8..383d5e3 100644
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -20,8 +20,8 @@
#define F2FS_BLKSIZE 4096 /* support only 4KB block */
#define F2FS_MAX_EXTENSION 64 /* # of extension entries */
-#define NULL_ADDR 0x0U
-#define NEW_ADDR -1U
+#define NULL_ADDR ((block_t)0) /* used as block_t addresses */
+#define NEW_ADDR ((block_t)-1) /* used as block_t addresses */
#define F2FS_ROOT_INO(sbi) (sbi->root_ino_num)
#define F2FS_NODE_INO(sbi) (sbi->node_ino_num)
--
1.8.1.3.566.gaa39828
--
Jaegeuk Kim
Samsung
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 421 bytes --]
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
[-- Attachment #3: Type: text/plain, Size: 179 bytes --]
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2013-05-24 3:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-23 10:02 [patch] f2fs: dereferencing an ERR_PTR Dan Carpenter
2013-05-23 10:02 ` [f2fs-dev] " Dan Carpenter
2013-05-23 10:12 ` Dan Carpenter
2013-05-23 10:12 ` [f2fs-dev] " Dan Carpenter
2013-05-24 3:46 ` Jaegeuk Kim [this message]
2013-05-24 3:46 ` Jaegeuk Kim
2013-05-24 11:23 ` Dan Carpenter
2013-05-24 11:23 ` [f2fs-dev] " Dan Carpenter
2013-05-24 11:32 ` Jaegeuk Kim
2013-05-24 11:32 ` [f2fs-dev] " Jaegeuk Kim
2013-05-26 15:05 ` walter harms
2013-05-26 15:05 ` [f2fs-dev] " walter harms
2013-05-26 20:41 ` Dan Carpenter
2013-05-26 20:41 ` [f2fs-dev] " Dan Carpenter
2013-05-27 7:13 ` walter harms
2013-05-27 7:13 ` [f2fs-dev] " walter harms
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1369367168.10521.13.camel@kjgkr \
--to=jaegeuk.kim@samsung.com \
--cc=dan.carpenter@oracle.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.