From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8218C46475 for ; Thu, 25 Oct 2018 08:11:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6E9C92083E for ; Thu, 25 Oct 2018 08:11:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E9C92083E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=de.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727308AbeJYQm5 (ORCPT ); Thu, 25 Oct 2018 12:42:57 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58938 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727230AbeJYQm5 (ORCPT ); Thu, 25 Oct 2018 12:42:57 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9P84aL8093431 for ; Thu, 25 Oct 2018 04:11:17 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0a-001b2d01.pphosted.com with ESMTP id 2nb965tpxt-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 25 Oct 2018 04:11:16 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 25 Oct 2018 09:11:14 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp01.uk.ibm.com (192.168.101.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 25 Oct 2018 09:11:10 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w9P8B9683932496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Oct 2018 08:11:09 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A29614C040; Thu, 25 Oct 2018 08:11:09 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 69DFD4C044; Thu, 25 Oct 2018 08:11:09 +0000 (GMT) Received: from osiris (unknown [9.152.212.171]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 25 Oct 2018 08:11:09 +0000 (GMT) Date: Thu, 25 Oct 2018 10:11:08 +0200 From: Heiko Carstens To: Sergey Senozhatsky Cc: Martin Schwidefsky , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky , Peter Oberparleiter Subject: Re: [PATCH] s390/fault: use wake_up_klogd() in bust_spinlocks() References: <20181024043048.21248-1-sergey.senozhatsky@gmail.com> <20181024043425.GA8862@jagdpanzerIV> <20181025062800.GB4037@osiris> <20181025070543.GB20702@jagdpanzerIV> MIME-Version: 1.0 In-Reply-To: <20181025070543.GB20702@jagdpanzerIV> X-TM-AS-GCONF: 00 x-cbid: 18102508-4275-0000-0000-000002D36AE6 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18102508-4276-0000-0000-000037DF7793 Message-Id: <20181025081108.GB26561@osiris> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-25_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=854 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810250075 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 25, 2018 at 04:05:43PM +0900, Sergey Senozhatsky wrote: > On (10/25/18 08:28), Heiko Carstens wrote: > > > > With your patch this looks nearly like the common code variant. I did > > some code archaeology and this function is unchanged since ~17 years. > > When it was introduced it was close to identical to the x86 variant. > > All other architectures use the common code variant in the > > meantime. So if we change this I'd prefer that we switch s390 to the > > common code variant as well. > > > > Right now I can't see a reason for not doing that, but I might be > > wrong of course. So, could you please provide a new version which just > > removes this variant and makes s390 use the generic one too. > > > > We'll see if there is any fallout... > > Heiko, if this one works for you then I'll submit a format patch. > Let me know. Thanks. > > ==== > > From: Sergey Senozhatsky > Subject: [PATCH] arch/s390: use common bust_spinlocks() > > s390 is the only architecture that is using own bust_spinlocks() > variant, while other arch-s seem to be OK with the common > implementation. > > Heiko Carstens [1] said he would prefer s390 to use the common > bust_spinlocks() as well: > I did some code archaeology and this function is unchanged since ~17 > years. When it was introduced it was close to identical to the x86 > variant. All other architectures use the common code variant in the > meantime. So if we change this I'd prefer that we switch s390 to the > common code variant as well. Right now I can't see a reason for not > doing that > > This patch removes s390 bust_spinlocks() and drops the weak attribute > from the common bust_spinlocks() version. > > [1] lkml.kernel.org/r/20181025062800.GB4037@osiris > Signed-off-by: Sergey Senozhatsky > --- > arch/s390/mm/fault.c | 24 ------------------------ > lib/bust_spinlocks.c | 6 +++--- > 2 files changed, 3 insertions(+), 27 deletions(-) I gave this some testing and forced panic/die in interrupt as well as process context with different consoles as well as single and multi cpu systems. Everything still seems to work. So I'm applying this to our internal queue first. It will hit upstream latest in the next merge window if there aren't any issues found. Thanks!