* [patch 1/2] MAINTAINERS: orphan FrameRelay DLCI
From: akpm @ 2011-07-28 20:54 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, joe, shemminger
From: Joe Perches <joe@perches.com>
Mike McLagan hasn't contributed in many years and his email bounces.
Signed-off-by: Joe Perches <joe@perches.com>
Cc: David Miller <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -puN MAINTAINERS~maintainers-orphan-framerelay-dlci MAINTAINERS
--- a/MAINTAINERS~maintainers-orphan-framerelay-dlci
+++ a/MAINTAINERS
@@ -2643,9 +2643,8 @@ S: Maintained
F: arch/x86/math-emu/
FRAME RELAY DLCI/FRAD (Sangoma drivers too)
-M: Mike McLagan <mike.mclagan@linux.org>
L: netdev@vger.kernel.org
-S: Maintained
+S: Orphan
F: drivers/net/wan/dlci.c
F: drivers/net/wan/sdla.c
_
^ permalink raw reply
* [patch 2/2] proc_fork_connector: a lockless ->real_parent usage is not safe
From: akpm @ 2011-07-28 20:54 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, oleg, johnpol, vzapolskiy, zbr
From: Oleg Nesterov <oleg@redhat.com>
proc_fork_connector() uses ->real_parent lockless. This is not safe if
copy_process() was called with CLONE_THREAD or CLONE_PARENT, in this case
the parent != current can go away at any moment.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Vladimir Zapolskiy <vzapolskiy@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/connector/cn_proc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff -puN drivers/connector/cn_proc.c~proc_fork_connector-a-lockless-real_parent-usage-is-not-safe drivers/connector/cn_proc.c
--- a/drivers/connector/cn_proc.c~proc_fork_connector-a-lockless-real_parent-usage-is-not-safe
+++ a/drivers/connector/cn_proc.c
@@ -57,6 +57,7 @@ void proc_fork_connector(struct task_str
struct proc_event *ev;
__u8 buffer[CN_PROC_MSG_SIZE];
struct timespec ts;
+ struct task_struct *parent;
if (atomic_read(&proc_event_num_listeners) < 1)
return;
@@ -67,8 +68,11 @@ void proc_fork_connector(struct task_str
ktime_get_ts(&ts); /* get high res monotonic timestamp */
put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
ev->what = PROC_EVENT_FORK;
- ev->event_data.fork.parent_pid = task->real_parent->pid;
- ev->event_data.fork.parent_tgid = task->real_parent->tgid;
+ rcu_read_lock();
+ parent = rcu_dereference(task->real_parent);
+ ev->event_data.fork.parent_pid = parent->pid;
+ ev->event_data.fork.parent_tgid = parent->tgid;
+ rcu_read_unlock();
ev->event_data.fork.child_pid = task->pid;
ev->event_data.fork.child_tgid = task->tgid;
_
^ permalink raw reply
* Re: r8169 driver crashes in 2.6.32.43
From: Kasper Dupont @ 2011-07-28 21:01 UTC (permalink / raw)
To: Francois Romieu; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110728144719.GA11465@electric-eye.fr.zoreil.com>
On 28/07/11 16.47, Francois Romieu wrote:
> Kasper Dupont <kasperd@cpvhh.24.jul.2011.kasperd.net> :
> > On 28/07/11 14.45, Kasper Dupont wrote:
> > > On 28/07/11 14.23, Francois Romieu wrote:
> > > > You can replace them with plain printk(KERN_{INFO/ERR} "S: ...).
> > >
> > > Then it compiles, will let you know shortly how it works out.
> >
> > The last 24 lines before network stopped working:
> [...]
> > S: 000000c0
> > FEmp
> > S: 000000c0
> > FEmp
> > S: 00000040
> > S: 000000c4
> > S: 00000044
> > S: 00000040
>
> Can you revert the last patch and apply the one below ?
I tested it and put a picture of the output in the same place
as the error messages from before. If necessary I can try to
copy the dmesg output back over the other network interface
(assuming it is still up when the first one stops working).
>
> Network traffic capture at the remote end of the link would be welcome,
> especially ethernet MAC control frames.
I did a dump, but it showed nothing useful. The last packet
from the machine before the network stopped was a TCP ACK.
The sending machine send three more packets before it slowed
down, then send another three packets at lower speed and then
started sending arp requests, which were not answered.
There were three separate switches on the path between the
two machines. If necessary I can try to set up a network
with just a direct link between two hosts. I am not sure
which control frames you are referring to. Will tcpdump
capture them by default?
--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);
^ permalink raw reply
* "mlx4_en: Enabling new steering" brokenness
From: Roland Dreier @ 2011-07-28 21:04 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi Yevgeny!
So I have a system with an mlx4_en device with pretty old FW (version
2.7.700), old enough that the firmware doesn't have the capability
MLX4_DEV_CAP_FLAG_VEP_UC_STEER set. And it looks like mlx4_en is
completely broken in this case, at least since your commit
1679200f91da ("mlx4_en: Enabling new steering"). If I try to bring up
the interface, I just see:
mlx4_en: eth1: Failed to allocate RSS indirection QP
And this is failing because the QPN in 0.
The problem is in drivers/net/mlx4/port.c:mlx4_register_mac():
if (!(dev->caps.flags & MLX4_DEV_CAP_FLAG_VEP_UC_STEER))
*qpn = info->base_qpn + free;
but absolutely nothing ever initializes info->base_qpn. It looks like
the intention of the code is to initialize this in
mlx4_init_port_info(); however even the below hack doesn't seem to fix
things completely -- I still seem to have problems on the RX side
unless I enable promiscuous mode by running tcpdump:
diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c
index c94b342..38092c7 100644
--- a/drivers/net/mlx4/main.c
+++ b/drivers/net/mlx4/main.c
@@ -1125,6 +1125,13 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
info->port_attr.store = set_port_type;
sysfs_attr_init(&info->port_attr.attr);
+ err = mlx4_qp_reserve_range(dev, 1, 1, &info->base_qpn);
+ if (err) {
+ mlx4_err(dev, "Failed to reserve QP range for port %d\n", port);
+ info->port = -1;
+ return err;
+ }
+
err = device_create_file(&dev->pdev->dev, &info->port_attr);
if (err) {
mlx4_err(dev, "Failed to create file for port %d\n", port);
Could you take a look at getting this working? (Or update the driver
so it immediately fails with an informative message if you want to
rely on certain FW versions; and then strip out the old broken
compatibility code)
Thanks!
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Ben Hutchings @ 2011-07-28 21:14 UTC (permalink / raw)
To: David Miller; +Cc: gregory.v.rose, netdev, jeffrey.t.kirsher
In-Reply-To: <20110728.091448.548423057039764289.davem@davemloft.net>
On Thu, 2011-07-28 at 09:14 -0700, David Miller wrote:
> From: "Rose, Gregory V" <gregory.v.rose@intel.com>
> Date: Thu, 28 Jul 2011 08:51:05 -0700
>
> >> -----Original Message-----
> >> From: David Miller [mailto:davem@davemloft.net]
> >> Sent: Wednesday, July 27, 2011 10:28 PM
> >> To: Rose, Gregory V
> >> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> >>
> >> From: Greg Rose <gregory.v.rose@intel.com>
> >> Date: Wed, 27 Jul 2011 15:17:59 -0700
> >>
> >> > Add new set commands to configure the number of SR-IOV VFs, the
> >> > number of VM queues and spoof checking on/off switch.
> >> >
> >> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> >> > ---
> >> >
> >> > include/linux/ethtool.h | 11 ++++++++++-
> >> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> >> > index c6e427a..c4972ba 100644
> >> > --- a/include/linux/ethtool.h
> >> > +++ b/include/linux/ethtool.h
> >> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> >> > __u8 mdio_support;
> >> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> >> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> >> > + __u32 num_vfs; /* Enable SR-IOV VFs */
> >> > + __u32 num_vmqs; /* Set number of queues for VMDq */
> >>
> >> You can't change the layout of this datastructure in this way without
> >> breaking every ethtool binary out there.
> >>
> >> You have to find another place to add these knobs.
> >
> > Perhaps at the end of the ethtool_cmd structure? Something like this:
>
> Either use the two reserved u32's we have there, or create a new
> ethtool command and control structure.
I'm going to insist on the latter. As I see it, struct ethtool_cmd is
for Ethernet PHY settings. (The max{rx,tx}pkt fields weren't, but
they're obsolete.)
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 net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 21:16 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: netdev@vger.kernel.org, Kirsher, Jeffrey T
In-Reply-To: <1311887685.2677.12.camel@deadeye>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Thursday, July 28, 2011 2:15 PM
> To: David Miller
> Cc: Rose, Gregory V; netdev@vger.kernel.org; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> On Thu, 2011-07-28 at 09:14 -0700, David Miller wrote:
> > From: "Rose, Gregory V" <gregory.v.rose@intel.com>
> > Date: Thu, 28 Jul 2011 08:51:05 -0700
> >
> > >> -----Original Message-----
> > >> From: David Miller [mailto:davem@davemloft.net]
> > >> Sent: Wednesday, July 27, 2011 10:28 PM
> > >> To: Rose, Gregory V
> > >> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher,
> Jeffrey T
> > >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> > >>
> > >> From: Greg Rose <gregory.v.rose@intel.com>
> > >> Date: Wed, 27 Jul 2011 15:17:59 -0700
> > >>
> > >> > Add new set commands to configure the number of SR-IOV VFs, the
> > >> > number of VM queues and spoof checking on/off switch.
> > >> >
> > >> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > >> > ---
> > >> >
> > >> > include/linux/ethtool.h | 11 ++++++++++-
> > >> > 1 files changed, 10 insertions(+), 1 deletions(-)
> > >> >
> > >> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > >> > index c6e427a..c4972ba 100644
> > >> > --- a/include/linux/ethtool.h
> > >> > +++ b/include/linux/ethtool.h
> > >> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > >> > __u8 mdio_support;
> > >> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > >> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > >> > + __u32 num_vfs; /* Enable SR-IOV VFs */
> > >> > + __u32 num_vmqs; /* Set number of queues for VMDq */
> > >>
> > >> You can't change the layout of this datastructure in this way without
> > >> breaking every ethtool binary out there.
> > >>
> > >> You have to find another place to add these knobs.
> > >
> > > Perhaps at the end of the ethtool_cmd structure? Something like this:
> >
> > Either use the two reserved u32's we have there, or create a new
> > ethtool command and control structure.
>
> I'm going to insist on the latter. As I see it, struct ethtool_cmd is
> for Ethernet PHY settings. (The max{rx,tx}pkt fields weren't, but
> they're obsolete.)
OK, that's what I'll do.
- Greg
^ permalink raw reply
* Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Ben Hutchings @ 2011-07-28 21:20 UTC (permalink / raw)
To: Greg Rose; +Cc: netdev, davem, jeffrey.t.kirsher
In-Reply-To: <20110727221759.8435.11589.stgit@gitlad.jf.intel.com>
On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> Add new set commands to configure the number of SR-IOV VFs, the
> number of VM queues and spoof checking on/off switch.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> ---
>
> include/linux/ethtool.h | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c6e427a..c4972ba 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -36,12 +36,14 @@ struct ethtool_cmd {
> __u8 mdio_support;
> __u32 maxtxpkt; /* Tx pkts before generating tx int */
> __u32 maxrxpkt; /* Rx pkts before generating rx int */
> + __u32 num_vfs; /* Enable SR-IOV VFs */
What are the semantics of changing this after VFs have already been set
up?
> + __u32 num_vmqs; /* Set number of queues for VMDq */
VMDq is an Intel proprietary name. Please specify this in generic
terms.
> __u16 speed_hi; /* The forced speed (upper
> * bits) in Mbps. Please use
> * ethtool_cmd_speed()/_set() to
> * access it */
> __u8 eth_tp_mdix;
> - __u8 reserved2;
> + __u8 spoof_check; /* Enable/Disable anti-spoofing */
> __u32 lp_advertising; /* Features the link partner advertises */
> __u32 reserved[2];
> };
> @@ -1121,6 +1123,13 @@ struct ethtool_ops {
> #define AUTONEG_DISABLE 0x00
> #define AUTONEG_ENABLE 0x01
>
> +/* Enable or disable MAC and/or VLAN spoofchecking.If this is
> + * set to enable, then depending on the controller capabilities
> + * MAC and/or VLAN spoofing will be turned on.
> + */
> +#define SPOOFCHECK_DISABLE 0x00
> +#define SPOOFCHECK_ENABLE 0x01
I'm not sure it's necessary to continue defining macros for booleans.
This should not 'depend on controller capabilities'. If the
administrator tries to enable this feature on a device that does not
support it, the request must return an error rather than failing
silently. (This is another reason to define new commands.)
Ben.
> /* Mode MDI or MDI-X */
> #define ETH_TP_MDI_INVALID 0x00
> #define ETH_TP_MDI 0x01
>
--
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 net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 21:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, davem@davemloft.net, Kirsher, Jeffrey T
In-Reply-To: <1311888004.2677.18.camel@deadeye>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Ben Hutchings
> Sent: Thursday, July 28, 2011 2:20 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; davem@davemloft.net; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > Add new set commands to configure the number of SR-IOV VFs, the
> > number of VM queues and spoof checking on/off switch.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > ---
> >
> > include/linux/ethtool.h | 11 ++++++++++-
> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > index c6e427a..c4972ba 100644
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > __u8 mdio_support;
> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > + __u32 num_vfs; /* Enable SR-IOV VFs */
>
> What are the semantics of changing this after VFs have already been set
> up?
There's an example of it patch 4/4 in this set. The PF driver checks if any VFs are assigned and active and if not then it will disable and destroy all the current VFs via a call to pci_disable_sriov() and then call pci_enable_sriov() with the new number of VFs. Or, if the number of new VFs is zero then SR-IOV is left disabled on that PF.
Mostly this is to accommodate customer requests to be able to set a different number of VFs per PF or to only have specified PFs enable VFs. The current usage of the max_vfs module parameter is unwieldy in this sense as you must enable SR-IOV VFs on all physical functions found during the device probe with the same number of VFs.
>
> > + __u32 num_vmqs; /* Set number of queues for VMDq */
>
> VMDq is an Intel proprietary name. Please specify this in generic
> terms.
I'll use the more generic term VM queues.
>
> > __u16 speed_hi; /* The forced speed (upper
> > * bits) in Mbps. Please use
> > * ethtool_cmd_speed()/_set() to
> > * access it */
> > __u8 eth_tp_mdix;
> > - __u8 reserved2;
> > + __u8 spoof_check; /* Enable/Disable anti-spoofing */
> > __u32 lp_advertising; /* Features the link partner advertises */
> > __u32 reserved[2];
> > };
> > @@ -1121,6 +1123,13 @@ struct ethtool_ops {
> > #define AUTONEG_DISABLE 0x00
> > #define AUTONEG_ENABLE 0x01
> >
> > +/* Enable or disable MAC and/or VLAN spoofchecking.If this is
> > + * set to enable, then depending on the controller capabilities
> > + * MAC and/or VLAN spoofing will be turned on.
> > + */
> > +#define SPOOFCHECK_DISABLE 0x00
> > +#define SPOOFCHECK_ENABLE 0x01
>
> I'm not sure it's necessary to continue defining macros for booleans.
OK. I tend to just follow the conventions in the code I see when I'm not that familiar with it but in this case I'll just use true and false.
>
> This should not 'depend on controller capabilities'. If the
> administrator tries to enable this feature on a device that does not
> support it, the request must return an error rather than failing
> silently. (This is another reason to define new commands.)
Alright, I'll fix it up to work that way.
- Greg
^ permalink raw reply
* [PATCH 2/2] bna: HW Interface Init Update
From: Rasesh Mody @ 2011-07-28 21:49 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody
In-Reply-To: <1311889767-9848-1-git-send-email-rmody@brocade.com>
Change details:
- Split the hw interface into common and asic specific to support new asic
in the future.
- Fix bfa_ioc_ct_isr_mode_set() to also include the case that we are already
in the desired msix mode.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/bna/bfa_ioc_ct.c | 28 +++++++++++++++++-----------
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/net/bna/bfa_ioc_ct.c b/drivers/net/bna/bfa_ioc_ct.c
index c43f942..29b5fd0 100644
--- a/drivers/net/bna/bfa_ioc_ct.c
+++ b/drivers/net/bna/bfa_ioc_ct.c
@@ -50,26 +50,32 @@ static enum bfa_status bfa_ioc_ct_pll_init(void __iomem *rb, bool fcmode);
static struct bfa_ioc_hwif nw_hwif_ct;
+static void
+bfa_ioc_set_ctx_hwif(struct bfa_ioc *ioc, struct bfa_ioc_hwif *hwif)
+{
+ hwif->ioc_firmware_lock = bfa_ioc_ct_firmware_lock;
+ hwif->ioc_firmware_unlock = bfa_ioc_ct_firmware_unlock;
+ hwif->ioc_notify_fail = bfa_ioc_ct_notify_fail;
+ hwif->ioc_ownership_reset = bfa_ioc_ct_ownership_reset;
+ hwif->ioc_sync_start = bfa_ioc_ct_sync_start;
+ hwif->ioc_sync_join = bfa_ioc_ct_sync_join;
+ hwif->ioc_sync_leave = bfa_ioc_ct_sync_leave;
+ hwif->ioc_sync_ack = bfa_ioc_ct_sync_ack;
+ hwif->ioc_sync_complete = bfa_ioc_ct_sync_complete;
+}
+
/**
* Called from bfa_ioc_attach() to map asic specific calls.
*/
void
bfa_nw_ioc_set_ct_hwif(struct bfa_ioc *ioc)
{
+ bfa_ioc_set_ctx_hwif(ioc, &nw_hwif_ct);
+
nw_hwif_ct.ioc_pll_init = bfa_ioc_ct_pll_init;
- nw_hwif_ct.ioc_firmware_lock = bfa_ioc_ct_firmware_lock;
- nw_hwif_ct.ioc_firmware_unlock = bfa_ioc_ct_firmware_unlock;
nw_hwif_ct.ioc_reg_init = bfa_ioc_ct_reg_init;
nw_hwif_ct.ioc_map_port = bfa_ioc_ct_map_port;
nw_hwif_ct.ioc_isr_mode_set = bfa_ioc_ct_isr_mode_set;
- nw_hwif_ct.ioc_notify_fail = bfa_ioc_ct_notify_fail;
- nw_hwif_ct.ioc_ownership_reset = bfa_ioc_ct_ownership_reset;
- nw_hwif_ct.ioc_sync_start = bfa_ioc_ct_sync_start;
- nw_hwif_ct.ioc_sync_join = bfa_ioc_ct_sync_join;
- nw_hwif_ct.ioc_sync_leave = bfa_ioc_ct_sync_leave;
- nw_hwif_ct.ioc_sync_ack = bfa_ioc_ct_sync_ack;
- nw_hwif_ct.ioc_sync_complete = bfa_ioc_ct_sync_complete;
-
ioc->ioc_hwif = &nw_hwif_ct;
}
@@ -297,7 +303,7 @@ bfa_ioc_ct_isr_mode_set(struct bfa_ioc *ioc, bool msix)
/**
* If already in desired mode, do not change anything
*/
- if (!msix && mode)
+ if ((!msix && mode) || (msix && !mode))
return;
if (msix)
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: Rasesh Mody @ 2011-07-28 21:49 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody
Change details:
- ioc->cna is always set to 1 for eth functions, remove the check that
asserts IOC is in CNA mode in bfa_ioc_firmware_lock() and
bfa_ioc_firmware_unlock() in bfa_ioc_ct.c.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/bna/bfa_ioc_ct.c | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/drivers/net/bna/bfa_ioc_ct.c b/drivers/net/bna/bfa_ioc_ct.c
index 87aecdf..c43f942 100644
--- a/drivers/net/bna/bfa_ioc_ct.c
+++ b/drivers/net/bna/bfa_ioc_ct.c
@@ -84,12 +84,6 @@ bfa_ioc_ct_firmware_lock(struct bfa_ioc *ioc)
struct bfi_ioc_image_hdr fwhdr;
/**
- * Firmware match check is relevant only for CNA.
- */
- if (!ioc->cna)
- return true;
-
- /**
* If bios boot (flash based) -- do not increment usage count
*/
if (bfa_cb_image_get_size(BFA_IOC_FWIMG_TYPE(ioc)) <
@@ -140,12 +134,6 @@ bfa_ioc_ct_firmware_unlock(struct bfa_ioc *ioc)
u32 usecnt;
/**
- * Firmware lock is relevant only for CNA.
- */
- if (!ioc->cna)
- return;
-
- /**
* If bios boot (flash based) -- do not decrement usage count
*/
if (bfa_cb_image_get_size(BFA_IOC_FWIMG_TYPE(ioc)) <
--
1.7.1
^ permalink raw reply related
* Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Anirban Chakraborty @ 2011-07-28 22:01 UTC (permalink / raw)
To: Rose, Gregory V
Cc: David Miller, netdev, Ben Hutchings, Kirsher, Jeffrey T,
virtualization@lists.linux-foundation.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019414D86D@orsmsx508.amr.corp.intel.com>
On Jul 28, 2011, at 1:38 PM, Rose, Gregory V wrote:
>
>> From: Anirban Chakraborty [mailto:anirban.chakraborty@qlogic.com]
>> Sent: Thursday, July 28, 2011 12:04 PM
>> To: Rose, Gregory V
>> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T
>> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>>
>>
>> On Jul 28, 2011, at 8:51 AM, Rose, Gregory V wrote:
>>
>>
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Wednesday, July 27, 2011 10:28 PM
>> To: Rose, Gregory V
>> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
>> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>>
>> From: Greg Rose <gregory.v.rose@intel.com>
>> Date: Wed, 27 Jul 2011 15:17:59 -0700
>>
>> Add new set commands to configure the number of SR-IOV VFs, the
>> number of VM queues and spoof checking on/off switch.
>>
>> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>> ---
>>
>> include/linux/ethtool.h | 11 ++++++++++-
>> 1 files changed, 10 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index c6e427a..c4972ba 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -36,12 +36,14 @@ struct ethtool_cmd {
>> __u8 mdio_support;
>> __u32 maxtxpkt; /* Tx pkts before generating tx int */
>> __u32 maxrxpkt; /* Rx pkts before generating rx int */
>> + __u32 num_vfs; /* Enable SR-IOV VFs */
>> + __u32 num_vmqs; /* Set number of queues for VMDq */
>>
>> You can't change the layout of this datastructure in this way without
>> breaking every ethtool binary out there.
>>
>> You have to find another place to add these knobs.
>>
>> Perhaps at the end of the ethtool_cmd structure? Something like this:
>>
>> /* This should work for both 32 and 64 bit userland. */
>> struct ethtool_cmd {
>> __u32 cmd;
>> __u32 supported; /* Features this interface supports */
>> __u32 advertising; /* Features this interface advertises */
>> __u16 speed; /* The forced speed (lower bits) in
>> * Mbps. Please use
>> * ethtool_cmd_speed()/_set() to
>> * access it */
>> __u8 duplex; /* Duplex, half or full */
>> __u8 port; /* Which connector port */
>> __u8 phy_address;
>> __u8 transceiver; /* Which transceiver to use */
>> __u8 autoneg; /* Enable or disable autonegotiation */
>> __u8 mdio_support;
>> __u32 maxtxpkt; /* Tx pkts before generating tx int */
>> __u32 maxrxpkt; /* Rx pkts before generating rx int */
>> __u16 speed_hi; /* The forced speed (upper
>> * bits) in Mbps. Please use
>> * ethtool_cmd_speed()/_set() to
>> * access it */
>> __u8 eth_tp_mdix;
>> __u8 spoof_check; /* Enable/Disable anti-spoofing */
>> __u32 lp_advertising; /* Features the link partner advertises */
>> __u32 reserved[2];
>> __u32 num_vfs; /* Enable SR-IOV VFs */
>> __u32 num_vmqs; /* Set number of queues for VMDq */
>> };
>>
>> If I understood it correctly, you are trying to set/unset spoofing on per
>> eth interface, which could be a PF on the hypervisor or a pci passthru-ed
>> VF in the linux guest. There are other security features that one could set
>> for a port on the VF (lets call it vport), e.g. setting a port VLAN ID for
>> a VF and specifying if the VF (VM) is allowed to send tagged/untagged
>> packets, setting a vport in port mirroring mode so that the PF can monitor
>> the traffic on a VF, setting a vport in promiscuous mode etc.
>>
>> Does it make sense to try to use ip link util to specify all these parameters,
>> since ip link already does the job of setting VF properties and VF port
>> profile?
>>
>> Any thoughts?
>>
>
> Sure, that's a possibility too. I was considering ethtool for this since MAC addresses and VLANs are fairly specific to Ethernet whereas netlink might apply to other types of physical networks. At least that's my understanding.
You could specify VF MAC and VLANs using netlink today.
e.g. ip link set ethX vf # mac, vlan etc.
Adding spoofing as follows would do it.
ip link set ethX vf # spoof on|off
Having SR-IOV features scattered among ethtool and ip link may be inconvenient for the end users.
CC-ing virtualization list.
>
> However, I have no strong feelings about it and if community consensus is to use ip link instead then that's fine by me.
>
> Of course, patches implementing such would be quite welcome also.
I could take a stab at it at the netlink side, if there is a consensus.
-Anirban
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 22:04 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: David Miller, netdev, Ben Hutchings, Kirsher, Jeffrey T,
virtualization@lists.linux-foundation.org
In-Reply-To: <789BE5A3-93DF-4869-A0AF-180AA86F4AC6@qlogic.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Anirban Chakraborty
> Sent: Thursday, July 28, 2011 3:01 PM
> To: Rose, Gregory V
> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T;
> virtualization@lists.linux-foundation.org
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
>
> On Jul 28, 2011, at 1:38 PM, Rose, Gregory V wrote:
>
> >
> >> From: Anirban Chakraborty [mailto:anirban.chakraborty@qlogic.com]
> >> Sent: Thursday, July 28, 2011 12:04 PM
> >> To: Rose, Gregory V
> >> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T
> >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> >>
> >>
> >> If I understood it correctly, you are trying to set/unset spoofing on
> per
> >> eth interface, which could be a PF on the hypervisor or a pci
> passthru-ed
> >> VF in the linux guest. There are other security features that one
> could set
> >> for a port on the VF (lets call it vport), e.g. setting a port VLAN ID
> for
> >> a VF and specifying if the VF (VM) is allowed to send tagged/untagged
> >> packets, setting a vport in port mirroring mode so that the PF can
> monitor
> >> the traffic on a VF, setting a vport in promiscuous mode etc.
> >>
> >> Does it make sense to try to use ip link util to specify all these
> parameters,
> >> since ip link already does the job of setting VF properties and VF
> port
> >> profile?
> >>
> >> Any thoughts?
> >>
> >
> > Sure, that's a possibility too. I was considering ethtool for this
> since MAC addresses and VLANs are fairly specific to Ethernet whereas
> netlink might apply to other types of physical networks. At least that's
> my understanding.
>
> You could specify VF MAC and VLANs using netlink today.
> e.g. ip link set ethX vf # mac, vlan etc.
> Adding spoofing as follows would do it.
> ip link set ethX vf # spoof on|off
>
> Having SR-IOV features scattered among ethtool and ip link may be
> inconvenient for the end users.
> CC-ing virtualization list.
>
> >
> > However, I have no strong feelings about it and if community consensus
> is to use ip link instead then that's fine by me.
> >
> > Of course, patches implementing such would be quite welcome also.
>
> I could take a stab at it at the netlink side, if there is a consensus.
Now that I think about it I'm seeing it more your way. I'll drop the anti-spoofing stuff from my ethtool patches. If you get the time to provide patches to netlink for anti-spoofing then that's great, otherwise I'll do it when I get done with the SR-IOV reconfig stuff.
Thanks,
- Greg
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Ben Hutchings @ 2011-07-28 22:04 UTC (permalink / raw)
To: Rose, Gregory V
Cc: netdev@vger.kernel.org, davem@davemloft.net, Kirsher, Jeffrey T
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019414D910@orsmsx508.amr.corp.intel.com>
On Thu, 2011-07-28 at 14:34 -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> > On Behalf Of Ben Hutchings
> > Sent: Thursday, July 28, 2011 2:20 PM
> > To: Rose, Gregory V
> > Cc: netdev@vger.kernel.org; davem@davemloft.net; Kirsher, Jeffrey T
> > Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> >
> > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > Add new set commands to configure the number of SR-IOV VFs, the
> > > number of VM queues and spoof checking on/off switch.
> > >
> > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > ---
> > >
> > > include/linux/ethtool.h | 11 ++++++++++-
> > > 1 files changed, 10 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > > index c6e427a..c4972ba 100644
> > > --- a/include/linux/ethtool.h
> > > +++ b/include/linux/ethtool.h
> > > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > > __u8 mdio_support;
> > > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > > + __u32 num_vfs; /* Enable SR-IOV VFs */
> >
> > What are the semantics of changing this after VFs have already been set
> > up?
>
> There's an example of it patch 4/4 in this set. The PF driver checks
> if any VFs are assigned and active and if not then it will disable and
> destroy all the current VFs via a call to pci_disable_sriov() and then
> call pci_enable_sriov() with the new number of VFs. Or, if the number
> of new VFs is zero then SR-IOV is left disabled on that PF.
And otherwise the request fails?
> Mostly this is to accommodate customer requests to be able to set a
> different number of VFs per PF or to only have specified PFs enable
> VFs. The current usage of the max_vfs module parameter is unwieldy in
> this sense as you must enable SR-IOV VFs on all physical functions
> found during the device probe with the same number of VFs.
Right, this makes a lot of sense.
> > > + __u32 num_vmqs; /* Set number of queues for VMDq */
> >
> > VMDq is an Intel proprietary name. Please specify this in generic
> > terms.
>
> I'll use the more generic term VM queues.
[...]
Still ambiguous. I think what you actually intend is that this will be
the number of RX queues and the number of TX queues per VF. Right?
You might want to allow for different numbers of RX and TX queues.
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
* drivers/net/tun.c: CAP_NET_ADMIN conditional not reached
From: Petar Bogdanovic @ 2011-07-28 22:00 UTC (permalink / raw)
To: netdev
Hi,
drivers/net/tun.c says:
1004 if (((tun->owner != -1 && cred->euid != tun->owner) ||
1005 (tun->group != -1 && !in_egroup_p(tun->group))) &&
1006 !capable(CAP_NET_ADMIN))
1007 return -EPERM;
this will skip !capable(CAP_NET_ADMIN) if tun->owner and tun->group are
both -1, which seems to be their default value (see lines 854,855).
ip(8) from iproute2 won't do any TUNSETOWNER/TUNSETGROUP ioctl() if no
uid and/or gid is supplied so when using `ip tuntap' as an unprivileged
user, you'll be unable to create a new tun(4) but won't have any
problems attaching to an existing device created without both user and
group options.
I'm not sure whether this is intentional since it has been around for
years.. although triggering it with tunctl(8) was not possible---tunctl
without `-u' seems to use 0 as the default value for TUNSETOWNER.
Petar Bogdanovic
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 22:25 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, davem@davemloft.net, Kirsher, Jeffrey T
In-Reply-To: <1311890667.2677.22.camel@deadeye>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Thursday, July 28, 2011 3:04 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; davem@davemloft.net; Kirsher, Jeffrey T
> Subject: RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> On Thu, 2011-07-28 at 14:34 -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org]
> > > On Behalf Of Ben Hutchings
> > > Sent: Thursday, July 28, 2011 2:20 PM
> > > To: Rose, Gregory V
> > > Cc: netdev@vger.kernel.org; davem@davemloft.net; Kirsher, Jeffrey T
> > > Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> > >
> > > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > > Add new set commands to configure the number of SR-IOV VFs, the
> > > > number of VM queues and spoof checking on/off switch.
> > > >
> > > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > > ---
> > > >
> > > > include/linux/ethtool.h | 11 ++++++++++-
> > > > 1 files changed, 10 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > > > index c6e427a..c4972ba 100644
> > > > --- a/include/linux/ethtool.h
> > > > +++ b/include/linux/ethtool.h
> > > > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > > > __u8 mdio_support;
> > > > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > > > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > > > + __u32 num_vfs; /* Enable SR-IOV VFs */
> > >
> > > What are the semantics of changing this after VFs have already been
> set
> > > up?
> >
> > There's an example of it patch 4/4 in this set. The PF driver checks
> > if any VFs are assigned and active and if not then it will disable and
> > destroy all the current VFs via a call to pci_disable_sriov() and then
> > call pci_enable_sriov() with the new number of VFs. Or, if the number
> > of new VFs is zero then SR-IOV is left disabled on that PF.
>
> And otherwise the request fails?
Yes, it returns -EBUSY if VFs are in use (assigned to guest VMs) or the PF driver is up and running. It can return other errors from the post configuration setup of interrupt resources.
>
> > Mostly this is to accommodate customer requests to be able to set a
> > different number of VFs per PF or to only have specified PFs enable
> > VFs. The current usage of the max_vfs module parameter is unwieldy in
> > this sense as you must enable SR-IOV VFs on all physical functions
> > found during the device probe with the same number of VFs.
>
> Right, this makes a lot of sense.
>
> > > > + __u32 num_vmqs; /* Set number of queues for VMDq */
> > >
> > > VMDq is an Intel proprietary name. Please specify this in generic
> > > terms.
> >
> > I'll use the more generic term VM queues.
> [...]
>
> Still ambiguous. I think what you actually intend is that this will be
> the number of RX queues and the number of TX queues per VF. Right?
> You might want to allow for different numbers of RX and TX queues.
OK, that's not a problem. Our devices only support matching numbers of queue pairs but I suppose other devices might have the ability to have different numbers of Rx/Tx queues per VF. I'll rework it that way while I'm adding the new command.
The number of queues might also be used in a scenario similar to the VMware Net Queues (TM) feature. There is no support for that in Linux at the moment but it could be supported in the future.
- Greg
^ permalink raw reply
* Add support for D-Link 530T rev C1 (Kernel Bug 38862)
From: Lennart Sorensen @ 2011-07-28 23:18 UTC (permalink / raw)
To: netdev
Cc: Len Sorensen, linux-kernel, Realtek linux nic maintainers,
Francois Romieu, drivers_network
The D-Link DGE-530T rev C1 is a re-badged Realtek 8169 named DLG10028C,
unlike the previous revisions which were skge based. It is probably
the same as the discontinued DGE-528T (0x4300) other than the PCI ID.
The PCI ID is 0x1186:0x4302.
Adding it to r8169.c where 0x1186:0x4300 is already found makes the card
be detected and work.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=38862
Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7d9c650..c77286e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -239,6 +239,7 @@ static DEFINE_PCI_DEVICE_TABLE(rtl8169_pci_tbl) = {
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), 0, 0, RTL_CFG_1 },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4302), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_AT, 0xc107), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS, 0x1032,
--
Len Sorensen
^ permalink raw reply related
* Re: [PATCH 05/14] userns: clamp down users of cap_raised
From: Vasiliy Kulikov @ 2011-07-28 23:23 UTC (permalink / raw)
To: Serge Hallyn; +Cc: linux-kernel, netdev, containers, dhowells, ebiederm
In-Reply-To: <1311706717-7398-6-git-send-email-serge@hallyn.com>
On Tue, Jul 26, 2011 at 18:58 +0000, Serge Hallyn wrote:
> From: Serge E. Hallyn <serge.hallyn@canonical.com>
>
> A few modules are using cap_raised(current_cap(), cap) to authorize
> actions, but the privilege should be applicable against the initial
> user namespace. Refuse privilege if the caller is not in init_user_ns.
>
> Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> ---
> drivers/block/drbd/drbd_nl.c | 5 +++++
> drivers/md/dm-log-userspace-transfer.c | 3 +++
> drivers/staging/pohmelfs/config.c | 3 +++
> drivers/video/uvesafb.c | 3 +++
> 4 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
> index 515bcd9..7717f8a 100644
> --- a/drivers/block/drbd/drbd_nl.c
> +++ b/drivers/block/drbd/drbd_nl.c
> @@ -2297,6 +2297,11 @@ static void drbd_connector_callback(struct cn_msg *req, struct netlink_skb_parms
> return;
> }
>
> + if (current_user_ns() != &init_user_ns) {
[...]
> if (!cap_raised(current_cap(), CAP_SYS_ADMIN)) {
[...]
Looks like it is an often pattern. Maybe move both checks to a
function?
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: Add support for D-Link 530T rev C1 (Kernel Bug 38862)
From: Stephen Hemminger @ 2011-07-28 23:34 UTC (permalink / raw)
To: Lennart Sorensen
Cc: netdev, linux-kernel, Realtek linux nic maintainers,
Francois Romieu, drivers_network
In-Reply-To: <20110728231811.GH8562@caffeine.csclub.uwaterloo.ca>
On Thu, 28 Jul 2011 19:18:11 -0400
lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> The D-Link DGE-530T rev C1 is a re-badged Realtek 8169 named DLG10028C,
> unlike the previous revisions which were skge based. It is probably
> the same as the discontinued DGE-528T (0x4300) other than the PCI ID.
>
> The PCI ID is 0x1186:0x4302.
>
> Adding it to r8169.c where 0x1186:0x4300 is already found makes the card
> be detected and work.
>
> This fixes https://bugzilla.kernel.org/show_bug.cgi?id=38862
>
> Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
Glad they at least changed the PCI-ID this time.
Other vendors have been known to do it wrong.
^ permalink raw reply
* Re: Add support for D-Link 530T rev C1 (Kernel Bug 38862)
From: Lennart Sorensen @ 2011-07-28 23:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Lennart Sorensen, netdev, linux-kernel,
Realtek linux nic maintainers, Francois Romieu
In-Reply-To: <20110728163434.4d3bb048@nehalam.ftrdhcpuser.net>
On Thu, Jul 28, 2011 at 04:34:34PM -0700, Stephen Hemminger wrote:
> Glad they at least changed the PCI-ID this time.
> Other vendors have been known to do it wrong.
No kidding. Ick.
--
Len Sorensen
^ permalink raw reply
* Re: [PATCH 05/14] userns: clamp down users of cap_raised
From: Serge E. Hallyn @ 2011-07-28 23:51 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: Serge Hallyn, dhowells, netdev, containers, linux-kernel,
ebiederm
In-Reply-To: <20110728232337.GA9186@albatros>
Quoting Vasiliy Kulikov (segooon@gmail.com):
> On Tue, Jul 26, 2011 at 18:58 +0000, Serge Hallyn wrote:
> > From: Serge E. Hallyn <serge.hallyn@canonical.com>
> >
> > A few modules are using cap_raised(current_cap(), cap) to authorize
> > actions, but the privilege should be applicable against the initial
> > user namespace. Refuse privilege if the caller is not in init_user_ns.
> >
> > Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
> > Cc: Eric W. Biederman <ebiederm@xmission.com>
> > ---
> > drivers/block/drbd/drbd_nl.c | 5 +++++
> > drivers/md/dm-log-userspace-transfer.c | 3 +++
> > drivers/staging/pohmelfs/config.c | 3 +++
> > drivers/video/uvesafb.c | 3 +++
> > 4 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
> > index 515bcd9..7717f8a 100644
> > --- a/drivers/block/drbd/drbd_nl.c
> > +++ b/drivers/block/drbd/drbd_nl.c
> > @@ -2297,6 +2297,11 @@ static void drbd_connector_callback(struct cn_msg *req, struct netlink_skb_parms
> > return;
> > }
> >
> > + if (current_user_ns() != &init_user_ns) {
> [...]
> > if (!cap_raised(current_cap(), CAP_SYS_ADMIN)) {
> [...]
>
> Looks like it is an often pattern. Maybe move both checks to a
> function?
This pattern is used 4 times (IIRC). The reason I didn't break it out is
that it's very close to just 'capable(CAP_SYS_ADMIN)', which also checks
for CAP_SYS_ADMIN to the init_user_ns. But the above, rightly or wrongly,
does not set the PF_SUPERPRIV task flag. I don't want to advocate usage
of the above, and creating a helper for the above would both further
pollute the capability-related function namespace, and make the above
look more legitimate than I think it is.
Imo 'cap-raised(current_cap(), X)' should not be used at all. But I
didn't want to deal with that here, just make it user-ns safe.
-serge
^ permalink raw reply
* Re: [PATCH] xfrm: Fix key lengths for rfc3686(ctr(aes))
From: Herbert Xu @ 2011-07-29 0:05 UTC (permalink / raw)
To: Tushar Gohad; +Cc: Joy Latten, netdev
In-Reply-To: <alpine.LFD.1.10.1107281246381.11308@net-test1.az.mvista.com>
On Thu, Jul 28, 2011 at 01:36:20PM -0700, Tushar Gohad wrote:
>
> Fix the min and max bit lengths for AES-CTR (RFC3686) keys.
> The number of bits in key spec is the key length (128/256)
> plus 32 bits of nonce.
>
> This change takes care of the "Invalid key length" errors
> reported by setkey when specifying 288 bit keys for aes-ctr.
>
> Signed-off-by: Tushar Gohad <tgohad@mvista.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [GIT PULL nf-2.6] IPVS
From: Simon Horman @ 2011-07-29 0:12 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, Dave Jones, Randy Dunlap, Huajun Li,
David S. Miller
In-Reply-To: <1311293920-1983-1-git-send-email-horms@verge.net.au>
On Fri, Jul 22, 2011 at 09:18:39AM +0900, Simon Horman wrote:
> Hi Pablo, Hi Patrick,
>
> please consider pulling
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-2.6.git master
>
> to get the following crash on module removal fix for IPVS.
>
> Sorry for sending this so very, very late in the release cycle.
> I had sent it earlier but it seems to have slipped through the cracks
> somehow.
>
> Simon Horman (1):
> IPVS: Free resources on module removal
>
> net/netfilter/ipvs/ip_vs_ctl.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Ping.
What is the best way forward to get this both in 3.1 and 3.0 -stable?
^ permalink raw reply
* Re: [PATCH] sis190: Rx filter init is needed for MAC address change.
From: David Miller @ 2011-07-29 1:18 UTC (permalink / raw)
To: romieu; +Cc: netdev, klement2
In-Reply-To: <20110728160322.GA11480@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 28 Jul 2011 18:03:22 +0200
> From: Klement Fish <klement2@azet.sk>
>
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=34552
>
> Signed-off-by: Klement Fish <klement2@azet.sk>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix new sunrpc kernel-doc warning
From: David Miller @ 2011-07-29 1:20 UTC (permalink / raw)
To: rdunlap; +Cc: netdev
In-Reply-To: <20110728095436.6fdb3eb4.rdunlap@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Thu, 28 Jul 2011 09:54:36 -0700
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Fix new kernel-doc warning in sunrpc:
>
> Warning(net/sunrpc/xprt.c:196): No description found for parameter 'xprt'
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Applied.
^ permalink raw reply
* Re: Oops when insmod rtl8192ce
From: Hubert Liao @ 2011-07-29 1:21 UTC (permalink / raw)
To: Larry Finger
Cc: John W. Linville, wlanfae, Chaoming Li, linux-wireless, netdev,
linux-kernel
In-Reply-To: <4E31788F.7000307@lwfinger.net>
2011/7/28 Larry Finger <Larry.Finger@lwfinger.net>:
> On 07/28/2011 02:06 AM, hubert Liao wrote:
>>
>> 2011/7/27 John W. Linville<linville@tuxdriver.com>:
>>>
>>> On Wed, Jul 27, 2011 at 05:20:15PM +0800, hubert Liao wrote:
>>>>
>>>> Hi,
>>>>
>>>> We got an oops when insmod rtl8192ce module (the board is an ARM soc),
>>>> accroding the oops message, find it's because in rtl_pci_probe() called
>>>> _rtl_pci_find_adapter(),
>>>> in this funcation, the pdev->bus->self is a NULL pointer .
>>>>
>>>> static boot _rtl_pci_find_adapter(strcut pci_dev *dev,
>>>> struct ieee80211_hw *hw)
>>>> {
>>>>
>>>> struct pci_dev *bridge_pdev = pdev->bus->self; //line 1601
>>>> ...
>>>>
>>>> pcipriv->ndis_adapter.pcibridge_vendorid = bridge_pdev->vendor;<-- [oops
>>>> here] line 1700
>>>>
>>>> ...
>>>> }
>>>>
>>>> here, I just want to know why the bus->self is NULL?
>>>
>>> pdev is coming straight from what is passed to the PCI probe routine.
>>> It seems like pdev->bus->self should already be set before that
>>> happens.
>>>
>> Yes, I think it should be initialized when added the pci bus bridge,
>> I have checked the mach-kirkwood(my board is arch/arm/mach-kirkwood)
>> pcie related code, and I think when system initialized should call
>> kirkwood_pcie_init() ->
>> kirkwood_pcie_scan_bus() ->
>> pci_scan_bus() ->
>> pci_bus_add_devices()
>> if the pci_bus->self was initialized in pci_bus_add_devices()?
>> Maybe the code is too complex for me , I really can not find where
>> set the “->self" member?
>
> I added a request to the bugzilla entry to post the full dmesg output there.
> Perhaps there is some clue in the bus setup.
>
I have added the full dmesg output on bugzilla.
thanks.
> Larry
>
>
^ 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