linux-kernel - [PATCH] Btrfs: avoid build warning on 32-bit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4264141.3m7C7LgF5c@wuerfel>
Date:	Tue, 13 Jan 2015 15:09:03 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Chris Mason <clm@...com>
Cc:	Miao Xie <miaox@...fujitsu.com>, Josef Bacik <jbacik@...com>,
	David Sterba <dsterba@...e.cz>, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH] Btrfs: avoid build warning on 32-bit

A recent change introduced a type cast from a private 64-bit
value to a pointer, which works fine on 64-bit architectures,
but not on 32-bit ones, where it produces a harmless compiler
warning:

fs/btrfs/extent_io.c: In function 'btrfs_free_io_failure_record':
fs/btrfs/extent_io.c:2193:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

This adds an intermediate cast to 'unsigned long', which tells
the compiler to ignore the type mismatch.

Signed-off-by: Arnd Bergmann <arnd@...db.de>
Fixes: f612496bca664 ("Btrfs: cleanup the read failure record after write
			or when the inode is freeing")

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 4ebabd237153..790dbae3343c 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2190,7 +2190,7 @@ void btrfs_free_io_failure_record(struct inode *inode, u64 start, u64 end)
 
 		next = next_state(state);
 
-		failrec = (struct io_failure_record *)state->private;
+		failrec = (struct io_failure_record *)(unsigned long)state->private;
 		free_extent_state(state);
 		kfree(failrec);
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/