[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e6baff2338ef4c3af9073c46b5492f271bdd9ae.camel@linux.ibm.com>
Date: Mon, 08 Apr 2024 21:05:47 +0200
From: Gerd Bayer <gbayer@...ux.ibm.com>
To: Niklas Schnelle <schnelle@...ux.ibm.com>,
"David S.Miller"
<davem@...emloft.net>
Cc: wintera@...ux.ibm.com, twinkler@...ux.ibm.com, hca@...ux.ibm.com,
pabeni@...hat.com, hch@....de, pasic@...ux.ibm.com,
wenjia@...ux.ibm.com, guwen@...ux.alibaba.com,
linux-s390@...r.kernel.org, netdev@...r.kernel.org, gor@...ux.ibm.com,
agordeev@...ux.ibm.com, borntraeger@...ux.ibm.com, svens@...ux.ibm.com
Subject: Re: [PATCH net v2] s390/ism: fix receive message buffer allocation
On Mon, 2024-04-08 at 14:40 +0200, Niklas Schnelle wrote:
> On Mon, 2024-04-08 at 11:00 +0000, patchwork-bot+netdevbpf@...nel.org
> wrote:
> > Hello:
> >
> > This patch was applied to netdev/net.git (main)
> > by David S. Miller <davem@...emloft.net>:
> >
> > On Fri, 5 Apr 2024 13:16:06 +0200 you wrote:
> > > Since [1], dma_alloc_coherent() does not accept requests for
> > > GFP_COMP
> > > anymore, even on archs that may be able to fulfill this.
> > > Functionality that
> > > relied on the receive buffer being a compound page broke at that
> > > point:
> > > The SMC-D protocol, that utilizes the ism device driver, passes
> > > receive
> > > buffers to the splice processor in a struct splice_pipe_desc with
> > > a
> > > single entry list of struct pages. As the buffer is no longer a
> > > compound
> > > page, the splice processor now rejects requests to handle more
> > > than a
> > > page worth of data.
> > >
> > > [...]
> >
> > Here is the summary with links:
> > - [net,v2] s390/ism: fix receive message buffer allocation
> > https://git.kernel.org/netdev/net/c/58effa347653
> >
> > You are awesome, thank you!
>
> This version of the patch has an outstanding issue around handling
> allocation failure see the comments on v1 here[0]. Please drop. Gerd
> will send a v3 with that issue fixed.
>
> Thanks,
> Niklas
>
> [0] https://lore.kernel.org/all/20240405143641.GA5865@lst.de/
Hi Dave,
so how do we go forward? Would you revert this v2 in the netdev tree to
have my next v3 properly reviewed?
Second best option: I can send a fixup to address the last issue from
[0], but that would still leave some pieces sent with (v1/v2) not
properly R-by'd or at least ack'd.
Thanks,
Gerd
Powered by blists - more mailing lists