* [PATCH 1/3 for 3.18] rtlwifi: rtl8192ce: Fix editing error that causes silent memory corruption
From: Larry Finger @ 2014-11-28 16:41 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA, Catalin Iacob
In-Reply-To: <1417192876-12101-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
In the major update of the rtlwifi-family of drivers, there was an editing
mistake. Unfortunately, this particular error leads to memory corruption that
silently leads to failure of the system. This patch is one of three needed to
fix the kernel regression reported at https://bugzilla.kernel.org/show_bug.cgi?id=88951.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Reported-by: Catalin Iacob <iacobcatalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Tested-by: Catalin Iacob <iacobcatalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Catalin Iacob <iacobcatalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
index dc3d20b..0916275 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
@@ -720,16 +720,15 @@ u32 rtl92ce_get_desc(u8 *p_desc, bool istx, u8 desc_name)
break;
}
} else {
- struct rx_desc_92c *pdesc = (struct rx_desc_92c *)p_desc;
switch (desc_name) {
case HW_DESC_OWN:
- ret = GET_RX_DESC_OWN(pdesc);
+ ret = GET_RX_DESC_OWN(p_desc);
break;
case HW_DESC_RXPKT_LEN:
- ret = GET_RX_DESC_PKT_LEN(pdesc);
+ ret = GET_RX_DESC_PKT_LEN(p_desc);
break;
case HW_DESC_RXBUFF_ADDR:
- ret = GET_RX_STATUS_DESC_BUFF_ADDR(pdesc);
+ ret = GET_RX_DESC_BUFF_ADDR(p_desc);
break;
default:
RT_ASSERT(false, "ERR rxdesc :%d not process\n",
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3 for 3.18] rtlwifi: rtl8192ce: Fix kernel crashes due to missing callback entry
From: Larry Finger @ 2014-11-28 16:41 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA, Catalin Iacob
In-Reply-To: <1417192876-12101-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
In the major update of the rtlwifi-family of drivers, one of the callback entries
was missed, which leads to memory corruption. Unfortunately, this corruption
never caused a kernel oops, but showed up in other parts of the system.
This patch is one of three needed to fix the kernel regression reported at
https://bugzilla.kernel.org/show_bug.cgi?id=88951.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Reported-by: Catalin Iacob <iacobcatalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Tested-by: Catalin Iacob <iacobcatalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Catalin Iacob <iacobcatalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 3 +++
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 17 +++++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192ce/trx.h | 2 ++
3 files changed, 22 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
index 46ea076..dd5aa08 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
@@ -228,6 +228,7 @@ static struct rtl_hal_ops rtl8192ce_hal_ops = {
.led_control = rtl92ce_led_control,
.set_desc = rtl92ce_set_desc,
.get_desc = rtl92ce_get_desc,
+ .is_tx_desc_closed = rtl92ce_is_tx_desc_closed,
.tx_polling = rtl92ce_tx_polling,
.enable_hw_sec = rtl92ce_enable_hw_security_config,
.set_key = rtl92ce_set_key,
@@ -271,6 +272,8 @@ static struct rtl_hal_cfg rtl92ce_hal_cfg = {
.maps[MAC_RCR_ACRC32] = ACRC32,
.maps[MAC_RCR_ACF] = ACF,
.maps[MAC_RCR_AAP] = AAP,
+ .maps[MAC_HIMR] = REG_HIMR,
+ .maps[MAC_HIMRE] = REG_HIMRE,
.maps[EFUSE_TEST] = REG_EFUSE_TEST,
.maps[EFUSE_CTRL] = REG_EFUSE_CTRL,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
index 0916275..e88dcd0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
@@ -739,6 +739,23 @@ u32 rtl92ce_get_desc(u8 *p_desc, bool istx, u8 desc_name)
return ret;
}
+bool rtl92ce_is_tx_desc_closed(struct ieee80211_hw *hw,
+ u8 hw_queue, u16 index)
+{
+ struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
+ struct rtl8192_tx_ring *ring = &rtlpci->tx_ring[hw_queue];
+ u8 *entry = (u8 *)(&ring->desc[ring->idx]);
+ u8 own = (u8)rtl92ce_get_desc(entry, true, HW_DESC_OWN);
+
+ /*beacon packet will only use the first
+ *descriptor defautly,and the own may not
+ *be cleared by the hardware
+ */
+ if (own)
+ return false;
+ return true;
+}
+
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
index 9a39ec4..4bec4b0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
@@ -723,6 +723,8 @@ bool rtl92ce_rx_query_desc(struct ieee80211_hw *hw,
void rtl92ce_set_desc(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
u8 desc_name, u8 *val);
u32 rtl92ce_get_desc(u8 *pdesc, bool istx, u8 desc_name);
+bool rtl92ce_is_tx_desc_closed(struct ieee80211_hw *hw,
+ u8 hw_queue, u16 index);
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue);
void rtl92ce_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 *pdesc,
bool b_firstseg, bool b_lastseg,
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3 for 3.18] rtlwifi: rtl8192ce: Fix missing interrupt ready flag
From: Larry Finger @ 2014-11-28 16:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Catalin Iacob
In-Reply-To: <1417192876-12101-1-git-send-email-Larry.Finger@lwfinger.net>
Proper operation with the rewritten PCI mini driver requires that a flag be set
when interrupts are enabled. This flag was missed. This patch is one of three needed to
fix the kernel regression reported at https://bugzilla.kernel.org/show_bug.cgi?id=88951.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Catalin Iacob <iacobcatalin@gmail.com>
Tested-by: Catalin Iacob <iacobcatalin@gmail.com>
Cc: Catalin Iacob <iacobcatalin@gmail.com>
---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index 55357d6..d2ec516 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -1287,6 +1287,7 @@ void rtl92ce_enable_interrupt(struct ieee80211_hw *hw)
rtl_write_dword(rtlpriv, REG_HIMR, rtlpci->irq_mask[0] & 0xFFFFFFFF);
rtl_write_dword(rtlpriv, REG_HIMRE, rtlpci->irq_mask[1] & 0xFFFFFFFF);
+ rtlpci->irq_enabled = true;
}
void rtl92ce_disable_interrupt(struct ieee80211_hw *hw)
@@ -1296,7 +1297,7 @@ void rtl92ce_disable_interrupt(struct ieee80211_hw *hw)
rtl_write_dword(rtlpriv, REG_HIMR, IMR8190_DISABLED);
rtl_write_dword(rtlpriv, REG_HIMRE, IMR8190_DISABLED);
- synchronize_irq(rtlpci->pdev->irq);
+ rtlpci->irq_enabled = false;
}
static void _rtl92ce_poweroff_adapter(struct ieee80211_hw *hw)
--
2.1.2
^ permalink raw reply related
* Re: [patch net-next v4 00/21] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Roopa Prabhu @ 2014-11-28 16:52 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman@tuxdriver.com,
Andy Gospodarek, Thomas Graf, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim,
Florian Fainelli, John Linville
In-Reply-To: <CAE4R7bDNbyfxx+XExmej8-p=E3X4cHc+Sr75S=aO67XMYcmU8g@mail.gmail.com>
On 11/28/14, 3:59 AM, Scott Feldman wrote:
> Thanks Jiri for coordinating this effort. It looks like we're close
> to convergence on this first patch set. I sifted thru review comments
> and compiled a list of items for follow-on work. I hope it's OK to
> use etherpad for this:
>
> https://etherpad.wikimedia.org/p/netdev-swdev-todo
>
> Feel free to edit as needed and claim an item if you intend to work on
> it. Don't turn the etherpad into a discussion board...try to keep it
> as list of work items. I don't think any of these items should hold
> up current patch set.
Thanks scott/jiri for putting this together. I made sure all my concerns
are covered on the ether-pad ;)
On Thu, Nov 27, 2014 at 2:40 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Hi all.
>>
>> This patchset is just the first phase of switch and switch-ish device
>> support api in kernel. Note that the api will extend.
>>
>> So what this patchset includes:
>> - introduce switchdev api skeleton for implementing switch drivers
>> - introduce rocker switch driver which implements switchdev api fdb and
>> bridge set/get link ndos
>>
>> As to the discussion if there is need to have specific class of device
>> representing the switch itself, so far we found no need to introduce that.
>> But we are generally ok with the idea and when the time comes and it will
>> be needed, it can be easily introduced without any disturbance.
>>
>> This patchset introduces switch id export through rtnetlink and sysfs,
>> which is similar to what we have for port id in SR-IOV. I will send iproute2
>> patchset for showing the switch id for port netdevs once this is applied.
>> This applies also for the PF_BRIDGE and fdb iproute2 patches.
>>
>> iproute2 patches are now available here:
>> https://github.com/jpirko/iproute2-rocker
>>
>> For detailed description and version history, please see individual patches.
>>
>> In v4 I reordered the patches leaving rocker patches on the end of the patchset.
>>
>> Jiri Pirko (10):
>> bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
>> neigh: sort Neighbor Cache Entry Flags
>> bridge: convert flags in fbd entry into bitfields
>> net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
>> net: rename netdev_phys_port_id to more generic name
>> net: introduce generic switch devices support
>> rtnl: expose physical switch id for particular device
>> net-sysfs: expose physical switch id for particular device
>> rocker: introduce rocker switch driver
>> rocker: implement ndo_fdb_dump
>>
>> Scott Feldman (9):
>> bridge: call netdev_sw_port_stp_update when bridge port STP status
>> changes
>> bridge: add API to notify bridge driver of learned FBD on offloaded
>> device
>> bridge: move private brport flags to if_bridge.h so port drivers can
>> use flags
>> bridge: add new brport flag LEARNING_SYNC
>> bridge: add new hwmode swdev
>> bridge: add brport flags to dflt bridge_getlink
>> rocker: implement rocker ofdpa flow table manipulation
>> rocker: implement L2 bridge offloading
>> rocker: add ndo_bridge_setlink/getlink support for learning policy
>>
>> Thomas Graf (2):
>> rocker: Add proper validation of Netlink attributes
>> rocker: Use logical operators on booleans
>>
>> Documentation/ABI/testing/sysfs-class-net | 8 +
>> Documentation/networking/switchdev.txt | 59 +
>> MAINTAINERS | 14 +
>> drivers/net/ethernet/Kconfig | 1 +
>> drivers/net/ethernet/Makefile | 1 +
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
>> drivers/net/ethernet/emulex/benet/be_main.c | 3 +-
>> drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +-
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +-
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
>> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 11 +-
>> drivers/net/ethernet/rocker/Kconfig | 27 +
>> drivers/net/ethernet/rocker/Makefile | 5 +
>> drivers/net/ethernet/rocker/rocker.c | 4374 ++++++++++++++++++++++
>> drivers/net/ethernet/rocker/rocker.h | 428 +++
>> drivers/net/macvlan.c | 4 +-
>> drivers/net/vxlan.c | 4 +-
>> include/linux/if_bridge.h | 31 +
>> include/linux/netdevice.h | 39 +-
>> include/linux/rtnetlink.h | 9 +-
>> include/net/switchdev.h | 37 +
>> include/uapi/linux/if_bridge.h | 1 +
>> include/uapi/linux/if_link.h | 2 +
>> include/uapi/linux/neighbour.h | 6 +-
>> net/Kconfig | 1 +
>> net/Makefile | 3 +
>> net/bridge/br_fdb.c | 144 +-
>> net/bridge/br_private.h | 21 +-
>> net/bridge/br_stp.c | 7 +
>> net/core/dev.c | 2 +-
>> net/core/net-sysfs.c | 26 +-
>> net/core/rtnetlink.c | 119 +-
>> net/switchdev/Kconfig | 13 +
>> net/switchdev/Makefile | 5 +
>> net/switchdev/switchdev.c | 52 +
>> 35 files changed, 5366 insertions(+), 105 deletions(-)
>> create mode 100644 Documentation/networking/switchdev.txt
>> create mode 100644 drivers/net/ethernet/rocker/Kconfig
>> create mode 100644 drivers/net/ethernet/rocker/Makefile
>> create mode 100644 drivers/net/ethernet/rocker/rocker.c
>> create mode 100644 drivers/net/ethernet/rocker/rocker.h
>> create mode 100644 include/net/switchdev.h
>> create mode 100644 net/switchdev/Kconfig
>> create mode 100644 net/switchdev/Makefile
>> create mode 100644 net/switchdev/switchdev.c
>>
>> --
>> 1.9.3
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] bridge: Fix NAT66ed IPv6 packets not being bridged correctly
From: Pablo Neira Ayuso @ 2014-11-28 17:55 UTC (permalink / raw)
To: Bernhard Thaler
Cc: sven, yoshfuji, netdev, bridge, jmorris, David Miller,
netfilter-devel, kuznet, kaber, linux-kernel
In-Reply-To: <54777AE6.7050102@wvnet.at>
On Thu, Nov 27, 2014 at 08:26:30PM +0100, Bernhard Thaler wrote:
> Hi,
>
> I tested Sven's patch in my setup and I think it should be safe to use
> it. It is shorter and cleaner written and he submitted it earlier.
Thanks for testing.
> I will be happy to assist you or Sven if any further work is needed.
Please, resubmit this patch to netfilter-devel@vger.kernel.org.
Thanks.
^ permalink raw reply
* tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Marcelo Ricardo Leitner @ 2014-11-28 19:25 UTC (permalink / raw)
To: herbert; +Cc: netdev
Hi,
I saw there are tun updates on Dave's queue but none seemed to handle this.
I can't use current net-next (799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a
kvm hypervisor because tun got clogged somehow. Bisected down to:
commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri Nov 7 21:22:23 2014 +0800
tun: Use iovec iterators
This patch removes the use of skb_copy_datagram_const_iovec in
favour of the iovec iterator-based skb_copy_datagram_iter.
tun interface, host drops 1 incoming packets from guest, shown at ip -s l l,
and keeps like that forever. netstat -s didn't mention any checksum issue
12: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master
virbr0 state UNKNOWN mode DEFAULT group default qlen 500
link/ether fe:54:00:10:3f:06 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
0 0 0 1 0 0
TX: bytes packets errors dropped carrier collsns
2704 51 0 0 0 0
And tap interfaces go counting dropped++ every time:
20: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master
virbr0 state UNKNOWN mode DEFAULT group default qlen 500
link/ether fe:97:a4:a6:14:65 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
0 0 0 16 0 0
TX: bytes packets errors dropped carrier collsns
1456 28 0 0 0 0
traffic capture on guest shows incoming and outgoing packets just fine, while
on host, it shows no incoming packets at all.
Tested with virtio_net and e1000.
With:
tun.c tun_get_user():
if (zerocopy)
err = zerocopy_sg_from_iter(skb, from);
else {
err = skb_copy_datagram_from_iter(skb, 0, from, len); <- fails
if (!err && msg_control) {
struct ubuf_info *uarg = msg_control;
uarg->callback(uarg, false);
}
}
if (err) {
tun->dev->stats.rx_dropped++;
kfree_skb(skb);
pr_err("%d %d %d %p\n", __LINE__, zerocopy, err, msg_control);
return -EFAULT;
}
And net/core/datagram.c, skb_copy_datagram_from_iter():
if (copy > 0) {
int ret;
if (copy > len)
copy = len;
ret = copy_from_iter(skb->data + offset, copy, from);
if (ret != copy) {
pr_err("%d ret=%d copy=%d offset=%d len=%d\n",
__LINE__, ret, copy, offset, len);
goto fault;
}
I get, for tun interfaces:
[ 75.435552] 506 ret=80 copy=90 offset=0 len=90
[ 75.435563] tun: 1124 0 -14 (null)
[ 75.499528] 506 ret=80 copy=90 offset=0 len=90
[ 75.499540] tun: 1124 0 -14 (null)
These were 1 drop on 1 interface each
And for tap interfaces:
[ 301.982639] 506 ret=80 copy=90 offset=0 len=90
[ 301.982649] tun: 1124 0 -14 (null)
[ 301.988625] 506 ret=80 copy=90 offset=0 len=90
[ 301.988635] tun: 1124 0 -14 (null)
[ 301.994762] 506 ret=80 copy=90 offset=0 len=90
[ 301.994773] tun: 1124 0 -14 (null)
[ 302.229962] 506 ret=332 copy=342 offset=0 len=342
[ 302.229972] tun: 1124 0 -14 (null)
[ 302.230621] 506 ret=332 copy=342 offset=0 len=342
[ 302.230627] tun: 1124 0 -14 (null)
[ 302.239065] 506 ret=332 copy=342 offset=0 len=342
[ 302.239071] tun: 1124 0 -14 (null)
It's returning 10 bytes less than the expected... ideas?
I can provide more info if needed, it's easy to reproduce in here.
Thanks,
Marcelo
^ permalink raw reply
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Al Viro @ 2014-11-28 20:37 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: herbert, netdev
In-Reply-To: <5478CC27.9040705@redhat.com>
On Fri, Nov 28, 2014 at 05:25:27PM -0200, Marcelo Ricardo Leitner wrote:
> Hi,
>
> I saw there are tun updates on Dave's queue but none seemed to handle this.
>
> I can't use current net-next
> (799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a kvm hypervisor
> because tun got clogged somehow. Bisected down to:
Umm... In host, presumably?
> And net/core/datagram.c, skb_copy_datagram_from_iter():
> if (copy > 0) {
> int ret;
> if (copy > len)
> copy = len;
> ret = copy_from_iter(skb->data + offset, copy, from);
> if (ret != copy) {
> pr_err("%d ret=%d copy=%d offset=%d
> len=%d\n", __LINE__, ret, copy, offset, len);
> goto fault;
> }
>
>
> I get, for tun interfaces:
> [ 75.435552] 506 ret=80 copy=90 offset=0 len=90
> [ 75.435563] tun: 1124 0 -14 (null)
> [ 75.499528] 506 ret=80 copy=90 offset=0 len=90
> [ 75.499540] tun: 1124 0 -14 (null)
>
> These were 1 drop on 1 interface each
>
> And for tap interfaces:
> [ 301.982639] 506 ret=80 copy=90 offset=0 len=90
> [ 301.982649] tun: 1124 0 -14 (null)
> [ 301.988625] 506 ret=80 copy=90 offset=0 len=90
> [ 301.988635] tun: 1124 0 -14 (null)
> [ 301.994762] 506 ret=80 copy=90 offset=0 len=90
> [ 301.994773] tun: 1124 0 -14 (null)
> [ 302.229962] 506 ret=332 copy=342 offset=0 len=342
> [ 302.229972] tun: 1124 0 -14 (null)
> [ 302.230621] 506 ret=332 copy=342 offset=0 len=342
> [ 302.230627] tun: 1124 0 -14 (null)
> [ 302.239065] 506 ret=332 copy=342 offset=0 len=342
> [ 302.239071] tun: 1124 0 -14 (null)
>
> It's returning 10 bytes less than the expected... ideas?
Could you print vnet_hdr_sz and sizeof(gso) right after that
copy_from_iter(&gso, ...)?
^ permalink raw reply
* Fix me in htc.c relating to skb_reserve
From: nick @ 2014-11-28 21:43 UTC (permalink / raw)
To: kvalo; +Cc: netdev, linux-wireless, linville, ath10k, linux-kernel
Greetings Kalle, John and others,
I am wondering why this file is complaining about the code below, if someone can explain to me the issue I would be
very glad :).
static struct sk_buff *ath10k_htc_build_tx_ctrl_skb(void *ar)
{
struct sk_buff *skb;
struct ath10k_skb_cb *skb_cb;
skb = dev_alloc_skb(ATH10K_HTC_CONTROL_BUFFER_SIZE);
if (!skb)
return NULL;
skb_reserve(skb, 20); /* FIXME: why 20 bytes? */
WARN_ONCE((unsigned long)skb->data & 3, "unaligned skb");
skb_cb = ATH10K_SKB_CB(skb);
memset(skb_cb, 0, sizeof(*skb_cb));
ath10k_dbg(ar, ATH10K_DBG_HTC, "%s: skb %p\n", __func__, skb);
return skb;
}
^ permalink raw reply
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Marcelo Ricardo Leitner @ 2014-11-28 22:10 UTC (permalink / raw)
To: Al Viro; +Cc: herbert, netdev
In-Reply-To: <20141128203733.GD29748@ZenIV.linux.org.uk>
On 28-11-2014 18:37, Al Viro wrote:
> On Fri, Nov 28, 2014 at 05:25:27PM -0200, Marcelo Ricardo Leitner wrote:
>> Hi,
>>
>> I saw there are tun updates on Dave's queue but none seemed to handle this.
>>
>> I can't use current net-next
>> (799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a kvm hypervisor
>> because tun got clogged somehow. Bisected down to:
>
> Umm... In host, presumably?
>
Exactly
>> And net/core/datagram.c, skb_copy_datagram_from_iter():
>> if (copy > 0) {
>> int ret;
>> if (copy > len)
>> copy = len;
>> ret = copy_from_iter(skb->data + offset, copy, from);
>> if (ret != copy) {
>> pr_err("%d ret=%d copy=%d offset=%d
>> len=%d\n", __LINE__, ret, copy, offset, len);
>> goto fault;
>> }
>>
>>
>> I get, for tun interfaces:
>> [ 75.435552] 506 ret=80 copy=90 offset=0 len=90
>> [ 75.435563] tun: 1124 0 -14 (null)
>> [ 75.499528] 506 ret=80 copy=90 offset=0 len=90
>> [ 75.499540] tun: 1124 0 -14 (null)
>>
>> These were 1 drop on 1 interface each
>>
>> And for tap interfaces:
>> [ 301.982639] 506 ret=80 copy=90 offset=0 len=90
>> [ 301.982649] tun: 1124 0 -14 (null)
>> [ 301.988625] 506 ret=80 copy=90 offset=0 len=90
>> [ 301.988635] tun: 1124 0 -14 (null)
>> [ 301.994762] 506 ret=80 copy=90 offset=0 len=90
>> [ 301.994773] tun: 1124 0 -14 (null)
>> [ 302.229962] 506 ret=332 copy=342 offset=0 len=342
>> [ 302.229972] tun: 1124 0 -14 (null)
>> [ 302.230621] 506 ret=332 copy=342 offset=0 len=342
>> [ 302.230627] tun: 1124 0 -14 (null)
>> [ 302.239065] 506 ret=332 copy=342 offset=0 len=342
>> [ 302.239071] tun: 1124 0 -14 (null)
>>
>> It's returning 10 bytes less than the expected... ideas?
>
> Could you print vnet_hdr_sz and sizeof(gso) right after that
> copy_from_iter(&gso, ...)?
Did a:
else {
err = skb_copy_datagram_from_iter(skb, 0, from, len);
+ pr_err("vnet_hdr_sz=%d sizeof(gso)=%lu\n", tun->vnet_hdr_sz,
sizeof(gso));
if (!err && msg_control) {
Got, for tun:
[ 50.514165] tun: vnet_hdr_sz=12 sizeof(gso)=10
for tap:
[ 82.911840] tun: vnet_hdr_sz=10 sizeof(gso)=10
other values were just as before.
Marcelo
^ permalink raw reply
* [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: Nicholas Krause @ 2014-11-28 22:16 UTC (permalink / raw)
To: stefano.brivio-hl5o88x/ua9eoWH0uzbU5w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Adds needed mutex lockng of wl->mutex in order to prevent issues with separate threads executing on
the b43_update_templates function call in the function, b43_op_beacon_set_time at the same time.
Signed-off-by: Nicholas Krause <xerofoify-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/wireless/b43/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 5d4173e..19ddc72 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -5094,8 +5094,9 @@ static int b43_op_beacon_set_tim(struct ieee80211_hw *hw,
{
struct b43_wl *wl = hw_to_b43_wl(hw);
- /* FIXME: add locking */
+ mutex_lock(&wl->mutex);
b43_update_templates(wl);
+ mutex_unlock(&wl->mutex);
return 0;
}
--
2.1.0
^ permalink raw reply related
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Al Viro @ 2014-11-28 22:35 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: herbert, netdev
In-Reply-To: <5478F2BB.9050409@redhat.com>
On Fri, Nov 28, 2014 at 08:10:03PM -0200, Marcelo Ricardo Leitner wrote:
> >Could you print vnet_hdr_sz and sizeof(gso) right after that
> >copy_from_iter(&gso, ...)?
>
> Did a:
> else {
> err = skb_copy_datagram_from_iter(skb, 0, from, len);
> + pr_err("vnet_hdr_sz=%d sizeof(gso)=%lu\n",
> tun->vnet_hdr_sz, sizeof(gso));
> if (!err && msg_control) {
>
> Got, for tun:
> [ 50.514165] tun: vnet_hdr_sz=12 sizeof(gso)=10
>
> for tap:
> [ 82.911840] tun: vnet_hdr_sz=10 sizeof(gso)=10
>
> other values were just as before.
Hmm... Do you have
commit 8c847d254146d32c86574a1b16923ff91bb784dd
Author: Jason Wang <jasowang@redhat.com>
Date: Thu Nov 13 16:54:14 2014 +0800
tun: fix issues of iovec iterators using in tun_put_user()
in your tree?
^ permalink raw reply
* Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: Rafał Miłecki @ 2014-11-28 22:40 UTC (permalink / raw)
To: Nicholas Krause, Michael Büsch
Cc: Stefano Brivio, Network Development,
linux-wireless@vger.kernel.org, Linux Kernel Mailing List,
b43-dev
In-Reply-To: <1417213013-19758-1-git-send-email-xerofoify@gmail.com>
On 28 November 2014 at 23:16, Nicholas Krause <xerofoify@gmail.com> wrote:
> Adds needed mutex lockng of wl->mutex in order to prevent issues with separate threads executing on
> the b43_update_templates function call in the function, b43_op_beacon_set_time at the same time.
For all kind of kernel documentation / descriptions we try to fit 72
chars limit and we really try to avoid exceeding 80 chars.
> @@ -5094,8 +5094,9 @@ static int b43_op_beacon_set_tim(struct ieee80211_hw *hw,
> {
> struct b43_wl *wl = hw_to_b43_wl(hw);
>
> - /* FIXME: add locking */
> + mutex_lock(&wl->mutex);
> b43_update_templates(wl);
> + mutex_unlock(&wl->mutex);
>
> return 0;
> }
Does anyone remember why this simple solution wasn't implemented
earlier? Michael?
Nicholas: did you test it anyhow?
^ permalink raw reply
* Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: Michael Büsch @ 2014-11-28 23:21 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Nicholas Krause, Stefano Brivio, Network Development,
linux-wireless@vger.kernel.org, Linux Kernel Mailing List,
b43-dev
In-Reply-To: <CACna6rxmOC0h9hOpa=5iWFM1THQ8Q4hCi8MnmqkZJbB_U0PJ0A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
On Fri, 28 Nov 2014 23:40:46 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> > @@ -5094,8 +5094,9 @@ static int b43_op_beacon_set_tim(struct ieee80211_hw *hw,
> > {
> > struct b43_wl *wl = hw_to_b43_wl(hw);
> >
> > - /* FIXME: add locking */
> > + mutex_lock(&wl->mutex);
> > b43_update_templates(wl);
> > + mutex_unlock(&wl->mutex);
> >
> > return 0;
> > }
>
> Does anyone remember why this simple solution wasn't implemented
> earlier? Michael?
I think the callback used to be (is?) in atomic context.
> Nicholas: did you test it anyhow?
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] e1000: remove unused variables
From: Florian Fainelli @ 2014-11-28 23:28 UTC (permalink / raw)
To: Sudip Mukherjee, Hisashi T Fujinaka
Cc: Linux NICS, e1000-devel, Bruce Allan, Jesse Brandeburg,
linux-kernel, John Ronciak, netdev
In-Reply-To: <20141127130725.GA12406@sudip-PC>
Le 27/11/2014 05:07, Sudip Mukherjee a écrit :
> On Wed, Nov 26, 2014 at 09:59:28PM -0800, Hisashi T Fujinaka wrote:
>> I'm pretty sure those double reads are there for a reason, so most of
>> this I'm going to have to check on Monday. We have a long holiday
>> weekend here in the US.
>
> if the double reads are there for some reason, can you please let me know what that reason might be..
Could be latching, especially in the context of reading from Ethernet
PHYs, some registers are latched, so you may have to do a double read to
ensure the value you get is consistent.
Also, if you do a read that is not stored in any return value, the
compiler is now free to remove that actual read, and that may have other
side effects for registers which are e.g: read to clear, or any of the like.
>
>>
>> I'm not sure why you're bothering with an old driver like this, but if
>> you haven't actually tried this on all the hardware it pertains to, I'm
>> going want to NAK this.
>
> no it has not been tested on hardware. :(
>
> i am still in the learning process, NAK is also part of learning.
>
> infact there is another part of the code, which, theoretically, will never get executed. but i didnot dare to send that removal patch without testing on the hardware.
>
> thanks
> sudip
>
>>
>> I should do this from my todd.fujinaka@intel.com account but it's 10PM
>> on the first day of a long holiday weekend.
>>
>> On Thu, 27 Nov 2014, Sudip Mukherjee wrote:
>>
>>> these variables were only being assigned some values, but were never
>>> used.
>>>
>>> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
>>> ---
>>> drivers/net/ethernet/intel/e1000/e1000_hw.c | 142 ++++++++++++--------------
> <snip>
>>> case SPEED_100:
>>> - txb2b = false;
>>> /* maybe add some timeout factor ? */
>>> break;
>>> }
>>>
>>
>> --
>> Hisashi T Fujinaka - htodd@twofifty.com
>> BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
> --
> 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
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Herbert Xu @ 2014-11-28 23:59 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: netdev
In-Reply-To: <5478CC27.9040705@redhat.com>
On Fri, Nov 28, 2014 at 05:25:27PM -0200, Marcelo Ricardo Leitner wrote:
>
> I saw there are tun updates on Dave's queue but none seemed to handle this.
>
> I can't use current net-next
> (799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a kvm hypervisor
> because tun got clogged somehow. Bisected down to:
>
> commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Fri Nov 7 21:22:23 2014 +0800
Does this patch help?
-- >8 --
Subject: tun: Fix GSO meta-data handling in tun_get_user
When we write the GSO meta-data in tun_get_user we end up advancing
the IO vector twice, thus exhausting the user buffer before we can
finish writing the packet.
Fixes: f5ff53b4d97c ("{macvtap,tun}_get_user(): switch to iov_iter")
Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 4b743c6..9357871 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1052,7 +1052,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
if (gso.hdr_len > len)
return -EINVAL;
- iov_iter_advance(from, tun->vnet_hdr_sz);
+ iov_iter_advance(iter, tun->vnet_hdr_sz - sizeof(gso));
}
if ((tun->flags & TUN_TYPE_MASK) == TUN_TAP_DEV) {
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 related
* Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: nick @ 2014-11-29 3:32 UTC (permalink / raw)
To: Michael Büsch, Rafał Miłecki
Cc: Network Development,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, Stefano Brivio, b43-dev
In-Reply-To: <20141129002148.1beb21d9@wiggum>
Michael,
I don't have hardware for this driver on me, so I didn't test it. However this seems to
be correct from my reading of the code around this function and other locking related
to this driver.
Cheers Nick
On 2014-11-28 06:21 PM, Michael Büsch wrote:
> On Fri, 28 Nov 2014 23:40:46 +0100
> Rafał Miłecki <zajec5@gmail.com> wrote:
>
>>> @@ -5094,8 +5094,9 @@ static int b43_op_beacon_set_tim(struct ieee80211_hw *hw,
>>> {
>>> struct b43_wl *wl = hw_to_b43_wl(hw);
>>>
>>> - /* FIXME: add locking */
>>> + mutex_lock(&wl->mutex);
>>> b43_update_templates(wl);
>>> + mutex_unlock(&wl->mutex);
>>>
>>> return 0;
>>> }
>>
>> Does anyone remember why this simple solution wasn't implemented
>> earlier? Michael?
>
> I think the callback used to be (is?) in atomic context.
>
>> Nicholas: did you test it anyhow?
>
_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev
^ permalink raw reply
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Marcelo Ricardo Leitner @ 2014-11-29 4:49 UTC (permalink / raw)
To: Al Viro; +Cc: herbert, netdev
In-Reply-To: <20141128223503.GE29748@ZenIV.linux.org.uk>
On 28-11-2014 20:35, Al Viro wrote:
> On Fri, Nov 28, 2014 at 08:10:03PM -0200, Marcelo Ricardo Leitner wrote:
>>> Could you print vnet_hdr_sz and sizeof(gso) right after that
>>> copy_from_iter(&gso, ...)?
>>
>> Did a:
>> else {
>> err = skb_copy_datagram_from_iter(skb, 0, from, len);
>> + pr_err("vnet_hdr_sz=%d sizeof(gso)=%lu\n",
>> tun->vnet_hdr_sz, sizeof(gso));
>> if (!err && msg_control) {
>>
>> Got, for tun:
>> [ 50.514165] tun: vnet_hdr_sz=12 sizeof(gso)=10
>>
>> for tap:
>> [ 82.911840] tun: vnet_hdr_sz=10 sizeof(gso)=10
>>
>> other values were just as before.
>
> Hmm... Do you have
> commit 8c847d254146d32c86574a1b16923ff91bb784dd
> Author: Jason Wang <jasowang@redhat.com>
> Date: Thu Nov 13 16:54:14 2014 +0800
>
> tun: fix issues of iovec iterators using in tun_put_user()
> in your tree?
>
Yes I have. I'm using based on net-next's
799d2fff1858004526ad75d66a5dd8a5cce6ad40.
Marcelo
^ permalink raw reply
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Marcelo Ricardo Leitner @ 2014-11-29 5:08 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20141128235935.GA2178@gondor.apana.org.au>
On 28-11-2014 21:59, Herbert Xu wrote:
> On Fri, Nov 28, 2014 at 05:25:27PM -0200, Marcelo Ricardo Leitner wrote:
>>
>> I saw there are tun updates on Dave's queue but none seemed to handle this.
>>
>> I can't use current net-next
>> (799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a kvm hypervisor
>> because tun got clogged somehow. Bisected down to:
>>
>> commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
>> Author: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Fri Nov 7 21:22:23 2014 +0800
>
> Does this patch help?
Yay, it does! Works for me, thanks Herbert.
I didn't test performance, but dhcp could get through.
Are you sure about the Fixes tag? Because bisect really pointed to e0b46d0ee9c.
Cheers,
Marcelo
> -- >8 --
> Subject: tun: Fix GSO meta-data handling in tun_get_user
>
> When we write the GSO meta-data in tun_get_user we end up advancing
> the IO vector twice, thus exhausting the user buffer before we can
> finish writing the packet.
>
> Fixes: f5ff53b4d97c ("{macvtap,tun}_get_user(): switch to iov_iter")
> Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 4b743c6..9357871 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1052,7 +1052,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
>
> if (gso.hdr_len > len)
> return -EINVAL;
> - iov_iter_advance(from, tun->vnet_hdr_sz);
> + iov_iter_advance(iter, tun->vnet_hdr_sz - sizeof(gso));
> }
>
> if ((tun->flags & TUN_TYPE_MASK) == TUN_TAP_DEV) {
>
> Cheers,
>
^ permalink raw reply
* Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: Rafał Miłecki @ 2014-11-29 8:54 UTC (permalink / raw)
To: nick
Cc: Michael Büsch, Stefano Brivio, Network Development,
linux-wireless@vger.kernel.org, Linux Kernel Mailing List,
b43-dev
In-Reply-To: <54793E4E.7050602@gmail.com>
On 29 November 2014 at 04:32, nick <xerofoify@gmail.com> wrote:
> I don't have hardware for this driver on me, so I didn't test it. However this seems to
> be correct from my reading of the code around this function and other locking related
> to this driver.
So do you say it's not executed in an atomic?
>From *early* look it seems b43_update_templates is called from
b43_op_beacon_set_tim and b43_op_bss_info_changed, both or them are
mac80211 callbacks. That also should be safe, however I didn't check
if it may conflict with some in-kernel code (still, assuming it's not
atomic code, which I don't know!).
^ permalink raw reply
* Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: Michael Büsch @ 2014-11-29 8:56 UTC (permalink / raw)
To: nick
Cc: Rafał Miłecki, Stefano Brivio, Network Development,
linux-wireless@vger.kernel.org, Linux Kernel Mailing List,
b43-dev
In-Reply-To: <54793E4E.7050602@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
On Fri, 28 Nov 2014 22:32:30 -0500
nick <xerofoify@gmail.com> wrote:
> I don't have hardware for this driver on me, so I didn't test it. However this seems to
> be correct from my reading of the code around this function and other locking related
> to this driver.
From the current docs:
> * @set_tim: Set TIM bit. mac80211 calls this function when a TIM bit
> * must be set or cleared for a given STA. Must be atomic.
So it is not allowed to lock a mutex here.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c
From: Rafał Miłecki @ 2014-11-29 9:04 UTC (permalink / raw)
To: Michael Büsch
Cc: nick, Stefano Brivio, Network Development,
linux-wireless@vger.kernel.org, Linux Kernel Mailing List,
b43-dev
In-Reply-To: <20141129095632.69361457@wiggum>
On 29 November 2014 at 09:56, Michael Büsch <m@bues.ch> wrote:
> On Fri, 28 Nov 2014 22:32:30 -0500
> nick <xerofoify@gmail.com> wrote:
>
>> I don't have hardware for this driver on me, so I didn't test it. However this seems to
>> be correct from my reading of the code around this function and other locking related
>> to this driver.
>
> From the current docs:
>
>> * @set_tim: Set TIM bit. mac80211 calls this function when a TIM bit
>> * must be set or cleared for a given STA. Must be atomic.
>
> So it is not allowed to lock a mutex here.
Nicholas please be more careful with your patches. It seems your patch
is wrong, you didn't check the docs and you didn't even say in the
first place that it wasn't tested. You could at least submit with with
RFT tag or sth.
--
Rafał
^ permalink raw reply
* Re: [patch net-next v5 06/21] net: introduce generic switch devices support
From: Lino Sanfilippo @ 2014-11-29 9:31 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417181672-11531-7-git-send-email-jiri@resnulli.us>
Hi,
On 28.11.2014 14:34, Jiri Pirko wrote:
> +
> + ndo_switch_parent_id_get - This returns the same ID for two port netdevices
> + of the same physical switch chip. This is
> + mandatory to be implemented by all switch drivers
> + and serves the caller for recognition of a port
> + netdevice.
> + ndo_switch_parent_* - Functions that serve for a manipulation of the switch
> + chip itself (it can be though of as a "parent" of the
> + port, therefore the name). They are not port-specific.
> + Caller might use arbitrary port netdevice of the same
> + switch and it will make no difference.
I doubt that this is a good solution. If you want to access some kind of
parent device why dont you provide a device structure for it along with
register and unregister functions? Also each device should IMHO show up
in sysfs somehow, which should also be part of a register function.
There is already an existing driver (see net/dsa) that addresses the
representation of switch devices. What is wrong with that?
Regards,
Lino
^ permalink raw reply
* Re: [patch net-next v5 06/21] net: introduce generic switch devices support
From: Jiri Pirko @ 2014-11-29 9:59 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5479927B.4020807@gmx.de>
Sat, Nov 29, 2014 at 10:31:39AM CET, LinoSanfilippo@gmx.de wrote:
>
>Hi,
>
>On 28.11.2014 14:34, Jiri Pirko wrote:
>> +
>> + ndo_switch_parent_id_get - This returns the same ID for two port netdevices
>> + of the same physical switch chip. This is
>> + mandatory to be implemented by all switch drivers
>> + and serves the caller for recognition of a port
>> + netdevice.
>> + ndo_switch_parent_* - Functions that serve for a manipulation of the switch
>> + chip itself (it can be though of as a "parent" of the
>> + port, therefore the name). They are not port-specific.
>> + Caller might use arbitrary port netdevice of the same
>> + switch and it will make no difference.
>
>I doubt that this is a good solution. If you want to access some kind of
>parent device why dont you provide a device structure for it along with
>register and unregister functions? Also each device should IMHO show up
>in sysfs somehow, which should also be part of a register function.
Lino, this was already discussed. So far there is no need to introduce
such new infrastructure. But we have deal that once the need appears, it
will be added (it easily can be).
>There is already an existing driver (see net/dsa) that addresses the
>representation of switch devices. What is wrong with that?
This was already discussed as well. dsa is more of a driver for specific
devices (has for example highly integrated mdio interface). There is
also a deal to keep these 2 thing separated for now and try to merge
that as much as we can in the future.
>
>Regards,
>Lino
>
>
>
^ permalink raw reply
* Re: [patch net-next v5 06/21] net: introduce generic switch devices support
From: Lino Sanfilippo @ 2014-11-29 10:44 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141129095902.GA1856@nanopsycho.orion>
On 29.11.2014 10:59, Jiri Pirko wrote:
>
> Lino, this was already discussed. So far there is no need to introduce
> such new infrastructure. But we have deal that once the need appears, it
> will be added (it easily can be).
>
>>There is already an existing driver (see net/dsa) that addresses the
>>representation of switch devices. What is wrong with that?
>
> This was already discussed as well. dsa is more of a driver for specific
> devices (has for example highly integrated mdio interface). There is
> also a deal to keep these 2 thing separated for now and try to merge
> that as much as we can in the future.
>
I admit i did not follow the whole discussion. I was just wondering why
the existing dsa driver is not extended. But as you said it is planned
to do this in future. So thanks for your explanation.
Regards,
Lino
^ permalink raw reply
* Re: [PATCH] e1000: remove unused variables
From: Lino Sanfilippo @ 2014-11-29 11:01 UTC (permalink / raw)
To: Florian Fainelli, Sudip Mukherjee, Hisashi T Fujinaka
Cc: Linux NICS, e1000-devel, Bruce Allan, Jesse Brandeburg,
linux-kernel, John Ronciak, netdev
In-Reply-To: <54790537.809@gmail.com>
On 29.11.2014 00:28, Florian Fainelli wrote:
> Also, if you do a read that is not stored in any return value, the
> compiler is now free to remove that actual read,
This does not apply to reads from iomem (see "volatile" specifier in
readl()).
Regards,
Lino
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ 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