Re: git guidance

Dave Quigley wrote: On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote: Dave Quigley schrieb: There is a project listed on the kernel.org git page called guilt. I find it very useful. It is much more responsive than stgit and it actually has a git backend which quilt does not. On

Linux and iptables

Hello, I have a kubuntu system with a firestarter Firewall. I did purchase a Sweex router. This router has also a firewall. If I connect the router then i have two Firewalls. The result is that no visitor from outside can visit my wiki's, because they have to pass 2 Firewalls. How can I

can we discuss

Linux and iptables

Hello, I have a kubuntu system with a firestarter Firewall. I did purchase a Sweex router. This router has also a firewall. If I connect the router then i have two Firewalls. The result is that no visitor from outside can visit my wiki's, because they have to pass 2 Firewalls. How can I

Re: git guidance

Dave Quigley wrote: On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote: Dave Quigley schrieb: There is a project listed on the kernel.org git page called guilt. I find it very useful. It is much more responsive than stgit and it actually has a git backend which quilt does not. On

can we discuss

Re: LANANA: To Pending Device Number Registrants

the good old device nodes in the filesystem as we have done for the last 30 years, with all the advantages, but without the major/minor number allocation troubles. Hmm, this all sounds too simple. I must be talking nonsense. Please wake me up. ;-) -- Willem Konynenberg [EMAIL PROTECTED

Re: [CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

); vfree((void *)buffer); return (-EIO); /* hit end of tape = fail */ Regards. Willem Riede. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More

Re: [CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

Junfeng Yang wrote: On Thu, 24 May 2001, Willem Riede wrote: Dawson Engler wrote: Hi All, Enclosed are 103 potential errors where code gets a pointer from a possibly-failing routine (kmalloc, etc) and dereferences it without [BUG] osst_do_scsi will never return NULL

[PATCH] wrong stat of NTFS volume in linux-kernel 2.4.0

in the syslog. (printk) Willem Dekker Patch to adapt super.c of the ntfs filesystem. On a stock linux 2.4.0 kernel. --- fs/ntfs/super.orig Tue Nov 7 20:22:35 2000 +++ fs/ntfs/super.c Sun Jan 7 22:34:43 2001 @@ -300,6 +300,82 @@ return 0; } +static ntfs_u64 div_by_power_of_2(ntfs_u64

Re: osst ide-2.2.19 conflict?

be removed. Success. Willem Riede. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [2.6 patch] drivers/scsi/osst.c: make code static

On 03/22/2005 09:28:07 AM, Adrian Bunk wrote: This patch makes needlessly global code static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] James, I agree with this, can you put it in BK, please? Signed-off-by: Willem Riede [EMAIL PROTECTED] --- This patch was already sent on: - 28 Feb

Re: [2.6 patch] drivers/scsi/osst.c: remove unused code

to os_scsi_tape_flush() recently. James, could you make this change in BK too, please? Signed-off-by: Willem Riede [EMAIL PROTECTED] --- linux-2.6.12-rc1-mm1-full/drivers/scsi/osst.c.old 2005-03-22 21:04:36.0 +0100 +++ linux-2.6.12-rc1-mm1-full/drivers/scsi/osst.c 2005-03-22 22:09

RE: NCQ support NVidia NForce4 (CK804) SATAII

? I don't understand your reluctance in this case (I do for your graphics processors) - it's not as if adding this function to sata_nv would expose your crown jewels - you write yourself that next time you'd use a different (better) interface... Regards, Willem Riede. - To unsubscribe from

Re: LANANA: To Pending Device Number Registrants

in /proc/sys/dev or thereabout. The big advantage of this approach is basically that we can continue to use the good old device nodes in the filesystem as we have done for the last 30 years, with all the advantages, but without the major/minor number allocation troubles. Hmm, this all sounds too

Re: [CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

; > SRpnt->sr_sense_buffer[13] == 2) { > printk(KERN_ERR "osst%d: Volume overflow in write >error recovery\n", dev); > vfree((void *)buffer); >

Re: [CHECKER] null bugs in 2.4.4 and 2.4.4-ac8

Junfeng Yang wrote: > > On Thu, 24 May 2001, Willem Riede wrote: > > > Dawson Engler wrote: > > > > > > Hi All, > > > > > > Enclosed are 103 potential errors where code gets a pointer from a > > > possibly-failing routine (kmalloc, etc

Re: PATCH: ide-scsi.c to allow claiming of Onstream drives

t try to support these drives and fails due to the drive particulars. Since SCSI, USB and IDE versions of these drives exist, patching st is more appropriate than ide-scsi. Regards. Willem Riede. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/

Re: osst & ide-2.2.19 conflict?

/* CONFIG_BLK_DEV_IDETAPE */ > > Any reason for this to stay in the ide patch, or is it now obsolete? > It is obsolete, and can safely be removed. Success. Willem Riede. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[PATCH] wrong stat of NTFS volume in linux-kernel 2.4.0

in the syslog. (printk) Willem Dekker Patch to adapt super.c of the ntfs filesystem. On a stock linux 2.4.0 kernel. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Re: [2.6 patch] drivers/scsi/osst.c: make code static

On 03/22/2005 09:28:07 AM, Adrian Bunk wrote: > This patch makes needlessly global code static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> James, I agree with this, can you put it in BK, please? Signed-off-by: Willem Riede <[EMAIL PROTECTED]> > --- > &g

Re: [2.6 patch] drivers/scsi/osst.c: remove unused code

t did use it moved to os_scsi_tape_flush() recently. James, could you make this change in BK too, please? Signed-off-by: Willem Riede <[EMAIL PROTECTED]> > --- linux-2.6.12-rc1-mm1-full/drivers/scsi/osst.c.old 2005-03-22 > 21:04:36.0 +0100 > +++ linux-2.6.12-rc1-mm1-full/d

RE: NCQ support NVidia NForce4 (CK804) SATAII

litely) to support the case? I don't understand your reluctance in this case (I do for your graphics processors) - it's not as if adding this function to sata_nv would expose your crown jewels - you write yourself that next time you'd use a different (better) interface... Regards, Willem Riede. - T

Re: status of kernel memory debugging?

reports once (if?) the kernel gets a good grinding. Willem - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH net] ip6tnl: fix use after free of fb_tnl_dev

in ip6_tnl_destroy_tunnels(). Let's add an handler for dellink, which will never remove the FB tunnel. With this patch it will no more be possible to remove it via 'ip link del ip6tnl0', but it's safer. The same fix was already proposed by Willem de Bruijn will...@google.com for sit interfaces

Re: [PATCH v10 net-next 2/6] net: add low latency socket poll

changed, 208 insertions(+), 2 deletions(-) create mode 100644 include/net/ll_poll.h Acked-by: Eric Dumazet eduma...@google.com Tested-by: Willem de Bruijn will...@google.com Per Eliezer's request, I applied v10 to a small set of workloads (netperf tcp_rr, udp_rr, 100x tcp_rr, 100x udp_rr

Re: [PATCH v10 net-next 1/6] net: add napi_id and hash

-off-by: Eric Dumazet eduma...@google.com Tested-by: Willem de Bruijn will...@google.com (per Eliezer's request) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo

Re: [PATCH v10 net-next 3/6] udp: add low latency socket poll support

-by: Eliezer Tamir eliezer.ta...@linux.intel.com --- net/core/datagram.c |4 net/ipv4/udp.c |6 +- net/ipv6/udp.c |6 +- 3 files changed, 14 insertions(+), 2 deletions(-) Acked-by: Eric Dumazet eduma...@google.com Tested-by: Willem de Bruijn

Re: [PATCH v10 net-next 4/6] tcp: add low latency socket poll support.

--- Acked-by: Eric Dumazet eduma...@google.com Tested-by: Willem de Bruijn will...@google.com (per Eliezer's request) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: [PATCH v9 net-next 2/7] net: add low latency socket poll

-by: Willem de Bruijn will...@google.com Signed-off-by: Eliezer Tamir eliezer.ta...@linux.intel.com --- Are you sure this version was tested by Willem ? I hadn't tested the latest revisions, indeed. Am testing this one right now. Acked-by: Eric Dumazet eduma...@google.com -- To unsubscribe

Re: [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll_poll

drivers to do something similar in order to enable support for CONFIG_INET_LL_RX_POLL I am not sure, Willem ported this to some undisclosed HW that they use at Google, his feedback was that it was not a major effort. The core ndo_ll_poll implementation is generally a subset of a device driver's

Re: [PATCH v3 net-next 0/4] net: low latency Ethernet device polling

2. How is the logic aware of RSS and RFS? With TCP sockets, the driver knows the specific ring it need to poll so this should be mapped and provide the best latency. This code is blissfully oblivious of RFS and RSS, it only assumes that the packets for a socket are likely to continue to

Re: [PATCH 0/2] [BUG FIXES - 3.10.27] sit: More backports

From d101450583c3a472a2a94904cfe13fd4e7d2f519 Mon Sep 17 00:00:00 2001 From: Nicolas Dichtel nicolas.dich...@6wind.com Date: Wed, 29 Jan 2014 16:40:30 +0100 Subject: [PATCH] sit: fix double free of fb_tunnel_dev on exit This problem was fixed upstream by commit 9434266f2c64 (sit: fix use

Re: [PATCH net-next] net: filter: rename 'struct sk_filter' to 'struct bpf_prog'

alternative fix for xt_bpf.h could be to replace: /* only used in the kernel */ struct sk_filter *filter __attribute__((aligned(8))); with /* only used in the kernel */ void *filter __attribute__((aligned(8))); but this 'void *' approach may further break

Re: [PATCH net-next] net: filter: rename 'struct sk_filter' to 'struct bpf_prog'

This follows a convention in include/uapi/linux/netfilter/*.h that likely predates the introduction of uapi. A search for Used internally by the kernel shows many more examples. I should not have included filter.h, however. The common behavior when using pointers to kernel-internal structures

Re: [PATCH net-next] net: filter: rename 'struct sk_filter' to 'struct bpf_prog'

On Fri, Jul 25, 2014 at 2:43 PM, Alexei Starovoitov a...@plumgrid.com wrote: On Fri, Jul 25, 2014 at 11:32 AM, Willem de Bruijn will...@google.com wrote: This follows a convention in include/uapi/linux/netfilter/*.h that likely predates the introduction of uapi. A search for Used internally

Re: [LKP] [net] 4ed2d765dfa: ltp.recv01.4.TFAIL

On Wed, Oct 1, 2014 at 11:29 AM, Fengguang Wu fengguang...@intel.com wrote: Hi Willem, FYI, we noticed the below LTP failures on commit Thanks for the report, Fengguang. The failures are recv01 4 TFAIL : recv01.c:142: invalid flags set ; returned -1 (expected -1), errno 11 (expected

Re: [LKP] [net] 4ed2d765dfa:

On Mon, Nov 24, 2014 at 7:38 AM, Yuanhan Liu yuanhan@linux.intel.com wrote: FYI, we noticed the below changes on commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b (net-timestamp: TCP timestamping) e7fd2885385157d4 4ed2d765dfaccff5ebdac68e20 --

Re: [PATCH] af_packet: don't pass empty blocks for PACKET_V3

On Thu, Feb 5, 2015 at 10:54 PM, Alexander Drozdov al.droz...@gmail.com wrote: On 05.02.2015 23:01:38 +0300 Willem de Bruijn wrote: On Wed, Feb 4, 2015 at 9:58 PM, Alexander Drozdov al.droz...@gmail.com wrote: Don't close an empty block on timeout. Its meaningless to pass it to the user

Re: [PATCH net] packet: bail out of packet_snd() if L2 header creation fails

) Signed-off-by: Christoph Jaeger c...@linux.com --- Nice catch ! Acked-by: Eric Dumazet eduma...@google.com Indeed. I'm responsible for that typo. Thanks a lot for catching it! Acked-by: Willem de Bruijn will...@google.com -- To unsubscribe from this list: send the line unsubscribe linux

Re: [PATCH] af_packet: don't pass empty blocks for PACKET_V3

On Wed, Feb 4, 2015 at 9:58 PM, Alexander Drozdov al.droz...@gmail.com wrote: Don't close an empty block on timeout. Its meaningless to pass it to the user. Moreover, passing empty blocks wastes CPU buffer space increasing probability of packets dropping on small timeouts. Side effect of

Re: [PATCH 2/2] af_packet: pass checksum validation status to the user

On Fri, Mar 20, 2015 at 2:46 AM, Alexander Drozdov al.droz...@gmail.com wrote: On 19.03.2015 21:50:03 +0300 Willem de Bruijn wrote: On Thu, Mar 19, 2015 at 2:08 PM, Alexander Drozdov al.droz...@gmail.com wrote: On Thu, 19 Mar 2015 11:29:32 -0400, Willem de Bruijn will...@google.com wrote

Re: [PATCH 2/2] af_packet: pass checksum validation status to the user

On Thu, Mar 19, 2015 at 2:08 PM, Alexander Drozdov al.droz...@gmail.com wrote: On Thu, 19 Mar 2015 11:29:32 -0400, Willem de Bruijn will...@google.com wrote: On Thu, Mar 19, 2015 at 4:01 AM, Alexander Drozdov al.droz...@gmail.com wrote: Introduce TP_STATUS_CSUM_VALID tp_status flag to tell

Re: [PATCH 2/2] af_packet: pass checksum validation status to the user

On Thu, Mar 19, 2015 at 4:01 AM, Alexander Drozdov al.droz...@gmail.com wrote: Introduce TP_STATUS_CSUM_VALID tp_status flag to tell the af_packet user that at least the transport header checksum has been already validated. This changes the interface slightly. Processes should be treating this

Re: linux-next: build warnings after merge of the net-next tree

On Thu, May 14, 2015 at 3:12 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) produced these warnings: In file included from arch/sparc/include/asm/cmpxchg.h:4:0, from

Re: net: heap-out-of-bounds in sock_setsockopt

> > Hmm, we should exclude the raw socket case, something like the > following, but I am not sure if the check is too strict or not, also > not sure if we should return an error for this raw socket case. No, SOF_TIMESTAMPING_OPT_ID with SOCK_RAW/IPPROTO_TCP is legitimate. It should fall through

Re: Boot failure when using NFS on OMAP based evms

Currently linux-next is failing to boot via NFS on my AM335x GP evm, AM437x GP evm and Beagle X15. I bisected the problem down to the commit "udp: remove headers from UDP packets before queueing". >>> >>> Thanks for the report, and apologies for breaking your configuration. >>> I

Re: Boot failure when using NFS on OMAP based evms

On Thu, Apr 7, 2016 at 10:36 AM, Franklin S Cooper Jr. <fcoo...@ti.com> wrote: > > > On 04/06/2016 09:22 PM, Willem de Bruijn wrote: >> On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. <fcoo...@ti.com> wrote: >>> Hi All, >>> >>> Currently

Re: Boot failure when using NFS on OMAP based evms

On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. wrote: > Hi All, > > Currently linux-next is failing to boot via NFS on my AM335x GP evm, > AM437x GP evm and Beagle X15. I bisected the problem down to the commit > "udp: remove headers from UDP packets before queueing". > > I

Re: Tool for sampling /proc/net/softnet_stat statistics

On Mon, Mar 7, 2016 at 10:36 AM, Jesper Dangaard Brouer wrote: > Hi Google, > > While playing with RPS, I needed to read stats from > /proc/net/softnet_stat and the tools I could find [1] and [2] was not > very good. > > I lack of better, I coded up my own tool softnet_stat.pl

Re: [patch -next] udp: fix if statement in SIOCINQ ioctl

o be unconditional. >> >> Fixes: 9f9a45beaa96 ('udp: do not expect udp headers on ioctl SIOCINQ') >> Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> > > Acked-by: Eric Dumazet <eduma...@google.com> Acked-by: Willem de Bruijn <will...@google.com> Thanks for catching this.

[PATCH tip/timers/core] uapi glibc compat: make linux/time.h compile after libc time.h files

From: Willem de Bruijn <will...@google.com> Add libc-compat workaround for definitions in linux/time.h that duplicate those in libc time.h, sys/time.h and bits/time.h. With this change, userspace builds succeeds when linux/time.h is included after those libc files. The inverse requires c

Re: [PATCH net] udp: prevent bugcheck if filter truncates packet too much

>> >> I'm okay if we take this for now as a quick band aid and find a better >> way how to deal with the underlying issue long-term so that it's >> /guaranteed/ that it doesn't bite us any further in such fragile ways. > > Agreed. As rc7 is due in a day or two, rushing a complex and intrusive > solution in might be too risky. Acked-by: Willem de Bruijn <will...@google.com> Thanks, Michal.

Re: Missing include file in include/uapi/linux/errqueue.h?

On Sun, Jul 10, 2016 at 1:43 AM, Brooks Moses wrote: > On Sat, Jul 9, 2016 at 10:36 AM, Brooks Moses wrote: >> I've been attempting to qualify the Linux 4.5.2 user-space headers for >> a toolchain release, and ran into what looks like a missing include >>

Re: Missing include file in include/uapi/linux/errqueue.h?

On Sun, Jul 10, 2016 at 9:56 AM, Willem de Bruijn <will...@google.com> wrote: > On Sun, Jul 10, 2016 at 1:43 AM, Brooks Moses <bmo...@google.com> wrote: >> On Sat, Jul 9, 2016 at 10:36 AM, Brooks Moses <bmo...@google.com> wrote: >>> I've been attempting t

Re: [PATCH tip/timers/core] uapi glibc compat: make linux/time.h compile after libc time.h files

On Wed, Aug 17, 2016 at 3:33 PM, John Stultz <john.stu...@linaro.org> wrote: > On Wed, Aug 10, 2016 at 8:45 AM, Willem de Bruijn > <willemdebruijn.ker...@gmail.com> wrote: >> From: Willem de Bruijn <will...@google.com> >> >> Add libc-compat

Re: [PATCH net-next 2/2] errqueue: include linux/time.h

On Mon, Sep 12, 2016 at 3:26 PM, kbuild test robot <l...@intel.com> wrote: > Hi Willem, > > [auto build test ERROR on net-next/master] > > url: > https://github.com/0day-ci/linux/commits/Willem-de-Bruijn/uapi-include-time-h-from-errqueue-h/20160913-020431 > confi

[PATCH net-next 0/2] uapi: include time.h from errqueue.h

From: Willem de Bruijn <will...@google.com> It was reported that linux/errqueue.h requires linux/time.h, but that adding the include directly may cause userspace conflicts between linux/time.h and glibc time.h: https://lkml.org/lkml/2016/7/10/10 Address the conflicts using the standar

[PATCH net-next 2/2] errqueue: include linux/time.h

From: Willem de Bruijn <will...@google.com> struct scm_timestamping has fields of type struct timespec. Now that it is safe to include linux/time.h and time.h at the same time, include linux/time.h directly in linux/errqueue.h Without this patch, when compiling the following program afte

[PATCH net-next 1/2] uapi glibc compat: make linux/time.h compile with user time.h files

From: Willem de Bruijn <will...@google.com> Add libc-compat workaround for definitions in linux/time.h that duplicate those in libc time.h, sys/time.h and bits/time.h. With this change, userspace builds succeeds when linux/time.h is included after libc time.h and when it is included aft

Re: af_packet: use after free in prb_retire_rx_blk_timer_expired

On Mon, Apr 10, 2017 at 3:23 PM, Dave Jones wrote: > On Mon, Apr 10, 2017 at 07:03:30PM +, alexander.le...@verizon.com wrote: > > Hi all, > > > > I seem to be hitting this use-after-free on a -next kernel using trinity: > > > > [ 531.036054] BUG: KASAN:

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

=== > BUG: KASAN: use-after-free in ipv4_datagram_support_cmsg > net/ipv4/ip_sockglue.c:500 [inline] at addr 880059be0128 Thanks for the report. This is accessing skb->dev from within recvmsg() at line info->ipi_ifindex = skb->dev->ifindex; Introduced in 829ae9d61165

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

On Wed, Apr 12, 2017 at 4:47 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-04-12 at 13:07 -0700, Cong Wang wrote: >> On Wed, Apr 12, 2017 at 8:39 AM, Willem de Bruijn >> <willemdebruijn.ker...@gmail.com> wrote: >> >

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

On Wed, Apr 12, 2017 at 6:25 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Wed, Apr 12, 2017 at 4:47 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> On Wed, 2017-04-12 at 13:07 -0700, Cong Wang wrote: >>> On Wed, Apr 12, 201

Re: [PATCH v06 18/36] uapi linux/errqueue.h: include linux/time.h in user space

>> > +#ifdef __KERNEL__ >> > +#include >> > +#else >> > +#include >> > +#endif /* __KERNEL__ */ >> >> This will break applications that include manually. >> I previously sent a patch to use libc-compat to make compilation succeed >> when both are included in the case where is included after >>

Re: [PATCH v06 18/36] uapi linux/errqueue.h: include linux/time.h in user space

On Sun, Aug 6, 2017 at 5:52 PM, Mikko Rapeli <mikko.rap...@iki.fi> wrote: > On Sun, Aug 06, 2017 at 05:42:13PM -0400, Willem de Bruijn wrote: >> On Sun, Aug 6, 2017 at 5:33 PM, Mikko Rapeli <mikko.rap...@iki.fi> wrote: >> > On Sun, Aug 06, 2017 at 05:24:20PM

Re: [PATCH v06 18/36] uapi linux/errqueue.h: include linux/time.h in user space

On Sun, Aug 6, 2017 at 5:33 PM, Mikko Rapeli <mikko.rap...@iki.fi> wrote: > On Sun, Aug 06, 2017 at 05:24:20PM -0400, Willem de Bruijn wrote: >> >> > +#ifdef __KERNEL__ >> >> > +#include >> >> > +#else >> >> > +#include >

Re: [PATCH v06 18/36] uapi linux/errqueue.h: include linux/time.h in user space

On Sun, Aug 6, 2017 at 4:23 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Sun, Aug 6, 2017 at 12:44 PM, Mikko Rapeli <mikko.rap...@iki.fi> wrote: >> linux/time.h conflicts with user space header time.h. Try to be compatible >> with both. >> >

Re: [PATCH v06 18/36] uapi linux/errqueue.h: include linux/time.h in user space

espec ts[3]; > > Signed-off-by: Mikko Rapeli <mikko.rap...@iki.fi> > Cc: Willem de Bruijn <will...@google.com> > Cc: Soheil Hassas Yeganeh <soh...@google.com> > Cc: net...@vger.kernel.org > --- > include/uapi/linux/errqueue.h | 6 ++ > 1 file changed, 6 i

Re: linux-next: build failure after merge of the netfilter tree

On Wed, May 17, 2017 at 1:02 AM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Tue, May 16, 2017 at 11:45 PM, Stephen Rothwell <s...@canb.auug.org.au> > wrote: >> Hi all, >> >> After merging the netfilter tree, today's linux-next b

Re: linux-next: build failure after merge of the netfilter tree

On Tue, May 16, 2017 at 11:45 PM, Stephen Rothwell wrote: > Hi all, > > After merging the netfilter tree, today's linux-next build (i386 > defconfig) failed like this: > > net/netfilter/x_tables.c: In function 'xt_match_to_user': > net/netfilter/x_tables.c:303:13: error:

Re: linux-next: build failure after merge of the net-next tree

On Sun, May 21, 2017 at 9:16 PM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > net/socket.c: In function 'put_ts_pktinfo': > net/socket.c:695:28: error:

Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

On Wed, Sep 13, 2017 at 10:40 PM, nixiaoming wrote: > If fanout_add is preempted after running po-> fanout = match > and before running __fanout_link, > it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink > > so, we need add mutex_lock(_mutex) to

Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

On Thu, Sep 14, 2017 at 10:07 AM, nixiaoming wrote: > From: l00219569 > > If fanout_add is preempted after running po-> fanout = match > and before running __fanout_link, > it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink > > so, we

Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

On Fri, Sep 15, 2017 at 1:41 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Thu, Sep 14, 2017 at 7:35 AM, Willem de Bruijn > <willemdebruijn.ker...@gmail.com> wrote: >> On Thu, Sep 14, 2017 at 10:07 AM, nixiaoming <nixiaom...@huawei.com> wrote: >>&

Re: Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

On Tue, Sep 19, 2017 at 3:21 AM, Nixiaoming <nixiaom...@huawei.com> wrote: > On Fri, Sep 15, 2017 at 10:46 AM, Willem de Bruijn > > <willemdebruijn.ker...@gmail.com> wrote: > >> > >> In case of failure we also need to unlink and free match. I

Re: Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

On Tue, Sep 19, 2017 at 12:09 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Tue, Sep 19, 2017 at 3:21 AM, Nixiaoming <nixiaom...@huawei.com> wrote: >> On Fri, Sep 15, 2017 at 10:46 AM, Willem de Bruijn >> >> <willemdebruijn.ker...@gma

Re: [PATCH 2/3] selftests: actually run the various net selftests

> > +TEST_GEN_PROGS += reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa >> > +TEST_GEN_PROGS += reuseport_dualstack msg_zerocopy reuseaddr_conflict >> >> Hmm. I see msg_zerocopy.sh for running msg_zerocopy. msg_zerocopy should >> still stay in TEST_GEN_FILES and msg_

Re: [PATCH net-next 0/3] support changing steering policies in tuntap

On Thu, Sep 28, 2017 at 3:23 AM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年09月28日 07:25, Willem de Bruijn wrote: >>>> >>>> In the future, both simple and sophisticated policy like RSS or other >>>> guest >>>> driven st

Re: [PATCH net-next RFC 5/5] vhost_net: basic tx virtqueue batched processing

> @@ -461,6 +460,7 @@ static void handle_tx(struct vhost_net *net) > struct socket *sock; > struct vhost_net_ubuf_ref *uninitialized_var(ubufs); > bool zcopy, zcopy_used; > + int i, batched = VHOST_NET_BATCH; > > mutex_lock(>mutex); > sock =

Re: [PATCH net-next RFC 3/5] vhost: introduce vhost_add_used_idx()

>> > > @@ -199,6 +199,7 @@ int __vhost_get_vq_desc(struct vhost_virtqueue *vq, >> > > void vhost_discard_vq_desc(struct vhost_virtqueue *, int n); >> > > int vhost_vq_init_access(struct vhost_virtqueue *); >> > > +int vhost_add_used_idx(struct vhost_virtqueue *vq, int n); >> > > int

Re: [PATCH net-next RFC 2/5] vhost: introduce helper to prefetch desc index

On Fri, Sep 22, 2017 at 4:02 AM, Jason Wang wrote: > This patch introduces vhost_prefetch_desc_indices() which could batch > descriptor indices fetching and used ring updating. This intends to > reduce the cache misses of indices fetching and updating and reduce > cache line

Re: [PATCH net-next 0/3] support changing steering policies in tuntap

>> In the future, both simple and sophisticated policy like RSS or other guest >> driven steering policies could be done on top. > > IMHO there should be a more practical example before adding all this > indirection. And it would be nice to understand why this queue selection > needs to be tun

Re: [PATCH] packet: Don't write vnet header beyond end of buffer

On Mon, Aug 28, 2017 at 2:29 PM, Benjamin Poirier <bpoir...@suse.com> wrote: > ... which may happen with certain values of tp_reserve and maclen. > > Fixes: 58d19b19cd99 ("packet: vnet_hdr support for tpacket_rcv") > Signed-off-by: Benjamin Poirier <bpoir...@s

Re: [PATCH 1/2] [net-next] packet: clarify timestamp overflow

ncompatible structures when > time_t gets redefined to 64-bit in 32-bit user space, but this one > does not. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> This change to avoid the deprecated internal interface looks great to me. Acked-by: Willem de Bruijn <will...@google.com>

Re: [PATCH 2/2] [RFC] packet: experimental support for 64-bit timestamps

On Mon, Nov 27, 2017 at 11:59 AM, Jiri Pirko wrote: > Mon, Nov 27, 2017 at 05:19:25PM CET, a...@arndb.de wrote: >>I tried to figure out what it would take to do a version 4 mmap packet >>socket interface to completely avoid the y2106 overflow problem. This is >>what I came up

Re: [PATCH] [RFC v2] packet: experimental support for 64-bit timestamps

On Tue, Nov 28, 2017 at 8:14 AM, Arnd Bergmann wrote: > This is a second attempt to allow 64-bit timestamps in packet sockets, Thanks for coding up this variant. > The implementation is fairly straightforward, but I'm less sure about the > interface. Using SOF_TIMESTAMPING_*

Re: [PATCH 2/2] [RFC] packet: experimental support for 64-bit timestamps

On Tue, Nov 28, 2017 at 3:46 AM, Arnd Bergmann wrote: > On Tue, Nov 28, 2017 at 8:04 AM, Björn Töpel wrote: >> 2017-11-27 21:51 GMT+01:00 Arnd Bergmann : >> [...] There already is an effort to come up with a new AF_PACKET V4 [1]. We

Re: [PATCH] [RFC v3] packet: experimental support for 64-bit timestamps

r nanoseconds or > microseconds, we now always send down 64 bits worth of nanoseconds when > this flag is set. > > Link: https://patchwork.kernel.org/patch/10077199/ > Suggested-by: Willem de Bruijn <willemdebruijn.ker...@gmail.com> > Signed-off-by: Arnd Bergmann <a.

Re: [PATCH] net: openvswitch: datapath: fix data type in queue_gso_packets

t. > > Addresses-Coverity-ID: 1462223 > Fixes: 0c19f846d582 ("net: accept UFO datagrams from tuntap and packet") > Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com> Acked-by: Willem de Bruijn <will...@google.com> Good catch, thanks! The issue here is that

Re: [PATCH] [RFC v3] packet: experimental support for 64-bit timestamps

> Thanks for the review! Any suggestions for how to do the testing? If you have > existing test cases, could you give my next version a test run to see if there > are any regressions and if the timestamps work as expected? > > I see that there are test cases in tools/testing/selftests/net/, but

Re: [PATCH] [RFC v3] packet: experimental support for 64-bit timestamps

On Wed, Nov 29, 2017 at 8:39 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Wed, Nov 29, 2017 at 3:06 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Wed, Nov 29, 2017 at 5:51 PM, Willem de Bruijn >> <willemdebruijn.ker...@gmail.com> wrote

Re: [PATCH] [RFC v3] packet: experimental support for 64-bit timestamps

On Wed, Nov 29, 2017 at 3:06 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Wed, Nov 29, 2017 at 5:51 PM, Willem de Bruijn > <willemdebruijn.ker...@gmail.com> wrote: >>> Thanks for the review! Any suggestions for how to do the testing? If you >>> have >&g

Re: [PATCH net-next V3] tun: add eBPF based queue selection method

On Mon, Dec 4, 2017 at 4:31 AM, Jason Wang wrote: > This patch introduces an eBPF based queue selection method. With this, > the policy could be offloaded to userspace completely through a new > ioctl TUNSETSTEERINGEBPF. > > Signed-off-by: Jason Wang >

Re: [B.A.T.M.A.N.] [RFC v2 2/6] batman-adv: Rename batman-adv.h to batadv_genl.h

On Fri, Dec 15, 2017 at 12:18 PM, Sven Eckelmann <sven.eckelm...@openmesh.com> wrote: > On Freitag, 15. Dezember 2017 11:57:55 CET Willem de Bruijn wrote: >> > No, this is also bad because batman_adv.h is MIT license and packet.h is >> > GPL-2. So what other name wou

Re: [B.A.T.M.A.N.] [RFC v2 2/6] batman-adv: Rename batman-adv.h to batadv_genl.h

On Fri, Dec 15, 2017 at 6:48 AM, Sven Eckelmann <sven.eckelm...@openmesh.com> wrote: > On Freitag, 15. Dezember 2017 11:32:05 CET Sven Eckelmann wrote: >> On Mittwoch, 6. Dezember 2017 11:58:14 CET Willem de Bruijn wrote: >> [...] >> > &

Re: [RFC v3 0/4] flow_dissector: Provide basic batman-adv unicast handling

es of > https://patchwork.ozlabs.org/cover/844783/ > > > Changes in v3: > == > > * removed change of uapi/linux/batman_adv.h to uapi/linux/batadv_genl.h > - requested by Willem de Bruijn <willemdebruijn.ker...@gmail.com> > * removed naming fixes for enums/de

Re: [PATCH net-next V2 3/3] tun: add eBPF based queue selection method

On Tue, Oct 31, 2017 at 7:32 PM, Jason Wang wrote: > This patch introduces an eBPF based queue selection method based on > the flow steering policy ops. Userspace could load an eBPF program > through TUNSETSTEERINGEBPF. This gives much more flexibility compare > to simple but

Re: [PATCH net-next V2 1/3] tun: abstract flow steering logic

On Tue, Oct 31, 2017 at 7:32 PM, Jason Wang wrote: > tun now use flow caches based automatic queue steering method. This > may not suffice all user cases. To extend it to be able to use more > flow steering policy, this patch abstracts flow steering logic into >

Re: [PATCH net-next V2 2/3] tun: introduce ioctls to set and get steering policies

On Tue, Oct 31, 2017 at 7:32 PM, Jason Wang wrote: > This patch introduces new ioctl for change packet steering policy for > tun. Only automatic flow steering is supported, more policies will > come. > > Signed-off-by: Jason Wang > --- >

  1   2   3   4   5   6   7   >