Roland McGrath wrote: >> y'all might get multiple copies of this--i think the stuttgart smtp >> server i've been using might not be working right... >> > > I got two copies, but one of them stole an R from you! > > >> looks like stuff that used to be wrapped up in >> rcu_read_lock()/rcu_read_unlock() is now wrapped up in >> read_lock(&tasklist_lock)/read_unlock(&tasklist_lock) but tasklist_lock >> is showing up as undefined in module build stage 2 and "Unknown symbol >> in module" in insmod. am i balling something up? or can i go on using >> rcu_read_(un)?lock? >> > > In the new utrace API there is nothing that requires you to use either RCU > or tasklist_lock. If you are using RCU for your own purposes, that's up to > you. The tasklist_lock has not been exported for modules to use in a long > time. Please be specific in your questions. What are you doing that you > think needs some locking you aren't doing? >
A little fnc to get the task associated with a given pid: static struct task_struct * get_task (long utraced_pid) { struct task_struct * task; read_lock (&tasklist_lock); task = find_task_by_vpid(utraced_pid); if (task) get_task_struct(task); read_unlock (&tasklist_lock); return task; } I know you've got utrace_attach_pid(), but there are other circumstances I've used in the past, like accessing user mem via get_user_pages(), where I needed access to the task struct. Even if I don't need task struct any more for utrace, I'm kinda trying to plan ahead a bit. Or are pid_task() and get_pid_task() the new/modern way of doing that w/o needing your own locking? cm > > Thanks, > Roland > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey
signature.asc
Description: OpenPGP digital signature