Displaying 3 results from an estimated 3 matches for "is_atomic".
Did you mean:
in_atomic
2020 May 26
6
[RFC] Loading Bitfields with Smallest Needed Types
...*frag;
unsigned int frag_len;
u16 flush;
u16 flush_id;
u16 count;
u16 gro_remcsum_start;
unsigned long age;
u16 proto;
u8 same_flow : 1;
u8 encap_mark : 1;
u8 csum_valid : 1;
u8 csum_cnt : 3;
u8 free : 2;
u8 is_ipv6 : 1;
u8 is_fou : 1;
u8 is_atomic : 1;
u8 recursive_counter : 4;
__wsum csum;
struct sk_buff *last;
};
void dev_gro_receive(struct sk_buff *skb)
{
...
same_flow = NAPI_GRO_CB(skb)->same_flow;
...
}
Right before the "same_flow = ... ->same_flow;" statement is executed,
a store is made to the bit...
2016 Jan 22
4
greendragon build noisy due to mmap_stress.cc
...e
>> shadow memory?
>>
>> Does “0x00486000000025df” like a reasonable content of a shadow cell?
>
>
>
> Yes, it looks like a reasonable shadow:
>
> // Shadow (from most significant bit):
> // freed : 1
> // tid : kTidBits
> // is_atomic : 1
> // is_read : 1
> // size_log : 2
> // addr0 : 3
> // epoch : kClkBits
+Nico pointed to another failure:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9782/testReport/ThreadSanitizer/ThreadSanitizer/mmap_stress_cc/
2016 Jan 22
2
greendragon build noisy due to mmap_stress.cc
Hm, I tried to reproduce this as well, but unsuccessfully. From the crash report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17, which is just after the prologue and just after calling cur_thread(). So I’d say it happens when we’re dereferencing the pointer returned by cur_thread(). On OS X, we’re