Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.

[Michael S. Tsirkin]

On Sat, Sep 11, 2010 at 03:41:14PM +0800, Xin, Xiaohui wrote:
> >>Playing with rlimit on data path, transparently to the application in this way
> >>looks strange to me, I suspect this has unexpected security implications.
> >>Further, applications may have other uses for locked memory
> >>besides mpassthru - you should not just take it because it's there.
> >>
> >>Can we have an ioctl that lets userspace configure how much
> >>memory to lock? This ioctl will decrement the rlimit and store
> >>the data in the device structure so we can do accounting
> >>internally. Put it back on close or on another ioctl.
> >Yes, we can decrement the rlimit in ioctl in one time to avoid
> >data path.
> >
> >>Need to be careful for when this operation gets called
> >>again with 0 or another small value while we have locked memory -
> >>maybe just fail with EBUSY?  or wait until it gets unlocked?
> >>Maybe 0 can be special-cased and deactivate zero-copy?.
> >>
> 
> How about we don't use a new ioctl, but just check the rlimit 
> in one MPASSTHRU_BINDDEV ioctl? If we find mp device
> break the rlimit, then we fail the bind ioctl, and thus can't do 
> zero copy any more.

Yes, and not just check, but decrement as well.
I think we should give userspace control over
how much memory we can lock and subtract from the rlimit.
It's OK to add this as a parameter to MPASSTHRU_BINDDEV.
Then increment the rlimit back on unbind and on close?

This opens up an interesting condition: process 1
calls bind, process 2 calls unbind or close.
This will increment rlimit for process 2.
Not sure how to fix this properly.

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/