linux-kernel - Re: [DRIVER SUBMISSION] DRBD wants to go mainline

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a781481a0707250512v29d41b1bh25bcd358e7381d38@mail.gmail.com>
Date:	Wed, 25 Jul 2007 17:42:15 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Lars Ellenberg" <lars.ellenberg@...bit.com>,
	"Satyam Sharma" <satyam.sharma@...il.com>,
	"Kyle Moffett" <mrlinuxman@....com>,
	"Jens Axboe" <axboe@...nel.dk>, "Andrew Morton" <akpm@...l.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [DRIVER SUBMISSION] DRBD wants to go mainline

On 7/25/07, Lars Ellenberg <lars.ellenberg@...bit.com> wrote:
> On Wed, Jul 25, 2007 at 04:41:53AM +0530, Satyam Sharma wrote:
> > [...]
> >
> > But where does the "send" come into the picture over here -- a send
> > won't block forever, so I don't foresee any issues whatsoever w.r.t.
> > kthreads conversion for that. [ BTW I hope you're *not* using any
> > signals-based interface for your kernel thread _at all_. Kthreads
> > disallow (ignore) all signals by default, as they should, and you really
> > shouldn't need to write any logic to handle or do-certain-things-on-seeing
> > a signal in a well designed kernel thread. ]
> >
> > >and the sending
> > >latency is crucial to performance, while the recv
> > >will not timeout for the next few seconds.
> >
> > Again, I don't see what sending latency has to do with a kernel_thread
> > to kthread conversion. Or with signals, for that matter. Anyway, as
> > Kyle Moffett mentioned elsewhere, you could probably look at other
> > examples (say cifs_demultiplexer_thread() in fs/cifs/connect.c).
>
> the basic problem, and what we use signals for, is:
>
> it is waiting in recv, waiting for the peer to say something.
> but I want it to stop recv, and go send something "right now".

That's ... weird. Most (all?) communication between any two parties
would follow a protocol where someone recv's stuff, does something
with it, and sends it back ... what would you send "right now" if you
didn't receive anything?

> I don't want to have two threads for that.

I really think you should -- you clearly should. From the above, it does
appear that you're mixing in multiple kinds of stuff into a single thread,
and thus mucking up the entire design (and implementation).

> yes we have timeo in place, anyways: we need to detect a failed peer
> node in time. we even aim for "sub-second failover" sometimes (which is
> not exactly feasible; but failover times of 15 seconds and less are
> requirement for useable HA-iSCSI deployments).
> but that does not cut it, timeo is seconds.
> you don't want seconds latency for IO operations.

Ok, that's a reasonable goal.

> so I signal it, it breaks out of recv, then sends, and goes back to recv.
>
> in-kernel epoll would probably solve this.
> I don't know how to do that properly, though.

Hmm, probably I don't understand what you're doing, how you're doing etc.
Will wait for the design & implementation docs.

Thanks,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/