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;
Date:   Thu, 18 Apr 2019 07:37:30 -0500
From:   Bjorn Helgaas <helgaas@kernel.org>
To:     Kirill Smelkov <kirr@nexedi.com>
Cc:     Julia Lawall <julia.lawall@lip6.fr>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        kbuild-all@01.org, Kurt Schwemmer <kurt.schwemmer@microsemi.com>,
        Logan Gunthorpe <logang@deltatee.com>,
        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: <alpine.DEB.2.21.1904131849350.2536@hadrien>
 <20190417215420.GV126710@google.com>
 <alpine.DEB.2.21.1904180728420.8144@hadrien>
 <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

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 <lkp@intel.com>
> > > > To: kbuild@01.org
> > > > Cc: Julia Lawall <julia.lawall@lip6.fr>
> > > > Subject: [PATCH] pci/switchtec: fix stream_open.cocci warnings
> > > >
> > > > CC: kbuild-all@01.org
> > > > TO: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > > > CC: Kurt Schwemmer <kurt.schwemmer@microsemi.com>
> > > > CC: Logan Gunthorpe <logang@deltatee.com>
> > > > CC: Bjorn Helgaas <helgaas@kernel.org>
> > > > CC: linux-pci@vger.kernel.org
> > > > CC: linux-kernel@vger.kernel.org
> > > >
> > > > From: kbuild test robot <lkp@intel.com>
> > > >
> > > > 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 <lkp@intel.com>
> > >
> > > 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 <bhelgaas@google.com> [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