* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Américo Wang @ 2010-12-09 16:47 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Florian Mickler, Ingo Molnar, Américo Wang, Dave Chinner,
Eric Dumazet, linux-kernel, netdev
In-Reply-To: <20101208140822.GA18681@redhat.com>
On Wed, Dec 08, 2010 at 03:08:22PM +0100, Oleg Nesterov wrote:
>On 12/08, Oleg Nesterov wrote:
>>
>> On 12/08, Oleg Nesterov wrote:
>> >
>> > On 12/08, Florian Mickler wrote:
>> > >
>> > > [ ccing Ingo and Oleg ] as suggested
>> >
>> > Well. Of course I can't explain this bug. But, looking at this email
>> > I do not see amything strange in exit/schedule/etc.
>> >
>> > > > >> > > > This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
>> > > > >> > > >
>> > > > >> > > > root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
>> > > > >> > > > root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
>> > > > >> > > > root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
>> >
>> > That is. ip is a zombie.
>>
>> And. I do not know if this matters or not, but "the command 'ip link
>> set tap0 up' hanging as a zombie" does not look right.
>>
>> This was spawned by
>>
>> > >> > > > if [ -n "$1" ];then
>> > >> > > > /usr/bin/sudo /sbin/ip link set $1 up
>> > >> > > > sleep 0.5s
>> > >> > > > /usr/bin/sudo /usr/sbin/brctl addif $switch $1
>> > >> > > > exit 0
>> > >> > > > fi
>>
>> The command does not hang. But it forks the child with pid == 3012,
>> this child exits.
>
>Damn, sorry for noise, forgot to mention...
>
>The parent's trace (pid == 3011) can be more useful. Say, if it
>hangs in do_wait(), then the kernel is obviously wrong.
>
Yeah, there is no point that a zombie can trigger a BUG_ON in kenrel.
But it is still interesting to know why it becomes a zombie...
^ permalink raw reply
* Re: rndis gadget: Inconsistent locking
From: Neil Jones @ 2010-12-09 17:00 UTC (permalink / raw)
To: Michał Nazarewicz; +Cc: linux-usb, netdev
In-Reply-To: <op.vnenkvz67p4s8u@pikus>
> Does this help: <https://patchwork.kernel.org/patch/195562/>?
Yes cheers, warning gone and driver seems fine so far.
has this been accepted upstream ?
Neil
2010/12/8 Michał Nazarewicz <m.nazarewicz@samsung.com>:
> On Wed, 08 Dec 2010 16:11:30 +0100, Neil Jones <neiljay@gmail.com> wrote:
>>
>> Im getting another lockdep warning when using the RNDIS gadget:
>>
>> WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
>> Modules linked in: g_ether
>>
>> Call trace:
>> [<40003bf8>] _show_stack+0x68/0x7c
>> [<40003c20>] _dump_stack+0x14/0x28
>> [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
>> [<40013c74>] _warn_slowpath_null+0x18/0x2c
>> [<4001b17c>] ___local_bh_disable+0xc0/0xd0
>> [<4001b1a0>] _local_bh_disable+0x14/0x28
>> [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
>> [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
>> [<402580c4>] _dev_get_stats+0xb8/0xc0
>> [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
>> [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
>> [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
>> [<401d928c>] _ep0_complete_request+0x3f4/0x578
>> [<401d95bc>] _handle_ep0+0x1ac/0x146c
>> [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
>> [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
>> [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
>> [<40054cf4>] _handle_IRQ_event+0x4c/0x184
>> [<40057b4c>] _handle_level_irq+0xac/0x15c
>> [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
>> [<40002dd4>] _do_IRQ+0x4c/0x78
>> [<40004000>] _trigger_handler+0x38/0xac
>> [<40000b18>] ___TBIBoingVec+0xc/0x10
>> [<40003588>] _cpu_idle+0x54/0x78
>>
>> no locks held by swapper/0.
>> ---[ end trace 77ac3cfee0ae5b25 ]---
>
> Known problem.
>
>> It looks like we are calling spin_lock_bh in the completion function
>> which is running in hard_irq, I think the driver should defer handling
>> this msg (and maybe all requests) to a workqueue?
>
> Does this help: <https://patchwork.kernel.org/patch/195562/>?
>
> --
> Best regards, _ _
> | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
> | Computer Science, Michał "mina86" Nazarewicz (o o)
> +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
>
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Eric Dumazet @ 2010-12-09 17:07 UTC (permalink / raw)
To: Américo Wang
Cc: Oleg Nesterov, Florian Mickler, Ingo Molnar, Dave Chinner,
linux-kernel, netdev
In-Reply-To: <20101209164748.GA3218@hack>
Le vendredi 10 décembre 2010 à 00:47 +0800, Américo Wang a écrit :
> Yeah, there is no point that a zombie can trigger a BUG_ON in kenrel.
> But it is still interesting to know why it becomes a zombie...
>
A zombie is very easy to get.
Technically speaking, all processes die and become zombies, unless
parent said : signal(SIGCLD, SIG_IGN) before fork()
The parent is buggy (sudo in this case ?) and doesnt call wait() to
'free' one of its children.
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Eric Dumazet @ 2010-12-09 17:09 UTC (permalink / raw)
To: Américo Wang
Cc: Oleg Nesterov, Florian Mickler, Ingo Molnar, Dave Chinner,
linux-kernel, netdev
In-Reply-To: <1291914474.4063.68.camel@edumazet-laptop>
Le jeudi 09 décembre 2010 à 18:07 +0100, Eric Dumazet a écrit :
> Le vendredi 10 décembre 2010 à 00:47 +0800, Américo Wang a écrit :
>
> > Yeah, there is no point that a zombie can trigger a BUG_ON in kenrel.
> > But it is still interesting to know why it becomes a zombie...
> >
>
> A zombie is very easy to get.
>
> Technically speaking, all processes die and become zombies, unless
> parent said : signal(SIGCLD, SIG_IGN) before fork()
>
> The parent is buggy (sudo in this case ?) and doesnt call wait() to
> 'free' one of its children.
>
>
Before you ask :)
If the parent dies before the child, task is re-parented to init.
Then, with namespaces, I dont know what happens (is there one init per
namespace ?)
^ permalink raw reply
* [PATCH] Sysctl interface to UNIX_INFLIGHT_TRIGGER_GC v.2
From: Pavel Vasilyev @ 2010-12-09 17:26 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 77 bytes --]
Sysctl interface to UNIX_INFLIGHT_TRIGGER_GC.
IMHO convenient for testing.
[-- Attachment #2: sysctl.inflight_trigger_gc.patch --]
[-- Type: text/x-patch, Size: 2797 bytes --]
Documentation/networking/ip-sysctl.txt | 4 ++++
include/net/af_unix.h | 1 +
net/unix/garbage.c | 5 ++---
net/unix/sysctl_net_unix.c | 9 +++++++++
4 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 3c5e465..11e6adf 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1463,6 +1463,10 @@ max_dgram_qlen - INTEGER
Default: 10
+inflight_trigger_gc - INTEGER
+ The maximal number of inflight sockets for force garbage collect.
+
+ Default: 16000
UNDOCUMENTED:
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 18e5c3f..ea580e4 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -15,6 +15,7 @@ extern struct sock *unix_get_socket(struct file *filp);
#define UNIX_HASH_SIZE 256
extern unsigned int unix_tot_inflight;
+extern unsigned int sysctl_inflight_trigger_gc;
struct unix_address {
atomic_t refcnt;
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index f89f83b..c646c6b 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -94,7 +94,7 @@ static DEFINE_SPINLOCK(unix_gc_lock);
static DECLARE_WAIT_QUEUE_HEAD(unix_gc_wait);
unsigned int unix_tot_inflight;
-
+unsigned int sysctl_inflight_trigger_gc = 16000;
struct sock *unix_get_socket(struct file *filp)
{
@@ -259,7 +259,6 @@ static void inc_inflight_move_tail(struct unix_sock *u)
}
static bool gc_in_progress = false;
-#define UNIX_INFLIGHT_TRIGGER_GC 16000
void wait_for_unix_gc(void)
{
@@ -267,7 +266,7 @@ void wait_for_unix_gc(void)
* If number of inflight sockets is insane,
* force a garbage collect right now.
*/
- if (unix_tot_inflight > UNIX_INFLIGHT_TRIGGER_GC && !gc_in_progress)
+ if (unix_tot_inflight > sysctl_inflight_trigger_gc && !gc_in_progress)
unix_gc();
wait_event(unix_gc_wait, gc_in_progress == false);
}
diff --git a/net/unix/sysctl_net_unix.c b/net/unix/sysctl_net_unix.c
index 397cffe..c807235 100644
--- a/net/unix/sysctl_net_unix.c
+++ b/net/unix/sysctl_net_unix.c
@@ -23,6 +23,13 @@ static ctl_table unix_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "inflight_trigger_gc",
+ .data = &sysctl_inflight_trigger_gc,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
{ }
};
@@ -41,6 +48,8 @@ int __net_init unix_sysctl_register(struct net *net)
goto err_alloc;
table[0].data = &net->unx.sysctl_max_dgram_qlen;
+ table[1].data = &sysctl_inflight_trigger_gc;
+
net->unx.ctl = register_net_sysctl_table(net, unix_path, table);
if (net->unx.ctl == NULL)
goto err_reg;
---
Signed-off-by: Pavel Vasilyev <pavel@pavlinux.ru>
^ permalink raw reply related
* [PATCH] connector: add module alias
From: Stephen Hemminger @ 2010-12-09 17:36 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev
Since connector can be built as a module and uses netlink socket
to communicate. The module should have an alias to autoload when socket
of NETLINK_CONNECTOR type is requested.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/connector/connector.c 2010-12-09 09:19:05.549120343 -0800
+++ b/drivers/connector/connector.c 2010-12-09 09:19:52.795051458 -0800
@@ -36,6 +36,7 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Evgeniy Polyakov <zbr@ioremap.net>");
MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector.");
+MODULE_ALIAS_NET_PF_PROTO(PF_NETLINK, NETLINK_CONNECTOR);
static struct cn_dev cdev;
^ permalink raw reply
* Re: [Bugme-new] [Bug 24472] New: Kernel panic - not syncing: Fatal Exception
From: Jarek Poplawski @ 2010-12-09 17:55 UTC (permalink / raw)
To: Paweł Staszewski
Cc: Andrew Morton, netdev, Paul Mackerras, bugzilla-daemon,
bugme-daemon, pstaszewski, Andrej Ota, Eric Dumazet
In-Reply-To: <4D00CE33.8040006@itcare.pl>
Paweł Staszewski wrote:
> W dniu 2010-12-08 23:01, Jarek Poplawski pisze:
>> Paweł Staszewski wrote:
>>> W dniu 2010-12-08 21:22, Andrew Morton pisze:
>>>> (switched to email. Please respond via emailed reply-to-all, not
>>>> via the
>>>> bugzilla web interface).
>>>>
>>>> On Wed, 8 Dec 2010 20:14:45 GMT
>>>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>>>
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=24472
>>>>>
>>>>> Summary: Kernel panic - not syncing: Fatal Exception
>>>>> Product: Drivers
>>>>> Version: 2.5
>>>>> Kernel Version: 2.6.36.1
>> Hi,
>> Could you try to revert this patch?:
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commitdiff;h=55c95e738da85373965cb03b4f975d0fd559865b
>>
>>
> After reverting this patch all is working
> 200 connects-disconnects and no kernel panic
>
> I will make more session and test more.
OK. I CC Andrej and Eric, who diagnosed it in this thread:
http://lkml.org/lkml/2010/12/3/116
[unable to handle kernel NULL pointer dereference in skb_dequeue]
This should be also interesting:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=db7bf6d97c6956b7eb0f22131cb5c37bd41f33c0
Thanks for testing,
Jarek P.
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Jim Bos @ 2010-12-09 17:59 UTC (permalink / raw)
To: Américo Wang
Cc: Oleg Nesterov, Florian Mickler, Ingo Molnar, Dave Chinner,
Eric Dumazet, linux-kernel, netdev
In-Reply-To: <20101209164748.GA3218@hack>
On 12/09/2010 05:47 PM, Américo Wang wrote:
> On Wed, Dec 08, 2010 at 03:08:22PM +0100, Oleg Nesterov wrote:
>> On 12/08, Oleg Nesterov wrote:
>>>
>>> On 12/08, Oleg Nesterov wrote:
>>>>
>>>> On 12/08, Florian Mickler wrote:
>>>>>
>>>>> [ ccing Ingo and Oleg ] as suggested
>>>>
>>>> Well. Of course I can't explain this bug. But, looking at this email
>>>> I do not see amything strange in exit/schedule/etc.
>>>>
>>>>>>>>>>> This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
>>>>>>>>>>>
>>>>>>>>>>> root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
>>>>>>>>>>> root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
>>>>>>>>>>> root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
>>>>
>>>> That is. ip is a zombie.
>>>
>>> And. I do not know if this matters or not, but "the command 'ip link
>>> set tap0 up' hanging as a zombie" does not look right.
>>>
>>> This was spawned by
>>>
>>>>>>>>> if [ -n "$1" ];then
>>>>>>>>> /usr/bin/sudo /sbin/ip link set $1 up
>>>>>>>>> sleep 0.5s
>>>>>>>>> /usr/bin/sudo /usr/sbin/brctl addif $switch $1
>>>>>>>>> exit 0
>>>>>>>>> fi
>>>
>>> The command does not hang. But it forks the child with pid == 3012,
>>> this child exits.
>>
>> Damn, sorry for noise, forgot to mention...
>>
>> The parent's trace (pid == 3011) can be more useful. Say, if it
>> hangs in do_wait(), then the kernel is obviously wrong.
>>
>
> Yeah, there is no point that a zombie can trigger a BUG_ON in kenrel.
> But it is still interesting to know why it becomes a zombie...
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
ip link tap0 up not working might be this issue:
http://marc.info/?l=linux-netdev&m=128783852132311&w=2
( Latest Virtualbox 3.2.12 works around this issue )
Jim
^ permalink raw reply
* Re: Behaviour of ETHTOOL_GLINK for an interface that's down
From: Ben Hutchings @ 2010-12-09 18:05 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev, sf-linux-drivers
In-Reply-To: <1291874559.24551.10.camel@dcbw.foobar.com>
On Thu, 2010-12-09 at 00:02 -0600, Dan Williams wrote:
> On Wed, 2010-12-08 at 23:47 -0600, Dan Williams wrote:
> > On Mon, 2010-12-06 at 21:59 +0000, Ben Hutchings wrote:
> > > ETHTOOL_GLINK is yet another ethtool operation that has unclear
> > > semantics that results in differing behaviour when the interface is
> > > down.
[...]
> > > DaveM said that Network Manager may require (2), although I don't think
> > > this is correct. At least the current version brings all managed
> > > interfaces up whether or not they have link-up already.
> >
> > NM has used netlink + IFF_RUNNING (not ethtool) for a few years for
> > actual carrier detection. Ethtool (and MII ioctls) are called as a
> > "best effort" method of determining that the device actually *has*
> > carrier detection at all, since if the device has gone to the trouble to
> > implement either MII or ethtool, it probably also has carrier detection.
> >
> > But ethtool isn't actually used to determine carrier status in NM. It's
> > netlink all the way down.
>
> And as a follow-on, yes, NM does bring all devices it is allowed to
> manager IFF_UP because that's the only way (at this point) that we can
> guarantee functional carrier detect from the card. I'd love it if that
> weren't the case, and if we could have some indicator that the driver
> could do carrier detect while in a lower-power state and !IFF_UP, but we
> don't have that yet.
Thanks for the information, Dan. Presumably it would actually be
sufficient for NM's requirements to implement 'energy detect' which some
PHYs can do even in a low power state? (Though I wonder whether that
works between two PHYs both in a low power state.) You could then use
this as a trigger to bring the interface up, while still relying on the
existing link change notification to trigger interface configuration.
But this clearly has to be separate from ETHTOOL_GLINK, not least
because you want notification rather than having to poll.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [stable] [STABLE 2.6.32 PATCH] net: release dst entry while cache-hot for GSO case too
From: Greg KH @ 2010-12-09 18:19 UTC (permalink / raw)
To: avagin@gmail.com
Cc: Greg Kroah-Hartman, krkumar2, avagin, eric.dumazet, netdev, mjt,
David Miller, stable
In-Reply-To: <4D007A77.8050102@gmail.com>
On Thu, Dec 09, 2010 at 09:43:03AM +0300, avagin@gmail.com wrote:
> I add the patch in attachments
Ok, thanks, I'll queue it up for the next .32 release after this one.
greg k-h
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: David Miller @ 2010-12-09 18:29 UTC (permalink / raw)
To: bhutchings; +Cc: srk, netdev
In-Reply-To: <1291906948.19763.16.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 09 Dec 2010 15:02:28 +0000
> So you really have no choice - you must implement hardware checksum
> offload if you want any of the others.
Right, advertising SG support is entirely pointless if you aren't
also advertising HW checksumming support.
^ permalink raw reply
* Re: Behaviour of ETHTOOL_GLINK for an interface that's down
From: Dan Williams @ 2010-12-09 18:29 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, sf-linux-drivers
In-Reply-To: <1291917939.2647.10.camel@bwh-desktop>
On Thu, 2010-12-09 at 18:05 +0000, Ben Hutchings wrote:
> On Thu, 2010-12-09 at 00:02 -0600, Dan Williams wrote:
> > On Wed, 2010-12-08 at 23:47 -0600, Dan Williams wrote:
> > > On Mon, 2010-12-06 at 21:59 +0000, Ben Hutchings wrote:
> > > > ETHTOOL_GLINK is yet another ethtool operation that has unclear
> > > > semantics that results in differing behaviour when the interface is
> > > > down.
> [...]
> > > > DaveM said that Network Manager may require (2), although I don't think
> > > > this is correct. At least the current version brings all managed
> > > > interfaces up whether or not they have link-up already.
> > >
> > > NM has used netlink + IFF_RUNNING (not ethtool) for a few years for
> > > actual carrier detection. Ethtool (and MII ioctls) are called as a
> > > "best effort" method of determining that the device actually *has*
> > > carrier detection at all, since if the device has gone to the trouble to
> > > implement either MII or ethtool, it probably also has carrier detection.
> > >
> > > But ethtool isn't actually used to determine carrier status in NM. It's
> > > netlink all the way down.
> >
> > And as a follow-on, yes, NM does bring all devices it is allowed to
> > manager IFF_UP because that's the only way (at this point) that we can
> > guarantee functional carrier detect from the card. I'd love it if that
> > weren't the case, and if we could have some indicator that the driver
> > could do carrier detect while in a lower-power state and !IFF_UP, but we
> > don't have that yet.
>
> Thanks for the information, Dan. Presumably it would actually be
> sufficient for NM's requirements to implement 'energy detect' which some
> PHYs can do even in a low power state? (Though I wonder whether that
> works between two PHYs both in a low power state.) You could then use
> this as a trigger to bring the interface up, while still relying on the
> existing link change notification to trigger interface configuration.
> But this clearly has to be separate from ETHTOOL_GLINK, not least
> because you want notification rather than having to poll.
+1 to all of that. If that showed up, I'd love to use it for NM.
Dan
^ permalink raw reply
* Re: [PATCH] connector: add module alias
From: Evgeniy Polyakov @ 2010-12-09 18:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem
In-Reply-To: <20101209093646.1b5a6abb@nehalam>
On Thu, Dec 09, 2010 at 09:36:46AM -0800, Stephen Hemminger (shemminger@vyatta.com) wrote:
> Since connector can be built as a module and uses netlink socket
> to communicate. The module should have an alias to autoload when socket
> of NETLINK_CONNECTOR type is requested.
Ack, thank you.
David, please apply.
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/drivers/connector/connector.c 2010-12-09 09:19:05.549120343 -0800
> +++ b/drivers/connector/connector.c 2010-12-09 09:19:52.795051458 -0800
> @@ -36,6 +36,7 @@
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Evgeniy Polyakov <zbr@ioremap.net>");
> MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector.");
> +MODULE_ALIAS_NET_PF_PROTO(PF_NETLINK, NETLINK_CONNECTOR);
>
> static struct cn_dev cdev;
>
--
Evgeniy Polyakov
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: Michał Mirosław @ 2010-12-09 18:47 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Govindarajan, Sriramakrishnan, netdev@vger.kernel.org
In-Reply-To: <1291906948.19763.16.camel@localhost>
2010/12/9 Ben Hutchings <bhutchings@solarflare.com>:
> On Thu, 2010-12-09 at 16:03 +0530, Govindarajan, Sriramakrishnan wrote:
>> Hi
>> We have a NAPI compliant driver(net/drivers/davinci_emac.c), that does
>> well at 10/100Mbps loads. Now the same controller/driver is used for
>> 1000Mbps
>> mode as well, where the CPU gets saturated easily
>>
>> Internally the module supports scatter gather DMA(which is currently not
>> exercised) but there is no HW checksum support.
>>
>> To specifically implement GRO, GSO support would it be sufficient to add
>> SG support to the driver? Are there other means of increasing the throughput
>> and decreasing the CPU loading?
[...]
> On the TX side, NETIF_F_SG means that the stack may include data in the
> skb by reference to arbitrary pages *even if their contents are still
> being changed* (think sendfile()), which means it depends on hardware
> checksum generation.
Isn't that condition too broad? If the data could change after packet
is submitted to the driver then results would be unpredictable and
allow sending wrong data with correct (because hw-calculated)
checksum.
Right now NETIF_F_SG is removed from dev->features by
netdev_fix_features() if no checksum offloads are enabled.
Just an idea: would driver with NETIF_F_SG|NETIF_F_HW_CSUM using
skb_checksum_help() in xmit path work? This would allow to use DMA
scatter-gather without hardware checksumming (and avoid copying the
packet's data before sending).
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: Ben Hutchings @ 2010-12-09 18:58 UTC (permalink / raw)
To: Michał Mirosław
Cc: Govindarajan, Sriramakrishnan, netdev@vger.kernel.org
In-Reply-To: <AANLkTi=8zWMYWG0DU147B08nN7xcvwaB9Bpq9fE8_fBe@mail.gmail.com>
On Thu, 2010-12-09 at 19:47 +0100, Michał Mirosław wrote:
> 2010/12/9 Ben Hutchings <bhutchings@solarflare.com>:
> > On Thu, 2010-12-09 at 16:03 +0530, Govindarajan, Sriramakrishnan wrote:
> >> Hi
> >> We have a NAPI compliant driver(net/drivers/davinci_emac.c), that does
> >> well at 10/100Mbps loads. Now the same controller/driver is used for
> >> 1000Mbps
> >> mode as well, where the CPU gets saturated easily
> >>
> >> Internally the module supports scatter gather DMA(which is currently not
> >> exercised) but there is no HW checksum support.
> >>
> >> To specifically implement GRO, GSO support would it be sufficient to add
> >> SG support to the driver? Are there other means of increasing the throughput
> >> and decreasing the CPU loading?
> [...]
> > On the TX side, NETIF_F_SG means that the stack may include data in the
> > skb by reference to arbitrary pages *even if their contents are still
> > being changed* (think sendfile()), which means it depends on hardware
> > checksum generation.
>
> Isn't that condition too broad? If the data could change after packet
> is submitted to the driver then results would be unpredictable and
> allow sending wrong data with correct (because hw-calculated)
> checksum.
This is not done for a regular send(), only for functions such as
sendfile() which are specified to read the data asynchronously.
> Right now NETIF_F_SG is removed from dev->features by
> netdev_fix_features() if no checksum offloads are enabled.
>
> Just an idea: would driver with NETIF_F_SG|NETIF_F_HW_CSUM using
> skb_checksum_help() in xmit path work? This would allow to use DMA
> scatter-gather without hardware checksumming (and avoid copying the
> packet's data before sending).
No, you cannot calculate a checksum for the fragments without also
copying them to ensure the data doesn't change afterward and invalidate
the checksum. You could in theory make a copy into multiple fragments,
but there's no point in doing that unless the frame size is larger than
a page.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [PATCH] bridge: Fix return value of br_multicast_add_group()
From: Tobias Klauser @ 2010-12-09 18:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, bridge, netdev
In-Reply-To: <20101209082924.6d797871@nehalam>
On 2010-12-09 at 17:29:24 +0100, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> On Thu, 9 Dec 2010 15:02:36 +0100
> Tobias Klauser <tklauser@distanz.ch> wrote:
>
> > If br_multicast_new_group returns NULL, we would return 0 (no error) to
> > the caller, which is not what we want. Instead we should return -ENOMEM
> > in this case.
> >
> > Also replace IS_ERR(x) || !x by IS_ERR_OR_NULL(x)
> >
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> > ---
> > net/bridge/br_multicast.c | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> > index 326e599..d4e1e81 100644
> > --- a/net/bridge/br_multicast.c
> > +++ b/net/bridge/br_multicast.c
> > @@ -713,8 +713,11 @@ static int br_multicast_add_group(struct net_bridge *br,
> >
> > mp = br_multicast_new_group(br, port, group);
> > err = PTR_ERR(mp);
> > - if (unlikely(IS_ERR(mp) || !mp))
> > + if (IS_ERR_OR_NULL(mp)) {
> > + if (!mp)
> > + err = -ENOMEM;
> > goto err;
> > + }
> >
> > if (!port) {
> > hlist_add_head(&mp->mglist, &br->mglist);
>
> I would rather fix br_multicast_new_group so it never returns
> NULL. Instead return PTR_ERR(-ENOMEM) on out of memory.
Ok, I'll change that and send an updated patch.
Thanks a lot
Tobias
^ permalink raw reply
* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: Eric W. Biederman @ 2010-12-09 19:09 UTC (permalink / raw)
To: Brian Haley
Cc: David Miller, netdev, Mahesh Kelkar, Lorenzo Colitti,
YOSHIFUJI Hideaki, Stephen Hemminger, stable
In-Reply-To: <4D00F58A.2050307@hp.com>
Brian Haley <brian.haley@hp.com> writes:
> On 12/08/2010 11:16 PM, Eric W. Biederman wrote:
>> Finding the real bug is beyond me right now, but fixing the regression
>> in disable_ipv6 is simple. We can just delete ::1 when we bring down
>> the loopback interface, and it will be restored automatically when we
>> bring the loopback interface back up.
>
> Hi Eric,
>
> This would work as well, same check, different way.
But that looks like less of an obvious magic exception. The only
address it is safe to ignore on is ::1, because we always restore it
when we bring the loopback interface up.
Long term we really do want to keep the loopback address. But
that actually requires finding and fixing what is broken in
ipv6.
So let's please keep this a line that we can easily remove. It isn't
like interfaces coming up and down are a fast path where every cycle
counts. We just need to be reasonably efficient.
Eric
^ permalink raw reply
* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: Stephen Hemminger @ 2010-12-09 19:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Brian Haley, David Miller, netdev, Mahesh Kelkar, Lorenzo Colitti,
YOSHIFUJI Hideaki, stable
In-Reply-To: <m139q6ahld.fsf@fess.ebiederm.org>
On Thu, 09 Dec 2010 11:09:34 -0800
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Brian Haley <brian.haley@hp.com> writes:
>
> > On 12/08/2010 11:16 PM, Eric W. Biederman wrote:
> >> Finding the real bug is beyond me right now, but fixing the regression
> >> in disable_ipv6 is simple. We can just delete ::1 when we bring down
> >> the loopback interface, and it will be restored automatically when we
> >> bring the loopback interface back up.
> >
> > Hi Eric,
> >
> > This would work as well, same check, different way.
>
> But that looks like less of an obvious magic exception. The only
> address it is safe to ignore on is ::1, because we always restore it
> when we bring the loopback interface up.
>
> Long term we really do want to keep the loopback address. But
> that actually requires finding and fixing what is broken in
> ipv6.
>
> So let's please keep this a line that we can easily remove. It isn't
> like interfaces coming up and down are a fast path where every cycle
> counts. We just need to be reasonably efficient.
No but since removing address propagates up to user space daemons
like Quagga please analyze and fix the problem, don't just look
for band aid.
^ permalink raw reply
* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: Eric W. Biederman @ 2010-12-09 19:22 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Brian Haley, David Miller, netdev, Mahesh Kelkar, Lorenzo Colitti,
YOSHIFUJI Hideaki, stable
In-Reply-To: <20101209082703.6e5519e7@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
> On Thu, 09 Dec 2010 10:28:10 -0500
> Brian Haley <brian.haley@hp.com> wrote:
>
>> On 12/08/2010 11:16 PM, Eric W. Biederman wrote:
>> /* If just doing link down, and address is permanent
>> and not link-local, then retain it. */
>> if (!how &&
>> (ifa->flags&IFA_F_PERMANENT) &&
>> !(ipv6_addr_type(&ifa->addr) & IPV6_ADDR_LINKLOCAL)) {
>> list_move_tail(&ifa->if_list, &keep_list);
>>
>> /* If not doing DAD on this address, just keep it. */
>> if ((dev->flags&(IFF_NOARP|IFF_LOOPBACK)) ||
>> idev->cnf.accept_dad <= 0 ||
>> (ifa->flags & IFA_F_NODAD))
>
> I think the problem is on coming back up, not on the down step.
Oh it is. All addresses that you keep break if you down the loopback
interface, no matter which interface those addresses are on.
Stephen the cause of the regression in 2.6.34-rc1 that you introduced
that breaks the disable_ipv6 functionality in practice is removing
the loopback address from the loopback interface. So I sent
a partial revert.
It is safe to do a partial revert because the loopback address is always
reprogrammed when we bring the interface back up. But that
reprogramming only works if it doesn't error out with -EEXIST.
So by all means properly fix the ancient bug that breaks usage of all
local ipv6 addresses when the loopback interface is brought down,
and we can remove the regression fix.
However complaining about a partial revert to fix a regression you
introduced because it fixes a problem deep within the ipv6 networking
stack that the smallest modicum of testing would have revealed on your
part before you broke things seems inappropriate.
Please let's get the disable_ipv6 functionality working again (where
in practice we don't care about preserving addresses). Then let's
take our time and tack and fix whatever this is properly.
Eric
^ permalink raw reply
* Re: tc: show format ABI changed
From: Jarek Poplawski @ 2010-12-09 19:25 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Eric Dumazet, netdev
In-Reply-To: <20101208145136.1ca3ece4@nehalam>
On Wed, Dec 08, 2010 at 02:51:36PM -0800, Stephen Hemminger wrote:
> Although well intentioned, the following patch should have not
> been applied since it changes the kernel ABI. It broke some scripts
> parsing the output format of tc commands.
I doubt you can blame this patch for changing any ABI. If there is
such a thing documented you would probably point us there. Otherwise,
it should be seen in the code, and tc has it all conditional:
if (tbs[TCA_STATS_RATE_EST]) {
...
fprintf(fp, "\n%srate %s %upps ",
prefix, sprint_rate(re.bps, b1), re.pps);
}
if (tbs[TCA_STATS_QUEUE]) {
...
if (!tbs[TCA_STATS_RATE_EST])
fprintf(fp, "\n%s", prefix);
fprintf(fp, "backlog %s %up requeues %u ",
sprint_size(q.backlog, b1), q.qlen, q.requeues);
}
which suggests scripts should use similar logic.
Anyway, these are tc's printouts and it should handle source data
errors too. Since it's accepted it can't be wrong ;-)
Jarek P.
>
> Before HTB would report bogus zero values, now it reports
> nothing and that changes the output format. Like the empty
> fields in /proc, I argue we can't play fast and loose with
> netlink responses.
>
> Not a big deal to fix the script in this case, in this case
> so don't revert it.
>
> commit d250a5f90e53f5e150618186230795352d154c88
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri Oct 2 10:32:18 2009 +0000
>
> pkt_sched: gen_estimator: Dont report fake rate estimators
>
> Jarek Poplawski a écrit :
> >
> >
> > Hmm... So you made me to do some "real" work here, and guess what?:
> > there is one serious checkpatch warning! ;-) Plus, this new parameter
> > should be added to the function description. Otherwise:
> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> >
> > Thanks,
> > Jarek P.
> >
> > PS: I guess full "Don't" would show we really mean it...
>
> Okay :) Here is the last round, before the night !
>
> Thanks again
>
> [RFC] pkt_sched: gen_estimator: Don't report fake rate estimators
>
> We currently send TCA_STATS_RATE_EST elements to netlink users, even if no estimator
> is running.
>
> # tc -s -d qdisc
> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 112833764978 bytes 1495081739 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
> User has no way to tell if the "rate 0bit 0pps" is a real estimation, or a fake
> one (because no estimator is active)
>
> After this patch, tc command output is :
> $ tc -s -d qdisc
> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 561075 bytes 1196 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
> We add a parameter to gnet_stats_copy_rate_est() function so that
> it can use gen_estimator_active(bstats, r), as suggested by Jarek.
>
> This parameter can be NULL if check is not necessary, (htb for
> example has a mandatory rate estimator)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: Eric W. Biederman @ 2010-12-09 19:31 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Brian Haley, David Miller, netdev, Mahesh Kelkar, Lorenzo Colitti,
YOSHIFUJI Hideaki, stable
In-Reply-To: <20101209111611.1d2e6e2b@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
> On Thu, 09 Dec 2010 11:09:34 -0800
> ebiederm@xmission.com (Eric W. Biederman) wrote:
> So let's please keep this a line that we can easily remove. It isn't
> like interfaces coming up and down are a fast path where every cycle
> counts. We just need to be reasonably efficient.
> No but since removing address propagates up to user space daemons
> like Quagga please analyze and fix the problem, don't just look
> for band aid.
You fix the problem. You introduced the regression, and you didn't test
that keeping addresses actually worked. This is not the first patch
that has been applied to fix regressions in this area.
I introduced a targeted revert of your broken change that only preserves
the one address people are least likely to change.
I know people are not downing the ipv6 loopback interface in practice
and bringing it back up because in practice on running systems because
that breaks ipv6 networking. So quagga should not see this issue
in practice.
Right now misplaced perfectionism is being a huge enemy of creating
a kernel that actually works.
Eric
^ permalink raw reply
* Re: Adding Support for SG,GSO,GRO
From: David Miller @ 2010-12-09 19:38 UTC (permalink / raw)
To: mirqus; +Cc: bhutchings, srk, netdev
In-Reply-To: <AANLkTi=8zWMYWG0DU147B08nN7xcvwaB9Bpq9fE8_fBe@mail.gmail.com>
From: Michał Mirosław <mirqus@gmail.com>
Date: Thu, 9 Dec 2010 19:47:57 +0100
> Isn't that condition too broad? If the data could change after packet
> is submitted to the driver then results would be unpredictable and
> allow sending wrong data with correct (because hw-calculated)
> checksum.
They are intentionally like that, without question.
Otherwise we'd need to interlock with all application mapped,
filesystem, and other page writes while sending any page over the
network.
We absolutely do not want to have to freeze every page we try to send
via sendfile() or similar, the cost is just too high.
If the application or networked filesystem needs such synchronization,
it provides it for itself.
For example, SAMBA only uses sendfile() when the file has an op-lock
held on it.
The checksum requirement for using SG is not going away, so continuing
to discuss along the lines of removing that requirement is not a good
use of your time I don't think.
^ permalink raw reply
* [PATCH net-next-26] cxgb4vf: Ingress Queue Entry Size needs to be 64 bytes
From: Casey Leedom @ 2010-12-09 19:38 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
Was using L1_CACHE_BYTES for the Ingress Queue Entry Size but it really
needs to be 64 bytes in order to support the largest message sizes.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index d887a76..6bf464a 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2269,6 +2269,7 @@ static void __devinit cfg_queues(struct adapter *adapter)
{
struct sge *s = &adapter->sge;
int q10g, n10g, qidx, pidx, qs;
+ size_t iqe_size;
/*
* We should not be called till we know how many Queue Sets we can
@@ -2313,6 +2314,13 @@ static void __devinit cfg_queues(struct adapter *adapter)
s->ethqsets = qidx;
/*
+ * The Ingress Queue Entry Size for our various Response Queues needs
+ * to be big enough to accommodate the largest message we can receive
+ * from the chip/firmware; which is 64 bytes ...
+ */
+ iqe_size = 64;
+
+ /*
* Set up default Queue Set parameters ... Start off with the
* shortest interrupt holdoff timer.
*/
@@ -2320,7 +2328,7 @@ static void __devinit cfg_queues(struct adapter *adapter)
struct sge_eth_rxq *rxq = &s->ethrxq[qs];
struct sge_eth_txq *txq = &s->ethtxq[qs];
- init_rspq(&rxq->rspq, 0, 0, 1024, L1_CACHE_BYTES);
+ init_rspq(&rxq->rspq, 0, 0, 1024, iqe_size);
rxq->fl.size = 72;
txq->q.size = 1024;
}
@@ -2329,8 +2337,7 @@ static void __devinit cfg_queues(struct adapter *adapter)
* The firmware event queue is used for link state changes and
* notifications of TX DMA completions.
*/
- init_rspq(&s->fw_evtq, SGE_TIMER_RSTRT_CNTR, 0, 512,
- L1_CACHE_BYTES);
+ init_rspq(&s->fw_evtq, SGE_TIMER_RSTRT_CNTR, 0, 512, iqe_size);
/*
* The forwarded interrupt queue is used when we're in MSI interrupt
@@ -2346,7 +2353,7 @@ static void __devinit cfg_queues(struct adapter *adapter)
* any time ...
*/
init_rspq(&s->intrq, SGE_TIMER_RSTRT_CNTR, 0, MSIX_ENTRIES + 1,
- L1_CACHE_BYTES);
+ iqe_size);
}
/*
--
1.7.0.4
^ permalink raw reply related
* Re: 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
From: Paul Moore @ 2010-12-09 19:42 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: James Morris, Stephen Smalley, NetDev, Linux Kernel Mailing List
In-Reply-To: <4CFFF3F3.90100@goop.org>
On Wed, 2010-12-08 at 13:09 -0800, Jeremy Fitzhardinge wrote:
> I just got this oops in a freshly booted 2.6.37-rc5 Xen domain, while
> sitting idle at the login prompt:
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000210
> IP: [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
> PGD 1c99d067 PUD 1cb03067 PMD 0
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/system/cpu/sched_mc_power_savings
> CPU 0
> Modules linked in: sunrpc dm_mirror dm_region_hash dm_log [last unloaded: scsi_wait_scan]
>
> Pid: 2297, comm: at-spi-registry Not tainted 2.6.37-rc5+ #293 /
> RIP: e030:[<ffffffff811d55d4>] [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
> RSP: e02b:ffff880006e7dd68 EFLAGS: 00010292
> RAX: ffff88001d1ed8c0 RBX: ffff88001d06d9a0 RCX: 0000000000000022
> RDX: ffff88001d1ed580 RSI: 0000000000000000 RDI: ffff88001b7d6ac0
> RBP: ffff880006e7de18 R08: 00000000ffff0201 R09: ffff88001e78c968
> R10: 000000001f47e9c2 R11: ffff88001fbf4400 R12: ffff88001d1ed8c0
> R13: ffff88001d1ed580 R14: ffff88001ca00cc0 R15: 0000000000000000
> FS: 00007fa643031920(0000) GS:ffff88001ff85000(0000) knlGS:0000000000000000
> CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000210 CR3: 000000001d78a000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process at-spi-registry (pid: 2297, threadinfo ffff880006e7c000, task ffff88001cdd1140)
> Stack:
> ffff88001d4c0bc0 000000004cffecc5 ffff880006e7ddc8 ffffffff81028dc5
> ffff8800ffffffff 0001628b2ec3fe22 ffff880006e7dde8 ffff88001d1edb80
> 0000000000000001 0000936a4da34099 0000000000000000 00000000000000fa
> Call Trace:
> [<ffffffff81028dc5>] ? pvclock_clocksource_read+0x48/0xb1
> [<ffffffff810074ab>] ? xen_clocksource_read+0x20/0x22
> [<ffffffff81008fd9>] ? xen_spin_lock+0xc6/0xd9
> [<ffffffff811d1d1e>] security_unix_stream_connect+0x16/0x18
> [<ffffffff81484366>] unix_stream_connect+0x215/0x3ff
> [<ffffffff813f351d>] sys_connect+0x7a/0xa0
> [<ffffffff8108cd9d>] ? audit_syscall_entry+0x1c2/0x1ee
> [<ffffffff8100bb42>] system_call_fastpath+0x16/0x1b
> Code: c9 c3 55 48 89 e5 41 55 41 54 53 48 81 ec 98 00 00 00 0f 1f 44 00 00 b9 22 00 00 00 48 8b 47 20 48 8b 76 20 48 8b 98 10 02 00 00 <4c> 8b a6 10 02 00 00 31 c0 4c 8b aa 10 02 00 00 4c 8d 85 50 ff
> RIP [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
> RSP <ffff880006e7dd68>
> CR2: 0000000000000210
> ---[ end trace 50030b578c1ee27e ]---
>
> This corresponds to:
>
> (gdb) list *0xffffffff811d55d4
> 0xffffffff811d55d4 is in selinux_socket_unix_stream_connect (/home/jeremy/git/upstream/security/selinux/hooks.c:3929).
> 3924 static int selinux_socket_unix_stream_connect(struct socket *sock,
> 3925 struct socket *other,
> 3926 struct sock *newsk)
> 3927 {
> 3928 struct sk_security_struct *sksec_sock = sock->sk->sk_security;
> 3929 struct sk_security_struct *sksec_other = other->sk->sk_security;
> 3930 struct sk_security_struct *sksec_new = newsk->sk_security;
> 3931 struct common_audit_data ad;
> 3932 int err;
> 3933
>
>
> The system is a somewhat out of date Fedora 13 with
> selinux-policy-3.7.19-73.fc13.noarch and
> selinux-policy-targeted-3.7.19-73.fc13.noarch installed.
>
> I'm not sure what at-spi-registry is or what it is trying to do here.
> The crash seems non-deterministic; I rebooted the domain without any issues.
>
> Thanks,
> J
Thanks for the report.
Unfortunately I don't have any great ideas off the top of my head but it
has been a couple of months since I've played with that code; I'll take
a look and see if anything jumps out at me.
For what it's worth, a quick Google makes me think that at-spi-registry
is part of Gnome's assistive technology functionality. That said, I
have no idea what it does exactly, but evidently it does it over a UNIX
domain socket ...
If you're ever able to recreate the problem or if you can think of
anything else that might be useful please let me know.
Thanks.
--
paul moore
linux @ hp
^ permalink raw reply
* [PATCH] MAINTAINERS: remove me from tulip
From: Kyle McMartin @ 2010-12-09 19:50 UTC (permalink / raw)
To: netdev; +Cc: davem, grundler
It was a nice idea, but -ENOTIME and -ENOHW. I never got around to doing
a lot of the clean up that I intended to.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 1a1c27b..a54a738 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5932,7 +5932,6 @@ F: include/linux/tty.h
TULIP NETWORK DRIVERS
M: Grant Grundler <grundler@parisc-linux.org>
-M: Kyle McMartin <kyle@mcmartin.ca>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/tulip/
^ 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