Message ID | 20230811110304.1613032-1-alexghiti@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b824:0:b0:3f2:4152:657d with SMTP id z4csp1062265vqi; Fri, 11 Aug 2023 05:42:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFpZYRWcXoMDuC/6K7wS7XoTXh3V47kryCplxhmb+ovszRUeokiNhqCcGaIHQ/6GfBCR0ZR X-Received: by 2002:a05:6402:506:b0:523:45df:55c with SMTP id m6-20020a056402050600b0052345df055cmr1482249edv.41.1691757751235; Fri, 11 Aug 2023 05:42:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691757751; cv=none; d=google.com; s=arc-20160816; b=0gNfLYUqf2RKUDZ6EHwUVJpdXtXtHX7lmomjDyXCN9MIP/i7UkUxdJvnXeCCk/70F3 DB9wJIl7+o/cMMLnRTNKeqlUSXn9hzJ9796sog9wOYQcEQfx+tXcaEXJeKOcclaXOnIt PH7c+R/QCbwaf1Md7vmxtc4KzX7gUdftlIJPcIvzQ0MdDDBUBP4JDzii3pmdDcKMP3J4 uz2V2V99h5Y25YxG5n7Yph31iM72QI2pd5SzFq4A0PdAMA1KwPRYLmN4560SIwNZrGIP At9Uq3inlK394D5ozy4vpJk+2zzCca/uSropraiy3+1cEBIRnkIUnI/gyQ+VHIyHdmBn 2Xcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=T5iAe6E8YopchFIRubf33eym0ZyKWuOCfagjLL9eNGQ=; fh=2I4VbIYSzq9QvOWA3RHe8DzXH++YRg2XypMoDXxf2SU=; b=dlsc+WaZAFKlK/Gzi7T5RhxLs+K4fWZsXN8bqICRde8Tn6xqs8/2H+6RObqqcDI4hG UIGsd1in3TcbJqL/O0PuJXe5xMuzjQPRL7B6jt5Ucwp0+0scEJygwLgzpzBy6VQ0QEQ5 xafO6RM+CEIJsS97bJ68H5RFhyQWqU1hH54C1Iy1NrJfzCLRgvOuXXonxWW8x543h0gT QcjmPfYm+ZgxpUtA4eepzi9n0dlv1kLkoiwm7K/CfGOUweHaGkMgSh2F/cRATRsln5CF zArs4OfYrJ7yhkAslR94BgjcNrH5i4Cb9imVPaMA1lQAHF1fJerRARPTSwbAthGTiCSw dGmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=4jTMNejE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d4-20020aa7c1c4000000b005232b615feasi3262589edp.568.2023.08.11.05.42.07; Fri, 11 Aug 2023 05:42:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=4jTMNejE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235987AbjHKLDS (ORCPT <rfc822;shaohuahua6@gmail.com> + 99 others); Fri, 11 Aug 2023 07:03:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235374AbjHKLDL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 11 Aug 2023 07:03:11 -0400 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5889A1718 for <linux-kernel@vger.kernel.org>; Fri, 11 Aug 2023 04:03:08 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-3fe5c0e57d2so16201295e9.0 for <linux-kernel@vger.kernel.org>; Fri, 11 Aug 2023 04:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1691751787; x=1692356587; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=T5iAe6E8YopchFIRubf33eym0ZyKWuOCfagjLL9eNGQ=; b=4jTMNejEAHGjjdu5dt8hMdVIR18zFTNB23v5xfp1DbngEKKqPM3LxeD22bbMR7489w SW1hKZanHIl7go1DSioiE/bZzAEonHuybk6hbVmssovIsAXgqA+PlBw0OLiLGYqBfpCD RZnZjSKfELh+G5hCy+F4RhZOvPTj4Y4dfbWbBgxayHB5neawBUxxXGrLzhAjozmPmn6B neVCO1hLrP54QzdesuJGsxGfFBSFZLVkL4KdJ+4ePAWxlDQHk4vAHrVZx9wSz1soSGmy Rl06TCI4KxH+J//mLP7BSNINuH68ssv1cM8sQWYfPai5tra1Lap8wSjq9Z9Yu7HKDyna cA3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691751787; x=1692356587; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T5iAe6E8YopchFIRubf33eym0ZyKWuOCfagjLL9eNGQ=; b=gAmtiVYjolIZyM/aN6CippAHXaaguyecudyAC7RDzOUVyr1sekmWfs/PX2z6O9UVxK /tHAihTiX8Fltu5ze+1DnBAJZzylMPXZkrNHJRGNe+C842ajvcmf1p4OOesZvt5M6So5 Tebe/1ZEdpZ9D4d3ECOX3vYxU6GPzvLAomHE9JJW6FuOtMuWrWKQZN4WoMKUGQmyvQhe hHEtOLW50AzK+Ujhc1DND9V7VkPplm/PUpPkmGf/Dv6yHaFLXk+DsWjBUH1u9uRdGbxR wKUTFj9QaL9vQRtSmJeGBv7Lcyjv3IgttJTC9w7H1bskfoF7IayJ7SvFU7L3UJdbWefk 4Upg== X-Gm-Message-State: AOJu0Yx5zbL9CXgxofprqq2IO4WEmSb9gLFFyglZF37ZVZUwucIaRh0m INGUPAI67gHn5U2C3tZaRE6Lpg== X-Received: by 2002:a05:600c:22da:b0:3f7:e3dd:8a47 with SMTP id 26-20020a05600c22da00b003f7e3dd8a47mr1371440wmg.11.1691751786608; Fri, 11 Aug 2023 04:03:06 -0700 (PDT) Received: from alex-rivos.ba.rivosinc.com (amontpellier-656-1-456-62.w92-145.abo.wanadoo.fr. [92.145.124.62]) by smtp.gmail.com with ESMTPSA id f21-20020a7bcc15000000b003fc01189b0dsm4792119wmh.42.2023.08.11.04.03.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Aug 2023 04:03:06 -0700 (PDT) From: Alexandre Ghiti <alexghiti@rivosinc.com> To: Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Alan Kao <alankao@andestech.com>, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Alexandre Ghiti <alexghiti@rivosinc.com>, Bo YU <tsu.yubo@gmail.com>, Aurelien Jarno <aurelien@aurel32.net> Subject: [PATCH -fixes] riscv: uaccess: Return the number of bytes effectively copied Date: Fri, 11 Aug 2023 13:03:04 +0200 Message-Id: <20230811110304.1613032-1-alexghiti@rivosinc.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773934910623067208 X-GMAIL-MSGID: 1773936575328388235 |
Series |
[-fixes] riscv: uaccess: Return the number of bytes effectively copied
|
|
Commit Message
Alexandre Ghiti
Aug. 11, 2023, 11:03 a.m. UTC
It was reported that the riscv kernel hangs while executing the test
in [1].
Indeed, the test hangs when trying to write a buffer to a file. The
problem is that the riscv implementation of raw_copy_from_user() does not
return the number of bytes written when an exception happens and is fixed
up.
generic_perform_write() pre-faults the user pages and bails out if nothing
can be written, otherwise it will access the userspace buffer: here the
riscv implementation keeps returning it was not able to copy any byte
though the pre-faulting indicates otherwise. So generic_perform_write()
keeps retrying to access the user memory and ends up in an infinite
loop.
Note that before the commit mentioned in [1] that introduced this
regression, it worked because generic_perform_write() would bail out if
only one byte could not be written.
So fix this by returning the number of bytes effectively written in
__asm_copy_[to|from]_user() and __clear_user(), as it is expected.
[1] https://lore.kernel.org/linux-riscv/20230309151841.bomov6hq3ybyp42a@debian/
Fixes: ebcbd75e3962 ("riscv: Fix the bug in memory access fixup code")
Reported-by: Bo YU <tsu.yubo@gmail.com>
Closes: https://lore.kernel.org/linux-riscv/20230309151841.bomov6hq3ybyp42a@debian/#t
Reported-by: Aurelien Jarno <aurelien@aurel32.net>
Closes: https://lore.kernel.org/linux-riscv/ZNOnCakhwIeue3yr@aurel32.net/
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
---
arch/riscv/lib/uaccess.S | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
Comments
Alexandre Ghiti <alex@ghiti.fr> writes: > On 11/08/2023 13:03, Alexandre Ghiti wrote: >> It was reported that the riscv kernel hangs while executing the test >> in [1]. >> >> Indeed, the test hangs when trying to write a buffer to a file. The >> problem is that the riscv implementation of raw_copy_from_user() does not >> return the number of bytes written when an exception happens and is fixed >> up. > > > I'll respin another version as the changelog and the title are > incorrect: the uaccess routines should not return the number of bytes > copied but actually the number of bytes not copied (this is what this > patch implements). > > I'll wait for feedbacks before doing so! Yikes! Nice catch. Functions like fault_in_readable() will fail horribly w/o this. I wonder why we haven't seen this problem more? Feel free to add my RB to your next spin! Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
Hi Alexandre, On 2023-08-11 13:03, Alexandre Ghiti wrote: > It was reported that the riscv kernel hangs while executing the test > in [1]. > > Indeed, the test hangs when trying to write a buffer to a file. The > problem is that the riscv implementation of raw_copy_from_user() does not > return the number of bytes written when an exception happens and is fixed > up. > > generic_perform_write() pre-faults the user pages and bails out if nothing > can be written, otherwise it will access the userspace buffer: here the > riscv implementation keeps returning it was not able to copy any byte > though the pre-faulting indicates otherwise. So generic_perform_write() > keeps retrying to access the user memory and ends up in an infinite > loop. > > Note that before the commit mentioned in [1] that introduced this > regression, it worked because generic_perform_write() would bail out if > only one byte could not be written. > > So fix this by returning the number of bytes effectively written in > __asm_copy_[to|from]_user() and __clear_user(), as it is expected. > > [1] https://lore.kernel.org/linux-riscv/20230309151841.bomov6hq3ybyp42a@debian/ > > Fixes: ebcbd75e3962 ("riscv: Fix the bug in memory access fixup code") > Reported-by: Bo YU <tsu.yubo@gmail.com> > Closes: https://lore.kernel.org/linux-riscv/20230309151841.bomov6hq3ybyp42a@debian/#t > Reported-by: Aurelien Jarno <aurelien@aurel32.net> > Closes: https://lore.kernel.org/linux-riscv/ZNOnCakhwIeue3yr@aurel32.net/ > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> > --- > arch/riscv/lib/uaccess.S | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) Thanks for providing a patch so fast. I confirm that the issue I reported is fixed, but also that the full strace testsuite now passes successfully. The code looks all good to me, so: Tested-by: Aurelien Jarno <aurelien@aurel32.net> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
diff --git a/arch/riscv/lib/uaccess.S b/arch/riscv/lib/uaccess.S index ec486e5369d9..09b47ebacf2e 100644 --- a/arch/riscv/lib/uaccess.S +++ b/arch/riscv/lib/uaccess.S @@ -17,8 +17,11 @@ ENTRY(__asm_copy_from_user) li t6, SR_SUM csrs CSR_STATUS, t6 - /* Save for return value */ - mv t5, a2 + /* + * Save the terminal address which will be used to compute the number + * of bytes copied in case of a fixup exception. + */ + add t5, a0, a2 /* * Register allocation for code below: @@ -176,7 +179,7 @@ ENTRY(__asm_copy_from_user) 10: /* Disable access to user memory */ csrc CSR_STATUS, t6 - mv a0, t5 + sub a0, t5, a0 ret ENDPROC(__asm_copy_to_user) ENDPROC(__asm_copy_from_user) @@ -228,7 +231,7 @@ ENTRY(__clear_user) 11: /* Disable access to user memory */ csrc CSR_STATUS, t6 - mv a0, a1 + sub a0, a3, a0 ret ENDPROC(__clear_user) EXPORT_SYMBOL(__clear_user)