Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net-next V2 05/11] net/mlx5e: Support RX multi-packet WQE (Striding RQ)
From: Eric Dumazet @ 2016-04-18 14:17 UTC (permalink / raw)
  To: Saeed Mahameed
  Cc: Saeed Mahameed, David S. Miller, Linux Netdev List, Or Gerlitz,
	Tal Alon, Tariq Toukan, Eran Ben Elisha, Achiad Shochat
In-Reply-To: <CALzJLG_W9SkgMBQp86P0WDknw4Kc=DCBrvpPemAUbRX=r4r8Yg@mail.gmail.com>

On Mon, 2016-04-18 at 16:05 +0300, Saeed Mahameed wrote:
> On Mon, Apr 18, 2016 at 3:48 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Sun, 2016-04-17 at 17:29 -0700, Eric Dumazet wrote:
> >
> >>
> >> If really you need to allocate physically contiguous memory, have you
> >> considered converting the order-5 pages into 32 order-0 ones ?
> >
> > Search for split_page() call sites for examples.
> >
> >
> 
> Thanks Eric, we are already evaluating split_page as we speak.
> 
> We did look but could not find any specific alloc_pages API that
> allocates many physically contiguous pages with order0 ! so we assume
> it is ok to use split_page.

Note: I have no idea of split_page() performance :

Buddy page allocator has to aggregate pages into order-5, then we would
undo the work, touching 32 cache lines.

You might first benchmark a simple loop doing 

loop 10,000,000 times
 Order-5 allocation
 split into 32 order-0
 free 32 pages


Another idea would be to have a way to control max number of order-5
pages that a port would be using.

Since driver always own a ref on a order-5 pages, idea would be to
maintain a circular ring of up to XXX such pages, so that we can detect
an abnormal use and fallback to order-0 immediately.

^ permalink raw reply

* Re: [PATCH bluetooth-next 07/10] ipv6: introduce neighbour discovery ops
From: kbuild test robot @ 2016-04-18 14:23 UTC (permalink / raw)
  To: Alexander Aring
  Cc: kbuild-all, linux-wpan, kernel, marcel, jukka.rissanen, hannes,
	stefan, mcr, werner, linux-bluetooth, netdev, Alexander Aring,
	David S . Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1460977108-4675-8-git-send-email-aar@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 9109 bytes --]

Hi Alexander,

[auto build test WARNING on bluetooth-next/master]

url:    https://github.com/0day-ci/linux/commits/Alexander-Aring/6lowpan-introduce-basic-6lowpan-nd/20160418-191825
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master
config: x86_64-randconfig-i0-04181247 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
                    from include/linux/stddef.h:4,
                    from include/uapi/linux/posix_types.h:4,
                    from include/uapi/linux/types.h:13,
                    from include/linux/types.h:5,
                    from include/uapi/linux/capability.h:16,
                    from include/linux/capability.h:15,
                    from net/appletalk/ddp.c:54:
   include/net/ndisc.h: In function 'ndisc_is_useropt':
   include/net/ndisc.h:201:16: error: 'const struct net_device' has no member named 'ndisc_ops'
     if (likely(dev->ndisc_ops->is_useropt))
                   ^
   include/linux/compiler.h:138:43: note: in definition of macro 'likely'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                              ^
   include/net/ndisc.h:201:16: error: 'const struct net_device' has no member named 'ndisc_ops'
     if (likely(dev->ndisc_ops->is_useropt))
                   ^
   include/linux/compiler.h:138:51: note: in definition of macro 'likely'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                                      ^
   include/net/ndisc.h:201:16: error: 'const struct net_device' has no member named 'ndisc_ops'
     if (likely(dev->ndisc_ops->is_useropt))
                   ^
   include/linux/compiler.h:114:47: note: in definition of macro 'likely_notrace'
    #define likely_notrace(x) __builtin_expect(!!(x), 1)
                                                  ^
   include/linux/compiler.h:138:56: note: in expansion of macro '__branch_check__'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                                           ^
>> include/net/ndisc.h:201:6: note: in expansion of macro 'likely'
     if (likely(dev->ndisc_ops->is_useropt))
         ^
   In file included from include/net/ipv6.h:20:0,
                    from include/net/inetpeer.h:15,
                    from include/net/route.h:28,
                    from net/appletalk/ddp.c:64:
   include/net/ndisc.h:202:13: error: 'const struct net_device' has no member named 'ndisc_ops'
      return dev->ndisc_ops->is_useropt(opt);
                ^
   In file included from include/uapi/linux/stddef.h:1:0,
                    from include/linux/stddef.h:4,
                    from include/uapi/linux/posix_types.h:4,
                    from include/uapi/linux/types.h:13,
                    from include/linux/types.h:5,
                    from include/uapi/linux/capability.h:16,
                    from include/linux/capability.h:15,
                    from net/appletalk/ddp.c:54:
   include/net/ndisc.h: In function 'ndisc_send_na':
   include/net/ndisc.h:213:16: error: 'struct net_device' has no member named 'ndisc_ops'
     if (likely(dev->ndisc_ops->send_na))
                   ^
   include/linux/compiler.h:138:43: note: in definition of macro 'likely'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                              ^
   include/net/ndisc.h:213:16: error: 'struct net_device' has no member named 'ndisc_ops'
     if (likely(dev->ndisc_ops->send_na))
                   ^
   include/linux/compiler.h:138:51: note: in definition of macro 'likely'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                                      ^
   include/net/ndisc.h:213:16: error: 'struct net_device' has no member named 'ndisc_ops'
     if (likely(dev->ndisc_ops->send_na))
                   ^
   include/linux/compiler.h:114:47: note: in definition of macro 'likely_notrace'
    #define likely_notrace(x) __builtin_expect(!!(x), 1)
                                                  ^
   include/linux/compiler.h:138:56: note: in expansion of macro '__branch_check__'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                                           ^
   include/net/ndisc.h:213:6: note: in expansion of macro 'likely'
     if (likely(dev->ndisc_ops->send_na))
         ^
   In file included from include/net/ipv6.h:20:0,
                    from include/net/inetpeer.h:15,
                    from include/net/route.h:28,
                    from net/appletalk/ddp.c:64:
   include/net/ndisc.h:214:6: error: 'struct net_device' has no member named 'ndisc_ops'
      dev->ndisc_ops->send_na(dev, daddr, solicited_addr, router,
         ^
   In file included from include/uapi/linux/stddef.h:1:0,
                    from include/linux/stddef.h:4,
                    from include/uapi/linux/posix_types.h:4,
                    from include/uapi/linux/types.h:13,
                    from include/linux/types.h:5,
                    from include/uapi/linux/capability.h:16,
                    from include/linux/capability.h:15,
                    from net/appletalk/ddp.c:54:
   include/net/ndisc.h: In function 'ndisc_recv_na':
   include/net/ndisc.h:220:21: error: 'struct net_device' has no member named 'ndisc_ops'
     if (likely(skb->dev->ndisc_ops->recv_na))
                        ^
   include/linux/compiler.h:138:43: note: in definition of macro 'likely'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                              ^
   include/net/ndisc.h:220:21: error: 'struct net_device' has no member named 'ndisc_ops'
     if (likely(skb->dev->ndisc_ops->recv_na))
                        ^
   include/linux/compiler.h:138:51: note: in definition of macro 'likely'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                                      ^
   include/net/ndisc.h:220:21: error: 'struct net_device' has no member named 'ndisc_ops'
     if (likely(skb->dev->ndisc_ops->recv_na))
                        ^
   include/linux/compiler.h:114:47: note: in definition of macro 'likely_notrace'
    #define likely_notrace(x) __builtin_expect(!!(x), 1)
                                                  ^
   include/linux/compiler.h:138:56: note: in expansion of macro '__branch_check__'
    #  define likely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
                                                           ^
   include/net/ndisc.h:220:6: note: in expansion of macro 'likely'
     if (likely(skb->dev->ndisc_ops->recv_na))
         ^
   In file included from include/net/ipv6.h:20:0,
                    from include/net/inetpeer.h:15,
                    from include/net/route.h:28,
                    from net/appletalk/ddp.c:64:
   include/net/ndisc.h:221:11: error: 'struct net_device' has no member named 'ndisc_ops'
      skb->dev->ndisc_ops->recv_na(skb);
              ^
   In file included from include/uapi/linux/stddef.h:1:0,
                    from include/linux/stddef.h:4,
                    from include/uapi/linux/posix_types.h:4,
                    from include/uapi/linux/types.h:13,
                    from include/linux/types.h:5,
                    from include/uapi/linux/capability.h:16,
                    from include/linux/capability.h:15,
                    from net/appletalk/ddp.c:54:
   include/net/ndisc.h: In function 'ndisc_send_ns':
   include/net/ndisc.h:229:16: error: 'struct net_device' has no member named 'ndisc_ops'
     if (likely(dev->ndisc_ops->send_ns))

vim +/likely +201 include/net/ndisc.h

   185		void	(*send_na)(struct net_device *dev,
   186				   const struct in6_addr *daddr,
   187				   const struct in6_addr *solicited_addr,
   188				   bool router, bool solicited,
   189				   bool override, bool inc_opt);
   190		void	(*recv_na)(struct sk_buff *skb);
   191		void	(*send_ns)(struct net_device *dev,
   192				   const struct in6_addr *solicit,
   193				   const struct in6_addr *daddr,
   194				   const struct in6_addr *saddr);
   195		void	(*recv_ns)(struct sk_buff *skb);
   196	};
   197	
   198	static inline int ndisc_is_useropt(const struct net_device *dev,
   199					   struct nd_opt_hdr *opt)
   200	{
 > 201		if (likely(dev->ndisc_ops->is_useropt))
   202			return dev->ndisc_ops->is_useropt(opt);
   203		else
   204			return 0;
   205	}
   206	
   207	static inline void ndisc_send_na(struct net_device *dev,
   208					 const struct in6_addr *daddr,
   209					 const struct in6_addr *solicited_addr,

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 24077 bytes --]

^ permalink raw reply

* [PATCH] net: ipv6: Do not fix up linklocal and loopback addresses
From: Mike Manning @ 2016-04-18 14:23 UTC (permalink / raw)
  To: netdev
In-Reply-To: <5711ADD1.2030904@brocade.com>

f1705ec197e7 "Make address flushing on ifdown optional" added the option
to retain user configured addresses on an admin down. A comment to one of
the later revisions suggested using the IFA_F_PERMANENT flag rather than
adding a user_managed boolean to the ifaddr struct. A side effect of this
change is that link local and loopback addresses were also retained which
was not part of the objective of the original changes. The fix 70af921db6f8
"Do not keep linklocal and loopback addresses" ensures that these are no
longer kept. Similarly, the present fix ensures that these addresses are not
fixed up either, otherwise the incorrect fixup triggers a crash in fib6.

Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning <mmanning@brocade.com>
---
 net/ipv6/addrconf.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 23cec53..cba4e10 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3200,6 +3200,12 @@ static void l3mdev_check_host_rt(struct inet6_dev *idev,
 }
 #endif
 
+static bool addr_is_local(const struct in6_addr *addr)
+{
+	return ipv6_addr_type(addr) &
+		(IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK);
+}
+
 static int fixup_permanent_addr(struct inet6_dev *idev,
 				struct inet6_ifaddr *ifp)
 {
@@ -3238,6 +3244,7 @@ static void addrconf_permanent_addr(struct net_device *dev)
 
 	list_for_each_entry_safe(ifp, tmp, &idev->addr_list, if_list) {
 		if ((ifp->flags & IFA_F_PERMANENT) &&
+		    !addr_is_local(&ifp->addr) &&
 		    fixup_permanent_addr(idev, ifp) < 0) {
 			write_unlock_bh(&idev->lock);
 			ipv6_del_addr(ifp);
@@ -3448,12 +3455,6 @@ static void addrconf_type_change(struct net_device *dev, unsigned long event)
 		ipv6_mc_unmap(idev);
 }
 
-static bool addr_is_local(const struct in6_addr *addr)
-{
-	return ipv6_addr_type(addr) &
-		(IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK);
-}
-
 static int addrconf_ifdown(struct net_device *dev, int how)
 {
 	struct net *net = dev_net(dev);
-- 
1.7.10.4

^ permalink raw reply related

* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Christoph Hellwig @ 2016-04-18 14:32 UTC (permalink / raw)
  To: Eli Cohen
  Cc: Sinan Kaya, linux-rdma, timur, cov, Yishai Hadas, netdev,
	linux-kernel
In-Reply-To: <20160418065447.GA11539@x-vnc01.mtx.labs.mlnx>

On Mon, Apr 18, 2016 at 09:54:47AM +0300, Eli Cohen wrote:
> Sinan,
> 
> if we get rid of the part this code:
> 
>                 if (BITS_PER_LONG == 64) {
>                         struct page **pages;
>                         pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
>                         if (!pages)
>                                 goto err_free;
>                         ...
>                         ...
>                         if (!buf->direct.buf)
>                                 goto err_free;
>                 }
> 
> Does that solve the arm issue?

Not quite.  You still have code in mlx4_en_map_buffer that performs
this mapping later if it it wasn't mapped in mlx4_buf_alloc.

You'll need to get rid of that by ensuring max_direct for all the cases
currently using mlx4_en_map_buffer as well.

^ permalink raw reply

* Re: [PATCH v5 2/4] Documentation: Bindings: Add STM32 DWMAC glue
From: Giuseppe CAVALLARO @ 2016-04-18 14:34 UTC (permalink / raw)
  To: Alexandre Torgue, Joachim Eastwood
  Cc: Rob Herring, Chen-Yu Tsai, Maxime Coquelin, netdev, devicetree,
	linux-kernel, linux-arm-kernel
In-Reply-To: <CAJgp7zxfFRhfNjcE23n+DKD0ffrvH4_sowPjK_-DZAS4ecH5dg@mail.gmail.com>

On 3/22/2016 5:11 PM, Alexandre Torgue wrote:
> Hi guys,
>
> I will fix typo issues (s/vesrion/version and ethernet @).
>
> Concerning compatible string. For sure "snps,dwmac-3.50a" string is
> not used inside glue driver.
> I perfere to keep it for information but if you really want that I
> remove it I will not block ;)
>
> 2016-03-21 16:36 GMT+01:00 Joachim  Eastwood <manabian@gmail.com>:
>> On 21 March 2016 at 13:40, Rob Herring <robh@kernel.org> wrote:
>>> On Sat, Mar 19, 2016 at 12:00:22AM +0800, Chen-Yu Tsai wrote:
>>>> Hi,
>>>>
>>>> On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE
>>>> <alexandre.torgue@gmail.com> wrote:
>>>>> +- clocks: Must contain a phandle for each entry in clock-names.
>>>>> +- clock-names: Should be "stmmaceth" for the host clock.
>>>
> We can remove host clock (stmmac eth) entry here and refer to
> stmmac.txt binding for common entry
>
>>> This doesn't sound like the clock input signal name...
>>>
>>>>> +              Should be "tx-clk" for the MAC TX clock.
>>>>> +              Should be "rx-clk" for the MAC RX clock.
>>>
>>> How can other DWMAC blocks not have these clocks? The glue can't really
>>> add these clocks. It could combine them into one or a new version of
>>> DWMAC could have a different number of clock inputs. So if there is
>>> variation here, then some of the bindings are probably wrong. I guess
>>> the only change I'm suggesting is possibly moving these into common
>>> binding doc.
>>
>> The LPC18xx implementation probably have these clocks as well but the
>> LPC1850 user manual only documents the main clock. Someone with access
>> to the IP block doc from Synopsys should be able to check which clocks
>> the MAC really needs.
>>
>> Rockchip bindings have two clocks named "mac_clk_rx" and "mac_clk_tx".
>> These are probably the same as stm32 needs so maybe use these names
>> and move them into the main doc and update the rockchip binding.
>>
> I think we can use same name. But I have a doubt on moving it in a
> common bindings (maybe I don't well understood). When you say "common
> binding file" is it "stmmac.txt" binding ? If yes does it mean that we
> have to control it inside stmmac driver (no more in glue) ? In this
> case those clocks will become "required" for stm32 and rockship but
> not for others chip. It could create confusion?

Currently we keep the "host" and "csr" " ptp  "clock from common
bindings because directly connected to the either MAC core or optional
internals modules.
Indeed, also clk_tx_i and clk_rx_i could be treated in the same way.
but... (my personal view).
Many platforms, also inside STi, have different clock routing schema,
so we could relax them giving each glue the way to internally manage
all (as done nowadays).
So these clocks can stay inside the glue and documented inside each
binding doc. Maybe, it could be not so easy to have generic schema
suitable for all the glues so documenting all inside the same binding
text file.
We could try to better name these clocks in each glue. For example, for
this, although I do not know the clk schema, I can image a single
rmii_clk (maybe from internal oscillator) that is connected to
clk_tx_i and clk_rx_i. So it could be useless to pass both. Please
let me know if I am wrong...
In case of (G)MII, we should use something like (g)mii_tx_clk,
(g)mii_rx_clk according to the real connections (if from
an internal oscillator and not from an ext one connected to the phy).

Regards,
Peppe


> Best regards
>
> Alex
>
>>
>> regards,
>> Joachim Eastwood
>

^ permalink raw reply

* Re: [PATCH] net: ipv6: Do not fix up linklocal and loopback addresses
From: David Ahern @ 2016-04-18 14:39 UTC (permalink / raw)
  To: Mike Manning, netdev
In-Reply-To: <5714EDDB.8080306@brocade.com>

On 4/18/16 8:23 AM, Mike Manning wrote:
> f1705ec197e7 "Make address flushing on ifdown optional" added the option
> to retain user configured addresses on an admin down. A comment to one of
> the later revisions suggested using the IFA_F_PERMANENT flag rather than
> adding a user_managed boolean to the ifaddr struct. A side effect of this
> change is that link local and loopback addresses were also retained which
> was not part of the objective of the original changes. The fix 70af921db6f8
> "Do not keep linklocal and loopback addresses" ensures that these are no
> longer kept. Similarly, the present fix ensures that these addresses are not
> fixed up either, otherwise the incorrect fixup triggers a crash in fib6.
>
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
> Signed-off-by: Mike Manning <mmanning@brocade.com>
> ---
>   net/ipv6/addrconf.c |   13 +++++++------
>   1 file changed, 7 insertions(+), 6 deletions(-)

Is this a v2? Code change is the same.

Acked-by: David Ahern <dsa@cumulusnetworks.com>

^ permalink raw reply

* RE: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Eli Cohen @ 2016-04-18 14:39 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Sinan Kaya, linux-rdma@vger.kernel.org, timur@codeaurora.org,
	cov@codeaurora.org, Yishai Hadas, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <20160418143255.GA15203@infradead.org>

Right, I did not suggest this as a patch but just wanted to pinpoint the problematic issue which is that virt_to_page does not give you the correct pointer to the page.

-----Original Message-----
From: Christoph Hellwig [mailto:hch@infradead.org] 
Sent: Monday, April 18, 2016 9:33 AM
To: Eli Cohen <eli@mellanox.com>
Cc: Sinan Kaya <okaya@codeaurora.org>; linux-rdma@vger.kernel.org; timur@codeaurora.org; cov@codeaurora.org; Yishai Hadas <yishaih@mellanox.com>; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On Mon, Apr 18, 2016 at 09:54:47AM +0300, Eli Cohen wrote:
> Sinan,
> 
> if we get rid of the part this code:
> 
>                 if (BITS_PER_LONG == 64) {
>                         struct page **pages;
>                         pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
>                         if (!pages)
>                                 goto err_free;
>                         ...
>                         ...
>                         if (!buf->direct.buf)
>                                 goto err_free;
>                 }
> 
> Does that solve the arm issue?

Not quite.  You still have code in mlx4_en_map_buffer that performs this mapping later if it it wasn't mapped in mlx4_buf_alloc.

You'll need to get rid of that by ensuring max_direct for all the cases currently using mlx4_en_map_buffer as well.

^ permalink raw reply

* Re: [PATCH net-next 2/5] qede: Add support for ethtool private flags
From: Yuval Mintz @ 2016-04-18 14:34 UTC (permalink / raw)
  To: Sergei Shtylyov, David Miller, netdev
In-Reply-To: <5714EB23.5020102@cogentembedded.com>

>> +     flags |= (!!(edev->dev_info.common.num_hwfns > 1)) <<
>> +              QEDE_PRI_FLAG_CMT;

>  Why not just '='?

>> +
>> +     return flags;

>  ... or direct return of the value above?

Probably wanted to lay the basis for future flags.
But you're right in that there's no need for it.
I'll change it in V2.

Thanks,
Yuval

^ permalink raw reply

* [PATCH 0/5] add __init attribute
From: Julia Lawall @ 2016-04-18 14:55 UTC (permalink / raw)
  To: netdev
  Cc: kernel-janitors, linux-kernel, linux-clk, linux-arm-kernel,
	linux-mediatek, linux-ide, Josh Triplett, Luis R . Rodriguez

Add __init attribute on a function that is only called from other __init
functions and that is not inlined.

The complete semantic patch used to detect the need for this change is
below (http://coccinelle.lip6.fr/).  This semantic patch checks for local
static non-init functions that are called from an __init function and are
not called from any other function.

<smpl>
@initialize:ocaml@
@@

let itbl = Hashtbl.create 101
let ltbl = Hashtbl.create 101
let thefile = ref ""

let hashadd t k =
  let cell =
    try Hashtbl.find t k
    with Not_found ->
      let cell = ref 0 in
      Hashtbl.add t k cell;
      cell in
  cell := !cell + 1

let hashget t k = try !(Hashtbl.find t k) with Not_found -> 0

let seen  = ref []

@script:ocaml@
@@

(let file = List.hd (Coccilib.files()) in
thefile := file;
let file =
    try List.hd(List.tl (Str.split (Str.regexp "/linux-next/") file))
    with _ -> file in
let ofile = "/var/julia/linux-next/" ^
      (Filename.chop_extension file) ^ ".o" in
if not(Sys.file_exists ofile)
then Coccilib.exit());

Hashtbl.clear itbl;
Hashtbl.clear ltbl;
seen := []

@r@
identifier f;
@@

__init f(...) { ... }

@script:ocaml@
f << r.f;
@@

Hashtbl.add itbl f ()

@s disable optional_attributes@
identifier f;
@@

static f(...) { ... }

@script:ocaml@
f << s.f;
@@

Hashtbl.add ltbl f ()

@t exists@
identifier f,g;
position p;
@@

__init f(...) { ... when any
   g@p(...)
   ... when any
 }

@script:ocaml@
g << t.g;
_p << t.p;
@@

if not (Hashtbl.mem ltbl g) || Hashtbl.mem itbl g
then Coccilib.include_match false

@ok1 disable optional_attributes exists@
identifier f,t.g;
@@

f(...) { ... when any
   g
   ... when any
 }

@ok2 disable optional_attributes exists@
identifier i,j,fld,t.g;
@@

struct i j = { .fld = g, };

@ok3 disable optional_attributes exists@
identifier t.g;
declarer d;
@@

d(...,g,...);

@ok4 disable optional_attributes exists@
identifier t.g;
expression e;
@@

(
e(...,g,...)
|
e(...,&g,...)
|
e = &g
|
e = g
)

@script:ocaml depends on !ok1 && !ok2 && !ok3 && !ok4@
g << t.g;
@@

let file = !thefile in
let file =
    try List.hd(List.tl (Str.split (Str.regexp "/linux-next/") file))
    with _ -> file in
if not(List.mem (g,file) !seen)
then
  begin
    seen := (g,file) :: !seen;
    let ofile = "/var/julia/linux-next/" ^
      (Filename.chop_extension file) ^ ".o" in
    if Sys.file_exists ofile
    then
      let l =
	Common.cmd_to_list
	  (Printf.sprintf
	     "objdump -x %s | grep -w %s | grep -w F | grep .text.unlikely"
	     ofile g) in
      match l with
	[] -> Coccilib.include_match false
      | _ ->
	  Printf.printf "Info for %s %s\n" file g;
	  List.iter
	    (function l -> Printf.printf "%s\n" l)
	    l;
	  Printf.printf "\n"; flush stdout
    else Coccilib.include_match false
  end
else Coccilib.include_match false

@depends on !ok1 && !ok2 && !ok3 && !ok4@
identifier t.g;
@@

- g
+__init g
 (...) { ... }
</smpl>

---

 drivers/clk/clk-qoriq.c         |    3 ++-
 drivers/clocksource/mtk_timer.c |    2 +-
 drivers/ide/cmd640.c            |    2 +-
 drivers/net/arcnet/com90xx.c    |    2 +-
 drivers/tty/rocket.c            |    3 ++-
 5 files changed, 7 insertions(+), 5 deletions(-)

^ permalink raw reply

* [PATCH 2/5] arcnet: com90xx: add __init attribute
From: Julia Lawall @ 2016-04-18 14:55 UTC (permalink / raw)
  To: Michael Grzeschik
  Cc: kernel-janitors, netdev, linux-kernel, Luis R . Rodriguez,
	Josh Triplett
In-Reply-To: <1460991338-9845-1-git-send-email-Julia.Lawall@lip6.fr>

Add __init attribute on a function that is only called from other __init
functions and that is not inlined, at least with gcc version 4.8.4 on an
x86 machine with allyesconfig.  Currently, the function is put in the
.text.unlikely segment.  Declaring it as __init will cause it to be put in
the .init.text and to disappear after initialization.

The result of objdump -x on the function before the change is as follows:

0000000000000000 l     F .text.unlikely 00000000000000bf check_mirror

And after the change it is as follows:

0000000000000000 l     F .init.text	00000000000000ba check_mirror

Done with the help of Coccinelle.  The semantic patch checks for local
static non-init functions that are called from an __init function and are
not called from any other function.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>

---
 drivers/net/arcnet/com90xx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/arcnet/com90xx.c b/drivers/net/arcnet/com90xx.c
index 0d9b45f..81f90c4 100644
--- a/drivers/net/arcnet/com90xx.c
+++ b/drivers/net/arcnet/com90xx.c
@@ -433,7 +433,7 @@ static void __init com90xx_probe(void)
 	kfree(iomem);
 }
 
-static int check_mirror(unsigned long addr, size_t size)
+static int __init check_mirror(unsigned long addr, size_t size)
 {
 	void __iomem *p;
 	int res = -1;

^ permalink raw reply related

* Re: [PATCHv2] wlcore: spi: add wl18xx support
From: Arnd Bergmann @ 2016-04-18 14:57 UTC (permalink / raw)
  To: Reizer, Eyal
  Cc: Kalle Valo, Eyal Reizer, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, linux-spi@vger.kernel.org
In-Reply-To: <8665E2433BC68541A24DFFCA87B70F5B360BF614@DFRE01.ent.ti.com>

On Monday 18 April 2016 05:55:51 Reizer, Eyal wrote:
> > >
> > > - all wilink family needs special init command for entering wspi mode.
> > >   extra clock cycles should be sent after the spi init command while the
> > >   cs pin is high.
> > > - switch to controling the cs pin from the spi driver for achieveing the
> > >   above.
> > > - the selected cs gpio is read from the spi device-tree node using the
> > >   cs-gpios field and setup as a gpio.
> > > - See the example below for specifying the cs gpio using the cs-gpios entry
> > > &spi0   {
> > >         ...
> > >         cs-gpios = <&gpio0 5 0>;
> > >         ...
> > >         wlcore: wlcore@0 {
> > >                 compatible = "ti,wl1835";
> > >         ...
> > >         ...
> > >         };
> > > };
> > >
> > > Signed-off-by: Eyal Reizer <eyalr@ti.com>
> > 
> > I don't think this can work in general: not all SPI hosts uses GPIOs for
> > controlling CS, so the logic can't work, and it's also a layering violation for the
> > driver to look at the parent.
> > 
> > I would suggest fixing this using a new API function from the SPI core, if we
> > don't already have a generic way to do it.
> >
> Originally this is what I have done until I was pointed to the generic cs-gpio mechanism 
> in the SPI core. 
> It is a generic mechanism already in the SPI core driver.
> See: Documentation/devicetree/bindings/spi/spi-bus.txt

The cs-gpios property is documented as optional, it defines how you should
list the gpios if CS is implemented using gpio, but not all hardware does
it like this.

> It is also part of the generic spi.h (include/Linux/spi/spi.h), already part of 
> " struct spi_device" So it seemed redundant adding another mechanism for 
> implementing the same.
> Platform that interact with a wilink need to use it, and platforms that don't  
> have this capability will probably not interact with a wilink device using SPI.

The cs_gpio field in spi_device belongs to the spi host controller, no other
slave driver uses it.

I wasn't asking for a duplication of this mechanism, but an interface to
use it properly. Internally, the spi core uses the spi_set_cs() function to
pick a CS. Find a way to use that rather than reimplementing it incorrectly.

	Arnd

^ permalink raw reply

* Re: [PATCH bluetooth-next 09/10] 6lowpan: introduce 6lowpan-nd
From: kbuild test robot @ 2016-04-18 15:04 UTC (permalink / raw)
  To: Alexander Aring
  Cc: kbuild-all, linux-wpan, kernel, marcel, jukka.rissanen, hannes,
	stefan, mcr, werner, linux-bluetooth, netdev, Alexander Aring,
	David S . Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1460977108-4675-10-git-send-email-aar@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

Hi Alexander,

[auto build test ERROR on bluetooth-next/master]

url:    https://github.com/0day-ci/linux/commits/Alexander-Aring/6lowpan-introduce-basic-6lowpan-nd/20160418-191825
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master
config: i386-randconfig-a0-04181351 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "ipv6_get_lladdr" [net/6lowpan/6lowpan.ko] undefined!
>> ERROR: "inet6_ifa_finish_destroy" [net/6lowpan/6lowpan.ko] undefined!
>> ERROR: "rt6_clean_tohost" [net/6lowpan/6lowpan.ko] undefined!
>> ERROR: "ipv6_chk_acast_addr" [net/6lowpan/6lowpan.ko] undefined!
>> ERROR: "addrconf_dad_failure" [net/6lowpan/6lowpan.ko] undefined!

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 23939 bytes --]

^ permalink raw reply

* Re: [PATCH] net: ipv6: Do not fix up linklocal and loopback addresses
From: Mike Manning @ 2016-04-18 15:14 UTC (permalink / raw)
  To: David Ahern, netdev
In-Reply-To: <5714F199.7020608@cumulusnetworks.com>

On 04/18/2016 03:39 PM, David Ahern wrote:
> On 4/18/16 8:23 AM, Mike Manning wrote:
>> f1705ec197e7 "Make address flushing on ifdown optional" added the option
>> to retain user configured addresses on an admin down. A comment to one of
>> the later revisions suggested using the IFA_F_PERMANENT flag rather than
>> adding a user_managed boolean to the ifaddr struct. A side effect of this
>> change is that link local and loopback addresses were also retained which
>> was not part of the objective of the original changes. The fix 70af921db6f8
>> "Do not keep linklocal and loopback addresses" ensures that these are no
>> longer kept. Similarly, the present fix ensures that these addresses are not
>> fixed up either, otherwise the incorrect fixup triggers a crash in fib6.
>>
>> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
>> Signed-off-by: Mike Manning <mmanning@brocade.com>
>> ---
>>   net/ipv6/addrconf.c |   13 +++++++------
>>   1 file changed, 7 insertions(+), 6 deletions(-)
> 
> Is this a v2? Code change is the same.

This is the same changeset, but Sergei requested on Saturday to change the wording as follows:


    scripts/checkpatch.pl now enforces commit citing certain style: <12-digit 

SHA1> ("<comit summary>").



> 
> Acked-by: David Ahern <dsa@cumulusnetworks.com>

^ permalink raw reply

* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Timur Tabi @ 2016-04-18 15:15 UTC (permalink / raw)
  To: Sinan Kaya, Christoph Hellwig
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, cov-sgV2jX0FEOL9JmXXK+q4OQ,
	Yishai Hadas, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5714E5D6.7050600-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

Sinan Kaya wrote:
>
> VMAP allows you to make several pages look contiguous to the CPU.
> It can only be used against logical addresses returned from kmalloc
> or alloc_page.
>
> You cannot take several virtually mapped addresses returned by dma_alloc_coherent
> and try to make them virtually contiguous again.
>
> The code happens to work on other architectures by pure luck. AFAIK, dma_alloc_coherent
> returns logical addresses on Intel systems until it runs out of DMA memory. After
> that intel arch will also start returning virtually mapped addresses and this code
> will also fail. ARM64 on the other hand always returns a virtually mapped address.
>
> The goal of this code is to allocate a bunch of page sized memory and make it look
> contiguous. It is just using the wrong API. The correct API is either kmalloc or
> alloc_page map it with dma_map_page not dma_alloc_coherent.
>
> The proper usage of dma_map_page requires code to call dma_sync API in correct
> places to be compatible with noncoherent systems. This code is already assuming
> coherency. It would be a nice to have dma_sync APIs in right places. There is no
> harm in calling dma_sync API for coherent systems as they are no-ops in DMA mapping
> layer whereas it is a cache flush for non-coherent systems.

The text would be a great addition to the patch description.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation collaborative project.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Christoph Hellwig @ 2016-04-18 15:17 UTC (permalink / raw)
  To: Eli Cohen
  Cc: Christoph Hellwig, Sinan Kaya,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Yishai Hadas,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <DB5PR05MB1848424EC9DC8D4150EADB03C56B0-8IvNv+8VlcDdorXcTtKhldqRiQSDpxhJvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>

On Mon, Apr 18, 2016 at 02:39:36PM +0000, Eli Cohen wrote:
> Right, I did not suggest this as a patch but just wanted to pinpoint the problematic issue which is that virt_to_page does not give you the correct pointer to the page.

Removing both the virt_to_page + vmap calls would solve the issue
indeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] net: ipv6: Do not fix up linklocal and loopback addresses
From: Sergei Shtylyov @ 2016-04-18 15:19 UTC (permalink / raw)
  To: Mike Manning, netdev
In-Reply-To: <5714EDDB.8080306@brocade.com>

Hello.

On 4/18/2016 5:23 PM, Mike Manning wrote:

> f1705ec197e7 "Make address flushing on ifdown optional" added the option

    Looking further, this doesn't seem like a complete commit summary. And you 
need to enclose it in parens too.

> to retain user configured addresses on an admin down. A comment to one of
> the later revisions suggested using the IFA_F_PERMANENT flag rather than
> adding a user_managed boolean to the ifaddr struct. A side effect of this
> change is that link local and loopback addresses were also retained which
> was not part of the objective of the original changes. The fix 70af921db6f8
> "Do not keep linklocal and loopback addresses" ensures that these are no

    Again, () are needed around the summary.

> longer kept. Similarly, the present fix ensures that these addresses are not
> fixed up either, otherwise the incorrect fixup triggers a crash in fib6.
>
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
> Signed-off-by: Mike Manning <mmanning@brocade.com>
[...]

MBR, Sergei

^ permalink raw reply

* [PATCH net-next] macvlan: fix failure during registration
From: Francesco Ruggeri @ 2016-04-18 15:20 UTC (permalink / raw)
  To: netdev
  Cc: David S. Miller, Eric W. Biederman, Mahesh Bandewar,
	Francesco Ruggeri

Resending, did not include netdev the first time ...

If a macvlan/macvtap creation fails in register_netdevice in
call_netdevice_notifiers(NETDEV_REGISTER) then while cleaning things up in
rollback_registered_many it invokes macvlan_uninit. This results in
port->count being decremented twice (in macvlan_uninit and in
macvlan_common_newlink).
A similar problem may exist in the ipvlan driver.
This patch adds priv_flags to struct macvlan_dev and a flag that
macvlan_uninit can use to determine if it is invoked in the context of a
failed newlink.
In macvtap_device_event(NETDEV_UNREGISTER) it also avoids cleaning up
/dev/tapNN in case creation of the char device had previously failed.
Tested in 3.18.
The failure can be reproduced by running the script below a few times. The
script creates macvtap interfaces in different namespaces causing along the
way sysfs_warn_dup failures in macvtap_device_event(NETDEV_REGISTER)
because of conflicting ifindexes, and finally a panic or
"unregister_netdevice: waiting for ddev to become free".

for ((ns=1; ns<3; ns++))
do
  ip netns add ns${ns}
  ip netns exec ns${ns} ip link add dev ddev type dummy
done

for ((ns=1; ns<3; ns++))
do
  for ((mv=0; mv<2; mv++))
  do
    ret=1
    while [ ${ret} != 0 ]
    do
      ip netns exec ns${ns} ip link add link ddev name \
                        macvtap${ns}${mv} type macvtap
      ret=$?
    done &
  done
done

sleep 5
ls /dev/tap*

for ((ns=1; ns<3; ns++))
do
  ip netns exec ns${ns} ip link del ddev &
done

sleep 2
ls /dev/tap*

for ((ns=1; ns<3; ns++))
do
  ip netns del ns${ns}
done

Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
---
 drivers/net/macvlan.c      | 11 ++++++++---
 drivers/net/macvtap.c      |  2 ++
 include/linux/if_macvlan.h |  3 +++
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2bcf1f3..11065af 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -823,9 +823,12 @@ static void macvlan_uninit(struct net_device *dev)
 	free_percpu(vlan->pcpu_stats);
 
 	macvlan_flush_sources(port, vlan);
-	port->count -= 1;
-	if (!port->count)
-		macvlan_port_destroy(port->dev);
+
+	if (!(vlan->priv_flags & MACVLAN_PRIV_FLAG_REGISTERING)) {
+		port->count -= 1;
+		if (!port->count)
+			macvlan_port_destroy(port->dev);
+	}
 }
 
 static struct rtnl_link_stats64 *macvlan_dev_get_stats64(struct net_device *dev,
@@ -1313,7 +1316,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
 	}
 
 	port->count += 1;
+	vlan->priv_flags |= MACVLAN_PRIV_FLAG_REGISTERING;
 	err = register_netdevice(dev);
+	vlan->priv_flags &= ~MACVLAN_PRIV_FLAG_REGISTERING;
 	if (err < 0)
 		goto destroy_port;
 
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 95394ed..e770221 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -1303,6 +1303,8 @@ static int macvtap_device_event(struct notifier_block *unused,
 		}
 		break;
 	case NETDEV_UNREGISTER:
+		if (vlan->minor == 0)
+			break;
 		devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
 		device_destroy(macvtap_class, devt);
 		macvtap_free_minor(vlan);
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index a4ccc31..7cf82d8 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -48,6 +48,7 @@ struct macvlan_dev {
 	netdev_features_t	set_features;
 	enum macvlan_mode	mode;
 	u16			flags;
+	u16			priv_flags;
 	/* This array tracks active taps. */
 	struct macvtap_queue	__rcu *taps[MAX_MACVTAP_QUEUES];
 	/* This list tracks all taps (both enabled and disabled) */
@@ -63,6 +64,8 @@ struct macvlan_dev {
 	unsigned int		macaddr_count;
 };
 
+#define MACVLAN_PRIV_FLAG_REGISTERING	1
+
 static inline void macvlan_count_rx(const struct macvlan_dev *vlan,
 				    unsigned int len, bool success,
 				    bool multicast)
-- 
1.8.1.4

^ permalink raw reply related

* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Sinan Kaya @ 2016-04-18 15:21 UTC (permalink / raw)
  To: Christoph Hellwig, Eli Cohen
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Yishai Hadas,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20160418151702.GA26565-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

On 4/18/2016 11:17 AM, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 02:39:36PM +0000, Eli Cohen wrote:
>> Right, I did not suggest this as a patch but just wanted to pinpoint the problematic issue which is that virt_to_page does not give you the correct pointer to the page.
> 
> Removing both the virt_to_page + vmap calls would solve the issue
> indeed.
> 

I was looking at the code. I don't see how removing virt_to_page + vmap 
would solve the issue.

The code is trying to access the buffer space with direct.buf member
from the CPU side. This member would become NULL, when this code is 
removed and also in mlx4_en_map_buffer. 


                if (BITS_PER_LONG == 64) {
                        struct page **pages;
                        pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
                        if (!pages)
                                goto err_free;
                        ...
                        ...
                        if (!buf->direct.buf)
                                goto err_free;
                }

drivers/net/ethernet/mellanox/mlx4/en_tx.c (2 hits)
Line 110: ring->buf = ring->wqres.buf.direct.buf;
Line 114: (unsigned long long) ring->wqres.buf.direct.map);

drivers/net/ethernet/mellanox/mlx4/en_rx.c (1 hit)
Line 404: ring->buf = ring->wqres.buf.direct.buf;

drivers/net/ethernet/mellanox/mlx4/en_cq.c (1 hit)
Line 85: cq->buf = (struct mlx4_cqe *)cq->wqres.buf.direct.buf;

What am I missing?

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Sinan Kaya @ 2016-04-18 15:22 UTC (permalink / raw)
  To: Timur Tabi, Christoph Hellwig
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, cov-sgV2jX0FEOL9JmXXK+q4OQ,
	Yishai Hadas, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5714FA2C.4030209-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

On 4/18/2016 11:15 AM, Timur Tabi wrote:
> Sinan Kaya wrote:
>>
>> VMAP allows you to make several pages look contiguous to the CPU.
>> It can only be used against logical addresses returned from kmalloc
>> or alloc_page.
>>
>> You cannot take several virtually mapped addresses returned by dma_alloc_coherent
>> and try to make them virtually contiguous again.
>>
>> The code happens to work on other architectures by pure luck. AFAIK, dma_alloc_coherent
>> returns logical addresses on Intel systems until it runs out of DMA memory. After
>> that intel arch will also start returning virtually mapped addresses and this code
>> will also fail. ARM64 on the other hand always returns a virtually mapped address.
>>
>> The goal of this code is to allocate a bunch of page sized memory and make it look
>> contiguous. It is just using the wrong API. The correct API is either kmalloc or
>> alloc_page map it with dma_map_page not dma_alloc_coherent.
>>
>> The proper usage of dma_map_page requires code to call dma_sync API in correct
>> places to be compatible with noncoherent systems. This code is already assuming
>> coherency. It would be a nice to have dma_sync APIs in right places. There is no
>> harm in calling dma_sync API for coherent systems as they are no-ops in DMA mapping
>> layer whereas it is a cache flush for non-coherent systems.
> 
> The text would be a great addition to the patch description.
> 

I can do that on the next version.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH] net: ipv6: Do not fix up linklocal and loopback addresses
From: Mike Manning @ 2016-04-18 15:28 UTC (permalink / raw)
  To: netdev
In-Reply-To: <5714EDDB.8080306@brocade.com>

f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional") added
the option to retain user configured addresses on an admin down. A comment
to one of the later revisions suggested using the IFA_F_PERMANENT flag rather
than adding a user_managed boolean to the ifaddr struct. A side effect of
this change is that link local and loopback addresses were also retained which
was not part of the objective of the original changes. The fix 70af921db6f8
("net: ipv6: Do not keep linklocal and loopback addresses") ensures that these
are no longer kept. Similarly, the present fix ensures that these addresses
are not fixed up, otherwise the incorrect fixup triggers a crash in fib6.

Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning <mmanning@brocade.com>
---
 net/ipv6/addrconf.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 23cec53..cba4e10 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3200,6 +3200,12 @@ static void l3mdev_check_host_rt(struct inet6_dev *idev,
 }
 #endif
 
+static bool addr_is_local(const struct in6_addr *addr)
+{
+	return ipv6_addr_type(addr) &
+		(IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK);
+}
+
 static int fixup_permanent_addr(struct inet6_dev *idev,
 				struct inet6_ifaddr *ifp)
 {
@@ -3238,6 +3244,7 @@ static void addrconf_permanent_addr(struct net_device *dev)
 
 	list_for_each_entry_safe(ifp, tmp, &idev->addr_list, if_list) {
 		if ((ifp->flags & IFA_F_PERMANENT) &&
+		    !addr_is_local(&ifp->addr) &&
 		    fixup_permanent_addr(idev, ifp) < 0) {
 			write_unlock_bh(&idev->lock);
 			ipv6_del_addr(ifp);
@@ -3448,12 +3455,6 @@ static void addrconf_type_change(struct net_device *dev, unsigned long event)
 		ipv6_mc_unmap(idev);
 }
 
-static bool addr_is_local(const struct in6_addr *addr)
-{
-	return ipv6_addr_type(addr) &
-		(IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK);
-}
-
 static int addrconf_ifdown(struct net_device *dev, int how)
 {
 	struct net *net = dev_net(dev);
-- 
1.7.10.4

^ permalink raw reply related

* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Christoph Hellwig @ 2016-04-18 15:40 UTC (permalink / raw)
  To: Sinan Kaya
  Cc: Christoph Hellwig, Eli Cohen,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Yishai Hadas,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5714FB68.3020604-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

On Mon, Apr 18, 2016 at 11:21:12AM -0400, Sinan Kaya wrote:
> I was looking at the code. I don't see how removing virt_to_page + vmap 
> would solve the issue.
> 
> The code is trying to access the buffer space with direct.buf member
> from the CPU side. This member would become NULL, when this code is 
> removed and also in mlx4_en_map_buffer. 
>
> ...
>
> What am I missing?

As mentioned before you'll also need to enforce you hit the nbufs = 1
case for these.  In fact most callers should simply switch to a plain
dma_zalloc_coherent call without all these wrappers.  If we have a case
where we really want multiple buffers that don't have to be contiguous
(maybe the MTT case) I'd rather opencode that instead of building this
confusing interface on top of it.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2] carl9170: Clarify kconfig text
From: Kalle Valo @ 2016-04-18 15:45 UTC (permalink / raw)
  To: Lauri Kasanen
  Cc: Christian Lamparter, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160416171856.1769c0e16bcc75372407e06f-KK0ffGbhmjU@public.gmane.org>

Lauri Kasanen <cand-KK0ffGbhmjU@public.gmane.org> writes:

> The previous text was confusing, leading readers to think this
> driver was a duplicate, and so didn't need to be enabled.
>
> After the removal of the older staging driver, this is the only
> driver in mainline for these devices.
>
> Signed-off-by: Lauri Kasanen <cand-KK0ffGbhmjU@public.gmane.org>
> ---
> v2: Remove the mention of the previous driver, suggested by Christian.
>
>  drivers/net/wireless/ath/carl9170/Kconfig | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/carl9170/Kconfig b/drivers/net/wireless/ath/carl9170/Kconfig
> index 1a796e5..2e34bae 100644
> --- a/drivers/net/wireless/ath/carl9170/Kconfig
> +++ b/drivers/net/wireless/ath/carl9170/Kconfig
> @@ -5,12 +5,10 @@ config CARL9170
>  	select FW_LOADER
>  	select CRC32
>  	help
> -	  This is another driver for the Atheros "otus" 802.11n USB devices.
> +	  This is the mainline driver for the Atheros "otus" 802.11n USB devices.
>  
> -	  This driver provides more features than the original,
> -	  but it needs a special firmware (carl9170-1.fw) to do that.
> -
> -	  The firmware can be downloaded from our wiki here:
> +	  It needs a special firmware (carl9170-1.fw), which can be downloaded
> +	  from our wiki here:
>  	  <http://wireless.kernel.org/en/users/Drivers/carl9170>

Why even mention anything about a "special firmware" as the firmware is
already available from linux-firmware.git? That's default location for
all firmware images and I think most, if not all, distros should have it
available. So wouldn't it be better not to mention anything about
firmware at all?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* switchdev fib offload issues
From: Jiri Pirko @ 2016-04-18 15:47 UTC (permalink / raw)
  To: netdev
  Cc: davem, idosch, eladr, yotamg, ogerlitz, roopa, nikolay, jhs,
	john.fastabend, rami.rosen, gospo, stephen, sfeldma, dsa,
	f.fainelli, andrew, vivien.didelot, tgraf, aduyck

Hi all.

The current situation of fib offloading is not good, I believe we need
to make some changes, therefore I'm writing this email. Please read,
think and comment.

Currently what we have is that for every fib entry inserted into a table,
there is a call to switchdev:
 fib_table_insert->switchdev_fib_ipv4_add
Driver then pushes fib entry down to HW. So far good.

However, if for any reason the switchdev add operation fails, there is an
abort function called (switchdev_fib_ipv4_abort). This function does two
things which are both unfortunate in many usecases:
1) evicts all fib entries from HW leaving all processing done in kernel
    - For Spectrum ASIC this means that all traffic running at 100G between
      all ports is immediately downgraded to ~1-3Gbits
    - Also this happens silently, user knows nothing about anything went wrong,
      only forwarding performance suddenly sucks.

2) sets net->ipv4.fib_offload_disabled = true
    - That results in no other fib entry being offloaded, forever,
      until net is removed and added again, machine reboot is required
      in case if init_ns

These 2 issues makes fib offload completely unusable. So I propose
to start thinking about fixing this.

I believe that although the current behaviour might be good for default,
user should be able to change it by setting a different policy. This
policy will allow to propagate offload error to user.

Note that user already has to handle fib add errors which are independent
on particular fib entry. That is a case of insufficient memory (-ENOBUFS).
In fact, when offload fails, that is most likely also due to insufficient
resources in HW.

Proposed solutions (ideas):
1) per-netns. Add a procfs file:
	/proc/sys/net/ipv4/route/fib_offload_error_policy
	  with values: "evict" - default, current behaviour
                       "fail" - propagate offload error to user
	The policy value would be stored in struct net.

2) per-VRF/table
	When user creates a VRF master, he specifies a table ID
	this VRF is going to use. I propose to extend this so
	he can pass a policy ("evict"/"fail").
	The policy value would be stored in struct fib_table or
	struct fib6_table. The problem is that vfr only saves
	table ID, allocates dst but does not actually create
	table. That might be created later. But I think this
	could be resolved.

3) per-VFR/master_netdev
	In this case, the policy would be also set during
	the creation of VFR master. From user perspective,
	this looks same as 2)
	The policy value would be stored in struct net_vrf (vrf private).

Thoughts?

Thanks!

Jiri

^ permalink raw reply

* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: David Miller @ 2016-04-18 15:59 UTC (permalink / raw)
  To: okaya-sgV2jX0FEOL9JmXXK+q4OQ
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
	cov-sgV2jX0FEOL9JmXXK+q4OQ, yishaih-VPRAkNaXOzVWk0Htik3J/w,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87c17d3f979cf0167cd37077f39d0534-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

From: okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
Date: Mon, 18 Apr 2016 01:06:27 -0400

> On 2016-04-18 00:00, David Miller wrote:
>> From: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Date: Sat, 16 Apr 2016 18:23:32 -0400
>> 
>>> Current code is assuming that the address returned by
>>> dma_alloc_coherent
>>> is a logical address. This is not true on ARM/ARM64 systems. This
>>> patch
>>> replaces dma_alloc_coherent with dma_map_page API. The address
>>> returned
>>> can later by virtually mapped from the CPU side with vmap API.
>>> Signed-off-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> You can't do this.
>> The DMA map page API gives non-coherent mappings, and thus requires
>> proper flushing.
>> So a straight conversion like this is never legitimate.
> 
> I would agree on proper dma api usage. However, the code is already
> assuming coherent architecture by mapping the cpu pages as
> page_kernel.
> 
> Dma_map_page returns cached buffers and you don't need cache flushes
> on coherent architecture to make the data visible.

All you are telling me is that there are two bugs instead of one, so now
both need to be fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] macsec: fix crypto Kconfig dependency
From: David Miller @ 2016-04-18 16:04 UTC (permalink / raw)
  To: herbert; +Cc: arnd, sd, hannes, johannes, netdev, linux-kernel
In-Reply-To: <20160418080202.GA18155@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 18 Apr 2016 16:02:02 +0800

> In fact this strikes me as a kbuild bug because CRYPTO_GCM already
> selects (indirectly) CRYPTO_ALGAPI so why is this happening at all?

Selects don't trigger selects.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox