Ensure that the size filled in by userland in the datagram header
matches the size of the buffer passed down in the IOCTL. Note that we
account for the size of the header itself in the check.
Acked-by: Jorgen Hansen
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
Reported-by: David Ramos
This version addresses Sergei's comments.
o Fixed description and added Reported-by
o Removed NULL check for kfree()
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
We should check if the map of the table actually succeeds, and also free
resources accordingly.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong
Acked-by: Bhavesh Davda
Signed-off-by: Andy King
Reported-by: Tetsuo Handa
---
drivers/net/vmxnet3/vmxnet3_drv.c | 15 ---
drivers
We should check if the map of the table actually succeeds, and also free
resources accordingly. This fixes the kernel panic reported by Tetsuo
Handa.
Version bumped to 1.2.1.0
Acked-by: Shelley Gong
Acked-by: Bhavesh Davda
Signed-off-by: Andy King
---
drivers/net/vmxnet3/vmxnet3_drv.c | 14
rsion bump to 1.0.1.0-k
Passes checkpatch this time, I swear...
Cc: sta...@vger.kernel.org
Acked-by: Dmitry Torokhov
Signed-off-by: Andy King
---
include/net/af_vsock.h |6 -
net/vmw_vsock/af_vsock.c | 47 +
2 files changed, 27 insertions(+
rom unloading if
> there are open sockets, which results in a panic. Fix that by allowing
> the transport to be the owner, which will refcount it properly.
>
> Includes version bump to 1.0.1.0-k
>
> Cc: sta...@vger.kernel.org
> Acked-by: Dmitry Torokhov
> Signed-off-by: An
rsion bump to 1.0.1.0-k
Cc: sta...@vger.kernel.org
Acked-by: Dmitry Torokhov
Signed-off-by: Andy King
---
include/net/af_vsock.h |6 +-
net/vmw_vsock/af_vsock.c | 46 +-
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/includ
> free_irq() expects the same device identity that was passed to
> corresponding request_irq(), otherwise the IRQ is not freed.
>
> Signed-off-by: Wei Yongjun
Acked-by: Andy King
Thanks for fixing this!
- Andy
--
To unsubscribe from this list: send the line "unsubscribe lin
27;ve replaced kmalloc() and friends.
Also fix two small bugs:
1) use after free of rq->buf_info in vmxnet3_rq_destroy()
2) a cpu_to_le32() that should have been a cpu_to_le64()
Acked-by: George Zhang
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/net/vmxnet3/vmxnet3_drv.
This patchset adds support for virtual IOMMU to the VMCI module. We switch to
DMA consistent mappings for queuepair and doorbell pages that are passed to the
device, which allows the module to work in the presence of vIOMMU/VT-d.
Andy King (2):
VMCI: Remove non-blocking/pinned queuepair
We added this for a special case that doesn't exist on Linux. Remove
the non-blocking/pinned queuepair code and simplify the driver in
preparation for adding virtual IOMMU support.
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_queue_pair.c |
cal
for an entire queuepair (especially since we allow up to 128 MiB!).
Also made the split between guest and host in the kernelIf struct much
clearer. Now it's obvious which fields are which.
Acked-by: George Zhang
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/misc/vmw_vmc
upport for virtual IOMMU to the VMCI module. We switch
> to
> DMA consistent mappings for queuepair and doorbell pages that are passed to
> the
> device, which allows the module to work in the presence of vIOMMU/VT-d.
>
> Andy King (2):
> VMCI: Remove non-blocking/pinned queu
Adding Greg, since this will apply to a similar patchset I sent out
for VMCI.
- Original Message -
> From: Andy King
> Date: Tue, 20 Aug 2013 10:33:32 -0700
>
> > We can't just do virt_to_phys() on memory that we pass to the device and
> > expect it to wor
We added this for a special case that doesn't exist on Linux. Remove
the non-blocking/pinned queuepair code and simplify the driver in
preparation for adding virtual IOMMU support.
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_queue_pair.c |
ed or we don't control the allocation (netdev).
Also fix two small bugs:
1) use after free of rq->buf_info in vmxnet3_rq_destroy()
2) a cpu_to_le32() that should have been a cpu_to_le64()
Acked-by: George Zhang
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/net/vmxnet3/
This patchset adds support for virtual IOMMU to the VMCI module. We switch to
DMA consistent mappings for queuepair and doorbell pages that are passed to the
device, which allows the module to work in the presence of vIOMMU/VT-d.
Andy King (2):
VMCI: Remove non-blocking/pinned queuepair
ds are which.
Acked-by: George Zhang
Acked-by: Aditya Sarwade
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_driver.c |2 +-
drivers/misc/vmw_vmci/vmci_driver.h |7 ++
drivers/misc/vmw_vmci/vmci_guest.c | 21 +++-
drivers/misc/vmw_vmci/vmci
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_datagram.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_datagram.c
b/drivers/misc/vmw_vmci/vmci_datagram.c
index ed5c433..f3cdd90 100644
--- a/drivers/misc/vmw_vmci/vmci_datagram.c
: Dmitry Torokhov
Signed-off-by: Andy King
---
include/linux/vm_sockets.h | 23 +++
include/uapi/linux/vm_sockets.h | 23 ---
2 files changed, 31 insertions(+), 15 deletions(-)
create mode 100644 include/linux/vm_sockets.h
diff --git a/include/linux
Hi Sasha,
> > + * Specifically, we initialize the vsock_bind_table array to a size of
> > + * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through
...
> Why isn't it using the kernel's linux/hashtable.h?
Gah, that's a leftover from when it was platform independent :/ I have a
patch lying arou
Hi Gerd,
> > + written = transport->stream_enqueue(
> > + vsk, msg->msg_iov,
> > + len - total_written);
>
> Hmm, shouldn't we pass total_written to stream_enqueue here?
>
> In case a blocking send(big-buffer) call gets splitted into
> > + if (protocol)
> > + return -EPROTONOSUPPORT;
> > +
>
> IMO protocol == PF_VSOCK should not get rejected here.
Good catch, I've sent out a patch for this.
Thanks!
- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
Remove hypervisor-only socket option.
Reported-by: Gerd Hoffmann
Acked-by: Dmitry Torokhov
Signed-off-by: Andy King
---
include/uapi/linux/vm_sockets.h |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux
Allow our own family as the protocol value for socket creation.
Reported-by: Gerd Hoffmann
Signed-off-by: Andy King
---
net/vmw_vsock/af_vsock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index c1b9e55..ca511c4
From: Dmitry Torokhov
This is the default behavior for a looong time.
Acked-by: Andy King
Signed-off-by: Dmitry Torokhov
---
net/vmw_vsock/af_vsock.c |2 --
net/vmw_vsock/vmci_transport.c |2 --
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/vmw_vsock
From: Dmitry Torokhov
There isn't really a need to have a separate file for it.
Acked-by: Andy King
Signed-off-by: Dmitry Torokhov
---
net/vmw_vsock/af_vsock.c |3 +--
net/vmw_vsock/vsock_version.h | 22 --
2 files changed, 1 insertions(+), 24 dele
Minor vSockets fixes, two of which were reported on LKML.
Andy King (2):
VSOCK: Remove hypervisor-only socket option
VSOCK: Don't reject PF_VSOCK protocol
Dmitry Torokhov (2):
VSOCK: get rid of EXPORT_SYMTAB
VSOCK: get rid of vsock_version.h
include/uapi/linux/vm_sockets.h |
> I've seen you have a notify_ops in the vmci bits. Do you have different
> notify ops depending on socket type or something? Does it make sense to
> move the notify ops ptr into "struct vsock_sock" maybe?
The notify stuff only applies to STREAMs. However, we have two different
notify impls, on
> > + if (protocol)
> > + return -EPROTONOSUPPORT;
> > +
>
> IMO protocol == PF_VSOCK should not get rejected here.
Agreed, let me fix that too.
Thanks!
- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
Hi Gerd,
> > +/* Option name for socket's service label. Use as the option name in
> > + * setsockopt(3) or getsockopt(3) to set or get the service label for a
> > socket.
> > + * The service label is a C-style NUL-terminated string. Only available
> > for
> > + * hypervisor endpoints.
> > + */
> stream_has_data: Returns amount of data available (in bytes) in the
> socket's receive buffer, or -1 if empty.
>
> stream_has_space: Returns amount of space available (in bytes) in the
> socket's send buffer, or -1 if full.
Actually, I think it's for empty/full, and -1 for an error (say, the
tr
Hi Gerd,
> > +struct vsock_transport {
...
> Whoa. This has grown *alot*. Care to explain this please? Patch
> creating a Documentation/virtual/vsock.txt would be cool.
Yes, it grew because of the notification stuff, which I'd forgotten
about until I removed the vmci header from the core code.
Hi Gerd,
> > linux/vmw_vmci_defs.h: No such file or directory
> > compilation terminated.
> > make[4]: *** [net/vmw_vsock/af_vsock.o] Error 1
>
> Oops, you're right, it really shouldn't need that header. Sorry
> about that, let me rip that out.
Fixed. The VMCI headers are now gone from the cor
transports, for example
virtio, with the ultimate goal being to make this new socket family
hypervisor-neutral.
[1] If Gerd tries it and determines this to be false (still), I'll ship him
a keg of beer.
Andy King (1):
VSOCK: Introduce VM Sockets
include/linux/socket.h
Hi Gerd,
> Some separation still needs to be done:
>
> CC [M] net/vmw_vsock/af_vsock.o
> In file included from
> /home/kraxel/projects/linux/net/vmw_vsock/af_vsock.c:102:0:
> /home/kraxel/projects/linux/net/vmw_vsock/af_vsock.h:21:33: fatal
> error:
> linux/vmw_vmci_defs.h: No such file or dir
Hi Dave,
> >> Instead, what I remember doing was deferring to the feedback these
> >> folks received, stating that ideas that the virtio people had
> >> mentioned should be considered instead.
> >>
> >> http://marc.info/?l=linux-netdev&m=135301515818462&w=2
> >
> > I believe Andy replied to Anth
Hi Gerd,
> From my side the minimum requirement is to have
> vsock_(un)register_transport calls available, so it is possible to
> write a virtio transport module without having to patch vsock code
> to hook it up.
We've done exactly that. It's now split into two separate modules,
with the core m
transports, for example
virtio, with the ultimate goal being to make this new socket family
hypervisor-neutral.
Andy King (1):
VSOCK: Introduce VM Sockets
include/linux/socket.h |4 +-
include/uapi/linux/vm_sockets.h | 169 +++
n
Hi Gerd,
Thanks so much for taking a look and apologies for the delay!
> > +config VMWARE_VSOCK
> > + tristate "Virtual Socket protocol"
> > + depends on VMWARE_VMCI
>
> I guess this is temporary? Cover letter says *mostly* separated ...
Yes, right now everything is still munged into one d
> > > Our position is that VSOCK feature set is more complete and that
> > > it
> > > should be possible to use transports other than VMCI for VSOCK
> > > traffic, should interested parties implement them,
> >
> > Implementing other transports requires restructing vsock (and vmci)
> > first as the
y Torokhov
Signed-off-by: Andy King
---
drivers/misc/vmw_vmci/vmci_guest.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index de1a90b..60c0199 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++
> > Our position is that VSOCK feature set is more complete and that it
> > should be possible to use transports other than VMCI for VSOCK
> > traffic, should interested parties implement them,
>
> Implementing other transports requires restructing vsock (and vmci)
> first as the current vsock cod
Hi Anthony,
> This was already done in a hypervisor neutral way using virtio:
>
> http://lists.openwall.net/netdev/2008/12/14/8
>
> The concept was Nacked and that led to the abomination of
> virtio-serial. If an address family for virtualization is on the
> table, we should reconsider AF_VMCHA
I didn't get the resend either, so it seems our corporate mail really is
eating messages. Lovely.
> > > +#define IOCTLCMD(_cmd) IOCTL_VMCI_ ## _cmd
> >
> > I don't recall ever getting a valid answer for this (if you did, my
> > appologies, can you repeat it). What in the world are you talking
>
Hi Joe,
> Just some trivial notes.
Thanks for taking a look!
> > + pr_warn("Failed to allocate memory for VMCI context.\n");
>
> OOM logging messages aren't necessary as alloc failures
> are already logged with a stack trace.
Noted, we'll remove all such occurrences.
> Maybe just us
Hi Sasha,
Thanks for taking a look.
> So all the documentation I see in the VMCI Socket Programming Guide
> is about userspace programming, and the documentation in af_vsock.c
> is all around implementation considerations.
Agreed, we're sorely lacking in proper documentation for the internal
pro
Hi Gerd,
>> Also, there was some interest from RedHat into using vSockets as
>> a unified interface, routed over a hypervisor-specific transport
>> (virtio or otherwise, although for now VMCI is the only one
>> implemented).
>
> Can you outline how this can be done? From a quick look over the
>
Hi Stephen,
> You did some scrubbing of the macro's to support multiple kernel
> versions, but there are still some leftovers.
> This code seems to have a lot of "this added in version xxx"
> type comments. These are probably not a good idea to include
> in the mainline kernel code.
Thanks so muc
Hi David,
> The big and only question is whether anyone can actually use any of
> this stuff without your proprietary bits?
Do you mean the VMCI calls? The VMCI driver is in the process of being
upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is
actively reviewing that code
Hi Greg,
> in the next few days with that change along with any modifications
> necessary after a sparse sanity check.
We have a change that fixes things, but I wanted to check if you
had any additional comments before we send out more patches. In
all likelihood you'd probably already given up i
Hi Greg,
> You can't just say "general GPL issues aside". Honestly, given your
> company's prior actions in regards to Linux kernel drivers and the
> licenses of them, I don't trust them at all. To help gain that trust
> back, marking the exports in this manner will be a great improvement.
>
>
Hi Greg,
> > +EXPORT_SYMBOL(vmci_device_get);
>
> EXPORT_SYMBOL_GPL() for this, and all other exports?
We'd prefer to leave them as vanilla exports. While we're committed
to open-sourcing everything, including our non-upstreamed drivers,
we don't really have a strong opinion regarding consuming
53 matches
Mail list logo
