* Re: linux-next: manual merge of the ipsec-next tree with the net-next tree
From: Stephen Rothwell @ 2013-09-27 2:01 UTC (permalink / raw)
To: Steffen Klassert
Cc: linux-next, linux-kernel, Fan Du, Joe Perches, David Miller,
netdev
In-Reply-To: <20130925052923.GU7660@secunet.com>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
Hi Steffen,
On Wed, 25 Sep 2013 07:29:23 +0200 Steffen Klassert <steffen.klassert@secunet.com> wrote:
>
> On Wed, Sep 25, 2013 at 09:59:19AM +1000, Stephen Rothwell wrote:
> >
> > On Tue, 24 Sep 2013 12:25:05 +0200 Steffen Klassert <steffen.klassert@secunet.com> wrote:
> > >
> > > On Tue, Sep 24, 2013 at 12:16:29PM +1000, Stephen Rothwell wrote:
> > > >
> > > > Today's linux-next merge of the ipsec-next tree got a conflict in
> > > > include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
> > > > from function prototypes") from the net-next tree and commit aba826958830
> > > > ("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
> > > > callback") from the ipsec-next tree.
> > >
> > > Thanks for the information, I'll do a rebase of the ipsec-next
> > > tree tomorrow.
> >
> > Did you miss the end of the next paragraph: "no action is required"?
> > Dave can fix this up (like I did) when he merges your tree into his.
>
> I applied this patch shortly before the merge window opened, it is a left
> over from the last develpoment cycle. I already rebased my tree onto
> net-next in the past if that happened, even if there were no merge
> conflicts. I did that just to see if everything still works. But I
> could also do a test merge to see if everything still works and ask
> to pull without a rebase then if this is the prefered way. Would make
> my life easier :)
That would be up to Dave ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the wireless tree
From: Stephen Rothwell @ 2013-09-27 3:03 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Arend van Spriel, John W. Linville,
Joe Perches
[-- Attachment #1: Type: text/plain, Size: 2860 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h between commit
db4efbbeb457 ("brcmfmac: obtain platform data upon module
initialization") from the wireless tree and commit 9bd91f3c00bd
("brcm80211: Remove extern from function prototypes") from the net-next
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
index 74156f8,5bc0276..0000000
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
@@@ -132,35 -132,33 +132,34 @@@ struct pktq *brcmf_bus_gettxq(struct br
* interface functions from common layer
*/
- extern bool brcmf_c_prec_enq(struct device *dev, struct pktq *q,
- struct sk_buff *pkt, int prec);
+ bool brcmf_c_prec_enq(struct device *dev, struct pktq *q, struct sk_buff *pkt,
+ int prec);
/* Receive frame for delivery to OS. Callee disposes of rxp. */
- extern void brcmf_rx_frames(struct device *dev, struct sk_buff_head *rxlist);
+ void brcmf_rx_frames(struct device *dev, struct sk_buff_head *rxlist);
/* Indication from bus module regarding presence/insertion of dongle. */
- extern int brcmf_attach(uint bus_hdrlen, struct device *dev);
+ int brcmf_attach(uint bus_hdrlen, struct device *dev);
/* Indication from bus module regarding removal/absence of dongle */
- extern void brcmf_detach(struct device *dev);
+ void brcmf_detach(struct device *dev);
/* Indication from bus module that dongle should be reset */
- extern void brcmf_dev_reset(struct device *dev);
+ void brcmf_dev_reset(struct device *dev);
/* Indication from bus module to change flow-control state */
- extern void brcmf_txflowblock(struct device *dev, bool state);
+ void brcmf_txflowblock(struct device *dev, bool state);
/* Notify the bus has transferred the tx packet to firmware */
- extern void brcmf_txcomplete(struct device *dev, struct sk_buff *txp,
- bool success);
+ void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
- extern int brcmf_bus_start(struct device *dev);
+ int brcmf_bus_start(struct device *dev);
#ifdef CONFIG_BRCMFMAC_SDIO
- extern void brcmf_sdio_exit(void);
- extern void brcmf_sdio_init(void);
- extern void brcmf_sdio_register(void);
+ void brcmf_sdio_exit(void);
+ void brcmf_sdio_init(void);
++void brcmf_sdio_register(void);
#endif
#ifdef CONFIG_BRCMFMAC_USB
- extern void brcmf_usb_exit(void);
- extern void brcmf_usb_register(void);
+ void brcmf_usb_exit(void);
-void brcmf_usb_init(void);
++void brcmf_usb_register(void);
#endif
#endif /* _BRCMF_BUS_H_ */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the wireless-next tree with the net-next tree
From: Stephen Rothwell @ 2013-09-27 3:19 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, linux-kernel, Joe Perches, David Miller, netdev,
Catalin Iacob
[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/rtlwifi/rtl8192ce/phy.h between commit a958df5dc306
("rtlwifi: Remove extern from function prototypes") from the net-next
tree and commit 3a1ea9fd9351 ("rtlwifi: remove duplicate declarations and
macros in headers") from the wireless-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
index f8973e5,80a0893..0000000
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
@@@ -217,10 -222,10 +215,9 @@@ void _rtl92ce_phy_lc_calibrate(struct i
void rtl92c_phy_set_rfpath_switch(struct ieee80211_hw *hw, bool bmain);
bool rtl92c_phy_config_rf_with_headerfile(struct ieee80211_hw *hw,
enum radio_path rfpath);
-bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw,
- u32 rfpath);
+bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw, u32 rfpath);
- bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
bool rtl92ce_phy_set_rf_power_state(struct ieee80211_hw *hw,
- enum rf_pwrstate rfpwr_state);
+ enum rf_pwrstate rfpwr_state);
void rtl92ce_phy_set_rf_on(struct ieee80211_hw *hw);
bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
void rtl92c_phy_set_io(struct ieee80211_hw *hw);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH 08/11] iwlwifi: Remove extern from function prototypes
From: Grumbach, Emmanuel @ 2013-09-27 4:25 UTC (permalink / raw)
To: Joe Perches, netdev@vger.kernel.org
Cc: David S. Miller, Berg, Johannes, Intel Linux Wireless,
John W. Linville, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <b3818394ccdf68d834ca1060c1d5a1fc44e2daee.1380137610.git.joe@perches.com>
> Subject: [PATCH 08/11] iwlwifi: Remove extern from function prototypes
>
> There are a mix of function prototypes with and without extern in the kernel
> sources. Standardize on not using extern for function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler. Its use is as unnecessary as using auto to
> declare automatic/local variables in a block.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/wireless/iwlwifi/dvm/agn.h | 2 +-
> drivers/net/wireless/iwlwifi/dvm/dev.h | 2 +-
> drivers/net/wireless/iwlwifi/dvm/rs.h | 8 ++++----
> drivers/net/wireless/iwlwifi/mvm/rs.h | 9 ++++-----
> 4 files changed, 10 insertions(+), 11 deletions(-)
>
ACK
^ permalink raw reply
* Re: [PATCH 1/4] [RFC] net: Explicitly initialize u64_stats_sync structures for lockdep
From: Ingo Molnar @ 2013-09-27 5:44 UTC (permalink / raw)
To: Eric Dumazet
Cc: John Stultz, LKML, Thomas Petazzoni, Mirko Lindner,
Stephen Hemminger, Roger Luethi, Patrick McHardy, Rusty Russell,
Michael S. Tsirkin, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Wensong Zhang, Simon Horman, Julian Anastasov,
Jesse Gross, Mathieu Desnoyers, Steven Rostedt, Peter Zijlstra,
Thomas Gleixner, David S. Miller, netdev, netfilter-devel
In-Reply-To: <1380223585.3165.205.camel@edumazet-glaptop>
* Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2013-09-26 at 11:34 -0700, John Stultz wrote:
> > In order to enable lockdep on seqcount/seqlock structures, we
> > must explicitly initialize any locks.
> >
>
> > diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
> > index 8da8c4e..c450e11 100644
> > --- a/include/linux/u64_stats_sync.h
> > +++ b/include/linux/u64_stats_sync.h
> > @@ -67,6 +67,13 @@ struct u64_stats_sync {
> > #endif
> > };
> >
> > +
> > +#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
> > +#define u64_stats_init(syncp) seqcount_init(syncp.seq)
> > +#else
> > +#define u64_stats_init(syncp)
> > +#endif
> > +
>
> I would prefer a function.
C cannot pass along symbolic names, unfortunately, so we are stuck with
1970's tech and the C preprocessor.
There's a way to make such macros look a tiny bit more structured and thus
be more palatable:
#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
# define u64_stats_init(syncp) seqcount_init(syncp.seq)
#else
# define u64_stats_init(syncp)
#endif
Note, the 'else' branch should probably be:
# define u64_stats_init(syncp) do { } while (0)
Thanks,
Ingo
^ permalink raw reply
* [PATCH net-next] virtio-net: switch to use XPS to choose txq
From: Jason Wang @ 2013-09-27 5:57 UTC (permalink / raw)
To: netdev, linux-kernel, virtualization; +Cc: Michael S. Tsirkin
We used to use a percpu structure vq_index to record the cpu to queue
mapping, this is suboptimal since it duplicates the work of XPS and
loses all other XPS functionality such as allowing use to configure
their own transmission steering strategy.
So this patch switches to use XPS and suggest a default mapping when
the number of cpus is equal to the number of queues. With XPS support,
there's no need for keeping per-cpu vq_index and .ndo_select_queue(),
so they were removed also.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 55 +++++++--------------------------------------
1 files changed, 9 insertions(+), 46 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index defec2b..4102c1b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -127,9 +127,6 @@ struct virtnet_info {
/* Does the affinity hint is set for virtqueues? */
bool affinity_hint_set;
- /* Per-cpu variable to show the mapping from CPU to virtqueue */
- int __percpu *vq_index;
-
/* CPU hot plug notifier */
struct notifier_block nb;
};
@@ -1063,7 +1060,6 @@ static int virtnet_vlan_rx_kill_vid(struct net_device *dev,
static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
{
int i;
- int cpu;
if (vi->affinity_hint_set) {
for (i = 0; i < vi->max_queue_pairs; i++) {
@@ -1073,20 +1069,11 @@ static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
vi->affinity_hint_set = false;
}
-
- i = 0;
- for_each_online_cpu(cpu) {
- if (cpu == hcpu) {
- *per_cpu_ptr(vi->vq_index, cpu) = -1;
- } else {
- *per_cpu_ptr(vi->vq_index, cpu) =
- ++i % vi->curr_queue_pairs;
- }
- }
}
static void virtnet_set_affinity(struct virtnet_info *vi)
{
+ cpumask_var_t cpumask;
int i;
int cpu;
@@ -1100,15 +1087,21 @@ static void virtnet_set_affinity(struct virtnet_info *vi)
return;
}
+ if (!alloc_cpumask_var(&cpumask, GFP_KERNEL))
+ return;
+
i = 0;
for_each_online_cpu(cpu) {
virtqueue_set_affinity(vi->rq[i].vq, cpu);
virtqueue_set_affinity(vi->sq[i].vq, cpu);
- *per_cpu_ptr(vi->vq_index, cpu) = i;
+ cpumask_clear(cpumask);
+ cpumask_set_cpu(cpu, cpumask);
+ netif_set_xps_queue(vi->dev, cpumask, i);
i++;
}
vi->affinity_hint_set = true;
+ free_cpumask_var(cpumask);
}
static int virtnet_cpu_callback(struct notifier_block *nfb,
@@ -1217,28 +1210,6 @@ static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
-/* To avoid contending a lock hold by a vcpu who would exit to host, select the
- * txq based on the processor id.
- */
-static u16 virtnet_select_queue(struct net_device *dev, struct sk_buff *skb)
-{
- int txq;
- struct virtnet_info *vi = netdev_priv(dev);
-
- if (skb_rx_queue_recorded(skb)) {
- txq = skb_get_rx_queue(skb);
- } else {
- txq = *__this_cpu_ptr(vi->vq_index);
- if (txq == -1)
- txq = 0;
- }
-
- while (unlikely(txq >= dev->real_num_tx_queues))
- txq -= dev->real_num_tx_queues;
-
- return txq;
-}
-
static const struct net_device_ops virtnet_netdev = {
.ndo_open = virtnet_open,
.ndo_stop = virtnet_close,
@@ -1250,7 +1221,6 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_get_stats64 = virtnet_stats,
.ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
- .ndo_select_queue = virtnet_select_queue,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = virtnet_netpoll,
#endif
@@ -1559,10 +1529,6 @@ static int virtnet_probe(struct virtio_device *vdev)
if (vi->stats == NULL)
goto free;
- vi->vq_index = alloc_percpu(int);
- if (vi->vq_index == NULL)
- goto free_stats;
-
mutex_init(&vi->config_lock);
vi->config_enable = true;
INIT_WORK(&vi->config_work, virtnet_config_changed_work);
@@ -1589,7 +1555,7 @@ static int virtnet_probe(struct virtio_device *vdev)
/* Allocate/initialize the rx/tx queues, and invoke find_vqs */
err = init_vqs(vi);
if (err)
- goto free_index;
+ goto free_stats;
netif_set_real_num_tx_queues(dev, 1);
netif_set_real_num_rx_queues(dev, 1);
@@ -1640,8 +1606,6 @@ free_recv_bufs:
free_vqs:
cancel_delayed_work_sync(&vi->refill);
virtnet_del_vqs(vi);
-free_index:
- free_percpu(vi->vq_index);
free_stats:
free_percpu(vi->stats);
free:
@@ -1678,7 +1642,6 @@ static void virtnet_remove(struct virtio_device *vdev)
flush_work(&vi->config_work);
- free_percpu(vi->vq_index);
free_percpu(vi->stats);
free_netdev(vi->dev);
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next 1/5] tipc: silence sparse warnings
From: David Miller @ 2013-09-27 5:59 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, paul.gortmaker, erik.hugne, ying.xue, maloy,
tipc-discussion, andreas.bofjall
In-Reply-To: <1380014868-2797-2-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 24 Sep 2013 04:27:44 -0500
> From: Ying Xue <ying.xue@windriver.com>
>
> Eliminate below sparse warnings:
>
> net/tipc/link.c:1210:37: warning: cast removes address space of expression
> net/tipc/link.c:1218:59: warning: incorrect type in argument 2 (different address spaces)
> net/tipc/link.c:1218:59: expected void const [noderef] <asn:1>*from
> net/tipc/link.c:1218:59: got unsigned char const [usertype] *[assigned] sect_crs
> net/tipc/msg.c:96:61: warning: incorrect type in argument 3 (different address spaces)
> net/tipc/msg.c:96:61: expected void const *from
> net/tipc/msg.c:96:61: got void [noderef] <asn:1>*const iov_base
> net/tipc/socket.c:341:49: warning: Using plain integer as NULL pointer
> net/tipc/socket.c:1371:36: warning: Using plain integer as NULL pointer
> net/tipc/socket.c:1694:57: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Andreas Bofjäll <andreas.bofjall@ericsson.com>
> Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
These warnings are not just for fun, and they are certainly not an
invitation to stick casts all over the place to make them go away.
They indicate real problems in the TIPC code.
There really are user pointers in the iovecs here, and that's why the
iov_base member is annotated with "__user".
These iovecs carry pointers that come from userspace via socket calls.
And you absolutely cannot pass user pointers to skb_copy_to_linear_data()
and friends as they access the source pointer using memcpy().
You have to use the proper interfaces for accessing userspace memory,
ones that have their arguments annotated with __user.
I'm not applying this series, sorry.
^ permalink raw reply
* Re: pull-request: can 2013-09-21
From: David Miller @ 2013-09-27 6:08 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <1379772493-7856-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Sat, 21 Sep 2013 16:08:12 +0200
> here is a fixes for the v3.12 release cycle. Alexey Khoroshilov from the Linux
> Driver Verification project submitted a patch that fixes a memory leak in the
> failure paths of the peak USB driver.
Pulled, thanks.
^ permalink raw reply
* Re: pull-request: can-next 2013-09-21
From: David Miller @ 2013-09-27 6:10 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <523DA52E.2030701@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Sat, 21 Sep 2013 15:54:54 +0200
> this is a pull request for net-next. It consists of two patches by Uwe
> Kleine-König, they add explicit copyrights to the uapi CAN headers
> (including Acked-bys of the header authors). And 12 cleanup patches by
> Jingoo Han. Several drivers are converted to use dev_get_platdata()
> instead of open coding it, two unnecessary pci_set_drvdata() are
> removed from the CAN PCI drivers.
Pulled, th anks.
^ permalink raw reply
* [PATCH net-next 0/2] netxen_nic: Minor enhancement
From: Shahed Shaikh @ 2013-09-27 5:42 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-HSGLinuxNICDev, Shahed Shaikh
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
This patch series contains following changes
* Log a message about ULA adapter type.
* Update the driver version to 4.0.82.
Please apply to net-next.
Thanks,
Shahed
Shahed Shaikh (2):
netxen_nic: Print ULA information
netxen_nic: Update version to 4.0.82
drivers/net/ethernet/qlogic/netxen/netxen_nic.h | 4 +-
.../net/ethernet/qlogic/netxen/netxen_nic_hdr.h | 1 +
.../net/ethernet/qlogic/netxen/netxen_nic_main.c | 28 ++++++++++++++++++++
3 files changed, 31 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH net-next 1/2] netxen_nic: Print ULA information
From: Shahed Shaikh @ 2013-09-27 5:42 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-HSGLinuxNICDev, Shahed Shaikh
In-Reply-To: <1380260547-25903-1-git-send-email-shahed.shaikh@qlogic.com>
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
This patch reads CAMRAM(0x178) where FW writes a key for ULA and non-ULA
adapter and based on the key, driver logs the message.
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
---
.../net/ethernet/qlogic/netxen/netxen_nic_hdr.h | 1 +
.../net/ethernet/qlogic/netxen/netxen_nic_main.c | 28 ++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hdr.h b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hdr.h
index 32c7906..0c64c82 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hdr.h
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hdr.h
@@ -958,6 +958,7 @@ enum {
#define NETXEN_PEG_HALT_STATUS2 (NETXEN_CAM_RAM(0xac))
#define NX_CRB_DEV_REF_COUNT (NETXEN_CAM_RAM(0x138))
#define NX_CRB_DEV_STATE (NETXEN_CAM_RAM(0x140))
+#define NETXEN_ULA_KEY (NETXEN_CAM_RAM(0x178))
/* MiniDIMM related macros */
#define NETXEN_DIMM_CAPABILITY (NETXEN_CAM_RAM(0x258))
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index cbd75f9..5ec21c5 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -1415,6 +1415,32 @@ netxen_setup_netdev(struct netxen_adapter *adapter,
return 0;
}
+#define NETXEN_ULA_ADAPTER_KEY (0xdaddad01)
+#define NETXEN_NON_ULA_ADAPTER_KEY (0xdaddad00)
+
+static void netxen_read_ula_info(struct netxen_adapter *adapter)
+{
+ u32 temp;
+
+ /* Print ULA info only once for an adapter */
+ if (adapter->portnum != 0)
+ return;
+
+ temp = NXRD32(adapter, NETXEN_ULA_KEY);
+ switch (temp) {
+ case NETXEN_ULA_ADAPTER_KEY:
+ dev_info(&adapter->pdev->dev, "ULA adapter");
+ break;
+ case NETXEN_NON_ULA_ADAPTER_KEY:
+ dev_info(&adapter->pdev->dev, "non ULA adapter");
+ break;
+ default:
+ break;
+ }
+
+ return;
+}
+
#ifdef CONFIG_PCIEAER
static void netxen_mask_aer_correctable(struct netxen_adapter *adapter)
{
@@ -1561,6 +1587,8 @@ netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_disable_msi;
}
+ netxen_read_ula_info(adapter);
+
err = netxen_setup_netdev(adapter, netdev);
if (err)
goto err_out_disable_msi;
--
1.5.6
^ permalink raw reply related
* [PATCH net-next 2/2] netxen_nic: Update version to 4.0.82
From: Shahed Shaikh @ 2013-09-27 5:42 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-HSGLinuxNICDev, Shahed Shaikh
In-Reply-To: <1380260547-25903-1-git-send-email-shahed.shaikh@qlogic.com>
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
index e8eff3e..9adcdbb 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
@@ -53,8 +53,8 @@
#define _NETXEN_NIC_LINUX_MAJOR 4
#define _NETXEN_NIC_LINUX_MINOR 0
-#define _NETXEN_NIC_LINUX_SUBVERSION 81
-#define NETXEN_NIC_LINUX_VERSIONID "4.0.81"
+#define _NETXEN_NIC_LINUX_SUBVERSION 82
+#define NETXEN_NIC_LINUX_VERSIONID "4.0.82"
#define NETXEN_VERSION_CODE(a, b, c) (((a) << 24) + ((b) << 16) + (c))
#define _major(v) (((v) >> 24) & 0xff)
--
1.5.6
^ permalink raw reply related
* [PATCH net 1/1] qlcnic: Fix register device in FAILED state for 82xx.
From: Sucheta Chakraborty @ 2013-09-27 6:12 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-HSGLinuxNICDev
o Commit 7e2cf4feba058476324dc545e3d1b316998c91e6
("qlcnic: change driver hardware interface mechanism")
has overwritten
commit b43e5ee76a4320c070cf0fe65cf4927198fbb4d1
("qlcnic: Register device in FAILED state")
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 8 +++++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 39 ++++++++++++++++++++--
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 12 +++++++
3 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 4d7ad00..ebe4c86 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -1794,3 +1794,11 @@ const struct ethtool_ops qlcnic_sriov_vf_ethtool_ops = {
.set_msglevel = qlcnic_set_msglevel,
.get_msglevel = qlcnic_get_msglevel,
};
+
+const struct ethtool_ops qlcnic_ethtool_failed_ops = {
+ .get_settings = qlcnic_get_settings,
+ .get_drvinfo = qlcnic_get_drvinfo,
+ .set_msglevel = qlcnic_set_msglevel,
+ .get_msglevel = qlcnic_get_msglevel,
+ .set_dump = qlcnic_set_dump,
+};
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index c4c5023..21d00a0 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -431,6 +431,9 @@ static void qlcnic_82xx_cancel_idc_work(struct qlcnic_adapter *adapter)
while (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
usleep_range(10000, 11000);
+ if (!adapter->fw_work.work.func)
+ return;
+
cancel_delayed_work_sync(&adapter->fw_work);
}
@@ -2275,8 +2278,9 @@ qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
adapter->portnum = adapter->ahw->pci_func;
err = qlcnic_start_firmware(adapter);
if (err) {
- dev_err(&pdev->dev, "Loading fw failed.Please Reboot\n");
- goto err_out_free_hw;
+ dev_err(&pdev->dev, "Loading fw failed.Please Reboot\n"
+ "\t\tIf reboot doesn't help, try flashing the card\n");
+ goto err_out_maintenance_mode;
}
qlcnic_get_multiq_capability(adapter);
@@ -2408,6 +2412,22 @@ err_out_disable_pdev:
pci_set_drvdata(pdev, NULL);
pci_disable_device(pdev);
return err;
+
+err_out_maintenance_mode:
+ netdev->netdev_ops = &qlcnic_netdev_failed_ops;
+ SET_ETHTOOL_OPS(netdev, &qlcnic_ethtool_failed_ops);
+ err = register_netdev(netdev);
+
+ if (err) {
+ dev_err(&pdev->dev, "Failed to register net device\n");
+ qlcnic_clr_all_drv_state(adapter, 0);
+ goto err_out_free_hw;
+ }
+
+ pci_set_drvdata(pdev, adapter);
+ qlcnic_add_sysfs(adapter);
+
+ return 0;
}
static void qlcnic_remove(struct pci_dev *pdev)
@@ -2518,8 +2538,16 @@ static int qlcnic_resume(struct pci_dev *pdev)
static int qlcnic_open(struct net_device *netdev)
{
struct qlcnic_adapter *adapter = netdev_priv(netdev);
+ u32 state;
int err;
+ state = QLC_SHARED_REG_RD32(adapter, QLCNIC_CRB_DEV_STATE);
+ if (state == QLCNIC_DEV_FAILED || state == QLCNIC_DEV_BADBAD) {
+ netdev_err(netdev, "%s: Device is in FAILED state\n", __func__);
+
+ return -EIO;
+ }
+
netif_carrier_off(netdev);
err = qlcnic_attach(adapter);
@@ -3228,6 +3256,13 @@ void qlcnic_82xx_dev_request_reset(struct qlcnic_adapter *adapter, u32 key)
return;
state = QLC_SHARED_REG_RD32(adapter, QLCNIC_CRB_DEV_STATE);
+ if (state == QLCNIC_DEV_FAILED || state == QLCNIC_DEV_BADBAD) {
+ netdev_err(adapter->netdev, "%s: Device is in FAILED state\n",
+ __func__);
+ qlcnic_api_unlock(adapter);
+
+ return;
+ }
if (state == QLCNIC_DEV_READY) {
QLC_SHARED_REG_WR32(adapter, QLCNIC_CRB_DEV_STATE,
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
index c6165d0..019f437 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
@@ -1272,6 +1272,7 @@ void qlcnic_remove_sysfs_entries(struct qlcnic_adapter *adapter)
void qlcnic_create_diag_entries(struct qlcnic_adapter *adapter)
{
struct device *dev = &adapter->pdev->dev;
+ u32 state;
if (device_create_bin_file(dev, &bin_attr_port_stats))
dev_info(dev, "failed to create port stats sysfs entry");
@@ -1285,8 +1286,13 @@ void qlcnic_create_diag_entries(struct qlcnic_adapter *adapter)
if (device_create_bin_file(dev, &bin_attr_mem))
dev_info(dev, "failed to create mem sysfs entry\n");
+ state = QLC_SHARED_REG_RD32(adapter, QLCNIC_CRB_DEV_STATE);
+ if (state == QLCNIC_DEV_FAILED || state == QLCNIC_DEV_BADBAD)
+ return;
+
if (device_create_bin_file(dev, &bin_attr_pci_config))
dev_info(dev, "failed to create pci config sysfs entry");
+
if (device_create_file(dev, &dev_attr_beacon))
dev_info(dev, "failed to create beacon sysfs entry");
@@ -1307,6 +1313,7 @@ void qlcnic_create_diag_entries(struct qlcnic_adapter *adapter)
void qlcnic_remove_diag_entries(struct qlcnic_adapter *adapter)
{
struct device *dev = &adapter->pdev->dev;
+ u32 state;
device_remove_bin_file(dev, &bin_attr_port_stats);
@@ -1315,6 +1322,11 @@ void qlcnic_remove_diag_entries(struct qlcnic_adapter *adapter)
device_remove_file(dev, &dev_attr_diag_mode);
device_remove_bin_file(dev, &bin_attr_crb);
device_remove_bin_file(dev, &bin_attr_mem);
+
+ state = QLC_SHARED_REG_RD32(adapter, QLCNIC_CRB_DEV_STATE);
+ if (state == QLCNIC_DEV_FAILED || state == QLCNIC_DEV_BADBAD)
+ return;
+
device_remove_bin_file(dev, &bin_attr_pci_config);
device_remove_file(dev, &dev_attr_beacon);
if (!(adapter->flags & QLCNIC_ESWITCH_ENABLED))
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH net 1/2] ip_tunnel: Fix a memory corruption in ip_tunnel_xmit
From: Steffen Klassert @ 2013-09-27 7:45 UTC (permalink / raw)
To: Pravin Shelar; +Cc: David Miller, netdev
In-Reply-To: <CALnjE+ofaXQa3gsPPxqdWZeBxgML6M1vnC9mmc5dufwy0gJO-Q@mail.gmail.com>
On Thu, Sep 26, 2013 at 11:25:01AM -0700, Pravin Shelar wrote:
> On Thu, Sep 26, 2013 at 1:25 AM, Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> > On Wed, Sep 25, 2013 at 09:55:50AM -0700, Pravin Shelar wrote:
> >> On Tue, Sep 24, 2013 at 10:54 PM, Steffen Klassert
> >> <steffen.klassert@secunet.com> wrote:
> >> > We might extend the used aera of a skb beyond the total
> >> > headroom when we install the ipip header. Fix this by
> >> > calling skb_cow_head() unconditionally.
> >> >
> >> It is better to call skb_cow_head() from ipip_tunnel_xmit() as it is
> >> consistent with gre.
> >
> > I think this would just move the bug from ipip to gre. ipgre_xmit()
> > uses dev->needed_headroom which is based on the guessed output device
> > in ip_tunnel_bind_dev(). If the device we get from the route lookup
> > in ip_tunnel_xmit() is different from the guessed one and the resulting
> > max_headroom is bigger than dev->needed_headroom, we run into that bug
> > because skb_cow_head() will not be called with the updated
> > dev->needed_headroom.
> >
> Thats why ip_tunnel_xmit() update dev->needed_headroom.
> Just to be clear I was talking abt calling skb_cow_head with
> dev->needed_headroom in ipip_xmit and leave ip_tunnel_xmit as it is.
> So that most of cases we will not need to adjust headroom in ip_tunnel
> xmit.
skb_cow_head() does not do much if there is enough headroom, so
calling it here is uncritical. But we should adjust the headroom
as soon as we know that it is insufficient.
Also, I really wonder how you want to adjust the headroom in
ipip_tunnel_xmit() to a correct value. We know the needed
headroom after the route lookup in ip_tunnel_xmit() and
we have to adust it here because ip_tunnel_xmit() calls
iptunnel_xmit() which does a __skb_push() before it
installs the IP header.
Please keep in mind tat this is a bug fix that might be interesting
for stable too, we should try to keep the changes at a minimum.
Another thing that I noticed, with commit 0e6fbc5b
(ip_tunnels: extend iptunnel_xmit()) you moved the IP header
installation to iptunnel_xmit() and changed skb_push()
to __skb_push(). This made this bug quite hard to track
down because instead of triggering a skb under panic,
it did a silent memory corruption and crashed at random
other places. Maybe we should change this back to skb_push().
^ permalink raw reply
* Re: [PATCH net 2/2] ip_tunnel: Add fallback tunnels to the hash lists
From: Steffen Klassert @ 2013-09-27 7:56 UTC (permalink / raw)
To: Pravin Shelar; +Cc: David Miller, netdev
In-Reply-To: <CALnjE+pu6CEwB+p3TNH56N09Cwabr9QbaKotKiwbfyLvZUsSpA@mail.gmail.com>
On Thu, Sep 26, 2013 at 11:24:07AM -0700, Pravin Shelar wrote:
> On Thu, Sep 26, 2013 at 1:13 AM, Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> > On Wed, Sep 25, 2013 at 09:03:11AM -0700, Pravin Shelar wrote:
> >> fallback tunnel s not required to be in hash table, Its is returned if
> >> none of hashed tunnels are matched, ref ip_tunnel_lookup().
> >> Can you post command to reproduce this issue?
> >>
> >
> > Something like
> >
> > ip tunnel change tunl0 mode ipip remote 0.0.0.0 local 0.0.0.0 ttl 0 tos 1
> >
> > worked until v3.9 and stopped working with v3.10.
>
> OK, I see the bug, tunnel exact match lookup does not check fb tunnel.
> There are two options.
> 1. Fix ip_tunnel_find() to check for fb tunnel.
> 2. Add fb tunnel to hash table, which is what ur patch does.
> I think your patch is better solution as it get rid of special case.
> But patch is not complete. It needs to remove fb tunnel checks on
> netdev unregister.
It looks like this is another bug that requires an additional patch.
We add the fallback tunnel to the unregister list when we iterate over
all netdevices in the namespace at the beginning of ip_tunnel_destroy()
and then again explicitly at the end of ip_tunnel_destroy().
^ permalink raw reply
* Re: [PATCH net-next 1/5] tipc: silence sparse warnings
From: Ying Xue @ 2013-09-27 8:01 UTC (permalink / raw)
To: David Miller
Cc: jon.maloy, netdev, paul.gortmaker, erik.hugne, maloy,
tipc-discussion, andreas.bofjall
In-Reply-To: <20130927.015908.1293107524454870319.davem@davemloft.net>
On 09/27/2013 01:59 PM, David Miller wrote:
> From: Jon Maloy <jon.maloy@ericsson.com>
> Date: Tue, 24 Sep 2013 04:27:44 -0500
>
>> From: Ying Xue <ying.xue@windriver.com>
>>
>> Eliminate below sparse warnings:
>>
>> net/tipc/link.c:1210:37: warning: cast removes address space of expression
>> net/tipc/link.c:1218:59: warning: incorrect type in argument 2 (different address spaces)
>> net/tipc/link.c:1218:59: expected void const [noderef] <asn:1>*from
>> net/tipc/link.c:1218:59: got unsigned char const [usertype] *[assigned] sect_crs
>> net/tipc/msg.c:96:61: warning: incorrect type in argument 3 (different address spaces)
>> net/tipc/msg.c:96:61: expected void const *from
>> net/tipc/msg.c:96:61: got void [noderef] <asn:1>*const iov_base
>> net/tipc/socket.c:341:49: warning: Using plain integer as NULL pointer
>> net/tipc/socket.c:1371:36: warning: Using plain integer as NULL pointer
>> net/tipc/socket.c:1694:57: warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Ying Xue <ying.xue@windriver.com>
>> Signed-off-by: Andreas Bofjäll <andreas.bofjall@ericsson.com>
>> Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
>
> These warnings are not just for fun, and they are certainly not an
> invitation to stick casts all over the place to make them go away.
>
> They indicate real problems in the TIPC code.
>
> There really are user pointers in the iovecs here, and that's why the
> iov_base member is annotated with "__user".
>
> These iovecs carry pointers that come from userspace via socket calls.
>
> And you absolutely cannot pass user pointers to skb_copy_to_linear_data()
> and friends as they access the source pointer using memcpy().
>
Good point!
It's better for us to use memcpy_fromiovecend() instead of
skb_copy_to_linear_data() and its friends.
We will submit another version to correct this error soon.
Regards,
Ying
> You have to use the proper interfaces for accessing userspace memory,
> ones that have their arguments annotated with __user.
>
> I'm not applying this series, sorry.
>
>
^ permalink raw reply
* Re: [PATCH net-next 1/5] tipc: silence sparse warnings
From: Andreas Bofjäll @ 2013-09-27 8:15 UTC (permalink / raw)
To: Ying Xue; +Cc: jon.maloy, netdev, tipc-discussion, David Miller
In-Reply-To: <52453B51.5070702@windriver.com>
On 09/27/2013 10:01 AM, Ying Xue wrote:
> Good point!
> It's better for us to use memcpy_fromiovecend() instead of
> skb_copy_to_linear_data() and its friends.
>
> We will submit another version to correct this error soon.
I could be wrong here, but I think you should also remove the entire
cast on line 1210 in link.c:
sect_crs = msg_sect[curr_sect].iov_base;
There should be no reason to cast there since you made sect_crs into
const unchar* __user and msg_sect[].iov_base is void* __user.
/Andreas
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCH] ipv6: Fix preferred_lft not updating in some cases
From: Hannes Frederic Sowa @ 2013-09-27 8:16 UTC (permalink / raw)
To: Paul Marks; +Cc: netdev, davem, yoshfuji, lorenzo
In-Reply-To: <1380147175-14874-1-git-send-email-pmarks@google.com>
On Wed, Sep 25, 2013 at 03:12:55PM -0700, Paul Marks wrote:
> Consider the scenario where an IPv6 router is advertising a fixed
> preferred_lft of 1800 seconds, while the valid_lft begins at 3600
> seconds and counts down in realtime.
>
> A client should reset its preferred_lft to 1800 every time the RA is
> received, but a bug is causing Linux to ignore the update.
>
> The core problem is here:
> if (prefered_lft != ifp->prefered_lft) {
>
> Note that ifp->prefered_lft is an offset, so it doesn't decrease over
> time. Thus, the comparison is always (1800 != 1800), which fails to
> trigger an update.
>
> The most direct solution would be to compute a "stored_prefered_lft",
> and use that value in the comparison. But I think that trying to filter
> out unnecessary updates here is a premature optimization. In order for
> the filter to apply, both of these would need to hold:
>
> - The advertised valid_lft and preferred_lft are both declining in
> real time.
> - No clock skew exists between the router & client.
>
> So in this patch, I've set "update_lft = 1" unconditionally, which
> allows the surrounding code to be greatly simplified.
I actually find this much harder to follow when verifying against the RFC.
> Signed-off-by: Paul Marks <pmarks@google.com>
> ---
> net/ipv6/addrconf.c | 52 +++++++++++++++-------------------------------------
> 1 file changed, 15 insertions(+), 37 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index d6ff126..9a5052c 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2193,43 +2193,21 @@ ok:
> else
> stored_lft = 0;
> if (!update_lft && !create && stored_lft) {
> - if (valid_lft > MIN_VALID_LIFETIME ||
> - valid_lft > stored_lft)
> - update_lft = 1;
> - else if (stored_lft <= MIN_VALID_LIFETIME) {
> - /* valid_lft <= stored_lft is always true */
> - /*
> - * RFC 4862 Section 5.5.3e:
> - * "Note that the preferred lifetime of
> - * the corresponding address is always
> - * reset to the Preferred Lifetime in
> - * the received Prefix Information
> - * option, regardless of whether the
> - * valid lifetime is also reset or
> - * ignored."
> - *
> - * So if the preferred lifetime in
> - * this advertisement is different
> - * than what we have stored, but the
> - * valid lifetime is invalid, just
> - * reset prefered_lft.
> - *
> - * We must set the valid lifetime
> - * to the stored lifetime since we'll
> - * be updating the timestamp below,
> - * else we'll set it back to the
> - * minimum.
> - */
> - if (prefered_lft != ifp->prefered_lft) {
Wouldn't the easiest solution be to just drop this if and execute the two
lines below unconditionally?
> - valid_lft = stored_lft;
> - update_lft = 1;
> - }
> - } else {
> - valid_lft = MIN_VALID_LIFETIME;
> - if (valid_lft < prefered_lft)
> - prefered_lft = valid_lft;
> - update_lft = 1;
> - }
> + const u32 minimum_lft = min(
> + stored_lft, (u32)MIN_VALID_LIFETIME);
> + valid_lft = max(valid_lft, minimum_lft);
Quick question: Don't we need a prefered_lft = min(preferred_lft, valid_lft)
here?
> +
> + /* RFC4862 Section 5.5.3e:
> + * "Note that the preferred lifetime of the
> + * corresponding address is always reset to
> + * the Preferred Lifetime in the received
> + * Prefix Information option, regardless of
> + * whether the valid lifetime is also reset or
> + * ignored."
> + *
> + * So we should always update prefered_lft here.
> + */
> + update_lft = 1;
> }
>
> if (update_lft) {
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH 00/51] DMA mask changes
From: Russell King - ARM Linux @ 2013-09-27 8:27 UTC (permalink / raw)
To: Rafał Miłecki
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel@driverdev.osuosl.org, linux-samsung-soc,
Linux SCSI List, e1000-devel, b43-dev, linux-media, devicetree,
dri-devel, linux-tegra, linux-omap,
linux-arm-kernel@lists.infradead.org,
Solarflare linux maintainers, Network Development, linux-usb,
linux-wireless@vger.kernel.org, linux-crypto, uclinux-dist-devel
In-Reply-To: <CACna6rxkpYzdD8_Jfi22vA2suUa3k-JM65_gCySQpp4crVCoPg@mail.gmail.com>
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally. The list of individuals is far to great to do that.
> > I'm hoping no mailing lists reject the patches based on the number of
> > recipients.
>
> Huh, I think it was enough to send only 3 patches to the b43-dev@. Like:
> [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
> [PATCH 14/51] DMA-API: net: b43: (...)
> [PATCH 15/51] DMA-API: net: b43legacy: (...)
> ;)
>
> I believe Joe has some nice script for doing it that way. When fixing
> some coding style / formatting, he sends only related patches to the
> given ML.
If I did that, then the mailing lists would not get the first patch,
because almost none of the lists would be referred to by patch 1.
Moreover, people complain when they don't have access to the full
patch series - they assume patches are missing for some reason, and
they ask for the rest of the series.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* RE: [PATCH] iproute2: xfrm state add abort issue
From: David Laight @ 2013-09-27 8:26 UTC (permalink / raw)
To: Sohny Thomas, stephen, netdev
In-Reply-To: <52447DAC.2060701@linux.vnet.ibm.com>
> ip xfrm state add causes a SIGABRT due to a strncpy_chk .
> This happens since strncpy doesn't account for the '\0' .
> I have fixed this using sizeof instead of strlen .
>
> There is a redhat bug which documents this issue
>
> https://bugzilla.redhat.com/show_bug.cgi?id=982761
>
> Signed-off-by: Sohny Thomas <sohthoma@in.ibm.com>
>
> --------------
>
> diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
> index 389942c..7dd8799 100644
> --- a/ip/xfrm_state.c
> +++ b/ip/xfrm_state.c
> @@ -117,7 +117,7 @@ static int xfrm_algo_parse(struct xfrm_algo *alg,
> enum xfrm_attr_type_t type,
> char *name, char *key, char *buf, int max)
> {
> int len;
> - int slen = strlen(key);
> + int slen = sizeof(key);
you definitely don't want sizeof(key) - that is either 4 or 8.
David
^ permalink raw reply
* [PATCHv2 net-next] xfrm: Simplify SA looking up when using wildcard source
From: Fan Du @ 2013-09-27 8:32 UTC (permalink / raw)
To: steffen.klassert; +Cc: davem, netdev
__xfrm4/6_state_addr_check is a four steps check, all we need to do
is checking whether the destination address match when looking SA
using wildcard source address. Passing saddr from flow is worst option,
as the checking needs to reach the fourth step while actually only
one time checking will do the work.
So, simplify this process by only checking destination address when
using wildcard source address for looking up SAs.
Signed-off-by: Fan Du <fan.du@windriver.com>
---
v2:
- Rewrite a good qualified commit log message
- Use xfrm_addr_equal instead of remaking wheel
---
net/xfrm/xfrm_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index e1373d5..3fad928 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -824,7 +824,7 @@ xfrm_state_find(const xfrm_address_t *daddr, const xfrm_address_t *saddr,
x->props.reqid == tmpl->reqid &&
(mark & x->mark.m) == x->mark.v &&
!(x->props.flags & XFRM_STATE_WILDRECV) &&
- xfrm_state_addr_check(x, daddr, saddr, encap_family) &&
+ xfrm_addr_equal(&x->id.daddr, daddr, encap_family) &&
tmpl->mode == x->props.mode &&
tmpl->id.proto == x->id.proto &&
(tmpl->id.spi == x->id.spi || !tmpl->id.spi))
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next] xfrm: Simplify SA looking up when using wildcard source address
From: Fan Du @ 2013-09-27 8:35 UTC (permalink / raw)
To: Steffen Klassert; +Cc: davem, netdev
In-Reply-To: <20130924114551.GT7660@secunet.com>
On 2013年09月24日 19:45, Steffen Klassert wrote:
> On Mon, Sep 23, 2013 at 05:18:37PM +0800, Fan Du wrote:
>> I'm not quite sure I get this "wildcard source address" right,
>> IMHO if a host needs to protect every traffic for a given remote host,
>> then the source address is wildcard address, i.e. all ZEROs.
>> (Please correct me if I'm bloodly wrong。。。)
>
> The above does not belong to a commit message, really.
> If you are not sure and you want comments on your patch,
> mark your patch as RFC. You should be sure that your patch
> is correct when you submit, at least in the moment you
> send it. I know that this can change a second after,
> but in that moment you should be sure.
One day without embarrassment is not my day :)
Have sent v2, please kindly review.
Thanks
>>
>> Here is the argument if above statement stands true:
>> __xfrm4/6_state_addr_check is a four steps check, all we need to do
>> is checking whether the destination address match. Passing saddr from
>> flow is worst option, as the checking needs to reach the fourth step.
>>
>> So, simply this process by only checking destination address only when
>> using wildcard source address for looking up SAs.
>>
>> Signed-off-by: Fan Du<fan.du@windriver.com>
>> ---
>
> If you have further comments on your patch that should not be
> included in the commit message, you can add them here.
>
>> include/net/xfrm.h | 31 +++++++++++++++++++++++++++++++
>> net/xfrm/xfrm_state.c | 2 +-
>> 2 files changed, 32 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
>> index e253bf0..fdb9343 100644
>> --- a/include/net/xfrm.h
>> +++ b/include/net/xfrm.h
>> @@ -1282,6 +1282,37 @@ xfrm_state_addr_check(const struct xfrm_state *x,
>> }
>>
>> static __inline__ int
>> +__xfrm4_state_daddr_check(const struct xfrm_state *x,
>> + const xfrm_address_t *daddr)
>> +{
>> + return ((daddr->a4 == x->id.daddr.a4) ? 1 : 0);
>> +}
>> +
>> +static __inline__ int
>> +__xfrm6_state_daddr_check(const struct xfrm_state *x,
>> + const xfrm_address_t *daddr)
>> +{
>> + if (ipv6_addr_equal((struct in6_addr *)daddr, (struct in6_addr *)&x->id.daddr))
>> + return 1;
>> + else
>> + return 0;
>> +}
>> +
>> +static __inline__ int
>> +xfrm_state_daddr_check(const struct xfrm_state *x,
>> + const xfrm_address_t *daddr,
>> + unsigned short family)
>> +{
>> + switch (family) {
>> + case AF_INET:
>> + return __xfrm4_state_daddr_check(x, daddr);
>> + case AF_INET6:
>> + return __xfrm6_state_daddr_check(x, daddr);
>> + }
>> + return 0;
>> +}
>
> You used whitespaces where you should use tabs in the whole patch.
> Please do the formating right to avoid cleanup patches.
>
> --
> 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
>
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply
* Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
From: Hannes Frederic Sowa @ 2013-09-27 8:37 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <1380207108-20030-1-git-send-email-oghorbell@gmail.com>
On Thu, Sep 26, 2013 at 03:51:48PM +0100, Oussama Ghorbel wrote:
> The (inner) MTU of a ipip6 (IPv4-in-IPv6) tunnel cannot be set below 1280, which is the minimum MTU in IPv6.
> However, there should be no IPv6 on the tunnel interface at all, so the IPv6 rules should not apply.
> More info at https://bugzilla.kernel.org/show_bug.cgi?id=15530
>
> This patch allows to check the minimum MTU for ipv6 tunnel according to these rules:
> -In case the tunnel is configured with ipip6 mode the minimum MTU is 68.
> -In case the tunnel is configured with ip6ip6 or any mode the minimum MTU is 1280.
>
> Signed-off-by: Oussama Ghorbel <oghorbell@gmail.com>
> ---
> net/ipv6/ip6_tunnel.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 1e55866..a66ead2 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -1423,8 +1423,14 @@ ip6_tnl_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> static int
> ip6_tnl_change_mtu(struct net_device *dev, int new_mtu)
> {
> - if (new_mtu < IPV6_MIN_MTU) {
> - return -EINVAL;
> + struct ip6_tnl *t = netdev_priv(dev);
> +
> + if (t->parms.proto == IPPROTO_IPIP) {
> + if (new_mtu < 68)
> + return -EINVAL;
Maybe you could have a look at ip_tunnel_change_mtu in ipv4/ip_tunnel.c,
generalize this check as e.g. ip_tunnel_valid_mtu or something and use it
here? Maybe an af-independent ip_tunnel_max_mtu()?
> + } else {
> + if (new_mtu < IPV6_MIN_MTU)
> + return -EINVAL;
This check could also be used here, then.
> }
> dev->mtu = new_mtu;
> return 0;
Thanks,
Hannes
^ permalink raw reply
* Re: GRE support for IPv6
From: Hannes Frederic Sowa @ 2013-09-27 8:41 UTC (permalink / raw)
To: Templin, Fred L; +Cc: Stephen Hemminger, netdev@vger.kernel.org, xeb@mail.ru
In-Reply-To: <2134F8430051B64F815C691A62D98318108F59@XCH-BLV-504.nw.nos.boeing.com>
Hi Fred!
On Fri, Sep 13, 2013 at 10:37:01PM +0000, Templin, Fred L wrote:
> See attached for the patches as applied to iproute2-3.10.0.
> The code compiles cleanly - testing is in progress.
Could you resend the patches inline (formatted with git-format-patch) so that
patchwork[1] can track them?
[1] http://patchwork.ozlabs.org/project/netdev/list/
Greetings,
Hannes
^ permalink raw reply
* RE: rx_dropped count for USB ethernet interfaces
From: David Laight @ 2013-09-27 8:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130926.132125.1343558938307288175.davem@redhat.com>
> From: "David Laight" <David.Laight@ACULAB.COM>
> Date: Thu, 26 Sep 2013 10:32:24 +0100
>
> > It isn't exactly useful behaviour though.
>
> In your opinion.
>
> We have tracepoints for people who want more fine grained drops
> in these kinds of situations.
>
> Also, the behavior of this statistic has existed for more than a
> decade so changing it is really not in the cards. Therefore any
> discussion about what would have been the best samentic to choose from
> the beginning is moot.
I suspect that not many people have networks with broadcast packets
for non-IP protocols - so don't ever see rx_dropped being incremented
because there wasn't a protocol stack looking for the packet.
A similar problem will arise if promiscuous mode is enabled
by someone who only wants a specific protocol - eg a specific
ethertype or a single LLC SAP value.
David
^ 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