* [patch 1/3] isdn: hisax, fix lock imbalance
From: akpm @ 2009-08-06 23:06 UTC (permalink / raw)
To: isdn; +Cc: netdev, akpm, jirislaby, Karsten-Keil
From: Jiri Slaby <jirislaby@gmail.com>
Add omittted unlocks to 2 functions.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Karsten Keil <Karsten-Keil@t-online.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/isdn/hisax/amd7930_fn.c | 1 +
drivers/isdn/hisax/icc.c | 1 +
2 files changed, 2 insertions(+)
diff -puN drivers/isdn/hisax/amd7930_fn.c~isdn-hisax-fix-lock-imbalance drivers/isdn/hisax/amd7930_fn.c
--- a/drivers/isdn/hisax/amd7930_fn.c~isdn-hisax-fix-lock-imbalance
+++ a/drivers/isdn/hisax/amd7930_fn.c
@@ -596,6 +596,7 @@ Amd7930_l1hw(struct PStack *st, int pr,
if (cs->debug & L1_DEB_WARN)
debugl1(cs, "Amd7930: l1hw: l2l1 tx_skb exist this shouldn't happen");
skb_queue_tail(&cs->sq, skb);
+ spin_unlock_irqrestore(&cs->lock, flags);
break;
}
if (cs->debug & DEB_DLOG_HEX)
diff -puN drivers/isdn/hisax/icc.c~isdn-hisax-fix-lock-imbalance drivers/isdn/hisax/icc.c
--- a/drivers/isdn/hisax/icc.c~isdn-hisax-fix-lock-imbalance
+++ a/drivers/isdn/hisax/icc.c
@@ -470,6 +470,7 @@ ICC_l1hw(struct PStack *st, int pr, void
if (cs->debug & L1_DEB_WARN)
debugl1(cs, " l2l1 tx_skb exist this shouldn't happen");
skb_queue_tail(&cs->sq, skb);
+ spin_unlock_irqrestore(&cs->lock, flags);
break;
}
if (cs->debug & DEB_DLOG_HEX)
_
^ permalink raw reply
* [patch 3/3] isdn: fix netjet build errors
From: akpm @ 2009-08-06 23:06 UTC (permalink / raw)
To: isdn; +Cc: netdev, akpm, randy.dunlap
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix netjet driver link errors when ISDN_I4L is not enabled:
drivers/built-in.o: In function `mode_tiger':
netjet.c:(.text+0x325dc8): undefined reference to `isdnhdlc_rcv_init'
netjet.c:(.text+0x325dd5): undefined reference to `isdnhdlc_out_init'
drivers/built-in.o: In function `fill_dma':
netjet.c:(.text+0x325fb6): undefined reference to `isdnhdlc_encode'
drivers/built-in.o: In function `read_dma':
netjet.c:(.text+0x32631a): undefined reference to `isdnhdlc_decode'
drivers/built-in.o: In function `nj_irq':
netjet.c:(.text+0x326e01): undefined reference to `isdnhdlc_encode'
or move isdnhdlc.c to some other sub-dir..
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/isdn/hardware/mISDN/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/isdn/hardware/mISDN/Kconfig~isdn-fix-netjet-build-errors drivers/isdn/hardware/mISDN/Kconfig
--- a/drivers/isdn/hardware/mISDN/Kconfig~isdn-fix-netjet-build-errors
+++ a/drivers/isdn/hardware/mISDN/Kconfig
@@ -78,6 +78,7 @@ config MISDN_NETJET
depends on PCI
select MISDN_IPAC
select ISDN_HDLC
+ select ISDN_I4L # so that make will recurse into sub-dir.
help
Enable support for Traverse Technologies NETJet PCI cards.
_
^ permalink raw reply
* [patch 2/3] hfc_usb: fix read buffer overflow
From: akpm @ 2009-08-06 23:06 UTC (permalink / raw)
To: isdn; +Cc: netdev, akpm, roel.kluin
From: Roel Kluin <roel.kluin@gmail.com>
Check whether index is within bounds before testing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/isdn/hisax/hfc_usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/isdn/hisax/hfc_usb.c~hfc_usb-fix-read-buffer-overflow drivers/isdn/hisax/hfc_usb.c
--- a/drivers/isdn/hisax/hfc_usb.c~hfc_usb-fix-read-buffer-overflow
+++ a/drivers/isdn/hisax/hfc_usb.c
@@ -817,8 +817,8 @@ collect_rx_frame(usb_fifo * fifo, __u8 *
}
/* we have a complete hdlc packet */
if (finish) {
- if ((!fifo->skbuff->data[fifo->skbuff->len - 1])
- && (fifo->skbuff->len > 3)) {
+ if (fifo->skbuff->len > 3 &&
+ !fifo->skbuff->data[fifo->skbuff->len - 1]) {
if (fifon == HFCUSB_D_RX) {
DBG(HFCUSB_DBG_DCHANNEL,
_
^ permalink raw reply
* [patch 1/1] proc connector: add event for process becoming session leader
From: akpm @ 2009-08-06 23:05 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, scott, johnpol, matthltc, oleg
From: Scott James Remnant <scott@ubuntu.com>
The act of a process becoming a session leader is a useful signal to a
supervising init daemon such as Upstart.
While a daemon will normally do this as part of the process of becoming a
daemon, it is rare for its children to do so. When the children do, it is
nearly always a sign that the child should be considered detached from the
parent and not supervised along with it.
The poster-child example is OpenSSH; the per-login children call setsid()
so that they may control the pty connected to them. If the primary daemon
dies or is restarted, we do not want to consider the per-login children
and want to respawn the primary daemon without killing the children.
This patch adds a new PROC_SID_EVENT and associated structure to the
proc_event event_data union, it arranges for this to be emitted when the
special PIDTYPE_SID pid is set.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
Acked-by: Matt Helsley <matthltc@us.ibm.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/connector/cn_proc.c | 25 +++++++++++++++++++++++++
include/linux/cn_proc.h | 10 ++++++++++
kernel/exit.c | 4 +++-
3 files changed, 38 insertions(+), 1 deletion(-)
diff -puN drivers/connector/cn_proc.c~proc-connector-add-event-for-process-becoming-session-leader drivers/connector/cn_proc.c
--- a/drivers/connector/cn_proc.c~proc-connector-add-event-for-process-becoming-session-leader
+++ a/drivers/connector/cn_proc.c
@@ -139,6 +139,31 @@ void proc_id_connector(struct task_struc
cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
}
+void proc_sid_connector(struct task_struct *task)
+{
+ struct cn_msg *msg;
+ struct proc_event *ev;
+ struct timespec ts;
+ __u8 buffer[CN_PROC_MSG_SIZE];
+
+ if (atomic_read(&proc_event_num_listeners) < 1)
+ return;
+
+ msg = (struct cn_msg *)buffer;
+ ev = (struct proc_event *)msg->data;
+ get_seq(&msg->seq, &ev->cpu);
+ ktime_get_ts(&ts); /* get high res monotonic timestamp */
+ put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
+ ev->what = PROC_EVENT_SID;
+ ev->event_data.sid.process_pid = task->pid;
+ ev->event_data.sid.process_tgid = task->tgid;
+
+ memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
+ msg->ack = 0; /* not used */
+ msg->len = sizeof(*ev);
+ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
+}
+
void proc_exit_connector(struct task_struct *task)
{
struct cn_msg *msg;
diff -puN include/linux/cn_proc.h~proc-connector-add-event-for-process-becoming-session-leader include/linux/cn_proc.h
--- a/include/linux/cn_proc.h~proc-connector-add-event-for-process-becoming-session-leader
+++ a/include/linux/cn_proc.h
@@ -52,6 +52,7 @@ struct proc_event {
PROC_EVENT_EXEC = 0x00000002,
PROC_EVENT_UID = 0x00000004,
PROC_EVENT_GID = 0x00000040,
+ PROC_EVENT_SID = 0x00000080,
/* "next" should be 0x00000400 */
/* "last" is the last process event: exit */
PROC_EVENT_EXIT = 0x80000000
@@ -89,6 +90,11 @@ struct proc_event {
} e;
} id;
+ struct sid_proc_event {
+ __kernel_pid_t process_pid;
+ __kernel_pid_t process_tgid;
+ } sid;
+
struct exit_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
@@ -102,6 +108,7 @@ struct proc_event {
void proc_fork_connector(struct task_struct *task);
void proc_exec_connector(struct task_struct *task);
void proc_id_connector(struct task_struct *task, int which_id);
+void proc_sid_connector(struct task_struct *task);
void proc_exit_connector(struct task_struct *task);
#else
static inline void proc_fork_connector(struct task_struct *task)
@@ -114,6 +121,9 @@ static inline void proc_id_connector(str
int which_id)
{}
+static inline void proc_sid_connector(struct task_struct *task)
+{}
+
static inline void proc_exit_connector(struct task_struct *task)
{}
#endif /* CONFIG_PROC_EVENTS */
diff -puN kernel/exit.c~proc-connector-add-event-for-process-becoming-session-leader kernel/exit.c
--- a/kernel/exit.c~proc-connector-add-event-for-process-becoming-session-leader
+++ a/kernel/exit.c
@@ -359,8 +359,10 @@ void __set_special_pids(struct pid *pid)
{
struct task_struct *curr = current->group_leader;
- if (task_session(curr) != pid)
+ if (task_session(curr) != pid) {
change_pid(curr, PIDTYPE_SID, pid);
+ proc_sid_connector(curr);
+ }
if (task_pgrp(curr) != pid)
change_pid(curr, PIDTYPE_PGID, pid);
_
^ permalink raw reply
* [patch 1/1] irda: fix read buffer overflow
From: akpm @ 2009-08-06 23:06 UTC (permalink / raw)
To: samuel; +Cc: netdev, akpm, roel.kluin
From: Roel Kluin <roel.kluin@gmail.com>
io[i] is read before the bounds check on i, order should be reversed.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Samuel Ortiz <samuel@sortiz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/irda/w83977af_ir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/irda/w83977af_ir.c~irda-fix-read-buffer-overflow drivers/net/irda/w83977af_ir.c
--- a/drivers/net/irda/w83977af_ir.c~irda-fix-read-buffer-overflow
+++ a/drivers/net/irda/w83977af_ir.c
@@ -115,7 +115,7 @@ static int __init w83977af_init(void)
IRDA_DEBUG(0, "%s()\n", __func__ );
- for (i=0; (io[i] < 2000) && (i < ARRAY_SIZE(dev_self)); i++) {
+ for (i=0; i < ARRAY_SIZE(dev_self) && io[i] < 2000; i++) {
if (w83977af_open(i, io[i], irq[i], dma[i]) == 0)
return 0;
}
_
^ permalink raw reply
* [net-2.6 PATCH 2/2] ixgbe: Disable packet split only on FCoE queues in 82599
From: Jeff Kirsher @ 2009-08-06 23:05 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Yi Zou, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20090806230514.28347.51172.stgit@localhost.localdomain>
From: Yi Zou <yi.zou@intel.com>
For 82599, packet split has to be disabled for FCoE direct data placement.
However, this is only required on received queues allocated for FCoE. This
patch adds a per ring flags to indicate if packet split is disabled on a
per queue basis, particularly for FCoE, as packet split must be disabled
for large receive using direct data placement (DDP).
Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe.h | 2 ++
drivers/net/ixgbe/ixgbe_main.c | 33 +++++++++++++++++----------------
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe.h b/drivers/net/ixgbe/ixgbe.h
index e11d83d..2c4dc82 100644
--- a/drivers/net/ixgbe/ixgbe.h
+++ b/drivers/net/ixgbe/ixgbe.h
@@ -136,6 +136,8 @@ struct ixgbe_ring {
u8 queue_index; /* needed for multiqueue queue management */
+#define IXGBE_RING_RX_PS_ENABLED (u8)(1)
+ u8 flags; /* per ring feature flags */
u16 head;
u16 tail;
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index e361b7f..e3cb949 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -585,7 +585,7 @@ static void ixgbe_alloc_rx_buffers(struct ixgbe_adapter *adapter,
rx_desc = IXGBE_RX_DESC_ADV(*rx_ring, i);
if (!bi->page_dma &&
- (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED)) {
+ (rx_ring->flags & IXGBE_RING_RX_PS_ENABLED)) {
if (!bi->page) {
bi->page = alloc_page(GFP_ATOMIC);
if (!bi->page) {
@@ -629,7 +629,7 @@ static void ixgbe_alloc_rx_buffers(struct ixgbe_adapter *adapter,
}
/* Refresh the desc even if buffer_addrs didn't change because
* each write-back erases this info. */
- if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED) {
+ if (rx_ring->flags & IXGBE_RING_RX_PS_ENABLED) {
rx_desc->read.pkt_addr = cpu_to_le64(bi->page_dma);
rx_desc->read.hdr_addr = cpu_to_le64(bi->dma);
} else {
@@ -726,7 +726,7 @@ static bool ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
break;
(*work_done)++;
- if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED) {
+ if (rx_ring->flags & IXGBE_RING_RX_PS_ENABLED) {
hdr_info = le16_to_cpu(ixgbe_get_hdr_info(rx_desc));
len = (hdr_info & IXGBE_RXDADV_HDRBUFLEN_MASK) >>
IXGBE_RXDADV_HDRBUFLEN_SHIFT;
@@ -798,7 +798,7 @@ static bool ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
rx_ring->stats.packets++;
rx_ring->stats.bytes += skb->len;
} else {
- if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED) {
+ if (rx_ring->flags & IXGBE_RING_RX_PS_ENABLED) {
rx_buffer_info->skb = next_buffer->skb;
rx_buffer_info->dma = next_buffer->dma;
next_buffer->skb = skb;
@@ -1919,7 +1919,7 @@ static void ixgbe_configure_srrctl(struct ixgbe_adapter *adapter,
srrctl |= (IXGBE_RX_HDR_SIZE << IXGBE_SRRCTL_BSIZEHDRSIZE_SHIFT) &
IXGBE_SRRCTL_BSIZEHDR_MASK;
- if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED) {
+ if (rx_ring->flags & IXGBE_RING_RX_PS_ENABLED) {
#if (PAGE_SIZE / 2) > IXGBE_MAX_RXBUFFER
srrctl |= IXGBE_MAX_RXBUFFER >> IXGBE_SRRCTL_BSIZEPKT_SHIFT;
#else
@@ -1992,11 +1992,6 @@ static void ixgbe_configure_rx(struct ixgbe_adapter *adapter)
/* Decide whether to use packet split mode or not */
adapter->flags |= IXGBE_FLAG_RX_PS_ENABLED;
-#ifdef IXGBE_FCOE
- if (adapter->flags & IXGBE_FLAG_FCOE_ENABLED)
- adapter->flags &= ~IXGBE_FLAG_RX_PS_ENABLED;
-#endif /* IXGBE_FCOE */
-
/* Set the RX buffer length according to the mode */
if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED) {
rx_buf_len = IXGBE_RX_HDR_SIZE;
@@ -2056,14 +2051,19 @@ static void ixgbe_configure_rx(struct ixgbe_adapter *adapter)
rx_ring->tail = IXGBE_RDT(j);
rx_ring->rx_buf_len = rx_buf_len;
+ if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED)
+ rx_ring->flags |= IXGBE_RING_RX_PS_ENABLED;
+
#ifdef IXGBE_FCOE
if (adapter->flags & IXGBE_FLAG_FCOE_ENABLED) {
struct ixgbe_ring_feature *f;
f = &adapter->ring_feature[RING_F_FCOE];
- if ((rx_buf_len < IXGBE_FCOE_JUMBO_FRAME_SIZE) &&
- (i >= f->mask) && (i < f->mask + f->indices))
- rx_ring->rx_buf_len =
- IXGBE_FCOE_JUMBO_FRAME_SIZE;
+ if ((i >= f->mask) && (i < f->mask + f->indices)) {
+ rx_ring->flags &= ~IXGBE_RING_RX_PS_ENABLED;
+ if (rx_buf_len < IXGBE_FCOE_JUMBO_FRAME_SIZE)
+ rx_ring->rx_buf_len =
+ IXGBE_FCOE_JUMBO_FRAME_SIZE;
+ }
}
#endif /* IXGBE_FCOE */
@@ -2143,7 +2143,8 @@ static void ixgbe_configure_rx(struct ixgbe_adapter *adapter)
if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED) {
/* Enable 82599 HW-RSC */
for (i = 0; i < adapter->num_rx_queues; i++) {
- j = adapter->rx_ring[i].reg_idx;
+ rx_ring = &adapter->rx_ring[i];
+ j = rx_ring->reg_idx;
rscctrl = IXGBE_READ_REG(hw, IXGBE_RSCCTL(j));
rscctrl |= IXGBE_RSCCTL_RSCEN;
/*
@@ -2151,7 +2152,7 @@ static void ixgbe_configure_rx(struct ixgbe_adapter *adapter)
* total size of max desc * buf_len is not greater
* than 65535
*/
- if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED) {
+ if (rx_ring->flags & IXGBE_RING_RX_PS_ENABLED) {
#if (MAX_SKB_FRAGS > 16)
rscctrl |= IXGBE_RSCCTL_MAXDESC_16;
#elif (MAX_SKB_FRAGS > 8)
^ permalink raw reply related
* [net-2.6 PATCH 1/2] ixgbe: Pass rx_ring directly in ixgbe_configure_srrctl()
From: Jeff Kirsher @ 2009-08-06 23:05 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Yi Zou, Peter P Waskiewicz Jr, Jeff Kirsher
From: Yi Zou <yi.zou@intel.com>
Instead of passing the register index of the corresponding rx_ring and find
the way back to get to corresponding rx_ring in ixgbe_configure_srrctl(),
simplify the function ixgbe_configure_srrctl() by passing the rx_ring into
it. Then the register index for that rx_ring is already available from
rx_ring->reg_idx.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 55 +++++++++++-----------------------------
1 files changed, 15 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 110c65a..e361b7f 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -1898,46 +1898,19 @@ static void ixgbe_configure_tx(struct ixgbe_adapter *adapter)
#define IXGBE_SRRCTL_BSIZEHDRSIZE_SHIFT 2
-static void ixgbe_configure_srrctl(struct ixgbe_adapter *adapter, int index)
+static void ixgbe_configure_srrctl(struct ixgbe_adapter *adapter,
+ struct ixgbe_ring *rx_ring)
{
- struct ixgbe_ring *rx_ring;
u32 srrctl;
- int queue0 = 0;
- unsigned long mask;
+ int index;
struct ixgbe_ring_feature *feature = adapter->ring_feature;
- if (adapter->hw.mac.type == ixgbe_mac_82599EB) {
- if (adapter->flags & IXGBE_FLAG_DCB_ENABLED) {
- int dcb_i = feature[RING_F_DCB].indices;
- if (dcb_i == 8)
- queue0 = index >> 4;
- else if (dcb_i == 4)
- queue0 = index >> 5;
- else
- dev_err(&adapter->pdev->dev, "Invalid DCB "
- "configuration\n");
-#ifdef IXGBE_FCOE
- if (adapter->flags & IXGBE_FLAG_FCOE_ENABLED) {
- struct ixgbe_ring_feature *f;
-
- rx_ring = &adapter->rx_ring[queue0];
- f = &adapter->ring_feature[RING_F_FCOE];
- if ((queue0 == 0) && (index > rx_ring->reg_idx))
- queue0 = f->mask + index -
- rx_ring->reg_idx - 1;
- }
-#endif /* IXGBE_FCOE */
- } else {
- queue0 = index;
- }
- } else {
+ index = rx_ring->reg_idx;
+ if (adapter->hw.mac.type == ixgbe_mac_82598EB) {
+ unsigned long mask;
mask = (unsigned long) feature[RING_F_RSS].mask;
- queue0 = index & mask;
index = index & mask;
}
-
- rx_ring = &adapter->rx_ring[queue0];
-
srrctl = IXGBE_READ_REG(&adapter->hw, IXGBE_SRRCTL(index));
srrctl &= ~IXGBE_SRRCTL_BSIZEHDR_MASK;
@@ -2002,6 +1975,7 @@ static void ixgbe_configure_rx(struct ixgbe_adapter *adapter)
{
u64 rdba;
struct ixgbe_hw *hw = &adapter->hw;
+ struct ixgbe_ring *rx_ring;
struct net_device *netdev = adapter->netdev;
int max_frame = netdev->mtu + ETH_HLEN + ETH_FCS_LEN;
int i, j;
@@ -2070,16 +2044,17 @@ static void ixgbe_configure_rx(struct ixgbe_adapter *adapter)
* the Base and Length of the Rx Descriptor Ring
*/
for (i = 0; i < adapter->num_rx_queues; i++) {
- rdba = adapter->rx_ring[i].dma;
- j = adapter->rx_ring[i].reg_idx;
+ rx_ring = &adapter->rx_ring[i];
+ rdba = rx_ring->dma;
+ j = rx_ring->reg_idx;
IXGBE_WRITE_REG(hw, IXGBE_RDBAL(j), (rdba & DMA_BIT_MASK(32)));
IXGBE_WRITE_REG(hw, IXGBE_RDBAH(j), (rdba >> 32));
IXGBE_WRITE_REG(hw, IXGBE_RDLEN(j), rdlen);
IXGBE_WRITE_REG(hw, IXGBE_RDH(j), 0);
IXGBE_WRITE_REG(hw, IXGBE_RDT(j), 0);
- adapter->rx_ring[i].head = IXGBE_RDH(j);
- adapter->rx_ring[i].tail = IXGBE_RDT(j);
- adapter->rx_ring[i].rx_buf_len = rx_buf_len;
+ rx_ring->head = IXGBE_RDH(j);
+ rx_ring->tail = IXGBE_RDT(j);
+ rx_ring->rx_buf_len = rx_buf_len;
#ifdef IXGBE_FCOE
if (adapter->flags & IXGBE_FLAG_FCOE_ENABLED) {
@@ -2087,12 +2062,12 @@ static void ixgbe_configure_rx(struct ixgbe_adapter *adapter)
f = &adapter->ring_feature[RING_F_FCOE];
if ((rx_buf_len < IXGBE_FCOE_JUMBO_FRAME_SIZE) &&
(i >= f->mask) && (i < f->mask + f->indices))
- adapter->rx_ring[i].rx_buf_len =
+ rx_ring->rx_buf_len =
IXGBE_FCOE_JUMBO_FRAME_SIZE;
}
#endif /* IXGBE_FCOE */
- ixgbe_configure_srrctl(adapter, j);
+ ixgbe_configure_srrctl(adapter, rx_ring);
}
if (hw->mac.type == ixgbe_mac_82598EB) {
^ permalink raw reply related
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Arnd Bergmann @ 2009-08-06 22:57 UTC (permalink / raw)
To: Gregory Haskins; +Cc: alacrityvm-devel, linux-kernel, netdev, Ira W. Snyder
In-Reply-To: <4A7B0D090200005A00051D2E@sinclair.provo.novell.com>
On Thursday 06 August 2009, Gregory Haskins wrote:
> >>> On 8/6/2009 at 1:03 PM, in message <200908061903.05083.arnd@arndb.de>, Arnd Bergmann <arnd@arndb.de> wrote:
> Here are some of my arguments against it:
>
> 1) there is an ample PCI model that is easy to work with when you are in QEMU and using its device model (and you get it for free). Its the path of least resistance. For something in kernel, it is more awkward to try to coordinate the in-kernel state with the PCI state. Afaict, you either need to have it live partially in both places, or you need some PCI emulation in the kernel.
True, if the whole hypervisor is in the host kernel, then doing full PCI emulation would be
insane. I was assuming that all of the setup code still lived in host user space.
What is the reason why it cannot? Do you want to use something other than qemu,
do you think this will impact performance, or something else?
> 2) The signal model for the 1:1 design is not very flexible IMO.
> 2a) I want to be able to allocate dynamic signal paths, not pre-allocate msi-x vectors at dev-add.
I believe msi-x implies that the interrupt vectors get added by the device driver
at run time, unlike legacy interrupts or msi. It's been a while since I dealt with
that though.
> 2b) I also want to collapse multiple interrupts together so as to minimize the context switch rate (inject + EIO overhead). My design effectively has "NAPI" for interrupt handling. This helps when the system needs it the most: heavy IO.
That sounds like a very useful concept in general, but this seems to be a
detail of the interrupt controller implementation. If the IO-APIC cannot
do what you want here, maybe we just need a paravirtual IRQ controller
driver, like e.g. the PS3 has.
> 3) The 1:1 model is not buying us much in terms of hotplug. We don't really "use" PCI very much even in virtio. Its a thin-shim of uniform dev-ids to resurface to the virtio-bus as something else. With LDM, hotplug is ridiculously easy anyway, so who cares. I already need an event channel anyway for (2b) anyway, so the devadd/devdrop events are trivial to handle.
I agree for Linux guests, but when you want to run other guest operating systems,
PCI hotplug is probably the most common interface for this. AFAIK, the windows
virtio-net driver does not at all have a concept of a virtio layer but is simply
a network driver for a PCI card. The same could be applied any other device,
possibly with some library code doing all the queue handling in a common way.l
> 4) communicating with something efficiently in-kernel requires more finesse than basic PIO/MMIO. There are tricks you can do to get around this, but with 1:1 you would have to do this trick repeatedly for each device. Even with a library solution to help, you still have per-cpu .data overhead and cpu hotplug overhead to get maximum performance. With my "bridge" model, I do it once, which I believe is ideal.
>
> 5) 1:1 is going to quickly populate the available MMIO/PIO and IDT slots for any kind of medium to large configuration. The bridge model scales better in this regard.
We don't need to rely on PIO, it's just the common interface that all hypervisors
can easily support. We could have different underlying methods for the communication
if space or performance becomes a bottleneck because of this.
> So based on that, I think the bridge model works better for vbus. Perhaps you can convince me otherwise ;)
Being able to define all of it in the host kernel seems to be the major
advantage of your approach, the other points you mentioned are less
important IMHO. The question is whether that is indeed a worthy goal,
or if it should just live in user space as with the qemu PCI code.
> >> In essence, this driver's job is to populate the "vbus-proxy" LDM bus with
> >> objects that it finds across the PCI-OTHER bridge. This would actually sit
> >> below the virtio components in the stack, so it doesnt make sense (to me) to
> >> turn around and build this on top of virtio. But perhaps I am missing
> >> something you are seeing.
> >>
> >> Can you elaborate?
> >
> > Your PCI device does not serve any real purpose as far as I can tell
>
> That is certainly debatable. Its purpose is as follows:
>
> 1) Allows a guest to discover the vbus feature (fwiw: I used to do this with cpuid)
true, I missed that.
> 2) Allows the guest to establish proper context to communicate with the feature (mmio, pio, and msi) (fwiw: i used to use hypercalls)
> 3) Access the virtual-devices that have been configured for the feature
>
> Correct me if I am wrong: Isn't this more of less the exact intent of something like an LDM bus (vbus-proxy) and a PCI-BRIDGE? Other than the possibility that there might be some mergable overlap (still debatable), I don't think its fair to say that this does not serve a purpose.
I guess you are right on that. An interesting variation of that would be make the
child devices of it virtio devices again though: Instead of the PCI emulation code
in the host kernel, you could define a simpler interface to the same effect. So the
root device would be a virtio-pci device, below which you can have virtio-virtio
devices.
> >, you could just as well have a root device as a parent for all the vbus devices
> > if you do your device probing like this.
>
> Yes, I suppose the "bridge" could have been advertised as a virtio-based root device. In this way, the virtio probe() would replace my pci probe() for feature discovery, and a virtqueue could replace my msi+ioq for the eventq channel.
>
> I see a few issues with that, however:
>
> 1) The virtqueue library, while a perfectly nice ring design at the metadata level, does not have an API that is friendly to kernel-to-kernel communication. It was designed more for frontend use to some remote backend. The IOQ library on the other hand, was specifically designed to support use as kernel-to-kernel (see north/south designations). So this made life easier for me. To do what you propose, the eventq channel would need to terminate in kernel, and I would thus be forced to deal that the potential API problems.
Well, virtqueues are not that bad for kernel-to-kernel communication, as Ira mentioned
referring to his virtio-over-PCI driver. You can have virtqueues on both sides, having
the host kernel create a pair of virtqueues (one in user aka guest space, one in the host
kernel), with the host virtqueue_ops doing copy_{to,from}_user to move data between them.
If you have that, you can actually use the same virtio_net driver in both guest and
host kernel, just communicating over different virtio implementations. Interestingly,
that would mean that you no longer need a separation between guest and host device
drivers (vbus and vbus-proxy in your case) but could use the same device abstraction
with just different transports to back the shm-signal or virtqueue.
> 2) I would need to have Avi et. al. allocate a virtio vector to use from their namespace, which I am sure they wont be willing to do until they accept my design. Today, I have a nice conflict free PCI ID to use as I see fit.
My impression is the opposite: as long as you try to reinvent everything at once,
you face opposition, but if you just improve parts of the existing design one
by one (like eventfd), I think you will find lots of support.
> Im sure both of these hurdles are not insurmountable, but I am left scratching my head as to why its worth the effort. It seems to me its a "six of one, half-dozen of the other" kind of scenario. Either I write a qemu PCI device and pci-bridge driver, or I write a qemu virtio-devicve and virtio root driver.
>
> In short: What does this buy us, or did you mean something else?
In my last reply, I was thinking of a root device that can not be probed like a PCI device.
> > However, assuming that you do the IMHO right thing to do probing like
> > virtio with a PCI device for each slave, the code will be almost the same
> > as virtio-pci and the two can be the same.
>
> Can you elaborate?
Well, let me revise based on the discussion:
The main point that remains is that I think a vbus-proxy should be the same as a
virtio device. This could be done by having (as in my earlier mails) a PCI device
per vbus-proxy, with devcall implemented in PIO or config-space and additional
shm/shm-signal, or it could be a single virtio device from virtio-pci or one
of the other existing provides that connects you with a new virtio provider
sitting in the host kernel. This provider has child devices for any endpoint
(virtio-net, venet, ...) that is implemented in the host kernel.
> >and you go and enumerate the devices on the bridge, creating a vbus_device for each
> > one as you go.
>
> Thats exactly what it does.
>
> > Then you just need to match the vbus drivers with the
> > devices by some string or vendor/device ID tuple.
> >
>
> Yep, thats right too. Then, when the driver gets a ->probe(), it does an dev->open() to check various state:
>
> a) can the device be opened? if it has an max-open policy (most will have a max-open = 1 policy) and something else already has the device open, it will fail (this will not be common).
> b) is the driver ABI revision compatible with the device ABI revision? This is like checking the pci config-space revision number.
>
> For an example, see drivers/net/vbus-enet.c, line 764:
>
> http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=drivers/net/vbus-enet.c;h=7220f43723adc5b0bece1bc37974fae1b034cd9e;hb=b3b2339efbd4e754b1c85f8bc8f85f21a1a1f509#l764
>
> Its simple a check to see if the driver and device are compatible, and therefore the probe should succeed. Nothing more. I think what I have done is similar to how most buses (like PCI) work today (ala revision number checks with a config-cycle).
ok.
> Regarding the id->handle indirection:
>
> Internally, the DEVOPEN call translates an "id" to a "handle". The handle is just a token to help ensure that the caller actually opened the device successfully. Note that the "id" namespace is 0 based. Therefore, something like an errant DEVCALL(0) would be indistinguishable from a legit request. Using the handle abstraction gives me a slightly more robust mechanism to ensure the caller actually meant to call the host, and was in the proper context to do so. For one thing, if the device had never been opened, this would have failed before it ever reached the model. Its one more check I can do at the infrastructure level, and one less thing each model has to look out for.
>
> Is the id->handle translation critical? No, i'm sure we could live without it, but I also don't think it hurts anything. It allows the overall code to be slightly more robust, and the individual model code to be slightly less complicated. Therefore, I don't see a problem.
Right, assuming your model with all vbus devices behind a single PCI device, your
handle does not hurt, it's the equivalent of a bus/dev/fn number or an MMIO address.
Arnd <><
^ permalink raw reply
* Re: [PATCH, RFC] bonding: prevent outgoing packets on inactive slaves
From: Jiri Bohac @ 2009-08-06 22:56 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Jiri Bohac, davem, netdev
In-Reply-To: <24645.1249491676@death.nxdomain.ibm.com>
On Wed, Aug 05, 2009 at 10:01:16AM -0700, Jay Vosburgh wrote:
> Jiri Bohac <jbohac@suse.cz> wrote:
> >This patch makes sure the TX queues on inactive slaves are
> >deactivated.
>
> I'd love to include this patch; many times I've tracked down
> "bonding" problems to some errant dingus confusing the switch, but I
> think this patch will break some things, and therefore has to be a NAK.
>
> Specifically, I suspect this will break users of some protocols
> that intentionally (and legitimately) bind directly to the slave
> underneath bonding, LLDP for one. I'm fairly sure there are such users,
> because the inactive slave rx path was changed last year to permit
> explicit binds to the inactive slaves to receive packets that normally
> would be dropped:
>
> commit 0d7a3681232f545c6a59f77e60f7667673ef0e93
> Author: Joe Eykholt <jre@nuovasystems.com>
> Date: Wed Jul 2 18:22:01 2008 -0700
>
> net/core: Allow certain receives on inactive slave.
>
> Allow a packet_type that specifies the exact device to receive
> even on an inactive bonding slave devices. This is important for some
> L2 protocols such as LLDP and FCoE. This can eventually be used
> for the bonding special cases as well.
OK. I checked FCoE and it really seems to bind to a specific
interface. I checked openlldp and it does bind to individual
interfaces specifically, so checking the ptype really seems like
it should work. How about the following patch, then?
I think it even is cleaner than the original, because
bond_set_slave_active_flags() really only sets flags instead of
calling non-trivial functions while holding locks. If some
protocol does not work with the ptype heuristics, it can easilly
be "whitelisted" in skb_bond_should_drop_tx():
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1955,7 +1955,7 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
slave_dev->priv_flags &= ~(IFF_MASTER_8023AD | IFF_MASTER_ALB |
IFF_SLAVE_INACTIVE | IFF_BONDING |
- IFF_SLAVE_NEEDARP);
+ IFF_SLAVE_NEEDARP | IFF_SLAVE_FILTER_TX);
kfree(slave);
@@ -2081,7 +2081,7 @@ static int bond_release_all(struct net_device *bond_dev)
}
slave_dev->priv_flags &= ~(IFF_MASTER_8023AD | IFF_MASTER_ALB |
- IFF_SLAVE_INACTIVE);
+ IFF_SLAVE_INACTIVE | IFF_SLAVE_FILTER_TX);
kfree(slave);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 6290a50..7d0e0bb 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -291,12 +291,15 @@ static inline void bond_set_slave_inactive_flags(struct slave *slave)
slave->dev->priv_flags |= IFF_SLAVE_INACTIVE;
if (slave_do_arp_validate(bond, slave))
slave->dev->priv_flags |= IFF_SLAVE_NEEDARP;
+ if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
+ slave->dev->priv_flags |= IFF_SLAVE_FILTER_TX;
}
static inline void bond_set_slave_active_flags(struct slave *slave)
{
slave->state = BOND_STATE_ACTIVE;
- slave->dev->priv_flags &= ~(IFF_SLAVE_INACTIVE | IFF_SLAVE_NEEDARP);
+ slave->dev->priv_flags &= ~(IFF_SLAVE_INACTIVE | IFF_SLAVE_NEEDARP |
+ IFF_SLAVE_FILTER_TX);
}
static inline void bond_set_master_3ad_flags(struct bonding *bond)
diff --git a/include/linux/if.h b/include/linux/if.h
index b9a6229..40d5c56 100644
--- a/include/linux/if.h
+++ b/include/linux/if.h
@@ -70,6 +70,7 @@
#define IFF_XMIT_DST_RELEASE 0x400 /* dev_hard_start_xmit() is allowed to
* release skb->dst
*/
+#define IFF_SLAVE_FILTER_TX 0x800 /* filter tx on bonding slaves */
#define IF_GET_IFACE 0x0001 /* for querying only */
#define IF_GET_PROTO 0x0002
diff --git a/net/core/dev.c b/net/core/dev.c
index 70c27e0..7018ba7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1786,6 +1786,25 @@ static struct netdev_queue *dev_pick_tx(struct net_device *dev,
return netdev_get_tx_queue(dev, queue_index);
}
+/* In active-backup mode, on bonding slaves other than the currently active slave,
+ * suppress outgoing packets, except for special L2 protocols.
+ */
+static inline int skb_bond_should_drop_tx(struct sk_buff *skb)
+{
+ struct packet_type *ptype;
+ __be16 type;
+
+ /* allow protocols specifically bound to this interface */
+ type = skb->protocol;
+ list_for_each_entry_rcu(ptype,
+ &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
+ if (ptype->type == type && ptype->dev == skb->dev)
+ return 0;
+ }
+
+ return 1;
+}
+
/**
* dev_queue_xmit - transmit a buffer
* @skb: buffer to transmit
@@ -1818,6 +1837,12 @@ int dev_queue_xmit(struct sk_buff *skb)
struct Qdisc *q;
int rc = -ENOMEM;
+ if ((dev->priv_flags & IFF_SLAVE_FILTER_TX) &&
+ skb_bond_should_drop_tx(skb)) {
+ rc = NET_XMIT_DROP;
+ goto out_kfree_skb;
+ }
+
/* GSO will handle the following emulations directly. */
if (netif_needs_gso(dev, skb))
goto gso;
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply related
* 3x59x-fix-pci-resource-management.patch
From: Andrew Morton @ 2009-08-06 22:42 UTC (permalink / raw)
To: Sergei Shtylyov, Steffen Klassert; +Cc: netdev
Guys, I seem to have been sitting on the below patch for, err, three years.
I generally do this because there's some issue which needs to be
addressed, but the patch didn't address it right.
Can we please have a revisit and work out what we should do with this?
Thanks.
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
The driver wrongly claimed I/O ports at an address returned by pci_iomap()
-- even if it was passed an MMIO address. Fix this by claiming/releasing
all PCI resources in the PCI driver probe/remove handlers instead and get
rid of the must_free_region flag weirdness (why would Cardbus claim
anything for us?).
Also, the remove handler was trying to talk to the chip after having
disabled its address decoders (at least on x86) -- fix this and get rid of
useless VORTEX_PCI() calls.
While at it, fix some cases of the overly indented code...
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/3c59x.c | 66 ++++++++++++++++++++----------------------
1 file changed, 32 insertions(+), 34 deletions(-)
diff -puN drivers/mtd/devices/Kconfig~3x59x-fix-pci-resource-management drivers/mtd/devices/Kconfig
diff -puN drivers/mtd/devices/Makefile~3x59x-fix-pci-resource-management drivers/mtd/devices/Makefile
diff -puN drivers/mtd/devices/sst25l.c~3x59x-fix-pci-resource-management drivers/mtd/devices/sst25l.c
diff -puN drivers/net/3c59x.c~3x59x-fix-pci-resource-management drivers/net/3c59x.c
--- a/drivers/net/3c59x.c~3x59x-fix-pci-resource-management
+++ a/drivers/net/3c59x.c
@@ -629,7 +629,6 @@ struct vortex_private {
pm_state_valid:1, /* pci_dev->saved_config_space has sane contents */
open:1,
medialock:1,
- must_free_region:1, /* Flag: if zero, Cardbus owns the I/O region */
large_frames:1; /* accept large frames */
int drv_flags;
u16 status_enable;
@@ -962,7 +961,13 @@ static int __devinit vortex_init_one(str
/* wake up and enable device */
rc = pci_enable_device(pdev);
if (rc < 0)
- goto out;
+ return rc;
+
+ rc = pci_request_regions(pdev, "3c59x");
+ if (rc < 0) {
+ pci_disable_device(pdev);
+ return rc;
+ }
unit = vortex_cards_found;
@@ -982,13 +987,13 @@ static int __devinit vortex_init_one(str
rc = vortex_probe1(&pdev->dev, ioaddr, pdev->irq,
ent->driver_data, unit);
if (rc < 0) {
+ pci_release_regions(pdev);
pci_disable_device(pdev);
- goto out;
+ return rc;
}
vortex_cards_found++;
-out:
return rc;
}
@@ -1125,11 +1130,6 @@ static int __devinit vortex_probe1(struc
/* PCI-only startup logic */
if (pdev) {
- /* EISA resources already marked, so only PCI needs to do this here */
- /* Ignore return value, because Cardbus drivers already allocate for us */
- if (request_region(dev->base_addr, vci->io_size, print_name) != NULL)
- vp->must_free_region = 1;
-
/* enable bus-mastering if necessary */
if (vci->flags & PCI_USES_MASTER)
pci_set_master(pdev);
@@ -1160,12 +1160,13 @@ static int __devinit vortex_probe1(struc
vp->mii.reg_num_mask = 0x1f;
/* Makes sure rings are at least 16 byte aligned. */
- vp->rx_ring = pci_alloc_consistent(pdev, sizeof(struct boom_rx_desc) * RX_RING_SIZE
- + sizeof(struct boom_tx_desc) * TX_RING_SIZE,
- &vp->rx_ring_dma);
+ vp->rx_ring = pci_alloc_consistent(pdev,
+ sizeof(struct boom_rx_desc) * RX_RING_SIZE +
+ sizeof(struct boom_tx_desc) * TX_RING_SIZE,
+ &vp->rx_ring_dma);
retval = -ENOMEM;
if (!vp->rx_ring)
- goto free_region;
+ goto free_device;
vp->tx_ring = (struct boom_tx_desc *)(vp->rx_ring + RX_RING_SIZE);
vp->tx_ring_dma = vp->rx_ring_dma + sizeof(struct boom_rx_desc) * RX_RING_SIZE;
@@ -1432,13 +1433,11 @@ static int __devinit vortex_probe1(struc
free_ring:
pci_free_consistent(pdev,
- sizeof(struct boom_rx_desc) * RX_RING_SIZE
- + sizeof(struct boom_tx_desc) * TX_RING_SIZE,
- vp->rx_ring,
- vp->rx_ring_dma);
-free_region:
- if (vp->must_free_region)
- release_region(dev->base_addr, vci->io_size);
+ sizeof(struct boom_rx_desc) * RX_RING_SIZE +
+ sizeof(struct boom_tx_desc) * TX_RING_SIZE,
+ vp->rx_ring,
+ vp->rx_ring_dma);
+free_device:
free_netdev(dev);
pr_err(PFX "vortex_probe1 fails. Returns %d\n", retval);
out:
@@ -3167,29 +3166,28 @@ static void __devexit vortex_remove_one(
vp = netdev_priv(dev);
if (vp->cb_fn_base)
- pci_iounmap(VORTEX_PCI(vp), vp->cb_fn_base);
+ pci_iounmap(pdev, vp->cb_fn_base);
unregister_netdev(dev);
- if (VORTEX_PCI(vp)) {
- pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */
- if (vp->pm_state_valid)
- pci_restore_state(VORTEX_PCI(vp));
- pci_disable_device(VORTEX_PCI(vp));
- }
+ pci_set_power_state(pdev, PCI_D0); /* Go active */
+ if (vp->pm_state_valid)
+ pci_restore_state(pdev);
+
/* Should really use issue_and_wait() here */
iowrite16(TotalReset | ((vp->drv_flags & EEPROM_RESET) ? 0x04 : 0x14),
vp->ioaddr + EL3_CMD);
- pci_iounmap(VORTEX_PCI(vp), vp->ioaddr);
+ pci_iounmap(pdev, vp->ioaddr);
pci_free_consistent(pdev,
- sizeof(struct boom_rx_desc) * RX_RING_SIZE
- + sizeof(struct boom_tx_desc) * TX_RING_SIZE,
- vp->rx_ring,
- vp->rx_ring_dma);
- if (vp->must_free_region)
- release_region(dev->base_addr, vp->io_size);
+ sizeof(struct boom_rx_desc) * RX_RING_SIZE +
+ sizeof(struct boom_tx_desc) * TX_RING_SIZE,
+ vp->rx_ring,
+ vp->rx_ring_dma);
+
+ pci_release_regions(pdev);
+ pci_disable_device(pdev);
free_netdev(dev);
}
_
^ permalink raw reply
* Re: 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd]
From: Benjamin Herrenschmidt @ 2009-08-06 22:23 UTC (permalink / raw)
To: michael; +Cc: Sachin Sant, netdev, David Miller, linuxppc-dev
In-Reply-To: <1249395350.8016.5.camel@concordia>
On Wed, 2009-08-05 at 00:15 +1000, Michael Ellerman wrote:
> > c000000000600000 00001010 .long 0x1010
> > 0:mon>
> > c000000000600004 00000008 .long 0x8
> > c000000000600008 00001013 .long 0x1013
> > c00000000060000c 0000000f .long 0xf
> > c000000000600010 7961626f rldimi. r1,r11,44,41
> > c000000000600014 6f740000 xoris r20,r27,0
> > c000000000600018 00101600 .long 0x101600
> > c00000000060001c 00000c00 .long 0xc00
> > c000000000600020 00000400 .long 0x400
> > c000000000600024 00101100 .long 0x101100
> > c000000000600028 000008e9 .long 0x8e9
BTW. Corruption looks like bi_recs... ie, broken yaboot. This was fixed
recently, yaboot would eventually crap over the kernel for certain sizes
of the kernel image.
0x1010 = BI_FIRST
0x1013 = BI_BOOTLOADER_ID followed by 0x7961626f6f74 which is
"yaboot" :-)
0x1016 = BI_MACHTYPE
etc...
Cheers,
Ben.
^ permalink raw reply
* [patch for 2.6.31? 2/2] gigaset: really fix chars_in_buffer
From: akpm @ 2009-08-06 22:19 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, tilman
From: Tilman Schmidt <tilman@imap.cc>
The tty_operation chars_in_buffer() is not allowed to return a negative
value to signal an error. Corrects the problem flagged by commit
23198fda7182969b619613a555f8645fdc3dc334, "tty: fix chars_in_buffers".
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/isdn/gigaset/interface.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff -puN drivers/isdn/gigaset/interface.c~gigaset-really-fix-chars_in_buffer drivers/isdn/gigaset/interface.c
--- a/drivers/isdn/gigaset/interface.c~gigaset-really-fix-chars_in_buffer
+++ a/drivers/isdn/gigaset/interface.c
@@ -408,33 +408,28 @@ static int if_write_room(struct tty_stru
return retval;
}
-/* FIXME: This function does not have error returns */
-
static int if_chars_in_buffer(struct tty_struct *tty)
{
struct cardstate *cs;
- int retval = -ENODEV;
+ int retval = 0;
cs = (struct cardstate *) tty->driver_data;
if (!cs) {
pr_err("%s: no cardstate\n", __func__);
- return -ENODEV;
+ return 0;
}
gig_dbg(DEBUG_IF, "%u: %s()", cs->minor_index, __func__);
- if (mutex_lock_interruptible(&cs->mutex))
- return -ERESTARTSYS; // FIXME -EINTR?
+ mutex_lock(&cs->mutex);
- if (!cs->connected) {
+ if (!cs->connected)
gig_dbg(DEBUG_IF, "not connected");
- retval = -ENODEV;
- } else if (!cs->open_count)
+ else if (!cs->open_count)
dev_warn(cs->dev, "%s: device not opened\n", __func__);
- else if (cs->mstate != MS_LOCKED) {
+ else if (cs->mstate != MS_LOCKED)
dev_warn(cs->dev, "can't write to unlocked device\n");
- retval = -EBUSY;
- } else
+ else
retval = cs->ops->chars_in_buffer(cs);
mutex_unlock(&cs->mutex);
_
^ permalink raw reply
* [patch for 2.6.31? 1/2] MAINTAINERS: update atlx contact info
From: akpm @ 2009-08-06 22:19 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, chris.snook, jcliburn, jie.yang
From: Chris Snook <chris.snook@gmail.com>
Update MAINTAINERS to reflect my current (non-)affiliation. Anyone
hiring?
Signed-off-by: Chris Snook <chris.snook@gmail.com>
Cc: Jay Cliburn <jcliburn@gmail.com>
Cc: Jie Yang <jie.yang@atheros.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN MAINTAINERS~maintainers-update-atlx-contact-info MAINTAINERS
--- a/MAINTAINERS~maintainers-update-atlx-contact-info
+++ a/MAINTAINERS
@@ -915,7 +915,7 @@ F: drivers/input/misc/ati_remote2.c
ATLX ETHERNET DRIVERS
M: Jay Cliburn <jcliburn@gmail.com>
-M: Chris Snook <csnook@redhat.com>
+M: Chris Snook <chris.snook@gmail.com>
M: Jie Yang <jie.yang@atheros.com>
L: atl1-devel@lists.sourceforge.net
W: http://sourceforge.net/projects/atl1
_
^ permalink raw reply
* 8139cp dma-debug warning.
From: Dave Jones @ 2009-08-06 21:57 UTC (permalink / raw)
To: netdev
I'm chasing yet another dma-debug warning where we're unmapping a different
size to what we mapped.
> WARNING: at lib/dma-debug.c:803 check_unmap+0x1f5/0x509() (Not tainted)
> Hardware name:
> 8139cp 0000:00:03.0: DMA-API: device driver frees DMA memory with different
> size [device address=0x000000001e9f8852] [map size=1536 bytes] [unmap size=1538
> bytes]
> Modules linked in: ipv6 dm_multipath uinput joydev 8139too virtio_balloon
> 8139cp mii i2c_piix4 virtio_pci i2c_core floppy squashfs pata_acpi ata_generic
> [last unloaded: scsi_wait_scan]
> Pid: 0, comm: swapper Not tainted 2.6.31-0.125.rc5.git2.fc12.i686 #1
> Call Trace:
> [<c0444408>] warn_slowpath_common+0x7b/0xa3
> [<c0606746>] ? check_unmap+0x1f5/0x509
> [<c0444499>] warn_slowpath_fmt+0x34/0x48
> [<c0606746>] check_unmap+0x1f5/0x509
> [<c04ecb43>] ? check_valid_pointer+0x2c/0x6c
> [<c0606c00>] debug_dma_unmap_page+0x62/0x7b
> [<e0dc80be>] dma_unmap_single_attrs.clone.2+0x5a/0x75 [8139cp]
> [<e0dc8220>] cp_rx_poll+0x147/0x301 [8139cp]
> [<c077e5d4>] net_rx_action+0xa7/0x1d3
> [<c044accf>] __do_softirq+0xc8/0x192
> [<c044ade2>] do_softirq+0x49/0x7f
> [<c044af36>] irq_exit+0x48/0x8c
> [<c041c302>] smp_apic_timer_interrupt+0x7a/0x99
> [<c0404416>] apic_timer_interrupt+0x36/0x3c
> [<c0425e98>] ? native_safe_halt+0xa/0xc
> [<c040ad6f>] default_idle+0x55/0x98
> [<c046e44d>] ? trace_hardirqs_off+0x19/0x2c
> [<c04029e3>] cpu_idle+0xac/0xcd
> [<c08080ee>] rest_init+0x66/0x79
> [<c0a72ae0>] start_kernel+0x36f/0x385
> [<c0a7207e>] __init_begin+0x7e/0x96
> ---[ end trace f3c3298e5df24f15 ]---
> Mapped at:
> [<c0606f6b>] debug_dma_map_page+0x6b/0x13b
> [<e0dc7c22>] dma_map_single_attrs.clone.1+0x78/0x93 [8139cp]
> [<e0dc86d0>] cp_init_rings+0xaa/0x12c [8139cp]
> [<e0dc87d6>] cp_open+0x84/0x154 [8139cp]
> [<c077ff2b>] dev_open+0x99/0xe4
Looking at 8139cp.c I see this code in cp_rx_poll ..
552 buflen = cp->rx_buf_sz + NET_IP_ALIGN;
553 new_skb = netdev_alloc_skb(dev, buflen);
554 if (!new_skb) {
555 dev->stats.rx_dropped++;
556 goto rx_next;
557 }
558
559 skb_reserve(new_skb, NET_IP_ALIGN);
Aren't we padding the alignment twice here? or am I missing something?
The warning was a difference of two bytes, which is NET_IP_ALIGN,
so I'm wondering if that skb_reserve line needs to be nuked ?
Dave
^ permalink raw reply
* [PATCH] macvlan: add tap device backend
From: Arnd Bergmann @ 2009-08-06 21:50 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, Patrick McHardy, Stephen Hemminger,
David S. Miller", Michael S. Tsirkin, Herbert Xu, Or Gerlitz,
Fischer, Anna, bridge, linux-kernel, Edge Virtual Bridging
This is a first prototype of a new interface into the network
stack, to eventually replace tun/tap and the bridge driver
in certain virtual machine setups.
Background
----------
The 'Edge Virtual Bridging' working group is discussing ways to overcome
the limitation of virtual bridges in hypervisors. One important part
of this is the Virtual Ethernet Port Aggregator (VEPA), as described in
http://www.ieee802.org/1/files/public/docs2009/new-evb-congdon-vepa-modular-0709-v01.pdf
In short, the idea of VEPA is that virtual machines do not communicate
with each other through direct bridging in the hypervisor but only via
an external managed switch that is already well integrated into the data
center, including network filtering, accounting and monitoring. While
we can do most of that efficiently in the Linux bridge code, doing it
externally simplifies the overall setup.
Related work
------------
Patches to implement VEPA in the Linux bridge driver have been posted by
Anna Fischer in June, see http://patchwork.ozlabs.org/patch/28702/. Those
patches are good and hopefully get merged in 2.6.32, but I think we can
take some shortcuts with an alternative approach:
The macvlan driver already has the property of forwarding all traffic
between guests and an external interface but not between the guests, just
as VEPA needs it. Also, VEPA does explicitly not want or need advanced
filtering in the way that netfilter-bridge provides, so we can use macvlan
to replace the bridge code in this setup, reducing the code path through
the kernel. This works fine with containers and network namespaces,
but not easily with kvm/qemu because we only have a network device.
Or Gerlitz posted a "raw" packet socket backend for qemu to deal with this,
at http://marc.info/?l=qemu-devel&m=124653801212767 and at least three
other people have done a similar functionality independently.
This driver
-----------
While the other approaches should work as well, doing it using a tap
interface should give additional benefits:
* We can keep using the optimizations for jumbo frames that we have put
into the tun/tap driver.
* No need for root permissions that packet sockets need, just use 'ip
link add link type macvtap' to create a new device and give it the right
permissions using udev (using one tap per macvlan netdev).
* support for multiqueue network adapters by opening the tap device
multiple times, using one file descriptor per guest CPU/network
queue/interrupt (if the adapter supports multiple queues on a single
MAC address).
* support for zero-copy receive/transmit using async I/O on the tap device
(if the adapter supports per MAC rx queues).
* The same framework in macvlan can be used to add a third backend
into a future kernel based virtio-net implementation.
This version of the driver does not support any of those features,
but they all appear possible to add ;).
The driver is currently called 'macvtap', but I'd be more than happy
to change that if anyone could suggest a better name. The code is
still in an early stage and I wish I had found more time to polish
it, but at this time, I'd first like to know if people agree with the
basic concept at all.
Cc: Patrick McHardy <kaber@trash.net>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: David S. Miller" <davem@davemloft.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Or Gerlitz <ogerlitz@voltaire.com>
Cc: "Fischer, Anna" <anna.fischer@hp.com>
Cc: netdev@vger.kernel.org
Cc: bridge@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: Edge Virtual Bridging <evb@yahoogroups.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The evb mailing list eats Cc headers, please make sure to keep everybody
in your Cc list when replying there.
---
drivers/net/Kconfig | 12 ++
drivers/net/Makefile | 1 +
drivers/net/macvlan.c | 39 +++-----
drivers/net/macvlan.h | 37 +++++++
drivers/net/macvtap.c | 276 +++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 341 insertions(+), 24 deletions(-)
create mode 100644 drivers/net/macvlan.h
create mode 100644 drivers/net/macvtap.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5f6509a..0b9ac6a 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -90,6 +90,18 @@ config MACVLAN
To compile this driver as a module, choose M here: the module
will be called macvlan.
+config MACVTAP
+ tristate "MAC-VLAN based tap driver (EXPERIMENTAL)"
+ depends on MACVLAN
+ help
+ This adds a specialized tap character device driver that is based
+ on the MAC-VLAN network interface, called macvtap. A macvtap device
+ can be added in the same way as a macvlan device, using 'type
+ macvlan', and then be accessed through the tap user space interface.
+
+ To compile this driver as a module, choose M here: the module
+ will be called macvtap.
+
config EQUALIZER
tristate "EQL (serial line load balancing) support"
---help---
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index ead8cab..8a2d2d7 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -162,6 +162,7 @@ obj-$(CONFIG_XEN_NETDEV_FRONTEND) += xen-netfront.o
obj-$(CONFIG_DUMMY) += dummy.o
obj-$(CONFIG_IFB) += ifb.o
obj-$(CONFIG_MACVLAN) += macvlan.o
+obj-$(CONFIG_MACVTAP) += macvtap.o
obj-$(CONFIG_DE600) += de600.o
obj-$(CONFIG_DE620) += de620.o
obj-$(CONFIG_LANCE) += lance.o
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 99eed9f..9f7dc6a 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -30,22 +30,7 @@
#include <linux/if_macvlan.h>
#include <net/rtnetlink.h>
-#define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
-
-struct macvlan_port {
- struct net_device *dev;
- struct hlist_head vlan_hash[MACVLAN_HASH_SIZE];
- struct list_head vlans;
-};
-
-struct macvlan_dev {
- struct net_device *dev;
- struct list_head list;
- struct hlist_node hlist;
- struct macvlan_port *port;
- struct net_device *lowerdev;
-};
-
+#include "macvlan.h"
static struct macvlan_dev *macvlan_hash_lookup(const struct macvlan_port *port,
const unsigned char *addr)
@@ -135,7 +120,7 @@ static void macvlan_broadcast(struct sk_buff *skb,
else
nskb->pkt_type = PACKET_MULTICAST;
- netif_rx(nskb);
+ vlan->receive(nskb);
}
}
}
@@ -180,11 +165,11 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
skb->dev = dev;
skb->pkt_type = PACKET_HOST;
- netif_rx(skb);
+ vlan->receive(skb);
return NULL;
}
-static int macvlan_start_xmit(struct sk_buff *skb, struct net_device *dev)
+int macvlan_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
const struct macvlan_dev *vlan = netdev_priv(dev);
unsigned int len = skb->len;
@@ -202,6 +187,7 @@ static int macvlan_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
return NETDEV_TX_OK;
}
+EXPORT_SYMBOL_GPL(macvlan_start_xmit);
static int macvlan_hard_header(struct sk_buff *skb, struct net_device *dev,
unsigned short type, const void *daddr,
@@ -412,7 +398,7 @@ static const struct net_device_ops macvlan_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
-static void macvlan_setup(struct net_device *dev)
+void macvlan_setup(struct net_device *dev)
{
ether_setup(dev);
@@ -423,6 +409,7 @@ static void macvlan_setup(struct net_device *dev)
dev->ethtool_ops = &macvlan_ethtool_ops;
dev->tx_queue_len = 0;
}
+EXPORT_SYMBOL_GPL(macvlan_setup);
static int macvlan_port_create(struct net_device *dev)
{
@@ -472,7 +459,7 @@ static void macvlan_transfer_operstate(struct net_device *dev)
}
}
-static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
+int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
{
if (tb[IFLA_ADDRESS]) {
if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN)
@@ -482,9 +469,10 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
}
return 0;
}
+EXPORT_SYMBOL_GPL(macvlan_validate);
-static int macvlan_newlink(struct net_device *dev,
- struct nlattr *tb[], struct nlattr *data[])
+int macvlan_newlink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
{
struct macvlan_dev *vlan = netdev_priv(dev);
struct macvlan_port *port;
@@ -524,6 +512,7 @@ static int macvlan_newlink(struct net_device *dev,
vlan->lowerdev = lowerdev;
vlan->dev = dev;
vlan->port = port;
+ vlan->receive = netif_rx;
err = register_netdevice(dev);
if (err < 0)
@@ -533,8 +522,9 @@ static int macvlan_newlink(struct net_device *dev,
macvlan_transfer_operstate(dev);
return 0;
}
+EXPORT_SYMBOL_GPL(macvlan_newlink);
-static void macvlan_dellink(struct net_device *dev)
+void macvlan_dellink(struct net_device *dev)
{
struct macvlan_dev *vlan = netdev_priv(dev);
struct macvlan_port *port = vlan->port;
@@ -545,6 +535,7 @@ static void macvlan_dellink(struct net_device *dev)
if (list_empty(&port->vlans))
macvlan_port_destroy(port->dev);
}
+EXPORT_SYMBOL_GPL(macvlan_dellink);
static struct rtnl_link_ops macvlan_link_ops __read_mostly = {
.kind = "macvlan",
diff --git a/drivers/net/macvlan.h b/drivers/net/macvlan.h
new file mode 100644
index 0000000..3f3c6c3
--- /dev/null
+++ b/drivers/net/macvlan.h
@@ -0,0 +1,37 @@
+#ifndef _MACVLAN_H
+#define _MACVLAN_H
+
+#include <linux/netdevice.h>
+#include <linux/netlink.h>
+#include <linux/list.h>
+
+#define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
+
+struct macvlan_port {
+ struct net_device *dev;
+ struct hlist_head vlan_hash[MACVLAN_HASH_SIZE];
+ struct list_head vlans;
+};
+
+struct macvlan_dev {
+ struct net_device *dev;
+ struct list_head list;
+ struct hlist_node hlist;
+ struct macvlan_port *port;
+ struct net_device *lowerdev;
+
+ int (*receive)(struct sk_buff *skb);
+};
+
+extern int macvlan_start_xmit(struct sk_buff *skb, struct net_device *dev);
+
+extern void macvlan_setup(struct net_device *dev);
+
+extern int macvlan_validate(struct nlattr *tb[], struct nlattr *data[]);
+
+extern int macvlan_newlink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[]);
+
+extern void macvlan_dellink(struct net_device *dev);
+
+#endif /* _MACVLAN_H */
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
new file mode 100644
index 0000000..d99bfc0
--- /dev/null
+++ b/drivers/net/macvtap.c
@@ -0,0 +1,276 @@
+#include <linux/etherdevice.h>
+#include <linux/nsproxy.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/cache.h>
+#include <linux/sched.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/wait.h>
+#include <linux/cdev.h>
+#include <linux/fs.h>
+
+#include <net/net_namespace.h>
+#include <net/rtnetlink.h>
+
+#include "macvlan.h"
+
+struct macvtap_dev {
+ struct macvlan_dev m;
+ struct cdev cdev;
+ struct sk_buff_head readq;
+ wait_queue_head_t wait;
+};
+
+/*
+ * Minor number matches netdev->ifindex, so need a large value
+ */
+static int macvtap_major;
+#define MACVTAP_NUM_DEVS 65536
+
+static int macvtap_receive(struct sk_buff *skb)
+{
+ struct macvtap_dev *vtap = netdev_priv(skb->dev);
+
+ skb_queue_tail(&vtap->readq, skb);
+ wake_up(&vtap->wait);
+ return 0;
+}
+
+static int macvtap_open(struct inode *inode, struct file *file)
+{
+ struct net *net = current->nsproxy->net_ns;
+ int ifindex = iminor(inode);
+ struct net_device *dev = dev_get_by_index(net, ifindex);
+ int err;
+
+ err = -ENODEV;
+ if (!dev)
+ goto out1;
+
+ file->private_data = netdev_priv(dev);
+ err = 0;
+out1:
+ return err;
+}
+
+static int macvtap_release(struct inode *inode, struct file *file)
+{
+ struct macvtap_dev *vtap = file->private_data;
+
+ if (!vtap)
+ return 0;
+
+ dev_put(vtap->m.dev);
+ return 0;
+}
+
+/* Get packet from user space buffer */
+static ssize_t macvtap_get_user(struct macvtap_dev *vtap,
+ const struct iovec *iv, size_t count,
+ int noblock)
+{
+ struct sk_buff *skb;
+ size_t len = count;
+
+ if (unlikely(len < ETH_HLEN))
+ return -EINVAL;
+
+ skb = alloc_skb(NET_IP_ALIGN + len, GFP_KERNEL);
+
+ if (!skb) {
+ vtap->m.dev->stats.rx_dropped++;
+ return -ENOMEM;
+ }
+
+ skb_reserve(skb, NET_IP_ALIGN);
+ skb_put(skb, count);
+
+ if (skb_copy_datagram_from_iovec(skb, 0, iv, 0, len)) {
+ vtap->m.dev->stats.rx_dropped++;
+ kfree_skb(skb);
+ return -EFAULT;
+ }
+
+ skb_set_network_header(skb, ETH_HLEN);
+ skb->dev = vtap->m.lowerdev;
+
+ macvlan_start_xmit(skb, vtap->m.dev);
+
+ return count;
+}
+
+static ssize_t macvtap_aio_write(struct kiocb *iocb, const struct iovec *iv,
+ unsigned long count, loff_t pos)
+{
+ struct file *file = iocb->ki_filp;
+ ssize_t result;
+ struct macvtap_dev *vtap = file->private_data;
+
+ result = macvtap_get_user(vtap, iv, iov_length(iv, count),
+ file->f_flags & O_NONBLOCK);
+
+ return result;
+}
+
+/* Put packet to the user space buffer */
+static ssize_t macvtap_put_user(struct macvtap_dev *vtap,
+ struct sk_buff *skb,
+ struct iovec *iv, int len)
+{
+ int ret;
+
+ skb_push(skb, ETH_HLEN);
+ len = min_t(int, skb->len, len);
+
+ ret = skb_copy_datagram_iovec(skb, 0, iv, len);
+
+ vtap->m.dev->stats.rx_packets++;
+ vtap->m.dev->stats.rx_bytes += len;
+
+ return ret ? ret : len;
+}
+
+static ssize_t macvtap_aio_read(struct kiocb *iocb, const struct iovec *iv,
+ unsigned long count, loff_t pos)
+{
+ struct file *file = iocb->ki_filp;
+ struct macvtap_dev *vtap = file->private_data;
+ DECLARE_WAITQUEUE(wait, current);
+ struct sk_buff *skb;
+ ssize_t len, ret = 0;
+
+ if (!vtap)
+ return -EBADFD;
+
+ len = iov_length(iv, count);
+ if (len < 0) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ add_wait_queue(&vtap->wait, &wait);
+ while (len) {
+ current->state = TASK_INTERRUPTIBLE;
+
+ /* Read frames from the queue */
+ if (!(skb=skb_dequeue(&vtap->readq))) {
+ if (file->f_flags & O_NONBLOCK) {
+ ret = -EAGAIN;
+ break;
+ }
+ if (signal_pending(current)) {
+ ret = -ERESTARTSYS;
+ break;
+ }
+ /* Nothing to read, let's sleep */
+ schedule();
+ continue;
+ }
+ ret = macvtap_put_user(vtap, skb, (struct iovec *) iv, len);
+ kfree_skb(skb);
+ break;
+ }
+
+ current->state = TASK_RUNNING;
+ remove_wait_queue(&vtap->wait, &wait);
+
+out:
+ return ret;
+}
+
+struct file_operations macvtap_fops = {
+ .owner = THIS_MODULE,
+ .open = macvtap_open,
+ .release = macvtap_release,
+ .aio_read = macvtap_aio_read,
+ .aio_write = macvtap_aio_write,
+ .llseek = no_llseek,
+};
+
+static int macvtap_newlink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct macvtap_dev *vtap = netdev_priv(dev);
+ int err;
+
+ err = macvlan_newlink(dev, tb, data);
+ if (err)
+ goto out1;
+
+ cdev_init(&vtap->cdev, &macvtap_fops);
+ vtap->cdev.owner = THIS_MODULE;
+ err = cdev_add(&vtap->cdev, MKDEV(MAJOR(macvtap_major), dev->ifindex), 1);
+
+ if (err)
+ goto out2;
+
+ /*
+ * TODO: add class dev so device node gets created automatically
+ * by udev.
+ */
+ pr_debug("%s:%d: added cdev %d:%d for dev %s\n",
+ __func__, __LINE__, MAJOR(macvtap_major),
+ dev->ifindex, dev->name);
+
+ skb_queue_head_init(&vtap->readq);
+ init_waitqueue_head(&vtap->wait);
+ vtap->m.receive = macvtap_receive;
+
+ return 0;
+
+out2:
+ macvlan_dellink(dev);
+out1:
+ return err;
+}
+
+static void macvtap_dellink(struct net_device *dev)
+{
+ struct macvtap_dev *vtap = netdev_priv(dev);
+ cdev_del(&vtap->cdev);
+ /* TODO: kill open file descriptors */
+ macvlan_dellink(dev);
+}
+
+static struct rtnl_link_ops macvtap_link_ops __read_mostly = {
+ .kind = "macvtap",
+ .priv_size = sizeof(struct macvtap_dev),
+ .setup = macvlan_setup,
+ .validate = macvlan_validate,
+ .newlink = macvtap_newlink,
+ .dellink = macvtap_dellink,
+};
+
+static int macvtap_init(void)
+{
+ int err;
+
+ err = alloc_chrdev_region(&macvtap_major, 0,
+ MACVTAP_NUM_DEVS, "macvtap");
+ if (err)
+ goto out1;
+
+ err = rtnl_link_register(&macvtap_link_ops);
+ if (err)
+ goto out2;
+
+ return 0;
+
+out2:
+ unregister_chrdev_region(macvtap_major, MACVTAP_NUM_DEVS);
+out1:
+ return err;
+}
+module_init(macvtap_init);
+
+static void macvtap_exit(void)
+{
+ rtnl_link_unregister(&macvtap_link_ops);
+ unregister_chrdev_region(macvtap_major, MACVTAP_NUM_DEVS);
+}
+module_exit(macvtap_exit);
+
+MODULE_ALIAS_RTNL_LINK("macvtap");
+MODULE_AUTHOR("Arnd Bergmann <arnd@arndb.de>");
+MODULE_LICENSE("GPL");
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Gregory Haskins @ 2009-08-06 21:04 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <200908061903.05083.arnd@arndb.de>
>>> On 8/6/2009 at 1:03 PM, in message <200908061903.05083.arnd@arndb.de>, Arnd
Bergmann <arnd@arndb.de> wrote:
> On Thursday 06 August 2009, you wrote:
>> >>> On 8/6/2009 at 10:42 AM, in message <200908061642.40614.arnd@arndb.de>, Arnd
>> Bergmann <arnd@arndb.de> wrote:
>> > On Monday 03 August 2009, Gregory Haskins wrote:
>> >> This patch adds a pci-based driver to interface between the a host VBUS
>> >> and the guest's vbus-proxy bus model.
>> >>
>> >> Signed-off-by: Gregory Haskins <ghaskins@novell.com>
>> >
>> > This seems to be duplicating parts of virtio-pci that could be kept
>> > common by extending the virtio code. Layering on top of virtio
>> > would also make it possible to use the same features you add
>> > on top of other transports (e.g. the s390 virtio code) without
>> > adding yet another backend for each of them.
>>
>> This doesn't make sense to me, but I suspect we are both looking at what
> this
>> code does differently. I am under the impression that you may believe that
>> there is one of these objects per vbus device. Note that this is just a
> bridge
>> to vbus, so there is only one of these per system with potentially many vbus
>> devices behind it.
>
> Right, this did not become clear from the posting. For virtio, we discussed
> a model like this in the beginning and then rejected it in favour of a
> "one PCI device per virtio device" model, which I now think is a better
> approach than your pci-to-vbus bridge.
I agree that the 1:1 model may have made sense for QEMU based virtio. I think you will find it has diminished value here, however.
Here are some of my arguments against it:
1) there is an ample PCI model that is easy to work with when you are in QEMU and using its device model (and you get it for free). Its the path of least resistance. For something in kernel, it is more awkward to try to coordinate the in-kernel state with the PCI state. Afaict, you either need to have it live partially in both places, or you need some PCI emulation in the kernel.
2) The signal model for the 1:1 design is not very flexible IMO.
2a) I want to be able to allocate dynamic signal paths, not pre-allocate msi-x vectors at dev-add.
2b) I also want to collapse multiple interrupts together so as to minimize the context switch rate (inject + EIO overhead). My design effectively has "NAPI" for interrupt handling. This helps when the system needs it the most: heavy IO.
3) The 1:1 model is not buying us much in terms of hotplug. We don't really "use" PCI very much even in virtio. Its a thin-shim of uniform dev-ids to resurface to the virtio-bus as something else. With LDM, hotplug is ridiculously easy anyway, so who cares. I already need an event channel anyway for (2b) anyway, so the devadd/devdrop events are trivial to handle.
4) communicating with something efficiently in-kernel requires more finesse than basic PIO/MMIO. There are tricks you can do to get around this, but with 1:1 you would have to do this trick repeatedly for each device. Even with a library solution to help, you still have per-cpu .data overhead and cpu hotplug overhead to get maximum performance. With my "bridge" model, I do it once, which I believe is ideal.
5) 1:1 is going to quickly populate the available MMIO/PIO and IDT slots for any kind of medium to large configuration. The bridge model scales better in this regard.
So based on that, I think the bridge model works better for vbus. Perhaps you can convince me otherwise ;)
>
>> In essence, this driver's job is to populate the "vbus-proxy" LDM bus with
>> objects that it finds across the PCI-OTHER bridge. This would actually sit
>> below the virtio components in the stack, so it doesnt make sense (to me) to
>> turn around and build this on top of virtio. But perhaps I am missing
>> something you are seeing.
>>
>> Can you elaborate?
>
> Your PCI device does not serve any real purpose as far as I can tell
That is certainly debatable. Its purpose is as follows:
1) Allows a guest to discover the vbus feature (fwiw: I used to do this with cpuid)
2) Allows the guest to establish proper context to communicate with the feature (mmio, pio, and msi) (fwiw: i used to use hypercalls)
3) Access the virtual-devices that have been configured for the feature
Correct me if I am wrong: Isn't this more of less the exact intent of something like an LDM bus (vbus-proxy) and a PCI-BRIDGE? Other than the possibility that there might be some mergable overlap (still debatable), I don't think its fair to say that this does not serve a purpose.
>, you could just as well have a root device as a parent for all the vbus devices
> if you do your device probing like this.
Yes, I suppose the "bridge" could have been advertised as a virtio-based root device. In this way, the virtio probe() would replace my pci probe() for feature discovery, and a virtqueue could replace my msi+ioq for the eventq channel.
I see a few issues with that, however:
1) The virtqueue library, while a perfectly nice ring design at the metadata level, does not have an API that is friendly to kernel-to-kernel communication. It was designed more for frontend use to some remote backend. The IOQ library on the other hand, was specifically designed to support use as kernel-to-kernel (see north/south designations). So this made life easier for me. To do what you propose, the eventq channel would need to terminate in kernel, and I would thus be forced to deal that the potential API problems.
2) I would need to have Avi et. al. allocate a virtio vector to use from their namespace, which I am sure they wont be willing to do until they accept my design. Today, I have a nice conflict free PCI ID to use as I see fit.
Im sure both of these hurdles are not insurmountable, but I am left scratching my head as to why its worth the effort. It seems to me its a "six of one, half-dozen of the other" kind of scenario. Either I write a qemu PCI device and pci-bridge driver, or I write a qemu virtio-devicve and virtio root driver.
In short: What does this buy us, or did you mean something else?
>
> However, assuming that you do the IMHO right thing to do probing like
> virtio with a PCI device for each slave, the code will be almost the same
> as virtio-pci and the two can be the same.
Can you elaborate?
>
>> > This seems to add an artificial abstraction that does not make sense
>> > if you stick to the PCI abstraction.
>>
>> I think there may be confusion about what is going on here. The
> "device-open"
>> pertains to a vbus device *beyond* the bridge, not the PCI device (the
> bridge)
>> itself. Nor is the vbus device a PCI device.
>>
>> Whats happening here is somewhat analogous to a PCI config-cycle. Its
>> a way to open a channel to a device beyond the bridge in _response_ to
>> a probe.
>>
>> We have a way to enumerate devices present beyond the bridge (this yields
>> a "device-id") but in order to actually talk to the device, you must first
>> call DEVOPEN(id). When a device-id is enumerated, it generates a probe()
>> event on vbus-proxy. The responding driver in question would then turn
>> around and issue the handle = dev->open(VERSION) to see if it is compatible
>> with the device, and to establish a context for further communication.
>>
>> The reason why DEVOPEN returns a unique handle is to help ensure that the
>> driver has established proper context before allowing other calls.
>
> So assuming this kind of bus is the right idea (which I think it's not),
> why can't the host assume they are open to start with
Read on..
>and you go and enumerate the devices on the bridge, creating a vbus_device for each
> one as you go.
Thats exactly what it does.
> Then you just need to match the vbus drivers with the
> devices by some string or vendor/device ID tuple.
>
Yep, thats right too. Then, when the driver gets a ->probe(), it does an dev->open() to check various state:
a) can the device be opened? if it has an max-open policy (most will have a max-open = 1 policy) and something else already has the device open, it will fail (this will not be common).
b) is the driver ABI revision compatible with the device ABI revision? This is like checking the pci config-space revision number.
For an example, see drivers/net/vbus-enet.c, line 764:
http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=drivers/net/vbus-enet.c;h=7220f43723adc5b0bece1bc37974fae1b034cd9e;hb=b3b2339efbd4e754b1c85f8bc8f85f21a1a1f509#l764
Its simple a check to see if the driver and device are compatible, and therefore the probe should succeed. Nothing more. I think what I have done is similar to how most buses (like PCI) work today (ala revision number checks with a config-cycle).
Regarding the id->handle indirection:
Internally, the DEVOPEN call translates an "id" to a "handle". The handle is just a token to help ensure that the caller actually opened the device successfully. Note that the "id" namespace is 0 based. Therefore, something like an errant DEVCALL(0) would be indistinguishable from a legit request. Using the handle abstraction gives me a slightly more robust mechanism to ensure the caller actually meant to call the host, and was in the proper context to do so. For one thing, if the device had never been opened, this would have failed before it ever reached the model. Its one more check I can do at the infrastructure level, and one less thing each model has to look out for.
Is the id->handle translation critical? No, i'm sure we could live without it, but I also don't think it hurts anything. It allows the overall code to be slightly more robust, and the individual model code to be slightly less complicated. Therefore, I don't see a problem.
>> >
>> > This could be implemented by virtio devices as well, right?
>>
>> The big difference with dev->shm() is that it is not bound to
>> a particular ABI within the shared-memory (as opposed to
>> virtio, which assumes a virtio ABI). This just creates a
>> n empty shared-memory region (with a bidirectional signaling
>> path) which you can overlay a variety of structures (virtio
>> included). You can of course also use non-ring based
>> structures, such as, say, an array of idempotent state.
>>
>> The point is that, once this is done, you have a shared-memory
>> region and a way (via the shm-signal) to bidirectionally signal
>> changes to that memory region. You can then build bigger
>> things with it, like virtqueues.
>
> Let me try to rephrase my point: I believe you can implement
> the shm/ioq data transport on top of the virtio bus level, by
> adding shm and signal functions to struct virtio_config_ops
> alongside find_vqs() so that a virtio_device can have either
> any combination of virtqueues, shm and ioq.
Yes, I believe this might be doable, but I don't know virtio well enough to say for sure.
>
>> > static int
>> > vbus_pci_device_call(struct vbus_device_proxy *vdev, u32 func, void *data,
>> > size_t len, int flags)
>> > {
>> > struct vbus_pci_device *dev = to_dev(vdev);
>> > struct vbus_pci_hypercall params = {
>> > .vector = func,
>> > .len = len,
>> > .datap = __pa(data),
>> > };
>> > spin_lock_irqsave(&dev.lock, flags);
>> > memcpy_toio(&dev.regs->hypercall.data, ¶ms, sizeof(params));
>> > ret = ioread32(&dev.regs->hypercall.result);
>> > spin_unlock_irqrestore(&dev.lock, flags);
>> >
>> > return ret;
>> > }
>> >
>> > This gets rid of your 'handle' and the unwinding through an extra pointer
>> > indirection. You just need to make sure that the device specific call
>> > numbers
>> > don't conflict with any global ones.
>>
>> Ah, now I see the confusion...
>>
>> DEVCALL is sending a synchronous call to a specific device beyond the
> bridge. The MMIO going on here against dev.regs->hypercall.data is sending a
> synchronous call to the bridge itself. They are distinctly different ;)
>
> well, my point earlier was that they probably should not be different ;-)
Ok :)
I still do not see how they could be merged in a way that is both a) worth the effort, and b) doesn't compromise my design. But I will keep an open mind if you want to continue the conversation.
Thanks for all the feedback. I do appreciate it.
Kind Regards,
-Greg
^ permalink raw reply
* Re: [GIT PULL 0/2] IEEE 802.15.4 last-minute fixes v3
From: Dmitry Eremin-Solenikov @ 2009-08-06 20:57 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20090806.132327.210162548.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, Aug 06, 2009 at 01:23:27PM -0700, David Miller wrote:
> From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Thu, 6 Aug 2009 16:26:24 +0400
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-linus
> >
> > Dmitry Eremin-Solenikov (2):
> > af_ieee802154: fix ioctl processing
> > af_ieee802154: provide dummy get/setsockopt
>
> Pulled, thanks.
>
> I'm currently waiting for Linus to pull in a locking fix from
> Ingo Molnar from my tree, and I don't want things to "magically"
> appear in a tree I've already asked him to pull from.
>
> So I'll push these changes back out once he's taken that fix from
> Ingo.
Fine with me, thank you! Sorry for all the problems with this request :)
--
With best wishes
Dmitry
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: [PATCH 1/7] shm-signal: shared-memory signals
From: Ira W. Snyder @ 2009-08-06 20:51 UTC (permalink / raw)
To: Gregory Haskins
Cc: Arnd Bergmann, paulmck, alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <4A7ABA530200005A00051C18@sinclair.provo.novell.com>
On Thu, Aug 06, 2009 at 09:11:15AM -0600, Gregory Haskins wrote:
> Hi Arnd,
>
> >>> On 8/6/2009 at 9:56 AM, in message <200908061556.55390.arnd@arndb.de>, Arnd
> Bergmann <arnd@arndb.de> wrote:
> > On Monday 03 August 2009, Gregory Haskins wrote:
> >> shm-signal provides a generic shared-memory based bidirectional
> >> signaling mechanism. It is used in conjunction with an existing
> >> signal transport (such as posix-signals, interrupts, pipes, etc) to
> >> increase the efficiency of the transport since the state information
> >> is directly accessible to both sides of the link. The shared-memory
> >> design provides very cheap access to features such as event-masking
> >> and spurious delivery mititgation, and is useful implementing higher
> >> level shared-memory constructs such as rings.
> >
> > Looks like a very useful feature in general.
>
> Thanks, I was hoping that would be the case.
>
> >
> >> +struct shm_signal_irq {
> >> + __u8 enabled;
> >> + __u8 pending;
> >> + __u8 dirty;
> >> +};
> >
> > Won't this layout cause cache line ping pong? Other schemes I have
> > seen try to separate the bits so that each cache line is written to
> > by only one side.
>
> It could possibly use some optimization in that regard. I generally consider myself an expert at concurrent programming, but this lockless stuff is, um, hard ;) I was going for correctness first.
>
> Long story short, any suggestions on ways to split this up are welcome (particularly now, before the ABI is sealed ;)
>
> > This gets much more interesting if the two sides
> > are on remote ends of an I/O link, e.g. using a nontransparent
> > PCI bridge, where you only want to send stores over the wire, but
> > never fetches or even read-modify-write cycles.
>
> /me head explodes ;)
>
I've actually implemented this idea for virtio. Read the virtio-over-PCI
patches I posted, and you'll see that the entire virtqueue
implementation NEVER uses reads across the PCI bus, only writes. The
slowpath configuration space uses reads, but the virtqueues themselves
are write-only.
Some trivial benchmarking against an earlier driver that did
writes+reads across the PCI bus showed that the write-only driver was
about 2x as fast. (Throughput increased from ~30MB/sec to ~65MB/sec).
I'm sure the write-only design was not the only change responsible for
the speedup, but it was definitely a contributing factor.
Ira
^ permalink raw reply
* Re: [PATCH ver2] Avoid enqueuing skb for default qdiscs
From: Stephen Hemminger @ 2009-08-06 20:49 UTC (permalink / raw)
To: Krishna Kumar
Cc: davem, Jarek Poplawski, netdev, herbert, Krishna Kumar, kaber
In-Reply-To: <20090806114421.19208.39374.sendpatchset@localhost.localdomain>
On Thu, 06 Aug 2009 17:14:21 +0530
Krishna Kumar <krkumar2@in.ibm.com> wrote:
> +static inline int qdisc_qlen(struct Qdisc *q)
> +{
> + return q->q.qlen;
> +}
> +
Why?
This kind of oneline accessor decreases the code clarity.
--
^ permalink raw reply
* Re: [PATCH ver2] Avoid enqueuing skb for default qdiscs
From: David Miller @ 2009-08-06 20:41 UTC (permalink / raw)
To: krkumar2; +Cc: jarkao2, netdev, herbert, kaber
In-Reply-To: <20090806114421.19208.39374.sendpatchset@localhost.localdomain>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Thu, 06 Aug 2009 17:14:21 +0530
> -
> static inline int dev_requeue_skb(struct sk_buff *skb, struct Qdisc *q)
> {
> q->gso_skb = skb;
> q->qstats.requeues++;
> + q->q.qlen++; /* it's still part of the queue */
> __netif_schedule(q);
>
> return 0;
I'm dubious about this new qlen accounting scheme, does it handle
the non-bypass case properly? Can you explain how it works
exactly?
^ permalink raw reply
* Re: [PATCH V2 net-next-2.6] net: relax dst refcnt in input path
From: David Miller @ 2009-08-06 20:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: kaber, netdev, markmc
In-Reply-To: <4A6732D6.90809@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 22 Jul 2009 17:40:06 +0200
> [PATCH net-next-2.6] net: relax dst refcnt in input path
Two things:
1) Don't use a boolean name like "noref" it results in using
double-negatives in one's mind while trying to read and understand
the code.
Call these arguments "need_ref" or something like that.
Also, use "bool" type.
2) I wonder about this:
> @@ -1700,9 +1700,15 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
> * If device doesnt need skb->dst, release it right now while
> * its hot in this cpu cache
> */
> - if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
> - skb_dst_drop(skb);
> -
> + if (skb_dst(skb)) {
> + if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
> + skb_dst_drop(skb);
> + else
> + /*
> + * make sure dst was refcounted by caller
> + */
> + WARN_ON(!(skb->_skb_dst & SKB_DST_REFTAKEN));
> + }
> rc = ops->ndo_start_xmit(skb, dev);
> if (rc == NETDEV_TX_OK)
So, won't this warning trigger if we are forwarding to a device that
does not set IFF_XMIT_DST_RELEASE?
If I understand things correctly, in IPv4 when we're not delivering to
a socket, we don't take a reference.
We'll get here from the forwarding path with a DST, and the target TX
device has IFF_XMIT_DST_RELEASE clear, the WARN_ON above will trigger.
^ permalink raw reply
* Re: [PATCH 5/5] net: smsc911x: switch to new dev_pm_ops
From: David Miller @ 2009-08-06 20:26 UTC (permalink / raw)
To: Steve.Glendinning
Cc: daniel, linux-kernel, linux-pm, netdev, linux-sh, Ian.Saturley
In-Reply-To: <OF06D1E485.71250FEA-ON8025760A.003F9572-8025760A.00415798@smsc.com>
From: Steve.Glendinning@smsc.com
Date: Thu, 6 Aug 2009 12:53:45 +0100
> David Miller <davem@davemloft.net> wrote on 06/08/2009 04:29:22:
>
>> From: Daniel Mack <daniel@caiaq.de>
>> Date: Wed, 5 Aug 2009 20:29:31 +0200
>>
>> > Hibernation is unsupported for now, which meets the actual
>> > implementation in the driver. For free/thaw, the chip's D2 state
> should
>> > be entered.
>> >
>> > Signed-off-by: Daniel Mack <daniel@caiaq.de>
>>
>> Steve, if it looks good to you I can toss this into net-next-2.6
>>
>> Just let me know.
>
> Looks fine. Compiles ok and doesn't actually change any PM
> implementation.
>
> Acked-by: <steve.glendinning@smsc.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [GIT PULL 0/2] IEEE 802.15.4 last-minute fixes v3
From: David Miller @ 2009-08-06 20:23 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249561586-26927-1-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 6 Aug 2009 16:26:24 +0400
> git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-linus
>
> Dmitry Eremin-Solenikov (2):
> af_ieee802154: fix ioctl processing
> af_ieee802154: provide dummy get/setsockopt
Pulled, thanks.
I'm currently waiting for Linus to pull in a locking fix from
Ingo Molnar from my tree, and I don't want things to "magically"
appear in a tree I've already asked him to pull from.
So I'll push these changes back out once he's taken that fix from
Ingo.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: [PATCH] appletalk: fix atalk_getname() leak
From: David Miller @ 2009-08-06 20:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4A7ACC3F.9070600@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 Aug 2009 14:27:43 +0200
> atalk_getname() can leak 8 bytes of kernel memory to user
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 5/5] tc35815: Use 0 RxFragSize.MinFrag value for non-packing mode
From: David Miller @ 2009-08-06 20:17 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-5-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:49 +0900
> The datasheet say "When not enabling packing, the MinFrag value must
> remain at 0". Do not set value to RxFragSize register if
> TC35815_USE_PACKEDBUFFER disabled.
>
> This is not a bugfix. No real problem reported on this.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox