Received: by 10.192.165.148 with SMTP id m20csp3993589imm; Tue, 8 May 2018 00:42:12 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr+gnlzqsdviNcLpFIPvugkJ52ezrJX8BQ2UjkQcDqi8C6i4OyMTXchs5XEYOqwDXymHphK X-Received: by 2002:a17:902:3001:: with SMTP id u1-v6mr40471547plb.164.1525765332056; Tue, 08 May 2018 00:42:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525765332; cv=none; d=google.com; s=arc-20160816; b=MJmQ6CwL6Ft7hSipAyuT9nisB8OdWfL1id4cpRpDQqbfLZ5inMiAqHJMPtDhrk2Dwy khw9VY2JSug4gOEyS+Ut3zHY2bPc/K5fm/RE+xa2Lj1R6g/T1SDegmvhATcuWH9/alFc 6pMde9pQYpFY8Rbt1IGVt4YR2EcSXn4gXzdnTej972z6lsYUKtYa9cnRFjq6IkLAb7Iz JDWPGVA0uLy54txPRvusbs+j9gSmAIKqcKOI13JCSvoP7feUb7q1KMz7jrPKX/2+uaad QQWiZmXSRiEsncTog1MRmCrQkHaKkTLdwXvWUzJpESnQBtmBS4MIth5Jnel94A0ZVBzD Ny1Q== 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:arc-authentication-results; bh=U2XDvZN3kS4HYddL8lTNsOTAbKNytgZpIaYH1uWoJpk=; b=FiSzmdtsZWlIIgv4883CJrQJnN0Nah2zNQiH4rQLczGpN273Dglg0EUkEK7B92WUMi FSqXTQBEkoYy4fenHV/ick/lUZfb0nrzA4iqcrVoEMtj+8Ovxsqny52QculZ2GTtsu7E dt2RrHYXqzl8IaLxp2g6AC9CJZ5SEmC7WiRuA6rhK/75Sz3zZG5XgxfLKby+qn0CwfgP DjQaUj+HrvGHcggDogUXoDh+MNbytyKHDbfj/1bbGTO3IfjV4pdjzCts0bDGsBJJHXM0 HMaVHP1GaRVw27AKVM5mBXDOTtprKPT2sM16DitjOwqLihryUq2rs+qTxecZ+SypIU2+ rLtQ== 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 u6-v6si24083732plz.461.2018.05.08.00.41.58; Tue, 08 May 2018 00:42:12 -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 S1754795AbeEHHkV (ORCPT + 99 others); Tue, 8 May 2018 03:40:21 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:54965 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754599AbeEHHkU (ORCPT ); Tue, 8 May 2018 03:40:20 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1fFxEN-0005FH-B9; Tue, 08 May 2018 09:40:15 +0200 Date: Tue, 8 May 2018 09:40:14 +0200 From: Sebastian Andrzej Siewior To: Daniel Wagner Cc: linux-kernel@vger.kernel.org, Geert Uytterhoeven , linux-rt-users@vger.kernel.org, linux-serial@vger.kernel.org, linux-sh@vger.kernel.org, gregkh@linuxfoundation.org, Daniel Wagner Subject: Re: [PATCH v2] serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version Message-ID: <20180508074013.w3lzbwzrym76li2e@linutronix.de> References: <20180504163041.28726-1-wagi@monom.org> <20180507125146.75crpaj2scav7mql@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180323 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-05-08 09:18:44 [+0200], Daniel Wagner wrote: > Hi Sebastian, Hi, > Should 'echo t > /proc/sysrq' trigger the splat? At least I was so naive > that think it would be enough. No, this is a different interface. The thing is you send the BREAK command and then, the next character (within a timeout) that comes over the UART is the MAGIC request. While that character is being received the sysrq request is answered and output is written to the console which is probably the UART and so you can't acquire the lock again. So you can't acquire the lock. I added a try_lock once to at least try to acquire the lock because this may race against a printk() from another CPU. But then someone complained about a failed try_lock on UP (this can't happen on UP unless in a scenario like this where the lock is already acquired) so this change to the 8250 was reverted. So the whole situation of the console interface is not perfect and this is the duct tape we have. It would good to have the same duct tape in all drivers or come up with a different interface to cover corner cases :) To reproduce the sysrq code path: You need to the UART as a console and send a BREAK (CTRL-A F in minicom) followed by `t' to match your example. > Thanks, > Daniel Sebastian