* netlink, RTM_NEWTCLASS, nested attributes
From: Denys Fedoryshchenko @ 2013-02-19 21:45 UTC (permalink / raw)
To: netdev, pablo, jhs, davem, linux-kernel
Hi
I tried recently to write my own tool based on amazing libmnl (which
makes understanding of netlink - easy), written
by Pablo Neira Ayuso, to manage QoS in Linux and faced problem, which i
think probably
a bug in handling netlink messages in kernel.
For example if i send message, RTM_NEWTCLASS, after attribute
TCA_OPTIONS i have nested attributes,
for example in HTB: TCA_HTB_PARMS, TCA_HTB_RTAB, TCA_HTB_CTAB.
libmnl, if i use nested attribute, adding a bit to it, by OR -
NLA_F_NESTED(1 << 15).
If i remove this flag - everything works fine. And here is the case,
iproute2 tools
just update length of TCA_OPTIONS, without setting flag, and it works
because of that fine too.
So there is basically 3 solutions:
1)New function in libmnl to do nested attributes without setting by OR
flag
2)AND-ing attribute type in kernel to ignore nested flag
3)Keeping as is, who cares?
Thank you for your attention.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* Re: [RFC PATCH] ipv6: Split from and expires field in dst_entry out of union [net-next]
From: Neil Horman @ 2013-02-19 21:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller, Gao feng, Jiri Bohac
In-Reply-To: <1361308665.19353.161.camel@edumazet-glaptop>
On Tue, Feb 19, 2013 at 01:17:45PM -0800, Eric Dumazet wrote:
> On Tue, 2013-02-19 at 15:28 -0500, Neil Horman wrote:
>
> > static inline void rt6_update_expires(struct rt6_info *rt, int timeout)
> > {
> > if (!(rt->rt6i_flags & RTF_EXPIRES)) {
> > - if (rt->dst.from)
> > - dst_release(rt->dst.from);
> > + dst_release(rt->dst.from);
> > /* dst_set_expires relies on expires == 0
> > * if it has not been set previously.
> > */
> > rt->dst.expires = 0;
> > + rt6->dst.from = NULL;
> > }
> >
>
> Sorry you didnt really address the problem, only reduce the race window.
>
I kinda had a feeling you would say that, but the only other solution I see here
is to either introduce some locking to protect the from pointer, or two revert
the patch that introduced the from pointer alltogether, neither of which sounds
appealing to me. I suppose we could use an xchng to atomically update the from
pointer, so there was only ever one context that was able to free it in
rt6_update_path. Does that seem reasonable to you?
Neil
^ permalink raw reply
* Re: [RFC PATCH] ipv6: Split from and expires field in dst_entry out of union [net-next]
From: Eric Dumazet @ 2013-02-19 21:55 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David Miller, Gao feng, Jiri Bohac
In-Reply-To: <20130219214934.GD31871@hmsreliant.think-freely.org>
On Tue, 2013-02-19 at 16:49 -0500, Neil Horman wrote:
> On Tue, Feb 19, 2013 at 01:17:45PM -0800, Eric Dumazet wrote:
> > On Tue, 2013-02-19 at 15:28 -0500, Neil Horman wrote:
> >
> > > static inline void rt6_update_expires(struct rt6_info *rt, int timeout)
> > > {
> > > if (!(rt->rt6i_flags & RTF_EXPIRES)) {
> > > - if (rt->dst.from)
> > > - dst_release(rt->dst.from);
> > > + dst_release(rt->dst.from);
> > > /* dst_set_expires relies on expires == 0
> > > * if it has not been set previously.
> > > */
> > > rt->dst.expires = 0;
> > > + rt6->dst.from = NULL;
> > > }
> > >
> >
> > Sorry you didnt really address the problem, only reduce the race window.
> >
> I kinda had a feeling you would say that, but the only other solution I see here
> is to either introduce some locking to protect the from pointer, or two revert
> the patch that introduced the from pointer alltogether, neither of which sounds
> appealing to me. I suppose we could use an xchng to atomically update the from
> pointer, so there was only ever one context that was able to free it in
> rt6_update_path. Does that seem reasonable to you?
I believe the setting of rt6->dst.from is safe :
It should be done at :
- dst creation time, when we are the only user.
- dst destry time, when we are the only user.
We only have to do the dst_release() at the right place, when we are the
last user of the dst.
So rt6_update_expires() should not mess with rt6->dst.from at all.
^ permalink raw reply
* [PATCH] ip_gre: remove an extra dst_release()
From: Eric Dumazet @ 2013-02-19 22:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Pravin B Shelar
From: Eric Dumazet <edumazet@google.com>
commit 68c331631143 (v4 GRE: Add TCP segmentation offload for GRE)
introduced a bug in error path.
dst is attached to skb, so will be released when skb is freed.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
---
net/ipv4/ip_gre.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 31bc941..5ef4da7 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1006,10 +1006,8 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
if (skb_has_shared_frag(skb)) {
err = __skb_linearize(skb);
- if (err) {
- ip_rt_put(rt);
+ if (err)
goto tx_error;
- }
}
*ptr = 0;
^ permalink raw reply related
* Re: [net-next 13/15] ixgbe: implement SFF diagnostic monitoring via ethtool
From: Ben Hutchings @ 2013-02-19 22:14 UTC (permalink / raw)
To: Jeff Kirsher, Aurélien Guillaume
Cc: davem, netdev, gospo, sassmann, Emil Tantilov
In-Reply-To: <1361003616-3422-14-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 2013-02-16 at 00:33 -0800, Jeff Kirsher wrote:
> From: Aurélien Guillaume <footplus@gmail.com>
>
> This patch adds support for reading data from SFP+ modules over i2c.
[...]
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
[...]
> +static int ixgbe_get_module_eeprom(struct net_device *dev,
> + struct ethtool_eeprom *ee,
> + u8 *data)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> + struct ixgbe_hw *hw = &adapter->hw;
> + u32 status = IXGBE_ERR_PHY_ADDR_INVALID;
> + u8 databyte = 0xFF;
> + int i = 0;
> + int ret_val = 0;
> +
> + /* ixgbe_get_module_info is called before this function in all
> + * cases, so we do not need any checks we already do above,
> + * and can trust ee->len to be a known value.
> + */
[...]
Whatever makes you think that?
All you are guaranteed is that:
ee->offset <= ee->offset + ee->len <= eeprom_len
Same as for the regular EEPROM read function.
This implementation doesn't result in a heap overrun at present because
the caller allocates a whole page as a buffer. But you should not
assume that it's safe to write more than ee->len bytes, nor that
ee->offset == 0.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* pull request: wireless-next 2013-02-19
From: John W. Linville @ 2013-02-19 22:04 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 7086 bytes --]
Dave,
One last batch of stragglers intended for 3.9...
For the iwlwifi pull, Johannes says:
"I hadn't expected to ask you to pull iwlwifi-next again, but I have a
number of fixes most of which I'd also send in after rc1, so here it is.
The first commit is a merge error between mac80211-next and
iwlwifi-next; in addition I have fixes for P2P scanning and MVM driver
MAC (virtual interface) management from Ilan, a CT-kill (critical
temperature) fix from Eytan, and myself fixed three different little but
annoying bugs in the MVM driver.
The only ones I might not send for -rc1 are Emmanuel's debug patch, but
OTOH it should help greatly if there are any issues, and my own time
event debugging patch that I used to find the race condition but we
decided to keep it for the future."
For the mac80211 pull, Johannes says:
"Like iwlwifi-next, this would almost be suitable for rc1.
I have a fix for station management on non-TDLS drivers, a CAB queue
crash fix for mesh, a fix for an annoying (but harmless) warning, a
tracing fix and a documentation fix. Other than that, only a few mesh
cleanups."
Along with that is a fix for memory corruption in rtlwifi, an
orinoco_usb fix to avoid allocating a DMA buffer on the stack, an a
hostap fix to return -ENOMEM instead of -1 after a memory allocation
failure. The remaining bits implement 802.11ac support for the mwifiex
driver -- I think that is still worth getting into 3.9.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 303c07db487be59ae9fda10600ea65ca11c21497:
ppp: set qdisc_tx_busylock to avoid LOCKDEP splat (2013-02-19 14:33:55 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
for you to fetch changes up to 0b7164458fc184455239ea3676af1b362df1ce1d:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem (2013-02-19 14:56:34 -0500)
----------------------------------------------------------------
Avinash Patil (1):
mwifiex: fix empty TX ring check for PCIe8897 while unloading driver
Bob Copeland (1):
mac80211: enable vif.cab_queue for mesh
Emmanuel Grumbach (1):
iwlwifi: dvm: improve (again) the prints in reclaim path
Eytan Lifshitz (1):
iwlwifi: dvm: fix delayed enter to CT-kill bug
Ilan Peer (3):
iwlwifi: mvm: Set the scan type according to the vif type
iwlwifi: mvm: Fix resource allocation for P2P Device
iwlwifi: mvm: Reserve MAC id 0 for managed interfaces
Johannes Berg (10):
mac80211: clean up mesh code
cfg80211: add correct docbook entries
mac80211: fix harmless station flush warning
cfg80211: fix station change if TDLS isn't supported
Merge remote-tracking branch 'wireless-next/master' into iwlwifi-next
iwlwifi: mvm: fix merge error
iwlwifi: mvm: program DTIM timings properly
iwlwifi: mvm: fix GO powersave client manipulation
iwlwifi: mvm: add debug statement to time event add
iwlwifi: mvm: fix time event command handling race
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Jussi Kivilinna (1):
rtlwifi: usb: allocate URB control message setup_packet and data buffer separately
Kumar Amit Mehta (2):
net: wireless: orinoco: orinoco_usb.c: fix DMA buffers on stack
net: wireless: hostap: hostap_ap.c: Return -ENOMEM instead of -1 for if kmalloc() fails.
Seth Forshee (1):
mac80211: Fix incorrect use of STA_PR_FMT in trace points
Thomas Pedersen (3):
mac80211: clean up mesh HT operation
mac80211: stringify mesh peering events
mac80211: don't spam mesh probe response messages
Yogesh Ashok Powar (2):
mwifiex: coding style cleanup in bss parameter update
mwifiex: add 802.11AC support
Documentation/DocBook/80211.tmpl | 4 +-
drivers/net/wireless/hostap/hostap_ap.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/commands.h | 1 +
drivers/net/wireless/iwlwifi/dvm/tt.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/tx.c | 51 +++--
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 47 ++++-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 10 +-
drivers/net/wireless/iwlwifi/mvm/rx.c | 1 +
drivers/net/wireless/iwlwifi/mvm/scan.c | 7 +-
drivers/net/wireless/iwlwifi/mvm/sta.c | 14 +-
drivers/net/wireless/iwlwifi/mvm/sta.h | 6 +-
drivers/net/wireless/iwlwifi/mvm/time-event.c | 10 +-
drivers/net/wireless/mwifiex/11ac.c | 261 ++++++++++++++++++++++++++
drivers/net/wireless/mwifiex/11ac.h | 26 +++
drivers/net/wireless/mwifiex/11n.c | 7 +-
drivers/net/wireless/mwifiex/11n.h | 4 +-
drivers/net/wireless/mwifiex/Makefile | 1 +
drivers/net/wireless/mwifiex/cfg80211.c | 177 ++++++++++++++---
drivers/net/wireless/mwifiex/cfp.c | 159 +++++++++++++++-
drivers/net/wireless/mwifiex/cmdevt.c | 19 ++
drivers/net/wireless/mwifiex/fw.h | 127 ++++++++++++-
drivers/net/wireless/mwifiex/ioctl.h | 4 +
drivers/net/wireless/mwifiex/join.c | 8 +
drivers/net/wireless/mwifiex/main.h | 23 ++-
drivers/net/wireless/mwifiex/pcie.c | 5 +-
drivers/net/wireless/mwifiex/scan.c | 63 ++++++-
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
drivers/net/wireless/mwifiex/sta_cmdresp.c | 1 +
drivers/net/wireless/mwifiex/sta_ioctl.c | 5 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 11 +-
drivers/net/wireless/rtlwifi/usb.c | 44 +++--
net/mac80211/cfg.c | 14 +-
net/mac80211/iface.c | 8 +-
net/mac80211/main.c | 3 +-
net/mac80211/mesh.c | 116 ++++++------
net/mac80211/mesh.h | 105 +++++------
net/mac80211/mesh_hwmp.c | 68 +++----
net/mac80211/mesh_pathtbl.c | 89 ++++-----
net/mac80211/mesh_plink.c | 134 ++++++-------
net/mac80211/mesh_sync.c | 47 ++---
net/mac80211/rx.c | 12 +-
net/mac80211/sta_info.h | 2 -
net/mac80211/trace.h | 6 +-
net/mac80211/tx.c | 26 ++-
net/wireless/nl80211.c | 9 -
45 files changed, 1297 insertions(+), 444 deletions(-)
create mode 100644 drivers/net/wireless/mwifiex/11ac.c
create mode 100644 drivers/net/wireless/mwifiex/11ac.h
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [MacVLAN] failure to deliver reassembled IPv6 multicast traffic
From: Ben Greear @ 2013-02-19 22:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Erik Hugne, netdev, kaber, ataschner
In-Reply-To: <1360956930.19353.24.camel@edumazet-glaptop>
On 02/15/2013 11:35 AM, Eric Dumazet wrote:
> On Fri, 2013-02-15 at 11:27 -0800, Ben Greear wrote:
>
>> For some reason I was thinking this wasn't fully fixed for IPv4, but
>> maybe it is..the bug in our internal tracker only mentions IPv6
>> as having issues...
>>
>> We'll do some testing on IPv4 sometime soon to make sure, and can test
>> IPv6 patches as well...
>
> This worries me a bit, as I wrote this patch because you reported the
> issue.
We just did some testing on this on the 3.7.6+ kernel. IPv4 multicast to
mac-vlans works OK with large packets if there is a single multicast receiver,
but does NOT work if there are multiple multicast receivers (ie, several
mac-vlans with an mcast receive bound to each mvlan).
Our setup also involves routing rules and send-to-self rules,
with sender on the same machine, but I'm not sure that matters
too much or not.
Multiple receivers work fine with smaller packets that do not
need to be segmented.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH_FRAME_LEN + ETH_FCS_LEN)
From: Andrew Morton @ 2013-02-19 22:27 UTC (permalink / raw)
To: kbuild test robot
Cc: Daniel Santos, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
netdev
In-Reply-To: <5122101a.nBjTqFyZXZ+WuzPr%fengguang.wu@intel.com>
On Mon, 18 Feb 2013 19:27:22 +0800
kbuild test robot <fengguang.wu@intel.com> wrote:
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> head: ae9da2a24a80423b8dbda9c5a72674ce6e7861be
> commit: f7d7e38e6df399b2af7f04c177054abdd744a077 [16/587] bug.h, compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG
> config: make ARCH=s390 allmodconfig
>
> All error/warnings:
>
> In function 'igb_build_rx_buffer',
> inlined from 'igb_clean_rx_irq' at drivers/net/ethernet/intel/igb/igb_main.c:6705:8:
> >> drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH_FRAME_LEN + ETH_FCS_LEN)
>
> vim +/__compiletime_assert_6235 +6231 drivers/net/ethernet/intel/igb/igb_main.c
>
> 6225 #endif
> 6226
> 6227 /* If we spanned a buffer we have a huge mess so test for it */
> 6228 BUG_ON(unlikely(!igb_test_staterr(rx_desc, E1000_RXD_STAT_EOP)));
> 6229
> 6230 /* Guarantee this function can be used by verifying buffer sizes */
> > 6231 BUILD_BUG_ON(SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD +
> 6232 NET_IP_ALIGN +
> 6233 IGB_TS_HDR_LEN +
> 6234 ETH_FRAME_LEN +
>
That BUILD_BUG_ON() triggers without Daniel's patches applied as well:
CC [M] drivers/net/ethernet/intel/igb/igb_main.o
drivers/net/ethernet/intel/igb/igb_main.c: In function 'igb_build_rx_buffer':
drivers/net/ethernet/intel/igb/igb_main.c:6231: error: size of array 'type name' is negative
I suspect that driver is busted on s390. Dunno why. Here's what cpp emits:
s390 allmodconfig:
bool __cond = !(!(((2048) - (((sizeof(struct skb_shared_info)) + (256 - 1)) & ~(256 - 1))) < (32 + 2 + 16 + 1514 + 4)));
x86_64 allmodconfig:
bool __cond = !(!(((2048) - (((sizeof(struct skb_shared_info)) + ((1 <<
(6)) - 1)) & ~((1 << (6)) - 1))) < (({ typeof(32) _max1 = (32); typeof((1
<< (6))) _max2 = ((1 << (6))); (void) (&_max1 == &_max2); _max1 > _max2 ? _max1 : _max2; }) + 0 + 16 + 1514 + 4)));
I doubt if anyone will be running this driver on s390, but I guess we
should work out why it broke.
^ permalink raw reply
* RE: [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH...
From: Allan, Bruce W @ 2013-02-19 22:30 UTC (permalink / raw)
To: Andrew Morton, Wu, Fengguang
Cc: Daniel Santos, Kirsher, Jeffrey T, Brandeburg, Jesse,
netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net
In-Reply-To: <20130219142708.b454d98a.akpm@linux-foundation.org>
> -----Original Message-----
> From: Andrew Morton [mailto:akpm@linux-foundation.org]
> Sent: Tuesday, February 19, 2013 2:27 PM
> To: Wu, Fengguang
> Cc: Daniel Santos; Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W;
> netdev@vger.kernel.org
> Subject: Re: [next:akpm 16/587]
> drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to
> '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON
> failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD +
> NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH...
>
> On Mon, 18 Feb 2013 19:27:22 +0800
> kbuild test robot <fengguang.wu@intel.com> wrote:
>
> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> akpm
> > head: ae9da2a24a80423b8dbda9c5a72674ce6e7861be
> > commit: f7d7e38e6df399b2af7f04c177054abdd744a077 [16/587] bug.h,
> compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG
> > config: make ARCH=s390 allmodconfig
> >
> > All error/warnings:
> >
> > In function 'igb_build_rx_buffer',
> > inlined from 'igb_clean_rx_irq' at
> drivers/net/ethernet/intel/igb/igb_main.c:6705:8:
> > >> drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to
> '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON
> failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD +
> NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH_FRAME_LEN + ETH_FCS_LEN)
> >
> > vim +/__compiletime_assert_6235 +6231
> drivers/net/ethernet/intel/igb/igb_main.c
> >
> > 6225 #endif
> > 6226
> > 6227 /* If we spanned a buffer we have a huge mess so test for it
> */
> > 6228 BUG_ON(unlikely(!igb_test_staterr(rx_desc,
> E1000_RXD_STAT_EOP)));
> > 6229
> > 6230 /* Guarantee this function can be used by verifying buffer
> sizes */
> > > 6231
> BUILD_BUG_ON(SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) <
> (NET_SKB_PAD +
> > 6232
> NET_IP_ALIGN +
> > 6233
> IGB_TS_HDR_LEN +
> > 6234
> ETH_FRAME_LEN +
> >
>
> That BUILD_BUG_ON() triggers without Daniel's patches applied as well:
>
> CC [M] drivers/net/ethernet/intel/igb/igb_main.o
> drivers/net/ethernet/intel/igb/igb_main.c: In function
> 'igb_build_rx_buffer':
> drivers/net/ethernet/intel/igb/igb_main.c:6231: error: size of array 'type
> name' is negative
>
> I suspect that driver is busted on s390. Dunno why. Here's what cpp emits:
>
>
> s390 allmodconfig:
>
> bool __cond = !(!(((2048) - (((sizeof(struct skb_shared_info)) + (256 - 1)) &
> ~(256 - 1))) < (32 + 2 + 16 + 1514 + 4)));
>
>
> x86_64 allmodconfig:
>
> bool __cond = !(!(((2048) - (((sizeof(struct skb_shared_info)) + ((1 <<
> (6)) - 1)) & ~((1 << (6)) - 1))) < (({ typeof(32) _max1 = (32); typeof((1
> << (6))) _max2 = ((1 << (6))); (void) (&_max1 == &_max2); _max1 > _max2 ?
> _max1 : _max2; }) + 0 + 16 + 1514 + 4)));
>
>
> I doubt if anyone will be running this driver on s390, but I guess we
> should work out why it broke.
Adding Intel wired ethernet developers mailing list.
^ permalink raw reply
* Re: [PATCH] ip_gre: remove an extra dst_release()
From: Pravin Shelar @ 2013-02-19 22:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1361312050.19353.169.camel@edumazet-glaptop>
On Tue, Feb 19, 2013 at 2:14 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> commit 68c331631143 (v4 GRE: Add TCP segmentation offload for GRE)
> introduced a bug in error path.
>
> dst is attached to skb, so will be released when skb is freed.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Pravin B Shelar <pshelar@nicira.com>
Looks good.
Acked-by: Pravin B Shelar <pshelar@nicira.com>
> ---
> net/ipv4/ip_gre.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 31bc941..5ef4da7 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -1006,10 +1006,8 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
>
> if (skb_has_shared_frag(skb)) {
> err = __skb_linearize(skb);
> - if (err) {
> - ip_rt_put(rt);
> + if (err)
> goto tx_error;
> - }
> }
>
> *ptr = 0;
>
>
^ permalink raw reply
* Re: [MacVLAN] failure to deliver reassembled IPv6 multicast traffic
From: Ben Greear @ 2013-02-19 22:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Erik Hugne, netdev, kaber, ataschner
In-Reply-To: <5123FB32.7050101@candelatech.com>
On 02/19/2013 02:22 PM, Ben Greear wrote:
> On 02/15/2013 11:35 AM, Eric Dumazet wrote:
>> On Fri, 2013-02-15 at 11:27 -0800, Ben Greear wrote:
>>
>>> For some reason I was thinking this wasn't fully fixed for IPv4, but
>>> maybe it is..the bug in our internal tracker only mentions IPv6
>>> as having issues...
>>>
>>> We'll do some testing on IPv4 sometime soon to make sure, and can test
>>> IPv6 patches as well...
>>
>> This worries me a bit, as I wrote this patch because you reported the
>> issue.
>
> We just did some testing on this on the 3.7.6+ kernel. IPv4 multicast to
> mac-vlans works OK with large packets if there is a single multicast receiver,
> but does NOT work if there are multiple multicast receivers (ie, several
> mac-vlans with an mcast receive bound to each mvlan).
I should clarify this a bit: This kernel has some additional
patches...probably nothing that makes this issue worse, but
I guess you never know. We have not tested this on standard
upstream kernels.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [MacVLAN] failure to deliver reassembled IPv6 multicast traffic
From: Eric Dumazet @ 2013-02-19 22:38 UTC (permalink / raw)
To: Ben Greear; +Cc: Erik Hugne, netdev, kaber, ataschner
In-Reply-To: <5123FB32.7050101@candelatech.com>
On Tue, 2013-02-19 at 14:22 -0800, Ben Greear wrote:
> On 02/15/2013 11:35 AM, Eric Dumazet wrote:
> > On Fri, 2013-02-15 at 11:27 -0800, Ben Greear wrote:
> >
> >> For some reason I was thinking this wasn't fully fixed for IPv4, but
> >> maybe it is..the bug in our internal tracker only mentions IPv6
> >> as having issues...
> >>
> >> We'll do some testing on IPv4 sometime soon to make sure, and can test
> >> IPv6 patches as well...
> >
> > This worries me a bit, as I wrote this patch because you reported the
> > issue.
>
> We just did some testing on this on the 3.7.6+ kernel. IPv4 multicast to
> mac-vlans works OK with large packets if there is a single multicast receiver,
> but does NOT work if there are multiple multicast receivers (ie, several
> mac-vlans with an mcast receive bound to each mvlan).
>
> Our setup also involves routing rules and send-to-self rules,
> with sender on the same machine, but I'm not sure that matters
> too much or not.
It might matter, because before commit 6d1ccff627806829c (net: reset mac
header in dev_start_xmit() ), we were accessing wrong ethernet header in
macvlan_broadcast() in the send-to-self path
struct ethhdr *eth = eth_hdr(skb);
was simply wrong.
You should try net-next and if it still fails, maybe share your test
programs.
^ permalink raw reply
* Re: [MacVLAN] failure to deliver reassembled IPv6 multicast traffic
From: Ben Greear @ 2013-02-19 22:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Erik Hugne, netdev, kaber, ataschner
In-Reply-To: <1361313484.19353.172.camel@edumazet-glaptop>
On 02/19/2013 02:38 PM, Eric Dumazet wrote:
> On Tue, 2013-02-19 at 14:22 -0800, Ben Greear wrote:
>> On 02/15/2013 11:35 AM, Eric Dumazet wrote:
>>> On Fri, 2013-02-15 at 11:27 -0800, Ben Greear wrote:
>>>
>>>> For some reason I was thinking this wasn't fully fixed for IPv4, but
>>>> maybe it is..the bug in our internal tracker only mentions IPv6
>>>> as having issues...
>>>>
>>>> We'll do some testing on IPv4 sometime soon to make sure, and can test
>>>> IPv6 patches as well...
>>>
>>> This worries me a bit, as I wrote this patch because you reported the
>>> issue.
>>
>> We just did some testing on this on the 3.7.6+ kernel. IPv4 multicast to
>> mac-vlans works OK with large packets if there is a single multicast receiver,
>> but does NOT work if there are multiple multicast receivers (ie, several
>> mac-vlans with an mcast receive bound to each mvlan).
>>
>> Our setup also involves routing rules and send-to-self rules,
>> with sender on the same machine, but I'm not sure that matters
>> too much or not.
>
> It might matter, because before commit 6d1ccff627806829c (net: reset mac
> header in dev_start_xmit() ), we were accessing wrong ethernet header in
> macvlan_broadcast() in the send-to-self path
I have that patch in my tree already, so it does not fix the
problem... Also, I mos-spoke slightly...the test was on 3.7.9+
kernel...
Our test setup is not simple, and is driven by a proprietary
user-space application. I can set it up on a system and
give you access if you want (you could investigate the
various routing rules, etc, to see how our config actually
happens).
Or, can help you install our app on your system and configure
it to cause this bug. All these features should run fine on
standard upstream kernels.
There's no sane way for me to reproduce our test setup
with standard tools and mcast traffic generator/receivers,
however...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] ip_gre: propogate target device GSO capability to the tunnel device
From: pravin @ 2013-02-19 22:51 UTC (permalink / raw)
To: Dmitry Kravkov; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F1C019A53@SJEXCHMB06.corp.ad.broadcom.com>
On Tue, Feb 19, 2013 at 11:31 AM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
>> -----Original Message-----
>> From: pravin [mailto:pravin.shelar@gmail.com]
>> Sent: Tuesday, February 19, 2013 8:40 PM
>> To: Dmitry Kravkov
>> Cc: davem@davemloft.net; netdev@vger.kernel.org
>> Subject: Re: [PATCH net-next v2 2/2] ip_gre: propogate target device GSO
>> capability to the tunnel device
>>
>> On Mon, Feb 18, 2013 at 11:50 AM, Dmitry Kravkov <dmitry@broadcom.com>
>> wrote:
>> >
>> > Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
>> > ---
>> > Changes from v1: fixed email address
>> >
>> >
>> > net/ipv4/ip_gre.c | 10 ++++++++--
>> > 1 files changed, 8 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>> > index cdc31ac..31bc941 100644
>> > --- a/net/ipv4/ip_gre.c
>> > +++ b/net/ipv4/ip_gre.c
>> > @@ -1103,8 +1103,14 @@ static int ipgre_tunnel_bind_dev(struct net_device
>> *dev)
>> > tunnel->hlen = addend;
>> > /* TCP offload with GRE SEQ is not supported. */
>> > if (!(tunnel->parms.o_flags & GRE_SEQ)) {
>> > - dev->features |= NETIF_F_GSO_SOFTWARE;
>> > - dev->hw_features |= NETIF_F_GSO_SOFTWARE;
>> > + /* device supports enc gso offload*/
>> > + if (tdev->hw_enc_features & NETIF_F_GRE_GSO) {
>> > + dev->features |= NETIF_F_TSO;
>> > + dev->hw_features |= NETIF_F_TSO;
>> > + } else {
>> > + dev->features |= NETIF_F_GSO_SOFTWARE;
>> > + dev->hw_features |= NETIF_F_GSO_SOFTWARE;
>> > + }
>> > }
>>
>> I am not sure about this change, Are you trying to limit GRE TSO to
>> just IPV4 in case of GRE offload in hardware?
>>
> You're right,
> It probably should be fixed to:
> if (tdev && tdev->hw_enc_features & NETIF_F_GRE_GSO) {
> dev->features |= tdev-> hw_enc_features & NETIF_F_GSO_MASK;
> dev->hw_features |= tdev-> hw_enc_features & NETIF_F_GSO_MASK;
>
>> >
>> > return mtu;
>> > --
>> > 1.7.7.2
>> >
I think if device features are set right, dev_hard_start_xmit() should
do right thing without any of these changes. i.e. it will GSO ipv6
packets if hardware only supports GRE-ipv4 packets.
This patch changes that at encapsulated dev layer and disables rest of
GSO if one type of TSO available which is not optimal.
>> >
>> > --
>> > 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: [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH...
From: Wyborny, Carolyn @ 2013-02-19 23:02 UTC (permalink / raw)
To: Andrew Morton, Wu, Fengguang
Cc: Daniel Santos, Kirsher, Jeffrey T, Brandeburg, Jesse,
Allan, Bruce W, netdev@vger.kernel.org
In-Reply-To: <20130219142708.b454d98a.akpm@linux-foundation.org>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Andrew Morton
> Sent: Tuesday, February 19, 2013 2:27 PM
> To: Wu, Fengguang
> Cc: Daniel Santos; Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W;
> netdev@vger.kernel.org
> Subject: Re: [next:akpm 16/587]
> drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to
> '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON
> failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD +
> NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH...
>
[..]
> That BUILD_BUG_ON() triggers without Daniel's patches applied as well:
>
[..]
> I doubt if anyone will be running this driver on s390, but I guess we should work
> out why it broke.
>
Yes, we'll work on it.
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
Networking Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to handle packets
From: pravin @ 2013-02-19 23:03 UTC (permalink / raw)
To: Dmitry Kravkov; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F1C019A30@SJEXCHMB06.corp.ad.broadcom.com>
On Tue, Feb 19, 2013 at 11:20 AM, Dmitry Kravkov <dmitry@broadcom.com> wrote:
>
>> -----Original Message-----
>> From: pravin [mailto:pravin.shelar@gmail.com]
>> Sent: Tuesday, February 19, 2013 8:28 PM
>> To: Dmitry Kravkov
>> Cc: davem@davemloft.net; netdev@vger.kernel.org
>> Subject: Re: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to
>> handle packets
>>
>> On Mon, Feb 18, 2013 at 11:50 AM, Dmitry Kravkov <dmitry@broadcom.com>
>> wrote:
>> > If device is not able to handle checksumming it will
>> > be handled in dev_xmit
>> >
>> > Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
>> > ---
>> > Changes from v1: fixed email address
>> >
>> > net/ipv4/ip_gre.c | 7 ++-----
>> > 1 files changed, 2 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>> > index a56f118..cdc31ac 100644
>> > --- a/net/ipv4/ip_gre.c
>> > +++ b/net/ipv4/ip_gre.c
>> > @@ -745,12 +745,9 @@ static struct sk_buff *handle_offloads(struct sk_buff
>> *skb)
>> > goto error;
>> > skb_shinfo(skb)->gso_type |= SKB_GSO_GRE;
>> > return skb;
>> > - } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
>> > - err = skb_checksum_help(skb);
>> > - if (unlikely(err))
>> > - goto error;
>> > }
>> > - skb->ip_summed = CHECKSUM_NONE;
>> > + if (skb->ip_summed != CHECKSUM_PARTIAL)
>> > + skb->ip_summed = CHECKSUM_NONE;
>> >
>> > return skb;
>> >
>> > --
>> > 1.7.7.2
>> >
>> >
>>
>> This patch breaks GRE tunnel with GRE_CSUM. since GRE_CSUM need
>> complete IP packet to checksum entire GRE payload.
>
> Testing for o_flags&GRE_CSUM does not look too hurt here, since it will be used in ipgre_tunnel_xmit() later on
> This is the only problematic case, right?
>
It does not work for me. I have GRE device with csum on. Ping works
fine but Netperf is not working.
Looking at code, I am not sure how tcp will work if inner packet TCP
checksum is calculated after GRE_CSUM calculation.
Thanks,
Pravin.
^ permalink raw reply
* Re: [Linux-zigbee-devel] [PATCH] wpan: use GFP_ATOMIC instead of GFP_KERNEL
From: Alan Ott @ 2013-02-19 23:31 UTC (permalink / raw)
To: Alexander Aring; +Cc: alex.bluesman.smirnov, netdev, davem, linux-zigbee-devel
In-Reply-To: <1360078474-24362-1-git-send-email-alex.aring@gmail.com>
On 02/05/2013 07:34 AM, Alexander Aring wrote:
> I got this message at runtime:
>
> [ 48.847347] BUG: scheduling while atomic: swapper/0/0/0x40000100
Hi Alexander,
Please check out the patch set here:
https://github.com/beagleboard/kernel/tree/3.8/patches/6lowpan
This is Tony's patch set which is not merged yet and might save you some
time. Tony is hoping to get much of it merged this cycle.
Alan.
^ permalink raw reply
* [PATCH] IPVS: change type of netns_ipvs->sysctl_sync_qlen_max
From: Zhang Yanfei @ 2013-02-19 23:53 UTC (permalink / raw)
To: akpm, horms, ja, davem; +Cc: Linux MM, netdev, linux-kernel, zhangyanfei
From: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
This member of struct netns_ipvs is calculated from nr_free_buffer_pages
so change its type to unsigned long in case of overflow. Also, type of
its related proc var sync_qlen_max and the return type of function
sysctl_sync_qlen_max() should be changed to unsigned long, too.
Besides, the type of ipvs_master_sync_state->sync_queue_len should be
changed to unsigned long accordingly.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Simon Horman <horms@verge.net.au>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
---
include/net/ip_vs.h | 8 ++++----
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 68c69d5..108ebe8 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -874,7 +874,7 @@ struct ip_vs_app {
struct ipvs_master_sync_state {
struct list_head sync_queue;
struct ip_vs_sync_buff *sync_buff;
- int sync_queue_len;
+ unsigned long sync_queue_len;
unsigned int sync_queue_delay;
struct task_struct *master_thread;
struct delayed_work master_wakeup_work;
@@ -966,7 +966,7 @@ struct netns_ipvs {
int sysctl_snat_reroute;
int sysctl_sync_ver;
int sysctl_sync_ports;
- int sysctl_sync_qlen_max;
+ unsigned long sysctl_sync_qlen_max;
int sysctl_sync_sock_size;
int sysctl_cache_bypass;
int sysctl_expire_nodest_conn;
@@ -1052,7 +1052,7 @@ static inline int sysctl_sync_ports(struct netns_ipvs *ipvs)
return ACCESS_ONCE(ipvs->sysctl_sync_ports);
}
-static inline int sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
+static inline unsigned long sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
{
return ipvs->sysctl_sync_qlen_max;
}
@@ -1099,7 +1099,7 @@ static inline int sysctl_sync_ports(struct netns_ipvs *ipvs)
return 1;
}
-static inline int sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
+static inline unsigned long sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
{
return IPVS_SYNC_QLEN_MAX;
}
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index ec664cb..d79a530 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -1747,9 +1747,9 @@ static struct ctl_table vs_vars[] = {
},
{
.procname = "sync_qlen_max",
- .maxlen = sizeof(int),
+ .maxlen = sizeof(unsigned long),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_doulongvec_minmax,
},
{
.procname = "sync_sock_size",
--
1.7.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* RE: [net-next 13/15] ixgbe: implement SFF diagnostic monitoring via ethtool
From: Tantilov, Emil S @ 2013-02-20 0:26 UTC (permalink / raw)
To: Ben Hutchings, Kirsher, Jeffrey T, Aurélien Guillaume
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
In-Reply-To: <1361312048.2967.44.camel@bwh-desktop.uk.solarflarecom.com>
>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Tuesday, February 19, 2013 2:14 PM
>To: Kirsher, Jeffrey T; Aurélien Guillaume
>Cc: davem@davemloft.net; netdev@vger.kernel.org; gospo@redhat.com;
>sassmann@redhat.com; Tantilov, Emil S
>Subject: Re: [net-next 13/15] ixgbe: implement SFF diagnostic monitoring
>via ethtool
>
>On Sat, 2013-02-16 at 00:33 -0800, Jeff Kirsher wrote:
>> From: Aurélien Guillaume <footplus@gmail.com>
>>
>> This patch adds support for reading data from SFP+ modules over i2c.
>[...]
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
>[...]
>> +static int ixgbe_get_module_eeprom(struct net_device *dev,
>> + struct ethtool_eeprom *ee,
>> + u8 *data)
>> +{
>> + struct ixgbe_adapter *adapter = netdev_priv(dev);
>> + struct ixgbe_hw *hw = &adapter->hw;
>> + u32 status = IXGBE_ERR_PHY_ADDR_INVALID;
>> + u8 databyte = 0xFF;
>> + int i = 0;
>> + int ret_val = 0;
>> +
>> + /* ixgbe_get_module_info is called before this function in all
>> + * cases, so we do not need any checks we already do above,
>> + * and can trust ee->len to be a known value.
>> + */
>[...]
>
>Whatever makes you think that?
>
>All you are guaranteed is that:
> ee->offset <= ee->offset + ee->len <= eeprom_len
>Same as for the regular EEPROM read function.
>
>This implementation doesn't result in a heap overrun at present because
>the caller allocates a whole page as a buffer. But you should not
>assume that it's safe to write more than ee->len bytes, nor that
>ee->offset == 0.
>
>Ben.
Thanks Ben, we'll address this in a follow up patch.
Emil
^ permalink raw reply
* Re: [PATCH] b43: Increase number of RX DMA slots
From: Julian Calaby @ 2013-02-20 0:47 UTC (permalink / raw)
To: Larry Finger
Cc: David Miller, David.Laight, linville, linux-wireless, netdev,
bittorf, stable
In-Reply-To: <5123C43D.2020602@lwfinger.net>
Hi Larry,
On Wed, Feb 20, 2013 at 5:28 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 02/19/2013 12:15 PM, David Miller wrote:
>
>> I understand your constraints, but this is a trivially remotely
>> DoS'able condition even on slow CPU atom laptops.
>>
>> Send an "expansive" full sized frame followed by 300 or so 64-byte UDP
>> packets --> instant hang.
>
>
> Thanks for the suggestion for a test. I think the reset solution should
> survive with only some packet loss, but we will find out.
Is it be possible to increase the number of slots at runtime? Maybe an
even better solution would be to keep the existing number of slots,
and if they run out, reset and increase incrementally to some sensible
maximum value.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH...
From: Eric Dumazet @ 2013-02-20 1:09 UTC (permalink / raw)
To: Allan, Bruce W
Cc: Andrew Morton, Wu, Fengguang, Daniel Santos, Kirsher, Jeffrey T,
Brandeburg, Jesse, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <804857E1F29AAC47BF68C404FC60A1844D0099DF@ORSMSX102.amr.corp.intel.com>
On Tue, Feb 19, 2013 at 2:30 PM, Allan, Bruce W <bruce.w.allan@intel.com> wrote:
>> -----Original Message-----
>> From: Andrew Morton [mailto:akpm@linux-foundation.org]
>> Sent: Tuesday, February 19, 2013 2:27 PM
>> To: Wu, Fengguang
>> Cc: Daniel Santos; Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W;
>> netdev@vger.kernel.org
>> Subject: Re: [next:akpm 16/587]
>> drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to
>> '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON
>> failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD +
>> NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH...
>>
>> On Mon, 18 Feb 2013 19:27:22 +0800
>> kbuild test robot <fengguang.wu@intel.com> wrote:
>>
>> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> akpm
>> > head: ae9da2a24a80423b8dbda9c5a72674ce6e7861be
>> > commit: f7d7e38e6df399b2af7f04c177054abdd744a077 [16/587] bug.h,
>> compiler.h: Introduce compiletime_assert & BUILD_BUG_ON_MSG
>> > config: make ARCH=s390 allmodconfig
>> >
>> > All error/warnings:
>> >
>> > In function 'igb_build_rx_buffer',
>> > inlined from 'igb_clean_rx_irq' at
>> drivers/net/ethernet/intel/igb/igb_main.c:6705:8:
>> > >> drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to
>> '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON
>> failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD +
>> NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH_FRAME_LEN + ETH_FCS_LEN)
>> >
>> > vim +/__compiletime_assert_6235 +6231
>> drivers/net/ethernet/intel/igb/igb_main.c
>> >
>> > 6225 #endif
>> > 6226
>> > 6227 /* If we spanned a buffer we have a huge mess so test for it
>> */
>> > 6228 BUG_ON(unlikely(!igb_test_staterr(rx_desc,
>> E1000_RXD_STAT_EOP)));
>> > 6229
>> > 6230 /* Guarantee this function can be used by verifying buffer
>> sizes */
>> > > 6231
>> BUILD_BUG_ON(SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) <
>> (NET_SKB_PAD +
>> > 6232
>> NET_IP_ALIGN +
>> > 6233
>> IGB_TS_HDR_LEN +
>> > 6234
>> ETH_FRAME_LEN +
>> >
>>
>> That BUILD_BUG_ON() triggers without Daniel's patches applied as well:
>>
>> CC [M] drivers/net/ethernet/intel/igb/igb_main.o
>> drivers/net/ethernet/intel/igb/igb_main.c: In function
>> 'igb_build_rx_buffer':
>> drivers/net/ethernet/intel/igb/igb_main.c:6231: error: size of array 'type
>> name' is negative
>>
>> I suspect that driver is busted on s390. Dunno why. Here's what cpp emits:
>>
>>
>> s390 allmodconfig:
>>
>> bool __cond = !(!(((2048) - (((sizeof(struct skb_shared_info)) + (256 - 1)) &
>> ~(256 - 1))) < (32 + 2 + 16 + 1514 + 4)));
>>
>>
>> x86_64 allmodconfig:
>>
>> bool __cond = !(!(((2048) - (((sizeof(struct skb_shared_info)) + ((1 <<
>> (6)) - 1)) & ~((1 << (6)) - 1))) < (({ typeof(32) _max1 = (32); typeof((1
>> << (6))) _max2 = ((1 << (6))); (void) (&_max1 == &_max2); _max1 > _max2 ?
>> _max1 : _max2; }) + 0 + 16 + 1514 + 4)));
>>
>>
>> I doubt if anyone will be running this driver on s390, but I guess we
>> should work out why it broke.
>
> Adding Intel wired ethernet developers mailing list.
>
Oh well, NET_SKB_PAD is too large on s390
I guess we should use 64 bytes max.
#define NET_SKB_PAD min(64, max(32, L1_CACHE_BYTES))
^ permalink raw reply
* Re: [PATCH] b43: Increase number of RX DMA slots
From: Larry Finger @ 2013-02-20 2:42 UTC (permalink / raw)
To: Julian Calaby
Cc: David Miller, David.Laight, linville, linux-wireless, netdev,
bittorf, stable
In-Reply-To: <CAGRGNgWZ0qUJSSkjmP8o4VaPRBdN67J=RPy5+45rWaQQXWnWrQ@mail.gmail.com>
On 02/19/2013 06:47 PM, Julian Calaby wrote:
>
> Is it be possible to increase the number of slots at runtime? Maybe an
> even better solution would be to keep the existing number of slots,
> and if they run out, reset and increase incrementally to some sensible
> maximum value.
The number could be increased a bit, but on systems with 32-bit DMA such as the
BCM4318, the maximum size of the ring buffer is 4KB. Even more importantly, each
slot is allocated an skb of 2390 bytes. Even at 256 slots, the memory allocation
is pretty large.
Larry
^ permalink raw reply
* Re: [PATCH] ip_gre: remove an extra dst_release()
From: David Miller @ 2013-02-20 3:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, pshelar
In-Reply-To: <1361312050.19353.169.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Feb 2013 14:14:10 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> commit 68c331631143 (v4 GRE: Add TCP segmentation offload for GRE)
> introduced a bug in error path.
>
> dst is attached to skb, so will be released when skb is freed.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: pull request: wireless-next 2013-02-19
From: David Miller @ 2013-02-20 3:25 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20130219220457.GA2126@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 19 Feb 2013 17:04:58 -0500
> One last batch of stragglers intended for 3.9...
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] phy: fix phy_device_free memory leak
From: David Miller @ 2013-02-20 3:48 UTC (permalink / raw)
To: oss; +Cc: netdev
In-Reply-To: <20130219193646.GA10851@bordel.klfree.net>
From: Petr Malat <oss@malat.biz>
Date: Tue, 19 Feb 2013 20:36:46 +0100
> From: Petr Malat <oss@malat.biz>
>
> Fix memory leak in phy_device_free() for the case when phy_device*
> returned by phy_device_create() is not registered in the system.
>
> Bug description:
> phy_device_create() sets name of kobject using dev_set_name(), which
> allocates memory using kvasprintf(), but this memory isn't freed if
> the underlying device isn't registered properly, because kobject_cleanup()
> is not called in that case. This can happen (and actually is happening on
> our machines) if phy_device_register(), called by mdiobus_scan(), fails.
>
> Patch description:
> Name is freed by phy_device_free(). In the case a device is released
> trough kobject_cleanup()->device_release()->phy_device_release(), the name
> is set to NULL and it is not freed by phy_device_free(), because it will
> be freed later by kobject_cleanup().
>
> Signed-off-by: Petr Malat <oss@malat.biz>
> ---
> Please put me on CC, I'm not signed into the mailing list.
I think it's cleaner to have phy_device_register() use the kobject
reference count properly.
Have it first go:
device_initialize(&phydev->dev);
And change the device_register() to device_add().
Finally, on the failure paths, do a put_device().
No funny NULL pointer assignments and state to maintainer, just using
kobject reference counting to handle it all transparently.
^ 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