* Re: [PATCH] Add IDs for 3C905B-TX Fast Etherlink XL PCI
From: Steffen Klassert @ 2009-08-05 14:41 UTC (permalink / raw)
To: Pascal Terjan; +Cc: netdev
In-Reply-To: <1249481499-9560-1-git-send-email-pterjan@mandriva.com>
On Wed, Aug 05, 2009 at 04:11:39PM +0200, Pascal Terjan wrote:
> We found this old card which was not supported, and physically
> looks similar to the other 3C905B we have (9055).
>
> After adding the IDs it seems to work fine (MII report, dhcp, scp, ...)
The patch looks sane.
Btw. you should add a Signed-off-by line to your patches.
Acked-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
^ permalink raw reply
* [PATCH] Add IDs for 3C905B-TX Fast Etherlink XL PCI
From: Pascal Terjan @ 2009-08-05 14:11 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev, Pascal Terjan
We found this old card which was not supported, and physically
looks similar to the other 3C905B we have (9055).
After adding the IDs it seems to work fine (MII report, dhcp, scp, ...)
---
drivers/net/3c59x.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index c204168..4567588 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -235,6 +235,7 @@ enum vortex_chips {
CH_3C900B_FL,
CH_3C905_1,
CH_3C905_2,
+ CH_3C905B_TX,
CH_3C905B_1,
CH_3C905B_2,
@@ -307,6 +308,8 @@ static struct vortex_chip_info {
PCI_USES_MASTER, IS_BOOMERANG|HAS_MII|EEPROM_RESET, 64, },
{"3c905 Boomerang 100baseT4",
PCI_USES_MASTER, IS_BOOMERANG|HAS_MII|EEPROM_RESET, 64, },
+ {"3C905B-TX Fast Etherlink XL PCI",
+ PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
{"3c905B Cyclone 100baseTx",
PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
@@ -389,6 +392,7 @@ static struct pci_device_id vortex_pci_tbl[] = {
{ 0x10B7, 0x900A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C900B_FL },
{ 0x10B7, 0x9050, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905_1 },
{ 0x10B7, 0x9051, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905_2 },
+ { 0x10B7, 0x9054, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_TX },
{ 0x10B7, 0x9055, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_1 },
{ 0x10B7, 0x9058, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_2 },
--
1.6.4
^ permalink raw reply related
* Re: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver
From: Serge E. Hallyn @ 2009-08-05 14:13 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, linux-security-module, selinux
In-Reply-To: <20090804212158.10798.34592.stgit@flek.lan>
Quoting Paul Moore (paul.moore@hp.com):
...
> static int tun_attach(struct tun_struct *tun, struct file *file)
> {
> struct tun_file *tfile = file->private_data;
> - const struct cred *cred = current_cred();
> - int err;
> + int err = 0;
>
> ASSERT_RTNL();
>
> - /* Check permissions */
> - if (((tun->owner != -1 && cred->euid != tun->owner) ||
> - (tun->group != -1 && !in_egroup_p(tun->group))) &&
> - !capable(CAP_NET_ADMIN))
> - return -EPERM;
...
> @@ -935,6 +930,13 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> else
> return -EINVAL;
>
> + if ((tun->owner != -1 && cred->euid != tun->owner) ||
> + (tun->group != -1 && !in_egroup_p(tun->group)))
> + return -EPERM;
> + err = security_tun_dev_attach(tun->sk);
> + if (err < 0)
> + return err;
> +
...
> +/**
> + * cap_tun_dev_attach - Determine if attaching to an TUN device is allowed
> + *
> + * Determine if the user is allowed to attach to an existing persistent TUN
> + * device, historically this has always required the CAP_NET_ADMIN permission.
> + */
> +int cap_tun_dev_attach(void)
> +{
> + if (!capable(CAP_NET_ADMIN))
> + return -EPERM;
> + return 0;
> +}
The checks before and after this patch are not equivalent. Post-patch,
one must always have CAP_NET_ADMIN to do the attach, whereas pre-patch
you only needed those if current_cred() did not own the tun device. Is
that intentional?
Also as Eric said this patch needs to set the cap_ hooks. This patch
isn't yet introducing the selinux hooks, so iiuc actually this patch should
always oops if CONFIG_SECURITY=y.
-serge
^ permalink raw reply
* Re: [PATCH] pxaficp-ir - remove incorrect net_device_ops
From: Marek Vasut @ 2009-08-05 14:02 UTC (permalink / raw)
To: Alexander Beregalov
Cc: Eric Miao, linux-arm-kernel, Russell King - ARM Linux, samuel,
netdev
In-Reply-To: <a4423d670907290416h4a0796c2s665d3f8ca0755e67@mail.gmail.com>
Dne St 29. července 2009 13:16:25 Alexander Beregalov napsal(a):
> 2009/7/28 Eric Miao <eric.y.miao@gmail.com>:
> > Marek Vasut wrote:
> >> Hi!
> >>
> >> This patch fixes broken pxaficp-ir. The problem was in incorrect
> >> net_device_ops being specified which prevented the driver from
> >> operating. The symptoms were:
> >> - failing ifconfig for IrLAN, resulting in
> >> SIOCSIFFLAGS: Cannot assign requested address
> >> - irattach working for IrCOMM, but the port stayed disabled
> >>
> >> Moreover this patch corrects missing sysfs device link.
> >>
> >> btw. guys, be honest, when did you last tested pxaficp-ir on real
> >> hardware? ;-)
> >
> > Well, this seems to be brought by the net_device_ops change, which seems
> > to happen silently without any of us being notified.
> >
> > OK, netdev and Alex are copied, so that we can look into this issue a bit
> > deeper:
> >
> > 1. it looks to me that SIOCSIFFLAGS actually returned -EADDRNOTAVAIL,
> > which is likely caused by eth_validate_addr, the default eth_addr comes
> > with irda should be "00:00:00:00:00:00" if not explicitly specified
> > (kzalloc), and this should be the problem, solution ? Either give a
> > valid address to the irda net_device or remove this 'ndo_validate_addr'.
> > And which is a correct fix will impact on the .ndo_set_mac_address
> >
> > 2. '.ndo_change_mtu' ? It looks to me that Irda device doesn't care too
> > much about the MTU, eth_change_mtu is supposed to work just fine and not
> > to cause any side effects, and may just benefit later irda device drivers
> > if there is a weird device happens to care about MTU
> >
> > - eric
> >
> > Marek's original patch in attachment.
>
> Sorry about that and thanks.
> Then we should fix the rest of irda drivers in the same way.
Hi!
Was my patch applied or what's the current status? Thanks
^ permalink raw reply
* Re: Boot lockups triggered by 'net: restore the original spinlock to protect unicast list'
From: Mark Brown @ 2009-08-05 13:49 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Meelis Roos, David S. Miller, netdev
In-Reply-To: <20090805134004.GG3897@psychotron.englab.brq.redhat.com>
On Wed, Aug 05, 2009 at 03:40:05PM +0200, Jiri Pirko wrote:
> Try this patch
> http://marc.info/?l=linux-kernel&m=124945666109347&w=2
> That should fix this.
It does indeed, thanks. FWIW
Tested-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply
* Re: Boot lockups triggered by 'net: restore the original spinlock to protect unicast list'
From: Jiri Pirko @ 2009-08-05 13:40 UTC (permalink / raw)
To: Mark Brown; +Cc: Meelis Roos, David S. Miller, netdev
In-Reply-To: <20090805133659.GA3740@rakim.wolfsonmicro.main>
Wed, Aug 05, 2009 at 03:36:59PM CEST, broonie@opensource.wolfsonmicro.com wrote:
>I'm experiencing lockups at boot in -next with the loopback interface on
>my SMDK6410. These appear to be triggered by commit
>a6ac65db2329e7685299666f5f7b6093c7b0f3a0 (net: restore the original
>spinlock to protect unicast list) - the code change is suspicious and
>reverting the change allows my system to boot. I've not yet tried to
>understand the failure, I'm just reporting it.
Try this patch
http://marc.info/?l=linux-kernel&m=124945666109347&w=2
That should fix this.
>
>The console trace I get on failure is:
>
>[ 1.830000] BUG: spinlock bad magic on CPU#0, swapper/1
>[ 1.830000] lock: c7852508, .magic: 00000000, .owner: <none>/-1, .owner_cpu0
>[ 1.840000] [<c002fdc8>] (unwind_backtrace+0x0/0xe0) from [<c01679fc>] (_raw)
>[ 1.850000] [<c01679fc>] (_raw_spin_lock+0x20/0x98) from [<c020ac40>] (dev_u)
>[ 1.860000] [<c020ac40>] (dev_unicast_init+0x18/0x3c) from [<c020ebf8>] (all)
>[ 1.860000] [<c020ebf8>] (alloc_netdev_mq+0xbc/0x13c) from [<c001b210>] (loo)
>[ 1.870000] [<c001b210>] (loopback_net_init+0x1c/0x70) from [<c02096e4>] (re)
>[ 1.880000] [<c02096e4>] (register_pernet_operations+0x20/0x2c) from [<c0209)
>[ 1.890000] [<c0209778>] (register_pernet_device+0x20/0x54) from [<c001cbbc>)
>[ 1.900000] [<c001cbbc>] (net_dev_init+0xd0/0x15c) from [<c0029274>] (do_one)
>[ 1.910000] [<c0029274>] (do_one_initcall+0x4c/0x174) from [<c0008640>] (do_)
>[ 1.920000] [<c0008640>] (do_initcalls+0x1c/0x38) from [<c0008a04>] (kernel_)
>[ 1.930000] [<c0008a04>] (kernel_init+0x3c/0x8c) from [<c002ac98>] (kernel_t)
>[ 9.930000] BUG: spinlock lockup on CPU#0, swapper/1, c7852508
>[ 9.930000] [<c002fdc8>] (unwind_backtrace+0x0/0xe0) from [<c01679c8>] (__sp)
>[ 9.940000] [<c01679c8>] (__spin_lock_debug+0x88/0x9c) from [<c0167a54>] (_r)
>[ 9.940000] [<c0167a54>] (_raw_spin_lock+0x78/0x98) from [<c020ac40>] (dev_u)
>[ 9.950000] [<c020ac40>] (dev_unicast_init+0x18/0x3c) from [<c020ebf8>] (all)
>[ 9.960000] [<c020ebf8>] (alloc_netdev_mq+0xbc/0x13c) from [<c001b210>] (loo)
>[ 9.970000] [<c001b210>] (loopback_net_init+0x1c/0x70) from [<c02096e4>] (re)
>[ 9.980000] [<c02096e4>] (register_pernet_operations+0x20/0x2c) from [<c0209)
>[ 9.990000] [<c0209778>] (register_pernet_device+0x20/0x54) from [<c001cbbc>)
>[ 10.000000] [<c001cbbc>] (net_dev_init+0xd0/0x15c) from [<c0029274>] (do_one)
>[ 10.010000] [<c0029274>] (do_one_initcall+0x4c/0x174) from [<c0008640>] (do_)
>[ 10.020000] [<c0008640>] (do_initcalls+0x1c/0x38) from [<c0008a04>] (kernel_)
>[ 10.030000] [<c0008a04>] (kernel_init+0x3c/0x8c) from [<c002ac98>] (kernel_t)
^ permalink raw reply
* Boot lockups triggered by 'net: restore the original spinlock to protect unicast list'
From: Mark Brown @ 2009-08-05 13:36 UTC (permalink / raw)
To: Jiri Pirko, Meelis Roos, David S. Miller; +Cc: netdev
I'm experiencing lockups at boot in -next with the loopback interface on
my SMDK6410. These appear to be triggered by commit
a6ac65db2329e7685299666f5f7b6093c7b0f3a0 (net: restore the original
spinlock to protect unicast list) - the code change is suspicious and
reverting the change allows my system to boot. I've not yet tried to
understand the failure, I'm just reporting it.
The console trace I get on failure is:
[ 1.830000] BUG: spinlock bad magic on CPU#0, swapper/1
[ 1.830000] lock: c7852508, .magic: 00000000, .owner: <none>/-1, .owner_cpu0
[ 1.840000] [<c002fdc8>] (unwind_backtrace+0x0/0xe0) from [<c01679fc>] (_raw)
[ 1.850000] [<c01679fc>] (_raw_spin_lock+0x20/0x98) from [<c020ac40>] (dev_u)
[ 1.860000] [<c020ac40>] (dev_unicast_init+0x18/0x3c) from [<c020ebf8>] (all)
[ 1.860000] [<c020ebf8>] (alloc_netdev_mq+0xbc/0x13c) from [<c001b210>] (loo)
[ 1.870000] [<c001b210>] (loopback_net_init+0x1c/0x70) from [<c02096e4>] (re)
[ 1.880000] [<c02096e4>] (register_pernet_operations+0x20/0x2c) from [<c0209)
[ 1.890000] [<c0209778>] (register_pernet_device+0x20/0x54) from [<c001cbbc>)
[ 1.900000] [<c001cbbc>] (net_dev_init+0xd0/0x15c) from [<c0029274>] (do_one)
[ 1.910000] [<c0029274>] (do_one_initcall+0x4c/0x174) from [<c0008640>] (do_)
[ 1.920000] [<c0008640>] (do_initcalls+0x1c/0x38) from [<c0008a04>] (kernel_)
[ 1.930000] [<c0008a04>] (kernel_init+0x3c/0x8c) from [<c002ac98>] (kernel_t)
[ 9.930000] BUG: spinlock lockup on CPU#0, swapper/1, c7852508
[ 9.930000] [<c002fdc8>] (unwind_backtrace+0x0/0xe0) from [<c01679c8>] (__sp)
[ 9.940000] [<c01679c8>] (__spin_lock_debug+0x88/0x9c) from [<c0167a54>] (_r)
[ 9.940000] [<c0167a54>] (_raw_spin_lock+0x78/0x98) from [<c020ac40>] (dev_u)
[ 9.950000] [<c020ac40>] (dev_unicast_init+0x18/0x3c) from [<c020ebf8>] (all)
[ 9.960000] [<c020ebf8>] (alloc_netdev_mq+0xbc/0x13c) from [<c001b210>] (loo)
[ 9.970000] [<c001b210>] (loopback_net_init+0x1c/0x70) from [<c02096e4>] (re)
[ 9.980000] [<c02096e4>] (register_pernet_operations+0x20/0x2c) from [<c0209)
[ 9.990000] [<c0209778>] (register_pernet_device+0x20/0x54) from [<c001cbbc>)
[ 10.000000] [<c001cbbc>] (net_dev_init+0xd0/0x15c) from [<c0029274>] (do_one)
[ 10.010000] [<c0029274>] (do_one_initcall+0x4c/0x174) from [<c0008640>] (do_)
[ 10.020000] [<c0008640>] (do_initcalls+0x1c/0x38) from [<c0008a04>] (kernel_)
[ 10.030000] [<c0008a04>] (kernel_init+0x3c/0x8c) from [<c002ac98>] (kernel_t)
^ permalink raw reply
* Re: [PATCH 5/5] c/r: Add AF_UNIX support (v7)
From: Serge E. Hallyn @ 2009-08-05 13:29 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, Alexey Dobriyan, netdev
In-Reply-To: <8763d3dwmx.fsf@caffeine.danplanet.com>
Quoting Dan Smith (danms@us.ibm.com):
> SH> why only free iov_base if ret!=0?
>
> Because I was diagnosing a crash that only seemed to happen when I
> free()'d the buffer after it was used by sendmsg() and I forgot to
> remove this :(
>
> >> + a->sk_peercred.pid = task_tgid_vnr(current);
> >> + a->sk_peercred.uid = ctx->realcred->uid;
>
> SH> I don't know how much it matters, but of course root could be
> SH> restarting a set of tasks owned by several non-root uids, and the
> SH> peercred.uid's might need to be something other than
> ctx-> realcred->uid. Or not?
>
> Oh, so you're suggesting I use ctx->ecred instead? I didn't actually
> notice the double declaration in the ckpt_ctx, but I guess that would
> be better.
No, I'm suggesting that the checkpointed application might have had
tasks owned by uids 0, 3, 55, and 1001, and a.peercred.uid might have
been 1001, right? current, ctx->realcred->uid, and ctx->ecred might
all be different uids. I think you just need to checkpoint the uid
(eventually an objref to a checkpointed user struct so we can also
catch the user namespace).
-serge
^ permalink raw reply
* Confirmed Receipt
From: pdacjoyce @ 2009-08-05 13:14 UTC (permalink / raw)
To: unl
You are among the lucky people.Confirm this receipt by replying the due process unit officer:Fill the details: FullName,Address,Tel,Occupation,etc,Reply to nelsonwhitedesk004@btinternet.com
^ permalink raw reply
* Re: [RFC PATCH v1 2/2] selinux: Support for the new TUN LSM hooks
From: Eric Paris @ 2009-08-05 13:06 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, linux-security-module, selinux
In-Reply-To: <20090804212204.10798.53727.stgit@flek.lan>
On Tue, Aug 4, 2009 at 5:22 PM, Paul Moore<paul.moore@hp.com> wrote:
> Add support for the new TUN LSM hooks: security_tun_dev_create(),
> security_tun_dev_post_create() and security_tun_dev_attach(). This includes
> the addition of a new object class, tun_socket, which represents the socks
> associated with TUN devices. The _tun_dev_create() and _tun_dev_post_create()
> hooks are fairly similar to the standard socket functions but _tun_dev_attach()
> is a bit special. The _tun_dev_attach() is unique because it involves a
> domain attaching to an existing TUN device and its associated tun_socket
> object, an operation which does not exist with standard sockets and most
> closely resembles a relabel operation.
>
> This patch also includes a new policy capability, tun_perms, to ensure that
> the new access controls do not affect older SELinux policies.
I think we finally have the first patch where the 'handle_unknown'
stuff fits better than the policy capabilities work! First time for
everything! I'd suggest dropping the policy capability all together
and the checks will be applied when the class and perm is defined in
the loaded policy. If the class+perm isn't defined in policy the
policy handle_unknown setting will define the result of the security
check.
whoo hoo, saves 32bits of memory and 2 branches on low use operations!
-Eric
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Changes to support the "-f" option of ethtool.
From: Ben Hutchings @ 2009-08-05 13:06 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: davem, jgarzik, netdev
In-Reply-To: <20090805123704.GC6592@serverengines.com>
On Wed, 2009-08-05 at 18:07 +0530, Ajit Khaparde wrote:
> The patch intends to use the request_firmware() interface to pick the
> firmware image file.
> I had missed this in the original post. Thanks.
[...]
Thanks for the clarification.
request_firmware() is meant for loading firmware that is stored in
volatile memory (RAM) on the device and therefore needs to be installed
on the host.
When the firmware is stored in flash on the device, updates only need to
be used once, and there should be no need to install them on the host.
So request_firmware() does not seem suitable.
I believe the ethtool EEPROM commands were meant for updating firmware
on NICs. Although they assume random access and so are unsuitable for
flash-based firmware, they might be a better model for adding flash
update commands. However, this command set is already available through
the MTD device class, which is what we use for firmware update as far as
possible. Not only does this allow for an arbitrary number of separate
firmware partitions per network device, but it can be used in an
out-of-tree driver for older kernel versions.
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: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver
From: Eric Paris @ 2009-08-05 13:03 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, linux-security-module, selinux
In-Reply-To: <20090804212158.10798.34592.stgit@flek.lan>
On Tue, Aug 4, 2009 at 5:21 PM, Paul Moore<paul.moore@hp.com> wrote:
> The TUN driver lacks any LSM hooks which makes it difficult for LSM modules,
> such as SELinux, to enforce access controls on network traffic generated by
> TUN users; this is particularly problematic for virtualization apps such as
> QEMU and KVM. This patch adds three new LSM hooks designed to control the
> creation and attachment of TUN devices, the hooks are:
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 48b7e02..07125a6 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -984,3 +984,29 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages)
> cap_sys_admin = 1;
> return __vm_enough_memory(mm, pages, cap_sys_admin);
> }
> +
> +/**
> + * cap_tun_dev_create - Determine if creation of a new TUN device is allowed
> + *
> + * Determine if the user is allowed to create a new TUN device, historically
> + * this has always required the CAP_NET_ADMIN permission.
> + */
> +int cap_tun_dev_create(void)
> +{
> + if (!capable(CAP_NET_ADMIN))
> + return -EPERM;
> + return 0;
> +}
> +
> +/**
> + * cap_tun_dev_attach - Determine if attaching to an TUN device is allowed
> + *
> + * Determine if the user is allowed to attach to an existing persistent TUN
> + * device, historically this has always required the CAP_NET_ADMIN permission.
> + */
> +int cap_tun_dev_attach(void)
> +{
> + if (!capable(CAP_NET_ADMIN))
> + return -EPERM;
> + return 0;
> +}
> diff --git a/security/security.c b/security/security.c
> index dc7674f..14ebf82 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1112,6 +1112,24 @@ void security_inet_conn_established(struct sock *sk,
> security_ops->inet_conn_established(sk, skb);
> }
>
> +int security_tun_dev_create(void)
> +{
> + return security_ops->tun_dev_create();
> +}
> +EXPORT_SYMBOL(security_tun_dev_create);
> +
> +void security_tun_dev_post_create(struct sock *tun_sk)
> +{
> + return security_ops->tun_dev_post_create(tun_sk);
> +}
> +EXPORT_SYMBOL(security_tun_dev_post_create);
> +
> +int security_tun_dev_attach(struct sock *tun_sk)
> +{
> + return security_ops->tun_dev_attach(tun_sk);
> +}
> +EXPORT_SYMBOL(security_tun_dev_attach);
> +
> #endif /* CONFIG_SECURITY_NETWORK */
>
> #ifdef CONFIG_SECURITY_NETWORK_XFRM
You also must add cap_tun_dev_post_create in security/capability.c and
you need to call set_to_cap_if_null() for all 3 of these new
functions. I believe you'll see a wonderful null pointer panic if you
tried with selinux=0.....
-Eric
^ permalink raw reply
* Re: [PATCH] ethtool: Add "-f" option to flash firmware image to a network device.
From: Ben Hutchings @ 2009-08-05 12:48 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: davem, jgarzik, netdev
In-Reply-To: <20090805123143.GA6592@serverengines.com>
On Wed, 2009-08-05 at 18:01 +0530, Ajit Khaparde wrote:
> Attached is a patch for ethtool utility to add a new "-f" option.
> This will enable flashing a firmware image to a network interface.
Which firmware? There can be several firmware images for controller,
PHY, host boot "ROM" and others.
[...]
> @@ -2398,6 +2404,20 @@ static int do_grxclass(int fd, struct ifreq
> *ifr)
> return 0;
> }
>
> +static int do_flash(int fd, struct ifreq *ifr)
> +{
> + int err;
> + struct ethtool_value ecmd;
> +
> + ecmd.cmd = ETHTOOL_FLASHDEV;
> + ifr->ifr_data = (caddr_t)&ecmd;
> + err = send_ioctl(fd, ifr);
> + if (err < 0)
> + perror("Flashing failed");
[..]
Where does the image come from? The running code? What about static
variables that have changed since startup?
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 net-next-2.6] net: Changes to support the "-f" option of ethtool.
From: Ajit Khaparde @ 2009-08-05 12:37 UTC (permalink / raw)
To: davem, jgarzik, netdev
In-Reply-To: <20090805123211.GB6592@serverengines.com>
The patch intends to use the request_firmware() interface to pick the
firmware image file.
I had missed this in the original post. Thanks.
On 05/08/09 18:02 +0530, Ajit Khaparde wrote:
> This patch adds kernel support for the new "-f" option in ethtool,
> This will allow a firmware image to be flashed to a network device.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
> ---
> include/linux/ethtool.h | 3 +++
> net/core/ethtool.c | 13 +++++++++++++
> 2 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 90c4a36..9b92f44 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -489,6 +489,7 @@ struct ethtool_ops {
> int (*get_stats_count)(struct net_device *);/* use get_sset_count */
> int (*get_rxnfc)(struct net_device *, struct ethtool_rxnfc *, void *);
> int (*set_rxnfc)(struct net_device *, struct ethtool_rxnfc *);
> + int (*flash_device)(struct net_device *);
> };
> #endif /* __KERNEL__ */
>
> @@ -545,6 +546,8 @@ struct ethtool_ops {
> #define ETHTOOL_GRXCLSRLALL 0x00000030 /* Get all RX classification rule */
> #define ETHTOOL_SRXCLSRLDEL 0x00000031 /* Delete RX classification rule */
> #define ETHTOOL_SRXCLSRLINS 0x00000032 /* Insert RX classification rule */
> +#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device
> + * (ethtool_value). */
>
> /* compatibility with older code */
> #define SPARC_ETH_GSET ETHTOOL_GSET
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 44e5711..0524201 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -898,6 +898,16 @@ static int ethtool_set_value(struct net_device *dev, char __user *useraddr,
> return actor(dev, edata.data);
> }
>
> +static int ethtool_flash_device(struct net_device *dev)
> +{
> + int err;
> +
> + if (!dev->ethtool_ops->flash_device)
> + return -EOPNOTSUPP;
> +
> + return dev->ethtool_ops->flash_device(dev);
> +}
> +
> /* The main entry point in this file. Called from net/core/dev.c */
>
> int dev_ethtool(struct net *net, struct ifreq *ifr)
> @@ -1111,6 +1121,9 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
> case ETHTOOL_SGRO:
> rc = ethtool_set_gro(dev, useraddr);
> break;
> + case ETHTOOL_FLASHDEV:
> + rc = ethtool_flash_device(dev);
> + break;
> default:
> rc = -EOPNOTSUPP;
> }
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] net/rds: Use AF_INET for sin_family field
From: Julia Lawall @ 2009-08-05 12:34 UTC (permalink / raw)
To: David S. Miller, Andy Grover, netdev, rds-devel, linux-kernel,
kernel-janitors
From: Julia Lawall <julia@diku.dk>
Elsewhere the sin_family field holds a value with a name of the form
AF_..., so it seems reasonable to do so here as well. Also the values of
PF_INET and AF_INET are the same.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
struct sockaddr_in sip;
@@
(
sip.sin_family ==
- PF_INET
+ AF_INET
|
sip.sin_family !=
- PF_INET
+ AF_INET
|
sip.sin_family =
- PF_INET
+ AF_INET
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
net/rds/rdma_transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -u -p a/net/rds/rdma_transport.c b/net/rds/rdma_transport.c
--- a/net/rds/rdma_transport.c
+++ b/net/rds/rdma_transport.c
@@ -137,7 +137,7 @@ static int __init rds_rdma_listen_init(v
goto out;
}
- sin.sin_family = PF_INET,
+ sin.sin_family = AF_INET,
sin.sin_addr.s_addr = (__force u32)htonl(INADDR_ANY);
sin.sin_port = (__force u16)htons(RDS_PORT);
^ permalink raw reply
* [PATCH net-next-2.6] net: Changes to support the "-f" option of ethtool.
From: Ajit Khaparde @ 2009-08-05 12:32 UTC (permalink / raw)
To: davem, jgarzik, netdev
This patch adds kernel support for the new "-f" option in ethtool,
This will allow a firmware image to be flashed to a network device.
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
include/linux/ethtool.h | 3 +++
net/core/ethtool.c | 13 +++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 90c4a36..9b92f44 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -489,6 +489,7 @@ struct ethtool_ops {
int (*get_stats_count)(struct net_device *);/* use get_sset_count */
int (*get_rxnfc)(struct net_device *, struct ethtool_rxnfc *, void *);
int (*set_rxnfc)(struct net_device *, struct ethtool_rxnfc *);
+ int (*flash_device)(struct net_device *);
};
#endif /* __KERNEL__ */
@@ -545,6 +546,8 @@ struct ethtool_ops {
#define ETHTOOL_GRXCLSRLALL 0x00000030 /* Get all RX classification rule */
#define ETHTOOL_SRXCLSRLDEL 0x00000031 /* Delete RX classification rule */
#define ETHTOOL_SRXCLSRLINS 0x00000032 /* Insert RX classification rule */
+#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device
+ * (ethtool_value). */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 44e5711..0524201 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -898,6 +898,16 @@ static int ethtool_set_value(struct net_device *dev, char __user *useraddr,
return actor(dev, edata.data);
}
+static int ethtool_flash_device(struct net_device *dev)
+{
+ int err;
+
+ if (!dev->ethtool_ops->flash_device)
+ return -EOPNOTSUPP;
+
+ return dev->ethtool_ops->flash_device(dev);
+}
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1111,6 +1121,9 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SGRO:
rc = ethtool_set_gro(dev, useraddr);
break;
+ case ETHTOOL_FLASHDEV:
+ rc = ethtool_flash_device(dev);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH] ethtool: Add "-f" option to flash firmware image to a network device.
From: Ajit Khaparde @ 2009-08-05 12:31 UTC (permalink / raw)
To: davem, jgarzik, netdev
Attached is a patch for ethtool utility to add a new "-f" option.
This will enable flashing a firmware image to a network interface.
Usage:
ethtool -f <interface name>
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
---
ethtool-copy.h | 1 +
ethtool.c | 22 +++++++++++++++++++++-
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3ca4e2c..49b741b 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -338,6 +338,7 @@ struct ethtool_rxnfc {
#define ETHTOOL_SRXFH 0x0000002a /* Set RX flow hash configuration */
#define ETHTOOL_GGRO 0x0000002b /* Get GRO enable (ethtool_value) */
#define ETHTOOL_SGRO 0x0000002c /* Set GRO enable (ethtool_value) */
+#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware (ethtool_value) */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/ethtool.c b/ethtool.c
index 0110682..fedb3a2 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -77,6 +77,7 @@ static char *unparse_rxfhashopts(u64 opts);
static int dump_rxfhash(int fhash, u64 val);
static int do_srxclass(int fd, struct ifreq *ifr);
static int do_grxclass(int fd, struct ifreq *ifr);
+static int do_flash(int fd, struct ifreq *ifr);
static int send_ioctl(int fd, struct ifreq *ifr);
static enum {
@@ -101,6 +102,7 @@ static enum {
MODE_GSTATS,
MODE_GNFC,
MODE_SNFC,
+ MODE_FLASHDEV,
} mode = MODE_GSET;
static struct option {
@@ -192,6 +194,7 @@ static struct option {
"classification options",
" [ rx-flow-hash tcp4|udp4|ah4|sctp4|"
"tcp6|udp6|ah6|sctp6 p|m|v|t|s|d|f|n|r... ]\n" },
+ { "-f", "--flash", MODE_FLASHDEV, "Flash firmware to device" },
{ "-h", "--help", MODE_HELP, "Show this help" },
{}
};
@@ -496,7 +499,8 @@ static void parse_cmdline(int argc, char **argp)
(mode == MODE_GSTATS) ||
(mode == MODE_GNFC) ||
(mode == MODE_SNFC) ||
- (mode == MODE_PHYS_ID)) {
+ (mode == MODE_PHYS_ID) ||
+ (mode == MODE_FLASHDEV)) {
devname = argp[i];
break;
}
@@ -1504,6 +1508,8 @@ static int doit(void)
return do_grxclass(fd, &ifr);
} else if (mode == MODE_SNFC) {
return do_srxclass(fd, &ifr);
+ } else if (mode == MODE_FLASHDEV) {
+ return do_flash(fd, &ifr);
}
return 69;
@@ -2398,6 +2404,20 @@ static int do_grxclass(int fd, struct ifreq *ifr)
return 0;
}
+static int do_flash(int fd, struct ifreq *ifr)
+{
+ int err;
+ struct ethtool_value ecmd;
+
+ ecmd.cmd = ETHTOOL_FLASHDEV;
+ ifr->ifr_data = (caddr_t)&ecmd;
+ err = send_ioctl(fd, ifr);
+ if (err < 0)
+ perror("Flashing failed");
+
+ return err;
+}
+
static int send_ioctl(int fd, struct ifreq *ifr)
{
return ioctl(fd, SIOCETHTOOL, ifr);
--
1.6.0.4
^ permalink raw reply related
* Re: Kernel oops on setting sky2 interfaces down
From: Rene Mayrhofer @ 2009-08-05 12:14 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <4A78CA13.6040409@ring3k.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike McCormack wrote:
>> Again, any hints would be greatly appreciated (and sorry for being
>> persistent about this annoying little bug...).
>
> Thanks for being persistent in testing :-) Looks like you've got a
> fairly unusual piece of hardware, as Stephen indicated.
Indeed, although I didn't think it _that_ unusual. It's just a 19" rack
appliance with 2 expansion slots for 4x LAN ports each. And those are
based around sky2.
But we have had problems before with kernel 2.4.34/.36 as well with that
hardware. They just weren't as easily reproducible but manifested
themselves in occasional malfunctions of the network devices that could
be solved by an ifdown/ifup cycle.
We still have one spare box and will try that one in case the hardware
is really flaky (which would be strange, given how reproducible it is
right now).
> Would you mind adding the phy_lock fix on top of the latest net-2.6
> git version of sky2 and testing that?
Tried it, doesn't fix the issue.
What would be the simplest change to stop disabling phy when the last
device goes down?
best regards,
Rene
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp5d6AACgkQq7SPDcPCS95OuACggTuTHsZd7m6IqHt0mrqUZbju
G4wAoPfPGr5G05E6HdO9kcKflGaSx7f5
=78yk
-----END PGP SIGNATURE-----
^ permalink raw reply
* [net-next-2.6 PATCH] be2net:Patch to perform function reset at initialization
From: Sarveshwar Bandi @ 2009-08-05 11:39 UTC (permalink / raw)
To: davem; +Cc: netdev
This patch is a bug fix to avoid system going into a bad state when driver
is loaded in context of kdump kernel. The patch fixes the issue by performing
a soft reset of pci function at probe time.
Signed-off-by: sarveshwarb <sarveshwarb@serverengines.com>
---
drivers/net/benet/be_cmds.c | 21 +++++++++++++++++++++
drivers/net/benet/be_cmds.h | 2 ++
drivers/net/benet/be_main.c | 4 ++++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index de10773..2547ee2 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1019,3 +1019,24 @@ int be_cmd_query_fw_cfg(struct be_adapte
spin_unlock(&adapter->mbox_lock);
return status;
}
+
+int be_cmd_reset_function(struct be_adapter *adapter)
+{
+ struct be_mcc_wrb *wrb = wrb_from_mbox(&adapter->mbox_mem);
+ struct be_cmd_req_hdr *req = embedded_payload(wrb);
+ int status;
+
+ spin_lock(&adapter->mbox_lock);
+
+ memset(wrb, 0, sizeof(*wrb));
+
+ be_wrb_hdr_prepare(wrb, sizeof(*req), true, 0);
+
+ be_cmd_hdr_prepare(req, CMD_SUBSYSTEM_COMMON,
+ OPCODE_COMMON_FUNCTION_RESET, sizeof(*req));
+
+ status = be_mbox_notify(adapter);
+
+ spin_unlock(&adapter->mbox_lock);
+ return status;
+}
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index 5c5de35..7061806 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -135,6 +135,7 @@ #define OPCODE_COMMON_EQ_DESTROY
#define OPCODE_COMMON_QUERY_FIRMWARE_CONFIG 58
#define OPCODE_COMMON_NTWK_PMAC_ADD 59
#define OPCODE_COMMON_NTWK_PMAC_DEL 60
+#define OPCODE_COMMON_FUNCTION_RESET 61
#define OPCODE_ETH_ACPI_CONFIG 2
#define OPCODE_ETH_PROMISCUOUS 3
@@ -744,4 +745,5 @@ extern int be_cmd_set_flow_control(struc
extern int be_cmd_get_flow_control(struct be_adapter *adapter,
u32 *tx_fc, u32 *rx_fc);
extern int be_cmd_query_fw_cfg(struct be_adapter *adapter, u32 *port_num);
+extern int be_cmd_reset_function(struct be_adapter *adapter);
extern void be_process_mcc(struct be_adapter *adapter);
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index ef82a52..d20235b 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1873,6 +1873,10 @@ static int __devinit be_probe(struct pci
if (status)
goto free_netdev;
+ status = be_cmd_reset_function(adapter);
+ if (status)
+ goto ctrl_clean;
+
status = be_stats_init(adapter);
if (status)
goto ctrl_clean;
--
1.4.0
^ permalink raw reply related
* Re: BUG: spinlock bad magic on CPU#1, swapper/1
From: Frans Pop @ 2009-08-05 10:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Mailing List, netdev, Jiri Pirko
In-Reply-To: <4A7958D3.40206@gmail.com>
On Wednesday 05 August 2009, Eric Dumazet wrote:
> Ingo posted a fix
> http://marc.info/?l=linux-kernel&m=124945666109347&w=2
Thanks. I'd missed that mail.
^ permalink raw reply
* Re: BUG: spinlock bad magic on CPU#1, swapper/1
From: Jiri Pirko @ 2009-08-05 10:03 UTC (permalink / raw)
To: Frans Pop; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <200908051150.53301.elendil@planet.nl>
Wed, Aug 05, 2009 at 11:50:52AM CEST, elendil@planet.nl wrote:
>On Wednesday 05 August 2009, Frans Pop wrote:
>> Current v2.6.31-rc5-246-g90bc1a6 gives me:
>>
>> BUG: spinlock bad magic on CPU#1, swapper/1
>> lock: ffff88007e1889c8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>> Pid: 1, comm: swapper Not tainted 2.6.31-rc5 #4
>> Call Trace:
>> [<ffffffff811345e8>] spin_bug+0xa2/0xaa
>> [<ffffffff8113469e>] _raw_spin_lock+0x23/0x135
>> [<ffffffff8125664e>] _spin_lock_bh+0x19/0x1e
>> [<ffffffff811e3702>] alloc_netdev_mq+0x127/0x211
>> [<ffffffff81433487>] ? netdev_init+0x6a/0xac
>> [<ffffffff811a81eb>] ? loopback_setup+0x0/0x7b
>> [<ffffffff8142e718>] loopback_net_init+0x30/0x7a
>> [<ffffffff811dd62e>] register_pernet_device+0x2b/0x58
>> [<ffffffff814336bd>] net_dev_init+0x13d/0x19b
>> [<ffffffff81433580>] ? net_dev_init+0x0/0x19b
>> [<ffffffff8100905c>] do_one_initcall+0x56/0x12b
>> [<ffffffff8106f55b>] ? register_irq_proc+0xb0/0xcc
>> [<ffffffff810e0000>] ? proc_pid_cmdline+0x5a/0xf9
>> [<ffffffff8140f65d>] kernel_init+0x14d/0x1a3
>> [<ffffffff8100ca7a>] child_rip+0xa/0x20
>> [<ffffffff8140f510>] ? kernel_init+0x0/0x1a3
>> [<ffffffff8100ca70>] ? child_rip+0x0/0x20
>>
>> Error occurs during early boot (between PCI/ACPI init and PnP init).
>
>Reverting the following commit fixes it:
Sure it fixes it but it also exposes the previous bug. I would rather suggest
to go with Ingo's patch.
Jirka
>commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
>Author: Jiri Pirko <jpirko@redhat.com>
>Date: Thu Jul 30 01:06:12 2009 +0000
>
> net: restore the original spinlock to protect unicast list
>
> There is a path when an assetion in dev_unicast_sync() appears.
>
> igmp6_group_added -> dev_mc_add -> __dev_set_rx_mode ->
> -> vlan_dev_set_rx_mode -> dev_unicast_sync
>
> Therefore we cannot protect this list with rtnl. This patch restores the
> original protecting this list with spinlock.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> Tested-by: Meelis Roos <mroos@linux.ee>
> Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: BUG: spinlock bad magic on CPU#1, swapper/1
From: Eric Dumazet @ 2009-08-05 10:02 UTC (permalink / raw)
To: Frans Pop; +Cc: Linux Kernel Mailing List, netdev, Jiri Pirko
In-Reply-To: <200908051150.53301.elendil@planet.nl>
Frans Pop a écrit :
> On Wednesday 05 August 2009, Frans Pop wrote:
>> Current v2.6.31-rc5-246-g90bc1a6 gives me:
>>
>> BUG: spinlock bad magic on CPU#1, swapper/1
>> lock: ffff88007e1889c8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>> Pid: 1, comm: swapper Not tainted 2.6.31-rc5 #4
>> Call Trace:
>> [<ffffffff811345e8>] spin_bug+0xa2/0xaa
>> [<ffffffff8113469e>] _raw_spin_lock+0x23/0x135
>> [<ffffffff8125664e>] _spin_lock_bh+0x19/0x1e
>> [<ffffffff811e3702>] alloc_netdev_mq+0x127/0x211
>> [<ffffffff81433487>] ? netdev_init+0x6a/0xac
>> [<ffffffff811a81eb>] ? loopback_setup+0x0/0x7b
>> [<ffffffff8142e718>] loopback_net_init+0x30/0x7a
>> [<ffffffff811dd62e>] register_pernet_device+0x2b/0x58
>> [<ffffffff814336bd>] net_dev_init+0x13d/0x19b
>> [<ffffffff81433580>] ? net_dev_init+0x0/0x19b
>> [<ffffffff8100905c>] do_one_initcall+0x56/0x12b
>> [<ffffffff8106f55b>] ? register_irq_proc+0xb0/0xcc
>> [<ffffffff810e0000>] ? proc_pid_cmdline+0x5a/0xf9
>> [<ffffffff8140f65d>] kernel_init+0x14d/0x1a3
>> [<ffffffff8100ca7a>] child_rip+0xa/0x20
>> [<ffffffff8140f510>] ? kernel_init+0x0/0x1a3
>> [<ffffffff8100ca70>] ? child_rip+0x0/0x20
>>
>> Error occurs during early boot (between PCI/ACPI init and PnP init).
>
> Reverting the following commit fixes it:
> commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
> Author: Jiri Pirko <jpirko@redhat.com>
> Date: Thu Jul 30 01:06:12 2009 +0000
>
> net: restore the original spinlock to protect unicast list
>
> There is a path when an assetion in dev_unicast_sync() appears.
>
> igmp6_group_added -> dev_mc_add -> __dev_set_rx_mode ->
> -> vlan_dev_set_rx_mode -> dev_unicast_sync
>
> Therefore we cannot protect this list with rtnl. This patch restores the
> original protecting this list with spinlock.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> Tested-by: Meelis Roos <mroos@linux.ee>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> --
Ingo posted a fix
http://marc.info/?l=linux-kernel&m=124945666109347&w=2
^ permalink raw reply
* Re: BUG: spinlock bad magic on CPU#1, swapper/1
From: Frans Pop @ 2009-08-05 9:50 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: netdev, Jiri Pirko
In-Reply-To: <200908051136.44908.elendil@planet.nl>
On Wednesday 05 August 2009, Frans Pop wrote:
> Current v2.6.31-rc5-246-g90bc1a6 gives me:
>
> BUG: spinlock bad magic on CPU#1, swapper/1
> lock: ffff88007e1889c8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> Pid: 1, comm: swapper Not tainted 2.6.31-rc5 #4
> Call Trace:
> [<ffffffff811345e8>] spin_bug+0xa2/0xaa
> [<ffffffff8113469e>] _raw_spin_lock+0x23/0x135
> [<ffffffff8125664e>] _spin_lock_bh+0x19/0x1e
> [<ffffffff811e3702>] alloc_netdev_mq+0x127/0x211
> [<ffffffff81433487>] ? netdev_init+0x6a/0xac
> [<ffffffff811a81eb>] ? loopback_setup+0x0/0x7b
> [<ffffffff8142e718>] loopback_net_init+0x30/0x7a
> [<ffffffff811dd62e>] register_pernet_device+0x2b/0x58
> [<ffffffff814336bd>] net_dev_init+0x13d/0x19b
> [<ffffffff81433580>] ? net_dev_init+0x0/0x19b
> [<ffffffff8100905c>] do_one_initcall+0x56/0x12b
> [<ffffffff8106f55b>] ? register_irq_proc+0xb0/0xcc
> [<ffffffff810e0000>] ? proc_pid_cmdline+0x5a/0xf9
> [<ffffffff8140f65d>] kernel_init+0x14d/0x1a3
> [<ffffffff8100ca7a>] child_rip+0xa/0x20
> [<ffffffff8140f510>] ? kernel_init+0x0/0x1a3
> [<ffffffff8100ca70>] ? child_rip+0x0/0x20
>
> Error occurs during early boot (between PCI/ACPI init and PnP init).
Reverting the following commit fixes it:
commit a6ac65db2329e7685299666f5f7b6093c7b0f3a0
Author: Jiri Pirko <jpirko@redhat.com>
Date: Thu Jul 30 01:06:12 2009 +0000
net: restore the original spinlock to protect unicast list
There is a path when an assetion in dev_unicast_sync() appears.
igmp6_group_added -> dev_mc_add -> __dev_set_rx_mode ->
-> vlan_dev_set_rx_mode -> dev_unicast_sync
Therefore we cannot protect this list with rtnl. This patch restores the
original protecting this list with spinlock.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* BUG: spinlock bad magic on CPU#1, swapper/1
From: Frans Pop @ 2009-08-05 9:36 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: netdev
Current v2.6.31-rc5-246-g90bc1a6 gives me:
BUG: spinlock bad magic on CPU#1, swapper/1
lock: ffff88007e1889c8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
Pid: 1, comm: swapper Not tainted 2.6.31-rc5 #4
Call Trace:
[<ffffffff811345e8>] spin_bug+0xa2/0xaa
[<ffffffff8113469e>] _raw_spin_lock+0x23/0x135
[<ffffffff8125664e>] _spin_lock_bh+0x19/0x1e
[<ffffffff811e3702>] alloc_netdev_mq+0x127/0x211
[<ffffffff81433487>] ? netdev_init+0x6a/0xac
[<ffffffff811a81eb>] ? loopback_setup+0x0/0x7b
[<ffffffff8142e718>] loopback_net_init+0x30/0x7a
[<ffffffff811dd62e>] register_pernet_device+0x2b/0x58
[<ffffffff814336bd>] net_dev_init+0x13d/0x19b
[<ffffffff81433580>] ? net_dev_init+0x0/0x19b
[<ffffffff8100905c>] do_one_initcall+0x56/0x12b
[<ffffffff8106f55b>] ? register_irq_proc+0xb0/0xcc
[<ffffffff810e0000>] ? proc_pid_cmdline+0x5a/0xf9
[<ffffffff8140f65d>] kernel_init+0x14d/0x1a3
[<ffffffff8100ca7a>] child_rip+0xa/0x20
[<ffffffff8140f510>] ? kernel_init+0x0/0x1a3
[<ffffffff8100ca70>] ? child_rip+0x0/0x20
Error occurs during early boot (between PCI/ACPI init and PnP init).
.31-rc5 itself did not give that error.
Cheers,
FJP
^ permalink raw reply
* Re: [PATCH 1/2] net: implement a SO_PROTOCOL getsockoption
From: Rémi Denis-Courmont @ 2009-08-05 9:28 UTC (permalink / raw)
To: ext Jan Engelhardt; +Cc: netdev@vger.kernel.org
In-Reply-To: <alpine.LSU.2.00.0908051042180.28374@fbirervta.pbzchgretzou.qr>
On Wednesday 05 August 2009 11:45:29 ext Jan Engelhardt wrote:
> On Wednesday 2009-08-05 08:35, Rémi Denis-Courmont wrote:
> >On Tuesday 04 August 2009 20:28:28 ext Jan Engelhardt wrote:
> >> Similar to SO_TYPE returning the socket type, SO_PROTOCOL allows to
> >> retrieve the protocol used with a given socket.
> >
> >You can easily infer the protocol family from the address family from
> >getsockname().
>
> As far as I remember, what you can get from getsockname is the
> domain type (AF_*/PF_*) through struct sockaddr->sa_family.
> Did you mean that?
Yes. It's almost like SO_DOMAIN but more portable and uglier.
> Though SO_PROTOCOL and SO_DOMAIN go nicely along with SO_TYPE.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ 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