search for: thread0

On 06/06, Mike Christie wrote: > > On 6/6/23 7:16 AM, Oleg Nesterov wrote: > > On 06/05, Mike Christie wrote: > > > >> So it works like if we were using a kthread still: > >> > >> 1. Userapce thread0 opens /dev/vhost-$something. > >> 2. thread0 does VHOST_SET_OWNER ioctl. This calls vhost_task_create() to > >> create the task_struct which runs the vhost_worker() function which handles > >> the work->fns. > >> 3. If userspace now does a SIGKILL or just exit...

...sunderstanding the sub-thread term. > > - Is it the task_struct's context that we did the > kernel/vhost_taskc.c:vhost_task_create() from? Below it would be the > thread we did VHOST_SET_OWNER from. Yes, > So it works like if we were using a kthread still: > > 1. Userapce thread0 opens /dev/vhost-$something. > 2. thread0 does VHOST_SET_OWNER ioctl. This calls vhost_task_create() to > create the task_struct which runs the vhost_worker() function which handles > the work->fns. > 3. If userspace now does a SIGKILL or just exits without doing a close() on > /d...

...; >> - Is it the task_struct's context that we did the >> kernel/vhost_taskc.c:vhost_task_create() from? Below it would be the >> thread we did VHOST_SET_OWNER from. > > Yes, > >> So it works like if we were using a kthread still: >> >> 1. Userapce thread0 opens /dev/vhost-$something. >> 2. thread0 does VHOST_SET_OWNER ioctl. This calls vhost_task_create() to >> create the task_struct which runs the vhost_worker() function which handles >> the work->fns. >> 3. If userspace now does a SIGKILL or just exits without doing a cl...

...d by kernel/vhost_taskc.c:vhost_task_create()? If so, then the answer is no. vhost_task_create has set the no_files arg on kernel_clone_args, so copy_files() sets task_struct->files to NULL and we don't clone or dup the files. So it works like if we were using a kthread still: 1. Userapce thread0 opens /dev/vhost-$something. 2. thread0 does VHOST_SET_OWNER ioctl. This calls vhost_task_create() to create the task_struct which runs the vhost_worker() function which handles the work->fns. 3. If userspace now does a SIGKILL or just exits without doing a close() on /dev/vhost-$something, then...

On 6/6/23 4:49 AM, Stefano Garzarella wrote: > On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: >> If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we >> can race where: >> 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue >> 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. >> 3. vhost_worker_create will set the dev->worker pointer before setting >> the worker->vtsk pointer. >> 4. thread0's vhost_work_queue will se...

...023 at 12:19:10PM -0500, Mike Christie wrote: > On 6/6/23 4:49 AM, Stefano Garzarella wrote: > > On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: > >> If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we > >> can race where: > >> 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue > >> 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. > >> 3. vhost_worker_create will set the dev->worker pointer before setting > >> the worker->vtsk pointer. > >> 4. thread0's vhos...

On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: >If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we >can race where: >1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue >2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. >3. vhost_worker_create will set the dev->worker pointer before setting >the worker->vtsk pointer. >4. thread0's vhost_work_queue will see the dev->worker...

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see the dev->worker pointer is set...

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see the dev->worker pointer is set...

Paul, On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > It is not so simple, I mean "local ordering for address and data > > dependencies". Local ordering is NOT enough. It happens that current > > MIPS R6 doesn't require in your example smp_read_barrier_depends() > >

Paul, On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > It is not so simple, I mean "local ordering for address and data > > dependencies". Local ordering is NOT enough. It happens that current > > MIPS R6 doesn't require in your example smp_read_barrier_depends() > >

...Use 'make rsync-extsoft' to populate the default directory. EXT_LIBS = D:/R64/extsoft # an alternative is to use -gstabs here, if the debugger supports only stabs. # G_FLAG = -gdwarf-2 # Set to YES and specify the path if you want to use the ATLAS BLAS. USE_ATLAS = YES ATLAS_PATH =D:/home/thread0 # Support for the ACML and Goto BLASes has been withdrawn: see R-admin.html # Define to use svnversion to set SVN-REVISION (slow, and requires a clean # checkout with no modifications). # USE_SVNVERSION = YES # With the previously recommended gcc 4.6.3 toolchain, set this to 32 or 64 # MULTI = 6...

...e the default directory. > EXT_LIBS = D:/R64/extsoft > > # an alternative is to use -gstabs here, if the debugger supports only > stabs. > # G_FLAG = -gdwarf-2 > > # Set to YES and specify the path if you want to use the ATLAS BLAS. > USE_ATLAS = YES > ATLAS_PATH =D:/home/thread0 > > # Support for the ACML and Goto BLASes has been withdrawn: see R-admin.html > > # Define to use svnversion to set SVN-REVISION (slow, and requires a clean > # checkout with no modifications). > # USE_SVNVERSION = YES > > # With the previously recommended gcc 4.6.3 toolch...

Hi All, I am trying to compile R from source on a 64 bit Windows. I have downloaded and installed all the third party software as per the R - documentation. The compilation starts fine and after a while it stops with the following error message: D:/Rtools/mingw_64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lRgraphapp collect2.exe: error: ld

Hi, Is there any documentation on enabling hypervisor support for both C and P-state control? On xen-unstable and linux-2.6.18-xen.hg, if I enable cpuidle=1 on the xen command line and then run xenpm, I will get output for C-states (shown below) but it complains that "Xen cpufreq is not enabled!" cpu id : 0 total C-states : 2 idle time(ms) : 73264 C0

...T_LIBS = D:/R64/extsoft >> >> # an alternative is to use -gstabs here, if the debugger supports only >> stabs. >> # G_FLAG = -gdwarf-2 >> >> # Set to YES and specify the path if you want to use the ATLAS BLAS. >> USE_ATLAS = YES >> ATLAS_PATH =D:/home/thread0 >> >> # Support for the ACML and Goto BLASes has been withdrawn: see R-admin.html >> >> # Define to use svnversion to set SVN-REVISION (slow, and requires a clean >> # checkout with no modifications). >> # USE_SVNVERSION = YES >> >> # With the previou...

...v_set_init_ops(); + + /* Now we can jump into the native init function */ + return hammer_time(0, physfree); +} +#endif + u_int64_t hammer_time(u_int64_t modulep, u_int64_t physfree) { @@ -1705,17 +1842,7 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) */ proc_linkup0(&proc0, &thread0); - preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE); - preload_bootstrap_relocate(KERNBASE); - kmdp = preload_search_by_type("elf kernel"); - if (kmdp == NULL) - kmdp = preload_search_by_type("elf64 kernel"); - boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int); - k...