* Re: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: Ben Hutchings @ 2011-04-06 20:20 UTC (permalink / raw)
To: David Miller; +Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <20110406.125637.70201394.davem@davemloft.net>
On Wed, 2011-04-06 at 12:56 -0700, David Miller wrote:
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Date: Fri, 1 Apr 2011 21:58:03 -0700
>
> > o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> > but it is tigtly coupled with RX flow hash configuration.
> > o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> > soon.
> > o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
> > dropping the affinity control from it.
> >
> > Ben Hutching:
> > o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> > queues so that most channels combine RX and TX work.
> > o Please could you use a kernel-doc comment to describe the structure.
> >
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> Ben, are you currently OK with this patch?
>
> There was some back and forth, and I just want to make sure all of the
> issues you raised were addressed to your satisfaction.
I'm afraid not.
On Fri, 2011-04-01 at 21:58 -0700, Amit Kumar Salecha wrote:
o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> but it is tigtly coupled with RX flow hash configuration.
> o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> soon.
> o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
> dropping the affinity control from it.
>
> Ben Hutching:
> o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> queues so that most channels combine RX and TX work.
> o Please could you use a kernel-doc comment to describe the structure.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Amit, I told you already that you must not use my Signed-off-by line
since you are changing the patch significantly.
> ---
> include/linux/ethtool.h | 41 +++++++++++++++++++++++++++++++++++++++++
> net/core/ethtool.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 82 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c8fcbdd..3c4d968 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -229,6 +229,42 @@ struct ethtool_ringparam {
> __u32 tx_pending;
> };
>
> +/**
> + * struct ethtool_channels - configuring number of network channel
> + * @cmd: ETHTOOL_{G,S}CHANNELS
> + * @type: Channel type defined in ethtool_channel_type
> + * @max_XX: Read only. Maximum number of channel the driver support
> + * @XX_count: Valid values are in the range 1 to the "max_XX" counterpart above.
The kernel-doc tools are going to complain about these field names with
'XX' in them. You'll have to describe each field individually.
> + * This can be used to configure RX,TX and other channels.
> + */
> +
> +struct ethtool_channels {
> + __u32 cmd;
> + __u32 type;
> + __u32 max_rx;
> + __u32 max_tx;
> + __u32 max_other;
> + __u32 rx_count;
> + __u32 tx_count;
> + __u32 other_count;
> +};
> +
> +/* Channel type */
> +/* Channel type should be pass in type field of ethtool_channels.
> + * TYPE_ALL indicates set all channels to XX_count values.
> + * TYPE_RX and TYPE_TX is to get and set RX and TX channels correspondingly.
> + * TYPE_COMBINED is to set both RX and TX channels to rx_count and tx_count
> + * correspondingly.
That's not what I meant by 'combined'. I meant a set of RX queues and
TX queues (usually 1 of each) with an IRQ and maybe an event queue
shared between them. It should be possible for ethtool to distinguish
combined channels, so it doesn't just report 'Invalid argument' if the
user tries to set rx_count != tx_count.
I think this requires that there are max_combined and combined_count (or
similar) fields in struct ethtool_channels, so a driver that only
supports combined channels can report max_rx = 0, max_tx = 0,
max_combined = N.
> TYPE_OTHER is to configure other channel.
> + */
> +enum ethtool_channel_type {
> + ETH_CHAN_TYPE_ALL = 0,
> + ETH_CHAN_TYPE_RX,
> + ETH_CHAN_TYPE_TX,
> + ETH_CHAN_TYPE_COMBINED,
> + ETH_CHAN_TYPE_OTHER,
> +};
[...]
Really I'm not sure whether there's a need to be able to specify which
channel counts are being changed. ethtool or whatever utility is used
can do ETHTOOL_GCHANNELS, modify channel counts, ETHTOOL_SCHANNELS and
all the counts the user didn't want to change will be unchanged. If you
still think it is useful then use flags for the different channel types
so there is no arbitrary restriction on which counts can be changed at
the same time.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: David Miller @ 2011-04-06 20:28 UTC (permalink / raw)
To: hirofumi; +Cc: netdev
In-Reply-To: <87oc4kj1bt.fsf@devron.myhome.or.jp>
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: Tue, 05 Apr 2011 22:05:10 +0900
> ipv4: Set rt->rt_iif more sanely on output routes.
> (1018b5c01636c7c6bda31a719bda34fc631db29a)
>
> The above patch seems to be caused of avahi breakage.
>
> I'm not debugging fully though, avahi is using IP_PKTINFO and checking
> in_pktinfo->ipi_ifindex > 0.
>
> And if I reverted above patch, it seems to fix avahi's IP_PKTINFO problem.
in_pktinfo is given to the application only during recvmsg() calls, the
call chain is (for example):
udp_recvmsg()
--> ip_cmsg_recv()
--> ip_cmsg_recv_pktinfo()
Therefore we will only be working with receive packets, whose routes are
computed using ip_route_input*() which will fill in the rt_iif field
appropriately.
The only exception to this would be packets which are looped back, in
which case the cached output route attached to the packet will be used.
Your RFC patch should work, but we're trying to make "struct rtable"
smaller rather than larger.
In what way does routing break if you simply restore the original
rt_iif assignment in output route creation? That's the most preferred
fix for this.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: David Miller @ 2011-04-06 20:29 UTC (permalink / raw)
To: eric.dumazet
Cc: acme, jesse.brandeburg, fedora-kernel-list, netdev,
jesse.brandeburg
In-Reply-To: <1302121136.2701.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Apr 2011 22:18:56 +0200
> I remember last time I work on a fedora kernel, it had conntrack enabled
>
> And yes, conntrack can really slowdown a router, because of default
> parameters.
Yes, if conntrack is enabled performance will indeed tank.
^ permalink raw reply
* Kernel crash in 2.6.39-rc2-wl
From: Ben Greear @ 2011-04-06 20:30 UTC (permalink / raw)
To: netdev
This is from today's wireless-testing kernel, with a few non-tainting
patches related to wireless stuff. In general, 39-rc2 seems pretty
flaky, but on this boot, this is the first kernel splat.
I had reloaded our user-space network-config DB, which would have deleted
and created some VETH and MAC-VLAN interfaces, and a bunch of
protocol sockets, virtual-routers (xorp with unique routing tables) etc.
BUG: unable to handle kernel paging request at 50435453
IP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sda/sda1/stat
Modules linked in: xt_CT iptable_raw xt_DSCP xt_dscp xt_string xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange xt_hashlimit xt_connmark xt_addrty]
Pid: 12747, comm: xorp_rtrmgr Not tainted 2.6.39-rc2-wl+ #56 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
EIP: 0060:[<c04d8ac6>] EFLAGS: 00210206 CPU: 0
EIP is at __kmalloc_track_caller+0xd8/0x117
EAX: c0b18ee0 EBX: f5402500 ECX: 0001d3c9 EDX: 00000000
ESI: 50435453 EDI: 0001d3c8 EBP: f17ddd00 ESP: f17ddce8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process xorp_rtrmgr (pid: 12747, ti=f17dc000 task=f147bde0 task.ti=f17dc000)
Stack:
c07869c6 000000d0 000001fc f1284fc0 000000d0 f5487f80 f17ddd1c c07468b9
00000001 00000140 f15e0000 f15e0000 00000000 f17ddd34 c07869c6 ffffffff
f15e0000 00010000 f17ddd88 f17ddd98 c0787005 00004040 00000000 00000002
Call Trace:
[<c07869c6>] ? sk_stream_alloc_skb+0x2c/0xc4
[<c07468b9>] __alloc_skb+0x5d/0xf9
[<c07869c6>] sk_stream_alloc_skb+0x2c/0xc4
[<c0787005>] tcp_sendmsg+0x16d/0x714
[<c07a1776>] inet_sendmsg+0x55/0x5e
[<c073ef79>] __sock_sendmsg+0x56/0x5f
[<c073f608>] sock_sendmsg+0x98/0xac
[<c0461879>] ? mark_lock+0x1e/0x1de
[<c042b66d>] ? pick_next_highest_task_rt+0x148/0x148
[<c04e643e>] ? fget_light+0x30/0xa4
[<c073f686>] ? sockfd_lookup_light+0x1b/0x4b
[<c073fc0f>] sys_sendto+0xaf/0xcb
[<c045500b>] ? __run_hrtimer+0xbc/0x106
[<c04633b5>] ? lock_release_non_nested+0x86/0x1d8
[<c04c10a1>] ? might_fault+0x4c/0x86
[<c073fc48>] sys_send+0x1d/0x1f
[<c0740bb7>] sys_socketcall+0xe6/0x1aa
[<c07fa19c>] sysenter_do_call+0x12/0x38
[<c07f0000>] ? timer_cpu_notify+0x47/0x222
Code: d2 75 13 8b 4d e8 8b 55 ec 50 89 d8 e8 e9 f6 ff ff 5f 89 c6 eb 21 8b 03 64 8b 30 39 d6 75 d2 64 8b 48 04 39 f9 75 ca 8b 53 14 41 <8b> 14 16 64
EIP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117 SS:ESP 0068:f17ddce8
CR2: 0000000050435453
BUG: unable to handle kernel paging request
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: David Miller @ 2011-04-06 20:30 UTC (permalink / raw)
To: bhutchings; +Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1302121247.2840.50.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 06 Apr 2011 21:20:47 +0100
> Amit, I told you already that you must not use my Signed-off-by line
> since you are changing the patch significantly.
Amit, this is a very serious infraction.
You must not ever add someone else's signed-off-by when you make
changes to a patch, unless you have their very clear and explicit
permission to do so.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Eric Dumazet @ 2011-04-06 20:32 UTC (permalink / raw)
To: David Miller
Cc: acme, jesse.brandeburg, fedora-kernel-list, netdev,
jesse.brandeburg
In-Reply-To: <20110406.132906.200378990.davem@davemloft.net>
Le mercredi 06 avril 2011 à 13:29 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Apr 2011 22:18:56 +0200
>
> > I remember last time I work on a fedora kernel, it had conntrack enabled
> >
> > And yes, conntrack can really slowdown a router, because of default
> > parameters.
>
> Yes, if conntrack is enabled performance will indeed tank.
I just check on latest fedora14 (yum updated) :
- conntrack is statically included in kernel, you cannot remove it.
Hmm...
^ permalink raw reply
* Re: [PATCH] dsa/mv88e6131: add support for mv88e6085 switch
From: David Miller @ 2011-04-06 20:33 UTC (permalink / raw)
To: buytenh; +Cc: jacmet, netdev
In-Reply-To: <20110405133944.GG22881@wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Tue, 5 Apr 2011 15:39:44 +0200
> On Tue, Apr 05, 2011 at 03:03:56PM +0200, Peter Korsgaard wrote:
>
>> The mv88e6085 is identical to the mv88e6095, except that all ports are
>> 10/100 Mb/s, so use the existing setup code except for the cpu/dsa speed
>> selection in _setup_port().
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> I don't have access to DSA chip docs anymore, but assuming that you've
> tested this:
>
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets (v2)
From: Neil Horman @ 2011-04-06 20:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber, therbert
In-Reply-To: <20110406.130749.35032326.davem@davemloft.net>
On Wed, Apr 06, 2011 at 01:07:49PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Wed, 6 Apr 2011 15:37:27 -0400
>
> > properly record sk_rxhash in ipv6 sockets (v2)
> >
> > Noticed while working on another project that flows to sockets which I had open
> > on a test systems weren't getting steered properly when I had RFS enabled.
> > Looking more closely I found that:
> >
> > 1) The affected sockets were all ipv6
> > 2) They weren't getting steered because sk->sk_rxhash was never set from the
> > incomming skbs on that socket.
> >
> > This was occuring because there are several points in the IPv4 tcp and udp code
> > which save the rxhash value when a new connection is established. Those calls
> > to sock_rps_save_rxhash were never added to the corresponding ipv6 code paths.
> > This patch adds those calls. Tested by myself to properly enable RFS
> > functionalty on ipv6.
> >
> > Change notes:
> > v2:
> > Filtered UDP to only arm RFS on bound sockets (Eric Dumazet)
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> Ok, I've decided to apply this to net-2.6
>
> The current behavior even surprised me, I was pretty sure we had added
> the hooks to both ipv4 and ipv6.
>
> Thanks a lot Neil.
>
Thanks Dave, I was kind of suprised too, but we definately weren't recording the
rxhash. FWIW It doesn't appear to be a regression. I can't find where in the
history we ever had the hooks. Perhaps at one point tcp and udp rcv paths were
common between ipv4 and 6 address families, and then we bifurcated without
replicating the sock_rps_save_rxhash calls?
Neil
^ permalink raw reply
* Re: Kernel crash in 2.6.39-rc2-wl
From: Eric Dumazet @ 2011-04-06 20:54 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4D9CCD72.7020308@candelatech.com>
Le mercredi 06 avril 2011 à 13:30 -0700, Ben Greear a écrit :
> This is from today's wireless-testing kernel, with a few non-tainting
> patches related to wireless stuff. In general, 39-rc2 seems pretty
> flaky, but on this boot, this is the first kernel splat.
>
> I had reloaded our user-space network-config DB, which would have deleted
> and created some VETH and MAC-VLAN interfaces, and a bunch of
> protocol sockets, virtual-routers (xorp with unique routing tables) etc.
>
>
> BUG: unable to handle kernel paging request at 50435453
> IP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117
> *pde = 00000000
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sda/sda1/stat
> Modules linked in: xt_CT iptable_raw xt_DSCP xt_dscp xt_string xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange xt_hashlimit xt_connmark xt_addrty]
>
> Pid: 12747, comm: xorp_rtrmgr Not tainted 2.6.39-rc2-wl+ #56 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
> EIP: 0060:[<c04d8ac6>] EFLAGS: 00210206 CPU: 0
> EIP is at __kmalloc_track_caller+0xd8/0x117
> EAX: c0b18ee0 EBX: f5402500 ECX: 0001d3c9 EDX: 00000000
> ESI: 50435453 EDI: 0001d3c8 EBP: f17ddd00 ESP: f17ddce8
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process xorp_rtrmgr (pid: 12747, ti=f17dc000 task=f147bde0 task.ti=f17dc000)
> Stack:
> c07869c6 000000d0 000001fc f1284fc0 000000d0 f5487f80 f17ddd1c c07468b9
> 00000001 00000140 f15e0000 f15e0000 00000000 f17ddd34 c07869c6 ffffffff
> f15e0000 00010000 f17ddd88 f17ddd98 c0787005 00004040 00000000 00000002
> Call Trace:
> [<c07869c6>] ? sk_stream_alloc_skb+0x2c/0xc4
> [<c07468b9>] __alloc_skb+0x5d/0xf9
> [<c07869c6>] sk_stream_alloc_skb+0x2c/0xc4
> [<c0787005>] tcp_sendmsg+0x16d/0x714
> [<c07a1776>] inet_sendmsg+0x55/0x5e
> [<c073ef79>] __sock_sendmsg+0x56/0x5f
> [<c073f608>] sock_sendmsg+0x98/0xac
> [<c0461879>] ? mark_lock+0x1e/0x1de
> [<c042b66d>] ? pick_next_highest_task_rt+0x148/0x148
> [<c04e643e>] ? fget_light+0x30/0xa4
> [<c073f686>] ? sockfd_lookup_light+0x1b/0x4b
> [<c073fc0f>] sys_sendto+0xaf/0xcb
> [<c045500b>] ? __run_hrtimer+0xbc/0x106
> [<c04633b5>] ? lock_release_non_nested+0x86/0x1d8
> [<c04c10a1>] ? might_fault+0x4c/0x86
> [<c073fc48>] sys_send+0x1d/0x1f
> [<c0740bb7>] sys_socketcall+0xe6/0x1aa
> [<c07fa19c>] sysenter_do_call+0x12/0x38
> [<c07f0000>] ? timer_cpu_notify+0x47/0x222
> Code: d2 75 13 8b 4d e8 8b 55 ec 50 89 d8 e8 e9 f6 ff ff 5f 89 c6 eb 21 8b 03 64 8b 30 39 d6 75 d2 64 8b 48 04 39 f9 75 ca 8b 53 14 41 <8b> 14 16 64
> EIP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117 SS:ESP 0068:f17ddce8
> CR2: 0000000050435453
Thats "STCP" in ASCII
^ permalink raw reply
* iputils git access broken?
From: Andrew Walrond @ 2011-04-06 21:32 UTC (permalink / raw)
To: netdev
I can't seem to clone the repo, although I can see source on gitweb.
$ git clone git://git.linux-ipv6.org/gitroot/iputils.git
Cloning into iputils...
git.linux-ipv6.org[0: 203.178.142.218]: errno=Connection refused
git.linux-ipv6.org[0: 2001:200:0:1c01:20f:1fff:fe67:32e9]: errno=Network is unreachable
fatal: unable to connect a socket (Network is unreachable)
Is something amiss?
Andrew Walrond
(cc me please; I'm not subscribed)
^ permalink raw reply
* [PATCH] capi: Perform scheduled capifs removal
From: Jan Kiszka @ 2011-04-06 20:58 UTC (permalink / raw)
To: netdev; +Cc: Amerigo Wang, Karsten Keil, David S. Miller
In-Reply-To: <1302080739-4029-1-git-send-email-amwang@redhat.com>
udev fully replaces this special file system that only contains CAPI
NCCI TTY device nodes. User space (pppdcapiplugin) works without
noticing the difference.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
---
I had this version queued locally for quite a while but then forgot to
post it... Thanks for bringing this topic up, Amerigo, but your patch
was missing a few remaining fragments.
Documentation/feature-removal-schedule.txt | 10 --
drivers/isdn/capi/Kconfig | 15 --
drivers/isdn/capi/Makefile | 1 -
drivers/isdn/capi/capi.c | 24 +---
drivers/isdn/capi/capifs.c | 239 ----------------------------
drivers/isdn/capi/capifs.h | 28 ----
6 files changed, 4 insertions(+), 313 deletions(-)
delete mode 100644 drivers/isdn/capi/capifs.c
delete mode 100644 drivers/isdn/capi/capifs.h
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 274b32d..e38ccae 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -425,16 +425,6 @@ Who: anybody or Florian Mickler <florian@mickler.org>
----------------------------
-What: capifs
-When: February 2011
-Files: drivers/isdn/capi/capifs.*
-Why: udev fully replaces this special file system that only contains CAPI
- NCCI TTY device nodes. User space (pppdcapiplugin) works without
- noticing the difference.
-Who: Jan Kiszka <jan.kiszka@web.de>
-
-----------------------------
-
What: KVM paravirt mmu host support
When: January 2011
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
diff --git a/drivers/isdn/capi/Kconfig b/drivers/isdn/capi/Kconfig
index a168e8a..15c3ffd 100644
--- a/drivers/isdn/capi/Kconfig
+++ b/drivers/isdn/capi/Kconfig
@@ -33,21 +33,6 @@ config ISDN_CAPI_CAPI20
standardized libcapi20 to access this functionality. You should say
Y/M here.
-config ISDN_CAPI_CAPIFS_BOOL
- bool "CAPI2.0 filesystem support (DEPRECATED)"
- depends on ISDN_CAPI_MIDDLEWARE && ISDN_CAPI_CAPI20
- help
- This option provides a special file system, similar to /dev/pts with
- device nodes for the special ttys established by using the
- middleware extension above.
- You no longer need this, udev fully replaces it. This feature is
- scheduled for removal.
-
-config ISDN_CAPI_CAPIFS
- tristate
- depends on ISDN_CAPI_CAPIFS_BOOL
- default ISDN_CAPI_CAPI20
-
config ISDN_CAPI_CAPIDRV
tristate "CAPI2.0 capidrv interface support"
depends on ISDN_I4L
diff --git a/drivers/isdn/capi/Makefile b/drivers/isdn/capi/Makefile
index 57123e3..4d5b4b7 100644
--- a/drivers/isdn/capi/Makefile
+++ b/drivers/isdn/capi/Makefile
@@ -7,7 +7,6 @@
obj-$(CONFIG_ISDN_CAPI) += kernelcapi.o
obj-$(CONFIG_ISDN_CAPI_CAPI20) += capi.o
obj-$(CONFIG_ISDN_CAPI_CAPIDRV) += capidrv.o
-obj-$(CONFIG_ISDN_CAPI_CAPIFS) += capifs.o
# Multipart objects.
diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
index 0d70883..bea1009 100644
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -38,8 +38,6 @@
#include <linux/isdn/capiutil.h>
#include <linux/isdn/capicmd.h>
-#include "capifs.h"
-
MODULE_DESCRIPTION("CAPI4Linux: Userspace /dev/capi20 interface");
MODULE_AUTHOR("Carsten Paeth");
MODULE_LICENSE("GPL");
@@ -85,7 +83,6 @@ struct capiminor {
struct kref kref;
unsigned int minor;
- struct dentry *capifs_dentry;
struct capi20_appl *ap;
u32 ncci;
@@ -300,17 +297,8 @@ static void capiminor_free(struct capiminor *mp)
static void capincci_alloc_minor(struct capidev *cdev, struct capincci *np)
{
- struct capiminor *mp;
- dev_t device;
-
- if (!(cdev->userflags & CAPIFLAG_HIGHJACKING))
- return;
-
- mp = np->minorp = capiminor_alloc(&cdev->ap, np->ncci);
- if (mp) {
- device = MKDEV(capinc_tty_driver->major, mp->minor);
- mp->capifs_dentry = capifs_new_ncci(mp->minor, device);
- }
+ if (cdev->userflags & CAPIFLAG_HIGHJACKING)
+ np->minorp = capiminor_alloc(&cdev->ap, np->ncci);
}
static void capincci_free_minor(struct capincci *np)
@@ -319,8 +307,6 @@ static void capincci_free_minor(struct capincci *np)
struct tty_struct *tty;
if (mp) {
- capifs_free_ncci(mp->capifs_dentry);
-
tty = tty_port_tty_get(&mp->port);
if (tty) {
tty_vhangup(tty);
@@ -1514,10 +1500,8 @@ static int __init capi_init(void)
proc_init();
-#if defined(CONFIG_ISDN_CAPI_CAPIFS) || defined(CONFIG_ISDN_CAPI_CAPIFS_MODULE)
- compileinfo = " (middleware+capifs)";
-#elif defined(CONFIG_ISDN_CAPI_MIDDLEWARE)
- compileinfo = " (no capifs)";
+#ifdef CONFIG_ISDN_CAPI_MIDDLEWARE
+ compileinfo = " (middleware)";
#else
compileinfo = " (no middleware)";
#endif
diff --git a/drivers/isdn/capi/capifs.c b/drivers/isdn/capi/capifs.c
deleted file mode 100644
index b4faed7..0000000
--- a/drivers/isdn/capi/capifs.c
+++ /dev/null
@@ -1,239 +0,0 @@
-/* $Id: capifs.c,v 1.1.2.3 2004/01/16 21:09:26 keil Exp $
- *
- * Copyright 2000 by Carsten Paeth <calle@calle.de>
- *
- * Heavily based on devpts filesystem from H. Peter Anvin
- *
- * This software may be used and distributed according to the terms
- * of the GNU General Public License, incorporated herein by reference.
- *
- */
-
-#include <linux/fs.h>
-#include <linux/mount.h>
-#include <linux/slab.h>
-#include <linux/namei.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/ctype.h>
-#include <linux/sched.h> /* current */
-
-#include "capifs.h"
-
-MODULE_DESCRIPTION("CAPI4Linux: /dev/capi/ filesystem");
-MODULE_AUTHOR("Carsten Paeth");
-MODULE_LICENSE("GPL");
-
-/* ------------------------------------------------------------------ */
-
-#define CAPIFS_SUPER_MAGIC (('C'<<8)|'N')
-
-static struct vfsmount *capifs_mnt;
-static int capifs_mnt_count;
-
-static struct {
- int setuid;
- int setgid;
- uid_t uid;
- gid_t gid;
- umode_t mode;
-} config = {.mode = 0600};
-
-/* ------------------------------------------------------------------ */
-
-static int capifs_remount(struct super_block *s, int *flags, char *data)
-{
- int setuid = 0;
- int setgid = 0;
- uid_t uid = 0;
- gid_t gid = 0;
- umode_t mode = 0600;
- char *this_char;
- char *new_opt = kstrdup(data, GFP_KERNEL);
-
- this_char = NULL;
- while ((this_char = strsep(&data, ",")) != NULL) {
- int n;
- char dummy;
- if (!*this_char)
- continue;
- if (sscanf(this_char, "uid=%i%c", &n, &dummy) == 1) {
- setuid = 1;
- uid = n;
- } else if (sscanf(this_char, "gid=%i%c", &n, &dummy) == 1) {
- setgid = 1;
- gid = n;
- } else if (sscanf(this_char, "mode=%o%c", &n, &dummy) == 1)
- mode = n & ~S_IFMT;
- else {
- kfree(new_opt);
- printk("capifs: called with bogus options\n");
- return -EINVAL;
- }
- }
-
- mutex_lock(&s->s_root->d_inode->i_mutex);
-
- replace_mount_options(s, new_opt);
- config.setuid = setuid;
- config.setgid = setgid;
- config.uid = uid;
- config.gid = gid;
- config.mode = mode;
-
- mutex_unlock(&s->s_root->d_inode->i_mutex);
-
- return 0;
-}
-
-static const struct super_operations capifs_sops =
-{
- .statfs = simple_statfs,
- .remount_fs = capifs_remount,
- .show_options = generic_show_options,
-};
-
-
-static int
-capifs_fill_super(struct super_block *s, void *data, int silent)
-{
- struct inode * inode;
-
- s->s_blocksize = 1024;
- s->s_blocksize_bits = 10;
- s->s_magic = CAPIFS_SUPER_MAGIC;
- s->s_op = &capifs_sops;
- s->s_time_gran = 1;
-
- inode = new_inode(s);
- if (!inode)
- goto fail;
- inode->i_ino = 1;
- inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
- inode->i_mode = S_IFDIR | S_IRUGO | S_IXUGO | S_IWUSR;
- inode->i_op = &simple_dir_inode_operations;
- inode->i_fop = &simple_dir_operations;
- inode->i_nlink = 2;
-
- s->s_root = d_alloc_root(inode);
- if (s->s_root)
- return 0;
-
- printk("capifs: get root dentry failed\n");
- iput(inode);
-fail:
- return -ENOMEM;
-}
-
-static struct dentry *capifs_mount(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
-{
- return mount_single(fs_type, flags, data, capifs_fill_super);
-}
-
-static struct file_system_type capifs_fs_type = {
- .owner = THIS_MODULE,
- .name = "capifs",
- .mount = capifs_mount,
- .kill_sb = kill_anon_super,
-};
-
-static struct dentry *new_ncci(unsigned int number, dev_t device)
-{
- struct super_block *s = capifs_mnt->mnt_sb;
- struct dentry *root = s->s_root;
- struct dentry *dentry;
- struct inode *inode;
- char name[10];
- int namelen;
-
- mutex_lock(&root->d_inode->i_mutex);
-
- namelen = sprintf(name, "%d", number);
- dentry = lookup_one_len(name, root, namelen);
- if (IS_ERR(dentry)) {
- dentry = NULL;
- goto unlock_out;
- }
-
- if (dentry->d_inode) {
- dput(dentry);
- dentry = NULL;
- goto unlock_out;
- }
-
- inode = new_inode(s);
- if (!inode) {
- dput(dentry);
- dentry = NULL;
- goto unlock_out;
- }
-
- /* config contents is protected by root's i_mutex */
- inode->i_uid = config.setuid ? config.uid : current_fsuid();
- inode->i_gid = config.setgid ? config.gid : current_fsgid();
- inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
- inode->i_ino = number + 2;
- init_special_inode(inode, S_IFCHR|config.mode, device);
-
- d_instantiate(dentry, inode);
- dget(dentry);
-
-unlock_out:
- mutex_unlock(&root->d_inode->i_mutex);
-
- return dentry;
-}
-
-struct dentry *capifs_new_ncci(unsigned int number, dev_t device)
-{
- struct dentry *dentry;
-
- if (simple_pin_fs(&capifs_fs_type, &capifs_mnt, &capifs_mnt_count) < 0)
- return NULL;
-
- dentry = new_ncci(number, device);
- if (!dentry)
- simple_release_fs(&capifs_mnt, &capifs_mnt_count);
-
- return dentry;
-}
-
-void capifs_free_ncci(struct dentry *dentry)
-{
- struct dentry *root = capifs_mnt->mnt_sb->s_root;
- struct inode *inode;
-
- if (!dentry)
- return;
-
- mutex_lock(&root->d_inode->i_mutex);
-
- inode = dentry->d_inode;
- if (inode) {
- drop_nlink(inode);
- d_delete(dentry);
- dput(dentry);
- }
- dput(dentry);
-
- mutex_unlock(&root->d_inode->i_mutex);
-
- simple_release_fs(&capifs_mnt, &capifs_mnt_count);
-}
-
-static int __init capifs_init(void)
-{
- return register_filesystem(&capifs_fs_type);
-}
-
-static void __exit capifs_exit(void)
-{
- unregister_filesystem(&capifs_fs_type);
-}
-
-EXPORT_SYMBOL(capifs_new_ncci);
-EXPORT_SYMBOL(capifs_free_ncci);
-
-module_init(capifs_init);
-module_exit(capifs_exit);
diff --git a/drivers/isdn/capi/capifs.h b/drivers/isdn/capi/capifs.h
deleted file mode 100644
index e193d11..0000000
--- a/drivers/isdn/capi/capifs.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/* $Id: capifs.h,v 1.1.2.2 2004/01/16 21:09:26 keil Exp $
- *
- * Copyright 2000 by Carsten Paeth <calle@calle.de>
- *
- * This software may be used and distributed according to the terms
- * of the GNU General Public License, incorporated herein by reference.
- *
- */
-
-#include <linux/dcache.h>
-
-#if defined(CONFIG_ISDN_CAPI_CAPIFS) || defined(CONFIG_ISDN_CAPI_CAPIFS_MODULE)
-
-struct dentry *capifs_new_ncci(unsigned int num, dev_t device);
-void capifs_free_ncci(struct dentry *dentry);
-
-#else
-
-static inline struct dentry *capifs_new_ncci(unsigned int num, dev_t device)
-{
- return NULL;
-}
-
-static inline void capifs_free_ncci(struct dentry *dentry)
-{
-}
-
-#endif
--
1.7.1
^ permalink raw reply related
* RE: mdiobus_register() issue for an SMSC8720a PHY
From: ANDY KENNEDY @ 2011-04-06 21:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <9AC3F0E75060224C8BBC5BA2DDC8853A1FA0C0C6@EXV1.corp.adtran.com>
> ====== get_device_parent:689
> dev = 0x8781da40
> dev->class = 0x803c2ad4
> dev->class->p = 0x00000000
> dev->class->p->class_dirs = 0x00000048
Ughh. I deleted a line of text from the e-mail I sent. I found my
problem. The line of text that would have given all of you the answer
quickly was this:
The below code is from arch/mips/<myboard>/platform.c.
Perhaps this is vague, so I'll clarify. I start this process from the
board level configuration, therefore the mdio class (which gets created
in the init of mdiobus) isn't -- thus class->p is empty.
So, now I just need to relocate this code to some "real" network driver,
I guess.
Andy
^ permalink raw reply
* Re: [PATCH] pppoe: drop PPPOX_ZOMBIEs in pppoe_flush_dev
From: David Miller @ 2011-04-06 21:05 UTC (permalink / raw)
To: uweber; +Cc: netdev
In-Reply-To: <20110404123324.GA12662@babylon>
From: Ulrich Weber <uweber@astaro.com>
Date: Mon, 4 Apr 2011 14:33:24 +0200
> otherwise we loop forever if a PPPoE socket was set
> to PPPOX_ZOMBIE state by a PADT message when the
> ethernet device is going down afterwards.
>
> Signed-off-by: Ulrich Weber <uweber@astaro.com>
Applied, thanks Ulrich.
^ permalink raw reply
* Re: pull request: wireless-2.6 2011-04-06
From: David Miller @ 2011-04-06 21:05 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110406200032.GK11941@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 6 Apr 2011 16:00:33 -0400
> Here is another batch of fixes intended for 2.6.39...
>
> This includes a fix to avoid receiving duplicate frames in "cooked"
> monitor mode, a mac80211 documentation fix to avoid developer
> confusion, an rt2x00 fix to avoid cancelling some uninitialized work,
> a wl12xx buffer overflow fix, an email address correction for wl12xx
> module info, a zd1211rw regression fix, a zd1211rw WARNING fix,
> and rtlwifi fix to avoid using some uninitialized variables, a fix
> to broaden the iwl600 hardware supported by iwlagn to match what the
> Windows driver is supporting, a b43 fix to allocate properly sized
> receive buffers, and some stuff related to device IDs.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Brandeburg, Jesse @ 2011-04-06 21:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, acme@ghostprotocols.net, jesse.brandeburg@gmail.com,
fedora-kernel-list@redhat.com, netdev@vger.kernel.org
In-Reply-To: <1302121945.2701.31.camel@edumazet-laptop>
On Wed, 6 Apr 2011, Eric Dumazet wrote:
> Le mercredi 06 avril 2011 à 13:29 -0700, David Miller a écrit :
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 06 Apr 2011 22:18:56 +0200
> >
> > > I remember last time I work on a fedora kernel, it had conntrack enabled
> > >
> > > And yes, conntrack can really slowdown a router, because of default
> > > parameters.
> >
> > Yes, if conntrack is enabled performance will indeed tank.
>
> I just check on latest fedora14 (yum updated) :
>
> - conntrack is statically included in kernel, you cannot remove it.
>
>
> Hmm...
Thanks for the replies,
Yes indeed, I bet that conntrack was the item that caused the grief I saw.
In fact turning off CONFIG_NETFILTER disables conntrack and solved my
problem. :-)
Now the question is how to get the netfiltery/conntracky goodness without
impacting those who want to go fast, maybe without a helmet.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Eric Dumazet @ 2011-04-06 21:11 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: David Miller, acme@ghostprotocols.net, jesse.brandeburg@gmail.com,
fedora-kernel-list@redhat.com, netdev@vger.kernel.org
In-Reply-To: <alpine.WNT.2.00.1104061400320.6556@JBRANDEB-DESK2.amr.corp.intel.com>
Le mercredi 06 avril 2011 à 14:08 -0700, Brandeburg, Jesse a écrit :
> Thanks for the replies,
> Yes indeed, I bet that conntrack was the item that caused the grief I saw.
> In fact turning off CONFIG_NETFILTER disables conntrack and solved my
> problem. :-)
>
> Now the question is how to get the netfiltery/conntracky goodness without
> impacting those who want to go fast, maybe without a helmet.
Thats pretty simple, just load netfilter modules if necessary.
If not loaded, cost is pretty small, being predicted branches.
^ permalink raw reply
* Re: 2.6.39-rc2 boot crash
From: Eric B Munson @ 2011-04-06 21:20 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel, kaber, zbr, davem, gregkh, ksrinivasan, netdev
In-Reply-To: <1302115953.8094.217.camel@nimitz>
[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]
On Wed, 06 Apr 2011, Dave Hansen wrote:
> On Wed, 2011-04-06 at 14:47 -0400, Eric B Munson wrote:
> > I am seeing a boot crash on my machine with 2.6.39-rc2. I don't yet have
> > netconsole setup and I don't have serial so the best I can do at the moment
> > is a couple of pictures of the stack trace.
> >
> > http://tinypic.com/r/2zsr19i/7
> >
> > And
> >
> > http://tinypic.com/r/2iw22dj/7
> >
> > I will try and get a net console working for better output, is there
> > anything else that would help?
>
> This:
>
> > boot_delay= Milliseconds to delay each printk during boot.
> > Values larger than 10 seconds (10000) are changed to
> > no delay (0).
> > Format: integer
>
> sometimes gives you enough time to get something out of the system. You
> might also want to try and boot the same kernel in a VM. It might just
> be a weird configuration issue, or maybe even a lockdep bug. If it's
> not hardware related, booting in a VM should help a lot.
>
> -- Dave
>
A bisect points at commit 04f482faf50535229a5a5c8d629cf963899f857c for the
first bad one. Unfortunately, I have not made netconsole work yet and the
hang is happening mostly right when X starts so I can't even see the console.
I will keep at the netconsole and see if I can get it functioning, also I will
try to boot this kernel in a VM and see if that helps.
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: 2.6.39-rc2 boot crash
From: David Miller @ 2011-04-06 21:21 UTC (permalink / raw)
To: emunson; +Cc: dave, linux-kernel, kaber, zbr, gregkh, ksrinivasan, netdev
In-Reply-To: <20110406212041.GA2596@mgebm.net>
From: Eric B Munson <emunson@mgebm.net>
Date: Wed, 6 Apr 2011 17:20:41 -0400
> A bisect points at commit 04f482faf50535229a5a5c8d629cf963899f857c for the
> first bad one. Unfortunately, I have not made netconsole work yet and the
> hang is happening mostly right when X starts so I can't even see the console.
> I will keep at the netconsole and see if I can get it functioning, also I will
> try to boot this kernel in a VM and see if that helps.
Patrick, please help Eric so we can fix this bug.
Thanks.
^ permalink raw reply
* Re: NETIF_F_TSO vs NETIF_F_TSO{6,_ECN}
From: David Miller @ 2011-04-06 21:22 UTC (permalink / raw)
To: bhutchings; +Cc: mirq-linux, netdev, herbert
In-Reply-To: <1302028298.2932.76.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 05 Apr 2011 19:31:38 +0100
> *sigh* So it seems the commit message was wrong... and it should have
> included a change like this:
This seems correct, can you formally submit this fix?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 01/12] sky2: support ethtool set_phys_id
From: David Miller @ 2011-04-06 21:30 UTC (permalink / raw)
To: shemminger; +Cc: bhutchings, netdev
In-Reply-To: <20110404184501.356412753@linuxplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 04 Apr 2011 11:43:41 -0700
> Use ethtool set_phys_id to control LED. Fixes issues with RTNL being
> held for extended periods.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 02/12] skge: implement set_phys_id
From: David Miller @ 2011-04-06 21:30 UTC (permalink / raw)
To: shemminger; +Cc: bhutchings, netdev
In-Reply-To: <20110404184501.450494215@linuxplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 04 Apr 2011 11:43:42 -0700
> Implement set_phys_id led control on SysKonnect board.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, although I had to fix:
> + case ETHTOOL_ID_ACTIVE:
> + return -1;
to return -EINVAL.
^ permalink raw reply
* Re: [PATCH net-next-2.6 03/12] e100: implemenet set_phys_id
From: David Miller @ 2011-04-06 21:31 UTC (permalink / raw)
To: shemminger
Cc: bhutchings, jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, john.ronciak, netdev
In-Reply-To: <20110404184501.541503577@linuxplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 04 Apr 2011 11:43:43 -0700
> Implement set_phys_id to control LED.
> Compile tested only.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Deferred to Intel driver maintainers.
^ permalink raw reply
* Re: [PATCH net-next-2.6 04/12] e1000: convert to set_phys_id
From: David Miller @ 2011-04-06 21:31 UTC (permalink / raw)
To: shemminger
Cc: bhutchings, jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, john.ronciak, netdev
In-Reply-To: <20110404184501.640779086@linuxplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 04 Apr 2011 11:43:44 -0700
> Convert to new LED control infrastucture and remove no longer
> necessary bits.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Deferred to Intel driver maintainers.
^ permalink raw reply
* Re: [PATCH net-next-2.6 05/12] e1000e: implement ethtool set_phys_id
From: David Miller @ 2011-04-06 21:31 UTC (permalink / raw)
To: shemminger
Cc: bhutchings, jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, john.ronciak, netdev
In-Reply-To: <20110404184501.732239902@linuxplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 04 Apr 2011 11:43:45 -0700
> The new ethtool set_phys_id takes over controlling the LED for identifying
> boards. This fixes the lockout during that period.
> For this device lots of extra infrastructure can also be removed by using
> set_phys_id.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Deferred to Intel driver maintainers.
^ permalink raw reply
* Re: [PATCH net-next-2.6 06/12] igb: convert to ethtool set_phys_id
From: David Miller @ 2011-04-06 21:31 UTC (permalink / raw)
To: shemminger
Cc: bhutchings, jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, john.ronciak, netdev
In-Reply-To: <20110404184501.824549872@linuxplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 04 Apr 2011 11:43:46 -0700
> Convert igb driver to use new set_phys_id ethtool interface.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Deferred to Intel driver maintainers.
^ 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