From: Geneviève Bastien
Date: Tue, 27 Nov 2018 12:52:39 -0500
> Trace events are already present for the receive entry points, to indicate
> how the reception entered the stack.
>
> This patch adds the corresponding exit trace events that will bound the
> reception such that all events occurring
From: Edward Cree
Date: Tue, 27 Nov 2018 15:40:59 +
> There are no such structs flow_dissector_key_flow_vlan or
> flow_dissector_key_flow_tags, the actual structs used are struct
> flow_dissector_key_vlan and struct flow_dissector_key_tags. So correct the
> comments against FLOW_DISSECTOR
From: Toni Peltonen
Date: Tue, 27 Nov 2018 16:56:57 +0200
> Previously when unbinding a slave the 802.3ad implementation only told
> partner that the port is not suitable for aggregation by setting the port
> aggregation state from aggregatable to individual. This is not enough. If the
> physical
On Wed, Nov 28, 2018 at 04:53:11PM +, Lorenz Bauer wrote:
> Add a new function, which encourages safe usage of the test interface.
> bpf_prog_test_run continues to work as before, but should be considered
> unsafe.
>
> Signed-off-by: Lorenz Bauer
..
> +
> +LIBBPF_API int bpf_prog_test_run_xat
From: Igor Russkikh
Date: Tue, 27 Nov 2018 14:51:17 +
> From: Dmitry Bogdanov
>
> The last set of csum offload fixes had a leak:
>
> Checksum enabled status bits from rx descriptor were incorrectly
> interpreted. Consequently all the other valid logic worked on zero bits.
> That caused rx
From: Colin King
Date: Tue, 27 Nov 2018 14:37:17 +
> From: Colin Ian King
>
> There is a spelling mistake in a net_warn_ratelimited message, fix this.
>
> Signed-off-by: Colin Ian King
Applied.
From: Colin King
Date: Tue, 27 Nov 2018 14:00:15 +
> From: Colin Ian King
>
> There is a spelling mistake in the oct_stats_strings array, fix it.
>
> Signed-off-by: Colin Ian King
Applied.
From: Thierry Reding
Date: Tue, 27 Nov 2018 14:21:43 +0100
> From: Thierry Reding
>
> Setting up and tearing down debugfs is current unbalanced, as seen by
> this error during resume from suspend:
>
> [ 752.134067] dwc-eth-dwmac 249.ethernet eth0: ERROR failed to
> create debugfs dir
From: Alexis Bauvin
Date: Tue, 27 Nov 2018 14:05:42 +0100
> UDP tunnel sockets are always opened unbound to a specific device. This
> patch allow the socket to be bound on a custom device, which
> incidentally makes UDP tunnels VRF-aware if binding to an l3mdev.
>
> Signed-off-by: Alexis Bauvin
From: Xin Long
Date: Tue, 27 Nov 2018 19:11:50 +0800
> sctp_assoc_update_frag_point() should be called whenever asoc->pathmtu
> changes, but we missed one place in sctp_association_init(). It would
> cause frag_point is zero when sending data.
>
> As says in Jakub's reproducer, if sp->pathmtu is
From: Pavel Balaev
Date: Tue, 27 Nov 2018 13:07:10 +0300
> -#define IPTOS_RT_MASK(IPTOS_TOS_MASK & ~3)
> +#define IPTOS_RT_MASK(IPTOS_DSCP_MASK & ~3)
I was hoping my original feedback would have you actually go
investigate why IPTOS_RT_MASK is defined the way that it is.
I will
From: Ganesh Goudar
Date: Tue, 27 Nov 2018 14:59:06 +0530
> Total number of VFs supported by PF is used to determine the last
> byte of VF's mac address. Number of VFs supported is not always
> 16, use the variable nvfs to get the number of VFs supported
> rather than hard coding it to 16.
>
> S
On Fri, Nov 30, 2018 at 11:40:17AM -0800, Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> wrote:
> >
> > In order to comply with the CoC, replace with a hug.
>
> Heh. I support the replacement of the stronger language, but I find
> "hug", "hugged", and "hugging" to be v
On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen wrote:
> This a direct quote from the CoC:
>
> "Harassment includes the use of abusive, offensive or degrading
> language, intimidation, stalking, harassing photography or recording,
> inappropriate physical contact, sexual imagery and unwelcome
On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > In order to comply with the CoC, re
On Fri, 2018-11-30 at 12:55 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > In order to comply with the CoC, replace
On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> On Fri, 30 Nov 2018, Kees Cook wrote:
>
> > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > wrote:
> > >
> > > In order to comply with the CoC, replace with a hug.
>
> I hope this is some kind of joke. How would anyone
On Fri, 30 Nov 2018 20:39:01 +
Abuse wrote:
> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> >
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>
> > >>>
From: Abuse
Date: Fri, 30 Nov 2018 20:39:01 +
> I assume I will now be barred.
Perhaps, but not because you said fuck. It would be because you're
intentionally creating a disturbance on the list and making it more
difficult for developers to get their work done and intentionally
creating a
What is the plan ahead here? I think the nvme code looks pretty
reasonable now (I'll do another pass at nitpicking), but we need the
networking stuff sorted out with at least ACKs, or a merge through
the networking tree and then a shared branch we can pull in.
I would think that having Dave
On 11/30/18 1:30 PM, Michael S. Tsirkin wrote:
I would like to see basic packets, bytes, and dropped counters
tracked
for Rx and Tx via the standard netdev counters for all devices.
>>
>> The problem of reporting XDP_DROP in the netedev drop counter is that
>> they don't fit this co
From: Jens Axboe
Date: Fri, 30 Nov 2018 13:12:26 -0700
> On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
>> On Fri, 30 Nov 2018, Kees Cook wrote:
>>
>>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>>> wrote:
In order to comply with the CoC, replace with a hug.
>>
>> I hope thi
Am 01.12.2018 um 09:12 schrieb Jens Axboe:
On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
On Fri, 30 Nov 2018, Kees Cook wrote:
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
In order to comply with the CoC, replace with a hug.
I hope this is some kind of joke. How would anyon
From: Davidlohr Bueso
Date: Fri, 30 Nov 2018 11:56:52 -0800
> I hope this is some kind of joke.
Whether or not it is a joke, it is censorship.
And because of that I have no intention to apply any patches like this
to any code I am in charge of.
On 30/11/2018 20:40, Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> wrote:
>>
>> In order to comply with the CoC, replace with a hug.
>
> Heh. I support the replacement of the stronger language, but I find
> "hug", "hugged", and "hugging" to be very weird replacemen
From: Willem de Bruijn
With MSG_ZEROCOPY, each skb holds a reference to a struct ubuf_info.
Release of its last reference triggers a completion notification.
The TCP stack in tcp_sendmsg_locked holds an extra ref independent of
the skbs, because it can build, send and free skbs within its loop,
From: Willem de Bruijn
Extend zerocopy to udp sockets. Allow setting sockopt SO_ZEROCOPY and
interpret flag MSG_ZEROCOPY.
This patch was previously part of the zerocopy RFC patchsets. Zerocopy
is not effective at small MTU. With segmentation offload building
larger datagrams, the benefit of page
From: Willem de Bruijn
Both msg_zerocopy and udpgso_bench have udp zerocopy variants.
Exercise these as part of the standard kselftest run.
With udp, msg_zerocopy has no control channel. Ensure that the
receiver exits after the sender by accounting for the initial
delay in starting them (in msg_
From: Willem de Bruijn
Enable MSG_ZEROCOPY for udp sockets
Patch 1/3 is the main patch, a rework of RFC patch
http://patchwork.ozlabs.org/patch/899630/
more details in the patch commit message
Patch 2/3 is an optimization to remove a branch from the UDP hot path
and refcount_inc/refcount_
On Fri, Nov 30, 2018 at 08:10:58PM +, Saeed Mahameed wrote:
> On Thu, 2018-11-22 at 18:00 +0100, Toke Høiland-Jørgensen wrote:
> > David Ahern writes:
> >
> > > On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote:
> > > > Saeed Mahameed writes:
> > > >
> > > > > > > I'd say it sounds reasonab
On 11/30/18 8:40 PM, Kees Cook wrote:
> Better yet, since it's only 17 files, how about doing context-specific
> changes? "This API is terrible", "Hateful interface", "Don't touch my
> freakin' code", "What in the world were they thinking?" etc?
Or just leave it as is because we're all grown up and
Hi Kalle,
Have you had a chance to check out these patches yet?
--
Kyle Roeschley
Software Engineer
National Instruments
On Thu, 2018-11-22 at 17:45 -0800, Cong Wang wrote:
> On Wed, Nov 21, 2018 at 11:33 AM Saeed Mahameed
> wrote:
> > On Wed, 2018-11-21 at 10:26 -0800, Eric Dumazet wrote:
> > > On Wed, Nov 21, 2018 at 10:17 AM Cong Wang <
> > > xiyou.wangc...@gmail.com>
> > > wrote:
> > > > On Wed, Nov 21, 2018 at
On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> On Fri, 30 Nov 2018, Kees Cook wrote:
>
>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>> wrote:
>>>
>>> In order to comply with the CoC, replace with a hug.
>
> I hope this is some kind of joke. How would anyone get offended by reading
>
On Thu, 2018-11-22 at 18:00 +0100, Toke Høiland-Jørgensen wrote:
> David Ahern writes:
>
> > On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote:
> > > Saeed Mahameed writes:
> > >
> > > > > > I'd say it sounds reasonable to include XDP in the normal
> > > > > > traffic
> > > > > > counters, but
From: Petar Penkov
The pkt_len field in qdisc_skb_cb stores the skb length as it will
appear on the wire after segmentation. For byte accounting, this value
is more accurate than skb->len. It is computed on entry to the TC
layer, so only valid there.
Allow read access to this field from BPF tc c
On 11/28/18 6:34 PM, Peter Oskolkov wrote:
> On Wed, Nov 28, 2018 at 4:47 PM David Ahern wrote:
>>
>> On 11/28/18 5:22 PM, Peter Oskolkov wrote:
>>> diff --git a/net/core/filter.c b/net/core/filter.c
>>> index bd0df75dc7b6..17f3c37218e5 100644
>>> --- a/net/core/filter.c
>>> +++ b/net/core/filter.
On Fri, 30 Nov 2018, Kees Cook wrote:
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
In order to comply with the CoC, replace with a hug.
I hope this is some kind of joke. How would anyone get offended by reading
technical comments? This is all beyond me...
Thanks,
Davidlohr
On Fri, Nov 30, 2018 at 11:01:03AM -0800, Bijan Mottahedeh wrote:
> On 11/30/2018 5:44 AM, Michael S. Tsirkin wrote:
> > On Thu, Nov 01, 2018 at 04:06:19PM -0700, Linus Torvalds wrote:
> > > On Thu, Nov 1, 2018 at 4:00 PM Kees Cook wrote:
> > > > + memset(&rsp, 0, sizeof(rsp));
> > > > +
On Fri, 30 Nov 2018 20:22:35 +0100
Alexis Vachette wrote:
> Hi Stephen,
>
> Thanks for your kind reply.
>
> It's sad to hear that, I am aware of your concern too.
>
> But it's not the best behavior for a network engineer.
>
> Is it possible to add a new option or everything is stone graved ?
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
>
> In order to comply with the CoC, replace with a hug.
Heh. I support the replacement of the stronger language, but I find
"hug", "hugged", and "hugging" to be very weird replacements. Can we
bikeshed this to "heck", "hecked", and "he
On Sat, Dec 01, 2018 at 03:53:26AM +0900, Xin Long wrote:
> On Sat, Dec 1, 2018 at 12:23 AM Neil Horman wrote:
> >
> > On Fri, Nov 30, 2018 at 10:48:10PM +0900, Xin Long wrote:
> > > On Fri, Nov 30, 2018 at 9:21 PM Neil Horman wrote:
> > > >
> > > > On Fri, Nov 30, 2018 at 03:22:39PM +0900, Xin L
Hi David,
On Thu, 29 Nov 2018 11:51:48 -0700
David Ahern wrote:
> On 11/29/18 11:50 AM, Stephen Hemminger wrote:
> > PS: ss still doesn't support JSON output, given the volume of output it
> > would be good.
>
> I thought Stefano was investigating it as an alternative to the 'display
> selec
On 30/11/2018 17:54, Qian Cai wrote:
The amount of DMA mappings from Hisilicon HNS ethernet devices is huge,
so it could trigger "DMA-API: debugging out of memory - disabling".
hnae_get_handle [1]
hnae_init_queue
hnae_init_ring
hnae_alloc_buffers [2]
debug_dma_map_page
On Sat, Dec 01, 2018 at 03:53:26AM +0900, Xin Long wrote:
> On Sat, Dec 1, 2018 at 12:23 AM Neil Horman wrote:
> >
> > On Fri, Nov 30, 2018 at 10:48:10PM +0900, Xin Long wrote:
> > > On Fri, Nov 30, 2018 at 9:21 PM Neil Horman wrote:
> > > >
> > > > On Fri, Nov 30, 2018 at 03:22:39PM +0900, Xin L
In order to comply with the CoC, replace with a hug.
Signed-off-by: Jarkko Sakkinen
---
drivers/net/ethernet/sun/sunhme.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunhme.c
b/drivers/net/ethernet/sun/sunhme.c
index 863fd602fd33..54a206
In order to comply with the CoC, replace with a hug.
Signed-off-by: Jarkko Sakkinen
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index a8217e221e19..8aadde6464a7 100644
--- a/net/core/skbuff.c
+++ b/net/core/
Hi Stephen,
Thanks for your kind reply.
It's sad to hear that, I am aware of your concern too.
But it's not the best behavior for a network engineer.
Is it possible to add a new option or everything is stone graved ?
If yes I will fix my e-mail client to submit a correct PR.
On Fri, 30 Nov 201
> 'cards_found' doesn't exist for the ixgbe driver.
Agh, sorry, i was looking at ixgb, not ixgbe.
Andrew
On Fri, 30 Nov 2018 at 19:26, Will Deacon wrote:
>
> On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote:
> > The arm64 module region is a 128 MB region that is kept close to
> > the core kernel, in order to ensure that relative branches are
> > always in range. So using the same region
On 11/30/2018 5:44 AM, Michael S. Tsirkin wrote:
On Thu, Nov 01, 2018 at 04:06:19PM -0700, Linus Torvalds wrote:
On Thu, Nov 1, 2018 at 4:00 PM Kees Cook wrote:
+ memset(&rsp, 0, sizeof(rsp));
+ rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED;
+ resp = vq->iov[out].iov_base;
+
On Sat, Dec 1, 2018 at 12:23 AM Neil Horman wrote:
>
> On Fri, Nov 30, 2018 at 10:48:10PM +0900, Xin Long wrote:
> > On Fri, Nov 30, 2018 at 9:21 PM Neil Horman wrote:
> > >
> > > On Fri, Nov 30, 2018 at 03:22:39PM +0900, Xin Long wrote:
> > > > On Thu, Nov 29, 2018 at 11:39 PM Neil Horman
> >
On 30.11.2018 18:46, Florian Fainelli wrote:
>
>
> On 11/30/2018 1:25 AM, Kunihiko Hayashi wrote:
>> Even though the link is down before entering hibernation,
>> there is an issue that the network interface always links up after resuming
>> from hibernation.
>>
>> The phydev->state is PHY_READY b
When a PHY_HALTED phydev is resumed by phy_start(), it is set to
PHY_RESUMING to wait for the link to come up.
However, if the phydev was put to PHY_HALTED (by e.g. phy_stop()) before
autonegotiation was ever started by phy_state_machine(), autonegotiation
remains unconfigured, i.e. phy_config_ane
When the phydev is put to PHY_HALTED (by e.g. phy_stop()) the state
machine suspends the phydev to save power.
However, this is wrongly inside a phydev->link check, causing the phydev
not to be suspended if there was no link at the time of stopping it.
Fix that by setting do_suspend regardless of
Hi all,
Here are a couple of fixes for PHY_HALTED/PHY_RESUMING handling.
On a related note, it feels a bit strange that AFAICS phydevs will only
be put to powerdown state (via PHY_HALTED) after the network interface
has been brought up and down once. If the ethernet interface is never
brought up
On 11/30/18 12:43 PM, Florian Fainelli wrote:
>
>
> On 11/30/2018 9:34 AM, Steve Douthit wrote:
>> On 11/30/18 11:34 AM, Andrew Lunn wrote:
Yep, registering multiple interfaces is wrong. The first board I tested
against only had a single MAC enabled (they can be disabled/hidden via
>>>
On Fri, Nov 30, 2018 at 10:28 AM Sharath Chandra Vurukala
wrote:
>
> when the tcp_retranmission_timer expires and tcp_retranmsit_skb is
> called if the retranmsission fails due to local congestion,
> backoff should not incremented.
>
> tcp_retransmit_skb() returns non-zero negative value in some c
On 11/30/2018 10:28 AM, Sharath Chandra Vurukala wrote:
> when the tcp_retranmission_timer expires and tcp_retranmsit_skb is
> called if the retranmsission fails due to local congestion,
> backoff should not incremented.
>
> tcp_retransmit_skb() returns non-zero negative value in some cases of
On 11/30/18 11:12 AM, Stephen Hemminger wrote:
> I can understand why you would want this, but it is changing the
> behavior of an existing command that might be used in scripts.
+1
when the tcp_retranmission_timer expires and tcp_retranmsit_skb is
called if the retranmsission fails due to local congestion,
backoff should not incremented.
tcp_retransmit_skb() returns non-zero negative value in some cases of
failure but the caller tcp_retransmission_timer() has a check for
fai
On Fri, Nov 30, 2018 at 10:12 AM Stephen Hemminger
wrote:
>
> On Fri, 30 Nov 2018 14:33:49 +0100
> Alexis Vachette wrote:
>
> > When using:
> >
> > - ip -s link
> >
> > I think it should be better to print errors stats without adding -s
> > option twice.
> >
> > This option print stats for each n
On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote:
> The arm64 module region is a 128 MB region that is kept close to
> the core kernel, in order to ensure that relative branches are
> always in range. So using the same region for programs that do
> not have this restriction is wastefu
On 11/29/2018 04:20 AM, Phil Sutter wrote:
> When fixing for shift/reduce conflicts, possibility to invert the last
> expression by prefixing with '!' or 'not' was accidentally removed.
>
> Fix this by allowing for expr to be an inverted expr so that any
> reference to it in exprlist accepts th
Bit RX_USED set to 0 in the address field allows the controller to write
data to the receive buffer descriptor.
The driver does not ensure the ctrl field is ready (cleared) when the
controller sees the RX_USED=0 written by the driver. The ctrl field might
only be cleared after the controller has a
64-bit DMA addresses are split in upper and lower halves that are
written in separate fields on GEM. For RX, bit 0 of the address is used
as the ownership bit (RX_USED). When the RX_USED bit is unset the
controller is allowed to write data to the buffer.
The driver does not guarantee that the cont
When reading buffer descriptors on RX or on TX completion, an
RX_USED/TX_USED bit is checked first to ensure that the descriptor has
been populated. However, there are no memory barriers to ensure that the
data protected by the RX_USED/TX_USED bit is up-to-date with respect to
that bit.
Fix that b
Hi all,
Here are a couple of race condition fixes for the macb driver. The first
two are issues observed on real HW.
Anssi Hannula (3):
net: macb: fix random memory corruption on RX with 64-bit DMA
net: macb: fix dropped RX frames due to a race
net: macb: add missing barriers wh
On Sat, Dec 01, 2018 at 01:36:59AM +0800, Xin Long wrote:
> In sctp_hash_transport/sctp_epaddr_lookup_transport, it dereferences
> a transport's asoc under rcu_read_lock while asoc is freed not after
> a grace period, which leads to a use-after-free panic.
>
> This patch fixes it by calling kfree_
My dear I contacted you few days ago but couldn’t get your response; I
like to share very vital information with you so do get back to me for
details.
On Fri, 30 Nov 2018 14:33:49 +0100
Alexis Vachette wrote:
> When using:
>
> - ip -s link
>
> I think it should be better to print errors stats without adding -s
> option twice.
>
> This option print stats for each network interfaces and we want to see
> if something is off and especially timer
On 2018-11-11 21:01:05 [-0500], Steven Rostedt wrote:
> On Sun, 11 Nov 2018 21:16:00 +0100
> Oleksandr Natalenko wrote:
> > Oh, I see that write_msg() calls netpoll_send_udp() under
> > spin_lock_irqsave(), but in PREEMPT_RT this, AFAIK, does not disable
> > interrupts.
> >
> > So, the real que
On Thu, 29 Nov 2018 at 16:30, Joe Stringer wrote:
>
> David Ahern and Nicolas Dichtel report that the handling of the netns id
> 0 is incorrect for the BPF socket lookup helpers: rather than finding
> the netns with id 0, it is resolving to the current netns. This renders
> the netns_id 0 inaccess
The amount of DMA mappings from Hisilicon HNS ethernet devices is huge,
so it could trigger "DMA-API: debugging out of memory - disabling".
hnae_get_handle [1]
hnae_init_queue
hnae_init_ring
hnae_alloc_buffers [2]
debug_dma_map_page
dma_entry_alloc
[1] for (i = 0; i
On Sat, Dec 01, 2018 at 01:36:59AM +0800, Xin Long wrote:
> In sctp_hash_transport/sctp_epaddr_lookup_transport, it dereferences
> a transport's asoc under rcu_read_lock while asoc is freed not after
> a grace period, which leads to a use-after-free panic.
>
> This patch fixes it by calling kfree_
On 11/30/2018 1:25 AM, Kunihiko Hayashi wrote:
> Even though the link is down before entering hibernation,
> there is an issue that the network interface always links up after resuming
> from hibernation.
>
> The phydev->state is PHY_READY before enabling the network interface, so
> the link is
Hi Baruch,
On mar., oct. 16 2018, Baruch Siach wrote:
> This reset signal controls the Marvell 1512 1G PHY.
>
> Note that current implementation queries the PHY over the MDIO bus
> (get_phy_device() call from of_mdiobus_register_phy()) before reset
> signal deassert. If the PHY reset signal is
Hi Baruch,
On mar., oct. 16 2018, Baruch Siach wrote:
> The fixed regulator driver ignores the gpio flags, so this change has
> no practical effect in the current implementation. Fix it anyway to
> correct the hardware description.
>
Applied on mvebu/dt64
Thanks,
Gregory
> Signed-off-by: B
On 11/30/2018 9:34 AM, Steve Douthit wrote:
> On 11/30/18 11:34 AM, Andrew Lunn wrote:
>>> Yep, registering multiple interfaces is wrong. The first board I tested
>>> against only had a single MAC enabled (they can be disabled/hidden via
>>> straps) so it just happened to work.
>>
>> Hi Steve
>
Hi Greg,
On 11/29/2018 11:57 PM, g...@kernel.org wrote:
> From: Greg Ungerer
>
> Add descriptive entries for the new bindings introduced to support the
> MT7530 implementation in the MediaTek MT7621 SoC.
>
> New bindings added for:
>
> mediatek,no-clock-regulator
> mediatek,mfc-has-cpuport
In sctp_hash_transport/sctp_epaddr_lookup_transport, it dereferences
a transport's asoc under rcu_read_lock while asoc is freed not after
a grace period, which leads to a use-after-free panic.
This patch fixes it by calling kfree_rcu to make asoc be freed after
a grace period.
Note that only the
On 11/30/18 11:34 AM, Andrew Lunn wrote:
>> Yep, registering multiple interfaces is wrong. The first board I tested
>> against only had a single MAC enabled (they can be disabled/hidden via
>> straps) so it just happened to work.
>
> Hi Steve
>
> Can you hide any/all via straps, or is 00.0 alway
Hi Simon,
On Fri, Nov 30, 2018 at 03:39:05PM +0100, Simon Horman wrote:
> On Wed, Nov 28, 2018 at 12:12:32PM +0100, Phil Sutter wrote:
> > The different encapsulation types are described in ENCAP_*
> > non-terminals, but ENCAP definition lists them without the ENCAP_
> > prefix. Fix this for consi
Commit a5681e20b541 ("net/ibmnvic: Fix deadlock problem
in reset") made the change to hold the RTNL lock during
driver reset but still calls netdev_notify_peers, which
results in a deadlock. Instead, use call_netdevice_notifiers,
which is functionally the same except that it does not
take the RTNL
On Fri, Nov 30, 2018 at 08:17:04AM -0800, Eric Dumazet wrote:
> On Fri, Nov 30, 2018 at 8:10 AM Dmitry Vyukov wrote:
> >
> > On Fri, Nov 30, 2018 at 4:02 PM, Ido Schimmel wrote:
> > > On Fri, Nov 30, 2018 at 08:59:09AM -0700, David Ahern wrote:
> > >> This does not repro for me:
> > >> # ./a.out
On Sat, Dec 01, 2018 at 12:24:16AM +0800, Tiwei Bie wrote:
> On Fri, Nov 30, 2018 at 10:53:07AM -0500, Michael S. Tsirkin wrote:
> > On Fri, Nov 30, 2018 at 11:37:37PM +0800, Tiwei Bie wrote:
> > > On Fri, Nov 30, 2018 at 08:52:42AM -0500, Michael S. Tsirkin wrote:
> > > > On Fri, Nov 30, 2018 at 0
> Yep, registering multiple interfaces is wrong. The first board I tested
> against only had a single MAC enabled (they can be disabled/hidden via
> straps) so it just happened to work.
Hi Steve
Can you hide any/all via straps, or is 00.0 always guaranteed to
exist?
> The Intel C3xxx family of
On Fri, Nov 30, 2018 at 03:58:34PM +0300, Dan Carpenter wrote:
> The pps_register_source() function doesn't return NULL, it returns
> error pointers.
It keeps a local variable for errno, but then it returns NULL.
But this is about to change with this recent patch:
26.Nov'18 YueHaibing [PATCH -
On Fri, Nov 30, 2018 at 10:53:07AM -0500, Michael S. Tsirkin wrote:
> On Fri, Nov 30, 2018 at 11:37:37PM +0800, Tiwei Bie wrote:
> > On Fri, Nov 30, 2018 at 08:52:42AM -0500, Michael S. Tsirkin wrote:
> > > On Fri, Nov 30, 2018 at 02:01:06PM +0100, Maxime Coquelin wrote:
> > > > On 11/30/18 1:47 PM
Fix bash completion for "bpftool prog (attach|detach) PROG TYPE MAP" so
that the list of indices proposed for MAP are map indices, and not PROG
indices. Also use variables for map and prog reference types ("id",
"pinned", and "tag" for programs).
Fixes: b7d3826c2ed6 ("bpf: bpftool, add support for
Hi,
Several items for bpftool are included in this set: the first three patches
are fixes for bpftool itself and bash completion, while the last two
slightly improve the information obtained when dumping programs or maps, on
Daniel's suggestion. Please refer to individual commit logs for more
detai
The getpid() function is called in a couple of places in bpftool to
craft links of the shape "/proc//...". Instead, it is possible to
use the "/proc/self/" shortcut, which makes things a bit easier, in
particular in jit_disasm.c.
Do the replacement, and remove the includes of from the
relevant fi
Commit 197c2dac74e4 ("bpf: Add BPF_MAP_TYPE_QUEUE and BPF_MAP_TYPE_STACK
to bpftool-map") added support for queue and stack eBPF map types in
bpftool map handling. Let's update the bash completion accordingly.
Fixes: 197c2dac74e4 ("bpf: Add BPF_MAP_TYPE_QUEUE and BPF_MAP_TYPE_STACK to
bpftool-map
For prog array maps, the type of the owner program, and the JIT-ed state
of that program, are available from the file descriptor information
under /proc. Add them to "bpftool map show" output. Example output:
# bpftool map show
158225: prog_array name jmp_table flags 0x0
key 4B
In bpftool (plain) output for "bpftool prog show" or "bpftool map show",
an offloaded BPF object is simply denoted with "dev ifname", which is
not really explicit. Change it with something that clearly shows the
program is offloaded.
While at it also add an additional space, as done between other
On Fri, Nov 30, 2018 at 8:10 AM Dmitry Vyukov wrote:
>
> On Fri, Nov 30, 2018 at 4:02 PM, Ido Schimmel wrote:
> > On Fri, Nov 30, 2018 at 08:59:09AM -0700, David Ahern wrote:
> >> This does not repro for me:
> >> # ./a.out
> >> Invalid address length 6 - must be 4 bytes
> >> RTNETLINK answers: No
On Fri, Nov 30, 2018 at 4:02 PM, Ido Schimmel wrote:
> On Fri, Nov 30, 2018 at 08:59:09AM -0700, David Ahern wrote:
>> This does not repro for me:
>> # ./a.out
>> Invalid address length 6 - must be 4 bytes
>> RTNETLINK answers: No buffer space available
>> RTNETLINK answers: Operation not supporte
Commit 78139c94dc8c ("net: vhost: lock the vqs one by one") moved the vq
lock to improve scalability, but introduced a possible deadlock in
vhost-iotlb. vhost_iotlb_notify_vq() now takes vq->mutex while holding
the device's IOTLB spinlock. And on the vhost_iotlb_miss() path, the
spinlock is taken w
On Fri, Nov 30, 2018 at 08:59:09AM -0700, David Ahern wrote:
> This does not repro for me:
> # ./a.out
> Invalid address length 6 - must be 4 bytes
> RTNETLINK answers: No buffer space available
> RTNETLINK answers: Operation not supported
> Invalid address length 6 - must be 4 bytes
> Invalid addr
On Fri, Nov 30, 2018 at 07:51:34AM -0800, Eric Dumazet wrote:
> On Fri, Nov 30, 2018 at 7:46 AM Eric Dumazet wrote:
> >
> > On Fri, Nov 30, 2018 at 7:40 AM Eric Dumazet wrote:
> > >
> > > On Fri, Nov 30, 2018 at 7:36 AM David Ahern wrote:
> > > >
> > > > On 11/30/18 7:58 AM, Ido Schimmel wrote:
101 - 200 of 289 matches
Mail list logo
