Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Thu, 22 Nov 2007 19:47:35 + Simon Arlott <[EMAIL PROTECTED]> wrote: > WARN during log message being output to ttyS0 and netconsole: > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at > kernel/softirq.c:139 local_bh_enable() > [2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97 > [2059664.620553] [<802e3356>] __nf_ct_ext_destroy+0x35/0x5b > [2059664.620569] [<802dfbeb>] destroy_conntrack+0x5e/0xf6 > [2059664.620577] [<802db821>] nf_conntrack_destroy+0x1f/0x3f > [2059664.620585] [<802c0c71>] __kfree_skb+0xb8/0xf6 > [2059664.620597] [<802d00f0>] zap_completion_queue+0x3e/0x64 > [2059664.620606] [<802d0583>] find_skb+0x14/0x6b > [2059664.620612] [<801167cc>] inc_nr_running+0x12/0x25 > [2059664.620622] [<802d0fd8>] netpoll_send_udp+0x2d/0x251 > [2059664.620630] [<80226135>] uart_console_write+0x2a/0x33 > [2059664.620645] [<80241319>] write_msg+0x32/0x41 > [2059664.620657] [<8011c205>] __call_console_drivers+0x61/0x6d > [2059664.620669] [<8011c3fc>] release_console_sem+0x164/0x1bf > [2059664.620679] [<8011c81f>] vprintk+0x27a/0x2ff > [2059664.620692] [<8013881e>] handle_IRQ_event+0x1a/0x3f > [2059664.620702] [<801203a5>] local_bh_enable+0x7d/0x97 > [2059664.620709] [<8031ae6a>] fn_hash_lookup+0xb0/0xcd > [2059664.620723] [<8011c8bf>] printk+0x1b/0x1f > [2059664.620731] [<8032b372>] ipt_log_packet+0x71/0x15e > [2059664.620747] [<8032b4a0>] ipt_log_target+0x41/0x4a > [2059664.620757] [<802ea446>] ipt_limit_match+0x58/0x76 > [2059664.620766] [<8032b45f>] ipt_log_target+0x0/0x4a > [2059664.620774] [<803288c5>] ipt_do_table+0x3e2/0x479 > [2059664.620785] [<80331228>] xfrm_policy_put_afinfo+0xa/0x1e > [2059664.620800] [<80332219>] xfrm_lookup+0x15/0x69 > [2059664.620809] [<802db7d0>] nf_iterate+0x38/0x6a > [2059664.620822] [<802dbb60>] nf_hook_slow+0x57/0xe0 > [2059664.620830] [<802f1e7c>] ip_forward_finish+0x0/0x22 > [2059664.620841] [<802f20d1>] ip_forward+0x233/0x2ae > [2059664.620849] [<802f1e7c>] ip_forward_finish+0x0/0x22 > [2059664.620859] [<802f0e7a>] ip_rcv+0x46f/0x49c > [2059664.620866] [<802f04a8>] ip_rcv_finish+0x0/0x2ab > [2059664.620876] [<802f0a0b>] ip_rcv+0x0/0x49c > [2059664.620884] [<802c544a>] netif_receive_skb+0x326/0x3ae > [2059664.620894] [<802c6efe>] process_backlog+0x6d/0xd2 > [2059664.620903] [<802c766e>] net_rx_action+0x86/0x193 > [2059664.620911] [<80120001>] __do_softirq+0x40/0x85 > [2059664.620919] [<8012006d>] do_softirq+0x27/0x2b > [2059664.620925] [<8012023d>] irq_exit+0x2d/0x37 > [2059664.620931] [<801062d9>] do_IRQ+0x7a/0x8d > [2059664.620943] [<8010479b>] common_interrupt+0x23/0x28 > [2059664.620954] [<80209f85>] acpi_processor_idle+0x235/0x3a0 > [2059664.620967] [<80102344>] cpu_idle+0x43/0x6c > [2059664.620973] [<804aa99e>] start_kernel+0x210/0x215 > [2059664.620989] [<804aa317>] unknown_bootoption+0x0/0x195 > [2059664.620998] === > [2059664.852188] SRC=66.249.93.147 DST=* LEN=40 TOS=0x00 PREC=0x00 TTL=53 > ID=23868 DF PROTO=TCP SPT=80 DPT=55219 WINDOW=0 RES=0x00 RST URGP=0 If that trace is to be beieved we're doing nefilter stuff on packets which were sent across netconsole. This probably isn't anything the netfilter guys have thought about. And probably we don't want them to. Is there some simple way in which we can exempt netconsole from netfilter processing? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] ipg: naming convention fixes
From: Pekka Enberg <[EMAIL PROTECTED]>
This changes some camel-case names to follow proper kernel naming convention.
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/ipg.c | 174 +++---
drivers/net/ipg.h | 19 +++--
2 files changed, 97 insertions(+), 96 deletions(-)
Index: linux-2.6/drivers/net/ipg.c
===
--- linux-2.6.orig/drivers/net/ipg.c
+++ linux-2.6/drivers/net/ipg.c
@@ -382,13 +382,13 @@ static void ipg_set_led_mode(struct net_
mode = ipg_r32(ASIC_CTRL);
mode &= ~(IPG_AC_LED_MODE_BIT_1 | IPG_AC_LED_MODE | IPG_AC_LED_SPEED);
- if ((sp->LED_Mode & 0x03) > 1)
+ if ((sp->led_mode & 0x03) > 1)
mode |= IPG_AC_LED_MODE_BIT_1; /* Write Asic Control Bit 29 */
- if ((sp->LED_Mode & 0x01) == 1)
+ if ((sp->led_mode & 0x01) == 1)
mode |= IPG_AC_LED_MODE;/* Write Asic Control Bit 14 */
- if ((sp->LED_Mode & 0x08) == 8)
+ if ((sp->led_mode & 0x08) == 8)
mode |= IPG_AC_LED_SPEED; /* Write Asic Control Bit 27 */
ipg_w32(mode, ASIC_CTRL);
@@ -402,7 +402,7 @@ static void ipg_set_phy_set(struct net_d
physet = ipg_r8(PHY_SET);
physet &= ~(IPG_PS_MEM_LENB9B | IPG_PS_MEM_LEN9 | IPG_PS_NON_COMPDET);
- physet |= ((sp->LED_Mode & 0x70) >> 4);
+ physet |= ((sp->led_mode & 0x70) >> 4);
ipg_w8(physet, PHY_SET);
}
@@ -733,7 +733,7 @@ static int ipg_get_rxbuff(struct net_dev
skb = netdev_alloc_skb(dev, IPG_RXSUPPORT_SIZE + NET_IP_ALIGN);
if (!skb) {
- sp->RxBuff[entry] = NULL;
+ sp->rx_buff[entry] = NULL;
return -ENOMEM;
}
@@ -746,7 +746,7 @@ static int ipg_get_rxbuff(struct net_dev
skb->dev = dev;
/* Save the address of the sk_buff structure. */
- sp->RxBuff[entry] = skb;
+ sp->rx_buff[entry] = skb;
rxfd->frag_info = cpu_to_le64(pci_map_single(sp->pdev, skb->data,
sp->rx_buf_sz, PCI_DMA_FROMDEVICE));
@@ -769,12 +769,12 @@ static int init_rfdlist(struct net_devic
for (i = 0; i < IPG_RFDLIST_LENGTH; i++) {
struct ipg_rx *rxfd = sp->rxd + i;
- if (sp->RxBuff[i]) {
+ if (sp->rx_buff[i]) {
pci_unmap_single(sp->pdev,
le64_to_cpu(rxfd->frag_info) & ~IPG_RFI_FRAGLEN,
sp->rx_buf_sz, PCI_DMA_FROMDEVICE);
- dev_kfree_skb_irq(sp->RxBuff[i]);
- sp->RxBuff[i] = NULL;
+ dev_kfree_skb_irq(sp->rx_buff[i]);
+ sp->rx_buff[i] = NULL;
}
/* Clear out the RFS field. */
@@ -825,9 +825,9 @@ static void init_tfdlist(struct net_devi
txfd->tfc = cpu_to_le64(IPG_TFC_TFDDONE);
- if (sp->TxBuff[i]) {
- dev_kfree_skb_irq(sp->TxBuff[i]);
- sp->TxBuff[i] = NULL;
+ if (sp->tx_buff[i]) {
+ dev_kfree_skb_irq(sp->tx_buff[i]);
+ sp->tx_buff[i] = NULL;
}
txfd->next_desc = cpu_to_le64(sp->txd_map +
@@ -844,7 +844,7 @@ static void init_tfdlist(struct net_devi
ipg_w32((u32) sp->txd_map, TFD_LIST_PTR_0);
ipg_w32(0x, TFD_LIST_PTR_1);
- sp->ResetCurrentTFD = 1;
+ sp->reset_current_tfd = 1;
}
/*
@@ -869,7 +869,7 @@ static void ipg_nic_txfree(struct net_de
for (released = 0; released < pending; released++) {
unsigned int dirty = sp->tx_dirty % IPG_TFDLIST_LENGTH;
- struct sk_buff *skb = sp->TxBuff[dirty];
+ struct sk_buff *skb = sp->tx_buff[dirty];
struct ipg_tx *txfd = sp->txd + dirty;
IPG_DEBUG_MSG("TFC = %16.16lx\n", (unsigned long) txfd->tfc);
@@ -893,7 +893,7 @@ static void ipg_nic_txfree(struct net_de
dev_kfree_skb_irq(skb);
- sp->TxBuff[dirty] = NULL;
+ sp->tx_buff[dirty] = NULL;
}
}
@@ -1065,7 +1065,7 @@ static int ipg_nic_rxrestore(struct net_
unsigned int entry = dirty % IPG_RFDLIST_LENGTH;
/* rx_copybreak may poke hole here and there. */
- if (sp->RxBuff[entry])
+ if (sp->rx_buff[entry])
continue;
/* Generate a new receive buffer to replace the
@@ -1096,15 +1096,15 @@ static int ipg_nic_rxrestore(struct net_
previous receiving and need to continue dumping the current one
*/
enum {
- NormalPacket,
- ErrorPacket
+ NORMAL_PACKET,
+ ERROR_
[PATCH 5/8] ipg: remove commented out code
From: Pekka Enberg <[EMAIL PROTECTED]>
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/ipg.c | 34 ++
drivers/net/ipg.h |4 +---
2 files changed, 7 insertions(+), 31 deletions(-)
Index: linux-2.6/drivers/net/ipg.c
===
--- linux-2.6.orig/drivers/net/ipg.c
+++ linux-2.6/drivers/net/ipg.c
@@ -1492,35 +1492,13 @@ static int ipg_nic_rx(struct net_device
/* Set the buffer's protocol field to Ethernet. */
skb->protocol = eth_type_trans(skb, dev);
- /* If the frame contains an IP/TCP/UDP frame,
-* determine if upper layer must check IP/TCP/UDP
-* checksums.
-*
-* NOTE: DO NOT RELY ON THE TCP/UDP CHECKSUM
-* VERIFICATION FOR SILICON REVISIONS B3
-* AND EARLIER!
-*
-if ((le64_to_cpu(rxfd->rfs &
-(IPG_RFS_TCPDETECTED | IPG_RFS_UDPDETECTED |
- IPG_RFS_IPDETECTED))) &&
- !(le64_to_cpu(rxfd->rfs &
- (IPG_RFS_TCPERROR | IPG_RFS_UDPERROR |
- IPG_RFS_IPERROR {
-* Indicate IP checksums were performed
-* by the IPG.
-*
- skb->ip_summed = CHECKSUM_UNNECESSARY;
-} else
+ /* The IPG encountered an error with (or
+* there were no) IP/TCP/UDP checksums.
+* This may or may not indicate an invalid
+* IP/TCP/UDP frame was received. Let the
+* upper layer decide.
*/
-{
- /* The IPG encountered an error with (or
-* there were no) IP/TCP/UDP checksums.
-* This may or may not indicate an invalid
-* IP/TCP/UDP frame was received. Let the
-* upper layer decide.
-*/
- skb->ip_summed = CHECKSUM_NONE;
- }
+ skb->ip_summed = CHECKSUM_NONE;
/* Hand off frame for higher layer processing.
* The function netif_rx() releases the sk_buff
Index: linux-2.6/drivers/net/ipg.h
===
--- linux-2.6.orig/drivers/net/ipg.h
+++ linux-2.6/drivers/net/ipg.h
@@ -23,7 +23,6 @@
#include
#include
#include
-/*#include */
/*
* Constants
@@ -733,8 +732,7 @@ enum ipg_regs {
* Miscellaneous macros.
*/
-/* Marco for printing debug statements.
-# define IPG_DDEBUG_MSG(args...) printk(KERN_DEBUG "IPG: " ## args) */
+/* Marco for printing debug statements. */
#ifdef IPG_DEBUG
# define IPG_DEBUG_MSG(args...)
# define IPG_DDEBUG_MSG(args...) printk(KERN_DEBUG "IPG: " args)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] ipg: remove driver version
From: Pekka Enberg <[EMAIL PROTECTED]>
The driver is in mainline now so there's no need to maintain a separate version
number.
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/ipg.c |3 +--
drivers/net/ipg.h |2 --
2 files changed, 1 insertion(+), 4 deletions(-)
Index: linux-2.6/drivers/net/ipg.c
===
--- linux-2.6.orig/drivers/net/ipg.c
+++ linux-2.6/drivers/net/ipg.c
@@ -51,8 +51,7 @@ enum {
#define DRV_NAME "ipg"
MODULE_AUTHOR("IC Plus Corp. 2003");
-MODULE_DESCRIPTION("IC Plus IP1000 Gigabit Ethernet Adapter Linux Driver "
- DrvVer);
+MODULE_DESCRIPTION("IC Plus IP1000 Gigabit Ethernet Adapter Linux Driver");
MODULE_LICENSE("GPL");
//variable record -- index by leading revision/length
Index: linux-2.6/drivers/net/ipg.h
===
--- linux-2.6.orig/drivers/net/ipg.h
+++ linux-2.6/drivers/net/ipg.h
@@ -25,8 +25,6 @@
#include
/*#include */
-#define DrvVer "2.09d"
-
/*
* Constants
*/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] ipg: remove boolean macros
From: Pekka Enberg <[EMAIL PROTECTED]>
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/ipg.h | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
Index: linux-2.6/drivers/net/ipg.h
===
--- linux-2.6.orig/drivers/net/ipg.h
+++ linux-2.6/drivers/net/ipg.h
@@ -478,38 +478,34 @@ enum ipg_regs {
* Tune
*/
-/* Miscellaneous Constants. */
-#define TRUE 1
-#define FALSE 0
-
/* Assign IPG_APPEND_FCS_ON_TX > 0 for auto FCS append on TX. */
-#define IPG_APPEND_FCS_ON_TX TRUE
+#define IPG_APPEND_FCS_ON_TX 1
/* Assign IPG_APPEND_FCS_ON_TX > 0 for auto FCS strip on RX. */
-#define IPG_STRIP_FCS_ON_RX TRUE
+#define IPG_STRIP_FCS_ON_RX 1
/* Assign IPG_DROP_ON_RX_ETH_ERRORS > 0 to drop RX frames with
* Ethernet errors.
*/
-#define IPG_DROP_ON_RX_ETH_ERRORSTRUE
+#define IPG_DROP_ON_RX_ETH_ERRORS1
/* Assign IPG_INSERT_MANUAL_VLAN_TAG > 0 to insert VLAN tags manually
* (via TFC).
*/
-#defineIPG_INSERT_MANUAL_VLAN_TAG FALSE
+#defineIPG_INSERT_MANUAL_VLAN_TAG 0
/* Assign IPG_ADD_IPCHECKSUM_ON_TX > 0 for auto IP checksum on TX. */
-#define IPG_ADD_IPCHECKSUM_ON_TX FALSE
+#define IPG_ADD_IPCHECKSUM_ON_TX 0
/* Assign IPG_ADD_TCPCHECKSUM_ON_TX > 0 for auto TCP checksum on TX.
* DO NOT USE FOR SILICON REVISIONS B3 AND EARLIER.
*/
-#define IPG_ADD_TCPCHECKSUM_ON_TXFALSE
+#define IPG_ADD_TCPCHECKSUM_ON_TX0
/* Assign IPG_ADD_UDPCHECKSUM_ON_TX > 0 for auto UDP checksum on TX.
* DO NOT USE FOR SILICON REVISIONS B3 AND EARLIER.
*/
-#define IPG_ADD_UDPCHECKSUM_ON_TXFALSE
+#define IPG_ADD_UDPCHECKSUM_ON_TX0
/* If inserting VLAN tags manually, assign the IPG_MANUAL_VLAN_xx
* constants as desired.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][IPv6] Correct the comment concerning inetsw6 table
It seems that net/ipv6/af_inet6.c was copied from net/ipv4/af_inet.c,
but one comment was not fixed.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 85178f7..64135e2 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -68,7 +68,7 @@ MODULE_LICENSE("GPL");
int sysctl_ipv6_bindv6only __read_mostly;
-/* The inetsw table contains everything that inet_create needs to
+/* The inetsw6 table contains everything that inet6_create needs to
* build a new socket.
*/
static struct list_head inetsw6[SOCK_MAX];
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] ipg: fix checkpatch reported errors
From: Pekka Enberg <[EMAIL PROTECTED]>
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/ipg.c | 48 +---
drivers/net/ipg.h | 32
2 files changed, 41 insertions(+), 39 deletions(-)
Index: 2.6/drivers/net/ipg.c
===
--- 2.6.orig/drivers/net/ipg.c 2007-11-23 10:08:41.0 +0200
+++ 2.6/drivers/net/ipg.c 2007-11-23 10:14:00.0 +0200
@@ -34,9 +34,9 @@ * Copyright (C) 2003, 2007 IC Plus Cor
IPG_AC_DMA | IPG_AC_FIFO | IPG_AC_NETWORK | IPG_AC_HOST | \
IPG_AC_AUTO_INIT)
-#define ipg_w32(val32,reg) iowrite32((val32), ioaddr + (reg))
-#define ipg_w16(val16,reg) iowrite16((val16), ioaddr + (reg))
-#define ipg_w8(val8,reg) iowrite8((val8), ioaddr + (reg))
+#define ipg_w32(val32, reg)iowrite32((val32), ioaddr + (reg))
+#define ipg_w16(val16, reg)iowrite16((val16), ioaddr + (reg))
+#define ipg_w8(val8, reg) iowrite8((val8), ioaddr + (reg))
#define ipg_r32(reg) ioread32(ioaddr + (reg))
#define ipg_r16(reg) ioread16(ioaddr + (reg))
@@ -54,20 +54,22 @@ MODULE_AUTHOR("IC Plus Corp. 2003");
MODULE_DESCRIPTION("IC Plus IP1000 Gigabit Ethernet Adapter Linux Driver");
MODULE_LICENSE("GPL");
-//variable record -- index by leading revision/length
-//Revision/Length(=N*4), Address1, Data1, Address2, Data2,...,AddressN,DataN
+/*
+ * variable record -- index by leading revision/length
+ * Revision/Length(=N*4), Address1, Data1, Address2, Data2,...,AddressN,DataN
+ */
static unsigned short DefaultPhyParam[] = {
- // 11/12/03 IP1000A v1-3 rev=0x40
+ /* 11/12/03 IP1000A v1-3 rev=0x40 */
/*--
(0x4000|(15*4)), 31, 0x0001, 27, 0x01e0, 31, 0x0002, 22, 0x85bd, 24,
0xfff2,
27, 0x0c10, 28, 0x0c10, 29, 0x2c10, 31,
0x0003, 23, 0x92f6,
31, 0x, 23, 0x003d, 30, 0x00de, 20,
0x20e7, 9, 0x0700,
--*/
- // 12/17/03 IP1000A v1-4 rev=0x40
+ /* 12/17/03 IP1000A v1-4 rev=0x40 */
(0x4000 | (07 * 4)), 31, 0x0001, 27, 0x01e0, 31, 0x0002, 27, 0xeb8e, 31,
0x,
30, 0x005e, 9, 0x0700,
- // 01/09/04 IP1000A v1-5 rev=0x41
+ /* 01/09/04 IP1000A v1-5 rev=0x41 */
(0x4100 | (07 * 4)), 31, 0x0001, 27, 0x01e0, 31, 0x0002, 27, 0xeb8e, 31,
0x,
30, 0x005e, 9, 0x0700,
@@ -187,7 +189,7 @@ ipg_w8((IPG_PC_MGMTCLK_LO | (IPG_PC_MGM
phyctrlpolarity) & IPG_PC_RSVD_MASK, PHY_CTRL);
}
-static u16 read_phy_bit(void __iomem * ioaddr, u8 phyctrlpolarity)
+static u16 read_phy_bit(void __iomem *ioaddr, u8 phyctrlpolarity)
{
u16 bit_data;
@@ -204,7 +206,7 @@ static u16 read_phy_bit(void __iomem * i
* Read a register from the Physical Layer device located
* on the IPG NIC, using the IPG PHYCTRL register.
*/
-static int mdio_read(struct net_device * dev, int phy_id, int phy_reg)
+static int mdio_read(struct net_device *dev, int phy_id, int phy_reg)
{
void __iomem *ioaddr = ipg_ioaddr(dev);
/*
@@ -548,7 +550,7 @@ return 0;
printk("\n");
} else {
/* Configure IPG for half duplex operation. */
- printk(KERN_INFO "%s: setting half duplex, "
+ printk(KERN_INFO "%s: setting half duplex, "
"no TX flow control, no RX flow control.\n", dev->name);
mac_ctrl_val &= ~IPG_MC_DUPLEX_SELECT_FD &
@@ -1089,12 +1091,12 @@ return 0;
#ifdef JUMBO_FRAME
/* use jumboindex and jumbosize to control jumbo frame status
- initial status is jumboindex=-1 and jumbosize=0
- 1. jumboindex = -1 and jumbosize=0 : previous jumbo frame has been done.
- 2. jumboindex != -1 and jumbosize != 0 : jumbo frame is not over size and
receiving
- 3. jumboindex = -1 and jumbosize != 0 : jumbo frame is over size, already
dump
-previous receiving and need to continue dumping the current one
-*/
+ * initial status is jumboindex=-1 and jumbosize=0
+ * 1. jumboindex = -1 and jumbosize=0 : previous jumbo frame has been done.
+ * 2. jumboindex != -1 and jumbosize != 0 : jumbo frame is not over size and
receiving
+ * 3. jumboindex = -1 and jumbosize != 0 : jumbo frame is over size, already
dump
+ * previous receiving and need to continue dumping the current
one
+ */
enum {
NORMAL_PACKET,
ERROR_PACKET
@@ -1209,7 +1211,7 @@ jumbo->current_size = 0;
jumbo->skb = NULL;
}
- // 1: found error, 0 no error
+ /* 1: found error, 0 no error */
if (ipg_
[PATCH 3/8] ipg: remove IPG_DEV_KFREE_SKB macro
From: Pekka Enberg <[EMAIL PROTECTED]>
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/ipg.c | 28 ++--
drivers/net/ipg.h |2 --
2 files changed, 14 insertions(+), 16 deletions(-)
Index: linux-2.6/drivers/net/ipg.c
===
--- linux-2.6.orig/drivers/net/ipg.c
+++ linux-2.6/drivers/net/ipg.c
@@ -776,7 +776,7 @@ static int init_rfdlist(struct net_devic
pci_unmap_single(sp->pdev,
le64_to_cpu(rxfd->frag_info) & ~IPG_RFI_FRAGLEN,
sp->rx_buf_sz, PCI_DMA_FROMDEVICE);
- IPG_DEV_KFREE_SKB(sp->RxBuff[i]);
+ dev_kfree_skb_irq(sp->RxBuff[i]);
sp->RxBuff[i] = NULL;
}
@@ -829,7 +829,7 @@ static void init_tfdlist(struct net_devi
txfd->tfc = cpu_to_le64(IPG_TFC_TFDDONE);
if (sp->TxBuff[i]) {
- IPG_DEV_KFREE_SKB(sp->TxBuff[i]);
+ dev_kfree_skb_irq(sp->TxBuff[i]);
sp->TxBuff[i] = NULL;
}
@@ -894,7 +894,7 @@ static void ipg_nic_txfree(struct net_de
le64_to_cpu(txfd->frag_info) & ~IPG_TFI_FRAGLEN,
skb->len, PCI_DMA_TODEVICE);
- IPG_DEV_KFREE_SKB(skb);
+ dev_kfree_skb_irq(skb);
sp->TxBuff[dirty] = NULL;
}
@@ -1121,7 +1121,7 @@ inline void ipg_nic_rx_free_skb(struct n
pci_unmap_single(sp->pdev,
le64_to_cpu(rxfd->frag_info & ~IPG_RFI_FRAGLEN),
sp->rx_buf_sz, PCI_DMA_FROMDEVICE);
- IPG_DEV_KFREE_SKB(sp->RxBuff[entry]);
+ dev_kfree_skb_irq(sp->RxBuff[entry]);
sp->RxBuff[entry] = NULL;
}
}
@@ -1189,7 +1189,7 @@ inline int ipg_nic_rx_check_error(struct
le64_to_cpu(rxfd->frag_info & ~IPG_RFI_FRAGLEN),
sp->rx_buf_sz, PCI_DMA_FROMDEVICE);
- IPG_DEV_KFREE_SKB(sp->RxBuff[entry]);
+ dev_kfree_skb_irq(sp->RxBuff[entry]);
sp->RxBuff[entry] = NULL;
}
return ErrorPacket;
@@ -1206,7 +1206,7 @@ static void ipg_nic_rx_with_start_and_en
int framelen;
if (jumbo->FoundStart) {
- IPG_DEV_KFREE_SKB(jumbo->skb);
+ dev_kfree_skb_irq(jumbo->skb);
jumbo->FoundStart = 0;
jumbo->CurrentSize = 0;
jumbo->skb = NULL;
@@ -1251,7 +1251,7 @@ static void ipg_nic_rx_with_start(struct
return;
if (jumbo->FoundStart)
- IPG_DEV_KFREE_SKB(jumbo->skb);
+ dev_kfree_skb_irq(jumbo->skb);
pci_unmap_single(pdev, le64_to_cpu(rxfd->frag_info & ~IPG_RFI_FRAGLEN),
sp->rx_buf_sz, PCI_DMA_FROMDEVICE);
@@ -1290,7 +1290,7 @@ static void ipg_nic_rx_with_end(struct n
framelen=IPG_RXFRAG_SIZE;
*/
if (framelen > IPG_RXSUPPORT_SIZE)
- IPG_DEV_KFREE_SKB(jumbo->skb);
+ dev_kfree_skb_irq(jumbo->skb);
else {
memcpy(skb_put(jumbo->skb, endframeLen),
skb->data, endframeLen);
@@ -1310,7 +1310,7 @@ static void ipg_nic_rx_with_end(struct n
ipg_nic_rx_free_skb(dev);
} else {
- IPG_DEV_KFREE_SKB(jumbo->skb);
+ dev_kfree_skb_irq(jumbo->skb);
jumbo->FoundStart = 0;
jumbo->CurrentSize = 0;
jumbo->skb = NULL;
@@ -1340,7 +1340,7 @@ static void ipg_nic_rx_no_start_no_end(s
ipg_nic_rx_free_skb(dev);
}
} else {
- IPG_DEV_KFREE_SKB(jumbo->skb);
+ dev_kfree_skb_irq(jumbo->skb);
jumbo->FoundStart = 0;
jumbo->CurrentSize = 0;
jumbo->skb = NULL;
@@ -1481,7 +1481,7 @@ static int ipg_nic_rx(struct net_device
le64_to_cpu(info) & ~IPG_RFI_FRAGLEN,
sp->rx_buf_sz, PCI_DMA_FROMDEVICE);
- IPG_DEV_KFREE_SKB(skb);
+ dev_kfree_skb_irq(skb);
}
} else {
@@ -1574,7 +1574,7 @@ static int ipg_nic_rx(struct net_device
pci_unmap_single(sp->pdev,
le64_to_cpu(rxfd->frag_info) & ~IPG_RFI_FRAGLEN,
[PATCH 1/8] ipg: remove old contact information
From: Pekka Enberg <[EMAIL PROTECTED]> Remove old comment as up-to-date contact information is in MAINTAINERS. Cc: Francois Romieu <[EMAIL PROTECTED]> Cc: Sorbica Shieh <[EMAIL PROTECTED]> Cc: Jesse Huang <[EMAIL PROTECTED]> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]> --- drivers/net/ipg.h | 12 1 file changed, 12 deletions(-) Index: linux-2.6/drivers/net/ipg.h === --- linux-2.6.orig/drivers/net/ipg.h +++ linux-2.6/drivers/net/ipg.h @@ -1,20 +1,8 @@ /* - * - * ipg.h - * * Include file for Gigabit Ethernet device driver for Network * Interface Cards (NICs) utilizing the Tamarack Microelectronics * Inc. IPG Gigabit or Triple Speed Ethernet Media Access * Controller. - * - * Craig Rich - * Sundance Technology, Inc. - * 1485 Saratoga Avenue - * Suite 200 - * San Jose, CA 95129 - * 408 873 4117 - * www.sundanceti.com - * [EMAIL PROTECTED] */ #ifndef __LINUX_IPG_H #define __LINUX_IPG_H - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] ipg: remove some internal comments
From: Pekka Enberg <[EMAIL PROTECTED]>
This removes some now useless comments that were added when the driver was
developed out-of-tree.
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/ipg.c | 11 ---
drivers/net/ipg.h | 10 --
2 files changed, 8 insertions(+), 13 deletions(-)
Index: linux-2.6/drivers/net/ipg.c
===
--- linux-2.6.orig/drivers/net/ipg.c
+++ linux-2.6/drivers/net/ipg.c
@@ -373,7 +373,6 @@ static void mdio_write(struct net_device
}
}
-/* Set LED_Mode JES20040127EEPROM */
static void ipg_set_led_mode(struct net_device *dev)
{
struct ipg_nic_private *sp = netdev_priv(dev);
@@ -395,7 +394,6 @@ static void ipg_set_led_mode(struct net_
ipg_w32(mode, ASIC_CTRL);
}
-/* Set PHYSet JES20040127EEPROM */
static void ipg_set_phy_set(struct net_device *dev)
{
struct ipg_nic_private *sp = netdev_priv(dev);
@@ -414,7 +412,7 @@ static int ipg_reset(struct net_device *
* register as specified by the 'resetflags' input
* parameter.
*/
- void __iomem *ioaddr = ipg_ioaddr(dev); //JES20040127EEPROM:
+ void __iomem *ioaddr = ipg_ioaddr(dev);
unsigned int timeout_count = 0;
IPG_DEBUG_MSG("_reset\n");
@@ -429,10 +427,10 @@ static int ipg_reset(struct net_device *
if (++timeout_count > IPG_AC_RESET_TIMEOUT)
return -ETIME;
}
- /* Set LED Mode in Asic Control JES20040127EEPROM */
+ /* Set LED Mode in Asic Control */
ipg_set_led_mode(dev);
- /* Set PHYSet Register Value JES20040127EEPROM */
+ /* Set PHYSet Register Value */
ipg_set_phy_set(dev);
return 0;
}
@@ -2018,7 +2016,6 @@ static void ipg_set_phy_default_param(un
}
}
-/* JES20040127EEPROM */
static int read_eeprom(struct net_device *dev, int eep_addr)
{
void __iomem *ioaddr = ipg_ioaddr(dev);
@@ -2085,7 +2082,7 @@ static int ipg_hw_init(struct net_device
unsigned int i;
int rc;
- /* Read/Write and Reset EEPROM Value Jesse20040128EEPROM_VALUE */
+ /* Read/Write and Reset EEPROM Value */
/* Read LED Mode Configuration from EEPROM */
sp->LED_Mode = read_eeprom(dev, 6);
Index: linux-2.6/drivers/net/ipg.h
===
--- linux-2.6.orig/drivers/net/ipg.h
+++ linux-2.6/drivers/net/ipg.h
@@ -79,7 +79,7 @@ enum ipg_regs {
TX_STATUS = 0x60,
MAC_CTRL= 0x6c,
VLAN_TAG= 0x70, // Unused
- PHY_SET = 0x75, // JES20040127EEPROM
+ PHY_SET = 0x75,
PHY_CTRL= 0x76,
STATION_ADDRESS_0 = 0x78,
STATION_ADDRESS_1 = 0x7a,
@@ -312,7 +312,7 @@ enum ipg_regs {
#define IPG_RM_RECEIVEMULTICASTHASH 0x10
#define IPG_RM_RECEIVEIPMULTICAST 0x20
-/* PhySet JES20040127EEPROM*/
+/* PhySet */
#define IPG_PS_MEM_LENB9B 0x01
#define IPG_PS_MEM_LEN9 0x02
#define IPG_PS_NON_COMPDET 0x04
@@ -369,8 +369,8 @@ enum ipg_regs {
#define IPG_AC_RST_OUT 0x0100
#define IPG_AC_INT_REQUEST 0x0200
#define IPG_AC_RESET_BUSY 0x0400
-#define IPG_AC_LED_SPEED0x0800 //JES20040127EEPROM
-#define IPG_AC_LED_MODE_BIT_1 0x2000 //JES20040127EEPROM
+#define IPG_AC_LED_SPEED0x0800
+#define IPG_AC_LED_MODE_BIT_1 0x2000
/* EepromCtrl */
#define IPG_EC_RSVD_MASK0x83FF
@@ -785,7 +785,6 @@ struct ipg_nic_private {
unsigned int tx_dirty;
unsigned int rx_current;
unsigned int rx_dirty;
-// Add by Grace 2005/05/19
#ifdef JUMBO_FRAME
struct SJumbo Jumbo;
#endif
@@ -796,7 +795,6 @@ struct ipg_nic_private {
spinlock_t lock;
int tenmbpsmode;
- /*Jesse20040128EEPROM_VALUE */
u16 LED_Mode;
u16 station_addr[3];/* Station Address in EEPROM Reg 0x10..0x12 */
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] [TCP]: Move FRTO checks out from write queue abstraction funcs
Better place exists in update_send_head (other non-queue related
adjustments are done there as well) which is the only caller of
tcp_advance_send_head (now that the bogus call from mtu_probe is
gone).
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/net/tcp.h |5 -
net/ipv4/tcp_output.c |4
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index ebe7347..59c1bce 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1241,14 +1241,9 @@ static inline struct sk_buff *tcp_send_head(struct sock
*sk)
static inline void tcp_advance_send_head(struct sock *sk, struct sk_buff *skb)
{
- struct tcp_sock *tp = tcp_sk(sk);
-
sk->sk_send_head = skb->next;
if (sk->sk_send_head == (struct sk_buff *)&sk->sk_write_queue)
sk->sk_send_head = NULL;
- /* Don't override Nagle indefinately with F-RTO */
- if (tp->frto_counter == 2)
- tp->frto_counter = 3;
}
static inline void tcp_check_send_head(struct sock *sk, struct sk_buff
*skb_unlinked)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 44d70db..3b17688 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -80,6 +80,10 @@ static void update_send_head(struct sock *sk, struct sk_buff
*skb)
tcp_advance_send_head(sk, skb);
tp->snd_nxt = TCP_SKB_CB(skb)->end_seq;
tcp_packets_out_inc(sk, skb);
+
+ /* Don't override Nagle indefinately with F-RTO */
+ if (tp->frto_counter == 2)
+ tp->frto_counter = 3;
}
/* SND.NXT, if window was not shrunk.
--
1.5.0.6
Does tc-prio really work as advertised?
Hello all, I might make a fool out of me, but I think the prio qdisc doesn't work as advertised in any document I could lay my hands on. My problem was that the link quality reported by the olsr.org olsrd degraded depending on the amount of payload traffic transferred through an adhoc/mesh interface. The LQ is calculated from the packet loss of LQ Hello packets sent through this interface. To make sure normal traffic does not interfere with this value, olsrd sets the TOS field to 0x10 (Minimize-Delay) by default. This should give olsr traffic the highest priority on the link. Investigating this issue I replaced the default Pfifo_fast with a prio qdisc and attached a pfifo on each of the bands: INTERFACE=wifi0 tc qdisc add dev $INTERFACE root handle 1: prio tc qdisc add dev $INTERFACE parent 1:1 handle 10: pfifo tc qdisc add dev $INTERFACE parent 1:2 handle 20: pfifo tc qdisc add dev $INTERFACE parent 1:3 handle 30: pfifo The I used ping -Q TOSVALUE to send packets with different TOS values through the interface. tcpdump confirmed the correct TOS values in the outgoing packets. With "tc -s qdisc ls dev wifi0" I could observe the effects of the different TOS values. The result: no effect at all! Every single packet used the band indicated by the first value in the priomap (e.g. band 1 by default, in my case the pfifo with handle 20:). I can't square this observation with the available documentation. Looking at the source code, it seems that sched_prio uses the skb->priority value to select the outgoing band. According to some documentation I found, an application can set this value. Now I'm at a loss. I can work around this problem with filters, but I don't think that this is the correct solution. Any suggestions? Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 01:11:20PM -0600, Matt Mackall ([EMAIL PROTECTED]) wrote: > On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote: > > On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL > > PROTECTED]) wrote: > > > On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL > > > PROTECTED]) wrote: > > > > Stop, we are trying to free skb without destructor and catch connection > > > > tracking, so it is not a solution. To fix the problem we need to check > > > > if it is not netfilter related, kind of this (not tested), Simon please > > > > give it a try: > > > > > > And to be really cool we need to bypass skbs with xfrm attached, since > > > its freeing also assumes BH context. > > > > What about compile options? > > What about my original suggestion that we mark skbs owned by netpoll > and free only those. Much safer, no? Untested: This should work if there are netpoll's skbs, but if we are under memory pressure we want to free not only netpoll skbs, but at least one, and what if there are no netpoll skbs in the queue? -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 10:54:11PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED]) > wrote: > > Here's another thought: move all this logic into the networking core, > > unify it with current softirq zapper, then allow it to be called from > > various other places (like atomic allocators). Then it'll all be in > > central maintained place with more users. > > This can be done quite easily - put a check into __kfree_skb() if > netpoll is compiled-in and we are in hardirq context, then put skb > into softirq freeing queue. Then zap_completion_queue() can free > anything without ever knowing about nature of the packet, since this > will be checked in __kfree_skb() anyway. What I had in mind was moving the whole zap_completion_queue concept into net/core/skbuff. So that netpoll (and, say, atomic kmalloc) can simply call something like "clean_completion_queue". -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 03/22] NET: DM9000: Pass IRQ flags via platform data
ACK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 01/22] NET: DM9000 use dev_xxx() instead of printk for output.
ACK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PowerPC: ibm_newemac minor fixes.
On Fri, 2007-11-23 at 20:20 -0500, Jeff Garzik wrote: > Benjamin Herrenschmidt wrote: > > On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote: > > > >> These patches have some minor ibm_newemac fixes. > > > > All 3 patches look good, thanks. I'll sign them off and forward them > > to Jeff in my next batch. > > > > Jeff, did you already pick up my previous drop of EMAC patches from last > > week for .25 or not ? If not, I will resend the whole lot along with > > Valentine's patches sometime next week. > > Just got back from Thanksgiving holiday, and am about to go through the > lot that's sitting in my inbox. > > Just let me know what you would prefer me to do, starting from today. Then wait for my next batch and ignore previous patches, except the one titled "ibm_newemac: Fix possible lockup on close" which is a 2.6.24 bug fix. Thanks ! Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PowerPC: ibm_newemac minor fixes.
On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote: > These patches have some minor ibm_newemac fixes. All 3 patches look good, thanks. I'll sign them off and forward them to Jeff in my next batch. Jeff, did you already pick up my previous drop of EMAC patches from last week for .25 or not ? If not, I will resend the whole lot along with Valentine's patches sometime next week. Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: dmfe: don't access configuration space in D3 state
On Saturday 24 November 2007 05:10:37 Jeff Garzik wrote: > Maxim Levitsky wrote: > >>From 7e24227257f315e52fe0b494dc1253d2a0ce5dff Mon Sep 17 00:00:00 2001 > > From: Maxim Levitsky <[EMAIL PROTECTED]> > > Date: Fri, 23 Nov 2007 01:15:36 +0200 > > Subject: [PATCH] NET: dmfe: don't access configuration space in D3 state > > Accidently I reversed the order of pci_save_state and > > pci_set_power_state in .suspend()/.resume() callbacks > > > > Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]> > > --- > > drivers/net/tulip/dmfe.c |4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > applied #upstream-fixes, after hand-editing patch changelog taking by > git-am from email body > > > Hi, Thanks, Next time I will be more careful with changelogs. Best regards, Maxim Levitsky - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add VLAN (802.1q) support to sis900 driver
Daniele Venzano wrote: The attached patch adds support for VLANs to the sis900 driver and bumps the version number. It is based on an old (2003) patch for the 2.4 series by Hamid Hashemi Golpayegani. It applies on top of 2.6.16(.5). I have one report that it works and behaves as intended. Please review and consider for inclusion. Signed-off-by: Daniele Venzano <[EMAIL PROTECTED]> I just found this buried in my inbox... can you resubmit for the latest kernel? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: dmfe: don't access configuration space in D3 state
Maxim Levitsky wrote: From 7e24227257f315e52fe0b494dc1253d2a0ce5dff Mon Sep 17 00:00:00 2001 From: Maxim Levitsky <[EMAIL PROTECTED]> Date: Fri, 23 Nov 2007 01:15:36 +0200 Subject: [PATCH] NET: dmfe: don't access configuration space in D3 state Accidently I reversed the order of pci_save_state and pci_set_power_state in .suspend()/.resume() callbacks Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]> --- drivers/net/tulip/dmfe.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) applied #upstream-fixes, after hand-editing patch changelog taking by git-am from email body - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] smc911x: Fix undefined CONFIG_ symbol warning
Peter Korsgaard wrote: elif defined(CONFIG_*) should be used instead of elif CONFIG_* so GCC doesn't give warnings about undefined symbols when the config option is disabled. --- drivers/net/smc911x.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h index 16a0edc..d04e4fa 100644 --- a/drivers/net/smc911x.h +++ b/drivers/net/smc911x.h @@ -37,7 +37,7 @@ #define SMC_USE_16BIT0 #define SMC_USE_32BIT1 #define SMC_IRQ_SENSEIRQF_TRIGGER_FALLING -#elif CONFIG_SH_MAGIC_PANEL_R2 +#elif defined(CONFIG_SH_MAGIC_PANEL_R2) #define SMC_USE_SH_DMA 0 #define SMC_USE_16BIT0 applied all three to #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] amd8111e: don't call napi_enable if configured w/o NAPI
Jiri Bohac wrote: The amd8111e network driver was broken by bea3348eef27e6044b6161fd04c3152215f96411, which makes the driver call napi_enable() and napi_disable() even if the driver had been configured without CONFIG_AMD8111E_NAPI, and thus netif_napi_add() had not been called on initialization. This triggers a BUG in napi_enable(). This patch fixes the problem. Please apply. Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]> applied #upstream-fixes would you consider creating and testing a patch that removed the non-NAPI path completely? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24 2/2]S2io: Fix to aggregate vlan tagged packets
Ramkrishna Vepa wrote: - Fix to aggregate vlan packets. IP offset is incremented by 4 bytes if the packet contains vlan header. Signed-off-by: Santoshkumar Rastapur <[EMAIL PROTECTED]> Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]> --- ACK but cannot apply due to dropped patches - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24 1/2]S2io: Strip the vlan tag if the vlan group is not NULL
Ramkrishna Vepa wrote: - Updated the vlan tag stripping code as per Dave Johnson's patch <[EMAIL PROTECTED]> Below is the driver behaviour for vlan_tag_strip loadable paramter, vlan_tag_strip - 0: Don't strip the vlan tag vlan_tag_strip - 1: Always strip the vlan tag vlan_tag_strip - 2 (default): strip the vlan tag if the vlan group is not NULL. Signed-off-by: Santoshkumar Rastapur <[EMAIL PROTECTED]> Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]> --- diff -Nurp 2.0.26.6/drivers/net/s2io.c 2.0.26.8P1/drivers/net/s2io.c --- 2.0.26.6/drivers/net/s2io.c 2007-11-15 18:19:42.0 -0800 +++ 2.0.26.8P1/drivers/net/s2io.c 2007-11-15 18:15:00.0 -0800 @@ -46,10 +46,10 @@ * Possible values '1' for enable and '0' for disable. Default is '1' * ufo: This parameter used to enable/disable UDP Fragmentation Offload(UFO) * Possible values '1' for enable and '0' for disable. Default is '0' - * vlan_tag_strip: This can be used to enable or disable vlan stripping. - * Possible values '1' for enable , '0' for disable. - * Default is '2' - which means disable in promisc mode - * and enable in non-promiscuous mode. + * vlan_tag_strip: This can be used to enable or disable vlan tag stripping. + * Possible values '2' for driver default, '1' for enable and + * '0' for disable + * Default is '2' - VLAN tag stripping enabled if vlan group present / this should be controlled via ethtool and behave like other net drivers - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24 1/1]S2io: Fixed memory leak by freeing MSI-X local entry memories when vector allocation fails
Sreenivasa Honnur wrote: - Fixed memory leak by freeing MSI-X local entry memories when vector allocation fails in s2io_add_isr. - Added two utility functions remove_msix_isr and remove_inta_isr to eliminate code duplication. - Incorporated following review comments from Jeff - Removed redundant stats->mem_freed and synchronize_irq call - do_rem_msix_isr is renamed as remove_msix_isr - do_rem_inta_isr is renamed as remove_inta_isr - (Resubmit third time) ditto, does not apply - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24 1/1]S2io: Support for add/delete/store/restore ethernet addresses
Sreenivasa Honnur wrote: - Support to add/delete/store/restore 64 and 128 Ethernet addresses for Xframe I and Xframe II respectively. - (Resubmit third time) patch does not apply to linux upstream (2.6.24-rc) nor netdev-2.6#upstream - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sky2: disable rx checksum on Yukon XL
Stephen Hemminger wrote: The Marvell Yukon XL chipset appears to have a hardware glitch where it will repeat the checksum of the last packet. Of course, this is timing sensitive and only happens sometimes... More info: http://bugzilla.kernel.org/show_bug.cgi?id=9381 As a workaround just disable hardware checksumming by default on this chip version. The earlier workaround for PCIX, dual port was also on Yukon XL so don't need to disable checksumming there. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> applied #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] cxgb3 - fix MSI-X failure path
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Return error code when msi-x settings fail. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/cxgb3_main.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) applied 1-9 to #upstream, then trimmed all trailing whitespace - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.
Hello. James Morris wrote: > From memory, one approach under discussion was to add netfilter hooks to > the transport layer, which could be invoked correctly by each type of > protocol when the target process is selected. > > If this is done for netfilter, then an LSM hook is probably not needed at > all, as security modules can utilize netfilter hooks directly. Patrick McHardy says (at http://marc.info/?l=linux-netdev&m=118495005800410&w=2 ) "Even with socket filters netfilter doesn't know the final receipient process, that is not known until it calls recvmsg and the data is read, which is too late for netfilter." > > Precautions: This approach has a side effect which unlikely occurs. > > > > If a socket is shared by multiple processes with different policy, > > the process who should be able to accept this connection > > will not be able to accept this connection > > because socket_post_accept() aborts this connection. > > But if socket_post_accept() doesn't abort this connection, > > the process who must not be able to accept this connection > > will repeat accept() forever, which is a worse side effect. I think this change is needed regardless of whether to use connection filtering or not. Currently, SELinux doesn't use socket_post_accept(). | * @socket_post_accept: | *This hook allows a security module to copy security | *information into the newly created socket's inode. But if one wants to *copy* security information to accept()ed socket, the location after fd_install() is too late to copy because the userland process can access accept()ed socket's fd whose security information is not copied yet. Also, if one wants to *assign* security information to accept()ed socket, it might attend memory allocation which can fail. So, use of void for socket_post_accept() deprives a security module of a chance to abort this connection if the security module failed to *assign* security information. Regards. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 02/22] NET: DM9000 update debugging macros to use debug level
you really should consider adding msg_enable support (grep for that in other net drivers, and for netif_msg in netdevice.h) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dm9601: Consolidate common parts of dm_write_*_async
Peter Korsgaard wrote: dm_write_async and dm_write_reg_async are almost identical. Move common functionality to dm_write_async_helper (saves ~256b). Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> --- drivers/net/usb/dm9601.c | 53 +++-- 1 files changed, 13 insertions(+), 40 deletions(-) applied #upstream - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dm9601: Fix printk
Peter Korsgaard wrote: A printk in the error handling code of dm9601.c was missing a newline. Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> --- drivers/net/usb/dm9601.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c index 2c68573..1ffdd10 100644 --- a/drivers/net/usb/dm9601.c +++ b/drivers/net/usb/dm9601.c @@ -94,7 +94,7 @@ static void dm_write_async_callback(struct urb *urb) struct usb_ctrlrequest *req = (struct usb_ctrlrequest *)urb->context; if (urb->status < 0) - printk(KERN_DEBUG "dm_write_async_callback() failed with %d", + printk(KERN_DEBUG "dm_write_async_callback() failed with %d\n", urb->status); applied #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 3c501: Bring into compliance with the coding style
Alan Cox wrote: 3c501 leads the way... 8) Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied #upstream please send stuff to netdev@vger.kernel.org, linux-net is pretty much dead - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 8/8] forcedeth boot delay fix
[EMAIL PROTECTED] wrote: From: Ayaz Abdulla <[EMAIL PROTECTED]> Fix a long boot delay in the forcedeth driver. During initialization, the timeout for the handshake between mgmt unit and driver can be very long. The patch reduces the timeout by eliminating a extra loop around the timeout logic. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9308 Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]> Cc: Alex Howells <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> applied #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/8] ucc_geth-fix-build-break-introduced-by-commit-09f75cd7bf13720738e6a196cc0107ce9a5bd5a0-checkpatch-fixes
[EMAIL PROTECTED] wrote: From: Andrew Morton <[EMAIL PROTECTED]> Cc: "David S. Miller" <[EMAIL PROTECTED]> Cc: Emil Medve <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Cc: Kumar Gala <[EMAIL PROTECTED]> Cc: Li Yang <[EMAIL PROTECTED]> Cc: Paul Mackerras <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/ucc_geth.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/ucc_geth.c~ucc_geth-fix-build-break-introduced-by-commit-09f75cd7bf13720738e6a196cc0107ce9a5bd5a0-checkpatch-fixes drivers/net/ucc_geth.c --- a/drivers/net/ucc_geth.c~ucc_geth-fix-build-break-introduced-by-commit-09f75cd7bf13720738e6a196cc0107ce9a5bd5a0-checkpatch-fixes +++ a/drivers/net/ucc_geth.c @@ -3443,7 +3443,7 @@ static int ucc_geth_rx(struct ucc_geth_p u16 length, howmany = 0; u32 bd_status; u8 *bdBuffer; - struct net_device * dev; + struct net_device *dev; ACK with a fixed description... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ethtool: Fix coalesce settings copy+paste typo
Auke Kok wrote: Coalesce setting errors use the same error messages as the descriptor ring errors. applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] PowerPC: ibm_newemac minor fixes.
Benjamin Herrenschmidt wrote: On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote: These patches have some minor ibm_newemac fixes. All 3 patches look good, thanks. I'll sign them off and forward them to Jeff in my next batch. Jeff, did you already pick up my previous drop of EMAC patches from last week for .25 or not ? If not, I will resend the whole lot along with Valentine's patches sometime next week. Just got back from Thanksgiving holiday, and am about to go through the lot that's sitting in my inbox. Just let me know what you would prefer me to do, starting from today. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
netdev-2.6 rebased
I pulled all the patches collected by DaveM in davem/netdev-2.6.git a few days ago into jgarzik/netdev-2.6.git#upstream. As of a few minutes ago, jgarzik/netdev-2.6.git was rebased to the latest 2.6.24-rc (torvalds/linux-2.6.git). Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 22/22] NET: DM9000: Show the MAC address source after printing MAC
ACK patches 16-22 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 15/22] NET: DM9000: Use netif_msg to enable debugging options
ah, you took care of my comment regarding an earlier patch. consider that comment rescinded - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 07/22] NET: DM9000: Use msleep() instead of udelay()
are you sure you cannot sleep during suspend? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 06/22] NET: DM9000: Use kthread to probe MII status when device open
seems like a delayed workqueue would be most appropriate for this. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2][2.6.24] ehea: Improve tx packets counting
Thomas Klein wrote: Using own tx_packets counter instead of firmware counters. Signed-off-by: Thomas Klein <[EMAIL PROTECTED]> --- drivers/net/ehea/ehea.h |2 +- drivers/net/ehea/ehea_main.c |9 +++-- 2 files changed, 8 insertions(+), 3 deletions(-) applies 1-2 to #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
Benjamin Herrenschmidt wrote: The e1000 driver stores the content of the PCI resources into unsigned long's before ioremapping. This breaks on 32 bits platforms that support 64 bits MMIO resources such as ppc 44x. This fixes it by removing those temporary variables and passing directly the result of pci_resource_start/len to ioremap. The side effect is that I removed the assignments to the netdev fields mem_start, mem_end and base_addr, which are totally useless for PCI devices. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> -- drivers/net/e1000/e1000_main.c | 18 +- 1 file changed, 5 insertions(+), 13 deletions(-) Looks good to me. auke? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ibm_newemac: Fix possible lockup on close
Benjamin Herrenschmidt wrote: It's a bad idea to call flush_scheduled_work from within a netdev->stop because the linkwatch will occasionally take the rtnl lock from a workqueue context, and thus that can deadlock. This reworks things a bit in that area to avoid the problem. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- applied #upstream-fixes (2.6.24-rc) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Saturday 24 November 2007 06:53:30 Andi Kleen wrote: > This serves as a documentation > on what is considered internal. And if some obscure module (in or > out of tree) wants to use an internal interface they first have > to send the module maintainer a patch and get some review this way. So, you're saying that there's a problem with in-tree modules using symbols they shouldn't? Can you give an example? > I believe that is fairly important in tree too because the > kernel has become so big now that review cannot be the only > enforcement mechanism for this anymore. If people aren't reviewing, this won't make them review. I don't think the problem is that people are conniving to avoid review. > Another secondary reason is that there are too many exported interfaces > in general. Probably, but this doesn't reduce it. > Several distributions have policies that require to > keep the changes to these exported interfaces minimal and that > is very hard with thousands of exported symbol. With name spaces > the number of truly publicly exported symbols will hopefully > shrink to a much smaller, more manageable set. *This* makes sense. But it's not clear that the burden should be placed on kernel coders. You can create a list yourself. How do I tell the difference between "truly publicly exported" symbols and others? If a symbol has more than one in-tree user, it's hard to argue against an out-of-tree module using the symbol, unless you're arguing against *all* out-of-tree modules. Sorry, Rusty. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] ibm_newemac: Candidate patches for 2.6.25
Benjamin Herrenschmidt wrote: Here are the patches I have pending for EMAC. With some non-released patches from Hugh Blemings, I get a taishan (440GX) booting now, in addition to Ebony (440GP) and various 405GP boards. This is 2.6.25 material except for patch #1 which has already been posted separately and is candidate for 2.6.24 (and possibly stable) dropping (waiting for resend), as requested - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
cqe, cqe_skb: return when both or when either NULL?
In function ehea_poll() drivers/net/ehea/ehea_main.c:667, in a loop cqe and cqe_skb - both struct ehea_cqe pointers - are assigned: -- cqe = ehea_poll_rq1(pr->qp, &wqe_index); cqe_skb = ehea_poll_cq(pr->send_cq); if (!cqe && !cqe_skb) return rx; -- Is it intended that only when both are NULL there is a return, or should there be returned when either is NULL (and the && replaced with ||). If the code is ok as is, sorry for the noise. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 10:54:10PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > Here's another thought: move all this logic into the networking core,
> > unify it with current softirq zapper, then allow it to be called from
> > various other places (like atomic allocators). Then it'll all be in
> > central maintained place with more users.
>
> This can be done quite easily - put a check into __kfree_skb() if
> netpoll is compiled-in and we are in hardirq context, then put skb
> into softirq freeing queue. Then zap_completion_queue() can free
> anything without ever knowing about nature of the packet, since this
> will be checked in __kfree_skb() anyway.
And let's add some mess...
But should fix the case when netpoll code is being executed in interrupt
context and is about to free skb, which should not be freed.
Frankly saying this looks like crap.
Crap-added-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 758dafe..88f8ea9 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -196,10 +196,7 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
- dev_kfree_skb_any(skb); /* put this one back */
- else
- __kfree_skb(skb);
+ __kfree_skb(skb);
}
}
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 27cfe5f..8642097 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -318,6 +318,26 @@ void kfree_skbmem(struct sk_buff *skb)
void __kfree_skb(struct sk_buff *skb)
{
+#if defined(CONFIG_NETPOLL) || defined(CONFIG_NETPOLL_TRAP)
+ if (in_irq() || irqs_disabled()) {
+ if (skb->destructor) {
+ dev_kfree_skb_irq(skb);
+ return;
+ }
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ if (skb->nfct || skb->nfct_reasm) {
+ dev_kfree_skb_irq(skb);
+ return;
+ }
+#endif
+#ifdef CONFIG_XFRM
+ if (skb->sp) {
+ dev_kfree_skb_irq(skb);
+ return;
+ }
+#endif
+ }
+#endif
dst_release(skb->dst);
#ifdef CONFIG_XFRM
secpath_put(skb->sp);
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
On Fri, Nov 23, 2007 at 02:35:05PM +1100, Rusty Russell wrote: > On Friday 23 November 2007 12:36:22 Andi Kleen wrote: > > On Friday 23 November 2007 01:25, Rusty Russell wrote: > > > That's my point. If there's a whole class of modules which can use a > > > symbol, why are we ruling out external modules? > > > > The point is to get cleaner interfaces. > > But this doesn't change interfaces at all. It makes modules fail to load > unless they're on a permitted list, which now requires maintenance. The modules wouldn't be using the internal interfaces in the first place with name spaces in place. This serves as a documentation on what is considered internal. And if some obscure module (in or out of tree) wants to use an internal interface they first have to send the module maintainer a patch and get some review this way. I believe that is fairly important in tree too because the kernel has become so big now that review cannot be the only enforcement mechanism for this anymore. Another secondary reason is that there are too many exported interfaces in general. Several distributions have policies that require to keep the changes to these exported interfaces minimal and that is very hard with thousands of exported symbol. With name spaces the number of truly publicly exported symbols will hopefully shrink to a much smaller, more manageable set. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> > > Stop, we are trying to free skb without destructor and catch connection
> > > tracking, so it is not a solution. To fix the problem we need to check
> > > if it is not netfilter related, kind of this (not tested), Simon please
> > > give it a try:
> >
> > And to be really cool we need to bypass skbs with xfrm attached, since
> > its freeing also assumes BH context.
>
> What about compile options?
What about my original suggestion that we mark skbs owned by netpoll
and free only those. Much safer, no? Untested:
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void refill_skbs(void)
spin_unlock_irqrestore(&skb_pool.lock, flags);
}
+/* used to mark an skb as owned by netpoll */
+static void netpoll_skb_destroy(struct sk_buff *skb)
+{
+ return;
+}
+
static void zap_completion_queue(void)
{
unsigned long flags;
@@ -219,10 +225,12 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
+ if (skb->destructor == netpoll_skb_destroy) {
+ skb->destructor = NULL;
+ __kfree_skb(skb);
+ }
+ else
dev_kfree_skb_any(skb); /* put this one back */
- else
- __kfree_skb(skb);
}
}
@@ -252,6 +260,7 @@ repeat:
atomic_set(&skb->users, 1);
skb_reserve(skb, reserve);
+ skb->destructor = netpoll_skb_destroy;
return skb;
}
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 08:57:57PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 11:07:56AM -0600, Matt Mackall ([EMAIL PROTECTED]) > wrote: > > On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote: > > > On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL > > > PROTECTED]) wrote: > > > > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at > > > > > kernel/softirq.c:139 local_bh_enable() > > > > > [2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97 > > > > > > > > [2059664.620657] [<8011c205>] __call_console_drivers+0x61/0x6d > > > > > [2059664.620669] [<8011c3fc>] release_console_sem+0x164/0x1bf > > > > > [2059664.620679] [<8011c81f>] vprintk+0x27a/0x2ff > > > > > > > If that trace is to be beieved we're doing nefilter stuff on packets > > > > which > > > > were sent across netconsole. > > > > > > > > This probably isn't anything the netfilter guys have thought about. And > > > > probably we don't want them to. Is there some simple way in which we > > > > can > > > > exempt netconsole from netfilter processing? > > > > > > This is not about netfilter, but about freeing skb in interrupt context, > > > which is not allowed, and in interrupt skbs are queued to be freed in > > > softirq, > > > but netcnsole wants to flush softirq freeing queue. That is a question: > > > why? > > > > My memory here is hazy, but I think this exists to rescue netconsole > > in low-memory situations. This bit originated with Ingo, so maybe he > > can recall. > > > > Netpoll can process an arbitrary number of skbs inside a single > > interrupt. Think sysrq-t at one packet per line or kgdboe where the > > entire trace session can happen inside one very long interrupt. > > > > Perhaps we can refine this to mark netpoll's skbs (perhaps with > > ->destructor?) and delete only skbs we own. As these are never passed > > through any of the other route/xfrm/filter code, they should be safe > > to delete even in irq context, yes? > > > > > Removing zap_completion_queue() from find_skb() will fix the warning, > > > but I'm not sure this is a correct fix. I've added Matt to the Cc list. > > > > Care to try the sysrq-t or OOM message tests? > > We basically can not free skbs there - if it is interrupt context and > we are freeing some skb with destructor we will catch the warning anyway. Perhaps I'm missing some context here. We don't free skbs with destructors in irq context in zap_completion_queue. We reinsert them on the completion list. We do this by calling dev_kfree_skb_any. So I'd be surprised if that was a problem. But I can imagine having problems for skbs without destructors which run into one of these in __kfree_skb: dst_release secpath_put nf_conntrack_put nf_conntrack_put_reasm nf_bridge_put ..some or all of which assume a softirq context. > No matter if we are under memory pressure or whatever - it is not > allowed - a lot of skbs are supposed to be freed in softirq context, > that is why dev_kfree_skb_any() exists. Some skbs we definitely -can- free in irq context. The only ones we care about are the ones generated by netpoll. If there's a reason you think netpoll's own skbs can't be freed, please describe it. > I think we can drop skbs _without_ destructor from the queue though in > that conditions given that we actually need only one. Huh? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Stop, we are trying to free skb without destructor and catch connection
> tracking, so it is not a solution. To fix the problem we need to check
> if it is not netfilter related, kind of this (not tested), Simon please
> give it a try:
And to be really cool we need to bypass skbs with xfrm attached, since
its freeing also assumes BH context.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 758dafe..5f86e60 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -196,7 +196,8 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
+ if (skb->destructor || skb->nfct ||
+ skb->nfct_reasm || skb->sp)
dev_kfree_skb_any(skb); /* put this one back */
else
__kfree_skb(skb);
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 08:57:57PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> > My memory here is hazy, but I think this exists to rescue netconsole
> > in low-memory situations. This bit originated with Ingo, so maybe he
> > can recall.
> >
> > Netpoll can process an arbitrary number of skbs inside a single
> > interrupt. Think sysrq-t at one packet per line or kgdboe where the
> > entire trace session can happen inside one very long interrupt.
> >
> > Perhaps we can refine this to mark netpoll's skbs (perhaps with
> > ->destructor?) and delete only skbs we own. As these are never passed
> > through any of the other route/xfrm/filter code, they should be safe
> > to delete even in irq context, yes?
> >
> > > Removing zap_completion_queue() from find_skb() will fix the warning,
> > > but I'm not sure this is a correct fix. I've added Matt to the Cc list.
> >
> > Care to try the sysrq-t or OOM message tests?
>
> We basically can not free skbs there - if it is interrupt context and
> we are freeing some skb with destructor we will catch the warning anyway.
>
> No matter if we are under memory pressure or whatever - it is not
> allowed - a lot of skbs are supposed to be freed in softirq context,
> that is why dev_kfree_skb_any() exists.
>
> I think we can drop skbs _without_ destructor from the queue though in
> that conditions given that we actually need only one.
Stop, we are trying to free skb without destructor and catch connection
tracking, so it is not a solution. To fix the problem we need to check
if it is not netfilter related, kind of this (not tested), Simon please
give it a try:
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 758dafe..855bb3f 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -196,7 +196,7 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
+ if (skb->destructor || skb->nfct || skb->nfct_reasm)
dev_kfree_skb_any(skb); /* put this one back */
else
__kfree_skb(skb);
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RFC] New driver "sfc" for Solarstorm SFC4000 controller
This is a net driver (and MTD driver, sfc_mtd) for our SFC4000 10G Ethernet controller, branded "Solarstorm", with various PHYs. It is intended to support our NIC reference designs SFE4001 (10GBASE-T), SFE4002 (XFP), SFE4003 (10GBASE-CX4), OEM designs based on them, and some development boards. We have been maintaining drivers out-of-tree for some time but are now preparing them to work in-tree. There are some issues that might need to be addressed: 1. When we enable NAPI polling, we need to set __LINK_STATE_START in the net device used for NAPI. This bit is commented as private in netdevice.h, but e1000 also does this. Is this incorrect? 2. We added a lot of definitions and code for 10G MDIO. This is mostly generic and could be moved into core code. We welcome review comments and are ready to address them. The patch (against net-2.6.25) is at: https://support.solarflare.com/netdev/net-2.6.25-sfc-2.2.0019.patch The new files may also be downloaded as a tarball: https://support.solarflare.com/netdev/net-2.6.25-sfc-2.2.0019.tar.gz And for verification there is: https://support.solarflare.com/netdev/MD5SUMS Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix memory leak in inet_hashtables.h when NUMA is on
The inet_ehash_locks_alloc() looks like this: #ifdef CONFIG_NUMA if (size > PAGE_SIZE) x = vmalloc(...); else #endif x = kmalloc(...); Unlike it, the inet_ehash_locks_alloc() looks like this: #ifdef CONFIG_NUMA if (size > PAGE_SIZE) vfree(x); else #else kfree(x); #endif The error is obvious - if the NUMA is on and the size is less than the PAGE_SIZE we leak the pointer (kfree is inside the #else branch). Compiler doesn't warn us because after the kfree(x) there's a "x = NULL" assignment, so here's another (minor?) bug: we don't set x to NULL under certain circumstances. Boring explanation, I know... Patch explains it better. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h index 469216d..37f6cb1 100644 --- a/include/net/inet_hashtables.h +++ b/include/net/inet_hashtables.h @@ -186,9 +186,8 @@ static inline void inet_ehash_locks_free(struct inet_hashinfo *hashinfo) if (size > PAGE_SIZE) vfree(hashinfo->ehash_locks); else -#else - kfree(hashinfo->ehash_locks); #endif + kfree(hashinfo->ehash_locks); hashinfo->ehash_locks = NULL; } } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25] [TCP]: Move FRTO checks out from write queue abstraction funcs
On Fri, 23 Nov 2007, Herbert Xu wrote: > On Fri, Nov 23, 2007 at 02:25:08PM +0200, Ilpo Järvinen wrote: > > > > Better place exists in update_send_head (other non-queue related > > adjustments are done there as well) which is the only caller of > > tcp_advance_send_head (now that the bogus call from mtu_probe is > > gone). > > > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> > > Hmm, why don't we just get rid of tcp_advance_send_head? > Or are you planning to start using it again? The purpose of the tcp_advance_send_head & friends was/is to abstract the write queue from the TCP worker code. RB-tree wq can then be put in place more easily (and I'm hopefully coming to that soon). There are some other similar functions in tcp.h as well which currently have only a single caller. Please don't undo that work while DaveM is away for a short while :-). IMHO it was a mistake from my side to add frto code into the wq abstaction function in the first place though I could use the bogus call that tcp_mtu_probe used to make there as an excuse :-), the TCP worker code is much better place for it (and it does similar stuff already)... -- i.
[PATCH net-2.6.25] Make macro to specify the ptype_base size
Currently this size is 16, but as the comment says this
is so only because all the chains (except one) has the
length 1. I think, that some day this may change, so
growing this hash will be much easier.
Besides, symbolic names are read better than magic constants.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 043e2f8..d88d832 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -150,8 +150,11 @@
* 86DDIPv6
*/
+#define PTYPE_HASH_SIZE(16)
+#define PTYPE_HASH_MASK(PTYPE_HASH_SIZE - 1)
+
static DEFINE_SPINLOCK(ptype_lock);
-static struct list_head ptype_base[16] __read_mostly; /* 16 way hashed list */
+static struct list_head ptype_base[PTYPE_HASH_SIZE] __read_mostly;
static struct list_head ptype_all __read_mostly; /* Taps */
#ifdef CONFIG_NET_DMA
@@ -362,7 +365,7 @@ void dev_add_pack(struct packet_type *pt)
if (pt->type == htons(ETH_P_ALL))
list_add_rcu(&pt->list, &ptype_all);
else {
- hash = ntohs(pt->type) & 15;
+ hash = ntohs(pt->type) & PTYPE_HASH_MASK;
list_add_rcu(&pt->list, &ptype_base[hash]);
}
spin_unlock_bh(&ptype_lock);
@@ -391,7 +394,7 @@ void __dev_remove_pack(struct packet_type *pt)
if (pt->type == htons(ETH_P_ALL))
head = &ptype_all;
else
- head = &ptype_base[ntohs(pt->type) & 15];
+ head = &ptype_base[ntohs(pt->type) & PTYPE_HASH_MASK];
list_for_each_entry(pt1, head, list) {
if (pt == pt1) {
@@ -1420,7 +1423,8 @@ struct sk_buff *skb_gso_segment(struct sk_buff *skb, int
features)
}
rcu_read_lock();
- list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type) & 15], list) {
+ list_for_each_entry_rcu(ptype,
+ &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
if (ptype->type == type && !ptype->dev && ptype->gso_segment) {
if (unlikely(skb->ip_summed != CHECKSUM_PARTIAL)) {
err = ptype->gso_send_check(skb);
@@ -2077,7 +2081,8 @@ ncls:
goto out;
type = skb->protocol;
- list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type)&15], list) {
+ list_for_each_entry_rcu(ptype,
+ &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
if (ptype->type == type &&
(!ptype->dev || ptype->dev == skb->dev)) {
if (pt_prev)
@@ -2521,7 +2526,7 @@ static void *ptype_get_idx(loff_t pos)
++i;
}
- for (t = 0; t < 16; t++) {
+ for (t = 0; t < PTYPE_HASH_SIZE; t++) {
list_for_each_entry_rcu(pt, &ptype_base[t], list) {
if (i == pos)
return pt;
@@ -2555,10 +2560,10 @@ static void *ptype_seq_next(struct seq_file *seq, void
*v, loff_t *pos)
hash = 0;
nxt = ptype_base[0].next;
} else
- hash = ntohs(pt->type) & 15;
+ hash = ntohs(pt->type) & PTYPE_HASH_MASK;
while (nxt == &ptype_base[hash]) {
- if (++hash >= 16)
+ if (++hash >= PTYPE_HASH_SIZE)
return NULL;
nxt = ptype_base[hash].next;
}
@@ -4396,7 +4401,7 @@ static int __init net_dev_init(void)
goto out;
INIT_LIST_HEAD(&ptype_all);
- for (i = 0; i < 16; i++)
+ for (i = 0; i < PTYPE_HASH_SIZE; i++)
INIT_LIST_HEAD(&ptype_base[i]);
if (register_pernet_subsys(&netdev_net_ops))
--
1.5.3.4
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] Name magic constants in sock_wake_async()
The sock_wake_async() performs a bit different actions
depending on "how" argument. Unfortunately this argument
ony has numerical magic values.
I propose to give names to their constants to help people
reading this function callers understand what's going on
without looking into this function all the time.
I suppose this is 2.6.25 material, but if it's not (or the
naming seems poor/bad/awful), I can rework it against the
current net-2.6 tree.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/net.h b/include/linux/net.h
index 0235d91..f95f12c 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -186,6 +186,13 @@ struct net_proto_family {
struct iovec;
struct kvec;
+enum {
+ SOCK_WAKE_IO,
+ SOCK_WAKE_WAITD,
+ SOCK_WAKE_SPACE,
+ SOCK_WAKE_URG,
+};
+
extern int sock_wake_async(struct socket *sk, int how, int band);
extern int sock_register(const struct net_proto_family *fam);
extern void sock_unregister(int family);
diff --git a/net/atm/common.c b/net/atm/common.c
index eba09a0..c865517 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -113,7 +113,7 @@ static void vcc_write_space(struct sock *sk)
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
wake_up_interruptible(sk->sk_sleep);
- sk_wake_async(sk, 2, POLL_OUT);
+ sk_wake_async(sk, SOCK_WAKE_SPACE, POLL_OUT);
}
read_unlock(&sk->sk_callback_lock);
diff --git a/net/core/sock.c b/net/core/sock.c
index eac7aa0..1182140 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1498,7 +1498,7 @@ static void sock_def_error_report(struct sock *sk)
read_lock(&sk->sk_callback_lock);
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
wake_up_interruptible(sk->sk_sleep);
- sk_wake_async(sk,0,POLL_ERR);
+ sk_wake_async(sk, SOCK_WAKE_IO, POLL_ERR);
read_unlock(&sk->sk_callback_lock);
}
@@ -1507,7 +1507,7 @@ static void sock_def_readable(struct sock *sk, int len)
read_lock(&sk->sk_callback_lock);
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
wake_up_interruptible(sk->sk_sleep);
- sk_wake_async(sk,1,POLL_IN);
+ sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
read_unlock(&sk->sk_callback_lock);
}
@@ -1524,7 +1524,7 @@ static void sock_def_write_space(struct sock *sk)
/* Should agree with poll, otherwise some programs break */
if (sock_writeable(sk))
- sk_wake_async(sk, 2, POLL_OUT);
+ sk_wake_async(sk, SOCK_WAKE_SPACE, POLL_OUT);
}
read_unlock(&sk->sk_callback_lock);
@@ -1539,7 +1539,7 @@ void sk_send_sigurg(struct sock *sk)
{
if (sk->sk_socket && sk->sk_socket->file)
if (send_sigurg(&sk->sk_socket->file->f_owner))
- sk_wake_async(sk, 3, POLL_PRI);
+ sk_wake_async(sk, SOCK_WAKE_URG, POLL_PRI);
}
void sk_reset_timer(struct sock *sk, struct timer_list* timer,
diff --git a/net/core/stream.c b/net/core/stream.c
index b2fb846..5586879 100644
--- a/net/core/stream.c
+++ b/net/core/stream.c
@@ -35,7 +35,7 @@ void sk_stream_write_space(struct sock *sk)
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
wake_up_interruptible(sk->sk_sleep);
if (sock->fasync_list && !(sk->sk_shutdown & SEND_SHUTDOWN))
- sock_wake_async(sock, 2, POLL_OUT);
+ sock_wake_async(sock, SOCK_WAKE_SPACE, POLL_OUT);
}
}
diff --git a/net/dccp/input.c b/net/dccp/input.c
index 1ce1010..11bf47e 100644
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -37,7 +37,7 @@ static void dccp_rcv_close(struct sock *sk, struct sk_buff
*skb)
dccp_send_reset(sk, DCCP_RESET_CODE_CLOSED);
dccp_fin(sk, skb);
dccp_set_state(sk, DCCP_CLOSED);
- sk_wake_async(sk, 1, POLL_HUP);
+ sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_HUP);
}
static void dccp_rcv_closereq(struct sock *sk, struct sk_buff *skb)
@@ -90,7 +90,7 @@ static void dccp_rcv_reset(struct sock *sk, struct sk_buff
*skb)
dccp_fin(sk, skb);
if (err && !sock_flag(sk, SOCK_DEAD))
- sk_wake_async(sk, 0, POLL_ERR);
+ sk_wake_async(sk, SOCK_WAKE_IO, POLL_ERR);
dccp_time_wait(sk, DCCP_TIME_WAIT, 0);
}
@@ -402,7 +402,7 @@ static int dccp_rcv_request_sent_state_process(struct sock
*sk,
if (!sock_flag(sk, SOCK_DEAD)) {
sk->sk_state_change(sk);
- sk_wake_async(sk, 0, POLL_OUT);
+ sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
}
if (sk->sk_write_pending || icsk->icsk_ack.pingpong ||
@@ -611,7 +611,7 @@ int dccp_rcv_state_process(struct sock *sk, struct sk_buff
*skb,
switch (old_sta
Re: [PATCHv6 iptables]Interface group match
On Tue, Nov 20, 2007 at 02:14:28PM +0100, Laszlo Attila Toth wrote:
> Interface group values can be checked on both input and output interfaces
> with optional mask.
> Index: extensions/libxt_ifgroup.c
> ===
> --- extensions/libxt_ifgroup.c(revision 0)
> +++ extensions/libxt_ifgroup.c(revision 0)
> + info->in_group = strtoul(optarg, &end, 0);
This is somewhat inconsistent with the iproute patch which targets
specific groups (with names).
Should iptables be allowed to read "/etc/iproute2/rt_ifgroup"?
There is no standard API like getservbyname()...
I do have a draft patch for physdev which is however against
iptables-1.3.8 and linux-2.6.19 so it will need some more work
but I will attach it for discussion.
(This will leave ebtables to be touched...)
Best regards,
Lutz
--
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG /protecting industrial networks/
tel: +49.30.6392-3308
fax: +49.30.6392-3307
Albert-Einstein-Str. 14
D-12489 Berlin, Germany
www.innominate.com
Register Court: AG Charlottenburg, HR B 81603
Management Board: Joachim Fietz, Dirk Seewald
Chairman of the Supervisory Board: Edward M. Stadum
Visit us at the SPS/IPC/Drives in Nuremberg / Germany
27 - 29 November 2007, Hall 9, Stand 9-141
diff -ruN iptables-1.3.8-vanilla/extensions/libipt_physdev.c
iptables-1.3.8/extensions/libipt_physdev.c
--- iptables-1.3.8-vanilla/extensions/libipt_physdev.c 2007-01-23
13:50:00.0 +0100
+++ iptables-1.3.8/extensions/libipt_physdev.c 2007-11-01 16:57:58.0
+0100
@@ -19,6 +19,8 @@
"physdev v%s options:\n"
" --physdev-in [!] input name[+] bridge port name ([+] for
wildcard)\n"
" --physdev-out [!] output name[+] bridge port name ([+] for wildcard)\n"
+" --physgroup-in [!] input group bridge port group value\n"
+" --physgroup-out [!] output group bridge port group value\n"
" [!] --physdev-is-in arrived on a bridge device\n"
" [!] --physdev-is-out will leave on a bridge device\n"
" [!] --physdev-is-bridged it's a bridged packet\n"
@@ -31,6 +33,8 @@
{ "physdev-is-in", 0, 0, '3' },
{ "physdev-is-out", 0, 0, '4' },
{ "physdev-is-bridged", 0, 0, '5' },
+ { "physgroup-in", 1, 0, '6' },
+ { "physgroup-out", 1, 0, '7' },
{0}
};
@@ -47,6 +51,7 @@
{
struct ipt_physdev_info *info =
(struct ipt_physdev_info*)(*match)->data;
+ char *end;
switch (c) {
case '1':
@@ -103,6 +108,44 @@
info->bitmask |= IPT_PHYSDEV_OP_BRIDGED;
break;
+ case '6':
+ if (*flags & IPT_PHYSDEV_OP_GROUPIN)
+ goto multiple_use;
+ check_inverse(argv[optind-1], &invert, &optind, 0);
+ end = optarg = argv[optind-1];
+ info->ingroup = strtoul(optarg, &end, 0);
+ info->ingroupmask = 0xUL;
+ if (*end == '/')
+ info->ingroupmask = strtoul(end+1, &end, 0);
+ if (*end != '\0' || end == optarg)
+ exit_error(PARAMETER_PROBLEM,
+ "physdev match: Bad ifgroup value `%s'",
+ optarg);
+ if (invert)
+ info->invert |= IPT_PHYSDEV_OP_GROUPIN;
+ *flags |= IPT_PHYSDEV_OP_GROUPIN;
+ info->bitmask |= IPT_PHYSDEV_OP_GROUPIN;
+ break;
+
+ case '7':
+ if (*flags & IPT_PHYSDEV_OP_GROUPOUT)
+ goto multiple_use;
+ check_inverse(argv[optind-1], &invert, &optind, 0);
+ end = optarg = argv[optind-1];
+ info->outgroup = strtoul(optarg, &end, 0);
+ info->outgroupmask = 0xUL;
+ if (*end == '/')
+ info->outgroupmask = strtoul(end+1, &end, 0);
+ if (*end != '\0' || end == optarg)
+ exit_error(PARAMETER_PROBLEM,
+ "physdev match: Bad ifgroup value `%s'",
+ optarg);
+ if (invert)
+ info->invert |= IPT_PHYSDEV_OP_GROUPOUT;
+ *flags |= IPT_PHYSDEV_OP_GROUPOUT;
+ info->bitmask |= IPT_PHYSDEV_OP_GROUPOUT;
+ break;
+
default:
return 0;
}
@@ -145,6 +186,13 @@
if (info->bitmask & IPT_PHYSDEV_OP_BRIDGED)
printf("%s --physdev-is-bridged",
info->invert & IPT_PHYSDEV_OP_BRIDGED ? " !":"");
+
+ if (info->bitmask & IPT_PHYSDEV_OP_GROUPIN)
+ printf("%s --physgroup-in 0x%x/0x%x",
+
Re: [PATCH][UNIX] Move the unix sock iterators in to proper place
On Fri, Nov 23, 2007 at 04:10:08PM +0300, Pavel Emelyanov wrote:
>
> I'm afraid to become importunate, but is the net-2.6 (not 25)
> tree is currently the David's tree (unlike net-2.6.25, which
> has temporary switched to your one)?
I'm about to do a push soon which will create net-2.6 in the
same place as my net-2.6.25 tree.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25] [TCP]: Move FRTO checks out from write queue abstraction funcs
On Fri, Nov 23, 2007 at 02:25:08PM +0200, Ilpo Järvinen wrote:
>
> Better place exists in update_send_head (other non-queue related
> adjustments are done there as well) which is the only caller of
> tcp_advance_send_head (now that the bogus call from mtu_probe is
> gone).
>
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
Hmm, why don't we just get rid of tcp_advance_send_head?
Or are you planning to start using it again?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPv6] Correct the comment concerning inetsw6 table
On Fri, Nov 23, 2007 at 11:57:54AM +0300, Pavel Emelyanov wrote:
> It seems that net/ipv6/af_inet6.c was copied from net/ipv4/af_inet.c,
> but one comment was not fixed.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Applied.
Oh and congratulations for advancing in the Order of Pedantry :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 iproute 2/2] Interface group as new ip link option
On Tue, Nov 20, 2007 at 02:14:30PM +0100, Laszlo Attila Toth wrote:
> Interfaces can be grouped and each group has an unique positive integer ID.
> It can be set via ip link. Symbolic names can be specified in
> /etc/iproute2/rt_ifgroup.
> diff --git a/include/rt_names.h b/include/rt_names.h
> index 07a10e0..72c5247 100644
> --- a/include/rt_names.h
> +++ b/include/rt_names.h
> @@ -8,11 +8,13 @@ char* rtnl_rtscope_n2a(int id, char *buf, int len);
> char* rtnl_rttable_n2a(__u32 id, char *buf, int len);
> char* rtnl_rtrealm_n2a(int id, char *buf, int len);
> char* rtnl_dsfield_n2a(int id, char *buf, int len);
> +char* rtnl_ifgroup_n2a(int id, char *buf, int len);
> int rtnl_rtprot_a2n(__u32 *id, char *arg);
> int rtnl_rtscope_a2n(__u32 *id, char *arg);
> int rtnl_rttable_a2n(__u32 *id, char *arg);
> int rtnl_rtrealm_a2n(__u32 *id, char *arg);
> int rtnl_dsfield_a2n(__u32 *id, char *arg);
> +int rtnl_ifgroup_a2n(__u32 *id, char *arg);
Shouldn't rtnl_ifgroup_n2a() using __u32 for "id"? It is actually handed
a __u32 value.
> diff --git a/lib/rt_names.c b/lib/rt_names.c
> index 8d019a0..a067e74 100644
> --- a/lib/rt_names.c
> +++ b/lib/rt_names.c
> @@ -446,3 +446,65 @@ int rtnl_dsfield_a2n(__u32 *id, char *arg)
> return 0;
> }
>
> +static char * rtnl_rtifgroup_tab[256] = {
> + "0",
> +};
> +
> +static int rtnl_rtifgroup_init;
> +
> +static void rtnl_rtifgroup_initialize(void)
> +{
> + rtnl_rtifgroup_init = 1;
> + rtnl_tab_initialize("/etc/iproute2/rt_ifgroup",
> + rtnl_rtifgroup_tab, 256);
> +}
> +
> +char * rtnl_ifgroup_n2a(int id, char *buf, int len)
> +{
> + if (id<0 || id>=256) {
> + snprintf(buf, len, "%d", id);
> + return buf;
> + }
Shouldn't we better use "hex" here? "hex" is used for values up to 255
and iptables matches use hex for all values as well.
(__u32 change proposed above will make "id<0" pointless.)
> + if (!rtnl_rtifgroup_tab[id]) {
> + if (!rtnl_rtifgroup_init)
> + rtnl_rtifgroup_initialize();
> + }
> + if (rtnl_rtifgroup_tab[id])
> + return rtnl_rtifgroup_tab[id];
> + snprintf(buf, len, "0x%02x", id);
> + return buf;
> +}
> +int rtnl_ifgroup_a2n(__u32 *id, char *arg)
> +{
> + static char *cache = NULL;
> + static unsigned long res;
> + char *end;
> + int i;
> +
> + if (cache && strcmp(cache, arg) == 0) {
> + *id = res;
> + return 0;
> + }
> +
> + if (!rtnl_rtifgroup_init)
> + rtnl_rtifgroup_initialize();
> +
> + for (i=0; i<256; i++) {
> + if (rtnl_rtifgroup_tab[i] &&
> + strcmp(rtnl_rtifgroup_tab[i], arg) == 0) {
> + cache = rtnl_rtifgroup_tab[i];
> + res = i;
> + *id = res;
> + return 0;
> + }
> + }
> +
> + res = strtoul(arg, &end, 16);
Why should we hardcode base 16 here. strtoul can handle dec and hex
(0x..) just fine. The iptables matches are usign strtoul(,,0) as
well.
> + if (!end || end == arg || *end || res > 255)
> + return -1;
Why do you restrict to values <=255? iptables match does not limit
and I do not really understand why I should restrict the values here.
(Even if they may not have a textual representation.)
Best regards,
Lutz
--
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG /protecting industrial networks/
tel: +49.30.6392-3308
fax: +49.30.6392-3307
Albert-Einstein-Str. 14
D-12489 Berlin, Germany
www.innominate.com
Register Court: AG Charlottenburg, HR B 81603
Management Board: Joachim Fietz, Dirk Seewald
Chairman of the Supervisory Board: Edward M. Stadum
Visit us at the SPS/IPC/Drives in Nuremberg / Germany
27 - 29 November 2007, Hall 9, Stand 9-141
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][UNIX] Move the unix sock iterators in to proper place
On Thu, Nov 22, 2007 at 04:22:30PM +0300, Pavel Emelyanov wrote:
> The first_unix_socket() and next_unix_sockets() are now used
> in proc file and in forall_unix_socets macro only.
>
> The forall_unix_sockets is not used in this file at all so
> remove it. After this move the helpers to where they really
> belong, i.e. closer to proc code under the #ifdef CONFIG_PROC_FS
> option.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Patch applied. Thanks Pavel!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [NET]: Fix TX bug VLAN in VLAN
This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=8766
Is it possible?
BUG((veth->h_vlan_proto != htons(ETH_P_8021Q)) && !(VLAN_DEV_INFO(dev)->flags &
VLAN_FLAG_REORDER_HDR))
I'm afraid, queued packet before vconfig set_flag would do that.
Thanks.
Joonwoo
[NET]: Fix TX bug VLAN in VLAN
Fix misbehavior of vlan_dev_hard_start_xmit() for recursive encapsulations.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 7a36878..3e34990 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -454,7 +454,9 @@ int vlan_dev_hard_header(struct sk_buff *skb, struct
net_device *dev,
int vlan_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct net_device_stats *stats = vlan_dev_get_stats(dev);
+#ifdef VLAN_DEBUG
struct vlan_ethhdr *veth = (struct vlan_ethhdr *)(skb->data);
+#endif
/* Handle non-VLAN frames if they are sent to us, for example by DHCP.
*
@@ -462,7 +464,7 @@ int vlan_dev_hard_start_xmit(struct sk_buff *skb, struct
net_device *dev)
* OTHER THINGS LIKE FDDI/TokenRing/802.3 SNAPs...
*/
- if (veth->h_vlan_proto != htons(ETH_P_8021Q)) {
+ if (VLAN_DEV_INFO(dev)->flags & VLAN_FLAG_REORDER_HDR) {
int orig_headroom = skb_headroom(skb);
unsigned short veth_TCI;
---
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2.6.24 1/1]S2io: Fixed memory leak by freeing MSI-X local entry memories when vector allocation fails
Jeff, We got an ACK back last week from Dave Miller that the following 2 patches were already applied - reply follows. " > [Ram] The version numbers are different for the 2 patches. Was the > MSI-X leak bug fix applied prior to resubmission (we had swapped the > version numbers on the patches for resubmission). > > [PATCH 2.6.24 1/1]S2io: Fixed memory leak by freeing MSI-X local entry > memories when vector allocation fails > +#define DRV_VERSION "2.0.26.6" > > [PATCH 2.6.24 1/1]S2io: Support for add/delete/store/restore ethernet > addresses > +#define DRV_VERSION "2.0.26.7" I applied only the leak fix to the stable branch, and only the ethernet address support patch to the 2.6.25 development tree. The bug fix will show up later when the 2.6.25 development tree gets rebased to upstream (which will have the leak fix by then). This is how I do things, and that's why changing the DRV_VERSION to 2.0.26.7 made no sense. Therefore it makes the most sense to bump driver version numbers only when things are entirely self contained." Ram > -Original Message- > From: Jeff Garzik [mailto:[EMAIL PROTECTED] > Sent: Friday, November 23, 2007 7:03 PM > To: Sreenivasa Honnur > Cc: netdev@vger.kernel.org; support > Subject: Re: [PATCH 2.6.24 1/1]S2io: Fixed memory leak by freeing MSI-X > local entry memories when vector allocation fails > > Sreenivasa Honnur wrote: > > - Fixed memory leak by freeing MSI-X local entry memories when vector > allocation > > fails in s2io_add_isr. > > - Added two utility functions remove_msix_isr and remove_inta_isr to > eliminate > > code duplication. > > - Incorporated following review comments from Jeff > > - Removed redundant stats->mem_freed and synchronize_irq call > > - do_rem_msix_isr is renamed as remove_msix_isr > > - do_rem_inta_isr is renamed as remove_inta_isr > > > > - (Resubmit third time) > > ditto, does not apply > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at > > kernel/softirq.c:139 local_bh_enable() > > [2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97 > > [2059664.620657] [<8011c205>] __call_console_drivers+0x61/0x6d > > [2059664.620669] [<8011c3fc>] release_console_sem+0x164/0x1bf > > [2059664.620679] [<8011c81f>] vprintk+0x27a/0x2ff > If that trace is to be beieved we're doing nefilter stuff on packets which > were sent across netconsole. > > This probably isn't anything the netfilter guys have thought about. And > probably we don't want them to. Is there some simple way in which we can > exempt netconsole from netfilter processing? This is not about netfilter, but about freeing skb in interrupt context, which is not allowed, and in interrupt skbs are queued to be freed in softirq, but netcnsole wants to flush softirq freeing queue. That is a question: why? Removing zap_completion_queue() from find_skb() will fix the warning, but I'm not sure this is a correct fix. I've added Matt to the Cc list. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9440] New: Problem in joinning a socket to ipv6 multicast address in specific scenario
On Thu, Nov 22, 2007 at 05:23:42PM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: > > 3. Now i am running a program i wrote in c that opens a dgram socket > > (sock_fd[i] = socket(test_data->protocol, SOCK_DGRAM, 0);) and join it to > > multicast ipv6 address. > > if i am running this program after steps 1+2 i get the following error: > > "Resource temporarily unavailable" when trying to join the socket to the > > multicast ipv6 address by the > > system call : Could you provide a test application? Given it is small and can be ran without external dependencies, it will be fixed way much faster. Thanks. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Blackfin EMAC driver: fix bug - NAT doesn't work with bfin_mac driver
From: Vitja Makarov <[EMAIL PROTECTED]> https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&forum_id=39&thread_id=23114&_forum_action=ForumMessageBrowse Today I was dealing with the same problem, on my custom bf537 board, and bfin_mac driver. I found that the problem is in setting ip_summed flag of skbuff structure, Signed-off-by: Vitja Makarov <[EMAIL PROTECTED]> Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- drivers/net/bfin_mac.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c index 0b99b55..eb97175 100644 --- a/drivers/net/bfin_mac.c +++ b/drivers/net/bfin_mac.c @@ -676,7 +676,7 @@ static void bf537mac_rx(struct net_device *dev) skb->protocol = eth_type_trans(skb, dev); #if defined(BFIN_MAC_CSUM_OFFLOAD) skb->csum = current_rx_ptr->status.ip_payload_csum; - skb->ip_summed = CHECKSUM_PARTIAL; + skb->ip_summed = CHECKSUM_COMPLETE; #endif netif_rx(skb); -- 1.5.3.4 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] SO_NO_CHECK for IPv6
David Schwartz <[EMAIL PROTECTED]> wrote:
>
>> Regardless of whatever verifications your application is doing
>> on the data, it is not checksumming the ports and that's what
>> the pseudo-header is helping with.
>
> So what? We are in the case where the data has already gotten to him. If it
> got to him in error, he'll reject it anyway. The receive checksum check will
> only reject packets that he would reject anyway. That makes it needless.
What if it goes to the wrong recipient who doesn't have the upper-
level checksums?
This is the whole point, IPv6 unlike IPv4 does not have IP header
checksums so the high-level needs to protect it by checksumming
the pseudo-header.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ethtool: add support for supporting 10000baseT
Auke Kok wrote: From: Jesse Brandeburg <[EMAIL PROTECTED]> there is missing support in ethtool for reporting 1baseT as SUPPORTED_1baseT_Full. The code seems to be half implemented because the "advertising" field has the implementation. this patch just adds it for supported reporting. Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- ethtool.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] forcedeth new mcp79 device ids
Ayaz Abdulla wrote: This patch adds new device ids for mcp79 devices. Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]> applied 1-2 to #upstream-fixes, after combining into a single patch - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 04/22] NET: DM9000: Add initial ethtool support
if ETHTOOL_GDRVINFO bus info is not PCI, you must add a prefix a la 3c59x.c or eepro.c - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
> Here's another thought: move all this logic into the networking core,
> unify it with current softirq zapper, then allow it to be called from
> various other places (like atomic allocators). Then it'll all be in
> central maintained place with more users.
This can be done quite easily - put a check into __kfree_skb() if
netpoll is compiled-in and we are in hardirq context, then put skb
into softirq freeing queue. Then zap_completion_queue() can free
anything without ever knowing about nature of the packet, since this
will be checked in __kfree_skb() anyway.
Kind of this:
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 758dafe..88f8ea9 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -196,10 +196,7 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
- dev_kfree_skb_any(skb); /* put this one back */
- else
- __kfree_skb(skb);
+ __kfree_skb(skb);
}
}
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 27cfe5f..f720685 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -318,6 +318,12 @@ void kfree_skbmem(struct sk_buff *skb)
void __kfree_skb(struct sk_buff *skb)
{
+#if defined(CONFIG_NETPOLL) || defined(CONFIG_NETPOLL_TRAP)
+ if (in_irq() || irqs_disabled()) {
+ dev_kfree_skb_irq(skb);
+ return;
+ }
+#endif
dst_release(skb->dst);
#ifdef CONFIG_XFRM
secpath_put(skb->sp);
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > Stop, we are trying to free skb without destructor and catch connection
> > tracking, so it is not a solution. To fix the problem we need to check
> > if it is not netfilter related, kind of this (not tested), Simon please
> > give it a try:
>
> And to be really cool we need to bypass skbs with xfrm attached, since
> its freeing also assumes BH context.
What about compile options?
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 758dafe..adb3c54 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -196,10 +196,25 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
+ if (skb->destructor) {
dev_kfree_skb_any(skb); /* put this one back */
- else
- __kfree_skb(skb);
+ continue;
+ }
+
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ if (skb->nfct || skb->nfct_reasm) {
+ dev_kfree_skb_any(skb); /* put this one back */
+ continue;
+ }
+#endif
+
+#ifdef CONFIG_XFRM
+ if (skb->sp) {
+ dev_kfree_skb_any(skb); /* put this one back */
+ continue;
+ }
+#endif
+ __kfree_skb(skb);
}
}
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 11:07:56AM -0600, Matt Mackall ([EMAIL PROTECTED]) wrote: > On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote: > > On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED]) > > wrote: > > > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at > > > > kernel/softirq.c:139 local_bh_enable() > > > > [2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97 > > > > > > [2059664.620657] [<8011c205>] __call_console_drivers+0x61/0x6d > > > > [2059664.620669] [<8011c3fc>] release_console_sem+0x164/0x1bf > > > > [2059664.620679] [<8011c81f>] vprintk+0x27a/0x2ff > > > > > If that trace is to be beieved we're doing nefilter stuff on packets which > > > were sent across netconsole. > > > > > > This probably isn't anything the netfilter guys have thought about. And > > > probably we don't want them to. Is there some simple way in which we can > > > exempt netconsole from netfilter processing? > > > > This is not about netfilter, but about freeing skb in interrupt context, > > which is not allowed, and in interrupt skbs are queued to be freed in > > softirq, > > but netcnsole wants to flush softirq freeing queue. That is a question: why? > > My memory here is hazy, but I think this exists to rescue netconsole > in low-memory situations. This bit originated with Ingo, so maybe he > can recall. > > Netpoll can process an arbitrary number of skbs inside a single > interrupt. Think sysrq-t at one packet per line or kgdboe where the > entire trace session can happen inside one very long interrupt. > > Perhaps we can refine this to mark netpoll's skbs (perhaps with > ->destructor?) and delete only skbs we own. As these are never passed > through any of the other route/xfrm/filter code, they should be safe > to delete even in irq context, yes? > > > Removing zap_completion_queue() from find_skb() will fix the warning, > > but I'm not sure this is a correct fix. I've added Matt to the Cc list. > > Care to try the sysrq-t or OOM message tests? We basically can not free skbs there - if it is interrupt context and we are freeing some skb with destructor we will catch the warning anyway. No matter if we are under memory pressure or whatever - it is not allowed - a lot of skbs are supposed to be freed in softirq context, that is why dev_kfree_skb_any() exists. I think we can drop skbs _without_ destructor from the queue though in that conditions given that we actually need only one. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25] [TCP]: Move FRTO checks out from write queue abstraction funcs
On Fri, Nov 23, 2007 at 04:14:03PM +0200, Ilpo Järvinen wrote:
>
> The purpose of the tcp_advance_send_head & friends was/is to abstract
> the write queue from the TCP worker code. RB-tree wq can then be put in
> place more easily (and I'm hopefully coming to that soon). There are some
> other similar functions in tcp.h as well which currently have only a
> single caller. Please don't undo that work while DaveM is away for a short
> while :-).
Thanks for the explanation! I'll apply this patch.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][UNIX] Move the unix sock iterators in to proper place
Herbert Xu wrote: > On Thu, Nov 22, 2007 at 04:22:30PM +0300, Pavel Emelyanov wrote: >> The first_unix_socket() and next_unix_sockets() are now used >> in proc file and in forall_unix_socets macro only. >> >> The forall_unix_sockets is not used in this file at all so >> remove it. After this move the helpers to where they really >> belong, i.e. closer to proc code under the #ifdef CONFIG_PROC_FS >> option. >> >> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> > > Patch applied. Thanks Pavel! I'm afraid to become importunate, but is the net-2.6 (not 25) tree is currently the David's tree (unlike net-2.6.25, which has temporary switched to your one)? Thanks, Pavel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ZD1211RW unaligned accesses...
> The problem is > drivers/net/wireless/zd1211/zd_mac.c:update_qual_rssi(). > Specifically the compare_ether_addr() call I don't believe this is true. Shaddy seems to back that up by the patch not helping. > Wireless folks, I would suggest we do some auditing of the > compare_ether_addr() calls and for the ones that are operating > on these potentially unaligned structs we change it to either > a straight memcmp() or some new routine which will more reflect > the issue (say something like "compare_ether_addr_unaligned()" > or "ieee80211_compare_ether_addr()"). All MAC addresses in 802.11 headers are at least aligned on 16-bit boundaries. Hence, if the some MAC address like the BSSID here was unaligned we'd also have the IP header unaligned causing a lot more trouble than this. Shaddy, please rebuild zd1211 with the patch below, it should make the compiler not inline all those static functions allowing us to pinpoint much better where the problem occurs. You will probably need to delete all *.o files in the zd1211rw/ directory to the them rebuilt after the Makefile change. --- everything.orig/drivers/net/wireless/zd1211rw/Makefile 2007-11-23 11:36:30.652094075 +0100 +++ everything/drivers/net/wireless/zd1211rw/Makefile 2007-11-23 11:36:57.112090711 +0100 @@ -1,5 +1,7 @@ obj-$(CONFIG_ZD1211RW) += zd1211rw.o +EXTRA_CFLAGS += -fno-inline-functions-called-once + zd1211rw-objs := zd_chip.o zd_ieee80211.o \ zd_mac.o zd_netdev.o \ zd_rf_al2230.o zd_rf_rf2959.o \ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
cassini driver hw checksum errors with vlans
Hello, When we use cassini driver without VLANs, it works as expected but when about 100 VLANs are configured on this interface, the hardware checksum fails. What is its reason or how can we debug it? -- Attila - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Blackfin SMC91x Driver: punt CONFIG_BFIN -- we already have CONFIG_BLACKFIN
From: Mike Frysinger <[EMAIL PROTECTED]> Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- drivers/net/Kconfig |2 +- drivers/net/smc91x.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index e8d69b0..1437b37 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -888,7 +888,7 @@ config SMC91X tristate "SMC 91C9x/91C1xxx support" select CRC32 select MII - depends on ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || SOC_AU1X00 || BFIN + depends on ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || SOC_AU1X00 || BLACKFIN help This is a driver for SMC's 91x series of Ethernet chipsets, including the SMC91C94 and the SMC91C111. Say Y if you want it diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h index db34e1e..07b7f71 100644 --- a/drivers/net/smc91x.h +++ b/drivers/net/smc91x.h @@ -55,7 +55,7 @@ #define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) #define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l) -#elif defined(CONFIG_BFIN) +#elif defined(CONFIG_BLACKFIN) #define SMC_IRQ_FLAGS IRQF_TRIGGER_HIGH #define RPC_LSA_DEFAULTRPC_LED_100_10 -- 1.5.3.4 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless vs. alignment requirements
Johannes Berg <[EMAIL PROTECTED]> wrote:
>
> Now, the IP stack actually assumes that its header is four-byte aligned
> (see comment at NET_IP_ALIGN, although it is not said explicitly that
> the alignment requirement for an IP header is four) so that is actually
> something for the hardware/firmware (!) to do, for example Broadcom
Good point. In fact IIRC we've always had the policy that drivers
should do their best to generate aligned packets but it is not a
requirement since on some platforms it's more important for the DMA
to be aligned.
So it's up the platform code to fix up any exceptions should they
show up.
Daniel, what's the specific case that you had in mind with this
patch?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 2/3] Interface group: core (netlink) part
On Tue, Nov 20, 2007 at 02:14:26PM +0100, Laszlo Attila Toth wrote:
> Interface groups let handle different interfaces together.
> Modified net device structure and netlink interface.
>
> Signed-off-by: Laszlo Attila Toth <[EMAIL PROTECTED]>
> ---
> include/linux/if_link.h |2 ++
> include/linux/netdevice.h |2 ++
> net/core/rtnetlink.c | 11 +++
> 3 files changed, 15 insertions(+), 0 deletions(-)
Adding read/write support via sysfs should not be too difficult:
diff -ruN a/net/core/net-sysfs.c b/net/core/net-sysfs.c
--- a/net/core/net-sysfs.c 2007-11-17 06:16:36.0 +0100
+++ b/net/core/net-sysfs.c 2007-11-23 14:04:47.0 +0100
@@ -219,6 +219,20 @@
return netdev_store(dev, attr, buf, len, change_tx_queue_len);
}
+NETDEVICE_SHOW(ifgroup, fmt_hex);
+
+static int change_ifgroup(struct net_device *net, unsigned long new_ifgroup)
+{
+ net->ifgroup = new_ifgroup;
+ return 0;
+}
+
+static ssize_t store_ifgroup(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ return netdev_store(dev, attr, buf, len, change_ifgroup);
+}
+
static struct device_attribute net_class_attributes[] = {
__ATTR(addr_len, S_IRUGO, show_addr_len, NULL),
__ATTR(iflink, S_IRUGO, show_iflink, NULL),
@@ -235,6 +249,7 @@
__ATTR(flags, S_IRUGO | S_IWUSR, show_flags, store_flags),
__ATTR(tx_queue_len, S_IRUGO | S_IWUSR, show_tx_queue_len,
store_tx_queue_len),
+ __ATTR(ifgroup, S_IRUGO | S_IWUSR, show_ifgroup, store_ifgroup),
{}
};
--
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG /protecting industrial networks/
tel: +49.30.6392-3308
fax: +49.30.6392-3307
Albert-Einstein-Str. 14
D-12489 Berlin, Germany
www.innominate.com
Register Court: AG Charlottenburg, HR B 81603
Management Board: Joachim Fietz, Dirk Seewald
Chairman of the Supervisory Board: Edward M. Stadum
Visit us at the SPS/IPC/Drives in Nuremberg / Germany
27 - 29 November 2007, Hall 9, Stand 9-141
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add compare_ether_addr_unaligned
On Fri, Nov 23, 2007 at 12:09:22AM +, Daniel Drake wrote:
> David Miller found a problem in a wireless driver where I was using
> compare_ether_addr() on potentially unaligned data. Document that
> compare_ether_addr() is not safe for use everywhere, and add an equivalent
> function that works regardless of alignment.
>
> Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Patch applied to net-2.6. Thanks.
I presume there will be some follow-on work to use this function?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at > > > kernel/softirq.c:139 local_bh_enable() > > > [2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97 > > > > [2059664.620657] [<8011c205>] __call_console_drivers+0x61/0x6d > > > [2059664.620669] [<8011c3fc>] release_console_sem+0x164/0x1bf > > > [2059664.620679] [<8011c81f>] vprintk+0x27a/0x2ff > > > If that trace is to be beieved we're doing nefilter stuff on packets which > > were sent across netconsole. > > > > This probably isn't anything the netfilter guys have thought about. And > > probably we don't want them to. Is there some simple way in which we can > > exempt netconsole from netfilter processing? > > This is not about netfilter, but about freeing skb in interrupt context, > which is not allowed, and in interrupt skbs are queued to be freed in softirq, > but netcnsole wants to flush softirq freeing queue. That is a question: why? My memory here is hazy, but I think this exists to rescue netconsole in low-memory situations. This bit originated with Ingo, so maybe he can recall. Netpoll can process an arbitrary number of skbs inside a single interrupt. Think sysrq-t at one packet per line or kgdboe where the entire trace session can happen inside one very long interrupt. Perhaps we can refine this to mark netpoll's skbs (perhaps with ->destructor?) and delete only skbs we own. As these are never passed through any of the other route/xfrm/filter code, they should be safe to delete even in irq context, yes? > Removing zap_completion_queue() from find_skb() will fix the warning, > but I'm not sure this is a correct fix. I've added Matt to the Cc list. Care to try the sysrq-t or OOM message tests? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9443] New: RFC4193 IPv6 addresses seem not to be completly supported : default gateway not set
On Fri, 23 Nov 2007 05:42:35 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9443 > >Summary: RFC4193 IPv6 addresses seem not to be completly > supported : default gateway not set >Product: Networking >Version: 2.5 > KernelVersion: 2.6.22-3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV6 > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Most recent kernel where this bug did not occur: unknown > Distribution: DEBIAN SID > Hardware Environment: tested on COMPAQ Deskpro EN and VMware Workstation > Software Environment: reproduced in Kernel Version 2.6.22-14 (UBUNTU) > Problem Description: > > RFC4193 defines fc00::/8 and fd00::/8 IPv6 addresses known as "Local IPv6 > addresses" and stated that "They are not expected to be routable on the global > Internet" and "They are routable inside of a more limited area such a site". > RFC4193 addresses are the equivalent of RFC1918 IPv4 addresses for IPv6. > > When using this kind of address as "static" (iface ... static), the default > gateway is not set (see the result of the command route -6 : ::/0 route is > missing), so sending such IPv6 packets outside the local LAN is not possible. > > > > Steps to reproduce: > > debian:~# cat /etc/network/interfaces > # This file describes the network interfaces available on your system > # and how to activate them. For more information, see interfaces(5). > > # The loopback network interface > auto lo > iface lo inet loopback > > # The primary network interface > allow-hotplug eth0 > iface eth0 inet dhcp > iface eth0 inet6 static > pre-up modprobe ipv6 > address fd12:3000:4000:5000::1 > netmask 64 > gateway fd12:3000:4000:5000::100 > debian:~# > > debian:~# ifconfig > eth0 Link encap:Ethernet HWaddr 00:0C:29:B8:53:3B > inet addr:192.168.19.135 Bcast:192.168.19.255 Mask:255.255.255.0 > inet6 addr: fd12:3000:4000:5000::1/64 Scope:Global > inet6 addr: fe80::20c:29ff:feb8:533b/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:262 errors:0 dropped:0 overruns:0 frame:0 > TX packets:141 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:28702 (28.0 KiB) TX bytes:20060 (19.5 KiB) > Interrupt:17 Base address:0x1080 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:8 errors:0 dropped:0 overruns:0 frame:0 > TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:560 (560.0 b) TX bytes:560 (560.0 b) > > debian:~# > > debian:~# route -6 > Kernel IPv6 routing table > Destination Next Hop Flags Metric Ref > Use Iface > ::1/128 :: U 0 4 1 lo > fd12:3000:4000:5000::1/128 :: U 0 0 1 lo > fd12:3000:4000:5000::/64:: U 2560 0 eth0 > fe80::20c:29ff:feb8:533b/128:: U 0 0 1 lo > fe80::/64 :: U 2560 0 eth0 > ff00::/8:: U 2560 0 eth0 > debian:~# > > And adding the default route manually gives an error : > > debian:~# route -A inet6 add ::/0 gw fd12:3000:4000:5000::100 eth0 > SIOCADDRT: Invalid argument > debian:~# > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] PowerPC: ibm_newemac minor fixes.
These patches have some minor ibm_newemac fixes. Thanks, Valentine. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] PowerPC: ibm_newemac correct opb_bus_freq value
The EMAC4_MR1_OBCI(freq) macro expects freg in MHz,
while opb_bus_freq is kept in Hz. Correct this.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c
linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2007-11-23
21:27:57.0 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c2007-11-23 21:47:53.0
+0300
@@ -402,7 +402,7 @@ static u32 __emac_calc_base_mr1(struct e
static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int
rx_size)
{
u32 ret = EMAC_MR1_VLE | EMAC_MR1_IST | EMAC4_MR1_TR |
- EMAC4_MR1_OBCI(dev->opb_bus_freq);
+ EMAC4_MR1_OBCI(dev->opb_bus_freq / 100);
DBG2(dev, "__emac4_calc_base_mr1" NL);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 12:59:43PM -0600, Matt Mackall ([EMAIL PROTECTED]) wrote: > So I'd be surprised if that was a problem. But I can imagine having > problems for skbs without destructors which run into one of these in > __kfree_skb: > > dst_release > secpath_put > nf_conntrack_put > nf_conntrack_put_reasm > nf_bridge_put > > ..some or all of which assume a softirq context. bridging is ok, others require softirq context. I've sent a patch (the last one should be ok) to guard against xfrm and connection tracking. > > No matter if we are under memory pressure or whatever - it is not > > allowed - a lot of skbs are supposed to be freed in softirq context, > > that is why dev_kfree_skb_any() exists. > > Some skbs we definitely -can- free in irq context. The only ones we > care about are the ones generated by netpoll. If there's a reason you > think netpoll's own skbs can't be freed, please describe it. Only some and to distinguish them we can not use destructor - if it is set (even empty function) it will fire an alarm. > > I think we can drop skbs _without_ destructor from the queue though in > > that conditions given that we actually need only one. > > Huh? Don't mind - friday... I posted a patch (third one should be ok) to fix this issue. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] PowerPC: ibm_newemac tah_ph typo fix
This patch fixes a typo in ibm_newemac/core.c (tah_port should be used instead of tah_ph) Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> --- drivers/net/ibm_newemac/core.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c --- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2007-11-23 21:27:57.0 +0300 +++ linux-2.6/drivers/net/ibm_newemac/core.c2007-11-23 21:36:00.0 +0300 @@ -2427,7 +2427,7 @@ static int __devinit emac_init_config(st if (emac_read_uint_prop(np, "tah-device", &dev->tah_ph, 0)) dev->tah_ph = 0; if (emac_read_uint_prop(np, "tah-channel", &dev->tah_port, 0)) - dev->tah_ph = 0; + dev->tah_port = 0; if (emac_read_uint_prop(np, "mdio-device", &dev->mdio_ph, 0)) dev->mdio_ph = 0; if (emac_read_uint_prop(np, "zmii-device", &dev->zmii_ph, 0)) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] PowerPC: ibm_newemac call dev_set_drvdata() before tah_reset()
The patch moves dev_set_drvdata(&ofdev->dev, dev) up before tah_reset(ofdev) is called to avoid a NULL pointer dereference, since tah_reset uses drvdata. Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> --- drivers/net/ibm_newemac/tah.c |3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/tah.c linux-2.6/drivers/net/ibm_newemac/tah.c --- linux-2.6.orig/drivers/net/ibm_newemac/tah.c2007-11-23 21:27:57.0 +0300 +++ linux-2.6/drivers/net/ibm_newemac/tah.c 2007-11-23 21:35:12.0 +0300 @@ -116,13 +116,14 @@ static int __devinit tah_probe(struct of goto err_free; } + dev_set_drvdata(&ofdev->dev, dev); + /* Initialize TAH and enable IPv4 checksum verification, no TSO yet */ tah_reset(ofdev); printk(KERN_INFO "TAH %s initialized\n", ofdev->node->full_name); wmb(); - dev_set_drvdata(&ofdev->dev, dev); return 0; - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 10:15:24PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 12:59:43PM -0600, Matt Mackall ([EMAIL PROTECTED]) > wrote: > > So I'd be surprised if that was a problem. But I can imagine having > > problems for skbs without destructors which run into one of these in > > __kfree_skb: > > > > dst_release > > secpath_put > > nf_conntrack_put > > nf_conntrack_put_reasm > > nf_bridge_put > > > > ..some or all of which assume a softirq context. > > bridging is ok, others require softirq context. > I've sent a patch (the last one should be ok) to guard against xfrm and > connection tracking. > > > > No matter if we are under memory pressure or whatever - it is not > > > allowed - a lot of skbs are supposed to be freed in softirq context, > > > that is why dev_kfree_skb_any() exists. > > > > Some skbs we definitely -can- free in irq context. The only ones we > > care about are the ones generated by netpoll. If there's a reason you > > think netpoll's own skbs can't be freed, please describe it. > > Only some and to distinguish them we can not use destructor - if it is > set (even empty function) it will fire an alarm. Yep, please look at the patch I just posted. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 10:32:22PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 01:11:20PM -0600, Matt Mackall ([EMAIL PROTECTED]) > wrote: > > On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote: > > > On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL > > > PROTECTED]) wrote: > > > > On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL > > > > PROTECTED]) wrote: > > > > > Stop, we are trying to free skb without destructor and catch > > > > > connection > > > > > tracking, so it is not a solution. To fix the problem we need to check > > > > > if it is not netfilter related, kind of this (not tested), Simon > > > > > please > > > > > give it a try: > > > > > > > > And to be really cool we need to bypass skbs with xfrm attached, since > > > > its freeing also assumes BH context. > > > > > > What about compile options? > > > > What about my original suggestion that we mark skbs owned by netpoll > > and free only those. Much safer, no? Untested: > > This should work if there are netpoll's skbs, but if we are under memory > pressure we want to free not only netpoll skbs, but at least one, and > what if there are no netpoll skbs in the queue? Yeah, that's a concern (but note that we do have a private reserve and we only really need the zap when our reserve is depleted). But I worry that it's too fragile and if we add a new unsafe case, it won't be noticed for a long time. This is the first report I've seen of this particular problem, so this has been a latent bug for three or four years now. Here's another thought: move all this logic into the networking core, unify it with current softirq zapper, then allow it to be called from various other places (like atomic allocators). Then it'll all be in central maintained place with more users. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
wireless vs. alignment requirements
> David Miller found a problem in a wireless driver where I was using > compare_ether_addr() on potentially unaligned data. Document that > compare_ether_addr() is not safe for use everywhere, and add an equivalent > function that works regardless of alignment. FWIW, as I've said in the other thread I cannot believe this to be true since the IP header is required to be aligned anyway. So *iff* this really was a problem then we'd have much more problems and better fixed the alignment of the received USB urb in zd1211rw. Let me explain... This is going to take a bit of text... Marking optional fields with < > for better readability, you have this 802.11 header layout (including byte sizes): | FC (2) | durid (2) | A1 (6) | A2 (6) | A3 (6) | seq (2) ... < optional A4 (6) > < optional qos (2) > ... < optional HT (4) > < optional mesh (4 or 16) > (NOTE: not sure about the order of the last two, this will probably depend on the order in which 11n/11s are accepted! logically I would expect the order as I wrote it) (which makes it 24, 26, 30 or 32 bytes long plus the optional 11n/11s additions which are multiples of four) After that comes the data which may contain a SNAP header or such and then the rest. The SNAP header is six bytes plus two byte ethertype, or there could be a bridge tunnel header with six bytes plus two byte ethertype, or it could be missing completely, in all of these cases it's evenly divisible by four. Now, the IP stack actually assumes that its header is four-byte aligned (see comment at NET_IP_ALIGN, although it is not said explicitly that the alignment requirement for an IP header is four) so that is actually something for the hardware/firmware (!) to do, for example Broadcom firmware will insert two bytes padding before the PLCP header (6 bytes, sitting before the 802.11 header) if either the QoS field or A4 was present (and the header length thus wasn't a multiple of four). Atheros hardware will insert two bytes padding after the QoS field in the same cases (IIRC). Of course, you need to consider the RX header that sits before the 802.11 stuff. Broadcom's is 30 bytes, but if you add the six byte PLCP header you have 36 bytes which is divisible by four. In the QoS XOR A4 case they add two bytes which makes it 38 with two bytes to spare for 4-byte alignment which are eaten up by the QoS/A4 field. I don't know about any other hardware but considering that things work as well as they do I'd think they do similar things. Hence, going back to the 802.11 header and the IP header alignment requirement, if we get the IP header alignment requirement right now I cannot possibly see any way we would use compare_ether_addr() on an address that is not at least two-byte aligned as required. Whew. Or so I think. johannes signature.asc Description: This is a digitally signed message part
Re: [patch 14/22] NET: DM9000: Remove unnecessary changelog in header comment
ACK patches 8-14 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 05/22] NET: DM9000: Do not sleep with spinlock and IRQs held
ACK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 29/59] drivers/net/chelsio: Add missing "space"
Joe Perches wrote: Signed-off-by: Joe Perches <[EMAIL PROTECTED]> --- drivers/net/chelsio/cxgb2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) appied 29-36 to netdev#upstream - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
