[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cfb39893b0e38164e8f3014089c2bb5a79d63f.camel@linux.ibm.com>
Date: Mon, 08 Apr 2024 14:40:51 +0200
From: Niklas Schnelle <schnelle@...ux.ibm.com>
To: patchwork-bot+netdevbpf@...nel.org, Gerd Bayer <gbayer@...ux.ibm.com>
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 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/
Powered by blists - more mailing lists