On Wed, Oct 14, 2015 at 10:48 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Peter Zijlstra <pet...@infradead.org> wrote: > >> > I'd still rather find a way to just delete get_wchan, but whatever. >> >> :-) > > AFAICS can only do that at the price of slowing down various scheduler > functions > by saving the caller address. >
A quick check on my machine: # for i in /proc/*/wchan; do cat $i && echo ''; done |sort |uniq doesn't have very much of interest to say: 0 devtmpfsd dmcrypt_write do_sigtimedwait do_wait ep_poll fsnotify_mark_destroy futex_wait_queue_me hrtimer_nanosleep irq_thread kauditd_thread khugepaged kjournald2 ksm_scan_thread kswapd kthreadd pipe_wait poll_schedule_timeout rcu_gp_kthread rcu_nocb_kthread rescuer_thread scsi_error_handler sk_wait_data smpboot_thread_fn unix_stream_recvmsg wait_woken worker_thread xfsaild A bunch of those look like they're specific to kernel threads, for which this whole mechanism is probably pointless -- just reading /proc/PID/stack (with suitable privilege) is probably better. For the rest, a few are useful, but I find myself wondering whether this mechanism is really useful enough to be worth keeping. We could just return "asleep" in /proc/PID/wchan. A more interesting thing to do might be to try to decode regs->orig_ax to give a guess as to which syscall is asleep. But this seems like a lot of fiddling and a lot of worry about security issues for a mechanism of dubious value. Also: $ cat /proc/1/wchan ep_poll Why do we allow unprivileged queries like that at all? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
