search for: ishst

...struct hlist_node *next) { n->pprev = next->pprev; n->next = next; rcu_assign_pointer(hlist_pprev_rcu(n), n); next->pprev = &n->next; } can reordered, and causes kernel crash. f94006a8 ldr x8, [x21,#8] f9000275 str x21, [x19] d5033abf dmb ishst f9400669 ldr x9, [x19,#8] f9000668 str x8, [x19,#8] <==== reordered str f9000133 str x19, [x9] f90006b3 str x19, [x21,#8] It should be: f94006a8 ldr x8, [x21,#8] f9000668 str x8, [x19,#8] f9000275 str x21, [x19] d5033abf dmb ishst f9400669 ldr x9, [x19,#8] f9000133 str x19, [x9] f900...

I'm using r223407. Switching to a clean built on r223853, it still gives me: ldr x8, [x21,#8] stp x21, x8, [x19] dmb ishst ldr x8, [x19,#8] str x19, [x8] str x19, [x21,#8] Thanks, Chengyu > On Dec 9, 2014, at 6:32 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 9 December 2014 at 15:14, Chengyu Song <csong84 at gatech.edu> wrote: >> Errr. my fault. I patched the rc...

...moves the hlist_pprev_rcu(n) access before the > n->pprev assignment. Could be because of an aliasing violation, or it > could be LLVM. The problem is explained below, the reordering causes accessing to uninitialized data. f94006a8 ldr x8, [x21,#8] f9000275 str x21, [x19] d5033abf dmb ishst f9400669 ldr x9, [x19,#8] <==== uninitialized data f9000668 str x8, [x19,#8] <==== initialization f9000133 str x19, [x9] <==== accessing uninitialized address f90006b3 str x19, [x21,#8] > Do you have preprocessed source or LLVM IR handy? (You can get a .i > file from "clang...

I'm not sure, I was never able to compile the whole kernel with -O0, too many errors. Plus, the problem seems to be within machine code generation. I tried opt -O1 and -O2, the generated .ll file does not diff much for the target function (insert_leaf_info). Thanks, Chengyu > On Dec 9, 2014, at 4:49 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 9 December 2014

...lude/asm/barrier.h @@ -60,15 +60,9 @@ extern void arm_heavy_mb(void); #define dma_wmb() barrier() #endif -#ifndef CONFIG_SMP -#define smp_mb() barrier() -#define smp_rmb() barrier() -#define smp_wmb() barrier() -#else -#define smp_mb() dmb(ish) -#define smp_rmb() smp_mb() -#define smp_wmb() dmb(ishst) -#endif +#define __smp_mb() dmb(ish) +#define __smp_rmb() __smp_mb() +#define __smp_wmb() dmb(ishst) #include <asm-generic/barrier.h> -- MST

...e to come up with an example and telling us about it. > Fixing it is a two line change in insertLeadingFence, but it triggers some > test failures, both because of tests looking specifically for a fence > release here, That's fine, we can change those easily enough. And the "dmb ishst" (as I understand it, it *is* a release fence, but not almost certainly not suitable for preventing this reordering). Cheers. Tim.

...PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> I guess it's because we disabled the integrated-asm, so it won't complain when compiling the kernel. > > No, it's something different. The inline assembly (for whatever > reason) says to use a "dmb ishst" rather than an "stlr". I don't > actually think the reason is that important, it's just surprising > because I'd expect stlr to be more efficient. I see .... guess I'm using an old version of Linux kernel ... from the Android branch ... > Thanks for the IR...

>> Switching to a clean built on r223853, it still gives me: >> >> ldr x8, [x21,#8] >> stp x21, x8, [x19] >> dmb ishst >> ldr x8, [x19,#8] >> str x19, [x8] >> str x19, [x21,#8] > > Isn't that correct though? The problematic "str" has been folded into > the "stp" instruction, so "x19 + 8" is written before it gets read. Indeed. I didn't pay...

...le changed, 1 insertion(+), 22 deletions(-) diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h index 3ff5642..31152e8 100644 --- a/arch/arm/include/asm/barrier.h +++ b/arch/arm/include/asm/barrier.h @@ -70,28 +70,7 @@ extern void arm_heavy_mb(void); #define smp_wmb() dmb(ishst) #endif -#define smp_store_release(p, v) \ -do { \ - compiletime_assert_atomic_type(*p); \ - smp_mb(); \ - WRITE_ONCE(*p, v); \ -} while (0) - -#define smp_load_acquire(p) \ -({ \ - typeof(*p) ___p1 = READ_ONCE(*p); \ - compiletime_assert_atomic_type(*p...

> I am planning in doing in IR, but with target specific-passes (such as X86ExpandAtomicPass) > that just share some of the code This would more normally be done via target hooks in LLVM, though the principle is sound. > But it must be target-dependent as for example on Power a > seq_cst store has a fence before it, while on ARM it has a fence > both before and after it (per

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven''t yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I