* Re: [PATCH 0/3] Add temperature reading and registers dump to mv88e6171
From: David Miller @ 2014-11-16 20:48 UTC (permalink / raw)
To: andrew; +Cc: netdev, linux
In-Reply-To: <1416086694-15790-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 15 Nov 2014 22:24:50 +0100
> These patches centralize the temperature sensor reading code, and then
> make use of it with the mv88e6171 which has a compatible
> sensor. Additionally, support is added for reading the mv88e6171 via
> ethtool.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] device: Add dev_<level>_once variants
From: David Miller @ 2014-11-16 20:49 UTC (permalink / raw)
To: joe
Cc: f.fainelli, jeffrey.t.kirsher, shannon.nelson, netdev, nhorman,
sassmann, jogreene
In-Reply-To: <1416091109.5912.32.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sat, 15 Nov 2014 14:38:29 -0800
> Add the equivalents to pr_<level>_once.
>
> Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Joe Perches <joe@perches.com>
This probably should go via the device layer core, thanks thus Greg KH.
^ permalink raw reply
* Re: [PATCH net-next 00/14] net: provide common RSS key infrastructure
From: David Miller @ 2014-11-16 21:03 UTC (permalink / raw)
To: edumazet
Cc: netdev, Thomas.Lendacky, ariel.elior, mchan, prashant,
rasesh.mody, sathya.perla, subbu.seetharaman, ajit.khaparde,
jesse.brandeburg, jeffrey.t.kirsher, amirv, sshah, sbhatewara
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 16 Nov 2014 06:23:04 -0800
> RSS (Receive Side Scaling) uses a 40 bytes key to provide hash for incoming
> packets to select appropriate incoming queue on NIC.
>
> Hash algo (Toeplitz) is also well known and documented by Microsoft
> (search for "Verifying the RSS Hash Calculation")
>
> Problem is that some drivers use a well known key.
> It makes very easy for attackers to target one particular RX queue,
> knowing that number of RX queues is a power of two, or at least some
> small number.
>
> Other drivers use a random value per port, making difficult
> tuning on bonding setups.
>
> Lets add a common infrastructure, so that host gets an unique
> RSS key, and drivers do not have to worry about this.
Looks good, series applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: David Miller @ 2014-11-16 21:05 UTC (permalink / raw)
To: bjorn; +Cc: mardnh, netdev
In-Reply-To: <87ppcneyy2.fsf@nemi.mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Sun, 16 Nov 2014 20:18:45 +0100
> Martin Hauke <mardnh@gmx.de> writes:
>
>> Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
>>
>> Signed-off-by: Martin Hauke <mardnh@gmx.de>
>
> Acked-by: Bjørn Mork <bjorn@mork.no>
>
> Dave, please add this to the netdev stable queue as well.
Ok, applied and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question
From: Michal Soltys @ 2014-11-16 21:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1416161725.17262.92.camel@edumazet-glaptop2.roam.corp.google.com>
Actually, now that I analyzed it more carefully - not having that patch
would cause obvious issues (e.g. hfsc trying to activate already active
leaf in certain scenarios).
So, sorry for the noise.
PS.
Removed Jarek from CC, as that email is no longer valid.
^ permalink raw reply
* Re: [PATCH v2 net-next 6/7] bpf: allow eBPF programs to use maps
From: Alexei Starovoitov @ 2014-11-16 21:24 UTC (permalink / raw)
To: David Miller
Cc: Ingo Molnar, Andy Lutomirski, Daniel Borkmann,
Hannes Frederic Sowa, Eric Dumazet, Linux API,
Network Development, LKML
In-Reply-To: <20141116.140422.570375628237589645.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sun, Nov 16, 2014 at 11:04 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
> Date: Thu, 13 Nov 2014 17:36:49 -0800
>
>> +static u64 bpf_map_lookup_elem(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
>> +{
>> + /* verifier checked that R1 contains a valid pointer to bpf_map
>> + * and R2 points to a program stack and map->key_size bytes were
>> + * initialized
>> + */
>> + struct bpf_map *map = (struct bpf_map *) (unsigned long) r1;
>> + void *key = (void *) (unsigned long) r2;
>> + void *value;
>> +
>> + WARN_ON_ONCE(!rcu_read_lock_held());
>> +
>> + value = map->ops->map_lookup_elem(map, key);
>> +
>> + /* lookup() returns either pointer to element value or NULL
>> + * which is the meaning of PTR_TO_MAP_VALUE_OR_NULL type
>> + */
>> + return (unsigned long) value;
>> +}
>
> You should translate this into a true boolean '1' or '0' value so that
> kernel pointers don't propagate to the user or his eBPF programs.
that won't work. eBPF programs have to see all sorts of kernel
pointers. In this case it's a pointer to map element value
or NULL. There are pointers to stack, pointers to map root,
pointers to context, etc. Programs can read pointers from
other data structures. And in the case of tracing they can
pretty much access any kernel memory in read only way.
Just like 'perf probe' filters.
The requirement that _unprivileged_ programs should
not be able to pass all these pointers back to user is
well understood and was discussed in detail several
month back. It's verifier that will prevent leaking of
kernel addresses. Today, the whole thing is for root
only. When the infra is ready for non-root I will add
a pass to verifier, that will kick in only for unprivileged
programs. Verifier already tracks all pointers and
can prevent passing them to user. In this case
verifier knows that register R0 after a call to
bpf_map_lookup_elem() is
"either pointer to element value or NULL",
so it will prevent storing it into any memory or
doing arithmetic on it, so that user space cannot
see the pointer, whereas eBPF program can use
it to access map element value.
^ permalink raw reply
* Re: [PATCH v2 net-next 6/7] bpf: allow eBPF programs to use maps
From: David Miller @ 2014-11-16 21:34 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAMEtUuwrST6wGnBU6UU2NYEubskHYf1XZmZQpkgM+cUc8YD9OA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Sun, 16 Nov 2014 13:24:53 -0800
> The requirement that _unprivileged_ programs should
> not be able to pass all these pointers back to user is
> well understood and was discussed in detail several
> month back. It's verifier that will prevent leaking of
> kernel addresses.
Ok, fair enough.
^ permalink raw reply
* [PATCH net-next] i40e: Reduce stack in i40e_dbg_dump_desc
From: Joe Perches @ 2014-11-16 22:12 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Shannon Nelson, netdev
In-Reply-To: <5467C3BA.6090003@gmail.com>
Reduce stack use by using kmemdup and not using a very
large struct on stack.
In function ‘i40e_dbg_dump_desc’:
warning: the frame size of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 30 +++++++++++++++-----------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index a03f459..232783d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -773,7 +773,7 @@ static void i40e_dbg_dump_desc(int cnt, int vsi_seid, int ring_id, int desc_n,
{
struct i40e_tx_desc *txd;
union i40e_rx_desc *rxd;
- struct i40e_ring ring;
+ struct i40e_ring *ring;
struct i40e_vsi *vsi;
int i;
@@ -792,29 +792,32 @@ static void i40e_dbg_dump_desc(int cnt, int vsi_seid, int ring_id, int desc_n,
vsi_seid);
return;
}
- if (is_rx_ring)
- ring = *vsi->rx_rings[ring_id];
- else
- ring = *vsi->tx_rings[ring_id];
+
+ ring = kmemdup(is_rx_ring
+ ? vsi->rx_rings[ring_id] : vsi->tx_rings[ring_id],
+ sizeof(*ring), GFP_KERNEL);
+ if (!ring)
+ return;
+
if (cnt == 2) {
dev_info(&pf->pdev->dev, "vsi = %02i %s ring = %02i\n",
vsi_seid, is_rx_ring ? "rx" : "tx", ring_id);
- for (i = 0; i < ring.count; i++) {
+ for (i = 0; i < ring->count; i++) {
if (!is_rx_ring) {
- txd = I40E_TX_DESC(&ring, i);
+ txd = I40E_TX_DESC(ring, i);
dev_info(&pf->pdev->dev,
" d[%03i] = 0x%016llx 0x%016llx\n",
i, txd->buffer_addr,
txd->cmd_type_offset_bsz);
} else if (sizeof(union i40e_rx_desc) ==
sizeof(union i40e_16byte_rx_desc)) {
- rxd = I40E_RX_DESC(&ring, i);
+ rxd = I40E_RX_DESC(ring, i);
dev_info(&pf->pdev->dev,
" d[%03i] = 0x%016llx 0x%016llx\n",
i, rxd->read.pkt_addr,
rxd->read.hdr_addr);
} else {
- rxd = I40E_RX_DESC(&ring, i);
+ rxd = I40E_RX_DESC(ring, i);
dev_info(&pf->pdev->dev,
" d[%03i] = 0x%016llx 0x%016llx 0x%016llx 0x%016llx\n",
i, rxd->read.pkt_addr,
@@ -823,26 +826,26 @@ static void i40e_dbg_dump_desc(int cnt, int vsi_seid, int ring_id, int desc_n,
}
}
} else if (cnt == 3) {
- if (desc_n >= ring.count || desc_n < 0) {
+ if (desc_n >= ring->count || desc_n < 0) {
dev_info(&pf->pdev->dev,
"descriptor %d not found\n", desc_n);
return;
}
if (!is_rx_ring) {
- txd = I40E_TX_DESC(&ring, desc_n);
+ txd = I40E_TX_DESC(ring, desc_n);
dev_info(&pf->pdev->dev,
"vsi = %02i tx ring = %02i d[%03i] = 0x%016llx 0x%016llx\n",
vsi_seid, ring_id, desc_n,
txd->buffer_addr, txd->cmd_type_offset_bsz);
} else if (sizeof(union i40e_rx_desc) ==
sizeof(union i40e_16byte_rx_desc)) {
- rxd = I40E_RX_DESC(&ring, desc_n);
+ rxd = I40E_RX_DESC(ring, desc_n);
dev_info(&pf->pdev->dev,
"vsi = %02i rx ring = %02i d[%03i] = 0x%016llx 0x%016llx\n",
vsi_seid, ring_id, desc_n,
rxd->read.pkt_addr, rxd->read.hdr_addr);
} else {
- rxd = I40E_RX_DESC(&ring, desc_n);
+ rxd = I40E_RX_DESC(ring, desc_n);
dev_info(&pf->pdev->dev,
"vsi = %02i rx ring = %02i d[%03i] = 0x%016llx 0x%016llx 0x%016llx 0x%016llx\n",
vsi_seid, ring_id, desc_n,
@@ -852,6 +855,7 @@ static void i40e_dbg_dump_desc(int cnt, int vsi_seid, int ring_id, int desc_n,
} else {
dev_info(&pf->pdev->dev, "dump desc rx/tx <vsi_seid> <ring_id> [<desc_n>]\n");
}
+ kfree(ring);
}
/**
^ permalink raw reply related
* [PATCH net-next] netdevice: Neaten includes and forward declarations
From: Joe Perches @ 2014-11-16 22:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141116.154923.1364136096942964102.davem@davemloft.net>
Use the appropriate #include path for neighbour.h and
add device.h which was indirectly #included by dmaengine.h
Remove unnecessary forward declaration of struct device;
Add comments for other forward struct declarations.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/linux/netdevice.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index fa6bd7d..33ce566 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -36,6 +36,7 @@
#include <linux/percpu.h>
#include <linux/rculist.h>
+#include <linux/device.h>
#include <linux/dmaengine.h>
#include <linux/workqueue.h>
#include <linux/dynamic_queue_limits.h>
@@ -49,16 +50,15 @@
#include <net/netprio_cgroup.h>
#include <linux/netdev_features.h>
-#include <linux/neighbour.h>
+
+#include <uapi/linux/neighbour.h>
#include <uapi/linux/netdevice.h>
-struct netpoll_info;
-struct device;
-struct phy_device;
-/* 802.11 specific */
-struct wireless_dev;
-/* 802.15.4 specific */
-struct wpan_dev;
+/* forward struct type declarations */
+struct netpoll_info; /* for net_device_ops */
+struct phy_device; /* for net_device */
+struct wireless_dev; /* for net_device: 802.11 specific */
+struct wpan_dev; /* for net_device: 802.15.4 specific */
void netdev_set_default_ethtool_ops(struct net_device *dev,
const struct ethtool_ops *ops);
^ permalink raw reply related
* Re: [PATCH 1/1 net-next] wireless: remove unnecessary sizeof(u8)
From: Julian Calaby @ 2014-11-16 22:33 UTC (permalink / raw)
To: Fabian Frederick
Cc: linux-kernel@vger.kernel.org, Stefano Brivio, John W. Linville,
Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Larry Finger, Chaoming Li, linux-wireless, b43-dev, netdev
In-Reply-To: <1415998553-12636-1-git-send-email-fabf@skynet.be>
Hi Fabian,
On Sat, Nov 15, 2014 at 7:55 AM, Fabian Frederick <fabf@skynet.be> wrote:
> sizeof(u8) is always 1.
I thought that sizeof(*variable) was preferred over sizeof(type), so
shouldn't these be switched to that format instead?
(I know that this is all no-op, but it should reduce the potential for
highly unlikely bugs in the future. Also, the extra processing is
compile-time not run-time.)
Thanks,
Julian Calaby
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> drivers/net/wireless/b43/ppr.c | 2 +-
> drivers/net/wireless/iwlwifi/pcie/trans.c | 2 +-
> drivers/net/wireless/rtlwifi/efuse.c | 16 ++++++++--------
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/ppr.c b/drivers/net/wireless/b43/ppr.c
> index 9a77027..6bc1c6f 100644
> --- a/drivers/net/wireless/b43/ppr.c
> +++ b/drivers/net/wireless/b43/ppr.c
> @@ -28,7 +28,7 @@ void b43_ppr_clear(struct b43_wldev *dev, struct b43_ppr *ppr)
> memset(ppr, 0, sizeof(*ppr));
>
> /* Compile-time PPR check */
> - BUILD_BUG_ON(sizeof(struct b43_ppr) != B43_PPR_RATES_NUM * sizeof(u8));
> + BUILD_BUG_ON(sizeof(struct b43_ppr) != B43_PPR_RATES_NUM);
> }
>
> void b43_ppr_add(struct b43_wldev *dev, struct b43_ppr *ppr, int diff)
> diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c b/drivers/net/wireless/iwlwifi/pcie/trans.c
> index 836725e..f016824 100644
> --- a/drivers/net/wireless/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
> @@ -1157,7 +1157,7 @@ static void iwl_trans_pcie_configure(struct iwl_trans *trans,
> trans_pcie->n_no_reclaim_cmds = trans_cfg->n_no_reclaim_cmds;
> if (trans_pcie->n_no_reclaim_cmds)
> memcpy(trans_pcie->no_reclaim_cmds, trans_cfg->no_reclaim_cmds,
> - trans_pcie->n_no_reclaim_cmds * sizeof(u8));
> + trans_pcie->n_no_reclaim_cmds);
>
> trans_pcie->rx_buf_size_8k = trans_cfg->rx_buf_size_8k;
> if (trans_pcie->rx_buf_size_8k)
> diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
> index 0b4082c..a3135c5 100644
> --- a/drivers/net/wireless/rtlwifi/efuse.c
> +++ b/drivers/net/wireless/rtlwifi/efuse.c
> @@ -251,8 +251,8 @@ void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16 _size_byte, u8 *pbuf)
> }
>
> /* allocate memory for efuse_tbl and efuse_word */
> - efuse_tbl = kzalloc(rtlpriv->cfg->maps[EFUSE_HWSET_MAX_SIZE] *
> - sizeof(u8), GFP_ATOMIC);
> + efuse_tbl = kzalloc(rtlpriv->cfg->maps[EFUSE_HWSET_MAX_SIZE],
> + GFP_ATOMIC);
> if (!efuse_tbl)
> return;
> efuse_word = kzalloc(EFUSE_MAX_WORD_UNIT * sizeof(u16 *), GFP_ATOMIC);
> @@ -733,8 +733,8 @@ static int efuse_pg_packet_read(struct ieee80211_hw *hw, u8 offset, u8 *data)
> if (offset > 15)
> return false;
>
> - memset(data, 0xff, PGPKT_DATA_SIZE * sizeof(u8));
> - memset(tmpdata, 0xff, PGPKT_DATA_SIZE * sizeof(u8));
> + memset(data, 0xff, PGPKT_DATA_SIZE);
> + memset(tmpdata, 0xff, PGPKT_DATA_SIZE);
>
> while (continual && (efuse_addr < EFUSE_MAX_SIZE)) {
> if (readstate & PG_STATE_HEADER) {
> @@ -772,7 +772,7 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
> struct rtl_priv *rtlpriv = rtl_priv(hw);
> struct pgpkt_struct tmp_pkt;
> int dataempty = true;
> - u8 originaldata[8 * sizeof(u8)];
> + u8 originaldata[8];
> u8 badworden = 0x0F;
> u8 match_word_en, tmp_word_en;
> u8 tmpindex;
> @@ -881,7 +881,7 @@ static void efuse_write_data_case2(struct ieee80211_hw *hw, u16 *efuse_addr,
> struct pgpkt_struct tmp_pkt;
> u8 pg_header;
> u8 tmp_header;
> - u8 originaldata[8 * sizeof(u8)];
> + u8 originaldata[8];
> u8 tmp_word_cnts;
> u8 badworden = 0x0F;
>
> @@ -904,7 +904,7 @@ static void efuse_write_data_case2(struct ieee80211_hw *hw, u16 *efuse_addr,
>
> tmp_word_cnts = efuse_calculate_word_cnts(tmp_pkt.word_en);
>
> - memset(originaldata, 0xff, 8 * sizeof(u8));
> + memset(originaldata, 0xff, 8);
>
> if (efuse_pg_packet_read(hw, tmp_pkt.offset, originaldata)) {
> badworden = enable_efuse_data_write(hw,
> @@ -962,7 +962,7 @@ static int efuse_pg_packet_write(struct ieee80211_hw *hw,
> target_pkt.offset = offset;
> target_pkt.word_en = word_en;
>
> - memset(target_pkt.data, 0xFF, 8 * sizeof(u8));
> + memset(target_pkt.data, 0xFF, 8);
>
> efuse_word_enable_data_read(word_en, data, target_pkt.data);
> target_word_cnts = efuse_calculate_word_cnts(target_pkt.word_en);
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [PATCH net-next] enic: support skb->xmit_more
From: Govindarajulu Varadarajan @ 2014-11-16 23:04 UTC (permalink / raw)
To: davem, netdev, ssujith, benve; +Cc: Govindarajulu Varadarajan
Update posted_index only when skb->xmit_more is 0 or tx queue is full.
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 8 ++++++--
drivers/net/ethernet/cisco/enic/vnic_wq.h | 20 +++++++++++---------
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 5afe360..52bccfd 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -533,6 +533,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
struct vnic_wq *wq;
unsigned long flags;
unsigned int txq_map;
+ struct netdev_queue *txq;
if (skb->len <= 0) {
dev_kfree_skb_any(skb);
@@ -541,6 +542,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
txq_map = skb_get_queue_mapping(skb) % enic->wq_count;
wq = &enic->wq[txq_map];
+ txq = netdev_get_tx_queue(netdev, skb_get_queue_mapping(skb));
/* Non-TSO sends must fit within ENIC_NON_TSO_MAX_DESC descs,
* which is very likely. In the off chance it's going to take
@@ -558,7 +560,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
if (vnic_wq_desc_avail(wq) <
skb_shinfo(skb)->nr_frags + ENIC_DESC_MAX_SPLITS) {
- netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
+ netif_tx_stop_queue(txq);
/* This is a hard error, log it */
netdev_err(netdev, "BUG! Tx ring full when queue awake!\n");
spin_unlock_irqrestore(&enic->wq_lock[txq_map], flags);
@@ -568,7 +570,9 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
enic_queue_wq_skb(enic, wq, skb);
if (vnic_wq_desc_avail(wq) < MAX_SKB_FRAGS + ENIC_DESC_MAX_SPLITS)
- netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
+ netif_tx_stop_queue(txq);
+ if (!skb->xmit_more || netif_xmit_stopped(txq))
+ vnic_wq_doorbell(wq);
spin_unlock_irqrestore(&enic->wq_lock[txq_map], flags);
diff --git a/drivers/net/ethernet/cisco/enic/vnic_wq.h b/drivers/net/ethernet/cisco/enic/vnic_wq.h
index 2c6c708..816f1ad 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_wq.h
+++ b/drivers/net/ethernet/cisco/enic/vnic_wq.h
@@ -104,6 +104,17 @@ static inline void *vnic_wq_next_desc(struct vnic_wq *wq)
return wq->to_use->desc;
}
+static inline void vnic_wq_doorbell(struct vnic_wq *wq)
+{
+ /* Adding write memory barrier prevents compiler and/or CPU
+ * reordering, thus avoiding descriptor posting before
+ * descriptor is initialized. Otherwise, hardware can read
+ * stale descriptor fields.
+ */
+ wmb();
+ iowrite32(wq->to_use->index, &wq->ctrl->posted_index);
+}
+
static inline void vnic_wq_post(struct vnic_wq *wq,
void *os_buf, dma_addr_t dma_addr,
unsigned int len, int sop, int eop,
@@ -122,15 +133,6 @@ static inline void vnic_wq_post(struct vnic_wq *wq,
buf->wr_id = wrid;
buf = buf->next;
- if (eop) {
- /* Adding write memory barrier prevents compiler and/or CPU
- * reordering, thus avoiding descriptor posting before
- * descriptor is initialized. Otherwise, hardware can read
- * stale descriptor fields.
- */
- wmb();
- iowrite32(buf->index, &wq->ctrl->posted_index);
- }
wq->to_use = buf;
wq->ring.desc_avail -= desc_skip_cnt;
--
2.1.3
^ permalink raw reply related
* [PATCH] fix #51791 - bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
From: Roland Kletzing @ 2014-11-17 0:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <trinity-1cec0308-6242-413f-a63f-b09cded30a4f-1416096326518@3capp-webde-bs03>
This one should fix Bugzilla #51791 (details below).
Natsemi driver does not read MAC correctly from eeprom, while natsemi-diag from nictools-pci does. Apparently, tt`s a timing issue in the kernel driver.
According to ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c , eeprom_delay(ee_addr) is defined as follows:
/* Delay between EEPROM clock transitions.
This flushes the write buffer to prevent quick double-writes.
*/
#define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr)
while in the natsemi linux kernel driver, the delay is done this way :
#define eeprom_delay(ee_addr) readl(ee_addr)
, which results in the MAC being all zero`s.
So i simply added a second readl() to increase delay (instead of turning into inl() as proposed before). This may look a little bit ugly, but it`s fixing the problem for me.
I´m not sure how many natsemi users being left on this planet (probably few), but i guess this change does not do any harm on platforms where the driver does not behave buggy, so please consider adding it to mainline/stable/longterm.
Signed-off-by: Roland Kletzing <devzero@web.de>
---
drivers/net/ethernet/natsemi/natsemi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/natsemi/natsemi.c b/drivers/net/ethernet/natsemi/natsemi.c
index b83f7c0..246bb91 100644
--- a/drivers/net/ethernet/natsemi/natsemi.c
+++ b/drivers/net/ethernet/natsemi/natsemi.c
@@ -987,7 +987,7 @@ static int natsemi_probe1(struct pci_dev *pdev, const struct pci_device_id *ent)
The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is
deprecated.
*/
-#define eeprom_delay(ee_addr) readl(ee_addr)
+#define eeprom_delay(ee_addr) readl(ee_addr); readl(ee_addr)
#define EE_Write0 (EE_ChipSelect)
#define EE_Write1 (EE_ChipSelect | EE_DataIn)
--
regards
Roland
> Gesendet: Sonntag, 16. November 2014 um 01:05 Uhr
> Von: devzero@web.de
> An: linux-kernel@vger.kernel.org
> Betreff: re: bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
>
> forwarding to lkml, as no response on netdev list so far.
>
> maybe someone has a clue how to properly fix this timing issue. the remaining question is about how to correctly replace readl() with inl() to make it compile cleanly or how eeprom_delay() is being done correctly. inl() seems to be slower to complete which seems to make the driver work, but it seems it needs an I/O port as param but not an memory-adress.
>
> sorry, i`m not good at programming, but now as the problem is "basically" fixed there are just some tiny bits missing for a proper fix. i´m unsure if typecasting ee_addr is the right thing to do (i think it`s not) and if a patch with such typecast would have any chance for being accepted.
>
> ----------------------------
> hi,
> as i`m doing a little project with this older devices, i have come across this issue again and had some fun to dig deeper into it.
>
> it`s a little bit academic, as i can do ifconfig eth0 hw ether..... as a workaround, but it sucks to hack that into startup scripts and i also have seen udev not playing nicely with it.
>
> apparently the problem is being caused by a timing issue in the natsemi driver.
>
> i added some debug printk`s in natsemi.c -> eeprom_read() after each occurrence of eeprom_delay(ee_addr); , and the problem went away.
>
> there is a hint about timing sensitivity in the code:
>
> /* Delay between EEPROM clock transitions.
> No extra delay is needed with 33Mhz PCI, but future 66Mhz access may need
> a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that
> made udelay() unreliable.
> The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is
> deprecated.
> */
>
> looking at the source of natsemi-diag.c made me wonder why that utility is using
>
> #define eeprom_delay(ee_addr) inl(ee_addr)
>
> instead of
>
> #define eeprom_delay(ee_addr) readl(ee_addr)
>
> and apparently, that also fixes the problem (but gives a compile warning):
>
> drivers/net/ethernet/natsemi/natsemi.c: In function âeeprom_readâ:
> drivers/net/ethernet/natsemi/natsemi.c:1019:3: warning: passing argument 1 of âinlâ makes integer from pointer without a cast [enabled by default]
> In file included from include/linux/io.h:22:0,
> from include/linux/pci.h:54,
> from drivers/net/ethernet/natsemi/natsemi.c:38:
>
>
> looking at a more recent version of natsemi-diag.c , i even found this one:
>
> ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c
>
> /* Delay between EEPROM clock transitions.
> This flushes the write buffer to prevent quick double-writes.
> */
> #define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr)
>
> The question is how to make a proper fix, as i don`t know what to pass to inl() , as it seems it should not get an mmapped adress but an i/o port instead !?
>
> "The in*() functions return data read from the specified I/O port"
>
> "The read*() functions read data from device memory previously mapped by map_memory()"
>
> regards
> roland
>
> ps: CC driver maintainer from Kernel Maintainers file.
>
>
>
> Roland Kletzing | 17 Dec 13:38 2012
> bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
>
> Hello,
> i recently played with my older evo t20/wyse 3235le thin clients and flashed
> a linux kernel into those, apparently there seems an issue with the natsemi
> driver.
>
> after driver load (natsemi.ko) eth0 has no valid mac adress, dmesg and
> ifconfig shows just zero`s: 00:00:00:00:00:00.
>
> despite that , the nic is working fine for me (in this test setup i set the
> mac manually: ifconfig eth0 hw ether de:ad:be:ef:be:ef )
>
> apparently, the driver fails to read the proper mac from the eeprom, as
> "natsemi-diag -ee" (from nictools-pci in debian squeeze) shows, that there
> is a valid "Ethernet MAC Station Address" stored inside the eeprom. (see
> below)
>
> looks like a driver bug !?
> does anybody have a clue what`s going wrong here?
>
> regards
> roland
>
> #lspci
>
> 00:00.0 Host bridge: Cyrix Corporation PCI Master
> 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815
> (MacPhyter) Ethernet Controller
> 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30)
> 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
> 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua]
> 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua]
> 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
> 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev
> 06)
>
> #dmesg |egrep "natsemi|eth"
> natsemi dp8381x driver, version 2.1, Sept 11, 2006
> natsemi 0000:00:0f.0: setting latency timer to 64
> natsemi eth0: NatSemi DP8381[56] at 0x4010000 (0000:00:0f.0),
> 00:00:00:00:00:00, IRQ 10, port TP.
> eth0: DSPCFG accepted after 0 usec.
> eth0: link up.
> eth0: Setting full-duplex based on negotiated link capability.
>
> #natsemi-diag -aa
> natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker <at> scyld.com)
> http://www.scyld.com/diag/index.html
> Index #1: Found a NatSemi DP83815 adapter at 0xf800.
> Natsemi 83815 series with station address de:ad:be:ef:be:ef
> Transceiver setting Autonegotation advertise 10/100 Mbps half and full
> duplex.
> This device appears to be active, so some registers will not be read.
> To see all register values use the '-f' flag.
> NatSemi DP83815 chip registers at 0xf800
> 0x000: 00000004 e805e000 00000002 00000000 ******** 00f1cd65 00000001
> 00000000
> 0x020: 03abd200 d0f01002 00000000 00000000 03abd000 18700010 00000000
> 00000000
> 0x040: ******** 00200000 00000004 0000efbe ffff000b 30303030 00000403
> 00000000
> 0x060: ******** ******** ******** ******** ******** ******** ********
> ********
> 0x080: 00003100 0000786d 00002000 00005c21 000005e1 000045e1 00000005
> 00002801
> 0x0A0: ******** ******** ******** ******** ******** ******** ********
> ********
> 0x0C0: 00000615 00000002 00000000 00000000 00000000 00000000 00000100
> 00000030
> 0x0E0: 00000000 000000bf 00000804 00008200 00000000 00000000 00000000
> 00000000
> Interrupt sources are pending (00000200).
> Tx queue emptied indication.
> Receive mode is 0xc8200000: Normal unicast and hashed multicast.
> Rx filter contents: adde efbe efbe 0000 0000 0000 0000 0000
>
> #natsemi-diag -ee
> natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker <at> scyld.com)
> http://www.scyld.com/diag/index.html
> Index #1: Found a NatSemi DP83815 adapter at 0xf800.
> Natsemi 83815 series with station address de:ad:be:ef:be:ef
> Transceiver setting Autonegotation advertise 10/100 Mbps half and full
> duplex.
> EEPROM address length 6, 64 words.
> EEPROM contents (64 words):
> 0x00: 100b 0020 0b34 41fb 0000 0000 0000 4000
> 0x08: 0d32 dff4 1905 aa48 0000 0000 129c 4c4c
> 0x10: ca52 2ccc 0cb2 9c6c 0c6c 8c0c 2020 6080
> 0x18: 0800 0000 0000 0000 0000 0000 0000 0000
> 0x20: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x28: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x30: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x38: 0000 0000 0000 0000 0000 0000 0000 e418
> Decoded EEPROM contents:
> PCI Subsystem IDs -- Vendor 0x100b, Device 0x0020.
> PCI timer settings -- minimum grant 11, maximum latency 52.
> Ethernet MAC Station Address 00:80:64:1a:e8:bf.
> Wake-On-LAN password 00:00:00:00:00:00.
> Transceiver setting 0x--f-: advertise 10/100 Mbps half and full duplex.
> Flow control enabled.
> EEPROM active region checksum read as aa48, vs aa48 calculated value.
^ permalink raw reply related
* Re: [PATCH] [bonding]: clear header_ops when last slave detached
From: Wengang @ 2014-11-17 1:19 UTC (permalink / raw)
To: netdev; +Cc: Wengang Wang
In-Reply-To: <1415845156-15461-1-git-send-email-wen.gang.wang@oracle.com>
Hi,
Could anybody please review this patch?
thanks,
wengang
于 2014年11月13日 10:19, Wengang Wang 写道:
> When last slave of a bonding master is removed, the bonding then does not work.
> When packet_snd is called against with a master net_device, it accesses
> header_ops. In case the header_ops is not valid any longer(say module unloaded)
> it will then access an invalid memory address.
> This patch try to fix this issue by clearing header_ops when last slave
> detached.
>
> Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
> ---
> drivers/net/bonding/bond_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index c9ac06c..84a34fc 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1728,6 +1728,8 @@ static int __bond_release_one(struct net_device *bond_dev,
> unblock_netpoll_tx();
> synchronize_rcu();
> bond->slave_cnt--;
> + if (!bond->slave_cnt)
> + bond->dev->header_ops = NULL;
>
> if (!bond_has_slaves(bond)) {
> call_netdevice_notifiers(NETDEV_CHANGEADDR, bond->dev);
^ permalink raw reply
* ipx: fix locking regression in ipx_sendmsg and ipx_recvmsg
From: Jiri Bohac @ 2014-11-17 1:34 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, netdev; +Cc: Arnd Bergmann
This fixes an old regression introduced by commit
b0d0d915 (ipx: remove the BKL).
When a recvmsg syscall blocks waiting for new data, no data can be sent on the
same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked.
This breaks mars-nwe (NetWare emulator):
- the ncpserv process reads the request using recvmsg
- ncpserv forks and spawns nwconn
- ncpserv calls a (blocking) recvmsg and waits for new requests
- nwconn deadlocks in sendmsg on the same socket
Commit b0d0d915 has simply replaced BKL locking with
lock_sock/release_sock. Unlike now, BKL got unlocked while
sleeping, so a blocking recvmsg did not block a concurrent
sendmsg.
Similarly, a potentially sleeping sendmsg() could block calls to recvmsg().
Only keep the socket locked while actually working with the socket data and
release it prior to calling skb_recv_datagram() / ipxitf_send().
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index 91729b8..1e0d796 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -1703,11 +1703,11 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
/* if (sk->sk_zapped)
return -EIO; */ /* Socket not bound */
if (flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT))
- goto out;
+ goto out_release;
/* Max possible packet size limited by 16 bit pktsize in header */
if (len >= 65535 - sizeof(struct ipxhdr))
- goto out;
+ goto out_release;
if (usipx) {
if (!ipxs->port) {
@@ -1718,24 +1718,24 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
#ifdef CONFIG_IPX_INTERN
rc = -ENETDOWN;
if (!ipxs->intrfc)
- goto out; /* Someone zonked the iface */
+ goto out_release; /* Someone zonked the iface */
memcpy(uaddr.sipx_node, ipxs->intrfc->if_node,
IPX_NODE_LEN);
#endif
rc = __ipx_bind(sock, (struct sockaddr *)&uaddr,
sizeof(struct sockaddr_ipx));
if (rc)
- goto out;
+ goto out_release;
}
rc = -EINVAL;
if (msg->msg_namelen < sizeof(*usipx) ||
usipx->sipx_family != AF_IPX)
- goto out;
+ goto out_release;
} else {
rc = -ENOTCONN;
if (sk->sk_state != TCP_ESTABLISHED)
- goto out;
+ goto out_release;
usipx = &local_sipx;
usipx->sipx_family = AF_IPX;
@@ -1745,12 +1745,16 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
memcpy(usipx->sipx_node, ipxs->dest_addr.node, IPX_NODE_LEN);
}
+ /* releases sk */
rc = ipxrtr_route_packet(sk, usipx, msg->msg_iov, len,
flags & MSG_DONTWAIT);
if (rc >= 0)
rc = len;
-out:
+ goto out;
+
+out_release:
release_sock(sk);
+out:
return rc;
}
@@ -1776,20 +1780,21 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
#ifdef CONFIG_IPX_INTERN
rc = -ENETDOWN;
if (!ipxs->intrfc)
- goto out; /* Someone zonked the iface */
+ goto out_release; /* Someone zonked the iface */
memcpy(uaddr.sipx_node, ipxs->intrfc->if_node, IPX_NODE_LEN);
#endif /* CONFIG_IPX_INTERN */
rc = __ipx_bind(sock, (struct sockaddr *)&uaddr,
sizeof(struct sockaddr_ipx));
if (rc)
- goto out;
+ goto out_release;
}
rc = -ENOTCONN;
if (sock_flag(sk, SOCK_ZAPPED))
- goto out;
+ goto out_release;
+ release_sock(sk);
skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT,
flags & MSG_DONTWAIT, &rc);
if (!skb) {
@@ -1807,8 +1812,10 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
rc = skb_copy_datagram_iovec(skb, sizeof(struct ipxhdr), msg->msg_iov,
copied);
- if (rc)
- goto out_free;
+ if (rc) {
+ skb_free_datagram(sk, skb);
+ goto out;
+ }
if (skb->tstamp.tv64)
sk->sk_stamp = skb->tstamp;
@@ -1822,11 +1829,11 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
msg->msg_namelen = sizeof(*sipx);
}
rc = copied;
+ goto out;
-out_free:
- skb_free_datagram(sk, skb);
-out:
+out_release:
release_sock(sk);
+out:
return rc;
}
diff --git a/net/ipx/ipx_route.c b/net/ipx/ipx_route.c
index 67e7ad3..2f082af 100644
--- a/net/ipx/ipx_route.c
+++ b/net/ipx/ipx_route.c
@@ -163,6 +163,7 @@ int ipxrtr_route_skb(struct sk_buff *skb)
/*
* Route an outgoing frame from a socket.
+ * Expects sk to be locked and releases it before returning.
*/
int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx,
struct iovec *iov, size_t len, int noblock)
@@ -184,7 +185,7 @@ int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx,
rt = ipxrtr_lookup(usipx->sipx_network);
rc = -ENETUNREACH;
if (!rt)
- goto out;
+ goto out_release;
intrfc = rt->ir_intrfc;
}
@@ -242,12 +243,16 @@ int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx,
else
ipx->ipx_checksum = ipx_cksum(ipx, len + sizeof(struct ipxhdr));
+ release_sock(sk);
rc = ipxitf_send(intrfc, skb, (rt && rt->ir_routed) ?
rt->ir_router_node : ipx->ipx_dest.node);
+ goto out;
out_put:
ipxitf_put(intrfc);
if (rt)
ipxrtr_put(rt);
+out_release:
+ release_sock(sk);
out:
return rc;
}
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply related
* Re: [PATCH] bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
From: Linus Lüssing @ 2014-11-17 2:08 UTC (permalink / raw)
To: David S. Miller
Cc: Linus Lüssing, netdev, bridge, Stephen Hemminger, Herbert Xu,
linux-kernel
In-Reply-To: <20141102220145.GA25604@gondor.apana.org.au>
On Mon, Nov 03, 2014 at 06:01:46AM +0800, Herbert Xu wrote:
> On Mon, Sep 22, 2014 at 01:32:44AM +0200, Linus Lüssing wrote:
> > Signed-off-by: Linus Lüssing <linus.luessing@web.de>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Hi David,
are there any unanswered questions left?
Cheers, Linus
^ permalink raw reply
* Re: [PATCH] bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
From: Herbert Xu @ 2014-11-17 2:33 UTC (permalink / raw)
To: Linus Lüssing
Cc: Stephen Hemminger, netdev, bridge, David S. Miller, linux-kernel
In-Reply-To: <20141117020816.GD2469@odroid>
On Mon, Nov 17, 2014 at 03:08:16AM +0100, Linus Lüssing wrote:
> On Mon, Nov 03, 2014 at 06:01:46AM +0800, Herbert Xu wrote:
> > On Mon, Sep 22, 2014 at 01:32:44AM +0200, Linus Lüssing wrote:
> > > Signed-off-by: Linus Lüssing <linus.luessing@web.de>
> >
> > Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Hi David,
>
> are there any unanswered questions left?
Please resubmit your patch as it's no longer in David's queue.
Cheers,
--
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
* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2014-11-17 2:34 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Jarno Rajahalme, Pravin B Shelar
[-- Attachment #1: Type: text/plain, Size: 2933 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from net/openvswitch/flow.h:23,
from net/openvswitch/flow_netlink.c:21:
net/openvswitch/flow_netlink.c: In function 'ovs_key_from_nlattrs':
include/linux/kern_levels.h:4:18: error: called object is not a function or function pointer
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^
include/linux/printk.h:247:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
net/openvswitch/datapath.h:205:3: note: in expansion of macro 'pr_info'
pr_info("netlink: " fmt "\n", ##__VA_ARGS__); \
^
net/openvswitch/flow_netlink.c:777:4: note: in expansion of macro 'OVS_NLERR'
OVS_NLERR("IPv6 flow label %x is out of range (max=%x).\n",
^
net/openvswitch/datapath.h:205:27: error: expected ')' before string constant
pr_info("netlink: " fmt "\n", ##__VA_ARGS__); \
^
net/openvswitch/flow_netlink.c:19:41: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
^
net/openvswitch/datapath.h:205:3: note: in expansion of macro 'pr_info'
pr_info("netlink: " fmt "\n", ##__VA_ARGS__); \
^
net/openvswitch/flow_netlink.c:777:4: note: in expansion of macro 'OVS_NLERR'
OVS_NLERR("IPv6 flow label %x is out of range (max=%x).\n",
^
Caused by commit 05da5898a96c ("openvswitch: Add support for
OVS_FLOW_ATTR_PROBE") interacting with commit fecaef85f718
("openvswitch: Validate IPv6 flow key and mask values") from the net
tree.
I applied the following merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 17 Nov 2014 13:31:33 +1100
Subject: [PATCH] openvswitch: fix up for OVS_NLERR API change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/openvswitch/flow_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 259b2f1ebd0d..45bdcf596414 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -774,7 +774,7 @@ static int ovs_key_from_nlattrs(struct sw_flow_match *match, u64 attrs,
}
if (ipv6_key->ipv6_label & htonl(0xFFF00000)) {
- OVS_NLERR("IPv6 flow label %x is out of range (max=%x).\n",
+ OVS_NLERR(log, "IPv6 flow label %x is out of range (max=%x).\n",
ntohl(ipv6_key->ipv6_label), (1 << 20) - 1);
return -EINVAL;
}
--
2.1.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH 3/3] sh_eth: Fix dma mapping issue
From: Simon Horman @ 2014-11-17 4:09 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Yoshihiro Kaneko, netdev, David S. Miller, Magnus Damm, linux-sh
In-Reply-To: <54653948.5070606@cogentembedded.com>
Hi Sergei,
On Fri, Nov 14, 2014 at 02:05:44AM +0300, Sergei Shtylyov wrote:
> On 11/13/2014 10:05 AM, Yoshihiro Kaneko wrote:
>
> >From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>
> >When CONFIG_DMA_API_DEBUG=y, many DMA error messages reports.
> >In order to use DMA debug, This patch fix following issues.
>
> >Issue 1:
> >If dma_mapping_error function is not called appropriately after
> >DMA mapping, DMA debug will report error message when DMA unmap
> >function is called.
>
> >Issue 2:
> >If skb_reserve function is called after DMA mapping, the relationship
> >between mapping addr and mapping size will be broken.
> >In this case, DMA debug will report error messages when DMA sync
> >function and DMA unmap function are called.
>
> >Issue 3:
> >If the size of frame data is less than ETH_ZLEN, the size is resized
> >to ETH_ZLEN after DMA map function is called.
> >In the TX skb freeing function, dma unmap function is called with that
> >resized value. So, unmap size error will reported.
>
> >Issue 4:
> >In the rx function, DMA map function is called without DMA unmap function
> >is called for RX skb reallocating.
> >It will case the DMA debug error that number of debug entry is full and
> >DMA debug logic is stopped.
>
> The rule of thumb is "fix one issue per patch". Please split accordingly.
>
> >Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> >Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>
> Thanks for beating me to it. Fixing these issues has been on my agenda
> for a long time... :-)
as this patch is somewhat involved and as you have pointed out needs a bit
of work I'm wondering if you could take it over.
> >---
> > drivers/net/ethernet/renesas/sh_eth.c | 26 +++++++++++++++++++++++---
> > 1 file changed, 23 insertions(+), 3 deletions(-)
>
> >diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> >index 0e4a407..23318cf 100644
> >--- a/drivers/net/ethernet/renesas/sh_eth.c
> >+++ b/drivers/net/ethernet/renesas/sh_eth.c
> >@@ -1136,6 +1136,11 @@ static void sh_eth_ring_format(struct net_device *ndev)
> > dma_map_single(&ndev->dev, skb->data, rxdesc->buffer_length,
> > DMA_FROM_DEVICE);
> > rxdesc->addr = virt_to_phys(skb->data);
>
> Can't we get rid of these bogus virt_to_phys() calls, while at it?
> dma_map_single() returns a DMA address, no?
>
> >+ if (dma_mapping_error(&ndev->dev, rxdesc->addr)) {
> >+ dev_kfree_skb(mdp->rx_skbuff[i]);
> >+ mdp->rx_skbuff[i] = NULL;
> >+ break;
> >+ }
> > rxdesc->status = cpu_to_edmac(mdp, RD_RACT | RD_RFP);
> >
> > /* Rx descriptor address set */
> >@@ -1364,7 +1369,7 @@ static int sh_eth_txfree(struct net_device *ndev)
> > if (mdp->tx_skbuff[entry]) {
> > dma_unmap_single(&ndev->dev, txdesc->addr,
> > txdesc->buffer_length, DMA_TO_DEVICE);
> >- dev_kfree_skb_irq(mdp->tx_skbuff[entry]);
> >+ dev_kfree_skb_any(mdp->tx_skbuff[entry]);
>
> Hm, I'm not sure where is this described in the changelog...
>
> > mdp->tx_skbuff[entry] = NULL;
> > free_num++;
> > }
> >@@ -1466,11 +1471,19 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
> > if (skb == NULL)
> > break; /* Better luck next round. */
> > sh_eth_set_receive_align(skb);
> >+ dma_unmap_single(&ndev->dev, rxdesc->addr,
> >+ rxdesc->buffer_length,
> >+ DMA_FROM_DEVICE);
> > dma_map_single(&ndev->dev, skb->data,
> > rxdesc->buffer_length, DMA_FROM_DEVICE);
> >
> > skb_checksum_none_assert(skb);
> > rxdesc->addr = virt_to_phys(skb->data);
>
> Likewise, can we get rid of this bogu?
>
> >+ if (dma_mapping_error(&ndev->dev, rxdesc->addr)) {
> >+ dev_kfree_skb_any(mdp->rx_skbuff[entry]);
> >+ mdp->rx_skbuff[entry] = NULL;
> >+ break;
> >+ }
> > }
> > if (entry >= mdp->num_rx_ring - 1)
> > rxdesc->status |=
> >@@ -2104,12 +2117,18 @@ static int sh_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> > if (!mdp->cd->hw_swap)
> > sh_eth_soft_swap(phys_to_virt(ALIGN(txdesc->addr, 4)),
> > skb->len + 2);
> >- txdesc->addr = dma_map_single(&ndev->dev, skb->data, skb->len,
> >- DMA_TO_DEVICE);
> > if (skb->len < ETH_ZLEN)
> > txdesc->buffer_length = ETH_ZLEN;
> > else
> > txdesc->buffer_length = skb->len;
> >+ txdesc->addr = dma_map_single(&ndev->dev, skb->data,
> >+ txdesc->buffer_length,
> >+ DMA_TO_DEVICE);
> >+ if (dma_mapping_error(&ndev->dev, txdesc->addr)) {
> >+ dev_kfree_skb_any(mdp->tx_skbuff[entry]);
> >+ mdp->tx_skbuff[entry] = NULL;
> >+ goto out;
>
> Why not just *return*?!
>
> [...]
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [PATCH 4/4] rhashtable: Add parent argument to mutex_is_held
From: Herbert Xu @ 2014-11-17 4:46 UTC (permalink / raw)
To: Josh Triplett; +Cc: tgraf, netdev, eric.dumazet, paulmck
In-Reply-To: <7DA2F716-1E87-4AC8-A18F-CE5BFB6E6F81@joshtriplett.org>
On Sat, Nov 15, 2014 at 06:37:26PM -0800, Josh Triplett wrote:
> On November 15, 2014 6:22:27 PM PST, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >Josh Triplett <josh@joshtriplett.org> wrote:
> >>
> >> - Set up the new empty table with the new set of hash parameters.
> >> - synchronize_rcu(). Readers will now search both old and new
> >tables.
> >> - Peel nodes off the ends of the old hash table and add them to the
> >new
> >
> >We currently use a singly linked list in rhashtable. Peeling nodes
> >off the end would mean upgrading to a doubly linked list, which is
> >no different than keeping two lists in terms of cache footprint, no?
>
> No, since each pass just handles one set of nodes from each bucket anyway, you can just do a bit more work in the rehasher instead.
OK let me see if I could implement something like that in rhashtable.
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: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Eric Dumazet @ 2014-11-17 5:01 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <1416168961.17262.96.camel@edumazet-glaptop2.roam.corp.google.com>
On Sun, 2014-11-16 at 12:16 -0800, Eric Dumazet wrote:
> Thanks Denys !
>
> Could you try following patch ?
>
> Thanks !
Hmm.... I have an updated patch, sorry.
(A memcpy_fromiovec() has to be memcpy_fromiovecend() )
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index a3d453b94747..c2bbfcd9c0db 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2998,7 +2998,7 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
{
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_fastopen_request *fo = tp->fastopen_req;
- int syn_loss = 0, space, i, err = 0, iovlen = fo->data->msg_iovlen;
+ int syn_loss = 0, space, err = 0;
struct sk_buff *syn_data = NULL, *data;
unsigned long last_syn_loss = 0;
@@ -3031,25 +3031,19 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
/* limit to order-0 allocations */
space = min_t(size_t, space, SKB_MAX_HEAD(MAX_TCP_HEADER));
- syn_data = skb_copy_expand(syn, MAX_TCP_HEADER, space,
- sk->sk_allocation);
- if (syn_data == NULL)
+ syn_data = sk_stream_alloc_skb(sk, space, sk->sk_allocation);
+ if (!syn_data)
goto fallback;
- for (i = 0; i < iovlen && syn_data->len < space; ++i) {
- struct iovec *iov = &fo->data->msg_iov[i];
- unsigned char __user *from = iov->iov_base;
- int len = iov->iov_len;
-
- if (syn_data->len + len > space)
- len = space - syn_data->len;
- else if (i + 1 == iovlen)
- /* No more data pending in inet_wait_for_connect() */
- fo->data = NULL;
+ syn_data->ip_summed = CHECKSUM_PARTIAL;
+ memcpy(syn_data->cb, syn->cb, sizeof(syn->cb));
+ if (memcpy_fromiovecend(skb_put(syn_data, space),
+ fo->data->msg_iov, 0, space))
+ goto fallback;
- if (skb_add_data(syn_data, from, len))
- goto fallback;
- }
+ /* No more data pending in inet_wait_for_connect() */
+ if (space == fo->size)
+ fo->data = NULL;
/* Queue a data-only packet after the regular SYN for retransmission */
data = pskb_copy(syn_data, sk->sk_allocation);
@@ -3101,13 +3095,10 @@ int tcp_connect(struct sock *sk)
return 0;
}
- buff = alloc_skb_fclone(MAX_TCP_HEADER + 15, sk->sk_allocation);
- if (unlikely(buff == NULL))
+ buff = sk_stream_alloc_skb(sk, 0, sk->sk_allocation);
+ if (unlikely(!buff))
return -ENOBUFS;
- /* Reserve space for headers. */
- skb_reserve(buff, MAX_TCP_HEADER);
-
tcp_init_nondata_skb(buff, tp->write_seq++, TCPHDR_SYN);
tp->retrans_stamp = tcp_time_stamp;
tcp_connect_queue_skb(sk, buff);
^ permalink raw reply related
* linux-next: manual merge of the tiny tree with the net-next tree
From: Stephen Rothwell @ 2014-11-17 5:35 UTC (permalink / raw)
To: Josh Triplett, David Miller, netdev
Cc: linux-next, linux-kernel, Iulia Manda, Pravin B Shelar
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
Hi Josh,
Today's linux-next merge of the tiny tree got a conflict in
net/openvswitch/Kconfig between commit 8cd4313aa775 ("openvswitch: Fix
build failure") from the net-next tree and commit b043d487e255 ("lib:
Conditionally compile flex_array") from the tiny 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 net/openvswitch/Kconfig
index b7d818c59423,1d979cecd66e..000000000000
--- a/net/openvswitch/Kconfig
+++ b/net/openvswitch/Kconfig
@@@ -4,9 -4,8 +4,10 @@@
config OPENVSWITCH
tristate "Open vSwitch"
+ depends on INET
select LIBCRC32C
+ select NET_MPLS_GSO
+ select FLEX_ARRAY
---help---
Open vSwitch is a multilayer Ethernet switch targeted at virtualized
environments. In addition to supporting a variety of features
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] enic: support skb->xmit_more
From: Eric Dumazet @ 2014-11-17 5:40 UTC (permalink / raw)
To: Govindarajulu Varadarajan; +Cc: davem, netdev, ssujith, benve
In-Reply-To: <1416179042-1858-1-git-send-email-_govind@gmx.com>
On Mon, 2014-11-17 at 04:34 +0530, Govindarajulu Varadarajan wrote:
> Update posted_index only when skb->xmit_more is 0 or tx queue is full.
>
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
> ---
> drivers/net/ethernet/cisco/enic/enic_main.c | 8 ++++++--
> drivers/net/ethernet/cisco/enic/vnic_wq.h | 20 +++++++++++---------
> 2 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
> index 5afe360..52bccfd 100644
> --- a/drivers/net/ethernet/cisco/enic/enic_main.c
> +++ b/drivers/net/ethernet/cisco/enic/enic_main.c
> @@ -533,6 +533,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
> struct vnic_wq *wq;
> unsigned long flags;
> unsigned int txq_map;
> + struct netdev_queue *txq;
>
> if (skb->len <= 0) {
> dev_kfree_skb_any(skb);
> @@ -541,6 +542,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
>
> txq_map = skb_get_queue_mapping(skb) % enic->wq_count;
> wq = &enic->wq[txq_map];
> + txq = netdev_get_tx_queue(netdev, skb_get_queue_mapping(skb));
>
This is strange.
Why dont you use instead :
txq = netdev_get_tx_queue(netdev, txq_map);
> /* Non-TSO sends must fit within ENIC_NON_TSO_MAX_DESC descs,
> * which is very likely. In the off chance it's going to take
> @@ -558,7 +560,7 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
>
> if (vnic_wq_desc_avail(wq) <
> skb_shinfo(skb)->nr_frags + ENIC_DESC_MAX_SPLITS) {
> - netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
See here ? Its not equivalent to previous code.
> + netif_tx_stop_queue(txq);
> /* This is a hard error, log it */
> netdev_err(netdev, "BUG! Tx ring full when queue awake!\n");
^ permalink raw reply
* Re: [PATCH 1/1 net-next] wireless: remove unnecessary sizeof(u8)
From: Fabian Frederick @ 2014-11-17 5:56 UTC (permalink / raw)
To: Julian Calaby
Cc: Johannes Berg, linux-wireless, Larry Finger, Chaoming Li, netdev,
linux-kernel@vger.kernel.org, Emmanuel Grumbach, b43-dev,
Stefano Brivio, John W. Linville, Intel Linux Wireless
In-Reply-To: <CAGRGNgWqjsDu_mQK=_agBWjOequb4b7ffgCuxRH=9d72grDYtQ@mail.gmail.com>
> On 16 November 2014 at 23:33 Julian Calaby <julian.calaby@gmail.com> wrote:
>
>
> Hi Fabian,
>
> On Sat, Nov 15, 2014 at 7:55 AM, Fabian Frederick <fabf@skynet.be> wrote:
> > sizeof(u8) is always 1.
>
> I thought that sizeof(*variable) was preferred over sizeof(type), so
> shouldn't these be switched to that format instead?
>
> (I know that this is all no-op, but it should reduce the potential for
> highly unlikely bugs in the future. Also, the extra processing is
> compile-time not run-time.)
>
> Thanks,
Hi Julian,
Of course but char/u8/s8... allocations never use it and result would be the
same:
factor 1 multiplication.
Those rare occurrences (+- 30 in the whole kernel) where we have
sizeof(u8/s8) is ambiguous.
Having a patch removing it gives a pointer...
If the developer meant something else, he will be able to fix it.
Regards,
Fabian
^ permalink raw reply
* Re: [PATCH] bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
From: David Miller @ 2014-11-17 6:12 UTC (permalink / raw)
To: linus.luessing; +Cc: stephen, netdev, bridge, herbert, linux-kernel
In-Reply-To: <20141117020816.GD2469@odroid>
From: Linus Lüssing <linus.luessing@c0d3.blue>
Date: Mon, 17 Nov 2014 03:08:16 +0100
> On Mon, Nov 03, 2014 at 06:01:46AM +0800, Herbert Xu wrote:
>> On Mon, Sep 22, 2014 at 01:32:44AM +0200, Linus Lüssing wrote:
>> > Signed-off-by: Linus Lüssing <linus.luessing@web.de>
>>
>> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Hi David,
>
> are there any unanswered questions left?
I expect to get this from the netfilter folks, since it is a
netfilter change. So you should submit it to the netfilter
maintainers.
^ permalink raw reply
* Re: [PATCH 4/4] rhashtable: Add parent argument to mutex_is_held
From: Thomas Graf @ 2014-11-17 6:16 UTC (permalink / raw)
To: Herbert Xu; +Cc: Josh Triplett, netdev, eric.dumazet, paulmck
In-Reply-To: <20141117044657.GA30723@gondor.apana.org.au>
On 11/17/14 at 12:46pm, Herbert Xu wrote:
> On Sat, Nov 15, 2014 at 06:37:26PM -0800, Josh Triplett wrote:
> > On November 15, 2014 6:22:27 PM PST, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > >Josh Triplett <josh@joshtriplett.org> wrote:
> > >>
> > >> - Set up the new empty table with the new set of hash parameters.
> > >> - synchronize_rcu(). Readers will now search both old and new
> > >tables.
> > >> - Peel nodes off the ends of the old hash table and add them to the
> > >new
> > >
> > >We currently use a singly linked list in rhashtable. Peeling nodes
> > >off the end would mean upgrading to a doubly linked list, which is
> > >no different than keeping two lists in terms of cache footprint, no?
> >
> > No, since each pass just handles one set of nodes from each bucket anyway, you can just do a bit more work in the rehasher instead.
>
> OK let me see if I could implement something like that in rhashtable.
This sounds great. Thanks Herbert and Josh!
^ 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