* Re: [PATCH 4/4] udp: memory accounting in IPv4
From: Herbert Xu @ 2007-12-10 9:22 UTC (permalink / raw)
To: Hideo AOKI
Cc: netdev, David Miller, Eric Dumazet, Satoshi Oshima, Bill Fink,
Andi Kleen, Evgeniy Polyakov, Stephen Hemminger, yoshfuji,
Yumiko Sugita
In-Reply-To: <47577A72.10205@redhat.com>
On Wed, Dec 05, 2007 at 11:28:34PM -0500, Hideo AOKI wrote:
>
> 1. Using sk_forward_alloc and adding socket lock
>
> UDP already uses a socket lock to send message. However, it doesn't
> use the lock to receive message. I wonder if we can also use the
> lock when sk_forward_alloc is updated in receive processing.
> I understand performance issue might occur, but ...
Having discussed this with Dave we've agreed that this is the
best way to go.
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
^ permalink raw reply
* Re: [PATCH 3/3] Fix use of skb after netif_rx
From: Wang Chen @ 2007-12-10 7:35 UTC (permalink / raw)
To: Julia Lawall; +Cc: fpavlic, linux-kernel, kernel-janitors, Jeff Garzik, netdev
In-Reply-To: <Pine.LNX.4.64.0712100813440.13319@ask.diku.dk>
Julia Lawall said the following on 2007-12-10 15:18:
>> Julia, seems that your semantic patch misses following place.
>>
>> drivers/s390/net/qeth_main.c:2733
>> ...
>> #endif
>> rxrc = netif_rx(skb);
>> card->dev->last_rx = jiffies;
>> card->stats.rx_packets++;
>> card->stats.rx_bytes += skb->len;
>> ...
>
> Actually, I found this one as well, but I wasn't sure what to do with it.
> This one is a bit more complicated because the line with the call to
> netif_rx is in an else branch if the #ifdef above is taken. So I wasn't
> sure what would be the best way to solve the problem in this case.
>
> Perhaps the solution would be just to save the value of the len field
> in a local variable in this case, as you proposed in your original patch.
>
I agree.
BTW, please send driver patch to Jeff Garzik <jgarzik@pobox.com> and
cc to netdev@vger.kernel.org.
--
WCN
^ permalink raw reply
* Re: all is not right with the world...
From: David Miller @ 2007-12-10 6:20 UTC (permalink / raw)
To: dlstevens; +Cc: yoshfuji, netdev
In-Reply-To: <OFED01B00C.3B84EA11-ON882573AD.0001073B-882573AD.0001C3EC@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Sun, 9 Dec 2007 16:19:12 -0800
> I don't know if you've fixed it already, but I was writing some
> UDPv6 tests in 2.6.23.9 and was getting EDESTADDRREQ unexpectedly. When
> I looked at the kernel code, I found:
>
> gerrit/wscott 1.115 | int udpv6_sendmsg(struct kiocb *iocb,
> struct sock *sk,
> shemminger 1.57 | struct
> msghdr *msg, size_t len)
> torvalds 1.1 | {
> ...
>
> yoshfuji 1.53 | } else if (!up->pending)
> {
> yoshfuji 1.53 | if
> (sk->sk_state != TCP_ESTABLISHED)
> yoshfuji 1.53 | return -EDESTADDRREQ;
> yoshfuji 1.53 | daddr =
> &np->daddr;
>
> I wouldn't expect a UDP socket to be setting
> sk_state to TCP_ESTABLISHED...
It does when you connect() it.
UDP reuses the TCP state values out of convenience.
^ permalink raw reply
* Re: IPsec replay sequence number overflow behavior? (RFC4303 section 3.3.3)
From: Herbert Xu @ 2007-12-10 3:43 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Paul Moore, netdev, latten
In-Reply-To: <475CAF94.7020306@trash.net>
On Mon, Dec 10, 2007 at 04:16:36AM +0100, Patrick McHardy wrote:
>
> Won't this break with manually installed SAs (without a keying
> daemon)?
Well what's being suggested here will already break that anyway :)
Alternatively we can take the interpretation that it's the KM's
responsibility to set the appropriate hard life time if ESNs are
not in use.
Either way is fine with me.
Cheers,
--
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
^ permalink raw reply
* Re: IPsec replay sequence number overflow behavior? (RFC4303 section 3.3.3)
From: Patrick McHardy @ 2007-12-10 3:16 UTC (permalink / raw)
To: Herbert Xu; +Cc: Paul Moore, netdev, latten
In-Reply-To: <20071210030653.GA31566@gondor.apana.org.au>
Herbert Xu wrote:
> On Sun, Dec 09, 2007 at 09:37:56AM -0500, Paul Moore wrote:
>
>> Thanks for clearing that up, I'll send a patch this week; complete with an
>> unlikely (similar to the RFC quality IPsec audit patch I sent on Friday) and
>> a decrement to the sequence counter in case of rollover.
>>
>
> Actually I think we should just use the SA expire mechanism
> to do this. The reason is that the overflow we want to detect
> only applies to 32-bit sequence numbers. In future we will be
> making our sequence numbers 64-bit.
>
> When we do that we can no longer just check against wrapping
> to zero since we need to know whether ESNs are in use or not.
>
> The easiest fix is to just force the hard_packet_limit to 2^32.
> upon SA creation.
Won't this break with manually installed SAs (without a keying
daemon)?
^ permalink raw reply
* Re: IPsec replay sequence number overflow behavior? (RFC4303 section 3.3.3)
From: Herbert Xu @ 2007-12-10 3:06 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, latten
In-Reply-To: <200712090937.56599.paul.moore@hp.com>
On Sun, Dec 09, 2007 at 09:37:56AM -0500, Paul Moore wrote:
>
> Thanks for clearing that up, I'll send a patch this week; complete with an
> unlikely (similar to the RFC quality IPsec audit patch I sent on Friday) and
> a decrement to the sequence counter in case of rollover.
Actually I think we should just use the SA expire mechanism
to do this. The reason is that the overflow we want to detect
only applies to 32-bit sequence numbers. In future we will be
making our sequence numbers 64-bit.
When we do that we can no longer just check against wrapping
to zero since we need to know whether ESNs are in use or not.
The easiest fix is to just force the hard_packet_limit to 2^32.
upon SA creation.
Cheers,
--
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
^ permalink raw reply
* Re: all is not right with the world...
From: David Stevens @ 2007-12-10 1:52 UTC (permalink / raw)
To: David Stevens; +Cc: davem, netdev, netdev-owner, yoshfuji
In-Reply-To: <OFED01B00C.3B84EA11-ON882573AD.0001073B-882573AD.0001C3EC@us.ibm.com>
Never mind...
Though I hate the "TCP" in the name (maybe overload UDP_CONNECTED?), I see
datagram
sockets are in fact setting it, and my EDESTADDRREQ was a bug in my test
program. :-)
+-DLS
netdev-owner@vger.kernel.org wrote on 12/09/2007 04:19:12 PM:
> I don't know if you've fixed it already, but I was writing some
> UDPv6 tests in 2.6.23.9 and was getting EDESTADDRREQ unexpectedly. When
> I looked at the kernel code, I found:
>
> gerrit/wscott 1.115 | int udpv6_sendmsg(struct kiocb *iocb,
> struct sock *sk,
> shemminger 1.57 | struct
> msghdr *msg, size_t len)
> torvalds 1.1 | {
> ...
>
> yoshfuji 1.53 | } else if
(!up->pending)
> {
> yoshfuji 1.53 | if
> (sk->sk_state != TCP_ESTABLISHED)
> yoshfuji 1.53 | return -EDESTADDRREQ;
> yoshfuji 1.53 | daddr =
> &np->daddr;
>
> I wouldn't expect a UDP socket to be setting
> sk_state to TCP_ESTABLISHED...
>
> +-DLS
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* all is not right with the world...
From: David Stevens @ 2007-12-10 0:19 UTC (permalink / raw)
To: yoshfuji, davem; +Cc: netdev
I don't know if you've fixed it already, but I was writing some
UDPv6 tests in 2.6.23.9 and was getting EDESTADDRREQ unexpectedly. When
I looked at the kernel code, I found:
gerrit/wscott 1.115 | int udpv6_sendmsg(struct kiocb *iocb,
struct sock *sk,
shemminger 1.57 | struct
msghdr *msg, size_t len)
torvalds 1.1 | {
...
yoshfuji 1.53 | } else if (!up->pending)
{
yoshfuji 1.53 | if
(sk->sk_state != TCP_ESTABLISHED)
yoshfuji 1.53 | return -EDESTADDRREQ;
yoshfuji 1.53 | daddr =
&np->daddr;
I wouldn't expect a UDP socket to be setting
sk_state to TCP_ESTABLISHED...
+-DLS
^ permalink raw reply
* Re: SIS190 Ethernet Driver check for ISA bridge on "SiS968" MotherBoards...
From: Francois Romieu @ 2007-12-09 22:20 UTC (permalink / raw)
To: Arliton Rocha; +Cc: netdev, J. Gleacher, Alexandre Penasso Teixeira
In-Reply-To: <acbb94d60712090816k72f72ab9m4d46665e7a6823c@mail.gmail.com>
Arliton Rocha <arliton@gmail.com> :
[...]
> Please, can you made sis190 ethernet driver check for isa bridge on
> "sis968" motherboards?
> SiS(R) 191 Gigabit Ethernet
>
> Similar
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8eb7ad68bd10d858066ca51713ca5645996e77a5
[...]
> It's Work!
I'd rather avoid the code duplication. Does the patch below do the
work ?
Can you send the output of a 'lspci -vvvxxxx' + 'mii-diag -v' and the brand
name of the motherboard ? Apparently all 968 based devices do not behave the
same (see http://bugzilla.kernel.org/show_bug.cgi?id=9386 for instance).
>From 38c4947eb946db4b5daea0fb37c1ca515ab803d6 Mon Sep 17 00:00:00 2001
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Tue, 4 Dec 2007 22:58:41 +0100
Subject: [PATCH] sis190: add cmos ram access code for the SiS19x/968 chipset pair
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: J. Gleacher <jgleacher@yahoo.com>
Cc: Alexandre Penasso Teixeira <alexandre@keepsoftware.com>
---
drivers/net/sis190.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index b644bc4..ad392c2 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -1582,28 +1582,31 @@ static int __devinit sis190_get_mac_addr_from_eeprom(struct pci_dev *pdev,
}
/**
- * sis190_get_mac_addr_from_apc - Get MAC address for SiS965 model
+ * sis190_get_mac_addr_from_apc - Get MAC address for SiS96x model
* @pdev: PCI device
* @dev: network device to get address for
*
- * SiS965 model, use APC CMOS RAM to store MAC address.
+ * SiS96x model, use APC CMOS RAM to store MAC address.
* APC CMOS RAM is accessed through ISA bridge.
* MAC address is read into @net_dev->dev_addr.
*/
static int __devinit sis190_get_mac_addr_from_apc(struct pci_dev *pdev,
struct net_device *dev)
{
+ static const u16 __devinitdata ids[] = { 0x0965, 0x0966, 0x0968 };
struct sis190_private *tp = netdev_priv(dev);
struct pci_dev *isa_bridge;
u8 reg, tmp8;
- int i;
+ unsigned int i;
net_probe(tp, KERN_INFO "%s: Read MAC address from APC.\n",
pci_name(pdev));
- isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0965, NULL);
- if (!isa_bridge)
- isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0966, NULL);
+ for (i = 0; i < ARRAY_SIZE(ids); i++) {
+ isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, ids[i], NULL);
+ if (isa_bridge)
+ break;
+ }
if (!isa_bridge) {
net_probe(tp, KERN_INFO "%s: Can not find ISA bridge.\n",
--
1.5.3.3
^ permalink raw reply related
* Re: tcp assertion failures in 2.6.24-rc4-mm1
From: Ilpo Järvinen @ 2007-12-09 21:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: Netdev
In-Reply-To: <20071209002357.e6d081e8.akpm@linux-foundation.org>
On Sun, 9 Dec 2007, Andrew Morton wrote:
>
> This is a mac g5. It is being used as a distcc server across the LAN
> when...
>
> windfarm: CPUs control loops started.
> EXT3-fs: INFO: recovery required on readonly filesystem.
> EXT3-fs: write access will be enabled during recovery.
> kjournald starting. Commit interval 5 seconds
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.
> audit(1197190525.100:2): audit_pid=1989 old=0 by auid=4294967295
> KERNEL: assertion (packets <= tp->packets_out) failed at net/ipv4/tcp_input.c (2136)
> KERNEL: assertion (packets <= tp->packets_out) failed at net/ipv4/tcp_input.c (2136)
> ------------[ cut here ]------------
> Badness at net/ipv4/tcp_input.c:2518
> NIP: c0000000003d46a4 LR: c0000000003d4d84 CTR: c000000000408914
> REGS: c000000177b770e0 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
> MSR: 9000000000029032 <EE,ME,IR,DR> CR: 24002488 XER: 00000000
> TASK = c000000178868540[8316] 'cc1' THREAD: c000000177b74000 CPU: 1
> NIP [c0000000003d46a4] .tcp_ack+0xd5c/0x1ce8
> LR [c0000000003d4d84] .tcp_ack+0x143c/0x1ce8
> Call Trace:
> [c000000177b77360] [c0000000003d4d84] .tcp_ack+0x143c/0x1ce8 (unreliable)
> [c000000177b77530] [c0000000003d81ac] .tcp_rcv_established+0x2fc/0x8d4
> [c000000177b775e0] [c0000000003e2818] .tcp_v4_do_rcv+0x1fc/0x580
> [c000000177b776d0] [c0000000003e37e0] .tcp_v4_rcv+0xc44/0xd28
> [c000000177b777e0] [c0000000003bd398] .ip_local_deliver+0xb4/0x2cc
> [c000000177b77870] [c0000000003bd87c] .ip_rcv+0x2cc/0x6f0
> [c000000177b77930] [c000000000396444] .netif_receive_skb+0x440/0x4bc
> [c000000177b779f0] [c00000000028255c] .tg3_poll+0x71c/0xb78
> [c000000177b77b30] [c000000000396888] .net_rx_action+0x1e4/0x26c
> [c000000177b77be0] [c000000000069584] .__do_softirq+0xd8/0x190
> [c000000177b77ca0] [c00000000000b95c] .do_softirq+0x94/0x9c
> [c000000177b77d30] [c0000000000696f0] .irq_exit+0x70/0x88
> [c000000177b77db0] [c00000000000b83c] .do_IRQ+0xa0/0x12c
> [c000000177b77e30] [c000000000004790] hardware_interrupt_entry+0x18/0x1c
> Instruction dump:
> 7d7a5b78 3b200000 409e0008 933b0584 811b0584 39200000 2fa80000 409e0018
> 801b0588 2f800000 419e000c 39200001 <0fe00000> 2fa90000 409e0d60 72b40040
> KERNEL: assertion (packets <= tp->packets_out) failed at net/ipv4/tcp_input.c (2136)
> ------------[ cut here ]------------
>
> It's done that three times so far.
This as well is due to fack_count miscount. I found one corrupter already
and will send a patch tomorrow (not sure if fixing that resolves also this
issue).
--
i.
^ permalink raw reply
* [PATCH 3/3][BNX2]: Update version to 1.6.9.
From: Michael Chan @ 2007-12-09 21:18 UTC (permalink / raw)
To: davem; +Cc: netdev
[BNX2]: Update version to 1.6.9.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index f9eea6e..4e7b46e 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -56,8 +56,8 @@
#define DRV_MODULE_NAME "bnx2"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "1.6.8"
-#define DRV_MODULE_RELDATE "October 17, 2007"
+#define DRV_MODULE_VERSION "1.6.9"
+#define DRV_MODULE_RELDATE "December 8, 2007"
#define RUN_AT(x) (jiffies + (x))
^ permalink raw reply related
* [PATCH 2/3][BNX2]: Fix RX packet rot.
From: Michael Chan @ 2007-12-09 21:17 UTC (permalink / raw)
To: davem; +Cc: netdev
[BNX2]: Fix RX packet rot.
Packets can be left in the RX ring if the NAPI budget is reached.
This is caused by storing the latest rx index at the beginning of
bnx2_rx_int(). We may not process all the work up to this index
if the budget is reached and so some packets in the RX ring may rot
when we later check for more work using this stored rx index.
The fix is to not store this latest hw index and only store the
processed rx index. We use a new function bnx2_get_hw_rx_cons()
to fetch the latest hw rx index.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index a4f3832..f9eea6e 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -2387,18 +2387,24 @@ bnx2_reuse_rx_skb(struct bnx2 *bp, struct sk_buff *skb,
prod_bd->rx_bd_haddr_lo = cons_bd->rx_bd_haddr_lo;
}
+static inline u16
+bnx2_get_hw_rx_cons(struct bnx2 *bp)
+{
+ u16 cons = bp->status_blk->status_rx_quick_consumer_index0;
+
+ if (unlikely((cons & MAX_RX_DESC_CNT) == MAX_RX_DESC_CNT))
+ cons++;
+ return cons;
+}
+
static int
bnx2_rx_int(struct bnx2 *bp, int budget)
{
- struct status_block *sblk = bp->status_blk;
u16 hw_cons, sw_cons, sw_ring_cons, sw_prod, sw_ring_prod;
struct l2_fhdr *rx_hdr;
int rx_pkt = 0;
- hw_cons = bp->hw_rx_cons = sblk->status_rx_quick_consumer_index0;
- if ((hw_cons & MAX_RX_DESC_CNT) == MAX_RX_DESC_CNT) {
- hw_cons++;
- }
+ hw_cons = bnx2_get_hw_rx_cons(bp);
sw_cons = bp->rx_cons;
sw_prod = bp->rx_prod;
@@ -2515,10 +2521,7 @@ next_rx:
/* Refresh hw_cons to see if there is new work */
if (sw_cons == hw_cons) {
- hw_cons = bp->hw_rx_cons =
- sblk->status_rx_quick_consumer_index0;
- if ((hw_cons & MAX_RX_DESC_CNT) == MAX_RX_DESC_CNT)
- hw_cons++;
+ hw_cons = bnx2_get_hw_rx_cons(bp);
rmb();
}
}
@@ -2622,7 +2625,7 @@ bnx2_has_work(struct bnx2 *bp)
{
struct status_block *sblk = bp->status_blk;
- if ((sblk->status_rx_quick_consumer_index0 != bp->hw_rx_cons) ||
+ if ((bnx2_get_hw_rx_cons(bp) != bp->rx_cons) ||
(sblk->status_tx_quick_consumer_index0 != bp->hw_tx_cons))
return 1;
@@ -2655,7 +2658,7 @@ static int bnx2_poll_work(struct bnx2 *bp, int work_done, int budget)
if (sblk->status_tx_quick_consumer_index0 != bp->hw_tx_cons)
bnx2_tx_int(bp);
- if (sblk->status_rx_quick_consumer_index0 != bp->hw_rx_cons)
+ if (bnx2_get_hw_rx_cons(bp) != bp->rx_cons)
work_done += bnx2_rx_int(bp, budget - work_done);
return work_done;
@@ -4177,7 +4180,6 @@ bnx2_init_rx_ring(struct bnx2 *bp)
ring_prod = prod = bp->rx_prod = 0;
bp->rx_cons = 0;
- bp->hw_rx_cons = 0;
bp->rx_prod_bseq = 0;
for (i = 0; i < bp->rx_max_ring; i++) {
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index 1dce0d1..30ba366 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6513,7 +6513,6 @@ struct bnx2 {
u32 rx_prod_bseq;
u16 rx_prod;
u16 rx_cons;
- u16 hw_rx_cons;
u32 rx_csum;
^ permalink raw reply related
* [PATCH 1/3][BNX2]: Add PHY_DIS_EARLY_DAC workaround.
From: Michael Chan @ 2007-12-09 21:16 UTC (permalink / raw)
To: davem; +Cc: netdev
[BNX2]: Add PHY_DIS_EARLY_DAC workaround.
5709 Ax and Bx chips all need this workaround.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index da767d3..a4f3832 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -6685,8 +6685,9 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
} else if (CHIP_NUM(bp) == CHIP_NUM_5706 ||
CHIP_NUM(bp) == CHIP_NUM_5708)
bp->phy_flags |= PHY_CRC_FIX_FLAG;
- else if (CHIP_ID(bp) == CHIP_ID_5709_A0 ||
- CHIP_ID(bp) == CHIP_ID_5709_A1)
+ else if (CHIP_NUM(bp) == CHIP_NUM_5709 &&
+ (CHIP_REV(bp) == CHIP_REV_Ax ||
+ CHIP_REV(bp) == CHIP_REV_Bx))
bp->phy_flags |= PHY_DIS_EARLY_DAC_FLAG;
if ((CHIP_ID(bp) == CHIP_ID_5708_A0) ||
^ permalink raw reply related
* Re: [PATCH] iproute2: support dotted-quad netmask notation.
From: Andreas Henriksson @ 2007-12-09 17:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <1197070894.5385.14.camel@localhost.localdomain>
On lör, 2007-12-08 at 00:41 +0100, Andreas Henriksson wrote:
> On tor, 2007-12-06 at 11:53 -0800, Stephen Hemminger wrote:
> > On Tue, 4 Dec 2007 14:58:18 +0100
> > Andreas Henriksson <andreas@fatal.se> wrote:
> >
> > > Suggested patch for allowing netmask to be specified in dotted quad format.
> > > See http://bugs.debian.org/357172
> > >
> Updated patch, added your netmask validation code but without the check
> that made 0.0.0.0 (default) and 255.255.255.255 (one address) invalid
> netmasks as they are permitted in CIDR format.
I think both previous patches where broken on big-endian platforms.
Here's an updated patch again. I'm very sorry for the inconvenience!
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
diff --git a/lib/utils.c b/lib/utils.c
index 4c42dfd..bb88cf7 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -47,6 +47,41 @@ int get_integer(int *val, const char *arg, int base)
return 0;
}
+/* a valid netmask must be 2^n - 1 (n = 1..31) */
+static int is_valid_netmask(const inet_prefix *addr)
+{
+ uint32_t host;
+
+ if (addr->family != AF_INET)
+ return 0;
+
+ host = ~ntohl(addr->data[0]);
+
+ return (host & (host + 1)) == 0;
+}
+
+static int get_netmask(unsigned *val, const char *arg, int base)
+{
+ inet_prefix addr;
+
+ if (!get_unsigned(val, arg, base))
+ return 0;
+
+ /* try coverting dotted quad to CIDR */
+ if (!get_addr_1(&addr, arg, AF_INET)) {
+ u_int32_t mask;
+
+ *val=0;
+ for (mask = ntohl(addr.data[0]); mask; mask <<= 1)
+ (*val)++;
+
+ if (is_valid_netmask(&addr))
+ return 0;
+ }
+
+ return -1;
+}
+
int get_unsigned(unsigned *val, const char *arg, int base)
{
unsigned long res;
@@ -304,7 +339,8 @@ int get_prefix_1(inet_prefix *dst, char *arg, int family)
dst->bitlen = 32;
}
if (slash) {
- if (get_unsigned(&plen, slash+1, 0) || plen > dst->bitlen) {
+ if (get_netmask(&plen, slash+1, 0)
+ || plen > dst->bitlen) {
err = -1;
goto done;
}
--
Regards,
Andreas Henriksson
^ permalink raw reply related
* Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.
From: Samir Bellabes @ 2007-12-09 16:05 UTC (permalink / raw)
To: Tetsuo Handa
Cc: jmorris, herbert, netdev, davem, linux-security-module, kaber,
netfilter-devel, sds
In-Reply-To: <200712091706.IDE39560.LJtFOFHOOMVFSQ@I-love.SAKURA.ne.jp>
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> Hello, Samir.
>
> Did you receive the following messages?
> Since these messages were dropped at vger.kernel.org ,
> I'm worrying that you couldn't receive the following messages.
Yes, I got it.
I will take time to investigate your example.
^ permalink raw reply
* Re: IPsec replay sequence number overflow behavior? (RFC4303 section 3.3.3)
From: Paul Moore @ 2007-12-09 14:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, latten
In-Reply-To: <E1J1Bfw-0006Kw-00@gondolin.me.apana.org.au>
On Saturday 08 December 2007 9:13:48 pm Herbert Xu wrote:
> Paul Moore <paul.moore@hp.com> wrote:
> > If it is a bug, I think the basic fix should be pretty simple, changing
> > the above xfrm_output() code to the following:
> >
> > if (x->type->flags & XFRM_TYPE_REPLAY_PROT) {
> > XFRM_SKB_CB(skb)->seq = ++x->replay.oseq;
> > + if (x->replay.oseq == 0)
> > + goto error;
>
> Yes we need this check.
>
> However please add an unlikely around it since it's a 1-in-4
> billion event :)
:)
Thanks for clearing that up, I'll send a patch this week; complete with an
unlikely (similar to the RFC quality IPsec audit patch I sent on Friday) and
a decrement to the sequence counter in case of rollover.
--
paul moore
linux security @ hp
^ permalink raw reply
* [RFC] Connection Oriented Routing Protocol
From: Michael Blizek @ 2007-12-09 10:20 UTC (permalink / raw)
To: netdev
Hi!
I'm programming a new layer 3+4 protocol. It does not
have a routing table for every destination. Instead the
end node established a connection through every router
to the destination. This allows some pretty interesting
optimisations. See
http://michaelblizek.homelinux.net/projects/cor/index.html
for more details. You can download it with this link:
http://michaelblizek.homelinux.net/projects/cor/downloads/cor_2007_12_09.diff
This is a pretty early version. It does compile, but it
will not run. I can post is on this list, if you want to.
It applies to 2.6.22.2 (sorry), but the only files which
are touched outside the new net/cor directory are
net/Kconfig and net/Makefile
-Michi
^ permalink raw reply
* Re: Bogus commit 70eba18b ("make bnx2x select ZLIB_INFLATE")?
From: David Miller @ 2007-12-09 8:52 UTC (permalink / raw)
To: rdreier; +Cc: netdev, jeff, torvalds, eliezert, lee.schermerhorn
In-Reply-To: <adasl2ca7md.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Sat, 08 Dec 2007 19:07:22 -0800
> Commit 70eba18b ("make bnx2x select ZLIB_INFLATE") in Linus's tree
> seems bogus. As far as I can tell, bnx2x is not upstream yet, and the
> commit in question actually adds "select ZLIB_INFLATE" to the TEHUTI
> config, since there is no BNX2X config option (and also I don't see
> any reference to zlib in any tehuti files).
>
> I assume this is some sort of merge problem that got added to the
> wrong tree and should be reverted upstream.
I already pointed this out to Jeff, here:
http://marc.info/?l=linux-netdev&m=119709982603567&w=2
Indeed, it needs to be fixed up.
^ permalink raw reply
* Re: [PATCHES 0/3]: DCCP patches for 2.6.25
From: David Miller @ 2007-12-09 8:32 UTC (permalink / raw)
To: acme; +Cc: netdev, dccp
In-Reply-To: <1197139933-11609-1-git-send-email-acme@redhat.com>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Sat, 8 Dec 2007 16:52:10 -0200
> Hi David,
>
> Please consider pulling from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.25
Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH][NET]: Finish removing unused "mibalign" argument for snmp_mib_init().
From: David Miller @ 2007-12-09 8:27 UTC (permalink / raw)
To: yoshfuji; +Cc: acme, netdev
In-Reply-To: <20071208.101354.18036989.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Sat, 08 Dec 2007 10:13:54 -0800 (PST)
> Hello.
>
> In article <20071208175532.GE3180@ghostprotocols.net> (at Sat, 8 Dec 2007 15:55:34 -0200), Arnaldo Carvalho de Melo <acme@redhat.com> says:
>
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> >
> > diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> > index 5ab8ba7..90d2f72 100644
> > --- a/net/ipv6/af_inet6.c
> > +++ b/net/ipv6/af_inet6.c
> > @@ -714,20 +714,19 @@ EXPORT_SYMBOL_GPL(ipv6_opt_accepted);
> >
> > static int __init init_ipv6_mibs(void)
> > {
> > - if (snmp_mib_init((void **)ipv6_statistics, sizeof (struct ipstats_mib),
> > - __alignof__(struct ipstats_mib)) < 0)
> > + if (snmp_mib_init((void **)ipv6_statistics,
> > + sizeof(struct ipstats_mib)) < 0)
> > goto err_ip_mib;
>
> Oops... thanks.
> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied, thanks.
^ permalink raw reply
* tcp assertion failures in 2.6.24-rc4-mm1
From: Andrew Morton @ 2007-12-09 8:23 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: netdev
This is a mac g5. It is being used as a distcc server across the LAN
when...
windfarm: CPUs control loops started.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
audit(1197190525.100:2): audit_pid=1989 old=0 by auid=4294967295
KERNEL: assertion (packets <= tp->packets_out) failed at net/ipv4/tcp_input.c (2136)
KERNEL: assertion (packets <= tp->packets_out) failed at net/ipv4/tcp_input.c (2136)
------------[ cut here ]------------
Badness at net/ipv4/tcp_input.c:2518
NIP: c0000000003d46a4 LR: c0000000003d4d84 CTR: c000000000408914
REGS: c000000177b770e0 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
MSR: 9000000000029032 <EE,ME,IR,DR> CR: 24002488 XER: 00000000
TASK = c000000178868540[8316] 'cc1' THREAD: c000000177b74000 CPU: 1
NIP [c0000000003d46a4] .tcp_ack+0xd5c/0x1ce8
LR [c0000000003d4d84] .tcp_ack+0x143c/0x1ce8
Call Trace:
[c000000177b77360] [c0000000003d4d84] .tcp_ack+0x143c/0x1ce8 (unreliable)
[c000000177b77530] [c0000000003d81ac] .tcp_rcv_established+0x2fc/0x8d4
[c000000177b775e0] [c0000000003e2818] .tcp_v4_do_rcv+0x1fc/0x580
[c000000177b776d0] [c0000000003e37e0] .tcp_v4_rcv+0xc44/0xd28
[c000000177b777e0] [c0000000003bd398] .ip_local_deliver+0xb4/0x2cc
[c000000177b77870] [c0000000003bd87c] .ip_rcv+0x2cc/0x6f0
[c000000177b77930] [c000000000396444] .netif_receive_skb+0x440/0x4bc
[c000000177b779f0] [c00000000028255c] .tg3_poll+0x71c/0xb78
[c000000177b77b30] [c000000000396888] .net_rx_action+0x1e4/0x26c
[c000000177b77be0] [c000000000069584] .__do_softirq+0xd8/0x190
[c000000177b77ca0] [c00000000000b95c] .do_softirq+0x94/0x9c
[c000000177b77d30] [c0000000000696f0] .irq_exit+0x70/0x88
[c000000177b77db0] [c00000000000b83c] .do_IRQ+0xa0/0x12c
[c000000177b77e30] [c000000000004790] hardware_interrupt_entry+0x18/0x1c
Instruction dump:
7d7a5b78 3b200000 409e0008 933b0584 811b0584 39200000 2fa80000 409e0018
801b0588 2f800000 419e000c 39200001 <0fe00000> 2fa90000 409e0d60 72b40040
KERNEL: assertion (packets <= tp->packets_out) failed at net/ipv4/tcp_input.c (2136)
------------[ cut here ]------------
It's done that three times so far.
^ permalink raw reply
* Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.
From: Tetsuo Handa @ 2007-12-09 8:06 UTC (permalink / raw)
To: sam
Cc: jmorris, herbert, netdev, davem, linux-security-module, kaber,
netfilter-devel, sds
In-Reply-To: <200712042200.CDH65164.OOFSMFFLHJOtVQ@I-love.SAKURA.ne.jp>
Hello, Samir.
Did you receive the following messages?
Since these messages were dropped at vger.kernel.org ,
I'm worrying that you couldn't receive the following messages.
Tetsuo Handa wrote:
> Hello.
>
> Samir Bellabes wrote:
> > >> what differences between you approach and netfilter in this case ? if
> > >> it's about packet filtering, you already have all you wishes in
> > >> netfilter project.
> > > Except a hook for making decision with the name of process who picks that packet up known.
> >
> > I think that we really don't need it, because we can catch the
> > informations as I explained.
>
> Well, I haven't understood yet why we don't need it.
>
> How can you know the the name of process who copies that datagram to its userspace memory?
> A socket may be shared by multiple different executable files,
> so the name of the executable file is not known until
> one of processes who share the socket issues accept()/recvmsg() syscall.
>
> Are you saying that I should not use the name of the executable file?
>
> Regards.
>
Tetsuo Handa wrote:
> Hello.
>
> I made an example.
>
> Usage:
>
> Compile app1 and app2 and run /tmp/app1 .
>
> Run something like
> curl http://localhost:10000/
> to connect to /tmp/app1.
>
> I want to know that */tmp/app2* accepts TCP connection
> so that the user can control
> whether this TCP connection from 127.0.0.1 port N
> should be accepted by */tmp/app2* or not.
>
> How can we do this without socket_post_accept() change?
>
> Regards.
>
> ---------- app1.c start ----------
> /* gcc -Wall -O2 -o /tmp/app1 app1.c */
> #include <fcntl.h>
> #include <netinet/in.h>
> #include <stdio.h>
> #include <string.h>
> #include <sys/select.h>
> #include <sys/socket.h>
> #include <sys/types.h>
> #include <unistd.h>
>
> int main(int argc, char *argv[]) {
> const int fd = socket(PF_INET, SOCK_STREAM, 0);
> struct sockaddr_in addr;
> char buf[16];
> memset(&addr, 0, sizeof(addr));
> addr.sin_family = AF_INET;
> addr.sin_addr.s_addr = htonl(INADDR_ANY);
> addr.sin_port = htons(10000);
> fprintf(stderr, "%s started.\n", argv[0]);
> if (bind(fd, (struct sockaddr *) &addr, sizeof(addr))) {
> fprintf(stderr, "Can't bind()\n");
> return 1;
> } else if (listen(fd, 5)) {
> fprintf(stderr, "Can't listen()\n");
> return 1;
> }
> while (1) {
> fd_set rfds;
> FD_ZERO(&rfds);
> FD_SET(fd, &rfds);
> select(fd + 1, &rfds, NULL, NULL, NULL);
> if (FD_ISSET(fd, &rfds)) break;
> fprintf(stderr, "Can't select()\n");
> return 1;
> }
> if (fcntl(fd, FD_CLOEXEC, 0)) {
> fprintf(stderr, "Can't fcntl()\n");
> return 1;
> }
> snprintf(buf, sizeof(buf), "%d", fd);
> execlp("/tmp/app2", "app2", buf, NULL);
> fprintf(stderr, "Can't execve()\n");
> return 1;
> }
> ---------- app1.c end ----------
>
> ---------- app2.c start ----------
> /* gcc -Wall -O2 -o /tmp/app2 app2.c */
> #include <netinet/in.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/socket.h>
> #include <sys/types.h>
> #include <unistd.h>
>
> int main(int argc, char *argv[]) {
> int lfd;
> if (argc != 2) {
> fprintf(stderr, "Bad parameter.\n");
> return 1;
> }
> fprintf(stderr, "%s started.\n", argv[0]);
> lfd = atoi(argv[1]);
> while (1) {
> struct sockaddr_in addr;
> socklen_t size = sizeof(addr);
> int fd = accept(lfd, (struct sockaddr *) &addr, &size);
> char c;
> if (fd == EOF) {
> fprintf(stderr, "Can't accept()\n");
> return 1;
> }
> while (read(fd, &c, 1) == 1 && write(fd, &c, 1) == 1);
> close(fd);
> }
> return 0;
> }
> ---------- app2.c end ----------
>
^ permalink raw reply
* Re: [PATCH 1/11] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
From: Benjamin Herrenschmidt @ 2007-12-09 7:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev, Josh Boyer
In-Reply-To: <4759A870.8030900@pobox.com>
On Fri, 2007-12-07 at 15:09 -0500, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > From: Stefan Roese <sr@denx.de>
> >
> > This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC 440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 39 insertions(+)
>
> applied 1-11 #upstream-fixes
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: Bogus commit 70eba18b ("make bnx2x select ZLIB_INFLATE")?
From: Jeff Garzik @ 2007-12-09 4:48 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, torvalds, Eliezer Tamir, Lee Schermerhorn
In-Reply-To: <adasl2ca7md.fsf@cisco.com>
Roland Dreier wrote:
> Commit 70eba18b ("make bnx2x select ZLIB_INFLATE") in Linus's tree
> seems bogus. As far as I can tell, bnx2x is not upstream yet, and the
> commit in question actually adds "select ZLIB_INFLATE" to the TEHUTI
> config, since there is no BNX2X config option (and also I don't see
> any reference to zlib in any tehuti files).
>
> I assume this is some sort of merge problem that got added to the
> wrong tree and should be reverted upstream.
Yeah DaveM pointed that too. My fault (and yes it should be reverted
upstream... I've prepared a commit for my next round of submissions)
Jeff
^ permalink raw reply
* Bogus commit 70eba18b ("make bnx2x select ZLIB_INFLATE")?
From: Roland Dreier @ 2007-12-09 3:07 UTC (permalink / raw)
To: netdev, Jeff Garzik, torvalds; +Cc: Eliezer Tamir, Lee Schermerhorn
Commit 70eba18b ("make bnx2x select ZLIB_INFLATE") in Linus's tree
seems bogus. As far as I can tell, bnx2x is not upstream yet, and the
commit in question actually adds "select ZLIB_INFLATE" to the TEHUTI
config, since there is no BNX2X config option (and also I don't see
any reference to zlib in any tehuti files).
I assume this is some sort of merge problem that got added to the
wrong tree and should be reverted upstream.
- R.
^ 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