* Re: [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior
From: Stephen Hemminger @ 2011-12-01 16:57 UTC (permalink / raw)
To: David Laight; +Cc: Hagen Paul Pfeifer, Eric Dumazet, netdev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AEFA@saturn3.aculab.com>
On Thu, 1 Dec 2011 16:38:51 -0000
"David Laight" <David.Laight@ACULAB.COM> wrote:
>
> > One idea to do small delays at higher speed is to insert
> > dummy pad frames into the device.
> > It would mean generating garbage, but would allow for
> > highly accurate fine grain delay.
>
> Not a good idea.
> They would have to be sent to a known MAC address
> otherwise all the ethernet switches would forward them
> on all output ports.
>
> David
>
>
Yes it would have to be a constant destination, not sure if there
is a discard value in Ethernet protocol spec.
^ permalink raw reply
* Re: [PATCH] bridge: Cannot communicate with brX when its MAC address is changed
From: Stephen Hemminger @ 2011-12-01 17:21 UTC (permalink / raw)
To: Koki Sanagi; +Cc: shemminger, bridge, netdev, davem
In-Reply-To: <4ED5E9D6.3070404@jp.fujitsu.com>
On Wed, 30 Nov 2011 17:31:18 +0900
Koki Sanagi <sanagi.koki@jp.fujitsu.com> wrote:
> When the MAC address of a bridge interface is changed, it cannot communicate
> with others. Because Whether or not a packet should be transferred to bridge
> interface depends on whether or not dst of a packet is in fdb and is_local=y.
> If we change MAC address of a bridge interface, it isn't in fdb.
>
> This patch adds an condition that dst of a packet matches MAC address of
> a bridge interface to the conventional condition.
>
> Signed-off-by: Koki Sanagi <sanagi.koki@jp.fujitsu.com>
> ---
> net/bridge/br_input.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 5a31731..4e5c862 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -94,7 +94,8 @@ int br_handle_frame_finish(struct sk_buff *skb)
> skb2 = skb;
>
> br->dev->stats.multicast++;
> - } else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
> + } else if ((dst = __br_fdb_get(br, dest) && dst->is_local) ||
> + !compare_ether_addr(p->br->dev->dev_addr, dest)) {
> skb2 = skb;
> /* Do not forward the packet since it's local. */
> skb = NULL;
>
There is a problem with paren's in this version of the patch, don't apply it!
Looked into using fdb to handle this, but then there would be fdb entries
where the destination port entry was either NULL (or a dummy), and that
would require a bunch of auditing of all usages and could introduce new
bugs.
I am testing a patch that does same thing by moving compare_ether up
to where broadcast is tested.
^ permalink raw reply
* Re: [PATCH iproute2] red: make burst optional
From: Stephen Hemminger @ 2011-12-01 17:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dave Taht, David Miller, netdev
In-Reply-To: <1322749559.2335.36.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, 01 Dec 2011 15:25:59 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Documentation advises to set burst to (min+min+max)/(3*avpkt)
>
> Let tc do this automatically if user doesnt provide burst himself.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Both applied.
^ permalink raw reply
* Re: [PATCH iproute2] netem: add man-page
From: Stephen Hemminger @ 2011-12-01 17:28 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: netdev
In-Reply-To: <1322228876-10500-2-git-send-email-hagen@jauu.net>
On Fri, 25 Nov 2011 14:47:56 +0100
Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Applied
^ permalink raw reply
* Re: Bug in computing data_len in tcp_sendmsg?
From: Jesse Brandeburg @ 2011-12-01 17:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tom Herbert, Linux Netdev List, David Miller, alexander.h.duyck
In-Reply-To: <1322730937.2335.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, 1 Dec 2011 01:15:37 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 30 novembre 2011 à 21:09 -0800, Tom Herbert a écrit :
> > > We recently added commit f07d960df33c5aef
> > > (tcp: avoid frag allocation for small frames)
> >
> > Yes, reverting that patch seems to fix the problem. Eric, do you have
> > an idea what should be used to determine length of headers in an skb
> > now (mac through transport).
Tom, thanks very much for finding this subtle bug! I bet that this
commit (which I had missed) broke a lot of other drivers in
very subtle ways due to changing a long standing behavior. Auditing
every driver's tx path is going to be a lot of work unless a way can be
discovered to automate finding incorrect assumptions in drivers.
> I dont know why its even necessary :
>
> TSO enabled NIC all provide hardware counters, so why even bother
> computing tx_bytes ourself ?
because we have runtime logic for adjusting interrupt rate that depends
on knowing how many bytes and packets were cleaned up in an interrupt
and reading MMIO to get latest stats causes CPU stall in hot path.
Counting the bytes sent on the wire via a segmented SKB was hard to get
right to begin with, I think we took a different approach in ixgbe
(recent versions) and compute the math in hard_start_xmit instead of tx
cleanup.
> skb->len is appropriate for BQL, as long as producers/consumer use the
> same skb->len. 1 or 2% error is not a problem if not cumulative ?
if skb->len access doesn't cause a cache miss in hot path (or at
least doesn't increase misses) then I say sure.
^ permalink raw reply
* Re: [PATCH v2] net: net_device flags is an unsigned int
From: David Miller @ 2011-12-01 17:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322725346.2577.31.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 01 Dec 2011 08:42:26 +0100
> commit b00055aacdb ([NET] core: add RFC2863 operstate) changed
> net_device flags from unsigned short to unsigned int.
>
> Some core functions still assume its an unsigned short.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] dsa: Include linux/if_ether.h to fix build error
From: David Miller @ 2011-12-01 17:41 UTC (permalink / raw)
To: axel.lin; +Cc: linux-kernel, netdev
In-Reply-To: <1322726838.14554.3.camel@phoenix>
From: Axel Lin <axel.lin@gmail.com>
Date: Thu, 01 Dec 2011 16:07:18 +0800
> Include linux/if_ether.h to fix below build errors:
>
> CC arch/arm/mach-kirkwood/common.o
> In file included from arch/arm/mach-kirkwood/common.c:19:
> include/net/dsa.h: In function 'dsa_uses_dsa_tags':
> include/net/dsa.h:192: error: 'ETH_P_DSA' undeclared (first use in this function)
> include/net/dsa.h:192: error: (Each undeclared identifier is reported only once
> include/net/dsa.h:192: error: for each function it appears in.)
> include/net/dsa.h: In function 'dsa_uses_trailer_tags':
> include/net/dsa.h:197: error: 'ETH_P_TRAILER' undeclared (first use in this function)
> make[1]: *** [arch/arm/mach-kirkwood/common.o] Error 1
> make: *** [arch/arm/mach-kirkwood] Error 2
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied.
^ permalink raw reply
* [PATCH 0/2] unix: Introduce /proc/net/unix_peers file
From: Pavel Emelyanov @ 2011-12-01 17:41 UTC (permalink / raw)
To: Linux Netdev List, David Miller, Eric Dumazet
Hi.
There's a common problem with unix sockets -- there's no way to determine
which tasks are connected to each other with a unix socket. Although the
/proc/<pid>/fd/<n> symlink shows a socket inode number, the peers do not
share an inode and thus these numbers give no answer.
There have been an attempt last year to print the peer=<number> for unbound
sockets in the existing /proc/net/unix file, but it was left unfinished and
had problems with bound sockets - for those the peer inode was still unknown
and the name didn't help at all.
I'd like to have this ability (determining the unix connection endpoints)
implemented and propose to introduce a /proc/net/unix_peers file with socket
inode number pairs. For not connected sockets 0 is printed.
Are there strong objections against this approach?
Patches apply to net-next tree.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
^ permalink raw reply
* [PATCH 1/2] unix: Reformat proc files creation
From: Pavel Emelyanov @ 2011-12-01 17:41 UTC (permalink / raw)
To: Linux Netdev List, David Miller, Eric Dumazet
In-Reply-To: <4ED7BC37.2030805@parallels.com>
This just makes codepaths better prepared for yet another
proc file creation.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
net/unix/af_unix.c | 34 +++++++++++++++++++++++++++-------
1 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 466fbcc..4b83a9c 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2326,6 +2326,29 @@ static const struct file_operations unix_seq_fops = {
.release = seq_release_net,
};
+static int unix_proc_create(struct net *net)
+{
+ if (!proc_net_fops_create(net, "unix", 0, &unix_seq_fops))
+ goto out;
+
+ return 0;
+out:
+ return -ENOMEM;
+}
+
+static void unix_proc_destroy(struct net *net)
+{
+ proc_net_remove(net, "unix");
+}
+#else
+static inline int unix_proc_create(struct net *net)
+{
+ return 0;
+}
+
+static inline void unix_proc_destroy(struct net *net)
+{
+}
#endif
static const struct net_proto_family unix_family_ops = {
@@ -2343,13 +2366,10 @@ static int __net_init unix_net_init(struct net *net)
if (unix_sysctl_register(net))
goto out;
-#ifdef CONFIG_PROC_FS
- if (!proc_net_fops_create(net, "unix", 0, &unix_seq_fops)) {
+ error = unix_proc_create(net);
+ if (error)
unix_sysctl_unregister(net);
- goto out;
- }
-#endif
- error = 0;
+
out:
return error;
}
@@ -2357,7 +2377,7 @@ out:
static void __net_exit unix_net_exit(struct net *net)
{
unix_sysctl_unregister(net);
- proc_net_remove(net, "unix");
+ unix_proc_destroy(net);
}
static struct pernet_operations unix_net_ops = {
--
1.5.5.6
^ permalink raw reply related
* [PATCH 2/2] unix: Add /proc/net/unix_peers file
From: Pavel Emelyanov @ 2011-12-01 17:42 UTC (permalink / raw)
To: Linux Netdev List, David Miller, Eric Dumazet
In-Reply-To: <4ED7BC37.2030805@parallels.com>
Currently it's not possible to find out what processes are connected
to each other via a unix socket. In the proposed proc file a socket
inode number and its peer inode number are shown. With these two at
hands it's possible to determine the unix connections endpoints.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
net/unix/af_unix.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 4b83a9c..4ce425a 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2305,6 +2305,33 @@ static int unix_seq_show(struct seq_file *seq, void *v)
return 0;
}
+static int unix_peers_seq_show(struct seq_file *seq, void *v)
+{
+ struct sock *s = v, *peer;
+ unsigned long ino, peer_ino = 0;
+
+ if (v == SEQ_START_TOKEN)
+ return 0;
+
+ unix_state_lock(s);
+ ino = sock_i_ino(s);
+ peer = unix_peer(s);
+ if (peer)
+ sock_hold(peer);
+ unix_state_unlock(s);
+
+ if (peer) {
+ unix_state_lock(peer);
+ peer_ino = sock_i_ino(peer);
+ unix_state_unlock(peer);
+
+ sock_put(peer);
+ }
+
+ seq_printf(seq, "%5lu %5lu\n", ino, peer_ino);
+ return 0;
+}
+
static const struct seq_operations unix_seq_ops = {
.start = unix_seq_start,
.next = unix_seq_next,
@@ -2326,18 +2353,46 @@ static const struct file_operations unix_seq_fops = {
.release = seq_release_net,
};
+static const struct seq_operations unix_peers_seq_ops = {
+ .start = unix_seq_start,
+ .next = unix_seq_next,
+ .stop = unix_seq_stop,
+ .show = unix_peers_seq_show,
+};
+
+static int unix_peers_seq_open(struct inode *inode, struct file *file)
+{
+ return seq_open_net(inode, file, &unix_peers_seq_ops,
+ sizeof(struct unix_iter_state));
+}
+
+static const struct file_operations unix_peers_seq_fops = {
+ .owner = THIS_MODULE,
+ .open = unix_peers_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release_net,
+};
+
static int unix_proc_create(struct net *net)
{
if (!proc_net_fops_create(net, "unix", 0, &unix_seq_fops))
goto out;
+ if (!proc_net_fops_create(net, "unix_peers", 0, &unix_peers_seq_fops))
+ goto out_peers;
+
return 0;
+
+out_peers:
+ proc_net_remove(net, "unix");
out:
return -ENOMEM;
}
static void unix_proc_destroy(struct net *net)
{
+ proc_net_remove(net, "unix_peers");
proc_net_remove(net, "unix");
}
#else
--
1.5.5.6
^ permalink raw reply related
* Re: ebtables on a stick
From: Michal Soltys @ 2011-12-01 17:44 UTC (permalink / raw)
To: Greg Scott; +Cc: David Lamparter, netdev
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A048F6@mail733.InfraSupportEtc.com>
On 11-12-01 06:46, Greg Scott wrote:
> Well this is frustrating. Now my public host can communicate anywhere
> it wants internally but nothing outside. Maddening - the exact
> opposite problem I had before.
>
>
> $IPTABLES -A FORWARD -s 1.2.115.157 -j ACCEPT
> $IPTABLES -A FORWARD -s 192.168.10.0/24 -d 1.2.115.157 -j ACCEPT
> $IPTABLES -A FORWARD -p TCP --dport 1720 -d $ADR -j allowed
> $IPTABLES -A FORWARD -p TCP -s $MGMT_IP -d $ADR -j allowed
>
And accepting traffic to 1.2.115.157 from the outside ? Are there any -m
state / -m conntrack --ctstate entries in your rules ?
^ permalink raw reply
* Re: [PATCH net-next] netem: fix build error on 32bit arches
From: David Miller @ 2011-12-01 17:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: hagen, netdev
In-Reply-To: <1322731934.2335.12.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 01 Dec 2011 10:32:14 +0100
> ERROR: "__udivdi3" [net/sched/sch_netem.ko] undefined!
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4 06/10] e1000e: Support for byte queue limits
From: David Miller @ 2011-12-01 17:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, jesse.brandeburg, netdev
In-Reply-To: <1322734334.2335.20.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 01 Dec 2011 11:12:14 +0100
> OK, as stated on your other thread, its obvious this driver (and
> probably other intel drivers) made assumptions that are now obsolete,
> since skb head can contain some data payload, not only (MAC+IP+TCP)
> headers.
They were always wrong assumptions even before your patch Eric.
Any Netfilter or similar module can pull some data into the linear
area before the driver sees the packet on transmit.
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-01 17:51 UTC (permalink / raw)
To: Michal Soltys; +Cc: David Lamparter, netdev
In-Reply-To: <4ED7BCE8.1040307@ziu.info>
Yes. 1.2.115.157 will eventually be an H.323 codec and will need to accept incoming calls. For right now, it's just a test Windows system I had handy.
I should have copied you on some of the other emails this morning. They should be in the netdev list but I'll forward them privately too.
- Greg
-----Original Message-----
From: Michal Soltys [mailto:soltys@ziu.info]
Sent: Thursday, December 01, 2011 11:44 AM
To: Greg Scott
Cc: David Lamparter; netdev@vger.kernel.org
Subject: Re: ebtables on a stick
On 11-12-01 06:46, Greg Scott wrote:
> Well this is frustrating. Now my public host can communicate anywhere
> it wants internally but nothing outside. Maddening - the exact
> opposite problem I had before.
>
>
> $IPTABLES -A FORWARD -s 1.2.115.157 -j ACCEPT
> $IPTABLES -A FORWARD -s 192.168.10.0/24 -d 1.2.115.157 -j ACCEPT
> $IPTABLES -A FORWARD -p TCP --dport 1720 -d $ADR -j allowed
> $IPTABLES -A FORWARD -p TCP -s $MGMT_IP -d $ADR -j allowed
>
And accepting traffic to 1.2.115.157 from the outside ? Are there any -m
state / -m conntrack --ctstate entries in your rules ?
^ permalink raw reply
* Re: [PATCH net] ipv4: flush route cache after change accept_local
From: David Miller @ 2011-12-01 17:52 UTC (permalink / raw)
To: panweiping3; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1e224b52de77dcd5f994c8e4c77c780c6996e4a4.1322740026.git.panweiping3@gmail.com>
From: Weiping Pan <panweiping3@gmail.com>
Date: Thu, 1 Dec 2011 19:47:56 +0800
> + if ((i == IPV4_DEVCONF_ACCEPT_LOCAL - 1))
I don't think the extra parenthesis is appropriate here, please only use
one set of them.
Thanks.
^ permalink raw reply
* [PATCH] drivers/net/ethernet/tile: use skb_frag_page() API
From: Chris Metcalf @ 2011-12-01 17:56 UTC (permalink / raw)
To: linux-kernel, netdev
This replaces raw access to the "page" field of the skb_frag_t.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
---
drivers/net/ethernet/tile/tilepro.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilepro.c b/drivers/net/ethernet/tile/tilepro.c
index 10826d8..1c0f9fa 100644
--- a/drivers/net/ethernet/tile/tilepro.c
+++ b/drivers/net/ethernet/tile/tilepro.c
@@ -1697,7 +1697,7 @@ static unsigned int tile_net_tx_frags(lepp_frag_t *frags,
for (i = 0; i < sh->nr_frags; i++) {
skb_frag_t *f = &sh->frags[i];
- unsigned long pfn = page_to_pfn(f->page);
+ unsigned long pfn = page_to_pfn(skb_frag_page(f));
/* FIXME: Compute "hash_for_home" properly. */
/* ISSUE: The hypervisor checks CHIP_HAS_REV1_DMA_PACKETS(). */
@@ -1706,7 +1706,7 @@ static unsigned int tile_net_tx_frags(lepp_frag_t *frags,
/* FIXME: Hmmm. */
if (!hash_default) {
void *va = pfn_to_kaddr(pfn) + f->page_offset;
- BUG_ON(PageHighMem(f->page));
+ BUG_ON(PageHighMem(skb_frag_page(f)));
finv_buffer_remote(va, f->size, 0);
}
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH v2] icplus: mdio_write(), remove unnecessary for loop
From: David Miller @ 2011-12-01 17:55 UTC (permalink / raw)
To: patrick.kelle81; +Cc: netdev, romieu, sorbica
In-Reply-To: <1322746016-2835-1-git-send-email-patrick.kelle81@gmail.com>
From: Patrick Kelle <patrick.kelle81@gmail.com>
Date: Thu, 1 Dec 2011 14:26:56 +0100
> At this point the variable j is always set to 7 and the code within
> the loop has to run only once anyway.
>
> As suggested by David Miller:
> "You can simply this even further since p[7] is what is used here,
> and this means len is one, the inner loop therefore executes only
> once, and the p[7].field value is not used (it's zero in the table)
> and the write to it is completely thrown away."
>
> Signed-off-by: Patrick Kelle <patrick.kelle81@gmail.com>
Applied.
^ permalink raw reply
* [PATCH] arch/tile: use new generic {enable,disable}_percpu_irq() routines
From: Chris Metcalf @ 2011-12-01 17:58 UTC (permalink / raw)
To: linux-kernel, Thomas Gleixner, netdev
We provided very similar routines internally, but now we can hook
into the generic framework by supplying our routines as function
pointers in the irq_chip structure instead.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
---
arch/tile/include/asm/irq.h | 10 ----------
arch/tile/kernel/irq.c | 16 ++++++++--------
drivers/net/ethernet/tile/tilepro.c | 4 ++--
3 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/arch/tile/include/asm/irq.h b/arch/tile/include/asm/irq.h
index 94e9a51..f80f8ce 100644
--- a/arch/tile/include/asm/irq.h
+++ b/arch/tile/include/asm/irq.h
@@ -74,16 +74,6 @@ enum {
*/
void tile_irq_activate(unsigned int irq, int tile_irq_type);
-/*
- * For onboard, non-PCI (e.g. TILE_IRQ_PERCPU) devices, drivers know
- * how to use enable/disable_percpu_irq() to manage interrupts on each
- * core. We can't use the generic enable/disable_irq() because they
- * use a single reference count per irq, rather than per cpu per irq.
- */
-void enable_percpu_irq(unsigned int irq);
-void disable_percpu_irq(unsigned int irq);
-
-
void setup_irq_regs(void);
#endif /* _ASM_TILE_IRQ_H */
diff --git a/arch/tile/kernel/irq.c b/arch/tile/kernel/irq.c
index aa0134d..02e6280 100644
--- a/arch/tile/kernel/irq.c
+++ b/arch/tile/kernel/irq.c
@@ -152,14 +152,13 @@ void tile_dev_intr(struct pt_regs *regs, int intnum)
* Remove an irq from the disabled mask. If we're in an interrupt
* context, defer enabling the HW interrupt until we leave.
*/
-void enable_percpu_irq(unsigned int irq)
+static void tile_irq_chip_enable(struct irq_data *d)
{
- get_cpu_var(irq_disable_mask) &= ~(1UL << irq);
+ get_cpu_var(irq_disable_mask) &= ~(1UL << d->irq);
if (__get_cpu_var(irq_depth) == 0)
- unmask_irqs(1UL << irq);
+ unmask_irqs(1UL << d->irq);
put_cpu_var(irq_disable_mask);
}
-EXPORT_SYMBOL(enable_percpu_irq);
/*
* Add an irq to the disabled mask. We disable the HW interrupt
@@ -167,13 +166,12 @@ EXPORT_SYMBOL(enable_percpu_irq);
* in an interrupt context, the return path is careful to avoid
* unmasking a newly disabled interrupt.
*/
-void disable_percpu_irq(unsigned int irq)
+static void tile_irq_chip_disable(struct irq_data *d)
{
- get_cpu_var(irq_disable_mask) |= (1UL << irq);
- mask_irqs(1UL << irq);
+ get_cpu_var(irq_disable_mask) |= (1UL << d->irq);
+ mask_irqs(1UL << d->irq);
put_cpu_var(irq_disable_mask);
}
-EXPORT_SYMBOL(disable_percpu_irq);
/* Mask an interrupt. */
static void tile_irq_chip_mask(struct irq_data *d)
@@ -209,6 +207,8 @@ static void tile_irq_chip_eoi(struct irq_data *d)
static struct irq_chip tile_irq_chip = {
.name = "tile_irq_chip",
+ .irq_enable = tile_irq_chip_enable,
+ .irq_disable = tile_irq_chip_disable,
.irq_ack = tile_irq_chip_ack,
.irq_eoi = tile_irq_chip_eoi,
.irq_mask = tile_irq_chip_mask,
diff --git a/drivers/net/ethernet/tile/tilepro.c b/drivers/net/ethernet/tile/tilepro.c
index 1c0f9fa..1187a11 100644
--- a/drivers/net/ethernet/tile/tilepro.c
+++ b/drivers/net/ethernet/tile/tilepro.c
@@ -926,7 +926,7 @@ static int tile_net_poll(struct napi_struct *napi, int budget)
goto done;
/* Re-enable the ingress interrupt. */
- enable_percpu_irq(priv->intr_id);
+ enable_percpu_irq(priv->intr_id, 0);
/* HACK: Avoid the "rotting packet" problem (see above). */
if (qup->__packet_receive_read !=
@@ -1296,7 +1296,7 @@ static void tile_net_open_enable(void *dev_ptr)
info->napi_enabled = true;
/* Enable the ingress interrupt. */
- enable_percpu_irq(priv->intr_id);
+ enable_percpu_irq(priv->intr_id, 0);
}
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: David Miller @ 2011-12-01 18:00 UTC (permalink / raw)
To: kirr; +Cc: therbert, eric.dumazet, netdev
In-Reply-To: <20111201165018.GA19451@tugrik.mns.mnsspb.ru>
From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Thu, 1 Dec 2011 20:50:18 +0400
> One "regression" is it is now not possible to disable BQL at compile time,
> because CONFIG_BQL can't be set to "n" via usual ways.
>
> Description and patch below. Thanks.
It's intentional, and your patch will not be applied.
The Kconfig entry and option is merely for expressing internal dependencies,
not for providing a way to disable the code.
^ permalink raw reply
* Re: [PATCH] bridge: Cannot communicate with brX when its MAC address is changed
From: David Miller @ 2011-12-01 18:02 UTC (permalink / raw)
To: shemminger; +Cc: sanagi.koki, netdev, bridge, shemminger
In-Reply-To: <20111201092106.00473fed@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 1 Dec 2011 09:21:06 -0800
> Looked into using fdb to handle this, but then there would be fdb entries
> where the destination port entry was either NULL (or a dummy), and that
> would require a bunch of auditing of all usages and could introduce new
> bugs.
>
> I am testing a patch that does same thing by moving compare_ether up
> to where broadcast is tested.
Stephen please fix this bug correctly.
The bug is that the FDB gets updated with the initial MAC address, but
doesn't get updated when the MAC address changes.
There is no other valid fix than to update the FDB when the MAC changes,
and making whatever is necessary for that to work.
I'm not applying a patch that adds a MAC address comparison here, because
you might was well not add the FDB entry in the first place if you're
going to add a hack like that.
^ permalink raw reply
* Re: Bug in computing data_len in tcp_sendmsg?
From: David Miller @ 2011-12-01 18:04 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: eric.dumazet, therbert, netdev, alexander.h.duyck
In-Reply-To: <20111201092950.00006ce8@unknown>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Thu, 1 Dec 2011 09:29:50 -0800
> Tom, thanks very much for finding this subtle bug! I bet that this
> commit (which I had missed) broke a lot of other drivers in
> very subtle ways due to changing a long standing behavior.
I call bullshit on this.
It's always been possible, any entity between the TCP stack and your
driver can pull data from the segmented pages into the linear data
area.
F.e. netfilter, packet scheduler actions, you name it.
This code sequence has always been buggy.
^ permalink raw reply
* Re: [PATCH next-next 0/2] can: cc770: add support for the Bosch CC770 and Intel AN82527
From: David Miller @ 2011-12-01 18:09 UTC (permalink / raw)
To: socketcan; +Cc: wg, netdev, linux-can, mkl, urs
In-Reply-To: <4ED73117.1020101@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 01 Dec 2011 08:47:35 +0100
> On 30.11.2011 22:07, David Miller wrote:
>
> To make it clear:
>
> Wolfgang Grandegger maintains drivers/net/can
>
> and
>
> Oliver Hartkopp maintains net/can
>
> As Marc Kleine-Budde is also very active in CAN driver development we should
> probably add him to the drivers/net/can maintainers.
>
> We'll continue the discussion on linux-can ML and give an update to the
> MAINTAINERS file if we sorted out any changes. So far Wolfgang and me remain
> the 'only interface' for you. Sorry for the traffic & confusion on netdev.
I said I want one person. One person who periodically send me GIT pull requests
or a patch series for "CAN updates" of all kinds.
Just like how the wireless stuff is maintained. They don't send me driver vs.
protcol layer vs. rfcomm vs. bluetooth changes seperately, John Linville collects
everything and sends me periodic pull requests.
And this is what I want from you guys. One person who explicitly says "Dave, please
take in these CAN changes" rather than the confusing manner in which changes get
submitted currently.
Thanks.
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 000000000000002c
From: Christoph Hellwig @ 2011-12-01 18:23 UTC (permalink / raw)
To: Stefan Priebe; +Cc: netdev, Dave Chinner, stable
In-Reply-To: <4ED7C367.3070109@profihost.ag>
On Thu, Dec 01, 2011 at 07:11:51PM +0100, Stefan Priebe wrote:
> Hi,
>
> i'm not quite sure if this is an XFS thing or a tcp thing. As the
> stacktrace confuses me a little but as it contains
> xfs_bmap_search_extents and xfs_iunlock. Kernel is 3.0.11 running as
> 2.6.40.11.
>
> [171464.091567] BUG: unable to handle kernel NULL pointer
> dereference at 000000000000002c
> [171464.092073] IP: [<ffffffff815494f6>] ipv4_dst_check+0xb6/0x190
> [171464.092073] PGD 15344e067 PUD 14c821067 PMD 0
> [171464.092073] Oops: 0002 [#1] SMP
>
> Full Stacktrace:
> http://pastebin.com/raw.php?i=QNg6jD2t
The ? entries mean even the backtrace code things they are unreliable,
and mos of the cases I've seen they are wrong. In this case it looks
like the process was doing XFS work before, but the current system call
indeed is purely in the networking code.
I've changed the cc list to the netdev list which is more appropinquate.
^ permalink raw reply
* Re: [PATCH net-next v6 0/4] can: cc770: add support for the Bosch CC770 and Intel AN82527
From: David Miller @ 2011-12-01 18:24 UTC (permalink / raw)
To: wg; +Cc: netdev, linux-can, socketcan-users
In-Reply-To: <1322732481-2255-1-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Thu, 1 Dec 2011 10:41:17 +0100
> Already since a while we have support for the Bosch CC770 and Intel
> AN82527 CAN controllers in our out-of-tree Socket-CAN repository.
>
> In the meantime I found a TQM855L board with two AN82527 on it,
> which allowed me to provide and test a generic platform driver
> as well.
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior
From: Rick Jones @ 2011-12-01 18:25 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Laight, Hagen Paul Pfeifer, Eric Dumazet, netdev
In-Reply-To: <20111201085701.02f885c5@nehalam.linuxnetplumber.net>
On 12/01/2011 08:57 AM, Stephen Hemminger wrote:
> On Thu, 1 Dec 2011 16:38:51 -0000
> "David Laight"<David.Laight@ACULAB.COM> wrote:
>
>>
>>> One idea to do small delays at higher speed is to insert
>>> dummy pad frames into the device.
>>> It would mean generating garbage, but would allow for
>>> highly accurate fine grain delay.
>>
>> Not a good idea.
>> They would have to be sent to a known MAC address
>> otherwise all the ethernet switches would forward them
>> on all output ports.
>>
>> David
>>
>>
>
> Yes it would have to be a constant destination, not sure if there
> is a discard value in Ethernet protocol spec.
Aren't there special addresses that aren't supposed to be forwarded by
(intelligent) switches? IIRC LLDP uses such things. Though the IEEE
may take a dim view of using it for such a purpose, and knuth only knows
what switch bugs would be uncovered that way...
http://standards.ieee.org/develop/regauth/grpmac/public.html
http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
rick jones
^ 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