ok yasuoka
On Fri, 06 Jan 2023 15:14:05 +0900 (JST)
Masato Asou wrote:
> I have updated my patch.
>
> From: YASUOKA Masahiko
> Date: Tue, 27 Dec 2022 11:58:34 +0900 (JST)
>
>> After diff, it doesn't use PAGE_SIZE any more. And VMware software
>> limit seems 1MB and changable by its
I have updated my patch.
From: YASUOKA Masahiko
Date: Tue, 27 Dec 2022 11:58:34 +0900 (JST)
> After diff, it doesn't use PAGE_SIZE any more. And VMware software
> limit seems 1MB and changable by its configuration(*1). So we can't
> say PVBUS_KVOP_MAXSIZE is enough.
>
> + * - Known pv
Hi,
Sorry for separating emails.
On Tue, 27 Dec 2022 11:58:34 +0900 (JST)
YASUOKA Masahiko wrote:
>> @@ -1115,12 +1116,19 @@ xs_kvop(void *xsc, int op, char *key, char *value,
>> size_t valuelen)
>> }
>> /* FALLTHROUGH */
>> case XS_LIST:
>> -for (i =
Hi,
On Mon, 26 Dec 2022 13:37:45 +0900 (JST)
Masato Asou wrote:
> My new patch is not returned value length from ioctl() system call
> when read the KEY's value.
>
> The hostctl command allocate 4k bytes memory for store the value. Then
> read the value by ioctl() system call. If ioctl()
I was rewrited the patch for hostctl command and sys/dev/pvbus.
From: "Theo de Raadt"
Date: Tue, 11 Oct 2022 19:09:42 -0600
> An example of this mechanism is SIOCGIFCONF. The ioctl passes a pointer
> to a struct containing length & pointer to data. See net/if.c ifconf()
> There are other
delete mbuhl from Cc:.
From: YASUOKA Masahiko
Date: Sat, 19 Nov 2022 16:37:47 +0900 (JST)
> On Sat, 19 Nov 2022 14:41:18 +0900 (JST)
> YASUOKA Masahiko wrote:
>> On Wed, 12 Oct 2022 07:58:20 +0900 (JST)
>> YASUOKA Masahiko wrote:
>>> On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
>>> Masato Asou
On Sat, 19 Nov 2022 14:41:18 +0900 (JST)
YASUOKA Masahiko wrote:
> On Wed, 12 Oct 2022 07:58:20 +0900 (JST)
> YASUOKA Masahiko wrote:
>> On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
>> Masato Asou wrote:
>>> From: "Theo de Raadt"
>>> Date: Tue, 04 Oct 2022 21:58:13 -0600
Userland may not ask
On Wed, 12 Oct 2022 07:58:20 +0900 (JST)
YASUOKA Masahiko wrote:
> On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
> Masato Asou wrote:
>> From: "Theo de Raadt"
>> Date: Tue, 04 Oct 2022 21:58:13 -0600
>>> Userland may not ask the kernel to allocate such a huge object. The
>>> kernel address space is
YASUOKA Masahiko wrote:
> Currently the value on VMware may be truncated silently. It's simply
> broken. I think we should fix it by having a way to know if the value
> is reached the limit.
>
> Also I think we should be able to pass larger size of data. Since at
> least on VMware, people is
Hello,
On Wed, 05 Oct 2022 13:37:35 +0900 (JST)
Masato Asou wrote:
> From: "Theo de Raadt"
> Date: Tue, 04 Oct 2022 21:58:13 -0600
>> 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.
>>
>>
Masato Asou wrote:
> As you pointed out, it is not a good idea to allocate large spaces
> in kernel.
>
> Would it be better to keep the current fixed length?
>
> Prepare a variable like kern.maxpvbus and default it to
> 4096. Futhermore, how about free() after copyout() to user space?
Sorry
From: "Theo de Raadt"
Date: Tue, 04 Oct 2022 21:58:13 -0600
> 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);
> +
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;
+
Hi,
The current VALUE length limit for the hostctl command for VMware is
fixed 4096 bytes. I want to pass a longer VALUE. I made a patch to
change it to variable length.
commane, ok?
Index: share/man/man4/pvbus.4
===
RCS file:
14 matches
Mail list logo
