similar to: [LLVMdev] inline asm semantics: output constraint width smaller than input

* Török Edwin <edwintorok at gmail.com> wrote: > On 2009-01-23 20:27, Török Edwin wrote: > >>> > >>> > >> i'd not mind it at all if the kernel could be built with other open-source > >> compilers too. > >> > >> Now in this case the patch you suggest might end up hurting the end result > >> so it's

On 2009-01-24 19:27, Ingo Molnar wrote: > * Török Edwin <edwintorok at gmail.com> wrote: > >> #define put_user(x, ptr) \ >> ({ \ >> - int __ret_pu; \ >> + __typeof__(*(ptr)) __ret_pu; \ >> > > This does not look right. We can sometimes have

On Tuesday 27 January 2009 20:56:30 Mike Stump wrote: > On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote: > > one thing that seems to be clear to everyone except me is... what > > are the > > semantics supposed to be? > > I don't know of any other semantic other than, if they are supposed to > be in the same register, then they have to be in the same register.

On 2009-01-27 22:24, Duncan Sands wrote: > On Tuesday 27 January 2009 20:56:30 Mike Stump wrote: > >> On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote: >> >>> one thing that seems to be clear to everyone except me is... what >>> are the >>> semantics supposed to be? >>> >> I don't know of any other semantic other than,

On Jan 24, 2009, at 9:27 AM, Ingo Molnar wrote: >> #define __put_user_size(x, ptr, size, retval, errret) \ >> diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c >> index f456860..12d27f8 100644 >> --- a/arch/x86/lib/delay.c >> +++ b/arch/x86/lib/delay.c >> @@ -112,7 +112,7 @@ EXPORT_SYMBOL(__delay); >> >> inline void

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

The virtio_ring header file uses the struct device without a forward declaration. Signed-off-by: Shunsuke Mie <mie at igel.co.jp> --- Changes from v2: https://lore.kernel.org/virtualization/20230410074929-mutt-send-email-mst at kernel.org/ - Fix a typo of commit title include/linux/virtio_ring.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/virtio_ring.h

The virtio_ring header file uses the struct device without a forward declaration. Signed-off-by: Shunsuke Mie <mie at igel.co.jp> --- include/linux/virtio_ring.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h index 8b95b69ef694..77a9c2f52919 100644 --- a/include/linux/virtio_ring.h +++ b/include/linux/virtio_ring.h @@ -58,6

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be instrumented separately). While it's possible to script the bulk of this tree-wide conversion, some

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be instrumented separately). While it's possible to script the bulk of this tree-wide conversion, some

On Mon, Apr 10, 2023 at 08:00:33AM -0400, Michael S. Tsirkin wrote: > On Mon, Apr 10, 2023 at 08:28:45PM +0900, Shunsuke Mie wrote: > > Fix the build dependency for virtio_test. The virtio_ring that is used from > > the test requires container_of_const(). Change to use container_of.h kernel > > header directly and adapt related codes. > > > > Signed-off-by:

Hello, On Wed, Nov 02, 2016 at 05:08:35AM -0400, Pan Xinhui wrote: > Support the vcpu_is_preempted() functionality under KVM. This will > enhance lock performance on overcommitted hosts (more runnable vcpus > than physical cpus in the system) as doing busy waits for preempted > vcpus will hurt system performance far worse than early yielding. > > Use one field of struct

Hello, On Wed, Nov 02, 2016 at 05:08:35AM -0400, Pan Xinhui wrote: > Support the vcpu_is_preempted() functionality under KVM. This will > enhance lock performance on overcommitted hosts (more runnable vcpus > than physical cpus in the system) as doing busy waits for preempted > vcpus will hurt system performance far worse than early yielding. > > Use one field of struct

hi, Andrea thanks for your reply. :) ? 2016/12/19 19:42, Andrea Arcangeli ??: > Hello, > > On Wed, Nov 02, 2016 at 05:08:35AM -0400, Pan Xinhui wrote: >> Support the vcpu_is_preempted() functionality under KVM. This will >> enhance lock performance on overcommitted hosts (more runnable vcpus >> than physical cpus in the system) as doing busy waits for preempted

On Mon, 3 Aug 2020 16:58:46 -0400 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Currently all config space fields are of the type __uXX. > This confuses people and some drivers (notably vdpa) > access them using CPU endian-ness - which only > works well for legacy or LE platforms. > > Update virtio_cread/virtio_cwrite macros to allow __virtioXX > and

In the latest Fedora rawhide kernel in the repos, I'm seeing the following oops when mounting xfs. rc2-ish kernels seem to be fine: [ 64.669633] ------------[ cut here ]------------ [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! [ 64.670008] invalid opcode: 0000 [#1] SMP [ 64.670008] Modules linked in: xfs libcrc32c snd_hda_codec_generic snd_hda_intel snd_hda_controller

In the latest Fedora rawhide kernel in the repos, I'm seeing the following oops when mounting xfs. rc2-ish kernels seem to be fine: [ 64.669633] ------------[ cut here ]------------ [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! [ 64.670008] invalid opcode: 0000 [#1] SMP [ 64.670008] Modules linked in: xfs libcrc32c snd_hda_codec_generic snd_hda_intel snd_hda_controller

On 2020/8/4 ??4:58, Michael S. Tsirkin wrote: > Currently all config space fields are of the type __uXX. > This confuses people and some drivers (notably vdpa) > access them using CPU endian-ness - which only > works well for legacy or LE platforms. > > Update virtio_cread/virtio_cwrite macros to allow __virtioXX > and __leXX field types. Follow-up patches will convert >

On 2020/8/4 ??4:58, Michael S. Tsirkin wrote: > Currently all config space fields are of the type __uXX. > This confuses people and some drivers (notably vdpa) > access them using CPU endian-ness - which only > works well for legacy or LE platforms. > > Update virtio_cread/virtio_cwrite macros to allow __virtioXX > and __leXX field types. Follow-up patches will convert >

When xfstests 224 was running, the box was panic, and i got this message: [ 1998.327235] ============================================= [ 1998.329940] [ INFO: possible recursive locking detected ] [ 1998.329940] 2.6.39+ #3 [ 1998.329940] --------------------------------------------- [ 1998.329940] dd/25718 is trying to acquire lock: [ 1998.329940] (&(&eb->lock)->rlock){+.+...}, at: