* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-14 0:18 UTC (permalink / raw)
To: Chase Venters
Cc: Ben Greear, Daniel Phillips, Stephen Hemminger, Sridhar Samudrala,
netdev, linux-kernel
In-Reply-To: <200606131906.16683.chase.venters@clientec.com>
Chase,
On Tue, 13 Jun 2006, Chase Venters wrote:
> I'm trying to imagine what kind of legitimate non-GPL modules might
> use them.
Example: in-kernel RTP implementation derived from AT&T rtp-lib
implementation (non-GPL compatible license) utilizing this kernel
interface for UDP socket access.
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Valerie Henson @ 2006-06-14 0:06 UTC (permalink / raw)
To: Grant Grundler; +Cc: Jeff Garzik, Andrew Morton, netdev
In-Reply-To: <20060613235531.GA4191@colo.lackof.org>
On Tue, Jun 13, 2006 at 05:55:31PM -0600, Grant Grundler wrote:
> On Thu, Jun 08, 2006 at 11:01:20AM -0600, Grant Grundler wrote:
> > Here is a new patch that moves free_irq() into tulip_down().
> > The resulting code is structured the same as cp_close().
>
> Val,
> Two details are wrong in version 2 and are fixed in v3 (appended below):
>
> o we don't need synchronize_irq() before calling free_irq().
> (It should be removed from cp_close() too)
> Thanks to willy for pointing me at kernel/irq/manage.c.
>
> o tulip_stop_rxtx() has to be called _after_ free_irq().
> ie. v2 patch didn't fix the original race condition
> and when under test, dies about as fast as the original code.
>
> Tested on rx4640 (HP IA64) for several hours.
> Please apply.
Thanks, I'll take a look next week (after the workshop and moving).
-VAL
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Chase Venters @ 2006-06-14 0:05 UTC (permalink / raw)
To: Ben Greear
Cc: Brian F. G. Bidulock, Daniel Phillips, Stephen Hemminger,
Sridhar Samudrala, netdev, linux-kernel
In-Reply-To: <448F4D6F.9070601@candelatech.com>
On Tuesday 13 June 2006 18:42, Ben Greear wrote:
> Chase Venters wrote:
> > 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).
>
> Some of us write modules for specific features that are not wanted in
> the mainline kernel, even though they are pure GPL. Our life is hard
> enough with out people setting out to deliberately make things more
> difficult!
Fair enough, but if you are doing out of tree, pure GPL modules,
EXPORT_SYMBOL_GPL() isn't a bad thing, is it?
Don't mistake me for actually having a big opinion specifically about this
socket API's usage of EXPORT_SYMBOL()... just raising some points that I
think apply to these decisions in general. I don't really see a compelling
reason for EXPORT_SYMBOL() over EXPORT_SYMBOL_GPL() on the socket APIs
though... I'm trying to imagine what kind of legitimate non-GPL modules might
use them.
> Ben
Thanks,
Chase
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Chase Venters @ 2006-06-13 23:59 UTC (permalink / raw)
To: bidulock
Cc: Daniel Phillips, Stephen Hemminger, Sridhar Samudrala, netdev,
linux-kernel
In-Reply-To: <20060613164714.B7232@openss7.org>
On Tuesday 13 June 2006 17:46, Brian F. G. Bidulock wrote:
> 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).
It depends on what you mean by "pure-BSD". If you're talking about the
4-clause license with the advertising clause, then you are correct. Otherwise
(IANAL) but my understanding is that BSD code can even be relicensed GPL by a
third party contribution (though it is perhaps kind to ask for relicensing
permission anyway).
From your other message:
> 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).
Then would offering a 'stable API in disguise' not be a disaster and an
irritation to these people? If the kernel doesn't specify that an in-kernel
interface is stable, then there is no reason to expect it to be. It might not
change, but there won't be too much sympathy for out-of-tree users if it
does. The kernel comes with big warnings about the lack of a stable API for a
reason.
> 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.
If the driver is an old-tech Linux port, then it seems there isn't too much
stopping them from doing this today (aside from the fact that some people
think proprietary modules are murky anyway). In this case, we don't want a
stable API/ABI, because then we leave them with little incentive to open the
code.
And if the driver is new code, they're better off doing an open driver from
the start (especially since writing a driver _for_ Linux, as opposed to
porting one, might make it count as 'derived' and hence unlawful unless
released GPL).
> Sorry for the rant.
We're not as perfect as I wish we were. But the lack of stable API (dead
horse) is something that is fairly well established and understood. I think
most people feel that the cost-benefit analysis, for Linux anyway, strongly
favors no stable API.
Thanks,
Chase
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-13 23:55 UTC (permalink / raw)
To: Valerie Henson; +Cc: Jeff Garzik, Andrew Morton, netdev
In-Reply-To: <20060608170120.GI8246@colo.lackof.org>
On Thu, Jun 08, 2006 at 11:01:20AM -0600, Grant Grundler wrote:
> Here is a new patch that moves free_irq() into tulip_down().
> The resulting code is structured the same as cp_close().
Val,
Two details are wrong in version 2 and are fixed in v3 (appended below):
o we don't need synchronize_irq() before calling free_irq().
(It should be removed from cp_close() too)
Thanks to willy for pointing me at kernel/irq/manage.c.
o tulip_stop_rxtx() has to be called _after_ free_irq().
ie. v2 patch didn't fix the original race condition
and when under test, dies about as fast as the original code.
Tested on rx4640 (HP IA64) for several hours.
Please apply.
thanks,
grant
Change Log:
IRQs are racing with tulip_down(). DMA can be restarted _after_
we call tulip_stop_rxtx() and the DMA buffers are unmapped.
The result is an MCA (hard crash on ia64) because of an
IO TLB miss.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -18,11 +18,11 @@
#define DRV_NAME "tulip"
#ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION "1.1.13-NAPI" /* Keep at least for test */
+#define DRV_VERSION "1.1.14-NAPI" /* Keep at least for test */
#else
-#define DRV_VERSION "1.1.13"
+#define DRV_VERSION "1.1.14"
#endif
-#define DRV_RELDATE "December 15, 2004"
+#define DRV_RELDATE "May 6, 2006"
#include <linux/module.h>
@@ -741,21 +741,20 @@ static void tulip_down (struct net_devic
/* Disable interrupts by clearing the interrupt mask. */
iowrite32 (0x00000000, ioaddr + CSR7);
+ ioread32 (ioaddr + CSR7); /* flush posted write */
- /* Stop the Tx and Rx processes. */
- tulip_stop_rxtx(tp);
+ spin_unlock_irqrestore (&tp->lock, flags);
- /* prepare receive buffers */
- tulip_refill_rx(dev);
+ free_irq (dev->irq, dev); /* no more races after this */
+ tulip_stop_rxtx(tp); /* Stop DMA */
- /* release any unconsumed transmit buffers */
- tulip_clean_tx_ring(tp);
+ /* Put driver back into the state we start with */
+ tulip_refill_rx(dev); /* prepare RX buffers */
+ tulip_clean_tx_ring(tp); /* clean up unsent TX buffers */
if (ioread32 (ioaddr + CSR6) != 0xffffffff)
tp->stats.rx_missed_errors += ioread32 (ioaddr + CSR8) & 0xffff;
- spin_unlock_irqrestore (&tp->lock, flags);
-
init_timer(&tp->timer);
tp->timer.data = (unsigned long)dev;
tp->timer.function = tulip_tbl[tp->chip_id].media_timer;
@@ -774,7 +773,6 @@ static int tulip_close (struct net_devic
printk (KERN_DEBUG "%s: Shutting down ethercard, status was %2.2x.\n",
dev->name, ioread32 (ioaddr + CSR5));
- free_irq (dev->irq, dev);
/* Free all the skbuffs in the Rx queue. */
for (i = 0; i < RX_RING_SIZE; i++) {
@@ -1752,7 +1752,6 @@ static int tulip_suspend (struct pci_dev
tulip_down(dev);
netif_device_detach(dev);
- free_irq(dev->irq, dev);
pci_save_state(pdev);
pci_disable_device(pdev);
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Ben Greear @ 2006-06-13 23:42 UTC (permalink / raw)
To: Chase Venters
Cc: Brian F. G. Bidulock, Daniel Phillips, Stephen Hemminger,
Sridhar Samudrala, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0606131655580.4856@turbotaz.ourhouse>
Chase Venters wrote:
> 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).
Some of us write modules for specific features that are not wanted in
the mainline kernel, even though they are pure GPL. Our life is hard
enough with out people setting out to deliberately make things more
difficult!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.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
* 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
* [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
* [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
* 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 - 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
* [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
* 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
* 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: [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: [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: 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: [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: 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: 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: [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: 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: 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: [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
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