search for: __mutex

.... It does, but it doesn't have to. It's fine if you guys don't want to change it. It may never be a problem with gcc. This is the definition of pthread_mutex_lock() in glibc. There aren't any magic hints that this invalidates memory: extern int pthread_mutex_lock (pthread_mutex_t *__mutex) __THROWNL __nonnull ((1)); THOWNL is attribute((nothrow)). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150225/1d46e029/attachment.html>

...gxx_personality_v0" can't be undefined in a subtraction expression for this reduced testcase: namespace __cxxabiv1 { extern "C" void *__cxa_allocate_exception() throw(); } int bork(void); namespace __gnu_cxx { inline void __throw_concurrence_unlock_error() { } struct __mutex { void unlock() { if (bork() != 0) __throw_concurrence_unlock_error(); } }; } __gnu_cxx::__mutex emergency_mutex; extern "C" void *__cxxabiv1::__cxa_allocate_exception() throw() { emergency_mutex.unlock(); } I've been looking at it, but haven't been ab...

On 8/24/07, Chris Lattner <sabre at nondot.org> wrote: > > so how about turning it on? > > It sounds good, but I'm concerned about darwin/x86. Bill, can you see how > well darwin/x86 is doing these days? If there are no regressions from > turning this on by default, we should do it. :) > I'm assuming that this is 4.2? :-) I'll give it a try. -bw

...t have to. It's fine if you guys don't want to change > it. It may never be a problem with gcc. > > This is the definition of pthread_mutex_lock() in glibc. There aren't any > magic hints that this invalidates memory: > > extern int pthread_mutex_lock (pthread_mutex_t *__mutex) > __THROWNL __nonnull ((1)); > > THOWNL is attribute((nothrow)). Hm, this is actually a little worrying. Maarten, thoughts? I would have assumed there'd be a __attribute__((some_magic_thing)) in there. -ilia

...if you guys don't want to change >> it. It may never be a problem with gcc. >> >> This is the definition of pthread_mutex_lock() in glibc. There aren't any >> magic hints that this invalidates memory: >> >> extern int pthread_mutex_lock (pthread_mutex_t *__mutex) >> __THROWNL __nonnull ((1)); >> >> THOWNL is attribute((nothrow)). > > Hm, this is actually a little worrying. Maarten, thoughts? I would > have assumed there'd be a __attribute__((some_magic_thing)) in there. In general things don't get optimized across functi...

So you're saying a compiler can optimize: > > - statement with memory access > - read memory barrier > - statement with memory access > > To drop the second statement? I would worry about your definition of > memory barrier then.. > This is tricky, but I think you're mixing up the general case with the actual code you have. In general, you are pointing to this

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 support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

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 support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

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 support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

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 support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +-

...100644 --- a/drivers/misc/vmw_vmci/vmci_queue_pair.c +++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c @@ -148,12 +148,10 @@ typedef int vmci_memcpy_from_queue_func(void *dest, size_t dest_offset, struct vmci_queue_kern_if { struct page **page; struct page **header_page; - void *va; struct mutex __mutex; /* Protects the queue. */ struct mutex *mutex; /* Shared by producer and consumer queues. */ bool host; size_t num_pages; - bool mapped; }; /* @@ -267,11 +265,6 @@ static void qp_free_queue(void *q, u64 size) if (queue) { u64 i = DIV_ROUND_UP(size, PAGE_SIZE); - if (queue->ker...

...h> #include <linux/uio.h> @@ -146,12 +147,20 @@ typedef int vmci_memcpy_from_queue_func(void *dest, size_t dest_offset, /* The Kernel specific component of the struct vmci_queue structure. */ struct vmci_queue_kern_if { - struct page **page; - struct page **header_page; struct mutex __mutex; /* Protects the queue. */ struct mutex *mutex; /* Shared by producer and consumer queues. */ - bool host; - size_t num_pages; + size_t num_pages; /* Number of pages incl. header. */ + bool host; /* Host or guest? */ + union { + struct { + dma_addr_t *pas; + void **vas; + } g; /* Used by...

...vmci_queue *queue, + uint64_t queueOffset, size_t size); + +/* The Kernel specific component of the struct vmci_queue structure. */ +struct vmci_queue_kern_if { + struct page **page; + struct page **headerPage; + void *va; + struct semaphore __mutex; + struct semaphore *mutex; + bool host; + size_t numPages; + bool mapped; +}; + +/* + * This structure is opaque to the clients. + */ +struct vmci_qp { + struct vmci_handle handle; + struct vmci_queue *produceQ; + struct vmci_queue *consumeQ; + uint6...

...vmci_queue *queue, + uint64_t queueOffset, size_t size); + +/* The Kernel specific component of the struct vmci_queue structure. */ +struct vmci_queue_kern_if { + struct page **page; + struct page **headerPage; + void *va; + struct semaphore __mutex; + struct semaphore *mutex; + bool host; + size_t numPages; + bool mapped; +}; + +/* + * This structure is opaque to the clients. + */ +struct vmci_qp { + struct vmci_handle handle; + struct vmci_queue *produceQ; + struct vmci_queue *consumeQ; + uint6...

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later

Second revision of the VMware VMCI RFC patchset. It incorperates fixes for all the feedback about the comment blocks and style and now passes checkpatch with 0 errors and 0 warnings. Thanks to all who have reviewed the code thus far. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication

Second revision of the VMware VMCI RFC patchset. It incorperates fixes for all the feedback about the comment blocks and style and now passes checkpatch with 0 errors and 0 warnings. Thanks to all who have reviewed the code thus far. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication