[f2fs-dev] [PATCH] resize.f2fs: correct the max segno in migrate_main

[Junling Zheng]

Signed-off-by: Junling Zheng 
---
 fsck/resize.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fsck/resize.c b/fsck/resize.c
index 46aa30e..ba7bb88 100644
--- a/fsck/resize.c
+++ b/fsck/resize.c
@@ -143,7 +143,7 @@ static void migrate_main(struct f2fs_sb_info *sbi,
 
ASSERT(raw != NULL);
 
-   for (i = TOTAL_SEGS(sbi); i >= 0; i--) {
+   for (i = TOTAL_SEGS(sbi) - 1; i >= 0; i--) {
se = get_seg_entry(sbi, i);
if (!se->valid_blocks)
continue;
-- 
2.7.4


--
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH] fscrypto: move ioctl processing more fully into common code

[Theodore Ts'o]

On Sat, Nov 26, 2016 at 08:20:48PM -0800, Eric Biggers wrote:
> 
> I guess I'm okay with that, since struct fscrypt_policy won't have any padding
> bytes because its members are all bytes.  Plus it's marked __packed, though I
> think that was a mistake given that the struct isn't stored on disk directly.
>

It wouldn't have mattered if wasn't marked __packed, since the first
four fields are __u8, and the master_key_descriptor is a 4 byte
aligned __u8 array of size 8.

The use of __packed in the fscrypt code came from Michael, and I
suspect it's more of a Microsoft thing, since his previous experience
was as the architect for Bitlocker.  It's actually pretty rare that we
use __packed in Linux kernel sources in general, and in ext4
specifically.

Personally, I tend to depend on __uNN declaration and various
assumptions that we make about "sane" packing rules which are assumed
by the kernel.  See how the on-disk ext4 superblock is defined; that's
not the only place where we make assumptions about sane structure
packing, and anyone who tried porting Linux to a 18-bit or 36-bit
architecture would have lots of other problems, even if a modern Linux
kernel could be made small enough to fit in the memory available to a
PDP-10 or a PDP-15. :-)

We probably could remove a few of them, but I haven't bothered, since
in general they aren't doing any harm.

Cheers,

- Ted



--
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel