* Re: [RFC PATCH 0/2] net: connect to UNIX sockets from specified root
From: H. Peter Anvin @ 2012-08-10 23:09 UTC (permalink / raw)
To: Alan Cox
Cc: J. Bruce Fields, Stanislav Kinsbursky, Trond.Myklebust, davem,
linux-nfs, eric.dumazet, xemul, netdev, linux-kernel, viro,
tim.c.chen, devel
In-Reply-To: <20120810202818.06236f46@pyramind.ukuu.org.uk>
On 08/10/2012 12:28 PM, Alan Cox wrote:
> Explicitly for Linux yes - this is not generally true of the AF_UNIX
> socket domain and even the permissions aspect isn't guaranteed to be
> supported on some BSD environments !
Yes, but let's worry about what the Linux behavior should be.
> The name is however just a proxy for the socket itself. You don't even
> get a device node in the usual sense or the same inode in the file system
> space.
No, but it is looked up the same way any other inode is (the difference
between FIFOs and sockets is that sockets have separate connections,
which is also why open() on sockets would be nice.)
However, there is a fundamental difference between AF_UNIX sockets and
open(), and that is how the pathname is delivered. It thus would make
more sense to provide the openat()-like information in struct
sockaddr_un, but that may be very hard to do in a sensible way. In that
sense it perhaps would be cleaner to be able to do an open[at]() on the
socket node with O_PATH (perhaps there should be an O_SOCKET option,
even?) and pass the resulting file descriptor to bind() or connect().
-hpa
^ permalink raw reply
* Re: Latest commit from 08 Aug 2012 hang system after run Eclipse -> Eclipse update
From: David Miller @ 2012-08-10 23:26 UTC (permalink / raw)
To: torvalds; +Cc: netdev, kkolasa
In-Reply-To: <CA+55aFz3M1bJ7PobLHPJAceToJivmnoHfe-NYbYv6FyqPg9otA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 10 Aug 2012 21:07:16 +0300
> ---------- Forwarded message ----------
> From: "Krzysztof Kolasa" <kkolasa@winsoft.pl>
> Date: Aug 9, 2012 10:38 PM
> Subject: Latest commit from 08 Aug 2012 hang system after run Eclipse ->
> Eclipse update
> To: <torvalds@linux-foundation.org>
>
> Probably after this path ( networking fixes from David Miller )
> https://github.com/torvalds/**linux/commit/**f4ba394c1b02e7fc2179fda8d3941a*
> *5b3b65efb6<https://github.com/torvalds/linux/commit/f4ba394c1b02e7fc2179fda8d3941a5b3b65efb6>
>
> java ( TCP ? ) crash system : run Eclipse, next Update Eclipse from menu ->
> kernel panic stop hardware
>
> error screenshot : https://docs.google.com/open?**id=**
> 0B1LAMAFWTdeweUl0MjdHNFJpbk0<https://docs.google.com/open?id=0B1LAMAFWTdeweUl0MjdHNFJpbk0>
Fixed in the 'net' tree by commit:
====================
commit 63d02d157ec4124990258d66517b6c11fd6df0cf
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Aug 9 14:11:00 2012 +0000
net: tcp: ipv6_mapped needs sk_rx_dst_set method
commit 5d299f3d3c8a2fb (net: ipv6: fix TCP early demux) added a
regression for ipv6_mapped case.
[ 67.422369] SELinux: initialized (dev autofs, type autofs), uses
genfs_contexts
[ 67.449678] SELinux: initialized (dev autofs, type autofs), uses
genfs_contexts
[ 92.631060] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 92.631435] IP: [< (null)>] (null)
[ 92.631645] PGD 0
[ 92.631846] Oops: 0010 [#1] SMP
[ 92.632095] Modules linked in: autofs4 sunrpc ipv6 dm_mirror
dm_region_hash dm_log dm_multipath dm_mod video sbs sbshc battery ac lp
parport sg snd_hda_intel snd_hda_codec snd_seq_oss snd_seq_midi_event
snd_seq snd_seq_device pcspkr snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer serio_raw button floppy snd i2c_i801 i2c_core soundcore
snd_page_alloc shpchp ide_cd_mod cdrom microcode ehci_hcd ohci_hcd
uhci_hcd
[ 92.634294] CPU 0
[ 92.634294] Pid: 4469, comm: sendmail Not tainted 3.6.0-rc1 #3
[ 92.634294] RIP: 0010:[<0000000000000000>] [< (null)>]
(null)
[ 92.634294] RSP: 0018:ffff880245fc7cb0 EFLAGS: 00010282
[ 92.634294] RAX: ffffffffa01985f0 RBX: ffff88024827ad00 RCX:
0000000000000000
[ 92.634294] RDX: 0000000000000218 RSI: ffff880254735380 RDI:
ffff88024827ad00
[ 92.634294] RBP: ffff880245fc7cc8 R08: 0000000000000001 R09:
0000000000000000
[ 92.634294] R10: 0000000000000000 R11: ffff880245fc7bf8 R12:
ffff880254735380
[ 92.634294] R13: ffff880254735380 R14: 0000000000000000 R15:
7fffffffffff0218
[ 92.634294] FS: 00007f4516ccd6f0(0000) GS:ffff880256600000(0000)
knlGS:0000000000000000
[ 92.634294] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 92.634294] CR2: 0000000000000000 CR3: 0000000245ed1000 CR4:
00000000000007f0
[ 92.634294] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 92.634294] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 92.634294] Process sendmail (pid: 4469, threadinfo ffff880245fc6000,
task ffff880254b8cac0)
[ 92.634294] Stack:
[ 92.634294] ffffffff813837a7 ffff88024827ad00 ffff880254b6b0e8
ffff880245fc7d68
[ 92.634294] ffffffff81385083 00000000001d2680 ffff8802547353a8
ffff880245fc7d18
[ 92.634294] ffffffff8105903a ffff88024827ad60 0000000000000002
00000000000000ff
[ 92.634294] Call Trace:
[ 92.634294] [<ffffffff813837a7>] ? tcp_finish_connect+0x2c/0xfa
[ 92.634294] [<ffffffff81385083>] tcp_rcv_state_process+0x2b6/0x9c6
[ 92.634294] [<ffffffff8105903a>] ? sched_clock_cpu+0xc3/0xd1
[ 92.634294] [<ffffffff81059073>] ? local_clock+0x2b/0x3c
[ 92.634294] [<ffffffff8138caf3>] tcp_v4_do_rcv+0x63a/0x670
[ 92.634294] [<ffffffff8133278e>] release_sock+0x128/0x1bd
[ 92.634294] [<ffffffff8139f060>] __inet_stream_connect+0x1b1/0x352
[ 92.634294] [<ffffffff813325f5>] ? lock_sock_nested+0x74/0x7f
[ 92.634294] [<ffffffff8104b333>] ? wake_up_bit+0x25/0x25
[ 92.634294] [<ffffffff813325f5>] ? lock_sock_nested+0x74/0x7f
[ 92.634294] [<ffffffff8139f223>] ? inet_stream_connect+0x22/0x4b
[ 92.634294] [<ffffffff8139f234>] inet_stream_connect+0x33/0x4b
[ 92.634294] [<ffffffff8132e8cf>] sys_connect+0x78/0x9e
[ 92.634294] [<ffffffff813fd407>] ? sysret_check+0x1b/0x56
[ 92.634294] [<ffffffff81088503>] ? __audit_syscall_entry+0x195/0x1c8
[ 92.634294] [<ffffffff811cc26e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 92.634294] [<ffffffff813fd3e2>] system_call_fastpath+0x16/0x1b
[ 92.634294] Code: Bad RIP value.
[ 92.634294] RIP [< (null)>] (null)
[ 92.634294] RSP <ffff880245fc7cb0>
[ 92.634294] CR2: 0000000000000000
[ 92.648982] ---[ end trace 24e2bed94314c8d9 ]---
[ 92.649146] Kernel panic - not syncing: Fatal exception in interrupt
Fix this using inet_sk_rx_dst_set(), and export this function in case
IPv6 is modular.
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/net/tcp.h b/include/net/tcp.h
index e19124b..1f000ff 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -464,6 +464,7 @@ extern int tcp_disconnect(struct sock *sk, int flags);
void tcp_connect_init(struct sock *sk);
void tcp_finish_connect(struct sock *sk, struct sk_buff *skb);
int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, size_t size);
+void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb);
/* From syncookies.c */
extern __u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 272241f..7678237 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1869,7 +1869,7 @@ static struct timewait_sock_ops tcp_timewait_sock_ops = {
.twsk_destructor= tcp_twsk_destructor,
};
-static void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb)
+void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb)
{
struct dst_entry *dst = skb_dst(skb);
@@ -1877,6 +1877,7 @@ static void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb)
sk->sk_rx_dst = dst;
inet_sk(sk)->rx_dst_ifindex = skb->skb_iif;
}
+EXPORT_SYMBOL(inet_sk_rx_dst_set);
const struct inet_connection_sock_af_ops ipv4_specific = {
.queue_xmit = ip_queue_xmit,
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 5a439e9..bb9ce2b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1777,6 +1777,7 @@ static const struct inet_connection_sock_af_ops ipv6_mapped = {
.queue_xmit = ip_queue_xmit,
.send_check = tcp_v4_send_check,
.rebuild_header = inet_sk_rebuild_header,
+ .sk_rx_dst_set = inet_sk_rx_dst_set,
.conn_request = tcp_v6_conn_request,
.syn_recv_sock = tcp_v6_syn_recv_sock,
.net_header_len = sizeof(struct iphdr),
^ permalink raw reply related
* Re: pull request: wireless 2012-08-10
From: David Miller @ 2012-08-10 23:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20120810183351.GD1950@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 10 Aug 2012 14:33:51 -0400
> Here is a handful of fixes intended for 3.6.
>
> Daniel Drake offers a cfg80211 fix to consume pending events before
> taking a wireless device down. This prevents a resource leak.
>
> Stanislaw Gruszka gives us a fix for a NULL pointer dereference in
> rt61pci.
>
> Johannes Berg provides an iwlwifi patch to disable "greenfield" mode.
> Use of that mode was causing a rate scaling problem in for iwlwifi.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 1/1] ixgbe: add missing braces
From: David Miller @ 2012-08-10 23:51 UTC (permalink / raw)
To: peter.p.waskiewicz.jr; +Cc: emil.s.tantilov, netdev, gospo, sassmann
In-Reply-To: <1344620114-6173-1-git-send-email-peter.p.waskiewicz.jr@intel.com>
From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Date: Fri, 10 Aug 2012 10:35:14 -0700
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> This patch adds missing braces around the 10gig link check to include the check for KR support.
>
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Reported-by: Sascha Wildner <saw@online.de>
> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] codel: refine one condition to avoid a nul rec_inv_sqrt
From: David Miller @ 2012-08-10 23:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, lp2s1h
In-Reply-To: <1344611771.31104.2716.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 10 Aug 2012 17:16:11 +0200
> On Mon, 2012-07-30 at 14:54 -0700, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 30 Jul 2012 08:52:21 +0200
>>
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > One condition before codel_Newton_step() was not good if
>> > we never left the dropping state for a flow. As a result
>> > rec_inv_sqrt was 0, instead of the ~0 initial value.
>> >
>> > codel control law was then set to a very aggressive mode, dropping
>> > many packets before reaching 'target' and recovering from this problem.
>> >
>> > To keep codel_vars_init() as efficient as possible, refine
>> > the condition to make sure rec_inv_sqrt initial value is correct
>> >
>> > Many thanks to Anton Mich for discovering the issue and suggesting
>> > a fix.
>> >
>> > Reported-by: Anton Mich <lp2s1h@gmail.com>
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>>
>> Applied and queued up for -stable.
>
> Hi David, I think this patch got lost somehow ?
Thanks for catching this, I've corrected it now.
^ permalink raw reply
* Re: [PATCH net-next] af_packet: relax BUG statement in tpacket_destruct_skb
From: David Miller @ 2012-08-10 23:54 UTC (permalink / raw)
To: danborkmann; +Cc: netdev
In-Reply-To: <1344530345.28842.11.camel@thinkbox>
From: Daniel Borkmann <danborkmann@iogearbox.net>
Date: Thu, 09 Aug 2012 18:39:05 +0200
> Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
>
> Don't use BUG() or BUG_ON() unless there's really no way out; one
> example might be detecting data structure corruption in the middle
> of an operation that can't be backed out of. If the (sub)system
> can somehow continue operating, perhaps with reduced functionality,
> it's probably not BUG-worthy.
>
> If you're tempted to BUG(), think again: is completely giving up
> really the *only* solution? There are usually better options, where
> users don't need to reboot ASAP and can mostly shut down cleanly.
>
> In our case, the status flag of a ring buffer slot is managed from both sides,
> the kernel space and the user space. This means that even though the kernel
> side might work as expected, the user space screws up and changes this flag
> right between the send(2) is triggered when the flag is changed to
> TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
> will hit the BUG macro. Instead, we relax this condition with a WARN_ON_ONCE
> macro, so that the user is aware of this situation. I've tested it and the
> system still behaves /stable/, so in accordance with the above comment, we
> should rather relax this behavior with a warning.
>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
I would like this check to simply be deleted completely.
As you said, it's a user changable value, therefore we cannot use it
for kernel side internal consistency checks at all.
^ permalink raw reply
* Re: [PATCH 1/1] ixgbe: add missing braces
From: Joe Perches @ 2012-08-11 0:34 UTC (permalink / raw)
To: Peter P Waskiewicz Jr; +Cc: davem, Emil Tantilov, netdev, gospo, sassmann
In-Reply-To: <1344620114-6173-1-git-send-email-peter.p.waskiewicz.jr@intel.com>
On Fri, 2012-08-10 at 10:35 -0700, Peter P Waskiewicz Jr wrote:
> From: Emil Tantilov <emil.s.tantilov@intel.com>
[]
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
[]
> @@ -804,12 +804,13 @@ static s32 ixgbe_setup_mac_link_82599(struct ixgbe_hw *hw,
> link_mode == IXGBE_AUTOC_LMS_KX4_KX_KR_SGMII) {
> /* Set KX4/KX/KR support according to speed requested */
> autoc &= ~(IXGBE_AUTOC_KX4_KX_SUPP_MASK | IXGBE_AUTOC_KR_SUPP);
> - if (speed & IXGBE_LINK_SPEED_10GB_FULL)
> + if (speed & IXGBE_LINK_SPEED_10GB_FULL) {
> if (orig_autoc & IXGBE_AUTOC_KX4_SUPP)
> autoc |= IXGBE_AUTOC_KX4_SUPP;
> if ((orig_autoc & IXGBE_AUTOC_KR_SUPP) &&
> (hw->phy.smart_speed_active == false))
trivial and unrelated:
Testing booleans against true|false is not good style.
"value == false" is better written as "!value", etc...
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove delay at device dismantle
From: Eric Dumazet @ 2012-08-11 5:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Tom Herbert, Mahesh Bandewar, Eric W. Biederman
In-Reply-To: <1344613369.31104.2734.camel@edumazet-glaptop>
On Fri, 2012-08-10 at 17:42 +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> I noticed extra one second delay in device dismantle, tracked down to
> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>
...
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Mahesh Bandewar <maheshb@google.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
> v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
> as its more risky, base this patch on net-next
Also I am leaving for a one week vacation with no access to the
Internet, so better hold this patch until my return ;)
Thanks
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove delay at device dismantle
From: David Miller @ 2012-08-11 5:57 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, therbert, maheshb, ebiederm
In-Reply-To: <1344664487.5158.1.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 11 Aug 2012 07:54:47 +0200
> On Fri, 2012-08-10 at 17:42 +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> I noticed extra one second delay in device dismantle, tracked down to
>> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>>
> ...
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Tom Herbert <therbert@google.com>
>> Cc: Mahesh Bandewar <maheshb@google.com>
>> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>> v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
>> as its more risky, base this patch on net-next
>
> Also I am leaving for a one week vacation with no access to the
> Internet, so better hold this patch until my return ;)
Ok :)
^ permalink raw reply
* Re: [RFC PATCH 0/2] net: connect to UNIX sockets from specified root
From: Pavel Emelyanov @ 2012-08-11 6:23 UTC (permalink / raw)
To: H. Peter Anvin, Alan Cox, Stanislav Kinsbursky
Cc: J. Bruce Fields,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
tim.c.chen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
In-Reply-To: <50259494.8060304-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
On 08/11/2012 03:09 AM, H. Peter Anvin wrote:
> On 08/10/2012 12:28 PM, Alan Cox wrote:
>> Explicitly for Linux yes - this is not generally true of the AF_UNIX
>> socket domain and even the permissions aspect isn't guaranteed to be
>> supported on some BSD environments !
>
> Yes, but let's worry about what the Linux behavior should be.
>
>> The name is however just a proxy for the socket itself. You don't even
>> get a device node in the usual sense or the same inode in the file system
>> space.
>
>
> No, but it is looked up the same way any other inode is (the difference
> between FIFOs and sockets is that sockets have separate connections,
> which is also why open() on sockets would be nice.)
>
> However, there is a fundamental difference between AF_UNIX sockets and
> open(), and that is how the pathname is delivered. It thus would make
> more sense to provide the openat()-like information in struct
> sockaddr_un, but that may be very hard to do in a sensible way. In that
> sense it perhaps would be cleaner to be able to do an open[at]() on the
> socket node with O_PATH (perhaps there should be an O_SOCKET option,
> even?) and pass the resulting file descriptor to bind() or connect().
I vote for this (openat + O_WHATEVER on a unix socket) as well. It will
help us in checkpoint-restore, making handling of overmounted/unlinked
sockets much cleaner.
> -hpa
Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] af_packet: relax BUG statement in tpacket_destruct_skb
From: Daniel Borkmann @ 2012-08-11 7:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120810.165450.638010040921216276.davem@davemloft.net>
On Sat, Aug 11, 2012 at 1:54 AM, David Miller <davem@davemloft.net> wrote:
> From: Daniel Borkmann <danborkmann@iogearbox.net>
> Date: Thu, 09 Aug 2012 18:39:05 +0200
>
>> Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
>>
>> Don't use BUG() or BUG_ON() unless there's really no way out; one
>> example might be detecting data structure corruption in the middle
>> of an operation that can't be backed out of. If the (sub)system
>> can somehow continue operating, perhaps with reduced functionality,
>> it's probably not BUG-worthy.
>>
>> If you're tempted to BUG(), think again: is completely giving up
>> really the *only* solution? There are usually better options, where
>> users don't need to reboot ASAP and can mostly shut down cleanly.
>>
>> In our case, the status flag of a ring buffer slot is managed from both sides,
>> the kernel space and the user space. This means that even though the kernel
>> side might work as expected, the user space screws up and changes this flag
>> right between the send(2) is triggered when the flag is changed to
>> TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
>> will hit the BUG macro. Instead, we relax this condition with a WARN_ON_ONCE
>> macro, so that the user is aware of this situation. I've tested it and the
>> system still behaves /stable/, so in accordance with the above comment, we
>> should rather relax this behavior with a warning.
>>
>> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
>
> I would like this check to simply be deleted completely.
>
> As you said, it's a user changable value, therefore we cannot use it
> for kernel side internal consistency checks at all.
Thanks for the feedback, I will resend a proper patch!
Best,
Daniel
^ permalink raw reply
* [PATCH net-next] af_packet: remove BUG statement in tpacket_destruct_skb
From: Daniel Borkmann @ 2012-08-11 8:48 UTC (permalink / raw)
To: davem; +Cc: netdev
Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
Don't use BUG() or BUG_ON() unless there's really no way out; one
example might be detecting data structure corruption in the middle
of an operation that can't be backed out of. If the (sub)system
can somehow continue operating, perhaps with reduced functionality,
it's probably not BUG-worthy.
If you're tempted to BUG(), think again: is completely giving up
really the *only* solution? There are usually better options, where
users don't need to reboot ASAP and can mostly shut down cleanly.
In our case, the status flag of a ring buffer slot is managed from both sides,
the kernel space and the user space. This means that even though the kernel
side might work as expected, the user space screws up and changes this flag
right between the send(2) is triggered when the flag is changed to
TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
will hit the BUG macro. As David suggested, the best solution is to simply
remove this statement since it cannot be used for kernel side internal
consistency checks. I've tested it and the system still behaves /stable/ in
this case, so in accordance with the above comment, we should rather remove it.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
---
net/packet/af_packet.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ceaca7c..bbea24c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1936,7 +1936,6 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
if (likely(po->tx_ring.pg_vec)) {
ph = skb_shinfo(skb)->destructor_arg;
- BUG_ON(__packet_get_status(po, ph) != TP_STATUS_SENDING);
BUG_ON(atomic_read(&po->tx_ring.pending) == 0);
atomic_dec(&po->tx_ring.pending);
__packet_set_status(po, ph, TP_STATUS_AVAILABLE);
^ permalink raw reply related
* [PATCH] macvtap: rcu_dereference outside read-lock section
From: Denis Efremov @ 2012-08-11 10:05 UTC (permalink / raw)
To: David S. Miller
Cc: Denis Efremov, Michael S. Tsirkin, Jason Wang, Eric W. Biederman,
Ian Campbell, netdev, linux-kernel, ldv-project
In this case it is not an error. rcu_dereference
occurs in update section. Replacement by
rcu_dereference_protected (with spinlock) in order to
prevent lockdep complaint.
Found by Linux Driver Verification project (linuxtesting.org)
Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
---
drivers/net/macvtap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 0737bd4..8ef11a8 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -94,7 +94,8 @@ static int get_slot(struct macvlan_dev *vlan, struct macvtap_queue *q)
int i;
for (i = 0; i < MAX_MACVTAP_QUEUES; i++) {
- if (rcu_dereference(vlan->taps[i]) == q)
+ if (rcu_dereference_protected(vlan->taps[i],
+ lockdep_is_held(&macvtap_lock)) == q)
return i;
}
--
1.7.7
^ permalink raw reply related
* Re: [RFC PATCH 0/2] net: connect to UNIX sockets from specified root
From: Stanislav Kinsbursky @ 2012-08-11 11:15 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: H. Peter Anvin, Alan Cox, J. Bruce Fields,
Trond.Myklebust@netapp.com, davem@davemloft.net,
linux-nfs@vger.kernel.org, eric.dumazet@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, tim.c.chen@linux.intel.com,
devel@openvz.org
In-Reply-To: <5025FA5A.4090403@parallels.com>
11.08.2012 10:23, Pavel Emelyanov пишет:
> On 08/11/2012 03:09 AM, H. Peter Anvin wrote:
>> On 08/10/2012 12:28 PM, Alan Cox wrote:
>>> Explicitly for Linux yes - this is not generally true of the AF_UNIX
>>> socket domain and even the permissions aspect isn't guaranteed to be
>>> supported on some BSD environments !
>> Yes, but let's worry about what the Linux behavior should be.
>>
>>> The name is however just a proxy for the socket itself. You don't even
>>> get a device node in the usual sense or the same inode in the file system
>>> space.
>>
>> No, but it is looked up the same way any other inode is (the difference
>> between FIFOs and sockets is that sockets have separate connections,
>> which is also why open() on sockets would be nice.)
>>
>> However, there is a fundamental difference between AF_UNIX sockets and
>> open(), and that is how the pathname is delivered. It thus would make
>> more sense to provide the openat()-like information in struct
>> sockaddr_un, but that may be very hard to do in a sensible way. In that
>> sense it perhaps would be cleaner to be able to do an open[at]() on the
>> socket node with O_PATH (perhaps there should be an O_SOCKET option,
>> even?) and pass the resulting file descriptor to bind() or connect().
> I vote for this (openat + O_WHATEVER on a unix socket) as well. It will
> help us in checkpoint-restore, making handling of overmounted/unlinked
> sockets much cleaner.
I have to notice, that it's not enough and doesn't solve the issue.
There should be some way how to connect/bind already existent unix
socket (from kernel, at least), because socket can be created in user space.
And this way (sock operation or whatever) have to provide an ability to
lookup UNIX socket starting from specified root to support containers.
>
>> -hpa
> Thanks,
> Pavel
>
^ permalink raw reply
* hello
From: sani @ 2012-08-11 16:55 UTC (permalink / raw)
Dear,
I apologized, If this mail finds you disturbing,my name is Miss awa sani.I
am contacting you for the investment purposes. I am available as needed to
discuss this further with you at any time. Please let me know how you
wish to proceed.
I look forward to hearing from you soon.
Thanks
awa
^ permalink raw reply
* Fw: [Bug 45681] New: no network to ip phones
From: Stephen Hemminger @ 2012-08-11 18:06 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 7 Aug 2012 05:02:58 +0000 (UTC)
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 45681] New: no network to ip phones
https://bugzilla.kernel.org/show_bug.cgi?id=45681
Summary: no network to ip phones
Product: Networking
Version: 2.5
Kernel Version: 3.0.39
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: slesru@gmail.com
Regression: No
Hello!
I run asterisk on x86 server , with kernel 2.6.39 all is OK, but with 3.0.38
and 3.0.39 after some time server lost connections to sip phones:
[Aug 2 15:02:51] WARNING[5790]: chan_sip.c:3392 __sip_xmit: sip_xmit of
0x9bd88f8 (len 548) to 192.168.26.116:5060 returned -2: Network is down
ping says the same, but other hosts work OK (from any other networks), only sip
phones are affected.
interfaces:
[root@asterisk ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:85:5B:0A
inet addr:192.168.22.19 Bcast:192.168.22.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe85:5b0a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:61867 errors:0 dropped:666 overruns:0 frame:0
TX packets:25992 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7013187 (6.6 MiB) TX bytes:3754003 (3.5 MiB)
eth0.9 Link encap:Ethernet HWaddr 00:30:48:85:5B:0A
inet addr:192.168.42.132 Bcast:192.168.42.255 Mask:255.255.255.128
inet6 addr: fe80::230:48ff:fe85:5b0a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11634 errors:0 dropped:0 overruns:0 frame:0
TX packets:10753 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2407018 (2.2 MiB) TX bytes:2439435 (2.3 MiB)
default gateway is on eth0, i.e. not tagged.
hardware:
[root@asterisk ~]# /sbin/lspci -nn | grep -i net
01:01.0 Ethernet controller [0200]: Intel Corporation 82547GI Gigabit Ethernet
Controller [8086:1075]
02:01.0 Ethernet controller [0200]: Digium, Inc. Wildcard TE122 single-span
T1/E1/J1 card [d161:8001] (rev 11)
03:0a.0 Ethernet controller [0200]: Intel Corporation 82541GI Gigabit Ethernet
Controller [8086:1076]
I use elrepo kernel build, here is there bug report:
http://elrepo.org/bugs/view.php?id=294
I have no idea what can cause this problem :-(
Thank you!
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 8/8] bridge: use list_for_each_entry() in netpoll functions
From: Stephen Hemminger @ 2012-08-11 18:07 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev
In-Reply-To: <1344263012-4031-9-git-send-email-amwang@redhat.com>
On Mon, 6 Aug 2012 22:23:32 +0800
Cong Wang <amwang@redhat.com> wrote:
> We don't delete 'p' from the list in the loop,
> so we can just use list_for_each_entry().
>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Good idea.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Fw: [Bug 45571] New: The kernel disallows to reuse sockets which have TIME_WAIT pending connections
From: Stephen Hemminger @ 2012-08-11 18:09 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sat, 4 Aug 2012 11:13:11 +0000 (UTC)
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 45571] New: The kernel disallows to reuse sockets which have TIME_WAIT pending connections
https://bugzilla.kernel.org/show_bug.cgi?id=45571
Summary: The kernel disallows to reuse sockets which have
TIME_WAIT pending connections
Product: Networking
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: t.artem@mailcity.com
Regression: No
This is a follow up of the following bug report:
http://bugs.winehq.org/show_bug.cgi?id=26031
It's not Wine's problem, as it can be easily reproduced with native Linux
applications.
Bruno Jesus 2011-11-10 21:35:54 CST wrote:
> Well, after reading a lot of internet pages and trying several different
> attempts I think it's possible to say that it's a kernel bug or a
> characteristic of the kernel tcp implementation.
>
> The attached patch forces SO_REUSEADDR in before every bind in an attempt to
> fix the problem but it only works if the program exits cleanly (so the kernel
> sets the socket to TIME_WAIT), if you do "wineserver -k" the socket will remain
> opened in an unknow broken state and no applications will be able to use it
> (wine or native linux apps).
>
> Output of strace:
> getsockopt(24, SOL_SOCKET, SO_REUSEADDR, [0], [4]) = 0
> setsockopt(24, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(24, {sa_family=AF_INET, sin_port=htons(43012), sin_addr=inet_addr("0.
> 0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>
> It's possible to see that I'm checking if SO_REUSEADDR is enabled and then
> enable it. But the bind fails anyway.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: TCP stalls with 802.3ad + bridge + kvm guest
From: Stephen Hemminger @ 2012-08-11 18:28 UTC (permalink / raw)
To: Peter Samuelson; +Cc: Jesse Brandeburg, Jay Vosburgh, netdev, jgoerzen
In-Reply-To: <20120804224511.GU17572@p12n.org>
On Sat, 4 Aug 2012 17:45:11 -0500
Peter Samuelson <psamuelson@efolder.net> wrote:
>
> > [Jesse Brandeburg]
> > > try
> > > # ethtool -K ethx tso off gso off lro off
>
> Specifically, 'lro off' is the trick. The others don't have a
> noticeable effect. Now I can get 70 MB/s or better most of the time,
> in either direction.
>
> Thanks again,
> Peter
When device is added to bridge, the bridge code does ask the device
to turn LRO off (automatically). Unfortunately some device drivers are
broken.
^ permalink raw reply
* [PATCH v2 01/15] net: proc entry showing inodes on sockfs and their types
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
I've worked on improving lsof output on linux both lsof and linux
sides. Sometimes lsof cannot resolve socket descriptors and as the
result it prints them like:
[yamato@localhost]/tmp% sudo lsof | grep dbus | grep iden
dbus-daem 652 dbus 6u sock ... 17812 can't identify protocol
dbus-daem 652 dbus 34u sock ... 24689 can't identify protocol
dbus-daem 652 dbus 42u sock ... 24739 can't identify protocol
dbus-daem 652 dbus 48u sock ... 22329 can't identify protocol
...
lsof refers /proc/net/PROTOCOL files to solve the type of socket for
given socket descriptor. lsof looks up inode column of the files.
lsof cannot resolve the type if there is no PROTOCOL file for PROTOCOL
for the given socket descriptor nor there is PROTOCOL file with no
inode column.
About kernel side, bluetooth protocol families didn't have their own
PROTOCOL files. So I added them. netlink protocol had its own PROTOCOL
file but no inode column. So I added the column to it.
About lsof side, I added code to refer /proc/net/netlink to lsof. I
added code to refer /proc/net/icmp to lsof. I have to added code to
refer /proc/net/PROTOCOL files for bluetooth protocol families.
However, it is far from complete.
$ grep -r '^\(static \)*struct proto ' | wc -l
60
It is difficult for me to deal such many protocols. During working on
improving, newer protocol may be implemented. Further more subsystem
mariners don't want to add inode column to /proc/net/PROTOCOL file for
avoiding file format incompatibility.
This patch introduces /proc/net/sockfs, which shows most of all inodes
on sockfs and their socket type. A socket newly associated with socket
descriptor in kernel is stored to a list named
`proc_sockfs_list'. /proc/net/sockfs shows the element of the list.
If a protocol has its own lsof friendly proc entry, a socket of the
protocol should not be stored to `proc_sockfs_list'; lsof can solve
the socket type via protocol the proc entry. A protocol can declare it
has own proc entry with `has_own_proc_entry' field in struct proto.
If the field is non-zero, the socket of the protocol is never added to
`proc_sockfs_list'.
In v2 patch, unnecessary CONFIG_PROC_FS ifdefs are removed as suggested
by Alan Cox. The patches are rebased to net-next.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
include/linux/net.h | 8 +++
include/net/sock.h | 3 +
net/socket.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 178 insertions(+), 2 deletions(-)
diff --git a/include/linux/net.h b/include/linux/net.h
index 99276c3..c87acff 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -61,6 +61,9 @@ typedef enum {
#include <linux/fcntl.h> /* For O_CLOEXEC and O_NONBLOCK */
#include <linux/kmemcheck.h>
#include <linux/rcupdate.h>
+#ifdef CONFIG_PROC_FS
+#include <linux/list.h>
+#endif
struct poll_table_struct;
struct pipe_inode_info;
@@ -135,6 +138,7 @@ struct socket_wq {
* @file: File back pointer for gc
* @sk: internal networking protocol agnostic socket representation
* @wq: wait queue for several uses
+ * @proc_sockfs_list: list head to link this socket to /proc/net/sockfs
*/
struct socket {
socket_state state;
@@ -150,6 +154,10 @@ struct socket {
struct file *file;
struct sock *sk;
const struct proto_ops *ops;
+
+#ifdef CONFIG_PROC_FS
+ struct list_head proc_sockfs_list;
+#endif
};
struct vm_area_struct;
diff --git a/include/net/sock.h b/include/net/sock.h
index 72132ae..af37a1e 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -955,6 +955,9 @@ struct proto {
void (*destroy_cgroup)(struct mem_cgroup *memcg);
struct cg_proto *(*proto_cgroup)(struct mem_cgroup *memcg);
#endif
+ /* Set non-zero value if this protocol manages its
+ own /proc/net/PROTOCOL entry and the entry has inode column. */
+ int has_own_proc_entry;
};
/*
diff --git a/net/socket.c b/net/socket.c
index dfe5b66..5f4f228 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -104,6 +104,7 @@
#include <linux/route.h>
#include <linux/sockios.h>
#include <linux/atalk.h>
+#include <linux/rwlock_types.h>
static int sock_no_open(struct inode *irrelevant, struct file *dontcare);
static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
@@ -127,6 +128,10 @@ static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
struct pipe_inode_info *pipe, size_t len,
unsigned int flags);
+static int proc_sockfs_init(void);
+static void proc_sockfs_add(struct socket *sock);
+static void proc_sockfs_remove(struct socket *sock);
+
/*
* Socket files have a set of 'special' operations as well as the generic file ones. These don't appear
* in the operation structures but are done directly via the socketcall() multiplexor.
@@ -259,6 +264,7 @@ static struct inode *sock_alloc_inode(struct super_block *sb)
ei->socket.ops = NULL;
ei->socket.sk = NULL;
ei->socket.file = NULL;
+ INIT_LIST_HEAD(&ei->socket.proc_sockfs_list);
return &ei->vfs_inode;
}
@@ -391,8 +397,10 @@ int sock_map_fd(struct socket *sock, int flags)
struct file *newfile;
int fd = sock_alloc_file(sock, &newfile, flags);
- if (likely(fd >= 0))
+ if (likely(fd >= 0)) {
fd_install(fd, newfile);
+ proc_sockfs_add(sock);
+ }
return fd;
}
@@ -512,9 +520,15 @@ const struct file_operations bad_sock_fops = {
void sock_release(struct socket *sock)
{
+ int externally_allocated = test_bit(SOCK_EXTERNALLY_ALLOCATED,
+ &sock->flags);
+
if (sock->ops) {
struct module *owner = sock->ops->owner;
+ if (!externally_allocated)
+ proc_sockfs_remove(sock);
+
sock->ops->release(sock);
sock->ops = NULL;
module_put(owner);
@@ -523,7 +537,7 @@ void sock_release(struct socket *sock)
if (rcu_dereference_protected(sock->wq, 1)->fasync_list)
printk(KERN_ERR "sock_release: fasync list not empty!\n");
- if (test_bit(SOCK_EXTERNALLY_ALLOCATED, &sock->flags))
+ if (externally_allocated)
return;
this_cpu_sub(sockets_in_use, 1);
@@ -1411,7 +1425,9 @@ SYSCALL_DEFINE4(socketpair, int, family, int, type, int, protocol,
audit_fd_pair(fd1, fd2);
fd_install(fd1, newfile1);
+ proc_sockfs_add(sock1);
fd_install(fd2, newfile2);
+ proc_sockfs_add(sock2);
/* fd1 and fd2 may be already another descriptors.
* Not kernel problem.
*/
@@ -1566,6 +1582,7 @@ SYSCALL_DEFINE4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr,
/* File flags are not inherited via accept() unlike another OSes. */
fd_install(newfd, newfile);
+ proc_sockfs_add(newsock);
err = newfd;
out_put:
@@ -2552,6 +2569,9 @@ static int __init sock_init(void)
err = PTR_ERR(sock_mnt);
goto out_mount;
}
+ err = proc_sockfs_init();
+ if (err)
+ goto out_proc_socfs;
/* The real protocol initialization is performed in later initcalls.
*/
@@ -2567,6 +2587,8 @@ static int __init sock_init(void)
out:
return err;
+out_proc_socfs:
+ kern_unmount(sock_mnt);
out_mount:
unregister_filesystem(&sock_fs_type);
out_fs:
@@ -3380,3 +3402,146 @@ int kernel_sock_shutdown(struct socket *sock, enum sock_shutdown_cmd how)
return sock->ops->shutdown(sock, how);
}
EXPORT_SYMBOL(kernel_sock_shutdown);
+
+#ifdef CONFIG_PROC_FS
+static LIST_HEAD(proc_sockfs_list);
+static DEFINE_RWLOCK(proc_sockfs_lock);
+
+static void proc_sockfs_add(struct socket *sock)
+{
+ struct sock *sk = sock->sk;
+
+ if (!sk->sk_prot_creator->has_own_proc_entry) {
+ write_lock(&proc_sockfs_lock);
+ list_add_tail(&sock->proc_sockfs_list, &proc_sockfs_list);
+ write_unlock(&proc_sockfs_lock);
+ }
+}
+
+static void proc_sockfs_remove(struct socket *sock)
+{
+ struct sock *sk = sock->sk;
+
+ if (!sk)
+ return;
+
+ if (!sk->sk_prot_creator->has_own_proc_entry) {
+ if (!list_empty(&sock->proc_sockfs_list)) {
+ write_lock(&proc_sockfs_lock);
+ list_del_init(&sock->proc_sockfs_list);
+ write_unlock(&proc_sockfs_lock);
+ }
+ }
+}
+
+static void *proc_sockfs_seq_start(struct seq_file *seq, loff_t *pos)
+ __acquires(&proc_sockfs_lock)
+{
+ read_lock(&proc_sockfs_lock);
+ return seq_list_start_head(&proc_sockfs_list, *pos);
+}
+
+static void *proc_sockfs_seq_next(struct seq_file *seq, void *v, loff_t *pos)
+{
+ return seq_list_next(v, &proc_sockfs_list, pos);
+}
+
+static void proc_sockfs_seq_stop(struct seq_file *seq, void *v)
+ __releases(&proc_sockfs_lock)
+{
+ read_unlock(&proc_sockfs_lock);
+}
+
+static int proc_sockfs_seq_show_header(struct seq_file *seq)
+{
+ return seq_printf(seq, "Inode name state family type protocol socket net\n");
+}
+
+static int proc_sockfs_seq_show_socket(struct seq_file *seq, struct socket *sock)
+{
+ struct sock *sk;
+ const char *name;
+
+ sk = sock->sk;
+ BUG_ON(sk == NULL);
+
+ name = sk->sk_prot_creator->name;
+ if (name == NULL || name[0] == '\0')
+ name = "UNKNOWN";
+
+ return seq_printf(seq, "%20lu %-8s %5d %6d %4d %8d %p %p\n",
+ sock_i_ino(sk),
+ name,
+ sock->state,
+ sk->sk_family,
+ sock->type,
+ sk->sk_protocol,
+ sock,
+ sock_net(sk));
+}
+
+static int proc_sockfs_seq_show(struct seq_file *seq, void *v)
+{
+ if (v == &proc_sockfs_list)
+ proc_sockfs_seq_show_header(seq);
+ else {
+ struct socket *sock = list_entry(v, struct socket, proc_sockfs_list);
+ proc_sockfs_seq_show_socket(seq, sock);
+ }
+
+ return 0;
+}
+
+static const struct seq_operations proc_sockfs_seq_ops = {
+ .start = proc_sockfs_seq_start,
+ .next = proc_sockfs_seq_next,
+ .stop = proc_sockfs_seq_stop,
+ .show = proc_sockfs_seq_show,
+};
+
+static int proc_sockfs_seq_open(struct inode *inode, struct file *file)
+{
+ return seq_open(file, &proc_sockfs_seq_ops);
+}
+
+static const struct file_operations proc_sockfs_seq_fops = {
+ .owner = THIS_MODULE,
+ .open = proc_sockfs_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+static __net_init int proc_sockfs_init_net(struct net *net)
+{
+ if (!proc_net_fops_create(net, "sockfs", S_IRUGO, &proc_sockfs_seq_fops))
+ return -ENOMEM;
+ return 0;
+}
+
+static __net_exit void proc_sockfs_exit_net(struct net *net)
+{
+ proc_net_remove(net, "sockfs");
+}
+
+static __net_initdata struct pernet_operations proc_sockfs_ops = {
+ .init = proc_sockfs_init_net,
+ .exit = proc_sockfs_exit_net,
+};
+
+static int proc_sockfs_init(void)
+{
+ return register_pernet_subsys(&proc_sockfs_ops);
+}
+#else
+static int proc_sockfs_init(void)
+{
+ return 0;
+}
+static void proc_sockfs_add(struct socket *sock)
+{
+}
+static void proc_sockfs_remove(struct socket *sock)
+{
+}
+#endif /* CONFIG_PROC_FS */
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 03/15] ipv4: declaring icmp protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring icmp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/ping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 6232d47..c4bb504 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -748,6 +748,7 @@ struct proto ping_prot = {
.unhash = ping_v4_unhash,
.get_port = ping_v4_get_port,
.obj_size = sizeof(struct inet_sock),
+ .has_own_proc_entry= 1,
};
EXPORT_SYMBOL(ping_prot);
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 05/15] ipv4: declaring raw protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring raw protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/raw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index ff0f071..3980a4a 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -901,6 +901,7 @@ struct proto raw_prot = {
.compat_getsockopt = compat_raw_getsockopt,
.compat_ioctl = compat_raw_ioctl,
#endif
+ .has_own_proc_entry= 1,
};
#ifdef CONFIG_PROC_FS
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 06/15] ipv4: declaring tcp protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring tcp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/ipv4/tcp_ipv4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index c660d2c..6f36929 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2635,6 +2635,7 @@ struct proto tcp_prot = {
.destroy_cgroup = tcp_destroy_cgroup,
.proto_cgroup = tcp_proto_cgroup,
#endif
+ .has_own_proc_entry= 1,
};
EXPORT_SYMBOL(tcp_prot);
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 07/15] packet: declaring packet protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring packet protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/packet/af_packet.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ceaca7c..6a0e47c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2564,6 +2564,7 @@ static struct proto packet_proto = {
.name = "PACKET",
.owner = THIS_MODULE,
.obj_size = sizeof(struct packet_sock),
+ .has_own_proc_entry= 1,
};
/*
--
1.7.11.2
^ permalink raw reply related
* [PATCH v2 08/15] unix: declaring unix protocols has its own proc entry
From: Masatake YAMATO @ 2012-08-11 20:07 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Masatake YAMATO
In-Reply-To: <1344715638-22997-1-git-send-email-yamato@redhat.com>
Declaring unix protocols has its own proc entry.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
net/unix/af_unix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index e4768c1..7f109e6 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -616,6 +616,7 @@ static struct proto unix_proto = {
.name = "UNIX",
.owner = THIS_MODULE,
.obj_size = sizeof(struct unix_sock),
+ .has_own_proc_entry= 1,
};
/*
--
1.7.11.2
^ permalink raw reply related
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