From patchwork Tue Sep 13 02:05:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kaixu Xia X-Patchwork-Id: 76034 Delivered-To: patch@linaro.org Received: by 10.140.106.72 with SMTP id d66csp1134195qgf; Mon, 12 Sep 2016 19:06:13 -0700 (PDT) X-Received: by 10.66.100.162 with SMTP id ez2mr39090818pab.123.1473732373050; Mon, 12 Sep 2016 19:06:13 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s126si24643084pfb.16.2016.09.12.19.06.12; Mon, 12 Sep 2016 19:06:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-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-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753959AbcIMCGG (ORCPT + 1 other); Mon, 12 Sep 2016 22:06:06 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:32776 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753940AbcIMCGF (ORCPT ); Mon, 12 Sep 2016 22:06:05 -0400 Received: from 172.24.1.47 (EHLO SZXEML424-HUB.china.huawei.com) ([172.24.1.47]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id CHR70995; Tue, 13 Sep 2016 10:05:27 +0800 (CST) Received: from [127.0.0.1] (10.111.182.180) by SZXEML424-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server id 14.3.235.1; Tue, 13 Sep 2016 10:05:16 +0800 Subject: Re: Kernel panic - encryption/decryption failed when open file on Arm64 To: Ard Biesheuvel , Herbert Xu References: <57D15BD3.40903@huawei.com> <20160908124709.GA26586@gondor.apana.org.au> <57D28CB8.4080904@huawei.com> <00B10D30F2BAA743B48953A4D86C96D54C8A8A@SZXEMI506-MBS.china.huawei.com> CC: liushuoran , "David S. Miller" , "Theodore Ts'o" , Jaegeuk Kim , "nhorman@tuxdriver.com" , "mh1@iki.fi" , "linux-crypto@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Wangbintian , Huxinwei , "zhangzhibin (C)" From: xiakaixu Message-ID: <57D75ED7.7080602@huawei.com> Date: Tue, 13 Sep 2016 10:05:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.111.182.180] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.57D75EEA.00AA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 11d8944132b7b6b872f38d5eb746961c Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org > On 12 September 2016 at 03:16, liushuoran wrote: >> Hi Ard, >> >> Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway. >> >> As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll simply switch over to processing it block by block". So does that mean the encryption/decryption should be successful even if the page allocation fails? Please correct me if I misunderstand anything. Thanks in advance. >> > > Perhaps Herbert can explain: I don't see how the 'n = 0' assignment > results in the correct path being taken; this chunk (blkcipher.c:252) > > if (unlikely(n < bsize)) { > err = blkcipher_next_slow(desc, walk, bsize, walk->alignmask); > goto set_phys_lowmem; > } > > is skipped due to the fact that n == 0 and therefore bsize == 0, and > so the condition is always false for n == 0 > > Therefore we end up here (blkcipher.c:257) > > walk->nbytes = n; > if (walk->flags & BLKCIPHER_WALK_COPY) { > err = blkcipher_next_copy(walk); > goto set_phys_lowmem; > } > > where blkcipher_next_copy() unconditionally calls memcpy() with > walk->page as destination (even though we ended up here due to the > fact that walk->page == NULL) > > So to me, it seems like we should be taking the blkcipher_next_slow() > path, which does a kmalloc() and bails with -ENOMEM if that fails. Hi Ard, Thanks for such a detailed reply. According to your reply, I just make a little change to take the blkcipher_next_slow() path. I test it on arm64 board, there is no panic anymore and seems the encryption/decryption is successful. It is just a trial and not sure it makes sense. But anyway, we can do something here to fix the crash result from the page allocation failure. What's your opinions, Herbert? Regards Kaixu Xia > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c index 0122bec..5389d40 100644 --- a/crypto/blkcipher.c +++ b/crypto/blkcipher.c @@ -240,12 +240,13 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc, walk->flags |= BLKCIPHER_WALK_COPY; if (!walk->page) { walk->page = (void *)__get_free_page(GFP_ATOMIC); + walk->page = NULL; if (!walk->page) n = 0; } } - bsize = min(walk->walk_blocksize, n); + bsize = walk->walk_blocksize; n = scatterwalk_clamp(&walk->in, n); n = scatterwalk_clamp(&walk->out, n);