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=-10.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT 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 0D3ADC10F0E for ; Thu, 18 Apr 2019 12:37:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C93F42183F for ; Thu, 18 Apr 2019 12:37:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555591054; bh=bSY2ERrnn9DQ42Z9xlSzuf+GCUi6Ii7f7cn+Hz4/NdA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=1+2tNY7eqmkcCuf1LsfbjlYOTOEFPPbj/fPyqelYAo0/mOOKdEOIl8yK1UUizaOQ6 5bqLsykXLDmjoKIcSdkYS9sTRvFONBB57v/mGXl2LjgDIgDUrC7tzx+Dq4BDeK4s7a vAGRBVzZVvTr8BTGld/jU8rd+6FB3Lbk6D7CWRvs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388572AbfDRMhd (ORCPT ); Thu, 18 Apr 2019 08:37:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:37548 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733192AbfDRMhd (ORCPT ); Thu, 18 Apr 2019 08:37:33 -0400 Received: from localhost (173-25-63-173.client.mchsi.com [173.25.63.173]) (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 8CF7621479; Thu, 18 Apr 2019 12:37:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555591051; bh=bSY2ERrnn9DQ42Z9xlSzuf+GCUi6Ii7f7cn+Hz4/NdA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i6aOz9hN1KocvJCVhNl5RA12uw6cHpUi/iTRE7H/AWFgimP9HH9/MwAhKzrKsenyd FPn95oETCjCZSMVPgchYn2JGXsnoN26rVsjyvYD9OAabSmdKu1CBLPs/Xje1fso2kY blJ7c4BI38Vd7ltZU0inEfOzExxHqqXlWVDSBcno= Date: Thu, 18 Apr 2019 07:37:30 -0500 From: Bjorn Helgaas To: Kirill Smelkov Cc: Julia Lawall , Sebastian Andrzej Siewior , kbuild-all@01.org, Kurt Schwemmer , Logan Gunthorpe , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] pci/switchtec: fix stream_open.cocci warnings (fwd) Message-ID: <20190418123730.GX126710@google.com> References: <20190417215420.GV126710@google.com> <20190418103755.GA14294@deco.navytux.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190418103755.GA14294@deco.navytux.spb.ru> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 18, 2019 at 10:38:02AM +0000, Kirill Smelkov wrote: > On Thu, Apr 18, 2019 at 07:31:02AM +0200, Julia Lawall wrote: > > On Wed, 17 Apr 2019, Bjorn Helgaas wrote: > > > On Sat, Apr 13, 2019 at 06:50:57PM +0200, Julia Lawall wrote: > > > > Hello, > > > > > > > > Kirill will explain about this issue. > > > > > > > > julia > > > > > > > > ---------- Forwarded message ---------- > > > > Date: Sat, 13 Apr 2019 11:22:51 +0800 > > > > From: kbuild test robot > > > > To: kbuild@01.org > > > > Cc: Julia Lawall > > > > Subject: [PATCH] pci/switchtec: fix stream_open.cocci warnings > > > > > > > > CC: kbuild-all@01.org > > > > TO: Sebastian Andrzej Siewior > > > > CC: Kurt Schwemmer > > > > CC: Logan Gunthorpe > > > > CC: Bjorn Helgaas > > > > CC: linux-pci@vger.kernel.org > > > > CC: linux-kernel@vger.kernel.org > > > > > > > > From: kbuild test robot > > > > > > > > drivers/pci/switch/switchtec.c:395:1-17: ERROR: switchtec_fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix. > > > > > > > > Generated by: scripts/coccinelle/api/stream_open.cocci > > > > > > > > Fixes: 8a29a3bae2a2 ("pci/switchtec: Don't use completion's wait queue") > > > > Signed-off-by: kbuild test robot > > > > > > Based on Kirill's subsequent email saying this is already queued to > > > the merge window, I assume I need to do nothing here. > > > > > > I think a signed-off-by from a robot, i.e., not from a real person, is > > > meaningless, and I don't think I would personally accept it. It's > > > certainly OK to indicate that a patch was auto-generated, but I think > > > a real person still needs to take responsibility for it. > > > > > > Documentation/process/submitting-patches.rst says it must contain a > > > real name (no pseudonyms or anonymous contributions), and I don't > > > think a robot fits in the spirit of that. > > > > > > I see that > > > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/?id=8a29a3bae2a2 > > > (mentioned below) does have a good signed-off-by from Sebastian, but > > > that's not *this* patch, so I don't know what's what. > > > > Normally, for these robot generated patches, when I approve them, I put my > > own sign off, but under the robot one, since the robot has put a From > > line. In this case, I handed the problem off to Kirill, so I didn't do > > that. I agree that it would be good for Kirill to sign off on it. > > Just for the reference: I have put my signature on the mass converstion > patch as well as ack's that were received: > > https://lab.nexedi.com/kirr/linux/commit/edaeb4101860 Looks good, thanks. Feel free to add my Acked-by: Bjorn Helgaas [drivers/pci/switch/switchtec] to the https://lab.nexedi.com/kirr/linux/commit/edaeb4101860 patch. It looks like maybe the commit log could use s/and the reset were/and the rest were/ It also mentions "the previous patch" a couple times, which may lose some of its meaning depending on how things get merged into git. If that previous patch has already been merged, a SHA1 reference would be more specific. I would personally split that into two patches: one to avoid the potential deadlocks and a second to do the "safe to change to stream_open" changes. It seems like the first is more serious and urgent while the second is more of a cleanup. Then you could streamline the commit logs by including a single diagnostic and omitting the entire list of files. But that's all bike-shedding and I'm totally fine with this as-is. Bjorn