* [PATCH] davinci: da850/omap-l138: Add Carrier Link OK check in Davinci RX Handler
From: Hegde, Vinay @ 2011-02-25 9:56 UTC (permalink / raw)
To: netdev; +Cc: khilman, davinci-linux-open-source, linux-arm-kernel,
Hegde, Vinay
This patch adds an additional check in the Davinci EMAC RX Handler,
which tests the __LINK_STATE_NOCARRIER flag along with the
__LINK_STATE_START flag as part EMAC shutting down procedure.
This avoids
WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf8/0x120()
during rtcwake used to suspend the target for a specified duration.
Signed-off-by: Hegde, Vinay <vinay.hegde@ti.com>
---
drivers/net/davinci_emac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 2a628d1..7018bfe 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1008,7 +1008,7 @@ static void emac_rx_handler(void *token, int len, int status)
int ret;
/* free and bail if we are shutting down */
- if (unlikely(!netif_running(ndev))) {
+ if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
dev_kfree_skb_any(skb);
return;
}
--
1.7.1
^ permalink raw reply related
* Re: Bug inkvm_set_irq
From: Gleb Natapov @ 2011-02-25 10:36 UTC (permalink / raw)
To: Jean-Philippe Menil; +Cc: kvm, netdev, virtualization, mst
In-Reply-To: <4D67714A.2050100@univ-nantes.fr>
CCing Michael in case he missed this.
On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote:
> Hi,
>
> Each time i try tou use vhost_net, i'm facing a kernel bug.
> I do a "modprobe vhost_net", and start guest whith vhost=on.
>
> Following is a trace with a kernel 2.6.37, but i had the same
> problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29).
>
> The bug only occurs whith vhost_net charged, so i don't know if this
> is a bug in kvm module code or in the vhost_net code.
>
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.243100] BUG: unable to handle kernel paging request at
> 0000000000002458
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.243250] IP: [<ffffffffa041aa8a>] kvm_set_irq+0x2a/0x130 [kvm]
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.243378] PGD 45d363067 PUD 45e77a067 PMD 0
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.243556] Oops: 0000 [#1] SMP
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.243692] last sysfs file:
> /sys/devices/pci0000:00/0000:00:0d.0/0000:05:00.0/0000:06:00.0/irq
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU 0
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.243820] Modules linked in: vhost_net macvtap macvlan tun
> powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave
> cpufreq_ondemand fre
> q_table cpufreq_conservative fuse xt_physdev ip6t_LOG
> ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp
> xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp
> nf_conntrack_ftp nf_connt
> rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache
> dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack
> nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore
> snd_page_alloc tpm_tis tpm ps
> mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes
> serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys
> xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses
> sd_mod enclosu
> re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2
> scsi_mod ehci_hcd [last unloaded: scsi_wait_scan]
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123]
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] Pid: 10, comm: kworker/0:1 Not tainted
> 2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] RIP: 0010:[<ffffffffa041aa8a>] [<ffffffffa041aa8a>]
> kvm_set_irq+0x2a/0x130 [kvm]
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] RSP: 0018:ffff88045fc89d30 EFLAGS: 00010246
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] RAX: 0000000000000000 RBX: 000000000000001a RCX:
> 0000000000000001
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> 0000000000000000
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] RBP: 0000000000000000 R08: 0000000000000001 R09:
> ffff880856a91e48
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] R10: 0000000000000000 R11: 00000000ffffffff R12:
> 0000000000000000
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] R13: 0000000000000001 R14: 0000000000000000 R15:
> 0000000000000000
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] FS: 00007f617986c710(0000) GS:ffff88007f800000(0000)
> knlGS:0000000000000000
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] CR2: 0000000000002458 CR3: 000000045d197000 CR4:
> 00000000000006f0
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] Process kworker/0:1 (pid: 10, threadinfo
> ffff88045fc88000, task ffff88085fc53c30)
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Stack:
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] ffff88045fc89fd8 00000000000119c0 ffff88045fc88010
> ffff88085fc53ee8
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] ffff88045fc89fd8 ffff88085fc53ee0 ffff88085fc53c30
> 00000000000119c0
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] 00000000000119c0 ffffffff8137f7ce ffff88007f80df40
> 00000000ffffffff
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] Call Trace:
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff8137f7ce>] ? common_interrupt+0xe/0x13
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffffa041bc30>] ? irqfd_inject+0x0/0x50 [kvm]
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffffa041bc57>] ? irqfd_inject+0x27/0x50 [kvm]
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffffa041bc30>] ? irqfd_inject+0x0/0x50 [kvm]
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff8106b6f2>] ? process_one_work+0x112/0x460
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff8106be25>] ? worker_thread+0x145/0x410
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff8103a3d0>] ? __wake_up_common+0x50/0x80
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff8106bce0>] ? worker_thread+0x0/0x410
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff8106bce0>] ? worker_thread+0x0/0x410
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff8106f786>] ? kthread+0x96/0xa0
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff81003ce4>] ? kernel_thread_helper+0x4/0x10
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff8106f6f0>] ? kthread+0x0/0xa0
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] [<ffffffff81003ce0>] ? kernel_thread_helper+0x0/0x10
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] Code: ff 41 57 41 89 f7 41 56 41 55 41 89 cd 41 54 49 89
> fc 55 53 89 d3 48 81 ec 98 00 00 00 8b 15 c6 79 03 00 85 d2 0f 85 c4
> 00 00 00 <4
> 9> 8b 84 24 58 24 00 00 3b 98 28 01 00 00 73 5e 89 db 48 8b 84
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] RIP [<ffffffffa041aa8a>] kvm_set_irq+0x2a/0x130 [kvm]
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] RSP <ffff88045fc89d30>
> Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [
> 685.246123] CR2: 0000000000002458
>
>
> If someone can help me, on how to solve this.
>
> Regards.
> begin:vcard
> fn:Jean-Philippe Menil
> n:Menil;Jean-Philippe
> org;quoted-printable:Universit=C3=A9 de Nantes;IRTS
> adr;dom:;;;Nantes
> email;internet:jean-philippe.menil@univ-nantes.fr
> title:Reseau
> tel;work:02.53.48.49.27
> tel;fax:02.53.48.49.97
> x-mozilla-html:FALSE
> version:2.1
> end:vcard
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization
--
Gleb.
^ permalink raw reply
* Re: [PATCH ref0] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-02-25 10:52 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <AANLkTikmqQfT1s2Z6J+KYmqi0CuCc4+2k67eeb4ydtCM@mail.gmail.com>
Le vendredi 25 février 2011 à 17:45 +0800, Po-Yu Chuang a écrit :
> It's a little faster than v5 now. Thanks.
> I will submit the current version later.
>
> One more question just curious, why 128 bytes?
Probably its best for NIU hardware specs
You could try 64, as it should be enough for most IP/TCP/UDP processing.
^ permalink raw reply
* Re: [PATCH v6] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-02-25 11:40 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <1298627845-1583-1-git-send-email-ratbert.chuang@gmail.com>
Le vendredi 25 février 2011 à 17:57 +0800, Po-Yu Chuang a écrit :
> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>
> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
> MII. This driver has been working on some ARM/NDS32 SoC's including
> Faraday A320 and Andes AG101.
>
> Signed-off-by: Po-Yu Chuang <ratbert@faraday-tech.com>
It seems fine to me, but I have somes questions
1) On V5, the receive function ftmac100_rx_packet() was able to process
several segments per skb. On V6 you process one frag only.
Isnt this NIC able to handle large MTU (say... 9000) ?
2) ftmac100_alloc_rx_page() is called and allocate a full page for a
rxdes.
128*4K -> 512 Kbytes of memory for RX ring
In V5, you were using half pages only, so 256 kbytes of memory.
If you look at other drivers (NIU, BENET), they are able to use exactly
128*2 kbytes (for a rxring of 128 slots, and 2Kbytes per slot)
^ permalink raw reply
* Re: [PATCH] davinci: da850/omap-l138: Add Carrier Link OK check in Davinci RX Handler
From: Sergei Shtylyov @ 2011-02-25 11:55 UTC (permalink / raw)
To: Hegde, Vinay; +Cc: netdev, davinci-linux-open-source, linux-arm-kernel
In-Reply-To: <1298627788-32339-1-git-send-email-vinay.hegde@ti.com>
Hello.
On 25-02-2011 12:56, Hegde, Vinay wrote:
This is not a patch to arch/arm/mach-davinci/, so the summary prefix
should not be "davinci: da850/omap-l138:" but rather "davinci_emac:" as you're
patching this driver.
> This patch adds an additional check in the Davinci EMAC RX Handler,
> which tests the __LINK_STATE_NOCARRIER flag along with the
> __LINK_STATE_START flag as part EMAC shutting down procedure.
> This avoids
> WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf8/0x120()
> during rtcwake used to suspend the target for a specified duration.
> Signed-off-by: Hegde, Vinay <vinay.hegde@ti.com>
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 2a628d1..7018bfe 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -1008,7 +1008,7 @@ static void emac_rx_handler(void *token, int len, int status)
> int ret;
>
> /* free and bail if we are shutting down */
> - if (unlikely(!netif_running(ndev))) {
> + if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
> dev_kfree_skb_any(skb);
> return;
> }
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] udp: avoid searching when no ports are available
From: Eric Dumazet @ 2011-02-25 12:06 UTC (permalink / raw)
To: Daniel Baluta; +Cc: netdev, davem, Rohan Chitradurga
In-Reply-To: <1298633711-11924-1-git-send-email-dbaluta@ixiacom.com>
Le vendredi 25 février 2011 à 13:35 +0200, Daniel Baluta a écrit :
> udp_lib_get_port uses a bitmap to mark used ports.
>
> When no ports are available we spend a lot of time, searching
> for a port while holding hslot lock. Avoid this by checking if
> bitmap is full.
>
>
> Signed-off-by: Rohan Chitradurga <rohan@ixiacom.com>
> Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
> ---
> net/ipv4/udp.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index d37baaa..3e3592d 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -225,6 +225,12 @@ int udp_lib_get_port(struct sock *sk, unsigned short snum,
> udp_lib_lport_inuse(net, snum, hslot, bitmap, sk,
> saddr_comp, udptable->log);
>
> + /* avoid searching when no ports are available */
> + if (bitmap_full(bitmap, PORTS_PER_CHAIN)) {
> + spin_unlock_bh(&hslot->lock);
> + break;
> + }
> +
> snum = first;
> /*
> * Iterate on all possible values of snum for this hash.
Really ? I wonder how you got your performance numbers then.
First, PORTS_PER_CHAIN is wrong here, since its value is the max
possible value (256 bits)
#define UDP_HTABLE_SIZE_MIN (CONFIG_BASE_SMALL ? 128 : 256)
#define MAX_UDP_PORTS 65536
#define PORTS_PER_CHAIN (MAX_UDP_PORTS / UDP_HTABLE_SIZE_MIN) -> 256
As soon as your machine (and most current machines have) has enough
memory, UDP hash table size is not 256, but 1024 or 2048
dmesg | grep "UDP hash"
[ 1.735203] UDP hash table entries: 2048 (order: 6, 327680 bytes)
So real bitmap size is 64 or 32 bits.
Your call to bitmap_full() always return false.
I dont like this patch. If you have special UDP needs on a small
machine, just add to kernel boot param "uhash_entries=8192", so that the
bitmap has 8 bits only.
^ permalink raw reply
* Re: module loading with CAP_NET_ADMIN
From: Vasiliy Kulikov @ 2011-02-25 12:30 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, linux-kernel, Kees Cook, Eugene Teo, Dan Rosenberg,
David S. Miller
In-Reply-To: <1298565265.2613.16.camel@bwh-desktop>
On Thu, Feb 24, 2011 at 16:34 +0000, Ben Hutchings wrote:
> On Thu, 2011-02-24 at 18:12 +0300, Vasiliy Kulikov wrote:
> > My proposal is changing request_module("%s", name) to something like
> > request_module("netdev-%s", name) inside of dev_load() and adding
> > aliases to related drivers.
>
> AFAIK these interface-name aliases are usually defined by distribution
> configuration files rather than within the modules themselves. And that
> behaviour is pretty much obsolete now that we have hotplug and udev.
>
> > This would allow to load only netdev
> > modules via these ioctls. I'm not sure what modules should be patches -
> > at least real physical netdevices have names different from drivers'
> > names, so they don't need patching. I suppose the list is not big.
>
> The only modules I can see that declare aliases like this are:
>
> net/ipv4/ip_gre.c:MODULE_ALIAS("gre0");
> net/ipv4/ipip.c:MODULE_ALIAS("tunl0");
> net/ipv6/sit.c:MODULE_ALIAS("sit0");
Thank you! These are not handled via udev or anything, it is usefull to
load it via "ifconfig sit0 up", so they do require patching.
I didn't find any modules requiring autoloading except these three.
Good candidate should be "isatap0" as it is seen in ip help, but there
is no such alias.
$ ip tunnel add help 2>&1 | grep mode
[ mode { ipip | gre | sit | isatap } ] [ remote ADDR ] [ local ADDR ]
I'll send the patch for request_module() and three drivers.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* [patch 0/1] [resend] s390: one more qeth patches for net-next
From: frank.blaschka @ 2011-02-25 12:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
Hi Dave,
I did not find this patch in net-next so far
shortlog:
Ursula Braun (1)
qeth: remove needless IPA-commands in offline
Thanks,
Frank
^ permalink raw reply
* [patch 1/1] [PATCH] qeth: remove needless IPA-commands in offline
From: frank.blaschka @ 2011-02-25 12:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Ursula Braun
In-Reply-To: <20110225123208.764828326@de.ibm.com>
[-- Attachment #1: 602-needless-ipa-commands.diff --]
[-- Type: text/plain, Size: 12373 bytes --]
From: Ursula Braun <ursula.braun@de.ibm.com>
If a qeth device is set offline, data and control subchannels are
cleared, which means removal of all IP Assist Primitive settings
implicitly. There is no need to delete those settings explicitly.
This patch removes all IP Assist invocations from offline.
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_core.h | 1
drivers/s390/net/qeth_core_main.c | 52 ++++++++++-------------------------
drivers/s390/net/qeth_l2_main.c | 45 +++++++++----------------------
drivers/s390/net/qeth_l3_main.c | 55 ++------------------------------------
4 files changed, 33 insertions(+), 120 deletions(-)
--- a/drivers/s390/net/qeth_core.h
+++ b/drivers/s390/net/qeth_core.h
@@ -741,7 +741,6 @@ struct qeth_card {
/* QDIO buffer handling */
struct qeth_qdio_info qdio;
struct qeth_perf_stats perf_stats;
- int use_hard_stop;
int read_or_write_problem;
struct qeth_osn_info osn_info;
struct qeth_discipline discipline;
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -302,12 +302,15 @@ static void qeth_issue_ipa_msg(struct qe
int com = cmd->hdr.command;
ipa_name = qeth_get_ipa_cmd_name(com);
if (rc)
- QETH_DBF_MESSAGE(2, "IPA: %s(x%X) for %s returned x%X \"%s\"\n",
- ipa_name, com, QETH_CARD_IFNAME(card),
- rc, qeth_get_ipa_msg(rc));
+ QETH_DBF_MESSAGE(2, "IPA: %s(x%X) for %s/%s returned "
+ "x%X \"%s\"\n",
+ ipa_name, com, dev_name(&card->gdev->dev),
+ QETH_CARD_IFNAME(card), rc,
+ qeth_get_ipa_msg(rc));
else
- QETH_DBF_MESSAGE(5, "IPA: %s(x%X) for %s succeeded\n",
- ipa_name, com, QETH_CARD_IFNAME(card));
+ QETH_DBF_MESSAGE(5, "IPA: %s(x%X) for %s/%s succeeded\n",
+ ipa_name, com, dev_name(&card->gdev->dev),
+ QETH_CARD_IFNAME(card));
}
static struct qeth_ipa_cmd *qeth_check_ipa_data(struct qeth_card *card,
@@ -1083,7 +1086,6 @@ static int qeth_setup_card(struct qeth_c
card->data.state = CH_STATE_DOWN;
card->state = CARD_STATE_DOWN;
card->lan_online = 0;
- card->use_hard_stop = 0;
card->read_or_write_problem = 0;
card->dev = NULL;
spin_lock_init(&card->vlanlock);
@@ -1732,20 +1734,22 @@ int qeth_send_control_data(struct qeth_c
};
}
+ if (reply->rc == -EIO)
+ goto error;
rc = reply->rc;
qeth_put_reply(reply);
return rc;
time_err:
+ reply->rc = -ETIME;
spin_lock_irqsave(&reply->card->lock, flags);
list_del_init(&reply->list);
spin_unlock_irqrestore(&reply->card->lock, flags);
- reply->rc = -ETIME;
atomic_inc(&reply->received);
+error:
atomic_set(&card->write.irq_pending, 0);
qeth_release_buffer(iob->channel, iob);
card->write.buf_no = (card->write.buf_no + 1) % QETH_CMD_BUFFER_NO;
- wake_up(&reply->wait_q);
rc = reply->rc;
qeth_put_reply(reply);
return rc;
@@ -2490,45 +2494,19 @@ int qeth_send_ipa_cmd(struct qeth_card *
}
EXPORT_SYMBOL_GPL(qeth_send_ipa_cmd);
-static int qeth_send_startstoplan(struct qeth_card *card,
- enum qeth_ipa_cmds ipacmd, enum qeth_prot_versions prot)
-{
- int rc;
- struct qeth_cmd_buffer *iob;
-
- iob = qeth_get_ipacmd_buffer(card, ipacmd, prot);
- rc = qeth_send_ipa_cmd(card, iob, NULL, NULL);
-
- return rc;
-}
-
int qeth_send_startlan(struct qeth_card *card)
{
int rc;
+ struct qeth_cmd_buffer *iob;
QETH_DBF_TEXT(SETUP, 2, "strtlan");
- rc = qeth_send_startstoplan(card, IPA_CMD_STARTLAN, 0);
+ iob = qeth_get_ipacmd_buffer(card, IPA_CMD_STARTLAN, 0);
+ rc = qeth_send_ipa_cmd(card, iob, NULL, NULL);
return rc;
}
EXPORT_SYMBOL_GPL(qeth_send_startlan);
-int qeth_send_stoplan(struct qeth_card *card)
-{
- int rc = 0;
-
- /*
- * TODO: according to the IPA format document page 14,
- * TCP/IP (we!) never issue a STOPLAN
- * is this right ?!?
- */
- QETH_DBF_TEXT(SETUP, 2, "stoplan");
-
- rc = qeth_send_startstoplan(card, IPA_CMD_STOPLAN, 0);
- return rc;
-}
-EXPORT_SYMBOL_GPL(qeth_send_stoplan);
-
int qeth_default_setadapterparms_cb(struct qeth_card *card,
struct qeth_reply *reply, unsigned long data)
{
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -202,17 +202,19 @@ static void qeth_l2_add_mc(struct qeth_c
kfree(mc);
}
-static void qeth_l2_del_all_mc(struct qeth_card *card)
+static void qeth_l2_del_all_mc(struct qeth_card *card, int del)
{
struct qeth_mc_mac *mc, *tmp;
spin_lock_bh(&card->mclock);
list_for_each_entry_safe(mc, tmp, &card->mc_list, list) {
- if (mc->is_vmac)
- qeth_l2_send_setdelmac(card, mc->mc_addr,
+ if (del) {
+ if (mc->is_vmac)
+ qeth_l2_send_setdelmac(card, mc->mc_addr,
IPA_CMD_DELVMAC, NULL);
- else
- qeth_l2_send_delgroupmac(card, mc->mc_addr);
+ else
+ qeth_l2_send_delgroupmac(card, mc->mc_addr);
+ }
list_del(&mc->list);
kfree(mc);
}
@@ -288,18 +290,13 @@ static int qeth_l2_send_setdelvlan(struc
qeth_l2_send_setdelvlan_cb, NULL);
}
-static void qeth_l2_process_vlans(struct qeth_card *card, int clear)
+static void qeth_l2_process_vlans(struct qeth_card *card)
{
struct qeth_vlan_vid *id;
QETH_CARD_TEXT(card, 3, "L2prcvln");
spin_lock_bh(&card->vlanlock);
list_for_each_entry(id, &card->vid_list, list) {
- if (clear)
- qeth_l2_send_setdelvlan(card, id->vid,
- IPA_CMD_DELVLAN);
- else
- qeth_l2_send_setdelvlan(card, id->vid,
- IPA_CMD_SETVLAN);
+ qeth_l2_send_setdelvlan(card, id->vid, IPA_CMD_SETVLAN);
}
spin_unlock_bh(&card->vlanlock);
}
@@ -379,19 +376,11 @@ static int qeth_l2_stop_card(struct qeth
dev_close(card->dev);
rtnl_unlock();
}
- if (!card->use_hard_stop ||
- recovery_mode) {
- __u8 *mac = &card->dev->dev_addr[0];
- rc = qeth_l2_send_delmac(card, mac);
- QETH_DBF_TEXT_(SETUP, 2, "Lerr%d", rc);
- }
+ card->info.mac_bits &= ~QETH_LAYER2_MAC_REGISTERED;
card->state = CARD_STATE_SOFTSETUP;
}
if (card->state == CARD_STATE_SOFTSETUP) {
- qeth_l2_process_vlans(card, 1);
- if (!card->use_hard_stop ||
- recovery_mode)
- qeth_l2_del_all_mc(card);
+ qeth_l2_del_all_mc(card, 0);
qeth_clear_ipacmd_list(card);
card->state = CARD_STATE_HARDSETUP;
}
@@ -405,7 +394,6 @@ static int qeth_l2_stop_card(struct qeth
qeth_clear_cmd_buffers(&card->read);
qeth_clear_cmd_buffers(&card->write);
}
- card->use_hard_stop = 0;
return rc;
}
@@ -705,7 +693,7 @@ static void qeth_l2_set_multicast_list(s
if (qeth_threads_running(card, QETH_RECOVER_THREAD) &&
(card->state != CARD_STATE_UP))
return;
- qeth_l2_del_all_mc(card);
+ qeth_l2_del_all_mc(card, 1);
spin_lock_bh(&card->mclock);
netdev_for_each_mc_addr(ha, dev)
qeth_l2_add_mc(card, ha->addr, 0);
@@ -907,10 +895,8 @@ static void qeth_l2_remove_device(struct
qeth_set_allowed_threads(card, 0, 1);
wait_event(card->wait_q, qeth_threads_running(card, 0xffffffff) == 0);
- if (cgdev->state == CCWGROUP_ONLINE) {
- card->use_hard_stop = 1;
+ if (cgdev->state == CCWGROUP_ONLINE)
qeth_l2_set_offline(cgdev);
- }
if (card->dev) {
unregister_netdev(card->dev);
@@ -1040,7 +1026,7 @@ contin:
if (card->info.type != QETH_CARD_TYPE_OSN &&
card->info.type != QETH_CARD_TYPE_OSM)
- qeth_l2_process_vlans(card, 0);
+ qeth_l2_process_vlans(card);
netif_tx_disable(card->dev);
@@ -1076,7 +1062,6 @@ contin:
return 0;
out_remove:
- card->use_hard_stop = 1;
qeth_l2_stop_card(card, 0);
ccw_device_set_offline(CARD_DDEV(card));
ccw_device_set_offline(CARD_WDEV(card));
@@ -1144,7 +1129,6 @@ static int qeth_l2_recover(void *ptr)
QETH_CARD_TEXT(card, 2, "recover2");
dev_warn(&card->gdev->dev,
"A recovery process has been started for the device\n");
- card->use_hard_stop = 1;
__qeth_l2_set_offline(card->gdev, 1);
rc = __qeth_l2_set_online(card->gdev, 1);
if (!rc)
@@ -1191,7 +1175,6 @@ static int qeth_l2_pm_suspend(struct ccw
if (gdev->state == CCWGROUP_OFFLINE)
return 0;
if (card->state == CARD_STATE_UP) {
- card->use_hard_stop = 1;
__qeth_l2_set_offline(card->gdev, 1);
} else
__qeth_l2_set_offline(card->gdev, 0);
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -510,8 +510,7 @@ static void qeth_l3_set_ip_addr_list(str
kfree(tbd_list);
}
-static void qeth_l3_clear_ip_list(struct qeth_card *card, int clean,
- int recover)
+static void qeth_l3_clear_ip_list(struct qeth_card *card, int recover)
{
struct qeth_ipaddr *addr, *tmp;
unsigned long flags;
@@ -530,11 +529,6 @@ static void qeth_l3_clear_ip_list(struct
addr = list_entry(card->ip_list.next,
struct qeth_ipaddr, entry);
list_del_init(&addr->entry);
- if (clean) {
- spin_unlock_irqrestore(&card->ip_lock, flags);
- qeth_l3_deregister_addr_entry(card, addr);
- spin_lock_irqsave(&card->ip_lock, flags);
- }
if (!recover || addr->is_multicast) {
kfree(addr);
continue;
@@ -1611,29 +1605,6 @@ static int qeth_l3_start_ipassists(struc
return 0;
}
-static int qeth_l3_put_unique_id(struct qeth_card *card)
-{
-
- int rc = 0;
- struct qeth_cmd_buffer *iob;
- struct qeth_ipa_cmd *cmd;
-
- QETH_CARD_TEXT(card, 2, "puniqeid");
-
- if ((card->info.unique_id & UNIQUE_ID_NOT_BY_CARD) ==
- UNIQUE_ID_NOT_BY_CARD)
- return -1;
- iob = qeth_get_ipacmd_buffer(card, IPA_CMD_DESTROY_ADDR,
- QETH_PROT_IPV6);
- cmd = (struct qeth_ipa_cmd *)(iob->data+IPA_PDU_HEADER_SIZE);
- *((__u16 *) &cmd->data.create_destroy_addr.unique_id[6]) =
- card->info.unique_id;
- memcpy(&cmd->data.create_destroy_addr.unique_id[0],
- card->dev->dev_addr, OSA_ADDR_LEN);
- rc = qeth_send_ipa_cmd(card, iob, NULL, NULL);
- return rc;
-}
-
static int qeth_l3_iqd_read_initial_mac_cb(struct qeth_card *card,
struct qeth_reply *reply, unsigned long data)
{
@@ -2324,25 +2295,14 @@ static int qeth_l3_stop_card(struct qeth
dev_close(card->dev);
rtnl_unlock();
}
- if (!card->use_hard_stop) {
- rc = qeth_send_stoplan(card);
- if (rc)
- QETH_DBF_TEXT_(SETUP, 2, "1err%d", rc);
- }
card->state = CARD_STATE_SOFTSETUP;
}
if (card->state == CARD_STATE_SOFTSETUP) {
- qeth_l3_clear_ip_list(card, !card->use_hard_stop, 1);
+ qeth_l3_clear_ip_list(card, 1);
qeth_clear_ipacmd_list(card);
card->state = CARD_STATE_HARDSETUP;
}
if (card->state == CARD_STATE_HARDSETUP) {
- if (!card->use_hard_stop &&
- (card->info.type != QETH_CARD_TYPE_IQD)) {
- rc = qeth_l3_put_unique_id(card);
- if (rc)
- QETH_DBF_TEXT_(SETUP, 2, "2err%d", rc);
- }
qeth_qdio_clear_card(card, 0);
qeth_clear_qdio_buffers(card);
qeth_clear_working_pool_list(card);
@@ -2352,7 +2312,6 @@ static int qeth_l3_stop_card(struct qeth
qeth_clear_cmd_buffers(&card->read);
qeth_clear_cmd_buffers(&card->write);
}
- card->use_hard_stop = 0;
return rc;
}
@@ -3483,17 +3442,15 @@ static void qeth_l3_remove_device(struct
qeth_set_allowed_threads(card, 0, 1);
wait_event(card->wait_q, qeth_threads_running(card, 0xffffffff) == 0);
- if (cgdev->state == CCWGROUP_ONLINE) {
- card->use_hard_stop = 1;
+ if (cgdev->state == CCWGROUP_ONLINE)
qeth_l3_set_offline(cgdev);
- }
if (card->dev) {
unregister_netdev(card->dev);
card->dev = NULL;
}
- qeth_l3_clear_ip_list(card, 0, 0);
+ qeth_l3_clear_ip_list(card, 0);
qeth_l3_clear_ipato_list(card);
return;
}
@@ -3594,7 +3551,6 @@ contin:
mutex_unlock(&card->discipline_mutex);
return 0;
out_remove:
- card->use_hard_stop = 1;
qeth_l3_stop_card(card, 0);
ccw_device_set_offline(CARD_DDEV(card));
ccw_device_set_offline(CARD_WDEV(card));
@@ -3663,7 +3619,6 @@ static int qeth_l3_recover(void *ptr)
QETH_CARD_TEXT(card, 2, "recover2");
dev_warn(&card->gdev->dev,
"A recovery process has been started for the device\n");
- card->use_hard_stop = 1;
__qeth_l3_set_offline(card->gdev, 1);
rc = __qeth_l3_set_online(card->gdev, 1);
if (!rc)
@@ -3684,7 +3639,6 @@ static int qeth_l3_recover(void *ptr)
static void qeth_l3_shutdown(struct ccwgroup_device *gdev)
{
struct qeth_card *card = dev_get_drvdata(&gdev->dev);
- qeth_l3_clear_ip_list(card, 0, 0);
qeth_qdio_clear_card(card, 0);
qeth_clear_qdio_buffers(card);
}
@@ -3700,7 +3654,6 @@ static int qeth_l3_pm_suspend(struct ccw
if (gdev->state == CCWGROUP_OFFLINE)
return 0;
if (card->state == CARD_STATE_UP) {
- card->use_hard_stop = 1;
__qeth_l3_set_offline(card->gdev, 1);
} else
__qeth_l3_set_offline(card->gdev, 0);
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Thomas Graf @ 2011-02-25 12:56 UTC (permalink / raw)
To: Tom Herbert, Bill Sommerfeld; +Cc: Daniel Baluta, netdev
In-Reply-To: <AANLkTi=j9VdTZjw4iTsczv2eHjTXo59-fNneBMo8rJyp@mail.gmail.com>
On Thu, Jan 27, 2011 at 01:32:25PM -0800, Tom Herbert wrote:
> Yes, we are still planning this. The UDP implementation for my
> earlier patch should be usable to try for DNS/UDP-- this is in fact
> where we saw a major performance gain. Eric Dumazet had some nice
> improvements that should probably be looked at also.
I can confirm this.
Serious scalability issues have been reported on a 12 core system
running bind 9.7-2. The system was only able to deliver ~110K queries
per second.
Using your SO_REUSEPORT patch and a modified bind using it. The same
system is able to deliver ~650K queries per seconds while maxing out
all cores completely.
Tom, Bill: do you have a timeline for merging this? Especially the
UDP bits?
-Thomas
^ permalink raw reply
* Re: [PATCH] davinci: da850/omap-l138: Add Carrier Link OK check in Davinci RX Handler
From: Cyril Chemparathy @ 2011-02-25 13:16 UTC (permalink / raw)
To: Hegde, Vinay
Cc: netdev@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1298627788-32339-1-git-send-email-vinay.hegde@ti.com>
On 02/25/2011 04:56 AM, Hegde, Vinay wrote:
> This patch adds an additional check in the Davinci EMAC RX Handler,
> which tests the __LINK_STATE_NOCARRIER flag along with the
> __LINK_STATE_START flag as part EMAC shutting down procedure.
>
> This avoids
> WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf8/0x120()
> during rtcwake used to suspend the target for a specified duration.
>
> Signed-off-by: Hegde, Vinay <vinay.hegde@ti.com>
> ---
> drivers/net/davinci_emac.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 2a628d1..7018bfe 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -1008,7 +1008,7 @@ static void emac_rx_handler(void *token, int len, int status)
> int ret;
>
> /* free and bail if we are shutting down */
> - if (unlikely(!netif_running(ndev))) {
> + if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
> dev_kfree_skb_any(skb);
> return;
> }
Looks ok.
Acked-by: Cyril Chemparathy <cyril@ti.com>
^ permalink raw reply
* Re: Mass udp flow reboot linux with RealTek RTL-8169 Gigabit
From: Hans Nieser @ 2011-02-25 13:45 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, linux-kernel
In-Reply-To: <1298485893.31256.40.camel@krikkit>
On Wed, 2011-02-23 at 19:31 +0100, Hans Nieser wrote:
> On Wed, 2011-02-23 at 13:21 +0100, Hans Nieser wrote:
> > On Wed, 2011-02-23 at 10:55 +0100, Francois Romieu wrote:
> > You may enable PCIEASPM_DEBUG, force 'pcie_aspm=off' and switch from
> > SLUB to SLAB but it's a bit cargo-cultish.
This seemed to have no effect sadly
> Ok, I just tried 2.6.34, and after over 5 hours of running my script,
> the system is still up and running, with only 24 'link up' messages on
> dmesg, and having transferred 2.1TiB of data (1428042421 rx_packets, 45
> rx_missed). So I'm going to assume the problem isn't present with this
> kernel and try a bisect between it and 2.6.35
After spending the entire day yesterday and this morning bisecting this,
I haven't gotten anywhere :/ I ended up at an unrelated commit as being
the first known bad commit (84d4db0e22965334ae8272f324d31fb4657465aa), I
think I may have marked a bad commit as good.. To properly bisect this
issue I probably need to test each commit for a several hours across
multiple reboots, but that is going to be too much time. I've at least
been able to establish that following v2.6.34, the following commits are
bad:
c222fb2efaf1a421f5bf74403df40a9384ccf516
4a973f2495fba8775d1c408b3ee7f2c19b19f13f
84d4db0e22965334ae8272f324d31fb4657465aa
After that I've been trying other various things (on 2.6.38-rc6+) and
made some interesting and confusing discoveries;
- Setting pci=nomsi causes instant reboot when I start my test script
- Enabling only one CPU core in the BIOS seems to solve the whole lock
up problem, I have not been able to reproduce it after a few hours of
testing (nor on 2.6.35). (Normally on 2.6.38-rc6 it would crash in
just a few seconds.)
Additionally, when I force wget to use IPv4 with only one core
enabled, I'm suddenly getting a solid 112MB/s instead of the lousy
9-12MB/s I have been getting since 2.6.36 - but only when using one
core. With all 4 cores enabled, performance is bad again even when
forcing wget to use IPv4..
Using only one CPU core also reduces the 'link up' messages a lot, I
only got a couple instead of hundreds/thousands.
- Enabling Tickless System (NO_HZ) kernel option seems to make lock up
occur less frequently (but it still happens), also much less 'link up'
messages, but also causes an occasional "NOHZ: local_softirq_pending
08" to appear on dmesg.
- Enabling HyperThreading (I disable it by default due to an issue with
VirtualBox) in BIOS causes performance to get even worse, just 2-3MB/s
instead of 9-12MB/s
I've also attempted to bisect the issue I have been having with slow
transfer speed (I don't know if its related to the hang, but I figure if
the hang ever gets fixed, this will have to be fixed as well to make
r8169 usable for me), which started somewhere between v2.6.35 (good) and
v2.6.36 (bad), unfortunately this too ended up at a seemingly unrelated
commit:
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 - clockevents: Remove the per
cpu tick skew
Just for kicks I attempted to revert this change on 2.6.38-rc6+, which
seemed to reduce the frequency of 'link up' messages, but no other real
change noticed.
^ permalink raw reply
* RE: [Bugme-new] [Bug 29712] New: Bonding Driver(version : 3.5.0) - Problem with ARP monitoring in active backup mode
From: Harsha R02 @ 2011-02-25 12:44 UTC (permalink / raw)
To: Brian Haley, Andrew Morton
Cc: bugzilla-daemon, bugme-daemon, netdev, Jay Vosburgh
In-Reply-To: <4D672525.5080609@hp.com>
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
Attached patch resolves the issue. Failover happened back to primary
when it was up again in both the point to point and switch
configuration.
Please let us know if this change can be included.
Thanks,
- Harsha
-----Original Message-----
From: Brian Haley [mailto:brian.haley@hp.com]
Sent: Friday, February 25, 2011 9:12 AM
To: Andrew Morton
Cc: Harsha R02; bugzilla-daemon@bugzilla.kernel.org;
bugme-daemon@bugzilla.kernel.org; netdev@vger.kernel.org; Jay Vosburgh
Subject: Re: [Bugme-new] [Bug 29712] New: Bonding Driver(version :
3.5.0) - Problem with ARP monitoring in active backup mode
On 02/24/2011 05:51 PM, Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via
the
> bugzilla web interface).
>
> On Wed, 23 Feb 2011 10:41:34 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=29712
>>
>> Summary: Bonding Driver(version : 3.5.0) - Problem with
ARP
>> monitoring in active backup mode
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 2.6.32
>
> That's a paleolithic kernel you have there. This problem might have
> been fixed already. Can you test a more recent kernel?
I can add some more info since I originally looked at the problem. This
happens on 2.6.38 as well, and on this 2.6.32 kernel with a backported
3.7.0 bonding driver (with the primary_reselect option). Harsha has a
prototype patch that's being tested, but wanted to log the bug to see
if one of the bonding maintainers had a better solution.
I'll let him respond as I'm now out of the loop...
Thanks,
-Brian
Information transmitted by this e-mail is proprietary to MphasiS, its associated companies and/ or its customers and is intended
for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded
to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly
prohibited. In such cases, please notify us immediately at mailmaster@mphasis.com and delete this mail from your records.
[-- Attachment #2: bonding.patch --]
[-- Type: application/octet-stream, Size: 841 bytes --]
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 40fb5ee..0413917 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3020,11 +3020,16 @@ static void bond_ab_arp_probe(struct bonding *bond)
bond->curr_active_slave->dev->name);
if (bond->curr_active_slave) {
+ if((bond->curr_active_slave != bond->primary_slave) &&
+ (IS_UP(bond->primary_slave->dev)))
+ goto failover;
+
bond_arp_send_all(bond, bond->curr_active_slave);
read_unlock(&bond->curr_slave_lock);
return;
}
+failover:
read_unlock(&bond->curr_slave_lock);
/* if we don't have a curr_active_slave, search for the next available
^ permalink raw reply related
* [PATCH] don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Vasiliy Kulikov @ 2011-02-25 15:14 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet,
Tom Herbert, Changli Gao, Jesse Gross
In-Reply-To: <20110225123023.GA8776@albatros>
Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with
CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean
that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are limited
to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't allow
anybody load any module not related to networking.
This patch restricts an ability of autoloading modules to netdev modules
with explicit aliases. Currently there are only three users of the
feature: ipip, ip_gre and sit.
Before the patch:
root@albatros:~# grep Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: fffffffc00001000
CapEff: fffffffc00001000
CapBnd: fffffffc00001000
root@albatros:~# lsmod | grep xfs
root@albatros:~# ifconfig xfs
xfs: error fetching interface information: Device not found
root@albatros:~# lsmod | grep xfs
xfs 767011 0
exportfs 4226 2 xfs,nfsd
After:
root@albatros:~# grep Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
root@albatros:~# lsmod | grep scsi_wait_scan
root@albatros:~# ifconfig scsi_wait_scan
scsi_wait_scan: error fetching interface information: Device not found
root@albatros:~# lsmod | grep scsi_wait_scan
root@albatros:~# modprobe scsi_wait_scan
root@albatros:~# lsmod | grep scsi_wait_scan
scsi_wait_scan 829 0
Reference: http://www.openwall.com/lists/oss-security/2011/02/24/17
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 2 +-
net/ipv4/ip_gre.c | 2 +-
net/ipv4/ipip.c | 2 +-
net/ipv6/sit.c | 2 +-
5 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d971346..71caf7a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2392,6 +2392,9 @@ extern int netdev_notice(const struct net_device *dev, const char *format, ...)
extern int netdev_info(const struct net_device *dev, const char *format, ...)
__attribute__ ((format (printf, 2, 3)));
+#define MODULE_ALIAS_NETDEV(device) \
+ MODULE_ALIAS("netdev-" device)
+
#if defined(DEBUG)
#define netdev_dbg(__dev, format, args...) \
netdev_printk(KERN_DEBUG, __dev, format, ##args)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8ae6631..79b33d9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1120,7 +1120,7 @@ void dev_load(struct net *net, const char *name)
rcu_read_unlock();
if (!dev && capable(CAP_NET_ADMIN))
- request_module("%s", name);
+ request_module("netdev-%s", name);
}
EXPORT_SYMBOL(dev_load);
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 6613edf..d1d0e2c 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
MODULE_LICENSE("GPL");
MODULE_ALIAS_RTNL_LINK("gre");
MODULE_ALIAS_RTNL_LINK("gretap");
-MODULE_ALIAS("gre0");
+MODULE_ALIAS_NETDEV("gre0");
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 988f52f..a5f58e7 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -913,4 +913,4 @@ static void __exit ipip_fini(void)
module_init(ipip_init);
module_exit(ipip_fini);
MODULE_LICENSE("GPL");
-MODULE_ALIAS("tunl0");
+MODULE_ALIAS_NETDEV("tunl0");
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 8ce38f1..d2c16e1 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1290,4 +1290,4 @@ static int __init sit_init(void)
module_init(sit_init);
module_exit(sit_cleanup);
MODULE_LICENSE("GPL");
-MODULE_ALIAS("sit0");
+MODULE_ALIAS_NETDEV("sit0");
--
1.7.0.4
^ permalink raw reply related
* Re: module loading with CAP_NET_ADMIN
From: Michael Tokarev @ 2011-02-25 15:29 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: Ben Hutchings, netdev, linux-kernel, Kees Cook, Eugene Teo,
Dan Rosenberg, David S. Miller
In-Reply-To: <20110225123023.GA8776@albatros>
25.02.2011 15:30, Vasiliy Kulikov wrote:
> On Thu, Feb 24, 2011 at 16:34 +0000, Ben Hutchings wrote:
>> On Thu, 2011-02-24 at 18:12 +0300, Vasiliy Kulikov wrote:
>>> My proposal is changing request_module("%s", name) to something like
>>> request_module("netdev-%s", name) inside of dev_load() and adding
>>> aliases to related drivers.
It is not the kernel patching which we should worry about, kernel
part is trivial.
What is not trivial is to patch all the systems out there who
autoloads network drivers based on /etc/modprobe.d/network-aliases.conf
(some local file), ie, numerous working setups which already
uses this mechanism since stone age. And patching these is
not trivial at all, unfortunately.
Somewhat weird setups (one can load the modules explicitly, and
nowadays this all is handled by udev anyway), but this change
will break some working systems.
Maybe the cost (some pain for some users) isn't large enough
but the outcome is good, and I think it _is_ good, but it needs
some wider discussion first, imho.
I can't think of a way to handle this without breaking stuff.
Thanks!
/mjt
^ permalink raw reply
* Re: [PATCH] sysctl: ipv6: use correct net in ipv6_sysctl_rtcache_flush
From: Daniel Lezcano @ 2011-02-25 15:30 UTC (permalink / raw)
To: Lucian Adrian Grijincu; +Cc: netdev, David S . Miller, Benjamin Thery
In-Reply-To: <1298612883-18762-1-git-send-email-lucian.grijincu@gmail.com>
On 02/25/2011 06:48 AM, Lucian Adrian Grijincu wrote:
> Before this patch issuing these commands:
>
> fd = open("/proc/sys/net/ipv6/route/flush")
> unshare(CLONE_NEWNET)
> write(fd, "stuff")
>
> would flush the newly created net, not the original one.
>
> The equivalent ipv4 code is correct (stores the net inside ->extra1).
> ---
Acked-by: Daniel Lezcano <daniel.lezcano@free.fr>
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH v2] xen network backend driver
From: Ian Campbell @ 2011-02-25 15:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ben Hutchings, netdev@vger.kernel.org, Jeremy Fitzhardinge,
xen-devel, Herbert Xu
In-Reply-To: <1298553792.5034.391.camel@zakaz.uk.xensource.com>
On Thu, 2011-02-24 at 13:23 +0000, Ian Campbell wrote:
>
> > > +
> > > + if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op,
> 1))
> > > + BUG();
> >
> > How about something less severe? Say return the error code?
>
> Yes, I folded this into the following check of op.status.
I revisited this and HYPERVISOR_grant_table_op has multicall like
semantics and a failure of the hypercall itself is a serious bug in the
calling kernel, akin to a page fault on kernel memory or similar so I
think a BUG() is the appropriate response.
Failures of the type which a guest may cause are the GNTST_* error codes
found in the op.status field an are handled appropriately gracefully.
Ian.
^ permalink raw reply
* [PATCH 1/7] net: handle addr_type of 0 properly
From: Hagen Paul Pfeifer @ 2011-02-25 15:45 UTC (permalink / raw)
To: netdev; +Cc: fw
addr_type of 0 means that the type should be adopted from from_dev and
not from __hw_addr_del_multiple(). Unfortunately it isn't so and
addr_type will always be considered. Fix this by implementing the
considered and documented behavior.
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
net/core/dev_addr_lists.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index 508f9c1..133fd22 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -144,7 +144,7 @@ void __hw_addr_del_multiple(struct netdev_hw_addr_list *to_list,
list_for_each_entry(ha, &from_list->list, list) {
type = addr_type ? addr_type : ha->type;
- __hw_addr_del(to_list, ha->addr, addr_len, addr_type);
+ __hw_addr_del(to_list, ha->addr, addr_len, type);
}
}
EXPORT_SYMBOL(__hw_addr_del_multiple);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 5/7] ipv6: variable next is never used in this function
From: Hagen Paul Pfeifer @ 2011-02-25 15:45 UTC (permalink / raw)
To: netdev; +Cc: fw
In-Reply-To: <1298648721-3026-1-git-send-email-hagen@jauu.net>
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
net/ipv6/route.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f786aed..7e9443f 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1075,11 +1075,9 @@ out:
int icmp6_dst_gc(void)
{
- struct dst_entry *dst, *next, **pprev;
+ struct dst_entry *dst, **pprev;
int more = 0;
- next = NULL;
-
spin_lock_bh(&icmp6_dst_lock);
pprev = &icmp6_dst_gc_list;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/7] dccp: newdp is declared/assigned but never be used
From: Hagen Paul Pfeifer @ 2011-02-25 15:45 UTC (permalink / raw)
To: netdev; +Cc: fw
In-Reply-To: <1298648721-3026-1-git-send-email-hagen@jauu.net>
Declaration and assignment of newdp is removed. Usage of dccp_sk()
exhibit no side effects.
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
net/dccp/ipv6.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index dca711d..460d545 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -484,7 +484,6 @@ static struct sock *dccp_v6_request_recv_sock(struct sock *sk,
struct inet6_request_sock *ireq6 = inet6_rsk(req);
struct ipv6_pinfo *newnp, *np = inet6_sk(sk);
struct inet_sock *newinet;
- struct dccp_sock *newdp;
struct dccp6_sock *newdp6;
struct sock *newsk;
struct ipv6_txoptions *opt;
@@ -498,7 +497,6 @@ static struct sock *dccp_v6_request_recv_sock(struct sock *sk,
return NULL;
newdp6 = (struct dccp6_sock *)newsk;
- newdp = dccp_sk(newsk);
newinet = inet_sk(newsk);
newinet->pinet6 = &newdp6->inet6;
newnp = inet6_sk(newsk);
@@ -578,7 +576,6 @@ static struct sock *dccp_v6_request_recv_sock(struct sock *sk,
newdp6 = (struct dccp6_sock *)newsk;
newinet = inet_sk(newsk);
newinet->pinet6 = &newdp6->inet6;
- newdp = dccp_sk(newsk);
newnp = inet6_sk(newsk);
memcpy(newnp, np, sizeof(struct ipv6_pinfo));
--
1.7.2.3
^ permalink raw reply related
* [PATCH 6/7] ipv6: ignore rtnl_unicast() return code
From: Hagen Paul Pfeifer @ 2011-02-25 15:45 UTC (permalink / raw)
To: netdev; +Cc: fw
In-Reply-To: <1298648721-3026-1-git-send-email-hagen@jauu.net>
rtnl_unicast() return value is not of interest, we can silently ignore
it, save some instructions and four byte on the stack.
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
net/ipv6/ip6mr.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 0e1d53b..618f67cc 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1039,7 +1039,6 @@ static void ip6mr_cache_resolve(struct net *net, struct mr6_table *mrt,
while((skb = __skb_dequeue(&uc->mfc_un.unres.unresolved))) {
if (ipv6_hdr(skb)->version == 0) {
- int err;
struct nlmsghdr *nlh = (struct nlmsghdr *)skb_pull(skb, sizeof(struct ipv6hdr));
if (__ip6mr_fill_mroute(mrt, skb, c, NLMSG_DATA(nlh)) > 0) {
@@ -1050,7 +1049,7 @@ static void ip6mr_cache_resolve(struct net *net, struct mr6_table *mrt,
skb_trim(skb, nlh->nlmsg_len);
((struct nlmsgerr *)NLMSG_DATA(nlh))->error = -EMSGSIZE;
}
- err = rtnl_unicast(skb, net, NETLINK_CB(skb).pid);
+ rtnl_unicast(skb, net, NETLINK_CB(skb).pid);
} else
ip6_mr_forward(net, mrt, skb, c);
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/7] ipv6: totlen is declared and assigned but not used
From: Hagen Paul Pfeifer @ 2011-02-25 15:45 UTC (permalink / raw)
To: netdev; +Cc: fw
In-Reply-To: <1298648721-3026-1-git-send-email-hagen@jauu.net>
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
net/ipv6/ip6_output.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 2600e22..25a2647 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -274,13 +274,10 @@ int ip6_nd_hdr(struct sock *sk, struct sk_buff *skb, struct net_device *dev,
{
struct ipv6_pinfo *np = inet6_sk(sk);
struct ipv6hdr *hdr;
- int totlen;
skb->protocol = htons(ETH_P_IPV6);
skb->dev = dev;
- totlen = len + sizeof(struct ipv6hdr);
-
skb_reset_network_header(skb);
skb_put(skb, sizeof(struct ipv6hdr));
hdr = ipv6_hdr(skb);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 7/7] sched: protocol only needed when CONFIG_NET_CLS_ACT is enabled
From: Hagen Paul Pfeifer @ 2011-02-25 15:45 UTC (permalink / raw)
To: netdev; +Cc: fw
In-Reply-To: <1298648721-3026-1-git-send-email-hagen@jauu.net>
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
net/sched/sch_api.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 1507415..7490f3f 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1672,12 +1672,12 @@ int tc_classify(struct sk_buff *skb, struct tcf_proto *tp,
struct tcf_result *res)
{
int err = 0;
- __be16 protocol;
#ifdef CONFIG_NET_CLS_ACT
+ __be16 protocol;
struct tcf_proto *otp = tp;
reclassify:
-#endif
protocol = skb->protocol;
+#endif
err = tc_classify_compat(skb, tp, res);
#ifdef CONFIG_NET_CLS_ACT
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/7] ipv6: hash is calculated but not used afterwards
From: Hagen Paul Pfeifer @ 2011-02-25 15:45 UTC (permalink / raw)
To: netdev; +Cc: fw
In-Reply-To: <1298648721-3026-1-git-send-email-hagen@jauu.net>
hash is declared and assigned but not used anymore. ipv6_addr_hash()
exhibit no side-effects.
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
net/ipv6/addrconf.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index fd6782e..3daaf3c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -718,12 +718,9 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
struct inet6_ifaddr *ifa, *ifn;
struct inet6_dev *idev = ifp->idev;
int state;
- int hash;
int deleted = 0, onlink = 0;
unsigned long expires = jiffies;
- hash = ipv6_addr_hash(&ifp->addr);
-
spin_lock_bh(&ifp->state_lock);
state = ifp->state;
ifp->state = INET6_IFADDR_STATE_DEAD;
--
1.7.2.3
^ permalink raw reply related
* Re: module loading with CAP_NET_ADMIN
From: Vasiliy Kulikov @ 2011-02-25 15:57 UTC (permalink / raw)
To: Michael Tokarev
Cc: Ben Hutchings, netdev, linux-kernel, Kees Cook, Eugene Teo,
Dan Rosenberg, David S. Miller
In-Reply-To: <4D67CAD7.7060408@msgid.tls.msk.ru>
On Fri, Feb 25, 2011 at 18:29 +0300, Michael Tokarev wrote:
> 25.02.2011 15:30, Vasiliy Kulikov wrote:
> > On Thu, Feb 24, 2011 at 16:34 +0000, Ben Hutchings wrote:
> >> On Thu, 2011-02-24 at 18:12 +0300, Vasiliy Kulikov wrote:
> >>> My proposal is changing request_module("%s", name) to something like
> >>> request_module("netdev-%s", name) inside of dev_load() and adding
> >>> aliases to related drivers.
>
> It is not the kernel patching which we should worry about, kernel
> part is trivial.
>
> What is not trivial is to patch all the systems out there who
> autoloads network drivers based on /etc/modprobe.d/network-aliases.conf
> (some local file), ie, numerous working setups which already
> uses this mechanism since stone age. And patching these is
> not trivial at all, unfortunately.
>
> Somewhat weird setups (one can load the modules explicitly, and
> nowadays this all is handled by udev anyway), but this change
> will break some working systems.
>
> Maybe the cost (some pain for some users) isn't large enough
> but the outcome is good, and I think it _is_ good, but it needs
> some wider discussion first, imho.
>
> I can't think of a way to handle this without breaking stuff.
Currently Linux slowly moves in the direction of rootless systems. This
definitely need proper restrictions of CAP_* power. Network admin does
nothing with general modules. It _has_ to break something one day
because old assumptions about permission stuff don't conform CAP_*
things: old assumptions are very closely connected with just everything.
I'm not sure how this particular CAP_NET_ADMIN misuse should be fixed,
maybe distributions should supply script to upgrade modprobe configs.
Also note that change s/CAP_SYS_MODULE/CAP_NET_ADMIN/ was made in
2.6.32, so there is a possibility that the set of affected distributions
(that doesn't use udev stuff) is very small.
Thanks for your input,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ 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