In D3989#151738, @jhibbits wrote:

Did some light testing, but not sure if I triggered anything.

Add comment noting size limit of each message

Limit number of messages to 42 to prevent exhaustion/short allocation on 32-bit systems

In D3989#135429, @jhibbits wrote:

I think qemu can boot powerpc64 (see https://wiki.freebsd.org/QemuRecipes ). What kinds of testing should be done? I have a Book-E board I could boot test with, and do basic SATA I/O, would that be enough? I also have some PowerMac hardware. Would need a week or two before I can test with that though.

Garrett, were you planning to add the limit on nmsgs and commit this? If not, I can do it.

This one's been sitting for a while. Anything I can do to test this out on my own? qemu maybe?

I think it's better to revert r292255 than to add this. Like Hans mentioned it adds complexity, and the fact that it forces entire buffers to be bounced seems wrong to me. The added memcpy probably isn't that big of a deal, since performance goes out the window if you're bouncing anyway. But the memory those bounce pages come from is likely to be somewhat precious. This could make large transfers use a lot more of that, which makes me nervous.

In D5155#109705, @kib wrote:

Copy/paste from my mail to the OP:

> > $ svn diff iic.c 
> > Index: iic.c
> > ===================================================================
> > --- iic.c       (revision 295081)
> > +++ iic.c       (working copy)
> > @@ -303,6 +303,10 @@
> >         buf = malloc(sizeof(*d->msgs) * d->nmsgs, M_IIC, M_WAITOK);
> >  
> >         error = copyin(d->msgs, buf, sizeof(*d->msgs) * d->nmsgs);
> > +       if (error != 0) {
> > +               free(buf, M_IIC);
> > +               return (error);
> > +       }
> >  
> >         /* Alloc kernel buffers for userland data, copyin write data */
> >         usrbufs = malloc(sizeof(void *) * d->nmsgs, M_IIC, M_WAITOK | M_ZERO);
> > 
> This just continues the original bug.
> 
> If you look at the line above the changed line, you would see the
> multiplication with the user-supplied value, which could e.g. overflow
> and results in the short buffer being malloced. Then copying trashes the
> kernel heap.
> 
> That said, even if overflow does not occur, the user-controlled malloc(9)
> either causes DoS by over-allocation of the kernel memory, or by causing
> panic by exhausting the kmem address space on 32bit arches.

I might've missed something, but it looks like we don't actually use the contents of buf for anything if error is set. We might store some of that bogus data in usrbufs at line 311, but we'll avoid using it.

In D3986#83956, @adrian wrote:

Just build some software or something that'll churn the VM and do disk IO. :)

In D3986#83554, @adrian wrote:

Can you test this out via a qemu-system-mips (from qemu-devel) package?

https://github.com/freebsd/freebsd-wifi-build/wiki/MipsQemuEmulatorImages

Remove unclear comment on PHYS_TO_VM_PAGE().
Noted by: avg

Remove unclear comments on PHYS_TO_VM_PAGE().
Noted by: avg

In D888#82509, @royger wrote:

In D888#80533, @jah wrote:

Thinking about this some more, I wonder if it would be better to have add_bounce_page() do coalescing in much the same way as _bus_dmamap_addseg() already does. You'd still have the 2-page array in struct bounce_page, but add_bounce_page() would go back to just taking one address. It would look at the tail of map->bpages (if that exists). If that last bounce page can still fit the new segment with the right alignment, then its datacount will be increased and datapage[1] will be set if necessary. Otherwise, a new bounce page will be pulled from the bz queue.

With that scheme, you wouldn't need the dedicated load_ma or count_ma functions; existing load_phys and load_buffer would "do the right thing". We'd also make more efficient use of bounce pages when magsegz is much smaller than a page. Right now, if maxsegsz is, say, 512 and those 512-byte segments get bounced, each one will waste a whole bounce page. Of course, I doubt that's a common use case.

A downside would be that you'd probably need to duplicate some of the coalescing logic in count_phys and count_pages to avoid over-requesting bounce pages.

Just a thought I had; there are probably holes in that scheme that I haven't thought of.

The solution you are proposing seems fine, but I don't think I will have time to look into it until a couple of weeks, do you mind if I commit this now so we can get unmapped IO for blkfront?

Narrow the scope of the temporary bounce buffer mappings

Fixed confusion of client page addr vs. bounce page addr, trimmed trailing whitespace

Comment on unaligned pages, move page array assertion back to dma_dcache_sync()

Re-adding comment, moving POSTWRITE check to beginning of _bus_dmamap_sync() as is done for armv5 and mips

Thinking about this some more, I wonder if it would be better to have add_bounce_page() do coalescing in much the same way as _bus_dmamap_addseg() already does. You'd still have the 2-page array in struct bounce_page, but add_bounce_page() would go back to just taking one address. It would look at the tail of map->bpages (if that exists). If that last bounce page can still fit the new segment with the right alignment, then its datacount will be increased and datapage[1] will be set if necessary. Otherwise, a new bounce page will be pulled from the bz queue.

Port unmapped bounce buffer alignment fix from x86

Port unmapped bounce buffer alignment fix from x86

Port unmapped bounce buffer alignment fix from x86

I like the memdesc idea, or at least something like it. I also agree that it's too tall an order to do everywhere right now, especially if Xen needs this right away.

Adding assert on non-contiguous pages

• Simplify loop in sync_sl

• Fix logic errors around call to sync_buf and bounce buffer cache maintenance
• Remove sync_buf call for unmapped case: cache operations in pmap_quick_enter_page()->pmap_kenter()->pmap_fix_cache() make sync_buf irrelevant

Style fixes. Initialize sl outside the mapping loop, since it is incremented inside the loop.

Making sl coalescing logic a little clearer, preventing coalescing in the case where the sl has a non-contiguous KVA but the physical pages happen to be adjacent.

Fix problems noted by wblock

Fix lint warnings

Move each sentence to its own line

Fixing the bugs kib pointed out

I think it is possible for calls into the smbus interface to get interleaved right now. If they come from smb(4) ioctls, they could get interleaved because that driver does not hold its own sx like iic(4) does (and did even before r281828). But those calls could also be made by another driver directly calling something like smbus_bwrite(), without going through smb(4).

Addressing wblock's feedback

Closed by commit rS281828 (authored by @jah).

@imp, @loos: can you guys look over this again as soon as you get a chance and see if you find it acceptable from an iic perspective?

addressing jhb's feedback:

• looping on short writes
• always using M_WAITOK
• style(9) fixes

imp, loos: can you guys look over this again when you have time?
I also need some clarification on Warner's comment about the lock.

Change chunk size back to 128 bytes. That should still be OK to keep on the kernel stack. 32 might be too stingy for faster iic controllers.

--Shrink chunk size to 32 bytes (same as smbus blocksize), move buffer to stack
--Respect O_NONBLOCK for mallocs
--Document IICBUS_CALLBACK locking assumptions in iiconf.c and iicbus interface

Remove stale comment