Hi Bart,

On 29/06/22 11:50, Bart Van Assche wrote:

On 6/28/22 16:09, Michael Schmitz wrote:

quoted

On 29/06/22 09:50, Arnd Bergmann wrote:

quoted

On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz 
[off-list ref] wrote:

quoted

On 28/06/22 19:03, Geert Uytterhoeven wrote:

quoted

quoted

The driver allocates bounce buffers using kmalloc if it hits an
unaligned data buffer - can such buffers still even happen these 
days?

No idea.

Hmmm - I think I'll stick a WARN_ONCE() in there so we know whether 
this
code path is still being used.

kmalloc() guarantees alignment to the next power-of-two size or
KMALLOC_MIN_ALIGN, whichever is bigger. On m68k this means it
is cacheline aligned.

And all SCSI buffers are allocated using kmalloc? No way at all for 
user space to pass unaligned data?

(SCSI is a weird beast - I have used a SCSI DAT tape driver many many 
years ago, which broke all sorts of assumptions about transfer block 
sizes ... but that might actually have been in the v0.99 days, many 
rewrites of SCSI midlevel ago).

Just being cautious, as getting any of this tested will be a stretch.

An example of a user space application that passes an SG I/O data 
buffer to the kernel that is aligned to a four byte boundary but not 
to an eight byte boundary if the -s (scattered) command line option is 
used: 
https://github.com/osandov/blktests/blob/master/src/discontiguous-io.cpp

Thanks - four byte alignment actually wouldn't be an issue for me. It's 
two byte or smaller that would trip up the SCSI DMA.

While I'm sure such an even more pathological test case could be 
written, I was rather worried about st.c and sr.c input ...

Cheers,

     Michael

Bart.