* RE: [openib-general] [PATCH v2 1/2] iWARP Connection Manager.
From: Sean Hefty @ 2006-06-13 21:36 UTC (permalink / raw)
To: 'Steve Wise', Tom Tucker
Cc: Andrew Morton, netdev, rdreier, linux-kernel, openib-general
In-Reply-To: <1150230871.17394.68.camel@stevo-desktop>
>> Er...no. It will lose this event. Depending on the event...the carnage
>> varies. We'll take a look at this.
>>
>
>This behavior is consistent with the Infiniband CM (see
>drivers/infiniband/core/cm.c function cm_recv_handler()). But I think
>we should at least log an error because a lost event will usually stall
>the rdma connection.
I believe that there's a difference here. For the Infiniband CM, an allocation
error behaves the same as if the received MAD were lost or dropped. Since MADs
are unreliable anyway, it's not so much that an IB CM event gets lost, as it
doesn't ever occur. A remote CM should retry the send, which hopefully allows
the connection to make forward progress.
- Sean
^ permalink raw reply
* Re: http://bugzilla.kernel.org/show_bug.cgi?id=6197
From: Michael Tokarev @ 2006-06-13 21:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <448EE065.9060207@trash.net>
Patrick McHardy wrote:
[]
> He patched his kernel with the IMQ device, which is known to cause all
> kinds of weird problems.
Wich problems? Known to whom?
I was considering using imq for our needs (not done yet), and from the
FAQ at http://www.linuximq.net/faq.html (item #3, "Is it stable?") it
seems there's no problems except of gre tunnels and locally generated
traffic...
Googling for "imq linux problem" shows usual pile of various user
support questions (how to configure.. what did I do wrong.. etc),
but nothing relevant.
So... I'm curious whenever the claim on linuximq.net site about the
stability is true, or there in fact are some real issue...
Thanks.
/mjt
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-13 21:40 UTC (permalink / raw)
To: Daniel Phillips
Cc: Stephen Hemminger, Sridhar Samudrala, netdev, linux-kernel
In-Reply-To: <448F2A49.5020809@google.com>
Daniel,
On Tue, 13 Jun 2006, Daniel Phillips wrote:
>
> This has the makings of a nice stable internal kernel api. Why do we want
> to provide this nice stable internal api to proprietary modules?
Why not? Not all non-GPL modules are proprietary. Do we lose
something by making a nice stable api available to non-derived
modules?
^ permalink raw reply
* How can we make more use of memory for TCP properly?
From: Kumiko Ono @ 2006-06-13 21:46 UTC (permalink / raw)
To: netdev
Hi all,
Although I tried to find similar topics in the maling list, I found no
useful clue. If I overlooked, please let me know the pointer.
I need to increase the value of sysctl_tcp_mem[2] that limit the total
amount of memory allocated for TCP in order to maintain a number of
simultateous TCP connections at a server, especially as a TCP server,
like a web server.
Accorting to TCP man page, the kernel calculates the values of
sysctl_tcp_mem depending on available physical memory at boot time.
I added 2GB RAM to a machine that had 2GB, and then it has 4GB RAM now.
However, the value of sysctl_tcp_mem[2] has not changed from 196608
(pages). The machine is running at Linux 2.6.16.5 i686 Intel(R)
Pentium(R) 4 CPU 3.06GHz.
When looking through the tcp_init() in tcp.c, I found the value are
determined with the tcp bind hash size, which reaches a upper cap of
65536. I understand this upper cap is derived from the maximum of local
port numbers, which are related to the behavior of TCP client, not that
of TCP server.
When I manually increased the sysctl_tcp_mem to the double, 393216, and
tried to establish over 30K TCP connections, the server hung up without
any error messages of syslog.
Could anbody tell me how to make more use of memory for TCP connections
properly, without replacing the machine to 64-bit arch.?
Regards,
Kumiko
^ permalink raw reply
* RE: [openib-general] [PATCH v2 1/2] iWARP Connection Manager.
From: Steve Wise @ 2006-06-13 21:46 UTC (permalink / raw)
To: Sean Hefty
Cc: Tom Tucker, Andrew Morton, netdev, rdreier, linux-kernel,
openib-general
In-Reply-To: <000001c68f31$78910fe0$24268686@amr.corp.intel.com>
On Tue, 2006-06-13 at 14:36 -0700, Sean Hefty wrote:
> >> Er...no. It will lose this event. Depending on the event...the carnage
> >> varies. We'll take a look at this.
> >>
> >
> >This behavior is consistent with the Infiniband CM (see
> >drivers/infiniband/core/cm.c function cm_recv_handler()). But I think
> >we should at least log an error because a lost event will usually stall
> >the rdma connection.
>
> I believe that there's a difference here. For the Infiniband CM, an allocation
> error behaves the same as if the received MAD were lost or dropped. Since MADs
> are unreliable anyway, it's not so much that an IB CM event gets lost, as it
> doesn't ever occur. A remote CM should retry the send, which hopefully allows
> the connection to make forward progress.
>
hmm. Ok. I see. I misunderstood the code in cm_recv_handler().
Tom and I have been talking about what we can do to not drop the event.
Stay tuned.
Steve.
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: Mark Lord @ 2006-06-13 21:49 UTC (permalink / raw)
To: David Miller; +Cc: jheffner, torvalds, linux-kernel, netdev
In-Reply-To: <20060613.142603.48825062.davem@davemloft.net>
David Miller wrote:
>..
> First, you are getting window scaling by default with the older
> kernel too. It's just a smaller window scale, using a shift
> value of say 1 or 2.
>
> What these broken middle boxes do is ignore the window scale
> entirely.
>
> So they don't apply a window scale to the advertised windows in each
> packet. Therefore, they think a smaller amount of window space is
> being advertised than really is. So they will silently drop packets
> they think is outside of this bogus window they've calculated.
>
> Now, when the window scale is smaller, the connection can still limp
> along, albeit slowly, making forward progress even in the face of such
> broken devices because half or a quarter of the window is still
> available. It will retransmit a lot, and the congestion window won't
> grow at all.
>
> When the window scale is larger, this middle box bug makes it such
> that not even one packet can fit into the miscalculated window and
> things wedge. The box thinks that your window is "94" instead of
> "94 << WINDOW_SCALE".
..
Unilaterally following the standard is all well and good
for those who know how to get around it when a site becomes
inaccessible, but not for Joe User.
If it always fails, or always works, that's not such a big problem.
I would never have complained if I had never been able to access
the web sites in question. But since it IS working in 2.6.16,
and got broken in 2.6.17, I'm bloody well going to complain.
I suppose the most important objection to our current behaviour
is that this behaviour *changes* when something totally unrelated
(to Joe User) happens: adding or removing a stick of RAM.
So I'm not against the window scaling, just against it's apparent
randomness (to the vast majority who are not "in the know").
We should perhaps just have a fixed upper memory setting, as we
currently do in 2.6.16, so that the behaviour is predictable.
On a related note.. I wonder if we can choose better values for
the window size, so that if the scale factor is ignored, we still
end up with reasonably sized packets? So that the other box
will not think our window is a mere "94" when the scale factor
is lost?
-ml
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Chase Venters @ 2006-06-13 22:00 UTC (permalink / raw)
To: Brian F. G. Bidulock
Cc: Daniel Phillips, Stephen Hemminger, Sridhar Samudrala, netdev,
linux-kernel
In-Reply-To: <20060613154031.A6276@openss7.org>
On Tue, 13 Jun 2006, Brian F. G. Bidulock wrote:
> Daniel,
>
> On Tue, 13 Jun 2006, Daniel Phillips wrote:
>>
>> This has the makings of a nice stable internal kernel api. Why do we want
>> to provide this nice stable internal api to proprietary modules?
>
> Why not? Not all non-GPL modules are proprietary. Do we lose
> something by making a nice stable api available to non-derived
> modules?
Look out for that word (stable). Judging from history (and sanity),
arguing /in favor of/ any kind of stable module API is asking for it.
At least some of us feel like stable module APIs should be explicitly
discouraged, because we don't want to offer comfort for code
that refuses to live in the tree (since getting said code into the tree is
often a goal).
I'm curious now too - can you name some non-GPL non-proprietary modules we
should be concerned about? I'd think most of the possible examples (not
sure what they are) would be better off dual-licensed (one license
being GPL) and in-kernel.
Thanks,
Chase
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: Chase Venters @ 2006-06-13 22:09 UTC (permalink / raw)
To: John Heffner; +Cc: Linus Torvalds, Mark Lord, Linux Kernel, netdev, davem
In-Reply-To: <448F03B3.5040501@psc.edu>
On Tue, 13 Jun 2006, John Heffner wrote:
>
> In the last couple years, we've added code that can automatically size the
> buffers as appropriate for each connection, but it's completely crippled
> unless you use a window scale. Personally, I think it's not a question of
> *whether* we have to start using a window scale by default, but *when*. I
> don't know that we want to let a small number of unambiguously broken
> middleboxes kill our forward progress.
Another example - Same thing happened with ECN. I recall setting up a mail
server at the time and noticing that I had to disable ECN because some
dumbass PIX routers out there were dropping packets with a _reserved bit_
set! Sure, there was a firmware upgrade, but the dingbat admins I tried to
alert didn't seem (at the time) too interested in fixing their problem.
Does anyone have any interesting statistics on how often end-users are
likely to run into this crap? It really is a shame when you have to suck just
because someone else does.
>
> Thanks,
> -John
Cheers,
Chase
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: Rick Jones @ 2006-06-13 22:12 UTC (permalink / raw)
To: Mark Lord; +Cc: David Miller, jheffner, torvalds, linux-kernel, netdev
In-Reply-To: <448F32E1.8080002@rtr.ca>
Mark
From everything I have read so far (which admittedly hasn't been
everything) it sounds like the firewall in question was a ticking
timebomb. If 2.6.17 hadn't set it off, something else might very well
have done so.
Or, if you prefer another metaphore, 2.6.17 was simply the last in a
series of straws on the back of the camel what was the firewall. Meta
issues of whether or not the camel that is firewalls should have ever
been allowed to poke its nose in the Internet Tent notwithstanding :)
At the very least, the firewall, if it is going to be "stateless," has
to strip the window scaling option from the SYN's that go past.
Otherwise, I would be inclined to agree with David that the firewall is
fundamentally broken.
rick jones
^ permalink raw reply
* Re: [RFC/PATCH 2/2] update sunrpc to use in-kernel sockets API
From: James Morris @ 2006-06-13 22:13 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: netdev, linux-kernel
In-Reply-To: <1150215626.31720.9.camel@w-sridhar2.beaverton.ibm.com>
On Tue, 13 Jun 2006, Sridhar Samudrala wrote:
> My patch doesn't touch this section of the code and this is called
> after the assignment we are talking about. So we should be using the
> right sendpage in the actual call.
Ok.
Acked-by: James Morris <jmorris@namei.org>
(for both patches).
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: David Miller @ 2006-06-13 22:23 UTC (permalink / raw)
To: lkml; +Cc: jheffner, torvalds, linux-kernel, netdev
In-Reply-To: <448F32E1.8080002@rtr.ca>
From: Mark Lord <lkml@rtr.ca>
Date: Tue, 13 Jun 2006 17:49:21 -0400
> I suppose the most important objection to our current behaviour
> is that this behaviour *changes* when something totally unrelated
> (to Joe User) happens: adding or removing a stick of RAM.
We are pretty much required to choose the TCP memory parameters
based upon how much physical memory is in the machine, and these
parameters in-turn are inextricably linked to what kind of window
scale we try to use for connections.
The behavior is unfortunate, but more unfortunate are the boxes that
create these problems in the first place. I believe their lifespan is
quite limited.
> We should perhaps just have a fixed upper memory setting, as we
> currently do in 2.6.16, so that the behaviour is predictable.
The change in 2.6.17 was exactly that we needed to increase this
upper limit to ~4MB.
> On a related note.. I wonder if we can choose better values for
> the window size, so that if the scale factor is ignored, we still
> end up with reasonably sized packets? So that the other box
> will not think our window is a mere "94" when the scale factor
> is lost?
We have an algorithm that tries to pick something based upon the
set of the values we might need to represent in the window field.
If the scale is too high, you lose accuracy, since the lower bits
get chopped off when the TCP header is being built and the computed
window size is shifted down.
So we try to pick the smallest scale necessary to represent the
largest window size we might end up needing to advertise.
A complication here is that we dynamically size both receive and send
buffers in response to our growing knowledge of the connection's
characteristics over time. So at the beginning we'll use a small
buffer size, and as the congestion window grows we'll increase our
buffer sizes to fill the pipe.
This adds even more considerations for window scale selection, as you
can imagine.
One final word about window sizes. If you have a connection whose
bandwidth-delay-product needs an N byte buffer to fill, you actually
have to have an "N * 2" sized buffer available in order for fast
retransmit to work.
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: David Miller @ 2006-06-13 22:23 UTC (permalink / raw)
To: chase.venters; +Cc: jheffner, torvalds, lkml, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.64.0606131706040.4856@turbotaz.ourhouse>
From: Chase Venters <chase.venters@clientec.com>
Date: Tue, 13 Jun 2006 17:09:16 -0500 (CDT)
> Does anyone have any interesting statistics on how often end-users
> are likely to run into this crap?
I think it's much less likely than the ECN stuff, by a long shot.
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Daniel Phillips @ 2006-06-13 22:30 UTC (permalink / raw)
To: Chase Venters
Cc: Brian F. G. Bidulock, Stephen Hemminger, Sridhar Samudrala,
netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0606131655580.4856@turbotaz.ourhouse>
Chase Venters wrote:
> can you name some non-GPL non-proprietary modules we should be concerned
> about?
You probably meant "non-GPL-compatible non-proprietary". If so, then by
definition there are none.
Regards,
Daniel
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: Rick Jones @ 2006-06-13 22:40 UTC (permalink / raw)
To: David Miller; +Cc: lkml, jheffner, torvalds, linux-kernel, netdev
In-Reply-To: <20060613.152301.26928146.davem@davemloft.net>
> One final word about window sizes. If you have a connection whose
> bandwidth-delay-product needs an N byte buffer to fill, you actually
> have to have an "N * 2" sized buffer available in order for fast
> retransmit to work.
Is that as important in the presence of SACK?
rick jones
^ permalink raw reply
* Re: [PATCH 2.6.18 3/6] bnx2: Use CPU native page size
From: David Miller @ 2006-06-13 22:41 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1150222782.26368.34.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 13 Jun 2006 11:19:42 -0700
> Use CPU native page size to determine various ring sizes. This allows
> order-0 memory allocations on all systems.
>
> Added check to limit the page size to 16K since that's the maximum rx
> ring size that will be used. This will prevent using unnecessarily
> large page sizes on some architectures with large page sizes.
> [Suggested by David Miller]
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Looks great, applied.
^ permalink raw reply
* Re: [PATCH 1/2] AES-XCBC-MAC
From: Herbert Xu @ 2006-06-13 22:40 UTC (permalink / raw)
To: Kazunori MIYAZAWA; +Cc: David Miller, netdev, usagi-core
In-Reply-To: <1150213440.4200.36.camel@hookipa>
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
On Wed, Jun 14, 2006 at 12:44:00AM +0900, Kazunori MIYAZAWA wrote:
> This is preparation to introduce AES-XCBC-MAC.
> - introducing common interface "keyed hash"
> - making HMAC use the interface
I'm sorry guys, but this seems to duplicate what I've been doing as
generic parameterised algorithms. I wish we'd discussed this more
so time didn't had to be wasted.
I've attached a sample HMAC implementation. Things are still fluid
so it may not even compile (Actually, it definitely wouldn't compile
without the template stuff which I'll post soon :)
In any case, this is the model AES-XCBC-MAC should look like.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: hmac.patch --]
[-- Type: text/plain, Size: 8825 bytes --]
diff --git a/crypto/Kconfig b/crypto/Kconfig
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -18,7 +18,7 @@ config CRYPTO_MANAGER
cbc(aes).
config CRYPTO_HMAC
- bool "HMAC support"
+ tristate "HMAC support"
depends on CRYPTO
help
HMAC: Keyed-Hashing for Message Authentication (RFC2104).
diff --git a/crypto/Makefile b/crypto/Makefile
diff --git a/crypto/hmac.c b/crypto/hmac.c
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -4,6 +4,7 @@
* HMAC: Keyed-Hashing for Message Authentication (RFC2104).
*
* Copyright (c) 2002 James Morris <jmorris@intercode.com.au>
+ * Copyright (c) 2006 Herbert Xu <herbert@gondor.apana.org.au>
*
* The HMAC implementation is derived from USAGI.
* Copyright (c) 2002 Kazunori Miyazawa <miyazawa@linux-ipv6.org> / USAGI
@@ -21,84 +22,80 @@
#include <linux/scatterlist.h>
#include "internal.h"
-static void hash_key(struct crypto_tfm *tfm, u8 *key, unsigned int keylen)
-{
- struct scatterlist tmp;
-
- sg_set_buf(&tmp, key, keylen);
- crypto_digest_digest(tfm, &tmp, 1, key);
-}
-
-int crypto_alloc_hmac_block(struct crypto_tfm *tfm)
-{
- int ret = 0;
-
- BUG_ON(!crypto_tfm_alg_blocksize(tfm));
-
- tfm->crt_digest.dit_hmac_block = kmalloc(crypto_tfm_alg_blocksize(tfm),
- GFP_KERNEL);
- if (tfm->crt_digest.dit_hmac_block == NULL)
- ret = -ENOMEM;
+struct hmac_ctx {
+ struct crypto_tfm *child;
+};
+
+static void crypto_hmac_setkey(struct crypto_tfm *parent, u8 *inkey,
+ unsigned int keylen, u32 *flags)
+{
+ int bs = crypto_tfm_alg_blocksize(parent);
+ char *key = crypto_tfm_ctx(parent);
+ char *pad = ctx_arg + bs;
+ struct hmac_ctx *ctx = pad + bs;
+ struct crypto_tfm *tfm = ctx->child;
+
+ if (keylen > bs) {
+ struct scatterlist tmp;
+ sg_set_buf(&tmp, inkey, keylen);
+ crypto_digest_digest(child, &tmp, 1, pad);
+ inkey = pad;
+ keylen = crypto_tfm_alg_digestsize(tfm);
+ }
- return ret;
-
+ memcpy(key, inkey, keylen);
+ memset(key + keylen, 0, bs - keylen);
}
-void crypto_free_hmac_block(struct crypto_tfm *tfm)
-{
- kfree(tfm->crt_digest.dit_hmac_block);
-}
-
-void crypto_hmac_init(struct crypto_tfm *tfm, u8 *key, unsigned int *keylen)
+static void crypto_hmac_init(struct crypto_tfm *parent)
{
+ int bs = crypto_tfm_alg_blocksize(parent);
+ char *key = crypto_tfm_ctx(parent);
+ char *ipad = ctx_arg + bs;
+ struct hmac_ctx *ctx = ipad + bs;
+ struct crypto_tfm *tfm = ctx->child;
unsigned int i;
struct scatterlist tmp;
- char *ipad = tfm->crt_digest.dit_hmac_block;
-
- if (*keylen > crypto_tfm_alg_blocksize(tfm)) {
- hash_key(tfm, key, *keylen);
- *keylen = crypto_tfm_alg_digestsize(tfm);
- }
- memset(ipad, 0, crypto_tfm_alg_blocksize(tfm));
- memcpy(ipad, key, *keylen);
+ memcpy(ipad, key, bs);
- for (i = 0; i < crypto_tfm_alg_blocksize(tfm); i++)
+ for (i = 0; i < bs; i++)
ipad[i] ^= 0x36;
- sg_set_buf(&tmp, ipad, crypto_tfm_alg_blocksize(tfm));
+ sg_set_buf(&tmp, ipad, bs);
crypto_digest_init(tfm);
crypto_digest_update(tfm, &tmp, 1);
}
-void crypto_hmac_update(struct crypto_tfm *tfm,
- struct scatterlist *sg, unsigned int nsg)
+static void crypto_hmac_update(struct crypto_tfm *parent,
+ struct scatterlist *sg, unsigned int nsg)
{
+ int bs = crypto_tfm_alg_blocksize(parent);
+ struct hmac_ctx *ctx = crypto_tfm_ctx(parent) + bs * 2;
+ struct crypto_tfm *tfm = ctx->child;
crypto_digest_update(tfm, sg, nsg);
}
-void crypto_hmac_final(struct crypto_tfm *tfm, u8 *key,
- unsigned int *keylen, u8 *out)
+static void crypto_hmac_final(struct crypto_tfm *parent, u8 *key,
+ unsigned int *keylen, u8 *out)
{
+ int bs = crypto_tfm_alg_blocksize(parent);
+ char *key = crypto_tfm_ctx(parent);
+ char *opad = ctx_arg + bs;
+ struct hmac_ctx *ctx = opad + bs;
+ struct crypto_tfm *tfm = ctx->child;
unsigned int i;
struct scatterlist tmp;
- char *opad = tfm->crt_digest.dit_hmac_block;
- if (*keylen > crypto_tfm_alg_blocksize(tfm)) {
- hash_key(tfm, key, *keylen);
- *keylen = crypto_tfm_alg_digestsize(tfm);
- }
-
crypto_digest_final(tfm, out);
- memset(opad, 0, crypto_tfm_alg_blocksize(tfm));
- memcpy(opad, key, *keylen);
+ memcpy(opad, key, bs);
- for (i = 0; i < crypto_tfm_alg_blocksize(tfm); i++)
+ for (i = 0; i < bs; i++)
opad[i] ^= 0x5c;
- sg_set_buf(&tmp, opad, crypto_tfm_alg_blocksize(tfm));
+ sg_set_buf(&tmp, opad, bs);
crypto_digest_init(tfm);
crypto_digest_update(tfm, &tmp, 1);
@@ -109,16 +106,109 @@ void crypto_hmac_final(struct crypto_tfm
crypto_digest_final(tfm, out);
}
-void crypto_hmac(struct crypto_tfm *tfm, u8 *key, unsigned int *keylen,
- struct scatterlist *sg, unsigned int nsg, u8 *out)
+static int hmac_init_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_instance *inst = (void *)tfm->__crt_alg;
+ struct crypto_spawn **spawn = crypto_instance_param(inst);
+ struct hmac_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ ctx->child = crypto_spawn_tfm(*spawn, 0);
+ if (!ctx->child)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static struct crypto_instance *hmac_init_alg(void *param, unsigned int len)
+{
+ struct rtattr *rta = param;
+ struct crypto_attr_base *base;
+ struct crypto_attr_alg *alg;
+ struct crypto_instance *inst;
+ struct crypto_spawn *spawn;
+ struct crypto_spawn **inst_param;
+ int err;
+
+ if (!RTA_OK(rta, len))
+ return ERR_PTR(-EBADR);
+ if (rta->rta_type != CRYPTOA_BASE || RTA_PAYLOAD(rta) < sizeof(*base))
+ return ERR_PTR(-EINVAL);
+
+ base = RTA_DATA(rta);
+
+ rta = RTA_NEXT(rta, len);
+ if (!RTA_OK(rta, len))
+ return ERR_PTR(-EBADR);
+ if (rta->rta_type != CRYPTOA_ALG || RTA_PAYLOAD(rta) < sizeof(*alg))
+ return ERR_PTR(-EINVAL);
+
+ alg = RTA_DATA(rta);
+
+ inst = kzalloc(sizeof(*inst) + sizeof(spawn));
+ if (!inst)
+ return ERR_PTR(-ENOMEM);
+
+ spawn = crypto_alloc_spawn(alg->name);
+ if (IS_ERR(spawn)) {
+ err = PTR_ERR(spawn);
+ goto err_spawn;
+ }
+
+ strlcpy(inst->alg.cra_name, base->type.name, CRYPTO_MAX_ALG_NAME);
+ strlcpy(inst->alg.cra_driver_name, base->driver.name,
+ CRYPTO_MAX_ALG_NAME);
+
+ inst_param = crypto_instance_param(inst);
+ *inst_param = spawn;
+
+ inst->alg.cra_priority = base->priority;
+ inst->alg.cra_flags = CRYPTO_ALG_TYPE_DIGEST;
+ inst->alg.cra_blocksize = spawn->alg->cra_blocksize;
+
+ /* XXX Check alignment once we have drivers with alignmask > 16. */
+ inst->alg.cra_ctxsize = sizeof(struct hmac_ctx) +
+ inst->alg.cra_blocksize * 2;
+
+ inst->alg.cra_module = THIS_MODULE;
+ inst->alg.cra_init = hmac_init_tfm;
+
+ inst->alg.cra_u.digest.dia_init = crypto_hmac_init;
+ inst->alg.cra_u.digest.dia_update = crypto_hmac_update;
+ inst->alg.cra_u.digest.dia_final = crypto_hmac_final;
+ inst->alg.cra_u.digest.dia_setkey = crypto_hmac_setkey;
+ return inst;
+
+err_spawn:
+ kfree(inst);
+ return ERR_PTR(err);
+}
+
+static void hmac_destroy_alg(struct crypto_instance *inst)
+{
+ struct crypto_spawn **spawn = crypto_instance_param(inst);
+ crypto_free_spawn(*spawn);
+ kfree(inst);
+}
+
+static struct crypto_template hmac_tmpl = {
+ .name = "hmac",
+ .base_type = CRYPTO_ALG_TYPE_DIGEST,
+ .init = hmac_init_alg,
+ .destroy = hmac_destroy_alg,
+};
+
+static int __init hmac_init(void)
+{
+ return crypto_register_template(&hmac_tmpl);
+}
+
+static void __exit hmac_exit(void)
{
- crypto_hmac_init(tfm, key, keylen);
- crypto_hmac_update(tfm, sg, nsg);
- crypto_hmac_final(tfm, key, keylen, out);
+ crypto_unregister_template(&hmac_tmpl);
}
-EXPORT_SYMBOL_GPL(crypto_hmac_init);
-EXPORT_SYMBOL_GPL(crypto_hmac_update);
-EXPORT_SYMBOL_GPL(crypto_hmac_final);
-EXPORT_SYMBOL_GPL(crypto_hmac);
+module_init(hmac_init);
+module_exit(hmac_exit);
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("HMAC digest algorithm");
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -209,9 +209,6 @@ struct digest_tfm {
unsigned int nsg, u8 *out);
int (*dit_setkey)(struct crypto_tfm *tfm,
const u8 *key, unsigned int keylen);
-#ifdef CONFIG_CRYPTO_HMAC
- void *dit_hmac_block;
-#endif
};
struct compress_tfm {
@@ -452,18 +449,5 @@ static inline int crypto_comp_decompress
return tfm->crt_compress.cot_decompress(tfm, src, slen, dst, dlen);
}
-/*
- * HMAC support.
- */
-#ifdef CONFIG_CRYPTO_HMAC
-void crypto_hmac_init(struct crypto_tfm *tfm, u8 *key, unsigned int *keylen);
-void crypto_hmac_update(struct crypto_tfm *tfm,
- struct scatterlist *sg, unsigned int nsg);
-void crypto_hmac_final(struct crypto_tfm *tfm, u8 *key,
- unsigned int *keylen, u8 *out);
-void crypto_hmac(struct crypto_tfm *tfm, u8 *key, unsigned int *keylen,
- struct scatterlist *sg, unsigned int nsg, u8 *out);
-#endif /* CONFIG_CRYPTO_HMAC */
-
#endif /* _LINUX_CRYPTO_H */
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-13 22:44 UTC (permalink / raw)
To: Chase Venters
Cc: Daniel Phillips, Stephen Hemminger, Sridhar Samudrala, netdev,
linux-kernel
In-Reply-To: <Pine.LNX.4.64.0606131655580.4856@turbotaz.ourhouse>
Chase,
On Tue, 13 Jun 2006, Chase Venters wrote:
>
> Look out for that word (stable). Judging from history (and sanity),
> arguing /in favor of/ any kind of stable module API is asking for it.
I was really just using Daniel's words. I am all too aware that kernel
APIs are unstable. To some it is a serious failing of Linux
(particularly those involved in porting kernel modules from branded UNIX
or embedded RTOS). To those whatever stability that can be offered is a
boon. To those, even worse is the lack of an ABI (even for a single
kernel version).
>
> At least some of us feel like stable module APIs should be explicitly
> discouraged, because we don't want to offer comfort for code
> that refuses to live in the tree (since getting said code into the tree is
> often a goal).
And that would be fine if we were completely agnostic toward what was
included in mainline, but we are not. A particular case in point that
I deal with are STREAMS modules. STREAMS continues to be forbidden from
the tree. Nevertheless, STREAMS has historically provided one of the
most widespread mechanisms for providing value-added drivers to branded
UNIX or embedded RTOS offerings. As a result, a large body of existing
drivers are cut off from the tree regardless of their licensing terms.
(Note that these is seldom a question of derivation for these drivers as
they are fully functioning on other operating systems: branded UNIX or
embedded RTOS.)
>
> I'm curious now too - can you name some non-GPL non-proprietary modules we
> should be concerned about? I'd think most of the possible examples (not
> sure what they are) would be better off dual-licensed (one license
> being GPL) and in-kernel.
Any open-source license not compatible with the GPL. One that comes to
mind is OpenSolaris drivers. I'm sure that there are others because there
are many license that qualify as open source licenses that are incompatible
with the GPL. For example, pure BSD is incompatible with GPL.
Another thing to consider is that the first step for many organizations in
opening a driver under GPL is to release a proprietary module that at least
first works. The second step is to jump through the hoops and over the
hurdles necessary to open what has been to date proprietary code that may
contain intellectual property issues across a number of organizations.
In adopting a policy that hinders this process, we, instead, discourage
opening of drivers and inclusion in mainline, rather than promoting it.
Sorry for the rant.
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-13 22:47 UTC (permalink / raw)
To: Daniel Phillips
Cc: Chase Venters, Stephen Hemminger, Sridhar Samudrala, netdev,
linux-kernel
In-Reply-To: <448F3C83.9080606@google.com>
Daniel,
On Tue, 13 Jun 2006, Daniel Phillips wrote:
>
> You probably meant "non-GPL-compatible non-proprietary". If so, then by
> definition there are none.
Well, being GPL compatible is not a requirement for an open source license.
IANAL, but last I checked, pure-BSD is not compatible with GPL (it actually
has to be dual-licensed BSD/GPL).
^ permalink raw reply
* [PATCH] DM9000 - better checks for platform resources
From: Ben Dooks @ 2006-06-13 22:47 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
The current DM9000 driver cannot cope if it
is given more than 3 resources (for example, if
it is being passed an wake-up irq that it is
not using yet).
Check that we have been given at-least one IRQ
resource.
Also fix the minor type-casting for the case
of 2 resources.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[-- Attachment #2: dm9k-resource-clean.patch --]
[-- Type: text/plain, Size: 1442 bytes --]
--- ../linux-2.6.17/linux-2.6.17-rc5/drivers/net/dm9000.c 2006-03-20 05:53:29.000000000 +0000
+++ linux-2.6.16-simtec2/drivers/net/dm9000.c 2006-05-22 21:46:18.000000000 +0100
@@ -410,10 +410,7 @@ dm9000_probe(struct platform_device *pde
if (pdev->num_resources < 2) {
ret = -ENODEV;
goto out;
- }
-
- switch (pdev->num_resources) {
- case 2:
+ } else if (pdev->num_resources == 2) {
base = pdev->resource[0].start;
if (!request_mem_region(base, 4, ndev->name)) {
@@ -423,17 +420,16 @@ dm9000_probe(struct platform_device *pde
ndev->base_addr = base;
ndev->irq = pdev->resource[1].start;
- db->io_addr = (void *)base;
- db->io_data = (void *)(base + 4);
-
- break;
+ db->io_addr = (void __iomem *)base;
+ db->io_data = (void __iomem *)(base + 4);
- case 3:
+ } else {
db->addr_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
db->data_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
db->irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (db->addr_res == NULL || db->data_res == NULL) {
+ if (db->addr_res == NULL || db->data_res == NULL ||
+ db->irq_res == NULL) {
printk(KERN_ERR PFX "insufficient resources\n");
ret = -ENOENT;
goto out;
@@ -482,7 +478,6 @@ dm9000_probe(struct platform_device *pde
/* ensure at least we have a default set of IO routines */
dm9000_set_io(db, iosize);
-
}
/* check to see if anything is being over-ridden */
^ permalink raw reply
* [PATCH] DM9000 - check for MAC left in by bootloader
From: Ben Dooks @ 2006-06-13 22:50 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
The DM9000 driver does not deal with the case
where there is no serial EEPROM to store the
configuration, and the bootloader has placed
an MAC address into the device already.
If there is no valid MAC in the EEPROM, read
the one already in the chip and check to see
if that one is valid.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[-- Attachment #2: dm9k-no-valid-eeprom.patch --]
[-- Type: text/plain, Size: 606 bytes --]
--- ../linux-2.6.17/linux-2.6.17-rc5/drivers/net/dm9000.c 2006-03-20 05:53:29.000000000 +0000
+++ linux-2.6.16-simtec2/drivers/net/dm9000.c 2006-05-22 21:46:18.000000000 +0100
@@ -564,6 +559,13 @@ dm9000_probe(struct platform_device *pde
for (i = 0; i < 6; i++)
ndev->dev_addr[i] = db->srom[i];
+ if (!is_valid_ether_addr(ndev->dev_addr)) {
+ /* try reading from mac */
+
+ for (i = 0; i < 6; i++)
+ ndev->dev_addr[i] = ior(db, i+DM9000_PAR);
+ }
+
if (!is_valid_ether_addr(ndev->dev_addr))
printk("%s: Invalid ethernet MAC address. Please "
"set using ifconfig\n", ndev->name);
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: David Miller @ 2006-06-13 23:01 UTC (permalink / raw)
To: rick.jones2; +Cc: lkml, jheffner, torvalds, linux-kernel, netdev
In-Reply-To: <448F3EF5.50701@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 13 Jun 2006 15:40:53 -0700
> > One final word about window sizes. If you have a connection whose
> > bandwidth-delay-product needs an N byte buffer to fill, you actually
> > have to have an "N * 2" sized buffer available in order for fast
> > retransmit to work.
>
> Is that as important in the presence of SACK?
The consern is identical, SACK or not.
The only difference SACK introduces for fast retransmit is that we
know with more certainty which holes need to be filled and thus which
packets to fast retransmit.
^ permalink raw reply
* [PATCH] DM9000 - do no re-init spin lock
From: Ben Dooks @ 2006-06-13 23:05 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
The DM9000 initialisation sequence for the
hardware re-initialise the board spin-lock,
which is in my view wrong.
This patch removes the extra spin lock
initialisation
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[-- Attachment #2: dm9k-no-spinlock-reinit.patch --]
[-- Type: text/plain, Size: 346 bytes --]
--- ../linux-2.6.17/linux-2.6.17-rc5/drivers/net/dm9000.c 2006-03-20 05:53:29.000000000 +0000
+++ linux-2.6.16-simtec2/drivers/net/dm9000.c 2006-05-22 21:46:18.000000000 +0100
@@ -663,7 +665,6 @@ dm9000_init_dm9000(struct net_device *de
db->tx_pkt_cnt = 0;
db->queue_pkt_len = 0;
dev->trans_start = 0;
- spin_lock_init(&db->lock);
}
/*
^ permalink raw reply
* [PATCH] DM9000 - minor code cleanups
From: Ben Dooks @ 2006-06-13 23:09 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 242 bytes --]
Ensure the driver's module owner field is
initialised for when this is being built and
loaded as a module.
Also change make the dm9000_tx_done function
static, as it is not exported elsewhere.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[-- Attachment #2: dm9k-minor-cleanups.patch --]
[-- Type: text/plain, Size: 824 bytes --]
--- ../linux-2.6.17/linux-2.6.17-rc5/drivers/net/dm9000.c 2006-03-20 05:53:29.000000000 +0000
+++ linux-2.6.16-simtec2/drivers/net/dm9000.c 2006-05-22 21:46:18.000000000 +0100
@@ -767,7 +768,7 @@ dm9000_stop(struct net_device *ndev)
* receive the packet to upper layer, free the transmitted packet
*/
-void
+static void
dm9000_tx_done(struct net_device *dev, board_info_t * db)
{
int tx_status = ior(db, DM9000_NSR); /* Got TX status */
@@ -1187,13 +1188,14 @@ dm9000_drv_remove(struct platform_device
}
static struct platform_driver dm9000_driver = {
+ .driver = {
+ .name = "dm9000",
+ .owner = THIS_MODULE,
+ },
.probe = dm9000_probe,
.remove = dm9000_drv_remove,
.suspend = dm9000_drv_suspend,
.resume = dm9000_drv_resume,
- .driver = {
- .name = "dm9000",
- },
};
static int __init
^ permalink raw reply
* RE: [PATCH] s2io: netpoll support
From: Ravinandan Arakali @ 2006-06-13 23:33 UTC (permalink / raw)
To: 'Brian Haley', netdev
Cc: jgarzik, Ananda. Raju (E-mail), Leonid. Grossman (E-mail)
In-Reply-To: <448849F6.8050002@hp.com>
I don't think we should disable and enable all interrupts in the
poll_controller entry point. With the current patch, at the end of
the routine _all_ interrupts get enabled which is not desirable.
Maybe you should just do disable_irq() at start of function and
enable_irq() before exiting, the way some of the other drivers do.
Ravi
-----Original Message-----
From: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org]On Behalf Of Brian Haley
Sent: Thursday, June 08, 2006 9:02 AM
To: netdev@vger.kernel.org
Cc: jgarzik@pobox.com
Subject: [PATCH] s2io: netpoll support
This adds netpoll support for things like netconsole/kgdboe to the s2io
10GbE driver.
This duplicates some code from s2io_poll() as I wanted to be
least-invasive, someone from Neterion might have other thoughts?
Signed-off-by: Brian Haley <brian.haley@hp.com>
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: Matt Mackall @ 2006-06-13 23:22 UTC (permalink / raw)
To: Mark Lord; +Cc: David Miller, jheffner, torvalds, linux-kernel, netdev
In-Reply-To: <448F32E1.8080002@rtr.ca>
On Tue, Jun 13, 2006 at 05:49:21PM -0400, Mark Lord wrote:
>
>
> David Miller wrote:
> >..
> >First, you are getting window scaling by default with the older
> >kernel too. It's just a smaller window scale, using a shift
> >value of say 1 or 2.
> >
> >What these broken middle boxes do is ignore the window scale
> >entirely.
> >
> >So they don't apply a window scale to the advertised windows in each
> >packet. Therefore, they think a smaller amount of window space is
> >being advertised than really is. So they will silently drop packets
> >they think is outside of this bogus window they've calculated.
> >
> >Now, when the window scale is smaller, the connection can still limp
> >along, albeit slowly, making forward progress even in the face of such
> >broken devices because half or a quarter of the window is still
> >available. It will retransmit a lot, and the congestion window won't
> >grow at all.
> >
> >When the window scale is larger, this middle box bug makes it such
> >that not even one packet can fit into the miscalculated window and
> >things wedge. The box thinks that your window is "94" instead of
> >"94 << WINDOW_SCALE".
> ..
>
> Unilaterally following the standard is all well and good
> for those who know how to get around it when a site becomes
> inaccessible, but not for Joe User.
We had very similar issues with ECN. But unlike ECN, window scaling is
not something we can just shrug our shoulders and say "oh well" about.
We will have to deal with it eventually. It might as well be sooner.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox