Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3408739ybi; Tue, 2 Jul 2019 07:17:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyPZGLgwyx5fXMR4bt1RlwdvImuPLySJ22XtHXuPfY+HnvMK/1EhtHdck9n90drD842x50K X-Received: by 2002:a17:90a:2343:: with SMTP id f61mr5979418pje.130.1562077043451; Tue, 02 Jul 2019 07:17:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562077043; cv=none; d=google.com; s=arc-20160816; b=DVMrHrtQ+8VLsm1dj090wa+FevCjUBPrBQbXzpZJzIPa0x4MERTEYWeyfjoD7RmlHp bgGr7DZIsjtkUesPODDVsKGmqb/I7c6q5/biLQnyMRY79dGheUlqcbq4Nj3IchTjWUU3 FPR/Ucl1KTxIhbDaFOMQN+jlgFlbMkOJVpKdrjnO7nrXhbAMQT05Dk8XmZh2YeMMAa1/ rvOc+qdIoaMICwpFEqh32+gKxi/BtaE0ZjTyZrQ1YqnZYFpP4cjXW/lBh/Ujl4IyvaEV +EeqWXUCXaLr6wefzN7uHj3NJn03qjIodEvMCwTse3isazwXGbmPBaO6ExGkZAWRhCLG GnTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=xRhLNTZFBCQneWjM1icf/K5pRWGUkLbrIMvkVnI3VvA=; b=rewmwQREXd5oFoDwwGaBZNorynJXIaDuhHzAcRHicRioopVTIoroi1BBIVS5k8Dmmb DkEVFlBl7tZnIXS+hkL5NJqunKGK7uYpt75FGEWmDJu/mR97yQr3xzBEGrAPLdKEki9a 013xIGTbBvX6p0Q4N8Cl5p/Qicb/wCkYILh6nwFTsXyMz2s72rVi0hYi6/8QG9WBw7z1 OncRI4QRyVkmt+PyPR3iG9gge2tigWtFoCzi/bSniyjYdoiBsOEBoQn/OfE8RCc5hUPo CCSBbfSWamalhS3lKoD/eqQZdF5D3d4g/tbTuz6hQOCYKxJtKaqfX3SCRnvcsuzPfucb ileg== 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 z11si12784635pgl.7.2019.07.02.07.17.08; Tue, 02 Jul 2019 07:17:23 -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; 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 S1727109AbfGBOOX (ORCPT + 99 others); Tue, 2 Jul 2019 10:14:23 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:45979 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726341AbfGBOOX (ORCPT ); Tue, 2 Jul 2019 10:14:23 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hiJXq-0002S7-DV; Tue, 02 Jul 2019 16:14:06 +0200 Date: Tue, 2 Jul 2019 16:14:05 +0200 (CEST) From: Thomas Gleixner To: Peter Zijlstra cc: Eiichi Tsukata , rostedt@goodmis.org, edwintorok@gmail.com, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, Josh Poimboeuf Subject: Re: [PATCH] x86/stacktrace: Do not access user space memory unnecessarily In-Reply-To: <20190702072821.GX3419@hirez.programming.kicks-ass.net> Message-ID: References: <20190702053151.26922-1-devel@etsukata.com> <20190702072821.GX3419@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Jul 2019, Peter Zijlstra wrote: > On Tue, Jul 02, 2019 at 02:31:51PM +0900, Eiichi Tsukata wrote: > > Put the boundary check before it accesses user space to prevent unnecessary > > access which might crash the machine. > > > > Especially, ftrace preemptirq/irq_disable event with user stack trace > > option can trigger SEGV in pid 1 which leads to panic. It triggers segfaults in random user processes which is bad enough. And even with that 'fix' applied I can see random segfaults just less frequent. > > RIP: 0033:0x55be7ad1c89f > > Code: Bad RIP value. > > ^^^ that's weird, no amount of unwinding should affect regs->ip. True. I've gathered a trace from a crash. It's available here: https://tglx.de/~tglx/log.1.xz The interesting part is: [ 352.756926] systemd-1 1d..2 346277977us : 0000000004 [ 352.756926] => <00007f785ae26289> [ 352.758084] systemd-1 1...1 346277978us : sys_clone -> 0x495 [ 352.758846] systemd-1 1...1 346277978us : 5 [ 352.758846] => do_syscall_64 [ 352.758846] => entry_SYSCALL_64_after_hwframe [ 352.760399] systemd-1 1...1 346277979us : [ 352.760399] => <00007f785ae26289>TS] [ 352.761556] systemd-1 1d... 346277979us : irq_disable: caller=do_syscall_64+0x87/0x110 parent=entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 352.763048] systemd-1 1d... 346277979us : [ 352.763048] => trace_hardirqs_off [ 352.763048] => do_syscall_64 [ 352.763048] => entry_SYSCALL_64_after_hwframe [ 352.765015] systemd-1 1d... 346277979us : <00007f785ae26289> [ 352.766173] systemd-1 1d... 346277980us : irq_enable: caller=trace_hardirqs_on_thunk+0x1a/0x1c parent=entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 352.767745] systemd-1 1d... 346277980us : [ 352.767745] => trace_hardirqs_on_caller [ 352.767745] => trace_hardirqs_on_thunk [ 352.767745] => entry_SYSCALL_64_after_hwframe [ 352.769831] systemd-1 1d... 346277981us : [ 352.769831] => <00007f785ae26289> [ 352.770989] systemd-1 1d... 346277982us : irq_disable: caller=trace_hardirqs_off_thunk+0x1a/0x1c parent=error_entry+0x80/0x100 [ 352.772408] systemd-1 1d... 346277983us : [ 352.772408] => trace_hardirqs_off_caller [ 352.772408] => trace_hardirqs_off_thunk [ 352.772408] => error_entry [ 352.774334] systemd-1 1d... 346277983us : [ 352.774334] => <00005614ef9dde48>ter_hwframe [ 352.775505] systemd-1 1d... 346277984us : page_fault_user: address=0x7ffd52fd0038 ip=0x5614ef9dde48 error_code=0x7 [ 352.776811] systemd-1 1d... 346277984us : -UU-52.776811] => do_page_fault 52.776811] => do_async_page_fault .... [ 353.078313] => <00005614ef9dde48> [ 353.079486] systemd-1 1d... 346278040us : irq_disable: caller=trace_hardirqs_off_thunk+0x1a/0x1c parent=error_entry+0x80/0x100 [ 353.080952] systemd-1 1d... 346278041us : [ 353.080952] => trace_hardirqs_off_caller [ 353.080952] => trace_hardirqs_off_thunk6278021us : [ 353.080952] => error_entry [ 353.082890] systemd-1 1d... 346278041us : rcu_irq_exit_irqson+0x2b/0x30 parent=trace_preempt_off+0xa1/0xd0 [ 353.082890] => <00007f785ab9ba85> [ 353.084059] systemd-1 1d... 346278042us : page_fault_user: address=0x495 ip=0x7f785ab9ba85 error_code=0x7p_page_copy+0x344/0x790 [ 353.085277] systemd-1 1d... 346278042us : [ 353.085277] => do1 1...1 346278034us : do_async_page_fault [ 353.085277] => async_page_fault [ 353.087114] systemd-1 1d... 346278043us : [ 353.087114] => <00007f785ab9ba85> [ 353.088391] systemd-1 1d... 346278043us : irq_enable: caller=__do_page_fault+0x2a7/0x4b0 parent=do_page_fault+0x28/0xf0 [ 353.089761] systemd-1 1d... 346278044us : That last #PF kills it. What's weird is the PF address 0x495 which is the return value of sys_clone() above. Might be coincidence, but I don't think so. Haven't had time to dig deeper. Thanks, tglx