Re: [Patch v3 2/6] cifs: Allocate validate negotiation request through kmalloc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/18/2018 1:11 PM, Long Li wrote:
Subject: Re: [Patch v3 2/6] cifs: Allocate validate negotiation request through
kmalloc

On 4/18/2018 9:08 AM, David Laight wrote:
From: Tom Talpey
Sent: 18 April 2018 12:32
...
On 4/17/2018 8:33 PM, Long Li wrote:
From: Long Li <longli@xxxxxxxxxxxxx>

The data buffer allocated on the stack can't be DMA'ed, and hence
can't send through RDMA via SMB Direct.

This comment is confusing. Any registered memory can be DMA'd, need
to state the reason for the choice here more clearly.

The stack could be allocated with vmalloc().
In which case the pages might not be physically contiguous and there
is no
(sensible) call to get the physical address required by the dma
controller (or other bus master).

Memory registration does not requires pages to be physically contiguous.
RDMA Regions can and do support very large physical page scatter/gather,
and the adapter DMA's them readily. Is this the only reason?

ib_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect address can't be detected by ib_dma_mapping_error. Sending data from this address to hardware will not fail, but the remote peer will get junk data.

I think it makes sense as stack is dynamic and can shrink as I/O proceeds, so the buffer is gone. Other kernel code use only data on the heap for DMA, e.g. BLK/SCSI layer never use buffer on the stack to send data.

I totally agree that registering the stack is a bad idea. I mainly
suggest that you capture these fundamental ib_dma* reasons in the
commit. There's no other practical reason why the original approach
would not work.

Tom.



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]