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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 19 Oct 2014 21:34:47 +0200 From: Geert Uytterhoeven <geert@...ux-m68k.org> To: Miao Xie <miaox@...fujitsu.com>, Chris Mason <clm@...com>, Josef Bacik <jbacik@...com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-btrfs <linux-btrfs@...r.kernel.org> Subject: btrfs extent_state.private compiler warning (Re: Btrfs: cleanup the read failure record after write or when the inode is freeing) On Sat, Oct 11, 2014 at 2:08 PM, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> wrote: > Gitweb: http://git.kernel.org/linus/;a=commit;h=f612496bca664bff6a09a99a9a7506410b6e876e > Commit: f612496bca664bff6a09a99a9a7506410b6e876e > Btrfs: cleanup the read failure record after write or when the inode is freeing > > After the data is written successfully, we should cleanup the read failure record > in that range because > - If we set data COW for the file, the range that the failure record pointed to is > mapped to a new place, so it is invalid. > - If we set no data COW for the file, and if there is no error during writting, > the corrupted data is corrected, so the failure record can be removed. And if > some errors happen on the mirrors, we also needn't worry about it because the > failure record will be recreated if we read the same place again. > > Sometimes, we may fail to correct the data, so the failure records will be left > in the tree, we need free them when we free the inode or the memory leak happens. > --- a/fs/btrfs/extent_io.c > +++ b/fs/btrfs/extent_io.c > +void btrfs_free_io_failure_record(struct inode *inode, u64 start, u64 end) > +{ > + struct extent_io_tree *failure_tree = &BTRFS_I(inode)->io_failure_tree; > + struct io_failure_record *failrec; > + struct extent_state *state, *next; > + failrec = (struct io_failure_record *)state->private; On 32-bit: fs/btrfs/extent_io.c: In function ‘btrfs_free_io_failure_record’: fs/btrfs/extent_io.c:2166: warning: cast to pointer from integer of different size Is there any specific reason extend_state.private is "u64", and not "unsigned long", or better "void *", or even better "struct io_failure_record *"? That would get rid of the (double) cast tricks. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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/
Powered by blists - more mailing lists