Date: Wed, 13 Mar 2019 21:14:47 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Hans Petter Selasky <hselasky@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r345100 - head/sys/compat/linuxkpi/common/include/linux Message-ID: <20190313191447.GC2492@kib.kiev.ua> In-Reply-To: <201903131855.x2DItg7s091824@repo.freebsd.org> References: <201903131855.x2DItg7s091824@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 13, 2019 at 06:55:42PM +0000, Hans Petter Selasky wrote: > Author: hselasky > Date: Wed Mar 13 18:55:41 2019 > New Revision: 345100 > URL: https://svnweb.freebsd.org/changeset/base/345100 > > Log: > Implement task_euid() and get_task_state() function macros in the LinuxKPI. > > Submitted by: Johannes Lundberg <johalun0@gmail.com> > MFC after: 1 week > Sponsored by: Limelight Networks > Sponsored by: Mellanox Technologies > > Modified: > head/sys/compat/linuxkpi/common/include/linux/sched.h > > Modified: head/sys/compat/linuxkpi/common/include/linux/sched.h > ============================================================================== > --- head/sys/compat/linuxkpi/common/include/linux/sched.h Wed Mar 13 18:53:29 2019 (r345099) > +++ head/sys/compat/linuxkpi/common/include/linux/sched.h Wed Mar 13 18:55:41 2019 (r345100) > @@ -95,7 +95,9 @@ struct task_struct { > #define get_pid(x) (x) > #define put_pid(x) do { } while (0) > #define current_euid() (curthread->td_ucred->cr_uid) > +#define task_euid(task) ((task)->task_thread->td_ucred->cr_uid) This looks very strange if you compare the definition of task_euid() with the definition of linux_task_exiting() in r345098. There you access td_ucred which is basically volatile and invalid unless the thread is known to be inhibited or sleeping (and not exiting). So to use the macro safely for task not associated with current thread, you must have very strong and unusual external guarantees. On the other hand, linux_task_exiting() correctly locks the target process. But, since the lock is dropped before the function returns, the process might exit wheh the callers gets to use the result. Again, some external guarantees must be ensured to give safe use for this macro as well, for the target process != curproc. > > +#define get_task_state(task) atomic_read(&(task)->state) > #define set_task_state(task, x) atomic_set(&(task)->state, (x)) > #define __set_task_state(task, x) ((task)->state.counter = (x)) > #define set_current_state(x) set_task_state(current, x)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190313191447.GC2492>