Re: [f2fs-dev] [PATCH 10/10] errno.h: Provide EFSCORRUPTED for everybody
On 2019/11/4 9:45, Valdis Kletnieks wrote: > There's currently 6 filesystems that have the same #define. Move it > into errno.h so it's defined in just one place. > > Signed-off-by: Valdis Kletnieks > Acked-by: Darrick J. Wong > Reviewed-by: Jan Kara > Acked-by: Theodore Ts'o > fs/erofs/internal.h | 2 -- > fs/f2fs/f2fs.h | 1 - Acked-by: Chao Yu Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 1/2] f2fs: support aligned pinned file
On 2019/10/31 23:29, Jaegeuk Kim wrote:
> On 10/31, Chao Yu wrote:
>> On 2019/10/31 0:09, Jaegeuk Kim wrote:
>>> On 10/26, Chao Yu wrote:
On 2019/10/26 2:18, Jaegeuk Kim wrote:
> On 10/24, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2019/10/23 1:16, Jaegeuk Kim wrote:
>>> This patch supports 2MB-aligned pinned file, which can guarantee no GC
>>> at all
>>> by allocating fully valid 2MB segment.
>>>
>>> Signed-off-by: Jaegeuk Kim
>>> ---
>>> fs/f2fs/f2fs.h | 4 +++-
>>> fs/f2fs/file.c | 39 ++-
>>> fs/f2fs/recovery.c | 2 +-
>>> fs/f2fs/segment.c | 21 -
>>> fs/f2fs/segment.h | 2 ++
>>> fs/f2fs/super.c| 1 +
>>> fs/f2fs/sysfs.c| 2 ++
>>> 7 files changed, 63 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>> index ca342f4c7db1..c681f51e351b 100644
>>> --- a/fs/f2fs/f2fs.h
>>> +++ b/fs/f2fs/f2fs.h
>>> @@ -890,6 +890,7 @@ enum {
>>> CURSEG_WARM_NODE, /* direct node blocks of normal files */
>>> CURSEG_COLD_NODE, /* indirect node blocks */
>>> NO_CHECK_TYPE,
>>> + CURSEG_COLD_DATA_PINNED,/* cold data for pinned file */
>>> };
>>>
>>> struct flush_cmd {
>>> @@ -1301,6 +1302,7 @@ struct f2fs_sb_info {
>>>
>>> /* threshold for gc trials on pinned files */
>>> u64 gc_pin_file_threshold;
>>> + struct rw_semaphore pin_sem;
>>>
>>> /* maximum # of trials to find a victim segment for SSR and GC
>>> */
>>> unsigned int max_victim_search;
>>> @@ -3116,7 +3118,7 @@ void f2fs_release_discard_addrs(struct
>>> f2fs_sb_info *sbi);
>>> int f2fs_npages_for_summary_flush(struct f2fs_sb_info *sbi, bool
>>> for_ra);
>>> void allocate_segment_for_resize(struct f2fs_sb_info *sbi, int type,
>>> unsigned int start, unsigned
>>> int end);
>>> -void f2fs_allocate_new_segments(struct f2fs_sb_info *sbi);
>>> +void f2fs_allocate_new_segments(struct f2fs_sb_info *sbi, int type);
>>> int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct fstrim_range *range);
>>> bool f2fs_exist_trim_candidates(struct f2fs_sb_info *sbi,
>>> struct cp_control *cpc);
>>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
>>> index 29bc0a542759..f6c038e8a6a7 100644
>>> --- a/fs/f2fs/file.c
>>> +++ b/fs/f2fs/file.c
>>> @@ -1545,12 +1545,41 @@ static int expand_inode_data(struct inode
>>> *inode, loff_t offset,
>>> if (off_end)
>>> map.m_len++;
>>>
>>> - if (f2fs_is_pinned_file(inode))
>>> - map.m_seg_type = CURSEG_COLD_DATA;
>>> + if (!map.m_len)
>>> + return 0;
>>> +
>>> + if (f2fs_is_pinned_file(inode)) {
>>> + block_t len = (map.m_len >> sbi->log_blocks_per_seg) <<
>>> + sbi->log_blocks_per_seg;
>>> + block_t done = 0;
>>> +
>>> + if (map.m_len % sbi->blocks_per_seg)
>>> + len += sbi->blocks_per_seg;
>>>
>>> - err = f2fs_map_blocks(inode, , 1,
>>> (f2fs_is_pinned_file(inode) ?
>>> - F2FS_GET_BLOCK_PRE_DIO :
>>> -
>>> F2FS_GET_BLOCK_PRE_AIO));
>>> + map.m_len = sbi->blocks_per_seg;
>>> +next_alloc:
>>> + mutex_lock(>gc_mutex);
>>> + err = f2fs_gc(sbi, true, false, NULL_SEGNO);
>>> + if (err && err != -ENODATA && err != -EAGAIN)
>>> + goto out_err;
>>
>> To grab enough free space?
>>
>> Shouldn't we call
>>
>> if (has_not_enough_free_secs(sbi, 0, 0)) {
>> mutex_lock(>gc_mutex);
>> f2fs_gc(sbi, false, false, NULL_SEGNO);
>> }
>
> The above calls gc all the time. Do we need this?
Hmmm... my concern is why we need to run foreground GC even if there is
enough
free space..
>>>
>>> In order to get the free segment easily?
>>
>> However, I doubt arbitrary foreground GC with greedy algorithm will ruin
>> hot/cold data separation, actually, for sufficient free segment case, it's
>> unnecessary to call FGGC.
>
> Two things here; 1) I do worry much about when hitting boundary on
> has_not_enough_free_secs() which calculates # of free segments based on # of
> dirty pages. In this case, we just jump to allocate another free segment so
> I think it increases the possiblity of no free segment panic. 2) Even if we
Yup, I guess for other places, if there is thousand of threads allocating space
concurrently, we may have small
Re: [f2fs-dev] [PATCH v5 7/9] fscrypt: add inline encryption support
On Thu, Oct 31, 2019 at 02:21:03PM -0700, Christoph Hellwig wrote: > > > > > > Btw, I'm not happy about the 8-byte IV assumptions everywhere here. > > > That really should be a parameter, not hardcoded. > > > > To be clear, the 8-byte IV assumption doesn't really come from fs/crypto/, > > but > > rather in what the blk-crypto API provides. If blk-crypto were to provide > > longer IV support, fs/crypto/ would pretty easily be able to make use of it. > > That's what I meant - we hardcode the value in fscrypt. Instead we need > to expose the size from blk-crypt and check for it. > > > > > (And if IVs >= 24 bytes were supported and we added AES-128-CBC-ESSIV and > > Adiantum support to blk-crypto.c, then inline encryption would be able to do > > everything that the existing filesystem-layer contents encryption can do.) > > > > Do you have anything in mind for how to make the API support longer IVs in a > > clean way? Are you thinking of something like: > > > > #define BLK_CRYPTO_MAX_DUN_SIZE 24 > > > > u8 dun[BLK_CRYPTO_MAX_DUN_SIZE]; > > int dun_size; > > > > We do have to perform arithmetic operations on it, so a byte array would > > make it > > ugly and slower, but it should be possible... > > Well, we could make it an array of u64s, which means we can do all the > useful arithmetics on components on one of them. But I see the point, > this adds significant complexity for no real short term gain, and we > should probably postponed it until needed. Maybe just document the > assumptions a little better. Just in case it's not obvious to anyone, I should also mention that being limited to specifying a 64-bit DUN doesn't prevent hardware that accepts a longer IV (e.g. 128 bits) from being used. It would just be a matter of zero-padding the IV in the driver rather than in hardware. The actual limitation we're talking about here is in the range of IVs that can be specified. A 64-bit DUN only allows the first 64 bits of the IV to be nonzero. That works for fscrypt in all cases except DIRECT_KEY policies, and it would work for dm-crypt using the usual dm-crypt IV generator (plain64). But for inline encryption to be compatible with DIRECT_KEY fscrypt policies or with certain other dm-crypt IV generators, we'd need the ability to specify more IV bits. - Eric ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 3/3] Revert "f2fs: use kvmalloc, if kmalloc is failed"
On 11/05, Chao Yu wrote: > On 2019/11/5 10:38, Eric Biggers wrote: > > On Tue, Nov 05, 2019 at 10:17:41AM +0800, Chao Yu wrote: > >> On 2019/11/5 8:02, Jaegeuk Kim wrote: > >>> On 11/01, Chao Yu wrote: > This reverts commit 5222595d093ebe80329d38d255d14316257afb3e. > > As discussed with Eric, as kvmalloc() will try kmalloc() first, so > when we need allocate large size memory, it'd better to use > f2fs_kvmalloc() directly rather than adding additional fallback > logic to call kvmalloc() after we failed in f2fs_kmalloc(). > > In order to avoid allocation failure described in original commit, > I change to use f2fs_kvmalloc() for .free_nid_bitmap bitmap memory. > >>> > >>> Is there any problem in the previous flow? > >> > >> No existing problem, however, it's redundant to introduce fallback flow in > >> f2fs_kmalloc() like vmalloc() did, since we can call f2fs_vmalloc() > >> directly in > >> places where we need large memory. > >> > >> Thanks, > >> > > > > f2fs_kmalloc() also violated the naming convention used everywhere else in > > the > > kernel since it could return both kmalloc and vmalloc memory, not just > > kmalloc > > memory. That's really error-prone since people would naturally assume it's > > safe > > to free the *_kmalloc()-ed memory with kfree(). > > Agreed. Then, why not just keeping f2fs_kvmalloc() and replace all f2fs_kmalloc() with f2fs_kvmalloc()? f2fs_kvmalloc() - call kmalloc() - vmalloc(), if failed I'd like to keep the allocation behavior first. Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 3/3] Revert "f2fs: use kvmalloc, if kmalloc is failed"
On 2019/11/5 10:38, Eric Biggers wrote: > On Tue, Nov 05, 2019 at 10:17:41AM +0800, Chao Yu wrote: >> On 2019/11/5 8:02, Jaegeuk Kim wrote: >>> On 11/01, Chao Yu wrote: This reverts commit 5222595d093ebe80329d38d255d14316257afb3e. As discussed with Eric, as kvmalloc() will try kmalloc() first, so when we need allocate large size memory, it'd better to use f2fs_kvmalloc() directly rather than adding additional fallback logic to call kvmalloc() after we failed in f2fs_kmalloc(). In order to avoid allocation failure described in original commit, I change to use f2fs_kvmalloc() for .free_nid_bitmap bitmap memory. >>> >>> Is there any problem in the previous flow? >> >> No existing problem, however, it's redundant to introduce fallback flow in >> f2fs_kmalloc() like vmalloc() did, since we can call f2fs_vmalloc() directly >> in >> places where we need large memory. >> >> Thanks, >> > > f2fs_kmalloc() also violated the naming convention used everywhere else in the > kernel since it could return both kmalloc and vmalloc memory, not just kmalloc > memory. That's really error-prone since people would naturally assume it's > safe > to free the *_kmalloc()-ed memory with kfree(). Agreed. Thanks, > > - Eric > . > ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
[f2fs-dev] [PATCH 1/1] errno.h: Provide EFSBADCRC for everybody
Four filesystems have their own defines for this. Move it into errno.h so it's defined in just one place. Signed-off-by: Valdis Kletnieks --- fs/ext4/ext4.h | 2 -- fs/f2fs/f2fs.h | 2 -- fs/xfs/xfs_linux.h | 1 - include/linux/jbd2.h | 2 -- include/uapi/asm-generic/errno.h | 1 + 5 files changed, 1 insertion(+), 7 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index a86c2585457d..79b3fd8291ab 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -3395,6 +3395,4 @@ static inline int ext4_buffer_uptodate(struct buffer_head *bh) #endif /* __KERNEL__ */ -#define EFSBADCRC EBADMSG /* Bad CRC detected */ - #endif /* _EXT4_H */ diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 04ebe77569a3..ba23fd18d44a 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -3751,6 +3751,4 @@ static inline bool is_journalled_quota(struct f2fs_sb_info *sbi) return false; } -#define EFSBADCRC EBADMSG /* Bad CRC detected */ - #endif /* _LINUX_F2FS_H */ diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h index 3409d02a7d21..abdfc506618d 100644 --- a/fs/xfs/xfs_linux.h +++ b/fs/xfs/xfs_linux.h @@ -123,7 +123,6 @@ typedef __u32 xfs_nlink_t; #define ENOATTRENODATA /* Attribute not found */ #define EWRONGFS EINVAL /* Mount with wrong filesystem type */ -#define EFSBADCRC EBADMSG /* Bad CRC detected */ #define SYNCHRONIZE() barrier() #define __return_address __builtin_return_address(0) diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h index 69411d7e0431..e07692fe6f20 100644 --- a/include/linux/jbd2.h +++ b/include/linux/jbd2.h @@ -1656,6 +1656,4 @@ static inline tid_t jbd2_get_latest_transaction(journal_t *journal) #endif /* __KERNEL__ */ -#define EFSBADCRC EBADMSG /* Bad CRC detected */ - #endif /* _LINUX_JBD2_H */ diff --git a/include/uapi/asm-generic/errno.h b/include/uapi/asm-generic/errno.h index 1d5ffdf54cb0..e4cae9a9ae79 100644 --- a/include/uapi/asm-generic/errno.h +++ b/include/uapi/asm-generic/errno.h @@ -55,6 +55,7 @@ #defineEMULTIHOP 72 /* Multihop attempted */ #defineEDOTDOT 73 /* RFS specific error */ #defineEBADMSG 74 /* Not a data message */ +#define EFSBADCRC EBADMSG /* Bad CRC detected */ #defineEOVERFLOW 75 /* Value too large for defined data type */ #defineENOTUNIQ76 /* Name not unique on network */ #defineEBADFD 77 /* File descriptor in bad state */ -- 2.24.0.rc1 ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 3/3] Revert "f2fs: use kvmalloc, if kmalloc is failed"
On Tue, Nov 05, 2019 at 10:17:41AM +0800, Chao Yu wrote: > On 2019/11/5 8:02, Jaegeuk Kim wrote: > > On 11/01, Chao Yu wrote: > >> This reverts commit 5222595d093ebe80329d38d255d14316257afb3e. > >> > >> As discussed with Eric, as kvmalloc() will try kmalloc() first, so > >> when we need allocate large size memory, it'd better to use > >> f2fs_kvmalloc() directly rather than adding additional fallback > >> logic to call kvmalloc() after we failed in f2fs_kmalloc(). > >> > >> In order to avoid allocation failure described in original commit, > >> I change to use f2fs_kvmalloc() for .free_nid_bitmap bitmap memory. > > > > Is there any problem in the previous flow? > > No existing problem, however, it's redundant to introduce fallback flow in > f2fs_kmalloc() like vmalloc() did, since we can call f2fs_vmalloc() directly > in > places where we need large memory. > > Thanks, > f2fs_kmalloc() also violated the naming convention used everywhere else in the kernel since it could return both kmalloc and vmalloc memory, not just kmalloc memory. That's really error-prone since people would naturally assume it's safe to free the *_kmalloc()-ed memory with kfree(). - Eric ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH] f2fs: avoid kernel panic on corruption test
On 2019/11/2 0:36, Jaegeuk Kim wrote: > xfstests/generic/475 complains kernel warn/panic while testing corrupted disk. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 3/3] Revert "f2fs: use kvmalloc, if kmalloc is failed"
On 2019/11/5 8:02, Jaegeuk Kim wrote:
> On 11/01, Chao Yu wrote:
>> This reverts commit 5222595d093ebe80329d38d255d14316257afb3e.
>>
>> As discussed with Eric, as kvmalloc() will try kmalloc() first, so
>> when we need allocate large size memory, it'd better to use
>> f2fs_kvmalloc() directly rather than adding additional fallback
>> logic to call kvmalloc() after we failed in f2fs_kmalloc().
>>
>> In order to avoid allocation failure described in original commit,
>> I change to use f2fs_kvmalloc() for .free_nid_bitmap bitmap memory.
>
> Is there any problem in the previous flow?
No existing problem, however, it's redundant to introduce fallback flow in
f2fs_kmalloc() like vmalloc() did, since we can call f2fs_vmalloc() directly in
places where we need large memory.
Thanks,
>
>>
>> Signed-off-by: Chao Yu
>> ---
>> fs/f2fs/acl.c| 6 ++---
>> fs/f2fs/checkpoint.c | 2 +-
>> fs/f2fs/data.c | 2 +-
>> fs/f2fs/debug.c | 2 +-
>> fs/f2fs/dir.c| 6 ++---
>> fs/f2fs/f2fs.h | 10 ++-
>> fs/f2fs/file.c | 2 +-
>> fs/f2fs/gc.c | 4 +--
>> fs/f2fs/hash.c | 4 +--
>> fs/f2fs/inline.c | 4 +--
>> fs/f2fs/namei.c | 2 +-
>> fs/f2fs/node.c | 10 +++
>> fs/f2fs/segment.c| 28 +--
>> fs/f2fs/super.c | 64 ++--
>> fs/f2fs/xattr.c | 10 +++
>> 15 files changed, 75 insertions(+), 81 deletions(-)
>>
>> diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
>> index 217b290ae3a5..306413589827 100644
>> --- a/fs/f2fs/acl.c
>> +++ b/fs/f2fs/acl.c
>> @@ -160,7 +160,7 @@ static void *f2fs_acl_to_disk(struct f2fs_sb_info *sbi,
>> return (void *)f2fs_acl;
>>
>> fail:
>> -kvfree(f2fs_acl);
>> +kfree(f2fs_acl);
>> return ERR_PTR(-EINVAL);
>> }
>>
>> @@ -190,7 +190,7 @@ static struct posix_acl *__f2fs_get_acl(struct inode
>> *inode, int type,
>> acl = NULL;
>> else
>> acl = ERR_PTR(retval);
>> -kvfree(value);
>> +kfree(value);
>>
>> return acl;
>> }
>> @@ -240,7 +240,7 @@ static int __f2fs_set_acl(struct inode *inode, int type,
>>
>> error = f2fs_setxattr(inode, name_index, "", value, size, ipage, 0);
>>
>> -kvfree(value);
>> +kfree(value);
>> if (!error)
>> set_cached_acl(inode, type, acl);
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index ffdaba0c55d2..b33779822a2c 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -965,7 +965,7 @@ int f2fs_get_valid_checkpoint(struct f2fs_sb_info *sbi)
>> f2fs_put_page(cp1, 1);
>> f2fs_put_page(cp2, 1);
>> fail_no_cp:
>> -kvfree(sbi->ckpt);
>> +kfree(sbi->ckpt);
>> return err;
>> }
>>
>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>> index 0bcb28d70894..58f4bade6c2b 100644
>> --- a/fs/f2fs/data.c
>> +++ b/fs/f2fs/data.c
>> @@ -2889,7 +2889,7 @@ static void f2fs_dio_end_io(struct bio *bio)
>> bio->bi_private = dio->orig_private;
>> bio->bi_end_io = dio->orig_end_io;
>>
>> -kvfree(dio);
>> +kfree(dio);
>>
>> bio_endio(bio);
>> }
>> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
>> index 9b0bedd82581..5abd1d67d8b2 100644
>> --- a/fs/f2fs/debug.c
>> +++ b/fs/f2fs/debug.c
>> @@ -515,7 +515,7 @@ void f2fs_destroy_stats(struct f2fs_sb_info *sbi)
>> list_del(>stat_list);
>> mutex_unlock(_stat_mutex);
>>
>> -kvfree(si);
>> +kfree(si);
>> }
>>
>> void __init f2fs_create_root_stats(void)
>> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
>> index c967cacf979e..83ca3b721015 100644
>> --- a/fs/f2fs/dir.c
>> +++ b/fs/f2fs/dir.c
>> @@ -158,7 +158,7 @@ static void f2fs_fname_setup_ci_filename(struct inode
>> *dir,
>> iname, cf_name->name,
>> F2FS_NAME_LEN);
>> if ((int)cf_name->len <= 0) {
>> -kvfree(cf_name->name);
>> +kfree(cf_name->name);
>> cf_name->name = NULL;
>> }
>> }
>> @@ -245,7 +245,7 @@ struct f2fs_dir_entry *f2fs_find_target_dentry(struct
>> fscrypt_name *fname,
>> *max_slots = max_len;
>>
>> #ifdef CONFIG_UNICODE
>> -kvfree(cf_str.name);
>> +kfree(cf_str.name);
>> #endif
>> return de;
>> }
>> @@ -1101,7 +1101,7 @@ static int f2fs_d_hash(const struct dentry *dentry,
>> struct qstr *str)
>> }
>> str->hash = full_name_hash(dentry, norm, len);
>> out:
>> -kvfree(norm);
>> +kfree(norm);
>> return ret;
>> }
>>
>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> index 3f6204202788..8833e9d32f9d 100644
>> --- a/fs/f2fs/f2fs.h
>> +++ b/fs/f2fs/f2fs.h
>> @@ -1677,7 +1677,7 @@ static inline void disable_nat_bits(struct
>> f2fs_sb_info *sbi, bool lock)
>> if (lock)
>> spin_unlock_irqrestore(>cp_lock, flags);
>>
>> -kvfree(nat_bits);
>> +kfree(nat_bits);
>> }
>>
>> static inline bool enabled_nat_bits(struct f2fs_sb_info *sbi,
>>
Re: [f2fs-dev] [PATCH v5 3/9] block: blk-crypto for Inline Encryption
On Thu, Oct 31, 2019 at 02:22:34PM -0700, Christoph Hellwig wrote: > On Thu, Oct 31, 2019 at 04:50:45PM -0400, Theodore Y. Ts'o wrote: > > One of the reasons I really want this is so I (as an upstream > > maintainer of ext4 and fscrypt) can test the new code paths using > > xfstests on GCE, without needing special pre-release hardware that has > > the ICE support. > > > > Yeah, I could probably get one of those dev boards internally at > > Google, but they're a pain in the tuckus to use, and I'd much rather > > be able to have my normal test infrastructure using gce-xfstests and > > kvm-xfstests be able to test inline-crypto. So in terms of CI > > testing, having the blk-crypto is really going to be helpful. > > Implementing the support in qemu or a special device mapper mode > seems like a much better idea for that use case over carrying the > code in the block layer and severely bloating the per-I/O data > structure. > QEMU doesn't support UFS, but even if it did and we added the UFS v2.1 crypto support, it would preclude testing with anything other than a custom QEMU VM or a system with real inline encryption hardware. gce-xfstests wouldn't work. So it would be much harder to test inline encrypted I/O, so e.g. in practice it wouldn't be tested as part of the regular ext4 regression testing. The advantages of blk-crypto over a device mapper target like "dm-inlinecrypt" are (a) blk-crypto is much easier for userspace to use, and (b) blk-crypto allows upper layers to simply use inline encryption rather than have to implement encryption twice, once manually and once with inline encryption. It's true that as of this patchset, the only user of this stuff (fscrypt) still implements both I/O paths anyway. But that's something that could change later once blk-crypto is ready for it, with longer IV support, O(1) keyslot lookups, and a way to configure whether hardware is used or not. Satya is already looking into longer IV support, and I have a proposal for making the keyslot lookups O(1) using a hash table. I think that "Severely bloating the per-I/O data structure" is an exaggeration, since that it's only 32 bytes, and it isn't in struct bio directly but rather in struct bio_crypt_ctx... In any case, Satya, it might be a good idea to reorganize this patchset so that it first adds all logic that's needed for "real" inline encryption support (including the needed parts of blk-crypto.c), then adds the crypto API fallback as a separate patch. That would separate the concerns more cleanly and make the patchset easier to review, and make it easier to make the fallback de-configurable or even remove it entirely if that turns out to be needed. - Eric ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v5 7/9] fscrypt: add inline encryption support
On Mon, Nov 04, 2019 at 04:15:54PM -0800, Christoph Hellwig wrote: > > I don't think combining these things is a good idea because it would > > restrict > > the use of inline encryption to filesystems that allow IV_INO_LBLK_64 > > encryption > > policies, i.e. filesystems that have stable inode numbers, 32-bit inodes, > > and > > 32-bit file logical block numbers. > > > > The on-disk format (i.e. the type of encryption policy chosen) and the > > implementation (inline or filesystem-layer crypto) are really two separate > > things. This was one of the changes in v4 => v5 of this patchset; these two > > things used to be conflated but now they are separate. Now you can use > > inline > > encryption with the existing fscrypt policies too. > > > > We could use two separate SB_* flags, like SB_INLINE_CRYPT and > > SB_IV_INO_LBLK_64_SUPPORT. > > Yes, I think that is a good idea. > > > However, the ->has_stable_inodes() and > > ->get_ino_and_lblk_bits() methods are nice because they separate the > > filesystem > > properties from the question of "is this encryption policy supported". > > Declaring the filesystem properties is easier to do because it doesn't > > require > > any fscrypt-specific knowledge. Also, fs/crypto/ could use these > > properties in > > different ways in the future, e.g. if another IV generation scheme is added. > > I don't really like writing up method boilerplates for something that > is a simple boolean flag. fs/crypto/ uses ->has_stable_inodes() and ->get_ino_and_lblk_bits() to print an appropriate error message. If we changed it to a simple flag we'd have to print a less useful error message. Also, people are basically guaranteed to not understand what "SB_IV_INO_LBLK_64_SUPPORT" means exactly, and are likely to copy-and-paste it incorrectly when adding fscrypt support to a new filesystem. Also it would make it more difficult to add other fscrypt IV generation schemes in the future as we'd then need to add another sb flag (e.g. SB_IV_INO_LBLK_128) and make filesystem-specific changes, rather than change fs/crypto/ only. So personally I'd prefer to keep ->has_stable_inodes() and ->get_ino_and_lblk_bits() for now. Replacing ->inline_crypt_enabled() with SB_INLINE_CRYPT makes much more sense though. - Eric ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 10/10] errno.h: Provide EFSCORRUPTED for everybody
On Sun, Nov 03, 2019 at 08:45:06PM -0500, Valdis Kletnieks wrote: > There's currently 6 filesystems that have the same #define. Move it > into errno.h so it's defined in just one place. And 4 out of 6 also define EFSBADCRC, so please lift that as well. ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v5 7/9] fscrypt: add inline encryption support
On Thu, Oct 31, 2019 at 03:25:03PM -0700, Eric Biggers wrote:
> It's more important to clean up the IS_ENCRYPTED(inode) &&
> S_ISREG(inode->i_mode) checks that are duplicated in fs/{ext4,f2fs}/, so I've
> been thinking of adding a helper:
>
> static inline bool fscrypt_needs_contents_encryption(const struct inode
> *inode)
> {
> return IS_ENABLED(CONFIG_FS_ENCRYPTION) && IS_ENCRYPTED(inode) &&
>S_ISREG(inode->i_mode);
> }
Sounds fine.
> I don't think combining these things is a good idea because it would restrict
> the use of inline encryption to filesystems that allow IV_INO_LBLK_64
> encryption
> policies, i.e. filesystems that have stable inode numbers, 32-bit inodes, and
> 32-bit file logical block numbers.
>
> The on-disk format (i.e. the type of encryption policy chosen) and the
> implementation (inline or filesystem-layer crypto) are really two separate
> things. This was one of the changes in v4 => v5 of this patchset; these two
> things used to be conflated but now they are separate. Now you can use inline
> encryption with the existing fscrypt policies too.
>
> We could use two separate SB_* flags, like SB_INLINE_CRYPT and
> SB_IV_INO_LBLK_64_SUPPORT.
Yes, I think that is a good idea.
> However, the ->has_stable_inodes() and
> ->get_ino_and_lblk_bits() methods are nice because they separate the
> filesystem
> properties from the question of "is this encryption policy supported".
> Declaring the filesystem properties is easier to do because it doesn't require
> any fscrypt-specific knowledge. Also, fs/crypto/ could use these properties
> in
> different ways in the future, e.g. if another IV generation scheme is added.
I don't really like writing up method boilerplates for something that
is a simple boolean flag.
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 3/3] Revert "f2fs: use kvmalloc, if kmalloc is failed"
On 11/01, Chao Yu wrote:
> This reverts commit 5222595d093ebe80329d38d255d14316257afb3e.
>
> As discussed with Eric, as kvmalloc() will try kmalloc() first, so
> when we need allocate large size memory, it'd better to use
> f2fs_kvmalloc() directly rather than adding additional fallback
> logic to call kvmalloc() after we failed in f2fs_kmalloc().
>
> In order to avoid allocation failure described in original commit,
> I change to use f2fs_kvmalloc() for .free_nid_bitmap bitmap memory.
Is there any problem in the previous flow?
>
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/acl.c| 6 ++---
> fs/f2fs/checkpoint.c | 2 +-
> fs/f2fs/data.c | 2 +-
> fs/f2fs/debug.c | 2 +-
> fs/f2fs/dir.c| 6 ++---
> fs/f2fs/f2fs.h | 10 ++-
> fs/f2fs/file.c | 2 +-
> fs/f2fs/gc.c | 4 +--
> fs/f2fs/hash.c | 4 +--
> fs/f2fs/inline.c | 4 +--
> fs/f2fs/namei.c | 2 +-
> fs/f2fs/node.c | 10 +++
> fs/f2fs/segment.c| 28 +--
> fs/f2fs/super.c | 64 ++--
> fs/f2fs/xattr.c | 10 +++
> 15 files changed, 75 insertions(+), 81 deletions(-)
>
> diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
> index 217b290ae3a5..306413589827 100644
> --- a/fs/f2fs/acl.c
> +++ b/fs/f2fs/acl.c
> @@ -160,7 +160,7 @@ static void *f2fs_acl_to_disk(struct f2fs_sb_info *sbi,
> return (void *)f2fs_acl;
>
> fail:
> - kvfree(f2fs_acl);
> + kfree(f2fs_acl);
> return ERR_PTR(-EINVAL);
> }
>
> @@ -190,7 +190,7 @@ static struct posix_acl *__f2fs_get_acl(struct inode
> *inode, int type,
> acl = NULL;
> else
> acl = ERR_PTR(retval);
> - kvfree(value);
> + kfree(value);
>
> return acl;
> }
> @@ -240,7 +240,7 @@ static int __f2fs_set_acl(struct inode *inode, int type,
>
> error = f2fs_setxattr(inode, name_index, "", value, size, ipage, 0);
>
> - kvfree(value);
> + kfree(value);
> if (!error)
> set_cached_acl(inode, type, acl);
>
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index ffdaba0c55d2..b33779822a2c 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -965,7 +965,7 @@ int f2fs_get_valid_checkpoint(struct f2fs_sb_info *sbi)
> f2fs_put_page(cp1, 1);
> f2fs_put_page(cp2, 1);
> fail_no_cp:
> - kvfree(sbi->ckpt);
> + kfree(sbi->ckpt);
> return err;
> }
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 0bcb28d70894..58f4bade6c2b 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -2889,7 +2889,7 @@ static void f2fs_dio_end_io(struct bio *bio)
> bio->bi_private = dio->orig_private;
> bio->bi_end_io = dio->orig_end_io;
>
> - kvfree(dio);
> + kfree(dio);
>
> bio_endio(bio);
> }
> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> index 9b0bedd82581..5abd1d67d8b2 100644
> --- a/fs/f2fs/debug.c
> +++ b/fs/f2fs/debug.c
> @@ -515,7 +515,7 @@ void f2fs_destroy_stats(struct f2fs_sb_info *sbi)
> list_del(>stat_list);
> mutex_unlock(_stat_mutex);
>
> - kvfree(si);
> + kfree(si);
> }
>
> void __init f2fs_create_root_stats(void)
> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> index c967cacf979e..83ca3b721015 100644
> --- a/fs/f2fs/dir.c
> +++ b/fs/f2fs/dir.c
> @@ -158,7 +158,7 @@ static void f2fs_fname_setup_ci_filename(struct inode
> *dir,
> iname, cf_name->name,
> F2FS_NAME_LEN);
> if ((int)cf_name->len <= 0) {
> - kvfree(cf_name->name);
> + kfree(cf_name->name);
> cf_name->name = NULL;
> }
> }
> @@ -245,7 +245,7 @@ struct f2fs_dir_entry *f2fs_find_target_dentry(struct
> fscrypt_name *fname,
> *max_slots = max_len;
>
> #ifdef CONFIG_UNICODE
> - kvfree(cf_str.name);
> + kfree(cf_str.name);
> #endif
> return de;
> }
> @@ -1101,7 +1101,7 @@ static int f2fs_d_hash(const struct dentry *dentry,
> struct qstr *str)
> }
> str->hash = full_name_hash(dentry, norm, len);
> out:
> - kvfree(norm);
> + kfree(norm);
> return ret;
> }
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 3f6204202788..8833e9d32f9d 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -1677,7 +1677,7 @@ static inline void disable_nat_bits(struct f2fs_sb_info
> *sbi, bool lock)
> if (lock)
> spin_unlock_irqrestore(>cp_lock, flags);
>
> - kvfree(nat_bits);
> + kfree(nat_bits);
> }
>
> static inline bool enabled_nat_bits(struct f2fs_sb_info *sbi,
> @@ -2798,18 +2798,12 @@ static inline bool f2fs_may_extent_tree(struct inode
> *inode)
> static inline void *f2fs_kmalloc(struct f2fs_sb_info *sbi,
> size_t size, gfp_t flags)
> {
> - void *ret;
> -
> if (time_to_inject(sbi, FAULT_KMALLOC)) {
> f2fs_show_injection_info(sbi,
[f2fs-dev] [PATCH v15 1/4] Add flags option to get xattr method paired to __vfs_getxattr
From: Mark Salyzyn Add a flag option to get xattr method that could have a bit flag of XATTR_NOSECURITY passed to it. XATTR_NOSECURITY is generally then set in the __vfs_getxattr path when called by security infrastructure. This handles the case of a union filesystem driver that is being requested by the security layer to report back the xattr data. For the use case where access is to be blocked by the security layer. The path then could be security(dentry) -> __vfs_getxattr(dentry...XATTR_NOSECURITY) -> handler->get(dentry...XATTR_NOSECURITY) -> __vfs_getxattr(lower_dentry...XATTR_NOSECURITY) -> lower_handler->get(lower_dentry...XATTR_NOSECURITY) which would report back through the chain data and success as expected, the logging security layer at the top would have the data to determine the access permissions and report back the target context that was blocked. Without the get handler flag, the path on a union filesystem would be the errant security(dentry) -> __vfs_getxattr(dentry) -> handler->get(dentry) -> vfs_getxattr(lower_dentry) -> nested -> security(lower_dentry, log off) -> lower_handler->get(lower_dentry) which would report back through the chain no data, and -EACCES. For selinux for both cases, this would translate to a correctly determined blocked access. In the first case with this change a correct avc log would be reported, in the second legacy case an incorrect avc log would be reported against an uninitialized u:object_r:unlabeled:s0 context making the logs cosmetically useless for audit2allow. This patch series is inert and is the wide-spread addition of the flags option for xattr functions, and a replacement of __vfs_getxattr with __vfs_getxattr(...XATTR_NOSECURITY). Signed-off-by: Mark Salyzyn Reviewed-by: Jan Kara Acked-by: Jan Kara Acked-by: Jeff Layton Acked-by: David Sterba Acked-by: Darrick J. Wong Acked-by: Mike Marshall Cc: Stephen Smalley Cc: linux-ker...@vger.kernel.org Cc: kernel-t...@android.com Cc: linux-security-mod...@vger.kernel.org v15 - revert back to v4 as struct xattr_gs_args was not acceptable by the wider audience. Incorporate any relevant fixes on the way. v14 (new series): - Reincorporate back into the bugfix series for overlayfs v8: - Documentation reported 'struct xattr_gs_flags' rather than 'struct xattr_gs_flags *args' as argument to get and set methods. v7: - missed spots in fs/9p/acl.c, fs/afs/xattr.c, fs/ecryptfs/crypto.c, fs/ubifs/xattr.c, fs/xfs/libxfs/xfs_attr.c, security/integrity/evm/evm_main.c and security/smack/smack_lsm.c. v6: - kernfs missed a spot v5: - introduce struct xattr_gs_args for get and set methods, __vfs_getxattr and __vfs_setxattr functions. - cover a missing spot in ext2. - switch from snprintf to scnprintf for correctness. v4: - ifdef __KERNEL__ around XATTR_NOSECURITY to keep it colocated in uapi headers. v3: - poor aim on ubifs not ubifs_xattr_get, but static xattr_get v2: - Missed a spot: ubifs, erofs and afs. v1: - Removed from an overlayfs patch set, and made independent. Expect this to be the basis of some security improvements. --- Documentation/filesystems/locking.rst | 2 +- fs/9p/acl.c | 3 ++- fs/9p/xattr.c | 3 ++- fs/afs/xattr.c| 26 ++- fs/btrfs/xattr.c | 3 ++- fs/ceph/xattr.c | 3 ++- fs/cifs/xattr.c | 2 +- fs/ecryptfs/inode.c | 6 +++-- fs/ecryptfs/mmap.c| 2 +- fs/erofs/xattr.c | 3 ++- fs/ext2/xattr_security.c | 2 +- fs/ext2/xattr_trusted.c | 2 +- fs/ext2/xattr_user.c | 2 +- fs/ext4/xattr_security.c | 2 +- fs/ext4/xattr_trusted.c | 2 +- fs/ext4/xattr_user.c | 2 +- fs/f2fs/xattr.c | 4 +-- fs/fuse/xattr.c | 4 +-- fs/gfs2/xattr.c | 3 ++- fs/hfs/attr.c | 2 +- fs/hfsplus/xattr.c| 3 ++- fs/hfsplus/xattr_security.c | 3 ++- fs/hfsplus/xattr_trusted.c| 3 ++- fs/hfsplus/xattr_user.c | 3 ++- fs/jffs2/security.c | 3 ++- fs/jffs2/xattr_trusted.c | 3 ++- fs/jffs2/xattr_user.c | 3 ++- fs/jfs/xattr.c| 5 ++-- fs/kernfs/inode.c | 3 ++- fs/nfs/nfs4proc.c | 6 +++-- fs/ocfs2/xattr.c | 9 --- fs/orangefs/xattr.c | 3 ++- fs/overlayfs/super.c | 8 +++--- fs/posix_acl.c| 2 +- fs/reiserfs/xattr_security.c | 3 ++- fs/reiserfs/xattr_trusted.c | 3 ++- fs/reiserfs/xattr_user.c | 3 ++- fs/squashfs/xattr.c | 2 +- fs/ubifs/xattr.c | 3 ++- fs/xattr.c
[f2fs-dev] fsstress with RENAME_EXCHANGE causing filesystem corruption
RENAME_EXCHANGE support was just added to fsstress in xfstests: commit 65dfd40a97b6bbbd2a22538977bab355c5bc0f06 Author: kaixuxia Date: Thu Oct 31 14:41:48 2019 +0800 fsstress: add EXCHANGE renameat2 support This is causing xfstest generic/579 to fail due to fsck.f2fs reporting errors. I'm not sure what the problem is, but it still happens even with all the fs-verity stuff in the test commented out, so that the test just runs fsstress. generic/579 23s ... [10:02:25] [7.745370] run fstests generic/579 at 2019-11-04 10:02:25 _check_generic_filesystem: filesystem on /dev/vdc is inconsistent (see /results/f2fs/results-default/generic/579.full for details) [10:02:47] Ran: generic/579 Failures: generic/579 Failed 1 of 1 tests Xunit report: /results/f2fs/results-default/result.xml Here's the contents of 579.full: F2FS-tools: mkfs.f2fs Ver: 1.13.0 (2019-11-01) Info: Disable heap-based policy Info: Debug level = 0 Info: Trim is enabled Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 10485760 (5120 MB) Info: zone aligned segment0 blkaddr: 512 Info: format version with "Linux version 5.4.0-rc6 (gcc version 8.3.0 (Debian 8.3.0-6)) #4 SMP Mon Nov 4 09:53:26 PST 2019" Info: [/dev/vdc] Discarding device Info: This device doesn't support BLKSECDISCARD Info: This device doesn't support BLKDISCARD Info: Overprovision ratio = 2.810% Info: Overprovision segments = 148 (GC reserved = 79) Info: format successful F2FS-tools: mkfs.f2fs Ver: 1.13.0 (2019-11-01) Info: Disable heap-based policy Info: Debug level = 0 Info: Trim is enabled Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 10485760 (5120 MB) Info: zone aligned segment0 blkaddr: 512 Info: format version with "Linux version 5.4.0-rc6 (gcc version 8.3.0 (Debian 8.3.0-6)) #4 SMP Mon Nov 4 09:53:26 PST 2019" Info: [/dev/vdc] Discarding device Info: This device doesn't support BLKSECDISCARD Info: This device doesn't support BLKDISCARD Info: Overprovision ratio = 2.810% Info: Overprovision segments = 148 (GC reserved = 79) Info: format successful seed = 1573262300 _check_generic_filesystem: filesystem on /dev/vdc is inconsistent *** fsck.f2fs output *** fsck from util-linux 2.33.1 Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 10485760 (5120 MB) Info: MKFS version "Linux version 5.4.0-rc6 (gcc version 8.3.0 (Debian 8.3.0-6)) #4 SMP Mon Nov 4 09:53:26 PST 2019" Info: FSCK version from "Linux version 5.4.0-rc6 (gcc version 8.3.0 (Debian 8.3.0-6)) #4 SMP Mon Nov 4 09:53:26 PST 2019" to "Linux version 5.4.0-rc6 (gcc version 8.3.0 (Debian 8.3.0-6)) #4 SMP Mon Nov 4 09:53:26 PST 2019" Info: superblock features = 400 : verity Info: superblock encrypt level = 0, salt = Info: total FS sectors = 10485760 (5120 MB) Info: CKPT version = 56bc55fa Info: Checked valid nat_bits in checkpoint Info: checkpoint state = c5 : nat_bits crc compacted_summary unmount [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x24] for '..', parent parent ino is [0xd10] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x239] for '..', parent parent ino is [0x4f5] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x64] for '..', parent parent ino is [0x107] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x3c5] for '..', parent parent ino is [0x22f] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x236] for '..', parent parent ino is [0x249] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x728] for '..', parent parent ino is [0xad3] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x3c5] for '..', parent parent ino is [0x5b2] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x7f4] for '..', parent parent ino is [0x348] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x248] for '..', parent parent ino is [0x34e] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0xa3f] for '..', parent parent ino is [0x2a1] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x2a1] for '..', parent parent ino is [0xa3f] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x707] for '..', parent parent ino is [0x781] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x8f1] for '..', parent parent ino is [0x841] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x3c5] for '..', parent parent ino is [0x41b] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x24] for '..', parent parent ino is [0x6c2] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x4c5] for '..', parent parent ino is [0x7ca] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x500] for '..', parent parent ino is [0xa30] [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x15c] for '..',
Re: [f2fs-dev] [PATCH 3/3] Revert "f2fs: use kvmalloc, if kmalloc is failed"
Hello,
Thanks for the report, I've fixed this.
Thanks,
On 2019/11/2 22:17, kbuild test robot wrote:
> Hi Chao,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on f2fs/dev-test]
> [cannot apply to v5.4-rc5 next-20191031]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Chao-Yu/f2fs-clean-up-check-condition-for-writting-beyond-EOF/20191102-212408
> base: https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
> dev-test
> config: sparc64-allmodconfig (attached as .config)
> compiler: sparc64-linux-gcc (GCC) 7.4.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=sparc64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>):
>
>fs/f2fs/super.c: In function 'destroy_device_list':
>>> fs/f2fs/super.c:1055:17: error: 'struct f2fs_dev_info' has no member named
>>> 'blkz_type'; did you mean 'blkz_seq'?
> kfree(FDEV(i).blkz_type);
> ^
> blkz_seq
>
> vim +1055 fs/f2fs/super.c
>
> 1047
> 1048static void destroy_device_list(struct f2fs_sb_info *sbi)
> 1049{
> 1050int i;
> 1051
> 1052for (i = 0; i < sbi->s_ndevs; i++) {
> 1053blkdev_put(FDEV(i).bdev, FMODE_EXCL);
> 1054#ifdef CONFIG_BLK_DEV_ZONED
>> 1055 kfree(FDEV(i).blkz_type);
> 1056#endif
> 1057}
> 1058kfree(sbi->devs);
> 1059}
> 1060
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
