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]

Date:	Wed, 25 Jul 2007 19:03:37 -0700 (PDT)
From:	david@...g.hm
To:	Satyam Sharma <satyam.sharma@...il.com>
cc:	Lars Ellenberg <lars.ellenberg@...bit.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 Wed, 25 Jul 2007, Satyam Sharma wrote:

> 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?

becouse even though you didn't receive anything you now have something 
important to send.

remember that both sides can be sitting in receive mode. this puts them 
both in a position to respond to the other if the other has something to 
say.

David Lang
-
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/