On 30/10/18 22:27, Spencer Olson wrote:
On Tue, Oct 30, 2018 at 6:21 AM Ian Abbott <abbotti@xxxxxxxxx> wrote:
On 25/10/18 02:36, Spencer E. Olson wrote:
Changes do_insn*_ioctl functions to allow for data lengths for each
comedi_insn of up to 2^16. This patch also changes these functions to only
allocate as much memory as is necessary for each comedi_insn, rather than
allocating a fixed-sized scratch space.
In testing some user-space code for the new INSN_DEVICE_CONFIG_GET_ROUTES
facility with some newer hardware, I discovered that do_insn_ioctl and
do_insnlist_ioctl limited the amount of data that can be passed into the
kernel for insn's to a length of 256. For some newer hardware, the number
of routes can be greater than 1000. Working around the old limits (256)
would complicate the user-space/kernel interaction.
The new upper limit is reasonable with current memory available and does
not otherwise impact the memory footprint for any current or otherwise
typical configuration.
[snip]
There are still some broken drivers that do not check insn->n and assume
the data has some minimum length, so we will need to make the data array
some minimum length (say 16 * sizeof(unsigned int)) until those drivers
have been fixed.
I don't think that would be much of a problem, since 16*sizeof(uint)
is pretty negligible. How certain are you that we would not have to
make that higher, as the previous default was a length of
256*sizeof(uint)? It'll take me a day or two to resubmit (have other
things pressing on my time).
ai_config_master_clock() in cb_pcidas64.c is the worst offender of using
unchecked data[] length, and that only uses a data[] length of 5. I've
checked all the insn_read, insn_write, and insn_config handlers now and
found a couple more drivers with the problem of potentially using data[]
members beyond insn->n-1. These are "s626.c" and "addi_apci_3501.c".
(The previously found files with the problem are "cb_pcidas64.c",
"cb_pcidda.c", "ni_labpc_common.c", "ni_mio_common.c", and "s526.c".
I've submitted patches for some of those, and will submit patches for
the others sometime in the next few days.)
--
-=( Ian Abbott <abbotti@xxxxxxxxx> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address: )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
