search for: racy

...8 %0, 1 %tobool = icmp eq i8 %1, 0 %2 = load i32* @a, align 4 %. = select i1 %tobool, i32 0, i32 %2 ret i32 %. } Consider the following function writeA() runs in parallel with readA(). void writeA(){ a = 42; } The source program has no data race if flag=false. But the target program is racy due to the introduced load(a) operation. This is a benign race since the load(a) is used only when flag=true. However, according to the C11/C++11 consistency model the semantics of a racy program is undefined and may have arbitrary behavior. Thus the transformation is unsafe. Note: The full exa...

Hi, I agree that the earlier example was already racy due to shared flag variable. Sorry for the wrong example. Please ignore it. I have modified the program as follows. The only shared variable is 'a' and the following is a non-racy program. int a; int readA(bool flag) { int r=0; if(flag) { r = a; } return r; } void writeA(){ a...

Hello. I am reporting an atomic instructions usage which seem be racy at fs/ocfs2/cluster/heartbeat.c in Linux 2.6.35. I am reporting this issue while I read the recent code. Since I do not have much background, I am not certain whether it is correct or not. But I hope this report is helpful. Please examine the code. In o2hb_heartbeat_group_drop_item(), there are...

This code from raw_ostream.h is really racy: raw_ostream &operator<<(StringRef Str) { // Inline fast path, particularly for strings with a known length. size_t Size = Str.size(); // Make sure we can use the fast path. if (Size > (size_t)(OutBufEnd - OutBufCur)) return write(Str.data(), Size); if (S...

...' > > - output from valgrind would go to stderr, where it is picked up by > the normal verbose output (so we don't need a special socket) This could be okay for me, ... > This doesn't handle the guestfsd shutdown case (but nor does the > current code, which is both racy on shutdown and introduces separate > shutdown paths for --enable-valgrind-daemon and ordinary > configurations). But we can punt on that until later. The above > would detect all memory errors except for memory leaks. ... although losing the leaks detection would be a no-go for me, sin...

...egister_adapter_interrupt(&info->airq); > @@ -273,8 +281,9 @@ static unsigned long get_airq_indicator(struct virtqueue *vqs[], int nvqs, > unsigned long bit, flags; > > for (i = 0; i < MAX_AIRQ_AREAS && !indicator_addr; i++) { > + /* TODO: this seems to be racy */ yes, my opinions too, was already racy, in my opinion, we need another patch in another series to fix this. However, not sure about the comment. > if (!airq_areas[i]) > - airq_areas[i] = new_airq_info(); > + airq_areas[i] = new_airq_info(i); > info = airq_areas[i]; &g...

...egister_adapter_interrupt(&info->airq); > @@ -273,8 +281,9 @@ static unsigned long get_airq_indicator(struct virtqueue *vqs[], int nvqs, > unsigned long bit, flags; > > for (i = 0; i < MAX_AIRQ_AREAS && !indicator_addr; i++) { > + /* TODO: this seems to be racy */ yes, my opinions too, was already racy, in my opinion, we need another patch in another series to fix this. However, not sure about the comment. > if (!airq_areas[i]) > - airq_areas[i] = new_airq_info(); > + airq_areas[i] = new_airq_info(i); > info = airq_areas[i]; &g...

On Wed, Dec 7, 2016 at 10:02 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > This code from raw_ostream.h is really racy: > > > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path, particularly for strings with a known length. > > size_t Size = Str.size(); > > > > // Make sure we can use the fast path. > > if (Size > (size_t)(OutB...

...type f -name "*,S=*" -mtime +1 -exec gzip -S Z -6 '{}' + I.e. find all maildir-files: - with size in the name ("*,S=*") - modified before I enabled zlib plugin - compress them - add the Z suffix - keep timestamps (gzip does that by default) It's of course racy without the maildirlock, but are there any other problems with this approach ? -jf

virtio_mmio currently lacks generation support which makes multi-byte field access racy. Fix by getting the value at offset 0xfc for version 2 devices. Nothing we can do for version 1, so return generation id 0. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Pawel, you mentioned you have a working virtio 1.0 hypervisor, can you pls confirm this works correctly? dr...

virtio_mmio currently lacks generation support which makes multi-byte field access racy. Fix by getting the value at offset 0xfc for version 2 devices. Nothing we can do for version 1, so return generation id 0. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Pawel, you mentioned you have a working virtio 1.0 hypervisor, can you pls confirm this works correctly? dr...

...llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > This code from raw_ostream.h is really racy: > > > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path, particularly for strings with a known length. > > size_t Size = Str.size(); > > > > // Make sure we can use the fast path. > > if (Size > (size_t)(OutB...

If I start ocfs2_controld.cman in parallel on a few nodes, only one of them starts up, the others exit with one of these errors: call_section_read at 370: Reading from section "daemon_protocol" on checkpoint "ocfs2:controld" (try 1) call_section_read at 387: Checkpoint "ocfs2:controld" does not have a section named "daemon_protocol" call_section_read at

...hardlinks in the parent directory, you can rename in the same directory but not across directory boundaries. This is the same behavior when you try to rename across regular partition boundaries, as a hardlink will fail. I understand that renaming was changed a while back so it would not be racy, but is there any reason it shouldn't fall back to a racy rename if EXDEV is returned? I know currently that if LINK_OPNOTSUPP_ERRNO is returned, we'll try a racy rename. Can this be extended to conditions where EXDEV is returned? -- Mike Garrison

Any way to check if another proc has run or been run by a proc that is setuid or seteuid?

Is there an alternative to using link(2) to rename files in sftp-server? Some users use sftp to upload files to a vfat partition on an sftp-server, and then renaming doesn't work. This breaks konqueror, for example (from KDE, which u), which upload files first with a ".part" extension and then renames them removing this extension.

...ed int ret; > > port = filp->private_data; > + if (!port->guest_connected) { > + /* Port was unplugged before we could proceed */ > + return POLLHUP; > + } > poll_wait(filp, &port->waitqueue, wait); > > if (!port->guest_connected) { Looks still racy here. Unlike port_fops_read() which check will_read_block(). If unplug happens after the check but before the poll_wait(), caller will be blocked forever.

...ed int ret; > > port = filp->private_data; > + if (!port->guest_connected) { > + /* Port was unplugged before we could proceed */ > + return POLLHUP; > + } > poll_wait(filp, &port->waitqueue, wait); > > if (!port->guest_connected) { Looks still racy here. Unlike port_fops_read() which check will_read_block(). If unplug happens after the check but before the poll_wait(), caller will be blocked forever.

...t;> > > You can do that locally, but as a patch it's very unlikely to be > accepted upstream because we've introduced RW locks to be able to access > domain list from multiple threads. Looking a bit more, the whole "iterating" bit is currently unsafe. First, it is racy since it's "check then take". Two threads may check the value is false and start iterating both. Moreover, at some places, it is not set, for example in virHashAddOrUpdateEntry(). So, it would be possible to call this function and during the update to iterate over the hash. This seems...

Zhang, Xiantao wrote: >>From 62895ff991d48398a77afdbf7f2bef127e802230 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Fri, 28 Mar 2008 09:49:57 +0800 > Subject: [PATCH] KVM: IA64: Add kvm arch-specific core code for > kvm/ia64. > > kvm_ia64.c is created to handle kvm ia64-specific core logic. > Signed-off-by: Xiantao Zhang