* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: Ben Hutchings @ 2014-10-21 19:32 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: David Miller, stable, netdev, hannes
In-Reply-To: <5446AF2A.1030508@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
On Tue, 2014-10-21 at 17:08 -0200, Marcelo Ricardo Leitner wrote:
> On 20-10-2014 01:09, Ben Hutchings wrote:
> > On Mon, 2014-10-13 at 13:51 -0400, David Miller wrote:
> >> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >> Date: Mon, 13 Oct 2014 14:03:30 -0300
> >>
> >>> Further tests revealed that after moving the garbage collector to a work
> >>> queue and protecting it with a spinlock may leave the system prone to
> >>> soft lockups if bottom half gets very busy.
> >>>
> >>> It was reproced with a set of firewall rules that REJECTed packets. If
> >>> the NIC bottom half handler ends up running on the same CPU that is
> >>> running the garbage collector on a very large cache, the garbage
> >>> collector will not be able to do its job due to the amount of work
> >>> needed for handling the REJECTs and also won't reschedule.
> >>>
> >>> The fix is to disable bottom half during the garbage collecting, as it
> >>> already was in the first place (most calls to it came from softirqs).
> >>>
> >>> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> >>> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> >>> Acked-by: David S. Miller <davem@davemloft.net>
> >>> Cc: stable@vger.kernel.org
> >>
> >> -stable folks, please integrate this directly, thanks!
> >
> > I've appplied this and the previous two patches mentioned ('ipv4: move
> > route garbage collector to work queue' and 'ipv4: avoid parallel route
> > cache gc executions'). But I didn't get the other two from you. The
> > last batch of networking fixes I received and applied was dated
> > 2014-08-07, and the next one I've seen is dated 2014-10-11 and has
> > nothing for 3.2 or 3.4. Did I miss one between these?
>
> Sorry to ask Ben but, where did you apply them? I'm not seeing the commits on
> linux-stable.git and couldn't find their summaries anywhere else.
They're in a patch queue that I've just pushed to:
git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git
Ben.
--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Hannes Frederic Sowa @ 2014-10-21 19:45 UTC (permalink / raw)
To: Erik Kline; +Cc: netdev, ben, lorenzo
In-Reply-To: <1413864306-20055-1-git-send-email-ek@google.com>
Hi,
On Di, 2014-10-21 at 13:05 +0900, Erik Kline wrote:
> Add a sysctl that causes an interface's optimistic addresses
> to be considered equivalent to other non-deprecated addresses
> for source address selection purposes. Preferred addresses
> will still take precedence over optimistic addresses, subject
> to other ranking in the source address selection algorithm.
>
> This is useful where different interfaces are connected to
> different networks from different ISPs (e.g., a cell network
> and a home wifi network).
>
> The current behaviour complies with RFC 3484/6724, and it
> makes sense if the host has only one interface, or has
> multiple interfaces on the same network (same or cooperating
> administrative domain(s), but not in the multiple distinct
> networks case.
>
> For example, if a mobile device has an IPv6 address on an LTE
> network and then connects to IPv6-enabled wifi, while the wifi
> IPv6 address is undergoing DAD, IPv6 connections will try use
> the wifi default route with the LTE IPv6 address, and will get
> stuck until they time out.
>
> Also, because optimistic addresses can actually be used, issue
> an RTM_NEWADDR as soon as DAD starts. If DAD fails an separate
> RTM_DELADDR will be sent.
>
> Also: add an entry in ip-sysctl.txt for optimistic_dad.
>
> Signed-off-by: Erik Kline <ek@google.com>
> ---
> Documentation/networking/ip-sysctl.txt | 13 ++++++++++++
> include/linux/ipv6.h | 1 +
> include/uapi/linux/ipv6.h | 1 +
> net/ipv6/addrconf.c | 36 ++++++++++++++++++++++++++++++++--
> 4 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index 0307e28..e03cf49 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1452,6 +1452,19 @@ suppress_frag_ndisc - INTEGER
> 1 - (default) discard fragmented neighbor discovery packets
> 0 - allow fragmented neighbor discovery packets
>
> +optimistic_dad - BOOLEAN
> + Whether to perform Optimistic Duplicate Address Detection (RFC 4429).
> + 0: disabled (default)
> + 1: enabled
> +
> +use_optimistic - BOOLEAN
> + If enabled, do not classify optimistic addresses as deprecated during
> + source address selection. Preferred addresses will still be chosen
> + before optimistic addresses, subject to other ranking in the source
> + address selection algorithm.
> + 0: disabled (default)
> + 1: enabled
> +
> icmp/*:
> ratelimit - INTEGER
> Limit the maximal rates for sending ICMPv6 packets.
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index ff56053..7121a2e 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -42,6 +42,7 @@ struct ipv6_devconf {
> __s32 accept_ra_from_local;
> #ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> __s32 optimistic_dad;
> + __s32 use_optimistic;
> #endif
> #ifdef CONFIG_IPV6_MROUTE
> __s32 mc_forwarding;
> diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> index efa2666..e863d08 100644
> --- a/include/uapi/linux/ipv6.h
> +++ b/include/uapi/linux/ipv6.h
> @@ -164,6 +164,7 @@ enum {
> DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL,
> DEVCONF_SUPPRESS_FRAG_NDISC,
> DEVCONF_ACCEPT_RA_FROM_LOCAL,
> + DEVCONF_USE_OPTIMISTIC,
> DEVCONF_MAX
> };
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 725c763..c2fddb7 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1169,6 +1169,9 @@ enum {
> IPV6_SADDR_RULE_LABEL,
> IPV6_SADDR_RULE_PRIVACY,
> IPV6_SADDR_RULE_ORCHID,
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + IPV6_SADDR_RULE_NOT_OPTIMISTIC,
> +#endif
> IPV6_SADDR_RULE_PREFIX,
> IPV6_SADDR_RULE_MAX
> };
> @@ -1257,10 +1260,17 @@ static int ipv6_get_saddr_eval(struct net *net,
> score->scopedist = ret;
> break;
> case IPV6_SADDR_RULE_PREFERRED:
> + {
> /* Rule 3: Avoid deprecated and optimistic addresses */
> + u8 avoid = IFA_F_DEPRECATED;
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + if (!score->ifa->idev->cnf.use_optimistic)
> + avoid |= IFA_F_OPTIMISTIC;
> +#endif
> ret = ipv6_saddr_preferred(score->addr_type) ||
> - !(score->ifa->flags & (IFA_F_DEPRECATED|IFA_F_OPTIMISTIC));
> + !(score->ifa->flags & avoid);
> break;
> + }
> #ifdef CONFIG_IPV6_MIP6
> case IPV6_SADDR_RULE_HOA:
> {
> @@ -1299,6 +1309,14 @@ static int ipv6_get_saddr_eval(struct net *net,
> ret = !(ipv6_addr_orchid(&score->ifa->addr) ^
> ipv6_addr_orchid(dst->addr));
> break;
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + case IPV6_SADDR_RULE_NOT_OPTIMISTIC:
> + /* Optimistic addresses still have lower precedence than other
> + * preferred addresses.
> + */
> + ret = !(score->ifa->flags & IFA_F_OPTIMISTIC);
> + break;
> +#endif
I wonder a bit why this rule is not directly ordered after
IPV6_SADDR_RULE_PREFERRED? This would e.g. matter for privacy addresses.
> case IPV6_SADDR_RULE_PREFIX:
> /* Rule 8: Use longest matching prefix */
> ret = ipv6_addr_diff(&score->ifa->addr, dst->addr);
> @@ -3222,8 +3240,13 @@ static void addrconf_dad_begin(struct inet6_ifaddr *ifp)
> * Optimistic nodes can start receiving
> * Frames right away
> */
> - if (ifp->flags & IFA_F_OPTIMISTIC)
> + if (ifp->flags & IFA_F_OPTIMISTIC) {
> ip6_ins_rt(ifp->rt);
> + /* Because optimistic nodes can receive frames, notify
> + * listeners. If DAD fails, RTM_DELADDR is sent.
> + */
> + ipv6_ifa_notify(RTM_NEWADDR, ifp);
> + }
I wonder if we can now delete the ipv6_ifa_notify(RTM_NEWADDR, ifp) in
addrconf_dad_completed.
> addrconf_dad_kick(ifp);
> out:
> @@ -4330,6 +4353,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
> array[DEVCONF_ACCEPT_SOURCE_ROUTE] = cnf->accept_source_route;
> #ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> array[DEVCONF_OPTIMISTIC_DAD] = cnf->optimistic_dad;
> + array[DEVCONF_USE_OPTIMISTIC] = cnf->use_optimistic;
> #endif
> #ifdef CONFIG_IPV6_MROUTE
> array[DEVCONF_MC_FORWARDING] = cnf->mc_forwarding;
> @@ -5155,6 +5179,14 @@ static struct addrconf_sysctl_table
> .proc_handler = proc_dointvec,
>
> },
> + {
> + .procname = "use_optimistic",
> + .data = &ipv6_devconf.use_optimistic,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> +
> + },
> #endif
> #ifdef CONFIG_IPV6_MROUTE
> {
Otherwise looks good.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH stable v3.2 v3.4] ipv4: disable bh while doing route gc
From: Marcelo Ricardo Leitner @ 2014-10-21 19:51 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, stable, netdev, hannes
In-Reply-To: <1413919971.31953.39.camel@decadent.org.uk>
On 21-10-2014 17:32, Ben Hutchings wrote:
> On Tue, 2014-10-21 at 17:08 -0200, Marcelo Ricardo Leitner wrote:
>> On 20-10-2014 01:09, Ben Hutchings wrote:
>>> On Mon, 2014-10-13 at 13:51 -0400, David Miller wrote:
>>>> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>>> Date: Mon, 13 Oct 2014 14:03:30 -0300
>>>>
>>>>> Further tests revealed that after moving the garbage collector to a work
>>>>> queue and protecting it with a spinlock may leave the system prone to
>>>>> soft lockups if bottom half gets very busy.
>>>>>
>>>>> It was reproced with a set of firewall rules that REJECTed packets. If
>>>>> the NIC bottom half handler ends up running on the same CPU that is
>>>>> running the garbage collector on a very large cache, the garbage
>>>>> collector will not be able to do its job due to the amount of work
>>>>> needed for handling the REJECTs and also won't reschedule.
>>>>>
>>>>> The fix is to disable bottom half during the garbage collecting, as it
>>>>> already was in the first place (most calls to it came from softirqs).
>>>>>
>>>>> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
>>>>> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>>>>> Acked-by: David S. Miller <davem@davemloft.net>
>>>>> Cc: stable@vger.kernel.org
>>>>
>>>> -stable folks, please integrate this directly, thanks!
>>>
>>> I've appplied this and the previous two patches mentioned ('ipv4: move
>>> route garbage collector to work queue' and 'ipv4: avoid parallel route
>>> cache gc executions'). But I didn't get the other two from you. The
>>> last batch of networking fixes I received and applied was dated
>>> 2014-08-07, and the next one I've seen is dated 2014-10-11 and has
>>> nothing for 3.2 or 3.4. Did I miss one between these?
>>
>> Sorry to ask Ben but, where did you apply them? I'm not seeing the commits on
>> linux-stable.git and couldn't find their summaries anywhere else.
>
> They're in a patch queue that I've just pushed to:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git
Cool, thanks!
Marcelo
^ permalink raw reply
* You are receiving this donation newsletter from the PR officer to Margaret Loughrey.
From: Loughrey, Empowerment, Project @ 2014-10-21 19:54 UTC (permalink / raw)
She is a renowned winner of the 27million pound jackpot.You are been informed that three(3) e-mail addresses including yours was recently selected by Google at the request of Margaret Loughrey to receive a $450,000.00USD donation each in the ongoing 2014 Email Donation Project.. Send Name, Country, Age, and Occupation and phone number for details. See my interview
http://www.bbc.com/news/uk-northern-ireland-25178018
http://www.belfasttelegraph.co.uk/news/local-national/northern-ireland/strabanes-27m-euromillions-winner-margaret-loughrey-giving-away-millions-to-help-needy-and-town-30481234.html
Regards,
Mark Worton,
Margaret Loughrey Foudation.
^ permalink raw reply
* [PATCH] netlink: Re-add locking to netlink_lookup() and seq walker
From: Thomas Graf @ 2014-10-21 20:05 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, David S. Miller, Eric Dumazet
The synchronize_rcu() in netlink_release() introduces unacceptable
latency. Reintroduce minimal lookup so we can drop the
synchronize_rcu() until socket destruction has been RCUfied.
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/netlink/af_netlink.c | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7a186e7..f1de72d 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -96,6 +96,14 @@ static DECLARE_WAIT_QUEUE_HEAD(nl_table_wait);
static int netlink_dump(struct sock *sk);
static void netlink_skb_destructor(struct sk_buff *skb);
+/* nl_table locking explained:
+ * Lookup and traversal are protected with nl_sk_hash_lock or nl_table_lock
+ * combined with an RCU read-side lock. Insertion and removal are protected
+ * with nl_sk_hash_lock while using RCU list modification primitives and may
+ * run in parallel to nl_table_lock protected lookups. Destruction of the
+ * Netlink socket may only occur *after* nl_table_lock has been acquired
+ * either during or after the socket has been removed from the list.
+ */
DEFINE_RWLOCK(nl_table_lock);
EXPORT_SYMBOL_GPL(nl_table_lock);
static atomic_t nl_table_users = ATOMIC_INIT(0);
@@ -109,10 +117,10 @@ EXPORT_SYMBOL_GPL(nl_sk_hash_lock);
static int lockdep_nl_sk_hash_is_held(void)
{
#ifdef CONFIG_LOCKDEP
- return (debug_locks) ? lockdep_is_held(&nl_sk_hash_lock) : 1;
-#else
- return 1;
+ if (debug_locks)
+ return lockdep_is_held(&nl_sk_hash_lock) || lockdep_is_held(&nl_table_lock);
#endif
+ return 1;
}
static ATOMIC_NOTIFIER_HEAD(netlink_chain);
@@ -1028,11 +1036,13 @@ static struct sock *netlink_lookup(struct net *net, int protocol, u32 portid)
struct netlink_table *table = &nl_table[protocol];
struct sock *sk;
+ read_lock(&nl_table_lock);
rcu_read_lock();
sk = __netlink_lookup(table, portid, net);
if (sk)
sock_hold(sk);
rcu_read_unlock();
+ read_unlock(&nl_table_lock);
return sk;
}
@@ -1257,9 +1267,6 @@ static int netlink_release(struct socket *sock)
}
netlink_table_ungrab();
- /* Wait for readers to complete */
- synchronize_net();
-
kfree(nlk->groups);
nlk->groups = NULL;
@@ -1281,6 +1288,7 @@ static int netlink_autobind(struct socket *sock)
retry:
cond_resched();
+ netlink_table_grab();
rcu_read_lock();
if (__netlink_lookup(table, portid, net)) {
/* Bind collision, search negative portid values. */
@@ -1288,9 +1296,11 @@ retry:
if (rover > -4097)
rover = -4097;
rcu_read_unlock();
+ netlink_table_ungrab();
goto retry;
}
rcu_read_unlock();
+ netlink_table_ungrab();
err = netlink_insert(sk, net, portid);
if (err == -EADDRINUSE)
@@ -2921,14 +2931,16 @@ static struct sock *netlink_seq_socket_idx(struct seq_file *seq, loff_t pos)
}
static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(RCU)
+ __acquires(nl_table_lock) __acquires(RCU)
{
+ read_lock(&nl_table_lock);
rcu_read_lock();
return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
+ struct rhashtable *ht;
struct netlink_sock *nlk;
struct nl_seq_iter *iter;
struct net *net;
@@ -2943,19 +2955,19 @@ static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
iter = seq->private;
nlk = v;
- rht_for_each_entry_rcu(nlk, nlk->node.next, node)
+ i = iter->link;
+ ht = &nl_table[i].hash;
+ rht_for_each_entry(nlk, nlk->node.next, ht, node)
if (net_eq(sock_net((struct sock *)nlk), net))
return nlk;
- i = iter->link;
j = iter->hash_idx + 1;
do {
- struct rhashtable *ht = &nl_table[i].hash;
const struct bucket_table *tbl = rht_dereference_rcu(ht->tbl, ht);
for (; j < tbl->size; j++) {
- rht_for_each_entry_rcu(nlk, tbl->buckets[j], node) {
+ rht_for_each_entry(nlk, tbl->buckets[j], ht, node) {
if (net_eq(sock_net((struct sock *)nlk), net)) {
iter->link = i;
iter->hash_idx = j;
@@ -2971,9 +2983,10 @@ static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
}
static void netlink_seq_stop(struct seq_file *seq, void *v)
- __releases(RCU)
+ __releases(RCU) __releases(nl_table_lock)
{
rcu_read_unlock();
+ read_unlock(&nl_table_lock);
}
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 1/1 net-next] mac80211: remove unnecessary null test before debugfs_remove
From: Fabian Frederick @ 2014-10-21 20:05 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, netdev, linux-kernel, David S. Miller,
John W. Linville
In-Reply-To: <1413918366.1998.10.camel@jlt4.sipsolutions.net>
> On 21 October 2014 at 21:06 Johannes Berg <johannes@sipsolutions.net> wrote:
>
>
> On Tue, 2014-10-21 at 18:20 +0200, Fabian Frederick wrote:
> > Fix checkpatch warnings:
> >
> > WARNING: debugfs_remove(NULL) is safe this check is probably not
> >required
>
> I'll apply this; however, I think that checkpatch is a just tool, and
> the commit message should reflect why you're changing the code.
> Presumably you're not doing it to make the tool happy, but to address an
> issue that the tool pointed out, so I think in most cases the commit
> message should state the former, not the latter.
>
> Note that in this particular case the NULL check check could be there to
> avoid a memory write (which can be significant depending on the context)
> so blindly doing what the tool suggested wouldn't always be a good idea.
>
> johannes
>
Thanks Johannes,
Maybe you can replace commit message with:
"
This patch removes NULL check before debugfs_remove.
That function already does that check and is
only called during key management so we can add some memory writes.
"
I can also resubmit patch if necessary.
Regards,
Fabian
^ permalink raw reply
* [PATCH 5/5] stmmac: pci: remove FSF address
From: Andy Shevchenko @ 2014-10-21 16:35 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S. Miller,
Vince Bridgers
Cc: Andy Shevchenko
In-Reply-To: <1413909333-16380-1-git-send-email-andriy.shevchenko@linux.intel.com>
The FSF address is subject to change, thus remove it from the file.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 22cb5ff..95eb195 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -12,10 +12,6 @@
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
- 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.,
- 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
-
The full GNU General Public License is included in this distribution in
the file called "COPYING".
--
2.1.1
^ permalink raw reply related
* [PATCH 2/5] stmmac: pci: use managed resources
From: Andy Shevchenko @ 2014-10-21 16:35 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S. Miller,
Vince Bridgers
Cc: Andy Shevchenko
In-Reply-To: <1413909333-16380-1-git-send-email-andriy.shevchenko@linux.intel.com>
Migrate pci driver to managed resources to reduce boilerplate error handling
code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 46 +++++-------------------
1 file changed, 8 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 5459a4e..f8d4ce2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -65,45 +65,29 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
int ret = 0;
- void __iomem *addr = NULL;
struct stmmac_priv *priv = NULL;
- int i;
+ int pci_bar = 0;
/* Enable pci device */
- ret = pci_enable_device(pdev);
+ ret = pcim_enable_device(pdev);
if (ret) {
pr_err("%s : ERROR: failed to enable %s device\n", __func__,
pci_name(pdev));
return ret;
}
- if (pci_request_regions(pdev, STMMAC_RESOURCE_NAME)) {
- pr_err("%s: ERROR: failed to get PCI region\n", __func__);
- ret = -ENODEV;
- goto err_out_req_reg_failed;
- }
+ ret = pcim_iomap_regions(pdev, BIT(pci_bar), pci_name(pdev));
+ if (ret)
+ return ret;
- /* Get the base address of device */
- for (i = 0; i <= 5; i++) {
- if (pci_resource_len(pdev, i) == 0)
- continue;
- addr = pci_iomap(pdev, i, 0);
- if (addr == NULL) {
- pr_err("%s: ERROR: cannot map register memory aborting",
- __func__);
- ret = -EIO;
- goto err_out_map_failed;
- }
- break;
- }
pci_set_master(pdev);
stmmac_default_data();
- priv = stmmac_dvr_probe(&(pdev->dev), &plat_dat, addr);
+ priv = stmmac_dvr_probe(&pdev->dev, &plat_dat,
+ pcim_iomap_table(pdev)[pci_bar]);
if (IS_ERR(priv)) {
pr_err("%s: main driver probe failed", __func__);
- ret = PTR_ERR(priv);
- goto err_out;
+ return PTR_ERR(priv);
}
priv->dev->irq = pdev->irq;
priv->wol_irq = pdev->irq;
@@ -113,15 +97,6 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pr_debug("STMMAC platform driver registration completed");
return 0;
-
-err_out:
- pci_clear_master(pdev);
-err_out_map_failed:
- pci_release_regions(pdev);
-err_out_req_reg_failed:
- pci_disable_device(pdev);
-
- return ret;
}
/**
@@ -134,13 +109,8 @@ err_out_req_reg_failed:
static void stmmac_pci_remove(struct pci_dev *pdev)
{
struct net_device *ndev = pci_get_drvdata(pdev);
- struct stmmac_priv *priv = netdev_priv(ndev);
stmmac_dvr_remove(ndev);
-
- pci_iounmap(pdev, priv->ioaddr);
- pci_release_regions(pdev);
- pci_disable_device(pdev);
}
#ifdef CONFIG_PM_SLEEP
--
2.1.1
^ permalink raw reply related
* [PATCH] netlink: don't copy over empty attribute data
From: Sasha Levin @ 2014-10-21 20:51 UTC (permalink / raw)
To: davem; +Cc: a.ryabinin, pablo, mschmidt, akpm, linux-kernel, netdev,
Sasha Levin
netlink uses empty data to seperate different levels. However, we still
try to copy that data from a NULL ptr using memcpy, which is an undefined
behaviour.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
lib/nlattr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 9c3e85f..6512b43 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -430,7 +430,8 @@ void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
struct nlattr *nla;
nla = __nla_reserve(skb, attrtype, attrlen);
- memcpy(nla_data(nla), data, attrlen);
+ if (data)
+ memcpy(nla_data(nla), data, attrlen);
}
EXPORT_SYMBOL(__nla_put);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/5] stmmac: pci: use managed resources
From: Sergei Shtylyov @ 2014-10-21 20:55 UTC (permalink / raw)
To: Andy Shevchenko, Giuseppe Cavallaro, netdev, Kweh Hock Leong,
David S. Miller, Vince Bridgers
In-Reply-To: <1413909333-16380-3-git-send-email-andriy.shevchenko@linux.intel.com>
Hello.
On 10/21/2014 08:35 PM, Andy Shevchenko wrote:
> Migrate pci driver to managed resources to reduce boilerplate error handling
> code.
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 46 +++++-------------------
> 1 file changed, 8 insertions(+), 38 deletions(-)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index 5459a4e..f8d4ce2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -65,45 +65,29 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
> const struct pci_device_id *id)
> {
> int ret = 0;
> - void __iomem *addr = NULL;
> struct stmmac_priv *priv = NULL;
> - int i;
> + int pci_bar = 0;
I don't see this variable changing anywhere...
> /* Enable pci device */
> - ret = pci_enable_device(pdev);
> + ret = pcim_enable_device(pdev);
> if (ret) {
> pr_err("%s : ERROR: failed to enable %s device\n", __func__,
> pci_name(pdev));
> return ret;
> }
> - if (pci_request_regions(pdev, STMMAC_RESOURCE_NAME)) {
> - pr_err("%s: ERROR: failed to get PCI region\n", __func__);
> - ret = -ENODEV;
> - goto err_out_req_reg_failed;
> - }
> + ret = pcim_iomap_regions(pdev, BIT(pci_bar), pci_name(pdev));
> + if (ret)
> + return ret;
>
> - /* Get the base address of device */
> - for (i = 0; i <= 5; i++) {
> - if (pci_resource_len(pdev, i) == 0)
> - continue;
> - addr = pci_iomap(pdev, i, 0);
> - if (addr == NULL) {
> - pr_err("%s: ERROR: cannot map register memory aborting",
> - __func__);
> - ret = -EIO;
> - goto err_out_map_failed;
> - }
> - break;
> - }
It's not an equivalent change: the old code mapped a first existing BAR,
you always map BAR0. Are you sure that's what you meant? If so, wouldn't hurt
to describe this in the changelog...
WBR, Sergei
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Kevin Fenzi @ 2014-10-21 21:12 UTC (permalink / raw)
To: netdev, linux-kernel
In-Reply-To: <20141020145359.565fe5e6@voldemort.scrye.com>
[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]
On Mon, 20 Oct 2014 14:53:59 -0600
Kevin Fenzi <kevin@scrye.com> wrote:
> On Mon, 20 Oct 2014 16:43:26 -0400
> Dave Jones <davej@redhat.com> wrote:
>
> > I've seen similar soft lockup traces from the sys_unshare path when
> > running my fuzz tester. It seems that if you create enough network
> > namespaces, it can take a huge amount of time for them to be
> > iterated. (Running trinity with '-c unshare' you can see the slow
> > down happen. In some cases, it takes so long that the watchdog
> > process kills it -- though the SIGKILL won't get delivered until
> > the unshare() completes)
> >
> > Any idea what this machine had been doing prior to this that may
> > have involved creating lots of namespaces ?
>
> That was right after boot. ;)
>
> This is my main rawhide running laptop.
>
> A 'ip netns list' shows nothing.
Some more information:
The problem started between:
v3.17-7872-g5ff0b9e1a1da and v3.17-8307-gf1d0d14120a8
(I can try and do a bisect, but have to head out on a trip tomorrow)
In all the kernels with the problem, there is a kworker process in D.
sysrq-t says:
Showing all locks held in the system:
Oct 21 15:06:31 voldemort.scrye.com kernel: 4 locks held by kworker/u16:0/6:
Oct 21 15:06:31 voldemort.scrye.com kernel: #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccbff>] process_one_work+0x17f/0x850
Oct 21 15:06:31 voldemort.scrye.com kernel: #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810ccbff>] process_one_work+0x17f/0x850
Oct 21 15:06:31 voldemort.scrye.com kernel: #2: (net_mutex){+.+.+.}, at: [<ffffffff817069fc>] cleanup_net+0x8c/0x1f0
Oct 21 15:06:31 voldemort.scrye.com kernel: #3:
(rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a395>]
_rcu_barrier+0x35/0x200
On first running any of the systemd units that use PrivateNetwork, then
run ok, but they are also set to timeout after a minute. On sucessive
runs they hang in D also.
kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()
From: Sitsofe Wheeler @ 2014-10-21 21:16 UTC (permalink / raw)
To: Long Li
Cc: David Miller, olaf@aepfle.de, netdev@vger.kernel.org,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
apw@canonical.com, devel@linuxdriverproject.org, Haiyang Zhang
In-Reply-To: <1413911624662.86334@microsoft.com>
On 21 October 2014 18:13, Long Li <longli@microsoft.com> wrote:
> Thanks Sitsofe. This should have been fixed by this patch:
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=f88e67149f97d73c704d6fe6f492edde97463025
>
> Can you give it a try?
Ah this one went mainline a few days ago so I've already been trying
it. Yes it resolves my problem (that system is no longer oopsing on
startup). I'd have added my Tested-by but it's already been committed
:-)
What helped you narrow it down?
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* RE: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()
From: Haiyang Zhang @ 2014-10-21 21:25 UTC (permalink / raw)
To: Sitsofe Wheeler, Long Li
Cc: David Miller, olaf@aepfle.de, netdev@vger.kernel.org,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
apw@canonical.com, devel@linuxdriverproject.org
In-Reply-To: <CALjAwxj1jHUugt+vtJL7duXfTpdoxmCrwTzRmNHGgOdj+Ju3Aw@mail.gmail.com>
> -----Original Message-----
> From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> Sent: Tuesday, October 21, 2014 5:16 PM
> To: Long Li
> Cc: David Miller; olaf@aepfle.de; netdev@vger.kernel.org;
> jasowang@redhat.com; linux-kernel@vger.kernel.org; apw@canonical.com;
> devel@linuxdriverproject.org; Haiyang Zhang
> Subject: Re: [PATCH net 1/1] hyperv: Fix a bug in netvsc_send()
>
> On 21 October 2014 18:13, Long Li <longli@microsoft.com> wrote:
> > Thanks Sitsofe. This should have been fixed by this patch:
> > http://git.kernel.org/cgit/linux/kernel/git/next/linux-
> next.git/commit/?id=f88e67149f97d73c704d6fe6f492edde97463025
> >
> > Can you give it a try?
>
> Ah this one went mainline a few days ago so I've already been trying
> it. Yes it resolves my problem (that system is no longer oopsing on
> startup). I'd have added my Tested-by but it's already been committed
> :-)
Thank you for the test!
- Haiyang
^ permalink raw reply
* Re: [PATCH] net: typhoon: Remove redundant casts
From: David Dillow @ 2014-10-21 21:29 UTC (permalink / raw)
To: Rasmus Villemoes; +Cc: netdev, linux-kernel
In-Reply-To: <1413903103-3047-1-git-send-email-linux@rasmusvillemoes.dk>
On Tue, 2014-10-21 at 16:51 +0200, Rasmus Villemoes wrote:
> Both image_data and typhoon_fw->data are const u8*, so the cast to u8*
> is unnecessary and confusing.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: David Dillow <dave@thedillows.org>
^ permalink raw reply
* Re: [PATCH 0/9] Marvell PXA168 libphy handling and Berlin Ethernet
From: Florian Fainelli @ 2014-10-21 22:03 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: David S. Miller, Antoine Ténart, Eric Miao, Haojian Zhuang,
linux-arm-kernel, netdev, devicetree, linux-kernel
In-Reply-To: <1413881627-21639-1-git-send-email-sebastian.hesselbarth@gmail.com>
Hi Sebastian,
On 10/21/2014 01:53 AM, Sebastian Hesselbarth wrote:
> This patch series deals with a removing a IP feature that can be found
> on all currently supported Marvell Ethernet IP (pxa168_eth, mv643xx_eth,
> mvneta). The MAC IP allows to automatically perform PHY auto-negotiation
> without software interaction.
>
> However, this feature (a) fundamentally clashes with the way libphy works
> and (b) is unable to deal with quirky PHYs that require special treatment.
> In this series, pxa168_eth driver is rewritten to completely disable that
> feature and properly deal with libphy provided PHYs.
>
> This is the real patch set after an RFT sent earlier. Unfortunately, there
> was no testing from MMP/gplug but there was for BG2Q. However, it still
> would be great to get a Tested-by on gplug. Also, this patch set is now
> rebased on v3.18-rc1. As usual, a branch on top of v3.18-rc1 can be found at
>
> git://git.infradead.org/users/hesselba/linux-berlin.git devel/bg2-bg2cd-eth-v1
>
> Patches 1-5 should go through David's net tree, I'll pick up the DT patches
> 6-9.
>
> Compared to the RFT, there have been some changes:
> - added phy-connection-type property to BG2Q PHY DT node
> - bail out from pxa168_eth_adjust_link when there is no change in
> PHY parameters. Also, add a call to phy_print_status.
>
> Patch 1 adds support for Marvell 88E3016 FastEthernet PHY that is also
> integrated in Marvell Berlin BG2/BG2CD SoCs.
>
> Patch 2 allows to pass phy_interface_t on pxa168_eth platform_data that
> is only used by mach-mmp/gplug. From the board setup, I guessed gplug's
> PHY is connected via RMII. The patch still isn't even compile tested.
>
> Patches 3-5 prepare proper libphy handling and finally remove all in-driver
> PHY mangling related to the feature explained above.
>
> Patches 6-9 add corresponding ethernet DT nodes to BG2, BG2CD, add a
> phy-connection-type property to BG2Q and enable ethernet on BG2-based Sony
> NSZ-GS7. I have tested all this on GS7 successfully with ip=dhcp on 100M FD.
Besides the misplacement of the 'phy-connection-type' as reported by
Sergei, this looks good to me:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
>
> Antoine Ténart (1):
> ARM: berlin: Add phy-connection-type to BG2Q PHY
>
> Sebastian Hesselbarth (8):
> phy: marvell: Add support for 88E3016 FastEthernet PHY
> net: pxa168_eth: Provide phy_interface mode on platform_data
> net: pxa168_eth: Prepare proper libphy handling
> net: pxa168_eth: Remove HW auto-negotiaion
> net: pxa168_eth: Remove in-driver PHY mangling
> ARM: berlin: Add BG2 ethernet DT nodes
> ARM: berlin: Add BG2CD ethernet DT nodes
> ARM: berlin: Enable ethernet on Sony NSZ-GS7
>
> arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts | 2 +
> arch/arm/boot/dts/berlin2.dtsi | 36 +++++
> arch/arm/boot/dts/berlin2cd.dtsi | 36 +++++
> arch/arm/boot/dts/berlin2q.dtsi | 1 +
> arch/arm/mach-mmp/gplugd.c | 2 +
> drivers/net/ethernet/marvell/pxa168_eth.c | 248 ++++++++++++-----------------
> drivers/net/phy/marvell.c | 46 ++++++
> include/linux/marvell_phy.h | 1 +
> include/linux/pxa168_eth.h | 1 +
> 9 files changed, 225 insertions(+), 148 deletions(-)
>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: "Antoine Ténart" <antoine.tenart@free-electrons.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: netdev@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
^ permalink raw reply
* Re: [PATCH] Documentation: ptp: Fix build failure on MIPS cross builds
From: Peter Foley @ 2014-10-21 22:04 UTC (permalink / raw)
To: Richard Cochran
Cc: David Daney, David Miller, markos.chandras, linux-mips, corbet,
netdev, linux-doc@vger.kernel.org, LKML
In-Reply-To: <20141021182757.GA3960@localhost.localdomain>
On Tue, Oct 21, 2014 at 2:27 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Oct 21, 2014 at 09:58:51AM -0700, David Daney wrote:
>> What I don't understand is why we are using hostprogs in this
>> Makefile. Isn't this a program that would run on the target, not
>> the build host?
>
> Yes.
>
> Peter, could you please fix it?
The intention of these changes was to generate more compiliation
coverage for code in Documentation/
The underlying issue is that this doesn't work for cross-compiling
because kbuild doesn't have cross-compile support for userspace code.
I submitted a patch to disable building Documentation when
cross-compiling, as the consensus in the thread that resulted in that
patch (https://lkml.org/lkml/2014/10/8/510) was that implementing
targetprogs in kbuild was not currently worth it.
I can try to take a crack at adding targetprogs support, but I'm
rather busy right now, so it may take a little while.
Thanks,
Peter
^ permalink raw reply
* Re: [PATCHv4 3/4] sparc64: Avoid irqsave/restore on vio.lock if in_softirq()
From: Julian Calaby @ 2014-10-21 22:35 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: David S. Miller, netdev, sparclinux
In-Reply-To: <20141021141647.GF15405@oracle.com>
Hi Sowmini,
On Wed, Oct 22, 2014 at 1:16 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> For NAPIfied drivers , there is no need to
> synchronize by doing irqsave/restore on vio.lock in the I/O
> path.
>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> ---
> arch/sparc/kernel/viohs.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/sparc/kernel/viohs.c b/arch/sparc/kernel/viohs.c
> index 7ef081a..d731586 100644
> --- a/arch/sparc/kernel/viohs.c
> +++ b/arch/sparc/kernel/viohs.c
> @@ -747,10 +747,11 @@ EXPORT_SYMBOL(vio_ldc_free);
>
> void vio_port_up(struct vio_driver_state *vio)
> {
> - unsigned long flags;
> + unsigned long flags = 0;
Is gcc not smart enough to know that this variable isn't used before
it's set? (I assume it isn't used elsewhere in this function)
> int err, state;
>
> - spin_lock_irqsave(&vio->lock, flags);
> + if (!in_softirq())
> + spin_lock_irqsave(&vio->lock, flags);
>
> state = ldc_state(vio->lp);
>
> @@ -777,7 +778,8 @@ void vio_port_up(struct vio_driver_state *vio)
> mod_timer(&vio->timer, expires);
> }
>
> - spin_unlock_irqrestore(&vio->lock, flags);
> + if (!in_softirq())
> + spin_unlock_irqrestore(&vio->lock, flags);
> }
> EXPORT_SYMBOL(vio_port_up);
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCHv4 3/4] sparc64: Avoid irqsave/restore on vio.lock if in_softirq()
From: Sowmini Varadhan @ 2014-10-21 22:39 UTC (permalink / raw)
To: Julian Calaby; +Cc: David S. Miller, netdev, sparclinux
In-Reply-To: <CAGRGNgXvKJBhOE1z3=_gZkE=X94HnoAvTN6Zv5G1h8JuFfS8Ng@mail.gmail.com>
On (10/22/14 09:35), Julian Calaby wrote:
> > void vio_port_up(struct vio_driver_state *vio)
> > {
> > - unsigned long flags;
> > + unsigned long flags = 0;
>
> Is gcc not smart enough to know that this variable isn't used before
> it's set? (I assume it isn't used elsewhere in this function)
No, it's not used elsewhere in the function, and yes, I too was
surprised by the build warning, which is why I initialized it
as above.
--Sowmini
^ permalink raw reply
* Re: [PATCHv4 3/4] sparc64: Avoid irqsave/restore on vio.lock if in_softirq()
From: Julian Calaby @ 2014-10-21 22:42 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: David S. Miller, netdev, sparclinux
In-Reply-To: <20141021223952.GA26724@oracle.com>
Hi Sowmini,
On Wed, Oct 22, 2014 at 9:39 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (10/22/14 09:35), Julian Calaby wrote:
>> > void vio_port_up(struct vio_driver_state *vio)
>> > {
>> > - unsigned long flags;
>> > + unsigned long flags = 0;
>>
>> Is gcc not smart enough to know that this variable isn't used before
>> it's set? (I assume it isn't used elsewhere in this function)
>
> No, it's not used elsewhere in the function, and yes, I too was
> surprised by the build warning, which is why I initialized it
> as above.
Ok, fair enough then.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [stable request <= 3.11] net/mlx4_en: Fix BlueFlame race
From: Cong Wang @ 2014-10-21 23:15 UTC (permalink / raw)
To: Vinson Lee
Cc: David S. Miller, Amir Vadai, Or Gerlitz, Jack Morgenstein,
Eugenia Emantayev, Matan Barak, netdev
In-Reply-To: <CAHTgTXVn1479XCoh1-j=Xghtad3zA-hf0za5r_AyoaKuKeFZ2g@mail.gmail.com>
On Sat, Oct 18, 2014 at 2:14 PM, Vinson Lee <vlee@twopensource.com> wrote:
> Hi.
>
> Please consider backporting upstream commit
> 2d4b646613d6b12175b017aca18113945af1faf3 "net/mlx4_en: Fix BlueFlame
> race" to stable kernels <= 3.11.
>
David, could you take care of it if you have time? It fixes a real
bug in production. :)
Thanks a lot!
^ permalink raw reply
* IPv6 UFO for VMs
From: Ben Hutchings @ 2014-10-21 23:44 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa, virtualization
[-- Attachment #1.1: Type: text/plain, Size: 1303 bytes --]
There are several ways that VMs can take advantage of UFO and get the
host to do fragmentation for them:
drivers/net/macvtap.c: gso_type = SKB_GSO_UDP;
drivers/net/tun.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
drivers/net/virtio_net.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
Our implementation of UFO for IPv6 does:
fptr = (struct frag_hdr *)(skb_network_header(skb) + unfrag_ip6hlen);
fptr->nexthdr = nexthdr;
fptr->reserved = 0;
fptr->identification = skb_shinfo(skb)->ip6_frag_id;
which assumes ip6_frag_id has been set. That's only true if the local
stack constructed the skb; otherwise it appears we get zero.
This seems to be a regression as a result of:
commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri Feb 21 02:55:35 2014 +0100
ipv6: reuse ip6_frag_id from ip6_ufo_append_data
However, that change seems reasonable - we *shouldn't* be choosing IDs
for any other stack. Any paravirt net driver that can use IPv6 UFO
needs to have some way of passing a fragmentation ID to put in
skb_shared_info::ip6_frag_id.
Ben.
--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCHv4 3/4] sparc64: Avoid irqsave/restore on vio.lock if in_softirq()
From: Dave Kleikamp @ 2014-10-21 23:56 UTC (permalink / raw)
To: Julian Calaby, Sowmini Varadhan; +Cc: David S. Miller, netdev, sparclinux
In-Reply-To: <CAGRGNgXvKJBhOE1z3=_gZkE=X94HnoAvTN6Zv5G1h8JuFfS8Ng@mail.gmail.com>
On 10/21/2014 05:35 PM, Julian Calaby wrote:
> Hi Sowmini,
>
> On Wed, Oct 22, 2014 at 1:16 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
>> For NAPIfied drivers , there is no need to
>> synchronize by doing irqsave/restore on vio.lock in the I/O
>> path.
>>
>> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
>> ---
>> arch/sparc/kernel/viohs.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/sparc/kernel/viohs.c b/arch/sparc/kernel/viohs.c
>> index 7ef081a..d731586 100644
>> --- a/arch/sparc/kernel/viohs.c
>> +++ b/arch/sparc/kernel/viohs.c
>> @@ -747,10 +747,11 @@ EXPORT_SYMBOL(vio_ldc_free);
>>
>> void vio_port_up(struct vio_driver_state *vio)
>> {
>> - unsigned long flags;
>> + unsigned long flags = 0;
>
> Is gcc not smart enough to know that this variable isn't used before
> it's set? (I assume it isn't used elsewhere in this function)
It probably assumes in_softirq() might evaluate differently in the each
case.
>
>> int err, state;
>>
>> - spin_lock_irqsave(&vio->lock, flags);
>> + if (!in_softirq())
>> + spin_lock_irqsave(&vio->lock, flags);
>>
>> state = ldc_state(vio->lp);
>>
>> @@ -777,7 +778,8 @@ void vio_port_up(struct vio_driver_state *vio)
>> mod_timer(&vio->timer, expires);
>> }
>>
>> - spin_unlock_irqrestore(&vio->lock, flags);
>> + if (!in_softirq())
>> + spin_unlock_irqrestore(&vio->lock, flags);
>> }
>> EXPORT_SYMBOL(vio_port_up);
>
> Thanks,
>
^ permalink raw reply
* Re: [PATCHv4 3/4] sparc64: Avoid irqsave/restore on vio.lock if in_softirq()
From: Sowmini Varadhan @ 2014-10-22 0:16 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: Julian Calaby, David S. Miller, netdev, sparclinux
In-Reply-To: <5446F291.1030400@oracle.com>
On (10/21/14 18:56), Dave Kleikamp wrote:
> >
> > Is gcc not smart enough to know that this variable isn't used before
> > it's set? (I assume it isn't used elsewhere in this function)
>
> It probably assumes in_softirq() might evaluate differently in the each
> case.
yes, that's what I suspected too. I suppose it is possible
from the compiler's point of view that something in between
might change the result of in_softirq() so that we may be
using an uninit variable in the second call.
anyway, the warning was annoying, and would only numb the
user into ignoring other real issues, so I figured I might
as well silence the warning.
--Sowmini
^ permalink raw reply
* RE: Urgent Order
From: Parker Nick @ 2014-10-22 7:37 UTC (permalink / raw)
Hello,
Please send me a price list and quotation for your products we want to import from your country this is a very large order for long term import and urgent request.
Thank you in advance for your prompt confirmation.
Regards,
Parker Nick
Equipos de Elevaci n , S.A. de C.V.Av. Texcoco #35,
54070 Tlalnepantla , Edo . de M xico
M xico
Tels.+27840117769
^ permalink raw reply
* Re: [PATCH] netlink: Re-add locking to netlink_lookup() and seq walker
From: David Miller @ 2014-10-22 1:36 UTC (permalink / raw)
To: tgraf; +Cc: davem, netdev, linux-kernel, eric.dumazet
In-Reply-To: <14101d52c64e0d52176ca0d4b8888f8cf20ab9b0.1413921873.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 21 Oct 2014 22:05:38 +0200
> The synchronize_rcu() in netlink_release() introduces unacceptable
> latency. Reintroduce minimal lookup so we can drop the
> synchronize_rcu() until socket destruction has been RCUfied.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
> Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Applied and queued up for -stable.
Please use an appropriate "Fixes: " tag in the future, this is
especially important for an issue as serious as this one.
Thanks.
^ 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