* Re: [PATCH 4/4 v3] net/smsc911x: Provide common clock functionality
From: David Miller @ 2013-01-17 19:36 UTC (permalink / raw)
To: lee.jones
Cc: linux, steve.glendinning, robert.marklund, linus.walleij, arnd,
netdev, linux-kernel, linux-arm-kernel, linus.walleij
In-Reply-To: <20130117104744.GP20091@gmail.com>
From: Lee Jones <lee.jones@linaro.org>
Date: Thu, 17 Jan 2013 10:47:44 +0000
> https://patchwork.kernel.org/patch/1926971/
I'm fine with this:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH] net: usb: initialize tmp in dm9601.c to avoid warning
From: Simon Que @ 2013-01-17 19:29 UTC (permalink / raw)
To: jacmet, netdev; +Cc: msb, Simon Que
In two places, tmp is initialized implicitly by being passed as a
pointer during a function call. However, this is not obvious to the
compiler, which logs a warning.
Signed-off-by: Simon Que <sque@chromium.org>
---
drivers/net/usb/dm9601.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
index e0433ce..94e716d 100644
--- a/drivers/net/usb/dm9601.c
+++ b/drivers/net/usb/dm9601.c
@@ -199,7 +199,7 @@ static int dm_read_shared_word(struct usbnet *dev, int phy, u8 reg, __le16 *valu
dm_write_reg(dev, DM_SHARED_CTRL, phy ? 0xc : 0x4);
for (i = 0; i < DM_TIMEOUT; i++) {
- u8 tmp;
+ u8 tmp = 0;
udelay(1);
ret = dm_read_reg(dev, DM_SHARED_CTRL, &tmp);
@@ -242,7 +242,7 @@ static int dm_write_shared_word(struct usbnet *dev, int phy, u8 reg, __le16 valu
dm_write_reg(dev, DM_SHARED_CTRL, phy ? 0x1a : 0x12);
for (i = 0; i < DM_TIMEOUT; i++) {
- u8 tmp;
+ u8 tmp = 0;
udelay(1);
ret = dm_read_reg(dev, DM_SHARED_CTRL, &tmp);
--
1.7.8.6
^ permalink raw reply related
* Re: pull request: wireless 2013-01-17
From: David Miller @ 2013-01-17 19:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130117173239.GA2098@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 17 Jan 2013 12:32:40 -0500
> This batch of fixes is intended for 3.8...
>
> Included is a Bluetooth pull. Gustavo says:
>
> "A few fixes for 3.8. Five of them are just new devices ids addition.
> Apart from the that there is fix to a kernel memory leak to userspace from
> Anderson Lizardo, two interoperability fixes from Jaganath Kanakkassery and
> Szymon Janc. And a crash fix by me."
>
> Along with that, Amitkumar Karwar brings a pair of mwifiex fixes for
> problems related to handling of band information within the driver.
> These problems can lead to association failures.
>
> Sujith Manoharan fixes a memory leak in the ath9k_htc code (originally
> reported by Larry Finger).
>
> The big hero this round is Felix Fietkau. Felix gives us seven
> ath9k fixes, including a fix for a race condition, the removal of a
> double-free, and a fix for a deadlock, among others.
>
> These have all been in linux-next for at least a couple of days,
> with no complaints so far. Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: fix GRO parameters
From: David Miller @ 2013-01-17 19:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: yuvalmin, netdev, eilong, ariele
In-Reply-To: <1358433181.29723.16.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 17 Jan 2013 06:33:01 -0800
> On Thu, 2013-01-17 at 15:26 +0200, Yuval Mintz wrote:
>> bnx2x does an internal GRO pass but doesn't provide gso_segs, thus
>> breaking qdisc_pkt_len_init() in case ingress qdisc is used.
>>
>> We store gso_segs in NAPI_GRO_CB(skb)->count, where tcp_gro_complete()
>> expects to find the number of aggregated segments.
>>
>> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
>> ---
>> This is Eric Dumazet's patch with slight semantic modifications.
>> Eric - Do you want to put your ack or signoff on this patch?
>>
>
> Sure, thanks !
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
>> Dave - Please apply this to 'net-next' afterwards.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] 3c574_cs: fix operator precedence between << and &
From: David Miller @ 2013-01-17 20:05 UTC (permalink / raw)
To: nickolai; +Cc: netdev, linux-kernel
In-Reply-To: <1358443109-63402-1-git-send-email-nickolai@csail.mit.edu>
From: Nickolai Zeldovich <nickolai@csail.mit.edu>
Date: Thu, 17 Jan 2013 12:18:29 -0500
> The code to print the FIFO size in tc574_config computes it as:
>
> 8 << config & Ram_size
>
> which evaluates the '<<' first, but the actual intent is to evaluate the
> '&' first. Add parentheses to enforce desired evaluation order.
>
> Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: add anti-spoofing checks for 6to4 and 6rd
From: Hannes Frederic Sowa @ 2013-01-17 20:07 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev
In-Reply-To: <50F81C4B.3050406@linux-ipv6.org>
On Fri, Jan 18, 2013 at 12:44:11AM +0900, YOSHIFUJI Hideaki wrote:
> It seems wrong. Check should be done for
> - inner source prefix
> - embedded source with relay_prefix.
> - inner destination prefix.
>
> Note: embedded destination is not being checked.
I fixed the handling of the embedded IPv4 in case of using 6rd
with prefixlen != 16. I'll investigate on how to easily implement
further address checks without breaking 6in4. I don't know if this is
possible without a further flag on the tunnel interface controlling
source/destination address checking.
[PATCH RFC] ipv6: add anti-spoofing checks for 6to4 and 6rd
This patch adds anti-spoofing checks in sit.c as specified in RFC3964
section 5.2 for 6to4 and RFC5969 section 12 for 6rd. I left out the
checks which could easily be implemented with netfilter.
Specifically this patch adds following logic (based loosely on the
pseudocode in RFC3964 section 5.2):
if prefix (inner_src_v6) == rd6_prefix (2002::/16 is the default)
and outer_src_v4 != embedded_ipv4 (inner_src_v6)
drop
if prefix (inner_dst_v6) == rd6_prefix (or 2002::/16 is the default)
and outer_dst_v4 != embedded_ipv4 (inner_dst_v6)
drop
accept
To accomplish the specified security checks proposed by above RFCs,
it is still necessary to employ uRPF filters with netfilter. These new
checks only kick in if the employed addresses are within the 2002::/16 or
another range specified by the 6rd-prefix (which defaults to 2002::/16).
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/sit.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index cfba99b..7942e81 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -73,6 +73,8 @@ static int ipip6_tunnel_init(struct net_device *dev);
static void ipip6_tunnel_setup(struct net_device *dev);
static void ipip6_dev_free(struct net_device *dev);
static struct rtnl_link_ops sit_link_ops __read_mostly;
+static inline __be32 try_6rd(const struct in6_addr *v6dst,
+ struct ip_tunnel *tunnel);
static int sit_net_id __read_mostly;
struct sit_net {
@@ -590,6 +592,22 @@ out:
return err;
}
+static int sit_chk_encap_addr(struct ip_tunnel *tunnel, const __be32 *addr,
+ const struct in6_addr *addr6)
+{
+#ifdef CONFIG_IPV6_SIT_6RD
+ if (ipv6_prefix_equal(addr6, &tunnel->ip6rd.prefix,
+ tunnel->ip6rd.prefixlen) &&
+ *addr != try_6rd(addr6, tunnel))
+ return 0;
+#else
+ if (addr6->s6_addr16[0] == htons(0x2002) &&
+ *addr != try_6rd(addr6, tunnel))
+ return 0;
+#endif
+ return 1;
+}
+
static int ipip6_rcv(struct sk_buff *skb)
{
const struct iphdr *iph;
@@ -613,8 +631,15 @@ static int ipip6_rcv(struct sk_buff *skb)
skb->protocol = htons(ETH_P_IPV6);
skb->pkt_type = PACKET_HOST;
- if ((tunnel->dev->priv_flags & IFF_ISATAP) &&
- !isatap_chksrc(skb, iph, tunnel)) {
+ if (tunnel->dev->priv_flags & IFF_ISATAP) {
+ if (!isatap_chksrc(skb, iph, tunnel)) {
+ tunnel->dev->stats.rx_errors++;
+ goto out;
+ }
+ } else if (!sit_chk_encap_addr(tunnel, &iph->saddr,
+ &ipv6_hdr(skb)->saddr) ||
+ !sit_chk_encap_addr(tunnel, &iph->daddr,
+ &ipv6_hdr(skb)->daddr)) {
tunnel->dev->stats.rx_errors++;
goto out;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [patch net-next] team: do not use -ENOENT
From: Jiri Pirko @ 2013-01-17 20:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem
In-Reply-To: <20130117075115.731c4cf0@nehalam.linuxnetplumber.net>
Thu, Jan 17, 2013 at 04:51:15PM CET, stephen@networkplumber.org wrote:
>On Thu, 17 Jan 2013 11:25:00 +0100
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Since this error code means "No such file or directory", change this
>> value in team driver to ones which make more sense.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>> drivers/net/team/team.c | 4 ++--
>> drivers/net/team/team_mode_activebackup.c | 2 +-
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
>> index 70d5d6b..3d7cf6e 100644
>> --- a/drivers/net/team/team.c
>> +++ b/drivers/net/team/team.c
>> @@ -1128,7 +1128,7 @@ static int team_port_del(struct team *team, struct net_device *port_dev)
>> if (!port || !team_port_find(team, port)) {
>> netdev_err(dev, "Device %s does not act as a port of this team\n",
>> portname);
>> - return -ENOENT;
>> + return -ENODEV;
>> }
>>
>> __team_option_inst_mark_removed_port(team, port);
>> @@ -2320,7 +2320,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
>> list_add(&opt_inst->tmp_list, &opt_inst_list);
>> }
>> if (!opt_found) {
>> - err = -ENOENT;
>> + err = -EINVAL;
>> goto team_put;
>> }
>> }
>> diff --git a/drivers/net/team/team_mode_activebackup.c b/drivers/net/team/team_mode_activebackup.c
>> index 6262b4d..2792e13 100644
>> --- a/drivers/net/team/team_mode_activebackup.c
>> +++ b/drivers/net/team/team_mode_activebackup.c
>> @@ -81,7 +81,7 @@ static int ab_active_port_set(struct team *team, struct team_gsetter_ctx *ctx)
>> return 0;
>> }
>> }
>> - return -ENOENT;
>> + return -ENODEV;
>> }
>>
>> static const struct team_option ab_options[] = {
>
>To be pedantic.
>Changing errno's means effectively changing the ABI.
>Linus has already rejected similar patches in other areas.
I'm not really sure. But in this case, I do not think that is a problem.
1) I'm most probably the only one (libteam) who is using this api and
libteam does not mind about what err code is returned in these cases.
2) In this case, it is only about different number. And one number or
another, it does not imply userspace to behave differently. In other words,
userspace should not take different actions in case for example -ENOENT
or -ENODEV is returned.
But as I said, I'm not sure.
Thanks
Jiri
^ permalink raw reply
* Re: [PATCH net-next 00/11] IPv6: rt->n (neighbour in rt6_info) removal (TAKE 3)
From: David Miller @ 2013-01-17 20:37 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, xiyou.wangcong
In-Reply-To: <50F837D5.4020505@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Fri, 18 Jan 2013 02:41:41 +0900
> This is "TAKE 3" of neighbour removal from rt6_info.
>
> 2->3:
> - Removed "icmp6_dst_alloc() removal" patch.
> This is nothing to do with this series.
> - Removed several unused variables, ifdefs, BUG_ONs.
> - Handled several comments from Cong Wang.
> - Reordered.
This series is almost perfect, great work.
In ip6_output you need to accomodate the fact that __neigh_create()
returns error pointers so it is not valid to simply use a NULL test on
'neigh'.
You'll need to use IS_ERR(). 'neigh' can never be NULL here, it is
either a valid non-NULL pointer or a return value from
__neigh_create().
^ permalink raw reply
* Re: [patch net-next] team: do not use -ENOENT
From: David Miller @ 2013-01-17 20:42 UTC (permalink / raw)
To: jiri; +Cc: stephen, netdev
In-Reply-To: <20130117203347.GA1591@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 17 Jan 2013 21:33:47 +0100
>>> @@ -2320,7 +2320,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
>>> list_add(&opt_inst->tmp_list, &opt_inst_list);
>>> }
>>> if (!opt_found) {
>>> - err = -ENOENT;
>>> + err = -EINVAL;
>>> goto team_put;
>>> }
>>> }
> I'm not really sure. But in this case, I do not think that is a problem.
>
> 1) I'm most probably the only one (libteam) who is using this api and
> libteam does not mind about what err code is returned in these cases.
>
> 2) In this case, it is only about different number. And one number or
> another, it does not imply userspace to behave differently. In other words,
> userspace should not take different actions in case for example -ENOENT
> or -ENODEV is returned.
I agree with this analysis.
But for the team_nl_cmd_options_set() case, I would strongly advise
that you use some error code more descriptive than -EINVAL. In fact
the existing -ENOENT I feel is better, because it tells the caller
what kind of problem there was.
Even if you don't like the fact that -ENOENT is oriented towards file
existence, it does convey a ton more information than -EINVAL does.
^ permalink raw reply
* Re: [PATCH net-next V1 5/6] net/mlx4_en: Fix a race when closing TX queue
From: David Miller @ 2013-01-17 20:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: amirv, netdev, ogerlitz, yevgenyp, eugenia
In-Reply-To: <1358432538.29723.8.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 17 Jan 2013 06:22:18 -0800
> On Thu, 2013-01-17 at 13:47 +0200, Amir Vadai wrote:
>> There is a possible race where the TX completion handler can clean the
>> entire TX queue between the decision that the queue is full and actually
>> closing it. To avoid this situation, check again if the queue is really
>> full, if not, reopen the transmit and continue with sending the packet.
>>
>> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.com>
>> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 9 ++++++++-
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> index 2b799f4..1d17f5f 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> @@ -592,7 +592,14 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
>> netif_tx_stop_queue(ring->tx_queue);
>> priv->port_stats.queue_stopped++;
>>
>> - return NETDEV_TX_BUSY;
>> + /* Check again whether the queue was cleaned */
>> + if (unlikely(((int)(ring->prod - ring->cons)) <=
>> + ring->size - HEADROOM - MAX_DESC_TXBBS)) {
>> + netif_tx_wake_queue(ring->tx_queue);
>> + priv->port_stats.wake_queue++;
>> + } else {
>> + return NETDEV_TX_BUSY;
>> + }
>> }
>>
>> /* Track current inflight packets for performance analysis */
>
> This looks racy to me. You probably want explicit memory barriers ?
The conditional is also not formatted correctly.
^ permalink raw reply
* Re: [PATCH] net/xfrm/xfrm_replay: avoid division by zero
From: David Miller @ 2013-01-17 20:46 UTC (permalink / raw)
To: nickolai; +Cc: steffen.klassert, herbert, netdev, linux-kernel
In-Reply-To: <1358449108-67839-1-git-send-email-nickolai@csail.mit.edu>
From: Nickolai Zeldovich <nickolai@csail.mit.edu>
Date: Thu, 17 Jan 2013 13:58:28 -0500
> All of the xfrm_replay->advance functions in xfrm_replay.c check if
> x->replay_esn->replay_window is zero (and return if so). However,
> one of them, xfrm_replay_advance_bmp(), divides by that value (in the
> '%' operator) before doing the check, which can potentially trigger
> a divide-by-zero exception. Some compilers will also assume that the
> earlier division means the value cannot be zero later, and thus will
> eliminate the subsequent zero check as dead code.
>
> This patch moves the division to after the check.
>
> Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
I'm assuming Steffen will take care of this patch.
^ permalink raw reply
* Re: [PATCH 1/1] phy/marvell: remove fiber/copper autoselect on 88e1111
From: David Miller @ 2013-01-17 20:47 UTC (permalink / raw)
To: stef.van.os; +Cc: chohnstaedt, srinivas.kandagatla, netdev, linux-kernel
In-Reply-To: <1358436978-7504-1-git-send-email-stef.van.os@prodrive.nl>
From: Stef van Os <stef.van.os@prodrive.nl>
Date: Thu, 17 Jan 2013 16:36:18 +0100
> Remove the code that always enables copper/fiber autoselect,
> ignoring the DIS_FC strapping pin. The default value for this
> register is autoselect on anyway, and if you explicitly disable
> autoselect via strapping you probably really don't want
> autoselect.
>
> Signed-off-by: Stef van Os <stef.van.os@prodrive.nl>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next] team: do not use -ENOENT
From: Jiri Pirko @ 2013-01-17 20:52 UTC (permalink / raw)
To: David Miller; +Cc: stephen, netdev
In-Reply-To: <20130117.154240.1134435647038964241.davem@davemloft.net>
Thu, Jan 17, 2013 at 09:42:40PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Thu, 17 Jan 2013 21:33:47 +0100
>
>>>> @@ -2320,7 +2320,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
>>>> list_add(&opt_inst->tmp_list, &opt_inst_list);
>>>> }
>>>> if (!opt_found) {
>>>> - err = -ENOENT;
>>>> + err = -EINVAL;
>>>> goto team_put;
>>>> }
>>>> }
>
>
>> I'm not really sure. But in this case, I do not think that is a problem.
>>
>> 1) I'm most probably the only one (libteam) who is using this api and
>> libteam does not mind about what err code is returned in these cases.
>>
>> 2) In this case, it is only about different number. And one number or
>> another, it does not imply userspace to behave differently. In other words,
>> userspace should not take different actions in case for example -ENOENT
>> or -ENODEV is returned.
>
>I agree with this analysis.
>
>But for the team_nl_cmd_options_set() case, I would strongly advise
>that you use some error code more descriptive than -EINVAL. In fact
>the existing -ENOENT I feel is better, because it tells the caller
>what kind of problem there was.
>
>Even if you don't like the fact that -ENOENT is oriented towards file
>existence, it does convey a ton more information than -EINVAL does.
I understand your feeling, because I have the same one :)
But looking all over the code and on possible err codes as well, I did
not find any suitable err code to indicate some object was not found.
And since I recently saw email from Linus about the fact that -ENOENT
should be used only in relation to files, -EINVAL the "default:" in my
"switch()".
^ permalink raw reply
* Re: [patch net-next] team: do not use -ENOENT
From: David Miller @ 2013-01-17 21:07 UTC (permalink / raw)
To: jiri; +Cc: stephen, netdev
In-Reply-To: <20130117205212.GB1591@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 17 Jan 2013 21:52:12 +0100
> Thu, Jan 17, 2013 at 09:42:40PM CET, davem@davemloft.net wrote:
>>From: Jiri Pirko <jiri@resnulli.us>
>>Date: Thu, 17 Jan 2013 21:33:47 +0100
>>
>>>>> @@ -2320,7 +2320,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
>>>>> list_add(&opt_inst->tmp_list, &opt_inst_list);
>>>>> }
>>>>> if (!opt_found) {
>>>>> - err = -ENOENT;
>>>>> + err = -EINVAL;
>>>>> goto team_put;
>>>>> }
>>>>> }
>>
>>
>>> I'm not really sure. But in this case, I do not think that is a problem.
>>>
>>> 1) I'm most probably the only one (libteam) who is using this api and
>>> libteam does not mind about what err code is returned in these cases.
>>>
>>> 2) In this case, it is only about different number. And one number or
>>> another, it does not imply userspace to behave differently. In other words,
>>> userspace should not take different actions in case for example -ENOENT
>>> or -ENODEV is returned.
>>
>>I agree with this analysis.
>>
>>But for the team_nl_cmd_options_set() case, I would strongly advise
>>that you use some error code more descriptive than -EINVAL. In fact
>>the existing -ENOENT I feel is better, because it tells the caller
>>what kind of problem there was.
>>
>>Even if you don't like the fact that -ENOENT is oriented towards file
>>existence, it does convey a ton more information than -EINVAL does.
>
> I understand your feeling, because I have the same one :)
> But looking all over the code and on possible err codes as well, I did
> not find any suitable err code to indicate some object was not found.
> And since I recently saw email from Linus about the fact that -ENOENT
> should be used only in relation to files, -EINVAL the "default:" in my
> "switch()".
Look in the packet scheduler API for how much we use -ENOENT in this
kind of situation where the requested object to operate on could not
be found.
I think it is entirely appropriate to use -ENOENT, if not completely
consistent with the rest of the networking.
^ permalink raw reply
* Re: [patch net-next] team: do not use -ENOENT
From: Jiri Pirko @ 2013-01-17 21:15 UTC (permalink / raw)
To: David Miller; +Cc: stephen, netdev
In-Reply-To: <20130117.160742.614484345035625041.davem@davemloft.net>
Thu, Jan 17, 2013 at 10:07:42PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Thu, 17 Jan 2013 21:52:12 +0100
>
>> Thu, Jan 17, 2013 at 09:42:40PM CET, davem@davemloft.net wrote:
>>>From: Jiri Pirko <jiri@resnulli.us>
>>>Date: Thu, 17 Jan 2013 21:33:47 +0100
>>>
>>>>>> @@ -2320,7 +2320,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
>>>>>> list_add(&opt_inst->tmp_list, &opt_inst_list);
>>>>>> }
>>>>>> if (!opt_found) {
>>>>>> - err = -ENOENT;
>>>>>> + err = -EINVAL;
>>>>>> goto team_put;
>>>>>> }
>>>>>> }
>>>
>>>
>>>> I'm not really sure. But in this case, I do not think that is a problem.
>>>>
>>>> 1) I'm most probably the only one (libteam) who is using this api and
>>>> libteam does not mind about what err code is returned in these cases.
>>>>
>>>> 2) In this case, it is only about different number. And one number or
>>>> another, it does not imply userspace to behave differently. In other words,
>>>> userspace should not take different actions in case for example -ENOENT
>>>> or -ENODEV is returned.
>>>
>>>I agree with this analysis.
>>>
>>>But for the team_nl_cmd_options_set() case, I would strongly advise
>>>that you use some error code more descriptive than -EINVAL. In fact
>>>the existing -ENOENT I feel is better, because it tells the caller
>>>what kind of problem there was.
>>>
>>>Even if you don't like the fact that -ENOENT is oriented towards file
>>>existence, it does convey a ton more information than -EINVAL does.
>>
>> I understand your feeling, because I have the same one :)
>> But looking all over the code and on possible err codes as well, I did
>> not find any suitable err code to indicate some object was not found.
>> And since I recently saw email from Linus about the fact that -ENOENT
>> should be used only in relation to files, -EINVAL the "default:" in my
>> "switch()".
>
>Look in the packet scheduler API for how much we use -ENOENT in this
>kind of situation where the requested object to operate on could not
>be found.
>
>I think it is entirely appropriate to use -ENOENT, if not completely
>consistent with the rest of the networking.
Okay, fair enough. In that case, I believe that also the other 2
occurrences of -ENOENT in team driver are ok as well. Please scratch this
patch.
Thanks!
^ permalink raw reply
* [PATCH] sctp: refactor sctp_outq_teardown to insure proper re-initalization
From: Neil Horman @ 2013-01-17 21:15 UTC (permalink / raw)
To: linux-sctp
Cc: Neil Horman, Jamie Parsons, Vlad Yasevich, David S. Miller,
netdev
Jamie Parsons reported a problem recently, in which the re-initalization of an
association (The duplicate init case), resulted in a loss of receive window
space. He tracked down the root cause to sctp_outq_teardown, which discarded
all the data on an outq during a re-initalization of the corresponding
association, but never reset the outq->outstanding_data field to zero. I wrote,
and he tested this fix, which does a proper full re-initalization of the outq,
fixing this problem, and hopefully future proofing us from simmilar issues down
the road.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
Tested-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
CC: Jamie Parsons <Jamie.Parsons@metaswitch.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: netdev@vger.kernel.org
---
net/sctp/outqueue.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 379c81d..9bcdbd0 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -224,7 +224,7 @@ void sctp_outq_init(struct sctp_association *asoc, struct sctp_outq *q)
/* Free the outqueue structure and any related pending chunks.
*/
-void sctp_outq_teardown(struct sctp_outq *q)
+static void __sctp_outq_teardown(struct sctp_outq *q)
{
struct sctp_transport *transport;
struct list_head *lchunk, *temp;
@@ -277,8 +277,6 @@ void sctp_outq_teardown(struct sctp_outq *q)
sctp_chunk_free(chunk);
}
- q->error = 0;
-
/* Throw away any leftover control chunks. */
list_for_each_entry_safe(chunk, tmp, &q->control_chunk_list, list) {
list_del_init(&chunk->list);
@@ -286,11 +284,17 @@ void sctp_outq_teardown(struct sctp_outq *q)
}
}
+void sctp_outq_teardown(struct sctp_outq *q)
+{
+ __sctp_outq_teardown(q);
+ sctp_outq_init(q->asoc, q);
+}
+
/* Free the outqueue structure and any related pending chunks. */
void sctp_outq_free(struct sctp_outq *q)
{
/* Throw away leftover chunks. */
- sctp_outq_teardown(q);
+ __sctp_outq_teardown(q);
/* If we were kmalloc()'d, free the memory. */
if (q->malloced)
--
1.7.11.7
^ permalink raw reply related
* Re: [patch net-next] team: do not use -ENOENT
From: David Miller @ 2013-01-17 21:18 UTC (permalink / raw)
To: jiri; +Cc: stephen, netdev
In-Reply-To: <20130117211532.GC1591@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 17 Jan 2013 22:15:32 +0100
> Okay, fair enough. In that case, I believe that also the other 2
> occurrences of -ENOENT in team driver are ok as well. Please scratch this
> patch.
Ok.
> Thanks!
No problem.
^ permalink raw reply
* [PATCH] macvlan: fix macvlan_get_size()
From: Eric Dumazet @ 2013-01-17 21:30 UTC (permalink / raw)
To: David Miller; +Cc: greearb, netdev, John Fastabend
In-Reply-To: <20130116.011120.2166745757980086775.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
commit df8ef8f3aaa (macvlan: add FDB bridge ops and macvlan flags)
forgot to update macvlan_get_size() after the addition of
IFLA_MACVLAN_FLAGS
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: John Fastabend <john.r.fastabend@intel.com>
---
drivers/net/macvlan.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 1047e58..7b44ebd 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -828,7 +828,10 @@ static int macvlan_changelink(struct net_device *dev,
static size_t macvlan_get_size(const struct net_device *dev)
{
- return nla_total_size(4);
+ return (0
+ + nla_total_size(4) /* IFLA_MACVLAN_MODE */
+ + nla_total_size(2) /* IFLA_MACVLAN_FLAGS */
+ );
}
static int macvlan_fill_info(struct sk_buff *skb,
^ permalink raw reply related
* Re: [PATCH] macvlan: fix macvlan_get_size()
From: David Miller @ 2013-01-17 21:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: greearb, netdev, john.r.fastabend
In-Reply-To: <1358458249.11051.6.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 17 Jan 2013 13:30:49 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> commit df8ef8f3aaa (macvlan: add FDB bridge ops and macvlan flags)
> forgot to update macvlan_get_size() after the addition of
> IFLA_MACVLAN_FLAGS
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: John Fastabend <john.r.fastabend@intel.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] {cfg,mac}80211.h: fix some kernel-doc warnings
From: Yacine Belkadi @ 2013-01-17 22:13 UTC (permalink / raw)
To: Johannes Berg
Cc: David S. Miller, linux-wireless, netdev, linux-doc, linux-kernel,
yacine.belkadi.1
In-Reply-To: <1358345501.22862.10.camel@jlt4.sipsolutions.net>
Hi,
On 01/16/2013 03:11 PM, Johannes Berg wrote:
> Hi,
>
> I totally missed your email before.
>
>> Warning(include/net/cfg80211.h:334): No description found for return value of 'cfg80211_get_chandef_type'
>>
>> These warnings are only reported when scripts/kernel-doc runs in verbose mode.
>>
>> Fix:
>> In comments, use "Return:" to describe function return values.
>
> I wasn't even aware of this, is that new? Anyway, applied, thanks.
Yes, it's from December.
Here is the last thread: https://lkml.org/lkml/2012/11/26/709
Yacine
^ permalink raw reply
* [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
From: Peter Korsgaard @ 2013-01-17 22:18 UTC (permalink / raw)
To: linux-omap, netdev, devicetree-discuss, mugunthanvnm, hvaibhav,
richardcochran, tony, michal.bachraty
Cc: Peter Korsgaard
When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
mode in U-Boot), nothing updates the ethernet hwaddr specified for the
CPSW slaves, causing the driver to use a random hwaddr, which is some times
troublesome.
The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
more sense to default to these rather than random ones. Add a fixup step
which adds mac-address dt properties using the efuse addresses if the DTB
didn't contain valid ones.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
Changes since v1:
- Use omap_arch_initcall as pointed out by Tony
arch/arm/mach-omap2/Makefile | 3 ++
arch/arm/mach-omap2/am33xx-cpsw.c | 94 +++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/control.h | 4 ++
3 files changed, 101 insertions(+)
create mode 100644 arch/arm/mach-omap2/am33xx-cpsw.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 65fb6fb..54fb2ee 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -298,4 +298,7 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
+cpsw-$(CONFIG_TI_CPSW) := am33xx-cpsw.o
+obj-y += $(cpsw-m) $(cpsw-y)
+
obj-y += common-board-devices.o twl-common.o dss-common.o
diff --git a/arch/arm/mach-omap2/am33xx-cpsw.c b/arch/arm/mach-omap2/am33xx-cpsw.c
new file mode 100644
index 0000000..eec29a4
--- /dev/null
+++ b/arch/arm/mach-omap2/am33xx-cpsw.c
@@ -0,0 +1,94 @@
+/*
+ * am335x specific cpsw dt fixups
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/etherdevice.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
+
+#include "soc.h"
+#include "control.h"
+
+/**
+ * am33xx_dt_cpsw_set_mac_from_efuse - Add mac-address property using
+ * ethernet hwaddr from efuse
+ * @np: Pointer to the cpsw slave to set mac address of
+ * @idx: Mac address index to use from efuse
+ */
+static void am33xx_dt_cpsw_set_mac_from_efuse(struct device_node *np, int idx)
+{
+ struct property *prop;
+ u32 lo, hi;
+ u8 *mac;
+
+ switch (idx) {
+ case 0:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_HIGH);
+ break;
+
+ case 1:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_HIGH);
+ break;
+
+ default:
+ pr_err("cpsw.%d: too many slaves found\n", idx);
+ return;
+ }
+
+ prop = kzalloc(sizeof(*prop) + ETH_ALEN, GFP_KERNEL);
+ if (!prop)
+ return;
+
+ prop->value = prop + 1;
+ prop->length = ETH_ALEN;
+ prop->name = kstrdup("mac-address", GFP_KERNEL);
+ if (!prop->name) {
+ kfree(prop);
+ return;
+ }
+
+ mac = prop->value;
+
+ mac[0] = hi;
+ mac[1] = hi >> 8;
+ mac[2] = hi >> 16;
+ mac[3] = hi >> 24;
+ mac[4] = lo;
+ mac[5] = lo >> 8;
+
+ of_update_property(np, prop);
+
+ pr_info("cpsw.%d: No hwaddr in dt. Using %pM from efuse\n", idx, mac);
+}
+
+static int __init am33xx_dt_cpsw_mac_fixup(void)
+{
+ struct device_node *np, *slave;
+ int idx = 0;
+
+ if (!soc_is_am33xx())
+ return -ENODEV;
+
+ for_each_compatible_node(np, NULL, "ti,cpsw")
+ for_each_node_by_name(slave, "slave") {
+ if (!of_get_mac_address(slave))
+ am33xx_dt_cpsw_set_mac_from_efuse(slave, idx);
+ idx++;
+ }
+
+ return 0;
+}
+omap_arch_initcall(am33xx_dt_cpsw_mac_fixup);
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..266d512 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -352,6 +352,10 @@
/* AM33XX CONTROL_STATUS register */
#define AM33XX_CONTROL_STATUS 0x040
#define AM33XX_CONTROL_SEC_CLK_CTRL 0x1bc
+#define AM33XX_CONTROL_MAC_ID0_LOW 0x630
+#define AM33XX_CONTROL_MAC_ID0_HIGH 0x634
+#define AM33XX_CONTROL_MAC_ID1_LOW 0x638
+#define AM33XX_CONTROL_MAC_ID1_HIGH 0x63c
/* AM33XX CONTROL_STATUS bitfields (partial) */
#define AM33XX_CONTROL_STATUS_SYSBOOT1_SHIFT 22
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net-next 00/11] IPv6: rt->n (neighbour in rt6_info) removal (TAKE 3)
From: Dave Jones @ 2013-01-17 22:42 UTC (permalink / raw)
To: David Miller; +Cc: yoshfuji, netdev, xiyou.wangcong
In-Reply-To: <20130117.153753.1608817353719202851.davem@davemloft.net>
On Thu, Jan 17, 2013 at 03:37:53PM -0500, David Miller wrote:
> From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Date: Fri, 18 Jan 2013 02:41:41 +0900
>
> > This is "TAKE 3" of neighbour removal from rt6_info.
> >
> > 2->3:
> > - Removed "icmp6_dst_alloc() removal" patch.
> > This is nothing to do with this series.
> > - Removed several unused variables, ifdefs, BUG_ONs.
> > - Handled several comments from Cong Wang.
> > - Reordered.
>
> This series is almost perfect, great work.
I guess if this is going in soon, the ip6 rt->n related oops I reported
this morning is moot ? (unless anyone cares about fixing it for older kernels)
Dave
^ permalink raw reply
* Re: [PATCH] net: usb: initialize tmp in dm9601.c to avoid warning
From: Peter Korsgaard @ 2013-01-17 22:47 UTC (permalink / raw)
To: Simon Que; +Cc: netdev, msb
In-Reply-To: <1358450989-25205-1-git-send-email-sque@chromium.org>
>>>>> "Simon" == Simon Que <sque@chromium.org> writes:
Simon> In two places, tmp is initialized implicitly by being passed as a
Simon> pointer during a function call. However, this is not obvious to the
Simon> compiler, which logs a warning.
What warning and what compiler version are you using?
Simon> Signed-off-by: Simon Que <sque@chromium.org>
Simon> ---
Simon> drivers/net/usb/dm9601.c | 4 ++--
Simon> 1 files changed, 2 insertions(+), 2 deletions(-)
Simon> diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
Simon> index e0433ce..94e716d 100644
Simon> --- a/drivers/net/usb/dm9601.c
Simon> +++ b/drivers/net/usb/dm9601.c
Simon> @@ -199,7 +199,7 @@ static int dm_read_shared_word(struct usbnet *dev, int phy, u8 reg, __le16 *valu
Simon> dm_write_reg(dev, DM_SHARED_CTRL, phy ? 0xc : 0x4);
Simon> for (i = 0; i < DM_TIMEOUT; i++) {
Simon> - u8 tmp;
Simon> + u8 tmp = 0;
Simon> udelay(1);
Simon> ret = dm_read_reg(dev, DM_SHARED_CTRL, &tmp);
Simon> @@ -242,7 +242,7 @@ static int dm_write_shared_word(struct usbnet *dev, int phy, u8 reg, __le16 valu
Simon> dm_write_reg(dev, DM_SHARED_CTRL, phy ? 0x1a : 0x12);
Simon> for (i = 0; i < DM_TIMEOUT; i++) {
Simon> - u8 tmp;
Simon> + u8 tmp = 0;
Simon> udelay(1);
Simon> ret = dm_read_reg(dev, DM_SHARED_CTRL, &tmp);
Simon> --
Simon> 1.7.8.6
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] sctp: refactor sctp_outq_teardown to insure proper re-initalization
From: Vlad Yasevich @ 2013-01-17 22:48 UTC (permalink / raw)
To: Neil Horman; +Cc: linux-sctp, Jamie Parsons, David S. Miller, netdev
In-Reply-To: <1358457308-6407-1-git-send-email-nhorman@tuxdriver.com>
On 01/17/2013 04:15 PM, Neil Horman wrote:
> Jamie Parsons reported a problem recently, in which the re-initalization of an
> association (The duplicate init case), resulted in a loss of receive window
> space. He tracked down the root cause to sctp_outq_teardown, which discarded
> all the data on an outq during a re-initalization of the corresponding
> association, but never reset the outq->outstanding_data field to zero. I wrote,
> and he tested this fix, which does a proper full re-initalization of the outq,
> fixing this problem, and hopefully future proofing us from simmilar issues down
> the road.
>
Good find.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
> Tested-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
> CC: Jamie Parsons <Jamie.Parsons@metaswitch.com>
> CC: Vlad Yasevich <vyasevich@gmail.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: netdev@vger.kernel.org
> ---
> net/sctp/outqueue.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 379c81d..9bcdbd0 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -224,7 +224,7 @@ void sctp_outq_init(struct sctp_association *asoc, struct sctp_outq *q)
>
> /* Free the outqueue structure and any related pending chunks.
> */
> -void sctp_outq_teardown(struct sctp_outq *q)
> +static void __sctp_outq_teardown(struct sctp_outq *q)
> {
> struct sctp_transport *transport;
> struct list_head *lchunk, *temp;
> @@ -277,8 +277,6 @@ void sctp_outq_teardown(struct sctp_outq *q)
> sctp_chunk_free(chunk);
> }
>
> - q->error = 0;
> -
> /* Throw away any leftover control chunks. */
> list_for_each_entry_safe(chunk, tmp, &q->control_chunk_list, list) {
> list_del_init(&chunk->list);
> @@ -286,11 +284,17 @@ void sctp_outq_teardown(struct sctp_outq *q)
> }
> }
>
> +void sctp_outq_teardown(struct sctp_outq *q)
> +{
> + __sctp_outq_teardown(q);
> + sctp_outq_init(q->asoc, q);
> +}
> +
> /* Free the outqueue structure and any related pending chunks. */
> void sctp_outq_free(struct sctp_outq *q)
> {
> /* Throw away leftover chunks. */
> - sctp_outq_teardown(q);
> + __sctp_outq_teardown(q);
>
> /* If we were kmalloc()'d, free the memory. */
> if (q->malloced)
>
^ permalink raw reply
* [PATCH net-next (V4) 00/11] IPv6: rt->n (neighbour in rt6_info) removal, TAKE 4.
From: YOSHIFUJI Hideaki @ 2013-01-17 22:52 UTC (permalink / raw)
To: davem, netdev; +Cc: yoshfuji, xiyou.wangcong
This is "TAKE 4" of neighbour removal from rt6_info.
3->4:
- error check in ip6_finish_output2(), in 10/11.
---
YOSHIFUJI Hideaki (11):
ndisc: Update neigh->updated with write lock.
ndisc: Remove tbl argument for __ipv6_neigh_lookup().
ipv6 route: Dump gateway based on RTF_GATEWAY flag and
rt->rt6i_gateway.
ndisc: Introduce __ipv6_neigh_lookup_noref().
ipv6: Do not depend on rt->n in ip6_pol_route().
ipv6: Do not depend on rt->n in rt6_check_neigh().
ipv6: Do not depend on rt->n in rt6_probe().
ipv6: Introduce rt6_nexthop() to select nexthop address.
ipv6: Do not depend on rt->n in ip6_dst_lookup_tail().
ipv6: Do not depend on rt->n in ip6_finish_output2().
ipv6: Complete neighbour entry removal from dst_entry.
include/net/ip6_fib.h | 2 -
include/net/ip6_route.h | 8 +++
include/net/ndisc.h | 24 ++++++---
net/ipv6/ip6_output.c | 26 ++++++---
net/ipv6/route.c | 138 ++++++++++++-----------------------------------
net/ipv6/xfrm6_policy.c | 1 -
6 files changed, 76 insertions(+), 123 deletions(-)
--
1.7.9.5
^ 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