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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 2515EC433E0 for ; Wed, 3 Jun 2020 08:41:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EAFAB206C3 for ; Wed, 3 Jun 2020 08:41:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591173671; bh=RgZUtVxKnCtVw5YOAOf1+p20ZhLDrmdlW/NiubsGS4Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=tfnxGso1uOR2mATo1SnB17bRimggnr13MeqaXM/MaMqa4LPxH4tVx2v90fRGR6VPR IWBNnNtQ3oMv0Y5xJC1tQ+5x3iufVbxZ6dHFp9q++DxexjUibFYl6HzWb52/J+jbcm sWjG10Vy133xbi8QlN/k0odDP2RKKPCi0Q3Cfwcc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725954AbgFCIlF (ORCPT ); Wed, 3 Jun 2020 04:41:05 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:38363 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725355AbgFCIlF (ORCPT ); Wed, 3 Jun 2020 04:41:05 -0400 Received: by mail-lf1-f66.google.com with SMTP id 202so789914lfe.5; Wed, 03 Jun 2020 01:41:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Y3+NZ002fR5cwFINbc/o3dpUhIJL9xPazQ2yRYvAcPI=; b=hCKGaV93HEyfanQW2nAnEjNxbwDsgSYdkTODol6+PNwAyo+kuNPDUKiMhE80mpiu9o zubbOA8qpI5QX647m0BK2AAWL2lLBQm7rYvJmni8wTFJcbW/j6/1sAT4blQrmczyWa21 PkFK/71ER6yi7IGo/HTGm+WmsJ9hVxb2jo4JUWEfKWbEmTqsb1ydZB/F5t96HyhSFqER QoFFj2ZwrQbFgNU3p4BAFtONiYu36xAAAerV4jGEKj6ZMWvp209JFnOkw368Of8RLXku WIXRMe7s/7BCS8M+TwOQUYOerldFaRTirFNp8LhCOdFqd2+oO6al5lxUaKw6hRKBvqH6 4jhw== X-Gm-Message-State: AOAM532MKL7xWBuCjQZLzHVIGx2++6Fs35TJgQGSNcVTihnQuXFP0jbB aJ2N+y6DsKs3nMgmICIQOfI= X-Google-Smtp-Source: ABdhPJzoycNz0b42LjEGhqRPhb5Q3Xac6OiJOYqR8aXp9vwMshAsFIyQ9VYMEqnoKBUzsU0ot5PTsA== X-Received: by 2002:a19:434e:: with SMTP id m14mr1905473lfj.40.1591173662210; Wed, 03 Jun 2020 01:41:02 -0700 (PDT) Received: from xi.terra (c-beaee455.07-184-6d6c6d4.bbcust.telenor.se. [85.228.174.190]) by smtp.gmail.com with ESMTPSA id w20sm298508lji.7.2020.06.03.01.41.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 01:41:01 -0700 (PDT) Received: from johan by xi.terra with local (Exim 4.93.0.4) (envelope-from ) id 1jgOx9-0002Ai-OO; Wed, 03 Jun 2020 10:40:51 +0200 Date: Wed, 3 Jun 2020 10:40:51 +0200 From: Johan Hovold To: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Andy Shevchenko , Johan Hovold , Greg Kroah-Hartman , Jiri Slaby , Andy Shevchenko , "open list:SERIAL DRIVERS" , Linux Kernel Mailing List , stable Subject: Re: [PATCH 2/4] serial: core: fix broken sysrq port unlock Message-ID: <20200603084051.GJ19480@localhost> References: <20200602140058.3656-1-johan@kernel.org> <20200602140058.3656-3-johan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-serial-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org On Tue, Jun 02, 2020 at 04:34:16PM +0100, Dmitry Safonov wrote: > On 6/2/20 3:48 PM, Andy Shevchenko wrote: > > On Tue, Jun 2, 2020 at 5:03 PM Johan Hovold wrote: > >> > >> Commit d6e1935819db ("serial: core: Allow processing sysrq at port > >> unlock time") worked around a circular locking dependency by adding > >> helpers used to defer sysrq processing to when the port lock was > >> released. > >> > >> A later commit unfortunately converted these inline helpers to exported > >> functions despite the fact that the unlock helper was restoring irq > >> flags, something which needs to be done in the same function that saved > >> them (e.g. on SPARC). > > > > I'm not familiar with sparc, can you elaborate a bit what is ABI / > > architecture lock implementation background? > > I remember that was a limitation a while ago to save/restore flags from > the same function. Though, I vaguely remember the reason. > I don't see this limitation in Documentation/* It's described in both LDD3 and LKD, which is possibly where I first picked it up too (admittedly a long time ago). > Google suggests that it's related to storage location: > https://stackoverflow.com/a/34279032 No, that was never the issue. SPARC includes the current register window in those flags, which at least had to be restored in the same stack frame. > Looking into arch/sparc I also can't catch if it's still a limitation. Yeah, looking closer at the current implementation it seems this is no longer an issue on SPARC. > Also, looking around, xa_unlock_irqrestore() is called not from the same > function. Maybe this issue is in history? xa_unlock_irqrestore() is just a macro for spin_unlock_irqsave() it seems, so not a counter example. > Also, some comments would be nice near functions in the header. Agreed. Let me respin this and either merge this with the next patch or at least amend the commit message. Johan