On Mon, Jul 10, 2017 at 9:51 PM, Jiri Pirko wrote:
> From: Jiri Pirko
>
> Currently the filters added to qdiscs are independent. So for example if you
> have 2 netdevices and you create ingress qdisc on both and you want to add
> identical filter rules both, you need to add them twice. This patch
Hi Christophe,
> If this check fails, we must release some resources as done everywhere
> else in this function before returning an error code.
>
> Signed-off-by: Christophe JAILLET
> ---
> V2: initialization of ret in this erro path ws missing. Stupid me!
> ---
> drivers/net/ieee802154/mrf24j40
On Mon, Jul 10, 2017 at 08:28:28PM +0200, Jiri Pirko wrote:
> Mon, Jul 10, 2017 at 06:22:23PM CEST, l...@kernel.org wrote:
> >On Mon, Jul 10, 2017 at 10:13:07AM +0200, Jiri Pirko wrote:
> >> Tue, Jul 04, 2017 at 09:55:40AM CEST, l...@kernel.org wrote:
> >> >From: Leon Romanovsky
> >> >
> >> >Link
Sorry for replying to old mail...
On Wed, Jun 14, 2017 at 11:37:39AM -0700, Dave Watson wrote:
> +static int tls_do_encryption(struct tls_context *tls_ctx,
> + struct tls_sw_context *ctx, size_t data_len,
> + gfp_t flags)
> +{
> + unsigned int
Hi Joe,
On Tuesday 11 July 2017 11:17 AM, Joe Perches wrote:
On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:
Hi Joe,
On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
attribute_groups are not supposed to change at runtime. All
On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:
> Hi Joe,
>
>
> On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
> > On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
> > > attribute_groups are not supposed to change at runtime. All functions
> > > working with attribute_groups pro
Hi Joe,
On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as
On 07/10/2017 11:30 AM, Jesper Dangaard Brouer wrote:
> On Sat, 8 Jul 2017 21:06:17 +0200
> Jesper Dangaard Brouer wrote:
>
>> On Sat, 08 Jul 2017 10:46:18 +0100 (WEST)
>> David Miller wrote:
>>
>>> From: John Fastabend
>>> Date: Fri, 07 Jul 2017 10:48:36 -0700
>>>
On 07/07/2017 10:34 A
I use NBD for fast building and savif SD card and, sadly, the TV box crashes
after few min of building
On 2017 Jul 11, Marc Duponcheel wrote:
> FYI
>
> I changed 4.12.0 drivers/net/phy/realtek.c RTL8211F code to equal the
> 3.14.29 amlogic/ethernet/phy/am_realtek.c code and now the networking
Hey Alexander,
Okay, I understand your point regarding the "most likely scenario" being
TLPs directed upstream to the Root Complex. But I'd still like to make sure
that we have an agreed upon API/methodology for doing Peer-to-Peer with
Relaxed Ordering and no Relaxed Ordering to the Root Compl
FYI
I changed 4.12.0 drivers/net/phy/realtek.c RTL8211F code to equal the
3.14.29 amlogic/ethernet/phy/am_realtek.c code and now the networking
works without TCP stalls.
I don't say below patch should be considered mainstream (as maybe some
4.12.0 rtl8211f_config_init code should not be removed)
On 7/10/17, 2:13 PM, "Daniel Borkmann" wrote:
On 07/10/2017 11:04 PM, Yonghong Song wrote:
> With latest net-next:
>
> clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include
-I./arch/x86/include -I./arch/x86/include/generated/uapi
-I./arch/x86/include/ge
On 07/04/2017 08:59 AM, Andrey Ryabinin wrote:
> On 07/04/2017 04:49 PM, Kalle Valo wrote:
>> Andrey Ryabinin writes:
>>
>>> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a
>>> laptop with ath10k card.
>>>
>>>
>>> [37207.593370] [ cut here ]
>>> [37207.
On 07/10/2017 11:04 PM, Yonghong Song wrote:
With latest net-next:
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include
-I./arch/x86/include -I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi
-I./include/uapi -I./i
With latest net-next:
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include
-I./arch/x86/include -I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi
-I./include/uapi -I./include/generated/uapi -include ./include/linux/
On 07/10/2017 10:51 PM, Yonghong Song wrote:
On 7/10/17 1:27 PM, Daniel Borkmann wrote:
On 07/10/2017 10:12 PM, Yonghong Song wrote:
From: Yonghong Song
With latest net-next:
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include
-I./arch/x86/include -I./arch/x86/inclu
Hi Arkadi,
Arkadi Sharshevsky writes:
>>> + err = dsa_port_fdb_add(p->dp, fdb_info->addr, fdb_info->vid);
>>> + if (err) {
>>> + netdev_dbg(dev, "fdb add failed err=%d\n", err);
>>> + break;
>>> + }
>>> + call_switchdev_
On 7/10/17 1:27 PM, Daniel Borkmann wrote:
On 07/10/2017 10:12 PM, Yonghong Song wrote:
From: Yonghong Song
With latest net-next:
clang -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include
-I./arch/x86/include/generated/uapi -I./arch/x86/include/gene
On 07/10/2017 10:12 PM, Yonghong Song wrote:
From: Yonghong Song
With latest net-next:
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include
-I./arch/x86/include -I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi
Thank you for fixing it.
On 7/10/17, 1:12 PM, "Yonghong Song" wrote:
From: Yonghong Song
With latest net-next:
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include
-I./arch/x86/include -I./arch/x86/include/generated/uapi
-I./arch/x86/include/gener
From: Yonghong Song
With latest net-next:
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include
-I./arch/x86/include -I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi
-I./include/uapi -I./include/generated/uapi -in
Hi Arkadi,
Arkadi Sharshevsky writes:
> +struct dsa_slave_dump_ctx {
> + struct net_device *dev;
> + struct sk_buff *skb;
> + struct netlink_callback *cb;
> + int idx;
> +};
> +
> struct dsa_switch_ops {
> /*
>* Legacy probing.
> @@ -392,9 +399,7 @@ struct dsa_swit
On 07/08/2017 04:40 AM, Christophe JAILLET wrote:
If this check fails, we must release some resources as done everywhere
else in this function before returning an error code.
Signed-off-by: Christophe JAILLET
---
V2: initialization of ret in this erro path ws missing. Stupid me!
---
drivers/ne
On Tue, Jul 04, 2017 at 04:46:21PM +0530, Atul Gupta wrote:
> +/**
> + * cxgb4_ptp_init - initialize PTP for devices which support it
> + * @adapter: board private structure
> + *
> + * This function performs the required steps for enabling PTP support.
> + */
> +void cxgb4_ptp_init(struct adapter
On 07/08/2017 08:22 PM, Al Viro wrote:
Signed-off-by: Al Viro
Acked-by: Daniel Borkmann
(Looks like ppp_sock_fprog_ioctl_trans() is another such candidate.)
From: Jiri Pirko
Signed-off-by: Jiri Pirko
---
include/linux/pkt_sched.h | 12 +++
tc/q_clsact.c | 54 ++-
tc/q_ingress.c| 32 +---
3 files changed, 90 insertions(+), 8 deletions(-)
diff --git a
From: Jiri Pirko
Allow qdiscs to share filter blocks among them. Each qdisc type has to
use block get/put modifications that enable sharing. Shared blocks are
tracked within each net namespace and identified by u32 value. This
value is auto-generated in case user did not pass it from userspace. I
From: Jiri Pirko
There is going to be need to be able to obtain net structure for
a qdisc. So introduce helper to do it.
Signed-off-by: Jiri Pirko
---
include/net/pkt_sched.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
index 2579
From: Jiri Pirko
Currently the filters added to qdiscs are independent. So for example if you
have 2 netdevices and you create ingress qdisc on both and you want to add
identical filter rules both, you need to add them twice. This patchset
makes this easier and mainly saves resources allowing to
From: Jiri Pirko
Benefit from the previously introduced shared filter blocks
infrastructure and allow ingress and clsact qdisc instances to share
filter blocks. The block index is coming from userspace as qdisc option.
Signed-off-by: Jiri Pirko
---
include/uapi/linux/pkt_sched.h | 12 +
n
From: Jiri Pirko
So far, there was possible only to register a single filter chain
pointer to a block->chain[0]. However, when the blocks will get
shareable, we need to allow multiple filter chain pointers registration.
Signed-off-by: Jiri Pirko
---
include/net/sch_generic.h | 2 +-
net/sched
From: Arnd Bergmann
Date: Mon, 10 Jul 2017 11:37:51 +0200
> The new IPSec offload code introduced a build error:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function
> `mlx5e_ipsec_build_inverse_table':
> ipsec_rxtx.c:(.text+0x556): undefined reference
>
> Another pat
On Sat, 8 Jul 2017 21:06:17 +0200
Jesper Dangaard Brouer wrote:
> On Sat, 08 Jul 2017 10:46:18 +0100 (WEST)
> David Miller wrote:
>
> > From: John Fastabend
> > Date: Fri, 07 Jul 2017 10:48:36 -0700
> >
> > > On 07/07/2017 10:34 AM, John Fastabend wrote:
> > >> This series adds two new
Mon, Jul 10, 2017 at 06:01:44PM CEST, l...@kernel.org wrote:
>On Mon, Jul 10, 2017 at 10:02:30AM +0200, Jiri Pirko wrote:
>> Tue, Jul 04, 2017 at 09:55:37AM CEST, l...@kernel.org wrote:
>> >Hi,
>> >
>> >This is third version of series implementing the RDAMtool - the tool
>> >to configure RDMA devi
Mon, Jul 10, 2017 at 06:22:23PM CEST, l...@kernel.org wrote:
>On Mon, Jul 10, 2017 at 10:13:07AM +0200, Jiri Pirko wrote:
>> Tue, Jul 04, 2017 at 09:55:40AM CEST, l...@kernel.org wrote:
>> >From: Leon Romanovsky
>> >
>> >Link (port) object represent struct ib_port to the user space.
>> >
>> >Link
This thing is definitely not cc'd to the right people:
On Sun, Jul 9, 2017 at 10:08 PM, Cong Wang wrote:
>
> Cc: Linus Torvalds
> Cc: Andrew Morton
> Cc: Manfred Spraul
> Signed-off-by: Cong Wang
Unlike your previous patch, this seems to be more of a generic netlink
interface issue, so you s
On 07/10/2017 10:53 AM, Jesper Dangaard Brouer wrote:
> On Fri, 07 Jul 2017 10:37:59 -0700
> John Fastabend wrote:
>
>> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
>> index 36dc13de..656e334 100644
>> --- a/kernel/bpf/devmap.c
>> +++ b/kernel/bpf/devmap.c
> [...]
>>
>> +void __dev_ma
On Fri, 07 Jul 2017 10:37:59 -0700
John Fastabend wrote:
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index 36dc13de..656e334 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
[...]
>
> +void __dev_map_insert_ctx(struct bpf_map *map, u32 key)
> +{
> + struct bpf_d
On 07/09/2017 06:37 AM, Saeed Mahameed wrote:
>
>
> On 7/7/2017 8:35 PM, John Fastabend wrote:
>> This adds support for a bpf_redirect helper function to the XDP
>> infrastructure. For now this only supports redirecting to the egress
>> path of a port.
>>
>> In order to support drivers handling a
Hi Alan,
On 07/08/2017 06:21 PM, Alan Stern wrote:
Pardon me for barging in, but I found this whole interchange extremely
confusing...
On Sat, 8 Jul 2017, Ingo Molnar wrote:
* Paul E. McKenney wrote:
On Sat, Jul 08, 2017 at 10:35:43AM +0200, Ingo Molnar wrote:
* Manfred Spraul wrote:
H
On Sun, Jul 9, 2017 at 10:08 PM, Cong Wang wrote:
> netlink_sendskb() is problematic, it releases sock refcnt
> silently which could cause troubles we can call it multiple
> times. info->notify_sock is a good example where we
> setup once and use it to send netlink skb's for many times.
> It shoul
Hi Florian, Arkadi,
Florian Fainelli writes:
> I would be more comfortable if we still had a way to dump HW entries by
> calling into drivers, because it's useful for debugging, and doing that
> using standard tools plus an additional flag for instance:
>
> bridge fdb show
>
> would dump the SW-
We are not allowed to block on the RCU reader side, so can't
just hold the mutex as before. As a quick fix, convert it to
a spinlock.
Fixes: d9f1f61c0801 ("tap: Extending tap device create/destroy APIs")
Reported-by: Christian Borntraeger
Tested-by: Christian Borntraeger
Cc: Sainath Grandhi
Sig
> 1) I think most of it should be some cfg80211 shareable code.
I’m not sure exactly what you mean by this, could you please clarify?
> 2) This "rxtx" while surely present in other places sounds like a
> workaround for LED subsystem limitation. Maybe it's time to finally
> rework LED triggers.
I
On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
> attribute_groups are not supposed to change at runtime. All functions
> working with attribute_groups provided by work
> with const attribute_group. So mark the non-const structs as const.
I think it's good you are doing all of these.
Inst
+ /* Reading from resource space should be 32b aligned */
+ fw_maj_min = ioread32be(fw_ver);
+ fw_sub_min = ioread32be(fw_ver + 1);
+ fw_major = fw_maj_min & 0x;
+ fw_minor = fw_maj_min >> 16;
+ fw_subminor = fw_sub_min & 0x;
Maybe second read should be
On Sun, Jul 9, 2017 at 7:07 PM, Jason A. Donenfeld wrote:
> On Sat, Jul 8, 2017 at 12:39 AM, Cong Wang wrote:
>> On Thu, Jul 6, 2017 at 7:24 AM, Jason A. Donenfeld wrote:
>>> list_add(&priv->list, &list_of_things);
>>>
>>> ret = register_netdevice(); // if ret is < 0, then destru
On Mon, Jul 10, 2017 at 10:13:07AM +0200, Jiri Pirko wrote:
> Tue, Jul 04, 2017 at 09:55:40AM CEST, l...@kernel.org wrote:
> >From: Leon Romanovsky
> >
> >Link (port) object represent struct ib_port to the user space.
> >
> >Link properties:
> > * Port capabilities
> > * IB subnet prefix
> > * LID
On Mon, Jul 10, 2017 at 10:02:30AM +0200, Jiri Pirko wrote:
> Tue, Jul 04, 2017 at 09:55:37AM CEST, l...@kernel.org wrote:
> >Hi,
> >
> >This is third version of series implementing the RDAMtool - the tool
> >to configure RDMA devices. The initial proposal was sent as RFC [1] and
> >was based on s
On 10/07/17 16:14, Arnd Bergmann wrote:
> Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA,
> as a result of the driver calling set_dma_ops(). While we can
> fix the build error in the dma-mapping implementation, there is
> another problem in this driver:
>
> The configuration for
On Mon, Jul 10, 2017 at 5:32 PM, Biju Das wrote:
> Add a new compatible string for the RZ/G1M (R8A7743) SoC.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-
Add a new compatible string for the RZ/G1M (R8A7743) SoC.
Signed-off-by: Biju Das
---
v1->v2
* Changed the subject
* re-formatted the required properties
.../devicetree/bindings/net/renesas,ravb.txt | 29 +-
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git
On Mon, 2017-07-10 at 10:24 +, Ilan Tayari wrote:
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly
> >
> > The new IPSec offload code introduced a build error:
> >
> > drivers/net/ethernet/mellano
Hi Arnd,
On Mon, Jul 10, 2017 at 5:14 PM, Arnd Bergmann wrote:
> Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA,
> as a result of the driver calling set_dma_ops(). While we can
> fix the build error in the dma-mapping implementation, there is
> another problem in this driver:
>
On 10/07/17 15:56, Christoph Hellwig wrote:
> This looks reasonable to me, I'd be happy to pick it up. Can you send
> it as a series with the reverts?
The fact remains that the FSL driver is still doing the wrong thing
though - set_dma_ops(dev1, get_dma_ops(dev2)) is just a hack which
happens to
On Mon, 10 Jul 2017 13:19:12 +0200
Phil Sutter wrote:
> +static bool is_basename(const char *name)
> +{
> + char *name_dup = strdup(name);
> + bool rc = true;
> +
> + if (!name_dup)
> + return false;
> +
> + if (strcmp(basename(name_dup), name))
> + rc = fa
Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA,
as a result of the driver calling set_dma_ops(). While we can
fix the build error in the dma-mapping implementation, there is
another problem in this driver:
The configuration for the DMA is done by the platform code,
looking up inf
Thank you for your time,
We are looking for clients in your country with good business or project that
requires financing to execute.
Please get back to me if you are interested in this or you know anybody who has
good business ideas but lack the necessary capital to fund his projects so we
ca
On 06/29/2017 05:41 PM, Andrew Lunn wrote:
>> Transceivers for CAN are not apart of any model. Traditional CAN didn't
>> have a problem because all transceivers from my understanding supported
>> the maximum speed of 1 Mbps defined by the spec. However, with the
>> introduction of CAN Flexible Data
This looks reasonable to me, I'd be happy to pick it up. Can you send
it as a series with the reverts?
> To be clear, are you suggesting that we add an additional property to
> of_mdio_parse_addr() that specifies the limit to check against, or
> remove the check and add it to each additional caller?
Hi Jon
Probably the simplest is to add an extra parameter to mdio_mux_init()
which is the maximum a
On Mon, Jul 10, 2017 at 8:56 AM, Andrew Lunn wrote:
> On Mon, Jul 10, 2017 at 02:35:23PM +0200, Martin Blumenstingl wrote:
>> mdio_mux_init parses the child nodes of the MDIO mux. When using
>> "mdio-mux-mmioreg" the child nodes are describing the register value
>> that is written to switch betwee
On Mon, Jul 10, 2017 at 08:10:02AM -0400, Sowmini Varadhan wrote:
>
> The reason that the WARN_ON is triggered is that af_alg_accept() calls
> sock_init_data() which does
>
>2636 if (sock) {
> :
>2639 sock->sk= sk;
Oh yes. This started out with
Since the introduction of ULD (Upper-Layer Drivers), the MSI-X
deallocating path changed in cxgb4: the driver frees the interrupts
of ULD when unregistering it or on shutdown PCI handler.
Problem is that if a MSI-X is not freed before deallocated in the PCI
layer, it will trigger a BUG() due to st
On Thu, Jul 06, 2017 at 10:37:57AM -0700, Arun Parameswaran wrote:
> Add SoC specific compatibility strings to the Broadcom DTE
> based PTP clock binding document.
>
> Fixed the document heading and node name.
>
> Fixes: 80d6076140b2 ("dt-binding: ptp: add bindings document for dte based
> ptp c
On Thu, Jul 06, 2017 at 03:05:30PM +0200, Richard Leitner wrote:
> Some PHYs (for example the LAN8710) doesn't allow turning the clocks off
> and on again without reset (according to their datasheet). Exactly this
> behaviour was introduced for power saving reasons by commit e8fcfcd5684a
> ("net: f
When calling the flow_free() to free the flow, we call many times
(cpu_possible_mask, eg. 128 as default) cpumask_next(). That will
take up our CPU usage if we call the flow_free() frequently.
When we put all packets to userspace via upcall, and OvS will send
them back via netlink to ovs_packet_cmd
In the ovs_flow_stats_update(), we only use the node
var to alloc flow_stats struct. But this is not a
common case, it is unnecessary to call the numa_node_id()
everytime. This patch is not a bugfix, but there maybe
a small increase.
Signed-off-by: Tonghao Zhang
---
net/openvswitch/flow.c | 3 +-
Hi Matteo,
On Mon, Jul 10, 2017 at 02:08:31PM +0200, Matteo Croce wrote:
> I noticed that your patch still leaves an uncovered scenario, the one where
> the
> namespace name is "." or "..".
> Calling 'ip netns del ..' will remove /var/run which is a symlink to /run on
> most systems causing some
On Mon, Jul 10, 2017 at 02:35:23PM +0200, Martin Blumenstingl wrote:
> mdio_mux_init parses the child nodes of the MDIO mux. When using
> "mdio-mux-mmioreg" the child nodes are describing the register value
> that is written to switch between the MDIO busses.
>
> The change which makes the error m
On 07/10/2017 02:35 PM, Martin Blumenstingl wrote:
> mdio_mux_init parses the child nodes of the MDIO mux. When using
> "mdio-mux-mmioreg" the child nodes are describing the register value
> that is written to switch between the MDIO busses.
>
> The change which makes the error messages more verbo
mdio_mux_init parses the child nodes of the MDIO mux. When using
"mdio-mux-mmioreg" the child nodes are describing the register value
that is written to switch between the MDIO busses.
The change which makes the error messages more verbose changed the
parsing of the "reg" property from a simple of
On (07/10/17 18:05), Herbert Xu wrote:
>
> Hmm, I can't see the problem in af_alg_accept. The struct socket
> comes directly from sys_accept() which creates it using sock_alloc.
>
> So the only thing I can think of is that the memory returned by
> sock_alloc is not zeroed and therefore the WARN_
Hi Phil,
I noticed that your patch still leaves an uncovered scenario, the one where the
namespace name is "." or "..".
Calling 'ip netns del ..' will remove /var/run which is a symlink to /run on
most systems causing some daemons, eg. dbus, to fail.
ip netns doesn't validate input, allowing crea
Computing the alignment manually for going from priv to pub is probably
not such a good idea, and in general the assumption that going from priv
to pub is possible trivially could change, so rather than relying on
that, we change things to just store a pointer to pub. This was sugested
by DaveM in
On Mon, Jul 10, 2017 at 10:04 AM, David Miller wrote:
> I disagree. Assuming one can go from the driver private to the netdev
> object trivially is a worse assumption than the other way around, and
> locks us into the current implementation of how the netdev and driver
> private memory is allocat
In order to keep track of created netns, 'ip netns' creates a mount
point inside NETNS_RUN_DIR. By not checking the user-specified name, it
allowed to create that mount point outside of NETNS_RUN_DIR and hence
lose track of it afterwards:
| # ip netns add ../../tmp/foobar
| # ip netns list
| # mou
On Mon, Jul 10, 2017 at 01:29:20PM +0300, Dan Carpenter wrote:
> The "goto no_pps" was a bug you introduced.
I took a second look, and yes, the original commit should not have
returned NULL, and the original callers did not expect NULL either.
> But I feel like you're being rude, so I'm not goin
Hi Casey:
On 2017/7/8 10:04, Casey Leedom wrote:
> Okay, thanks for the note Alexander.I'll have to look more closely
> at
> the patch on Monday and try it out on one of the targeted systems to verify
> the semantics you describe.
>
All the modification is only clearing the device's D
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
28720 985 12 297177415 drive
On Mon, Jul 10, 2017 at 11:48:06AM +0200, Richard Cochran wrote:
> On Mon, Jul 10, 2017 at 12:38:16PM +0300, Dan Carpenter wrote:
> > There were two buggy commits so I chose the ealier one. The other buggy
>
> No, you are mistaken. In the original patch, NULL or PTR_ERR were
> returned on error,
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly
>
> The new IPSec offload code introduced a build error:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function
> `mlx5e_ipsec_build_
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
45121472 059841760 drive
From: Stephen Hemminger
> Sent: 07 July 2017 16:40
> For the most of the address flags, use a table of bit values rather
> than open coding every value. This allows for easier inevitable
> expansion of flags.
>
> This also fixes the missing stable-privacy flag.
>
> Signed-off-by: Stephen Hemmin
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
3409 948 2843851121 drive
On Sun, Jul 09, 2017 at 09:40:43PM +0100, David Miller wrote:
>
> > It look like PF_ALG sets up a ->sk in alg_create() (but this
> > would get over-written in alg_accept()?)
No it does not. The struct socket comes from sys_accept() and
AFAICS it doesn't carry a struck sock with it.
> > Cc'ing H
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly
>
> The new IPSec offload code introduced a build error:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function
> `mlx5e_ipsec_build_
On Mon, Jul 10, 2017 at 10:16:15AM +0300, Dan Carpenter wrote:
> We're checking ptp_clock_register() for NULL but we should be checking
> for error pointers.
No.
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
> index 50517cfd9671.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +-
1 file changed, 1 inser
On Fri, Jul 07, 2017 at 10:16:31AM -0700, Florian Fainelli wrote:
> On 07/06/2017 11:50 PM, Alvaro Gamez Machado wrote:
> > Keep supporting proprietary "xlnx,phy-type" attribute and add support for
> > MII connectivity to the PHY.
> >
> > Signed-off-by: Alvaro Gamez Machado
> > ---
> > diff --git
On Mon, Jul 10, 2017 at 12:38:16PM +0300, Dan Carpenter wrote:
> There were two buggy commits so I chose the ealier one. The other buggy
No, you are mistaken. In the original patch, NULL or PTR_ERR were
returned on error, and that was not a bug.
If you want to correct the present version of ptp
On 7 July 2017 at 16:09, Russell Joyce wrote:
> Add three basic LED triggers to brcmfmac, based on those in mac80211: one
> for transmit, one for receive, and one for combined transmit/receive.
>
> Signed-off-by: Russell Joyce
1) I think most of it should be some cfg80211 shareable code.
2) This
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +-
1 file changed, 1 inser
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
1 file changed, 1 inserti
The new IPSec offload code introduced a build error:
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function
`mlx5e_ipsec_build_inverse_table':
ipsec_rxtx.c:(.text+0x556): undefined reference
Another patch was added on top to fix the build error, but
that introduced a new bug,
On Mon, Jul 10, 2017 at 11:21:03AM +0200, Richard Cochran wrote:
> On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote:
> > The ptp_clock_register() function returns NULL when it's #ifdefed out
> > because CONFIG_PTP_1588_CLOCK is disabled. Otherwise, it's intended to
> > return error po
On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote:
> The ptp_clock_register() function returns NULL when it's #ifdefed out
> because CONFIG_PTP_1588_CLOCK is disabled. Otherwise, it's intended to
> return error pointers. Unfortunately, there are a couple paths where we
> forget to set
Hello!
On 7/10/2017 4:20 AM, Rob Herring wrote:
Add support for Gigabit Ethernet E-MAC on r8a7743 (RZ/G1M) SoC.
Renesas RZ/G1M (R8A7743) SoC Ethernet AVB IP is identical to the R-Car Gen2
family.
For the subject: "dt-bindings: net: ..."
Signed-off-by: Biju Das
Reviewed-by: Chris Paterson
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
1 file changed, 1 inserti
On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote:
> The ptp_clock_register() function returns NULL when it's #ifdefed out
> because CONFIG_PTP_1588_CLOCK is disabled. Otherwise, it's intended to
> return error pointers. Unfortunately, there are a couple paths where we
> forget to set
1 - 100 of 119 matches
Mail list logo
