Looking at these pieces:
+ sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
...
+vm_rpc_buf_realloc(struct vmt_softc *sc, size_t len)
+{
+ free(sc->sc_rpc_buf, M_DEVBUF, sc->sc_rpc_buflen);
+
+ sc->sc_rpc_buflen = len / VMT_RPC_BUFLEN * VMT_RPC_BUFLEN;
+ sc->sc_rpc_buflen += ((len % VMT_RPC_BUFLEN) <= 0) ? 0 : VMT_RPC_BUFLEN;
+ sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
...
+ else if (srclen > SIZE_T_MAX)
return (ENAMETOOLONG);
*dstp = dst = malloc(srclen + 1, M_TEMP|M_ZERO, M_WAITOK);
Userland may not ask the kernel to allocate such a huge object. The
kernel address space is quite small. First off, huge allocations will
fail.
But it is worse -- the small kernel address space is shared for many
purposes, so large allocations will harm the other subsystems.
As written, this diff is too dangerous. Arbitrary allocation inside
the kernel is not reasonable. object sizes requested by userland must
be small, or the operations must be cut up, which does create impact
on atomicity or other things.
