Re: [PATCH v3 00/30] Update cros_ec_commands.h
On Tue, 21 May 2019, Benson Leung wrote: > Hi Lee, > > On Sat, May 18, 2019 at 07:39:49AM +0100, Lee Jones wrote: > > On Fri, 17 May 2019, Gwendal Grignou wrote: > > > > > Lee, > > > > > > I verified and merged the changes on the kernels (3.18, 4.4 and 4.14) > > > used on chromebook using a squashed version of these patches. > > > (crrev.com/c/1583322, crrev.com/c/1583385, crrev.com/c/1583321 > > > respectively) > > > Please let me know if you have any questions. > > > > Is no one else from Chromium going to review? > > > > These seem like quite important changes. > > > > I've gone ahead and acked the whole series. Enric and I are OK with this going > in for 5.3, and as Gwendal mentioned, he's landed these changes into our > production kernels for Chrome OS as well, so this is what we want to sync on. Wonderful, thank you. > Let me know if you have any other concerns. > > Thanks, > Benson > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [alsa-devel] [PATCH v3 00/30] Update cros_ec_commands.h
On Tue, 21 May 2019, Fabien Lahoudere wrote: > Le jeudi 09 mai 2019 à 14:13 -0700, Gwendal Grignou a écrit : > > The interface between CrosEC embedded controller and the host, > > described by cros_ec_commands.h, as diverged from what the embedded > > controller really support. > > > > The source of thruth is at > > https://chromium.googlesource.com/chromiumos/platform/ec/+/master/include/ec_commands.h > > > > That include file is converted to remove ACPI and Embedded only code. > > Hi, > > I reviewed patches of the series and they looks good to me. > > Reviewed-by: Fabien Lahoudere Thanks Fabien. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: linux-next: manual merge of the pidfd tree with Linus' tree
On Wed, May 22, 2019 at 11:01:15AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the pidfd tree got a conflict in:
>
> tools/testing/selftests/pidfd/Makefile
>
> between commit:
>
> ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig")
>
> from Linus' tree and commit:
>
> 233ad92edbea ("pidfd: add polling selftests")
>
> from the pidfd tree.
Sorry, you are going to get a number of these types of minor conflicts
now. That's the problem of touching thousands of files :(
thanks,
greg k-h
Re: [PATCH] pinctrl: stmfx: Fix compile issue when CONFIG_OF_GPIO is not defined
On Mon, 20 May 2019, Amelie Delaunay wrote:
> When CONFIG_GPIO_OF is not defined, struct gpio_chip 'of_node' member does
> not exist:
> drivers/pinctrl/pinctrl-stmfx.c: In function 'stmfx_pinctrl_probe':
> drivers/pinctrl/pinctrl-stmfx.c:652:17: error: 'struct gpio_chip' has no
> member named 'of_node'
> pctl->gpio_chip.of_node = np;
>
> Fixes: 1490d9f841b1 ("pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver")
> Reported-by: kbuild test robot
> Signed-off-by: Amelie Delaunay
> ---
> drivers/pinctrl/pinctrl-stmfx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-stmfx.c b/drivers/pinctrl/pinctrl-stmfx.c
> index eba872c..bb64aa0 100644
> --- a/drivers/pinctrl/pinctrl-stmfx.c
> +++ b/drivers/pinctrl/pinctrl-stmfx.c
> @@ -648,7 +648,9 @@ static int stmfx_pinctrl_probe(struct platform_device
> *pdev)
> pctl->gpio_chip.base = -1;
> pctl->gpio_chip.ngpio = pctl->pctl_desc.npins;
> pctl->gpio_chip.can_sleep = true;
> +#ifdef CONFIG_OF_GPIO
> pctl->gpio_chip.of_node = np;
> +#endif
This is pretty ugly. Will STMFX ever be used without OF support? If
not, it might be better to place this restriction on the driver as a
whole.
Incidentally, why is this blanked out in the structure definition?
Even 'struct device' doesn't do this.
> pctl->gpio_chip.need_valid_mask = true;
>
> ret = devm_gpiochip_add_data(pctl->dev, >gpio_chip, pctl);
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[GIT] Networking
1) Clear up some recent tipc regressions because of registration ordering. Fix from Junwei Hu. 2) tipc's TLV_SET() can read past the end of the supplied buffer during the copy. From Chris Packham. 3) ptp example program doesn't match the kernel, from Richard Cochran. 4) Outgoing message type fix in qrtr, from Bjorn Andersson. 5) Flow control regression in stmmac, from Tan Tee Min. 6) Fix inband autonegotiation in phylink, from Russell King. 7) Fix sk_bound_dev_if handling in rawv6_bind(), from Mike Manning. 8) Fix usbnet crash after disconnect, from Kloetzke Jan. Please pull, thanks a lot! The following changes since commit f49aa1de98363b6c5fba4637678d6b0ba3d18065: Merge tag 'for-5.2-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux (2019-05-20 09:52:35 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git for you to fetch changes up to ad70411a978d1e6e97b1e341a7bde9a79af0c93d: usbnet: fix kernel crash after disconnect (2019-05-21 13:46:23 -0700) Bernd Eckstein (1): usbnet: ipheth: fix racing condition Bjorn Andersson (1): net: qrtr: Fix message type of outgoing packets Chris Packham (1): tipc: Avoid copying bytes beyond the supplied data David S. Miller (2): Merge branch 'net-readx_poll_timeout' Merge branch 'kselftests-fib_rule_tests-fix' Erez Alfasi (1): net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query Gustavo A. R. Silva (2): macvlan: Mark expected switch fall-through vlan: Mark expected switch fall-through Hangbin Liu (3): selftests: fib_rule_tests: fix local IPv4 address typo selftests: fib_rule_tests: enable forwarding before ipv4 from/iif test selftests: fib_rule_tests: use pre-defined DEV_ADDR Junwei Hu (1): tipc: fix modprobe tipc failed after switch order of device registration Kloetzke Jan (1): usbnet: fix kernel crash after disconnect Kurt Kanzenbach (2): 1/2] net: axienet: use readx_poll_timeout() in mdio wait function 2/2] net: xilinx_emaclite: use readx_poll_timeout() in mdio wait function Masanari Iida (1): net-next: net: Fix typos in ip-sysctl.txt Mike Manning (1): ipv6: Consider sk_bound_dev_if when binding a raw socket to an address Richard Cochran (1): ptp: Fix example program to match kernel. Russell King (1): net: phylink: ensure inband AN works correctly Tan, Tee Min (1): net: stmmac: fix ethtool flow control not able to get/set Weifeng Voon (1): net: stmmac: dma channel control register need to be init first Weitao Hou (2): fddi: fix typos in code comments networking: : fix typos in code comments Documentation/networking/ip-sysctl.txt | 4 ++-- Documentation/networking/segmentation-offloads.rst | 4 ++-- drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 4 +++- drivers/net/ethernet/mellanox/mlx4/port.c| 5 - drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 4 ++-- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c| 8 drivers/net/ethernet/xilinx/xilinx_axienet.h | 5 + drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c| 16 ++-- drivers/net/ethernet/xilinx/xilinx_emaclite.c| 16 ++-- drivers/net/fddi/skfp/hwmtm.c| 4 ++-- drivers/net/macvlan.c| 1 + drivers/net/phy/phylink.c| 37 +++-- drivers/net/usb/ipheth.c | 3 ++- drivers/net/usb/usbnet.c | 6 ++ include/uapi/linux/tipc_config.h | 10 +++--- net/8021q/vlan_dev.c | 1 + net/ipv6/raw.c | 2 ++ net/qrtr/qrtr.c | 4 ++-- net/tipc/core.c | 18 -- net/tipc/subscr.h| 5 +++-- net/tipc/topsrv.c| 14 -- tools/testing/selftests/net/fib_rule_tests.sh| 10 -- tools/testing/selftests/ptp/testptp.c| 85 + 23 files changed, 104 insertions(+), 162 deletions(-)
Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR
On Tue, 21 May 2019, Jacek Anaszewski wrote: > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git > tags/ti-lmu-led-drivers > > for you to fetch changes up to 13f5750a60b923d8f3f0e23902f2ece46dd733d7: > > leds: lm36274: Introduce the TI LM36274 LED driver (2019-05-21 20:34:19 > +0200) > > > TI LMU LED support rework and introduction of two new drivers > with DT bindings: > > - leds-lm3697 (entails additions to lm363x-regulator.c) > - leds-lm36274 > > Dan Murphy (12): > dt-bindings: mfd: LMU: Add the ramp up/down property > dt-bindings: mfd: LMU: Add ti,brightness-resolution > mfd: ti-lmu: Remove support for LM3697 > mfd: ti-lmu: Add LM36274 support to the ti-lmu These patches were Acked "for my own reference", which means I'd at least expect a discussion on how/where they would be applied. It's fine for them to go in via the LED tree in this instance and I do thank you for sending a PR. Next time can we at least agree on the route-in though please? > leds: TI LMU: Add common code for TI LMU devices > dt-bindings: ti-lmu: Modify dt bindings for the LM3697 > leds: lm3697: Introduce the lm3697 driver > regulator: lm363x: Make the gpio register enable flexible > dt-bindings: mfd: Add lm36274 bindings to ti-lmu > regulator: lm363x: Add support for LM36274 > dt-bindings: leds: Add LED bindings for the LM36274 > leds: lm36274: Introduce the TI LM36274 LED driver > > .../devicetree/bindings/leds/leds-lm36274.txt | 82 + > .../devicetree/bindings/leds/leds-lm3697.txt | 73 > Documentation/devicetree/bindings/mfd/ti-lmu.txt | 88 +++-- > drivers/leds/Kconfig | 23 ++ > drivers/leds/Makefile | 3 + > drivers/leds/leds-lm36274.c| 174 + > drivers/leds/leds-lm3697.c | 395 > + > drivers/leds/leds-ti-lmu-common.c | 156 > drivers/mfd/Kconfig| 5 +- > drivers/mfd/ti-lmu.c | 23 +- > drivers/regulator/Kconfig | 2 +- > drivers/regulator/lm363x-regulator.c | 56 ++- > include/linux/leds-ti-lmu-common.h | 47 +++ > include/linux/mfd/ti-lmu-register.h| 63 ++-- > include/linux/mfd/ti-lmu.h | 5 +- > 15 files changed, 1112 insertions(+), 83 deletions(-) > create mode 100644 Documentation/devicetree/bindings/leds/leds-lm36274.txt > create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3697.txt > create mode 100644 drivers/leds/leds-lm36274.c > create mode 100644 drivers/leds/leds-lm3697.c > create mode 100644 drivers/leds/leds-ti-lmu-common.c > create mode 100644 include/linux/leds-ti-lmu-common.h -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 5.1 000/128] 5.1.4-stable review
On Wed, May 22, 2019 at 10:33:06AM +0530, Naresh Kamboju wrote: > On Mon, 20 May 2019 at 18:03, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.1.4 release. > > There are 128 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed 22 May 2019 11:50:41 AM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.4-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > 5.1.4-rc2 report, > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. Wonderful, thanks for testing all of these again, and letting me know. greg k-h
Re: [PATCH 5.1 000/128] 5.1.4-stable review
On Tue, May 21, 2019 at 03:11:15PM -0600, shuah wrote: > On 5/20/19 6:13 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.4 release. > > There are 128 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed 22 May 2019 11:50:41 AM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.4-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on the test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH] scripts/spelling.txt: drop "sepc" from the misspelling list
On Tue, 2019-05-21 at 21:47 -0700, Paul Walmsley wrote: > On Tue, 21 May 2019, Andrew Morton wrote: > > > On Sun, 19 May 2019 11:24:22 -0700 (PDT) Paul Walmsley > > wrote: > > > > > On Sat, 18 May 2019, Joe Perches wrote: > > > > > > > On Sat, 2019-05-18 at 14:00 -0700, Paul Walmsley wrote: > > > > > The RISC-V architecture has a register named the "Supervisor Exception > > > > > Program Counter", or "sepc". This abbreviation triggers > > > > > checkpatch.pl's misspelling detector, resulting in noise in the > > > > > checkpatch output. The risk that this noise could cause more useful > > > > > warnings to be missed seems to outweigh the harm of an occasional > > > > > misspelling of "spec". Thus drop the "sepc" entry from the > > > > > misspelling list. > > > > > > > > I would agree if you first fixed the existing sepc/spec > > > > and sepcific/specific typos. > > > > > > > > arch/powerpc/kvm/book3s_xics.c: * a pending interrupt, this is a SW > > > > error and PAPR sepcifies > > > > arch/unicore32/include/mach/regs-gpio.h: * Sepcial Voltage Detect Reg > > > > GPIO_GPIR. > > > > drivers/scsi/lpfc/lpfc_init.c: /* Stop any OneConnect device > > > > sepcific driver timers */ > > > > drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c:* OverView: Read > > > > "sepcific bits" from BB register > > > > drivers/net/wireless/realtek/rtlwifi/wifi.h:/* Ref: 802.11i sepc D10.0 > > > > 7.3.2.25.1 > > > > > > Your agreement shouldn't be needed for the patch I sent. > > > > I always find Joe's input to be very useful. > > > > Here: > > > > From: Andrew Morton > > Subject: scripts-spellingtxt-drop-sepc-from-the-misspelling-list-fix > > > > fix existing "sepc" instances, per Joe > > > > Cc: Joe Perches > > Cc: Paul Walmsley > > Signed-off-by: Andrew Morton > > Thanks Andrew. Sorry that you had to do it. > > Reviewed-by: Paul Walmsley > > What troubled me about Joe's message is that it seems like poor kernel > developer precedent to block a fix for static analysis false positives to > fix comment spelling errors -- particularly considering that four out of > five of them were unrelated to the actual patch in question. While > comment spelling fixes are worthwhile, I think we should make sure that > the "tail doesn't wag the dog" by prioritizing code fixes first. I don't believe there is any tail wagging occurring here. There is no code 'fix' in the original proposed patch. It is, as described, effectively a subsystem specific static analysis false positive avoidance patch. And the static analysis tool's false positive report is not active by default. Any scripts/spelling.txt change like a sepc removal could be overridden by using checkpatch's --codespell option. btw: I don't generally add acked-by or reviewed-by to patches as I rather agree with Ted's position on these headers. https://lore.kernel.org/lkml/20190521171618.gd2...@mit.edu/ > I will try to do better next time, Thanks.
[PATCH 1/3] perf tools: Protect reading thread's namespace
It seems that the current code lacks holding the namespace lock in
thread__namespaces(). Otherwise it can see inconsistent results.
Signed-off-by: Namhyung Kim
---
tools/perf/util/thread.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 403045a2bbea..b413ba5b9835 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -133,7 +133,7 @@ void thread__put(struct thread *thread)
}
}
-struct namespaces *thread__namespaces(const struct thread *thread)
+static struct namespaces *__thread__namespaces(const struct thread *thread)
{
if (list_empty(>namespaces_list))
return NULL;
@@ -141,10 +141,21 @@ struct namespaces *thread__namespaces(const struct thread
*thread)
return list_first_entry(>namespaces_list, struct namespaces,
list);
}
+struct namespaces *thread__namespaces(const struct thread *thread)
+{
+ struct namespaces *ns;
+
+ down_read((struct rw_semaphore *)>namespaces_lock);
+ ns = __thread__namespaces(thread);
+ up_read((struct rw_semaphore *)>namespaces_lock);
+
+ return ns;
+}
+
static int __thread__set_namespaces(struct thread *thread, u64 timestamp,
struct namespaces_event *event)
{
- struct namespaces *new, *curr = thread__namespaces(thread);
+ struct namespaces *new, *curr = __thread__namespaces(thread);
new = namespaces__new(event);
if (!new)
--
2.21.0.1020.gf2820cf01a-goog
[PATCH 0/3] perf tools: Assorted fixes and cleanups for namespace events
Hello, These are some missing pieces that I found during the code-reading. Thanks, Namhyung Namhyung Kim (3): perf tools: Protect reading thread's namespace perf tools: Add missing swap ops for namespace events perf top: Enable --namespaces option tools/perf/Documentation/perf-top.txt | 5 + tools/perf/builtin-top.c | 5 + tools/perf/util/session.c | 21 + tools/perf/util/thread.c | 15 +-- 4 files changed, 44 insertions(+), 2 deletions(-) -- 2.21.0.1020.gf2820cf01a-goog
[PATCH 2/3] perf tools: Add missing swap ops for namespace events
In case it's recorded from other arch.
Signed-off-by: Namhyung Kim
---
tools/perf/util/session.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 2310a1752983..54cf163347f7 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -647,6 +647,26 @@ static void perf_event__throttle_swap(union perf_event
*event,
swap_sample_id_all(event, >throttle + 1);
}
+static void perf_event__namespaces_swap(union perf_event *event,
+ bool sample_id_all)
+{
+ u64 i;
+
+ event->namespaces.pid = bswap_32(event->namespaces.pid);
+ event->namespaces.tid = bswap_32(event->namespaces.tid);
+ event->namespaces.nr_namespaces =
bswap_64(event->namespaces.nr_namespaces);
+
+ for (i = 0; i < event->namespaces.nr_namespaces; i++) {
+ struct perf_ns_link_info *ns = >namespaces.link_info[i];
+
+ ns->dev = bswap_64(ns->dev);
+ ns->ino = bswap_64(ns->ino);
+ }
+
+ if (sample_id_all)
+ swap_sample_id_all(event, >namespaces.link_info[i]);
+}
+
static u8 revbyte(u8 b)
{
int rev = (b >> 4) | ((b & 0xf) << 4);
@@ -887,6 +907,7 @@ static perf_event__swap_op perf_event__swap_ops[] = {
[PERF_RECORD_LOST_SAMPLES]= perf_event__all64_swap,
[PERF_RECORD_SWITCH] = perf_event__switch_swap,
[PERF_RECORD_SWITCH_CPU_WIDE] = perf_event__switch_swap,
+ [PERF_RECORD_NAMESPACES] = perf_event__namespaces_swap,
[PERF_RECORD_HEADER_ATTR] = perf_event__hdr_attr_swap,
[PERF_RECORD_HEADER_EVENT_TYPE] = perf_event__event_type_swap,
[PERF_RECORD_HEADER_TRACING_DATA] = perf_event__tracing_data_swap,
--
2.21.0.1020.gf2820cf01a-goog
[PATCH 3/3] perf top: Enable --namespaces option
Since perf record already have the option, let's have it for perf top as well. Signed-off-by: Namhyung Kim --- tools/perf/Documentation/perf-top.txt | 5 + tools/perf/builtin-top.c | 5 + 2 files changed, 10 insertions(+) diff --git a/tools/perf/Documentation/perf-top.txt b/tools/perf/Documentation/perf-top.txt index 44d89fb9c788..cfea87c6f38e 100644 --- a/tools/perf/Documentation/perf-top.txt +++ b/tools/perf/Documentation/perf-top.txt @@ -262,6 +262,11 @@ Default is to monitor all CPUS. The number of threads to run when synthesizing events for existing processes. By default, the number of threads equals to the number of online CPUs. +--namespaces:: + Record events of type PERF_RECORD_NAMESPACES and display it with the + 'cgroup_id' sort key. + + INTERACTIVE PROMPTING KEYS -- diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c index 3648ef576996..6651377fd762 100644 --- a/tools/perf/builtin-top.c +++ b/tools/perf/builtin-top.c @@ -1208,6 +1208,9 @@ static int __cmd_top(struct perf_top *top) init_process_thread(top); + if (opts->record_namespaces) + top->tool.namespace_events = true; + ret = perf_event__synthesize_bpf_events(top->session, perf_event__process, >session->machines.host, >record_opts); @@ -1500,6 +1503,8 @@ int cmd_top(int argc, const char **argv) OPT_BOOLEAN(0, "force", _conf.force, "don't complain, do it"), OPT_UINTEGER(0, "num-thread-synthesize", _threads_synthesize, "number of thread to run event synthesize"), + OPT_BOOLEAN(0, "namespaces", >record_namespaces, + "Record namespaces events"), OPT_END() }; struct perf_evlist *sb_evlist = NULL; -- 2.21.0.1020.gf2820cf01a-goog
Re: [PATCH 4/4] serial: 8250-mtk: modify uart DMA rx
On Fri, 2019-05-17 at 15:36 +0800, Long Cheng wrote:
> On Wed, 2019-05-15 at 21:48 +0800, Nicolas Boichat wrote:
> > On Sat, Apr 27, 2019 at 11:36 AM Long Cheng wrote:
> > >
> > > Modify uart rx and complete for DMA.
> >
> > I don't know much about the DMA framework, but can you please explain
> > why you are making the changes in this CL? I see that you are dropping
> > dma_sync_single_for_device calls, for example, why?
> >
>
> the rx buffer is create by 'dma_alloc_coherent'. in the function, the
> buffer is uncache. We don't need to sync between CPU and DMA. So I
> remove it.
>
> > >
> > > Signed-off-by: Long Cheng
> > > ---
> > > drivers/tty/serial/8250/8250_mtk.c | 53
> > >
> > > 1 file changed, 23 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/8250/8250_mtk.c
> > > b/drivers/tty/serial/8250/8250_mtk.c
> > > index c1fdbc0..04081a6 100644
> > > --- a/drivers/tty/serial/8250/8250_mtk.c
> > > +++ b/drivers/tty/serial/8250/8250_mtk.c
> > > @@ -30,7 +30,6 @@
> > > #define MTK_UART_DMA_EN_TX 0x2
> > > #define MTK_UART_DMA_EN_RX 0x5
> > >
> > > -#define MTK_UART_TX_SIZE UART_XMIT_SIZE
> > > #define MTK_UART_RX_SIZE 0x8000
> > > #define MTK_UART_TX_TRIGGER1
> > > #define MTK_UART_RX_TRIGGERMTK_UART_RX_SIZE
> > > @@ -64,28 +63,30 @@ static void mtk8250_dma_rx_complete(void *param)
> > > struct mtk8250_data *data = up->port.private_data;
> > > struct tty_port *tty_port = >port.state->port;
> > > struct dma_tx_state state;
> > > + int copied, cnt, tmp;
> > > unsigned char *ptr;
> > > - int copied;
> > >
> > > - dma_sync_single_for_cpu(dma->rxchan->device->dev, dma->rx_addr,
> > > - dma->rx_size, DMA_FROM_DEVICE);
> > > + if (data->rx_status == DMA_RX_SHUTDOWN)
> > > + return;
> > >
> > > dmaengine_tx_status(dma->rxchan, dma->rx_cookie, );
> > > + cnt = dma->rx_size - state.residue;
> > > + tmp = cnt;
> >
> > I ponder, maybe we should rename cnt to left? (like, how many bytes
> > are left to transfer, in total) Or maybe "total"
> > Then maybe rename tmp to cnt.
> >
> like better.
>
> > >
> > > - if (data->rx_status == DMA_RX_SHUTDOWN)
> > > - return;
> > > + if ((data->rx_pos + cnt) > dma->rx_size)
> > > + tmp = dma->rx_size - data->rx_pos;
> >
> > Maybe replace this and the line above:
> > tmp = max_t(int, cnt, dma->rx_size - data->rx_pos);
> >
> Yes. It's better.
>
can't replace by 'max_t'. So I will keep original code.
> > >
> > > - if ((data->rx_pos + state.residue) <= dma->rx_size) {
> > > - ptr = (unsigned char *)(data->rx_pos + dma->rx_buf);
> > > - copied = tty_insert_flip_string(tty_port, ptr,
> > > state.residue);
> > > - } else {
> > > - ptr = (unsigned char *)(data->rx_pos + dma->rx_buf);
> > > - copied = tty_insert_flip_string(tty_port, ptr,
> > > - dma->rx_size -
> > > data->rx_pos);
> > > + ptr = (unsigned char *)(data->rx_pos + dma->rx_buf);
> > > + copied = tty_insert_flip_string(tty_port, ptr, tmp);
> > > + data->rx_pos += tmp;
> > > +
> > > + if (cnt > tmp) {
> > > ptr = (unsigned char *)(dma->rx_buf);
> > > - copied += tty_insert_flip_string(tty_port, ptr,
> > > - data->rx_pos + state.residue -
> > > dma->rx_size);
> > > + tmp = cnt - tmp;
> > > + copied += tty_insert_flip_string(tty_port, ptr, tmp);
> > > + data->rx_pos = tmp;
> > > }
> > > +
> > > up->port.icount.rx += copied;
> > >
> > > tty_flip_buffer_push(tty_port);
> > > @@ -96,9 +97,7 @@ static void mtk8250_dma_rx_complete(void *param)
> > > static void mtk8250_rx_dma(struct uart_8250_port *up)
> > > {
> > > struct uart_8250_dma *dma = up->dma;
> > > - struct mtk8250_data *data = up->port.private_data;
> > > struct dma_async_tx_descriptor *desc;
> > > - struct dma_tx_state state;
> > >
> > > desc = dmaengine_prep_slave_single(dma->rxchan, dma->rx_addr,
> > >dma->rx_size, DMA_DEV_TO_MEM,
> > > @@ -113,12 +112,6 @@ static void mtk8250_rx_dma(struct uart_8250_port *up)
> > >
> > > dma->rx_cookie = dmaengine_submit(desc);
> > >
> > > - dmaengine_tx_status(dma->rxchan, dma->rx_cookie, );
> > > - data->rx_pos = state.residue;
> > > -
> > > - dma_sync_single_for_device(dma->rxchan->device->dev, dma->rx_addr,
> > > - dma->rx_size, DMA_FROM_DEVICE);
> > > -
> > > dma_async_issue_pending(dma->rxchan);
> > > }
> > >
> > > @@ -131,13 +124,13 @@ static void mtk8250_dma_enable(struct
> > > uart_8250_port *up)
> > > if (data->rx_status != DMA_RX_START)
Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use
On Tue, May 21, 2019 at 05:48:11PM -0400, Steven Rostedt wrote: > On Tue, 21 May 2019 14:43:26 -0700 > Alexei Starovoitov wrote: > > > Steve, > > sounds like you've missed all prior threads. > > I probably have missed them ;-) > > > The feedback was given to Kris it was very clear: > > implement dtrace the same way as bpftrace is working with bpf. > > No changes are necessary to dtrace scripts > > and no kernel changes are necessary. > > Kris, I haven't been keeping up on all the discussions. But what > exactly is the issue where Dtrace can't be done the same way as the > bpftrace is done? There are several issues (and I keep finding new ones as I move forward) but the biggest one is that I am not trying to re-design and re-implement) DTrace from the ground up. We have an existing userspace component that is getting modified to work with a new kernel implementation (based on BPF and various other kernel features that are thankfully available these days). But we need to ensure that the userspace component continues to function exactly as one would expect. There should be no need to modify DTrace scripts. Perhaps bpftrace could be taught to parse DTrace scripts (i.e. implement the D script language with all its bells and whistles) but it currently cannot and DTrace obviously can. It seems to be a better use of resources to focus on the kernel component, where we can really provide a much cleaner implementation for DTrace probe execution because BPF is available and very powerful. Userspace aside, there are various features that are not currently available such as retrieving the ppid of the current task, and various other data items that relate to the current task that triggered a probe. There are ways to work around it (using the bpf_probe_read() helper, which actually performs a probe_kernel_read()) but that is rather clunky and definitely shouldn't be something that can be done from a BPF program if we're doing unprivileged tracing (which is a goal that is important for us). New helpers can be added for things like this, but the list grows large very quickly once you look at what information DTrace scripts tend to use. One of the benefits of DTrace is that probes are largely abstracted entities when you get to the script level. While different probes provide different data, they are all represented as probe arguments and they are accessed in a very consistent manner that is independent from the actual kind of probe that triggered the execution. Often, a single DTrace clause is associated with multiple probes, of different types. Probes in the kernel (kprobe, perf event, tracepoint, ...) are associated with their own BPF program type, so it is not possible to load the DTrace clause (translated into BPF code) once and associate it with probes of different types. Instead, I'd have to load it as a BPF_PROG_TYPE_KPROBE program to associate it with a kprobe, and I'd have to load it as a BPF_PROG_TYPE_TRACEPOINT program to associate it with a tracepoint, and so on. This also means that I suddenly have to add code to the userspace component to know about the different program types with more detail, like what helpers are available to specific program types. Another advantage of being able to operate on a more abstract probe concept that is not tied to a specific probe type is that the userspace component does not need to know about the implementation details of the specific probes. This avoids a tight coupling between the userspace component and the kernel implementation. Another feature that is currently not supported is speculative tracing. This is a feature that is not as commonly used (although I personally have found it to be very useful in the past couple of years) but it quite powerful because it allows for probe data to be recorded, and have the decision on whether it is to be made available to userspace postponed to a later event. At that time, the data can be discarded or committed. These are just some examples of issues I have been working on. I spent quite a bit of time to look for ways to implement what we need for DTrace with a minimal amount of patches to the kernel because there really isn't any point in doing unnecessary work. I do not doubt that there are possible clever ways to somehow get around some of these issues with clever hacks and workarounds, but I am not trying to hack something together that hopefully will be close enough to the expected functionality. DTrace has proven itself to be quite useful and dependable as a tracing solution, and I am working on continuing to deliver on that while recognizing the significant work that others have put into advancing the tracing infrastructure in Linux in recent years. So many people have contributed excellent features - and I am making use of those features as much as I can. But as is often the case, not everything that I need is currently implemented. As I expressed during last year's Plumbers in Vancouver, I am
[PATCH] Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265.
This commit breaks some HID devices, see [1] for details
https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Vasily Khoruzhick
Cc: sta...@vger.kernel.org
---
include/net/bluetooth/hci_core.h | 3 ---
net/bluetooth/hci_conn.c | 8
2 files changed, 11 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 05b1b96f4d9e..094e61e07030 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -190,9 +190,6 @@ struct adv_info {
#define HCI_MAX_SHORT_NAME_LENGTH 10
-/* Min encryption key size to match with SMP */
-#define HCI_MIN_ENC_KEY_SIZE 7
-
/* Default LE RPA expiry time, 15 minutes */
#define HCI_DEFAULT_RPA_TIMEOUT(15 * 60)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 3cf0764d5793..bd4978ce8c45 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1276,14 +1276,6 @@ int hci_conn_check_link_mode(struct hci_conn *conn)
!test_bit(HCI_CONN_ENCRYPT, >flags))
return 0;
- /* The minimum encryption key size needs to be enforced by the
-* host stack before establishing any L2CAP connections. The
-* specification in theory allows a minimum of 1, but to align
-* BR/EDR and LE transports, a minimum of 7 is chosen.
-*/
- if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE)
- return 0;
-
return 1;
}
--
2.21.0
RE: [PATCH] PCI: hv: Detect and fix Hyper-V PCI domain number collision
> From: Stephen Hemminger > Sent: Tuesday, May 21, 2019 9:40 PM > > Thanks for working this out with the host team. > Now if we could just get some persistent slot information it would make udev > in systemd happy. The slot info comes from the serial number "hpdev->desc.ser", which may not guarantee uniqueness: "...Hyper-V doesn't provide unique serial numbers": see the changelog of the below commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29927dfb7f69bcf2ae7fd1cda10997e646a5189c And we can pass through multiple devices to a VM in any order (i.e. hot add/remove), so IMO the "slot" info is not unique and persistent. Thanks, -- Dexuan
Re: [RFC 0/7] introduce memory hinting API for external process
On Tue, May 21, 2019 at 4:39 AM Christian Brauner wrote: > > On Tue, May 21, 2019 at 01:30:29PM +0200, Christian Brauner wrote: > > On Tue, May 21, 2019 at 08:05:52PM +0900, Minchan Kim wrote: > > > On Tue, May 21, 2019 at 10:42:00AM +0200, Christian Brauner wrote: > > > > On Mon, May 20, 2019 at 12:52:47PM +0900, Minchan Kim wrote: > > > > > - Background > > > > > > > > > > The Android terminology used for forking a new process and starting > > > > > an app > > > > > from scratch is a cold start, while resuming an existing app is a hot > > > > > start. > > > > > While we continually try to improve the performance of cold starts, > > > > > hot > > > > > starts will always be significantly less power hungry as well as > > > > > faster so > > > > > we are trying to make hot start more likely than cold start. > > > > > > > > > > To increase hot start, Android userspace manages the order that apps > > > > > should > > > > > be killed in a process called ActivityManagerService. > > > > > ActivityManagerService > > > > > tracks every Android app or service that the user could be > > > > > interacting with > > > > > at any time and translates that into a ranked list for lmkd(low memory > > > > > killer daemon). They are likely to be killed by lmkd if the system > > > > > has to > > > > > reclaim memory. In that sense they are similar to entries in any > > > > > other cache. > > > > > Those apps are kept alive for opportunistic performance improvements > > > > > but > > > > > those performance improvements will vary based on the memory > > > > > requirements of > > > > > individual workloads. > > > > > > > > > > - Problem > > > > > > > > > > Naturally, cached apps were dominant consumers of memory on the > > > > > system. > > > > > However, they were not significant consumers of swap even though they > > > > > are > > > > > good candidate for swap. Under investigation, swapping out only begins > > > > > once the low zone watermark is hit and kswapd wakes up, but the > > > > > overall > > > > > allocation rate in the system might trip lmkd thresholds and cause a > > > > > cached > > > > > process to be killed(we measured performance swapping out vs. zapping > > > > > the > > > > > memory by killing a process. Unsurprisingly, zapping is 10x times > > > > > faster > > > > > even though we use zram which is much faster than real storage) so > > > > > kill > > > > > from lmkd will often satisfy the high zone watermark, resulting in > > > > > very > > > > > few pages actually being moved to swap. > > > > > > > > > > - Approach > > > > > > > > > > The approach we chose was to use a new interface to allow userspace to > > > > > proactively reclaim entire processes by leveraging platform > > > > > information. > > > > > This allowed us to bypass the inaccuracy of the kernel’s LRUs for > > > > > pages > > > > > that are known to be cold from userspace and to avoid races with lmkd > > > > > by reclaiming apps as soon as they entered the cached state. > > > > > Additionally, > > > > > it could provide many chances for platform to use much information to > > > > > optimize memory efficiency. > > > > > > > > > > IMHO we should spell it out that this patchset complements > > > > > MADV_WONTNEED > > > > > and MADV_FREE by adding non-destructive ways to gain some free memory > > > > > space. MADV_COLD is similar to MADV_WONTNEED in a way that it hints > > > > > the > > > > > kernel that memory region is not currently needed and should be > > > > > reclaimed > > > > > immediately; MADV_COOL is similar to MADV_FREE in a way that it hints > > > > > the > > > > > kernel that memory region is not currently needed and should be > > > > > reclaimed > > > > > when memory pressure rises. > > > > > > > > > > To achieve the goal, the patchset introduce two new options for > > > > > madvise. > > > > > One is MADV_COOL which will deactive activated pages and the other is > > > > > MADV_COLD which will reclaim private pages instantly. These new > > > > > options > > > > > complement MADV_DONTNEED and MADV_FREE by adding non-destructive ways > > > > > to > > > > > gain some free memory space. MADV_COLD is similar to MADV_DONTNEED in > > > > > a way > > > > > that it hints the kernel that memory region is not currently needed > > > > > and > > > > > should be reclaimed immediately; MADV_COOL is similar to MADV_FREE in > > > > > a way > > > > > that it hints the kernel that memory region is not currently needed > > > > > and > > > > > should be reclaimed when memory pressure rises. > > > > > > > > > > This approach is similar in spirit to madvise(MADV_WONTNEED), but the > > > > > information required to make the reclaim decision is not known to the > > > > > app. > > > > > Instead, it is known to a centralized userspace daemon, and that > > > > > daemon > > > > > must be able to initiate reclaim on its own without any app > > > > > involvement. > > > > > To solve the concern, this patch introduces new syscall
[PATCH] input: silead: Add MSSL0017 to acpi_device_id.
On Chuwi Hi10 Plus, the Silead device id is MSSL0017.
Signed-off-by: Danct12
---
drivers/input/touchscreen/silead.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen/silead.c
b/drivers/input/touchscreen/silead.c
index 09241d4cdebc..06f0eb04a8fd 100644
--- a/drivers/input/touchscreen/silead.c
+++ b/drivers/input/touchscreen/silead.c
@@ -617,6 +617,7 @@ static const struct acpi_device_id silead_ts_acpi_match[] =
{
{ "MSSL1680", 0 },
{ "MSSL0001", 0 },
{ "MSSL0002", 0 },
+ { "MSSL0017", 0 },
{ }
};
MODULE_DEVICE_TABLE(acpi, silead_ts_acpi_match);
--
2.21.0
Re: ext4 regression (was Re: [PATCH 4.19 000/105] 4.19.45-stable review)
On Tue, May 21, 2019 at 11:27:21PM +0530, Naresh Kamboju wrote:
> Steps to reproduce is,
> running LTP three test cases in sequence on x86 device.
> # cd ltp/runtest
> # cat syscalls ( only three test case)
> open12 open12
> madvise06 madvise06
> poll02 poll02
> #
>
> as Dan referring to,
>
> LTP is run using '/opt/ltp/runltp -d /scratch -f syscalls', where the
> syscalls file has been replaced with three test case names, and
> /scratch is an ext4 SATA drive. /scratch is created using 'mkfs -t ext4
> /dev/disk/by-id/ata-TOSHIBA_MG03ACA100_37O9KGKWF' and mounted to
> /scratch.
I'm still having trouble reproducing the problem. I've followed the
above exactly, and it doesn't trigger on my system. I think I know
what is happening, but even given my theory, I'm still not able to
trigger it. So, I'm not 100% sure this is the appropriate fix. If
you can reproduce it, can you see if this patch, applied on top of the
Linus's tip, fixes the problem for you?
- Ted
commit 3ad7621bfff343b16d59ed418f6d4420d4ec3e63
Author: Theodore Ts'o
Date: Tue May 21 17:01:01 2019 -0400
ext4: don't perform block validity checks on the journal inode
Since the journal inode is already checked when we added it to the
block validity's system zone, if we check it again, we'll just trigger
a failure.
This was causing failures like this:
[ 53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode
#8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent
entries - magic f30a, entries 8, max 340(340), depth 0(0)
[ 53.931430] jbd2_journal_bmap: journal block not found at offset 49 on
sda-8
[ 53.938480] Aborting journal on device sda-8.
... but only if the system was under enough memory pressure that
logical->physical mapping for the journal inode gets pushed out of the
extent cache. (This is why it wasn't noticed earlier.)
Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using
block_validity")
Reported-by: Dan Rue
Signed-off-by: Theodore Ts'o
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index f2c62e2a0c98..d40ed940001e 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -518,10 +518,14 @@ __read_extent_tree_block(const char *function, unsigned
int line,
}
if (buffer_verified(bh) && !(flags & EXT4_EX_FORCE_CACHE))
return bh;
- err = __ext4_ext_check(function, line, inode,
- ext_block_hdr(bh), depth, pblk);
- if (err)
- goto errout;
+ if (!ext4_has_feature_journal(inode->i_sb) ||
+ (inode->i_ino !=
+le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum))) {
+ err = __ext4_ext_check(function, line, inode,
+ ext_block_hdr(bh), depth, pblk);
+ if (err)
+ goto errout;
+ }
set_buffer_verified(bh);
/*
* If this is a leaf block, cache all of its entries
Re: [PATCH 4.19 000/105] 4.19.45-stable review
On Mon, 20 May 2019 at 17:51, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.45 release. > There are 105 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 22 May 2019 11:50:49 AM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.45-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h 4.19.45-rc2 report, Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.19.45-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 84889965d346f29e8d1614f9c3cb35c389a40eec git describe: v4.19.44-103-g84889965d346 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.44-103-g84889965d346 No regressions (compared to build v4.19.44) No fixes (compared to build v4.19.44) Ran 21466 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.1 000/128] 5.1.4-stable review
On Mon, 20 May 2019 at 18:03, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.4 release. > There are 128 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 22 May 2019 11:50:41 AM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.4-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.1.y > and the diffstat can be found below. > > thanks, > > greg k-h > 5.1.4-rc2 report, Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.1.4-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.1.y git commit: a8112defa801e2b32d9da822880f32966d30158c git describe: v5.1.3-126-ga8112defa801 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.1-oe/build/v5.1.3-126-ga8112defa801 No regressions (compared to build v5.1.3) No fixes (compared to build v5.1.3) Ran 20655 total tests in the following environments and test suites. Environments -- - dragonboard-410c - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.0 000/123] 5.0.18-stable review
On Mon, 20 May 2019 at 17:56, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.0.18 release. > There are 123 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 22 May 2019 11:50:46 AM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.18-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.0.y > and the diffstat can be found below. > > thanks, > > greg k-h 5.0.18-rc2 report, Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.0.18-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.0.y git commit: 5eaa7ad66ec7e9d1c3e1ef871ec29a5427d05ca7 git describe: v5.0.17-121-g5eaa7ad66ec7 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.0-oe/build/v5.0.17-121-g5eaa7ad66ec7 No regressions (compared to build v5.0.17) No fixes (compared to build v5.0.17) Ran 21429 total tests in the following environments and test suites. Environments -- - dragonboard-410c - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 2/2] powerpc/perf: Fix mmcra corruption by bhrb_filter
On 11/05/19 8:12 AM, Ravi Bangoria wrote:
Consider a scenario where user creates two events:
1st event:
attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
attr.branch_sample_type = PERF_SAMPLE_BRANCH_ANY;
fd = perf_event_open(attr, 0, 1, -1, 0);
This sets cpuhw->bhrb_filter to 0 and returns valid fd.
2nd event:
attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
attr.branch_sample_type = PERF_SAMPLE_BRANCH_CALL;
fd = perf_event_open(attr, 0, 1, -1, 0);
It overrides cpuhw->bhrb_filter to -1 and returns with error.
Now if power_pmu_enable() gets called by any path other than
power_pmu_add(), ppmu->config_bhrb(-1) will set mmcra to -1.
Reviewed-by: Madhavan Srinivasan
Signed-off-by: Ravi Bangoria
---
arch/powerpc/perf/core-book3s.c | 6 --
arch/powerpc/perf/power8-pmu.c | 3 +++
arch/powerpc/perf/power9-pmu.c | 3 +++
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index b0723002a396..8eb5dc5df62b 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1846,6 +1846,7 @@ static int power_pmu_event_init(struct perf_event *event)
int n;
int err;
struct cpu_hw_events *cpuhw;
+ u64 bhrb_filter;
if (!ppmu)
return -ENOENT;
@@ -1951,13 +1952,14 @@ static int power_pmu_event_init(struct perf_event
*event)
err = power_check_constraints(cpuhw, events, cflags, n + 1);
if (has_branch_stack(event)) {
- cpuhw->bhrb_filter = ppmu->bhrb_filter_map(
+ bhrb_filter = ppmu->bhrb_filter_map(
event->attr.branch_sample_type);
- if (cpuhw->bhrb_filter == -1) {
+ if (bhrb_filter == -1) {
put_cpu_var(cpu_hw_events);
return -EOPNOTSUPP;
}
+ cpuhw->bhrb_filter = bhrb_filter;
}
put_cpu_var(cpu_hw_events);
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index d12a2db26353..d10feef93b6b 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -29,6 +29,7 @@ enum {
#define POWER8_MMCRA_IFM1 0x4000UL
#define POWER8_MMCRA_IFM2 0x8000UL
#define POWER8_MMCRA_IFM3 0xC000UL
+#definePOWER8_MMCRA_BHRB_MASK 0xC000UL
/*
* Raw event encoding for PowerISA v2.07 (Power8):
@@ -243,6 +244,8 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type)
static void power8_config_bhrb(u64 pmu_bhrb_filter)
{
+ pmu_bhrb_filter &= POWER8_MMCRA_BHRB_MASK;
+
/* Enable BHRB filter in PMU */
mtspr(SPRN_MMCRA, (mfspr(SPRN_MMCRA) | pmu_bhrb_filter));
}
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 030544e35959..f3987915cadc 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -92,6 +92,7 @@ enum {
#define POWER9_MMCRA_IFM1 0x4000UL
#define POWER9_MMCRA_IFM2 0x8000UL
#define POWER9_MMCRA_IFM3 0xC000UL
+#define POWER9_MMCRA_BHRB_MASK 0xC000UL
/* Nasty Power9 specific hack */
#define PVR_POWER9_CUMULUS0x2000
@@ -300,6 +301,8 @@ static u64 power9_bhrb_filter_map(u64 branch_sample_type)
static void power9_config_bhrb(u64 pmu_bhrb_filter)
{
+ pmu_bhrb_filter &= POWER9_MMCRA_BHRB_MASK;
+
/* Enable BHRB filter in PMU */
mtspr(SPRN_MMCRA, (mfspr(SPRN_MMCRA) | pmu_bhrb_filter));
}
Re: [PATCH v6 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC.
Hi Andrew,
On Tue, May 21, 2019 at 7:24 PM Andrew Lunn wrote:
>
> > static void ocores_process_polling(struct ocores_i2c *i2c)
> > {
> > + const struct of_device_id *match;
> > +
> > + match = of_match_node(ocores_i2c_match, i2c->adap.dev.of_node);
> > +
> > while (1) {
> > irqreturn_t ret;
> > int err;
>
> Please keep with the idea of i2c->flags, which is set during probe.
> Just because it was removed because it was no longer needed does not
> stop you from putting it back again if it is needed.
>
I had modified the implementation, so as to keep it compatible with
the new implementation of polling mode.
As per your suggestion, I will keep the older method (the v5 version
which you Reviewed earlier : https://lkml.org/lkml/2019/5/20/1261)
and submit a v7 for this.
>Andrew
Thanks & Regards,
Sagar
Re: [PATCH v6 1/3] dt-bindings: i2c: extend existing opencore bindings.
Hi Andrew, On Tue, May 21, 2019 at 7:26 PM Andrew Lunn wrote: > > > Required properties: > > -- compatible : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst" > > +- compatible : "opencores,i2c-ocores", > > + "aeroflexgaisler,i2cmst", > > +"sifive,fu540-c000-i2c","sifive,i2c0". > > + For Opencore based I2C IP block reimplemented in > > It looks like there are some tabs vs space issues here. Ohh. It was not catched in checkpatch.pl. I will update it. Thanks, Sagar Kadam >Andrew
Re: [PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel
On 05/22/19 at 11:20am, Dave Young wrote:
> How about the userspace kexec-tools? It needs a similar detection, but
> I'm not sure how to detect paging mode, maybe some sysfs entry or
> vmcoreinfo in /proc/vmcore
In usersapce, I plan to parse /proc/kcore to get the starting address
of page_offset or vmalloc. You can see the different level has different
value range.
4-level:
8880 | -119.5 TB | c87f | 64 TB | direct mapping
of all physical memory (page_offset_base)
c880 | -55.5 TB | c8ff | 0.5 TB | ... unused hole
c900 | -55TB | e8ff | 32 TB | vmalloc/ioremap
space (vmalloc_base)
e900 | -23TB | e9ff |1 TB | ... unused hole
ea00 | -22TB | eaff |1 TB | virtual memory
map (vmemmap_base)
5-level:
ff11 | -59.75 PB | ff90 | 32 PB | direct mapping
of all physical memory (page_offset_base)
ff91 | -27.75 PB | ff9f | 3.75 PB | ... unused hole
ffa0 | -24PB | ffd1 | 12.5 PB | vmalloc/ioremap
space (vmalloc_base)
ffd2 | -11.5 PB | ffd3 | 0.5 PB | ... unused hole
ffd4 | -11PB | ffd5 | 0.5 PB | virtual memory
map (vmemmap_base)
>
>
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/x86/kernel/kexec-bzimage64.c
> > b/arch/x86/kernel/kexec-bzimage64.c
> > index 22f60dd26460..858cc892672f 100644
> > --- a/arch/x86/kernel/kexec-bzimage64.c
> > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > @@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned
> > long len)
> > return ret;
> > }
> >
> > + if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
> > + pr_err("Can not jump to old 4-level kernel from 5-level
> > kernel.\n");
>
> 4-level kernel sounds not very clear, maybe something like below?
>
> "5-level paging enabled, can not kexec into an old kernel without 5-level
> paging facility"?
Oops, tglx commented on this message. He suggested changing it like:
"bzImage cannot handle 5-level paging mode\n"
I forgot updating this part. Any one is fine to me. Will update.
Thanks
Baoquan
Re: [PATCH] scripts/spelling.txt: drop "sepc" from the misspelling list
On Tue, 21 May 2019, Andrew Morton wrote: > On Sun, 19 May 2019 11:24:22 -0700 (PDT) Paul Walmsley > wrote: > > > On Sat, 18 May 2019, Joe Perches wrote: > > > > > On Sat, 2019-05-18 at 14:00 -0700, Paul Walmsley wrote: > > > > The RISC-V architecture has a register named the "Supervisor Exception > > > > Program Counter", or "sepc". This abbreviation triggers > > > > checkpatch.pl's misspelling detector, resulting in noise in the > > > > checkpatch output. The risk that this noise could cause more useful > > > > warnings to be missed seems to outweigh the harm of an occasional > > > > misspelling of "spec". Thus drop the "sepc" entry from the > > > > misspelling list. > > > > > > I would agree if you first fixed the existing sepc/spec > > > and sepcific/specific typos. > > > > > > arch/powerpc/kvm/book3s_xics.c:* a pending interrupt, this is a SW > > > error and PAPR sepcifies > > > arch/unicore32/include/mach/regs-gpio.h: * Sepcial Voltage Detect Reg > > > GPIO_GPIR. > > > drivers/scsi/lpfc/lpfc_init.c:/* Stop any OneConnect device > > > sepcific driver timers */ > > > drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c:* OverView: Read > > > "sepcific bits" from BB register > > > drivers/net/wireless/realtek/rtlwifi/wifi.h:/* Ref: 802.11i sepc D10.0 > > > 7.3.2.25.1 > > > > Your agreement shouldn't be needed for the patch I sent. > > I always find Joe's input to be very useful. > > Here: > > From: Andrew Morton > Subject: scripts-spellingtxt-drop-sepc-from-the-misspelling-list-fix > > fix existing "sepc" instances, per Joe > > Cc: Joe Perches > Cc: Paul Walmsley > Signed-off-by: Andrew Morton Thanks Andrew. Sorry that you had to do it. Reviewed-by: Paul Walmsley What troubled me about Joe's message is that it seems like poor kernel developer precedent to block a fix for static analysis false positives to fix comment spelling errors -- particularly considering that four out of five of them were unrelated to the actual patch in question. While comment spelling fixes are worthwhile, I think we should make sure that the "tail doesn't wag the dog" by prioritizing code fixes first. Reflecting on it on Sunday evening, if Joe had acked the patch, or added a Reviewed-by, and asked whether I might send a patch to fix those spelling errors, it probably would have gotten done. I will try to do better next time, - Paul
[PATCH] x86/fpu: allow kernel_fpu_{begin,end} to be used by non-GPL modules
Prior to [1], all non-GPL modules were able to make use of SIMD on x86
by making use of the __kernel_fpu_* API. Given that __kernel_fpu_* were
both EXPORT_SYMBOL'd and kernel_fpu_* are such trivial wrappers around
the now-static __kernel_fpu_*, it seems to me that there is no reason to
have different licensing rules for them.
In the case of OpenZFS, the lack of SIMD on newer Linux kernels has
caused significant performance problems (since ZFS uses SIMD for
calculation of blkptr checksums as well as raidz calculations).
[1]: commit 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()")
Cc: "Jason A. Donenfeld"
Signed-off-by: Aleksa Sarai
---
arch/x86/kernel/fpu/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 2e5003fef51a..8de5687a470d 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -127,14 +127,14 @@ void kernel_fpu_begin(void)
preempt_disable();
__kernel_fpu_begin();
}
-EXPORT_SYMBOL_GPL(kernel_fpu_begin);
+EXPORT_SYMBOL(kernel_fpu_begin);
void kernel_fpu_end(void)
{
__kernel_fpu_end();
preempt_enable();
}
-EXPORT_SYMBOL_GPL(kernel_fpu_end);
+EXPORT_SYMBOL(kernel_fpu_end);
/*
* Save the FPU state (mark it for reload if necessary):
--
2.21.0
Re: [GIT PULL] SPDX update for 5.2-rc1 - round 1
On Tue, May 21, 2019 at 10:34 PM Greg KH wrote: > > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > tags/spdx-5.2-rc2 > > for you to fetch changes up to 7170066ecd289cd8560695b6f86ba8dc723b6505: > > treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 25 > (2019-05-21 11:52:39 +0200) > > > SPDX update for 5.2-rc2, round 1 > > Here are series of patches that add SPDX tags to different kernel files, > based on two different things: > - SPDX entries are added to a bunch of files that we missed a year ago > that do not have any license information at all. > > These were either missed because the tool saw the MODULE_LICENSE() > tag, or some EXPORT_SYMBOL tags, and got confused and thought the > file had a real license, or the files have been added since the last > big sweep, or they were Makefile/Kconfig files, which we didn't > touch last time. > > - Add GPL-2.0-only or GPL-2.0-or-later tags to files where our scan > tools can determine the license text in the file itself. Where this > happens, the license text is removed, in order to cut down on the > 700+ different ways we have in the kernel today, in a quest to get > rid of all of these. I have been wondering for a while which version of spdx tags I should use in my work. I know the 'GPL-2.0' tag is already deprecated. (https://spdx.org/licenses/GPL-2.0.html) But, I saw negative reaction to this: https://lore.kernel.org/patchwork/patch/975394/ Nor "-only" / "-or-later" are documented in Documentation/process/license-rules.rst In this patch series, Thomas used 'GPL-2.0-only' and 'GPL-2.0-or-later' instead of 'GPL-2.0' and 'GPL-2.0+'. Now, we have a great number of users of spdx v3 tags. $ git grep -P 'SPDX-License-Identifier.*(?:-or-later|-only)'| wc -l 4135 So, what I understood is: For newly added tags, '*-only' and '*-or-later' are preferred. (But, we do not convert existing spdx v2 tags globally.) Joe's patch was not merged, but at least Documentation/process/license-rules.rst should be updated in my opinion. (Perhaps, checkpatch.pl can suggest newer tags in case patch submitters do not even know that deprecation.) Thanks. > These patches have been out for review on the linux-spdx@vger mailing > list, and while they were created by automatic tools, they were > hand-verified by a bunch of different people, all whom names are on the > patches are reviewers. > > The reason for these "large" patches is if we were to continue to > progress at the current rate of change in the kernel, adding license > tags to individual files in different subsystems, we would be finished > in about 10 years at the earliest. > > There will be more series of these types of patches coming over the next > few weeks as the tools and reviewers crunch through the more "odd" > variants of how to say "GPLv2" that developers have come up with over > the years, combined with other fun oddities (GPL + a BSD disclaimer?) > that are being unearthed, with the goal for the whole kernel to be > cleaned up. > > These diffstats are not small, 3840 files are touched, over 10k lines > removed in just 24 patches. > > Signed-off-by: Greg Kroah-Hartman -- Best Regards Masahiro Yamada
Re: [PATCH] misc: remove redundant 'default n' from Kconfig-s
Le 20/05/2019 à 16:10, Bartlomiej Zolnierkiewicz a écrit :
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:
...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...
Signed-off-by: Bartlomiej Zolnierkiewicz
---
for cxl and ocxl:
Acked-by: Frederic Barrat
drivers/misc/Kconfig | 10 --
drivers/misc/altera-stapl/Kconfig |1 -
drivers/misc/c2port/Kconfig |2 --
drivers/misc/cb710/Kconfig|1 -
drivers/misc/cxl/Kconfig |3 ---
drivers/misc/echo/Kconfig |1 -
drivers/misc/genwqe/Kconfig |1 -
drivers/misc/lis3lv02d/Kconfig|2 --
drivers/misc/ocxl/Kconfig |1 -
9 files changed, 22 deletions(-)
Index: b/drivers/misc/Kconfig
===
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -8,7 +8,6 @@ config SENSORS_LIS3LV02D
tristate
depends on INPUT
select INPUT_POLLDEV
- default n
config AD525X_DPOT
tristate "Analog Devices Digital Potentiometers"
@@ -61,7 +60,6 @@ config ATMEL_TCLIB
config DUMMY_IRQ
tristate "Dummy IRQ handler"
- default n
---help---
This module accepts a single 'irq' parameter, which it should
register for.
The sole purpose of this module is to help with debugging of systems
on
@@ -117,7 +115,6 @@ config PHANTOM
config INTEL_MID_PTI
tristate "Parallel Trace Interface for MIPI P1149.7 cJTAG standard"
depends on PCI && TTY && (X86_INTEL_MID || COMPILE_TEST)
- default n
help
The PTI (Parallel Trace Interface) driver directs
trace data routed from various parts in the system out
@@ -193,7 +190,6 @@ config ATMEL_SSC
config ENCLOSURE_SERVICES
tristate "Enclosure Services"
- default n
help
Provides support for intelligent enclosures (bays which
contain storage devices). You also need either a host
@@ -217,7 +213,6 @@ config SGI_XP
config CS5535_MFGPT
tristate "CS5535/CS5536 Geode Multi-Function General Purpose Timer (MFGPT)
support"
depends on MFD_CS5535
- default n
help
This driver provides access to MFGPT functionality for other
drivers that need timers. MFGPTs are available in the CS5535 and
@@ -250,7 +245,6 @@ config CS5535_CLOCK_EVENT_SRC
config HP_ILO
tristate "Channel interface driver for the HP iLO processor"
depends on PCI
- default n
help
The channel interface driver allows applications to communicate
with iLO management processors present on HP ProLiant servers.
@@ -285,7 +279,6 @@ config QCOM_FASTRPC
config SGI_GRU
tristate "SGI GRU driver"
depends on X86_UV && SMP
- default n
select MMU_NOTIFIER
---help---
The GRU is a hardware resource located in the system chipset. The GRU
@@ -300,7 +293,6 @@ config SGI_GRU
config SGI_GRU_DEBUG
bool "SGI GRU driver debug"
depends on SGI_GRU
- default n
---help---
This option enables additional debugging code for the SGI GRU driver.
If you are unsure, say N.
@@ -358,7 +350,6 @@ config SENSORS_BH1770
config SENSORS_APDS990X
tristate "APDS990X combined als and proximity sensors"
depends on I2C
-default n
---help---
Say Y here if you want to build a driver for Avago APDS990x
combined ambient light and proximity sensor chip.
@@ -386,7 +377,6 @@ config DS1682
config SPEAR13XX_PCIE_GADGET
bool "PCIe gadget support for SPEAr13XX platform"
depends on ARCH_SPEAR13XX && BROKEN
- default n
help
This option enables gadget support for PCIe controller. If
board file defines any controller as PCIe endpoint then a sysfs
Index: b/drivers/misc/altera-stapl/Kconfig
===
--- a/drivers/misc/altera-stapl/Kconfig
+++ b/drivers/misc/altera-stapl/Kconfig
@@ -4,6 +4,5 @@ comment "Altera FPGA firmware download m
config ALTERA_STAPL
tristate "Altera FPGA firmware download module"
depends on I2C
- default n
help
Re: [PATCH] tty_io: Fix a missing-check bug in drivers/tty/tty_io.c
On 22. 05. 19, 3:40, Gen Zhang wrote:
> In alloc_tty_struct(), tty->dev is assigned by tty_get_device(). And it
> calls class_find_device(). And class_find_device() may return NULL.
> And tty->dev is dereferenced in the following codes. When
> tty_get_device() returns NULL, dereferencing this tty->dev null pointer
> may cause the kernel go wrong. Thus we should check tty->dev.
> Further, if tty_get_device() returns NULL, we should free tty and
> return NULL.
>
> Signed-off-by: Gen Zhang
>
> ---
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 033ac7e..1444b59 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -3008,6 +3008,10 @@ struct tty_struct *alloc_tty_struct(struct tty_driver
> *driver, int idx)
> tty->index = idx;
> tty_line_name(driver, idx, tty->name);
> tty->dev = tty_get_device(tty);
> + if (!tty->dev) {
> + kfree(tty);
> + return NULL;
> + }
This is incorrect, you introduced an ldisc reference leak.
And can this happen at all?
thanks,
--
js
suse labs
Re: [RFC 0/7] introduce memory hinting API for external process
To expand on the ChromeOS use case we're in a very similar situation to Android. For example, the Chrome browser uses a separate process for each individual tab (with some exceptions) and over time many tabs remain open in a back-grounded or idle state. Given that we have a lot of information about the weight of a tab, when it was last active, etc, we can benefit tremendously from per-process reclaim. We're working on getting real world numbers but all of our initial testing shows very promising results. On Tue, May 21, 2019 at 5:57 AM Shakeel Butt wrote: > > On Mon, May 20, 2019 at 7:55 PM Anshuman Khandual > wrote: > > > > > > > > On 05/20/2019 10:29 PM, Tim Murray wrote: > > > On Sun, May 19, 2019 at 11:37 PM Anshuman Khandual > > > wrote: > > >> > > >> Or Is the objective here is reduce the number of processes which get > > >> killed by > > >> lmkd by triggering swapping for the unused memory (user hinted) sooner > > >> so that > > >> they dont get picked by lmkd. Under utilization for zram hardware is a > > >> concern > > >> here as well ? > > > > > > The objective is to avoid some instances of memory pressure by > > > proactively swapping pages that userspace knows to be cold before > > > those pages reach the end of the LRUs, which in turn can prevent some > > > apps from being killed by lmk/lmkd. As soon as Android userspace knows > > > that an application is not being used and is only resident to improve > > > performance if the user returns to that app, we can kick off > > > process_madvise on that process's pages (or some portion of those > > > pages) in a power-efficient way to reduce memory pressure long before > > > the system hits the free page watermark. This allows the system more > > > time to put pages into zram versus waiting for the watermark to > > > trigger kswapd, which decreases the likelihood that later memory > > > allocations will cause enough pressure to trigger a kill of one of > > > these apps. > > > > So this opens up bit of LRU management to user space hints. Also because > > the app > > in itself wont know about the memory situation of the entire system, new > > system > > call needs to be called from an external process. > > > > > > > >> Swapping out memory into zram wont increase the latency for a hot start > > >> ? Or > > >> is it because as it will prevent a fresh cold start which anyway will be > > >> slower > > >> than a slow hot start. Just being curious. > > > > > > First, not all swapped pages will be reloaded immediately once an app > > > is resumed. We've found that an app's working set post-process_madvise > > > is significantly smaller than what an app allocates when it first > > > launches (see the delta between pswpin and pswpout in Minchan's > > > results). Presumably because of this, faulting to fetch from zram does > > > > pswpin 4176131392647 975034 233.00 > > pswpout127422426617311387507 108.00 > > > > IIUC the swap-in ratio is way higher in comparison to that of swap out. Is > > that > > always the case ? Or it tend to swap out from an active area of the working > > set > > which faulted back again. > > > > > not seem to introduce a noticeable hot start penalty, not does it > > > cause an increase in performance problems later in the app's > > > lifecycle. I've measured with and without process_madvise, and the > > > differences are within our noise bounds. Second, because we're not > > > > That is assuming that post process_madvise() working set for the > > application is > > always smaller. There is another challenge. The external process should > > ideally > > have the knowledge of active areas of the working set for an application in > > question for it to invoke process_madvise() correctly to prevent such > > scenarios. > > > > > preemptively evicting file pages and only making them more likely to > > > be evicted when there's already memory pressure, we avoid the case > > > where we process_madvise an app then immediately return to the app and > > > reload all file pages in the working set even though there was no > > > intervening memory pressure. Our initial version of this work evicted > > > > That would be the worst case scenario which should be avoided. Memory > > pressure > > must be a parameter before actually doing the swap out. But pages if know > > to be > > inactive/cold can be marked high priority to be swapped out. > > > > > file pages preemptively and did cause a noticeable slowdown (~15%) for > > > that case; this patch set avoids that slowdown. Finally, the benefit > > > from avoiding cold starts is huge. The performance improvement from > > > having a hot start instead of a cold start ranges from 3x for very > > > small apps to 50x+ for larger apps like high-fidelity games. > > > > Is there any other real world scenario apart from this app based ecosystem > > where > > user hinted LRU management might be helpful ? Just being curious. Thanks > > for the > > detailed
Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use
On Tue, May 21, 2019 at 04:26:19PM -0700, Alexei Starovoitov wrote: > On Tue, May 21, 2019 at 05:36:49PM -0400, Kris Van Hees wrote: > > On Tue, May 21, 2019 at 01:55:34PM -0700, Alexei Starovoitov wrote: > > > On Tue, May 21, 2019 at 02:41:37PM -0400, Kris Van Hees wrote: > > > > On Tue, May 21, 2019 at 10:56:18AM -0700, Alexei Starovoitov wrote: > > > > > On Mon, May 20, 2019 at 11:47:00PM +, Kris Van Hees wrote: > > > > > > > > > > > > 2. bpf: add BPF_PROG_TYPE_DTRACE > > > > > > > > > > > > This patch adds BPF_PROG_TYPE_DTRACE as a new BPF program type, > > > > > > without > > > > > > actually providing an implementation. The actual > > > > > > implementation is > > > > > > added in patch 4 (see below). We do it this way because the > > > > > > implementation is being added to the tracing subsystem as a > > > > > > component > > > > > > that I would be happy to maintain (if merged) whereas the > > > > > > declaration > > > > > > of the program type must be in the bpf subsystem. Since the two > > > > > > subsystems are maintained by different people, we split the > > > > > > implementing patches across maintainer boundaries while > > > > > > ensuring that > > > > > > the kernel remains buildable between patches. > > > > > > > > > > None of these kernel patches are necessary for what you want to > > > > > achieve. > > > > > > > > I disagree. The current support for BPF programs for probes associates > > > > a > > > > specific BPF program type with a specific set of probes, which means > > > > that I > > > > cannot write BPF programs based on a more general concept of a 'DTrace > > > > probe' > > > > and provide functionality based on that. It also means that if I have > > > > a D > > > > clause (DTrace probe action code associated with probes) that is to be > > > > executed > > > > for a list of probes of different types, I need to duplicate the program > > > > because I cannot cross program type boundaries. > > > > > > tracepoint vs kprobe vs raw_tracepoint vs perf event work on different > > > input. > > > There is no common denominator to them that can serve as single 'generic' > > > context. > > > We're working on the concept of bpf libraries where different bpf program > > > with different types can call single bpf function with arbitrary > > > arguments. > > > This concept already works in bpf2bpf calls. We're working on extending it > > > to different program types. > > > You're more then welcome to help in that direction, > > > but type casting of tracepoint into kprobe is no go. > > > > I am happy to hear about the direction you are going in adding > > functionality. > > Please note though that I am not type casting tracepoint into kprobe or > > anything like that. I am making it possible to transfer execution from > > tracepoint, kprobe, raw-tracepoint, perf event, etc into a BPF program of > > a different type (BPF_PROG_TYPE_DTRACE) which operates as a general probe > > action execution program type. It provides functionality that is used to > > implement actions to be executed when a probe fires, independent of the > > actual probe type that fired. > > > > What you describe seems to me to be rather equivalent to what I already > > implement in my patch. > > except they're not. > you're converting to one new prog type only that no one else can use. > Whereas bpf infra is aiming to be as generic as possible and > fit networking, tracing, security use case all at once. Two points here... the patch that implements cross-prog type tail-call support is not specific to *any* specific prog type. Each prog type can specify which (if any) prog types is can receive calls from (and it can implement context conversion code to carry any relevant info from the caller context into the context for the callee). There is nothing in that patch that is specific to DTrace or any other prog type. Then I also introduce a new prog type (not tied to any specific probe type) to provide the ability to execute programs in a probe type independent context, and it makes use of the cross-prog-type tail-call support in order to be able to invoke programs in that probe-independent context from probe-specific BPF programs. And there is nothing that prevents anyone from using that new prog type as well - it is available for use just like any other prog type that already exists. But I am confused... the various probes you mentioned a few emails back (kprobe, tracepoint, raw_tracepoint, perf event) each have their own BPF program type associated with them (raw_tracepoint has two program types serving it), which doesn't sound very generic. But you are objecting to the introduction of a generic prog type that can be used to execute programs regardless of the probe type that caused the invocation because the bpf infrastructure is aimed at being as generic as possible. Could you elaborate on why you believe my patches are not adding generic features?
Re: [PATCH] arm64: dts: sdm845: Add CPU topology
On Thu 16 May 04:54 PDT 2019, Amit Kucheria wrote:
> (cc'ing Andy's correct email address)
>
> On Wed, May 15, 2019 at 2:46 AM Stephen Boyd wrote:
> >
> > Quoting Amit Kucheria (2019-05-13 04:54:12)
> > > On Mon, May 13, 2019 at 4:31 PM Amit Kucheria
> > > wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 12:13 AM Matthias Kaehlcke
> > > > wrote:
> > > > >
> > > > > The 8 CPU cores of the SDM845 are organized in two clusters of 4 big
> > > > > ("gold") and 4 little ("silver") cores. Add a cpu-map node to the DT
> > > > > that describes this topology.
> > > >
> > > > This is partly true. There are two groups of gold and silver cores,
> > > > but AFAICT they are in a single cluster, not two separate ones. SDM845
> > > > is one of the early examples of ARM's Dynamiq architecture.
> > > >
> > > > > Signed-off-by: Matthias Kaehlcke
> > > >
> > > > I noticed that this patch sneaked through for this merge window but
> > > > perhaps we can whip up a quick fix for -rc2?
> > > >
> > >
> > > And please find attached a patch to fix this up. Andy, since this
> > > hasn't landed yet (can we still squash this into the original patch?),
> > > I couldn't add a Fixes tag.
> > >
> >
> > I had the same concern. Thanks for catching this. I suspect this must
> > cause some problem for IPA given that it can't discern between the big
> > and little "power clusters"?
>
> Both EAS and IPA, I believe. It influences the scheduler's view of the
> the topology.
>
> > Either way,
> >
> > Reviewed-by: Stephen Boyd
>
> Thanks.
>
> Andy/Bjorn, can we squeeze this in for -rc2 as a bugfix?
>
Yes, I've picked this up among a few other fixes.
Regards,
Bjorn
Re: [PATCH v2 8/9] arm64: dts: qcom: sdm845: Add PSCI cpuidle low power states
On Tue 21 May 02:35 PDT 2019, Amit Kucheria wrote:
> From: "Raju P.L.S.S.S.N"
>
> Add device bindings for cpuidle states for cpu devices.
>
> Cc:
> Signed-off-by: Raju P.L.S.S.S.N
> Reviewed-by: Evan Green
> [amit: rename the idle-states to more generic names and fixups]
> Signed-off-by: Amit Kucheria
> Acked-by: Daniel Lezcano
> ---
Applied
Thanks,
Bjorn
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 69
> 1 file changed, 69 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 5308f1671824..a0ae6bf033ee 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -119,6 +119,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x0>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0
> _CPU_SLEEP_1 _SLEEP_0>;
> qcom,freq-domain = <_hw 0>;
> #cooling-cells = <2>;
> next-level-cache = <_0>;
> @@ -136,6 +137,8 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x100>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0
> _CPU_SLEEP_1
> +_SLEEP_0>;
> qcom,freq-domain = <_hw 0>;
> #cooling-cells = <2>;
> next-level-cache = <_100>;
> @@ -150,6 +153,8 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x200>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0
> _CPU_SLEEP_1
> +_SLEEP_0>;
> qcom,freq-domain = <_hw 0>;
> #cooling-cells = <2>;
> next-level-cache = <_200>;
> @@ -164,6 +169,8 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x300>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0
> _CPU_SLEEP_1
> +_SLEEP_0>;
> qcom,freq-domain = <_hw 0>;
> #cooling-cells = <2>;
> next-level-cache = <_300>;
> @@ -178,6 +185,8 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x400>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0 _CPU_SLEEP_1
> +_SLEEP_0>;
> qcom,freq-domain = <_hw 1>;
> #cooling-cells = <2>;
> next-level-cache = <_400>;
> @@ -192,6 +201,8 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x500>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0 _CPU_SLEEP_1
> +_SLEEP_0>;
> qcom,freq-domain = <_hw 1>;
> #cooling-cells = <2>;
> next-level-cache = <_500>;
> @@ -206,6 +217,8 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x600>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0 _CPU_SLEEP_1
> +_SLEEP_0>;
> qcom,freq-domain = <_hw 1>;
> #cooling-cells = <2>;
> next-level-cache = <_600>;
> @@ -220,6 +233,8 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x700>;
> enable-method = "psci";
> + cpu-idle-states = <_CPU_SLEEP_0 _CPU_SLEEP_1
> +_SLEEP_0>;
> qcom,freq-domain = <_hw 1>;
> #cooling-cells = <2>;
> next-level-cache = <_700>;
> @@ -228,6 +243,60 @@
> next-level-cache = <_0>;
> };
> };
> +
> + idle-states {
> + entry-method = "psci";
> +
> + LITTLE_CPU_SLEEP_0: cpu-sleep-0-0 {
> + compatible = "arm,idle-state";
> + idle-state-name = "little-power-down";
> + arm,psci-suspend-param = <0x4003>;
> + entry-latency-us = <350>;
> + exit-latency-us = <461>;
> + min-residency-us = <1890>;
> + local-timer-stop;
> + };
> +
> + LITTLE_CPU_SLEEP_1: cpu-sleep-0-1 {
> +
Re: [PATCH v2 9/9] arm64: dts: msm8996: Add proper capacity scaling for the cpus
On Tue 21 May 02:35 PDT 2019, Amit Kucheria wrote:
> msm8996 features 4 cpus - 2 in each cluster. However, all cpus implement
> the same microarchitecture and the two clusters only differ in the
> maximum frequency attainable by the CPUs.
>
> Add capacity-dmips-mhz property to allow the topology code to determine
> the actual capacity by taking into account the highest frequency for
> each CPU.
>
> Signed-off-by: Amit Kucheria
> Suggested-by: Daniel Lezcano
Applied
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 4f2fb7885f39..e0e8f30ce11a 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -96,6 +96,7 @@
> reg = <0x0 0x0>;
> enable-method = "psci";
> cpu-idle-states = <_SLEEP_0>;
> + capacity-dmips-mhz = <1024>;
> next-level-cache = <_0>;
> L2_0: l2-cache {
> compatible = "cache";
> @@ -109,6 +110,7 @@
> reg = <0x0 0x1>;
> enable-method = "psci";
> cpu-idle-states = <_SLEEP_0>;
> + capacity-dmips-mhz = <1024>;
> next-level-cache = <_0>;
> };
>
> @@ -118,6 +120,7 @@
> reg = <0x0 0x100>;
> enable-method = "psci";
> cpu-idle-states = <_SLEEP_0>;
> + capacity-dmips-mhz = <1024>;
> next-level-cache = <_1>;
> L2_1: l2-cache {
> compatible = "cache";
> @@ -131,6 +134,7 @@
> reg = <0x0 0x101>;
> enable-method = "psci";
> cpu-idle-states = <_SLEEP_0>;
> + capacity-dmips-mhz = <1024>;
> next-level-cache = <_1>;
> };
>
> --
> 2.17.1
>
Re: [PATCH v2 6/9] arm64: dts: qcom: msm8996: Add PSCI cpuidle low power states
On Tue 21 May 02:35 PDT 2019, Amit Kucheria wrote:
> Add device bindings for cpuidle states for cpu devices.
>
> msm8996 features 4 cpus - 2 in each cluster. However, all cpus implement
> the same microarchitecture and the two clusters only differ in the
> maximum frequency attainable by the CPUs.
>
> Signed-off-by: Amit Kucheria
Applied
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index c761269caf80..4f2fb7885f39 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -95,6 +95,7 @@
> compatible = "qcom,kryo";
> reg = <0x0 0x0>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> next-level-cache = <_0>;
> L2_0: l2-cache {
> compatible = "cache";
> @@ -107,6 +108,7 @@
> compatible = "qcom,kryo";
> reg = <0x0 0x1>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> next-level-cache = <_0>;
> };
>
> @@ -115,6 +117,7 @@
> compatible = "qcom,kryo";
> reg = <0x0 0x100>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> next-level-cache = <_1>;
> L2_1: l2-cache {
> compatible = "cache";
> @@ -127,6 +130,7 @@
> compatible = "qcom,kryo";
> reg = <0x0 0x101>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> next-level-cache = <_1>;
> };
>
> @@ -151,6 +155,19 @@
> };
> };
> };
> +
> + idle-states {
> + entry-method = "psci";
> +
> + CPU_SLEEP_0: cpu-sleep-0 {
> + compatible = "arm,idle-state";
> + idle-state-name = "standalone-power-collapse";
> + arm,psci-suspend-param = <0x0004>;
> + entry-latency-us = <40>;
> + exit-latency-us = <80>;
> + min-residency-us = <300>;
> + };
> + };
> };
>
> thermal-zones {
> --
> 2.17.1
>
Re: [PATCH] PCI / PM: Don't runtime suspend when device only supports wakeup from D0
at 6:23 AM, Bjorn Helgaas wrote:
[+cc Mathias, linux-usb]
On Wed, May 22, 2019 at 12:31:04AM +0800, Kai-Heng Feng wrote:
There's an xHC device that doesn't wake when a USB device gets plugged
to its USB port. The driver's own runtime suspend callback was called,
PME signaling was enabled, but it stays at PCI D0.
s/xHC/xHCI/ ?
This looks like it's fixing a bug? If so, please include a link to
the bug report, and make sure the bug report has "lspci -vv" output
attached to it.
Ok, I’ll update this in V2.
A PCI device can be runtime suspended to D0 when it supports D0 PME and
its _S0W reports D0. Theoratically this should work, but as [1]
specifies, D0 doesn't have wakeup capability.
s/Theoratically/Theoretically/
Ok.
What does "runtime suspended to D0" mean?
It’s runtime suspended by PCI core, but stays at D0.
Is that different from the regular "device is fully operational" sort of D0?
Yes it's different to that.
Because of _S0W reports D0 and the device has D0 PME support, so it’s
“suspended” to D0:
00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB
XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
Subsystem: Dell FCH USB XHCI Controller [1028:096c]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
If so, what
distinguishes "runtime suspended D0" from "normal fully operational
D0”?
The xHC’s own runtime suspend routine is called, but PCI core’s runtime
suspend routine decides it should stay at D0.
So it’s technically runtime suspended to D0.
Kai-Heng
To avoid this problematic situation, we should avoid runtime suspend if
D0 is the only state that can wake up the device.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/device-working-state-d0
Signed-off-by: Kai-Heng Feng
---
drivers/pci/pci-driver.c | 5 +
drivers/pci/pci.c| 2 +-
include/linux/pci.h | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index cae630fe6387..15a6310c5d7b 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1251,6 +1251,11 @@ static int pci_pm_runtime_suspend(struct device
*dev)
return 0;
}
+ if (pci_target_state(pci_dev, device_can_wakeup(dev)) == PCI_D0) {
+ dev_dbg(dev, "D0 doesn't have wakeup capability\n");
+ return -EBUSY;
+ }
+
pci_dev->state_saved = false;
if (pm && pm->runtime_suspend) {
error = pm->runtime_suspend(dev);
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8abc843b1615..ceee6efbbcfe 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2294,7 +2294,7 @@ EXPORT_SYMBOL(pci_wake_from_d3);
* If the platform can't manage @dev, return the deepest state from which it
* can generate wake events, based on any available PME info.
*/
-static pci_power_t pci_target_state(struct pci_dev *dev, bool wakeup)
+pci_power_t pci_target_state(struct pci_dev *dev, bool wakeup)
{
pci_power_t target_state = PCI_D3hot;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 4a5a84d7bdd4..91e8dc4d04aa 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1188,6 +1188,7 @@ bool pci_pme_capable(struct pci_dev *dev,
pci_power_t state);
void pci_pme_active(struct pci_dev *dev, bool enable);
int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable);
int pci_wake_from_d3(struct pci_dev *dev, bool enable);
+pci_power_t pci_target_state(struct pci_dev *dev, bool wakeup);
int pci_prepare_to_sleep(struct pci_dev *dev);
int pci_back_from_sleep(struct pci_dev *dev);
bool pci_dev_run_wake(struct pci_dev *dev);
@@ -1672,6 +1673,8 @@ static inline int pci_set_power_state(struct
pci_dev *dev, pci_power_t state)
{ return 0; }
static inline int pci_wake_from_d3(struct pci_dev *dev, bool enable)
{ return 0; }
+pci_power_t pci_target_state(struct pci_dev *dev, bool wakeup)
+{ return PCI_D0; }
static inline pci_power_t pci_choose_state(struct pci_dev *dev,
pm_message_t state)
{ return PCI_D0; }
--
2.17.1
linux-next: Tree for May 22
Hi all, Changes since 20190521: The imx-mxs tree lost its build failure. The scsi tree gained conflicts against Linus' tree. The pidfd tree gained a conflict against Linus' tree. The akpm-current tree gained a conflict against the pidfd tree. Non-merge commits (relative to Linus' tree): 1426 1472 files changed, 43462 insertions(+), 28147 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 290 trees (counting Linus' and 70 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (9c7db5004280 Merge tag 'selinux-pr-20190521' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux) Merging fixes/master (2bbacd1a9278 Merge tag 'kconfig-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kspp-gustavo/for-next/kspp (d979d4a47db7 firewire: mark expected switch fall-throughs) Merging kbuild-current/fixes (5bdd9ad875b6 Merge tag 'kbuild-fixes-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging arc-current/for-curr (4c70850aeb2e ARC: [plat-hsdk]: Add missing FIFO size entry in GMAC node) Merging arm-current/fixes (e17b1af96b2a ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache) Merging arm64-fixes/for-next/fixes (7a0a93c51799 arm64: vdso: Explicitly add build-id option) Merging m68k-current/for-linus (fdd20ec8786a Documentation/features/time: Mark m68k having modern-timekeeping) Merging powerpc-fixes/fixes (672eaf37db9f powerpc/cacheinfo: Remove double free) Merging sparc/master (f49aa1de9836 Merge tag 'for-5.2-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (34632975cafd selftests: fib_rule_tests: use pre-defined DEV_ADDR) Merging bpf/master (a195cefff49f samples, bpf: suppress compiler warning) Merging ipsec/master (af8f3fb7fb07 net: stmmac: dma channel control register need to be init first) Merging netfilter/master (6bac76db1da3 netfilter: nat: fix udp checksum corruption) Merging ipvs/master (e633508a9528 netfilter: nft_fib: Fix existence check support) Merging wireless-drivers/master (7a0f8ad5ff63 Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git) Merging mac80211/master (933b40530b4b mac80211: remove set but not used variable 'old') Merging rdma-fixes/for-rc (a188339ca5a3 Linux 5.2-rc1) Merging sound-current/for-linus (c7b55fabfa44 ALSA: hdac: fix memory release for SST and SOF drivers) Merging sound-asoc-fixes/for-linus (12bb37a10514 Merge branch 'asoc-5.2' into asoc-linus) Merging regmap-fixes/for-linus (38ee2a8cc70e Merge branch 'regmap-5.2' into regmap-linus) Merging regulator-fixes/for-linus (41a585c947de Merge branch 'regulator-5.2' into regulator-linus) Merging spi-fixes/for-linus (e99091799f09 Merge branch 'spi-5.2' into spi-linus) Merging pci-current/for-linus (a188339ca5a3 Linux 5.2-rc1) Merging driver-core.current/driver-core-linus (a188339ca5a3 Linux 5.2-rc1) Merging tty.current/tty-linus (5d24f455c182 tty: max310x: Fix external crystal register setup) Merging usb.current/usb-linus (53c7b63f797c USB: rio500: update Documentation) Merging usb-gadget-fixes/fixes (072684e8c58d USB: gadget: f_hid: fix deadlock in f_hidg_write()
Re: [PATCH v5 4/6] usb: roles: add API to get usb_role_switch by node
On Tue, 2019-05-21 at 13:33 +0300, Heikki Krogerus wrote:
> On Tue, May 21, 2019 at 03:35:04PM +0800, Chunfeng Yun wrote:
> > Hi,
> > On Mon, 2019-05-20 at 09:45 +, Biju Das wrote:
> > >
> > > Hi Heikki,
> > >
> > > Thanks for the feedback.
> > >
> > > > Subject: Re: [PATCH v5 4/6] usb: roles: add API to get usb_role_switch
> > > > by
> > > > node
> > > >
> > > > On Mon, May 20, 2019 at 08:06:41AM +, Biju Das wrote:
> > > > > Hi Heikki,
> > > > >
> > > > > > Subject: Re: [PATCH v5 4/6] usb: roles: add API to get
> > > > > > usb_role_switch by node
> > > > > >
> > > > > > On Mon, May 20, 2019 at 10:39:11AM +0800, Chunfeng Yun wrote:
> > > > > > > Hi,
> > > > > > > On Fri, 2019-05-17 at 16:05 +0300, Heikki Krogerus wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Fri, May 17, 2019 at 01:37:36PM +0300, Heikki Krogerus wrote:
> > > > > > > > > On Tue, May 14, 2019 at 04:47:21PM +0800, Chunfeng Yun wrote:
> > > > > > > > > > Add fwnode_usb_role_switch_get() to make easier to get
> > > > > > > > > > usb_role_switch by fwnode which register it.
> > > > > > > > > > It's useful when there is not device_connection registered
> > > > > > > > > > between two drivers and only knows the fwnode which register
> > > > > > > > > > usb_role_switch.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Chunfeng Yun
> > > > > > > > > > Tested-by: Biju Das
> > > > > > > > >
> > > > > > > > > Acked-by: Heikki Krogerus
> > > > > > > >
> > > > > > > > Hold on. I just noticed Rob's comment on patch 2/6, where he
> > > > > > > > points out that you don't need to use device graph since the
> > > > > > > > controller is the parent of the connector. Doesn't that mean you
> > > > > > > > don't really need this API?
> > > > > > > No, I still need it.
> > > > > > > The change is about the way how to get fwnode; when use device
> > > > > > > graph, get fwnode by of_graph_get_remote_node(); but now will get
> > > > > > > fwnode by of_get_parent();
> > > > > >
> > > > > > OK, I get that, but I'm still not convinced about if something like
> > > > > > this function is needed at all. I also have concerns regarding how
> > > > > > you are using the function. I'll explain in comment to the patch
> > > > > > 5/6 in this
> > > > series...
> > > > >
> > > > > FYI, Currently I am also using this api in my patch series.
> > > > > https://patchwork.kernel.org/patch/10944637/
> > > >
> > > > Yes, and I have the same question for you I jusb asked in comment I
> > > > added
> > > > to the patch 5/6 of this series. Why isn't usb_role_switch_get() enough?
> > >
> > > Currently no issue. It will work with this api as well, since the port
> > > node is part of controller node.
> > > For eg:-
> > > https://patchwork.kernel.org/patch/10944627/
> > >
> > > However if any one adds port node inside the connector node, then this
> > > api may won't work as expected.
> > > Currently I get below error
> > >
> > > [2.299703] OF: graph: no port node found in
> > > /soc/i2c@e650/hd3ss3220@47
> > >
> > > For eg:-
> > >
> > > hd3ss3220@47 {
> > > compatible = "ti,hd3ss3220";
> > > ...
> > >
> > > usb_con: connector {
> > >
> > >
> > > port {
> > > hd3ss3220_ep: endpoint@0 {
> > > reg = <0>;
> > > remote-endpoint =
> > > <_role_switch>;
> > > };
> > > };
> > > };
> > > };
> > >
> > > Regards,
> > > Biju
> >
> > I tested 3 cases:
> >
> > case 1:
> >
> > connector {
> > compatible = "linux,typeb-conn-gpio", "usb-b-connector";
> > label = "micro-USB";
> > type = "micro";
> > id-gpios = < 12 GPIO_ACTIVE_HIGH>;
> > vbus-supply = <_p0_vbus>;
> >
> > port {
> > bconn_ep: endpoint@0 {
> > remote-endpoint = <_role_sw>;
> > };
> > };
> > };
> >
> > {
> > usb-role-switch;
> >
> > port {
> > usb_role_sw: endpoint@0 {
> > remote-endpoint = <_ep>;
> > };
> > };
> > };
> >
> > the driver of connector could use usb_role_switch_get(dev) to get
> > mtu3's USB Role Switch. (dev is the device of connector)
> >
> > case 2:
> >
> > {
> > usb-role-switch;
> >
> > connector {
> > compatible = "linux,typeb-conn-gpio", "usb-b-connector";
> > label = "micro-USB";
> > type = "micro";
> > id-gpios = < 12 GPIO_ACTIVE_HIGH>;
> > vbus-supply = <_p0_vbus>;
> > };
> > };
> >
> > the driver of connector using usb_role_switch_get(dev) failed to get
> > mtu3's USB Role Switch.
> > error log:
> > #OF: graph: no port node found in /usb@11271000/connector
> > this is because connector hasn't child node connected to remote
> > endpoint which register USB Role Switch
> >
> > case 3:
> >
> > rsw_iddig:
Re: [PATCH v2 5/9] arm64: dts: qcom: qcs404: Add PSCI cpuidle low power states
On Tue 21 May 02:35 PDT 2019, Amit Kucheria wrote:
> From: Niklas Cassel
>
> Add device bindings for cpuidle states for cpu devices.
>
> Signed-off-by: Niklas Cassel
> Reviewed-by: Vinod Koul
> [rename the idle-states to more generic names and fixups]
> Signed-off-by: Amit Kucheria
> Acked-by: Daniel Lezcano
> ---
Applied
Regards,
Bjorn
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> index e8fd26633d57..0a9b29af64c2 100644
> --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> @@ -30,6 +30,7 @@
> compatible = "arm,cortex-a53";
> reg = <0x100>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> next-level-cache = <_0>;
> };
>
> @@ -38,6 +39,7 @@
> compatible = "arm,cortex-a53";
> reg = <0x101>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> next-level-cache = <_0>;
> };
>
> @@ -46,6 +48,7 @@
> compatible = "arm,cortex-a53";
> reg = <0x102>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> next-level-cache = <_0>;
> };
>
> @@ -54,6 +57,7 @@
> compatible = "arm,cortex-a53";
> reg = <0x103>;
> enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> next-level-cache = <_0>;
> };
>
> @@ -61,6 +65,20 @@
> compatible = "cache";
> cache-level = <2>;
> };
> +
> + idle-states {
> + entry-method = "psci";
> +
> + CPU_SLEEP_0: cpu-sleep-0 {
> + compatible = "arm,idle-state";
> + idle-state-name = "standalone-power-collapse";
> + arm,psci-suspend-param = <0x4003>;
> + entry-latency-us = <125>;
> + exit-latency-us = <180>;
> + min-residency-us = <595>;
> + local-timer-stop;
> + };
> + };
> };
>
> firmware {
> --
> 2.17.1
>
Re: [PATCH v2 4/9] arm64: dts: qcom: msm8916: Use more generic idle state names
On Tue 21 May 02:35 PDT 2019, Amit Kucheria wrote:
> Instead of using Qualcomm-specific terminology, use generic node names
> for the idle states that are easier to understand. Move the description
> into the "idle-state-name" property.
>
> Signed-off-by: Amit Kucheria
> Reviewed-by: Niklas Cassel
> Acked-by: Daniel Lezcano
> ---
Picked up
Regards,
Bjorn
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 82ea5b8b37a2..3a8c6c4fcf15 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -110,7 +110,7 @@
> reg = <0x0>;
> next-level-cache = <_0>;
> enable-method = "psci";
> - cpu-idle-states = <_SPC>;
> + cpu-idle-states = <_SLEEP_0>;
> clocks = <>;
> operating-points-v2 = <_opp_table>;
> #cooling-cells = <2>;
> @@ -122,7 +122,7 @@
> reg = <0x1>;
> next-level-cache = <_0>;
> enable-method = "psci";
> - cpu-idle-states = <_SPC>;
> + cpu-idle-states = <_SLEEP_0>;
> clocks = <>;
> operating-points-v2 = <_opp_table>;
> #cooling-cells = <2>;
> @@ -134,7 +134,7 @@
> reg = <0x2>;
> next-level-cache = <_0>;
> enable-method = "psci";
> - cpu-idle-states = <_SPC>;
> + cpu-idle-states = <_SLEEP_0>;
> clocks = <>;
> operating-points-v2 = <_opp_table>;
> #cooling-cells = <2>;
> @@ -146,7 +146,7 @@
> reg = <0x3>;
> next-level-cache = <_0>;
> enable-method = "psci";
> - cpu-idle-states = <_SPC>;
> + cpu-idle-states = <_SLEEP_0>;
> clocks = <>;
> operating-points-v2 = <_opp_table>;
> #cooling-cells = <2>;
> @@ -160,8 +160,9 @@
> idle-states {
> entry-method = "psci";
>
> - CPU_SPC: spc {
> + CPU_SLEEP_0: cpu-sleep-0 {
> compatible = "arm,idle-state";
> + idle-state-name = "standalone-power-collapse";
> arm,psci-suspend-param = <0x4002>;
> entry-latency-us = <130>;
> exit-latency-us = <150>;
> --
> 2.17.1
>
Re: [PATCH v2 3/9] arm64: dts: qcom: msm8916: Add entry-method property for the idle-states node
On Tue 21 May 02:35 PDT 2019, Amit Kucheria wrote:
> The idle-states binding documentation[1] mentions that the
> 'entry-method' property is required on 64-bit platforms and must be set
> to "psci".
>
> [1] Documentation/devicetree/bindings/arm/idle-states.txt (see
> idle-states node)
>
> Signed-off-by: Amit Kucheria
> Reviewed-by: Niklas Cassel
> Acked-by: Daniel Lezcano
Picked up
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 0803ca8c02da..82ea5b8b37a2 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -158,6 +158,8 @@
> };
>
> idle-states {
> + entry-method = "psci";
> +
> CPU_SPC: spc {
> compatible = "arm,idle-state";
> arm,psci-suspend-param = <0x4002>;
> --
> 2.17.1
>
[PATCH] tick/sched: Drop duplicated tick_sched.inidle
It is set before entering idle and cleared when quitting idle, though
it seems to be a complete duplicate of tick_sched.idle_active. We
should probably be able to use any one of them to replace the other.
CC: Frederic Weisbecker
CC: Thomas Gleixner
CC: Ingo Molnar
CC: linux-kernel@vger.kernel.org
Signed-off-by: Peter Xu
---
kernel/time/tick-sched.c | 11 ---
kernel/time/tick-sched.h | 3 +--
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index f4ee1a3428ae..6bb5ad03e962 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -137,7 +137,7 @@ static void tick_sched_do_timer(struct tick_sched *ts,
ktime_t now)
if (tick_do_timer_cpu == cpu)
tick_do_update_jiffies64(now);
- if (ts->inidle)
+ if (ts->idle_active)
ts->got_idle_tick = 1;
}
@@ -534,7 +534,6 @@ static void tick_nohz_stop_idle(struct tick_sched *ts,
ktime_t now)
{
update_ts_time_stats(smp_processor_id(), ts, now, NULL);
ts->idle_active = 0;
-
sched_clock_idle_wakeup_event();
}
@@ -999,7 +998,6 @@ void tick_nohz_idle_enter(void)
WARN_ON_ONCE(ts->timer_expires_base);
- ts->inidle = 1;
tick_nohz_start_idle(ts);
local_irq_enable();
@@ -1017,7 +1015,7 @@ void tick_nohz_irq_exit(void)
{
struct tick_sched *ts = this_cpu_ptr(_cpu_sched);
- if (ts->inidle)
+ if (ts->idle_active)
tick_nohz_start_idle(ts);
else
tick_nohz_full_update_tick(ts);
@@ -1067,7 +1065,7 @@ ktime_t tick_nohz_get_sleep_length(ktime_t *delta_next)
ktime_t now = ts->idle_entrytime;
ktime_t next_event;
- WARN_ON_ONCE(!ts->inidle);
+ WARN_ON_ONCE(!ts->idle_active);
*delta_next = ktime_sub(dev->next_event, now);
@@ -1163,10 +1161,9 @@ void tick_nohz_idle_exit(void)
local_irq_disable();
- WARN_ON_ONCE(!ts->inidle);
+ WARN_ON_ONCE(!ts->idle_active);
WARN_ON_ONCE(ts->timer_expires_base);
- ts->inidle = 0;
idle_active = ts->idle_active;
tick_stopped = ts->tick_stopped;
diff --git a/kernel/time/tick-sched.h b/kernel/time/tick-sched.h
index 4fb06527cf64..ae9335d019f0 100644
--- a/kernel/time/tick-sched.h
+++ b/kernel/time/tick-sched.h
@@ -31,7 +31,7 @@ enum tick_nohz_mode {
* @idle_active: Indicator that the CPU is actively in the tick idle
mode;
* it is resetted during irq handling phases.
* @do_timer_lst: CPU was the last one doing do_timer before going idle
- * @got_idle_tick: Tick timer function has run with @inidle set
+ * @got_idle_tick: Tick timer function has run with @idle_active set
* @last_tick: Store the last tick expiry time when the tick
* timer is modified for nohz sleeps. This is necessary
* to resume the tick timer operation in the timeline
@@ -55,7 +55,6 @@ struct tick_sched {
unsigned long check_clocks;
enum tick_nohz_mode nohz_mode;
- unsigned intinidle : 1;
unsigned inttick_stopped: 1;
unsigned intidle_active : 1;
unsigned intdo_timer_last : 1;
--
2.17.1
[V3 1/2] dmaengine: fsl-qdma: fixed the source/destination descriptor format
CMD of Source/Destination descriptor format should be lower of
struct fsl_qdma_engine number data address.
Signed-off-by: Peng Ma
---
changed for V3:
- Delete macro to simplify code.
drivers/dma/fsl-qdma.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
index aa1d0ae..da8fdf5 100644
--- a/drivers/dma/fsl-qdma.c
+++ b/drivers/dma/fsl-qdma.c
@@ -113,6 +113,7 @@
/* Field definition for Descriptor offset */
#define QDMA_CCDF_STATUS 20
#define QDMA_CCDF_OFFSET 20
+#define QDMA_SDDF_CMD(x) (((u64)(x)) << 32)
/* Field definition for safe loop count*/
#define FSL_QDMA_HALT_COUNT1500
@@ -341,6 +342,7 @@ static void fsl_qdma_free_chan_resources(struct dma_chan
*chan)
static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
dma_addr_t dst, dma_addr_t src, u32 len)
{
+ u32 cmd;
struct fsl_qdma_format *sdf, *ddf;
struct fsl_qdma_format *ccdf, *csgf_desc, *csgf_src, *csgf_dest;
@@ -369,14 +371,14 @@ static void fsl_qdma_comp_fill_memcpy(struct
fsl_qdma_comp *fsl_comp,
/* This entry is the last entry. */
qdma_csgf_set_f(csgf_dest, len);
/* Descriptor Buffer */
- sdf->data =
- cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
- FSL_QDMA_CMD_RWTTYPE_OFFSET);
- ddf->data =
- cpu_to_le64(FSL_QDMA_CMD_RWTTYPE <<
- FSL_QDMA_CMD_RWTTYPE_OFFSET);
- ddf->data |=
- cpu_to_le64(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
+ cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
+ FSL_QDMA_CMD_RWTTYPE_OFFSET);
+ sdf->data = QDMA_SDDF_CMD(cmd);
+
+ cmd = cpu_to_le32(FSL_QDMA_CMD_RWTTYPE <<
+ FSL_QDMA_CMD_RWTTYPE_OFFSET);
+ cmd |= cpu_to_le32(FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
+ ddf->data = QDMA_SDDF_CMD(cmd);
}
/*
--
1.7.1
[V3 2/2] dmaengine: fsl-qdma: Add improvement
When an error occurs we should clean the error register then to return
Signed-off-by: Peng Ma
---
changed for V3:
- no changed.
drivers/dma/fsl-qdma.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
index da8fdf5..8e341c0 100644
--- a/drivers/dma/fsl-qdma.c
+++ b/drivers/dma/fsl-qdma.c
@@ -703,10 +703,8 @@ static irqreturn_t fsl_qdma_error_handler(int irq, void
*dev_id)
intr = qdma_readl(fsl_qdma, status + FSL_QDMA_DEDR);
- if (intr) {
+ if (intr)
dev_err(fsl_qdma->dma_dev.dev, "DMA transaction error!\n");
- return IRQ_NONE;
- }
qdma_writel(fsl_qdma, FSL_QDMA_DEDR_CLEAR, status + FSL_QDMA_DEDR);
return IRQ_HANDLED;
--
1.7.1
Re: [v3 PATCH 2/2] mm: vmscan: correct some vmscan counters for THP swapout
On 5/22/19 9:23 AM, Huang, Ying wrote:
Yang Shi writes:
Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
and some other vm counters still get inc'ed by one even though a whole
THP (512 pages) gets swapped out.
This doesn't make too much sense to memory reclaim. For example, direct
reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
could fulfill it. But, if nr_reclaimed is not increased correctly,
direct reclaim may just waste time to reclaim more pages,
SWAP_CLUSTER_MAX * 512 pages in worst case.
And, it may cause pgsteal_{kswapd|direct} is greater than
pgscan_{kswapd|direct}, like the below:
pgsteal_kswapd 122933
pgsteal_direct 26600225
pgscan_kswapd 174153
pgscan_direct 14678312
nr_reclaimed and nr_scanned must be fixed in parallel otherwise it would
break some page reclaim logic, e.g.
vmpressure: this looks at the scanned/reclaimed ratio so it won't
change semantics as long as scanned & reclaimed are fixed in parallel.
compaction/reclaim: compaction wants a certain number of physical pages
freed up before going back to compacting.
kswapd priority raising: kswapd raises priority if we scan fewer pages
than the reclaim target (which itself is obviously expressed in order-0
pages). As a result, kswapd can falsely raise its aggressiveness even
when it's making great progress.
Other than nr_scanned and nr_reclaimed, some other counters, e.g.
pgactivate, nr_skipped, nr_ref_keep and nr_unmap_fail need to be fixed
too since they are user visible via cgroup, /proc/vmstat or trace
points, otherwise they would be underreported.
When isolating pages from LRUs, nr_taken has been accounted in base
page, but nr_scanned and nr_skipped are still accounted in THP. It
doesn't make too much sense too since this may cause trace point
underreport the numbers as well.
So accounting those counters in base page instead of accounting THP as
one page.
This change may result in lower steal/scan ratio in some cases since
THP may get split during page reclaim, then a part of tail pages get
reclaimed instead of the whole 512 pages, but nr_scanned is accounted
by 512, particularly for direct reclaim. But, this should be not a
significant issue.
Cc: "Huang, Ying"
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Mel Gorman
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Cc: Shakeel Butt
Signed-off-by: Yang Shi
---
v3: Removed Shakeel's Reviewed-by since the patch has been changed significantly
Switched back to use compound_order per Matthew
Fixed more counters per Johannes
v2: Added Shakeel's Reviewed-by
Use hpage_nr_pages instead of compound_order per Huang Ying and William
Kucharski
mm/vmscan.c | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b65bc50..1044834 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1250,7 +1250,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
case PAGEREF_ACTIVATE:
goto activate_locked;
case PAGEREF_KEEP:
- stat->nr_ref_keep++;
+ stat->nr_ref_keep += (1 << compound_order(page));
goto keep_locked;
case PAGEREF_RECLAIM:
case PAGEREF_RECLAIM_CLEAN:
@@ -1294,6 +1294,17 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
goto activate_locked;
}
+/*
+* Account all tail pages when THP is added
+* into swap cache successfully.
+* The head page has been accounted at the
+* first place.
+*/
+ if (PageTransHuge(page))
+ sc->nr_scanned +=
+ ((1 << compound_order(page)) -
+ 1);
+
The "if" here could be changed to "else if" because if add_to_swap()
fails we don't need to call PageTransHuge() here. But this isn't a big
deal.
This could be moved to the beginning according to Johannes.
You have analyzed the code and found that nr_dirty, nr_unqueued_dirty,
nr_congested and nr_writeback are file cache related and not impacted by
THP swap out. How about add your findings in the patch description?
Yes, sure. Will add in v4.
Best Regards,
Huang, Ying
Re: [v3 PATCH 2/2] mm: vmscan: correct some vmscan counters for THP swapout
On 5/22/19 12:00 AM, Johannes Weiner wrote:
On Tue, May 21, 2019 at 05:40:42PM +0800, Yang Shi wrote:
Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
and some other vm counters still get inc'ed by one even though a whole
THP (512 pages) gets swapped out.
This doesn't make too much sense to memory reclaim. For example, direct
reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
could fulfill it. But, if nr_reclaimed is not increased correctly,
direct reclaim may just waste time to reclaim more pages,
SWAP_CLUSTER_MAX * 512 pages in worst case.
And, it may cause pgsteal_{kswapd|direct} is greater than
pgscan_{kswapd|direct}, like the below:
pgsteal_kswapd 122933
pgsteal_direct 26600225
pgscan_kswapd 174153
pgscan_direct 14678312
nr_reclaimed and nr_scanned must be fixed in parallel otherwise it would
break some page reclaim logic, e.g.
vmpressure: this looks at the scanned/reclaimed ratio so it won't
change semantics as long as scanned & reclaimed are fixed in parallel.
compaction/reclaim: compaction wants a certain number of physical pages
freed up before going back to compacting.
kswapd priority raising: kswapd raises priority if we scan fewer pages
than the reclaim target (which itself is obviously expressed in order-0
pages). As a result, kswapd can falsely raise its aggressiveness even
when it's making great progress.
Other than nr_scanned and nr_reclaimed, some other counters, e.g.
pgactivate, nr_skipped, nr_ref_keep and nr_unmap_fail need to be fixed
too since they are user visible via cgroup, /proc/vmstat or trace
points, otherwise they would be underreported.
When isolating pages from LRUs, nr_taken has been accounted in base
page, but nr_scanned and nr_skipped are still accounted in THP. It
doesn't make too much sense too since this may cause trace point
underreport the numbers as well.
So accounting those counters in base page instead of accounting THP as
one page.
This change may result in lower steal/scan ratio in some cases since
THP may get split during page reclaim, then a part of tail pages get
reclaimed instead of the whole 512 pages, but nr_scanned is accounted
by 512, particularly for direct reclaim. But, this should be not a
significant issue.
Cc: "Huang, Ying"
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Mel Gorman
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Cc: Shakeel Butt
Signed-off-by: Yang Shi
---
v3: Removed Shakeel's Reviewed-by since the patch has been changed significantly
Switched back to use compound_order per Matthew
Fixed more counters per Johannes
v2: Added Shakeel's Reviewed-by
Use hpage_nr_pages instead of compound_order per Huang Ying and William
Kucharski
mm/vmscan.c | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b65bc50..1044834 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1250,7 +1250,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
case PAGEREF_ACTIVATE:
goto activate_locked;
case PAGEREF_KEEP:
- stat->nr_ref_keep++;
+ stat->nr_ref_keep += (1 << compound_order(page));
goto keep_locked;
case PAGEREF_RECLAIM:
case PAGEREF_RECLAIM_CLEAN:
@@ -1294,6 +1294,17 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
goto activate_locked;
}
+/*
+* Account all tail pages when THP is added
+* into swap cache successfully.
+* The head page has been accounted at the
+* first place.
+*/
+ if (PageTransHuge(page))
+ sc->nr_scanned +=
+ ((1 << compound_order(page)) -
+ 1);
+
may_enter_fs = 1;
Even if we don't split and reclaim the page, we should always account
the number of base pages in nr_scanned. Otherwise it's not clear what
nr_scanned means.
Sure.
/* Adding to swap updated mapping */
@@ -1315,7 +1326,8 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
if (unlikely(PageTransHuge(page)))
flags |= TTU_SPLIT_HUGE_PMD;
if (!try_to_unmap(page, flags)) {
- stat->nr_unmap_fail++;
+ stat->nr_unmap_fail +=
+ (1 << compound_order(page));
Re: [PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel
On 05/22/19 at 11:20am, Dave Young wrote: > On 05/09/19 at 09:36am, Baoquan He wrote: > > If the running kernel has 5-level paging activated, the 5-level paging > > mode is preserved across kexec. If the kexec'ed kernel does not contain > > support for handling active 5-level paging mode in the decompressor, the > > decompressor will crash with #GP. > > > > Prevent this situation at load time. If 5-level paging is active, check the > > xloadflags whether the kexec kernel can handle 5-level paging at least in > > the decompressor. If not, reject the load attempt and print out error > > message. > > > > Signed-off-by: Baoquan He > > Acked-by: Kirill A. Shutemov > > --- > > arch/x86/kernel/kexec-bzimage64.c | 5 + > > How about the userspace kexec-tools? It needs a similar detection, but > I'm not sure how to detect paging mode, maybe some sysfs entry or > vmcoreinfo in /proc/vmcore meant /proc/kcore ... Thanks Dave
[PATCH v2] signal: Adjust error codes according to restore_user_sigmask()
A regression caused by 854a6ed56839 ("signal: Add restore_user_sigmask()")
caused users of epoll_pwait, io_pgetevents, and ppoll to notice a
latent problem in signal handling during these syscalls.
That patch (854a6ed56839) moved the signal_pending() check closer
to restoring of the user sigmask. But, it failed to update the error
code accordingly. From the userspace perspective, the patch increased
the time window for the signal discovery and subsequent delivery to the
userspace, but did not always adjust the errno afterwards. The behavior
before 854a6ed56839a was that the signals were dropped after the error
code was decided. This resulted in lost signals but the userspace did not
notice it as the syscalls had finished executing the core functionality
and the error codes returned notified success.
For all the syscalls that receive a sigmask from the userland,
the user sigmask is to be in effect through the syscall execution.
At the end of syscall, sigmask of the current process is restored
to what it was before the switch over to user sigmask.
But, for this to be true in practice, the sigmask should be restored
only at the the point we change the saved_sigmask. Anything before
that loses signals. And, anything after is just pointless as the
signal is already lost by restoring the sigmask.
Detailed issue discussion permalink:
https://lore.kernel.org/linux-fsdevel/20190427093319.sgicqik2oqkez3wk@dcvr/
Note that this patch returns interrupted errors (EINTR, ERESTARTNOHAND,
etc) only when there is no other error. If there is a signal and an error
like EINVAL, the syscalls return -EINVAL rather than the interrupted
error codes.
Reported-by: Eric Wong
Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
restore_user_sigmask()")
Signed-off-by: Deepa Dinamani
Cc: # 5.0.x
Cc: # 5.1.x
---
Changes since v1:
* updated the commit text for more context of the pre-existing condition
* added stable tags as requested
fs/aio.c | 24
fs/eventpoll.c | 14 ++
fs/io_uring.c | 7 +--
fs/select.c| 37 +
include/linux/signal.h | 2 +-
kernel/signal.c| 13 ++---
6 files changed, 59 insertions(+), 38 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 3490d1fa0e16..ebd2b1980161 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -2095,7 +2095,7 @@ SYSCALL_DEFINE6(io_pgetevents,
struct __aio_sigset ksig = { NULL, };
sigset_tksigmask, sigsaved;
struct timespec64 ts;
- int ret;
+ int ret, signal_detected;
if (timeout && unlikely(get_timespec64(, timeout)))
return -EFAULT;
@@ -2108,8 +2108,8 @@ SYSCALL_DEFINE6(io_pgetevents,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
- restore_user_sigmask(ksig.sigmask, );
- if (signal_pending(current) && !ret)
+ signal_detected = restore_user_sigmask(ksig.sigmask, );
+ if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2128,7 +2128,7 @@ SYSCALL_DEFINE6(io_pgetevents_time32,
struct __aio_sigset ksig = { NULL, };
sigset_tksigmask, sigsaved;
struct timespec64 ts;
- int ret;
+ int ret, signal_detected;
if (timeout && unlikely(get_old_timespec32(, timeout)))
return -EFAULT;
@@ -2142,8 +2142,8 @@ SYSCALL_DEFINE6(io_pgetevents_time32,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
- restore_user_sigmask(ksig.sigmask, );
- if (signal_pending(current) && !ret)
+ signal_detected = restore_user_sigmask(ksig.sigmask, );
+ if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2193,7 +2193,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents,
struct __compat_aio_sigset ksig = { NULL, };
sigset_t ksigmask, sigsaved;
struct timespec64 t;
- int ret;
+ int ret, signal_detected;
if (timeout && get_old_timespec32(, timeout))
return -EFAULT;
@@ -2206,8 +2206,8 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents,
return ret;
ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? : NULL);
- restore_user_sigmask(ksig.sigmask, );
- if (signal_pending(current) && !ret)
+ signal_detected = restore_user_sigmask(ksig.sigmask, );
+ if (signal_detected && !ret)
ret = -ERESTARTNOHAND;
return ret;
@@ -2226,7 +2226,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents_time64,
struct __compat_aio_sigset ksig = { NULL, };
sigset_t ksigmask, sigsaved;
struct timespec64 t;
- int ret;
+ int ret, signal_detected;
if (timeout && get_timespec64(, timeout))
return -EFAULT;
@@ -2239,8 +2239,8 @@
Re: [PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel
On 05/09/19 at 09:36am, Baoquan He wrote:
> If the running kernel has 5-level paging activated, the 5-level paging
> mode is preserved across kexec. If the kexec'ed kernel does not contain
> support for handling active 5-level paging mode in the decompressor, the
> decompressor will crash with #GP.
>
> Prevent this situation at load time. If 5-level paging is active, check the
> xloadflags whether the kexec kernel can handle 5-level paging at least in
> the decompressor. If not, reject the load attempt and print out error
> message.
>
> Signed-off-by: Baoquan He
> Acked-by: Kirill A. Shutemov
> ---
> arch/x86/kernel/kexec-bzimage64.c | 5 +
How about the userspace kexec-tools? It needs a similar detection, but
I'm not sure how to detect paging mode, maybe some sysfs entry or
vmcoreinfo in /proc/vmcore
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/x86/kernel/kexec-bzimage64.c
> b/arch/x86/kernel/kexec-bzimage64.c
> index 22f60dd26460..858cc892672f 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned
> long len)
> return ret;
> }
>
> + if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
> + pr_err("Can not jump to old 4-level kernel from 5-level
> kernel.\n");
4-level kernel sounds not very clear, maybe something like below?
"5-level paging enabled, can not kexec into an old kernel without 5-level
paging facility"?
> + return ret;
> + }
> +
> /* I've got a bzImage */
> pr_debug("It's a relocatable bzImage64\n");
> ret = 0;
> --
> 2.17.2
>
Thanks
Dave
Re: [PATCH net] xfrm: Fix xfrm sel prefix length validation
On Tue, May 21, 2019 at 08:59:47PM +0530, Anirudh Gupta wrote:
> Family of src/dst can be different from family of selector src/dst.
> Use xfrm selector family to validate address prefix length,
> while verifying new sa from userspace.
>
> Validated patch with this command:
> ip xfrm state add src 1.1.6.1 dst 1.1.6.2 proto esp spi 4260196 \
> reqid 20004 mode tunnel aead "rfc4106(gcm(aes))" \
> 0x01640001 128 \
> sel src 1011:1:4::2/128 sel dst 1021:1:4::2/128 dev Port5
>
> Fixes: 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm
> selector.")
> Signed-off-by: Anirudh Gupta
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation
On 05/22/19 at 11:11am, Dave Young wrote: > Hi Baoquan, > > A few nitpicks, otherwise > Acked-by: Dave Young > > On 05/09/19 at 09:36am, Baoquan He wrote: > > Restrict kdump to only reserve crashkernel below 64TB. > > > > The reaons is that the kdump may jump from 5-level to 4-level, and if > > the kdump kernel is put above 64TB, then the jumping will fail. While the > > 1st kernel reserves crashkernel region during bootup, we don't know yet > > which kind of kernel will be loaded after system bootup, 5-level kernel > > or 5-level kernel. > > 5-level kernel or 4-level kernel ? Right, it's typo. Should be '5-level kernel or 4-level kernel'. Thanks. Will update. > > > > Signed-off-by: Baoquan He > > Acked-by: Kirill A. Shutemov > > --- > > arch/x86/kernel/setup.c | 17 ++--- > > 1 file changed, 14 insertions(+), 3 deletions(-) > > > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > index 905dae880563..efb0934a46f6 100644 > > --- a/arch/x86/kernel/setup.c > > +++ b/arch/x86/kernel/setup.c > > @@ -452,15 +452,26 @@ static void __init > > memblock_x86_reserve_range_setup_data(void) > > #define CRASH_ALIGNSZ_16M > > > > /* > > - * Keep the crash kernel below this limit. On 32 bits earlier kernels > > - * would limit the kernel to the low 512 MiB due to mapping restrictions. > > + * Keep the crash kernel below this limit. > > + * > > + * On 32 bits earlier kernels would limit the kernel to the low > > + * 512 MiB due to mapping restrictions. > > + * > > + * On 64bit, old kexec-tools need to be under 896MiB. The later > > + * supports to put kernel above 4G, up to system RAM top. Here > > Above two lines are not reflected in code because we have removed > the 896M limitation, it would be better to drop the two lines to > avoid confusion. > > > + * kdump kernel need be restricted to be under 64TB, which is > > + * the upper limit of system RAM in 4-level paing mode. Since > > + * the kdump jumping could be from 5-level to 4-level, the jumping > > + * will fail if kernel is put above 64TB, and there's no way to > > + * detect the paging mode of the kernel which will be loaded for > > + * dumping during the 1st kernel bootup. > > */ > > #ifdef CONFIG_X86_32 > > # define CRASH_ADDR_LOW_MAXSZ_512M > > # define CRASH_ADDR_HIGH_MAX SZ_512M > > #else > > # define CRASH_ADDR_LOW_MAXSZ_4G > > -# define CRASH_ADDR_HIGH_MAX MAXMEM > > +# define CRASH_ADDR_HIGH_MAX (64UL << 40) > > Maybe add a new macro in sizes.h like SZ_64T > > > #endif > > > > static int __init reserve_crashkernel_low(void) > > -- > > 2.17.2 > > > > Thanks > Dave
RE: [PATCH] PCI: hv: Detect and fix Hyper-V PCI domain number collision
> From: linux-hyperv-ow...@vger.kernel.org > Sent: Sunday, May 19, 2019 3:29 PM > > Due to Azure host agent settings, the device instance ID's bytes 8 and 9 > are no longer unique. This causes some of the PCI devices not showing up > in VMs with multiple passthrough devices, such as GPUs. So, as recommended > by Azure host team, we now use the bytes 4 and 5 which usually provide > unique numbers. > > In the rare cases of collision, we will detect and find another number > that is not in use. > Thanks to Michael Kelley for proposing this idea. > > Signed-off-by: Haiyang Zhang The patch looks good to me. Reviewed-by: Dexuan Cui
Re: [PATCH v4 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation
Hi Baoquan, A few nitpicks, otherwise Acked-by: Dave Young On 05/09/19 at 09:36am, Baoquan He wrote: > Restrict kdump to only reserve crashkernel below 64TB. > > The reaons is that the kdump may jump from 5-level to 4-level, and if > the kdump kernel is put above 64TB, then the jumping will fail. While the > 1st kernel reserves crashkernel region during bootup, we don't know yet > which kind of kernel will be loaded after system bootup, 5-level kernel > or 5-level kernel. 5-level kernel or 4-level kernel ? > > Signed-off-by: Baoquan He > Acked-by: Kirill A. Shutemov > --- > arch/x86/kernel/setup.c | 17 ++--- > 1 file changed, 14 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 905dae880563..efb0934a46f6 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -452,15 +452,26 @@ static void __init > memblock_x86_reserve_range_setup_data(void) > #define CRASH_ALIGN SZ_16M > > /* > - * Keep the crash kernel below this limit. On 32 bits earlier kernels > - * would limit the kernel to the low 512 MiB due to mapping restrictions. > + * Keep the crash kernel below this limit. > + * > + * On 32 bits earlier kernels would limit the kernel to the low > + * 512 MiB due to mapping restrictions. > + * > + * On 64bit, old kexec-tools need to be under 896MiB. The later > + * supports to put kernel above 4G, up to system RAM top. Here Above two lines are not reflected in code because we have removed the 896M limitation, it would be better to drop the two lines to avoid confusion. > + * kdump kernel need be restricted to be under 64TB, which is > + * the upper limit of system RAM in 4-level paing mode. Since > + * the kdump jumping could be from 5-level to 4-level, the jumping > + * will fail if kernel is put above 64TB, and there's no way to > + * detect the paging mode of the kernel which will be loaded for > + * dumping during the 1st kernel bootup. > */ > #ifdef CONFIG_X86_32 > # define CRASH_ADDR_LOW_MAX SZ_512M > # define CRASH_ADDR_HIGH_MAX SZ_512M > #else > # define CRASH_ADDR_LOW_MAX SZ_4G > -# define CRASH_ADDR_HIGH_MAX MAXMEM > +# define CRASH_ADDR_HIGH_MAX (64UL << 40) Maybe add a new macro in sizes.h like SZ_64T > #endif > > static int __init reserve_crashkernel_low(void) > -- > 2.17.2 > Thanks Dave
Re: [PATCH v2 1/2] Bluetooth: Disable LE Advertising in hci_suspend_dev()
Hi Marcel,
at 5:25 PM, Kai-Heng Feng wrote:
LE Advertising may wake up system during system-wide sleep, disable it
to prevent this issue from happening.
Do the reverse in hci_resume_dev().
Do you have any suggestion for this patch?
Kai-Heng
Signed-off-by: Kai-Heng Feng
---
v2:
- Abstract away enabling/disabling LE advertising from btusb.
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 47
2 files changed, 48 insertions(+)
diff --git a/include/net/bluetooth/hci_core.h
b/include/net/bluetooth/hci_core.h
index 094e61e07030..65574943131d 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -269,6 +269,7 @@ struct hci_dev {
__u16 le_max_rx_time;
__u8le_max_key_size;
__u8le_min_key_size;
+ __u8le_events[8];
__u16 discov_interleaved_timeout;
__u16 conn_info_min_age;
__u16 conn_info_max_age;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d6b2540ba7f8..7c19e3b9294c 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -412,6 +412,49 @@ static void hci_setup_event_mask(struct hci_request
*req)
hci_req_add(req, HCI_OP_SET_EVENT_MASK, sizeof(events), events);
}
+static int hci_enable_le_advertising_req(struct hci_request *req,
unsigned long opt)
+{
+ struct hci_dev *hdev = req->hdev;
+ u8 events[8];
+ memcpy(events, hdev->le_events, sizeof(events));
+
+ hci_req_add(req, HCI_OP_LE_SET_EVENT_MASK, sizeof(events),
+ events);
+
+ return 0;
+}
+
+static int hci_disable_le_advertising_req(struct hci_request *req,
unsigned long opt)
+{
+ struct hci_dev *hdev = req->hdev;
+
+ u8 events[8];
+ memcpy(events, hdev->le_events, sizeof(events));
+
+ events[0] &= ~(u8)0x02; /* LE Advertising Report */
+
+ hci_req_add(req, HCI_OP_LE_SET_EVENT_MASK, sizeof(events),
+ events);
+
+ return 0;
+}
+
+static int hci_enable_le_advertising(struct hci_dev *hdev)
+{
+ if (!lmp_le_capable(hdev))
+ return 0;
+
+ return __hci_req_sync(hdev, hci_enable_le_advertising_req, 0,
HCI_CMD_TIMEOUT, NULL);
+}
+
+static int hci_disable_le_advertising(struct hci_dev *hdev)
+{
+ if (!lmp_le_capable(hdev))
+ return 0;
+
+ return __hci_req_sync(hdev, hci_disable_le_advertising_req, 0,
HCI_CMD_TIMEOUT, NULL);
+}
+
static int hci_init2_req(struct hci_request *req, unsigned long opt)
{
struct hci_dev *hdev = req->hdev;
@@ -772,6 +815,8 @@ static int hci_init3_req(struct hci_request *req,
unsigned long opt)
}
hci_set_le_support(req);
+
+ memcpy(hdev->le_events, events, sizeof(events));
}
/* Read features beyond page 1 if available */
@@ -3431,6 +3476,7 @@ EXPORT_SYMBOL(hci_unregister_dev);
/* Suspend HCI device */
int hci_suspend_dev(struct hci_dev *hdev)
{
+ hci_disable_le_advertising(hdev);
hci_sock_dev_event(hdev, HCI_DEV_SUSPEND);
return 0;
}
@@ -3440,6 +3486,7 @@ EXPORT_SYMBOL(hci_suspend_dev);
int hci_resume_dev(struct hci_dev *hdev)
{
hci_sock_dev_event(hdev, HCI_DEV_RESUME);
+ hci_enable_le_advertising(hdev);
return 0;
}
EXPORT_SYMBOL(hci_resume_dev);
--
2.17.1
答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
Hi Pali,
Why it does not report input data?
--> The alps devices which detected to use the ALPS_PROTO_V8 contains ALPS
touchpad and ALPS track point.
But the ALPS_PROTO_V8 do not support the track point device process.
When the track point was detected to use ALPS_PROTO_V8 ,the v8
process_packet method alps_process_packet_ss4_v2 will reject to report the
data because the v8 device is not set the ALPS_DUALPOINT flag.
You can refer below code.
/* Report trackstick */
if (alps_get_pkt_id_ss4_v2(packet) == SS4_PACKET_ID_STICK) {
if (!(priv->flags & ALPS_DUALPOINT)) {
psmouse_warn(psmouse,
"Rejected trackstick packet from non
DualPoint device");
return;
}
...
return;
}
why is for non-ALPS trackpoints used ALPS driver?
--> the non-Alps track point is the ALPS touchpad, it is right to use the ALPS
driver for ALPS touchpad.
The v8 protocol condition may modified as below, it will be more easier to
understand.
if (e7[0] == 0x73 && e7[1] == 0x03 && (e7[2] == 0x14 || e7[2] == 0x28)
&& (alps_check_is_trackpoint(psmouse) != 0) ) {
protocol = _v8_protocol_data;
}
Best Regards
XiaoXiao Liu
sliuuxiaonx...@gmail.com
xiaoxiao.li...@cn.alps.com
-邮件原件-
发件人: Pali Rohár
发送时间: Tuesday, May 21, 2019 5:46 PM
收件人: Hui Wang
抄送: 劉 曉曉 Xiaoxiao Liu ; XiaoXiao Liu
; dmitry.torok...@gmail.com;
linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org; 曹 曉建 Xiaojian Cao
; zhang...@lenovo.com
主题: Re: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do
not work.
Hello!
On Tuesday 21 May 2019 10:26:47 Hui Wang wrote:
> Tested-by: Hui Wang
>
> On 2019/5/21 上午9:07, Xiaoxiao Liu wrote:
> > Add Pali Rohár.
> >
> > -邮件原件-
> > 发件人: XiaoXiao Liu
> > 发送时间: Monday, May 20, 2019 7:02 PM
> > 收件人: dmitry.torok...@gmail.com
> > 抄送: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > hui.w...@canonical.com; 曹 曉建 Xiaojian Cao
> > ; zhang...@lenovo.com; 劉 曉曉 Xiaoxiao Liu
> > ; XiaoXiao Liu
> >
> > 主题: [PATCH] input: alps-fix the issue the special alps trackpoint do not
> > work.
> >
> > when the alps trackpoint is detected and using the
> > alps_v8_protocol_data procotol, the alps driver will not report the input
> > data.
Why it does not report input data?
> > solution: use standard mouse driver instead of alps driver when the specail
> > trackpoint was detected.
This looks like an (undocumented) hack or workaround. Not a solution.
> > Signed-off-by: XiaoXiao Liu
> > ---
> > drivers/input/mouse/alps.c | 23 ++-
> > 1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> > index 0a6f7ca883e7..516ae1d0eb17 100644
> > --- a/drivers/input/mouse/alps.c
> > +++ b/drivers/input/mouse/alps.c
> > @@ -24,7 +24,7 @@
> > #include "psmouse.h"
> > #include "alps.h"
> > -
> > +#include "trackpoint.h"
> > /*
> >* Definitions for ALPS version 3 and 4 command mode protocol
> >*/
> > @@ -2864,6 +2864,22 @@ static const struct alps_protocol_info
> > *alps_match_table(unsigned char *e7,
> > return NULL;
> > }
> > +int alps_check_is_trackpoint(struct psmouse *psmouse) {
> > + u8 param[2] = { 0 };
> > + int error;
> > +
> > + error = ps2_command(>ps2dev,
> > + param, MAKE_PS2_CMD(0, 2, TP_READ_ID));
> > + if (error)
> > + return error;
> > +
> > + if (param[0] == TP_VARIANT_ALPS)
> > + return 0;
> > + psmouse_warn(psmouse, "It is not alps trackpoint.\n");
> > + return -ENODEV;
> > +}
So, this function returns 0 when detected ALPS trackpoint and -ENODEV when not.
> > +
> > static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
> > {
> > const struct alps_protocol_info *protocol; @@ -2912,6 +2928,11 @@
> > static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
> > protocol = _v3_protocol_data;
> > } else if (e7[0] == 0x73 && e7[1] == 0x03 &&
> >(e7[2] == 0x14 || e7[2] == 0x28)) {
> > + if (alps_check_is_trackpoint(psmouse) == 0) {
> > + psmouse_warn(psmouse,
> > + "It is alps trackpoint, use the
> > standard mouse driver.\n");
> > + return -EINVAL;
And here I'm lost. If we have *not* detected ALPS trackpoint then if block is
not called which means that ALPS driver is used.
So why is for non-ALPS trackpoints used ALPS driver? This does not seem like a
correct...
And when we have detected ALPS trackpoint (return value 0) then standard mouse
driver is used and returned -EINVAL. This seems strange too.
So either this code is wrong or there are missing more details
Re: [RFC 2/2] Add the ability to lock down access to the running kernel image
On Tue, 21 May 2019, Matthew Garrett wrote: > + int (*locked_down)(const char *where, enum lockdown_level level); > +static int lockdown_is_locked_down(const char *what, enum lockdown_level > level) I'm guessing 'what' is the best option here. -- James Morris
Re: [PATCH v2] vt: Fix a missing-check bug in drivers/tty/vt/vt.c
On Tue, 21 May 2019, Gen Zhang wrote:
> On Tue, May 21, 2019 at 12:30:38AM -0400, Nicolas Pitre wrote:
> > Now imagine that MIN_NR_CONSOLES is defined to 10 instead of 1.
> >
> > What happens with allocated memory if the err_vc condition is met on the
> > 5th loop?
> Yes, vc->vc_screenbuf from the last loop is still not freed, right? I
> don't have idea to solve this one. Could please give some advice? Since
> we have to consider the err_vc condition.
>
> > If err_vc_screenbuf condition is encountered on the 5th loop (curcons =
> > 4), what is the value of vc_cons[4].d? Isn't it the same as vc that you
> > just freed?
> >
> >
> > Nicolas
> Thanks for your explaination! You mean a double free situation may
> happen, right? But in vc_allocate() there is also such a kfree(vc) and
> vc_cons[currcons].d = NULL operation. This situation is really confusing
> me.
What you could do is something that looks like:
for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
vc_cons[currcons].d = vc = kzalloc(...);
if (!vc)
goto fail1;
...
vc->vc_screenbuf = kzalloc(...);
if (!vc->vc_screenbuf)
goto fail2;
...
return 0;
/* free already allocated memory on error */
fail1:
while (curcons > 0) {
curcons--;
kfree(vc_cons[currcons].d->vc_screenbuf);
fail2:
kfree(vc_cons[currcons].d);
vc_cons[currcons].d = NULL;
}
console_unlock();
return -ENOMEM;
Nicolas
Re: [RFC] Turn lockdown into an LSM
On Tue, 21 May 2019, Matthew Garrett wrote: > Hi James, > > This is a quick attempt to integrate lockdown into the existing LSM > framework. It adds a new lockdown security hook and an LSM that defines > the existing coarse-grained policy, and also adds a new > DEFINE_EARLY_LSM() definition in order to permit lockdown (and > potentially other modules) to be initialised at the top of kernel init > in order to allow policy to be imposed on stuff that happens in > setup_arch(). The goal here is to allow policy to be devolved to other > LSMs on systems that have a secure mechanism for loading LSM policy > early in boot, allowing creation of arbitrarily complicated policies > without interfering with the common-case coarse-grained approach. > > This should probably be extended so a uapi-exposed constant is passed to > the hook in order to make it easier to write policy in other LSMs, but > does this broadly look like you were imagining? This looks promising! An LSM could also potentially implement its own policy for the hook. -- James Morris
Re: [PATCH v3 13/13] epoll: implement epoll_create2() syscall
On Thu, 16 May 2019 12:20:50 +0200 Roman Penyaev wrote: > On 2019-05-16 12:03, Arnd Bergmann wrote: > > On Thu, May 16, 2019 at 10:59 AM Roman Penyaev > > wrote: > >> > >> epoll_create2() is needed to accept EPOLL_USERPOLL flags > >> and size, i.e. this patch wires up polling from userspace. > > > > Could you add the system call to all syscall*.tbl files at the same > > time here? > > For all other archs, you mean? Sure. But what is the rule of thumb? > Sometimes people tend to add to the most common x86 and other tables > are left untouched, but then you commit the rest, e.g. > > commit 39036cd2727395c3369b1051005da74059a85317 > Author: Arnd Bergmann > Date: Thu Feb 28 13:59:19 2019 +0100 > > arch: add pidfd and io_uring syscalls everywhere > I thought the preferred approach was to wire up the architectures on which the submitter has tested the syscall, then allow the arch maintainers to enable the syscall independently? And to help them in this, provide a test suite for the new syscall under tools/testing/selftests/. https://github.com/rouming/test-tools/blob/master/userpolled-epoll.c will certainly help but I do think it would be better to move the test into the kernel tree to keep it maintained and so that many people run it in their various setups on an ongoing basis.
[No Subject]
We are now providing business & personal loans: -Rate starting at: 2.05%. -Flexible repayment: up to 30 years. For more information and application, please reply. > To unsubscribe please reply with "unsubscribe" as subject.
Re: [PATCH] mm/kasan: Print frame description for stack bugs
On Sun, 19 May 2019 04:48:21 +0800 kbuild test robot wrote:
> Hi Marco,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v5.1 next-20190517]
> [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/Marco-Elver/mm-kasan-Print-frame-description-for-stack-bugs/20190519-040214
> config: xtensa-allyesconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 8.1.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=8.1.0 make.cross ARCH=xtensa
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
This, I assume?
--- a/mm/kasan/report.c~mm-kasan-print-frame-description-for-stack-bugs-fix
+++ a/mm/kasan/report.c
@@ -230,7 +230,7 @@ static void print_decoded_frame_descr(co
return;
pr_err("\n");
- pr_err("this frame has %zu %s:\n", num_objects,
+ pr_err("this frame has %lu %s:\n", num_objects,
num_objects == 1 ? "object" : "objects");
while (num_objects--) {
@@ -257,7 +257,7 @@ static void print_decoded_frame_descr(co
strreplace(token, ':', '\0');
/* Finally, print object information. */
- pr_err(" [%zu, %zu) '%s'", offset, offset + size, token);
+ pr_err(" [%lu, %lu) '%s'", offset, offset + size, token);
}
}
_
Re: [PATCH v2 2/3] clk: sprd: Check error only for devm_regmap_init_mmio()
On Wed, 22 May 2019 at 09:15, Chunyan Zhang wrote:
>
> The function devm_regmap_init_mmio() wouldn't return NULL pointer for
> now, so only need to ensure the return value is not an error code.
>
> Signed-off-by: Chunyan Zhang
Reviewed-by: Baolin Wang
> ---
> drivers/clk/sprd/common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sprd/common.c b/drivers/clk/sprd/common.c
> index 9ce690999eaa..a5bdca1de5d0 100644
> --- a/drivers/clk/sprd/common.c
> +++ b/drivers/clk/sprd/common.c
> @@ -58,7 +58,7 @@ int sprd_clk_regmap_init(struct platform_device *pdev,
>
> regmap = devm_regmap_init_mmio(>dev, base,
>_regmap_config);
> - if (IS_ERR_OR_NULL(regmap)) {
> + if (IS_ERR(regmap)) {
> pr_err("failed to init regmap\n");
> return PTR_ERR(regmap);
> }
> --
> 2.17.1
>
--
Baolin Wang
Best Regards
Re: [PATCH v2 1/3] clk: sprd: Switch from of_iomap() to devm_ioremap_resource()
On Wed, 22 May 2019 at 09:15, Chunyan Zhang wrote:
>
> devm_ioremap_resources() automatically requests resources and devm_ wrappers
> do better error handling and unmapping of the I/O region when needed,
> that would make drivers more clean and simple.
>
> Signed-off-by: Chunyan Zhang
Reviewed-by: Baolin Wang
> ---
> drivers/clk/sprd/common.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sprd/common.c b/drivers/clk/sprd/common.c
> index e038b0447206..9ce690999eaa 100644
> --- a/drivers/clk/sprd/common.c
> +++ b/drivers/clk/sprd/common.c
> @@ -42,6 +42,7 @@ int sprd_clk_regmap_init(struct platform_device *pdev,
> void __iomem *base;
> struct device_node *node = pdev->dev.of_node;
> struct regmap *regmap;
> + struct resource *res;
>
> if (of_find_property(node, "sprd,syscon", NULL)) {
> regmap = syscon_regmap_lookup_by_phandle(node, "sprd,syscon");
> @@ -50,7 +51,11 @@ int sprd_clk_regmap_init(struct platform_device *pdev,
> return PTR_ERR(regmap);
> }
> } else {
> - base = of_iomap(node, 0);
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> regmap = devm_regmap_init_mmio(>dev, base,
>_regmap_config);
> if (IS_ERR_OR_NULL(regmap)) {
> --
> 2.17.1
>
--
Baolin Wang
Best Regards
Re: [PATCH] initramfs: Fix a missing-check bug in init/initramfs.c
On Wed, May 22, 2019 at 10:00:37AM +0800, Li Zhijian wrote:
>
> On 5/22/19 09:04, Gen Zhang wrote:
> >In dir_add(), de and de->name are allocated by kmalloc() and kstrdup().
> >And de->name is dereferenced in the following codes. However, memory
> >allocation functions such as kmalloc() and kstrdup() may fail.
> >Dereferencing this de->name null pointer may cause the kernel go wrong.
> >Thus we should check this allocation.
> >Further, if kstrdup() returns NULL, we should free de and panic().
> >
> >Signed-off-by: Gen Zhang
> >
> >---
> >diff --git a/init/initramfs.c b/init/initramfs.c
> >index 178130f..dc8063f 100644
> >--- a/init/initramfs.c
> >+++ b/init/initramfs.c
> >@@ -125,6 +125,10 @@ static void __init dir_add(const char *name, time64_t
> >mtime)
> > panic("can't allocate dir_entry buffer");
> > INIT_LIST_HEAD(>list);
> > de->name = kstrdup(name, GFP_KERNEL);
> >+if (!de->name) {
> >+kfree(de);
> >+panic("can't allocate dir_entry name buffer");
> >+}
>
> Looks good
>
> but the following place should be considered as well i think
> 342 vcollected = kstrdup(collected,
> GFP_KERNEL);
> 343 state = CopyFile;
>
>
> Thanks
> Zhijian
Thanks for your comments, Zhijian!
I thinks you are correct that vcollected should also be checked.
I will work on this patch and resubmit it.
Thank
Gen
[PATCH -mm -V9] mm, swap: fix race between swapoff and some swap operations
From: Huang Ying
When swapin is performed, after getting the swap entry information from
the page table, system will swap in the swap entry, without any lock held
to prevent the swap device from being swapoff. This may cause the race
like below,
CPU 1 CPU 2
- -
do_swap_page
swapin_readahead
__read_swap_cache_async
swapoff swapcache_prepare
p->swap_map = NULL__swap_duplicate
p->swap_map[?] /* !!! NULL pointer
access */
Because swapoff is usually done when system shutdown only, the race may
not hit many people in practice. But it is still a race need to be fixed.
To fix the race, get_swap_device() is added to check whether the specified
swap entry is valid in its swap device. If so, it will keep the swap
entry valid via preventing the swap device from being swapoff, until
put_swap_device() is called.
Because swapoff() is very rare code path, to make the normal path runs
as fast as possible, rcu_read_lock/unlock() and synchronize_rcu()
instead of reference count is used to implement get/put_swap_device().
>From get_swap_device() to put_swap_device(), RCU reader side is
locked, so synchronize_rcu() in swapoff() will wait until
put_swap_device() is called.
In addition to swap_map, cluster_info, etc. data structure in the struct
swap_info_struct, the swap cache radix tree will be freed after swapoff,
so this patch fixes the race between swap cache looking up and swapoff
too.
Races between some other swap cache usages and swapoff are fixed too
via calling synchronize_rcu() between clearing PageSwapCache() and
freeing swap cache data structure.
Another possible method to fix this is to use preempt_off() +
stop_machine() to prevent the swap device from being swapoff when its
data structure is being accessed. The overhead in hot-path of both
methods is similar. The advantages of RCU based method are,
1. stop_machine() may disturb the normal execution code path on other
CPUs.
2. File cache uses RCU to protect its radix tree. If the similar
mechanism is used for swap cache too, it is easier to share code
between them.
3. RCU is used to protect swap cache in total_swapcache_pages() and
exit_swap_address_space() already. The two mechanisms can be
merged to simplify the logic.
Fixes: 235b62176712 ("mm/swap: add cluster lock")
Signed-off-by: "Huang, Ying"
Reviewed-by: Andrea Parri
Not-Nacked-by: Hugh Dickins
Cc: Andrea Arcangeli
Cc: Paul E. McKenney
Cc: Daniel Jordan
Cc: Michal Hocko
Cc: Minchan Kim
Cc: Johannes Weiner
Cc: Tim Chen
Cc: Mel Gorman
Cc: Jérôme Glisse
Cc: Yang Shi
Cc: David Rientjes
Cc: Rik van Riel
Cc: Jan Kara
Cc: Dave Jiang
Changelog:
v9:
- Rebased on latest mmotm
- Revise the comments and patch description
v8:
- Use swp_swap_info() to cleanup the code per Daniel's comments
- Use rcu_read_lock/unlock and synchronize_rcu() per Andrea
Arcangeli's comments
- Added Fixes tag per Michal Hocko's comments
v7:
- Rebased on patch: "mm, swap: bounds check swap_info accesses to avoid NULL
derefs"
v6:
- Add more comments to get_swap_device() to make it more clear about
possible swapoff or swapoff+swapon.
v5:
- Replace RCU with stop_machine()
v4:
- Use synchronize_rcu() in enable_swap_info() to reduce overhead of
normal paths further.
v3:
- Re-implemented with RCU to reduce the overhead of normal paths
v2:
- Re-implemented with SRCU to reduce the overhead of normal paths.
- Avoid to check whether the swap device has been swapoff in
get_swap_device(). Because we can check the origin of the swap
entry to make sure the swap device hasn't bee swapoff.
---
include/linux/swap.h | 13 +++-
mm/memory.c | 2 +-
mm/swap_state.c | 16 -
mm/swapfile.c| 154 ++-
4 files changed, 146 insertions(+), 39 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 4bfb5c4ac108..6358a6185634 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -175,8 +175,9 @@ enum {
SWP_PAGE_DISCARD = (1 << 10), /* freed swap page-cluster discards */
SWP_STABLE_WRITES = (1 << 11), /* no overwrite PG_writeback pages */
SWP_SYNCHRONOUS_IO = (1 << 12), /* synchronous IO is efficient */
+ SWP_VALID = (1 << 13),/* swap is valid to be operated on? */
/* add others here before... */
- SWP_SCANNING= (1 << 13),/* refcount in scan_swap_map */
+ SWP_SCANNING= (1 << 14),/* refcount in scan_swap_map */
};
#define SWAP_CLUSTER_MAX 32UL
@@ -460,7 +461,7 @@ extern unsigned int count_swap_pages(int, int);
extern sector_t map_swap_page(struct page *, struct block_device **);
extern sector_t swapdev_block(int, pgoff_t);
[PATCH] soc: qcom: apr: Don't use reg for domain id
The reg property represents the address and size on the bus that a
device lives, but for APR the parent is a rpmsg bus, which does not have
numerical addresses. Simply defining #address/#size-cells to 1 and 0,
respectively, to silence the compiler is not an appropriate solution.
Replace the use of "reg" with an APR specific property.
Signed-off-by: Bjorn Andersson
---
The APR device was recently added to msm8996.dtsi, but this is still
depending on working SMMU to provide functional audio support.
Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt | 2 +-
drivers/soc/qcom/apr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
index bcc612cc7423..38d3c06abc41 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
@@ -9,7 +9,7 @@ used for audio/voice services on the QDSP.
Value type:
Definition: must be "qcom,apr-v", example "qcom,apr-v2"
-- reg
+- qcom,apr-domain
Usage: required
Value type:
Definition: Destination processor ID.
diff --git a/drivers/soc/qcom/apr.c b/drivers/soc/qcom/apr.c
index 74f8b9607daa..b83d71b2e0a4 100644
--- a/drivers/soc/qcom/apr.c
+++ b/drivers/soc/qcom/apr.c
@@ -276,7 +276,7 @@ static int apr_probe(struct rpmsg_device *rpdev)
if (!apr)
return -ENOMEM;
- ret = of_property_read_u32(dev->of_node, "reg", >dest_domain_id);
+ ret = of_property_read_u32(dev->of_node, "qcom,apr-domain",
>dest_domain_id);
if (ret) {
dev_err(dev, "APR Domain ID not specified in DT\n");
return ret;
--
2.18.0
Re: [PATCH] consolemap: Fix a memory leaking bug in drivers/tty/vt/consolemap.c
On Tue, May 21, 2019 at 01:44:33PM -0700, Kees Cook wrote: > This doesn't look safe to me: p->uni_pgdir[n] will still have a handle > to the freed memory, won't it? > Thanks for your reply, Kees! I think you are right. Maybe we should do this: kfree(p1); p->uni_pgdir[n] = NULL; Is this correct? > (And please direct these patches to Greg, as he's the current > maintainer; I'm happy to stay CCed, of course.) > I will follow your suggestions, thanks! Gen > -Kees > > > memset(p2, 0xff, 64*sizeof(u16)); /* No glyphs for the > > characters (yet) */ > > } > > > > -- > Kees Cook
Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER
On Tue, May 21, 2019 at 11:33:10AM -0400, Johannes Weiner wrote: > On Tue, May 21, 2019 at 11:55:33AM +0900, Minchan Kim wrote: > > On Mon, May 20, 2019 at 11:28:01AM +0200, Michal Hocko wrote: > > > [cc linux-api] > > > > > > On Mon 20-05-19 12:52:54, Minchan Kim wrote: > > > > System could have much faster swap device like zRAM. In that case, > > > > swapping > > > > is extremely cheaper than file-IO on the low-end storage. > > > > In this configuration, userspace could handle different strategy for > > > > each > > > > kinds of vma. IOW, they want to reclaim anonymous pages by MADV_COLD > > > > while it keeps file-backed pages in inactive LRU by MADV_COOL because > > > > file IO is more expensive in this case so want to keep them in memory > > > > until memory pressure happens. > > > > > > > > To support such strategy easier, this patch introduces > > > > MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER options in madvise(2) like > > > > that /proc//clear_refs already has supported same filters. > > > > They are filters could be Ored with other existing hints using top two > > > > bits > > > > of (int behavior). > > > > > > madvise operates on top of ranges and it is quite trivial to do the > > > filtering from the userspace so why do we need any additional filtering? > > > > > > > Once either of them is set, the hint could affect only the interested > > > > vma > > > > either anonymous or file-backed. > > > > > > > > With that, user could call a process_madvise syscall simply with a > > > > entire > > > > range(0x0 - 0x) but either of MADV_ANONYMOUS_FILTER and > > > > MADV_FILE_FILTER so there is no need to call the syscall range by range. > > > > > > OK, so here is the reason you want that. The immediate question is why > > > cannot the monitor do the filtering from the userspace. Slightly more > > > work, all right, but less of an API to expose and that itself is a > > > strong argument against. > > > > What I should do if we don't have such filter option is to enumerate all of > > vma via /proc//maps and then parse every ranges and inode from string, > > which would be painful for 2000+ vmas. > > Just out of curiosity, how do you get to 2000+ distinct memory regions > in the address space of a mobile app? I'm assuming these aren't files, > but rather anon objects with poor grouping. Is that from guard pages > between individual heap allocations or something? Android uses preload library model to speed up app launch so it loads all of library in advance on zygote and forks new app based on it.
RE: [PATCH V3 2/4] nvmem: imx: add i.MX8 nvmem driver
Hi Srinivas,
> Subject: Re: [PATCH V3 2/4] nvmem: imx: add i.MX8 nvmem driver
>
>
>
> On 15/05/2019 08:53, Peng Fan wrote:
> > This patch adds i.MX8 nvmem ocotp driver to access fuse via RPC to
> > i.MX8 system controller.
> >
> > Cc: Srinivas Kandagatla
> > Cc: Shawn Guo
> > Cc: Sascha Hauer
> > Cc: Pengutronix Kernel Team
> > Cc: Fabio Estevam
> > Cc: NXP Linux Team
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: Peng Fan
>
> I don't see any dt-binding patches in my list. May be you forgot to add me in
> CC.
>
> Can You please make sure that you add me to the cc of the dt-bindings patch
> so that I can take the driver and dt-bindings together via nvmem tree.
> I will not be able to apply any driver patches without dt-bindings.
Sorry. Forgot to add you in that patch. Resent the whole v3 patchset with
you in To list just now.
Thanks,
Peng.
>
> Thanks,
> srini
> > ---
> >
> > V3:
> > Use imx_sc_msg_misc_fuse_read for req/resp
> > Drop uneccessary check
> > Drop the unnecessary type conversion
> > Minor fixes according to v2 comments
> >
> > V2:
> > Add "scu" or "SCU", Add imx_sc_misc_otp_fuse_read, minor fixes
> >
> > drivers/nvmem/Kconfig | 7 ++
> > drivers/nvmem/Makefile| 2 +
> > drivers/nvmem/imx-ocotp-scu.c | 161
> ++
> > 3 files changed, 170 insertions(+)
> > create mode 100644 drivers/nvmem/imx-ocotp-scu.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig index
> > 530d570724c9..79afe44195a1 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -36,6 +36,13 @@ config NVMEM_IMX_OCOTP
> > This driver can also be built as a module. If so, the module
> > will be called nvmem-imx-ocotp.
> >
> > +config NVMEM_IMX_OCOTP_SCU
> > + tristate "i.MX8 SCU On-Chip OTP Controller support"
> > + depends on IMX_SCU
> > + help
> > + This is a driver for the SCU On-Chip OTP Controller (OCOTP)
> > + available on i.MX8 SoCs.
> > +
> > config NVMEM_LPC18XX_EEPROM
> > tristate "NXP LPC18XX EEPROM Memory Support"
> > depends on ARCH_LPC18XX || COMPILE_TEST diff --git
> > a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile index
> > 2ece8dda..30d653d34e57 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -13,6 +13,8 @@ obj-$(CONFIG_NVMEM_IMX_IIM) +=
> nvmem-imx-iim.o
> > nvmem-imx-iim-y := imx-iim.o
> > obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
> > nvmem-imx-ocotp-y := imx-ocotp.o
> > +obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU) += nvmem-imx-ocotp-scu.o
> > +nvmem-imx-ocotp-scu-y := imx-ocotp-scu.o
> > obj-$(CONFIG_NVMEM_LPC18XX_EEPROM)+=
> nvmem_lpc18xx_eeprom.o
> > nvmem_lpc18xx_eeprom-y:= lpc18xx_eeprom.o
> > obj-$(CONFIG_NVMEM_LPC18XX_OTP) += nvmem_lpc18xx_otp.o
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c new file mode 100644 index
> > ..d9dc482ecb2f
> > --- /dev/null
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -0,0 +1,161 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX8 OCOTP fusebox driver
> > + *
> > + * Copyright 2019 NXP
> > + *
> > + * Peng Fan
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +enum ocotp_devtype {
> > + IMX8QXP,
> > +};
> > +
> > +struct ocotp_devtype_data {
> > + int devtype;
> > + int nregs;
> > +};
> > +
> > +struct ocotp_priv {
> > + struct device *dev;
> > + const struct ocotp_devtype_data *data;
> > + struct imx_sc_ipc *nvmem_ipc;
> > +};
> > +
> > +struct imx_sc_msg_misc_fuse_read {
> > + struct imx_sc_rpc_msg hdr;
> > + u32 word;
> > +} __packed;
> > +
> > +static struct ocotp_devtype_data imx8qxp_data = {
> > + .devtype = IMX8QXP,
> > + .nregs = 800,
> > +};
> > +
> > +static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> > +u32 *val)
> > +{
> > + struct imx_sc_msg_misc_fuse_read msg;
> > + struct imx_sc_rpc_msg *hdr =
> > + int ret;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_MISC;
> > + hdr->func = IMX_SC_MISC_FUNC_OTP_FUSE_READ;
> > + hdr->size = 2;
> > +
> > + msg.word = word;
> > +
> > + ret = imx_scu_call_rpc(ipc, , true);
> > + if (ret)
> > + return ret;
> > +
> > + *val = msg.word;
> > +
> > + return 0;
> > +}
> > +
> > +static int imx_scu_ocotp_read(void *context, unsigned int offset,
> > + void *val, size_t bytes)
> > +{
> > + struct ocotp_priv *priv = context;
> > + u32 count, index, num_bytes;
> > + u32 *buf;
> > + void *p;
> > + int i, ret;
> > +
> > + index = offset >> 2;
> > + num_bytes = round_up((offset % 4) + bytes, 4);
> > + count = num_bytes >> 2;
> > +
> > + if (count > (priv->data->nregs - index))
> > + count = priv->data->nregs - index;
> > +
> > + p =
[PATCH V3 RESEND 2/4] nvmem: imx: add i.MX8 nvmem driver
This patch adds i.MX8 nvmem ocotp driver to access fuse via
RPC to i.MX8 system controller.
Cc: Srinivas Kandagatla
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Peng Fan
---
V3:
Use imx_sc_msg_misc_fuse_read for req/resp
Drop uneccessary check
Drop the unnecessary type conversion
Minor fixes according to v2 comments
V2:
Add "scu" or "SCU", Add imx_sc_misc_otp_fuse_read, minor fixes
drivers/nvmem/Kconfig | 7 ++
drivers/nvmem/Makefile| 2 +
drivers/nvmem/imx-ocotp-scu.c | 161 ++
3 files changed, 170 insertions(+)
create mode 100644 drivers/nvmem/imx-ocotp-scu.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 530d570724c9..79afe44195a1 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -36,6 +36,13 @@ config NVMEM_IMX_OCOTP
This driver can also be built as a module. If so, the module
will be called nvmem-imx-ocotp.
+config NVMEM_IMX_OCOTP_SCU
+ tristate "i.MX8 SCU On-Chip OTP Controller support"
+ depends on IMX_SCU
+ help
+ This is a driver for the SCU On-Chip OTP Controller (OCOTP)
+ available on i.MX8 SoCs.
+
config NVMEM_LPC18XX_EEPROM
tristate "NXP LPC18XX EEPROM Memory Support"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 2ece8dda..30d653d34e57 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_NVMEM_IMX_IIM) += nvmem-imx-iim.o
nvmem-imx-iim-y:= imx-iim.o
obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
nvmem-imx-ocotp-y := imx-ocotp.o
+obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU) += nvmem-imx-ocotp-scu.o
+nvmem-imx-ocotp-scu-y := imx-ocotp-scu.o
obj-$(CONFIG_NVMEM_LPC18XX_EEPROM) += nvmem_lpc18xx_eeprom.o
nvmem_lpc18xx_eeprom-y := lpc18xx_eeprom.o
obj-$(CONFIG_NVMEM_LPC18XX_OTP)+= nvmem_lpc18xx_otp.o
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
new file mode 100644
index ..d9dc482ecb2f
--- /dev/null
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 OCOTP fusebox driver
+ *
+ * Copyright 2019 NXP
+ *
+ * Peng Fan
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum ocotp_devtype {
+ IMX8QXP,
+};
+
+struct ocotp_devtype_data {
+ int devtype;
+ int nregs;
+};
+
+struct ocotp_priv {
+ struct device *dev;
+ const struct ocotp_devtype_data *data;
+ struct imx_sc_ipc *nvmem_ipc;
+};
+
+struct imx_sc_msg_misc_fuse_read {
+ struct imx_sc_rpc_msg hdr;
+ u32 word;
+} __packed;
+
+static struct ocotp_devtype_data imx8qxp_data = {
+ .devtype = IMX8QXP,
+ .nregs = 800,
+};
+
+static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
+u32 *val)
+{
+ struct imx_sc_msg_misc_fuse_read msg;
+ struct imx_sc_rpc_msg *hdr =
+ int ret;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_OTP_FUSE_READ;
+ hdr->size = 2;
+
+ msg.word = word;
+
+ ret = imx_scu_call_rpc(ipc, , true);
+ if (ret)
+ return ret;
+
+ *val = msg.word;
+
+ return 0;
+}
+
+static int imx_scu_ocotp_read(void *context, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct ocotp_priv *priv = context;
+ u32 count, index, num_bytes;
+ u32 *buf;
+ void *p;
+ int i, ret;
+
+ index = offset >> 2;
+ num_bytes = round_up((offset % 4) + bytes, 4);
+ count = num_bytes >> 2;
+
+ if (count > (priv->data->nregs - index))
+ count = priv->data->nregs - index;
+
+ p = kzalloc(num_bytes, GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ buf = p;
+
+ for (i = index; i < (index + count); i++) {
+ if (priv->data->devtype == IMX8QXP) {
+ if ((i > 271) && (i < 544)) {
+ *buf++ = 0;
+ continue;
+ }
+ }
+
+ ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
+ if (ret) {
+ kfree(p);
+ return ret;
+ }
+ buf++;
+ }
+
+ memcpy(val, (u8 *)p + offset % 4, bytes);
+
+ kfree(p);
+
+ return 0;
+}
+
+static struct nvmem_config imx_scu_ocotp_nvmem_config = {
+ .name = "imx-scu-ocotp",
+ .read_only = true,
+ .word_size = 4,
+ .stride = 1,
+ .owner = THIS_MODULE,
+ .reg_read = imx_scu_ocotp_read,
+};
+
+static const struct of_device_id
[PATCH V3 RESEND 3/4] defconfig: arm64: enable i.MX8 SCU octop driver
Build in CONFIG_NVMEM_IMX_OCOTP_SCU. Cc: Catalin Marinas Cc: Will Deacon Cc: Shawn Guo Cc: Andy Gross Cc: Maxime Ripard Cc: Olof Johansson Cc: Jagan Teki Cc: Bjorn Andersson Cc: Leonard Crestez Cc: Marc Gonzalez Cc: Enric Balletbo i Serra Cc: linux-arm-ker...@lists.infradead.org Reviewed-by: Dong Aisheng Signed-off-by: Peng Fan --- V3: No change V2: rename patch title, add review tag arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 979a95c915b6..32b85102b857 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -748,6 +748,7 @@ CONFIG_HISI_PMU=y CONFIG_QCOM_L2_PMU=y CONFIG_QCOM_L3_PMU=y CONFIG_NVMEM_IMX_OCOTP=y +CONFIG_NVMEM_IMX_OCOTP_SCU=y CONFIG_QCOM_QFPROM=y CONFIG_ROCKCHIP_EFUSE=y CONFIG_UNIPHIER_EFUSE=y -- 2.16.4
[PATCH V3 RESEND 1/4] dt-bindings: fsl: scu: add ocotp binding
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller(SCU), the ocotp controller is being controlled
by the SCU, so Linux need use RPC to SCU for ocotp handling. This
patch adds binding doc for i.MX8 SCU OCOTP driver.
Cc: Mark Rutland
Cc: Shawn Guo
Cc: Ulf Hansson
Cc: Stephen Boyd
Cc: Anson Huang
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
Reviewed-by: Dong Aisheng
Signed-off-by: Peng Fan
---
V3:
Add R-b tag
V2:
Move OCOTP to end, add example, add "scu"
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 5d7dbabbb784..f378922906f6 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -133,6 +133,18 @@ RTC bindings based on SCU Message Protocol
Required properties:
- compatible: should be "fsl,imx8qxp-sc-rtc";
+OCOTP bindings based on SCU Message Protocol
+
+Required properties:
+- compatible: Should be "fsl,imx8qxp-scu-ocotp"
+- #address-cells: Must be 1. Contains byte index
+- #size-cells: Must be 1. Contains byte length
+
+Optional Child nodes:
+
+- Data cells of ocotp:
+ Detailed bindings are described in bindings/nvmem/nvmem.txt
+
Example (imx8qxp):
-
aliases {
@@ -177,6 +189,16 @@ firmware {
...
};
+ ocotp: imx8qx-ocotp {
+ compatible = "fsl,imx8qxp-scu-ocotp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ fec_mac0: mac@2c4 {
+ reg = <0x2c4 8>;
+ };
+ };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
--
2.16.4
[PATCH V3 RESEND 4/4] arm64: dts: imx: add i.MX8QXP ocotp support
Add i.MX8QXP ocotp node
Cc: Rob Herring
Cc: Mark Rutland
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: Anson Huang
Cc: Daniel Baluta
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Dong Aisheng
Signed-off-by: Peng Fan
---
V3:
Add R-b tag
V2:
move address/size-cells below compatible, add "scu"
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0683ee2a48ae..725d341ee160 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -141,6 +141,12 @@
compatible = "fsl,imx8qxp-iomuxc";
};
+ ocotp: imx8qx-ocotp {
+ compatible = "fsl,imx8qxp-scu-ocotp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd";
#power-domain-cells = <1>;
--
2.16.4
linux-next: manual merge of the akpm-current tree with the pidfd tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
kernel/pid.c
between commit:
99e9da7f2796 ("pid: add pidfd_open()")
from the pidfd tree and commit:
51c59c914840 ("kernel/pid.c: convert struct pid:count to refcount_t")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/pid.c
index 39181ccca846,b59681973dd6..
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@@ -37,8 -36,7 +37,8 @@@
#include
#include
#include
- #include
+ #include
+#include
#include
#include
pgpCtyFdgLJcj.pgp
Description: OpenPGP digital signature
[PATCH] Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD
In the case of compat syscall ioctl numbers for UI_BEGIN_FF_UPLOAD and
UI_END_FF_UPLOAD need to be adjusted before being passed on
uinput_ioctl_handler() since code built with -m32 will be passing
slightly different values. Extend the code already covering
UI_SET_PHYS to cover UI_BEGIN_FF_UPLOAD and UI_END_FF_UPLOAD as well.
Reported-by: Pierre-Loup A. Griffais
Signed-off-by: Andrey Smirnov
Cc: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/input/misc/uinput.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 1a6762fc38f9..1116d4cd5695 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -1051,13 +1051,24 @@ static long uinput_ioctl(struct file *file, unsigned
int cmd, unsigned long arg)
#ifdef CONFIG_COMPAT
-#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108,
compat_uptr_t)
+#define UI_BEGIN_FF_UPLOAD_COMPAT _IOWR(UINPUT_IOCTL_BASE, 200, struct
uinput_ff_upload_compat)
+#define UI_END_FF_UPLOAD_COMPAT_IOW(UINPUT_IOCTL_BASE, 201,
struct uinput_ff_upload_compat)
static long uinput_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
- if (cmd == UI_SET_PHYS_COMPAT)
+ switch (cmd) {
+ case UI_SET_PHYS_COMPAT:
cmd = UI_SET_PHYS;
+ break;
+ case UI_BEGIN_FF_UPLOAD_COMPAT:
+ cmd = UI_BEGIN_FF_UPLOAD;
+ break;
+ case UI_END_FF_UPLOAD_COMPAT:
+ cmd = UI_END_FF_UPLOAD;
+ break;
+ }
return uinput_ioctl_handler(file, cmd, arg, compat_ptr(arg));
}
--
2.21.0
[PATCH] tty_io: Fix a missing-check bug in drivers/tty/tty_io.c
In alloc_tty_struct(), tty->dev is assigned by tty_get_device(). And it
calls class_find_device(). And class_find_device() may return NULL.
And tty->dev is dereferenced in the following codes. When
tty_get_device() returns NULL, dereferencing this tty->dev null pointer
may cause the kernel go wrong. Thus we should check tty->dev.
Further, if tty_get_device() returns NULL, we should free tty and
return NULL.
Signed-off-by: Gen Zhang
---
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 033ac7e..1444b59 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3008,6 +3008,10 @@ struct tty_struct *alloc_tty_struct(struct tty_driver
*driver, int idx)
tty->index = idx;
tty_line_name(driver, idx, tty->name);
tty->dev = tty_get_device(tty);
+ if (!tty->dev) {
+ kfree(tty);
+ return NULL;
+ }
return tty;
}
[PATCH] clk: imx: imx8mm: correct audio_pll2_clk to audio_pll2_out
There is no audio_pll2_clk registered, it should be audio_pll2_out.
Cc:
Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-imx8mm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 1ef8438e3d6d..3a889846a05c 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -325,7 +325,7 @@ static const char *imx8mm_dsi_dbi_sels[] = {"osc_24m",
"sys_pll1_266m", "sys_pll
"sys_pll2_1000m", "sys_pll3_out",
"audio_pll2_out", "video_pll1_out", };
static const char *imx8mm_usdhc3_sels[] = {"osc_24m", "sys_pll1_400m",
"sys_pll1_800m", "sys_pll2_500m",
- "sys_pll3_out", "sys_pll1_266m",
"audio_pll2_clk", "sys_pll1_100m", };
+ "sys_pll3_out", "sys_pll1_266m",
"audio_pll2_out", "sys_pll1_100m", };
static const char *imx8mm_csi1_core_sels[] = {"osc_24m", "sys_pll1_266m",
"sys_pll2_250m", "sys_pll1_800m",
"sys_pll2_1000m", "sys_pll3_out",
"audio_pll2_out", "video_pll1_out", };
@@ -361,11 +361,11 @@ static const char *imx8mm_pdm_sels[] = {"osc_24m",
"sys_pll2_100m", "audio_pll1_
"sys_pll2_1000m", "sys_pll3_out",
"clk_ext3", "audio_pll2_out", };
static const char *imx8mm_vpu_h1_sels[] = {"osc_24m", "vpu_pll_out",
"sys_pll1_800m", "sys_pll2_1000m",
- "audio_pll2_clk", "sys_pll2_125m",
"sys_pll3_clk", "audio_pll1_out", };
+ "audio_pll2_out", "sys_pll2_125m",
"sys_pll3_clk", "audio_pll1_out", };
static const char *imx8mm_dram_core_sels[] = {"dram_pll_out", "dram_alt_root",
};
-static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m",
"osc_27m", "sys_pll1_200m", "audio_pll2_clk",
+static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m",
"osc_27m", "sys_pll1_200m", "audio_pll2_out",
"vpu_pll", "sys_pll1_80m", };
static struct clk *clks[IMX8MM_CLK_END];
--
2.16.4
[PATCH v2] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN
Due to:
* Current implementation of l2cap_config_rsp() dropping BT
connection if sender of configuration response replied with unknown
option failure (Result=0x0003/L2CAP_CONF_UNKNOWN)
* Current implementation of l2cap_build_conf_req() adding
L2CAP_CONF_RFC(0x04) option to initial configure request sent by
the Linux host.
devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S
controllers, will get stuck in endless connect -> configure ->
disconnect loop, never connect and be generaly unusable.
To avoid this problem add code to do the following:
1. Parse the body of response L2CAP_CONF_UNKNOWN and, in case of
unsupported option being RFC, clear L2CAP_FEAT_ERTM and
L2CAP_FEAT_STREAMING from connection's feature mask (in order to
prevent RFC option from being added going forward)
2. Retry configuration step the same way it's done for
L2CAP_CONF_UNACCEPT
Signed-off-by: Andrey Smirnov
Cc: Pierre-Loup A. Griffais
Cc: Florian Dollinger
Cc: Marcel Holtmann
Cc: Johan Hedberg
Cc: linux-blueto...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Changes since [v1]:
- Patch simplified to simply clear L2CAP_FEAT_ERTM |
L2CAP_FEAT_STREAMING from feat_mask when device flags RFC options
as unknown
[v1] lore.kernel.org/r/20190208025828.30901-1-andrew.smir...@gmail.com
net/bluetooth/l2cap_core.c | 59 ++
1 file changed, 59 insertions(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index b53acd6c9a3d..d5d682679128 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4185,6 +4185,50 @@ static inline int l2cap_config_req(struct l2cap_conn
*conn,
return err;
}
+static inline int l2cap_config_rsp_unknown(struct l2cap_conn *conn,
+ struct l2cap_chan *chan,
+ const u8 *data,
+ int len)
+{
+ int o;
+ char req[64];
+
+ if (!len || len > sizeof(req) - sizeof(struct l2cap_conf_req))
+ return -ECONNRESET;
+
+ while (len--) {
+ const u8 option_type = *data++;
+
+ BT_DBG("chan %p, unknown option type: %u", chan, option_type);
+
+ /* "...Hints shall not be included in the Response and
+* shall not be the sole cause for rejecting the
+* Request.."
+*/
+ if (option_type & L2CAP_CONF_HINT)
+ return -ECONNRESET;
+
+ switch (option_type) {
+ case L2CAP_CONF_RFC:
+ /* Clearing the following feature should
+* prevent RFC option from being added next
+* connection attempt
+*/
+ conn->feat_mask &= ~(L2CAP_FEAT_ERTM |
+L2CAP_FEAT_STREAMING);
+ break;
+ default:
+ return -ECONNRESET;
+ }
+ }
+
+ len = l2cap_build_conf_req(chan, req, sizeof(req));
+ l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ, len, req);
+ chan->num_conf_req++;
+
+ return 0;
+}
+
static inline int l2cap_config_rsp(struct l2cap_conn *conn,
struct l2cap_cmd_hdr *cmd, u16 cmd_len,
u8 *data)
@@ -4240,6 +4284,21 @@ static inline int l2cap_config_rsp(struct l2cap_conn
*conn,
}
goto done;
+ case L2CAP_CONF_UNKNOWN:
+ if (chan->num_conf_rsp <= L2CAP_CONF_MAX_CONF_RSP) {
+ if (l2cap_config_rsp_unknown(conn, chan, rsp->data,
+len) < 0) {
+ l2cap_send_disconn_req(chan, ECONNRESET);
+ goto done;
+ }
+ break;
+ }
+ /* Once, chan->num_conf_rsp goes above
+* L2CAP_CONF_MAX_CONF_RSP we want to go down all the
+* way to default label (just like L2CAP_CONF_UNACCEPT
+* below)
+*/
+ /* fall through */
case L2CAP_CONF_UNACCEPT:
if (chan->num_conf_rsp <= L2CAP_CONF_MAX_CONF_RSP) {
char req[64];
--
2.21.0
[PATCH v2 0/3] Return immediately if sprd_clk_regmap_init() fails
The function sprd_clk_regmap_init() doesn't always return success, drivers should return immediately when it fails rather than continue the clock initialization. The patch 1/3 in this set switchs to use devm_ioremap_resources() instead of of_iomap(), that will make caller programs more simple. Changes from V1: - Split out the patch 2/3 from 1/2 of the first version; - Added reviewed-by from Baolin. Chunyan Zhang (3): clk: sprd: Switch from of_iomap() to devm_ioremap_resource() clk: sprd: Check error only for devm_regmap_init_mmio() clk: sprd: Add check the return value of sprd_clk_regmap_init() drivers/clk/sprd/common.c | 9 +++-- drivers/clk/sprd/sc9860-clk.c | 4 +++- 2 files changed, 10 insertions(+), 3 deletions(-) -- 2.17.1
Re: [v3 PATCH 2/2] mm: vmscan: correct some vmscan counters for THP swapout
Yang Shi writes:
> Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
> swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
> and some other vm counters still get inc'ed by one even though a whole
> THP (512 pages) gets swapped out.
>
> This doesn't make too much sense to memory reclaim. For example, direct
> reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
> could fulfill it. But, if nr_reclaimed is not increased correctly,
> direct reclaim may just waste time to reclaim more pages,
> SWAP_CLUSTER_MAX * 512 pages in worst case.
>
> And, it may cause pgsteal_{kswapd|direct} is greater than
> pgscan_{kswapd|direct}, like the below:
>
> pgsteal_kswapd 122933
> pgsteal_direct 26600225
> pgscan_kswapd 174153
> pgscan_direct 14678312
>
> nr_reclaimed and nr_scanned must be fixed in parallel otherwise it would
> break some page reclaim logic, e.g.
>
> vmpressure: this looks at the scanned/reclaimed ratio so it won't
> change semantics as long as scanned & reclaimed are fixed in parallel.
>
> compaction/reclaim: compaction wants a certain number of physical pages
> freed up before going back to compacting.
>
> kswapd priority raising: kswapd raises priority if we scan fewer pages
> than the reclaim target (which itself is obviously expressed in order-0
> pages). As a result, kswapd can falsely raise its aggressiveness even
> when it's making great progress.
>
> Other than nr_scanned and nr_reclaimed, some other counters, e.g.
> pgactivate, nr_skipped, nr_ref_keep and nr_unmap_fail need to be fixed
> too since they are user visible via cgroup, /proc/vmstat or trace
> points, otherwise they would be underreported.
>
> When isolating pages from LRUs, nr_taken has been accounted in base
> page, but nr_scanned and nr_skipped are still accounted in THP. It
> doesn't make too much sense too since this may cause trace point
> underreport the numbers as well.
>
> So accounting those counters in base page instead of accounting THP as
> one page.
>
> This change may result in lower steal/scan ratio in some cases since
> THP may get split during page reclaim, then a part of tail pages get
> reclaimed instead of the whole 512 pages, but nr_scanned is accounted
> by 512, particularly for direct reclaim. But, this should be not a
> significant issue.
>
> Cc: "Huang, Ying"
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Mel Gorman
> Cc: "Kirill A . Shutemov"
> Cc: Hugh Dickins
> Cc: Shakeel Butt
> Signed-off-by: Yang Shi
> ---
> v3: Removed Shakeel's Reviewed-by since the patch has been changed
> significantly
> Switched back to use compound_order per Matthew
> Fixed more counters per Johannes
> v2: Added Shakeel's Reviewed-by
> Use hpage_nr_pages instead of compound_order per Huang Ying and William
> Kucharski
>
> mm/vmscan.c | 40
> 1 file changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index b65bc50..1044834 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1250,7 +1250,7 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> case PAGEREF_ACTIVATE:
> goto activate_locked;
> case PAGEREF_KEEP:
> - stat->nr_ref_keep++;
> + stat->nr_ref_keep += (1 << compound_order(page));
> goto keep_locked;
> case PAGEREF_RECLAIM:
> case PAGEREF_RECLAIM_CLEAN:
> @@ -1294,6 +1294,17 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> goto activate_locked;
> }
>
> + /*
> + * Account all tail pages when THP is added
> + * into swap cache successfully.
> + * The head page has been accounted at the
> + * first place.
> + */
> + if (PageTransHuge(page))
> + sc->nr_scanned +=
> + ((1 << compound_order(page)) -
> + 1);
> +
The "if" here could be changed to "else if" because if add_to_swap()
fails we don't need to call PageTransHuge() here. But this isn't a big
deal.
You have analyzed the code and found that nr_dirty, nr_unqueued_dirty,
nr_congested and nr_writeback are file cache related and not impacted by
THP swap out. How about add your findings in the patch description?
Best Regards,
Huang, Ying
[PATCH v2 3/3] clk: sprd: Add check for return value of sprd_clk_regmap_init()
sprd_clk_regmap_init() doesn't always return success, adding check for its return value should make the code more strong. Signed-off-by: Chunyan Zhang Reviewed-by: Baolin Wang --- drivers/clk/sprd/sc9860-clk.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/sprd/sc9860-clk.c b/drivers/clk/sprd/sc9860-clk.c index 9980ab55271b..1ed45b4f2fe8 100644 --- a/drivers/clk/sprd/sc9860-clk.c +++ b/drivers/clk/sprd/sc9860-clk.c @@ -2031,7 +2031,9 @@ static int sc9860_clk_probe(struct platform_device *pdev) } desc = match->data; - sprd_clk_regmap_init(pdev, desc); + ret = sprd_clk_regmap_init(pdev, desc); + if (ret) + return ret; return sprd_clk_probe(>dev, desc->hw_clks); } -- 2.17.1
[PATCH v2 2/3] clk: sprd: Check error only for devm_regmap_init_mmio()
The function devm_regmap_init_mmio() wouldn't return NULL pointer for
now, so only need to ensure the return value is not an error code.
Signed-off-by: Chunyan Zhang
---
drivers/clk/sprd/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sprd/common.c b/drivers/clk/sprd/common.c
index 9ce690999eaa..a5bdca1de5d0 100644
--- a/drivers/clk/sprd/common.c
+++ b/drivers/clk/sprd/common.c
@@ -58,7 +58,7 @@ int sprd_clk_regmap_init(struct platform_device *pdev,
regmap = devm_regmap_init_mmio(>dev, base,
_regmap_config);
- if (IS_ERR_OR_NULL(regmap)) {
+ if (IS_ERR(regmap)) {
pr_err("failed to init regmap\n");
return PTR_ERR(regmap);
}
--
2.17.1
[PATCH v2 3/3] clk: sprd: Add check the return value of sprd_clk_regmap_init()
sprd_clk_regmap_init() doesn't always return success, adding check for its return value should make the code more strong. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/sc9860-clk.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/sprd/sc9860-clk.c b/drivers/clk/sprd/sc9860-clk.c index 9980ab55271b..1ed45b4f2fe8 100644 --- a/drivers/clk/sprd/sc9860-clk.c +++ b/drivers/clk/sprd/sc9860-clk.c @@ -2031,7 +2031,9 @@ static int sc9860_clk_probe(struct platform_device *pdev) } desc = match->data; - sprd_clk_regmap_init(pdev, desc); + ret = sprd_clk_regmap_init(pdev, desc); + if (ret) + return ret; return sprd_clk_probe(>dev, desc->hw_clks); } -- 2.17.1
[PATCH v2 1/3] clk: sprd: Switch from of_iomap() to devm_ioremap_resource()
devm_ioremap_resources() automatically requests resources and devm_ wrappers
do better error handling and unmapping of the I/O region when needed,
that would make drivers more clean and simple.
Signed-off-by: Chunyan Zhang
---
drivers/clk/sprd/common.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sprd/common.c b/drivers/clk/sprd/common.c
index e038b0447206..9ce690999eaa 100644
--- a/drivers/clk/sprd/common.c
+++ b/drivers/clk/sprd/common.c
@@ -42,6 +42,7 @@ int sprd_clk_regmap_init(struct platform_device *pdev,
void __iomem *base;
struct device_node *node = pdev->dev.of_node;
struct regmap *regmap;
+ struct resource *res;
if (of_find_property(node, "sprd,syscon", NULL)) {
regmap = syscon_regmap_lookup_by_phandle(node, "sprd,syscon");
@@ -50,7 +51,11 @@ int sprd_clk_regmap_init(struct platform_device *pdev,
return PTR_ERR(regmap);
}
} else {
- base = of_iomap(node, 0);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
regmap = devm_regmap_init_mmio(>dev, base,
_regmap_config);
if (IS_ERR_OR_NULL(regmap)) {
--
2.17.1
[PATCH v2 0/3] Return immediately if sprd_clk_regmap_init() fails
The function sprd_clk_regmap_init() doesn't always return success, drivers should return immediately when it fails ranther than continue the clock initialization. The patch 1/3 in this set switchs to use devm_ioremap_resources() instead of of_iomap(), that will make caller programs more simple. Chunyan Zhang (3): clk: sprd: Switch from of_iomap() to devm_ioremap_resource() clk: sprd: Check error only for devm_regmap_init_mmio() clk: sprd: Add check the return value of sprd_clk_regmap_init() drivers/clk/sprd/common.c | 9 +++-- drivers/clk/sprd/sc9860-clk.c | 4 +++- 2 files changed, 10 insertions(+), 3 deletions(-) -- 2.17.1
Re: [PATCH v4 1/4] ftrace: Implement fs notification for tracing_max_latency
On Wed, 22 May 2019 02:30:14 +0200
Viktor Rosendahl wrote:
>
> I can try to add the static branch if you want it though.
Yes, it would need a static branch to prevent overhead.
>
> best regards,
>
> Viktor
> ---
> include/linux/ftrace.h | 13 +
> kernel/sched/core.c| 2 +
> kernel/sched/idle.c| 2 +
> kernel/sched/sched.h | 1 +
> kernel/trace/trace.c | 111 -
> kernel/trace/trace.h | 12
> kernel/trace/trace_hwlat.c | 4 +-
> 7 files changed, 142 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 25e2995d4a4c..88c76f23277c 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -907,4 +907,17 @@ unsigned long arch_syscall_addr(int nr);
>
> #endif /* CONFIG_FTRACE_SYSCALLS */
>
> +#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \
> + defined(CONFIG_FSNOTIFY)
> +
> +void trace_disable_fsnotify(void);
> +void trace_enable_fsnotify(void);
> +
> +#else
> +
> +#define trace_disable_fsnotify() do { } while (0)
> +#define trace_enable_fsnotify() do { } while (0)
> +
> +#endif
> +
> #endif /* _LINUX_FTRACE_H */
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 874c427742a9..440cd1a62722 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3374,6 +3374,7 @@ static void __sched notrace __schedule(bool preempt)
> struct rq *rq;
> int cpu;
>
> + trace_disable_fsnotify();
Also, don't use "trace_*" names, I'm trying to reserve them for tracepoints
only.
latency_fsnotify_disable();
perhaps?
> cpu = smp_processor_id();
> rq = cpu_rq(cpu);
> prev = rq->curr;
> @@ -3449,6 +3450,7 @@ static void __sched notrace __schedule(bool preempt)
> }
>
> balance_callback(rq);
> + trace_enable_fsnotify();
latency_fsnotify_enable();
> }
>
> void __noreturn do_task_dead(void)
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index b52ed1ada0be..e22871d489a5 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -46,6 +46,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 2c92b3d9ea30..5dcc1147cbcc 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -44,6 +44,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "trace.h"
> #include "trace_output.h"
> @@ -1481,6 +1483,111 @@ static ssize_t trace_seq_to_buffer(struct trace_seq
> *s, void *buf, size_t cnt)
>
> unsigned long __read_mostly tracing_thresh;
>
> +#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \
> + defined(CONFIG_FSNOTIFY)
> +
> +static const struct file_operations tracing_max_lat_fops;
> +static struct workqueue_struct *fsnotify_wq;
> +static DEFINE_PER_CPU(atomic_t, notify_disabled) = ATOMIC_INIT(0);
per cpu atomics is a bit of an overkill. Why the atomic if they are
only used per cpu?
Just make them per cpu, and use things like this_cpu_inc/dec();
> +static DEFINE_PER_CPU(struct llist_head, notify_list);
> +
> +static void trace_fsnotify_workfn(struct work_struct *work)
> +{
> + struct trace_array *tr = container_of(work, struct trace_array,
> + fsnotify_work);
> + fsnotify(tr->d_max_latency->d_inode, FS_MODIFY,
> + tr->d_max_latency->d_inode, FSNOTIFY_EVENT_INODE, NULL, 0);
> +}
> +
> +static void trace_create_maxlat_file(struct trace_array *tr,
> + struct dentry *d_tracer)
> +{
> + INIT_WORK(>fsnotify_work, trace_fsnotify_workfn);
> + atomic_set(>notify_pending, 0);
> + tr->d_max_latency = trace_create_file("tracing_max_latency", 0644,
> + d_tracer, >max_latency,
> + _max_lat_fops);
> +}
> +
> +/*
> + * Disable fsnotify while in scheduler and idle code. Trying wake anything up
> + * from there, such as calling queue_work() is prone to deadlock.
> + */
> +void trace_disable_fsnotify(void)
> +{
> + int cpu;
> +
> + cpu = smp_processor_id();
> + atomic_set(_cpu(notify_disabled, cpu), 1);
> +}
This should be a static inline function:
static inline void latency_fsnotify_disable(void)
{
this_cpu_inc(latency_trace_notify_disable);
}
> +EXPORT_SYMBOL(trace_disable_fsnotify);
> +
> +void trace_enable_fsnotify(void)
Also this needs to be split as a static inline and a function call.
static inline void latency_fsnotify_enable(void)
{
this_cpu_dec(latency_trace_notify_disable);
if (static_key_false(_notify_key))
lantency_fsnotify_process();
}
Have the static_key enabled by the latency tracers that modify the file.
In this file:
void latency_fsontify_process(void)
{
> +{
> + int cpu;
> +
[PATCH] initramfs: Fix a missing-check bug in init/initramfs.c
In dir_add(), de and de->name are allocated by kmalloc() and kstrdup().
And de->name is dereferenced in the following codes. However, memory
allocation functions such as kmalloc() and kstrdup() may fail.
Dereferencing this de->name null pointer may cause the kernel go wrong.
Thus we should check this allocation.
Further, if kstrdup() returns NULL, we should free de and panic().
Signed-off-by: Gen Zhang
---
diff --git a/init/initramfs.c b/init/initramfs.c
index 178130f..dc8063f 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -125,6 +125,10 @@ static void __init dir_add(const char *name, time64_t
mtime)
panic("can't allocate dir_entry buffer");
INIT_LIST_HEAD(>list);
de->name = kstrdup(name, GFP_KERNEL);
+ if (!de->name) {
+ kfree(de);
+ panic("can't allocate dir_entry name buffer");
+ }
de->mtime = mtime;
list_add(>list, _list);
}
[PATCH v8 5/5] media: imx: Try colorimetry at both sink and source pads
Retask imx_media_fill_default_mbus_fields() to try colorimetry parameters,
renaming it to to imx_media_try_colorimetry(), and call it at both sink and
source pad try_fmt's. The unrelated check for uninitialized field value is
moved out to appropriate places in each subdev try_fmt.
The IC now supports Rec.709 and BT.601 Y'CbCr encoding, and both limited
and full range quantization for both YUV and RGB space, so allow those
for pipelines that route through the IC.
Signed-off-by: Steve Longerbeam
---
Changes in v7:
- squashed with "media: imx: Allow Rec.709 encoding for IC routes".
- remove the RGB full-range quantization restriction for IC routes.
---
drivers/staging/media/imx/imx-ic-prp.c | 6 +-
drivers/staging/media/imx/imx-ic-prpencvf.c | 8 +--
drivers/staging/media/imx/imx-media-csi.c | 19 +++---
drivers/staging/media/imx/imx-media-utils.c | 73 ++---
drivers/staging/media/imx/imx-media-vdic.c | 5 +-
drivers/staging/media/imx/imx-media.h | 5 +-
drivers/staging/media/imx/imx7-media-csi.c | 8 +--
7 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prp.c
b/drivers/staging/media/imx/imx-ic-prp.c
index 10ffe00f1a54..f87fe0203720 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -193,8 +193,8 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
sdformat->format.code = cc->codes[0];
}
- imx_media_fill_default_mbus_fields(>format, infmt,
- true);
+ if (sdformat->format.field == V4L2_FIELD_ANY)
+ sdformat->format.field = V4L2_FIELD_NONE;
break;
case PRP_SRC_PAD_PRPENC:
case PRP_SRC_PAD_PRPVF:
@@ -203,6 +203,8 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
break;
}
+ imx_media_try_colorimetry(>format, true);
+
fmt = __prp_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
*fmt = sdformat->format;
out:
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index e8b36a181ccc..f2fe3c11c70e 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -907,8 +907,6 @@ static void prp_try_fmt(struct prp_priv *priv,
/* propagate colorimetry from sink */
sdformat->format.colorspace = infmt->colorspace;
sdformat->format.xfer_func = infmt->xfer_func;
- sdformat->format.quantization = infmt->quantization;
- sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
} else {
v4l_bound_align_image(>format.width,
MIN_W_SINK, MAX_W_SINK, W_ALIGN_SINK,
@@ -916,9 +914,11 @@ static void prp_try_fmt(struct prp_priv *priv,
MIN_H_SINK, MAX_H_SINK, H_ALIGN_SINK,
S_ALIGN);
- imx_media_fill_default_mbus_fields(>format, infmt,
- true);
+ if (sdformat->format.field == V4L2_FIELD_ANY)
+ sdformat->format.field = V4L2_FIELD_NONE;
}
+
+ imx_media_try_colorimetry(>format, true);
}
static int prp_set_fmt(struct v4l2_subdev *sd,
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 1d248aca40a9..dce4addadff4 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1375,9 +1375,15 @@ static void csi_try_field(struct csi_priv *priv,
struct v4l2_mbus_framefmt *infmt =
__csi_get_fmt(priv, cfg, CSI_SINK_PAD, sdformat->which);
- /* no restrictions on sink pad field type */
- if (sdformat->pad == CSI_SINK_PAD)
+ /*
+* no restrictions on sink pad field type except must
+* be initialized.
+*/
+ if (sdformat->pad == CSI_SINK_PAD) {
+ if (sdformat->format.field == V4L2_FIELD_ANY)
+ sdformat->format.field = V4L2_FIELD_NONE;
return;
+ }
switch (infmt->field) {
case V4L2_FIELD_SEQ_TB:
@@ -1455,8 +1461,6 @@ static void csi_try_fmt(struct csi_priv *priv,
/* propagate colorimetry from sink */
sdformat->format.colorspace = infmt->colorspace;
sdformat->format.xfer_func = infmt->xfer_func;
- sdformat->format.quantization = infmt->quantization;
- sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
break;
case CSI_SINK_PAD:
@@ -1476,10 +1480,6 @@ static void csi_try_fmt(struct csi_priv *priv,
csi_try_field(priv, cfg, sdformat);
- imx_media_fill_default_mbus_fields(
- >format, infmt,
-
linux-next: manual merge of the pidfd tree with Linus' tree
Hi all,
Today's linux-next merge of the pidfd tree got a conflict in:
tools/testing/selftests/pidfd/Makefile
between commit:
ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig")
from Linus' tree and commit:
233ad92edbea ("pidfd: add polling selftests")
from the pidfd tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/pidfd/Makefile
index 443fedbd6231,8d97cb35fca4..
--- a/tools/testing/selftests/pidfd/Makefile
+++ b/tools/testing/selftests/pidfd/Makefile
@@@ -1,7 -1,6 +1,7 @@@
+# SPDX-License-Identifier: GPL-2.0-only
- CFLAGS += -g -I../../../../usr/include/
+ CFLAGS += -g -I../../../../usr/include/ -lpthread
- TEST_GEN_PROGS := pidfd_test
+ TEST_GEN_PROGS := pidfd_test pidfd_open_test
include ../lib.mk
pgp0_k0s1BnVh.pgp
Description: OpenPGP digital signature
Re: [v3 PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush
On 5/22/19 7:18 AM, Andrew Morton wrote:
On Mon, 20 May 2019 11:17:32 +0800 Yang Shi wrote:
A few new fields were added to mmu_gather to make TLB flush smarter for
huge page by telling what level of page table is changed.
__tlb_reset_range() is used to reset all these page table state to
unchanged, which is called by TLB flush for parallel mapping changes for
the same range under non-exclusive lock (i.e. read mmap_sem). Before
commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
munmap"), the syscalls (e.g. MADV_DONTNEED, MADV_FREE) which may update
PTEs in parallel don't remove page tables. But, the forementioned
commit may do munmap() under read mmap_sem and free page tables. This
may result in program hang on aarch64 reported by Jan Stancek. The
problem could be reproduced by his test program with slightly modified
below.
...
Use fullmm flush since it yields much better performance on aarch64 and
non-fullmm doesn't yields significant difference on x86.
The original proposed fix came from Jan Stancek who mainly debugged this
issue, I just wrapped up everything together.
Thanks. I'll add
Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
to this.
Thanks, Andrew.
Re: [PATCH v4 0/1] Use HMM for ODP v4
On Tue, May 21, 2019 at 04:53:22PM -0400, Jerome Glisse wrote:
> On Mon, May 06, 2019 at 04:56:57PM -0300, Jason Gunthorpe wrote:
> > On Thu, Apr 11, 2019 at 02:13:13PM -0400, jgli...@redhat.com wrote:
> > > From: Jérôme Glisse
> > >
> > > Just fixed Kconfig and build when ODP was not enabled, other than that
> > > this is the same as v3. Here is previous cover letter:
> > >
> > > Git tree with all prerequisite:
> > > https://cgit.freedesktop.org/~glisse/linux/log/?h=rdma-odp-hmm-v4
> > >
> > > This patchset convert RDMA ODP to use HMM underneath this is motivated
> > > by stronger code sharing for same feature (share virtual memory SVM or
> > > Share Virtual Address SVA) and also stronger integration with mm code to
> > > achieve that. It depends on HMM patchset posted for inclusion in 5.2 [2]
> > > and [3].
> > >
> > > It has been tested with pingpong test with -o and others flags to test
> > > different size/features associated with ODP.
> > >
> > > Moreover they are some features of HMM in the works like peer to peer
> > > support, fast CPU page table snapshot, fast IOMMU mapping update ...
> > > It will be easier for RDMA devices with ODP to leverage those if they
> > > use HMM underneath.
> > >
> > > Quick summary of what HMM is:
> > > HMM is a toolbox for device driver to implement software support for
> > > Share Virtual Memory (SVM). Not only it provides helpers to mirror a
> > > process address space on a device (hmm_mirror). It also provides
> > > helper to allow to use device memory to back regular valid virtual
> > > address of a process (any valid mmap that is not an mmap of a device
> > > or a DAX mapping). They are two kinds of device memory. Private memory
> > > that is not accessible to CPU because it does not have all the
> > > expected
> > > properties (this is for all PCIE devices) or public memory which can
> > > also be access by CPU without restriction (with OpenCAPI or CCIX or
> > > similar cache-coherent and atomic inter-connect).
> > >
> > > Device driver can use each of HMM tools separatly. You do not have to
> > > use all the tools it provides.
> > >
> > > For RDMA device i do not expect a need to use the device memory support
> > > of HMM. This device memory support is geared toward accelerator like GPU.
> > >
> > >
> > > You can find a branch [1] with all the prerequisite in. This patch is on
> > > top of rdma-next with the HMM patchset [2] and mmu notifier patchset [3]
> > > applied on top of it.
> > >
> > > [1] https://cgit.freedesktop.org/~glisse/linux/log/?h=rdma-odp-hmm-v4
> > > [2] https://lkml.org/lkml/2019/4/3/1032
> > > [3] https://lkml.org/lkml/2019/3/26/900
> >
> > Jerome, please let me know if these dependent series are merged during
> > the first week of the merge window.
> >
> > This patch has been tested and could go along next week if the
> > dependencies are met.
> >
>
> So attached is a rebase on top of 5.2-rc1, i have tested with pingpong
> (prefetch and not and different sizes). Seems to work ok.
Urk, it already doesn't apply to the rdma tree :(
The conflicts are a little more extensive than I'd prefer to handle..
Can I ask you to rebase it on top of this branch please:
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=wip/jgg-for-next
Specifically it conflicts with this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=wip/jgg-for-next=d2183c6f1958e6b6dfdde279f4cee04280710e34
> +long ib_umem_odp_map_dma_pages(struct ib_umem_odp *umem_odp,
> +struct hmm_range *range)
> {
> + struct device *device = umem_odp->umem.context->device->dma_device;
> + struct ib_ucontext_per_mm *per_mm = umem_odp->per_mm;
> struct ib_umem *umem = _odp->umem;
> - struct task_struct *owning_process = NULL;
> - struct mm_struct *owning_mm = umem_odp->umem.owning_mm;
> - struct page **local_page_list = NULL;
> - u64 page_mask, off;
> - int j, k, ret = 0, start_idx, npages = 0, page_shift;
> - unsigned int flags = 0;
> - phys_addr_t p = 0;
> -
> - if (access_mask == 0)
> + struct mm_struct *mm = per_mm->mm;
> + unsigned long idx, npages;
> + long ret;
> +
> + if (mm == NULL)
> + return -ENOENT;
> +
> + /* Only drivers with invalidate support can use this function. */
> + if (!umem->context->invalidate_range)
> return -EINVAL;
>
> - if (user_virt < ib_umem_start(umem) ||
> - user_virt + bcnt > ib_umem_end(umem))
> - return -EFAULT;
> + /* Sanity checks. */
> + if (range->default_flags == 0)
> + return -EINVAL;
>
> - local_page_list = (struct page **)__get_free_page(GFP_KERNEL);
> - if (!local_page_list)
> - return -ENOMEM;
> + if (range->start < ib_umem_start(umem) ||
> + range->end > ib_umem_end(umem))
> + return -EINVAL;
>
> - page_shift =
Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR
Mark On 5/21/19 4:15 PM, Mark Brown wrote: > On Tue, May 21, 2019 at 10:30:38PM +0200, Jacek Anaszewski wrote: > >> regulator: lm363x: Make the gpio register enable flexible >> regulator: lm363x: Add support for LM36274 > > Why have these been applied, I haven't reviewed them? As far as I can > tell they were sent before the merge window so I'd expect a resend at > this point... > You and Liam were cc'd on April 10,2019 for v2 of this patch set. So I am not sure why the review was missed. My apologies for not cc'ing you on v4 but there were no change since that time. I cannot find v3 of this patchset. The initial patches were sent on April 5, 2019 Dan
[PATCH] staging: rtl8723bs: Add missing blank lines
This patch resolves the following warning from checkpatch.pl
WARNING: Missing a blank line after declarations
Signed-off-by: Fabio Lima
---
drivers/staging/rtl8723bs/core/rtw_debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c
b/drivers/staging/rtl8723bs/core/rtw_debug.c
index 9f8446ccf..853362381 100644
--- a/drivers/staging/rtl8723bs/core/rtw_debug.c
+++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
@@ -382,6 +382,7 @@ ssize_t proc_set_roam_tgt_addr(struct file *file, const
char __user *buffer, siz
if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp))) {
int num = sscanf(tmp, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx", addr,
addr+1, addr+2, addr+3, addr+4, addr+5);
+
if (num == 6)
memcpy(adapter->mlmepriv.roam_tgt_addr, addr, ETH_ALEN);
@@ -1348,6 +1349,7 @@ int proc_get_btcoex_dbg(struct seq_file *m, void *v)
struct net_device *dev = m->private;
struct adapter *padapter;
char buf[512] = {0};
+
padapter = (struct adapter *)rtw_netdev_priv(dev);
rtw_btcoex_GetDBG(padapter, buf, 512);
--
2.11.0
Re: [PATCH 1/1] signal: Adjust error codes according to restore_user_sigmask()
On Tue, May 21, 2019 at 5:35 PM Deepa Dinamani wrote: > > > > > It's been 2 weeks and this fix hasn't appeared in mmots / mmotm. > > > > I also noticed it's missing Cc: for stable@ (below) > > > > > > Why is a -stable backport needed? I see some talk above about lost > > > signals but it is unclear whether these are being observed after fixing > > > the regression caused by 854a6ed56839a. > > > > I guess Deepa's commit messages wasn't clear... > > I suggest prepending this as the first paragraph to Deepa's > > original message: > > > > This fixes a bug introduced with 854a6ed56839a which caused > > EINTR to not be reported to userspace on epoll_pwait. Failure > > to report EINTR to userspace caused problems with user code > > which relies on EINTR to run signal handlers. > > This is not what the patch fixed. > > The notable change is userspace is that now whenever a signal is > delivered, the return value is adjusted to reflect the signal > delivery. > Prior to this patch, there was a window, however small it might have > been, when the signal was delivered but the errono was not adjusted > appropriately. > This is because of the regression caused by 854a6ed56839a, which > extended the window of delivery of signals that was delivered to > userspace. > The patch also fixes more than sys_epoll_pwait(). > > I will post a follow up patch. > > > > > > IOW, can we please have a changelog which has a clear and complete > > > description of the user-visible effects of the change. > > > > > > And please Cc Oleg. > > I will cc Oleg. Also the commit message was brief because the issue was explained in the link that was quoted in the commit message. Detailed issue discussion permalink: https://lore.kernel.org/linux-fsdevel/20190427093319.sgicqik2oqkez3wk@dcvr/ -Deepa
[PATCH] slab: cleanup after /proc/slab_allocators removal
From: Yury Norov
The commit 7878c231dae0 ("slab: remove /proc/slab_allocators")
removes DEBUG_SLAB_LEAK config everywhere but a parisc config.
It doesn't look intentional. Fix it.
Signed-off-by: Yury Norov
---
arch/parisc/configs/c8000_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/parisc/configs/c8000_defconfig
b/arch/parisc/configs/c8000_defconfig
index 088ab948a5ca..900b00084953 100644
--- a/arch/parisc/configs/c8000_defconfig
+++ b/arch/parisc/configs/c8000_defconfig
@@ -225,7 +225,6 @@ CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_SLAB=y
-CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_PANIC_ON_OOPS=y
--
2.17.1
Re: [PATCH 1/1] signal: Adjust error codes according to restore_user_sigmask()
> > > It's been 2 weeks and this fix hasn't appeared in mmots / mmotm. > > > I also noticed it's missing Cc: for stable@ (below) > > > > Why is a -stable backport needed? I see some talk above about lost > > signals but it is unclear whether these are being observed after fixing > > the regression caused by 854a6ed56839a. > > I guess Deepa's commit messages wasn't clear... > I suggest prepending this as the first paragraph to Deepa's > original message: > > This fixes a bug introduced with 854a6ed56839a which caused > EINTR to not be reported to userspace on epoll_pwait. Failure > to report EINTR to userspace caused problems with user code > which relies on EINTR to run signal handlers. This is not what the patch fixed. The notable change is userspace is that now whenever a signal is delivered, the return value is adjusted to reflect the signal delivery. Prior to this patch, there was a window, however small it might have been, when the signal was delivered but the errono was not adjusted appropriately. This is because of the regression caused by 854a6ed56839a, which extended the window of delivery of signals that was delivered to userspace. The patch also fixes more than sys_epoll_pwait(). I will post a follow up patch. > > > IOW, can we please have a changelog which has a clear and complete > > description of the user-visible effects of the change. > > > > And please Cc Oleg. I will cc Oleg.
Re: [PATCH v4 1/4] ftrace: Implement fs notification for tracing_max_latency
On 5/21/19 6:01 PM, Steven Rostedt wrote:>
>
> Note, you need to add the scheduling and power management maintainers
> when adding trace events to their code.
>
My bad.
> As these trace events become visible to user space, and you only need a
> callback to disable fsnotify, it may be better to just have a hard
> coded call to disable fsnotify (and have it be a nop when not
> configured).
My thinking was that it would not be defensible to clutter the idle and
scheduling code with calls to slightly obscure tracing code and that
perhaps some users would like to have these tracepoints for perf/ftrace but
I don't insist on it.
Below is a patch with hard coded calls.
> We can use a static branch if you want to keep the
> overhead down when not enabled, and enable the static branch when you
> start these latency tracers.
>
I noticed that it's possible to slightly simplify the enable/disble
functions, so I guess that this would not be necessary, especially since
one would need to handle the case when some CPUs are in the forbidden
sections when the tracers are enabled.
I can try to add the static branch if you want it though.
best regards,
Viktor
---
include/linux/ftrace.h | 13 +
kernel/sched/core.c| 2 +
kernel/sched/idle.c| 2 +
kernel/sched/sched.h | 1 +
kernel/trace/trace.c | 111 -
kernel/trace/trace.h | 12
kernel/trace/trace_hwlat.c | 4 +-
7 files changed, 142 insertions(+), 3 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 25e2995d4a4c..88c76f23277c 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -907,4 +907,17 @@ unsigned long arch_syscall_addr(int nr);
#endif /* CONFIG_FTRACE_SYSCALLS */
+#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \
+ defined(CONFIG_FSNOTIFY)
+
+void trace_disable_fsnotify(void);
+void trace_enable_fsnotify(void);
+
+#else
+
+#define trace_disable_fsnotify() do { } while (0)
+#define trace_enable_fsnotify() do { } while (0)
+
+#endif
+
#endif /* _LINUX_FTRACE_H */
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 874c427742a9..440cd1a62722 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3374,6 +3374,7 @@ static void __sched notrace __schedule(bool preempt)
struct rq *rq;
int cpu;
+ trace_disable_fsnotify();
cpu = smp_processor_id();
rq = cpu_rq(cpu);
prev = rq->curr;
@@ -3449,6 +3450,7 @@ static void __sched notrace __schedule(bool preempt)
}
balance_callback(rq);
+ trace_enable_fsnotify();
}
void __noreturn do_task_dead(void)
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 80940939b733..1a38bcdb3652 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -225,6 +225,7 @@ static void cpuidle_idle_call(void)
static void do_idle(void)
{
int cpu = smp_processor_id();
+ trace_disable_fsnotify();
/*
* If the arch has a polling bit, we maintain an invariant:
*
@@ -284,6 +285,7 @@ static void do_idle(void)
smp_mb__after_atomic();
sched_ttwu_pending();
+ /* schedule_idle() will call trace_enable_fsnotify() */
schedule_idle();
if (unlikely(klp_patch_pending(current)))
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b52ed1ada0be..e22871d489a5 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2c92b3d9ea30..5dcc1147cbcc 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -44,6 +44,8 @@
#include
#include
#include
+#include
+#include
#include "trace.h"
#include "trace_output.h"
@@ -1481,6 +1483,111 @@ static ssize_t trace_seq_to_buffer(struct trace_seq *s,
void *buf, size_t cnt)
unsigned long __read_mostlytracing_thresh;
+#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \
+ defined(CONFIG_FSNOTIFY)
+
+static const struct file_operations tracing_max_lat_fops;
+static struct workqueue_struct *fsnotify_wq;
+static DEFINE_PER_CPU(atomic_t, notify_disabled) = ATOMIC_INIT(0);
+static DEFINE_PER_CPU(struct llist_head, notify_list);
+
+static void trace_fsnotify_workfn(struct work_struct *work)
+{
+ struct trace_array *tr = container_of(work, struct trace_array,
+ fsnotify_work);
+ fsnotify(tr->d_max_latency->d_inode, FS_MODIFY,
+tr->d_max_latency->d_inode, FSNOTIFY_EVENT_INODE, NULL, 0);
+}
+
+static void trace_create_maxlat_file(struct trace_array *tr,
+ struct dentry *d_tracer)
+{
+ INIT_WORK(>fsnotify_work, trace_fsnotify_workfn);
+ atomic_set(>notify_pending, 0);
+ tr->d_max_latency = trace_create_file("tracing_max_latency", 0644,
+
