* Re: 3.13-rc1: eth0 hw csum failure on powerpc
From: Andreas Schwab @ 2013-11-30 22:05 UTC (permalink / raw)
To: Christian Kujau; +Cc: LKML, netdev, linuxppc-dev, Alexander Graf
In-Reply-To: <alpine.DEB.2.11.1311301314220.31521__48727.6146108799$1385846242$gmane$org@trent.utfs.org>
Christian Kujau <lists@nerdbynature.de> writes:
> On Sat, 30 Nov 2013 at 02:11, Christian Kujau wrote:
>> On Sat, 30 Nov 2013 at 02:07, Christian Kujau wrote:
>> > while trying to upgrade from 3.12.0 to 3.13-rc1 or -rc2, the following
>> > happens early during bootup:
>> >
>> > [...]
>> > Freeing unused kernel memory: 204K (c06ea000 - c071d000)
>> > eth0: hw csum failure
>> > CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0-rc2 #1
>> > Call Trace:
>>
>> Btw, full dmesg & .config: http://nerdbynature.de/bits/3.13-rc1/
>
> Oh, this has already been reported earlier this week:
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-November/113584.html
No solution yet, though, 3.13-rc2 is still broken.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: r8169 - it's dead jim
From: Francois Romieu @ 2013-11-30 22:18 UTC (permalink / raw)
To: David Miller; +Cc: james, netdev
In-Reply-To: <20131130.160629.2435326869658907.davem@davemloft.net>
David Miller <davem@davemloft.net> :
[...]
> Francois should I apply this or are you just posting this to get
> testing feedback?
No, it's only debuging help and testing feedback straight from
format-patch.
If I don't send fixes as "[PATCH net x/y] r8169: ..." or features as
"[PATCH net-next 1/1] r8169: perform Tx completion before Rx processing"
during the net-next window in self-contained messages, you should
consider that nothing is expected to be applied and something is probably
going wrong.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/4] pch_gbe: Fix transmit queue management
From: Ondřej Pužman @ 2013-11-30 22:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20131129.164229.2292905485668904870.davem@davemloft.net>
> Please format your commit message text to 80 columns.
Ok, no problem. I did not know that 80 columns limitation applies also
for commit messages.
> You should be instead preventing the transmit method from being
> invoked when it might be possible that a request cannot be
> satisfied. This means that at the end of a transmit request, you must
> stop the queue if a packet with the maximum number of possible
> descriptors cannot be satisfied. Then it is impossible for the
> transmit function to be invoked in a situation where it would need to
> fail for lack of available transmit descriptors. This is why drivers
> decided whether to stop their TX queues based upon calculations
> involving MAX_SKB_FRAGS.
Hmm, correct me if I'm wrong ... but the driver and hardware does not
support scatter-gather DMA. So fragmented skbs can't be passed to
ndo_start_xmit function and each skb passed to the function represents
one packet and one descriptor in tx_ring.
I do not think that in this caseit makes sense to to involve
MAX_SKB_FRAGS in any calculation and the queue should be stopped in the
moment when it gets full.
But maybe I am missing something, I am no expert in this kind of stuff.
--
Ondrej Puzman
^ permalink raw reply
* Re: [PATCH] Fix ARM BUILD_BUG_ON() errors with batman-adv
From: Russell King - ARM Linux @ 2013-11-30 23:03 UTC (permalink / raw)
To: David Miller; +Cc: mareklindner, sw, antonio, b.a.t.m.a.n, netdev
In-Reply-To: <20131130.160547.837987320410619405.davem@davemloft.net>
On Sat, Nov 30, 2013 at 04:05:47PM -0500, David Miller wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> Date: Sat, 30 Nov 2013 19:15:53 +0000
>
> > so there should be no undesired side effect from this packing.
>
> There is a huge side effect from ever using the packed attribute, in
> that the compiler can assume absolutely nothing about the alignment of
> any object or sub-object of the type you apply this attribute to.
>
> Even if it is "obvious" that some members will be aligned, the
> compiler cannot take advantage of this assumption because this
> attribute also means that an array of such elements might have
> arbitrary alignment. So you when you get a pointer to one of these
> objects, the compiler has to assume the worst possible case.
>
> This means using 4 byte loads to load a 32-bit quantity, always,
> unconditionally, no matter what.
>
> That's why we should do whatever is necessary to align things properly
> by hand, and use packed only as the last possible and least desirable
> resort.
>
> I'm not applying this, please try work to implement this more
> acceptably first.
Okay, someone else fixes this problem then, I've no idea how this can
be fixed.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH] Fix ARM BUILD_BUG_ON() errors with batman-adv
From: Russell King - ARM Linux @ 2013-11-30 23:05 UTC (permalink / raw)
To: Antonio Quartulli
Cc: The list for a Better Approach To Mobile Ad-hoc Networking,
Marek Lindner, Simon Wunderlich, netdev, David Miller
In-Reply-To: <529A46C4.9090906@meshcoding.com>
On Sat, Nov 30, 2013 at 09:12:52PM +0100, Antonio Quartulli wrote:
> I don't know the ARM architecture at all (I don't know if the other
> batman-adv developers do), so could you please provide here some more
> details about why that static check is failing? We would like to
> address this issue differently rather than re-adding the __packed
> attribute.
The reason is this struct becomes a size of 4 bytes, even though
it only contains three uint8_t members. This offsets the members
of all structs that this struct is embedded in.
If you don't wish to fix this, then please make your subsystem
depend on !ARM because it's otherwise impossible to fix and can never
work on ARM.
^ permalink raw reply
* Re: [PATCH] net: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
From: Chen Gang @ 2013-11-30 23:48 UTC (permalink / raw)
To: Joe Perches
Cc: Johannes Berg, John W. Linville, rkuo,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <1385843940.2664.4.camel@joe-AO722>
On 12/01/2013 04:39 AM, Joe Perches wrote:
> On Sat, 2013-11-30 at 21:08 +0100, Johannes Berg wrote:
>> On Sat, 2013-11-30 at 22:02 +0800, Chen Gang wrote:
>>> - fall-through is obvious (although I did not notice it, originally).
>>>
>>> - Check 'A' again just near by "case A" seems a little strange.
>>>
>>> - Some compilers aren't quit smart enough to know 'chanctx_conf' is OK.
>>
>> I know. If you have any good ideas of how to make it more obvious to the
>> compiler, I'm all ears, I just don't like any of the solutions offered
>> so far (and you aren't the first to do so either) :-)
>>
OK, thanks.
>> FWIW, I find the label to be odd because if you're familiar with the
>> code then AP/AP_VLAN *should* be identical except for two special things
>> that are now linearly & neatly handled in the code (the first being the
>> 4-addr station, the second the chanctx assignment which always has to be
>> done regardless of 4-addr). IMHO the == check after case should be
>> enough to make a human reader take a closer look. I understand that you
>> didn't and that's OK since you were just trying to squelch compile
>> warnings, but I don't see that this one warrants much attention.
>
> The label/test could be moved to save a couple of lines
> of duplicated code.
>
Hmm... for me, it must be an implementation which can satisfy all of us.
If ieee80211_subif_start_xmit() is not performance sensitive (I guess
so), we can use some short static functions instead of some code blocks
within ieee80211_subif_start_xmit().
- ieee80211_subif_start_xmit() is a long function (600+ lines).
- use short static function can share some code.
- if code can be shared, the work flow can be more clearer too (don't
need fall-through or goto).
And I guess, the implementation below can cause panic when
"sdata->vif.type == NL80211_IFTYPE_AP_VLAN". :-(
> Maybe:
>
> net/mac80211/tx.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 70b5a05..b2160f4 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1777,18 +1777,16 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
> }
> ap_sdata = container_of(sdata->bss, struct ieee80211_sub_if_data,
> u.ap);
> - chanctx_conf = rcu_dereference(ap_sdata->vif.chanctx_conf);
> - if (!chanctx_conf)
> - goto fail_rcu;
> - band = chanctx_conf->def.chan->band;
> - if (sta)
> - break;
> /* fall through */
> case NL80211_IFTYPE_AP:
> - if (sdata->vif.type == NL80211_IFTYPE_AP)
> - chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> + chanctx_conf = rcu_dereference(ap_sdata->vif.chanctx_conf);
> if (!chanctx_conf)
> goto fail_rcu;
> + if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
> + band = chanctx_conf->def.chan->band;
> + if (sta)
> + break;
> + }
> fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS);
> /* DA BSSID SA */
> memcpy(hdr.addr1, skb->data, ETH_ALEN);
>
>
--
Chen Gang
--
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
* Re: [PATCH] net: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
From: Chen Gang @ 2013-11-30 23:59 UTC (permalink / raw)
To: Joe Perches
Cc: Johannes Berg, John W. Linville, rkuo,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <529A7955.9010507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12/01/2013 07:48 AM, Chen Gang wrote:
> On 12/01/2013 04:39 AM, Joe Perches wrote:
>> On Sat, 2013-11-30 at 21:08 +0100, Johannes Berg wrote:
>>> On Sat, 2013-11-30 at 22:02 +0800, Chen Gang wrote:
>>>> - fall-through is obvious (although I did not notice it, originally).
>>>>
>>>> - Check 'A' again just near by "case A" seems a little strange.
>>>>
>>>> - Some compilers aren't quit smart enough to know 'chanctx_conf' is OK.
>>>
>>> I know. If you have any good ideas of how to make it more obvious to the
>>> compiler, I'm all ears, I just don't like any of the solutions offered
>>> so far (and you aren't the first to do so either) :-)
>>>
>
> OK, thanks.
>
>>> FWIW, I find the label to be odd because if you're familiar with the
>>> code then AP/AP_VLAN *should* be identical except for two special things
>>> that are now linearly & neatly handled in the code (the first being the
>>> 4-addr station, the second the chanctx assignment which always has to be
>>> done regardless of 4-addr). IMHO the == check after case should be
>>> enough to make a human reader take a closer look. I understand that you
>>> didn't and that's OK since you were just trying to squelch compile
>>> warnings, but I don't see that this one warrants much attention.
>>
>> The label/test could be moved to save a couple of lines
>> of duplicated code.
>>
>
> Hmm... for me, it must be an implementation which can satisfy all of us.
>
> If ieee80211_subif_start_xmit() is not performance sensitive (I guess
> so), we can use some short static functions instead of some code blocks
> within ieee80211_subif_start_xmit().
>
> - ieee80211_subif_start_xmit() is a long function (600+ lines).
>
Oh, one typo issue (need use 400+ instead of 600+), it is a long
function (although not quite long).
> - use short static function can share some code.
>
> - if code can be shared, the work flow can be more clearer too (don't
> need fall-through or goto).
>
>
> And I guess, the implementation below can cause panic when
> "sdata->vif.type == NL80211_IFTYPE_AP_VLAN". :-(
>
>> Maybe:
>>
>> net/mac80211/tx.c | 14 ++++++--------
>> 1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
>> index 70b5a05..b2160f4 100644
>> --- a/net/mac80211/tx.c
>> +++ b/net/mac80211/tx.c
>> @@ -1777,18 +1777,16 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
>> }
>> ap_sdata = container_of(sdata->bss, struct ieee80211_sub_if_data,
>> u.ap);
>> - chanctx_conf = rcu_dereference(ap_sdata->vif.chanctx_conf);
>> - if (!chanctx_conf)
>> - goto fail_rcu;
>> - band = chanctx_conf->def.chan->band;
>> - if (sta)
>> - break;
>> /* fall through */
>> case NL80211_IFTYPE_AP:
>> - if (sdata->vif.type == NL80211_IFTYPE_AP)
>> - chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
>> + chanctx_conf = rcu_dereference(ap_sdata->vif.chanctx_conf);
>> if (!chanctx_conf)
>> goto fail_rcu;
>> + if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
>> + band = chanctx_conf->def.chan->band;
>> + if (sta)
>> + break;
>> + }
>> fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS);
>> /* DA BSSID SA */
>> memcpy(hdr.addr1, skb->data, ETH_ALEN);
>>
>>
>
>
--
Chen Gang
--
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
* Re: [PATCH] Fix ARM BUILD_BUG_ON() errors with batman-adv
From: Antonio Quartulli @ 2013-12-01 0:27 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller, Marek Lindner
In-Reply-To: <20131130230518.GC16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/12/13 00:05, Russell King - ARM Linux wrote:
> On Sat, Nov 30, 2013 at 09:12:52PM +0100, Antonio Quartulli wrote:
>> I don't know the ARM architecture at all (I don't know if the
>> other batman-adv developers do), so could you please provide here
>> some more details about why that static check is failing? We
>> would like to address this issue differently rather than
>> re-adding the __packed attribute.
>
> The reason is this struct becomes a size of 4 bytes, even though it
> only contains three uint8_t members. This offsets the members of
> all structs that this struct is embedded in.
>
> If you don't wish to fix this, then please make your subsystem
> depend on !ARM because it's otherwise impossible to fix and can
> never work on ARM.
>
I'd like to fix this.
Actually I can't really understand your explanation: struct
batadv_header is always used inside another parent structure and the
latter always has a uint8_t following the batadv_header, thus filling
that gap and aligning it to 4bytes.
I think this is also why we don't get this compiler error on any other
architecture. Or am I missing something?
I'll install a toolchain for ARM and I'll try to inspect it better. If
we have to make a change we should do it before 3.13 is release since
this change could possibly alter the packet layout.
- --
Antonio Quartulli
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlKagnYACgkQpGgxIkP9cwe1KgCeMUkV6xpNOsM4Bilc1e1uHpCG
8BAAnjsHJ/AHn8COhwiZ5wrKiIpQ0CFa
=D4xa
-----END PGP SIGNATURE-----
^ permalink raw reply
* [RFC] Fix Free Software Foundation address in file headers
From: Jeff Kirsher @ 2013-12-01 0:42 UTC (permalink / raw)
To: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
This came up when John Fastabend got a patch to fix up the headers in
the drivers/scsi/ directory and so I did a quick search of the network
drivers and found several instances in the file headers where an old FSF
address remains. The old address is:
59 Temple Place - Suite 330
Boston, MA 02111-1307
The current address is:
51 Franklin Street - Fifth Floor
Boston, MA 02110-1301
I am wondering whether it may be best to just put a link to the Free
Software Foundation web page instead of having to update the address any
time a change is made.
Either way, I feel the address either needs to get corrected or changed
to the URL, even though I am not a fan of huge patch series to make
trivial changes like this.
Thoughts?
Cheers,
Jeff Kirsher
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] PCI / tg3: Give up chip reset and carrier loss handling if PCI device is not present
From: Rafael J. Wysocki @ 2013-12-01 1:34 UTC (permalink / raw)
To: netdev
Cc: LKML, Linux PM list, Linux PCI, Bjorn Helgaas, Nithin Nayak Sujir,
Michael Chan, David Miller
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Modify tg3_chip_reset() and tg3_close() to check if the PCI network
adapter device is accessible at all in order to skip poking it or
trying to handle a carrier loss in vain when that's not the case.
Introduce a special PCI helper function pci_device_is_present()
for this purpose.
Of course, this uncovers the lack of the appropriate RTNL locking
in tg3_suspend() and tg3_resume(), so add that locking in there
too.
These changes prevent tg3 from burning a CPU at 100% load level for
solid several seconds after the Thunderbolt link is disconnected from
a Matrox DS1 docking station.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/net/ethernet/broadcom/tg3.c | 26 +++++++++++++++++++-------
drivers/pci/pci.c | 8 ++++++++
include/linux/pci.h | 1 +
3 files changed, 28 insertions(+), 7 deletions(-)
Index: linux-pm/drivers/net/ethernet/broadcom/tg3.c
===================================================================
--- linux-pm.orig/drivers/net/ethernet/broadcom/tg3.c
+++ linux-pm/drivers/net/ethernet/broadcom/tg3.c
@@ -8932,6 +8932,9 @@ static int tg3_chip_reset(struct tg3 *tp
void (*write_op)(struct tg3 *, u32, u32);
int i, err;
+ if (!pci_device_is_present(tp->pdev))
+ return -ENODEV;
+
tg3_nvram_lock(tp);
tg3_ape_lock(tp, TG3_APE_LOCK_GRC);
@@ -11594,10 +11597,11 @@ static int tg3_close(struct net_device *
memset(&tp->net_stats_prev, 0, sizeof(tp->net_stats_prev));
memset(&tp->estats_prev, 0, sizeof(tp->estats_prev));
- tg3_power_down_prepare(tp);
-
- tg3_carrier_off(tp);
+ if (pci_device_is_present(tp->pdev)) {
+ tg3_power_down_prepare(tp);
+ tg3_carrier_off(tp);
+ }
return 0;
}
@@ -17739,10 +17743,12 @@ static int tg3_suspend(struct device *de
struct pci_dev *pdev = to_pci_dev(device);
struct net_device *dev = pci_get_drvdata(pdev);
struct tg3 *tp = netdev_priv(dev);
- int err;
+ int err = 0;
+
+ rtnl_lock();
if (!netif_running(dev))
- return 0;
+ goto unlock;
tg3_reset_task_cancel(tp);
tg3_phy_stop(tp);
@@ -17784,6 +17790,8 @@ out:
tg3_phy_start(tp);
}
+unlock:
+ rtnl_unlock();
return err;
}
@@ -17792,10 +17800,12 @@ static int tg3_resume(struct device *dev
struct pci_dev *pdev = to_pci_dev(device);
struct net_device *dev = pci_get_drvdata(pdev);
struct tg3 *tp = netdev_priv(dev);
- int err;
+ int err = 0;
+
+ rtnl_lock();
if (!netif_running(dev))
- return 0;
+ goto unlock;
netif_device_attach(dev);
@@ -17819,6 +17829,8 @@ out:
if (!err)
tg3_phy_start(tp);
+unlock:
+ rtnl_unlock();
return err;
}
#endif /* CONFIG_PM_SLEEP */
Index: linux-pm/drivers/pci/pci.c
===================================================================
--- linux-pm.orig/drivers/pci/pci.c
+++ linux-pm/drivers/pci/pci.c
@@ -4171,6 +4171,14 @@ int pci_set_vga_state(struct pci_dev *de
return 0;
}
+bool pci_device_is_present(struct pci_dev *pdev)
+{
+ u32 v;
+
+ return pci_bus_read_dev_vendor_id(pdev->bus, pdev->devfn, &v, 0);
+}
+EXPORT_SYMBOL_GPL(pci_device_is_present);
+
#define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
static DEFINE_SPINLOCK(resource_alignment_lock);
Index: linux-pm/include/linux/pci.h
===================================================================
--- linux-pm.orig/include/linux/pci.h
+++ linux-pm/include/linux/pci.h
@@ -961,6 +961,7 @@ void pci_update_resource(struct pci_dev
int __must_check pci_assign_resource(struct pci_dev *dev, int i);
int __must_check pci_reassign_resource(struct pci_dev *dev, int i, resource_size_t add_size, resource_size_t align);
int pci_select_bars(struct pci_dev *dev, unsigned long flags);
+bool pci_device_is_present(struct pci_dev *pdev);
/* ROM control related routines */
int pci_enable_rom(struct pci_dev *pdev);
^ permalink raw reply
* Re: [PATCH net] net: neighbour: make sure the handler has finished before kfree neighbour
From: Ding Tianhong @ 2013-12-01 2:43 UTC (permalink / raw)
To: David Miller; +Cc: dingtianhong, gaofeng, yoshfuji, joe, vfalico, netdev
In-Reply-To: <20131130.162733.145727596946626316.davem@davemloft.net>
于 2013/12/1 5:27, David Miller 写道:
> From: Ding Tianhong <dingtianhong@huawei.com>
> Date: Thu, 28 Nov 2013 20:28:52 +0800
>
>> I have met the oops in Suse11 SP2, the kernel is 2.6.32.59-0.7-default:
>
> This doesn't make any sense.
>
> If this actually was the reason, then del_timer() would have returned true,
> and thus neigh_del_timer() would have returned "1" and you would have
> seen the "Impossible event" log message that neigh_destroy() prints out.
>
> You may think the cause is a pending timer, but the data you've provided
> does not support this at all.
>
> And if it isn't happening, your patch removing that warning is wrong.
>
> Furthermore, if this change to use del_timer_sync() is correct, it
> probably belongs in neigh_del_timer() because all of it's other callers
> expect the timer to not be running and that all references to the object
> are stable after such calls.
>
> I'm not applying this, you really need to pursue this bug fix more
> cleanly and more thoroughly because it's a non-trivial issue.
>
> Thanks.
ok，thanks for the advice, I would like to think it over and make it better.
Regards
Ding
> --
> 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 3/3] xfrm: Fix null pointer dereference when decoding sessions
From: Matthias Schiffer @ 2013-12-01 4:19 UTC (permalink / raw)
To: Steffen Klassert, David Miller; +Cc: Herbert Xu, netdev
In-Reply-To: <52920CEE.2040407@universe-factory.net>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
On 11/24/2013 03:27 PM, Matthias Schiffer wrote:
> On 11/01/2013 09:21 AM, Steffen Klassert wrote:
>> On some codepaths the skb does not have a dst entry
>> when xfrm_decode_session() is called. So check for
>> a valid skb_dst() before dereferencing the device
>> interface index. We use 0 as the device index if
>> there is no valid skb_dst(), or at reverse decoding
>> we use skb_iif as device interface index.
>>
>> Bug was introduced with git commit bafd4bd4dc
>> ("xfrm: Decode sessions with output interface.").
>>
>> Reported-by: Meelis Roos <mroos@linux.ee>
>> Tested-by: Meelis Roos <mroos@linux.ee>
>> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> Please queue this for 3.12-stable, I've seen this bug trigger a panic
> when heavily using Bittorrent (screenshot:
> http://i.imgur.com/OIKVccM.jpg )
>
> Thanks,
> Matthias
>
Ping? Several people I know have hit this panic with 3.12.x at least
once or twice by now during heavy IPv6 usage.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [[PATCH stable <3.12]] xen-netback: fix refcnt unbalance for 3.11 and earlier versions
From: Greg KH @ 2013-12-01 4:48 UTC (permalink / raw)
To: Wei Liu
Cc: xen-devel, netdev, stable, tomasz.wroblewski, Ian Campbell,
Konrad Wilk, David Vrabel
In-Reply-To: <1385642889-11513-1-git-send-email-wei.liu2@citrix.com>
On Thu, Nov 28, 2013 at 12:48:09PM +0000, Wei Liu wrote:
> With the introduction of "xen-netback: Don't destroy the netdev until
> the vif is shut down" (upstream commit id 279f438e36), vif disconnect
> and free are separated. However in the backported verion reference
> counting code was not correctly modified, and the reset of vif->tx_irq
> was lost. If frontend goes through vif life cycle more than once the
> reference counting is skewed.
>
> This patch adds back the missing tx_irq reset line. It also moves
> several lines of the reference counting code to vif_free, so the moved
> code corresponds to the counterpart in vif_alloc, thus the reference
> counting is balanced.
>
> 3.12 and onward versions are not affected by this bug, because reference
> counting code was removed due to the introduction of 1:1 model.
>
> This pacth should be backported to all stable verions which are lower
> than 3.12 and have 279f438e36.
What stable versions are those? 279f438e36 showed up in 3.12-rc2, and
was not marked for stable inclusion, so what kernel would end up needing
this patch?
confused,
greg k-h
^ permalink raw reply
* [PATCHv2 net] {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
From: Fan Du @ 2013-12-01 8:28 UTC (permalink / raw)
To: steffen.klassert; +Cc: davem, netdev
commit a553e4a6317b2cfc7659542c10fe43184ffe53da ("[PKTGEN]: IPSEC support")
tried to support IPsec ESP transport transformation for pktgen, but acctually
this doesn't work at all for two reasons(The orignal transformed packet has
bad IPv4 checksum value, as well as wrong auth value, reported by wireshark)
- After transpormation, IPv4 header total length needs update,
because encrypted payload's length is NOT same as that of plain text.
- After transformation, IPv4 checksum needs re-caculate because of payload
has been changed.
With this patch, armmed pktgen with below cofiguration, Wireshark is able to
decrypted ESP packet generated by pktgen without any IPv4 checksum error or
auth value error.
pgset "flag IPSEC"
pgset "flows 1"
Signed-off-by: Fan Du <fan.du@windriver.com>
---
v2:
- compute IPv4 checksum only after transformation taken place.
- This weekend I also noticed auth value is not correct as well, further
investigation indicates IPv4 header length is not updated after
transformation.,so v2 fix this.
---
net/core/pktgen.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 261357a..0bb8e5c 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2527,6 +2527,8 @@ static int process_ipsec(struct pktgen_dev *pkt_dev,
if (x) {
int ret;
__u8 *eth;
+ struct iphdr *iph;
+
nhead = x->props.header_len - skb_headroom(skb);
if (nhead > 0) {
ret = pskb_expand_head(skb, nhead, 0, GFP_ATOMIC);
@@ -2548,6 +2550,11 @@ static int process_ipsec(struct pktgen_dev *pkt_dev,
eth = (__u8 *) skb_push(skb, ETH_HLEN);
memcpy(eth, pkt_dev->hh, 12);
*(u16 *) ð[12] = protocol;
+
+ /* Update IPv4 header len as well as checksum value */
+ iph = ip_hdr(skb);
+ iph->tot_len = htons(skb->len - ETH_HLEN);
+ ip_send_check(iph);
}
}
return 1;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] net: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
From: Johannes Berg @ 2013-12-01 9:35 UTC (permalink / raw)
To: Joe Perches
Cc: Chen Gang, John W. Linville, rkuo, linux-kernel@vger.kernel.org,
David Miller, linux-wireless, netdev
In-Reply-To: <1385843940.2664.4.camel@joe-AO722>
On Sat, 2013-11-30 at 12:39 -0800, Joe Perches wrote:
> +++ b/net/mac80211/tx.c
> @@ -1777,18 +1777,16 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
> }
> ap_sdata = container_of(sdata->bss, struct ieee80211_sub_if_data,
> u.ap);
> - chanctx_conf = rcu_dereference(ap_sdata->vif.chanctx_conf);
> - if (!chanctx_conf)
> - goto fail_rcu;
> - band = chanctx_conf->def.chan->band;
> - if (sta)
> - break;
> /* fall through */
> case NL80211_IFTYPE_AP:
> - if (sdata->vif.type == NL80211_IFTYPE_AP)
> - chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> + chanctx_conf = rcu_dereference(ap_sdata->vif.chanctx_conf);
Good try, but no, now ap_sdata isn't even assigned. :)
johannes
^ permalink raw reply
* Re: [PATCH] net: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
From: Johannes Berg @ 2013-12-01 9:37 UTC (permalink / raw)
To: Chen Gang
Cc: Joe Perches, John W. Linville, rkuo, linux-kernel@vger.kernel.org,
David Miller, linux-wireless, netdev
In-Reply-To: <529A7955.9010507@gmail.com>
On Sun, 2013-12-01 at 07:48 +0800, Chen Gang wrote:
> If ieee80211_subif_start_xmit() is not performance sensitive (I guess
> so), we can use some short static functions instead of some code blocks
> within ieee80211_subif_start_xmit().
>
> - ieee80211_subif_start_xmit() is a long function (600+ lines).
>
> - use short static function can share some code.
>
> - if code can be shared, the work flow can be more clearer too (don't
> need fall-through or goto).
Frankly, I'm getting tired of discussing this. Please don't try to
rewrite this code until you've understood it. You suggesting that
"start_xmit()" isn't a performance sensitive function makes me realize
you haven't even tried.
johannes
^ permalink raw reply
* Re: [PATCH] net: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
From: Chen Gang @ 2013-12-01 11:50 UTC (permalink / raw)
To: Johannes Berg
Cc: Joe Perches, John W. Linville, rkuo,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <1385890647.4171.3.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
On 12/01/2013 05:37 PM, Johannes Berg wrote:
> On Sun, 2013-12-01 at 07:48 +0800, Chen Gang wrote:
>
>> If ieee80211_subif_start_xmit() is not performance sensitive (I guess
>> so), we can use some short static functions instead of some code blocks
>> within ieee80211_subif_start_xmit().
>>
>> - ieee80211_subif_start_xmit() is a long function (600+ lines).
>>
>> - use short static function can share some code.
>>
>> - if code can be shared, the work flow can be more clearer too (don't
>> need fall-through or goto).
>
> Frankly, I'm getting tired of discussing this. Please don't try to
> rewrite this code until you've understood it. You suggesting that
> "start_xmit()" isn't a performance sensitive function makes me realize
> you haven't even tried.
>
OK, thank you for "you are getting tired ...". Please help try when you
have time. :-)
No I didn't try -- so use 'if' and 'guess' for discussing.
Hmm... if it is performance sensitive:
- use static function instead of some code block and try to share them.
it adds additional instructions, but can shrink binary code size.
if the performance is acceptable, it is the best way to me.
- else (1st way not acceptable), use macro instead of static function.
it expends binary code size, but can save some instructions.
if the performance is acceptable, it is the acceptable way to me.
- If neither of static function nor macro are acceptable,
I still prefer to use 'goto' instead of 'fall-through'.
that can let all compilers feel well, and can not feel any strange.
normally, when prev case uses fall-through,
it need be sure of next case need not notice about it (prev case).
or it will make a little strange for readers when read next case.
Welcome any suggestions or completions.
Thanks.
--
Chen Gang
--
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
* [PATCH net] net/mlx4_en: Remove selftest TX queues empty condition
From: Amir Vadai @ 2013-12-01 12:19 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Amir Vadai, Or Gerlitz, Eugenia Emantayev
From: Eugenia Emantayev <eugenia@mellanox.com>
Remove waiting for TX queues to become empty during selftest.
This check is not necessary for any purpose, and might put
the driver into an infinite loop.
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_selftest.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_selftest.c b/drivers/net/ethernet/mellanox/mlx4/en_selftest.c
index 4062669..c11d063 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_selftest.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_selftest.c
@@ -140,7 +140,6 @@ void mlx4_en_ex_selftest(struct net_device *dev, u32 *flags, u64 *buf)
{
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
- struct mlx4_en_tx_ring *tx_ring;
int i, carrier_ok;
memset(buf, 0, sizeof(u64) * MLX4_EN_NUM_SELF_TEST);
@@ -150,16 +149,10 @@ void mlx4_en_ex_selftest(struct net_device *dev, u32 *flags, u64 *buf)
carrier_ok = netif_carrier_ok(dev);
netif_carrier_off(dev);
-retry_tx:
/* Wait until all tx queues are empty.
* there should not be any additional incoming traffic
* since we turned the carrier off */
msleep(200);
- for (i = 0; i < priv->tx_ring_num && carrier_ok; i++) {
- tx_ring = priv->tx_ring[i];
- if (tx_ring->prod != (tx_ring->cons + tx_ring->last_nr_txbb))
- goto retry_tx;
- }
if (priv->mdev->dev->caps.flags &
MLX4_DEV_CAP_FLAG_UC_LOOPBACK) {
--
1.8.3.4
^ permalink raw reply related
* Re: [PATCH v2 13/17] net: mlx4 calls skb_set_rxhash
From: Amir Vadai @ 2013-12-01 12:26 UTC (permalink / raw)
To: Tom Herbert, netdev, davem; +Cc: Hadar Hen Zion
In-Reply-To: <alpine.DEB.2.02.1311260928050.21143@tomh.mtv.corp.google.com>
On 26/11/2013 19:31, Tom Herbert wrote:
> Drivers should call skb_set_rxhash to set the rxhash and its type
> in an skbuff.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index 07a1d0f..3e48c44 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -747,7 +747,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> }
>
> if (dev->features & NETIF_F_RXHASH)
> - gro_skb->rxhash = be32_to_cpu(cqe->immed_rss_invalid);
> + skb_set_rxhash(gro_skb, be32_to_cpu(cqe->immed_rss_invalid), RXHASH_TYPE_L3);
>
> skb_record_rx_queue(gro_skb, cq->ring);
>
> @@ -789,7 +789,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> skb_record_rx_queue(skb, cq->ring);
>
> if (dev->features & NETIF_F_RXHASH)
> - skb->rxhash = be32_to_cpu(cqe->immed_rss_invalid);
> + skb_set_rxhash(skb, be32_to_cpu(cqe->immed_rss_invalid), RXHASH_TYPE_L3);
>
> if ((be32_to_cpu(cqe->vlan_my_qpn) &
> MLX4_CQE_VLAN_PRESENT_MASK) &&
>
I need to do some work in this area of code, but anyway it is not in the
scope of this patchset.
Acked-By: Amir Vadai <amirv@mellanox.com>
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH] Fix ARM BUILD_BUG_ON() errors with batman-adv
From: Antonio Quartulli @ 2013-12-01 14:28 UTC (permalink / raw)
To: linux
Cc: The list for a Better Approach To Mobile Ad-hoc Networking,
netdev, David Miller
In-Reply-To: <529A8276.9060002@meshcoding.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/12/13 01:27, Antonio Quartulli wrote:
> On 01/12/13 00:05, Russell King - ARM Linux wrote:
>> On Sat, Nov 30, 2013 at 09:12:52PM +0100, Antonio Quartulli
>> wrote:
>>> I don't know the ARM architecture at all (I don't know if the
>>> other batman-adv developers do), so could you please provide
>>> here some more details about why that static check is failing?
>>> We would like to address this issue differently rather than
>>> re-adding the __packed attribute.
>
>> The reason is this struct becomes a size of 4 bytes, even though
>> it only contains three uint8_t members. This offsets the
>> members of all structs that this struct is embedded in.
>
>> If you don't wish to fix this, then please make your subsystem
>> depend on !ARM because it's otherwise impossible to fix and can
>> never work on ARM.
>
>
> I'd like to fix this.
>
> Actually I can't really understand your explanation: struct
> batadv_header is always used inside another parent structure and
> the latter always has a uint8_t following the batadv_header, thus
> filling that gap and aligning it to 4bytes. I think this is also
> why we don't get this compiler error on any other architecture. Or
> am I missing something?
>
> I'll install a toolchain for ARM and I'll try to inspect it
> better. If we have to make a change we should do it before 3.13 is
> release since this change could possibly alter the packet layout.
>
>
It looks like that the ARM compiler cannot pack the structures properly.
So, given these two structures:
struct batadv_header {
uint8_t packet_type;
uint8_t version;
uint8_t ttl;
};
struct batadv_unicast_packet {
struct batadv_header header;
uint8_t ttvn;
uint8_t dest[ETH_ALEN];
};
we have the compiler saying that offset_of dest in struct
batadv_unicast_packet is 5.
This means that struct batadv_header is padded to 4 bytes even if it
is enclosed in struct batadv_unicast_packet and a proper 1byte member
is put right after it.
Am I wrong or this is a problem in the ARM compiler not doing the
right assumption? On x86 and x86_64 offset_of dest is 4, as expected.
Regards,
- --
Antonio Quartulli
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlKbR6oACgkQpGgxIkP9cwdpYACgjcWLZ7EGFDatHTsByPz7idsY
YOgAnRq6JTmOv8zI3OrRiBRtOIprgOew
=Jxbq
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: "swiotlb buffer is full" with 3.13-rc1+ but not 3.4.
From: Stefano Stabellini @ 2013-12-01 17:06 UTC (permalink / raw)
To: James Bottomley
Cc: Konrad Rzeszutek Wilk, Ian Jackson, netdev, Michael Chan,
dl-mptfusionlinux, linux-scsi, support, Sreekanth Reddy,
Nagalakshmi Nandigama, xen-devel, linux-kernel
In-Reply-To: <1385844524.2170.10.camel@dabdike>
On Sat, 30 Nov 2013, James Bottomley wrote:
> On Sat, 2013-11-30 at 13:56 -0500, Konrad Rzeszutek Wilk wrote:
> > My theory is that the SWIOTLB is not full - it is just that the request
> > is for a compound page that is more than 512kB. Please note that
> > SWIOTLB highest "chunk" of buffer it can deal with is 512kb.
> >
> > And that is of course the question comes out - why would it try to
> > bounce buffer it. In Xen the answer is simple - the sg chunks cross page
> > boundaries which means that they are not physically contingous - so we
> > have to use the bounce buffer. It would be better if the the sg list
> > provided a large list of 4KB pages instead of compound pages as that
> > could help in avoiding the bounce buffer.
> >
> > But I digress - this is a theory - I don't know whether the SCSI layer
> > does any colescing of the sg list - and if so, whether there is any
> > easy knob to tell it to not do it.
>
> Well, SCSI doesn't, but block does. It's actually an efficiency thing
> since most firmware descriptor formats cope with multiple pages and the
> more descriptors you have for a transaction, the more work the on-board
> processor on the HBA has to do. If you have an emulated HBA, like
> virtio, you could turn off physical coalesing by setting the
> use_clustering flag to DISABLE_CLUSTERING. But you can't do that for a
> real card. I assume the problem here is that the host is passing the
> card directly to the guest and the guest clusters based on its idea of
> guest pages which don't map to contiguous physical pages?
>
> The way you tell how many physically contiguous pages block is willing
> to merge is by looking at /sys/block/<dev>/queue/max_segment_size if
> that's 4k then it won't merge, if it's greater than 4k, then it will.
>
> I'm not quite sure what to do ... you can't turn of clustering globally
> in the guest because the virtio drivers use it to reduce ring descriptor
> pressure, what you probably want is some way to flag a pass through
> device.
Given that we don't use virtio on Xen, we could actually turn off
clustering globally (if we are running on Xen).
In fact for example BIOVEC_PHYS_MERGEABLE is defined:
+#define BIOVEC_PHYS_MERGEABLE(vec1, vec2) \
+ (__BIOVEC_PHYS_MERGEABLE(vec1, vec2) && \
+ (!xen_domain() || xen_biovec_phys_mergeable(vec1, vec2)))
so that we can disable it if the two bv_page are not actually physical
contiguous.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH] Fix ARM BUILD_BUG_ON() errors with batman-adv
From: Russell King - ARM Linux @ 2013-12-01 17:13 UTC (permalink / raw)
To: Antonio Quartulli
Cc: The list for a Better Approach To Mobile Ad-hoc Networking,
netdev, David Miller
In-Reply-To: <529B47AA.8060403@meshcoding.com>
On Sun, Dec 01, 2013 at 03:28:58PM +0100, Antonio Quartulli wrote:
> On 01/12/13 01:27, Antonio Quartulli wrote:
> > On 01/12/13 00:05, Russell King - ARM Linux wrote:
> >> On Sat, Nov 30, 2013 at 09:12:52PM +0100, Antonio Quartulli
> >> wrote:
> >>> I don't know the ARM architecture at all (I don't know if the
> >>> other batman-adv developers do), so could you please provide
> >>> here some more details about why that static check is failing?
> >>> We would like to address this issue differently rather than
> >>> re-adding the __packed attribute.
> >
> >> The reason is this struct becomes a size of 4 bytes, even though
> >> it only contains three uint8_t members. This offsets the
> >> members of all structs that this struct is embedded in.
> >
> >> If you don't wish to fix this, then please make your subsystem
> >> depend on !ARM because it's otherwise impossible to fix and can
> >> never work on ARM.
> >
> >
> > I'd like to fix this.
> >
> > Actually I can't really understand your explanation: struct
> > batadv_header is always used inside another parent structure and
> > the latter always has a uint8_t following the batadv_header, thus
> > filling that gap and aligning it to 4bytes. I think this is also
> > why we don't get this compiler error on any other architecture. Or
> > am I missing something?
> >
> > I'll install a toolchain for ARM and I'll try to inspect it
> > better. If we have to make a change we should do it before 3.13 is
> > release since this change could possibly alter the packet layout.
> >
> >
>
> It looks like that the ARM compiler cannot pack the structures properly.
This is not a compiler bug. This is a bug in how you understand the C
specifications.
> we have the compiler saying that offset_of dest in struct
> batadv_unicast_packet is 5.
Correct.
> This means that struct batadv_header is padded to 4 bytes even if it
> is enclosed in struct batadv_unicast_packet and a proper 1byte member
> is put right after it.
>
> Am I wrong or this is a problem in the ARM compiler not doing the
> right assumption? On x86 and x86_64 offset_of dest is 4, as expected.
The C standards allow implementations to pad structures as they see fit
for performance reasons. The only thing which C guarantees is that the
order of the structure members are specified. Padding is allowed to be
added between members and at the end of the structure.
The ARM compilers have for the last 20 years always aligned the size of
structs to a multiple of 32 bits to ensure that members following a
structure are appropriately aligned.
Changing this behaviour is completely out of the question: that would
be similar to asking for the x86 compiler to change the way it lays out
its structures.
The only solutions are: use the GCC packed attribute, redesign the
structures, or just accept that it won't ever be usable on ARM.
Frankly, I don't care about having this protocol working on ARM. My
report was just because it was found by one of my randconfig builds.
I've learned my lesson now - don't report bugs...
^ permalink raw reply
* Re: [RFC] Fix Free Software Foundation address in file headers
From: Xose Vazquez Perez @ 2013-12-01 18:56 UTC (permalink / raw)
To: jeffrey.t.kirsher, netdev, linux-kernel
Jeff Kirsher wrote:
> This came up when John Fastabend got a patch to fix up the headers in
> the drivers/scsi/ directory and so I did a quick search of the network
> drivers and found several instances in the file headers where an old FSF
> address remains. The old address is:
>
> 59 Temple Place - Suite 330
> Boston, MA 02111-1307
>
> The current address is:
>
> 51 Franklin Street - Fifth Floor
> Boston, MA 02110-1301
>
> I am wondering whether it may be best to just put a link to the Free
> Software Foundation web page instead of having to update the address any
> time a change is made.
>
> Either way, I feel the address either needs to get corrected or changed
> to the URL, even though I am not a fan of huge patch series to make
> trivial changes like this.
>
> Thoughts?
Something like that should be enough:
[...]
You should have received a copy of the GNU General Public License along
- with this program; if not, write to the Free Software Foundation, Inc.,
- 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ with this program. If not, see <http://www.gnu.org/licenses/>.
[...]
This was changed in that form in gpl3.
There are about 3684 references with, at least, 140 variations. Infinite Patience(TM).
^ permalink raw reply
* Re: [PATCH] Fix ARM BUILD_BUG_ON() errors with batman-adv
From: David Miller @ 2013-12-01 19:21 UTC (permalink / raw)
To: antonio-x4xJYDvStAgysxA8WJXlww
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
linux-lFZ/pmaqli7XmaaqVzeoHQ
In-Reply-To: <529B47AA.8060403-x4xJYDvStAgysxA8WJXlww@public.gmane.org>
From: Antonio Quartulli <antonio-x4xJYDvStAgysxA8WJXlww@public.gmane.org>
Date: Sun, 01 Dec 2013 15:28:58 +0100
> Am I wrong or this is a problem in the ARM compiler not doing the
> right assumption? On x86 and x86_64 offset_of dest is 4, as expected.
These alignment behaviors are defined by the processor ABI, there is
no set of global rules that apply, so it behaves differently on
different CPUs. What you observe is correct behavior for compilation
on ARM processors.
^ permalink raw reply
* ATTENTION
From: Crossfield @ 2013-12-01 18:55 UTC (permalink / raw)
Your Email has won (£1,373,420 pounds) in our
British Promotion.contact us for details via:
lottery_b1@yahoo.com
_____________________________________________________________________________________
This communication is intended for the use of the recipient to which it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communication received in error, or subsequent
reply, should be deleted or destroyed.
^ 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