Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1162580ybb; Fri, 3 Apr 2020 20:15:40 -0700 (PDT) X-Google-Smtp-Source: APiQypKNEykdMldIYn8vCqK35FdlbTx6M68AuoHfsdf11Kg13sabDZ3Fx4T1xvnpFnpFUzBbdzvQ X-Received: by 2002:a05:6830:1c7:: with SMTP id r7mr9249233ota.58.1585970140581; Fri, 03 Apr 2020 20:15:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585970140; cv=none; d=google.com; s=arc-20160816; b=yMrPtEFGkDqczsagoCM1dYMxIMmg1Bn1PRgqEOVIUrnw4iGZZYyOv5BjyQNuXSyzfR bM0nC36dRCgcJPQ4pgRcUc/Z+SqCn62Pzi/XPfqGUKIEZJa5elF6a53h55ahQfEDiwJf s5j5qqiZxQK7s5HLg9fbdrkMmuy7sfiXB33c8Wwt0nIsINYg4v61iCI4vi52rODzxKdS HgAM6V2UyyvCDnuSM+rbiSGBLPIhhDb5KsgGHzkyl+K3vnpO+H+e1WYaVutHuLzK3PCQ SVXWDpKA5Pp1TOYAaWblZlUHrSKj2cLBJ5r+rrtcTLRsqgL0+3M2v47vpoIYXnWSYGL9 4cNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=HQzIJIpQMelVal6iTR5y6Y7xPjfkwcDxzcUjZCqcKEU=; b=TyMXvObtNRuHo2/xpWSG/bECxYSnd476QpuLLss4Sa3kK/ReZWENFeHn/C9e0bOSUc U/tsktHwT/pfYlMh/EJQFZV+59zW4AkuCMlGfswRhoIh0SNMFQFNgVpRVmGELEpvJGdL HkEXw7rcedfTiOxQuezmQGQUr+leM4mlVfpwzsE9l5SSp1AQzpkKvnIAeLpJzMKzgw/P mmIGWW69Vnz6lveB6IXP2qN0OOhYVibJ8wrJg4ERZypgHr7kLJxM1ZfH+YJikP08oCzB Lt+79u9BXmpJ5o9ski3DzTNPhHKPKIv0SsgtP6AyRMl7v17Y2XqOUDq9oIzwoSjdOtS1 cFsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kyIC+9Ga; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x64si4529800oig.34.2020.04.03.20.15.27; Fri, 03 Apr 2020 20:15:40 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=kyIC+9Ga; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726230AbgDDDOf (ORCPT + 99 others); Fri, 3 Apr 2020 23:14:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:38194 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726186AbgDDDOf (ORCPT ); Fri, 3 Apr 2020 23:14:35 -0400 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (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 8B200206E2; Sat, 4 Apr 2020 03:14:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585970074; bh=4Lmz+/S7SlPMvBnfl+eEEwjVNnxHk+Bjv+KwNBduwyc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kyIC+9GaonW5ruza0M6g0/ynePvKYZ0yHSqC7gusaQwnIP3H5nakQfDkWHbmmKFTB tOxRT39pzl2KMlmDZaYr2Rv4qpbSUY8Kz55Zmrk8Uo4oSmae23hSxxgHIyE7i5ijU2 nqN9TPh+A0SMorxTDUt97QNxDzS86cp0h9ydJhHA= Date: Sat, 4 Apr 2020 12:14:28 +0900 From: Masami Hiramatsu To: Zong Li Cc: Palmer Dabbelt , Paul Walmsley , Albert Ou , linux-riscv , "linux-kernel@vger.kernel.org List" Subject: Re: [PATCH v3 8/9] riscv: introduce interfaces to patch kernel code Message-Id: <20200404121428.596911ba5653f8b18a80eab2@kernel.org> In-Reply-To: References: <20200401003233.17fe4b6f7075e5b8f0ed5114@kernel.org> <20200402101733.1ef240faeaeada6e4d38ae80@kernel.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Zong, On Fri, 3 Apr 2020 17:04:51 +0800 Zong Li wrote: > > > > > +{ > > > > > + void *waddr = addr; > > > > > + bool across_pages = (((uintptr_t) addr & ~PAGE_MASK) + len) > PAGE_SIZE; > > > > > + unsigned long flags = 0; > > > > > + int ret; > > > > > + > > > > > + raw_spin_lock_irqsave(&patch_lock, flags); > > > > > > > > This looks a bit odd since stop_machine() is protected by its own mutex, > > > > and also the irq is already disabled here. > > > > > > We need it because we don't always enter the riscv_patch_text_nosync() > > > through stop_machine mechanism. If we call the > > > riscv_patch_text_nosync() directly, we need a lock to protect the > > > page. > > > > Oh, OK, but it leads another question. Is that safe to patch the > > text without sync? Would you use it for UP system? > > I think it is better to clarify "in what case user can call _nosync()" > > and add a comment on it. > > The ftrace is one of the cases, as documentation of ftrace said, when > dynamic ftrace is initialized, it calls kstop_machine to make the > machine act like a uniprocessor so that it can freely modify code > without worrying about other processors executing that same code. So > the ftrace called the _nosync interface here directly. Hmm, even though, since it already running under kstop_machine(), no other thread will run. Could you consider to use text_mutex instead of that? The text_mutex is already widely used in x86 and kernel/kprobes.c etc. (Hmm, it seems except for x86, alternative code don't care about racing...) Thank you, -- Masami Hiramatsu