On 11/11, Greg Thelen wrote: > > a) my original report added rcu_read_lock() to sys_ioprio_get() and > claims that "something" is needed in sys_ioprio_set(). > > c) http://lkml.org/lkml/2010/10/29/168 added rcu locks to both > sys_ioprio_get() and sys_ioprio_set() thus addressing the issues > raised in a). However, I do not see this patch in -mm. Well, I do not know what happened with this patch, but > I can resubmit my patch, but want to know if there is a reason that > http://lkml.org/lkml/2010/10/29/168 did not make it into either -mm > or linux-next? I am looking at http://lkml.org/lkml/2010/10/29/168 now, and I think it should be dropped or you can submit the patch on top of it. It only adds rcu_read_lock() around of find_task_by_vpid(), but we can use rcu_read_lock() instead of tasklist_lock. > d) the sys_ioprio_set() comment indicating that "we can't use > rcu_read_lock()" needs to be updated to be more clear. I'm not sure > what this should be updated to, which leads into the next > sub-topic... It should be just removed. It doesn't match the reality today. > e) possibly removing tasklist_lock, Yes. > though there seems to be some > concern that this might introduce task->io_context usage race. No! I am sorry for confusion, those ->io_context races are completely orthogonal to s/tasklist/rcu/. Oleg. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>