* Re: [PATCH net-next 00/10] Misc. bug fixes & cleanups for HNS3 driver
From: David Miller @ 2018-07-07 2:13 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm
In-Reply-To: <20180706102804.196-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Fri, 6 Jul 2018 11:27:54 +0100
> This patch-set presents some miscellaneous bug fixes and cleanups
> for the HNS3 driver.
Series applied, thank you.
^ permalink raw reply
* Re: [RFC bpf-next 2/6] net: xdp: RX meta data infrastructure
From: Alexei Starovoitov @ 2018-07-07 2:38 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Waskiewicz Jr, Peter, Duyck, Alexander H, daniel@iogearbox.net,
saeedm@mellanox.com, brouer@redhat.com, borkmann@iogearbox.net,
tariqt@mellanox.com, john.fastabend@gmail.com,
netdev@vger.kernel.org, saeedm@dev.mellanox.co.il
In-Reply-To: <20180706182047.0885297f@cakuba.netronome.com>
On Fri, Jul 06, 2018 at 06:20:47PM -0700, Jakub Kicinski wrote:
> On Fri, 6 Jul 2018 18:00:13 -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 06, 2018 at 05:40:43PM -0700, Jakub Kicinski wrote:
> > >
> > > Could we just say that at the start we expose only existing SKB fields
> > > (csum, hash, mark) and the meaning of the is the same as in the SKB?
> >
> > what would be the meaning of 'hash' ? Over which fields?
> > Does it support inner and outer packets? How about udp encap (vxlan and friends) ?
>
> We don't seem to need to answer that for the rest of the stack, no? We
> can expose the "hash type" field as well if that's *really* necessary.
>
> > Same question of csum... tcp only?
>
> Shouldn't we just stick to CHECKSUM_COMPLETE?
I don't yet see how checksum_complete and 'hash just like stack'
helps to accelerate xdp programs like ddos and load balancer.
'hash like stack' may help to accelerate networking stack itself,
but that's very different discussion. There is no xdp in such case.
No programs and no metadata. If some NICs can do
'hash like stack' and demonstrate performance improvements
for regular tcp/ip processing with netperf in user space
that would definitely be interesting and standardizing such
hash from the drivers into upper layers would warrant its own patches,
but seems orthogonal to this xdp hints discussion.
^ permalink raw reply
* Re: [RFC bpf-next 2/6] net: xdp: RX meta data infrastructure
From: Alexei Starovoitov @ 2018-07-07 2:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Borkmann, Saeed Mahameed, saeedm@dev.mellanox.co.il,
alexander.h.duyck@intel.com, netdev@vger.kernel.org, Tariq Toukan,
john.fastabend@gmail.com, brouer@redhat.com,
borkmann@iogearbox.net, peter.waskiewicz.jr@intel.com
In-Reply-To: <20180706184424.1440b1cf@cakuba.netronome.com>
On Fri, Jul 06, 2018 at 06:44:24PM -0700, Jakub Kicinski wrote:
> On Fri, 6 Jul 2018 17:53:18 -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 06, 2018 at 05:08:47PM -0700, Jakub Kicinski wrote:
> > > On Fri, 6 Jul 2018 16:42:51 -0700, Alexei Starovoitov wrote:
> > > > On Fri, Jul 06, 2018 at 02:33:58PM -0700, Jakub Kicinski wrote:
> > > > > On Fri, 6 Jul 2018 09:30:42 -0700, Alexei Starovoitov wrote:
> > > > > > On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> > > > > > >
> > > > > > > I'm also not 100% on board with the argument that "future" FW can
> > > > > > > reshuffle things whatever way it wants to. Is the assumption that
> > > > > > > future ASICs/FW will be designed to always use the "blessed" BTF
> > > > > > > format? Or will it be reconfigurable at runtime?
> > > > > >
> > > > > > let's table configuration of metadata aside for a second.
> > > > > >
> > > > > > Describing metedata layout in BTF allows NICs to disclose everything
> > > > > > NIC has to users in a standard and generic way.
> > > > > > Whether firmware is reconfigurable on the fly or has to reflashed
> > > > > > and hw powercycled to have new md layout (and corresponding BTF description)
> > > > > > is a separate discussion.
> > > > > > Saeed's proposal introduces the concept of 'offset' inside 'struct xdp_md_info'
> > > > > > to reach 'hash' value in metadata.
> > > > > > Essentially it's a run-time way to access 'hash' instead of build-time.
> > > > > > So bpf program would need two loads to read csum or hash field instead of one.
> > > > > > With BTF the layout of metadata is known to the program at build-time.
> > > > > >
> > > > > > To reiterate the proposal:
> > > > > > - driver+firmware keep layout of the metadata in BTF format (either in the driver
> > > > > > or driver can read it from firmware)
> > > > > > - 'bpftool read-metadata-desc eth0 > md_desc.h' command will query the driver and
> > > > > > generate normal C header file based on BTF in the given NIC
> > > > > > - user does #include "md_desc.h" and bpf program can access md->csum or md->hash
> > > > > > with direct single load out of metadata area in front of the packet
> > > > > > - llvm compiles bpf program and records how program is doing this md->csum accesses
> > > > > > in BTF format as well (the compiler will be keeping such records
> > > > > > for __sk_buff and all other structs too, but that's separate discussion)
> > > > > > - during sys_bpf(prog_load) the kernel checks (via supplied BTF) that the way the program
> > > > > > accesses metadata (and other structs) matches BTF from the driver,
> > > > > > so no surprises if driver+firmware got updated, but program is not recompiled
> > > > > > - every NIC can have their own layout of metadata and its own meaning of the fields,
> > > > > > but would be good to standardize at least a few common fields like hash
> > > > >
> > > > > Can I expose HW descriptors this way, though, or is the proposal to
> > > > > copy this data into the packet buffer?
> > > >
> > > > That crossed my mind too. We can use BTF to describe HW descriptors too,
> > > > but I don't think it would buy us anything. AF_XDP approach is better.
> > > >
> > > > > > Once this is working we can do more cool things with BTF.
> > > > > > Like doing offset rewriting at program load time similar to what we plan
> > > > > > to do for tracing. Tracing programs will be doing 'task->pid' access
> > > > > > and the kernel will adjust offsetof(struct task_struct, pid) during program load
> > > > > > depending on BTF for the kernel.
> > > > > > The same trick we can do for networking metadata.
> > > > > > The program will contain load instruction md->hash that will get automatically
> > > > > > adjusted to proper offset depending on BTF of 'hash' field in the NIC.
> > > > > > For now I'm proposing _not_ to go that far with offset rewriting and start
> > > > > > with simple steps described above.
> > > > >
> > > > > Why? :( Could we please go with the rewrite/driver helpers instead of
> > > > > impacting fast paths of the drivers yet again? This rewrite should be
> > > > > easier than task->pid, because we have the synthetic user space struct
> > > > > xdp_md definition.
> > > >
> > > > I don't understand 'impact fast path yet again' concern.
> > > > If NIC has certain metadata today, just derscribe what it has in BTF
> > > > and supply the actual per-packet md to xdp program as-is.
> > > > No changes for fast path at all.
> > > > Future rewritting will be done by the bpf/xdp core with zero
> > > > changes to the driver. All driver has to do is to provide BTF.
> > >
> > > I'm confused. AFAIK most *existing* NICs have the metadata in the
> > > "descriptor", i.e. not in the packet buffer. So if the NIC just
> > > describes what it has, and there is no data shuffling/copying
> > > (performance) then we have to expose the descriptor, no?
> >
> > which piece of sw put that data into desciptor ?
> > I bet it's firmware. It could have stored it into pre-packet data, no?
> > I'd like to avoid _all_ copies.
> > Right now xdp program can only see a pointer to packet and pre-packet.
> > If we need another pointer to a piece of the packet descriptor,
> > that's also fine. Both pre-packet metadata and pieces of descriptor
> > can be described in BTF.
>
> Okay, if we expose another pointer then it's possible to avoid copies.
>
> But please keep in mind that descriptors are very compact, there is
> a lot of interdependencies between fields and the fields can shift
> depending on the type of packet. HW/FW guys always quote the 64B
> packet performance as a reason why things can't be simple. We can't
> consume 50% of PCIe bandwidth to DMA the metadata alone.
Certainly. With l4 load balancer we're after short packet performance too.
> > I'd like to push back on firmware folks that should be listening
> > to feedback from driver folks and kernel stack instead of saying
> > 'here is hw spec that firmware provides'. Firmware is software.
> > It can change and should be open to change by the community
> > with proper maintainership.
>
> I think the way to influence FW/HW is to provide a strong and well
> justified standard, and if we just expose raw HW data we are doing
> just the opposite. We can claim BTF driver provides is not uABI, but
> I will personally no longer feel comfortable with modifying descriptor
> formats (and I've done that for the NFP in the past - grep for
> chained_metadata_format).
I think AF_XDP is doing what you're asking for. It defined a standard
descriptor format. Metadata for the packet is use case specific.
What is useful for l4 load balancer could be a waste of pcie bandwidth
for regular tcp/ip. I'm not proposing to have it always on.
What I'm proposing with BTF is instead of doing nfp_net_parse_meta()
for this chained format in the nfp driver expose it to xdp program.
Let program deal with it when it wants to. Would that work?
^ permalink raw reply
* Re: [RFC] Add BPF_SYNCHRONIZE bpf(2) command
From: Alexei Starovoitov @ 2018-07-07 2:54 UTC (permalink / raw)
To: Daniel Colascione; +Cc: joelaf, ast, linux-kernel, timmurray, daniel, netdev
In-Reply-To: <20180707015616.25988-1-dancol@google.com>
On Fri, Jul 06, 2018 at 06:56:16PM -0700, Daniel Colascione wrote:
> BPF_SYNCHRONIZE waits for any BPF programs active at the time of
> BPF_SYNCHRONIZE to complete, allowing userspace to ensure atomicity of
> RCU data structure operations with respect to active programs. For
> example, userspace can update a map->map entry to point to a new map,
> use BPF_SYNCHRONIZE to wait for any BPF programs using the old map to
> complete, and then drain the old map without fear that BPF programs
> may still be updating it.
>
> Signed-off-by: Daniel Colascione <dancol@google.com>
> ---
> include/uapi/linux/bpf.h | 1 +
> kernel/bpf/syscall.c | 14 ++++++++++++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index b7db3261c62d..4365c50e8055 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -98,6 +98,7 @@ enum bpf_cmd {
> BPF_BTF_LOAD,
> BPF_BTF_GET_FD_BY_ID,
> BPF_TASK_FD_QUERY,
> + BPF_SYNCHRONIZE,
> };
>
> enum bpf_map_type {
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index d10ecd78105f..60ec7811846e 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -2272,6 +2272,20 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
> if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> + if (cmd == BPF_SYNCHRONIZE) {
> + if (uattr != NULL || size != 0)
> + return -EINVAL;
> + err = security_bpf(cmd, NULL, 0);
> + if (err < 0)
> + return err;
> + /* BPF programs are run with preempt disabled, so
> + * synchronize_sched is sufficient even with
> + * RCU_PREEMPT.
> + */
> + synchronize_sched();
> + return 0;
I don't think it's necessary. sys_membarrier() can do this already
and some folks use it exactly for this use case.
^ permalink raw reply
* Re: [RFC] Add BPF_SYNCHRONIZE bpf(2) command
From: Daniel Colascione @ 2018-07-07 3:22 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Joel Fernandes, ast, linux-kernel, Tim Murray, daniel, netdev
In-Reply-To: <20180707025426.ssxipi7hsehoiuyo@ast-mbp.dhcp.thefacebook.com>
On Fri, Jul 6, 2018 at 7:54 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Fri, Jul 06, 2018 at 06:56:16PM -0700, Daniel Colascione wrote:
>> BPF_SYNCHRONIZE waits for any BPF programs active at the time of
>> BPF_SYNCHRONIZE to complete, allowing userspace to ensure atomicity of
>> RCU data structure operations with respect to active programs. For
>> example, userspace can update a map->map entry to point to a new map,
>> use BPF_SYNCHRONIZE to wait for any BPF programs using the old map to
>> complete, and then drain the old map without fear that BPF programs
>> may still be updating it.
>>
>> Signed-off-by: Daniel Colascione <dancol@google.com>
>> ---
>> include/uapi/linux/bpf.h | 1 +
>> kernel/bpf/syscall.c | 14 ++++++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index b7db3261c62d..4365c50e8055 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -98,6 +98,7 @@ enum bpf_cmd {
>> BPF_BTF_LOAD,
>> BPF_BTF_GET_FD_BY_ID,
>> BPF_TASK_FD_QUERY,
>> + BPF_SYNCHRONIZE,
>> };
>>
>> enum bpf_map_type {
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index d10ecd78105f..60ec7811846e 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -2272,6 +2272,20 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
>> if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
>> return -EPERM;
>>
>> + if (cmd == BPF_SYNCHRONIZE) {
>> + if (uattr != NULL || size != 0)
>> + return -EINVAL;
>> + err = security_bpf(cmd, NULL, 0);
>> + if (err < 0)
>> + return err;
>> + /* BPF programs are run with preempt disabled, so
>> + * synchronize_sched is sufficient even with
>> + * RCU_PREEMPT.
>> + */
>> + synchronize_sched();
>> + return 0;
>
> I don't think it's necessary. sys_membarrier() can do this already
> and some folks use it exactly for this use case.
True --- implementation-wise, today. The point of the patch is to sort
out contractual guarantees. membarrier isn't documented to have the
BPF_SYNCHRONIZE effect right now, although it does. If we want to
extend membarrier's contract, great, but that might make it more
expensive than necessary for callers who, well, just want a memory
barrier. It's worthwhile to have a dedicated BPF command for this
task, especially considering the simplicity of the implementation.
^ permalink raw reply
* [PATCH v3 0/7] Introduce struct __kernel_timex
From: Deepa Dinamani @ 2018-07-07 5:42 UTC (permalink / raw)
To: tglx, linux-kernel
Cc: linux-arch, palmer, arnd, y2038, catalin.marinas, linux-alpha,
netdev, linux-api, linux-riscv, davem
The series introduces struct __kernel_timex as a substitute for
the non y2038 safe struct timex.
The series is based on the original series posted by Arnd Bergmann
in [1].
The overview of the series is as below:
1. Prepare for the compat timex interfaces to be used unconditionally.
2. Introduce struct __kernel_timex.
3. Use struct __kernel_timex in place of struct timex.
4. Switch syscalls to use struct __kernel_timex.
[1] https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html
Changes since v2:
* Use only generic compat.h for riscv
Changes since v1:
* Fix riscv asm/compat.h to pick up generic compat types
Deepa Dinamani (7):
arm64: Make basic compat_* types always available
sparc: Make thread_info.h available directly
riscv: Delete asm/compat.h
timex: prepare compat helpers for y2038 changes
time: Add struct __kernel_timex
timex: use __kernel_timex internally
timex: change syscalls to use struct __kernel_timex
arch/alpha/kernel/osf_sys.c | 2 +-
arch/arm64/include/asm/compat.h | 22 ++++-----
arch/riscv/include/asm/Kbuild | 1 +
arch/riscv/include/asm/compat.h | 29 ------------
arch/sparc/include/asm/compat.h | 2 +
drivers/ptp/ptp_clock.c | 2 +-
include/asm-generic/compat.h | 8 +++-
include/linux/compat.h | 33 --------------
include/linux/compat_time.h | 34 ++++++++++++++
include/linux/posix-clock.h | 2 +-
include/linux/syscalls.h | 5 +--
include/linux/timex.h | 9 +++-
include/uapi/linux/timex.h | 41 +++++++++++++++++
kernel/compat.c | 63 --------------------------
kernel/time/ntp.c | 12 ++---
kernel/time/ntp_internal.h | 2 +-
kernel/time/posix-clock.c | 2 +-
kernel/time/posix-timers.c | 14 ++----
kernel/time/posix-timers.h | 2 +-
kernel/time/time.c | 80 ++++++++++++++++++++++++++++++---
kernel/time/timekeeping.c | 4 +-
21 files changed, 199 insertions(+), 170 deletions(-)
delete mode 100644 arch/riscv/include/asm/compat.h
base-commit: 526674536360a4c508e84f67314c2028e45e1bf2
--
2.17.1
Cc: catalin.marinas@arm.com
Cc: davem@davemloft.net
Cc: linux-alpha@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Cc: netdev@vger.kernel.org
Cc: palmer@sifive.com
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* [PATCH v3 6/7] timex: use __kernel_timex internally
From: Deepa Dinamani @ 2018-07-07 5:42 UTC (permalink / raw)
To: tglx, linux-kernel; +Cc: arnd, y2038, linux-alpha, netdev
In-Reply-To: <20180707054247.19802-1-deepa.kernel@gmail.com>
struct timex is not y2038 safe.
Replace all uses of timex with y2038 safe __kernel_timex.
Note that struct __kernel_timex is an ABI interface definition.
We could define a new structure based on __kernel_timex that
is only available internally instead. Right now, there isn't
a strong motivation for this as the structure is isolated to
a few defined struct timex interfaces and such a structure would
be exactly the same as struct timex.
The patch was generated by the following coccinelle script:
virtual patch
@depends on patch forall@
identifier ts;
expression e;
@@
(
- struct timex ts;
+ struct __kernel_timex ts;
|
- struct timex ts = {};
+ struct __kernel_timex ts = {};
|
- struct timex ts = e;
+ struct __kernel_timex ts = e;
|
- struct timex *ts;
+ struct __kernel_timex *ts;
|
(memset \| copy_from_user \| copy_to_user \)(...,
- sizeof(struct timex))
+ sizeof(struct __kernel_timex))
)
@depends on patch forall@
identifier ts;
identifier fn;
@@
fn(...,
- struct timex *ts,
+ struct __kernel_timex *ts,
...) {
...
}
@depends on patch forall@
identifier ts;
identifier fn;
@@
fn(...,
- struct timex *ts) {
+ struct __kernel_timex *ts) {
...
}
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: linux-alpha@vger.kernel.org
Cc: netdev@vger.kernel.org
---
arch/alpha/kernel/osf_sys.c | 2 +-
drivers/ptp/ptp_clock.c | 2 +-
include/linux/compat_time.h | 6 +++---
include/linux/posix-clock.h | 2 +-
include/linux/timex.h | 2 +-
kernel/time/ntp.c | 12 +++++++-----
kernel/time/ntp_internal.h | 2 +-
kernel/time/posix-clock.c | 2 +-
kernel/time/posix-timers.c | 4 ++--
kernel/time/posix-timers.h | 2 +-
kernel/time/time.c | 14 +++++++-------
kernel/time/timekeeping.c | 4 ++--
12 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 6e921754c8fc..ec86e77d3055 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1260,7 +1260,7 @@ struct timex32 {
SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
{
- struct timex txc;
+ struct __kernel_timex txc;
int ret;
/* copy relevant bits of struct timex. */
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index 7eacc1c4b3b1..f2147e9dd3ca 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -121,7 +121,7 @@ static int ptp_clock_gettime(struct posix_clock *pc, struct timespec64 *tp)
return err;
}
-static int ptp_clock_adjtime(struct posix_clock *pc, struct timex *tx)
+static int ptp_clock_adjtime(struct posix_clock *pc, struct __kernel_timex *tx)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
struct ptp_clock_info *ops;
diff --git a/include/linux/compat_time.h b/include/linux/compat_time.h
index f04454e1b863..25dbd59b3b43 100644
--- a/include/linux/compat_time.h
+++ b/include/linux/compat_time.h
@@ -59,8 +59,8 @@ extern int get_compat_itimerspec64(struct itimerspec64 *its,
const struct compat_itimerspec __user *uits);
extern int put_compat_itimerspec64(const struct itimerspec64 *its,
struct compat_itimerspec __user *uits);
-struct timex;
-int compat_get_timex(struct timex *, const struct compat_timex __user *);
-int compat_put_timex(struct compat_timex __user *, const struct timex *);
+struct __kernel_timex;
+int compat_get_timex(struct __kernel_timex *, const struct compat_timex __user *);
+int compat_put_timex(struct compat_timex __user *, const struct __kernel_timex *);
#endif /* _LINUX_COMPAT_TIME_H */
diff --git a/include/linux/posix-clock.h b/include/linux/posix-clock.h
index 3a3bc71017d5..18674d7d5b1c 100644
--- a/include/linux/posix-clock.h
+++ b/include/linux/posix-clock.h
@@ -51,7 +51,7 @@ struct posix_clock;
struct posix_clock_operations {
struct module *owner;
- int (*clock_adjtime)(struct posix_clock *pc, struct timex *tx);
+ int (*clock_adjtime)(struct posix_clock *pc, struct __kernel_timex *tx);
int (*clock_gettime)(struct posix_clock *pc, struct timespec64 *ts);
diff --git a/include/linux/timex.h b/include/linux/timex.h
index 7f40e9e42ecc..cb894730463c 100644
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -158,7 +158,7 @@ extern unsigned long tick_nsec; /* SHIFTED_HZ period (nsec) */
#define NTP_INTERVAL_FREQ (HZ)
#define NTP_INTERVAL_LENGTH (NSEC_PER_SEC/NTP_INTERVAL_FREQ)
-extern int do_adjtimex(struct timex *);
+extern int do_adjtimex(struct __kernel_timex *);
extern void hardpps(const struct timespec64 *, const struct timespec64 *);
int read_current_timer(unsigned long *timer_val);
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 10a79053e82f..7da9eb8adfd4 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -189,7 +189,7 @@ static inline int is_error_status(int status)
&& (status & (STA_PPSWANDER|STA_PPSERROR)));
}
-static inline void pps_fill_timex(struct timex *txc)
+static inline void pps_fill_timex(struct __kernel_timex *txc)
{
txc->ppsfreq = shift_right((pps_freq >> PPM_SCALE_INV_SHIFT) *
PPM_SCALE_INV, NTP_SCALE_SHIFT);
@@ -221,7 +221,7 @@ static inline int is_error_status(int status)
return status & (STA_UNSYNC|STA_CLOCKERR);
}
-static inline void pps_fill_timex(struct timex *txc)
+static inline void pps_fill_timex(struct __kernel_timex *txc)
{
/* PPS is not implemented, so these are zero */
txc->ppsfreq = 0;
@@ -642,7 +642,8 @@ void ntp_notify_cmos_timer(void)
/*
* Propagate a new txc->status value into the NTP state:
*/
-static inline void process_adj_status(struct timex *txc, struct timespec64 *ts)
+static inline void process_adj_status(struct __kernel_timex *txc,
+ struct timespec64 *ts)
{
if ((time_status & STA_PLL) && !(txc->status & STA_PLL)) {
time_state = TIME_OK;
@@ -665,7 +666,7 @@ static inline void process_adj_status(struct timex *txc, struct timespec64 *ts)
}
-static inline void process_adjtimex_modes(struct timex *txc,
+static inline void process_adjtimex_modes(struct __kernel_timex *txc,
struct timespec64 *ts,
s32 *time_tai)
{
@@ -718,7 +719,8 @@ static inline void process_adjtimex_modes(struct timex *txc,
* adjtimex mainly allows reading (and writing, if superuser) of
* kernel time-keeping variables. used by xntpd.
*/
-int __do_adjtimex(struct timex *txc, struct timespec64 *ts, s32 *time_tai)
+int __do_adjtimex(struct __kernel_timex *txc, struct timespec64 *ts,
+ s32 *time_tai)
{
int result;
diff --git a/kernel/time/ntp_internal.h b/kernel/time/ntp_internal.h
index 909bd1f1bfb1..4386138bed32 100644
--- a/kernel/time/ntp_internal.h
+++ b/kernel/time/ntp_internal.h
@@ -8,6 +8,6 @@ extern void ntp_clear(void);
extern u64 ntp_tick_length(void);
extern ktime_t ntp_get_next_leap(void);
extern int second_overflow(time64_t secs);
-extern int __do_adjtimex(struct timex *, struct timespec64 *, s32 *);
+extern int __do_adjtimex(struct __kernel_timex *, struct timespec64 *, s32 *);
extern void __hardpps(const struct timespec64 *, const struct timespec64 *);
#endif /* _LINUX_NTP_INTERNAL_H */
diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c
index fe56c4e06c51..a138642553cf 100644
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -241,7 +241,7 @@ static void put_clock_desc(struct posix_clock_desc *cd)
fput(cd->fp);
}
-static int pc_clock_adjtime(clockid_t id, struct timex *tx)
+static int pc_clock_adjtime(clockid_t id, struct __kernel_timex *tx)
{
struct posix_clock_desc cd;
int err;
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 3ac7295306dc..a2595cb0cb16 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -209,7 +209,7 @@ static int posix_clock_realtime_set(const clockid_t which_clock,
}
static int posix_clock_realtime_adj(const clockid_t which_clock,
- struct timex *t)
+ struct __kernel_timex *t)
{
return do_adjtimex(t);
}
@@ -1087,7 +1087,7 @@ SYSCALL_DEFINE2(clock_adjtime, const clockid_t, which_clock,
struct timex __user *, utx)
{
const struct k_clock *kc = clockid_to_kclock(which_clock);
- struct timex ktx;
+ struct __kernel_timex ktx;
int err;
if (!kc)
diff --git a/kernel/time/posix-timers.h b/kernel/time/posix-timers.h
index ddb21145211a..de5daa6d975a 100644
--- a/kernel/time/posix-timers.h
+++ b/kernel/time/posix-timers.h
@@ -8,7 +8,7 @@ struct k_clock {
const struct timespec64 *tp);
int (*clock_get)(const clockid_t which_clock,
struct timespec64 *tp);
- int (*clock_adj)(const clockid_t which_clock, struct timex *tx);
+ int (*clock_adj)(const clockid_t which_clock, struct __kernel_timex *tx);
int (*timer_create)(struct k_itimer *timer);
int (*nsleep)(const clockid_t which_clock, int flags,
const struct timespec64 *);
diff --git a/kernel/time/time.c b/kernel/time/time.c
index c40cce820380..2c5afb008b14 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -265,24 +265,24 @@ COMPAT_SYSCALL_DEFINE2(settimeofday, struct compat_timeval __user *, tv,
SYSCALL_DEFINE1(adjtimex, struct timex __user *, txc_p)
{
- struct timex txc; /* Local copy of parameter */
+ struct __kernel_timex txc; /* Local copy of parameter */
int ret;
/* Copy the user data space into the kernel copy
* structure. But bear in mind that the structures
* may change
*/
- if (copy_from_user(&txc, txc_p, sizeof(struct timex)))
+ if (copy_from_user(&txc, txc_p, sizeof(struct __kernel_timex)))
return -EFAULT;
ret = do_adjtimex(&txc);
- return copy_to_user(txc_p, &txc, sizeof(struct timex)) ? -EFAULT : ret;
+ return copy_to_user(txc_p, &txc, sizeof(struct __kernel_timex)) ? -EFAULT : ret;
}
#ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE1(adjtimex, struct compat_timex __user *, utp)
{
- struct timex txc;
+ struct __kernel_timex txc;
int err, ret;
err = compat_get_timex(&txc, utp);
@@ -979,11 +979,11 @@ int put_compat_itimerspec64(const struct itimerspec64 *its,
}
EXPORT_SYMBOL_GPL(put_compat_itimerspec64);
-int compat_get_timex(struct timex *txc, const struct compat_timex __user *utp)
+int compat_get_timex(struct __kernel_timex *txc, const struct compat_timex __user *utp)
{
struct compat_timex tx32;
- memset(txc, 0, sizeof(struct timex));
+ memset(txc, 0, sizeof(struct __kernel_timex));
if (copy_from_user(&tx32, utp, sizeof(struct compat_timex)))
return -EFAULT;
@@ -1011,7 +1011,7 @@ int compat_get_timex(struct timex *txc, const struct compat_timex __user *utp)
return 0;
}
-int compat_put_timex(struct compat_timex __user *utp, const struct timex *txc)
+int compat_put_timex(struct compat_timex __user *utp, const struct __kernel_timex *txc)
{
struct compat_timex tx32;
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 77c436a0070b..9bb7e977f50e 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2220,7 +2220,7 @@ ktime_t ktime_get_update_offsets_now(unsigned int *cwsseq, ktime_t *offs_real,
/**
* timekeeping_validate_timex - Ensures the timex is ok for use in do_adjtimex
*/
-static int timekeeping_validate_timex(struct timex *txc)
+static int timekeeping_validate_timex(struct __kernel_timex *txc)
{
if (txc->modes & ADJ_ADJTIME) {
/* singleshot must not be used with any other mode bits */
@@ -2286,7 +2286,7 @@ static int timekeeping_validate_timex(struct timex *txc)
/**
* do_adjtimex() - Accessor function to NTP __do_adjtimex function
*/
-int do_adjtimex(struct timex *txc)
+int do_adjtimex(struct __kernel_timex *txc)
{
struct timekeeper *tk = &tk_core.timekeeper;
unsigned long flags;
--
2.17.1
^ permalink raw reply related
* Re: KASAN: stack-out-of-bounds Read in vmalloc_fault
From: Dmitry Vyukov @ 2018-07-07 7:00 UTC (permalink / raw)
To: syzbot
Cc: bridge, coreteam, David Miller, Florian Westphal,
Jozsef Kadlecsik, LKML, netdev, netfilter-devel,
Pablo Neira Ayuso, stephen hemminger, syzkaller-bugs
In-Reply-To: <000000000000d8e31b05705e901b@google.com>
On Sat, Jul 7, 2018 at 3:19 AM, syzbot
<syzbot+7b269953d076326d7de0@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 6fcf9b1d4d6c r8169: fix runtime suspend
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=174529b2400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=d264f2b04177ca7c
> dashboard link: https://syzkaller.appspot.com/bug?extid=7b269953d076326d7de0
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1397e2c2400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120e462c400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+7b269953d076326d7de0@syzkaller.appspotmail.com
This looks like the bpf map bug which leads to random bugs on stack:
#syz dup: KASAN: stack-out-of-bounds Read in timerqueue_add
> IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
> IPv6: ADDRCONF(NETDEV_UP): team0: link is not ready
> 8021q: adding VLAN 0 to HW filter on device team0
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in pgd_val
> arch/x86/include/asm/paravirt.h:412 [inline]
> BUG: KASAN: stack-out-of-bounds in p4d_pfn
> arch/x86/include/asm/pgtable.h:205 [inline]
> BUG: KASAN: stack-out-of-bounds in vmalloc_fault+0x743/0x760
> arch/x86/mm/fault.c:462
> Read of size 8 at addr ffff8801a936f160 by task ksoftirqd/0/9
>
> CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 4.18.0-rc3+ #47
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> pgd_val arch/x86/include/asm/paravirt.h:412 [inline]
> p4d_pfn arch/x86/include/asm/pgtable.h:205 [inline]
> vmalloc_fault+0x743/0x760 arch/x86/mm/fault.c:462
> __do_page_fault+0x829/0xe50 arch/x86/mm/fault.c:1245
> do_page_fault+0xf6/0x8c0 arch/x86/mm/fault.c:1471
> page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1160
> RIP: 0010:ebt_do_table+0x1a7/0x2170 net/bridge/netfilter/ebtables.c:208
> Code: 24 04 4d 8d ac 24 80 00 00 00 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89
> f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 8f 1e 00 00 <41> 8b 44 24 04 49
> 8d 7c 24 38 65 8b 15 28 7f 39 79 48 c1 e0 04 48
> RSP: 0018:ffff8801d9ab6ab8 EFLAGS: 00010246
> RAX: 0000000000000007 RBX: 0000000000000005 RCX: ffffffff81601dff
> RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffc90001e2c004
> RBP: ffff8801d9ab6c88 R08: ffffed003a6f4e49 R09: ffffed003a6f4e48
> R10: ffffed003a6f4e48 R11: ffff8801d37a7243 R12: ffffc90001e2c000
> R13: ffffc90001e2c080 R14: ffff8801d9ab6cc0 R15: ffff8801d9394380
> ebt_broute+0x200/0x340 net/bridge/netfilter/ebtable_broute.c:60
> br_handle_frame+0x6d1/0x1a20 net/bridge/br_input.c:292
> __netif_receive_skb_core.constprop.140+0x142d/0x3620 net/core/dev.c:4697
> __netif_receive_skb_one_core+0xd0/0x200 net/core/dev.c:4766
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4873
> process_backlog+0x219/0x760 net/core/dev.c:5676
> napi_poll net/core/dev.c:6088 [inline]
> net_rx_action+0x7a5/0x1950 net/core/dev.c:6154
> __do_softirq+0x2e8/0xb17 kernel/softirq.c:288
> run_ksoftirqd+0x86/0x100 kernel/softirq.c:649
> smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
> kthread+0x345/0x410 kernel/kthread.c:240
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>
> The buggy address belongs to the page:
> page:ffffea0006a4dbc0 count:1 mapcount:0 mapping:0000000000000000 index:0x0
> flags: 0x2fffc0000000000()
> raw: 02fffc0000000000 dead000000000100 dead000000000200 0000000000000000
> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801a936f000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801a936f080: 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00
>>
>> ffff8801a936f100: f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2 f8
>
> ^
> ffff8801a936f180: f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00
> ffff8801a936f200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000d8e31b05705e901b%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATH net] cxgb4: assume flash part size to be 4MB, if it can't be determined
From: Ganesh Goudar @ 2018-07-07 7:08 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, venkatesh, Casey Leedom, Ganesh Goudar
From: Casey Leedom <leedom@chelsio.com>
t4_get_flash_params() fails in a fatal fashion if the FLASH part isn't
one of the recognized parts. But this leads to desperate efforts to update
drivers when various FLASH parts which we are using suddenly become
unavailable and we need to substitute new FLASH parts. This has lead to
more than one Customer Field Emergency when a Customer has an old driver
and suddenly can't use newly shipped adapters.
This commit fixes this by simply assuming that the FLASH part is 4MB in
size if it can't be identified. Note that all Chelsio adapters will have
flash parts which are at least 4MB in size.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 35 +++++++++++-------------------
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index d266177..2d9943f 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -8753,7 +8753,7 @@ static int t4_get_flash_params(struct adapter *adap)
};
unsigned int part, manufacturer;
- unsigned int density, size;
+ unsigned int density, size = 0;
u32 flashid = 0;
int ret;
@@ -8823,11 +8823,6 @@ static int t4_get_flash_params(struct adapter *adap)
case 0x22: /* 256MB */
size = 1 << 28;
break;
-
- default:
- dev_err(adap->pdev_dev, "Micron Flash Part has bad size, ID = %#x, Density code = %#x\n",
- flashid, density);
- return -EINVAL;
}
break;
}
@@ -8843,10 +8838,6 @@ static int t4_get_flash_params(struct adapter *adap)
case 0x17: /* 64MB */
size = 1 << 26;
break;
- default:
- dev_err(adap->pdev_dev, "ISSI Flash Part has bad size, ID = %#x, Density code = %#x\n",
- flashid, density);
- return -EINVAL;
}
break;
}
@@ -8862,10 +8853,6 @@ static int t4_get_flash_params(struct adapter *adap)
case 0x18: /* 16MB */
size = 1 << 24;
break;
- default:
- dev_err(adap->pdev_dev, "Macronix Flash Part has bad size, ID = %#x, Density code = %#x\n",
- flashid, density);
- return -EINVAL;
}
break;
}
@@ -8881,17 +8868,21 @@ static int t4_get_flash_params(struct adapter *adap)
case 0x18: /* 16MB */
size = 1 << 24;
break;
- default:
- dev_err(adap->pdev_dev, "Winbond Flash Part has bad size, ID = %#x, Density code = %#x\n",
- flashid, density);
- return -EINVAL;
}
break;
}
- default:
- dev_err(adap->pdev_dev, "Unsupported Flash Part, ID = %#x\n",
- flashid);
- return -EINVAL;
+ }
+
+ /* If we didn't recognize the FLASH part, that's no real issue: the
+ * Hardware/Software contract says that Hardware will _*ALWAYS*_
+ * use a FLASH part which is at least 4MB in size and has 64KB
+ * sectors. The unrecognized FLASH part is likely to be much larger
+ * than 4MB, but that's all we really need.
+ */
+ if (size == 0) {
+ dev_warn(adap->pdev_dev, "Unknown Flash Part, ID = %#x, assuming 4MB\n",
+ flashid);
+ size = 1 << 22;
}
/* Store decoded Flash size and fall through into vetting code. */
--
2.1.0
^ permalink raw reply related
* Please Let My Prayer Touch Your Heart.
From: allanlillian @ 2018-07-07 7:16 UTC (permalink / raw)
Hello My Dear
Calvary Greetings in the name of the ALMIGHTY
I am Mrs Lillian Allan from Switzerland I am married to Late Mr.Allan
Joseph who is a wealthy business man here in Burkina Faso we were
married for many years without a child before he died after a brief
illness Before his sudden death we where devoted christian When my
late husband was alive he deposited the sum of Six Million Two
Hundred United State Dollars ($6.200.000.00) in one of the prime bank
here in Burkina Faso, Presently this money is still with the Bank,
I am very sick from Kidney cancer that i may not last till the next
two months according to my doctor so now i decided to donate this
money to a honest individual who will use it to work for Almighty,
orphans, widow and maintenance of church to fulfill the vow i and my
late husband made to Almighty, and i have chosen you after praying.
I want this money to be use as i have said since i do not have any
child to inherit it and our relatives are all unbelievers and i don't
want our hard earn money to be used in ungodly way so you will take
40% of the fund for your effort and use the remaining as i stated, as
soon as i read from you i will give you more details on how to achieve
it, as i don't know what tomorrow will result, i wish you the best in
life. Please Always remember me in your prayers.
Yours Sister,
Mrs Lillian Allan.
Please Let My Prayer Touch Your Heart.
^ permalink raw reply
* [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets in tcp_abort
From: Lorenzo Colitti @ 2018-07-07 7:31 UTC (permalink / raw)
To: netdev
Cc: astrachan, subashab, eric.dumazet, davem, Lorenzo Colitti,
David Ahern
When tcp_diag_destroy closes a TCP_NEW_SYN_RECV socket, it first
frees it by calling inet_csk_reqsk_queue_drop_and_and_put in
tcp_abort, and then frees it again by calling sock_gen_put.
Since tcp_abort only has one caller, and all the other codepaths
in tcp_abort don't free the socket, just remove the free in that
function.
Cc: David Ahern <dsa@cumulusnetworks.com>
Tested: passes Android sock_diag_test.py, which exercises this codepath
Fixes: d7226c7a4dd1 ("net: diag: Fix refcnt leak in error path destroying socket")
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
---
net/ipv4/tcp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index e7b53d2a97..c959bb6ea4 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3720,8 +3720,7 @@ int tcp_abort(struct sock *sk, int err)
struct request_sock *req = inet_reqsk(sk);
local_bh_disable();
- inet_csk_reqsk_queue_drop_and_put(req->rsk_listener,
- req);
+ inet_csk_reqsk_queue_drop(req->rsk_listener, req);
local_bh_enable();
return 0;
}
--
2.18.0.203.gfac676dfb9-goog
^ permalink raw reply related
* Re: Crash due to destroying TCP request sockets using SOCK_DESTROY
From: Lorenzo Colitti @ 2018-07-07 7:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Subash Abhinov Kasiviswanathan, netdev, Alistair Strachan,
David Ahern
In-Reply-To: <af52b285-e97b-f610-acc6-cb1361609034@gmail.com>
On Fri, Jul 6, 2018 at 7:24 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Your patch makes sense to me, please submit it formally with :
>
> Fixes: d7226c7a4dd1 ("net: diag: Fix refcnt leak in error path destroying socket")
> Cc: David Ahern <dsa@cumulusnetworks.com>
Submitted a patch against net: https://patchwork.ozlabs.org/patch/940757/ .
Cheers,
Lorenzo
^ permalink raw reply
* Re: [PATCH 09/12] iwlwifi: Remove local iwl_bcast_addr and use ether_broadcast_addr
From: Luciano Coelho @ 2018-07-07 7:40 UTC (permalink / raw)
To: Joe Perches, linux-kernel
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, linux-wireless, netdev
In-Reply-To: <af831d8873ffcc36014244f76d21cd6aaf5aca9c.1522479608.git.joe@perches.com>
On Sat, 2018-03-31 at 00:05 -0700, Joe Perches wrote:
> Use the new global to save a little bit of object code.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
I took this one to our internal tree and it will be applied as part of
our normal upstreaming process.
Thanks!
--
Luca.
^ permalink raw reply
* [PATCH v3 net-next] net/sched: add skbprio scheduler
From: Nishanth Devarajan @ 2018-07-07 10:13 UTC (permalink / raw)
To: xiyou.wangcong, jhs, jiri, davem; +Cc: netdev, doucette, michel
net/sched: add skbprio scheduer
Skbprio (SKB Priority Queue) is a queueing discipline that prioritizes packets
according to their skb->priority field. Under congestion, already-enqueued lower
priority packets will be dropped to make space available for higher priority
packets. Skbprio was conceived as a solution for denial-of-service defenses that
need to route packets with different priorities as a means to overcome DoS
attacks.
v3
*Drop max_limit parameter in struct skbprio_sched_data and instead use
sch->limit.
*Reference qdisc_dev(sch)->tx_queue_len only once, during initialisation for
qdisc (previously being referenced every time qdisc changes).
*Move qdisc's detailed description from in-code to Documentation/networking.
*When qdisc is saturated, enqueue incoming packet first before dequeueing
lowest priority packet in queue - improves usage of call stack registers.
*Introduce and use overlimit stat to keep track of number of dropped packets.
v2
*Use skb->priority field rather than DS field. Rename queueing discipline as
SKB Priority Queue (previously Gatekeeper Priority Queue).
*Queueing discipline is made classful to expose Skbprio's internal priority
queues.
Signed-off-by: Nishanth Devarajan <ndev2021@gmail.com>
Reviewed-by: Sachin Paryani <sachin.paryani@gmail.com>
Reviewed-by: Cody Doucette <doucette@bu.edu>
Reviewed-by: Michel Machado <michel@digirati.com.br>
---
Documentation/networking/sch_skbprio.txt | 24 +++
include/uapi/linux/pkt_sched.h | 15 ++
net/sched/Kconfig | 13 ++
net/sched/Makefile | 1 +
net/sched/sch_skbprio.c | 330 +++++++++++++++++++++++++++++++
5 files changed, 383 insertions(+)
create mode 100644 Documentation/networking/sch_skbprio.txt
create mode 100644 net/sched/sch_skbprio.c
diff --git a/Documentation/networking/sch_skbprio.txt b/Documentation/networking/sch_skbprio.txt
new file mode 100644
index 0000000..3aa4d3e
--- /dev/null
+++ b/Documentation/networking/sch_skbprio.txt
@@ -0,0 +1,24 @@
+SKB Priority Queue
+==================
+
+This qdisc schedules a packet according to skb->priority, where a higher
+value places the packet closer to the exit of the queue. When the queue is
+full, the lowest priority packet in the queue is dropped to make room for
+the packet to be added if it has higher priority. If the packet to be added
+has lower priority than all packets in the queue, it is dropped.
+
+Without the SKB priority queue, queue length limits must be imposed
+for individual queues, and there is no easy way to enforce a global queue
+length limit across all priorities. With the SKBprio queue, a global
+queue length limit can be enforced while not restricting the queue lengths
+of individual priorities.
+
+This is especially useful for a denial-of-service defense system like
+Gatekeeper, which prioritizes packets in flows that demonstrate expected
+behavior of legitimate users. The queue is flexible to allow any number
+of packets of any priority up to the global limit of the scheduler
+without risking resource overconsumption by a flood of low priority packets.
+
+The Gatekeeper codebase is found here:
+
+ https://github.com/AltraMayor/gatekeeper
diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index 9491184..5c6429d 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b/include/uapi/linux/pkt_sched.h
@@ -124,6 +124,21 @@ struct tc_fifo_qopt {
__u32 limit; /* Queue length: bytes for bfifo, packets for pfifo */
};
+/* SKBPRIO section */
+
+/*
+ * Priorities go from zero to (SKBPRIO_MAX_PRIORITY - 1).
+ * SKBPRIO_MAX_PRIORITY should be at least 64 in order for skbprio to be able
+ * to map one to one the DS field of IPV4 and IPV6 headers.
+ * Memory allocation grows linearly with SKBPRIO_MAX_PRIORITY.
+ */
+
+#define SKBPRIO_MAX_PRIORITY 64
+
+struct tc_skbprio_qopt {
+ __u32 limit; /* Queue length in packets. */
+};
+
/* PRIO section */
#define TCQ_PRIO_BANDS 16
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index fcc8970..4aa6eb0 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -251,6 +251,19 @@ config NET_SCH_MQPRIO
If unsure, say N.
+config NET_SCH_SKBPRIO
+ tristate "SKB priority queue scheduler (SKBPRIO)"
+ help
+ Say Y here if you want to use the SKB priority queue
+ scheduler. This schedules packets according to skb->priority,
+ which is useful for request packets in DoS mitigation systems such
+ as Gatekeeper.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sch_skbprio.
+
+ If unsure, say N.
+
config NET_SCH_CHOKE
tristate "CHOose and Keep responsive flow scheduler (CHOKE)"
help
diff --git a/net/sched/Makefile b/net/sched/Makefile
index 9a5a707..ad5cd1e 100644
--- a/net/sched/Makefile
+++ b/net/sched/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_NET_SCH_NETEM) += sch_netem.o
obj-$(CONFIG_NET_SCH_DRR) += sch_drr.o
obj-$(CONFIG_NET_SCH_PLUG) += sch_plug.o
obj-$(CONFIG_NET_SCH_MQPRIO) += sch_mqprio.o
+obj-$(CONFIG_NET_SCH_SKBPRIO) += sch_skbprio.o
obj-$(CONFIG_NET_SCH_CHOKE) += sch_choke.o
obj-$(CONFIG_NET_SCH_QFQ) += sch_qfq.o
obj-$(CONFIG_NET_SCH_CODEL) += sch_codel.o
diff --git a/net/sched/sch_skbprio.c b/net/sched/sch_skbprio.c
new file mode 100644
index 0000000..6b94f54
--- /dev/null
+++ b/net/sched/sch_skbprio.c
@@ -0,0 +1,330 @@
+/*
+ * net/sched/sch_skbprio.c SKB Priority Queue.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Nishanth Devarajan, <ndev2021@gmail.com>
+ * Cody Doucette, <doucette@bu.edu>
+ * original idea by Michel Machado, Cody Doucette, and Qiaobin Fu
+ */
+
+#include <linux/string.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/skbuff.h>
+#include <net/pkt_sched.h>
+#include <net/sch_generic.h>
+#include <net/inet_ecn.h>
+
+/* SKB Priority Queue
+ * =================================
+ *
+ * Skbprio (SKB Priority Queue) is a queueing discipline that prioritizes
+ * packets according to their skb->priority field. Under congestion,
+ * Skbprio drops already-enqueued lower priority packets to make space
+ * available for higher priority packets; it was conceived as a solution
+ * for denial-of-service defenses that need to route packets with different
+ * priorities as a mean to overcome DoS attacks.
+ */
+
+struct skbprio_sched_data {
+ /* Queue state. */
+ struct sk_buff_head qdiscs[SKBPRIO_MAX_PRIORITY];
+ struct gnet_stats_queue qstats[SKBPRIO_MAX_PRIORITY];
+ u16 highest_prio;
+ u16 lowest_prio;
+};
+
+static u16 calc_new_high_prio(const struct skbprio_sched_data *q)
+{
+ int prio;
+
+ for (prio = q->highest_prio - 1; prio >= q->lowest_prio; prio--) {
+ if (!skb_queue_empty(&q->qdiscs[prio]))
+ return prio;
+ }
+
+ /* SKB queue is empty, return 0 (default highest priority setting). */
+ return 0;
+}
+
+static u16 calc_new_low_prio(const struct skbprio_sched_data *q)
+{
+ int prio;
+
+ for (prio = q->lowest_prio + 1; prio <= q->highest_prio; prio++) {
+ if (!skb_queue_empty(&q->qdiscs[prio]))
+ return prio;
+ }
+
+ /* SKB queue is empty, return SKBPRIO_MAX_PRIORITY - 1
+ * (default lowest priority setting).
+ */
+ return SKBPRIO_MAX_PRIORITY - 1;
+}
+
+static int skbprio_enqueue(struct sk_buff *skb, struct Qdisc *sch,
+ struct sk_buff **to_free)
+{
+ const unsigned int max_priority = SKBPRIO_MAX_PRIORITY - 1;
+ struct skbprio_sched_data *q = qdisc_priv(sch);
+ struct sk_buff_head *qdisc;
+ struct sk_buff_head *lp_qdisc;
+ struct sk_buff *to_drop;
+ u16 prio, lp;
+
+ /* Obtain the priority of @skb. */
+ prio = min(skb->priority, max_priority);
+
+ qdisc = &q->qdiscs[prio];
+ if (sch->q.qlen < sch->limit) {
+ __skb_queue_tail(qdisc, skb);
+ qdisc_qstats_backlog_inc(sch, skb);
+ q->qstats[prio].backlog += qdisc_pkt_len(skb);
+
+ /* Check to update highest and lowest priorities. */
+ if (prio > q->highest_prio)
+ q->highest_prio = prio;
+
+ if (prio < q->lowest_prio)
+ q->lowest_prio = prio;
+
+ sch->q.qlen++;
+ return NET_XMIT_SUCCESS;
+ }
+
+ /* If this packet has the lowest priority, drop it. */
+ lp = q->lowest_prio;
+ if (prio <= lp) {
+ q->qstats[prio].drops++;
+ q->qstats[prio].overlimits++;
+ return qdisc_drop(skb, sch, to_free);
+ }
+
+ __skb_queue_tail(qdisc, skb);
+ qdisc_qstats_backlog_inc(sch, skb);
+ q->qstats[prio].backlog += qdisc_pkt_len(skb);
+
+ /* Drop the packet at the tail of the lowest priority qdisc. */
+ lp_qdisc = &q->qdiscs[lp];
+ to_drop = __skb_dequeue_tail(lp_qdisc);
+ BUG_ON(!to_drop);
+ qdisc_qstats_backlog_dec(sch, to_drop);
+ qdisc_drop(to_drop, sch, to_free);
+
+ q->qstats[lp].backlog -= qdisc_pkt_len(to_drop);
+ q->qstats[lp].drops++;
+ q->qstats[lp].overlimits++;
+
+ /* Check to update highest and lowest priorities. */
+ if (skb_queue_empty(lp_qdisc)) {
+ if (q->lowest_prio == q->highest_prio) {
+ /* The incoming packet is the only packet in queue. */
+ BUG_ON(sch->q.qlen != 1);
+ q->lowest_prio = prio;
+ q->highest_prio = prio;
+ } else {
+ q->lowest_prio = calc_new_low_prio(q);
+ }
+ }
+
+ if (prio > q->highest_prio)
+ q->highest_prio = prio;
+
+ return NET_XMIT_CN;
+}
+
+static struct sk_buff *skbprio_dequeue(struct Qdisc *sch)
+{
+ struct skbprio_sched_data *q = qdisc_priv(sch);
+ struct sk_buff_head *hpq = &q->qdiscs[q->highest_prio];
+ struct sk_buff *skb = __skb_dequeue(hpq);
+
+ if (unlikely(!skb))
+ return NULL;
+
+ sch->q.qlen--;
+ qdisc_qstats_backlog_dec(sch, skb);
+ qdisc_bstats_update(sch, skb);
+
+ q->qstats[q->highest_prio].backlog -= qdisc_pkt_len(skb);
+
+ /* Update highest priority field. */
+ if (skb_queue_empty(hpq)) {
+ if (q->lowest_prio == q->highest_prio) {
+ BUG_ON(sch->q.qlen);
+ q->highest_prio = 0;
+ q->lowest_prio = SKBPRIO_MAX_PRIORITY - 1;
+ } else {
+ q->highest_prio = calc_new_high_prio(q);
+ }
+ }
+ return skb;
+}
+
+static int skbprio_change(struct Qdisc *sch, struct nlattr *opt,
+ struct netlink_ext_ack *extack)
+{
+ struct skbprio_sched_data *q = qdisc_priv(sch);
+ struct tc_skbprio_qopt *ctl = nla_data(opt);
+ const unsigned int min_limit = 1;
+
+ if (ctl->limit == (typeof(ctl->limit))-1)
+ sch->limit = max(qdisc_dev(sch)->tx_queue_len, min_limit);
+ else if (ctl->limit < min_limit)
+ return -EINVAL;
+ else
+ sch->limit = ctl->limit;
+
+ return 0;
+}
+
+static int skbprio_init(struct Qdisc *sch, struct nlattr *opt,
+ struct netlink_ext_ack *extack)
+{
+ struct skbprio_sched_data *q = qdisc_priv(sch);
+ const unsigned int min_limit = 1;
+ int prio;
+
+ /* Initialise all queues, one for each possible priority. */
+ for (prio = 0; prio < SKBPRIO_MAX_PRIORITY; prio++)
+ __skb_queue_head_init(&q->qdiscs[prio]);
+
+ memset(&q->qstats, 0, sizeof(q->qstats));
+ q->highest_prio = 0;
+ q->lowest_prio = SKBPRIO_MAX_PRIORITY - 1;
+ if (!opt) {
+ sch->limit = max(qdisc_dev(sch)->tx_queue_len, min_limit);
+ return 0;
+ }
+ return skbprio_change(sch, opt, extack);
+}
+
+static int skbprio_dump(struct Qdisc *sch, struct sk_buff *skb)
+{
+ struct skbprio_sched_data *q = qdisc_priv(sch);
+ struct tc_skbprio_qopt opt;
+
+ opt.limit = sch->limit;
+
+ if (nla_put(skb, TCA_OPTIONS, sizeof(opt), &opt))
+ return -1;
+
+ return skb->len;
+}
+
+static void skbprio_reset(struct Qdisc *sch)
+{
+ struct skbprio_sched_data *q = qdisc_priv(sch);
+ int prio;
+
+ sch->qstats.backlog = 0;
+ sch->q.qlen = 0;
+
+ for (prio = 0; prio < SKBPRIO_MAX_PRIORITY; prio++)
+ __skb_queue_purge(&q->qdiscs[prio]);
+
+ memset(&q->qstats, 0, sizeof(q->qstats));
+ q->highest_prio = 0;
+ q->lowest_prio = SKBPRIO_MAX_PRIORITY - 1;
+}
+
+static void skbprio_destroy(struct Qdisc *sch)
+{
+ struct skbprio_sched_data *q = qdisc_priv(sch);
+ int prio;
+
+ for (prio = 0; prio < SKBPRIO_MAX_PRIORITY; prio++)
+ __skb_queue_purge(&q->qdiscs[prio]);
+}
+
+static struct Qdisc *skbprio_leaf(struct Qdisc *sch, unsigned long arg)
+{
+ return NULL;
+}
+
+static unsigned long skbprio_find(struct Qdisc *sch, u32 classid)
+{
+ return 0;
+}
+
+static int skbprio_dump_class(struct Qdisc *sch, unsigned long cl,
+ struct sk_buff *skb, struct tcmsg *tcm)
+{
+ tcm->tcm_handle |= TC_H_MIN(cl);
+ return 0;
+}
+
+static int skbprio_dump_class_stats(struct Qdisc *sch, unsigned long cl,
+ struct gnet_dump *d)
+{
+ struct skbprio_sched_data *q = qdisc_priv(sch);
+ if (gnet_stats_copy_queue(d, NULL, &q->qstats[cl - 1],
+ q->qstats[cl - 1].qlen) < 0)
+ return -1;
+ return 0;
+}
+
+static void skbprio_walk(struct Qdisc *sch, struct qdisc_walker *arg)
+{
+ unsigned int i;
+
+ if (arg->stop)
+ return;
+
+ for (i = 0; i < SKBPRIO_MAX_PRIORITY; i++) {
+ if (arg->count < arg->skip) {
+ arg->count++;
+ continue;
+ }
+ if (arg->fn(sch, i + 1, arg) < 0) {
+ arg->stop = 1;
+ break;
+ }
+ arg->count++;
+ }
+}
+
+static const struct Qdisc_class_ops skbprio_class_ops = {
+ .leaf = skbprio_leaf,
+ .find = skbprio_find,
+ .dump = skbprio_dump_class,
+ .dump_stats = skbprio_dump_class_stats,
+ .walk = skbprio_walk,
+};
+
+static struct Qdisc_ops skbprio_qdisc_ops __read_mostly = {
+ .cl_ops = &skbprio_class_ops,
+ .id = "skbprio",
+ .priv_size = sizeof(struct skbprio_sched_data),
+ .enqueue = skbprio_enqueue,
+ .dequeue = skbprio_dequeue,
+ .peek = qdisc_peek_dequeued,
+ .init = skbprio_init,
+ .reset = skbprio_reset,
+ .change = skbprio_change,
+ .dump = skbprio_dump,
+ .destroy = skbprio_destroy,
+ .owner = THIS_MODULE,
+};
+
+static int __init skbprio_module_init(void)
+{
+ return register_qdisc(&skbprio_qdisc_ops);
+}
+
+static void __exit skbprio_module_exit(void)
+{
+ unregister_qdisc(&skbprio_qdisc_ops);
+}
+
+module_init(skbprio_module_init)
+module_exit(skbprio_module_exit)
+
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 1/6] net: mvneta: remove data pointer usage from device_node structure
From: kbuild test robot @ 2018-07-07 10:45 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: kbuild-all, David S. Miller, linux-kernel, netdev,
Thomas Petazzoni, linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory CLEMENT, Yelena Krivosheev,
Nadav Haklai, Marcin Wojtas, Dmitri Epshtein, Antoine Tenart,
Miquèl Raynal, Maxime Chevallier
In-Reply-To: <20180706131949.2684-2-gregory.clement@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
Hi Gregory,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Gregory-CLEMENT/Few-improvements-on-mvneta/20180707-034934
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "mvneta_bm_get" [drivers/net/ethernet/marvell/mvneta.ko] undefined!
>> ERROR: "mvneta_bm_put" [drivers/net/ethernet/marvell/mvneta.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 64043 bytes --]
^ permalink raw reply
* Re: [net 0/4] tipc: fixes in duplicate address discovery function
From: David Miller @ 2018-07-07 11:03 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1530900606-24429-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Fri, 6 Jul 2018 20:10:02 +0200
> commit 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address
> hash values") introduced new functionality that has turned out to
> contain several bugs and weaknesses.
>
> We address those in this series.
Series applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix br_vlan_get_{pvid,info} return values
From: David Miller @ 2018-07-07 11:05 UTC (permalink / raw)
To: arnd; +Cc: nikolay, jiri, yotamg, roopa, petrm, netdev, linux-kernel
In-Reply-To: <20180706124420.3129099-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 6 Jul 2018 14:44:02 +0200
> These two functions return the regular -EINVAL failure in the normal
> code path, but return a nonstandard '-1' error otherwise, which gets
> interpreted as -EPERM.
>
> Let's change it to -EINVAL for the dummy functions as well.
>
> Fixes: 4d4fd36126d6 ("net: bridge: Publish bridge accessor functions")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum_router: avoid uninitialized variable access
From: David Miller @ 2018-07-07 11:07 UTC (permalink / raw)
To: arnd; +Cc: jiri, idosch, petrm, arkadis, dsahern, netdev, linux-kernel
In-Reply-To: <20180706124455.3151925-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 6 Jul 2018 14:44:45 +0200
> When CONFIG_BRIDGE_VLAN_FILTERING is disabled, gcc correctly points out
> that the 'vid' variable is uninitialized whenever br_vlan_get_pvid
> returns an error:
>
> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function 'mlxsw_sp_rif_vlan_fid_get':
> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:6881:6: error: 'vid' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This changes the condition check to always return -EINVAL here,
> which I guess is what the author intended here.
>
> Fixes: e6f1960ae6c7 ("mlxsw: spectrum_router: Allocate FID according to PVID")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH] [net-next] devlink: fix incorrect return statement
From: David Miller @ 2018-07-07 11:07 UTC (permalink / raw)
To: arnd; +Cc: jiri, arkadis, moshe, dsahern, netdev, linux-kernel
In-Reply-To: <20180706125858.3602497-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 6 Jul 2018 14:58:51 +0200
> A newly added dummy helper function tries to return a failure from a "void"
> function:
>
> In file included from include/net/dsa.h:24,
> from arch/arm/plat-orion/common.c:21:
> include/net/devlink.h: In function 'devlink_param_value_changed':
> include/net/devlink.h:771:9: error: 'return' with a value, in function returning void [-Werror]
> return -EOPNOTSUPP;
>
> This fixes it by removing the bogus statement.
>
> Fixes: ea601e170988 ("devlink: Add devlink notifications support for params")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH v4,net-next] vlan: implement vlan id and protocol changes
From: David Miller @ 2018-07-07 11:11 UTC (permalink / raw)
To: 3chas3; +Cc: netdev
In-Reply-To: <20180702223528.582-1-3chas3@gmail.com>
From: Chas Williams <3chas3@gmail.com>
Date: Mon, 2 Jul 2018 18:35:28 -0400
> vlan_changelink silently ignores attempts to change the vlan id
> or protocol id of an existing vlan interface. Implement by adding
> the new vlan id and protocol to the interface's vlan group and then
> removing the old vlan id and protocol from the vlan group. This
> avoids the netlink churn of deleting and re-adding an interface
> to change the vlan id.
>
> Signed-off-by: Chas Williams <3chas3@gmail.com>
Chas, it seems to me that you add the new notifier by not even one
driver is listening for the event.
Either it is necessary, and you should show at least one example
use case, or it not necessary and therefore should not be added.
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] tcp: fix high tail latencies in DCTCP
From: David Miller @ 2018-07-07 11:15 UTC (permalink / raw)
To: brakmo
Cc: netdev, kernel-team, bmatheny, ast, ncardwell, ycheng, sibanez,
eric.dumazet
In-Reply-To: <20180703162615.314231-1-brakmo@fb.com>
From: Lawrence Brakmo <brakmo@fb.com>
Date: Tue, 3 Jul 2018 09:26:13 -0700
> When have observed high tail latencies when using DCTCP for RPCs as
> compared to using Cubic. For example, in one setup there are 2 hosts
> sending to a 3rd one, with each sender having 3 flows (1 stream,
> 1 1MB back-to-back RPCs and 1 10KB back-to-back RPCs). The following
> table shows the 99% and 99.9% latencies for both Cubic and dctcp:
>
> Cubic 99% Cubic 99.9% dctcp 99% dctcp 99.9%
> 1MB RPCs 2.6ms 5.5ms 43ms 208ms
> 10KB RPCs 1.1ms 1.3ms 53ms 212ms
...
> v2: Removed call to tcp_ca_event from tcp_send_ack since I added one in
> tcp_event_ack_sent. Based on Neal Cardwell <ncardwell@google.com>
> feedback.
> Modified tcp_ecn_check_ce (and renamed it tcp_ecn_check) instead of modifying
> tcp_ack_send_check to insure an ACK when cwr is received.
> v3: Handling cwr in tcp_ecn_accept_cwr instead of in tcp_ecn_check.
>
> [PATCH net-next v3 1/2] tcp: notify when a delayed ack is sent
> [PATCH net-next v3 2/2] tcp: ack immediately when a cwr packet
Neal and co., what are your thoughts right now about this patch series?
Thank you.
^ permalink raw reply
* Re: [PATCH] net/mlx5: Use 2-factor allocator calls
From: David Miller @ 2018-07-07 11:15 UTC (permalink / raw)
To: keescook; +Cc: saeedm, tariqt, leon, vadimp, netdev, linux-kernel
In-Reply-To: <20180704172847.GA33621@beast>
From: Kees Cook <keescook@chromium.org>
Date: Wed, 4 Jul 2018 10:28:47 -0700
> This restores the use of 2-factor allocation helpers that were already
> fixed treewide. Please do not use open-coded multiplication; prefer,
> instead, using 2-factor allocation helpers.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Saeed and co., please review.
^ permalink raw reply
* Re: [PATCH net-next 0/4] vxlan: fix default fdb entry user-space notify ordering/race
From: David Miller @ 2018-07-07 11:23 UTC (permalink / raw)
To: roopa; +Cc: netdev, jbenc, mike.rapoport, stephen
In-Reply-To: <1530747992-15878-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Wed, 4 Jul 2018 16:46:28 -0700
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Problem:
> In vxlan_newlink, a default fdb entry is added before register_netdev.
> The default fdb creation function notifies user-space of the
> fdb entry on the vxlan device which user-space does not know about yet.
> (RTM_NEWNEIGH goes before RTM_NEWLINK for the same ifindex).
>
> This series fixes the user-space netlink notification ordering issue
> with the following changes:
> - decouple fdb notify from fdb create.
> - Move fdb notify after register_netdev.
> - modify rtnl_configure_link to allow configuring a link early.
> - Call rtnl_configure_link in vxlan newlink handler to notify
> userspace about the newlink before fdb notify and
> hence avoiding the user-space race.
>
> Fixes: afbd8bae9c79 ("vxlan: add implicit fdb entry for default destination")
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This is quite an old bug (circa v3.11). Maybe after this cooks for some
time in net-next you can also submit it for 'net' and we can thus send
it off to -stable as well?
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net 1/1] net/smc: reduce sock_put() for fallback sockets
From: David Miller @ 2018-07-07 11:25 UTC (permalink / raw)
To: ubraun
Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel, ebiggers3
In-Reply-To: <20180705141530.72728-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Thu, 5 Jul 2018 16:15:30 +0200
> smc_release() calls a sock_put() for smc fallback sockets to cover
> the passive closing sock_hold() in __smc_connect() and
> smc_tcp_listen_work(). This does not make sense for sockets in state
> SMC_LISTEN and SMC_INIT.
> An SMC socket stays in state SMC_INIT if connect fails. The sock_put
> in smc_connect_abort() does not cover all failures. Move it into
> smc_connect_decline_fallback().
>
> Fixes: ee9dfbef02d18 ("net/smc: handle sockopts forcing fallback")
> Reported-by: syzbot+3a0748c8f2f210c0ef9b@syzkaller.appspotmail.com
> Reported-by: syzbot+9e60d2428a42049a592a@syzkaller.appspotmail.com
> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] farsync: remove redundant variable txq_length
From: Colin King @ 2018-07-07 11:27 UTC (permalink / raw)
To: Kevin Curtis, David S . Miller, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable txq_length is being assigned but is never used hence it is
redundant and can be removed.
Cleans up clang warning:
warning: variable 'txq_length' set but not used [-Wunused-but-set-variable]
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wan/farsync.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index bd46b2552980..2a3f0f1a2b0a 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -2134,7 +2134,6 @@ static void
fst_openport(struct fst_port_info *port)
{
int signals;
- int txq_length;
/* Only init things if card is actually running. This allows open to
* succeed for downloads etc.
@@ -2161,7 +2160,6 @@ fst_openport(struct fst_port_info *port)
else
netif_carrier_off(port_to_dev(port));
- txq_length = port->txqe - port->txqs;
port->txqe = 0;
port->txqs = 0;
}
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox