* Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO
From: Andy Lutomirski @ 2018-09-01 3:39 UTC (permalink / raw)
To: Matt Rickard, Florian Weimer
Cc: Thomas Gleixner, Andy Lutomirski, Stephen Boyd, John Stultz,
X86 ML, LKML
In-Reply-To: <20180901015935.CCF0B18E20A9@virtux64.softrans.com.au>
[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]
(Hi, Florian!)
On Fri, Aug 31, 2018 at 6:59 PM, Matt Rickard <matt@softrans.com.au> wrote:
> Process clock_gettime(CLOCK_TAI) in vDSO.
> This makes the call about as fast as CLOCK_REALTIME and CLOCK_MONOTONIC:
>
> nanoseconds
> before after clockname
> ---- ----- ---------
> 233 87 CLOCK_TAI
> 96 93 CLOCK_REALTIME
> 88 87 CLOCK_MONOTONIC
Are you sure you did this right? With the clocksource set to TSC
(which is the only reasonable choice unless KVM has seriously cleaned
up its act), with retpolines enabled, I get 24ns for CLOCK_MONOTONIC
without your patch and 32ns with your patch. And there is indeed a
retpoline in the disassembled output:
e5: e8 07 00 00 00 callq f1 <__vdso_clock_gettime+0x31>
ea: f3 90 pause
ec: 0f ae e8 lfence
ef: eb f9 jmp ea <__vdso_clock_gettime+0x2a>
f1: 48 89 04 24 mov %rax,(%rsp)
f5: c3 retq
You're probably going to have to set -fno-jump-tables or do something
clever like adding a whole array of (seconds, nsec) in gtod and
indexing that array by the clock id.
Meanwhile, I wrote the following trivial patch to add a
__vdso_clock_gettime_monotonic export. It runs in 21ns, and I suspect
that the speedup is even a bit bigger when cache-cold because it
avoids some branches. What do you all think? Florian, do you think
glibc would be willing to add some magic to turn
clock_gettime(CLOCK_MONOTONIC, t) into
__vdso_clock_gettime_monotonic(t) when CLOCK_MONOTONIC is a constant?
[-- Attachment #2: vclock_gettime_monotonic.patch --]
[-- Type: text/x-patch, Size: 1107 bytes --]
diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c
index 91ed1bb2a3bb..4f22e9cb97a5 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -319,6 +319,14 @@ notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
int clock_gettime(clockid_t, struct timespec *)
__attribute__((weak, alias("__vdso_clock_gettime")));
+notrace int __vdso_clock_gettime_monotonic(struct timespec *ts)
+{
+ if (likely(do_monotonic(ts) != VCLOCK_NONE))
+ return 0;
+
+ return vdso_fallback_gettime(CLOCK_MONOTONIC, ts);
+}
+
notrace int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz)
{
if (likely(tv != NULL)) {
diff --git a/arch/x86/entry/vdso/vdso.lds.S b/arch/x86/entry/vdso/vdso.lds.S
index d3a2dce4cfa9..28e23cbc02c9 100644
--- a/arch/x86/entry/vdso/vdso.lds.S
+++ b/arch/x86/entry/vdso/vdso.lds.S
@@ -15,6 +15,11 @@
* This controls what userland symbols we export from the vDSO.
*/
VERSION {
+ LINUX_4.19 {
+ global:
+ __vdso_clock_gettime_monotonic;
+ };
+
LINUX_2.6 {
global:
clock_gettime;
^ permalink raw reply related
* [PATCH net-next] net: bgmac: remove set but not used variable 'err'
From: YueHaibing @ 2018-09-01 3:13 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Andrew Lunn, Colin Ian King
Cc: YueHaibing, netdev, linux-kernel, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/broadcom/bgmac.c: In function 'bgmac_dma_alloc':
drivers/net/ethernet/broadcom/bgmac.c:619:6: warning:
variable 'err' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/broadcom/bgmac.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 4c94d92..cabc8e4 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -616,7 +616,6 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
static const u16 ring_base[] = { BGMAC_DMA_BASE0, BGMAC_DMA_BASE1,
BGMAC_DMA_BASE2, BGMAC_DMA_BASE3, };
int size; /* ring size: different for Tx and Rx */
- int err;
int i;
BUILD_BUG_ON(BGMAC_MAX_TX_RINGS > ARRAY_SIZE(ring_base));
@@ -666,7 +665,6 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
if (!ring->cpu_base) {
dev_err(bgmac->dev, "Allocation of RX ring 0x%X failed\n",
ring->mmio_base);
- err = -ENOMEM;
goto err_dma_free;
}
^ permalink raw reply related
* Re: [PATCH 0/4] media: platform: Add Aspeed Video Engine driver
From: Stephen Boyd @ 2018-09-01 2:46 UTC (permalink / raw)
To: Eddie James, linux-kernel
Cc: linux-media, linux-aspeed, openbmc, andrew, mchehab, joel,
robh+dt, mark.rutland, devicetree, linux-clk, mturquette,
linux-arm-kernel
In-Reply-To: <a959a032-6817-dcb4-2c5f-b4bd17fc1c8b@linux.vnet.ibm.com>
Quoting Eddie James (2018-08-31 12:30:02)
>
>
> On 08/31/2018 12:56 PM, Stephen Boyd wrote:
> > Quoting Eddie James (2018-08-29 14:09:29)
> > Please let me know your merge strategy here. I can ack the clk patches
> > because they look fine from high-level clk driver perspective (maybe
> > Joel can take a closer look) or I can merge the patches into clk-next
> > and get them into next release while the video driver gets reviewed.
>
> Thanks for taking a look! Probably preferable to get the clk patches
> into clk-next first (though Joel reviewing would be great). I just put
> everything in the same set for the sake of explaining the necessity of
> the clk changes.
>
Ok. If Joel is able to review then I can easily merge it into clk-next.
^ permalink raw reply
* Re: [PATCH v5 1/2] clk: Add of_clk_get_by_name_optional() function
From: Stephen Boyd @ 2018-09-01 2:45 UTC (permalink / raw)
To: Andy Shevchenko, Michael Turquette, Phil Edworthy, Russell King
Cc: Geert Uytterhoeven, Simon Horman, linux-clk, linux-kernel,
linux-arm-kernel, Phil Edworthy
In-Reply-To: <1535724443-21150-2-git-send-email-phil.edworthy@renesas.com>
Quoting Phil Edworthy (2018-08-31 07:07:22)
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 9ab3db8..4adb99e 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -54,30 +54,29 @@ EXPORT_SYMBOL(of_clk_get);
>
> static struct clk *__of_clk_get_by_name(struct device_node *np,
> const char *dev_id,
> - const char *name)
> + const char *name,
> + bool optional)
> {
> struct clk *clk = ERR_PTR(-ENOENT);
> + struct device_node *child = np;
> + int index = 0;
>
> /* Walk up the tree of devices looking for a clock that matches */
> while (np) {
> - int index = 0;
>
> /*
> * For named clocks, first look up the name in the
> * "clock-names" property. If it cannot be found, then
> - * index will be an error code, and of_clk_get() will fail.
> + * index will be an error code.
> */
> if (name)
> index = of_property_match_string(np, "clock-names", name);
> - clk = __of_clk_get(np, index, dev_id, name);
> - if (!IS_ERR(clk)) {
> - break;
> - } else if (name && index >= 0) {
> - if (PTR_ERR(clk) != -EPROBE_DEFER)
> - pr_err("ERROR: could not get clock %pOF:%s(%i)\n",
> - np, name ? name : "", index);
> + if (index >= 0)
> + clk = __of_clk_get(np, index, dev_id, name);
> + if (!IS_ERR(clk))
Was this change necessary? It looks like we can leave it all alone and
keep passing a negative number to __of_clk_get() and have that return an
error pointer which we then return immediately as an error. But, if the
clock is optional and we've passed a name here, shouldn't we treat an
error from of_property_match_string() as success too? This is all
looking pretty fragile so maybe it can be better commented and also more
explicit instead of relying on the reader to jump through all the
function calls to figure out what the return value is in some cases.
> return clk;
> - }
> + if (name && index >= 0)
> + break;
And this causes us to duplicate logic down below because we have to
check it again if it's not optional or some other error condition?
>
> /*
> * No matching clock found on this node. If the parent node
> @@ -89,6 +88,16 @@ static struct clk *__of_clk_get_by_name(struct device_node *np,
> break;
> }
>
> + /* The clock is not valid, but it could be optional or deferred */
> + if (optional && PTR_ERR(clk) == -ENOENT) {
> + clk = NULL;
> + pr_info("no optional clock %pOF:%s\n", child,
> + name ? name : "");
Is this intentionally pr_info?
> + } else if (name && index >= 0 && PTR_ERR(clk) != -EPROBE_DEFER) {
> + pr_err("ERROR: could not get clock %pOF:%s(%i)\n",
> + child, name, index);
> + }
> +
> return clk;
> }
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-am65: Change #address-cells and #size-cells of interconnect to 2
From: Nishanth Menon @ 2018-09-01 2:44 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Tero Kristo, Rob Herring, Tony Lindgren, Mark Rutland,
Catalin Marinas, Will Deacon, linux-arm-kernel, devicetree,
linux-kernel, Santosh Shilimkar, nsekhar
In-Reply-To: <20180828102642.26482-1-kishon@ti.com>
On 15:56-20180828, Kishon Vijay Abraham I wrote:
[...]
> cbass_mcu: interconnect@28380000 {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> - ranges = <0x28380000 0x28380000 0x03880000>, /* MCU NAVSS*/
> - <0x40200000 0x40200000 0x00900100>, /* First peripheral window */
> - <0x42040000 0x42040000 0x03ac2400>, /* WKUP */
> - <0x45100000 0x45100000 0x00c24000>, /* MMRs, remaining NAVSS */
> - <0x46000000 0x46000000 0x00200000>, /* CPSW */
> - <0x47000000 0x47000000 0x00068400>; /* OSPI space 1 */
> + ranges = <0x28380000 0x00 0x28380000 0x03880000>, /* MCU NAVSS*/
> + <0x40200000 0x00 0x40200000 0x00900100>, /* First peripheral window */
> + <0x42040000 0x00 0x42040000 0x03ac2400>, /* WKUP */
> + <0x45100000 0x00 0x45100000 0x00c24000>, /* MMRs, remaining NAVSS */
> + <0x46000000 0x00 0x46000000 0x00200000>, /* CPSW */
> + <0x47000000 0x00 0x47000000 0x00068400>; /* OSPI space 1 */
>
You might need #address-cells and #size-cells as 2 in MCU as
well.. Could you refer to response from Vignesh?
https://marc.info/?l=linux-arm-kernel&m=153572924921895&w=2
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH 2/3] of/fdt: avoid re-parsing '#{address,size}-cells' in of_fdt_limit_memory
From: kbuild test robot @ 2018-09-01 2:41 UTC (permalink / raw)
To: Rob Herring; +Cc: kbuild-all, Frank Rowand, devicetree, linux-kernel
In-Reply-To: <20180830190523.31474-3-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]
Hi Rob,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.19-rc1 next-20180831]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rob-Herring/of-root-size-address-cells-clean-ups/20180831-160759
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
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 warnings (new ones prefixed by >>):
>> WARNING: vmlinux.o(.text+0x718907): Section mismatch in reference from the function of_fdt_limit_memory() to the variable .init.data:dt_root_addr_cells
The function of_fdt_limit_memory() references
the variable __initdata dt_root_addr_cells.
This is often because of_fdt_limit_memory lacks a __initdata
annotation or the annotation of dt_root_addr_cells is wrong.
--
>> WARNING: vmlinux.o(.text+0x718917): Section mismatch in reference from the function of_fdt_limit_memory() to the variable .init.data:dt_root_size_cells
The function of_fdt_limit_memory() references
the variable __initdata dt_root_size_cells.
This is often because of_fdt_limit_memory lacks a __initdata
annotation or the annotation of dt_root_size_cells is wrong.
---
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: 65138 bytes --]
^ permalink raw reply
* Re: REGRESSION: boot stalls on several old dual core Intel CPUs
From: Kevin Shanahan @ 2018-09-01 2:21 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Siegfried Metz, linux-kernel, tglx, rafael.j.wysocki, len.brown,
rjw, diego.viola, rui.zhang, viktor_jaegerskuepper
In-Reply-To: <20180830130439.GM24082@hirez.programming.kicks-ass.net>
On Thu, Aug 30, 2018 at 03:04:39PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 12:55:30PM +0200, Siegfried Metz wrote:
> > Dear kernel developers,
> >
> > since mainline kernel 4.18 (up to the latest mainline kernel 4.18.5)
> > Intel Core 2 Duo processors are affected by boot stalling early in the
> > boot process. As it is so early there is no dmesg output (or any log).
> >
> > A few users in the Arch Linux community used git bisect and tracked the
> > issue down to this the bad commit:
> > 7197e77abcb65a71d0b21d67beb24f153a96055e clocksource: Remove kthread
>
> I just dug out my core2duo laptop (Lenovo T500) and build a tip/master
> kernel for it (x86_64 debian distro .config).
>
> Seems to boot just fine.. 3/3 so far.
>
> Any other clues?
One additional data point, my affected system is a Dell Latitude E6400
laptop which has a P8400 CPU:
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz
stepping : 6
microcode : 0x610
Judging from what is being discussed in the Arch forums, it does seem
to related to the CPU having unstable TSC and transitioning to another
clock source. Workarounds that seem to be reliable are either booting
with clocksource=<something_not_tsc> or with nosmp.
One person did point out that the commit that introduced the kthread
did so to remove a deadlock - is the circular locking dependency
mentioned in that commit still relevant?
commit 01548f4d3e8e94caf323a4f664eb347fd34a34ab
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Tue Aug 18 17:09:42 2009 +0200
clocksource: Avoid clocksource watchdog circular locking dependency
stop_machine from a multithreaded workqueue is not allowed because
of a circular locking dependency between cpu_down and the workqueue
execution. Use a kernel thread to do the clocksource downgrade.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: john stultz <johnstul@us.ibm.com>
LKML-Reference: <20090818170942.3ab80c91@skybase>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Thanks,
Kevin.
^ permalink raw reply
* [GIT PULL] clk fixes for v4.19-rc1
From: sboyd @ 2018-09-01 2:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen Boyd, Michael Turquette, linux-clk, linux-kernel
From: Stephen Boyd <sboyd@kernel.org>
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-fixes-for-linus
for you to fetch changes up to bded6c03e398dc6e862dc8301fb9a60175740653:
clk: x86: Set default parent to 48Mhz (2018-08-30 14:47:41 -0700)
----------------------------------------------------------------
Two small fixes, one for the x86 Stoney SoC to get a more accurate clk
frequency and the other to fix a bad allocation in the Nuvoton NPCM7XX
driver.
----------------------------------------------------------------
Akshu Agrawal (1):
clk: x86: Set default parent to 48Mhz
Gustavo A. R. Silva (1):
clk: npcm7xx: fix memory allocation
drivers/clk/clk-npcm7xx.c | 4 ++--
drivers/clk/x86/clk-st.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
Sent by a computer through tubes
^ permalink raw reply
* [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO
From: Matt Rickard @ 2018-09-01 1:59 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Andy Lutomirski, Stephen Boyd, John Stultz, X86 ML, LKML
Process clock_gettime(CLOCK_TAI) in vDSO.
This makes the call about as fast as CLOCK_REALTIME and CLOCK_MONOTONIC:
nanoseconds
before after clockname
---- ----- ---------
233 87 CLOCK_TAI
96 93 CLOCK_REALTIME
88 87 CLOCK_MONOTONIC
Signed-off-by: Matt Rickard <matt@softrans.com.au>
---
arch/x86/entry/vdso/vclock_gettime.c | 25 +++++++++++++++++++++++++
arch/x86/entry/vsyscall/vsyscall_gtod.c | 2 ++
arch/x86/include/asm/vgtod.h | 1 +
3 files changed, 28 insertions(+)
diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c
index f19856d95c60..91ed1bb2a3bb 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -246,6 +246,27 @@ notrace static int __always_inline do_monotonic(struct timespec *ts)
return mode;
}
+notrace static int __always_inline do_tai(struct timespec *ts)
+{
+ unsigned long seq;
+ u64 ns;
+ int mode;
+
+ do {
+ seq = gtod_read_begin(gtod);
+ mode = gtod->vclock_mode;
+ ts->tv_sec = gtod->tai_time_sec;
+ ns = gtod->wall_time_snsec;
+ ns += vgetsns(&mode);
+ ns >>= gtod->shift;
+ } while (unlikely(gtod_read_retry(gtod, seq)));
+
+ ts->tv_sec += __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
+ ts->tv_nsec = ns;
+
+ return mode;
+}
+
notrace static void do_realtime_coarse(struct timespec *ts)
{
unsigned long seq;
@@ -277,6 +298,10 @@ notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
if (do_monotonic(ts) == VCLOCK_NONE)
goto fallback;
break;
+ case CLOCK_TAI:
+ if (do_tai(ts) == VCLOCK_NONE)
+ goto fallback;
+ break;
case CLOCK_REALTIME_COARSE:
do_realtime_coarse(ts);
break;
diff --git a/arch/x86/entry/vsyscall/vsyscall_gtod.c b/arch/x86/entry/vsyscall/vsyscall_gtod.c
index e1216dd95c04..d61392fe17f6 100644
--- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
+++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
@@ -53,6 +53,8 @@ void update_vsyscall(struct timekeeper *tk)
vdata->monotonic_time_snsec = tk->tkr_mono.xtime_nsec
+ ((u64)tk->wall_to_monotonic.tv_nsec
<< tk->tkr_mono.shift);
+ vdata->tai_time_sec = tk->xtime_sec
+ + tk->tai_offset;
while (vdata->monotonic_time_snsec >=
(((u64)NSEC_PER_SEC) << tk->tkr_mono.shift)) {
vdata->monotonic_time_snsec -=
diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index fb856c9f0449..adc9f7b20b9c 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -32,6 +32,7 @@ struct vsyscall_gtod_data {
gtod_long_t wall_time_coarse_nsec;
gtod_long_t monotonic_time_coarse_sec;
gtod_long_t monotonic_time_coarse_nsec;
+ gtod_long_t tai_time_sec;
int tz_minuteswest;
int tz_dsttime;
^ permalink raw reply related
* Re: [PATCH net-next 0/5] rtnetlink: add IFA_IF_NETNSID for RTM_GETADDR
From: Christian Brauner @ 2018-09-01 1:34 UTC (permalink / raw)
To: Kirill Tkhai
Cc: netdev, linux-kernel, davem, kuznet, yoshfuji, pombredanne,
kstewart, gregkh, dsahern, fw, lucien.xin, jakub.kicinski, jbenc,
nicolas.dichtel
In-Reply-To: <20180830144544.tpross4jd6awou4u@gmail.com>
On Thu, Aug 30, 2018 at 04:45:45PM +0200, Christian Brauner wrote:
> On Thu, Aug 30, 2018 at 11:49:31AM +0300, Kirill Tkhai wrote:
> > On 29.08.2018 21:13, Christian Brauner wrote:
> > > Hi Kirill,
> > >
> > > Thanks for the question!
> > >
> > > On Wed, Aug 29, 2018 at 11:30:37AM +0300, Kirill Tkhai wrote:
> > >> Hi, Christian,
> > >>
> > >> On 29.08.2018 02:18, Christian Brauner wrote:
> > >>> From: Christian Brauner <christian@brauner.io>
> > >>>
> > >>> Hey,
> > >>>
> > >>> A while back we introduced and enabled IFLA_IF_NETNSID in
> > >>> RTM_{DEL,GET,NEW}LINK requests (cf. [1], [2], [3], [4], [5]). This has led
> > >>> to signficant performance increases since it allows userspace to avoid
> > >>> taking the hit of a setns(netns_fd, CLONE_NEWNET), then getting the
> > >>> interfaces from the netns associated with the netns_fd. Especially when a
> > >>> lot of network namespaces are in use, using setns() becomes increasingly
> > >>> problematic when performance matters.
> > >>
> > >> could you please give a real example, when setns()+socket(AF_NETLINK) cause
> > >> problems with the performance? You should do this only once on application
> > >> startup, and then you have created netlink sockets in any net namespaces you
> > >> need. What is the problem here?
> > >
> > > So we have a daemon (LXD) that is often running thousands of containers.
> > > When users issue a lxc list request against the daemon it returns a list
> > > of all containers including all of the interfaces and addresses for each
> > > container. To retrieve those addresses we currently rely on setns() +
> > > getifaddrs() for each of those containers. That has horrible
> > > performance.
> >
> > Could you please provide some numbers showing that setns()
> > introduces signify performance decrease in the application?
>
> Sure, might take a few days++ though since I'm traveling.
Hey Kirill,
As promised here's some code [1] that compares performance. I basically
did a setns() to the network namespace and called getifaddrs() and
compared this to the scenario where I use the newly introduced property.
I did this 1 million times and calculated the mean getifaddrs()
retrieval time based on that.
My patch cuts the time in half.
brauner@wittgenstein:~/netns_getifaddrs$ ./getifaddrs_perf 0 1178
Mean time in microseconds (netnsid): 81
Mean time in microseconds (setns): 162
Christian
I'm only appending the main file since the netsns_getifaddrs() code I
used is pretty long:
[1]:
#define _GNU_SOURCE
#define __STDC_FORMAT_MACROS
#include <fcntl.h>
#include <inttypes.h>
#include <linux/types.h>
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#include "netns_getifaddrs.h"
#include "print_getifaddrs.h"
#define ITERATIONS 1000000
#define SEC_TO_MICROSEC(x) (1000000 * (x))
int main(int argc, char *argv[])
{
int i, ret;
__s32 netns_id;
pid_t netns_pid;
char path[1024];
intmax_t times[ITERATIONS];
struct timeval t1, t2;
intmax_t time_in_mcs;
int fret = EXIT_FAILURE;
intmax_t sum = 0;
int host_netns_fd = -1, netns_fd = -1;
struct ifaddrs *ifaddrs = NULL;
if (argc != 3)
goto on_error;
netns_id = atoi(argv[1]);
netns_pid = atoi(argv[2]);
printf("%d\n", netns_id);
printf("%d\n", netns_pid);
for (i = 0; i < ITERATIONS; i++) {
ret = gettimeofday(&t1, NULL);
if (ret < 0)
goto on_error;
ret = netns_getifaddrs(&ifaddrs, netns_id);
freeifaddrs(ifaddrs);
if (ret < 0)
goto on_error;
ret = gettimeofday(&t2, NULL);
if (ret < 0)
goto on_error;
time_in_mcs = (SEC_TO_MICROSEC(t2.tv_sec) + t2.tv_usec) -
(SEC_TO_MICROSEC(t1.tv_sec) + t1.tv_usec);
times[i] = time_in_mcs;
}
for (i = 0; i < ITERATIONS; i++)
sum += times[i];
printf("Mean time in microseconds (netnsid): %ju\n",
sum / ITERATIONS);
ret = snprintf(path, sizeof(path), "/proc/%d/ns/net", netns_pid);
if (ret < 0 || (size_t)ret >= sizeof(path))
goto on_error;
netns_fd = open(path, O_RDONLY | O_CLOEXEC);
if (netns_fd < 0)
goto on_error;
host_netns_fd = open("/proc/self/ns/net", O_RDONLY | O_CLOEXEC);
if (host_netns_fd < 0)
goto on_error;
memset(times, 0, sizeof(times));
for (i = 0; i < ITERATIONS; i++) {
ret = gettimeofday(&t1, NULL);
if (ret < 0)
goto on_error;
ret = setns(netns_fd, CLONE_NEWNET);
if (ret < 0)
goto on_error;
ret = getifaddrs(&ifaddrs);
freeifaddrs(ifaddrs);
if (ret < 0)
goto on_error;
ret = gettimeofday(&t2, NULL);
if (ret < 0)
goto on_error;
ret = setns(host_netns_fd, CLONE_NEWNET);
if (ret < 0)
goto on_error;
time_in_mcs = (SEC_TO_MICROSEC(t2.tv_sec) + t2.tv_usec) -
(SEC_TO_MICROSEC(t1.tv_sec) + t1.tv_usec);
times[i] = time_in_mcs;
}
for (i = 0; i < ITERATIONS; i++)
sum += times[i];
printf("Mean time in microseconds (setns): %ju\n",
sum / ITERATIONS);
fret = EXIT_SUCCESS;
on_error:
if (netns_fd >= 0)
close(netns_fd);
if (host_netns_fd >= 0)
close(host_netns_fd);
exit(fret);
}
>
> >
> > I worry about all this just because of netlink interface is
> > already overloaded, while this patch makes it even less modular.
>
> Introducing the IFA_IF_NETNSID property will not make the netlink
> interface less modular. It is a clean, RTM_*ADDR-request specific
> property using network namespace identifiers which we discussed in prior
> patches are the way to go forward.
>
> You can already get interfaces via GETLINK from another network
> namespaces than the one you reside in (Which we enabled just a few
> months back.) but you can't do the same for GETADDR. Those two are
> almost always used together. When you want to get the links you usually
> also want to get the addresses associated with it right after.
> In a prior discussion we agreed that network namespace identifiers are
> the way to go forward but that any other propery, i.e. PIDs and fds
> should never be ported into other parts of the codebase and that is
> indeed something I agree with.
>
> > In case of one day we finally reach rtnl unscalability trap,
> > every common interface like this may be a decisive nail in
> > a coffin lid of possibility to overwrite everything.
> >
> > > The problem with what you're proposing is that the daemon would need to
> > > cache a socket file descriptor for each container which is something
> > > that we unfortunately cannot do since we can't excessively cache file
> > > descriptors because we can easily hit the open file limit. We also
> > > refrain from caching file descriptors for a long time for security
> > > reasons.
> > >
> > > For the case where users just request a list of the interfaces we
> > > can already use RTM_GETLINK + IFLA_IF_NETNS which has way better
> > > performance. But we can't do the same with RTM_GETADDR requests which
> > > was an oversight on my part when I wrote the original patchset for the
> > > RTM_*LINK requests. This just rectifies this and aligns RTM_GETLINK +
> > > RTM_GETADDR.
> > > Based on this patchset I have written a userspace POC that is basically
> > > a netns namespace aware getifaddr() or - as I like to call it -
> > > netns_getifaddr().
> > >
> > >>
> > >>> Usually, RTML_GETLINK requests are followed by RTM_GETADDR requests (cf.
> > >>> getifaddrs() style functions and friends). But currently, RTM_GETADDR
> > >>> requests do not support a similar property like IFLA_IF_NETNSID for
> > >>> RTM_*LINK requests.
> > >>> This is problematic since userspace can retrieve interfaces from another
> > >>> network namespace by sending a IFLA_IF_NETNSID property along but
> > >>> RTM_GETLINK request but is still forced to use the legacy setns() style of
> > >>> retrieving interfaces in RTM_GETADDR requests.
> > >>>
> > >>> The goal of this series is to make it possible to perform RTM_GETADDR
> > >>> requests on different network namespaces. To this end a new IFA_IF_NETNSID
> > >>> property for RTM_*ADDR requests is introduced. It can be used to send a
> > >>> network namespace identifier along in RTM_*ADDR requests. The network
> > >>> namespace identifier will be used to retrieve the target network namespace
> > >>> in which the request is supposed to be fulfilled. This aligns the behavior
> > >>> of RTM_*ADDR requests with the behavior of RTM_*LINK requests.
> > >>>
> > >>> Security:
> > >>> - The caller must have assigned a valid network namespace identifier for
> > >>> the target network namespace.
> > >>> - The caller must have CAP_NET_ADMIN in the owning user namespace of the
> > >>> target network namespace.
> > >>>
> > >>> Thanks!
> > >>> Christian
> > >>>
> > >>> [1]: commit 7973bfd8758d ("rtnetlink: remove check for IFLA_IF_NETNSID")
> > >>> [2]: commit 5bb8ed075428 ("rtnetlink: enable IFLA_IF_NETNSID for RTM_NEWLINK")
> > >>> [3]: commit b61ad68a9fe8 ("rtnetlink: enable IFLA_IF_NETNSID for RTM_DELLINK")
> > >>> [4]: commit c310bfcb6e1b ("rtnetlink: enable IFLA_IF_NETNSID for RTM_SETLINK")
> > >>> [5]: commit 7c4f63ba8243 ("rtnetlink: enable IFLA_IF_NETNSID in do_setlink()")
> > >>>
> > >>> Christian Brauner (5):
> > >>> rtnetlink: add rtnl_get_net_ns_capable()
> > >>> if_addr: add IFA_IF_NETNSID
> > >>> ipv4: enable IFA_IF_NETNSID for RTM_GETADDR
> > >>> ipv6: enable IFA_IF_NETNSID for RTM_GETADDR
> > >>> rtnetlink: move type calculation out of loop
> > >>>
> > >>> include/net/rtnetlink.h | 1 +
> > >>> include/uapi/linux/if_addr.h | 1 +
> > >>> net/core/rtnetlink.c | 15 +++++---
> > >>> net/ipv4/devinet.c | 38 +++++++++++++++-----
> > >>> net/ipv6/addrconf.c | 70 ++++++++++++++++++++++++++++--------
> > >>> 5 files changed, 97 insertions(+), 28 deletions(-)
> > >>>
^ permalink raw reply
* Re: [PATCH] mm: slowly shrink slabs with a relatively small number of objects
From: Rik van Riel @ 2018-09-01 1:27 UTC (permalink / raw)
To: Roman Gushchin
Cc: linux-mm, linux-kernel, kernel-team, Josef Bacik, Johannes Weiner,
Andrew Morton
In-Reply-To: <20180831213138.GA9159@tower.DHCP.thefacebook.com>
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
On Fri, 2018-08-31 at 14:31 -0700, Roman Gushchin wrote:
> On Fri, Aug 31, 2018 at 05:15:39PM -0400, Rik van Riel wrote:
> > On Fri, 2018-08-31 at 13:34 -0700, Roman Gushchin wrote:
> >
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index fa2c150ab7b9..c910cf6bf606 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -476,6 +476,10 @@ static unsigned long do_shrink_slab(struct
> > > shrink_control *shrinkctl,
> > > delta = freeable >> priority;
> > > delta *= 4;
> > > do_div(delta, shrinker->seeks);
> > > +
> > > + if (delta == 0 && freeable > 0)
> > > + delta = min(freeable, batch_size);
> > > +
> > > total_scan += delta;
> > > if (total_scan < 0) {
> > > pr_err("shrink_slab: %pF negative objects to delete
> > > nr=%ld\n",
> >
> > I agree that we need to shrink slabs with fewer than
> > 4096 objects, but do we want to put more pressure on
> > a slab the moment it drops below 4096 than we applied
> > when it had just over 4096 objects on it?
> >
> > With this patch, a slab with 5000 objects on it will
> > get 1 item scanned, while a slab with 4000 objects on
> > it will see shrinker->batch or SHRINK_BATCH objects
> > scanned every time.
> >
> > I don't know if this would cause any issues, just
> > something to ponder.
>
> Hm, fair enough. So, basically we can always do
>
> delta = max(delta, min(freeable, batch_size));
>
> Does it look better?
Yeah, that looks fine to me.
That will read to small cgroups having small caches
reclaimed relatively more quickly than large caches
getting reclaimed, but small caches should also be
faster to refill once they are needed again, so it
is probably fine.
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next] ipv6:sr: Use the right next-hop value for neighbor discovery in End.DX4
From: David Miller @ 2018-09-01 0:46 UTC (permalink / raw)
To: amsalam20; +Cc: dlebrun, netdev, linux-kernel
In-Reply-To: <20180825141541.960-1-amsalam20@gmail.com>
From: Ahmed Abdelsalam <amsalam20@gmail.com>
Date: Sat, 25 Aug 2018 16:15:41 +0200
> This patch makes sure that "rt_gateway" has the value of
> the next-hop configured from the control plane.
You can't change the rt_gateway field of an existing route,
this will change the value for unrelated users trying to
reach the same destination.
^ permalink raw reply
* Re: [PATCH net-next 0/5] rtnetlink: add IFA_IF_NETNSID for RTM_GETADDR
From: David Miller @ 2018-09-01 0:58 UTC (permalink / raw)
To: nicolas.dichtel
Cc: christian.brauner, ktkhai, netdev, linux-kernel, kuznet, yoshfuji,
pombredanne, kstewart, gregkh, dsahern, fw, lucien.xin,
jakub.kicinski, jbenc
In-Reply-To: <ba6a1b18-959e-e307-45fa-e0da9d6f0b0f@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 30 Aug 2018 17:49:12 +0200
> Maybe I would choose a more generic name for the attribute,
> something that can be used in other netlink families (xfrm,
> netfilter, ...) also. What about IFA_TARGET_NSID?
Agreed, let's at least try to think ahead about potential future
uses :)
^ permalink raw reply
* Re: [PATCH net-next] rds: store socket timestamps as ktime_t
From: David Miller @ 2018-09-01 1:04 UTC (permalink / raw)
To: arnd
Cc: santosh.shilimkar, sowmini.varadhan, willemb, ka-cheong.poon,
s.mesoraca16, avinash.repaka, edumazet, netdev, linux-rdma,
rds-devel, linux-kernel
In-Reply-To: <20180829154732.844217-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 29 Aug 2018 17:47:19 +0200
> rds is the last in-kernel user of the old do_gettimeofday()
> function. Convert it over to ktime_get_real() to make it
> work more like the generic socket timestamps, and to let
> us kill off do_gettimeofday().
>
> A follow-up patch will have to change the user space interface
> to deal better with 32-bit tasks, which may use an incompatible
> layout for 'struct timespec'.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 00/15] blkcg ref count refactor/cleanup + blkcg avg_lat
From: Tejun Heo @ 2018-09-01 0:35 UTC (permalink / raw)
To: Dennis Zhou
Cc: Jens Axboe, Johannes Weiner, Josef Bacik, kernel-team,
linux-block, cgroups, linux-kernel
In-Reply-To: <20180831015356.69796-1-dennisszhou@gmail.com>
Hello,
On Thu, Aug 30, 2018 at 09:53:41PM -0400, Dennis Zhou wrote:
> This is a fairly lengthy patchset that aims to cleanup reference
> counting for blkcgs and blkgs. There are 4 problems that this patchset
> tries to address:
> 1. fix blkcg destruction
> 2. always associate a bio with a blkg
> 3. remove the extra css ref held by bios and utilize the blkg ref
> 4. add average latency tracking to blkcg core in io.stat.
1 is already merged. Reviewed 2, 3 parts. Generally looks great.
Let's try to address the found issues and get these two parts merged
first.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 14/15] blkcg: rename blkg_try_get to blkg_tryget
From: Tejun Heo @ 2018-09-01 0:32 UTC (permalink / raw)
To: Dennis Zhou
Cc: Jens Axboe, Johannes Weiner, Josef Bacik, kernel-team,
linux-block, cgroups, linux-kernel
In-Reply-To: <20180831015356.69796-15-dennisszhou@gmail.com>
On Thu, Aug 30, 2018 at 09:53:55PM -0400, Dennis Zhou wrote:
> From: "Dennis Zhou (Facebook)" <dennisszhou@gmail.com>
>
> blkg reference counting now uses percpu_ref rather than atomic_t. Let's
> make this consistent with css_tryget. This renames blkg_try_get to
> blkg_tryget and now returns a bool rather than the blkg or NULL.
>
> Signed-off-by: Dennis Zhou <dennisszhou@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 13/15] blkcg: change blkg reference counting to use percpu_ref
From: Tejun Heo @ 2018-09-01 0:31 UTC (permalink / raw)
To: Dennis Zhou
Cc: Jens Axboe, Johannes Weiner, Josef Bacik, kernel-team,
linux-block, cgroups, linux-kernel
In-Reply-To: <20180831015356.69796-14-dennisszhou@gmail.com>
Hello,
On Thu, Aug 30, 2018 at 09:53:54PM -0400, Dennis Zhou wrote:
> @@ -217,6 +240,10 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
> blkg_get(blkg->parent);
> }
>
> + ret = percpu_ref_init(&blkg->refcnt, __blkg_release, 0, GFP_KERNEL);
So, while this would work in some configs, you can't depend on RCU
grace period inside percpu_ref. blkg is now percpu-reference counted
and rcu protected object - it has to explicitly go through a rcu grace
period before release.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 12/15] blkcg: cleanup and make blk_get_rl use blkg_lookup_create
From: Tejun Heo @ 2018-09-01 0:29 UTC (permalink / raw)
To: Dennis Zhou
Cc: Jens Axboe, Johannes Weiner, Josef Bacik, kernel-team,
linux-block, cgroups, linux-kernel
In-Reply-To: <20180831015356.69796-13-dennisszhou@gmail.com>
On Thu, Aug 30, 2018 at 09:53:53PM -0400, Dennis Zhou wrote:
> From: "Dennis Zhou (Facebook)" <dennisszhou@gmail.com>
>
> blk_get_rl is responsible for identifying which request_list a request
> should be allocated to. Try get logic was added earlier, but
> semantically the logic was not changed.
>
> This patch makes better use of the bio already having a reference to the
> blkg in the hot path. The cold path uses a better fallback of
> blkg_lookup_create rather than just blkg_lookup and then falling back to
> the q->root_rl. If lookup_create fails with anything but -ENODEV, it
> falls back to q->root_rl.
>
> A clarifying comment is added to explain why q->root_rl is used rather
> than the root blkg's rl.
>
> Signed-off-by: Dennis Zhou <dennisszhou@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
We're replicating that retry busy loop a lot. It'd be really great to
factor that out and document what it's doing.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 11/15] blkcg: remove additional reference to the css
From: Tejun Heo @ 2018-09-01 0:26 UTC (permalink / raw)
To: Dennis Zhou
Cc: Jens Axboe, Johannes Weiner, Josef Bacik, kernel-team,
linux-block, cgroups, linux-kernel
In-Reply-To: <20180831015356.69796-12-dennisszhou@gmail.com>
Hello,
On Thu, Aug 30, 2018 at 09:53:52PM -0400, Dennis Zhou wrote:
> - css = cgroup_get_e_css(page->mem_cgroup->css.cgroup, &io_cgrp_subsys);
>
> - return __bio_associate_blkg_from_css(bio, css);
> + rcu_read_lock();
> +
> + while (true) {
> + css = cgroup_e_css(page->mem_cgroup->css.cgroup,
> + &io_cgrp_subsys);
So, while they seem similar cgroup_e_css() and cgroup_get_e_css()
behave very differently in terms of locking. cgroup_e_css() can only
be used under cgroup_mutex because it is used during migration and has
to test cgroup_ss_mask(). The right thing to do here would be
renaming cgroup_e_css() to something else and add a new implementation
which operates in the same way as cgroup_get_e_css().
BTW, this should have triggered lockdep warning. I'd strongly
recommend testing with lockdep enabled.
Other than that, looks good to me.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v6 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array
From: Peter Rosin @ 2018-09-01 0:23 UTC (permalink / raw)
To: Janusz Krzysztofik, Linus Walleij
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Ulf Hansson, Andrew Lunn, Florian Fainelli, David S. Miller,
Dominik Brodowski, Greg Kroah-Hartman, Kishon Vijay Abraham I,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald-Stadler, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven, linux-doc, linux-i2c, linux-mmc, netdev,
linux-iio, devel, linux-serial, linux-gpio, linux-kernel
In-Reply-To: <20180831225616.29221-2-jmkrzyszt@gmail.com>
On 2018-09-01 00:56, Janusz Krzysztofik wrote:
> Most users of get/set array functions iterate consecutive bits of data,
> usually a single integer, while processing array of results obtained
> from, or building an array of values to be passed to those functions.
> Save time wasted on those iterations by changing the functions' API to
> accept bitmaps.
>
> All current users are updated as well.
>
> More benefits from the change are expected as soon as planned support
> for accepting/passing those bitmaps directly from/to respective GPIO
> chip callbacks if applicable is implemented.
> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
> index 401308e3d036..e28ddc20000d 100644
> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> @@ -22,18 +22,16 @@ struct gpiomux {
> struct i2c_mux_gpio_platform_data data;
> unsigned gpio_base;
> struct gpio_desc **gpios;
> - int *values;
> };
>
> static void i2c_mux_gpio_set(const struct gpiomux *mux, unsigned val)
> {
> - int i;
> -
> - for (i = 0; i < mux->data.n_gpios; i++)
> - mux->values[i] = (val >> i) & 1;
> + DECLARE_BITMAP(value_bitmap, mux->data.n_gpios);
Picking a random driver for this comment, it applies to many of them.
I think this creates a VLA? Can't you, for the bit-count, just go with
BITS_PER_TYPE(unsigned)? Or whatever is appropriate for the driver
in question.
Also, I find that where you use DECLARE_BITMAP, the _bitmap suffix is
just noise and I would very much like to zap it.
Cheers,
Peter
> +
> + *value_bitmap = val;
>
> gpiod_set_array_value_cansleep(mux->data.n_gpios,
> - mux->gpios, mux->values);
> + mux->gpios, value_bitmap);
> }
>
> static int i2c_mux_gpio_select(struct i2c_mux_core *muxc, u32 chan)
> @@ -182,15 +180,13 @@ static int i2c_mux_gpio_probe(struct platform_device *pdev)
> return -EPROBE_DEFER;
>
> muxc = i2c_mux_alloc(parent, &pdev->dev, mux->data.n_values,
> - mux->data.n_gpios * sizeof(*mux->gpios) +
> - mux->data.n_gpios * sizeof(*mux->values), 0,
> + mux->data.n_gpios * sizeof(*mux->gpios), 0,
> i2c_mux_gpio_select, NULL);
> if (!muxc) {
> ret = -ENOMEM;
> goto alloc_failed;
> }
> mux->gpios = muxc->priv;
> - mux->values = (int *)(mux->gpios + mux->data.n_gpios);
> muxc->priv = mux;
>
> platform_set_drvdata(pdev, muxc);
^ permalink raw reply
* Re: [PATCH 10/15] blkcg: remove bio->bi_css and instead use bio->bi_blkg
From: Tejun Heo @ 2018-09-01 0:13 UTC (permalink / raw)
To: Dennis Zhou
Cc: Jens Axboe, Johannes Weiner, Josef Bacik, kernel-team,
linux-block, cgroups, linux-kernel
In-Reply-To: <20180831015356.69796-11-dennisszhou@gmail.com>
On Thu, Aug 30, 2018 at 09:53:51PM -0400, Dennis Zhou wrote:
> From: "Dennis Zhou (Facebook)" <dennisszhou@gmail.com>
>
> Prior patches ensured that all bios are now associated with some blkg.
> This now makes bio->bi_css unnecessary as blkg maintains a reference to
> the blkcg already.
>
> This patch removes the field bi_css and transfers corresponding uses to
> access via bi_blkg.
>
> Signed-off-by: Dennis Zhou <dennisszhou@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commit in the bpf-next tree
From: Daniel Borkmann @ 2018-09-01 0:06 UTC (permalink / raw)
To: Stephen Rothwell, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20180901050751.3714fc63@canb.auug.org.au>
On 08/31/2018 09:07 PM, Stephen Rothwell wrote:
> Hi all,
>
> Commits
>
> 0f93c3995c93 ("bpf: add TCP_SAVE_SYN/TCP_SAVED_SYN sample program")
> 9452048c7940 ("bpf: add TCP_SAVE_SYN/TCP_SAVED_SYN options for bpf_(set|get)sockopt")
> 175eba5962b4 ("xdp: remove redundant variable 'headroom'")
>
> are missing a Signed-off-by from their committers.
Fixed up, thanks!
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: qcom: Add SPMI PMIC Arbiter nodes for APQ8084 and MSM8974
From: Frank Rowand @ 2018-09-01 0:05 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Ivan T. Ivanov, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Russell King, devicetree, linux-kernel,
linux-arm-kernel, linux-arm-msm
In-Reply-To: <20180831230125.GU2523@minitux>
On 08/31/18 16:01, Bjorn Andersson wrote:
> On Fri 31 Aug 15:46 PDT 2018, Frank Rowand wrote:
>>> + spmi_bus: spmi@fc4cf000 {
>>> + compatible = "qcom,spmi-pmic-arb";
>>> + reg-names = "core", "intr", "cnfg";
>>> + reg = <0xfc4cf000 0x1000>,
>>> + <0xfc4cb000 0x1000>,
>>> + <0xfc4ca000 0x1000>;
>>> + interrupt-names = "periph_irq";
>>
>>> + interrupts = <0 190 0>;
>>
>> The final value in this interrupts property means IRQ_TYPE_NONE.
>>
>> A WARN_ON() was added early this year to complain about use of
>> IRQ_TYPE_NONE: 83a86fbb5b56 "irqchip/gic: Loudly complain about
>> the use of IRQ_TYPE_NONE", resulting in many warnings spewing
>> forth when I boot an APQ8074 Dragonboard. I am trying to
>> determine whether the warning is overly aggressive, or whether
>> the IRQ TYPE is incorrectly specified for the spmi node.
>>
>> The interrupt-parent for the spmi node is intc: interrupt-controller@f9000000,
>> which has compatible = "qcom,msm-qgic2". I do not know the architecture
>> or implementation of this interrupt controller. Is an IRQ_TYPE_NONE
>> valid in this case, or should a specific type be provided?
>>
>
> No, IRQ_TYPE_NONE isn't valid and the WARN_ON() is reasonable.
>
> Please change it to IRQ_TYPE_LEVEL_HIGH. And while you're at it, replace
> the first 0 with GIC_SPI.
>
>
> If you have more of these warnings you can most likely look at e.g.
> msm8916 (arm64) to find the right flags.
Thanks, I'll create a patch.
^ permalink raw reply
* Re: [PATCH 09/15] blkcg: associate writeback bios with a blkg
From: Tejun Heo @ 2018-08-31 23:53 UTC (permalink / raw)
To: Dennis Zhou
Cc: Jens Axboe, Johannes Weiner, Josef Bacik, kernel-team,
linux-block, cgroups, linux-kernel
In-Reply-To: <20180831015356.69796-10-dennisszhou@gmail.com>
On Thu, Aug 30, 2018 at 09:53:50PM -0400, Dennis Zhou wrote:
> From: "Dennis Zhou (Facebook)" <dennisszhou@gmail.com>
>
> One of the goals of this series is to remove a separate reference to
> the css of the bio. This can and should be accessed via bio_blkcg. In
> this patch, the wbc_init_bio call is changed such that it must be called
> after a queue has been associated with the bio.
>
> Signed-off-by: Dennis Zhou <dennisszhou@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 0/4] of: Convert to using %pOFn for node name printf
From: Frank Rowand @ 2018-08-31 23:51 UTC (permalink / raw)
To: Rob Herring, devicetree; +Cc: linux-kernel
In-Reply-To: <20180828155254.10709-1-robh@kernel.org>
On 08/28/18 08:52, Rob Herring wrote:
> This is the DT portion of converting node name printf's to use the
> %pOFn format specifier rather than device_node.name. Patches for other
> subsystems are independent and have been sent separately.
>
> Rob
>
> Rob Herring (4):
> of/unittest: remove use of node name pointer in overlay high level
> test
> of/unittest: add printf tests for node name
> of: Convert to using %pOFn instead of device_node.name
> vsprintf: print OF node name using full_name
>
> drivers/of/device.c | 4 ++--
> drivers/of/of_mdio.c | 12 ++++++------
> drivers/of/of_numa.c | 4 ++--
> drivers/of/overlay.c | 4 ++--
> drivers/of/platform.c | 8 ++++----
> drivers/of/unittest.c | 26 ++++++++++++++++----------
> lib/vsprintf.c | 9 +++++++--
> 7 files changed, 39 insertions(+), 28 deletions(-)
>
Reviewed-by: Frank Rowand <frank.rowand@sony.com>
^ permalink raw reply
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