From: Matt Mackall <mpm@selenic.com>
To: Erlend Aasland <erlend-a@ux.his.no>
Cc: Steve French <sfrench@us.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Samba Technical Mailing List <samba-technical@samba.org>,
James Morris <jmorris@intercode.com.au>
Subject: Re: [PATCH CIFS] use CryptoAPI MD4/MD5
Date: Wed, 1 Oct 2003 18:42:19 -0500 [thread overview]
Message-ID: <20031001234219.GM1897@waste.org> (raw)
In-Reply-To: <20031001232650.GB18028@badne3.ux.his.no>
On Thu, Oct 02, 2003 at 01:26:50AM +0200, Erlend Aasland wrote:
> On 10/01/03 14:55, Matt Mackall wrote:
> > On Wed, Oct 01, 2003 at 03:30:39PM +0200, Erlend Aasland wrote:
> > > static int cifs_calculate_signature(const struct smb_hdr * cifs_pdu, const char * key, char * signature)
> > [...]
> > Eek. How often does this get called?
> It is (normally) called twice in SendReceive(). SendReceive() is called
> very often in cifs. After a quick look at cifs, it seems that most of
> these calls are protected with a per connection-lock (correct me if I'm
> wrong). But since two connections can call SendReceive() at the same
> time, we have to protect the tfm with locks. Correct?
Correct. But this lock is going to be a huge bottleneck.
> Would a better solution be to allocate one tfm per connection, thus
> no need to protect the tfm with a dedicated lock, right?
Per connection sounds like a much better answer, assuming you can
guarantee that SendReceive() never gets called simultaneously on the
same connection.
> [Or is converting cifs to the cryptoapi is waste of time? (I hope not :-) ]
No, it's generally a good idea, but the allocation of tfms means that
conversion isn't necessarily straightforward.
--
Matt Mackall : http://www.selenic.com : of or relating to the moon
next prev parent reply other threads:[~2003-10-01 23:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-02 20:30 [RFC][PATCH] 2nd try to convert cifs to use CryptoAPI Erlend Aasland
2003-10-01 13:30 ` [PATCH CIFS] use CryptoAPI MD4/MD5 Erlend Aasland
2003-10-01 19:55 ` Matt Mackall
2003-10-01 23:26 ` Erlend Aasland
2003-10-01 23:42 ` Matt Mackall [this message]
2003-10-01 23:52 ` Erlend Aasland
[not found] <OF9C1504BB.5FB00D5A-ON87256DB3.0015672E-86256DB3.001798AE@us.ibm.com>
2003-10-02 11:37 ` Erlend Aasland
2003-10-04 18:00 ` dean gaudet
2003-10-04 18:24 ` Matt Mackall
2003-10-04 18:51 ` dean gaudet
2003-10-04 20:08 ` Francois Romieu
2003-10-05 0:08 ` Matt Mackall
2003-10-05 12:29 ` Erlend Aasland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031001234219.GM1897@waste.org \
--to=mpm@selenic.com \
--cc=erlend-a@ux.his.no \
--cc=jmorris@intercode.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=samba-technical@samba.org \
--cc=sfrench@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.