* [PATCH] atm: nicstar: fix regression made by previous patch
From: Andy Shevchenko @ 2013-09-13 15:00 UTC (permalink / raw)
To: Chas Williams, linux-atm-general, netdev; +Cc: Andy Shevchenko
The commit 8390f814 "atm: nicstar: re-use native mac_pton() helper" did a
usefull thing. However, mac_pton() returns 1 in the case of the successfully
parsed input. This patch fixes a typo.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/atm/nicstar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c
index 409502a..5aca5f4 100644
--- a/drivers/atm/nicstar.c
+++ b/drivers/atm/nicstar.c
@@ -778,7 +778,7 @@ static int ns_init_card(int i, struct pci_dev *pcidev)
return error;
}
- if (mac[i] == NULL || mac_pton(mac[i], card->atmdev->esi)) {
+ if (mac[i] == NULL || !mac_pton(mac[i], card->atmdev->esi)) {
nicstar_read_eprom(card->membase, NICSTAR_EPROM_MAC_ADDR_OFFSET,
card->atmdev->esi, 6);
if (memcmp(card->atmdev->esi, "\x00\x00\x00\x00\x00\x00", 6) ==
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH] [Trivial] remove unnecessary header file inclusion
From: ZHAO Gang @ 2013-09-13 14:57 UTC (permalink / raw)
To: gamerh2o; +Cc: davem, netdev, linux-kernel
file linux/fib_rules.h doesn't exist, so remove it.
Signed-off-by: ZHAO Gang <gamerh2o@gmail.com>
---
include/net/fib_rules.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
index 4b2b557..c816f91 100644
--- a/include/net/fib_rules.h
+++ b/include/net/fib_rules.h
@@ -4,7 +4,6 @@
#include <linux/types.h>
#include <linux/slab.h>
#include <linux/netdevice.h>
-#include <linux/fib_rules.h>
#include <net/flow.h>
#include <net/rtnetlink.h>
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net, vxlan Fix compile warning
From: Stephen Hemminger @ 2013-09-13 14:40 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: netdev, jpirko, tgraf, David S. Miller
In-Reply-To: <52331FF7.3070905@redhat.com>
On Fri, 13 Sep 2013 10:23:51 -0400
Prarit Bhargava <prarit@redhat.com> wrote:
>
>
> On 09/13/2013 10:20 AM, Stephen Hemminger wrote:
> > On Fri, 13 Sep 2013 08:29:12 -0400
> > Prarit Bhargava <prarit@redhat.com> wrote:
> >
> >> Fix a unintialized variable warning.
> >>
> >> drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
> >> drivers/net/vxlan.c:2240:11: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >> vs->sock = sock;
> >> ^
> >> drivers/net/vxlan.c:2217:17: note: ‘sock’ was declared here
> >> struct socket *sock;
> >> ^
> >>
> >> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> >> Cc: jpirko@redhat.com
> >> Cc: tgraf@redhat.com
> >> Cc: "David S. Miller" <davem@davemloft.net>
> >
> > Which compiler version? Gcc 4.6 is known to be stupid,
> > and I would rather not change the source if it is only caused
> > by a gcc bug fixed in a later release.
>
> Hi Stephen,
>
> [root@intel-rosecity-06 ~]# gcc --version
> gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> P.
Argh, gcc got stupid again. I guess we have to live it.
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* [net] vxlan: Fix sparse warnings
From: Jeff Kirsher @ 2013-09-13 14:34 UTC (permalink / raw)
To: davem; +Cc: Joseph Gasparakis, netdev, gospo, sassmann, Jeff Kirsher
From: Joseph Gasparakis <joseph.gasparakis@intel.com>
This patch fixes sparse warnings when incorrectly handling the port number
and using int instead of unsigned int iterating through &vn->sock_list[].
Keeping the port as __be16 also makes things clearer wrt endianess.
Also, it was pointed out that vxlan_get_rx_port() had unnecessary checks
which got removed.
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/vxlan.c | 18 ++++++++----------
include/linux/netdevice.h | 8 ++++----
2 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bf64b41..2400b1b 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -564,7 +564,7 @@ static void vxlan_notify_add_rx_port(struct sock *sk)
struct net_device *dev;
struct net *net = sock_net(sk);
sa_family_t sa_family = sk->sk_family;
- u16 port = htons(inet_sk(sk)->inet_sport);
+ __be16 port = inet_sk(sk)->inet_sport;
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
@@ -581,7 +581,7 @@ static void vxlan_notify_del_rx_port(struct sock *sk)
struct net_device *dev;
struct net *net = sock_net(sk);
sa_family_t sa_family = sk->sk_family;
- u16 port = htons(inet_sk(sk)->inet_sport);
+ __be16 port = inet_sk(sk)->inet_sport;
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
@@ -2021,7 +2021,8 @@ static struct device_type vxlan_type = {
};
/* Calls the ndo_add_vxlan_port of the caller in order to
- * supply the listening VXLAN udp ports.
+ * supply the listening VXLAN udp ports. Callers are expected
+ * to implement the ndo_add_vxlan_port.
*/
void vxlan_get_rx_port(struct net_device *dev)
{
@@ -2029,16 +2030,13 @@ void vxlan_get_rx_port(struct net_device *dev)
struct net *net = dev_net(dev);
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
sa_family_t sa_family;
- u16 port;
- int i;
-
- if (!dev || !dev->netdev_ops || !dev->netdev_ops->ndo_add_vxlan_port)
- return;
+ __be16 port;
+ unsigned int i;
spin_lock(&vn->sock_lock);
for (i = 0; i < PORT_HASH_SIZE; ++i) {
- hlist_for_each_entry_rcu(vs, vs_head(net, i), hlist) {
- port = htons(inet_sk(vs->sock->sk)->inet_sport);
+ hlist_for_each_entry_rcu(vs, &vn->sock_list[i], hlist) {
+ port = inet_sk(vs->sock->sk)->inet_sport;
sa_family = vs->sock->sk->sk_family;
dev->netdev_ops->ndo_add_vxlan_port(dev, sa_family,
port);
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 041b42a..3de49ac 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -950,14 +950,14 @@ struct netdev_phys_port_id {
* multiple net devices on single physical port.
*
* void (*ndo_add_vxlan_port)(struct net_device *dev,
- * sa_family_t sa_family, __u16 port);
+ * sa_family_t sa_family, __be16 port);
* Called by vxlan to notiy a driver about the UDP port and socket
* address family that vxlan is listnening to. It is called only when
* a new port starts listening. The operation is protected by the
* vxlan_net->sock_lock.
*
* void (*ndo_del_vxlan_port)(struct net_device *dev,
- * sa_family_t sa_family, __u16 port);
+ * sa_family_t sa_family, __be16 port);
* Called by vxlan to notify the driver about a UDP port and socket
* address family that vxlan is not listening to anymore. The operation
* is protected by the vxlan_net->sock_lock.
@@ -1093,10 +1093,10 @@ struct net_device_ops {
struct netdev_phys_port_id *ppid);
void (*ndo_add_vxlan_port)(struct net_device *dev,
sa_family_t sa_family,
- __u16 port);
+ __be16 port);
void (*ndo_del_vxlan_port)(struct net_device *dev,
sa_family_t sa_family,
- __u16 port);
+ __be16 port);
};
/*
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
From: Thomas Gleixner @ 2013-09-13 14:32 UTC (permalink / raw)
To: Fan Du
Cc: David Miller, herbert, steffen.klassert, dborkman, linux-kernel,
netdev, John Stultz
In-Reply-To: <52327C92.5010009@windriver.com>
On Fri, 13 Sep 2013, Fan Du wrote:
> (2) What I have been bugging you around here for this long time is really the
> second
> problem, I'm sorry I didn't make it clearly to you and others, which is
> below:
>
> Why using wall clock time to calculate soft/hard IPsec events when
> xfrm_state timer
> out happens in its timeout handler? Because even if xfrm_state using
> CLOCK_BOOTTIME,
> system wall clock time changing will surely disturb soft/hard IPsec
> events, which
> you raised your concern about in (*a*).
No CLOCK_BOOTTIME is not affected by wall clock time changes. It's
basically CLOCK_MONOTONIC, it just keeps counting the suspend time as
well. So without a suspend/resume cycle CLOCK_MONOTONIC and
CLOCK_BOOTTIME are the same. After a suspend/resume cycle
CLOCK_BOOTTIME will be N seconds ahead of CLOCK_MONOTONIC, where N is
the number of seconds spent in suspend.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] net, vxlan Fix compile warning
From: Prarit Bhargava @ 2013-09-13 14:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, jpirko, tgraf, David S. Miller
In-Reply-To: <20130913072028.54b1c28d@samsung-9>
On 09/13/2013 10:20 AM, Stephen Hemminger wrote:
> On Fri, 13 Sep 2013 08:29:12 -0400
> Prarit Bhargava <prarit@redhat.com> wrote:
>
>> Fix a unintialized variable warning.
>>
>> drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
>> drivers/net/vxlan.c:2240:11: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> vs->sock = sock;
>> ^
>> drivers/net/vxlan.c:2217:17: note: ‘sock’ was declared here
>> struct socket *sock;
>> ^
>>
>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>> Cc: jpirko@redhat.com
>> Cc: tgraf@redhat.com
>> Cc: "David S. Miller" <davem@davemloft.net>
>
> Which compiler version? Gcc 4.6 is known to be stupid,
> and I would rather not change the source if it is only caused
> by a gcc bug fixed in a later release.
Hi Stephen,
[root@intel-rosecity-06 ~]# gcc --version
gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
P.
^ permalink raw reply
* Re: [PATCH] net, vxlan Fix compile warning
From: Stephen Hemminger @ 2013-09-13 14:20 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: netdev, jpirko, tgraf, David S. Miller
In-Reply-To: <1379075352-20051-1-git-send-email-prarit@redhat.com>
On Fri, 13 Sep 2013 08:29:12 -0400
Prarit Bhargava <prarit@redhat.com> wrote:
> Fix a unintialized variable warning.
>
> drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
> drivers/net/vxlan.c:2240:11: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> vs->sock = sock;
> ^
> drivers/net/vxlan.c:2217:17: note: ‘sock’ was declared here
> struct socket *sock;
> ^
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> Cc: jpirko@redhat.com
> Cc: tgraf@redhat.com
> Cc: "David S. Miller" <davem@davemloft.net>
Which compiler version? Gcc 4.6 is known to be stupid,
and I would rather not change the source if it is only caused
by a gcc bug fixed in a later release.
^ permalink raw reply
* Re: [PATCH 4/7] ptp: switch to use gpiolib
From: Richard Cochran @ 2013-09-13 13:36 UTC (permalink / raw)
To: Krzysztof Halasa
Cc: Linus Walleij, linux-gpio@vger.kernel.org, Imre Kaloz,
Alexandre Courbot, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org
In-Reply-To: <m38uz0vrlz.fsf@intrepid.localdomain>
On Fri, Sep 13, 2013 at 02:22:16PM +0200, Krzysztof Halasa wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>
> > Thanks, I have found numerous active hobbyists using the
> > IXP4-based NSLU2 NAS machine for various things - mostly
> > non-network related as it happens, so it'll be with us for a
> > while I think.
>
> IXP42x are most probably "end of life" in the commercial sense, but the
> newer IXP46x/455 and even newer IXP43x are still being sold. For
> example, Gateworks have a couple of IXP43x boards ("Cambria") which
> I personally find interesting, for some specific applications.
I was really talking about the IXP465 with its PTP function. The Intel
devel board had a silicon bug making the PTP function useless. But
even if the bug got fixed, still the PTP function was very limiting.
I never got any feedback about the IXP465 PTP stuff, and so I doubt
whether anyone is really using the Linux PTP driver on the IXP465, but
you never know.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] net, vxlan Fix compile warning
From: Jiri Pirko @ 2013-09-13 12:58 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: netdev, jpirko, tgraf, David S. Miller
In-Reply-To: <1379075352-20051-1-git-send-email-prarit@redhat.com>
Fri, Sep 13, 2013 at 02:29:12PM CEST, prarit@redhat.com wrote:
>Fix a unintialized variable warning.
>
>drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
>drivers/net/vxlan.c:2240:11: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> vs->sock = sock;
> ^
>drivers/net/vxlan.c:2217:17: note: ‘sock’ was declared here
> struct socket *sock;
> ^
>
>Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>Cc: jpirko@redhat.com
>Cc: tgraf@redhat.com
>Cc: "David S. Miller" <davem@davemloft.net>
Reviewed-by: Jiri Pirko <jiri@resnulli.us>
^ permalink raw reply
* Re: [PATCH net v2] net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit
From: Neil Horman @ 2013-09-13 12:42 UTC (permalink / raw)
To: Daniel Borkmann
Cc: davem, netdev, linux-sctp, adobriyan, Steffen Klassert,
Hannes Frederic Sowa
In-Reply-To: <1378911516-15942-1-git-send-email-dborkman@redhat.com>
On Wed, Sep 11, 2013 at 04:58:36PM +0200, Daniel Borkmann wrote:
> Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not
> being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport
> does not seem to have the desired effect:
>
> SCTP + IPv4:
>
> 22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116)
> 192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72
> 22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340)
> 192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1):
>
> SCTP + IPv6:
>
> 22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364)
> fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp
> 1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10]
>
> Moreover, Alan says:
>
> This problem was seen with both Racoon and Racoon2. Other people have seen
> this with OpenSwan. When IPsec is configured to encrypt all upper layer
> protocols the SCTP connection does not initialize. After using Wireshark to
> follow packets, this is because the SCTP packet leaves Box A unencrypted and
> Box B believes all upper layer protocols are to be encrypted so it drops
> this packet, causing the SCTP connection to fail to initialize. When IPsec
> is configured to encrypt just SCTP, the SCTP packets are observed unencrypted.
>
> In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext"
> string on the other end, results in cleartext on the wire where SCTP eventually
> does not report any errors, thus in the latter case that Alan reports, the
> non-paranoid user might think he's communicating over an encrypted transport on
> SCTP although he's not (tcpdump ... -X):
>
> ...
> 0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000 ]p.......}.l....
> 0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000 ....plaintext...
>
> Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the
> receiver side. Initial follow-up analysis from Alan's bug report was done by
> Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this.
>
> SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit().
> This has the implication that it probably never really got updated along with
> changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers.
>
> SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since
> a call to inet6_csk_xmit() would solve this problem, but result in unecessary
> route lookups, let us just use the cached flowi6 instead that we got through
> sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(),
> we do the route lookup / flow caching in sctp_transport_route(), hold it in
> tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in
> sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect
> of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst()
> instead to get the correct source routed dst entry, which we assign to the skb.
>
> Also source address routing example from 625034113 ("sctp: fix sctp to work with
> ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095
> it is actually 'recommended' to not use that anyway due to traffic amplification [1].
> So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if
> we overwrite the flow destination here, the lower IPv6 layer will be unable to
> put the correct destination address into IP header, as routing header is added in
> ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside,
> result of this patch is that we do not have any XfrmInTmplMismatch increase plus on
> the wire with this patch it now looks like:
>
> SCTP + IPv6:
>
> 08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba:
> AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72
> 08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a:
> AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296
>
> This fixes Kernel Bugzilla 24412. This security issue seems to be present since
> 2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have
> its fun with that. lksctp-tools IPv6 regression test suite passes as well with
> this patch.
>
> [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
>
> Reported-by: Alan Chester <alan.chester@tekelec.com>
> Reported-by: Alexey Dobriyan <adobriyan@gmail.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> v1->v2:
> - use cached flow
> - improved commit msg
>
> net/sctp/ipv6.c | 42 +++++++++++++-----------------------------
> 1 file changed, 13 insertions(+), 29 deletions(-)
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [patch v2 -stable] igbvf: integer wrapping bug setting the mtu
From: Jeff Kirsher @ 2013-09-13 12:39 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jesse Brandeburg, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Peter P Waskiewicz Jr, Alex Duyck, John Ronciak,
Tushar Dave, David S. Miller, Mitch Williams, Patrick McHardy,
Greg Kroah-Hartman, e1000-devel, netdev, kernel-janitors
In-Reply-To: <20130913122927.GA31819@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
On Fri, 2013-09-13 at 15:29 +0300, Dan Carpenter wrote:
> If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
> wrap and the check on the next line can underflow. This is one of
> those
> bugs which can be triggered by the user if you have namespaces
> configured.
>
> Also since this is something the user can trigger then we don't want
> to
> have dev_err() message.
>
> This is a static checker fix and I'm not sure what the impact is.
> ---
> v2: reformat and also remove the dev_err()
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Thanks Dan, I have added your patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] net, mellanox mlx4 Fix compile warnings
From: Prarit Bhargava @ 2013-09-13 12:30 UTC (permalink / raw)
To: netdev; +Cc: Prarit Bhargava, dledford, Amir Vadai, Or Gerlitz
Fix unitialized variable warnings.
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function ‘mlx4_HW2SW_CQ_wrapper’:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:2551:16: error: ‘cq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
atomic_dec(&cq->mtt->ref_count);
^
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function ‘mlx4_HW2SW_SRQ_wrapper’:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:2734:17: error: ‘srq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
atomic_dec(&srq->mtt->ref_count);
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: dledford@redhat.com
Cc: Amir Vadai <amirv@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
---
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index dd68763..d703838 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -2563,7 +2563,7 @@ int mlx4_HW2SW_CQ_wrapper(struct mlx4_dev *dev, int slave,
{
int err;
int cqn = vhcr->in_modifier;
- struct res_cq *cq;
+ struct res_cq *uninitialized_var(cq);
err = cq_res_start_move_to(dev, slave, cqn, RES_CQ_ALLOCATED, &cq);
if (err)
@@ -2746,7 +2746,7 @@ int mlx4_HW2SW_SRQ_wrapper(struct mlx4_dev *dev, int slave,
{
int err;
int srqn = vhcr->in_modifier;
- struct res_srq *srq;
+ struct res_srq *uninitialized_var(srq);
err = srq_res_start_move_to(dev, slave, srqn, RES_SRQ_ALLOCATED, &srq);
if (err)
--
1.7.9.3
^ permalink raw reply related
* [patch v2 -stable] igbvf: integer wrapping bug setting the mtu
From: Dan Carpenter @ 2013-09-13 12:29 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Jesse Brandeburg, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Peter P Waskiewicz Jr, Alex Duyck, John Ronciak,
Tushar Dave, David S. Miller, Mitch Williams, Patrick McHardy,
Greg Kroah-Hartman, e1000-devel, netdev, kernel-janitors
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7332@saturn3.aculab.com>
If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
wrap and the check on the next line can underflow. This is one of those
bugs which can be triggered by the user if you have namespaces
configured.
Also since this is something the user can trigger then we don't want to
have dev_err() message.
This is a static checker fix and I'm not sure what the impact is.
---
v2: reformat and also remove the dev_err()
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 95d5430..8cb7958 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2344,10 +2344,9 @@ static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
struct igbvf_adapter *adapter = netdev_priv(netdev);
int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
- if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
- dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
+ if (new_mtu < 68 || new_mtu > INT_MAX - ETH_HLEN - ETH_FCS_LEN ||
+ max_frame > MAX_JUMBO_FRAME_SIZE)
return -EINVAL;
- }
#define MAX_STD_JUMBO_FRAME_SIZE 9234
if (max_frame > MAX_STD_JUMBO_FRAME_SIZE) {
^ permalink raw reply related
* [PATCH] net, vxlan Fix compile warning
From: Prarit Bhargava @ 2013-09-13 12:29 UTC (permalink / raw)
To: netdev; +Cc: Prarit Bhargava, jpirko, tgraf, David S. Miller
Fix a unintialized variable warning.
drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
drivers/net/vxlan.c:2240:11: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
vs->sock = sock;
^
drivers/net/vxlan.c:2217:17: note: ‘sock’ was declared here
struct socket *sock;
^
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: jpirko@redhat.com
Cc: tgraf@redhat.com
Cc: "David S. Miller" <davem@davemloft.net>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bf64b41..ed3d7f4 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2276,7 +2276,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
{
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
struct vxlan_sock *vs;
- struct socket *sock;
+ struct socket *uninitialized_var(sock);
struct sock *sk;
int rc = 0;
unsigned int h;
--
1.7.9.3
^ permalink raw reply related
* [PATCH] ISDN, hfcpci Fix uninitialized warning
From: Prarit Bhargava @ 2013-09-13 12:28 UTC (permalink / raw)
To: netdev; +Cc: Prarit Bhargava, dzickus, Karsten Keil
Fix uninitialized warning. Use same fix as
drivers/media/pci/cx18/cx18-alsa-main.c
CC [M] drivers/isdn/hardware/mISDN/hfcpci.o
drivers/isdn/hardware/mISDN/hfcpci.c: In function ‘hfcpci_softirq’:
drivers/isdn/hardware/mISDN/hfcpci.c:2298:2: error: ignoring return
value of ‘driver_for_each_device’, declared with attribute
warn_unused_result [-Werror=unused-result]
(void) driver_for_each_device(&hfc_driver.driver, NULL, arg,
^
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: dzickus@redhat.com
Cc: Karsten Keil <isdn@linux-pingi.de>
---
drivers/isdn/hardware/mISDN/hfcpci.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcpci.c b/drivers/isdn/hardware/mISDN/hfcpci.c
index 7f910c7..2373b44 100644
--- a/drivers/isdn/hardware/mISDN/hfcpci.c
+++ b/drivers/isdn/hardware/mISDN/hfcpci.c
@@ -2295,8 +2295,12 @@ _hfcpci_softirq(struct device *dev, void *arg)
static void
hfcpci_softirq(void *arg)
{
- (void) driver_for_each_device(&hfc_driver.driver, NULL, arg,
+ int ret;
+
+ ret = driver_for_each_device(&hfc_driver.driver, NULL, arg,
_hfcpci_softirq);
+ if (unlikely(ret))
+ pr_warn("hfcpci_softirq: driver softirq failed\n");
/* if next event would be in the past ... */
if ((s32)(hfc_jiffies + tics - jiffies) <= 0)
--
1.7.9.3
^ permalink raw reply related
* Re: [PATCH 4/7] ptp: switch to use gpiolib
From: Krzysztof Halasa @ 2013-09-13 12:22 UTC (permalink / raw)
To: Linus Walleij
Cc: Richard Cochran, linux-gpio@vger.kernel.org, Imre Kaloz,
Alexandre Courbot, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org
In-Reply-To: <CACRpkdZOCkLmgQHZSiqQfvLp=WzNsaE5AcY3siJ0b=bL0Xv8Pg@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> Thanks, I have found numerous active hobbyists using the
> IXP4-based NSLU2 NAS machine for various things - mostly
> non-network related as it happens, so it'll be with us for a
> while I think.
IXP42x are most probably "end of life" in the commercial sense, but the
newer IXP46x/455 and even newer IXP43x are still being sold. For
example, Gateworks have a couple of IXP43x boards ("Cambria") which
I personally find interesting, for some specific applications.
There is no platform driver for Cambria in the official Linux, guess it
should be changed.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Toshiaki Makita @ 2013-09-13 12:06 UTC (permalink / raw)
To: David Miller
Cc: makita.toshiaki, vyasevic, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <20130912.160033.779509034953932316.davem@davemloft.net>
On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> Date: Tue, 10 Sep 2013 19:27:54 +0900
>
> > There seem to be some undesirable behaviors related with PVID.
> > 1. It has no effect assigning PVID to a port. PVID cannot be applied
> > to any frame regardless of whether we set it or not.
> > 2. FDB entries learned via frames applied PVID are registered with
> > VID 0 rather than VID value of PVID.
> > 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
> > This leads interoperational problems such as sending frames with VID
> > 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
> > 0 as they belong to VLAN 0, which is expected to be handled as they have
> > no VID according to IEEE 802.1Q.
> >
> > Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
> > is fixed, because we cannot activate PVID due to it.
>
> Please work out the issues in patch #2 with Vlad and resubmit this
> series.
>
> Thank you.
I'm hovering between whether we should fix the issue by changing vlan 0
interface behavior in 8021q module or enabling a bridge port to sending
priority-tagged frames, or another better way.
If you could comment it, I'd appreciate it :)
BTW, I think what is discussed in patch #2 is another problem about
handling priority-tags, and it exists without this patch set applied.
It looks like that we should prepare another patch set than this to fix
that problem.
Should I include patches that fix the priority-tags problem in this
patch set and resubmit them all together?
Thanks,
Toshiaki Makita
>
> --
> 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 -stable] igbvf: integer wrapping bug setting the mtu
From: David Laight @ 2013-09-13 10:55 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Peter P Waskiewicz Jr, Alex Duyck,
John Ronciak, Tushar Dave, David S. Miller, Mitch Williams,
Patrick McHardy, Greg Kroah-Hartman, e1000-devel, netdev,
kernel-janitors
In-Reply-To: <20130913095423.GH19256@mwanda>
> > > static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
> > > {
> > > struct igbvf_adapter *adapter = netdev_priv(netdev);
> > > - int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> > > + unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> > >
> > > if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
> > > dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
> >
> > It is safer to check:
> > if ((new_mtu < 68) || (new_mtu > MAX_JUMBO_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)) {
> >
>
> I believe my fix is already 100% safe... Where is the bug in my code?
>
> Your fix harder to read because of the additional math and because it's
> checking "new_mtu" when we care about "max_frame".
I don't like the window check on two variables.
However if ETH_HLEN and ETH_FCS_LEN are 'int' (not an unsigned type)
and 'new_mtu' is just below MAX_INT then the signed arithmetic
could overflow - generating an indeterminate value.
In which case 'max_frame' might not exceed MAX_JUMBO_FRAME_SIZE.
David
^ permalink raw reply
* [PATCH net 1/1] qlcnic: Fix VF reset recovery
From: Manish Chopra @ 2013-09-13 10:13 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-HSGLinuxNICDev
o At the time of firmware hang "adapter->need_fw_reset" variable gets
set but after re-initialization of firmware OR at the time of VF
re-initialization that variable was not getting cleared which
was leading to failure in VF reset recovery.Fix it by clearing
this variable before re-initializing VF
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
---
.../ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
index 652cc13..392b9bd 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
@@ -1561,6 +1561,7 @@ static int qlcnic_sriov_vf_reinit_driver(struct qlcnic_adapter *adapter)
{
int err;
+ adapter->need_fw_reset = 0;
qlcnic_83xx_reinit_mbx_work(adapter->ahw->mailbox);
qlcnic_83xx_enable_mbx_interrupt(adapter);
--
1.5.6
^ permalink raw reply related
* Re: [patch -stable] igbvf: integer wrapping bug setting the mtu
From: Dan Carpenter @ 2013-09-13 9:54 UTC (permalink / raw)
To: David Laight
Cc: kernel-janitors, netdev, Patrick McHardy, e1000-devel,
Bruce Allan, Jesse Brandeburg, David S. Miller, John Ronciak,
Greg Kroah-Hartman
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B732F@saturn3.aculab.com>
On Fri, Sep 13, 2013 at 09:58:25AM +0100, David Laight wrote:
> > If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
> > wrap and the check on the next line can underflow. This is one of those
> > bugs which can be triggered by the user if you have namespaces
> > configured.
> >
> > This is a static checker fix and I'm not sure what the impact is.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
> > index 95d5430..24e3883 100644
> > --- a/drivers/net/ethernet/intel/igbvf/netdev.c
> > +++ b/drivers/net/ethernet/intel/igbvf/netdev.c
> > @@ -2342,7 +2342,7 @@ static struct net_device_stats *igbvf_get_stats(struct net_device *netdev)
> > static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
> > {
> > struct igbvf_adapter *adapter = netdev_priv(netdev);
> > - int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> > + unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> >
> > if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
> > dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
>
> It is safer to check:
> if ((new_mtu < 68) || (new_mtu > MAX_JUMBO_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)) {
>
I believe my fix is already 100% safe... Where is the bug in my code?
Your fix harder to read because of the additional math and because it's
checking "new_mtu" when we care about "max_frame".
regards,
dan carpenter
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] Inet-hashtable: Change the range of sk->hash lock to avoid the race condition.
From: Jun Chen @ 2013-09-13 9:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: edumazet, davem, netdev, linux-kernel, Jun Chen
In-Reply-To: <1378987204.24408.1.camel@edumazet-glaptop>
On Thu, 2013-09-12 at 05:00 -0700, Eric Dumazet wrote:
> On Thu, 2013-09-12 at 12:32 -0400, Jun Chen wrote:
> > When try to add node to list in __inet_hash_nolisten function, first get the
> > list and then to lock for using, but in extremeness case, others can del this
> > node before locking it, then the node should be null.So this patch try to lock
> > firstly and then get the list for using to avoid this race condition.
>
> I suspect another bug. This should not happen.
>
> Care to describe the problem you got ?
>
> Thanks
>
>
Ok, I just got this call stack and no more info, pls help to look it.
thanks!
<1>[ 88.548263] BUG: unable to handle kernel NULL pointer dereference at
00000004
<1>[ 88.548490] IP: [] __inet_hash_nolisten+0xc1/0x140
<4>[ 88.548617] *pde = 00000000
<4>[ 88.549927] EIP is at __inet_hash_nolisten+0xc1/0x140
<4>[ 88.550008] EAX: 00000000 EBX: e08c0000 ECX: edf846e0 EDX: e08c0020
<4>[ 88.550055] ESI: c20213c0 EDI: edc12dc0 EBP: ce4bfdfc ESP: ce4bfde8
<4>[ 88.550137] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068
<4>[ 88.550184] CR0: 80050033 CR2: 00000004 CR3: 2b4ff000 CR4: 001007d0
<4>[ 88.550266] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
<4>[ 88.550346] DR6: ffff0ff0 DR7: 00000400
<0>[ 88.550392] Process WebViewCoreThre (pid: 2137, ti=ce4be000
task=eb193c80 task.ti=ce4be000)
<0>[ 88.551746] Call Trace:
<4>[ 88.551797] [] __inet_hash_connect+0x295/0x2d0
<4>[ 88.551883] [] inet_hash_connect+0x40/0x50
<4>[ 88.551932] [] ? inet_unhash+0x90/0x90
<4>[ 88.551981] [] ? __inet_lookup_listener+0x1b0/0x1b0
<4>[ 88.552067] [] tcp_v4_connect+0x247/0x4a0
<4>[ 88.552117] [] ? lock_sock_nested+0x3e/0x50
<4>[ 88.552205] [] inet_stream_connect+0xe2/0x290
<4>[ 88.552254] [] ? _copy_from_user+0x35/0x50
<4>[ 88.552342] [] sys_connect+0xb2/0xd0
<4>[ 88.552393] [] ? alloc_file+0x20/0xa0
<4>[ 88.552441] [] ? tcp_setsockopt+0x50/0x60
<4>[ 88.552525] [] ? fget_light+0x44/0xe0
<4>[ 88.552574] [] ? sock_common_setsockopt+0x27/0x40
<4>[ 88.552659] [] ? _copy_from_user+0x35/0x50
<4>[ 88.552708] [] sys_socketcall+0xab/0x2b0
<4>[ 88.552790] [] ? trace_hardirqs_on_thunk+0xc/0x10
<4>[ 88.552840] [] syscall_call+0x7/0xb
<4>[ 88.552923] [] ? mutex_trylock+0x30/0x140
^ permalink raw reply
* RE: [patch -stable] igbvf: integer wrapping bug setting the mtu
From: David Laight @ 2013-09-13 8:58 UTC (permalink / raw)
To: Dan Carpenter, Jeff Kirsher
Cc: Jesse Brandeburg, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Peter P Waskiewicz Jr, Alex Duyck, John Ronciak,
Tushar Dave, David S. Miller, Mitch Williams, Patrick McHardy,
Greg Kroah-Hartman, e1000-devel, netdev, kernel-janitors
In-Reply-To: <20130913083736.GK19211@elgon.mountain>
> If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
> wrap and the check on the next line can underflow. This is one of those
> bugs which can be triggered by the user if you have namespaces
> configured.
>
> This is a static checker fix and I'm not sure what the impact is.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
> index 95d5430..24e3883 100644
> --- a/drivers/net/ethernet/intel/igbvf/netdev.c
> +++ b/drivers/net/ethernet/intel/igbvf/netdev.c
> @@ -2342,7 +2342,7 @@ static struct net_device_stats *igbvf_get_stats(struct net_device *netdev)
> static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
> {
> struct igbvf_adapter *adapter = netdev_priv(netdev);
> - int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> + unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
>
> if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
> dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
It is safer to check:
if ((new_mtu < 68) || (new_mtu > MAX_JUMBO_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)) {
David
^ permalink raw reply
* Re: [PATCH] net: smsc: remove deprecated IRQF_DISABLED
From: Will Deacon @ 2013-09-13 8:56 UTC (permalink / raw)
To: Michael Opdenacker
Cc: steve.glendinning@shawell.net, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, davidb
In-Reply-To: <1379046467-6900-1-git-send-email-michael.opdenacker@free-electrons.com>
[adding David Brown]
On Fri, Sep 13, 2013 at 05:27:47AM +0100, Michael Opdenacker wrote:
> This patch proposes to remove the IRQF_DISABLED flag from
> code in drivers/net/ethernet/smsc/
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
> ---
> drivers/net/ethernet/smsc/smc91x.h | 2 +-
> drivers/net/ethernet/smsc/smsc9420.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
> index 370e13d..5730fe2 100644
> --- a/drivers/net/ethernet/smsc/smc91x.h
> +++ b/drivers/net/ethernet/smsc/smc91x.h
> @@ -271,7 +271,7 @@ static inline void mcf_outsw(void *a, unsigned char *p, int l)
> #define SMC_insw(a, r, p, l) mcf_insw(a + r, p, l)
> #define SMC_outsw(a, r, p, l) mcf_outsw(a + r, p, l)
>
> -#define SMC_IRQ_FLAGS (IRQF_DISABLED)
> +#define SMC_IRQ_FLAGS 0
After this change, the only machine that defines the flags to anything other
than IRQF_TRIGGER_RISING is MSM, which uses IRQF_TRIGGER_HIGH. David: do
you actually need this? The irq_chip code under mach-msm doesn't seem to
distinguish between the two.
Will
^ permalink raw reply
* Re: [PATCH 4/7] ptp: switch to use gpiolib
From: Linus Walleij @ 2013-09-13 8:38 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-gpio@vger.kernel.org, Imre Kaloz, Krzysztof Halasa,
Alexandre Courbot, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org
In-Reply-To: <20130910141912.GB5088@netboy>
On Tue, Sep 10, 2013 at 4:19 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 02:31:00PM +0200, Linus Walleij wrote:
>> Hi Richard, I'm seeking an ACK on this patch to take it throug
>> the GPIO tree as part of a clean-out of custom GPIO implementations.
>
> I don't have this hardware for testing (it is really obsolete now),
> but the change looks okay to me.
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
Thanks, I have found numerous active hobbyists using the
IXP4-based NSLU2 NAS machine for various things - mostly
non-network related as it happens, so it'll be with us for a
while I think.
Yours,
Linus Walleij
^ permalink raw reply
* [patch -stable] igbvf: integer wrapping bug setting the mtu
From: Dan Carpenter @ 2013-09-13 8:37 UTC (permalink / raw)
To: Jeff Kirsher
Cc: kernel-janitors, netdev, Patrick McHardy, e1000-devel,
Bruce Allan, Jesse Brandeburg, David S. Miller, John Ronciak,
Greg Kroah-Hartman
If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
wrap and the check on the next line can underflow. This is one of those
bugs which can be triggered by the user if you have namespaces
configured.
This is a static checker fix and I'm not sure what the impact is.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 95d5430..24e3883 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2342,7 +2342,7 @@ static struct net_device_stats *igbvf_get_stats(struct net_device *netdev)
static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
{
struct igbvf_adapter *adapter = netdev_priv(netdev);
- int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
+ unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
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