netdev - Workqueues vs. kernel threads for processing asynchronous socket events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101210152754.GC28580@dezo.moloch.sk>
Date:	Fri, 10 Dec 2010 16:27:54 +0100
From:	Martin Lucina <mato@...elna.sk>
To:	netdev@...r.kernel.org
Cc:	Martin Sustrik <sustrik@...bpm.com>
Subject: Workqueues vs. kernel threads for processing asynchronous socket
	events

Hi,

I'm trying to find the best mechanism to process events from kernel space
sockets in an asynchronous manner. The work in progress code I have at the
moment tries to at least call kernel_accept() on a bound TCP socket when it
gets called by the underlying sk->sk_data_ready callback.

The current approach I have is to use a workqueue and try to schedule work
inside the callback, but this has the kernel complaining about "scheduling
while atomic", so it doesn't look like it's the right approach? Am I
allowed to call schedule_work() from the context of a sk->sk_data_ready
callback or not?

Sunrpc/knfsd appears to use a different approach where
svc_tcp_listen_data_ready() sets the appropriate state and then calls
wake_up_interruptible_all(sk_sleep(sk)) -- it's not clear who this is
waking up, the nfsd kernel thread or someone else?

Any advice on what is the best future-proof approach to use for this kind
of thing in a new project?

-mato
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html