Received: by 10.223.185.116 with SMTP id b49csp6917791wrg; Wed, 28 Feb 2018 18:51:12 -0800 (PST) X-Google-Smtp-Source: AG47ELvQtziueTZj9nI7GElksf48whzjGWVUbDd4iKrdxRH2gsfcAD2+LsIrMeWr9Bos2I06ZngZ X-Received: by 2002:a17:902:d81:: with SMTP id 1-v6mr359912plv.324.1519872672687; Wed, 28 Feb 2018 18:51:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519872672; cv=none; d=google.com; s=arc-20160816; b=EXWd1s7o/pOLvOC9NeTxX1pbVz53C9KGNN8tG53HMqpyKpqgeE8lvK3HaeTSBTBcZS dCRIafTm7Z9Qa3JRym8lDDwflBy3AdSo5R/b7mLPwJ7D5tXzXvHHfpJxiWpsLAlHSK+f 4x/+CJvMU1QvrUzB2XhgOxZUZR12LvwlytSwIpwSIXNmXFXk9ZLWD5VhLJ3f1ch4h+8V ARPl4ZZwiJMjjJzyi6uwAh8rucK062SiB0JssyX2gXUDZjnwfgksf8QSzkaedHLYmnyf RVnO4MC2m805HcDHC5r1VvG1pTiuQiF9g1/g7+spH+tukUmrkExRD4X7cmwKCTHSGyj3 FqCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:arc-authentication-results; bh=MY6zFmaA1g9Y43x1Cv/luM+raWy1BSwGiAUx9k1JXyA=; b=qOI7MyvgoO9OcKfDK306EdguNTxj/1bTzkXa4IL4/RH+Z/7jW8woQEVttAbmlIYnC+ NGFswYP+i+d32eUdchxDQIoaJyvG/YuMd1lqu/b9OkyaU+6DwtudJd0vUviN6r2+ltRx uPi6oKXcz42KVYeaTRlC6p6fSQHI0gRThtwciwUAxlmL2jERWuM56yT67nKOplAI67Qs RsEAz+vtycIwIINRTghDLT0G7UXqASIOj34ditcn2IW1tbZ0gwkp5qR0ErM5+q9Qf5ww 4Xx3eWOK7RY0drMCEICr0TJGzSBsHvTAijikVnkGpUaYyg9Y+wHdupRFZ3vqUlMMNY/J XKWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w130si2198615pfd.280.2018.02.28.18.50.58; Wed, 28 Feb 2018 18:51:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965549AbeCACuM (ORCPT + 99 others); Wed, 28 Feb 2018 21:50:12 -0500 Received: from mail.kernel.org ([198.145.29.99]:47028 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965488AbeCACuL (ORCPT ); Wed, 28 Feb 2018 21:50:11 -0500 Received: from localhost (unknown [104.132.1.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 90C8D214EE; Thu, 1 Mar 2018 02:50:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90C8D214EE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jaegeuk@kernel.org Date: Wed, 28 Feb 2018 18:50:09 -0800 From: Jaegeuk Kim To: Chao Yu Cc: Yunlong Song , chao@kernel.org, yunlong.song@icloud.com, miaoxie@huawei.com, bintian.wang@huawei.com, shengyong1@huawei.com, heyunlei@huawei.com, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] Revert "f2fs crypto: avoid unneeded memory allocation in ->readdir" Message-ID: <20180301025009.GC18665@jaegeuk-macbookpro.roam.corp.google.com> References: <1519463698-60555-1-git-send-email-yunlong.song@huawei.com> <1519787857-107910-1-git-send-email-yunlong.song@huawei.com> <20180228054810.GB86647@jaegeuk-macbookpro.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/28, Chao Yu wrote: > Hi Jaegeuk, > > On 2018/2/28 13:48, Jaegeuk Kim wrote: > > Hi Yunlong, > > > > As Eric pointed out, how do you think using nohighmem for directory likewise > > I'd like to ask, at the beginning, why we choose to use highmem for dentry page? > any history reason there? There was no huge preference on it based on performance. I just wanted not to abuse lowmem. Thanks, > > > ext4, which looks like more efficient? Actually, we don't need to do this in > > most of recent kernels, right? > > It's OK to me to keep a line with ext4. > > Thanks, > > > > > Thanks, > > > > On 02/28, Yunlong Song wrote: > >> This reverts commit e06f86e61d7a67fe6e826010f57aa39c674f4b1b. > >> > >> Conflicts: > >> fs/f2fs/dir.c > >> > >> In some platforms (such as arm), high memory is used, then the > >> decrypting filename will cause panic, the reason see commit > >> 569cf1876a32e574ba8a7fb825cd91bafd003882 ("f2fs crypto: allocate buffer > >> for decrypting filename"): > >> > >> We got dentry pages from high_mem, and its address space directly goes into the > >> decryption path via f2fs_fname_disk_to_usr. > >> But, sg_init_one assumes the address is not from high_mem, so we can get this > >> panic since it doesn't call kmap_high but kunmap_high is triggered at the end. > >> > >> kernel BUG at ../../../../../../kernel/mm/highmem.c:290! > >> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM > >> ... > >> (kunmap_high+0xb0/0xb8) from [] (__kunmap_atomic+0xa0/0xa4) > >> (__kunmap_atomic+0xa0/0xa4) from [] (blkcipher_walk_done+0x128/0x1ec) > >> (blkcipher_walk_done+0x128/0x1ec) from [] (crypto_cbc_decrypt+0xc0/0x170) > >> (crypto_cbc_decrypt+0xc0/0x170) from [] (crypto_cts_decrypt+0xc0/0x114) > >> (crypto_cts_decrypt+0xc0/0x114) from [] (async_decrypt+0x40/0x48) > >> (async_decrypt+0x40/0x48) from [] (f2fs_fname_disk_to_usr+0x124/0x304) > >> (f2fs_fname_disk_to_usr+0x124/0x304) from [] (f2fs_fill_dentries+0xac/0x188) > >> (f2fs_fill_dentries+0xac/0x188) from [] (f2fs_readdir+0x1f0/0x300) > >> (f2fs_readdir+0x1f0/0x300) from [] (vfs_readdir+0x90/0xb4) > >> (vfs_readdir+0x90/0xb4) from [] (SyS_getdents64+0x64/0xcc) > >> (SyS_getdents64+0x64/0xcc) from [] (ret_fast_syscall+0x0/0x30) > >> > >> Howerver, later patch: > >> commit e06f86e61d7a ("f2fs crypto: avoid unneeded memory allocation in ->readdir") > >> reverts the codes, which causes panic again in arm, so fix it back to the old version. > >> > >> Signed-off-by: Yunlong Song > >> Reviewed-by: Chao Yu > >> --- > >> fs/f2fs/dir.c | 7 +++++++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c > >> index f00b5ed..de2e295 100644 > >> --- a/fs/f2fs/dir.c > >> +++ b/fs/f2fs/dir.c > >> @@ -825,9 +825,16 @@ int f2fs_fill_dentries(struct dir_context *ctx, struct f2fs_dentry_ptr *d, > >> int save_len = fstr->len; > >> int err; > >> > >> + de_name.name = f2fs_kmalloc(sbi, de_name.len, GFP_NOFS); > >> + if (!de_name.name) > >> + return -ENOMEM; > >> + > >> + memcpy(de_name.name, d->filename[bit_pos], de_name.len); > >> + > >> err = fscrypt_fname_disk_to_usr(d->inode, > >> (u32)de->hash_code, 0, > >> &de_name, fstr); > >> + kfree(de_name.name); > >> if (err) > >> return err; > >> > >> -- > >> 1.8.5.2 > > > > . > >