On 2021/1/30 3:11, Jay Vosburgh wrote:
> moyufeng wrote:
>
>> Ping...
>> Any comments? Thanks!
>>
>> On 2021/1/15 10:02, moyufeng wrote:
>>> Hi Team,
>>>
>>> I have a question about bonding. During testing bonding mode 4
>>> scenarios, I find that there is a very low probability that
>>> the p
moyufeng wrote:
>Ping...
>Any comments? Thanks!
>
>On 2021/1/15 10:02, moyufeng wrote:
>> Hi Team,
>>
>> I have a question about bonding. During testing bonding mode 4
>> scenarios, I find that there is a very low probability that
>> the pointer is null. The following information is displayed:
>
Ping...
Any comments? Thanks!
On 2021/1/15 10:02, moyufeng wrote:
> Hi Team,
>
> I have a question about bonding. During testing bonding mode 4
> scenarios, I find that there is a very low probability that
> the pointer is null. The following information is displayed:
>
> [99359.795934] bond0: (
On 1/11/21 12:17 AM, Tiezhu Yang wrote:
Hi all,
I found the following build errors and warnings when make M=samples/bpf
on the Loongson 3A3000 platform which belongs to MIPS arch.
Are theseknown issues? Should I submit patches to fix them? (1) fatal
error: 'asm/rwonce.h' file not found
Th
> I thought as much, but maybe there is some driver which can offload
> whole i2c_transfer to HW, and has to pass the addresses of the buffers
> to the HW, and the HW can have problems if the buffers overlap
> somewhere...
Well, sure, you can never know what crazy HW is out there :) But that
shou
On Thu, 7 Jan 2021 22:02:48 +0100
Wolfram Sang wrote:
> > My question is whether this is allowed, whether the msgs array passed
> > to the i2c_transfer() function can have multiple msgs pointing to the
> > same buffer (the one into which the original page is first stored
> > with first i2c_msg an
> My question is whether this is allowed, whether the msgs array passed
> to the i2c_transfer() function can have multiple msgs pointing to the
> same buffer (the one into which the original page is first stored
> with first i2c_msg and then restored from it in the last i2c_msg).
Sending the mess
I forgot to mail to Dan Johansen as well.
Jian-Hong Pan 於 2020年9月30日 週三 下午4:15寫道：
>
> Hi,
>
> According to the preloaded system Manjaro ARM on Pinebook Pro [1], I
> found the firmware files in ap6256-firmware package [2] enable the
> wireless module, including WiFi and Bluetooth.
> If we want to
On Tue, Sep 8, 2020 at 6:23 PM Xie He wrote:
>
> On Tue, Sep 8, 2020 at 4:53 AM Willem de Bruijn
> wrote:
> >
> > On Tue, Sep 8, 2020 at 1:04 PM Xie He wrote:
> > >
> > > I was recently looking at some drivers, and I felt that if af_packet.c
> > > could help me filter out the invalid RAW frames,
On Tue, Sep 8, 2020 at 4:53 AM Willem de Bruijn
wrote:
>
> On Tue, Sep 8, 2020 at 1:04 PM Xie He wrote:
> >
> > I was recently looking at some drivers, and I felt that if af_packet.c
> > could help me filter out the invalid RAW frames, I didn't need to
> > check the validity of the frames myself
On Tue, Sep 8, 2020 at 1:04 PM Xie He wrote:
>
> On Tue, Sep 8, 2020 at 1:41 AM Willem de Bruijn
> wrote:
> >
> > The intent is to bypass such validation to be able to test device
> > drivers. Note that removing that may cause someone's test to start
> > failing.
> >
> > > So there's no point in
On Tue, Sep 8, 2020 at 1:41 AM Willem de Bruijn
wrote:
>
> The intent is to bypass such validation to be able to test device
> drivers. Note that removing that may cause someone's test to start
> failing.
>
> > So there's no point in
> > keeping the ability to test this, either.
>
> I don't disag
On Mon, Sep 7, 2020 at 11:17 PM Xie He wrote:
>
> On Mon, Sep 7, 2020 at 2:06 AM Willem de Bruijn
> wrote:
> >
> > The CAP_SYS_RAWIO exception indeed was requested to be able to
> > purposely test devices against bad inputs. The gmane link
> > unfortunately no longer works, but this was the discu
On Mon, Sep 7, 2020 at 2:06 AM Willem de Bruijn
wrote:
>
> The CAP_SYS_RAWIO exception indeed was requested to be able to
> purposely test devices against bad inputs. The gmane link
> unfortunately no longer works, but this was the discussion thread:
> https://www.mail-archive.com/netdev@vger.kern
On Sun, Sep 6, 2020 at 1:21 AM Xie He wrote:
>
> On Sat, Sep 5, 2020 at 3:24 PM Xie He wrote:
> >
> > Hi Willem,
> >
> > I have a question about the function dev_validate_header used in
> > af_packet.c. Can you help me? Thanks!
> >
> > I see when the length of the data is smaller than hard_header
On Sat, Sep 5, 2020 at 3:24 PM Xie He wrote:
>
> Hi Willem,
>
> I have a question about the function dev_validate_header used in
> af_packet.c. Can you help me? Thanks!
>
> I see when the length of the data is smaller than hard_header_len, and
> when the user is "capable" enough, the function will
On Sat, Sep 5, 2020 at 12:28 AM Yang Yingliang wrote:
>
> Hi,
>
> I got some crashes when using connector module in linux-4.19:
Can you test a reasonably recent kernel?
> The invalid address[0x0003004c] is the value of nlmsghdr from cn
> netlink, nlmsg_type is 3 and nlmsg_len is 0x4c.
Sorry for responding late. I got engaged with other work.
I didn't replace ingress with
To do more experiments, I will have to recompile everything
from fresh as I lost that setup where I was experimenting with
tc utility.
But if we can get inputs from Daniel's about this change,
it will hel
On Thu, Aug 6, 2020 at 10:21 AM satish dhote wrote:
>
> Hi Cong,
>
> I tried adding below patch i.e. "return cl == 0 ? q->block : NULL;"
> but after this I'm not able to see any output using "tc filter show... "
> command. Looks like the filter is not getting configured.
What exact command did yo
Hi Cong,
I tried adding below patch i.e. "return cl == 0 ? q->block : NULL;"
but after this I'm not able to see any output using "tc filter show... "
command. Looks like the filter is not getting configured.
If this is a bug, then do I need to file a new ticket for this?
Thanks
Satish
On Thu, A
Hello,
On Tue, Aug 4, 2020 at 10:39 PM satish dhote wrote:
>
> Hi Team,
>
> I have a question regarding tc filter behavior. I tried to look
> for the answer over the web and netdev FAQ but didn't get the
> answer. Hence I'm looking for your help.
>
> I added ingress qdisc for interface enp0s25 an
On Wed, 5 Aug 2020 11:08:08 +0530 satish dhote wrote:
> Hi Team,
>
> I have a question regarding tc filter behavior. I tried to look
> for the answer over the web and netdev FAQ but didn't get the
> answer. Hence I'm looking for your help.
>
> I added ingress qdisc for interface enp0s25 and then
Hi Jakub,
Thanks for your response. Below are the OS and Kernel version I'm using.
OS: Ubuntu 20.04.1 LTS
Kernel Version: 5.4.0-42-generic
Thanks
Satish
On Wed, Aug 5, 2020 at 10:15 PM Jakub Kicinski wrote:
>
> On Wed, 5 Aug 2020 11:08:08 +0530 satish dhote wrote:
> > Hi Team,
> >
> > I have a
On Mon, 2020-07-27 at 16:47 -0700, Stephen Hemminger wrote:
> On Sun, 26 Jul 2020 21:46:16 -0700
> Briana Oursler wrote:
>
> > I have a patch I've written to address a format specifier change
> > that
> > breaks some tests in tc-testing, but I wanted to ask about the
> > change
> > and for some g
On Mon, 2020-07-27 at 21:31 +0200, Petr Machata wrote:
> Briana Oursler writes:
>
> > I git bisected and found d0e450438571("tc: q_red: Add support for
> > qevents "mark" and "early_drop"), the commit that introduced the
> > formatting change causing the break.
> >
> > - print_string(PRINT
On Sun, 26 Jul 2020 21:46:16 -0700
Briana Oursler wrote:
> I have a patch I've written to address a format specifier change that
> breaks some tests in tc-testing, but I wanted to ask about the change
> and for some guidance with respect to how formatters are approached in
> iproute2.
>
> On a
On Mon, 27 Jul 2020 21:31:36 +0200
Petr Machata wrote:
> Briana Oursler writes:
>
> > I git bisected and found d0e450438571("tc: q_red: Add support for
> > qevents "mark" and "early_drop"), the commit that introduced the
> > formatting change causing the break.
> >
> > - print_string(PRIN
Briana Oursler writes:
> I git bisected and found d0e450438571("tc: q_red: Add support for
> qevents "mark" and "early_drop"), the commit that introduced the
> formatting change causing the break.
>
> - print_string(PRINT_FP, NULL, "max %s ", sprint_size(qopt->qth_max,
> b3));
> +
On Sun, Jul 26, 2020 at 2:18 PM Han wrote:
>
> On Sun, Jul 26, 2020 at 6:42 AM Willem de Bruijn
> wrote:
> >
> > On Sat, Jul 25, 2020 at 7:08 PM Han wrote:
> > >
> > > My apologies if this is not the right place to ask this question.
> > >
> > > I'm trying to use UDP GSO to improve the throughpu
On Sun, Jul 26, 2020 at 6:42 AM Willem de Bruijn
wrote:
>
> On Sat, Jul 25, 2020 at 7:08 PM Han wrote:
> >
> > My apologies if this is not the right place to ask this question.
> >
> > I'm trying to use UDP GSO to improve the throughput. My testing shows
> > that UDP GSO works with the local serv
On Sat, Jul 25, 2020 at 7:08 PM Han wrote:
>
> My apologies if this is not the right place to ask this question.
>
> I'm trying to use UDP GSO to improve the throughput. My testing shows
> that UDP GSO works with the local server (i.e. loopback interface) but
> fails with a remote server (in WLAN,
On 6/20/20 4:35 PM, Andrew Lunn wrote:
>> So yes, we can read the code here, but I'm wondering which packet types
>> would then get this flag set, and which won't. Because in case of
>> IGMP/MLD, the packets are in fact forwarded, but the meaning of the flag
>> in skb is to prevent the skb from bei
> So yes, we can read the code here, but I'm wondering which packet types
> would then get this flag set, and which won't. Because in case of
> IGMP/MLD, the packets are in fact forwarded, but the meaning of the flag
> in skb is to prevent the skb from being forwarded further, which seems
> wrong i
On 6/20/20 12:36 AM, Andrew Lunn wrote:
>> I've run into the same issue. To resolve it, In my case, in the same file,
>> I've had to send all IGMP control traffic to the CPU:
>> skb->offload_fwd_mark = 1;
>> switch (ih->type) {
>> case IGMP_HOST_MEMBERSHIP_REPORT:
>>
Hi Andrew,
Thanks a lot for the quick reply!
On 6/19/20 11:58 PM, Andrew Lunn wrote:
> On Fri, Jun 19, 2020 at 11:31:04PM +0200, Daniel Mack wrote:
>> When an IGMP query enters the switch, it is redirected to the CPU port
>> as all 'external' ports are configured for IGMP/MLP snooping by the
>>
> I've run into the same issue. To resolve it, In my case, in the same file,
> I've had to send all IGMP control traffic to the CPU:
> skb->offload_fwd_mark = 1;
> switch (ih->type) {
> case IGMP_HOST_MEMBERSHIP_REPORT:
> case IGMPV2_HOST_MEMBERSHIP_REPORT:
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Andrew Lunn
> Sent: Friday, June 19, 2020 2:58 PM
> To: Daniel Mack
> Cc: netdev@vger.kernel.org; Ido Schimmel; Jiri Pirko; Ivan Vecera; Florian
> F
On Fri, Jun 19, 2020 at 11:31:04PM +0200, Daniel Mack wrote:
> Hi,
>
> I'm working on a custom board featuring a Marvell mv88e6085 Ethernet
> switch controlled by the Linux DSA driver, and I'm facing an issue with
> IGMP packet flows.
>
> Consider two Ethernet stations, each connected to the swit
On 2020/5/13 9:59, Andrew Lunn wrote:
> On Wed, May 13, 2020 at 09:34:13AM +0800, Yonglong Liu wrote:
>> Hi, Andrew:
>> Thanks for your reply!
>>
>> On 2020/5/12 22:00, Andrew Lunn wrote:
>>> On Tue, May 12, 2020 at 08:48:21PM +0800, Yonglong Liu wrote:
I use two devices, both support 100
On Wed, May 13, 2020 at 09:34:13AM +0800, Yonglong Liu wrote:
> Hi, Andrew:
> Thanks for your reply!
>
> On 2020/5/12 22:00, Andrew Lunn wrote:
> > On Tue, May 12, 2020 at 08:48:21PM +0800, Yonglong Liu wrote:
> >> I use two devices, both support 1000M speed, they are directly connected
> >>
Hi, Andrew:
Thanks for your reply!
On 2020/5/12 22:00, Andrew Lunn wrote:
> On Tue, May 12, 2020 at 08:48:21PM +0800, Yonglong Liu wrote:
>> I use two devices, both support 1000M speed, they are directly connected
>> with a network cable. Two devices enable autoneg, and then do the followi
On Tue, May 12, 2020 at 08:48:21PM +0800, Yonglong Liu wrote:
> I use two devices, both support 1000M speed, they are directly connected
> with a network cable. Two devices enable autoneg, and then do the following
> test repeatedly:
> ifconfig eth5 down
> ifconfig eth5 up
> sleep
On 2019/9/27 16:13, Jiri Pirko wrote:
> Fri, Sep 27, 2019 at 09:40:47AM CEST, linyunsh...@huawei.com wrote:
>> Hi, Jiri & Alex
>>
>>It seems that a region' snapshot is only created through the
>> driver when some error is detected, for example:
>> mlx4_crdump_collect_fw_health() -> devlink_regi
Fri, Sep 27, 2019 at 09:40:47AM CEST, linyunsh...@huawei.com wrote:
>Hi, Jiri & Alex
>
>It seems that a region' snapshot is only created through the
>driver when some error is detected, for example:
>mlx4_crdump_collect_fw_health() -> devlink_region_snapshot_create()
>
>We want to trigger a
Madhavi Joshi wrote:
> We have a question regarding LACP Bypass feature . It appears that by
>default, this feature is enabled in the kernel (we are on 4.1.1274 version
>kernel).
>Having said that, we do not see any sysctl or directory on the lines of
>/sys/class/net//bonding/lacp_bypass.
>
Hello,
We have a question regarding LACP Bypass feature . It appears that by
default, this feature is enabled in the kernel (we are on 4.1.1274 version
kernel).
Having said that, we do not see any sysctl or directory on the lines of
/sys/class/net//bonding/lacp_bypass.
Really appreciate y
On 18.08.19 10:31, Dongli Zhang wrote:
Hi,
Would you please help confirm why the condition at line 908 is ">="?
In my opinion, we would only hit "skb_shinfo(skb)->nr_frag == MAX_SKB_FRAGS" at
line 908.
890 static RING_IDX xennet_fill_frags(struct netfront_queue *queue,
891
etdev@vger.kernel.org; Wei Wang ;
Martin KaFai Lau ; Eric Dumazet
Subject: Re: Question about linux kernel commit: "net/ipv6: move metrics from
dst to rt6_info"
On 7/10/19 1:09 PM, Stefano Brivio wrote:
> Jan,
>
> On Wed, 10 Jul 2019 12:59:41 +
> Jan Szewczyk wrote:
>
On 7/10/19 1:09 PM, Stefano Brivio wrote:
> Jan,
>
> On Wed, 10 Jul 2019 12:59:41 +
> Jan Szewczyk wrote:
>
>> Hi!
>> I digged up a little further and maybe it's not a problem with MTU
>> itself. I checked every entry I get from RTM_GETROUTE netlink message
>> and after triggering "too big p
Jan,
On Wed, 10 Jul 2019 12:59:41 +
Jan Szewczyk wrote:
> Hi!
> I digged up a little further and maybe it's not a problem with MTU
> itself. I checked every entry I get from RTM_GETROUTE netlink message
> and after triggering "too big packet" by pinging ipv6address I get
> exactly the same m
ould try to reproduce it locally on some
virtual box and check if it behaves the same.
Thanks for the tip about the testing tools, I'll try to use them.
BR,
Jan Szewczyk
-Original Message-
From: David Ahern
Sent: Wednesday, July 10, 2019 14:28
To: Jan Szewczyk ; da...@davemloft.ne
[ adding netdev so others can chime in ]
On 7/10/19 2:28 AM, Jan Szewczyk wrote:
> Hi guys!
>
> We can see different behavior of one of our commands that supposed to
> show pmtu information.
>
> It’s using netlink message RTM_GETROUTE to get the information and in
> Linux kernel version 4.12 aft
Naruto Nguyen wrote:
> Could you please elaborate more on how generic tracker tracks ESP connection?
All protocols that do not have a more specific l4 tracker are tracked
based on l3 protocol + l4 proto number.
IOW, any ESP packet sent between the same endpoint addresses is seen
as matching a si
Hi Florian,
Thanks a lot for your reply.
Could you please elaborate more on how generic tracker tracks ESP connection?
Brs,
Bao
On Wed, 26 Jun 2019 at 18:13, Florian Westphal wrote:
>
> Naruto Nguyen wrote:
> > In linux/latest/source/net/netfilter/ folder, I only see we have
> > nf_conntrack_
Naruto Nguyen wrote:
> In linux/latest/source/net/netfilter/ folder, I only see we have
> nf_conntrack_proto_tcp.c, nf_conntrack_proto_udp.c and some other
> conntrack implementations for other protocols but I do not see
> nf_conntrack_proto for IPsec, so does it mean connection tracking
> cannot
On Wed, May 22, 2019 at 11:44:26AM +0800, Jason Wang wrote:
>
> On 2019/5/21 下午9:56, Michael S. Tsirkin wrote:
> > On Tue, May 21, 2019 at 03:49:20PM +0200, Stefano Garzarella wrote:
> > > On Tue, May 21, 2019 at 06:05:31AM -0400, Michael S. Tsirkin wrote:
> > > > On Tue, May 21, 2019 at 11:44:07A
On 2019/5/21 下午9:56, Michael S. Tsirkin wrote:
On Tue, May 21, 2019 at 03:49:20PM +0200, Stefano Garzarella wrote:
On Tue, May 21, 2019 at 06:05:31AM -0400, Michael S. Tsirkin wrote:
On Tue, May 21, 2019 at 11:44:07AM +0200, Stefano Garzarella wrote:
Hi Micheal, Jason,
as suggested by Stefan
On Tue, May 21, 2019 at 09:56:42AM -0400, Michael S. Tsirkin wrote:
> On Tue, May 21, 2019 at 03:49:20PM +0200, Stefano Garzarella wrote:
> > On Tue, May 21, 2019 at 06:05:31AM -0400, Michael S. Tsirkin wrote:
> > > On Tue, May 21, 2019 at 11:44:07AM +0200, Stefano Garzarella wrote:
> > > > Hi Mich
On Tue, May 21, 2019 at 03:49:20PM +0200, Stefano Garzarella wrote:
> On Tue, May 21, 2019 at 06:05:31AM -0400, Michael S. Tsirkin wrote:
> > On Tue, May 21, 2019 at 11:44:07AM +0200, Stefano Garzarella wrote:
> > > Hi Micheal, Jason,
> > > as suggested by Stefan, I'm checking if we have some races
On Tue, May 21, 2019 at 06:05:31AM -0400, Michael S. Tsirkin wrote:
> On Tue, May 21, 2019 at 11:44:07AM +0200, Stefano Garzarella wrote:
> > Hi Micheal, Jason,
> > as suggested by Stefan, I'm checking if we have some races in the
> > virtio-vsock driver. We found some races in the .probe() and .re
On Tue, May 21, 2019 at 11:44:07AM +0200, Stefano Garzarella wrote:
> Hi Micheal, Jason,
> as suggested by Stefan, I'm checking if we have some races in the
> virtio-vsock driver. We found some races in the .probe() and .remove()
> with the upper layer (socket) and I'll fix it.
>
> Now my attentio
On Thu, May 9, 2019 at 4:30 PM Alexei Starovoitov
wrote:
> I'm not sure how that can work. seccomp's prctl accepts a list of insns.
> There is no handle.
> kernel can keep a hashtable of all progs ever loaded and do a search
> in it before loading another one, but that's an ugly hack.
> Another al
On Thu, May 9, 2019 at 4:30 PM Alexei Starovoitov
wrote:
>
> On Thu, May 09, 2019 at 01:49:25PM +0200, Daniel Borkmann wrote:
> > On 05/09/2019 12:58 PM, Eric Dumazet wrote:
> > > On Thu, May 9, 2019 at 3:52 AM Eric Dumazet wrote:
> > >> On Wed, May 8, 2019 at 9:47 PM Alexei Starovoitov
> > >> w
On Thu, May 09, 2019 at 04:50:12PM -0700, Eric Dumazet wrote:
> On Thu, May 9, 2019 at 4:30 PM Alexei Starovoitov
> wrote:
> >
> > On Thu, May 09, 2019 at 01:49:25PM +0200, Daniel Borkmann wrote:
> > > On 05/09/2019 12:58 PM, Eric Dumazet wrote:
> > > > On Thu, May 9, 2019 at 3:52 AM Eric Dumazet
On Thu, May 09, 2019 at 01:49:25PM +0200, Daniel Borkmann wrote:
> On 05/09/2019 12:58 PM, Eric Dumazet wrote:
> > On Thu, May 9, 2019 at 3:52 AM Eric Dumazet wrote:
> >> On Wed, May 8, 2019 at 9:47 PM Alexei Starovoitov
> >> wrote:
> >>> On Wed, May 08, 2019 at 04:17:29PM -0700, Eric Dumazet wro
On 05/09/2019 12:58 PM, Eric Dumazet wrote:
> On Thu, May 9, 2019 at 3:52 AM Eric Dumazet wrote:
>> On Wed, May 8, 2019 at 9:47 PM Alexei Starovoitov
>> wrote:
>>> On Wed, May 08, 2019 at 04:17:29PM -0700, Eric Dumazet wrote:
On Wed, May 8, 2019 at 4:09 PM Alexei Starovoitov
wrote:
>>>
On Thu, May 9, 2019 at 3:52 AM Eric Dumazet wrote:
>
> On Wed, May 8, 2019 at 9:47 PM Alexei Starovoitov
> wrote:
> >
> > On Wed, May 08, 2019 at 04:17:29PM -0700, Eric Dumazet wrote:
> > > On Wed, May 8, 2019 at 4:09 PM Alexei Starovoitov
> > > wrote:
> > > >
> > > > On Wed, May 08, 2019 at 02:
On Wed, May 8, 2019 at 9:47 PM Alexei Starovoitov
wrote:
>
> On Wed, May 08, 2019 at 04:17:29PM -0700, Eric Dumazet wrote:
> > On Wed, May 8, 2019 at 4:09 PM Alexei Starovoitov
> > wrote:
> > >
> > > On Wed, May 08, 2019 at 02:21:52PM -0700, Eric Dumazet wrote:
> > > > Hi Alexei and Daniel
> > >
On Wed, May 08, 2019 at 04:17:29PM -0700, Eric Dumazet wrote:
> On Wed, May 8, 2019 at 4:09 PM Alexei Starovoitov
> wrote:
> >
> > On Wed, May 08, 2019 at 02:21:52PM -0700, Eric Dumazet wrote:
> > > Hi Alexei and Daniel
> > >
> > > I have a question about seccomp.
> > >
> > > It seems that after t
On Wed, May 8, 2019 at 4:09 PM Alexei Starovoitov
wrote:
>
> On Wed, May 08, 2019 at 02:21:52PM -0700, Eric Dumazet wrote:
> > Hi Alexei and Daniel
> >
> > I have a question about seccomp.
> >
> > It seems that after this patch, seccomp no longer needs a helper
> > (seccomp_bpf_load())
> >
> > htt
On Wed, May 08, 2019 at 02:21:52PM -0700, Eric Dumazet wrote:
> Hi Alexei and Daniel
>
> I have a question about seccomp.
>
> It seems that after this patch, seccomp no longer needs a helper
> (seccomp_bpf_load())
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=
On 4/16/19 8:00 AM, Florian Westphal wrote:
> Lorenz Bauer wrote:
>> Apologies for contacting you out of the blue. I'm currently trying to
>> understand how TPROXY works under the hood. As part of this endeavour,
>> I've stumbled upon the commit attached to this email.
>>
>> From the commit mes
Hello Florian,
Thank you, that makes sense. I guess that technically early demux also
relies on the skb_orphan call to function? I think that's what
confused me.
Best
Lorenz
On Tue, 16 Apr 2019 at 17:00, Florian Westphal wrote:
>
> Lorenz Bauer wrote:
> > Apologies for contacting you out of th
Lorenz Bauer wrote:
> Apologies for contacting you out of the blue. I'm currently trying to
> understand how TPROXY works under the hood. As part of this endeavour,
> I've stumbled upon the commit attached to this email.
>
> From the commit message I infer that somewhere, TPROXY relies on a
> che
From: maowenan
Date: Tue, 5 Mar 2019 11:33:03 +0800
>
>
> On 2019/3/5 2:16, David Miller wrote:
>> From: maowenan
>> Date: Mon, 4 Mar 2019 20:47:42 +0800
>>
>>> pmc->tomb = psf;
>>> rv = 1; //if it does not kfree(psf), will it
>>> lead to memor
On 2019/3/5 2:16, David Miller wrote:
> From: maowenan
> Date: Mon, 4 Mar 2019 20:47:42 +0800
>
>> pmc->tomb = psf;
>> rv = 1; //if it does not kfree(psf), will it
>> lead to memory leak after this line?
>
> pmc->tomb points to psf, why shoul
From: maowenan
Date: Mon, 4 Mar 2019 20:47:42 +0800
> pmc->tomb = psf;
> rv = 1; //if it does not kfree(psf), will it
> lead to memory leak after this line?
pmc->tomb points to psf, why should we free it?
> -Original Message-
> From: Michal Vokáč [mailto:michal.vo...@ysoft.com]
> Sent: Friday, March 01, 2019 8:58 PM
> To: liweihang
> Cc: netdev@vger.kernel.org; da...@davemloft.net; linyunsheng
> ; Zhuangyuzeng (Yisen)
> ; Salil Mehta ;
> lipeng (Y) ; shenjian (K)
(+) LinuxArm
> From: Michal Vokáč [mailto:michal.vo...@ysoft.com]
> Sent: Friday, March 1, 2019 12:58 PM
> To: liweihang
> Cc: netdev@vger.kernel.org; da...@davemloft.net; linyunsheng
> ; Zhuangyuzeng (Yisen)
> ; Salil Mehta ; lipeng
> (Y) ; shenjian (K)
> Subject: Re
On 01. 03. 19 12:26, liweihang wrote:
Hi all,
We encountered a problem that if there are two devices in kernel v5.0 with
marvell phy 88E1510 connect with each other directly, one with autoneg on and
the other off. The one who has disabled auto-negotiation will failed on setting
speed and duplex
Hi Michael ,
I have solved all the data race issue , it seems.
The data race culprit is the ring index which I have removed
in the latest datarace-free code.
The diff can be found at https://www.diffchecker.com/w0Pxp2mF
I plan to study the internal implementation of ptr_ring c coding
in the comi
Hi Michael,
> If I had to guess I'd say the way you play with indices is probably racy
> so you are producing an invalid index.
You are probably right.
I am suspecting item_recv_push_index and item_send_push_index in
https://gist.github.com/promach/7716ee8addcaa33fda140d74d1ad94d6#file-riffa_dri
On Fri, Feb 01, 2019 at 04:12:46PM +0800, fei phung wrote:
> > I am not sure what does assignment of pointers mean in this context.
> > ptr_ring is designed for a single producer and a single consumer. For
> > why it works see explanation about data dependencies in
> > Documentation/memory-barrier
> I am not sure what does assignment of pointers mean in this context.
> ptr_ring is designed for a single producer and a single consumer. For
> why it works see explanation about data dependencies in
> Documentation/memory-barriers.txt. You will have to be more specific
> about the data race tha
On Thu, Jan 31, 2019 at 01:16:31PM +0800, fei phung wrote:
> Hi,
>
> /*
> * Filename: circ_ring.c
> * Version: 1.0
> * Description: A circular buffer using API from
> * https://github.com/torvalds/linux/blob/master/include/linux/ptr_ring.h
> */
>
> ptr_ring's void** queue is just giving data
Hi,
/*
* Filename: circ_ring.c
* Version: 1.0
* Description: A circular buffer using API from
* https://github.com/torvalds/linux/blob/master/include/linux/ptr_ring.h
*/
ptr_ring's void** queue is just giving data race problem, running
consume() together with [assignment of pointers+produce(
On 2019/1/24 6:41, Russell King - ARM Linux admin wrote:
> On Sat, Jan 05, 2019 at 11:28:19AM +0800, Yunsheng Lin wrote:
>> On 2018/12/17 22:36, Russell King - ARM Linux wrote:
>>> I'll try to do further diagnosis over Christmas in case I've missed
>>> something, but I suspect it may be one of thos
On Sat, Jan 05, 2019 at 11:28:19AM +0800, Yunsheng Lin wrote:
> On 2018/12/17 22:36, Russell King - ARM Linux wrote:
> > I'll try to do further diagnosis over Christmas in case I've missed
> > something, but I suspect it may be one of those "weird behaviour" issues
> > where the safest action is to
在 2019/1/17 20:41, Andrew Lunn 写道:
> On Thu, Jan 17, 2019 at 10:58:07AM +0800, shenjian (K) wrote:
>>
>>
>> 在 2019/1/17 0:04, Andrew Lunn 写道:
Thanks, Andrew.
But we are using acpi mode, is there any ohter way to poke values into
registers ?
>>>
>>> You can register a PHY fix
On Thu, Jan 17, 2019 at 10:58:07AM +0800, shenjian (K) wrote:
>
>
> 在 2019/1/17 0:04, Andrew Lunn 写道:
> >> Thanks, Andrew.
> >>
> >> But we are using acpi mode, is there any ohter way to poke values into
> >> registers ?
> >
> > You can register a PHY fixup.
> >
> > phy_register_fixup_for_uid(
Hi,
I am having data race from threadsanitizer report.
Could you see if there is still data race in the following code using
ptr_ring API ?
/*
* Filename: circ_ring.c
* Version: 1.0
* Description: A circular buffer using API from
* https://github.com/torvalds/linux/blob/master/include/linu
在 2019/1/15 17:08, Wang, Dongsheng 写道:
> On 2019/1/15 14:41, shenjian (K) wrote:
>>
>> 在 2019/1/15 11:39, Andrew Lunn 写道:
>>> On Tue, Jan 15, 2019 at 11:07:17AM +0800, shenjian (K) wrote:
Hi, all
We encounted a problem when using the marvel 88e151x phy driver, the
link(LED[0])/
在 2019/1/17 0:04, Andrew Lunn 写道:
>> Thanks, Andrew.
>>
>> But we are using acpi mode, is there any ohter way to poke values into
>> registers ?
>
> You can register a PHY fixup.
>
> phy_register_fixup_for_uid(), mach-orion5x/dns323-setup.c
>
> Andrew
>
> .
>
Thanks Andrew!
I have t
> Thanks, Andrew.
>
> But we are using acpi mode, is there any ohter way to poke values into
> registers ?
You can register a PHY fixup.
phy_register_fixup_for_uid(), mach-orion5x/dns323-setup.c
Andrew
On Wed, Jan 16, 2019 at 06:48:41AM +, Cheng Fei Phung wrote:
> Hi,
>
> > https://gist.github.com/promach/65e9331d55a43a2815239430a28e29c6#file-circ_ring-c-L62
> > racy if there are multiple consumers.
> > just call ptr_ring_consume_any.
>
> If I modify pop_circ_queue() below to directly use p
Hi,
> https://gist.github.com/promach/65e9331d55a43a2815239430a28e29c6#file-circ_ring-c-L62
> racy if there are multiple consumers.
> just call ptr_ring_consume_any.
If I modify pop_circ_queue() below to directly use
ptr_ring_consume_any() without
ptr_ring_empty_any() , I am afraid I am running i
On Wed, Jan 16, 2019 at 01:10:31AM +0800, fei phung wrote:
> Hi,
>
> inline int pop_circ_queue(struct ptr_ring * buffer, struct item * item_pop)
> {
> if (!ptr_ring_empty_any(buffer)) // if (not empty)
> {
> DEBUG_MSG(KERN_INFO "Before pop, head = %u , tail =
> %u\n
Hi,
inline int pop_circ_queue(struct ptr_ring * buffer, struct item * item_pop)
{
if (!ptr_ring_empty_any(buffer)) // if (not empty)
{
DEBUG_MSG(KERN_INFO "Before pop, head = %u , tail =
%u\n", buffer->consumer_head, buffer->consumer_tail);
/* extra
On Tue, Jan 15, 2019 at 12:33:28PM +0800, fei phung wrote:
> Hi netdev mailing list and Michael,
>
> I am having problem getting proper ptr_ring operation where one
> ptr_ring entry (val1=2 for item_recv_pop) is missing from the void **
> queue
>
> Did I initialize the ring pointers (ptr_ring_ini
On 2019/1/15 14:41, shenjian (K) wrote:
>
> 在 2019/1/15 11:39, Andrew Lunn 写道:
>> On Tue, Jan 15, 2019 at 11:07:17AM +0800, shenjian (K) wrote:
>>> Hi, all
>>> We encounted a problem when using the marvel 88e151x phy driver, the
>>> link(LED[0])/ack(LED[1]) leds worked abnormally since we updat
1 - 100 of 358 matches
Mail list logo
