RE: [PATCH] platform/chrome: cros_ec_typec: Avoid setting usb role twice during disconnect
Hi,
> -Original Message-
> From: Heikki Krogerus
> Sent: Friday, July 31, 2020 6:37 AM
> To: Shaikh, Azhar
> Cc: ble...@chromium.org; enric.balle...@collabora.com;
> gro...@chromium.org; pmal...@chromium.org; linux-
> ker...@vger.kernel.org; Patel, Utkarsh H ;
> Bowman, Casey G ; Mani, Rajmohan
>
> Subject: Re: [PATCH] platform/chrome: cros_ec_typec: Avoid setting usb
> role twice during disconnect
>
> Hi,
>
> I guess this is was supposed to be PATCH v2 2/2, right?
>
That is correct.
> On Thu, Jul 30, 2020 at 03:52:57PM -0700, Azhar Shaikh wrote:
> > On disconnect port partner is removed and usb role is set to NONE.
> > But then in cros_typec_port_update() the role is set again.
> > Avoid this by moving usb_role_switch_set_role() to
> > cros_typec_configure_mux().
> >
> > Signed-off-by: Azhar Shaikh
> > Suggested-by: Prashant Malani
>
> Reviewed-by: Heikki Krogerus
>
> > ---
> > drivers/platform/chrome/cros_ec_typec.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_typec.c
> > b/drivers/platform/chrome/cros_ec_typec.c
> > index eb4713b7ae14..df97431b2275 100644
> > --- a/drivers/platform/chrome/cros_ec_typec.c
> > +++ b/drivers/platform/chrome/cros_ec_typec.c
> > @@ -515,6 +515,12 @@ static int cros_typec_configure_mux(struct
> cros_typec_data *typec, int port_num,
> > if (ret)
> > return ret;
> >
> > + ret = usb_role_switch_set_role(typec->ports[port_num]->role_sw,
> > + pd_ctrl->role &
> PD_CTRL_RESP_ROLE_DATA
> > + ? USB_ROLE_HOST : USB_ROLE_DEVICE);
> > + if (ret)
> > + return ret;
> > +
> > if (mux_flags & USB_PD_MUX_TBT_COMPAT_ENABLED) {
> > ret = cros_typec_enable_tbt(typec, port_num, pd_ctrl);
> > } else if (mux_flags & USB_PD_MUX_DP_ENABLED) { @@ -589,9
> +595,7 @@
> > static int cros_typec_port_update(struct cros_typec_data *typec, int
> port_num)
> > if (ret)
> > dev_warn(typec->dev, "Configure muxes failed, err = %d\n",
> ret);
> >
> > - return usb_role_switch_set_role(typec->ports[port_num]-
> >role_sw,
> > - resp.role & PD_CTRL_RESP_ROLE_DATA
> > - ? USB_ROLE_HOST : USB_ROLE_DEVICE);
> > + return ret;
> > }
> >
> > static int cros_typec_get_cmd_version(struct cros_typec_data *typec)
> > --
> > 2.17.1
>
> thanks,
>
> --
> heikki
Re: [PATCHv4 00/19] perf metric: Add support to reuse metric
On Sat, Aug 1, 2020 at 4:41 AM Paul A. Clarke wrote:
>
> On Wed, Jul 29, 2020 at 11:18:49AM +0200, Jiri Olsa wrote:
> > this patchset is adding the support to reused metric in
> > another metric.
> >
> > For example, to define IPC by using CPI with change like:
> >
> > {
> > "BriefDescription": "Instructions Per Cycle (per Logical
> > Processor)",
> > -"MetricExpr": "INST_RETIRED.ANY / CPU_CLK_UNHALTED.THREAD",
> > +"MetricExpr": "1/CPI",
> > "MetricGroup": "TopDownL1",
> > "MetricName": "IPC"
> > },
> >
> > I won't be able to find all the possible places we could
> > use this at, so I wonder you guys (who was asking for this)
> > would try it and come up with comments if there's something
> > missing or we could already use it at some places.
> >
> > It's based on Arnaldo's tmp.perf/core.
> >
> > v4 changes:
> > - removed acks from patch because it changed a bit
> > with the last fixes:
> > perf metric: Collect referenced metrics in struct metric_ref_node
> > - fixed runtime metrics [Kajol Jain]
> > - increased recursion depth [Paul A. Clarke]
> > - changed patches due to dependencies:
> > perf metric: Collect referenced metrics in struct metric_ref_node
> > perf metric: Add recursion check when processing nested metrics
> > perf metric: Rename struct egroup to metric
> > perf metric: Rename group_list to metric_list
> >
> > Also available in here:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> > perf/metric
>
> I built and ran from the above git branch, and things seem to work.
> Indeed, I was able to apply my changes to exploit the new capabilities
> via modifications to tools/perf/pmu-events/arch/powerpc/power9/metrics.json,
> as I posted earlier (and will submit once this set gets merged).
>
> Tested-by: Paul A. Clarke
>
> One thing I noted, but which also occurs without these patches, is that
> the perf metrics are not computed unless run as root:
> --
> $ perf stat --metrics br_misprediction_percent command
>
> Performance counter stats for 'command':
>
> 1,823,530,051 pm_br_pred:u
> 2,662,705 pm_br_mpred_cmpl:u
>
> $ /usr/bin/sudo perf stat --metrics br_misprediction_percent command
>
> Performance counter stats for 'command':
>
> 1,824,655,269 pm_br_pred# 0.09
> br_misprediction_percent
> 1,654,466 pm_br_mpred_cmpl
> --
>
> Is that expected? I don't think it's always been that way.
I agree Paul, this seems broken. I've noticed a bunch of issues with
printing CSV, per-socket output and so on. Jiri may have a better idea
but I plan to look at problems in this area later, and hopefully stick
a few tests on it :-)
Thanks,
Ian
> PC
Re: [PATCH] regulator: cros-ec-regulator: Add NULL test for devm_kmemdup call
On Sun, 2 Aug 2020 11:25:09 +0800, Axel Lin wrote: > Fix possible NULL pointer dereference. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/1] regulator: cros-ec-regulator: Add NULL test for devm_kmemdup call commit: 3eccc72b0c3462a6047aa0f85c50263a0a58b001 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 0/4] regulator: mp886x: two features and dt json convert
On Tue, 28 Jul 2020 23:23:27 +0800, Jisheng Zhang wrote: > This is to improve the mp886x regulator driver support. > patch1 converts dt binding to json-schema > patch2 implments .set_ramp_delay > patch3 and patch3 support the switch freq setting > > Jisheng Zhang (4): > dt-bindings: regulator: Convert mp886x to json-schema > regulator: mp886x: implement set_ramp_delay > dt-bindings: regulator: mp886x: support mps,switch-frequency > regulator: mp886x: support setting switch freq > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/4] dt-bindings: regulator: Convert mp886x to json-schema (no commit info) [2/4] regulator: mp886x: implement set_ramp_delay commit: 0eddcf0267f913cb6336af64cadaf5acf6b19b7b [3/4] dt-bindings: regulator: mp886x: support mps,switch-frequency (no commit info) [4/4] regulator: mp886x: support setting switch freq commit: ee6ad5a24575071b66bd37ffb2d8747a64fcb45f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
[GIT PULL] x86/alternatives change for v5.9
Linus, Please pull the latest x86/alternatives git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-alternatives-2020-08-03 # HEAD: 1b2e335ebfa2243517e09f99653c78d1936cb6d2 x86/alternatives: Add pr_fmt() to debug macros A single commit that improves the alternatives patching syslog debug output. Signed-off-by: Ingo Molnar Thanks, Ingo --> Borislav Petkov (1): x86/alternatives: Add pr_fmt() to debug macros arch/x86/kernel/alternative.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: [PATCH v2 0/4] regulator: mp886x: two features and dt json convert
On Wed, 29 Jul 2020 13:08:39 +0800, Jisheng Zhang wrote: > This is to improve the mp886x regulator driver support. > patch1 implments .set_ramp_delay > patch2 and patch3 support the switch freq setting > patch4 converts dt binding to json-schema > > Since v2: > - put any schema conversions at the end of the series as Mark > suggested. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/3] regulator: mp886x: implement set_ramp_delay commit: 0eddcf0267f913cb6336af64cadaf5acf6b19b7b [2/3] regulator: mp886x: support mps,switch-frequency commit: b4b85af052f434bc3be5ee18462164986618feb1 [3/3] regulator: mp886x: support setting switch freq commit: ee6ad5a24575071b66bd37ffb2d8747a64fcb45f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v3] ASoC: fsl-asoc-card: Remove fsl_asoc_card_set_bias_level function
On Mon, 3 Aug 2020 10:13:31 +0800, Shengjiu Wang wrote: > With this case: > aplay -Dhw:x 16khz.wav 24khz.wav > There is sound distortion for 24khz.wav. The reason is that setting > PLL of WM8962 with set_bias_level function, the bias level is not > changed when 24khz.wav is played, then the PLL won't be reset, the > clock is not correct, so distortion happens. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl-asoc-card: Remove fsl_asoc_card_set_bias_level function commit: f36e8edb95734c03134db628afa25ee23b8e0d95 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 1/2] irqchip: irq-mt58xx: Add mt58xx interrupt controller support
On 2020-08-03 16:03, Mark-PK Tsai wrote:
From: Marc Zyngier
On 2020-08-03 07:22, Mark-PK Tsai wrote:
> Add mt58xx interrupt controller support using hierarchy irq
> domain.
>
> Signed-off-by: Mark-PK Tsai
> ---
> drivers/irqchip/Kconfig | 7 ++
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-mt58xx.c | 196 +++
> 3 files changed, 204 insertions(+)
> create mode 100644 drivers/irqchip/irq-mt58xx.c
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 216b3b8392b5..00453af78be0 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -572,4 +572,11 @@ config LOONGSON_PCH_MSI
>help
> Support for the Loongson PCH MSI Controller.
>
> +config MT58XX_IRQ
> + bool "MT58XX IRQ"
> + select IRQ_DOMAIN
> + select IRQ_DOMAIN_HIERARCHY
> + help
> +Support Mediatek MT58XX Interrupt Controller.
> +
> endmenu
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 133f9c45744a..5062e9bfa92d 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -111,3 +111,4 @@ obj-$(CONFIG_LOONGSON_HTPIC) +=
> irq-loongson-htpic.o
> obj-$(CONFIG_LOONGSON_HTVEC) += irq-loongson-htvec.o
> obj-$(CONFIG_LOONGSON_PCH_PIC)+= irq-loongson-pch-pic.o
> obj-$(CONFIG_LOONGSON_PCH_MSI)+= irq-loongson-pch-msi.o
> +obj-$(CONFIG_MT58XX_IRQ) += irq-mt58xx.o
> diff --git a/drivers/irqchip/irq-mt58xx.c
> b/drivers/irqchip/irq-mt58xx.c
> new file mode 100644
> index ..e45ad023afa6
> --- /dev/null
> +++ b/drivers/irqchip/irq-mt58xx.c
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + * Author Mark-PK Tsai
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define INTC_MASK 0x0
> +#define INTC_EOI 0x20
> +
> +struct mtk_intc_chip_data {
> + char *name;
> + struct irq_chip chip;
There is no need to embed a full struct irqchip per controller, see
below.
We want to distinguish which controller the device interrupts are
belong to
by "cat /proc/interrupts".
And if all the controller share the same struct, the name field will be
the
same.
Do you have suggestion for this?
Yes. /proc/interrupts is not a debug tool, and doesn't need to
show the interrupt routing. We have a debugfs option for this
purpose, and that is what you should use. If it is missing
any information, just say so and I will see what we can do.
[...]
> +static struct irq_chip mtk_intc_chip = {
> + .irq_mask = mtk_intc_mask_irq,
> + .irq_unmask = mtk_intc_unmask_irq,
> + .irq_eoi= mtk_intc_eoi_irq,
> + .irq_get_irqchip_state = irq_chip_get_parent_state,
> + .irq_set_irqchip_state = irq_chip_set_parent_state,
> + .irq_set_affinity = irq_chip_set_affinity_parent,
> + .irq_set_vcpu_affinity = irq_chip_set_vcpu_affinity_parent,
How about retrigger?
What is retrigger means?
It allows the HW to regenerate an interrupt. Set irq_retrigger
to irq_chip_retrigger_hierarchy, and you'll be fine. It is
going to be implemented shortly in the GIC driver.
To be honest, I just try to direct all the irqchip ops implemented in
/drivers/irqchip/irq-gic.c to gic driver.
But "irq_set_vcpu_affinity" is not used in our projects now.
I assume you are not contributing this code just for your
own project...
Should I remove ".irq_set_vcpu_affinity" here?
No, just leave it. Who knows, just in case virtualization becomes
a thing...
M.
--
Jazz is not dead. It just smells funny...
Re: [RFC PATCH 0/8] KVM: x86/mmu: Introduce pinned SPTEs framework
Thanks for series Sean. Some thoughts On 7/31/20 4:23 PM, Sean Christopherson wrote: > SEV currently needs to pin guest memory as it doesn't support migrating > encrypted pages. Introduce a framework in KVM's MMU to support pinning > pages on demand without requiring additional memory allocations, and with > (somewhat hazy) line of sight toward supporting more advanced features for > encrypted guest memory, e.g. host page migration. Eric's attempt to do a lazy pinning suffers with the memory allocation problem and your series seems to address it. As you have noticed, currently the SEV enablement in the KVM does not support migrating the encrypted pages. But the recent SEV firmware provides a support to migrate the encrypted pages (e.g host page migration). The support is available in SEV FW >= 0.17. > The idea is to use a software available bit in the SPTE to track that a > page has been pinned. The decision to pin a page and the actual pinning > managment is handled by vendor code via kvm_x86_ops hooks. There are > intentionally two hooks (zap and unzap) introduced that are not needed for > SEV. I included them to again show how the flag (probably renamed?) could > be used for more than just pin/unpin. If using the available software bits for the tracking the pinning is acceptable then it can be used for the non-SEV guests (if needed). I will look through your patch more carefully but one immediate question, when do we unpin the pages? In the case of the SEV, once a page is pinned then it should not be unpinned until the guest terminates. If we unpin the page before the VM terminates then there is a chance the host page migration will kick-in and move the pages. The KVM MMU code may call to drop the spte's during the zap/unzap and this happens a lot during a guest execution and it will lead us to the path where a vendor specific code will unpin the pages during the guest execution and cause a data corruption for the SEV guest. > Bugs in the core implementation are pretty much guaranteed. The basic > concept has been tested, but in a fairly different incarnation. Most > notably, tagging PRESENT SPTEs as PINNED has not been tested, although > using the PINNED flag to track zapped (and known to be pinned) SPTEs has > been tested. I cobbled this variation together fairly quickly to get the > code out there for discussion. > > The last patch to pin SEV pages during sev_launch_update_data() is > incomplete; it's there to show how we might leverage MMU-based pinning to > support pinning pages before the guest is live. I will add the SEV specific bits and give this a try. > > Sean Christopherson (8): > KVM: x86/mmu: Return old SPTE from mmu_spte_clear_track_bits() > KVM: x86/mmu: Use bits 2:0 to check for present SPTEs > KVM: x86/mmu: Refactor handling of not-present SPTEs in mmu_set_spte() > KVM: x86/mmu: Add infrastructure for pinning PFNs on demand > KVM: SVM: Use the KVM MMU SPTE pinning hooks to pin pages on demand > KVM: x86/mmu: Move 'pfn' variable to caller of direct_page_fault() > KVM: x86/mmu: Introduce kvm_mmu_map_tdp_page() for use by SEV > KVM: SVM: Pin SEV pages in MMU during sev_launch_update_data() > > arch/x86/include/asm/kvm_host.h | 7 ++ > arch/x86/kvm/mmu.h | 3 + > arch/x86/kvm/mmu/mmu.c | 186 +--- > arch/x86/kvm/mmu/paging_tmpl.h | 3 +- > arch/x86/kvm/svm/sev.c | 141 +++- > arch/x86/kvm/svm/svm.c | 3 + > arch/x86/kvm/svm/svm.h | 3 + > 7 files changed, 302 insertions(+), 44 deletions(-) >
[GIT PULL] Filesystem Information
s a string.
In future, I want to make fsinfo() capable of querying a context created by
fsopen() or fspick(), e.g.:
fd = fsopen("ext4", 0);
struct fsinfo_params params = {
.flags = FSINFO_FLAGS_QUERY_FSCONTEXT,
.request= FSINFO_ATTR_CONFIGURATION;
};
char buffer[65536];
fsinfo(fd, NULL, , sizeof(params), , sizeof(buffer));
even if that context doesn't currently have a superblock attached.
David
---
The following changes since commit 841a0dfa511364fa9a8d67512e0643669f1f03e3:
watch_queue: sample: Display mount tree change notifications (2020-08-03
12:15:38 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
tags/fsinfo-core-20200803
for you to fetch changes up to 19d687f5902b65a158c5bec904d65d0525ea4efe:
samples: add error state information to test-fsinfo.c (2020-08-03 13:43:46
+0100)
Filesystem information
David Howells (15):
fsinfo: Introduce a non-repeating system-unique superblock ID
fsinfo: Add fsinfo() syscall to query filesystem information
fsinfo: Provide a bitmap of the features a filesystem supports
fsinfo: Allow retrieval of superblock devname, options and stats
fsinfo: Allow fsinfo() to look up a mount object by ID
fsinfo: Add a uniquifier ID to struct mount
fsinfo: Allow mount information to be queried
fsinfo: Allow mount topology and propagation info to be retrieved
watch_queue: Mount event counters
fsinfo: Provide notification overrun handling support
fsinfo: sample: Mount listing program
fsinfo: Add API documentation
fsinfo: Add support for AFS
fsinfo: Add support to ext4
fsinfo: Add an attribute that lists all the visible mounts in a namespace
Jeff Layton (3):
errseq: add a new errseq_scrape function
vfs: allow fsinfo to fetch the current state of s_wb_err
samples: add error state information to test-fsinfo.c
Documentation/filesystems/fsinfo.rst| 574 ++
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl| 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
fs/Kconfig | 7 +
fs/Makefile | 1 +
fs/afs/internal.h | 1 +
fs/afs/super.c | 216 ++-
fs/d_path.c | 2 +-
fs/ext4/Makefile| 1 +
fs/ext4/ext4.h | 6 +
fs/ext4/fsinfo.c| 97 +++
fs/ext4/super.c | 3 +
fs/fsinfo.c | 748 +++
fs/internal.h | 16 +
fs/mount.h | 6 +
fs/mount_notify.c | 10 +-
fs/namespace.c | 427 +-
fs/super.c | 2 +
include/linux/errseq.h | 1 +
include/linux/fs.h | 7 +
include/linux/fsinfo.h | 112
include/linux/syscalls.h| 4 +
include/uapi/asm-generic/unistd.h | 4 +-
include/uapi/linux/fsinfo.h | 344 +++
include/uapi/linux/mount.h | 13 +-
kernel/sys_ni.c | 1 +
lib/errseq.c| 33 +-
samples/vfs/Makefile| 6 +-
samples/vfs/test-fsinfo.c | 883
samples/vfs/test-mntinfo.c | 277 +
46 files changed, 3808 insertions(+), 14 deletions(-)
create mode 100644 Documentation/filesystems/fsinfo.rst
create mode 100644 fs/ext4/fsinfo.c
create mode 100644 fs/fsinfo.c
create mode 100644 include/linux/fsinfo.h
create mode 100644 include/uapi/linux/fsinf
[PATCH] sched/cpuacct:Fix previous bugs submitted in history.
Historical submission introduces new issues that When the current cpu wakes up the thread which works on other cores,the cpuacct module may add the execution time of thread which on the the other core's rq to the current core's cpuusage. Signed-off-by: ning.le --- kernel/sched/cpuacct.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index 941c28cf9738..bd38c9cffdd6 100644 --- a/kernel/sched/cpuacct.c +++ b/kernel/sched/cpuacct.c @@ -341,6 +341,7 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime) struct cpuacct *ca; int index = CPUACCT_STAT_SYSTEM; struct pt_regs *regs = get_irq_regs() ? : task_pt_regs(tsk); + int cpu = task_cpu(tsk); if (regs && user_mode(regs)) index = CPUACCT_STAT_USER; @@ -348,8 +349,7 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime) rcu_read_lock(); for (ca = task_ca(tsk); ca; ca = parent_ca(ca)) - __this_cpu_add(ca->cpuusage->usages[index], cputime); - + per_cpu_ptr(ca->cpuusage, cpu)->usages[index] += cputime; rcu_read_unlock(); } -- 2.17.1 - ±¾Óʼþ¼°Æ丽¼þº¬ÓÐлªÈý¼¯Íŵı£ÃÜÐÅÏ¢£¬½öÏÞÓÚ·¢Ë͸øÉÏÃæµØÖ·ÖÐÁгö µÄ¸öÈË»òȺ×é¡£½ûÖ¹ÈκÎÆäËûÈËÒÔÈκÎÐÎʽʹÓ㨰üÀ¨µ«²»ÏÞÓÚÈ«²¿»ò²¿·ÖµØй¶¡¢¸´ÖÆ¡¢ »òÉ¢·¢£©±¾ÓʼþÖеÄÐÅÏ¢¡£Èç¹ûÄú´íÊÕÁ˱¾Óʼþ£¬ÇëÄúÁ¢¼´µç»°»òÓʼþ֪ͨ·¢¼þÈ˲¢É¾³ý±¾ Óʼþ£¡ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting
On 03/08/20 16:13, Thomas Gleixner wrote: > Vladimir Oltean writes: >>> 1) When irq accounting is disabled, RT throttling kicks in as >>> expected. >>> >>> 2) With irq accounting the RT throttler does not kick in and the RCU >>> stall/lockups happen. >> What is this telling us? > > It seems that the fine grained irq time accounting affects the runtime > accounting in some way which I haven't figured out yet. > With IRQ_TIME_ACCOUNTING, rq_clock_task() will always be incremented by a lesser-or-equal value than when not having the option; you start with the same delta_exec but slice some for the IRQ accounting, and leave the rest for the rq_clock_task() (+paravirt). IIUC this means that if you spend e.g. 10% of the time in IRQ and 90% of the time running the stress-ng RT tasks, despite having RT tasks hogging the entirety of the "available time" it is still only 90% runtime, which is below the 95% default and the throttling doesn't happen. I don't know if considering IRQ time in some way or another in sched_rt_runtime_exceeded() really is a way out here. > Thanks, > > tglx
Re: [PATCH] mm, memory_hotplug: update pcp lists everytime onlining a memory block
On Sun 02-08-20 18:24:56, Charan Teja Reddy wrote:
> When onlining a first memory block in a zone, pcp lists are not updated
> thus pcp struct will have the default setting of ->high = 0,->batch = 1.
> This means till the second memory block in a zone(if it have) is onlined
> the pcp lists of this zone will not contain any pages because pcp's
> ->count is always greater than ->high thus free_pcppages_bulk() is
> called to free batch size(=1) pages every time system wants to add a
> page to the pcp list through free_unref_page(). To put this in a word,
> system is not using benefits offered by the pcp lists when there is a
> single onlineable memory block in a zone. Correct this by always
> updating the pcp lists when memory block is onlined.
Yes this seems like an ancient bug
Fixes: 1f522509c77a ("mem-hotplug: avoid multiple zones sharing same boot
strapping boot_pageset")
Just nobody has noticed because a single block memory zone is really
rare.
> Signed-off-by: Charan Teja Reddy
Acked-by: Michal Hocko
Thanks
> ---
> mm/memory_hotplug.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index dcdf327..7f62d69 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -854,8 +854,7 @@ int __ref online_pages(unsigned long pfn, unsigned long
> nr_pages,
> node_states_set_node(nid, );
> if (need_zonelists_rebuild)
> build_all_zonelists(NULL);
> - else
> - zone_pcp_update(zone);
> + zone_pcp_update(zone);
>
> init_per_zone_wmark_min();
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of the Code Aurora Forum, hosted by The Linux Foundation
>
--
Michal Hocko
SUSE Labs
Re: [PATCH] mm: sort freelist by rank number
On 8/3/20 9:57 AM, David Hildenbrand wrote: > On 03.08.20 08:10, pullip@samsung.com wrote: >> From: Cho KyongHo >> >> LPDDR5 introduces rank switch delay. If three successive DRAM accesses >> happens and the first and the second ones access one rank and the last >> access happens on the other rank, the latency of the last access will >> be longer than the second one. >> To address this panelty, we can sort the freelist so that a specific >> rank is allocated prior to another rank. We expect the page allocator >> can allocate the pages from the same rank successively with this >> change. It will hopefully improves the proportion of the consecutive >> memory accesses to the same rank. > > This certainly needs performance numbers to justify ... and I am sorry, > "hopefully improves" is not a valid justification :) > > I can imagine that this works well initially, when there hasn't been a > lot of memory fragmentation going on. But quickly after your system is > under stress, I doubt this will be very useful. Proof me wrong. ;) Agreed. The implementation of __preferred_rank() seems to be very simple and optimistic. I think these systems could perhaps better behave as NUMA with (interleaved) nodes for each rank, then you immediately have all the mempolicies support etc to achieve what you need? Of course there's some cost as well, but not the costs of adding hacks to page allocator core?
[PATCH v8 05/10] media: tegra-video: Separate CSI stream enable and disable implementations
This patch separates implementation of CSI stream enable and disable
into separate functions for readability.
Reviewed-by: Dmitry Osipenko
Signed-off-by: Sowjanya Komatineni
---
drivers/staging/media/tegra-video/csi.c | 51 ++---
1 file changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/media/tegra-video/csi.c
b/drivers/staging/media/tegra-video/csi.c
index fb667df..cfe6187 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -232,34 +232,53 @@ static int tegra_csi_g_frame_interval(struct v4l2_subdev
*subdev,
return 0;
}
-static int tegra_csi_s_stream(struct v4l2_subdev *subdev, int enable)
+static int tegra_csi_enable_stream(struct v4l2_subdev *subdev)
{
struct tegra_vi_channel *chan = v4l2_get_subdev_hostdata(subdev);
struct tegra_csi_channel *csi_chan = to_csi_chan(subdev);
struct tegra_csi *csi = csi_chan->csi;
- int ret = 0;
+ int ret;
+
+ ret = pm_runtime_get_sync(csi->dev);
+ if (ret < 0) {
+ dev_err(csi->dev, "failed to get runtime PM: %d\n", ret);
+ pm_runtime_put_noidle(csi->dev);
+ return ret;
+ }
csi_chan->pg_mode = chan->pg_mode;
- if (enable) {
- ret = pm_runtime_get_sync(csi->dev);
- if (ret < 0) {
- dev_err(csi->dev,
- "failed to get runtime PM: %d\n", ret);
- pm_runtime_put_noidle(csi->dev);
- return ret;
- }
+ ret = csi->ops->csi_start_streaming(csi_chan);
+ if (ret < 0)
+ goto rpm_put;
- ret = csi->ops->csi_start_streaming(csi_chan);
- if (ret < 0)
- goto rpm_put;
+ return 0;
- return 0;
- }
+rpm_put:
+ pm_runtime_put(csi->dev);
+ return ret;
+}
+
+static int tegra_csi_disable_stream(struct v4l2_subdev *subdev)
+{
+ struct tegra_csi_channel *csi_chan = to_csi_chan(subdev);
+ struct tegra_csi *csi = csi_chan->csi;
csi->ops->csi_stop_streaming(csi_chan);
-rpm_put:
pm_runtime_put(csi->dev);
+
+ return 0;
+}
+
+static int tegra_csi_s_stream(struct v4l2_subdev *subdev, int enable)
+{
+ int ret;
+
+ if (enable)
+ ret = tegra_csi_enable_stream(subdev);
+ else
+ ret = tegra_csi_disable_stream(subdev);
+
return ret;
}
--
2.7.4
Re: Re: [RFC PATCH 4/4] i2c: at91: Move to generic GPIO bus recovery
On 02.08.2020 20:08, Wolfram Sang wrote: > On Fri, Jun 19, 2020 at 05:19:04PM +0300, Codrin Ciubotariu wrote: >> Make the Microchip at91 driver the first to use the generic GPIO bus >> recovery support from the I2C core and discard the driver implementation. >> >> Signed-off-by: Codrin Ciubotariu >> --- >> drivers/i2c/busses/i2c-at91-master.c | 69 ++-- >> drivers/i2c/busses/i2c-at91.h| 3 -- > > Nice diffstat! I will try using this new functionality with another > controller next week. > Thanks, this would be great! I tested this on a sam9x60, with the HW feature for the 9 pulses disabled, with a picky audio codec as I2C device. Please let me know of the result. Best regards, Codrin
[PATCH v8 03/10] media: tegra-video: Update format lookup to offset based
Tegra VI supported video formats are more for non TPG and there
can be multiple pixel formats for the same media bus format.
This patch updates the helper function for format lookup based on
mbus code from pre-defined Tegra supported format list to look from
the specified list index offset.
Offset based look up is used with sensor device graph (non TPG)
where format enumeration can list all supported formats for the
specific sensor mbus codes.
Signed-off-by: Sowjanya Komatineni
---
drivers/staging/media/tegra-video/vi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/tegra-video/vi.c
b/drivers/staging/media/tegra-video/vi.c
index 0197f4e..52d751f 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -53,11 +53,12 @@ to_tegra_channel_buffer(struct vb2_v4l2_buffer *vb)
}
static int tegra_get_format_idx_by_code(struct tegra_vi *vi,
- unsigned int code)
+ unsigned int code,
+ unsigned int offset)
{
unsigned int i;
- for (i = 0; i < vi->soc->nformats; ++i) {
+ for (i = offset; i < vi->soc->nformats; ++i) {
if (vi->soc->video_formats[i].code == code)
return i;
}
@@ -598,11 +599,12 @@ static void vi_tpg_fmts_bitmap_init(struct
tegra_vi_channel *chan)
bitmap_zero(chan->tpg_fmts_bitmap, MAX_FORMAT_NUM);
index = tegra_get_format_idx_by_code(chan->vi,
-MEDIA_BUS_FMT_SRGGB10_1X10);
+MEDIA_BUS_FMT_SRGGB10_1X10, 0);
bitmap_set(chan->tpg_fmts_bitmap, index, 1);
index = tegra_get_format_idx_by_code(chan->vi,
-MEDIA_BUS_FMT_RGB888_1X32_PADHI);
+MEDIA_BUS_FMT_RGB888_1X32_PADHI,
+0);
bitmap_set(chan->tpg_fmts_bitmap, index, 1);
}
--
2.7.4
[PATCH v8 08/10] gpu: host1x: mipi: Keep MIPI clock enabled till calibration is done
With the split of MIPI calibration into tegra_mipi_calibrate() and
tegra_mipi_wait(), MIPI clock is not kept enabled till the calibration
is done.
So, this patch skips disabling MIPI clock after triggering start of
calibration and disables it only after waiting for done status from
the calibration logic.
This patch renames tegra_mipi_calibrate() as tegra_mipi_start_calibration()
and tegra_mipi_wait() as tegra_mipi_finish_calibration() to be inline
with their usage.
As MIPI clock is left enabled and in case of any failures with CSI input
streaming tegra_mipi_finish_calibration() will not get invoked.
So added new API tegra_mipi_cancel_calibration() which disables MIPI clock
and consumer drivers can call this in such cases.
Reviewed-by: Dmitry Osipenko
Signed-off-by: Sowjanya Komatineni
---
drivers/gpu/drm/tegra/dsi.c | 4 ++--
drivers/gpu/host1x/mipi.c | 19 ++-
include/linux/host1x.h | 5 +++--
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 3820e8d..a7864e9 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -694,11 +694,11 @@ static int tegra_dsi_pad_calibrate(struct tegra_dsi *dsi)
DSI_PAD_PREEMP_PD(0x03) | DSI_PAD_PREEMP_PU(0x3);
tegra_dsi_writel(dsi, value, DSI_PAD_CONTROL_3);
- err = tegra_mipi_calibrate(dsi->mipi);
+ err = tegra_mipi_start_calibration(dsi->mipi);
if (err < 0)
return err;
- return tegra_mipi_wait(dsi->mipi);
+ return tegra_mipi_finish_calibration(dsi->mipi);
}
static void tegra_dsi_set_timeout(struct tegra_dsi *dsi, unsigned long bclk,
diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
index e606464..b15ab6e 100644
--- a/drivers/gpu/host1x/mipi.c
+++ b/drivers/gpu/host1x/mipi.c
@@ -293,17 +293,19 @@ int tegra_mipi_disable(struct tegra_mipi_device *dev)
}
EXPORT_SYMBOL(tegra_mipi_disable);
-int tegra_mipi_wait(struct tegra_mipi_device *device)
+void tegra_mipi_cancel_calibration(struct tegra_mipi_device *device)
+{
+ clk_disable(device->mipi->clk);
+}
+EXPORT_SYMBOL(tegra_mipi_cancel_calibration);
+
+int tegra_mipi_finish_calibration(struct tegra_mipi_device *device)
{
struct tegra_mipi *mipi = device->mipi;
void __iomem *status_reg = mipi->regs + (MIPI_CAL_STATUS << 2);
u32 value;
int err;
- err = clk_enable(device->mipi->clk);
- if (err < 0)
- return err;
-
mutex_lock(>mipi->lock);
err = readl_relaxed_poll_timeout(status_reg, value,
@@ -315,9 +317,9 @@ int tegra_mipi_wait(struct tegra_mipi_device *device)
return err;
}
-EXPORT_SYMBOL(tegra_mipi_wait);
+EXPORT_SYMBOL(tegra_mipi_finish_calibration);
-int tegra_mipi_calibrate(struct tegra_mipi_device *device)
+int tegra_mipi_start_calibration(struct tegra_mipi_device *device)
{
const struct tegra_mipi_soc *soc = device->mipi->soc;
unsigned int i;
@@ -382,11 +384,10 @@ int tegra_mipi_calibrate(struct tegra_mipi_device *device)
tegra_mipi_writel(device->mipi, value, MIPI_CAL_CTRL);
mutex_unlock(>mipi->lock);
- clk_disable(device->mipi->clk);
return 0;
}
-EXPORT_SYMBOL(tegra_mipi_calibrate);
+EXPORT_SYMBOL(tegra_mipi_start_calibration);
static const struct tegra_mipi_pad tegra114_mipi_pads[] = {
{ .data = MIPI_CAL_CONFIG_CSIA },
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 20c885d..b490dda 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -333,7 +333,8 @@ struct tegra_mipi_device *tegra_mipi_request(struct device
*device,
void tegra_mipi_free(struct tegra_mipi_device *device);
int tegra_mipi_enable(struct tegra_mipi_device *device);
int tegra_mipi_disable(struct tegra_mipi_device *device);
-int tegra_mipi_calibrate(struct tegra_mipi_device *device);
-int tegra_mipi_wait(struct tegra_mipi_device *device);
+int tegra_mipi_start_calibration(struct tegra_mipi_device *device);
+int tegra_mipi_finish_calibration(struct tegra_mipi_device *device);
+void tegra_mipi_cancel_calibration(struct tegra_mipi_device *device);
#endif
--
2.7.4
[PATCH v8 04/10] dt-bindings: tegra: Update VI and CSI bindings with port info
Update VI and CSI bindings to add port and endpoint nodes as per
media video-interfaces DT binding document.
Acked-by: Rob Herring
Signed-off-by: Sowjanya Komatineni
---
.../display/tegra/nvidia,tegra20-host1x.txt| 92 +-
1 file changed, 90 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index 4731921..ac63ae4a 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -51,8 +51,16 @@ of the following host1x client modules:
- vi
- Tegra210:
- power-domains: Must include venc powergate node as vi is in VE partition.
- - Tegra210 has CSI part of VI sharing same host interface and register space.
-So, VI device node should have CSI child node.
+
+ ports (optional node)
+ vi can have optional ports node and max 6 ports are supported. Each port
+ should have single 'endpoint' child node. All port nodes are grouped under
+ ports node. Please refer to the bindings defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+ csi (required node)
+ Tegra210 has CSI part of VI sharing same host interface and register space.
+ So, VI device node should have CSI child node.
- csi: mipi csi interface to vi
@@ -65,6 +73,46 @@ of the following host1x client modules:
- power-domains: Must include sor powergate node as csicil is in
SOR partition.
+ channel (optional nodes)
+ Maximum 6 channels are supported with each csi brick as either x4 or x2
+ based on hw connectivity to sensor.
+
+ Required properties:
+ - reg: csi port number. Valid port numbers are 0 through 5.
+ - nvidia,mipi-calibrate: Should contain a phandle and a specifier
+specifying which pads are used by this CSI port and need to be
+ calibrated. See also ../display/tegra/nvidia,tegra114-mipi.txt.
+
+ Each channel node must contain 2 port nodes which can be grouped
+ under 'ports' node and each port should have a single child 'endpoint'
+ node.
+
+ports node
+Please refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+ports node must contain below 2 port nodes.
+port@0 with single child 'endpoint' node always a sink.
+port@1 with single child 'endpoint' node always a source.
+
+port@0 (required node)
+Required properties:
+- reg: 0
+
+ endpoint (required node)
+ Required properties:
+ - data-lanes: an array of data lane from 1 to 4. Valid array
+ lengths are 1/2/4.
+ - remote-endpoint: phandle to sensor 'endpoint' node.
+
+port@1 (required node)
+Required properties:
+- reg: 1
+
+ endpoint (required node)
+ Required properties:
+ - remote-endpoint: phandle to vi port 'endpoint' node.
+
- epp: encoder pre-processor
Required properties:
@@ -340,6 +388,18 @@ Example:
ranges = <0x0 0x0 0x5408 0x2000>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ imx219_vi_in0: endpoint {
+ remote-endpoint =
<_csi_out0>;
+ };
+ };
+ };
+
csi@838 {
compatible = "nvidia,tegra210-csi";
reg = <0x838 0x1300>;
@@ -362,6 +422,34 @@ Example:
<_car TEGRA210_CLK_CSI_TPG>;
clock-names = "csi", "cilab", "cilcd", "cile",
"csi_tpg";
power-domains = <_sor>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ nvidia,mipi-calibrate = < 0x001>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ imx219_csi_in0:
endpoint {
+ data-lanes = <1
2>;
+ remote-endpoint
= <_out0>;
+
[PATCH v8 06/10] media: tegra-video: Add support for external sensor capture
This patch adds support to capture from the external sensor
based on device graph in the device tree.
Driver walks through the device graph to create media links
between the entities and registers and unregisters video devices
when the corresponding sub-devices are bound and unbound.
Channel formats are enumerated based on available formats from
the sensor and the corresponding matched formats from the Tegra
supported video formats list.
Each Tegra CSI instance can be configured as 4-lane or 2-lane
based on supported lane configuration from the sensor through
the device tree.
Currently this driver supports V4L2 video node centric only.
Signed-off-by: Sowjanya Komatineni
---
drivers/staging/media/tegra-video/Kconfig| 1 +
drivers/staging/media/tegra-video/TODO | 4 -
drivers/staging/media/tegra-video/csi.c | 139 +-
drivers/staging/media/tegra-video/csi.h | 1 +
drivers/staging/media/tegra-video/tegra210.c | 2 +-
drivers/staging/media/tegra-video/vi.c | 692 +--
drivers/staging/media/tegra-video/vi.h | 25 +-
7 files changed, 800 insertions(+), 64 deletions(-)
diff --git a/drivers/staging/media/tegra-video/Kconfig
b/drivers/staging/media/tegra-video/Kconfig
index 566da62..1f35da4 100644
--- a/drivers/staging/media/tegra-video/Kconfig
+++ b/drivers/staging/media/tegra-video/Kconfig
@@ -5,6 +5,7 @@ config VIDEO_TEGRA
depends on VIDEO_V4L2
select MEDIA_CONTROLLER
select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
help
Choose this option if you have an NVIDIA Tegra SoC.
diff --git a/drivers/staging/media/tegra-video/TODO
b/drivers/staging/media/tegra-video/TODO
index 6ceb7549..97a19b4 100644
--- a/drivers/staging/media/tegra-video/TODO
+++ b/drivers/staging/media/tegra-video/TODO
@@ -1,8 +1,4 @@
TODO list
-* Currently driver supports Tegra build-in TPG only with direct media links
- from CSI to VI. Add kernel config CONFIG_VIDEO_TEGRA_TPG and update the
- driver to do TPG Vs Sensor media links based on CONFIG_VIDEO_TEGRA_TPG.
-* Add real camera sensor capture support.
* Add Tegra CSI MIPI pads calibration.
* Add MIPI clock Settle time computation based on the data rate.
* Add support for Ganged mode.
diff --git a/drivers/staging/media/tegra-video/csi.c
b/drivers/staging/media/tegra-video/csi.c
index cfe6187..4176933 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -9,10 +9,13 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
+
#include "csi.h"
#include "video.h"
@@ -304,31 +307,115 @@ static const struct v4l2_subdev_ops tegra_csi_ops = {
.pad= _csi_pad_ops,
};
+static int tegra_csi_channel_alloc(struct tegra_csi *csi,
+ struct device_node *node,
+ unsigned int port_num, unsigned int lanes,
+ unsigned int num_pads)
+{
+ struct tegra_csi_channel *chan;
+
+ chan = kzalloc(sizeof(*chan), GFP_KERNEL);
+ if (!chan)
+ return -ENOMEM;
+
+ list_add_tail(>list, >csi_chans);
+ chan->csi = csi;
+ chan->csi_port_num = port_num;
+ chan->numlanes = lanes;
+ chan->of_node = node;
+ chan->numpads = num_pads;
+ if (num_pads & 0x2) {
+ chan->pads[0].flags = MEDIA_PAD_FL_SINK;
+ chan->pads[1].flags = MEDIA_PAD_FL_SOURCE;
+ } else {
+ chan->pads[0].flags = MEDIA_PAD_FL_SOURCE;
+ }
+
+ return 0;
+}
+
static int tegra_csi_tpg_channels_alloc(struct tegra_csi *csi)
{
struct device_node *node = csi->dev->of_node;
unsigned int port_num;
- struct tegra_csi_channel *chan;
unsigned int tpg_channels = csi->soc->csi_max_channels;
+ int ret;
/* allocate CSI channel for each CSI x2 ports */
for (port_num = 0; port_num < tpg_channels; port_num++) {
- chan = kzalloc(sizeof(*chan), GFP_KERNEL);
- if (!chan)
- return -ENOMEM;
-
- list_add_tail(>list, >csi_chans);
- chan->csi = csi;
- chan->csi_port_num = port_num;
- chan->numlanes = 2;
- chan->of_node = node;
- chan->numpads = 1;
- chan->pads[0].flags = MEDIA_PAD_FL_SOURCE;
+ ret = tegra_csi_channel_alloc(csi, node, port_num, 2, 1);
+ if (ret < 0)
+ return ret;
}
return 0;
}
+static int tegra_csi_channels_alloc(struct tegra_csi *csi)
+{
+ struct device_node *node = csi->dev->of_node;
+ struct v4l2_fwnode_endpoint v4l2_ep = {
+ .bus_type = V4L2_MBUS_CSI2_DPHY
+ };
+ struct fwnode_handle *fwh;
+ struct device_node *channel;
+ struct device_node *ep;
+ unsigned int lanes, portno, num_pads;
+ int
Re: [RFC PATCH 0/5] madvise MADV_DOEXEC
On Mon, 2020-08-03 at 10:28 -0500, Eric W. Biederman wrote: [...] > What is wrong with live migration between one qemu process and > another qemu process on the same machine not work for this use case? > > Just reusing live migration would seem to be the simplest path of > all, as the code is already implemented. Further if something goes > wrong with the live migration you can fallback to the existing > process. With exec there is no fallback if the new version does not > properly support the handoff protocol of the old version. Actually, could I ask this another way: the other patch set you sent to the KVM list was to snapshot the VM to a PKRAM capsule preserved across kexec using zero copy for extremely fast save/restore. The original idea was to use this as part of a CRIU based snapshot, kexec to new system, restore. However, why can't you do a local snapshot, restart qemu, restore using the PKRAM capsule to achieve exactly the same as MADV_DOEXEC does but using a system that's easy to reason about? It may be slightly slower, but I think we're still talking milliseconds. James
[PATCH v8 07/10] media: tegra-video: Add support for selection ioctl ops
This patch adds selection v4l2 ioctl operations to allow configuring
a selection rectangle in the sensor through the Tegra video device
node.
Some sensor drivers supporting crop uses try_crop rectangle from
v4l2_subdev_pad_config during try format for computing binning.
So with selection ops support, this patch also updates try format
to use try crop rectangle either from subdev frame size enumeration
or from subdev crop boundary.
Signed-off-by: Sowjanya Komatineni
---
drivers/staging/media/tegra-video/vi.c | 106 +
1 file changed, 106 insertions(+)
diff --git a/drivers/staging/media/tegra-video/vi.c
b/drivers/staging/media/tegra-video/vi.c
index deb1252..29a172f 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -474,6 +474,13 @@ static int __tegra_channel_try_format(struct
tegra_vi_channel *chan,
struct v4l2_subdev *subdev;
struct v4l2_subdev_format fmt;
struct v4l2_subdev_pad_config *pad_cfg;
+ struct v4l2_subdev_frame_size_enum fse = {
+ .which = V4L2_SUBDEV_FORMAT_TRY,
+ };
+ struct v4l2_subdev_selection sdsel = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ .target = V4L2_SEL_TGT_CROP_BOUNDS,
+ };
int ret;
subdev = tegra_channel_get_remote_source_subdev(chan);
@@ -499,6 +506,24 @@ static int __tegra_channel_try_format(struct
tegra_vi_channel *chan,
fmt.which = V4L2_SUBDEV_FORMAT_TRY;
fmt.pad = 0;
v4l2_fill_mbus_format(, pix, fmtinfo->code);
+
+ /*
+* Attempt to obtain the format size from subdev.
+* If not available, try to get crop boundary from subdev.
+*/
+ fse.code = fmtinfo->code;
+ ret = v4l2_subdev_call(subdev, pad, enum_frame_size, pad_cfg, );
+ if (ret) {
+ ret = v4l2_subdev_call(subdev, pad, get_selection, NULL,
);
+ if (ret)
+ return -EINVAL;
+ pad_cfg->try_crop.width = sdsel.r.width;
+ pad_cfg->try_crop.height = sdsel.r.height;
+ } else {
+ pad_cfg->try_crop.width = fse.max_width;
+ pad_cfg->try_crop.height = fse.max_height;
+ }
+
ret = v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, );
if (ret < 0)
return ret;
@@ -588,6 +613,85 @@ static int tegra_channel_set_subdev_active_fmt(struct
tegra_vi_channel *chan)
return 0;
}
+static int tegra_channel_g_selection(struct file *file, void *priv,
+struct v4l2_selection *sel)
+{
+ struct tegra_vi_channel *chan = video_drvdata(file);
+ struct v4l2_subdev *subdev;
+ struct v4l2_subdev_format fmt = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ };
+ struct v4l2_subdev_selection sdsel = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ .target = sel->target,
+ };
+ int ret;
+
+ subdev = tegra_channel_get_remote_source_subdev(chan);
+ if (!v4l2_subdev_has_op(subdev, pad, get_selection))
+ return -ENOTTY;
+
+ if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+ /*
+* Try the get selection operation and fallback to get format if not
+* implemented.
+*/
+ ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, );
+ if (!ret)
+ sel->r = sdsel.r;
+ if (ret != -ENOIOCTLCMD)
+ return ret;
+
+ ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, );
+ if (ret < 0)
+ return ret;
+
+ sel->r.left = 0;
+ sel->r.top = 0;
+ sel->r.width = fmt.format.width;
+ sel->r.height = fmt.format.height;
+
+ return 0;
+}
+
+static int tegra_channel_s_selection(struct file *file, void *fh,
+struct v4l2_selection *sel)
+{
+ struct tegra_vi_channel *chan = video_drvdata(file);
+ struct v4l2_subdev *subdev;
+ int ret;
+ struct v4l2_subdev_selection sdsel = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ .target = sel->target,
+ .flags = sel->flags,
+ .r = sel->r,
+ };
+
+ subdev = tegra_channel_get_remote_source_subdev(chan);
+ if (!v4l2_subdev_has_op(subdev, pad, set_selection))
+ return -ENOTTY;
+
+ if (sel->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ if (vb2_is_busy(>queue))
+ return -EBUSY;
+
+ ret = v4l2_subdev_call(subdev, pad, set_selection, NULL, );
+ if (!ret) {
+ sel->r = sdsel.r;
+ /*
+* Subdev active format resolution may have changed during
+* set selection operation. So, update channel format to
+* the sub-device active format.
+*/
+ return
[PATCH v8 02/10] media: tegra-video: Enable TPG based on kernel config
Tegra internal TPG mode is only for Tegra vi and csi testing
without a real sensor and driver should default support real
sensor.
So, This patch adds CONFIG_VIDEO_TEGRA_TPG and enables Tegra
internal TPG mode only when this config is selected.
Signed-off-by: Sowjanya Komatineni
---
drivers/staging/media/tegra-video/Kconfig| 6 +
drivers/staging/media/tegra-video/csi.c | 38 +++-
drivers/staging/media/tegra-video/tegra210.c | 6 +
drivers/staging/media/tegra-video/vi.c | 13 +++---
drivers/staging/media/tegra-video/video.c| 23 +
5 files changed, 65 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/media/tegra-video/Kconfig
b/drivers/staging/media/tegra-video/Kconfig
index f6c61ec..566da62 100644
--- a/drivers/staging/media/tegra-video/Kconfig
+++ b/drivers/staging/media/tegra-video/Kconfig
@@ -10,3 +10,9 @@ config VIDEO_TEGRA
To compile this driver as a module, choose M here: the module
will be called tegra-video.
+
+config VIDEO_TEGRA_TPG
+ bool "NVIDIA Tegra VI driver TPG mode"
+ depends on VIDEO_TEGRA
+ help
+ Say yes here to enable Tegra internal TPG mode
diff --git a/drivers/staging/media/tegra-video/csi.c
b/drivers/staging/media/tegra-video/csi.c
index 40ea195..fb667df 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -62,6 +62,9 @@ static int csi_enum_bus_code(struct v4l2_subdev *subdev,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code)
{
+ if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return -ENOIOCTLCMD;
+
if (code->index >= ARRAY_SIZE(tegra_csi_tpg_fmts))
return -EINVAL;
@@ -76,6 +79,9 @@ static int csi_get_format(struct v4l2_subdev *subdev,
{
struct tegra_csi_channel *csi_chan = to_csi_chan(subdev);
+ if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return -ENOIOCTLCMD;
+
fmt->format = csi_chan->format;
return 0;
@@ -121,6 +127,9 @@ static int csi_enum_framesizes(struct v4l2_subdev *subdev,
{
unsigned int i;
+ if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return -ENOIOCTLCMD;
+
if (fse->index >= ARRAY_SIZE(tegra_csi_tpg_sizes))
return -EINVAL;
@@ -148,6 +157,9 @@ static int csi_enum_frameintervals(struct v4l2_subdev
*subdev,
const struct tpg_framerate *frmrate = csi->soc->tpg_frmrate_table;
int index;
+ if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return -ENOIOCTLCMD;
+
/* one framerate per format and resolution */
if (fie->index > 0)
return -EINVAL;
@@ -172,6 +184,9 @@ static int csi_set_format(struct v4l2_subdev *subdev,
const struct v4l2_frmsize_discrete *sizes;
unsigned int i;
+ if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return -ENOIOCTLCMD;
+
sizes = v4l2_find_nearest_size(tegra_csi_tpg_sizes,
ARRAY_SIZE(tegra_csi_tpg_sizes),
width, height,
@@ -208,6 +223,9 @@ static int tegra_csi_g_frame_interval(struct v4l2_subdev
*subdev,
{
struct tegra_csi_channel *csi_chan = to_csi_chan(subdev);
+ if (!IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ return -ENOIOCTLCMD;
+
vfi->interval.numerator = 1;
vfi->interval.denominator = csi_chan->framerate;
@@ -311,8 +329,12 @@ static int tegra_csi_channel_init(struct tegra_csi_channel
*chan)
subdev = >subdev;
v4l2_subdev_init(subdev, _csi_ops);
subdev->dev = csi->dev;
- snprintf(subdev->name, V4L2_SUBDEV_NAME_SIZE, "%s-%d", "tpg",
-chan->csi_port_num);
+ if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG))
+ snprintf(subdev->name, V4L2_SUBDEV_NAME_SIZE, "%s-%d", "tpg",
+chan->csi_port_num);
+ else
+ snprintf(subdev->name, V4L2_SUBDEV_NAME_SIZE, "%s",
+kbasename(chan->of_node->full_name));
v4l2_set_subdevdata(subdev, chan);
subdev->fwnode = of_fwnode_handle(chan->of_node);
@@ -405,11 +427,13 @@ static int tegra_csi_init(struct host1x_client *client)
INIT_LIST_HEAD(>csi_chans);
- ret = tegra_csi_tpg_channels_alloc(csi);
- if (ret < 0) {
- dev_err(csi->dev,
- "failed to allocate tpg channels: %d\n", ret);
- goto cleanup;
+ if (IS_ENABLED(CONFIG_VIDEO_TEGRA_TPG)) {
+ ret = tegra_csi_tpg_channels_alloc(csi);
+ if (ret < 0) {
+ dev_err(csi->dev,
+ "failed to allocate tpg channels: %d\n", ret);
+ goto cleanup;
+ }
}
ret = tegra_csi_channels_init(csi);
diff --git
[PATCH v8 10/10] media: tegra-video: Compute settle times based on the clock rate
Settle time determines the number of cil clock cyles to wait after
LP00 when moving from LP to HS.
This patch computes T-CLK-SETTLE and T-HS-SETTLE times based on cil
clock rate and pixel rate from the sensor and programs them during
streaming.
T-CLK-SETTLE time is the interval during which receiver will ignore
any HS transitions on clock lane starting from the beginning of
T-CLK-PREPARE.
T-HS-SETTLE time is the interval during which recevier will ignore
any HS transitions on data lane starting from the beginning of
T-HS-PREPARE.
Signed-off-by: Sowjanya Komatineni
---
drivers/staging/media/tegra-video/TODO | 1 -
drivers/staging/media/tegra-video/csi.c | 55
drivers/staging/media/tegra-video/csi.h | 5 +++
drivers/staging/media/tegra-video/tegra210.c | 17 -
4 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/tegra-video/TODO
b/drivers/staging/media/tegra-video/TODO
index 98d3c7d..c821081 100644
--- a/drivers/staging/media/tegra-video/TODO
+++ b/drivers/staging/media/tegra-video/TODO
@@ -1,5 +1,4 @@
TODO list
-* Add MIPI clock Settle time computation based on the data rate.
* Add support for Ganged mode.
* Add RAW10 packed video format support to Tegra210 video formats.
* Add support for suspend and resume.
diff --git a/drivers/staging/media/tegra-video/csi.c
b/drivers/staging/media/tegra-video/csi.c
index 76b4311..93875cb 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -19,6 +19,8 @@
#include "csi.h"
#include "video.h"
+#define MHZ100
+
static inline struct tegra_csi *
host1x_client_to_csi(struct host1x_client *client)
{
@@ -235,6 +237,59 @@ static int tegra_csi_g_frame_interval(struct v4l2_subdev
*subdev,
return 0;
}
+static unsigned int csi_get_pixel_rate(struct tegra_csi_channel *csi_chan)
+{
+ struct tegra_vi_channel *chan;
+ struct v4l2_subdev *src_subdev;
+ struct v4l2_ctrl *ctrl;
+
+ chan = v4l2_get_subdev_hostdata(_chan->subdev);
+ src_subdev = tegra_channel_get_remote_source_subdev(chan);
+ ctrl = v4l2_ctrl_find(src_subdev->ctrl_handler, V4L2_CID_PIXEL_RATE);
+ if (ctrl)
+ return v4l2_ctrl_g_ctrl_int64(ctrl);
+
+ return 0;
+}
+
+void tegra_csi_calc_settle_time(struct tegra_csi_channel *csi_chan,
+ u8 *clk_settle_time,
+ u8 *ths_settle_time)
+{
+ struct tegra_csi *csi = csi_chan->csi;
+ unsigned int cil_clk_mhz;
+ unsigned int pix_clk_mhz;
+ int clk_idx = (csi_chan->csi_port_num >> 1) + 1;
+
+ cil_clk_mhz = clk_get_rate(csi->clks[clk_idx].clk) / MHZ;
+ pix_clk_mhz = csi_get_pixel_rate(csi_chan) / MHZ;
+
+ /*
+* CLK Settle time is the interval during which HS receiver should
+* ignore any clock lane HS transitions, starting from the beginning
+* of T-CLK-PREPARE.
+* Per DPHY specification, T-CLK-SETTLE should be between 95ns ~ 300ns
+*
+* 95ns < (clk-settle-programmed + 7) * lp clk period < 300ns
+* midpoint = 197.5 ns
+*/
+ *clk_settle_time = ((95 + 300) * cil_clk_mhz - 14000) / 2000;
+
+ /*
+* THS Settle time is the interval during which HS receiver should
+* ignore any data lane HS transitions, starting from the beginning
+* of THS-PREPARE.
+*
+* Per DPHY specification, T-HS-SETTLE should be between 85ns + 6UI
+* and 145ns+10UI.
+* 85ns + 6UI < (Ths-settle-prog + 5) * lp_clk_period < 145ns + 10UI
+* midpoint = 115ns + 8UI
+*/
+ if (pix_clk_mhz)
+ *ths_settle_time = (115 * cil_clk_mhz + 8000 * cil_clk_mhz
+ / (2 * pix_clk_mhz) - 5000) / 1000;
+}
+
static int tegra_csi_enable_stream(struct v4l2_subdev *subdev)
{
struct tegra_vi_channel *chan = v4l2_get_subdev_hostdata(subdev);
diff --git a/drivers/staging/media/tegra-video/csi.h
b/drivers/staging/media/tegra-video/csi.h
index 0d50fc3..c65ff73 100644
--- a/drivers/staging/media/tegra-video/csi.h
+++ b/drivers/staging/media/tegra-video/csi.h
@@ -51,6 +51,7 @@ struct tegra_csi;
* @h_blank: horizontal blanking for TPG active format
* @v_blank: vertical blanking for TPG active format
* @mipi: mipi device for corresponding csi channel pads
+ * @pixel_rate: active pixel rate from the sensor on this channel
*/
struct tegra_csi_channel {
struct list_head list;
@@ -67,6 +68,7 @@ struct tegra_csi_channel {
unsigned int h_blank;
unsigned int v_blank;
struct tegra_mipi_device *mipi;
+ unsigned int pixel_rate;
};
/**
@@ -147,4 +149,7 @@ extern const struct tegra_csi_soc tegra210_csi_soc;
#endif
void tegra_csi_error_recover(struct v4l2_subdev *subdev);
+void tegra_csi_calc_settle_time(struct tegra_csi_channel *csi_chan,
+
[PATCH v8 09/10] media: tegra-video: Add CSI MIPI pads calibration
CSI MIPI pads need to be enabled and calibrated for capturing from
the external sensor or transmitter.
MIPI CAL unit calibrates MIPI pads pull-up, pull-down and termination
impedances. Calibration is done by co-work of MIPI BIAS pad and MIPI
CAL control unit.
Triggering calibration start can happen any time after MIPI pads are
enabled but calibration results will be latched and applied to MIPI
pads by MIPI CAL unit only when the link is in LP11 state and then
calibration status register gets updated.
This patch enables CSI MIPI pads and calibrates them during streaming.
Tegra CSI receiver is able to catch the very first clock transition.
So, CSI receiver is always enabled prior to sensor streaming and
trigger of calibration start is done during CSI subdev streaming and
status of calibration is verified after sensor stream on.
Reviewed-by: Dmitry Osipenko
Signed-off-by: Sowjanya Komatineni
---
drivers/staging/media/tegra-video/TODO | 1 -
drivers/staging/media/tegra-video/csi.c | 61 +++--
drivers/staging/media/tegra-video/csi.h | 2 ++
drivers/staging/media/tegra-video/vi.c | 28 ---
4 files changed, 84 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/tegra-video/TODO
b/drivers/staging/media/tegra-video/TODO
index 97a19b4..98d3c7d 100644
--- a/drivers/staging/media/tegra-video/TODO
+++ b/drivers/staging/media/tegra-video/TODO
@@ -1,5 +1,4 @@
TODO list
-* Add Tegra CSI MIPI pads calibration.
* Add MIPI clock Settle time computation based on the data rate.
* Add support for Ganged mode.
* Add RAW10 packed video format support to Tegra210 video formats.
diff --git a/drivers/staging/media/tegra-video/csi.c
b/drivers/staging/media/tegra-video/csi.c
index 4176933..76b4311 100644
--- a/drivers/staging/media/tegra-video/csi.c
+++ b/drivers/staging/media/tegra-video/csi.c
@@ -240,7 +240,7 @@ static int tegra_csi_enable_stream(struct v4l2_subdev
*subdev)
struct tegra_vi_channel *chan = v4l2_get_subdev_hostdata(subdev);
struct tegra_csi_channel *csi_chan = to_csi_chan(subdev);
struct tegra_csi *csi = csi_chan->csi;
- int ret;
+ int ret, err;
ret = pm_runtime_get_sync(csi->dev);
if (ret < 0) {
@@ -249,13 +249,47 @@ static int tegra_csi_enable_stream(struct v4l2_subdev
*subdev)
return ret;
}
+ if (csi_chan->mipi) {
+ ret = tegra_mipi_enable(csi_chan->mipi);
+ if (ret < 0) {
+ dev_err(csi->dev,
+ "failed to enable MIPI pads: %d\n", ret);
+ goto rpm_put;
+ }
+
+ /*
+* CSI MIPI pads PULLUP, PULLDN and TERM impedances need to
+* be calibrated after power on.
+* So, trigger the calibration start here and results will
+* be latched and applied to the pads when link is in LP11
+* state during start of sensor streaming.
+*/
+ ret = tegra_mipi_start_calibration(csi_chan->mipi);
+ if (ret < 0) {
+ dev_err(csi->dev,
+ "failed to start MIPI calibration: %d\n", ret);
+ goto disable_mipi;
+ }
+ }
+
csi_chan->pg_mode = chan->pg_mode;
ret = csi->ops->csi_start_streaming(csi_chan);
if (ret < 0)
- goto rpm_put;
+ goto cancel_calibration;
return 0;
+cancel_calibration:
+ if (csi_chan->mipi)
+ tegra_mipi_cancel_calibration(csi_chan->mipi);
+disable_mipi:
+ if (csi_chan->mipi) {
+ err = tegra_mipi_disable(csi_chan->mipi);
+ if (err < 0)
+ dev_err(csi->dev,
+ "failed to disable MIPI pads: %d\n", err);
+ }
+
rpm_put:
pm_runtime_put(csi->dev);
return ret;
@@ -265,9 +299,17 @@ static int tegra_csi_disable_stream(struct v4l2_subdev
*subdev)
{
struct tegra_csi_channel *csi_chan = to_csi_chan(subdev);
struct tegra_csi *csi = csi_chan->csi;
+ int err;
csi->ops->csi_stop_streaming(csi_chan);
+ if (csi_chan->mipi) {
+ err = tegra_mipi_disable(csi_chan->mipi);
+ if (err < 0)
+ dev_err(csi->dev,
+ "failed to disable MIPI pads: %d\n", err);
+ }
+
pm_runtime_put(csi->dev);
return 0;
@@ -313,6 +355,7 @@ static int tegra_csi_channel_alloc(struct tegra_csi *csi,
unsigned int num_pads)
{
struct tegra_csi_channel *chan;
+ int ret = 0;
chan = kzalloc(sizeof(*chan), GFP_KERNEL);
if (!chan)
@@ -331,7 +374,16 @@ static int tegra_csi_channel_alloc(struct tegra_csi *csi,
chan->pads[0].flags = MEDIA_PAD_FL_SOURCE;
}
- return 0;
+
[PATCH v8 01/10] media: tegra-video: Fix channel format alignment
Pixel format width is mistakenly aligned to surface align bytes
and altering width to aligned value may force sensor mode change
other than the requested one and also cause mismatch in width
programmed between sensor and vi which can lead to capture errors.
This patch removes width alignment and clamps width as per Tegra
minimum and maximum limits.
Signed-off-by: Sowjanya Komatineni
---
drivers/staging/media/tegra-video/vi.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/media/tegra-video/vi.c
b/drivers/staging/media/tegra-video/vi.c
index 1b5e660..d621ebc 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -359,25 +359,15 @@ static void tegra_channel_fmt_align(struct
tegra_vi_channel *chan,
struct v4l2_pix_format *pix,
unsigned int bpp)
{
- unsigned int align;
- unsigned int min_width;
- unsigned int max_width;
- unsigned int width;
unsigned int min_bpl;
unsigned int max_bpl;
unsigned int bpl;
/*
-* The transfer alignment requirements are expressed in bytes. Compute
-* minimum and maximum values, clamp the requested width and convert
-* it back to pixels. Use bytesperline to adjust the width.
+* The transfer alignment requirements are expressed in bytes.
+* Clamp the requested width and height to the limits.
*/
- align = lcm(SURFACE_ALIGN_BYTES, bpp);
- min_width = roundup(TEGRA_MIN_WIDTH, align);
- max_width = rounddown(TEGRA_MAX_WIDTH, align);
- width = roundup(pix->width * bpp, align);
-
- pix->width = clamp(width, min_width, max_width) / bpp;
+ pix->width = clamp(pix->width, TEGRA_MIN_WIDTH, TEGRA_MAX_WIDTH);
pix->height = clamp(pix->height, TEGRA_MIN_HEIGHT, TEGRA_MAX_HEIGHT);
/* Clamp the requested bytes per line value. If the maximum bytes per
--
2.7.4
Re: [PATCH v2 -next] tools build: Check return value of fwrite_unlocked in jvmti_agent.c
On Fri, Jul 31, 2020 at 4:42 AM Wang ShaoBo wrote:
>
> Function jvmti_write_code called by compiled_method_load_cb may return
> error in using fwrite_unlocked, this failure should be captured and
> warned.
>
> Signed-off-by: Wang ShaoBo
Thanks, looks good now!
Reviewed-by: Ian Rogers
> ---
> tools/perf/jvmti/jvmti_agent.c | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/tools/perf/jvmti/jvmti_agent.c b/tools/perf/jvmti/jvmti_agent.c
> index 88108598d6e9..dfb6cb8564cb 100644
> --- a/tools/perf/jvmti/jvmti_agent.c
> +++ b/tools/perf/jvmti/jvmti_agent.c
> @@ -363,7 +363,7 @@ jvmti_write_code(void *agent, char const *sym,
> struct jr_code_load rec;
> size_t sym_len;
> FILE *fp = agent;
> - int ret = -1;
> + int sret;
>
> /* don't care about 0 length function, no samples */
> if (size == 0)
> @@ -400,17 +400,24 @@ jvmti_write_code(void *agent, char const *sym,
> */
> rec.code_index = code_generation++;
>
> - ret = fwrite_unlocked(, sizeof(rec), 1, fp);
> - fwrite_unlocked(sym, sym_len, 1, fp);
> + sret = fwrite_unlocked(, sizeof(rec), 1, fp);
> + if (sret != 1)
> + goto error;
> + sret = fwrite_unlocked(sym, sym_len, 1, fp);
> + if (sret != 1)
> + goto error;
>
> - if (code)
> - fwrite_unlocked(code, size, 1, fp);
> + if (code) {
> + sret = fwrite_unlocked(code, size, 1, fp);
> + if (sret != 1)
> + goto error;
> + }
>
> funlockfile(fp);
> -
> - ret = 0;
> -
> - return ret;
> + return 0;
> +error:
> + funlockfile(fp);
> + return -1;
> }
>
> int
> --
> 2.25.1
>
[PATCH v8 00/10] Support for Tegra video capture from external sensor
This series adds support for video capture from external camera sensor to Tegra video driver. Jetson TX1 has camera expansion connector and supports custom camera module designed as per TX1 design specification. This series also enables camera capture support for Jetson Nano which has Raspberry PI camera header. This series is tested with IMX274 and IMX219 camera sensors. This series include, Tegra video driver updates - TPG Vs Non-TPG based on Kconfig - Support for external sensor video capture based on device graph from DT - Support for selection ioctl operations - Tegra MIPI CSI pads calibration - CSI T-CLK and T-HS settle time computation based on clock rates - dt-binding doc update Host1x driver updates - Keep MIPI clock enabled till calibration is done Delta between patch versions: [v8]: Includes below minor changes - Fixed missing of_node_put and updated error message to be more informative in tegra_csi_channels_alloc() and tegra_vi_channels_alloc() Patch-0006 has compilation dependency on https://patchwork.kernel.org/patch/11659521/ [v7]: Includes minor feedback from v6 - Patch-0009 has minor update Note: Patch-0006 has compilation dependency on https://patchwork.kernel.org/patch/11659521/ [v6]: Includes below changes based on v5 feedback - Patches are based on latest linux-next. - separated stream enable and disable implementations into separate functions for tegra_channel_set_stream() and tegra_csi_s_stream(). - changed dev_err to dev_warn on MIPI calibration failure after sensor streaming as its not critical error. Note: Patch-0006 has compilation dependency on https://patchwork.kernel.org/patch/11659521/ [v5]: Includes below minor change based on v4 feedback Patch-0012: renames APIs to use calibration instead of calibrate. Note: Patch-0010 has compilation dependency on https://patchwork.kernel.org/patch/11659521/ [v4]: Includes below fix based on v3 feedback - Patches are based on latest linux-next. - With split of tegra_mipi_calibrate() and tegra_mipi_wait(), mipi clock is not left enabled till calibration done. This series adds a patch to fix this by keeping clock enabled till calibration is done. Note: Patch-0010 has compilation dependency on https://patchwork.kernel.org/patch/11659521/ [v3]: Includes v2 feedback - Uses separate helper function for retrieving remote csi subdevice and source subdevice. - Added check for presence of subdevice ops set/get_selection - dropped vb2_queue_release from driver and using vb2_video_unregister_device instead of video_unregister_device. - video device register should happen in the last after all video device related setup is done in the driver. This is being addressed in below RFC patch. Once proper implementation of this is available will update Tegra video driver to use split APIs and do all setup prior to device register. Added this as TODO in the driver. https://www.spinics.net/lists/linux-media/msg172761.html Note: Patch-0012 has compilation dependency on https://patchwork.kernel.org/patch/11659521/ [v2]: Includes below changes based on v1 feedback - dt-binding document and the driver update for device graph to use separate ports for sink endpoint and source endpoint for csi. - Use data-lanes endpoint property for csi. - Update tegra_mipi_request() to take device node pointer argument rather than adding extra API. - Remove checking for clk pointer before clk_disable. Sowjanya Komatineni (10): media: tegra-video: Fix channel format alignment media: tegra-video: Enable TPG based on kernel config media: tegra-video: Update format lookup to offset based dt-bindings: tegra: Update VI and CSI bindings with port info media: tegra-video: Separate CSI stream enable and disable implementations media: tegra-video: Add support for external sensor capture media: tegra-video: Add support for selection ioctl ops gpu: host1x: mipi: Keep MIPI clock enabled till calibration is done media: tegra-video: Add CSI MIPI pads calibration media: tegra-video: Compute settle times based on the clock rate .../display/tegra/nvidia,tegra20-host1x.txt| 92 ++- drivers/gpu/drm/tegra/dsi.c| 4 +- drivers/gpu/host1x/mipi.c | 19 +- drivers/staging/media/tegra-video/Kconfig | 7 + drivers/staging/media/tegra-video/TODO | 6 - drivers/staging/media/tegra-video/csi.c| 314 +++- drivers/staging/media/tegra-video/csi.h| 8 + drivers/staging/media/tegra-video/tegra210.c | 25 +-
Re: [PATCH bpf-next v7 5/7] bpf: Implement bpf_local_storage for inodes
On 31.07.20 21:02, Martin KaFai Lau wrote:
> On Fri, Jul 31, 2020 at 02:08:55PM +0200, KP Singh wrote:
> [ ... ]
+const struct bpf_map_ops inode_storage_map_ops = {
[...]
>>
>> btf dump file /sys/kernel/btf/vmlinux | grep "STRUCT 'inode'"
>> "[915] STRUCT 'inode' size=984 vlen=48
>>
>> So it seems like btf_id[0] and btf_id[1] are set to the BTF ID
>> for inode. Now I think this might just be a coincidence as
>> the next helper (bpf_inode_storage_delete)
>> also has a BTF argument of type inode.
> It seems the next BTF_ID_LIST(bpf_inode_storage_delete_btf_ids)
> is not needed because they are the same. I think one
> BTF_ID_LIST(bpf_inode_btf_ids) can be used for both helpers.
>
Cool, yeah. I have fixed it and also for sock helpers. Will
send a new series out.
- KP
>>
>> and sure enough if I call:
>>
>> bpf_inode_storage_delete from my selftests program,
>> it does not load:
[...]
>> ./test_progs -t test_local_storage
>> [ 20.577223] btf_ids[0]=0
>> [ 20.577702] btf_ids[1]=915
>>
>> Thanks for noticing this!
>>
>> - KP
>>
>>>
+
+const struct bpf_func_proto bpf_inode_storage_get_proto = {
+ .func = bpf_inode_storage_get,
+ .gpl_only = false,
+ .ret_type = RET_PTR_TO_MAP_VALUE_OR_NULL,
+ .arg1_type = ARG_CONST_MAP_PTR,
+ .arg2_type = ARG_PTR_TO_BTF_ID,
+ .arg3_type = ARG_PTR_TO_MAP_VALUE_OR_NULL,
+ .arg4_type = ARG_ANYTHING,
+ .btf_id = bpf_inode_storage_get_btf_ids,
+};
+
+BTF_ID_LIST(bpf_inode_storage_delete_btf_ids)
+BTF_ID(struct, inode)
+
+const struct bpf_func_proto bpf_inode_storage_delete_proto = {
+ .func = bpf_inode_storage_delete,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_CONST_MAP_PTR,
+ .arg2_type = ARG_PTR_TO_BTF_ID,
+ .btf_id = bpf_inode_storage_delete_btf_ids,
+};
Re: [PATCH 2/2] dmabuf/tracing: Add dma-buf trace events
On Mon, Aug 03, 2020 at 02:47:19PM +, Kalesh Singh wrote:
> +static void dma_buf_fd_install(int fd, struct file *filp)
> +{
> + trace_dma_buf_fd_ref_inc(current, filp);
> +}
You're adding a new file_operation in order to just add a new tracepoint?
NACK.
Re: [PATCH] gve: Fix the size used in a 'dma_free_coherent()' call
On Sun, 2 Aug 2020 16:15:23 +0200 Christophe JAILLET wrote:
> Update the size used in 'dma_free_coherent()' in order to match the one
> used in the corresponding 'dma_alloc_coherent()'.
>
> Fixes: 893ce44df5 ("gve: Add basic driver framework for Compute Engine
> Virtual NIC")
> Signed-off-by: Christophe JAILLET
Fixes tag: Fixes: 893ce44df5 ("gve: Add basic driver framework for Compute
Engine Virtual NIC")
Has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
Re: [PATCH] mm: Fix protection usage propagation
On Mon, Aug 03, 2020 at 05:32:31PM +0200, Michal Hocko wrote:
> From: Michal Koutný
>
> When workload runs in cgroups that aren't directly below root cgroup and
> their parent specifies reclaim protection, it may end up ineffective.
>
> The reason is that propagate_protected_usage() is not called in all
> hierarchy up. All the protected usage is incorrectly accumulated in the
> workload's parent. This means that siblings_low_usage is overestimated
> and effective protection underestimated. Even though it is transitional
> phenomenon (uncharge path does correct propagation and fixes the wrong
> children_low_usage), it can undermine the indended protection
> unexpectedly.
Indeed, good catch!
>
> The fix is simply updating children_low_usage in respective ancestors
> also in the charging path.
>
> Fixes: 230671533d64 ("mm: memory.low hierarchical behavior")
> Cc: stable # 4.18+
> Signed-off-by: Michal Koutný
> Acked-by: Michal Hocko
Acked-by: Roman Gushchin
Thank you!
> ---
>
> Hi,
> I am sending this patch on behalf of Michal Koutny who is currently
> on vacation and didn't get to post it before he left.
>
> We have noticed this problem while seeing a swap out in a descendant of
> a protected memcg (intermediate node) while the parent was conveniently
> under its protection limit and the memory pressure was external
> to that hierarchy. Michal has pinpointed this down to the wrong
> siblings_low_usage which led to the unwanted reclaim.
>
> I am adding my ack directly in this submission.
>
> mm/page_counter.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_counter.c b/mm/page_counter.c
> index c56db2d5e159..b4663844c9b3 100644
> --- a/mm/page_counter.c
> +++ b/mm/page_counter.c
> @@ -72,7 +72,7 @@ void page_counter_charge(struct page_counter *counter,
> unsigned long nr_pages)
> long new;
>
> new = atomic_long_add_return(nr_pages, >usage);
> - propagate_protected_usage(counter, new);
> + propagate_protected_usage(c, new);
> /*
>* This is indeed racy, but we can live with some
>* inaccuracy in the watermark.
> @@ -116,7 +116,7 @@ bool page_counter_try_charge(struct page_counter *counter,
> new = atomic_long_add_return(nr_pages, >usage);
> if (new > c->max) {
> atomic_long_sub(nr_pages, >usage);
> - propagate_protected_usage(counter, new);
> + propagate_protected_usage(c, new);
> /*
>* This is racy, but we can live with some
>* inaccuracy in the failcnt.
> @@ -125,7 +125,7 @@ bool page_counter_try_charge(struct page_counter *counter,
> *fail = c;
> goto failed;
> }
> - propagate_protected_usage(counter, new);
> + propagate_protected_usage(c, new);
> /*
>* Just like with failcnt, we can live with some
>* inaccuracy in the watermark.
> --
> 2.27.0
>
[PATCH] proc: use untagged_addr() for pagemap_read addresses
When we try to visit the pagemap of a tagged userspace pointer, we find that the start_vaddr is not correct because of the tag. To fix it, we should untag the usespace pointers in pagemap_read(). Signed-off-by: Miles Chen --- fs/proc/task_mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index dbda4499a859..d0c6e8e0cf37 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -1541,11 +1541,11 @@ static ssize_t pagemap_read(struct file *file, char __user *buf, src = *ppos; svpfn = src / PM_ENTRY_BYTES; - start_vaddr = svpfn << PAGE_SHIFT; + start_vaddr = untagged_addr(svpfn << PAGE_SHIFT); end_vaddr = mm->task_size; /* watch out for wraparound */ - if (svpfn > mm->task_size >> PAGE_SHIFT) + if (start_vaddr > mm->task_size) start_vaddr = end_vaddr; /* -- 2.18.0
Re: [PATCH] ARM64: Setup DMA32 zone size by bootargs
On 2020-08-03 15:26, Phil Chang wrote:
this patch allowing the arm64 DMA zone be configurable.
Signed-off-by: Alix Wu
Signed-off-by: YJ Chiang
Signed-off-by: Phil Chang
---
Hi
For some devices, the main memory split into 2 part due to the memory
architecture,
the efficient and less inefficient part.
One of the use case is fine-tune the dma32 size to contain all the
efficient part of memory block on this kind of architecture,
but in general, the DMA32 zone size is hardcode to 4G.
The sole point of ZONE_DMA32 is to contain all the 32-bit addressable
memory which is not covered by ZONE_DMA. As such the only possible thing
that could be configured is the size of ZONE_DMA (if present), and this
patch makes no sense.
If you want to describe NUMA characteristics, use NUMA properties.
Giving users freedom to break fundamental assumptions of the DMA layer
by arbitrarily changing the meaning of "32-bit" is not an appropriate
solution.
Robin.
.../admin-guide/kernel-parameters.txt | 3 ++
arch/arm64/include/asm/memory.h | 2 ++
arch/arm64/mm/init.c | 33 +--
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index fb95fad81c79..441ad3cb8ee8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -956,6 +956,9 @@
The filter can be disabled or changed to another
driver later using sysfs.
+ dma32_zone=nn [KMG] [KNL,BOOT]
+ Forces the DMA32 zone size of in mb, arm64 only.
+
driver_async_probe= [KNL]
List of driver names to be probed asynchronously.
Format: ,...
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index a1871bb32bb1..377f2252618a 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -174,6 +174,8 @@ extern u64 kimage_vaddr;
/* the offset between the kernel virtual and physical mappings */
extern u64kimage_voffset;
+extern phys_addr_t arm_dma_zone_size;
+
static inline unsigned long kaslr_offset(void)
{
return kimage_vaddr - KIMAGE_VADDR;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 1e93cfc7c47a..642ab323392c 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -60,6 +60,9 @@ EXPORT_SYMBOL(physvirt_offset);
struct page *vmemmap __ro_after_init;
EXPORT_SYMBOL(vmemmap);
+phys_addr_t arm_dma_zone_size __ro_after_init;
+EXPORT_SYMBOL(arm_dma_zone_size);
+
/*
* We create both ZONE_DMA and ZONE_DMA32. ZONE_DMA covers the first 1G of
* memory as some devices, namely the Raspberry Pi 4, have peripherals with
@@ -242,6 +245,25 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
+/*
+ * Setup the dma32 zone size
+ */
+static int __init setup_dma32_zone(char *p)
+{
+ if (!p)
+ return -EINVAL;
+
+ if (kstrtoull(p, 0, _dma_zone_size))
+ return -EINVAL;
+
+ arm_dma_zone_size *= SZ_1M;
+ pr_notice("Setup dma32 zone size to %llu Mb\n", arm_dma_zone_size);
+
+ return 0;
+}
+
+early_param("dma32_zone", setup_dma32_zone);
+
static int __init early_init_dt_scan_usablemem(unsigned long node,
const char *uname, int depth, void *data)
{
@@ -392,10 +414,15 @@ void __init arm64_memblock_init(void)
arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS);
}
- if (IS_ENABLED(CONFIG_ZONE_DMA32))
- arm64_dma32_phys_limit = max_zone_phys(32);
- else
+ if (IS_ENABLED(CONFIG_ZONE_DMA32)) {
+ if (arm_dma_zone_size)
+ arm64_dma32_phys_limit = arm_dma_zone_size +
+ memblock_start_of_DRAM();
+ else
+ arm64_dma32_phys_limit = max_zone_phys(32);
+ } else {
arm64_dma32_phys_limit = PHYS_MASK + 1;
+ }
reserve_crashkernel();
Re: [PATCH v4 2/2] soc: mediatek: add mtk-devapc driver
Neal Liu 於 2020年8月3日 週一 下午12:05寫道：
>
> Hi Chun-Kuang,
>
> On Sun, 2020-08-02 at 07:50 +0800, Chun-Kuang Hu wrote:
> > Hi, Neal:
> >
> > Neal Liu 於 2020年7月29日 週三 下午4:29寫道：
> > >
> > > MediaTek bus fabric provides TrustZone security support and data
> > > protection to prevent slaves from being accessed by unexpected
> > > masters.
> > > The security violation is logged and sent to the processor for
> > > further analysis or countermeasures.
> > >
> > > Any occurrence of security violation would raise an interrupt, and
> > > it will be handled by mtk-devapc driver. The violation
> > > information is printed in order to find the murderer.
> > >
> > > Signed-off-by: Neal Liu
> > > ---
> >
> > [snip]
> >
> > > +
> > > +struct mtk_devapc_context {
> > > + struct device *dev;
> > > + u32 vio_idx_num;
> > > + void __iomem *devapc_pd_base;
> >
> > This is devapc context, so prefix 'devapc' is redundant.
> > And, what does 'pd' mean?
>
> 'pd' means power down. Of course we would also remove it as well.
> I suggest to change it as 'infra_base'.
This is OK for me.
>
> >
> > Regards,
> > Chun-Kuang.
> >
> > > + struct mtk_devapc_vio_info *vio_info;
> > > + const struct mtk_devapc_pd_offset *offset;
> > > + const struct mtk_devapc_vio_dbgs *vio_dbgs;
> > > +};
> > > +
>
Re: KASAN: use-after-free Read in tipc_bcast_get_mode
On 8/3/20 8:23 AM, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:bd0b33b2 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=13f236a490 > kernel config: https://syzkaller.appspot.com/x/.config?x=91a13b78c7dc258d > dashboard link: https://syzkaller.appspot.com/bug?extid=6ea1f7a8df64596ef4d7 > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+6ea1f7a8df64596ef...@syzkaller.appspotmail.com > > tipc: 32-bit node address hash set to fcff1eac > == > BUG: KASAN: use-after-free in tipc_bcast_get_mode+0x3ab/0x400 > net/tipc/bcast.c:759 > Read of size 1 at addr 88805e6b3571 by task kworker/0:6/3850 > > CPU: 0 PID: 3850 Comm: kworker/0:6 Not tainted 5.8.0-rc7-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: events tipc_net_finalize_work > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x18f/0x20d lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383 > __kasan_report mm/kasan/report.c:513 [inline] > kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 > tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 > tipc_node_broadcast+0x9e/0xcc0 net/tipc/node.c:1744 > tipc_nametbl_publish+0x60b/0x970 net/tipc/name_table.c:752 > tipc_net_finalize net/tipc/net.c:141 [inline] > tipc_net_finalize+0x1fa/0x310 net/tipc/net.c:131 > tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150 > process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 > worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 > kthread+0x3b5/0x4a0 kernel/kthread.c:291 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 > > Allocated by task 8062: > save_stack+0x1b/0x40 mm/kasan/common.c:48 > set_track mm/kasan/common.c:56 [inline] > __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 > kmem_cache_alloc_trace+0x14f/0x2d0 mm/slab.c:3551 > kmalloc include/linux/slab.h:555 [inline] > kzalloc include/linux/slab.h:669 [inline] > tipc_bcast_init+0x21e/0x7b0 net/tipc/bcast.c:689 > tipc_init_net+0x4f6/0x5c0 net/tipc/core.c:85 > ops_init+0xaf/0x470 net/core/net_namespace.c:151 > setup_net+0x2d8/0x850 net/core/net_namespace.c:341 > copy_net_ns+0x2cf/0x5e0 net/core/net_namespace.c:482 > create_new_namespaces+0x3f6/0xb10 kernel/nsproxy.c:110 > unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231 > ksys_unshare+0x36c/0x9a0 kernel/fork.c:2979 > __do_sys_unshare kernel/fork.c:3047 [inline] > __se_sys_unshare kernel/fork.c:3045 [inline] > __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3045 > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Freed by task 8843: > save_stack+0x1b/0x40 mm/kasan/common.c:48 > set_track mm/kasan/common.c:56 [inline] > kasan_set_free_info mm/kasan/common.c:316 [inline] > __kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455 > __cache_free mm/slab.c:3426 [inline] > kfree+0x103/0x2c0 mm/slab.c:3757 > tipc_bcast_stop+0x1b0/0x2f0 net/tipc/bcast.c:721 > tipc_exit_net+0x24/0x270 net/tipc/core.c:112 > ops_exit_list+0xb0/0x160 net/core/net_namespace.c:186 > cleanup_net+0x4ea/0xa00 net/core/net_namespace.c:603 > process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 > worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 > kthread+0x3b5/0x4a0 kernel/kthread.c:291 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 > > The buggy address belongs to the object at 88805e6b3500 > which belongs to the cache kmalloc-128 of size 128 > The buggy address is located 113 bytes inside of > 128-byte region [88805e6b3500, 88805e6b3580) > The buggy address belongs to the page: > page:ea000179acc0 refcount:1 mapcount:0 mapping: index:0x0 > flags: 0xfffe000200(slab) > raw: 00fffe000200 ea0002375c48 8880aa001550 8880aa000700 > raw: 88805e6b3000 00010010 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 88805e6b3400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 88805e6b3480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> 88805e6b3500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > 88805e6b3580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > 88805e6b3600: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc > == > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be
Re: [PATCH v2 2/2] memory: samsung: exynos5422-dmc: Add module param to control IRQ mode
Hi All, On 03.08.2020 17:30, Marek Szyprowski wrote: > On 10.07.2020 21:11, Lukasz Luba wrote: >> The driver can operate in two modes relaying on devfreq monitoring >> mechanism which periodically checks the device status or it can use >> interrupts when they are provided by loaded Device Tree. The newly >> introduced module parameter can be used to choose between devfreq >> monitoring and internal interrupts without modifying the Device Tree. >> It also sets devfreq monitoring as default when the parameter is not set >> (also the case for default when the driver is not built as a module). >> >> Reported-by: Willy Wolff >> Signed-off-by: Lukasz Luba > > I've got back from my holidays and noticed that in meantime this > commit got merged as commit 4fc9a0470d2d. It revealed that there is a > race between registering exynos5422-dmc driver and exynos-ppmu driver, > which can be observed sometimes as the following message and freeze on > Odroid XU3 with multi_v7_defconfig: > > [ 8.767708] exynos5-dmc 10c2.memory-controller: couldn't probe > performance counters > > I will check this later why the EPROBE_DEFER error is not properly > propagated and why it causes a freeze. It looks that simply propagating return value from exynos5_counters_get() in exynos5_dmc_get_status() fixes the boot: # dmesg | grep dmc [ 8.838754] exynos-ppmu: new PPMU device registered 10d0.ppmu (ppmu-event3-dmc0_0) [ 8.861344] exynos-ppmu: new PPMU device registered 10d1.ppmu (ppmu-event3-dmc0_1) [ 8.868488] exynos5-dmc 10c2.memory-controller: couldn't probe performance counters [ 8.874417] exynos-ppmu: new PPMU device registered 10d6.ppmu (ppmu-event3-dmc1_0) [ 8.886612] exynos-ppmu: new PPMU device registered 10d7.ppmu (ppmu-event3-dmc1_1) [ 9.396769] exynos5-dmc 10c2.memory-controller: DMC initialized, in irq mode: 0 I'm still curious why it freezes if getting performance counters is not possible. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH bpf-next v3 00/29] bpf: switch to memcg-based memory accounting
On Mon, Aug 03, 2020 at 02:05:29PM +0200, Daniel Borkmann wrote: > On 7/30/20 11:22 PM, Roman Gushchin wrote: > > Currently bpf is using the memlock rlimit for the memory accounting. > > This approach has its downsides and over time has created a significant > > amount of problems: > > > > 1) The limit is per-user, but because most bpf operations are performed > > as root, the limit has a little value. > > > > 2) It's hard to come up with a specific maximum value. Especially because > > the counter is shared with non-bpf users (e.g. memlock() users). > > Any specific value is either too low and creates false failures > > or too high and useless. > > > > 3) Charging is not connected to the actual memory allocation. Bpf code > > should manually calculate the estimated cost and precharge the counter, > > and then take care of uncharging, including all fail paths. > > It adds to the code complexity and makes it easy to leak a charge. > > > > 4) There is no simple way of getting the current value of the counter. > > We've used drgn for it, but it's far from being convenient. > > > > 5) Cryptic -EPERM is returned on exceeding the limit. Libbpf even had > > a function to "explain" this case for users. > > > > In order to overcome these problems let's switch to the memcg-based > > memory accounting of bpf objects. With the recent addition of the percpu > > memory accounting, now it's possible to provide a comprehensive accounting > > of memory used by bpf programs and maps. > > > > This approach has the following advantages: > > 1) The limit is per-cgroup and hierarchical. It's way more flexible and > > allows > > a better control over memory usage by different workloads. > > > > 2) The actual memory consumption is taken into account. It happens > > automatically > > on the allocation time if __GFP_ACCOUNT flags is passed. Uncharging is > > also > > performed automatically on releasing the memory. So the code on the bpf > > side > > becomes simpler and safer. > > > > 3) There is a simple way to get the current value and statistics. > > > > The patchset consists of the following parts: > > 1) memcg-based accounting for various bpf objects: progs and maps > > 2) removal of the rlimit-based accounting > > 3) removal of rlimit adjustments in userspace samples Hi Daniel, > > The diff stat looks nice & agree that rlimit sucks, but I'm missing how this > is set > is supposed to work reliably, at least I currently fail to see it. > Elaborating on this > in more depth especially for the case of unprivileged users should be a > /fundamental/ > part of the commit message. > > Lets take an example: unprivileged user adds a max sized hashtable to one of > its > programs, and configures the map that it will perform runtime allocation. The > load > succeeds as it doesn't surpass the limits set for the current memcg. Kernel > then > processes packets from softirq. Given the runtime allocations, we end up > mischarging > to whoever ended up triggering __do_softirq(). If, for example, ksoftirq > thread, then > it's probably reasonable to assume that this might not be accounted e.g. > limits are > not imposed on the root cgroup. If so we would probably need to drag the > context of > /where/ this must be charged to __memcg_kmem_charge_page() to do it reliably. > Otherwise > how do you protect unprivileged users to OOM the machine? this is a valid concern, thank you for bringing it in. It can be resolved by associating a map with a memory cgroup on creation, so that we can charge this memory cgroup later, even from a soft-irq context. The question here is whether we want to do it for all maps, or just for dynamic hashtables (or any similar cases, if there are any)? I think the second option is better. With the first option we have to annotate all memory allocations in bpf maps code with memalloc_use_memcg()/memalloc_unuse_memcg(), so it's easy to mess it up in the future. What do you think? > > Similarly, what happens to unprivileged users if kmemcg was not configured > into the > kernel or has been disabled? Well, I don't think we can address it. Memcg-based memory accounting requires enabled memory cgroups, a properly configured cgroup tree and also the kernel memory accounting turned on to function properly. Because we at Facebook are using cgroup for the memory accounting and control everywhere, I might be biased. If there are real !memcg systems which are actively using non-privileged bpf, we should keep the old system in place and make it optional, so everyone can choose between having both accounting systems or just the new one. Or we can disable the rlimit-based accounting for root. But eliminating it completely looks so much nicer to me. Thanks!
Re: Re: [RFC PATCH 3/4] i2c: core: treat EPROBE_DEFER when acquiring SCL/SDA GPIOs
On 02.08.2020 20:05, Wolfram Sang wrote:
> On Fri, Jun 19, 2020 at 05:19:03PM +0300, Codrin Ciubotariu wrote:
>> Even if I2C bus GPIO recovery is optional, devm_gpiod_get() can return
>> -EPROBE_DEFER, so we should at least treat that. This ends up with
>> i2c_register_adapter() to be able to return -EPROBE_DEFER.
>>
>> Signed-off-by: Codrin Ciubotariu
>> ---
>> drivers/i2c/i2c-core-base.c | 22 --
>> 1 file changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
>> index 4ee29fec4e93..f8d9f2048ca8 100644
>> --- a/drivers/i2c/i2c-core-base.c
>> +++ b/drivers/i2c/i2c-core-base.c
>> @@ -368,15 +368,16 @@ static int i2c_gpio_init_recovery(struct i2c_adapter
>> *adap)
>> return i2c_gpio_init_generic_recovery(adap);
>> }
>>
>> -static void i2c_init_recovery(struct i2c_adapter *adap)
>> +static int i2c_init_recovery(struct i2c_adapter *adap)
>> {
>> struct i2c_bus_recovery_info *bri = adap->bus_recovery_info;
>> char *err_str;
>>
>> if (!bri)
>> -return;
>> +return 0;
>>
>> -i2c_gpio_init_recovery(adap);
>> +if (i2c_gpio_init_recovery(adap) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>>
>> if (!bri->recover_bus) {
>> err_str = "no recover_bus() found";
>> @@ -392,7 +393,7 @@ static void i2c_init_recovery(struct i2c_adapter *adap)
>> if (gpiod_get_direction(bri->sda_gpiod) == 0)
>> bri->set_sda = set_sda_gpio_value;
>> }
>> -return;
>> +return 0;
>
> This is correct but I think the code flow is/was confusing. Can you drop
> this 'return' and use 'else if' for the next code block? I think this is
> more readable.
Ok, it makes sense. Should I make a separate patch for this only?
One more question, should we keep:
if (!bri->set_sda && !bri->get_sda) {
err_str = "either get_sda() or set_sda() needed";
goto err;
}
?
Without {get/set}_sda we won't be able to generate stop commands and
possibly check if the bus is free, but we can still generate the SCL
clock pulses.
>
>> }
>>
>> if (bri->recover_bus == i2c_generic_scl_recovery) {
>> @@ -407,10 +408,12 @@ static void i2c_init_recovery(struct i2c_adapter *adap)
>> }
>> }
>>
>> -return;
>> +return 0;
>>err:
>> dev_err(>dev, "Not using recovery: %s\n", err_str);
>> adap->bus_recovery_info = NULL;
>> +
>> +return 0;
>
> 'return -EINVAL;' I'd suggest.
OK
>
>> }
>>
>> static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
>> @@ -1476,7 +1479,9 @@ static int i2c_register_adapter(struct i2c_adapter
>> *adap)
>> "Failed to create compatibility class link\n");
>> #endif
>>
>> -i2c_init_recovery(adap);
>> +res = i2c_init_recovery(adap);
>> +if (res == -EPROBE_DEFER)
>> +goto out_link;
>
> Please move 'i2c_init_recovery' above the class-link creation. It
> shouldn't make a difference but we can skip the extra label and the
> ifdeffery.
Ok. Perhaps I should also move the debug print with the registered
adapter after calling i2c_init_recovery().
>
>>
>> /* create pre-declared device nodes */
>> of_i2c_register_devices(adap);
>> @@ -1493,6 +1498,11 @@ static int i2c_register_adapter(struct i2c_adapter
>> *adap)
>>
>> return 0;
>>
>> +out_link:
>> +#ifdef CONFIG_I2C_COMPAT
>> +class_compat_remove_link(i2c_adapter_compat_class, >dev,
>> + adap->dev.parent);
>> +#endif
>> out_reg:
>> init_completion(>dev_released);
>> device_unregister(>dev);
>> --
>> 2.25.1
>>
Do you want me to integrate this patch in the previous one?
Best regards,
Codrin
[PATCH] mm: Fix protection usage propagation
From: Michal Koutný
When workload runs in cgroups that aren't directly below root cgroup and
their parent specifies reclaim protection, it may end up ineffective.
The reason is that propagate_protected_usage() is not called in all
hierarchy up. All the protected usage is incorrectly accumulated in the
workload's parent. This means that siblings_low_usage is overestimated
and effective protection underestimated. Even though it is transitional
phenomenon (uncharge path does correct propagation and fixes the wrong
children_low_usage), it can undermine the indended protection
unexpectedly.
The fix is simply updating children_low_usage in respective ancestors
also in the charging path.
Fixes: 230671533d64 ("mm: memory.low hierarchical behavior")
Cc: stable # 4.18+
Signed-off-by: Michal Koutný
Acked-by: Michal Hocko
---
Hi,
I am sending this patch on behalf of Michal Koutny who is currently
on vacation and didn't get to post it before he left.
We have noticed this problem while seeing a swap out in a descendant of
a protected memcg (intermediate node) while the parent was conveniently
under its protection limit and the memory pressure was external
to that hierarchy. Michal has pinpointed this down to the wrong
siblings_low_usage which led to the unwanted reclaim.
I am adding my ack directly in this submission.
mm/page_counter.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/page_counter.c b/mm/page_counter.c
index c56db2d5e159..b4663844c9b3 100644
--- a/mm/page_counter.c
+++ b/mm/page_counter.c
@@ -72,7 +72,7 @@ void page_counter_charge(struct page_counter *counter,
unsigned long nr_pages)
long new;
new = atomic_long_add_return(nr_pages, >usage);
- propagate_protected_usage(counter, new);
+ propagate_protected_usage(c, new);
/*
* This is indeed racy, but we can live with some
* inaccuracy in the watermark.
@@ -116,7 +116,7 @@ bool page_counter_try_charge(struct page_counter *counter,
new = atomic_long_add_return(nr_pages, >usage);
if (new > c->max) {
atomic_long_sub(nr_pages, >usage);
- propagate_protected_usage(counter, new);
+ propagate_protected_usage(c, new);
/*
* This is racy, but we can live with some
* inaccuracy in the failcnt.
@@ -125,7 +125,7 @@ bool page_counter_try_charge(struct page_counter *counter,
*fail = c;
goto failed;
}
- propagate_protected_usage(counter, new);
+ propagate_protected_usage(c, new);
/*
* Just like with failcnt, we can live with some
* inaccuracy in the watermark.
--
2.27.0
Re: [PATCH 2/2] dmabuf/tracing: Add dma-buf trace events
On Mon, 3 Aug 2020 14:47:19 + Kalesh Singh wrote: > +DECLARE_EVENT_CLASS(dma_buf_ref_template, > + > + TP_PROTO(struct task_struct *task, struct file *filp), > + > + TP_ARGS(task, filp), > + > + TP_STRUCT__entry( > + __field(u32, tgid) > + __field(u32, pid) I only see "current" passed in as "task". Why are you recording the pid and tgid as these are available by the tracing infrastructure. At least the pid is saved at every event. You can see the tgid when enabling the "record_tgid". # trace-cmd start -e all -O record_tgid # trace-cmd show # tracer: nop # # entries-in-buffer/entries-written: 39750/39750 #P:8 # # _-=> irqs-off # / _=> need-resched #| / _---=> hardirq/softirq #|| / _--=> preempt-depth #||| / delay # TASK-PIDTGID CPU# TIMESTAMP FUNCTION # | || | | | trace-cmd-28284 (28284) [005] 240338.934671: sys_exit: NR 1 = 1 kworker/3:2-27891 (27891) [003] d... 240338.934671: timer_start: timer=d643debd function=delayed_work_timer_fn expires=4535008893 [timeout=1981] cpu=3 idx=186 flags=I trace-cmd-28284 (28284) [005] 240338.934672: sys_write -> 0x1 kworker/3:2-27891 (27891) [003] 240338.934672: workqueue_execute_end: work struct 8fddd403: function psi_avgs_work kworker/3:2-27891 (27891) [003] 240338.934673: workqueue_execute_start: work struct 111c941e: function dbs_work_handler kworker/3:2-27891 (27891) [003] 240338.934673: workqueue_execute_end: work struct 111c941e: function dbs_work_handler kworker/3:2-27891 (27891) [003] d... 240338.934673: rcu_utilization: Start context switch kworker/3:2-27891 (27891) [003] d... 240338.934673: rcu_utilization: End context switch -- Steve > + __field(u64, size) > + __field(s64, count) > + __string(exp_name, dma_buffer(filp)->exp_name) > + __string(name, dma_buffer(filp)->name ? dma_buffer(filp)->name > : UNKNOWN) > + __field(u64, i_ino) > + ), > + > + TP_fast_assign( > + __entry->tgid = task->tgid; > + __entry->pid = task->pid; > + __entry->size = dma_buffer(filp)->size; > + __entry->count = file_count(filp); > + __assign_str(exp_name, dma_buffer(filp)->exp_name); > + __assign_str(name, dma_buffer(filp)->name ? > dma_buffer(filp)->name : UNKNOWN); > + __entry->i_ino = filp->f_inode->i_ino; > + ), > +
Re: [RFC PATCH 0/5] madvise MADV_DOEXEC
Steven Sistare writes:
> On 7/30/2020 5:58 PM, ebied...@xmission.com wrote:
>> Here is another suggestion.
>>
>> Have a very simple program that does:
>>
>> for (;;) {
>> handle = dlopen("/my/real/program");
>> real_main = dlsym(handle, "main");
>> real_main(argc, argv, envp);
>> dlclose(handle);
>> }
>>
>> With whatever obvious adjustments are needed to fit your usecase.
>>
>> That should give the same level of functionality, be portable to all
>> unices, and not require you to duplicate code. It belive it limits you
>> to not upgrading libc, or librt but that is a comparatively small
>> limitation.
>>
>>
>> Given that in general the interesting work is done in userspace and that
>> userspace has provided an interface for reusing that work already.
>> I don't see the justification for adding anything to exec at this point.
>
> Thanks for the suggestion. That is clever, and would make a fun project,
> but I would not trust it for production. These few lines are just
> the first of many that it would take to reset the environment to the
> well-defined post-exec initial conditions that all executables expect,
> and incrementally tearing down state will be prone to bugs.
Agreed.
> Getting a clean slate from a kernel exec is a much more reliable
> design.
Except you are explicitly throwing that out the window, by preserving
VMAs. You very much need to have a clean bug free shutdown to pass VMAs
reliably.
> The use case is creating long-lived apps that never go down, and the
> simplest implementation will have the fewest bugs and is the best.
> MADV_DOEXEC is simple, and does not even require a new system call,
> and the kernel already knows how to exec without bugs.
*ROFL* I wish the kernel knew how to exec things without bugs.
The bugs are hard to hit but the ones I am aware of are not straight
forward to fix.
MADV_DOEXEC is not conceptually simple. It completely violates the
guarantees that exec is known to make about the contents of the memory
of the new process. This makes it very difficult to reason about. Nor
will MADV_DOEXEC be tested very much as it has only one or two users.
Which means in the fullness of time it is likely someone will change
something that will break the implementation subtlely and the bug report
probably won't come in for 3 years, or maybe a decade. At which point
it won't be clear if the bug even can be fixed as something else might
rely on it.
What is wrong with live migration between one qemu process and another
qemu process on the same machine not work for this use case?
Just reusing live migration would seem to be the simplest path of all,
as the code is already implemented. Further if something goes wrong
with the live migration you can fallback to the existing process. With
exec there is no fallback if the new version does not properly support
the handoff protocol of the old version.
Eric
Re: [PATCH v2 2/2] memory: samsung: exynos5422-dmc: Add module param to control IRQ mode
Hi Lukasz, On 10.07.2020 21:11, Lukasz Luba wrote: > The driver can operate in two modes relaying on devfreq monitoring > mechanism which periodically checks the device status or it can use > interrupts when they are provided by loaded Device Tree. The newly > introduced module parameter can be used to choose between devfreq > monitoring and internal interrupts without modifying the Device Tree. > It also sets devfreq monitoring as default when the parameter is not set > (also the case for default when the driver is not built as a module). > > Reported-by: Willy Wolff > Signed-off-by: Lukasz Luba I've got back from my holidays and noticed that in meantime this commit got merged as commit 4fc9a0470d2d. It revealed that there is a race between registering exynos5422-dmc driver and exynos-ppmu driver, which can be observed sometimes as the following message and freeze on Odroid XU3 with multi_v7_defconfig: [ 8.767708] exynos5-dmc 10c2.memory-controller: couldn't probe performance counters I will check this later why the EPROBE_DEFER error is not properly propagated and why it causes a freeze. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v6 08/22] bootconfig: init: Allow admin to use bootconfig for init command line
On Tue, Aug 04, 2020 at 12:03:45AM +0900, Masami Hiramatsu wrote:
> On Sat, 1 Aug 2020 22:33:18 -0400
> Arvind Sankar wrote:
> >
> > I came across this as I was poking around some of the command line
> > parsing. AFAICT, initargs_found will never be set to true here, because
> > parse_args handles "--" itself by immediately returning: it doesn't
> > invoke the callback for it. So you'd instead have to check the return of
> > parse_args("bootconfig"...) to detect the initargs_found case.
>
> Oops, good catch!
> Does this fixes the problem?
Note I found the issue by code inspection, I don't have an actual test
case. But the change looks good to me, with one comment below.
>
> strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> - parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL,
> -bootconfig_params);
> + err = parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL,
> + bootconfig_params);
>
> - if (!bootconfig_found)
> + if (IS_ERR(err) || !bootconfig_found)
> return;
>
> + /* parse_args() stops at '--' and returns an address */
> + if (!IS_ERR(err) && err)
> + initargs_found = true;
> +
I think you can drop the second IS_ERR, since we already checked that.
> if (!data) {
> pr_err("'bootconfig' found on command line, but no bootconfig
> found\n");
> return;
> --
> 2.25.1
[GIT PULL] Mount notifications
Hi Linus,
Here's a set of patches to add notifications for mount topology events,
such as mounting, unmounting, mount expiry, mount reconfiguration.
The first patch in the series adds a hard limit on the number of watches
that any particular user can add. The RLIMIT_NOFILE value for the process
adding a watch is used as the limit. Even if you don't take the rest of
the series, can you at least take this one?
An LSM hook is included for an LSM to rule on whether or not a mount watch
may be set on a particular path.
This series is intended to be taken in conjunction with the fsinfo series
which I'll post a pull request for shortly and which is dependent on it.
Karel Zak[*] has created preliminary patches that add support to libmount
and Ian Kent has started working on making systemd use them.
[*] https://github.com/karelzak/util-linux/commits/topic/fsinfo
Note that there have been some last minute changes to the patchset: you
wanted something adding and Miklós wanted some bits taking out/changing.
I've placed a tag, fsinfo-core-20200724 on the aggregate of these two
patchsets that can be compared to fsinfo-core-20200803.
To summarise the changes: I added the limiter that you wanted; removed an
unused symbol; made the mount ID fields in the notificaion 64-bit (the
fsinfo patchset has a change to convey the mount uniquifier instead of the
mount ID); removed the event counters from the mount notification and moved
the event counters into the fsinfo patchset.
WHY?
Why do we want mount notifications? Whilst /proc/mounts can be polled, it
only tells you that something changed in your namespace. To find out, you
have to trawl /proc/mounts or similar to work out what changed in the mount
object attributes and mount topology. I'm told that the proc file holding
the namespace_sem is a point of contention, especially as the process of
generating the text descriptions of the mounts/superblocks can be quite
involved.
The notification generated here directly indicates the mounts involved in
any particular event and gives an idea of what the change was.
This is combined with a new fsinfo() system call that allows, amongst other
things, the ability to retrieve in one go an { id, change_counter } tuple
from all the children of a specified mount, allowing buffer overruns to be
dealt with quickly.
This is of use to systemd to improve efficiency:
https://lore.kernel.org/linux-fsdevel/20200227151421.3u74ijhqt6ekb...@ws.net.home/
And it's not just Red Hat that's potentially interested in this:
https://lore.kernel.org/linux-fsdevel/293c9bd3-f530-d75e-c353-ddeabac27...@6wind.com/
David
---
The following changes since commit ba47d845d715a010f7b51f6f89bae32845e6acb7:
Linux 5.8-rc6 (2020-07-19 15:41:18 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
tags/mount-notifications-20200803
for you to fetch changes up to 841a0dfa511364fa9a8d67512e0643669f1f03e3:
watch_queue: sample: Display mount tree change notifications (2020-08-03
12:15:38 +0100)
Mount notifications
David Howells (5):
watch_queue: Limit the number of watches a user can hold
watch_queue: Make watch_sizeof() check record size
watch_queue: Add security hooks to rule on setting mount watches
watch_queue: Implement mount topology and attribute change notifications
watch_queue: sample: Display mount tree change notifications
Documentation/watch_queue.rst | 12 +-
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl| 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
fs/Kconfig | 9 ++
fs/Makefile | 1 +
fs/mount.h | 18 +++
fs/mount_notify.c | 222
fs/namespace.c | 22 +++
include/linux/dcache.h | 1 +
include/linux
Re: [PATCH v2 4/7] cpufreq: report whether cpufreq supports Frequency Invariance (FI)
Hi Viresh,
On Thursday 30 Jul 2020 at 10:13:46 (+0530), Viresh Kumar wrote:
> On 22-07-20, 10:37, Ionela Voinescu wrote:
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 3497c1cd6818..1d0b046fe8e9 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -61,6 +61,9 @@ static struct cpufreq_driver *cpufreq_driver;
> > static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
> > static DEFINE_RWLOCK(cpufreq_driver_lock);
> >
> > +/* Mark support for the scheduler's frequency invariance engine */
> > +static DEFINE_STATIC_KEY_FALSE(cpufreq_set_freq_scale);
> > +
> > /* Flag to suspend/resume CPUFreq governors */
> > static bool cpufreq_suspended;
> >
> > @@ -69,6 +72,25 @@ static inline bool has_target(void)
> > return cpufreq_driver->target_index || cpufreq_driver->target;
> > }
> >
> > +static inline
> > +void enable_cpufreq_freq_invariance(struct cpufreq_driver *driver)
> > +{
> > + if ((driver->target || driver->target_index || driver->fast_switch) &&
> > + !driver->setpolicy) {
>
> Just checking for !driver->setpolicy should be enough here.
>
Right, cpufreq_register_driver() should check that at least one of them
is present (although currently cpufreq_register_driver() will return
-EINVAL if .fast_switch() alone is present - something to be fixed).
Will do, on both accounts.
> > + static_branch_enable_cpuslocked(_set_freq_scale);
> > + pr_debug("%s: Driver %s can provide frequency invariance.",
> > +__func__, driver->name);
>
> I think a simpler print will work well too.
>
> pr_debug("Freq invariance enabled");
>
I think the right way of reporting this support is important here.
By enabling the static key here, we're not actually enabling frequency
invariance. So printing "Freq invariance enabled" would be very
misleading. Frequency invariance (scheduler concept) being truly enabled
depends on three things:
- Having a source of information for current frequency and maximum
frequency (cpufreq, counters)
- Having arch support for using that information to set the frequency
scale factor: arch_set_freq_scale(), arch_scale_freq_tick()
- Having arch support for passing the set frequency scale factor to the
scheduler and reporting support for frequency invariance:
arch_scale_freq_capacity(), arch_scale_freq_invariant().
Therefore, cpufreq can only report that the current driver can be a
source of information for frequency invariance "Driver %s can provide
frequency invariance", but it can't guarantee that the other conditions
are accomplished.
So I would recommend to keep this original debug message.
> __func__ isn't really required as this is the only print with that
> kind of info in cpufreq.c.
>
Makes sense!
> > + } else
> > + pr_err("%s: Driver %s cannot provide frequency invariance.",
> > + __func__, driver->name);
>
> Why not supporting freq-invariance an error ? I will just drop this
> message completely.
Yes, an error does not make sense here. I was thinking to demote it to a
warning instead in my previous reply to Rafael, but removing it
altogether might be better.
Many thanks for the thorough review,
Ionela.
>
> --
> viresh
KASAN: use-after-free Read in tipc_bcast_get_mode
Hello, syzbot found the following issue on: HEAD commit:bd0b33b2 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=13f236a490 kernel config: https://syzkaller.appspot.com/x/.config?x=91a13b78c7dc258d dashboard link: https://syzkaller.appspot.com/bug?extid=6ea1f7a8df64596ef4d7 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+6ea1f7a8df64596ef...@syzkaller.appspotmail.com tipc: 32-bit node address hash set to fcff1eac == BUG: KASAN: use-after-free in tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 Read of size 1 at addr 88805e6b3571 by task kworker/0:6/3850 CPU: 0 PID: 3850 Comm: kworker/0:6 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 tipc_node_broadcast+0x9e/0xcc0 net/tipc/node.c:1744 tipc_nametbl_publish+0x60b/0x970 net/tipc/name_table.c:752 tipc_net_finalize net/tipc/net.c:141 [inline] tipc_net_finalize+0x1fa/0x310 net/tipc/net.c:131 tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Allocated by task 8062: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 kmem_cache_alloc_trace+0x14f/0x2d0 mm/slab.c:3551 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] tipc_bcast_init+0x21e/0x7b0 net/tipc/bcast.c:689 tipc_init_net+0x4f6/0x5c0 net/tipc/core.c:85 ops_init+0xaf/0x470 net/core/net_namespace.c:151 setup_net+0x2d8/0x850 net/core/net_namespace.c:341 copy_net_ns+0x2cf/0x5e0 net/core/net_namespace.c:482 create_new_namespaces+0x3f6/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231 ksys_unshare+0x36c/0x9a0 kernel/fork.c:2979 __do_sys_unshare kernel/fork.c:3047 [inline] __se_sys_unshare kernel/fork.c:3045 [inline] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3045 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 8843: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455 __cache_free mm/slab.c:3426 [inline] kfree+0x103/0x2c0 mm/slab.c:3757 tipc_bcast_stop+0x1b0/0x2f0 net/tipc/bcast.c:721 tipc_exit_net+0x24/0x270 net/tipc/core.c:112 ops_exit_list+0xb0/0x160 net/core/net_namespace.c:186 cleanup_net+0x4ea/0xa00 net/core/net_namespace.c:603 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 The buggy address belongs to the object at 88805e6b3500 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 113 bytes inside of 128-byte region [88805e6b3500, 88805e6b3580) The buggy address belongs to the page: page:ea000179acc0 refcount:1 mapcount:0 mapping: index:0x0 flags: 0xfffe000200(slab) raw: 00fffe000200 ea0002375c48 8880aa001550 8880aa000700 raw: 88805e6b3000 00010010 page dumped because: kasan: bad access detected Memory state around the buggy address: 88805e6b3400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88805e6b3480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >88805e6b3500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 88805e6b3580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 88805e6b3600: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc == --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v6 12/12] x86/traps: Fix up invalid PASID
On Mon, Aug 03, 2020 at 08:12:18AM -0700, Andy Lutomirski wrote: > On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote: > > > > On 7/31/20 4:34 PM, Andy Lutomirski wrote: > > >> Thomas suggested to provide a reason for the #GP caused by executing > > >> ENQCMD > > >> without a valid PASID value programmed. #GP error codes are 16 bits and > > >> all > > >> 16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The > > >> other > > >> choice was to reflect the error code in an MSR. ENQCMD can also cause #GP > > >> when loading from the source operand, so its not fully comprehending all > > >> the reasons. Rather than special case the ENQCMD, in future Intel may > > >> choose a different fault mechanism for such cases if recovery is needed > > >> on > > >> #GP. > > > Decoding the user instruction is ugly and sets a bad architecture > > > precedent, but we already do it in #GP for UMIP. So I'm unconvinced. > > > > I'll try to do one more bit of convincing. :) > > > > In the end, we need a way to figure out if the #GP was from a known "OK" > > source that we can fix up. You're right that we could fire up the > > instruction decoder to help answer that question. But, it (also) > > doesn't easily yield a perfect answer as to the source of the #GP, it > > always involves a user copy, and it's a larger code impact than what > > we've got. > > > > I think I went and looked at fixup_umip_exception(), and compared it to > > the alternative which is essentially just these three lines of code: > > > > > + /* > > > + * If the current task already has a valid PASID in the MSR, > > > + * the #GP must be for some other reason. > > > + */ > > > + if (current->has_valid_pasid) > > > + return false; > > ...> + /* Now the current task has a valid PASID in the MSR. */ > > > + current->has_valid_pasid = 1; > > > > and *I* was convinced that instruction decoding wasn't worth it. > > > > There's a lot of stuff that fixup_umip_exception() does which we don't > > have to duplicate, but it's going to be really hard to get it anywhere > > near as compact as what we've got. > > > > I could easily be convinced that the PASID fixup is so trivial and so > obviously free of misfiring in a way that causes an infinite loop that > this code is fine. But I think we first need to answer the bigger > question of why we're doing a lazy fixup in the first place. We choose lazy fixup for 2 reasons. - If some threads were already created before the MSR is programmed, then we need to fixup those in a race free way. scheduling some task-work etc. We did do that early on, but decided it was ugly. - Not all threads need to submit ENQCMD, force feeding the MSR probably isn't even required for all. Yes the overhead isn't probably big, but might not even be required for all threads. We needed to fixup MSR in two different way. To keep the code simple, the choice was to only fixup on #GP, that eliminated the extra code we need to support case1. Cheers, Ashok
RE: [RFC][PATCH] objtool,x86_64,paravirt: Add pv_ops[] support
From: pet...@infradead.org Sent: Monday, August 3, 2020 7:33 AM
>
> Thomas wanted paramuck vs noinstr, here goes. Very rough, very nasty,
> mostly works.
>
> It requires call sites are the normal indirect call, and not mangled
> retpoison (slow_down_io() had those), it also requires pv_ops[]
> assignments are single instructions and not laundered through some
> pointless intermediate helper (hyperv).
>
> It doesn't warn when you get any of that wrong.
>
> But if you have it all lined up right, it will warn about noinstr
> violations due to paramuck:
>
> $ ./objtool check -afl ../../defconfig-build/vmlinux.o
> ../../defconfig-build/vmlinux.o: warning: objtool:
> xen_pv_evtchn_do_upcall()+0x69: return
> with instrumentation enabled
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_double_fault()+0x15:
> call pv_ops[48]
> from noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: pv_op[48]: xen_read_cr2
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_double_fault()+0x15:
> call to
> {dynamic}() leaves .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_debug()+0x29: call
> pv_ops[4] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: pv_op[4]:
> native_get_debugreg
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_debug()+0x29: call to
> {dynamic}()
> leaves .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool: noist_exc_debug()+0x26:
> call pv_ops[4]
> from noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: pv_op[4]:
> native_get_debugreg
> ../../defconfig-build/vmlinux.o: warning: objtool: noist_exc_debug()+0x26:
> call to
> {dynamic}() leaves .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_nmi()+0x3a: call
> pv_ops[48] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: pv_op[48]: xen_read_cr2
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_nmi()+0x3a: call to
> {dynamic}() leaves
> .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool: mce_setup()+0x80: call
> pv_ops[25] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: pv_op[25]: native_cpuid
> ../../defconfig-build/vmlinux.o: warning: objtool: mce_setup()+0x80: call to
> {dynamic}()
> leaves .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool: do_machine_check()+0x46:
> call to
> mce_rdmsrl() leaves .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_machine_check()+0x24:
> call
> pv_ops[4] from noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: pv_op[4]:
> native_get_debugreg
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_machine_check()+0x24:
> call to
> {dynamic}() leaves .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool:
> noist_exc_machine_check()+0x24: call
> pv_ops[4] from noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: pv_op[4]:
> native_get_debugreg
> ../../defconfig-build/vmlinux.o: warning: objtool:
> noist_exc_machine_check()+0x24: call to
> {dynamic}() leaves .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_page_fault()+0xe: call
> pv_ops[48]
> from noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: pv_op[48]: xen_read_cr2
> ../../defconfig-build/vmlinux.o: warning: objtool: exc_page_fault()+0xe: call
> to {dynamic}()
> leaves .noinstr.text section
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0xf17: call
> pv_ops[32] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x12f1: call
> pv_ops[35] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0xf5a: call
> pv_ops[32] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x1002: call
> pv_ops[32] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x1186: call
> pv_ops[32] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x12ba: call
> pv_ops[32] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x12a7: call
> pv_ops[32] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x124c: call
> pv_ops[32] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x14f0: call
> pv_ops[32] from
> noinstr
> ../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x1683: call
> pv_ops[32] from
> noinstr
>
> [ funny that, WTH does x86_64 have IRET pv_ops... ]
>
> Requested-by: Thomas Gleixner
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/include/asm/paravirt.h| 8 +--
> arch/x86/kernel/cpu/mshyperv.c | 7 ---
> drivers/clocksource/hyperv_timer.c | 7 +++
> include/asm-generic/mshyperv.h | 1 -
> lib/Kconfig.debug | 2 +-
> tools/objtool/Makefile | 2 +-
> tools/objtool/arch.h | 2 +-
>
Re: [PATCH v5 00/16] HWPOISON: soft offline rework
On Mon, Aug 03, 2020 at 01:36:58PM +, HORIGUCHI NAOYA(堀口 直也) wrote: > Hello, > > On Mon, Aug 03, 2020 at 08:39:55AM -0400, Qian Cai wrote: > > On Fri, Jul 31, 2020 at 12:20:56PM +, nao.horigu...@gmail.com wrote: > > > This patchset is the latest version of soft offline rework patchset > > > targetted for v5.9. > > > > > > Main focus of this series is to stabilize soft offline. Historically soft > > > offlined pages have suffered from racy conditions because PageHWPoison is > > > used to a little too aggressively, which (directly or indirectly) invades > > > other mm code which cares little about hwpoison. This results in > > > unexpected > > > behavior or kernel panic, which is very far from soft offline's "do not > > > disturb userspace or other kernel component" policy. > > > > > > Main point of this change set is to contain target page "via buddy > > > allocator", > > > where we first free the target page as we do for normal pages, and remove > > > from buddy only when we confirm that it reaches free list. There is surely > > > race window of page allocation, but that's fine because someone really > > > want > > > that page and the page is still working, so soft offline can happily give > > > up. > > > > > > v4 from Oscar tries to handle the race around reallocation, but that part > > > seems still work in progress, so I decide to separate it for changes into > > > v5.9. Thank you for your contribution, Oscar. > > > > > > The issue reported by Qian Cai is fixed by patch 16/16. > > > > I am still getting EIO everywhere on next-20200803 (which includes this v5). > > > > # ./random 1 > > - start: migrate_huge_offline > > - use NUMA nodes 0,8. > > - mmap and free 8388608 bytes hugepages on node 0 > > - mmap and free 8388608 bytes hugepages on node 8 > > madvise: Input/output error > > > > From the serial console, > > > > [ 637.164222][ T8357] soft offline: 0x118ee0: hugepage isolation failed: > > 0, page count 2, type 7fff81000e (referenced|uptodate|dirty|head) > > [ 637.164890][ T8357] Soft offlining pfn 0x20001380 at process virtual > > address 0x7fff9f00 > > [ 637.165422][ T8357] Soft offlining pfn 0x3ba00 at process virtual > > address 0x7fff9f20 > > [ 637.166409][ T8357] Soft offlining pfn 0x201914a0 at process virtual > > address 0x7fff9f00 > > [ 637.166833][ T8357] Soft offlining pfn 0x12b9a0 at process virtual > > address 0x7fff9f20 > > [ 637.168044][ T8357] Soft offlining pfn 0x1abb60 at process virtual > > address 0x7fff9f00 > > [ 637.168557][ T8357] Soft offlining pfn 0x20014820 at process virtual > > address 0x7fff9f20 > > [ 637.169493][ T8357] Soft offlining pfn 0x119720 at process virtual > > address 0x7fff9f00 > > [ 637.169603][ T8357] soft offline: 0x119720: hugepage isolation failed: > > 0, page count 2, type 7fff81000e (referenced|uptodate|dirty|head) > > [ 637.169756][ T8357] Soft offlining pfn 0x118ee0 at process virtual > > address 0x7fff9f20 > > [ 637.170653][ T8357] Soft offlining pfn 0x200e81e0 at process virtual > > address 0x7fff9f00 > > [ 637.171067][ T8357] Soft offlining pfn 0x201c5f60 at process virtual > > address 0x7fff9f20 > > [ 637.172101][ T8357] Soft offlining pfn 0x201c8f00 at process virtual > > address 0x7fff9f00 > > [ 637.172241][ T8357] __get_any_page: 0x201c8f00: unknown zero refcount > > page type 87fff80 > > I might misjudge to skip the following patch, sorry about that. > Could you try with it? Still getting EIO after applied this patch. [ 1215.499030][T88982] soft offline: 0x201bdc20: hugepage isolation failed: 0, page count 2, type 87fff81000e (referenced|uptodate|dirty|head) [ 1215.499775][T88982] Soft offlining pfn 0x201bdc20 at process virtual address 0x7fff91a0 [ 1215.500189][T88982] Soft offlining pfn 0x201c19c0 at process virtual address 0x7fff91c0 [ 1215.500297][T88982] soft offline: 0x201c19c0: hugepage isolation failed: 0, page count 2, type 87fff81000e (referenced|uptodate|dirty|head) [ 1215.500982][T88982] Soft offlining pfn 0x1f1fa0 at process virtual address 0x7fff91a0 [ 1215.501086][T88982] soft offline: 0x1f1fa0: hugepage isolation failed: 0, page count 2, type 7fff81000e (referenced|uptodate|dirty|head) [ 1215.501237][T88982] Soft offlining pfn 0x1f4520 at process virtual address 0x7fff91c0 [ 1215.501355][T88982] soft offline: 0x1f4520: hugepage isolation failed: 0, page count 2, type 7fff8
[PATCH] iio:temperature:mlx90632: Reduce number of equal calulcations
TAdut4 was calculated each iteration although it did not change. In light
of near future additions of the Extended range DSP calculations, this
function refactoring will help reduce unrelated changes in that series as
well as reduce the number of new functions needed.
Also converted shifts in this function of signed integers to divisions as
that is less implementation-defined behavior.
Signed-off-by: Crt Mori
---
drivers/iio/temperature/mlx90632.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/temperature/mlx90632.c
b/drivers/iio/temperature/mlx90632.c
index eaca6ba06864..d7ba0b2fe3c0 100644
--- a/drivers/iio/temperature/mlx90632.c
+++ b/drivers/iio/temperature/mlx90632.c
@@ -374,29 +374,25 @@ static s32 mlx90632_calc_temp_ambient(s16
ambient_new_raw, s16 ambient_old_raw,
}
static s32 mlx90632_calc_temp_object_iteration(s32 prev_object_temp, s64
object,
- s64 TAdut, s32 Fa, s32 Fb,
+ s64 TAdut, s64 TAdut4, s32 Fa,
s32 Fb,
s32 Ga, s16 Ha, s16 Hb,
u16 emissivity)
{
s64 calcedKsTO, calcedKsTA, ir_Alpha, TAdut4, Alpha_corr;
s64 Ha_customer, Hb_customer;
- Ha_customer = ((s64)Ha * 100LL) >> 14ULL;
- Hb_customer = ((s64)Hb * 100) >> 10ULL;
+ Ha_customer = div64_s64((s64)Ha * 100LL, 16384);
+ Hb_customer = div64_s64((s64)Hb * 100, 1024);
- calcedKsTO = ((s64)((s64)Ga * (prev_object_temp - 25 * 1000LL)
-* 1000LL)) >> 36LL;
- calcedKsTA = ((s64)(Fb * (TAdut - 25 * 100LL))) >> 36LL;
- Alpha_corr = div64_s64s64)(Fa * 100LL) >> 46LL)
- * Ha_customer), 1000LL);
+ calcedKsTO = div64_s64((s64)((s64)Ga * (prev_object_temp - 25 * 1000LL)
+* 1000LL), 68719476736);
+ calcedKsTA = div64_s64((s64)(Fb * (TAdut - 25 * 100LL)),
68719476736);
+ Alpha_corr = div64_s64(div64_s64((s64)(Fa * 100LL),
70368744177664)
+ * Ha_customer, 1000LL);
Alpha_corr *= ((s64)(1 * 100LL + calcedKsTO + calcedKsTA));
Alpha_corr = emissivity * div64_s64(Alpha_corr, 10LL);
Alpha_corr = div64_s64(Alpha_corr, 1000LL);
ir_Alpha = div64_s64((s64)object * 1000LL, Alpha_corr);
- TAdut4 = (div64_s64(TAdut, 1LL) + 27315) *
- (div64_s64(TAdut, 1LL) + 27315) *
- (div64_s64(TAdut, 1LL) + 27315) *
- (div64_s64(TAdut, 1LL) + 27315);
return (int_sqrt64(int_sqrt64(ir_Alpha * 1LL + TAdut4))
- 27315 - Hb_customer) * 10;
@@ -413,10 +409,14 @@ static s32 mlx90632_calc_temp_object(s64 object, s64
ambient, s32 Ea, s32 Eb,
kTA = (Ea * 1000LL) >> 16LL;
kTA0 = (Eb * 1000LL) >> 8LL;
TAdut = div64_s64(((ambient - kTA0) * 100LL), kTA) + 25 * 100LL;
+ TAdut4 = (div64_s64(TAdut, 1LL) + 27315) *
+ (div64_s64(TAdut, 1LL) + 27315) *
+ (div64_s64(TAdut, 1LL) + 27315) *
+ (div64_s64(TAdut, 1LL) + 27315);
/* Iterations of calculation as described in datasheet */
for (i = 0; i < 5; ++i) {
- temp = mlx90632_calc_temp_object_iteration(temp, object, TAdut,
+ temp = mlx90632_calc_temp_object_iteration(temp, object, TAdut,
TAdut4,
Fa, Fb, Ga, Ha, Hb,
tmp_emi);
}
--
2.25.1
Re: [RFC v2 4/5] dt-bindings: of: Add plumbing for restricted DMA pool
Hi Claire and Rob, On Mon, Aug 3, 2020 at 4:26 PM Claire Chang wrote: > > On Sat, Aug 1, 2020 at 4:58 AM Rob Herring wrote: > > > > On Tue, Jul 28, 2020 at 01:01:39PM +0800, Claire Chang wrote: > > > Introduce the new compatible string, device-swiotlb-pool, for restricted > > > DMA. One can specify the address and length of the device swiotlb memory > > > region by device-swiotlb-pool in the device tree. > > > > > > Signed-off-by: Claire Chang > > > --- > > > .../reserved-memory/reserved-memory.txt | 35 +++ > > > 1 file changed, 35 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > index 4dd20de6977f..78850896e1d0 100644 > > > --- > > > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > +++ > > > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > @@ -51,6 +51,24 @@ compatible (optional) - standard definition > > >used as a shared pool of DMA buffers for a set of devices. It > > > can > > >be used by an operating system to instantiate the necessary > > > pool > > >management subsystem if necessary. > > > +- device-swiotlb-pool: This indicates a region of memory meant > > > to be > > > > swiotlb is a Linux thing. The binding should be independent. > Got it. Thanks for pointing this out. > > > > > > + used as a pool of device swiotlb buffers for a given device. > > > When > > > + using this, the no-map and reusable properties must not be > > > set, so the > > > + operating system can create a virtual mapping that will be > > > used for > > > + synchronization. Also, there must be a restricted-dma property > > > in the > > > + device node to specify the indexes of reserved-memory nodes. > > > One can > > > + specify two reserved-memory nodes in the device tree. One with > > > + shared-dma-pool to handle the coherent DMA buffer allocation, > > > and > > > + another one with device-swiotlb-pool for regular DMA to/from > > > system > > > + memory, which would be subject to bouncing. The main purpose > > > for > > > + restricted DMA is to mitigate the lack of DMA access control on > > > + systems without an IOMMU, which could result in the DMA > > > accessing the > > > + system memory at unexpected times and/or unexpected addresses, > > > + possibly leading to data leakage or corruption. The feature on > > > its own > > > + provides a basic level of protection against the DMA > > > overwriting buffer > > > + contents at unexpected times. However, to protect against > > > general data > > > + leakage and system memory corruption, the system needs to > > > provide a > > > + way to restrict the DMA to a predefined memory region. > > > > I'm pretty sure we already support per device carveouts and I don't > > understand how this is different. > We use this to bounce streaming DMA in and out of a specially allocated > region. > I'll try to merge this with the existing one (i.e., shared-dma-pool) > to see if that > makes things clearer. > Indeed, from the firmware point of view, this is just a carveout, for which we have the "shared-dma-pool" compatible string defined already. However, depending on the device and firmware setup, the way the carevout is used may change. I can see the following scenarios: 1) coherent DMA (dma_alloc_*) within a reserved pool and no non-coherent DMA (dma_map_*). This is how the "memory-region" property is handled today in Linux for devices which can only DMA from/to the given memory region. However, I'm not sure if no non-coherent DMA is actually enforced in any way by the DMA subsystem. 2) coherent DMA from a reserved pool and non-coherent DMA from system memory This is the case for the systems which have some dedicated part of memory which is guaranteed to be coherent with the DMA, but still can do non-coherent DMA to any part of the system memory. Linux handles it the same way as 1), which is what made me believe that 1) might not actually be handled correctly. 3) coherent DMA and bounced non-coherent DMA within a reserved pool 4) coherent DMA within one pool and bounced non-coherent within another pool These are the two cases we're interested in. Basically they make it possible for non-coherent DMA from arbitrary system memory to be bounced through a reserved pool, which the device has access to. The current series implements 4), but I'd argue that it: - is problematic from the firmware point of view, because on most of the systems, both pools would be just some carveouts and the fact that Linux would use one for coherent and the other for non-coherent DMA would be an OS implementation detail, - suffers from the static memory split
Re: [RFC][PATCH] objtool,x86_64,paravirt: Add pv_ops[] support
On Mon, Aug 3, 2020 at 7:33 AM wrote: > > > Thomas wanted paramuck vs noinstr, here goes. Very rough, very nasty, > mostly works. > > It requires call sites are the normal indirect call, and not mangled > retpoison (slow_down_io() had those), it also requires pv_ops[] > assignments are single instructions and not laundered through some > pointless intermediate helper (hyperv). > > It doesn't warn when you get any of that wrong. > > But if you have it all lined up right, it will warn about noinstr > violations due to paramuck: I certainly agree that pv_ops is mucky, but could you expound on precisely what this patch actually does? On a very quick read-through, I'm guessing you're complaining about any call to pv_ops in a noinstr section? But maybe this is only calls to pv_ops that aren't themselves noinstr?
Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting
Vladimir Oltean writes: >> 1) When irq accounting is disabled, RT throttling kicks in as >> expected. >> >> 2) With irq accounting the RT throttler does not kick in and the RCU >> stall/lockups happen. >> >> Not much, but there is clearly interaction between irq time accounting >> and scheduler accounting. >> >> Can you please reduce /proc/sys/kernel/sched_rt_runtime_us in steps of >> 5? At least in theory, reduction should bring the throttling back. > > We already know from my original report that reducing > sched_rt_runtime_us to 80% (80) gives us a stable system. > https://lkml.org/lkml/2020/6/4/1062 Oh. Somehow missed that. Btw, can you please use links in the form of: https://lore.kernel.org/r/$MSGID lkml.org is spotty and having the message id allows to search in the mail client as well. > What is this telling us? It seems that the fine grained irq time accounting affects the runtime accounting in some way which I haven't figured out yet. Thanks, tglx
Re: [PATCH v6 12/12] x86/traps: Fix up invalid PASID
On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote: > > On 7/31/20 4:34 PM, Andy Lutomirski wrote: > >> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD > >> without a valid PASID value programmed. #GP error codes are 16 bits and all > >> 16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The other > >> choice was to reflect the error code in an MSR. ENQCMD can also cause #GP > >> when loading from the source operand, so its not fully comprehending all > >> the reasons. Rather than special case the ENQCMD, in future Intel may > >> choose a different fault mechanism for such cases if recovery is needed on > >> #GP. > > Decoding the user instruction is ugly and sets a bad architecture > > precedent, but we already do it in #GP for UMIP. So I'm unconvinced. > > I'll try to do one more bit of convincing. :) > > In the end, we need a way to figure out if the #GP was from a known "OK" > source that we can fix up. You're right that we could fire up the > instruction decoder to help answer that question. But, it (also) > doesn't easily yield a perfect answer as to the source of the #GP, it > always involves a user copy, and it's a larger code impact than what > we've got. > > I think I went and looked at fixup_umip_exception(), and compared it to > the alternative which is essentially just these three lines of code: > > > + /* > > + * If the current task already has a valid PASID in the MSR, > > + * the #GP must be for some other reason. > > + */ > > + if (current->has_valid_pasid) > > + return false; > ...> + /* Now the current task has a valid PASID in the MSR. */ > > + current->has_valid_pasid = 1; > > and *I* was convinced that instruction decoding wasn't worth it. > > There's a lot of stuff that fixup_umip_exception() does which we don't > have to duplicate, but it's going to be really hard to get it anywhere > near as compact as what we've got. > I could easily be convinced that the PASID fixup is so trivial and so obviously free of misfiring in a way that causes an infinite loop that this code is fine. But I think we first need to answer the bigger question of why we're doing a lazy fixup in the first place. --Andy
Re: [PATCH v6 2/3] binder: add trace at free transaction.
On Sun, Aug 2, 2020 at 8:11 PM Frankie Chang wrote:
>
> On Fri, 2020-07-31 at 11:50 -0700, Todd Kjos wrote:
> > On Mon, Jul 27, 2020 at 8:28 PM Frankie Chang
> > wrote:
> > >
> > > From: "Frankie.Chang"
> > >
> > > Since the original trace_binder_transaction_received cannot
> > > precisely present the real finished time of transaction, adding a
> > > trace_binder_txn_latency_free at the point of free transaction
> > > may be more close to it.
> > >
> > > Signed-off-by: Frankie.Chang
> > > ---
> > > drivers/android/binder.c |6 ++
> > > drivers/android/binder_trace.h | 27 +++
> > > 2 files changed, 33 insertions(+)
> > >
> > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > > index 2df146f..1e6fc40 100644
> > > --- a/drivers/android/binder.c
> > > +++ b/drivers/android/binder.c
> > > @@ -1522,6 +1522,9 @@ static void binder_free_transaction(struct
> > > binder_transaction *t)
> > > * If the transaction has no target_proc, then
> > > * t->buffer->transaction has already been cleared.
> > > */
> > > + spin_lock(>lock);
> > > + trace_binder_txn_latency_free(t);
> > > + spin_unlock(>lock);
> >
> > Hmm. I don't prefer taking the lock just to call a trace. It doesn't
> > make clear why the lock has to be taken. I'd prefer something like:
> >
> > if (trace_binder_txn_latency_free_enabled()) {
> c
> > }
> >
> > And then the trace would use the passed-in values instead of accessing
> > via t->to_proc/to_thread.
> >
> Then we still add lock protection in the hook function, when trace is
> disable ?
I don't understand... in the example I gave, the trace doesn't get
called if disabled. What do you mean to "add lock protection when the
trace is disabled()"?
>
> Or we also pass these to hook function, no matter the trace is enable or
What do you mean by "hook" function? If something has attached to the
trace, then xxx_enabled() will return true.
> not.I think this way is more clear that the lock protects @from,
> @to_proc and @to_thread.Then, there is no need to add the lock in hook
> function.
Why is it clearer (other than the fact that I missed including t->from
under the lock)?
>
> int from_proc, from_thread, to_proc, to_thread;
>
> spin_lock(>lock);
> from_proc = t->from ? t->from->proc->pid : 0;
> from_thread = t->from ? t->from->pid :0;
> to_proc = t->to_proc ? t->to_proc->pid : 0;
> to_thread = t->to_thread ? t->to_thread->pid : 0;
> spin_unlock(>lock);
> trace_binder_txn_latency_free(t, from_proc, from_thread, to_proc,
> to_pid);
The main feedback is I'd like to see the fields dereferenced in the
same context as the lock acquisition instead of acquiring the lock and
calling the trace function, so this code would be fine. There will be
very little contention for t->lock so using xxx_enabled() is optional.
Since trace_binder_txn_latency_free() is called twice, it would make
sense to have a helper function to do the above.
>
> > > binder_free_txn_fixups(t);
> > > kfree(t);
> > > binder_stats_deleted(BINDER_STAT_TRANSACTION);
> > > @@ -3093,6 +3096,9 @@ static void binder_transaction(struct binder_proc
> > > *proc,
> > > kfree(tcomplete);
> > > binder_stats_deleted(BINDER_STAT_TRANSACTION_COMPLETE);
> > > err_alloc_tcomplete_failed:
> > > + spin_lock(>lock);
> > > + trace_binder_txn_latency_free(t);
> > > + spin_unlock(>lock);
> > > kfree(t);
> > > binder_stats_deleted(BINDER_STAT_TRANSACTION);
> > > err_alloc_t_failed:
> > > diff --git a/drivers/android/binder_trace.h
> > > b/drivers/android/binder_trace.h
> > > index 6731c3c..8ac87d1 100644
> > > --- a/drivers/android/binder_trace.h
> > > +++ b/drivers/android/binder_trace.h
> > > @@ -95,6 +95,33 @@
> > > __entry->thread_todo)
> > > );
> > >
> > > +TRACE_EVENT(binder_txn_latency_free,
> > > + TP_PROTO(struct binder_transaction *t),
> > > + TP_ARGS(t),
> > > + TP_STRUCT__entry(
> > > + __field(int, debug_id)
> > > + __field(int, from_proc)
> > > + __field(int, from_thread)
> > > + __field(int, to_proc)
> > > + __field(int, to_thread)
> > > + __field(unsigned int, code)
> > > + __field(unsigned int, flags)
> > > + ),
> > > + TP_fast_assign(
> > > + __entry->debug_id = t->debug_id;
> > > + __entry->from_proc = t->from ? t->from->proc->pid : 0;
> > > + __entry->from_thread = t->from ? t->from->pid : 0;
> > > + __entry->to_proc = t->to_proc ? t->to_proc->pid : 0;
> > > + __entry->to_thread = t->to_thread ? t->to_thread->pid : 0;
> > > + __entry->code = t->code;
> > > + __entry->flags = t->flags;
> > > + ),
> > > + TP_printk("transaction=%d from %d:%d to %d:%d flags=0x%x
> > > code=0x%x",
> > > +
[PATCH] asm-generic/io.h: Fix sparse warnings on big-endian architectures
On big-endian architectures like OpenRISC, sparse outputs below warnings on
asm-generic/io.h. This is due to io statements like:
__raw_writel(cpu_to_le32(value), PCI_IOBASE + addr);
The __raw_writel() function expects native endianness, however
cpu_to_le32() returns __le32. On little-endian machines these match up
and there is no issue. However, on big-endian we get warnings, for IO
that is defined as little-endian the mismatch is expected.
The fix I propose is to __force to native endian.
Warnings:
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:215:22: warning: incorrect type in argument 1
(different base types)
./include/asm-generic/io.h:215:22:expected unsigned short [usertype] value
./include/asm-generic/io.h:215:22:got restricted __le16 [usertype]
./include/asm-generic/io.h:225:22: warning: incorrect type in argument 1
(different base types)
./include/asm-generic/io.h:225:22:expected unsigned int [usertype] value
./include/asm-generic/io.h:225:22:got restricted __le32 [usertype]
Signed-off-by: Stafford Horne
---
include/asm-generic/io.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 30a3aab312e6..c88b73934ab7 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -163,7 +163,7 @@ static inline u16 readw(const volatile void __iomem *addr)
u16 val;
__io_br();
- val = __le16_to_cpu(__raw_readw(addr));
+ val = __le16_to_cpu((__le16 __force) __raw_readw(addr));
__io_ar(val);
return val;
}
@@ -176,7 +176,7 @@ static inline u32 readl(const volatile void __iomem *addr)
u32 val;
__io_br();
- val = __le32_to_cpu(__raw_readl(addr));
+ val = __le32_to_cpu((__le32 __force) __raw_readl(addr));
__io_ar(val);
return val;
}
@@ -212,7 +212,7 @@ static inline void writeb(u8 value, volatile void __iomem
*addr)
static inline void writew(u16 value, volatile void __iomem *addr)
{
__io_bw();
- __raw_writew(cpu_to_le16(value), addr);
+ __raw_writew((u16 __force) cpu_to_le16(value), addr);
__io_aw();
}
#endif
@@ -222,7 +222,7 @@ static inline void writew(u16 value, volatile void __iomem
*addr)
static inline void writel(u32 value, volatile void __iomem *addr)
{
__io_bw();
- __raw_writel(__cpu_to_le32(value), addr);
+ __raw_writel((u32 __force) __cpu_to_le32(value), addr);
__io_aw();
}
#endif
@@ -474,7 +474,7 @@ static inline u16 _inw(unsigned long addr)
u16 val;
__io_pbr();
- val = __le16_to_cpu(__raw_readw(PCI_IOBASE + addr));
+ val = __le16_to_cpu((__le16 __force) __raw_readw(PCI_IOBASE + addr));
__io_par(val);
return val;
}
@@ -487,7 +487,7 @@ static inline u32 _inl(unsigned long addr)
u32 val;
__io_pbr();
- val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
+ val = __le32_to_cpu((__le32 __force) __raw_readl(PCI_IOBASE + addr));
__io_par(val);
return val;
}
@@ -508,7 +508,7 @@ static inline void _outb(u8 value, unsigned long addr)
static inline void _outw(u16 value, unsigned long addr)
{
__io_pbw();
- __raw_writew(cpu_to_le16(value), PCI_IOBASE + addr);
+ __raw_writew((u16 __force) cpu_to_le16(value), PCI_IOBASE + addr);
__io_paw();
}
#endif
@@ -518,7 +518,7 @@ static inline void _outw(u16 value, unsigned long addr)
static inline void _outl(u32 value, unsigned long addr)
{
__io_pbw();
- __raw_writel(cpu_to_le32(value), PCI_IOBASE + addr);
+ __raw_writel((u32 __force) cpu_to_le32(value), PCI_IOBASE + addr);
__io_paw();
}
#endif
--
2.26.2
Re: [PATCH v5 3/4] LSM: Define SELinux function to measure state and policy
On 7/29/20 11:47 PM, Lakshmi Ramasubramanian wrote: SELinux configuration and policy are some of the critical data for this security module that needs to be measured. This measurement can be used by an attestation service, for instance, to verify if the configuration and policies have been setup correctly and that they haven't been tampered with at runtime. Measure SELinux configuration, policy capabilities settings, and the loaded policy by calling the IMA hooks ima_measure_lsm_state() and ima_measure_lsm_policy() respectively. Sample measurement of SELinux state and hash of the policy: 10 e32e...5ac3 ima-buf sha256:86e8...4594 selinux-state-1595389364:287899386 696e697469616c697a65643d313b656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574776f726b5f706565725f636f6e74726f6c733d313b6f70656e5f7065726d733d313b657874656e6465645f736f636b65745f636c6173733d313b616c776179735f636865636b5f6e6574776f726b3d303b6367726f75705f7365636c6162656c3d313b6e6e705f6e6f737569645f7472616e736974696f6e3d313b67656e66735f7365636c6162656c5f73796d6c696e6b733d303 10 f4a7...9408 ima-ng sha256:8d1d...1834 selinux-policy-hash-1595389353:863934271 To verify the measurement check the following: Execute the following command to extract the measured data from the IMA log for SELinux configuration (selinux-state). grep -m 1 "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 6 | xxd -r -p The output should be the list of key-value pairs. For example, initialized=1;enabled=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0; To verify the measured data with the current SELinux state: => enabled should be set to 1 if /sys/fs/selinux folder exists, 0 otherwise For other entries, compare the integer value in the files => /sys/fs/selinux/enforce => /sys/fs/selinux/checkreqprot And, each of the policy capabilities files under => /sys/fs/selinux/policy_capabilities For selinux-policy-hash, the hash of SELinux policy is included in the IMA log entry. To verify the measured data with the current SELinux policy run the following commands and verify the output hash values match. sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1 grep -m 1 "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 4 Signed-off-by: Lakshmi Ramasubramanian Suggested-by: Stephen Smalley Reported-by: kernel test robot # error: implicit declaration of function 'vfree' Reported-by: kernel test robot # error: implicit declaration of function 'crypto_alloc_shash' Reported-by: kernel test robot # sparse: symbol 'security_read_selinux_policy' was not declared. Should it be static? Possibly I'm missing something but with these patches applied on top of next-integrity, and the following lines added to /etc/ima/ima-policy: measure func=LSM_STATE template=ima-buf measure func=LSM_POLICY I still don't get the selinux-state or selinux-policy-hash entries in the ascii_runtime_measurements file. No errors during loading of the ima policy as far as I can see.
Re: add file system helpers that take kernel pointers for the init code v4
On Mon, Aug 03, 2020 at 10:56:23AM -0400, Qian Cai wrote:
> On Tue, Jul 28, 2020 at 06:33:53PM +0200, Christoph Hellwig wrote:
> > Hi Al and Linus,
> >
> > currently a lot of the file system calls in the early in code (and the
> > devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot.
> > This is one of the few last remaining places we need to deal with to kill
> > off set_fs entirely, so this series adds new helpers that take kernel
> > pointers. These helpers are in init/ and marked __init and thus will
> > be discarded after bootup. A few also need to be duplicated in devtmpfs,
> > though unfortunately.
>
> Reverting this series from next-20200803 fixed the crash below on shutdown.
Please try this patch:
---
>From 6448eebe2fe7189cedc5136ab3464517956922b7 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Mon, 3 Aug 2020 15:56:18 +0200
Subject: init: fix init_dup
Don't allocate an unused fd for each call. Also drop the extra
reference from filp_open after the init_dup calls while we're at it.
Fixes: 36e96b411649 ("init: add an init_dup helper")
Reported-by Stephen Rothwell
Signed-off-by: Christoph Hellwig
---
fs/init.c | 2 +-
init/main.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/init.c b/fs/init.c
index 730e05acda2392..e9c320a48cf157 100644
--- a/fs/init.c
+++ b/fs/init.c
@@ -260,6 +260,6 @@ int __init init_dup(struct file *file)
fd = get_unused_fd_flags(0);
if (fd < 0)
return fd;
- fd_install(get_unused_fd_flags(0), get_file(file));
+ fd_install(fd, get_file(file));
return 0;
}
diff --git a/init/main.c b/init/main.c
index 089e21504b1fc1..9dae9c4f806bb9 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1470,6 +1470,7 @@ void __init console_on_rootfs(void)
init_dup(file);
init_dup(file);
init_dup(file);
+ fput(file);
}
static noinline void __init kernel_init_freeable(void)
--
2.27.0
Re: [PATCH v17 00/21] per memcg lru lock
On Thu 30-07-20 10:16:13, Alex Shi wrote: > > > 在 2020/7/30 上午2:06, Hugh Dickins 写道: > > On Wed, 29 Jul 2020, Alex Shi wrote: > >> > >> Is there any comments or suggestion for this patchset? > >> Any hints will be very appreciated. > > > > Alex: it is now v5.8-rc7, obviously too late for this patchset to make > > v5.9, so I'm currently concentrated on checking some patches headed for > > v5.9 (and some bugfix patches of my own that I don't get time to send): > > I'll get back to responding on lru_lock in a week or two's time. > > Hi Hugh, > > Thanks a lot for response! It's fine to wait longer. > But thing would be more efficient if review get concentrated... > I am still too new in mm area. I am sorry and owe you a review but it is hard to find time for that. This is a large change and the review will be really far from trivial. If this version is mostly stable then I would recommend not posting new versions and simply remind people you expect the review from by a targeted ping. -- Michal Hocko SUSE Labs
Re: [PATCH v7 05/19] mm: memcontrol: decouple reference counting from page accounting
On Mon 03-08-20 11:03:49, Johannes Weiner wrote: > On Mon, Aug 03, 2020 at 11:00:33AM +0200, Michal Hocko wrote: > > On Tue 23-06-20 10:40:23, Roman Gushchin wrote: > > > @@ -5456,7 +5460,10 @@ static int mem_cgroup_move_account(struct page > > > *page, > > >*/ > > > smp_mb(); > > > > > > - page->mem_cgroup = to; /* caller should have done css_get */ > > > + css_get(>css); > > > + css_put(>css); > > > + > > > + page->mem_cgroup = to; > > > > > > __unlock_page_memcg(from); > > > > What prevents from memcg to be released here? > > ->attach_task() and kill_css() are exclusive through the cgroup_mutex, > so the base ref cannot disappear from under us during this operation. OK, is this worth a comment? Reference counting before other operation on the object always makes me worried and those details are hidden elsewhere. Btw. with the follow up fix from Hugh Acked-by: Michal Hocko -- Michal Hocko SUSE Labs
Re: [PATCH v3] sched: Provide USF for the portable equipment.
On Mon, Aug 03, 2020 at 10:31:15PM +0800, Dongdong Yang wrote: > + /* > + * create a sched_usf in cpu_subsys: > + * /sys/devices/system/cpu/sched_usf/... I thought I asked you not to use a "raw" kobject, you are making this much harder than it has to be. Just use a normal struct device. Also you failed to document your new sysfs files in Documentation/ABI/ like is required :( Because of both of those things, this isn't ok as-is, sorry. greg k-h
KASAN: slab-out-of-bounds Read in hci_le_meta_evt
Hello, syzbot found the following issue on: HEAD commit:5a30a789 Merge tag 'x86-urgent-2020-08-02' of git://git.ke.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11cd21cc90 kernel config: https://syzkaller.appspot.com/x/.config?x=c0cfcf935bcc94d2 dashboard link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10fd450490 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14aa36a490 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+24ebd650e20bd263c...@syzkaller.appspotmail.com Bluetooth: hci0: unknown advertising packet type: 0x2b == BUG: KASAN: slab-out-of-bounds in hci_le_direct_adv_report_evt net/bluetooth/hci_event.c:5850 [inline] BUG: KASAN: slab-out-of-bounds in hci_le_meta_evt+0x380c/0x3eb0 net/bluetooth/hci_event.c:5914 Read of size 1 at addr 8880a727de0c by task kworker/u5:0/1535 CPU: 1 PID: 1535 Comm: kworker/u5:0 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: hci0 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 hci_le_direct_adv_report_evt net/bluetooth/hci_event.c:5850 [inline] hci_le_meta_evt+0x380c/0x3eb0 net/bluetooth/hci_event.c:5914 hci_event_packet+0x245a/0x86f5 net/bluetooth/hci_event.c:6167 hci_rx_work+0x22e/0xb10 net/bluetooth/hci_core.c:4705 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Allocated by task 6834: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0xae/0x550 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1083 [inline] bt_skb_alloc include/net/bluetooth/bluetooth.h:377 [inline] vhci_get_user drivers/bluetooth/hci_vhci.c:165 [inline] vhci_write+0xbd/0x450 drivers/bluetooth/hci_vhci.c:285 call_write_iter include/linux/fs.h:1908 [inline] new_sync_write+0x422/0x650 fs/read_write.c:503 vfs_write+0x59d/0x6b0 fs/read_write.c:578 ksys_write+0x12d/0x250 fs/read_write.c:631 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 6627: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455 __cache_free mm/slab.c:3426 [inline] kfree+0x103/0x2c0 mm/slab.c:3757 tomoyo_find_next_domain+0x81d/0x1f77 security/tomoyo/domain.c:885 tomoyo_bprm_check_security security/tomoyo/tomoyo.c:101 [inline] tomoyo_bprm_check_security+0x121/0x1a0 security/tomoyo/tomoyo.c:91 security_bprm_check+0x45/0xa0 security/security.c:840 search_binary_handler fs/exec.c:1737 [inline] exec_binprm fs/exec.c:1790 [inline] __do_execve_file+0x1577/0x2ee0 fs/exec.c:1926 do_execveat_common fs/exec.c:1980 [inline] do_execve+0x35/0x50 fs/exec.c:1997 __do_sys_execve fs/exec.c:2073 [inline] __se_sys_execve fs/exec.c:2068 [inline] __x64_sys_execve+0x7c/0xa0 fs/exec.c:2068 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at 8880a727dc00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 12 bytes to the right of 512-byte region [8880a727dc00, 8880a727de00) The buggy address belongs to the page: page:ea00029c9f40 refcount:1 mapcount:0 mapping: index:0x0 flags: 0xfffe000200(slab) raw: 00fffe000200 ea00029e3848 ea0002731b88 8880aa000a80 raw: 8880a727d000 00010004 page dumped because: kasan: bad access detected Memory state around the buggy address: 8880a727dd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8880a727dd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >8880a727de00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ 8880a727de80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 8880a727df00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc == --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track
Re: [PATCH v7 05/19] mm: memcontrol: decouple reference counting from page accounting
On Mon, Aug 03, 2020 at 11:00:33AM +0200, Michal Hocko wrote: > On Tue 23-06-20 10:40:23, Roman Gushchin wrote: > > @@ -5456,7 +5460,10 @@ static int mem_cgroup_move_account(struct page *page, > > */ > > smp_mb(); > > > > - page->mem_cgroup = to; /* caller should have done css_get */ > > + css_get(>css); > > + css_put(>css); > > + > > + page->mem_cgroup = to; > > > > __unlock_page_memcg(from); > > What prevents from memcg to be released here? ->attach_task() and kill_css() are exclusive through the cgroup_mutex, so the base ref cannot disappear from under us during this operation.
Re: [PATCH v6 12/12] x86/traps: Fix up invalid PASID
On 7/31/20 4:34 PM, Andy Lutomirski wrote: >> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD >> without a valid PASID value programmed. #GP error codes are 16 bits and all >> 16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The other >> choice was to reflect the error code in an MSR. ENQCMD can also cause #GP >> when loading from the source operand, so its not fully comprehending all >> the reasons. Rather than special case the ENQCMD, in future Intel may >> choose a different fault mechanism for such cases if recovery is needed on >> #GP. > Decoding the user instruction is ugly and sets a bad architecture > precedent, but we already do it in #GP for UMIP. So I'm unconvinced. I'll try to do one more bit of convincing. :) In the end, we need a way to figure out if the #GP was from a known "OK" source that we can fix up. You're right that we could fire up the instruction decoder to help answer that question. But, it (also) doesn't easily yield a perfect answer as to the source of the #GP, it always involves a user copy, and it's a larger code impact than what we've got. I think I went and looked at fixup_umip_exception(), and compared it to the alternative which is essentially just these three lines of code: > + /* > + * If the current task already has a valid PASID in the MSR, > + * the #GP must be for some other reason. > + */ > + if (current->has_valid_pasid) > + return false; ...> + /* Now the current task has a valid PASID in the MSR. */ > + current->has_valid_pasid = 1; and *I* was convinced that instruction decoding wasn't worth it. There's a lot of stuff that fixup_umip_exception() does which we don't have to duplicate, but it's going to be really hard to get it anywhere near as compact as what we've got. I guess Fenghua could go give instruction decoding a shot and see how it looks, though.
Re: [PATCH v6 08/22] bootconfig: init: Allow admin to use bootconfig for init command line
On Sat, 1 Aug 2020 22:33:18 -0400
Arvind Sankar wrote:
> On Fri, Feb 07, 2020 at 02:46:03PM -0500, Steven Rostedt wrote:
> >
> > diff --git a/init/main.c b/init/main.c
> > index 491f1cdb3105..113c8244e5f0 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -142,6 +142,15 @@ static char *extra_command_line;
> > /* Extra init arguments */
> > static char *extra_init_args;
> >
> > +#ifdef CONFIG_BOOT_CONFIG
> > +/* Is bootconfig on command line? */
> > +static bool bootconfig_found;
> > +static bool initargs_found;
> > +#else
> > +# define bootconfig_found false
> > +# define initargs_found false
> > +#endif
> > +
> > static char *execute_command;
> > static char *ramdisk_execute_command;
> >
> > @@ -336,17 +345,32 @@ u32 boot_config_checksum(unsigned char *p, u32 size)
> > return ret;
> > }
> >
> > +static int __init bootconfig_params(char *param, char *val,
> > + const char *unused, void *arg)
> > +{
> > + if (strcmp(param, "bootconfig") == 0) {
> > + bootconfig_found = true;
> > + } else if (strcmp(param, "--") == 0) {
> > + initargs_found = true;
> > + }
> > + return 0;
> > +}
> > +
>
> I came across this as I was poking around some of the command line
> parsing. AFAICT, initargs_found will never be set to true here, because
> parse_args handles "--" itself by immediately returning: it doesn't
> invoke the callback for it. So you'd instead have to check the return of
> parse_args("bootconfig"...) to detect the initargs_found case.
Oops, good catch!
Does this fixes the problem?
>From b078e8b02ad54aea74f8c3645fc11dd3a1cdc1e7 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu
Date: Mon, 3 Aug 2020 23:57:29 +0900
Subject: [PATCH] bootconfig: Fix to find the initargs correctly
Since the parse_args() stops parsing at '--', bootconfig_params()
will never get the '--' as param and initargs_found never be true.
In the result, if we pass some init arguments via the bootconfig,
those are always appended to the kernel command line with '--'
and user will see double '--'.
To fix this correctly, check the return value of parse_args()
and set initargs_found true if the return value is not an error
but a valid address.
Fixes: f61872bb58a1 ("bootconfig: Use parse_args() to find bootconfig and '--'")
Cc: sta...@vger.kernel.org
Reported-by: Arvind Sankar
Suggested-by: Arvind Sankar
Signed-off-by: Masami Hiramatsu
---
init/main.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/init/main.c b/init/main.c
index 0ead83e86b5a..627f9230dbe8 100644
--- a/init/main.c
+++ b/init/main.c
@@ -387,8 +387,6 @@ static int __init bootconfig_params(char *param, char *val,
{
if (strcmp(param, "bootconfig") == 0) {
bootconfig_found = true;
- } else if (strcmp(param, "--") == 0) {
- initargs_found = true;
}
return 0;
}
@@ -399,19 +397,23 @@ static void __init setup_boot_config(const char *cmdline)
const char *msg;
int pos;
u32 size, csum;
- char *data, *copy;
+ char *data, *copy, *err;
int ret;
/* Cut out the bootconfig data even if we have no bootconfig option */
data = get_boot_config_from_initrd(, );
strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
- parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL,
- bootconfig_params);
+ err = parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL,
+bootconfig_params);
- if (!bootconfig_found)
+ if (IS_ERR(err) || !bootconfig_found)
return;
+ /* parse_args() stops at '--' and returns an address */
+ if (!IS_ERR(err) && err)
+ initargs_found = true;
+
if (!data) {
pr_err("'bootconfig' found on command line, but no bootconfig
found\n");
return;
--
2.25.1
Re: [RFC PATCH 0/8] KVM: x86/mmu: Introduce pinned SPTEs framework
On Sun, Aug 02, 2020 at 10:00:13PM -0500, Eric van Tassell wrote:
> Sean,
> What commit did you base your series on?
Gah, sorry.
kvm/queue, commit 9c2475f3e46a1 ("KVM: Using macros instead of magic values").
Re: add file system helpers that take kernel pointers for the init code v4
On Tue, Jul 28, 2020 at 06:33:53PM +0200, Christoph Hellwig wrote: > Hi Al and Linus, > > currently a lot of the file system calls in the early in code (and the > devtmpfs kthread) rely on the implicit set_fs(KERNEL_DS) during boot. > This is one of the few last remaining places we need to deal with to kill > off set_fs entirely, so this series adds new helpers that take kernel > pointers. These helpers are in init/ and marked __init and thus will > be discarded after bootup. A few also need to be duplicated in devtmpfs, > though unfortunately. Reverting this series from next-20200803 fixed the crash below on shutdown. [ 7303.287890][T1] systemd-shutdown[1]: All loop devices detached. [ 7303.287930][T1] systemd-shutdown[1]: Detaching DM devices. [ 7303.441674][T1] printk: shutdown: 9 output lines suppressed due to ratelimiting [ 7303.443999][T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0100 [ 7303.444027][T1] CPU: 120 PID: 1 Comm: shutdown Not tainted 5.8.0-next-20200803 #2 [ 7303.444053][T1] Call Trace: [ 7303.444069][T1] [c00015d27b70] [c06f3778] dump_stack+0xfc/0x174 (unreliable) [ 7303.444103][T1] [c00015d27bc0] [c00c9328] panic+0x214/0x4ac [ 7303.444140][T1] [c00015d27c60] [c00d4d28] do_exit+0xda8/0xee0 [ 7303.444178][T1] [c00015d27d60] [c00d4f1c] do_group_exit+0x5c/0xd0 list_empty at include/linux/list.h:282 (inlined by) thread_group_empty at include/linux/sched/signal.h:671 (inlined by) do_group_exit at kernel/exit.c:888 [ 7303.444205][T1] [c00015d27da0] [c00d4fac] sys_exit_group+0x1c/0x20 sys_exit_group at kernel/exit.c:914 [ 7303.444234][T1] [c00015d27dc0] [c002c628] system_call_exception+0xf8/0x1d0 [ 7303.444262][T1] [c00015d27e20] [c000d0a8] system_call_common+0xe8/0x218 [ 7304.936912][T1] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0100 ]--- > > The series sits on top of my previous > > "decruft the early init / initrd / initramfs code v2" > > series. > > > Git tree: > > git://git.infradead.org/users/hch/misc.git init_path > > Gitweb: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/init_path > > > Changes since v3: > - rename fs/for_init.c to fs/init.c > - document the purpose of the routines in fs/init.c with a comment > - don't mark devtmpfs __init as that will cause it to get overwritten >by initmem poisoning > - add an init_dup helper to make Al more happy than with the version >commit to the "decruft the early init / initrd / initramfs code v2" >series > > Changes since v2: > - move to fs/for_init.c > - reuse the init routines in devtmpfs after refactoring devtmpfsd >(and thus the broken error handling in the previous version) > - actually use kern_path in a place where user_path_at sneaked back in > > Changes since v1: > - avoid most core VFS changes > - renamed the functions and move them to init/ and devtmpfs > - drop a bunch of cleanups that can be submitted independently now > > > Diffstat:
[GIT PULL] scheduler updates for v5.9
Linus, Please pull the latest sched/core git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-core-2020-08-03 # HEAD: 949bcb8135a96a6923e676646bd29cbe69e8350f sched/doc: Factorize bits between sched-energy.rst & sched-capacity.rst The main changes in this cycle were: - Improve uclamp performance by using a static key for the fast path - Add the "sched_util_clamp_min_rt_default" sysctl, to optimize for better power efficiency of RT tasks on battery powered devices. (The default is to maximize performance & reduce RT latencies.) - Improve utime and stime tracking accuracy, which had a fixed boundary of error, which created larger and larger relative errors as the values become larger. This is now replaced with more precise arithmetics, using the new mul_u64_u64_div_u64() helper in math64.h. - Improve the deadline scheduler, such as making it capacity aware - Improve frequency-invariant scheduling - Misc cleanups in energy/power aware scheduling - Add sched_update_nr_running tracepoint to track changes to nr_running - Documentation additions and updates - Misc cleanups and smaller fixes Thanks, Ingo --> Alex Belits (3): lib: Restrict cpumask_local_spread to houskeeping CPUs PCI: Restrict probe functions to housekeeping CPUs net: Restrict receive packets queuing to housekeeping CPUs Christophe JAILLET (1): sched/deadline: Fix a typo in a comment Dietmar Eggemann (6): sched/pelt: Remove redundant cap_scale() definition sched/core: Remove redundant 'preempt' param from sched_class->yield_to_task() sched/idle,stop: Remove .get_rr_interval from sched_class sched/fair: Remove unused 'sd' parameter from scale_rt_capacity() sched/deadline: Optimize dl_bw_cpus() sched/deadline: Add dl_bw_capacity() Giovanni Gherdovich (3): x86, sched: check for counters overflow in frequency invariant accounting x86, sched: Bail out of frequency invariance if turbo frequency is unknown x86, sched: Bail out of frequency invariance if turbo_freq/base_freq gives 0 Kirill Tkhai (1): sched: Micro optimization in pick_next_task() and in check_preempt_curr() Luca Abeni (3): sched/deadline: Improve admission control for asymmetric CPU capacities sched/deadline: Make DL capacity-aware sched/deadline: Implement fallback mechanism for !fit case Marcelo Tosatti (2): kthread: Switch to cpu_possible_mask isolcpus: Affine unbound kernel threads to housekeeping cpus Miaohe Lin (1): sched: Remove duplicated tick_nohz_full_enabled() check Muchun Song (1): smp: Fix a potential usage of stale nr_cpus Oleg Nesterov (1): sched/cputime: Improve cputime_adjust() Paul Gortmaker (1): sched: nohz: stop passing around unused "ticks" parameter. Peng Liu (1): sched: correct SD_flags returned by tl->sd_flags() Peng Wang (1): sched/fair: Optimize dequeue_task_fair() Peter Puhov (1): sched/fair: update_pick_idlest() Select group with lowest group_util when idle_cpus are equal Peter Zijlstra (3): sched/deadline: Impose global limits on sched_attr::sched_period sched, vmlinux.lds: Increase STRUCT_ALIGNMENT to 64 bytes for GCC-4.9 sched: Better document ttwu() Phil Auld (1): sched: Add a tracepoint to track rq->nr_running Qais Yousef (5): sched/uclamp: Fix initialization of struct uclamp_rq sched/uclamp: Protect uclamp fast path code with static key sched/uclamp: Fix a deadlock when enabling uclamp static key sched/uclamp: Add a new sysctl to control RT default boost value Documentation/sysctl: Document uclamp sysctl knobs Qinglang Miao (1): sched/uclamp: Remove unnecessary mutex_init() Randy Dunlap (2): linux/sched/mm.h: drop duplicated words in comments trace/events/sched.h: fix duplicated word Sebastian Andrzej Siewior (1): sched/core: Remove mmdrop() definition Steven Rostedt (VMware) (3): sched: Force the address order of each sched class descriptor sched: Have sched_class_highest define by vmlinux.lds.h sched: Remove struct sched_class::next field Suren Baghdasaryan (1): psi: eliminate kthread_worker from psi trigger scheduling mechanism Valentin Schneider (7): arch_topology, sched/core: Cleanup thermal pressure definition sched: Cleanup SCHED_THERMAL_PRESSURE kconfig entry arm, arm64: Select CONFIG_SCHED_THERMAL_PRESSURE arm, arm64: Fix selection of CONFIG_SCHED_THERMAL_PRESSURE sched: Document arch_scale_*_capacity() sched/doc: Document capacity aware scheduling sched/doc: Factorize bits between sched-energy.rst & sched-capacity.rst Vincent Donnefort (1): sched/debug: Add new tracepoints to track util_est Vincent Guittot (2): sched/fair: Fix NOHZ next idle balance sched/pelt: Cleanup PELT divider 王文虎 (1): sched: Fix a
Re: VAIO EEPROM support in at24
Hi Wolfram, Sorry, somehow this message of yours slipped through the cracks. On Tue, 17 Mar 2020 16:01:42 +0100, Wolfram Sang wrote: > > And we could introduce a new macro called AT24_CHIP_DATA_MASKED that > > would automacially set the AT24_FLAG_MASKED_RANGE flag and take > > another argument that would contain the address and size of the masked > > register range (we'd put it into the "masked" resource)? > > I am all for generic solutions. One thing to consider here is that we > need a generic way to detect the various types. I guess it will > always(?) be decided on some memory locations having specific values? In the case of Sony VAIO EEPROMs, they can be identified by the combination of the EEPROM's I2C address (always 0x57) and the value of the 4 bytes at register address 0x80 (would read either "PCG-" or "VGN-"). If that's not considered robust enough then I suppose we could improve it further by checking that the DMI vendor is "Sony Corporation". That being said, automatic detection was not even on my mind originally. If we had a specific type defined for these EEPROMs, as we do with SPD EEPROMs, then one could easily instantiate them from user-space using the "new_device" sysfs attribute at the I2C bus level. This is exactly how we have been doing it for SPD EEPROMs until recently, as you have just merged my patch set to automate this recently. And even then, it's still limited to x86 and specific systems at the moment. Incidentally, instantiating these Sony VAIO EEPROMs automatically would share some code with that patch set, so that might be a good sign that it's the right time to look into that. I may give a try to Bartosz's idea to make it somewhat generic if everybody agrees that's the way to go. I'm not deeply familiar with the at24 driver so I'm not sure how to do it, but hopefully it will get clearer as I progress. -- Jean Delvare SUSE L3 Support
[PATCH v2 1/2] dt-bindings: leds: pca955x: Add IBM implementation compatible string
IBM created an implementation of the PCA9552 on a PIC16F microcontroller. Document the new compatible string for this device. Signed-off-by: Eddie James --- Documentation/devicetree/bindings/leds/leds-pca955x.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt index 7a5830f8d5ab..817f460f3a72 100644 --- a/Documentation/devicetree/bindings/leds/leds-pca955x.txt +++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt @@ -9,6 +9,7 @@ Required properties: "nxp,pca9550" "nxp,pca9551" "nxp,pca9552" + "ibm,pca9552" "nxp,pca9553" - #address-cells: must be 1 - #size-cells: must be 0 -- 2.24.0
Re: [PATCH] kprobes: fix NULL pointer dereference at kprobe_ftrace_handler
On Mon, 3 Aug 2020 13:46:25 +0800
Muchun Song wrote:
> Ping guys. Any comments or suggestions?
>
> On Tue, Jul 28, 2020 at 2:45 PM Muchun Song wrote:
> >
> > We found a case of kernel panic on our server. The stack trace is as
> > follows(omit some irrelevant information):
> >
> > BUG: kernel NULL pointer dereference, address: 0080
> > RIP: 0010:kprobe_ftrace_handler+0x5e/0xe0
> > RSP: 0018:b512c6550998 EFLAGS: 00010282
> > RAX: RBX: 8e9d16eea018 RCX:
> > RDX: be1179c0 RSI: c0535564 RDI: c0534ec0
> > RBP: c0534ec1 R08: 8e9d1bbb0f00 R09: 0004
> > R10: R11: R12:
> > R13: 8e9d1f797060 R14: bacc R15: 8e9ce13eca00
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 0080 CR3: 0008453d0005 CR4: 003606e0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> >
> >ftrace_ops_assist_func+0x56/0xe0
> >ftrace_call+0x5/0x34
> >tcpa_statistic_send+0x5/0x130 [ttcp_engine]
> >
> > The tcpa_statistic_send is the function being kprobed. After analysis,
> > the root cause is that the fourth parameter regs of kprobe_ftrace_handler
> > is NULL. Why regs is NULL? We use the crash tool to analyze the kdump.
> >
> > crash> dis tcpa_statistic_send -r
> > : callq 0xbd8018c0
> >
> > The tcpa_statistic_send calls ftrace_caller instead of ftrace_regs_caller.
> > So it is reasonable that the fourth parameter regs of kprobe_ftrace_handler
> > is NULL. In theory, we should call the ftrace_regs_caller instead of the
> > ftrace_caller. After in-depth analysis, we found a reproducible path.
> >
> > Writing a simple kernel module which starts a periodic timer. The
> > timer's handler is named 'kprobe_test_timer_handler'. The module
> > name is kprobe_test.ko.
> >
> > 1) insmod kprobe_test.ko
> > 2) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}'
> > 3) echo 0 > /proc/sys/kernel/ftrace_enabled
> > 4) rmmod kprobe_test
> > 5) stop step 2) kprobe
> > 6) insmod kprobe_test.ko
> > 7) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}'
> >
> > We mark the kprobe as GONE but not disarm the kprobe in the step 4).
> > The step 5) also do not disarm the kprobe when unregister kprobe. So
> > we do not remove the ip from the filter. In this case, when the module
> > loads again in the step 6), we will replace the code to ftrace_caller
> > via the ftrace_module_enable(). When we register kprobe again, we will
> > not replace ftrace_caller to ftrace_regs_caller because the ftrace is
> > disabled in the step 3). So the step 7) will trigger kernel panic. Fix
> > this problem by disarming the kprobe when the module is going away.
> >
Nice catch!
Acked-by: Masami Hiramatsu
Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
Cc: sta...@vger.kernel.org
Thank you!
> > Signed-off-by: Muchun Song
> > Co-developed-by: Chengming Zhou
> > Signed-off-by: Chengming Zhou
> > ---
> > kernel/kprobes.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 146c648eb943..503add629599 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -2148,6 +2148,13 @@ static void kill_kprobe(struct kprobe *p)
> > * the original probed function (which will be freed soon) any more.
> > */
> > arch_remove_kprobe(p);
> > +
> > + /*
> > +* The module is going away. We should disarm the kprobe which
> > +* is using ftrace.
> > +*/
> > + if (kprobe_ftrace(p))
> > + disarm_kprobe_ftrace(p);
> > }
> >
> > /* Disable one kprobe */
> > --
> > 2.11.0
> >
>
>
> --
> Yours,
> Muchun
--
Masami Hiramatsu
[PATCH v2 2/2] leds: pca955x: Add an IBM software implementation of the PCA9552 chip
IBM created an implementation of the PCA9552 on a PIC16F
microcontroller. The I2C device addresses are different from the
hardware PCA9552, so add a new compatible string and associated
platform data to be able to probe this device.
Signed-off-by: Eddie James
Reviewed-by: Vishwanatha Subbanna
---
drivers/leds/leds-pca955x.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/leds/leds-pca955x.c b/drivers/leds/leds-pca955x.c
index 131f8e922ade..7087ca4592fc 100644
--- a/drivers/leds/leds-pca955x.c
+++ b/drivers/leds/leds-pca955x.c
@@ -65,6 +65,7 @@ enum pca955x_type {
pca9550,
pca9551,
pca9552,
+ ibm_pca9552,
pca9553,
};
@@ -90,6 +91,11 @@ static struct pca955x_chipdef pca955x_chipdefs[] = {
.slv_addr = /* 1100xxx */ 0x60,
.slv_addr_shift = 3,
},
+ [ibm_pca9552] = {
+ .bits = 16,
+ .slv_addr = /* 0110xxx */ 0x30,
+ .slv_addr_shift = 3,
+ },
[pca9553] = {
.bits = 4,
.slv_addr = /* 110001x */ 0x62,
@@ -101,6 +107,7 @@ static const struct i2c_device_id pca955x_id[] = {
{ "pca9550", pca9550 },
{ "pca9551", pca9551 },
{ "pca9552", pca9552 },
+ { "ibm-pca9552", ibm_pca9552 },
{ "pca9553", pca9553 },
{ }
};
@@ -412,6 +419,7 @@ static const struct of_device_id of_pca955x_match[] = {
{ .compatible = "nxp,pca9550", .data = (void *)pca9550 },
{ .compatible = "nxp,pca9551", .data = (void *)pca9551 },
{ .compatible = "nxp,pca9552", .data = (void *)pca9552 },
+ { .compatible = "ibm,pca9552", .data = (void *)ibm_pca9552 },
{ .compatible = "nxp,pca9553", .data = (void *)pca9553 },
{},
};
--
2.24.0
[PATCH v2 0/2] leds: pca955x: Add IBM software implemenation of the PCA9552 chip
IBM created an implementation of the PCA9552 on a PIC16F microcontroller. The I2C device addresses are different from the hardware PCA9552, so add a new compatible string and associated platform data to be able to probe this device, and document the new string. Changes since v1: - Switch the vendor part of the compatible string to ibm - Change the enum in the driver to be ibm_ Eddie James (2): dt-bindings: leds: pca955x: Add IBM implementation compatible string leds: pca955x: Add an IBM software implementation of the PCA9552 chip Documentation/devicetree/bindings/leds/leds-pca955x.txt | 1 + drivers/leds/leds-pca955x.c | 8 2 files changed, 9 insertions(+) -- 2.24.0
[PATCH 1/2] fs: Add fd_install file operation
Provides a per process hook for the acquisition of file descriptors,
despite the method used to obtain the descriptor.
Signed-off-by: Kalesh Singh
---
Documentation/filesystems/vfs.rst | 5 +
fs/file.c | 3 +++
include/linux/fs.h| 1 +
3 files changed, 9 insertions(+)
diff --git a/Documentation/filesystems/vfs.rst
b/Documentation/filesystems/vfs.rst
index ed17771c212b..95b30142c8d9 100644
--- a/Documentation/filesystems/vfs.rst
+++ b/Documentation/filesystems/vfs.rst
@@ -1123,6 +1123,11 @@ otherwise noted.
``fadvise``
possibly called by the fadvise64() system call.
+``fd_install``
+ called by the VFS when a file descriptor is installed in the
+ process's file descriptor table, regardless how the file descriptor
+ was acquired -- be it via the open syscall, received over IPC, etc.
+
Note that the file operations are implemented by the specific
filesystem in which the inode resides. When opening a device node
(character or block special) most filesystems will call special
diff --git a/fs/file.c b/fs/file.c
index abb8b7081d7a..f5db8622b851 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -616,6 +616,9 @@ void __fd_install(struct files_struct *files, unsigned int
fd,
void fd_install(unsigned int fd, struct file *file)
{
__fd_install(current->files, fd, file);
+
+ if (file->f_op->fd_install)
+ file->f_op->fd_install(fd, file);
}
EXPORT_SYMBOL(fd_install);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index f5abba86107d..b976fbe8c902 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1864,6 +1864,7 @@ struct file_operations {
struct file *file_out, loff_t pos_out,
loff_t len, unsigned int remap_flags);
int (*fadvise)(struct file *, loff_t, loff_t, int);
+ void (*fd_install)(int, struct file *);
} __randomize_layout;
struct inode_operations {
--
2.28.0.163.g6104cc2f0b6-goog
[PATCH 2/2] dmabuf/tracing: Add dma-buf trace events
Being able to analyze the per process usage of shared
dma buffers prodives useful insights in situations where
the system is experiencing high memory pressure. This would
allow us to see exactly which processes are holding references
to the shared buffer.
Signed-off-by: Kalesh Singh
---
drivers/dma-buf/dma-buf.c | 29 +
include/trace/events/dma_buf.h | 77 ++
2 files changed, 106 insertions(+)
create mode 100644 include/trace/events/dma_buf.h
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 1ca609f66fdf..1729191ac9ca 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -29,6 +29,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include
+
static inline int is_dma_buf_file(struct file *);
struct dma_buf_list {
@@ -110,6 +113,15 @@ static struct file_system_type dma_buf_fs_type = {
.kill_sb = kill_anon_super,
};
+static void dma_buf_vma_close(struct vm_area_struct *area)
+{
+ trace_dma_buf_map_ref_dec(current, area->vm_file);
+}
+
+static const struct vm_operations_struct dma_buf_vm_ops = {
+ .close = dma_buf_vma_close,
+};
+
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
{
struct dma_buf *dmabuf;
@@ -128,6 +140,9 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
+ trace_dma_buf_map_ref_inc(current, file);
+ vma->vm_ops = _buf_vm_ops;
+
return dmabuf->ops->mmap(dmabuf, vma);
}
@@ -410,6 +425,17 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct
file *file)
spin_unlock(>name_lock);
}
+static int dma_buf_flush(struct file *filp, fl_owner_t id)
+{
+ trace_dma_buf_fd_ref_dec(current, filp);
+ return 0;
+}
+
+static void dma_buf_fd_install(int fd, struct file *filp)
+{
+ trace_dma_buf_fd_ref_inc(current, filp);
+}
+
static const struct file_operations dma_buf_fops = {
.mmap = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
@@ -417,6 +443,8 @@ static const struct file_operations dma_buf_fops = {
.unlocked_ioctl = dma_buf_ioctl,
.compat_ioctl = compat_ptr_ioctl,
.show_fdinfo= dma_buf_show_fdinfo,
+ .fd_install = dma_buf_fd_install,
+ .flush = dma_buf_flush,
};
/*
@@ -1177,6 +1205,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
if (oldfile)
fput(oldfile);
}
+
return ret;
}
diff --git a/include/trace/events/dma_buf.h b/include/trace/events/dma_buf.h
new file mode 100644
index ..05af336cd849
--- /dev/null
+++ b/include/trace/events/dma_buf.h
@@ -0,0 +1,77 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM dma_buf
+
+#if !defined(_TRACE_DMA_BUF_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_DMA_BUF_H
+
+#include
+#include
+#include
+
+#define UNKNOWN ""
+
+#ifdef CREATE_TRACE_POINTS
+static inline struct dma_buf *dma_buffer(struct file *filp)
+{
+ return filp->private_data;
+}
+#endif
+
+DECLARE_EVENT_CLASS(dma_buf_ref_template,
+
+ TP_PROTO(struct task_struct *task, struct file *filp),
+
+ TP_ARGS(task, filp),
+
+ TP_STRUCT__entry(
+ __field(u32, tgid)
+ __field(u32, pid)
+ __field(u64, size)
+ __field(s64, count)
+ __string(exp_name, dma_buffer(filp)->exp_name)
+ __string(name, dma_buffer(filp)->name ? dma_buffer(filp)->name
: UNKNOWN)
+ __field(u64, i_ino)
+ ),
+
+ TP_fast_assign(
+ __entry->tgid = task->tgid;
+ __entry->pid = task->pid;
+ __entry->size = dma_buffer(filp)->size;
+ __entry->count = file_count(filp);
+ __assign_str(exp_name, dma_buffer(filp)->exp_name);
+ __assign_str(name, dma_buffer(filp)->name ?
dma_buffer(filp)->name : UNKNOWN);
+ __entry->i_ino = filp->f_inode->i_ino;
+ ),
+
+ TP_printk("tgid=%u pid=%u size=%llu count=%lld exp_name=%s name=%s
i_ino=%llu",
+ __entry->tgid,
+ __entry->pid,
+ __entry->size,
+ __entry->count,
+ __get_str(exp_name),
+ __get_str(name),
+ __entry->i_ino
+ )
+);
+
+DEFINE_EVENT(dma_buf_ref_template, dma_buf_fd_ref_inc,
+ TP_PROTO(struct task_struct *task, struct file *filp),
+ TP_ARGS(task, filp));
+
+DEFINE_EVENT(dma_buf_ref_template, dma_buf_fd_ref_dec,
+ TP_PROTO(struct task_struct *task, struct file *filp),
+ TP_ARGS(task, filp));
+
+DEFINE_EVENT(dma_buf_ref_template, dma_buf_map_ref_inc,
+ TP_PROTO(struct task_struct *task, struct file *filp),
+ TP_ARGS(task, filp));
+
[PATCH 0/2] Per process tracking of dma buffers
Since debugfs doesn't have stable abi. This patch series enables per process accounting of dma buffers using trace events. Kalesh Singh (2): fs: Add fd_install file operation dmabuf/tracing: Add dma-buf trace events Documentation/filesystems/vfs.rst | 5 ++ drivers/dma-buf/dma-buf.c | 29 fs/file.c | 3 ++ include/linux/fs.h| 1 + include/trace/events/dma_buf.h| 77 +++ 5 files changed, 115 insertions(+) create mode 100644 include/trace/events/dma_buf.h -- 2.28.0.163.g6104cc2f0b6-goog
Re: [PATCH 4/5] PCI: aardvark: Implement driver 'remove' function and allow to build it as module
On Wednesday 29 July 2020 12:48:09 Rob Herring wrote:
> On Wed, Jul 15, 2020 at 04:25:56PM +0200, Marek Behún wrote:
> > From: Pali Rohár
> >
> > Providing driver's 'remove' function allows kernel to bind and unbind
> > devices
> > from aardvark driver. It also allows to build aardvark driver as a module.
> >
> > Compiling aardvark as a module simplifies development and debugging of
> > this driver as it can be reloaded at runtime without the need to reboot
> > to new kernel.
> >
> > Signed-off-by: Pali Rohár
> > Reviewed-by: Marek Behún
> > ---
> > drivers/pci/controller/Kconfig| 2 +-
> > drivers/pci/controller/pci-aardvark.c | 25 ++---
> > 2 files changed, 23 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> > index adddf21fa381..f9da5ff2c517 100644
> > --- a/drivers/pci/controller/Kconfig
> > +++ b/drivers/pci/controller/Kconfig
> > @@ -12,7 +12,7 @@ config PCI_MVEBU
> > select PCI_BRIDGE_EMUL
> >
> > config PCI_AARDVARK
> > - bool "Aardvark PCIe controller"
> > + tristate "Aardvark PCIe controller"
> > depends on (ARCH_MVEBU && ARM64) || COMPILE_TEST
> > depends on OF
> > depends on PCI_MSI_IRQ_DOMAIN
> > diff --git a/drivers/pci/controller/pci-aardvark.c
> > b/drivers/pci/controller/pci-aardvark.c
> > index d5f58684d962..0a5aa6d77f5d 100644
> > --- a/drivers/pci/controller/pci-aardvark.c
> > +++ b/drivers/pci/controller/pci-aardvark.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1114,6 +1115,7 @@ static int advk_pcie_probe(struct platform_device
> > *pdev)
> >
> > pcie = pci_host_bridge_priv(bridge);
> > pcie->pdev = pdev;
> > + platform_set_drvdata(pdev, pcie);
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pcie->base = devm_ioremap_resource(dev, res);
> > @@ -1204,18 +1206,35 @@ static int advk_pcie_probe(struct platform_device
> > *pdev)
> > return 0;
> > }
> >
> > +static int advk_pcie_remove(struct platform_device *pdev)
> > +{
> > + struct advk_pcie *pcie = platform_get_drvdata(pdev);
> > + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> > +
> > + pci_stop_root_bus(bridge->bus);
> > + pci_remove_root_bus(bridge->bus);
>
> Based on pci_host_common_remove() implementation, doesn't this need a
> lock around it (pci_lock_rescan_remove)?
Well, I'm not sure. I looked into other pci drivers and none of
following drivers pci-tegra.c, pcie-altera.c, pcie-brcmstb.c,
pcie-iproc.c, pcie-mediatek.c, pcie-rockchip-host.c calls
pci_lock_rescan_remove() and pci_unlock_rescan_remove().
Only pci-host-common.c and pci-hyperv.c protect pci_stop_root_bus() and
pci_remove_root_bus() by locks.
> We should probably have a common function (say pci_bridge_remove) to
> implement this. You could use pci_host_common_remove(), but you'd have
> to adjust drvdata.
Ok, I agree that some common function could be useful as the same code
(pci_stop_root_bus(); pci_remove_root_bus();) is called in more pci
drivers.
But first we need to know if locks are required or not.
> > +
> > + advk_pcie_remove_msi_irq_domain(pcie);
> > + advk_pcie_remove_irq_domain(pcie);
> > +
> > + return 0;
> > +}
> > +
> > static const struct of_device_id advk_pcie_of_match_table[] = {
> > { .compatible = "marvell,armada-3700-pcie", },
> > {},
> > };
> > +MODULE_DEVICE_TABLE(of, advk_pcie_of_match_table);
> >
> > static struct platform_driver advk_pcie_driver = {
> > .driver = {
> > .name = "advk-pcie",
> > .of_match_table = advk_pcie_of_match_table,
> > - /* Driver unloading/unbinding currently not supported */
> > - .suppress_bind_attrs = true,
> > },
> > .probe = advk_pcie_probe,
> > + .remove = advk_pcie_remove,
> > };
> > -builtin_platform_driver(advk_pcie_driver);
> > +module_platform_driver(advk_pcie_driver);
> > +
> > +MODULE_DESCRIPTION("Aardvark PCIe controller");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 2.26.2
> >
Re: [PATCH] habanalabs: Fix memory corruption in debugfs
On Mon, Aug 3, 2020 at 5:36 PM Dan Carpenter wrote:
>
> This has to be a long instead of a u32 because we write a long value.
> On 64 bit systems, this will cause memory corruption.
>
> Fixes: c216477363a3 ("habanalabs: add debugfs support")
> Signed-off-by: Dan Carpenter
> ---
> drivers/misc/habanalabs/common/debugfs.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/misc/habanalabs/common/debugfs.c
> b/drivers/misc/habanalabs/common/debugfs.c
> index 71cfe1b6fafc..ecd37b427480 100644
> --- a/drivers/misc/habanalabs/common/debugfs.c
> +++ b/drivers/misc/habanalabs/common/debugfs.c
> @@ -19,7 +19,7 @@
> static struct dentry *hl_debug_root;
>
> static int hl_debugfs_i2c_read(struct hl_device *hdev, u8 i2c_bus, u8
> i2c_addr,
> - u8 i2c_reg, u32 *val)
> + u8 i2c_reg, long *val)
> {
> struct armcp_packet pkt;
> int rc;
> @@ -36,7 +36,7 @@ static int hl_debugfs_i2c_read(struct hl_device *hdev, u8
> i2c_bus, u8 i2c_addr,
> pkt.i2c_reg = i2c_reg;
>
> rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) ,
> sizeof(pkt),
> - 0, (long *) val);
> + 0, val);
>
> if (rc)
> dev_err(hdev->dev, "Failed to read from I2C, error %d\n", rc);
> @@ -827,7 +827,7 @@ static ssize_t hl_i2c_data_read(struct file *f, char
> __user *buf,
> struct hl_dbg_device_entry *entry = file_inode(f)->i_private;
> struct hl_device *hdev = entry->hdev;
> char tmp_buf[32];
> - u32 val;
> + long val;
> ssize_t rc;
>
> if (*ppos)
> @@ -842,7 +842,7 @@ static ssize_t hl_i2c_data_read(struct file *f, char
> __user *buf,
> return rc;
> }
>
> - sprintf(tmp_buf, "0x%02x\n", val);
> + sprintf(tmp_buf, "0x%02lx\n", val);
> rc = simple_read_from_buffer(buf, count, ppos, tmp_buf,
> strlen(tmp_buf));
>
> --
> 2.27.0
>
This patch is:
Reviewed-by: Oded Gabbay
Applied to -fixes,
Thanks!
Oded
Re: [PATCH v4 0/7] Support inhibiting input devices
Hi Dmitry, W dniu 12.06.2020 o 10:17, Hans de Goede pisze: Hi, On 6/8/20 1:22 PM, Andrzej Pietrasiewicz wrote: This is a quick respin of v3, with just two small changes, please see the changelog below. Userspace might want to implement a policy to temporarily disregard input from certain devices. v3..v4: - updated the comment in input_open_device() (Hans) - used more straightforward locking pattern in adc/exynos (Michał) v2..v3: - ignored autorepeat events in input_get_disposition() if a key is not pressed (Hans) - dropped inhibit()/uninhibit() driver callbacks (Hans) - split ACPI button patch into taking the lock and using the helper (Rafael) - dropped the elan_i2c conversion - fixed typos in exynos adc v1..v2: - added input_device_enabled() helper and used it in drivers (Dmitry) - the fact of open() and close() being called in inhibit/uninhibit paths has been emphasized in the commit message of PATCH 6/7 (Dmitry) The entire series looks good to me: Acked-by: Hans de Goede What are the prospects of this series being merged? Regards, Andrzej
Re: [PATCH] ALSA: usb-audio: Add support for Lenovo ThinkStation P620
On Mon, 03 Aug 2020 16:26:08 +0200, Kai-Heng Feng wrote: > > Lenovo ThinkStation P620 is like other TRX40 boards, is equipped with > two USB audio cards. > > USB device (17aa:104d) provides functionality for Internal Speaker and > Front Headset. It's UAC v2, so it supports insertion control (jack > detection). However, when trying to get the connector status of the > speaker, an error occurs: > [5.787405] usb 3-1: cannot get connectors status: req = 0x81, wValue = > 0x200, wIndex = 0x1000, type = 0 > > Since the insertion control works perfectly for the headset, the error > for speaker is probably casued by connecting internally. So let's relax > the error for a bit if it's a speaker, and always reports it's connected. > > USB device (17aa:1046) is for rear Line-in, Line-out and Microphone. > The insertion control works for all three jacks. However, there's an > Function Unit that doesn't work: > [5.905415] usb 3-6: cannot get ctl value: req = 0x83, wValue = 0xc00, > wIndex = 0x1300, type = 4 > [5.905418] usb 3-6: 19:0: cannot get min/max values for control 12 (id 19) > > So turn off the FU to avoid the error. > > Also, add specific card name for both devices, so userspace can easily > indentify both cards. > > Signed-off-by: Kai-Heng Feng Thanks, applied. Takashi
KASAN: slab-out-of-bounds Read in usb_destroy_configuration
Hello, syzbot found the following issue on: HEAD commit:e3ee0e74 usb: common: usb-conn-gpio: Register charger git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing console output: https://syzkaller.appspot.com/x/log.txt?x=175a3e0c90 kernel config: https://syzkaller.appspot.com/x/.config?x=fb6677a3d4f11788 dashboard link: https://syzkaller.appspot.com/bug?extid=aafdc32825a345214a76 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+aafdc32825a345214...@syzkaller.appspotmail.com usb 1-1: USB disconnect, device number 72 == BUG: KASAN: slab-out-of-bounds in usb_destroy_configuration+0x636/0x6d0 drivers/usb/core/config.c:834 Read of size 8 at addr 8881c7e3c758 by task kworker/1:7/3434 CPU: 1 PID: 3434 Comm: kworker/1:7 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xf6/0x16e lib/dump_stack.c:118 print_address_description.constprop.0+0x1a/0x210 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x37/0x7c mm/kasan/report.c:530 usb_destroy_configuration+0x636/0x6d0 drivers/usb/core/config.c:834 usb_release_dev+0x3e/0x100 drivers/usb/core/usb.c:417 device_release+0x71/0x200 drivers/base/core.c:1579 kobject_cleanup lib/kobject.c:693 [inline] kobject_release lib/kobject.c:722 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x245/0x540 lib/kobject.c:739 put_device+0x1b/0x30 drivers/base/core.c:2799 hub_port_connect drivers/usb/core/hub.c:5059 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x1c93/0x4390 drivers/usb/core/hub.c:5576 process_one_work+0x94c/0x15f0 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x392/0x470 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Allocated by task 13775: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 kmalloc include/linux/slab.h:560 [inline] kzalloc include/linux/slab.h:669 [inline] usb_get_configuration+0x186/0x3a50 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2387 [inline] usb_new_device+0x42c/0x7a0 drivers/usb/core/hub.c:2523 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x2361/0x4390 drivers/usb/core/hub.c:5576 process_one_work+0x94c/0x15f0 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x392/0x470 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Freed by task 3070: save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0x116/0x160 mm/kasan/common.c:455 slab_free_hook mm/slub.c:1474 [inline] slab_free_freelist_hook+0x53/0x140 mm/slub.c:1507 slab_free mm/slub.c:3072 [inline] kfree+0xbc/0x2c0 mm/slub.c:4052 kfree_const+0x51/0x60 mm/util.c:40 kobject_cleanup lib/kobject.c:699 [inline] kobject_release lib/kobject.c:722 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x26f/0x540 lib/kobject.c:739 put_device drivers/base/core.c:2799 [inline] device_unregister+0x34/0xc0 drivers/base/core.c:2910 usb_remove_ep_devs+0x3e/0x80 drivers/usb/core/endpoint.c:215 remove_intf_ep_devs drivers/usb/core/message.c:1120 [inline] usb_disable_device+0x335/0x930 drivers/usb/core/message.c:1244 usb_disconnect.cold+0x27d/0x780 drivers/usb/core/hub.c:2217 hub_port_connect drivers/usb/core/hub.c:5059 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x1c93/0x4390 drivers/usb/core/hub.c:5576 process_one_work+0x94c/0x15f0 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x392/0x470 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 The buggy address belongs to the object at 8881c7e3c750 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of 8-byte region [8881c7e3c750, 8881c7e3c758) The buggy address belongs to the page: page:ea00071f8f00 refcount:1 mapcount:0 mapping: index:0x8881c7e3c7b0 flags: 0x2000200(slab) raw: 02000200 ea00071ffac0 000b000b 8881da003900 raw: 8881c7e3c7b0 80aa00a8 0001 page dumped
Re: [PATCH] soc: ti: k3-socinfo: Add entry for J7200
On 03/08/20 4:23 pm, Peter Ujfalusi wrote:
> Update K3 chipinfo driver to support new TI J7200 SoC.
> It's JTAG PARTNO is 0xBB6D.
>
> Signed-off-by: Peter Ujfalusi
Reviewed-by: Lokesh Vutla
Thanks and regards,
Lokesh
> ---
> drivers/soc/ti/k3-socinfo.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
> index af0ba5288e58..bbbc2d2b7091 100644
> --- a/drivers/soc/ti/k3-socinfo.c
> +++ b/drivers/soc/ti/k3-socinfo.c
> @@ -39,6 +39,7 @@ static const struct k3_soc_id {
> } k3_soc_ids[] = {
> { 0xBB5A, "AM65X" },
> { 0xBB64, "J721E" },
> + { 0xBB6D, "J7200" },
> };
>
> static int
>
Re: [PATCH v2 3/7] arch_topology: disable frequency invariance for CONFIG_BL_SWITCHER
Hi guys, On Friday 31 Jul 2020 at 16:48:38 (+0100), Sudeep Holla wrote: > On Thu, Jul 30, 2020 at 12:29:52PM +0200, Dietmar Eggemann wrote: > > [...] > > > > > Are there still any users of CONFIG_BL_SWITCHER? I guess it's only > > limited to A15/A7 systems w/ vexpress-spc-cpufreq.c ... so probably only > > TC2? > > I think so as no one shouted when I merged bL switcher driver into > vexpress-spc-cpufreq.c > I think a good indication is also the fact that frequency invariance was broken for a long time for bL_switcher_enabled systems and nobody shouted. A way to make this nicer is to fully remove BL_SWITCHER support. This support was valuable at its time, but given that now there is proper asymmetric CPU capacity support, is there any reason to hold on to this? Thanks, Ionela. > -- > Regards, > Sudeep
[PATCH] habanalabs: Fix memory corruption in debugfs
This has to be a long instead of a u32 because we write a long value.
On 64 bit systems, this will cause memory corruption.
Fixes: c216477363a3 ("habanalabs: add debugfs support")
Signed-off-by: Dan Carpenter
---
drivers/misc/habanalabs/common/debugfs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/habanalabs/common/debugfs.c
b/drivers/misc/habanalabs/common/debugfs.c
index 71cfe1b6fafc..ecd37b427480 100644
--- a/drivers/misc/habanalabs/common/debugfs.c
+++ b/drivers/misc/habanalabs/common/debugfs.c
@@ -19,7 +19,7 @@
static struct dentry *hl_debug_root;
static int hl_debugfs_i2c_read(struct hl_device *hdev, u8 i2c_bus, u8 i2c_addr,
- u8 i2c_reg, u32 *val)
+ u8 i2c_reg, long *val)
{
struct armcp_packet pkt;
int rc;
@@ -36,7 +36,7 @@ static int hl_debugfs_i2c_read(struct hl_device *hdev, u8
i2c_bus, u8 i2c_addr,
pkt.i2c_reg = i2c_reg;
rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) , sizeof(pkt),
- 0, (long *) val);
+ 0, val);
if (rc)
dev_err(hdev->dev, "Failed to read from I2C, error %d\n", rc);
@@ -827,7 +827,7 @@ static ssize_t hl_i2c_data_read(struct file *f, char __user
*buf,
struct hl_dbg_device_entry *entry = file_inode(f)->i_private;
struct hl_device *hdev = entry->hdev;
char tmp_buf[32];
- u32 val;
+ long val;
ssize_t rc;
if (*ppos)
@@ -842,7 +842,7 @@ static ssize_t hl_i2c_data_read(struct file *f, char __user
*buf,
return rc;
}
- sprintf(tmp_buf, "0x%02x\n", val);
+ sprintf(tmp_buf, "0x%02lx\n", val);
rc = simple_read_from_buffer(buf, count, ppos, tmp_buf,
strlen(tmp_buf));
--
2.27.0
[PATCH v3] sched: Provide USF for the portable equipment.
From: Dongdong Yang The power consumption and UI response are more cared for by the portable equipment users. USF(User Sensitive Feedback factor) auxiliary cpufreq governor is providing more utils adjustment settings to the high level by scenario identification. >From the view of portable equipment, screen off status usually stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. In some scenarios, such as listening to music, low power processors, such as DSP, take more actions and CPU load requirements cut down. It would bring more power consumption benefit if high level have interfaces to adjust utils according to the current scenario and load. In addition, the portable equipment user usually heavily interact with devices by touch, and other peripherals. The boost preemptive counts are marking the load requirement urgent, vice versa. If such feedback factor could be set to high level according to the scenario, it would contribute to the power consumption and UI response. If no USF sysfs inode is set, and no screen on or off event, adjust_task_pred_demand shall not be invoked. Once sched_usf_up_l0_r sched_usf_down_r or sched_usf_non_ux_r be set, adjust_task_pred_demand shall be called back to update settings according to high level scenario identification. We can get about 17% mean power consumption save at listening to music with speaker on "screen off" scenario, as below statistical data from 7766 XiaoMi devices for two weeks with sched_usf_non_ux_r be set: day1 day2 day3 day4 count 7766.00 7766.00 7766.00 7766.00 mean88.03552585.50028283.82930586.054997 std 111.049980 108.258834 107.562583 108.558240 min 0.099000 0.037000 0.067000 0.045000 25% 34.76550034.02175034.10150034.423000 50% 54.9555.28650054.18950054.248500 75% 95.95400093.94200091.73800094.0592500 80% 114.675000 107.43 106.378000 108.673000 85% 137.851000 129.511000 127.156500 131.750750 90% 179.669000 170.208500 164.027000 172.348000 95% 272.395000 257.845500 247.750500 263.275750 98% 399.034500 412.170400 391.484000 402.835600 day5 day6day7 day8 count 7766.00 7766.0 7766.00 7766.00 mean82.53267779.2192377.61138081.075081 std 104.870079 101.34819 103.140037 97.506221 min 0.051000 0.02900 0.007000 0.068000 25% 32.87300033.4440031.96550033.863500 50% 52.18050051.5655050.80650053.08 75% 90.90575086.8262583.85925089.973000 80% 105.455000 99.6470097.271000104.225000 85% 128.30 118.47825 116.570250 126.648250 90% 166.647500 149.18000 150.649500 161.087000 95% 247.208500 224.36050 226.38 245.291250 98% 393.002000 347.92060 369.791800 378.778600 day9 day10day11day12 count 7766.00 7766.00 7766.00 7766.00 mean79.98917083.85941778.03293077.060542 std 104.226122 108.893043 102.561715 99.844276 min 0.118000 0.017000 0.028000 0.039000 25% 32.05625033.45450031.17625030.897750 50% 51.50600054.05600048.96950049.069000 75% 88.51350092.95350083.50675084.096000 80% 102.876000 107.845000 97.71700098.073000 85% 124.363000 128.288000 118.366500 116.869250 90% 160.557000 167.084000 154.342500 148.187500 95% 231.149000 242.925750 236.759000 228.131250 98% 367.206600 388.619100 385.269100 376.541600 day13day14 count 7766.00 7766.00 mean75.52803673.702878 std 90.75059486.796016 min 0.066000 0.054000 25% 31.17050031.608500 50% 48.75850049.215000 75% 84.52275083.053000 80% 97.87900094.875000 85% 116.680250 113.573750 90% 149.083500 144.089500 95% 226.177750 211.488750 98% 347.011100 331.317100 Signed-off-by: Dongdong Yang Co-developed-by: Jun Tao Co-developed-by: Qiwu Huang Co-developed-by: Peng Wang --- Documentation/scheduler/sched-ufs.txt | 78 + drivers/cpufreq/Kconfig | 11 ++ drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + include/trace/events/sched.h | 35 kernel/sched/Makefile | 1 + kernel/sched/cpufreq_schedutil.c | 3 + kernel/sched/sched.h | 10 ++ kernel/sched/usf.c| 305 ++ 9 files changed, 446 insertions(+) create mode 100644 Documentation/scheduler/sched-ufs.txt create mode 100644 kernel/sched/usf.c diff --git a/Documentation/scheduler/sched-ufs.txt
Teo En Ming's Guide on Basic Configuration of Cisco ASA 5505 Firewall
Subject: Teo En Ming's Guide on Basic Configuration of Cisco ASA 5505 Firewall Author: Mr. Turritopsis Dohrnii Teo En Ming (Targeted Individual) Country: Singapore Date Published: 3rd August 2020 Monday Singapore Time Type of Publication: PDF manual Cisco ASA firewall appliances use open source software. Cisco Adaptive Security Appliance Software, version 9.8 Copyright (c) 1996-2019 by Cisco Systems, Inc. For licenses and notices for open source software used in this product, please visit http://www.cisco.com/go/asa-opensource Redundant Google Drive download links for Teo En Ming's PDF manual: [1] https://drive.google.com/file/d/1-YTN_PQxE5uBjuDlEsirzNETXo62H4Gc/view?usp=sharing [2] https://drive.google.com/file/d/1J19bw0pV5PF_fOalaQ9QkW0uX2XlskXK/view?usp=sharing [3] https://drive.google.com/file/d/12P-pVWJNIZ4BJpi044PflqoDAg8UDVl9/view?usp=sharing [4] https://drive.google.com/file/d/1VNoEkdVNyIx43YkeZMM0Lrux51GyDDst/view?usp=sharing [5] https://drive.google.com/file/d/1eUFHZ5MihrgSxIMfnAqRNls48ib5g3vW/view?usp=sharing [6] https://drive.google.com/file/d/1Gqqn-d7sMxT7a57ItEzDwqiKxBNkXsc-/view?usp=sharing Total number of pages: 52 -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
[PATCH] memory: jz4780_nemc: Fix an error pointer vs NULL check in probe()
The devm_ioremap() function returns NULL on error, it doesn't return
error pointers. This bug could lead to an Oops during probe.
Fixes: f046e4a3f0b9 ("memory: jz4780_nemc: Only request IO memory the driver
will use")
Signed-off-by: Dan Carpenter
---
drivers/memory/jz4780-nemc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/jz4780-nemc.c b/drivers/memory/jz4780-nemc.c
index 3ec5cb0fce1e..608ae925e641 100644
--- a/drivers/memory/jz4780-nemc.c
+++ b/drivers/memory/jz4780-nemc.c
@@ -304,9 +304,9 @@ static int jz4780_nemc_probe(struct platform_device *pdev)
}
nemc->base = devm_ioremap(dev, res->start, NEMC_REG_LEN);
- if (IS_ERR(nemc->base)) {
+ if (!nemc->base) {
dev_err(dev, "failed to get I/O memory\n");
- return PTR_ERR(nemc->base);
+ return -ENOMEM;
}
writel(0, nemc->base + NEMC_NFCSR);
--
2.27.0
[RFC][PATCH] objtool,x86_64,paravirt: Add pv_ops[] support
Thomas wanted paramuck vs noinstr, here goes. Very rough, very nasty,
mostly works.
It requires call sites are the normal indirect call, and not mangled
retpoison (slow_down_io() had those), it also requires pv_ops[]
assignments are single instructions and not laundered through some
pointless intermediate helper (hyperv).
It doesn't warn when you get any of that wrong.
But if you have it all lined up right, it will warn about noinstr
violations due to paramuck:
$ ./objtool check -afl ../../defconfig-build/vmlinux.o
../../defconfig-build/vmlinux.o: warning: objtool:
xen_pv_evtchn_do_upcall()+0x69: return with instrumentation enabled
../../defconfig-build/vmlinux.o: warning: objtool: exc_double_fault()+0x15:
call pv_ops[48] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: pv_op[48]: xen_read_cr2
../../defconfig-build/vmlinux.o: warning: objtool: exc_double_fault()+0x15:
call to {dynamic}() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool: exc_debug()+0x29: call
pv_ops[4] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: pv_op[4]: native_get_debugreg
../../defconfig-build/vmlinux.o: warning: objtool: exc_debug()+0x29: call to
{dynamic}() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool: noist_exc_debug()+0x26: call
pv_ops[4] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: pv_op[4]: native_get_debugreg
../../defconfig-build/vmlinux.o: warning: objtool: noist_exc_debug()+0x26: call
to {dynamic}() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool: exc_nmi()+0x3a: call
pv_ops[48] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: pv_op[48]: xen_read_cr2
../../defconfig-build/vmlinux.o: warning: objtool: exc_nmi()+0x3a: call to
{dynamic}() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool: mce_setup()+0x80: call
pv_ops[25] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: pv_op[25]: native_cpuid
../../defconfig-build/vmlinux.o: warning: objtool: mce_setup()+0x80: call to
{dynamic}() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool: do_machine_check()+0x46:
call to mce_rdmsrl() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool: exc_machine_check()+0x24:
call pv_ops[4] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: pv_op[4]: native_get_debugreg
../../defconfig-build/vmlinux.o: warning: objtool: exc_machine_check()+0x24:
call to {dynamic}() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool:
noist_exc_machine_check()+0x24: call pv_ops[4] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: pv_op[4]: native_get_debugreg
../../defconfig-build/vmlinux.o: warning: objtool:
noist_exc_machine_check()+0x24: call to {dynamic}() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool: exc_page_fault()+0xe: call
pv_ops[48] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: pv_op[48]: xen_read_cr2
../../defconfig-build/vmlinux.o: warning: objtool: exc_page_fault()+0xe: call
to {dynamic}() leaves .noinstr.text section
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0xf17: call
pv_ops[32] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x12f1: call
pv_ops[35] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0xf5a: call
pv_ops[32] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x1002: call
pv_ops[32] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x1186: call
pv_ops[32] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x12ba: call
pv_ops[32] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x12a7: call
pv_ops[32] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x124c: call
pv_ops[32] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x14f0: call
pv_ops[32] from noinstr
../../defconfig-build/vmlinux.o: warning: objtool: .entry.text+0x1683: call
pv_ops[32] from noinstr
[ funny that, WTH does x86_64 have IRET pv_ops... ]
Requested-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/paravirt.h| 8 +--
arch/x86/kernel/cpu/mshyperv.c | 7 ---
drivers/clocksource/hyperv_timer.c | 7 +++
include/asm-generic/mshyperv.h | 1 -
lib/Kconfig.debug | 2 +-
tools/objtool/Makefile | 2 +-
tools/objtool/arch.h | 2 +-
tools/objtool/arch/x86/decode.c| 30 -
tools/objtool/builtin-check.c | 10 +--
tools/objtool/builtin-orc.c| 10 +--
tools/objtool/check.c | 126 ++---
tools/objtool/elf.h| 1 +
tools/objtool/objtool.c| 46 ++
[PATCH v3] Provide USF for the portable equipment.
From: Dongdong Yang This patch provides USF(User Sensitive Feedback factor) auxiliary cpufreq governor to support high level layer sysfs inodes setting for utils adjustment purpose from the identified scenario on portable equipment. Because the power consumption and UI response are more cared for by portable equipment users. And the "screen off" status stands for no request from the user, however, the kernel is still expected to notify the user in time on modem, network or powerkey events occur. USF provides "sched_usf_non_ux_r" sysfs inode to cut down the utils from user space tasks according to high level scenario. In addition, it usually hints more cpufreq demand that the preemptive counts of the tasks on the cpu burst and over the user expecting completed time such as the ratio sysctl_sched_latency to sysctl_sched_min_granularity on "screen on" status, which more likely with more UI. The sysfs inodes "sched_usf_up_l0_r" and "sched_usf_down_r" have been provided to adjust the utils according to high level identified scenario to alloc the cpufreq in time. Changes in v3 - Move usf.c to kernel/sched. - Remove trace_printk and debugfs. - Add document draft. - Update comments. Changes in v2 - Add adjust_task_pred_set switch. - Move adjust_task_pred_demand declaration into sched.h - Update comments. Dongdong Yang (1): sched: Provide USF for the portable equipment. Documentation/scheduler/sched-ufs.txt | 78 + drivers/cpufreq/Kconfig | 11 ++ drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + include/trace/events/sched.h | 35 kernel/sched/Makefile | 1 + kernel/sched/cpufreq_schedutil.c | 3 + kernel/sched/sched.h | 10 ++ kernel/sched/usf.c| 305 ++ 9 files changed, 446 insertions(+) create mode 100644 Documentation/scheduler/sched-ufs.txt create mode 100644 kernel/sched/usf.c -- 2.7.4
Re: [PATCH] tools/bpf/bpftool: Fix wrong return value in do_dump()
On 8/2/20 1:15 PM, Tianjia Zhang wrote:
In case of btf_id does not exist, a negative error code -ENOENT
should be returned.
Fixes: c93cc69004df3 ("bpftool: add ability to dump BTF types")
Cc: Andrii Nakryiko
Signed-off-by: Tianjia Zhang
Applied, thanks!
[PATCH v2 4/4] media: i2c: ov5640: Fallback to parallel mode
Fallback to parallel mode if bus_type doesn't match the supported
interfaces by the driver.
Signed-off-by: Lad Prabhakar
---
drivers/media/i2c/ov5640.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 08c67250042f..4e88b0540740 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -3074,6 +3074,12 @@ static int ov5640_probe(struct i2c_client *client)
return ret;
}
+ /* fallback to parallel mode */
+ if (sensor->ep.bus_type != V4L2_MBUS_PARALLEL &&
+ sensor->ep.bus_type != V4L2_MBUS_CSI2_DPHY &&
+ sensor->ep.bus_type != V4L2_MBUS_BT656)
+ sensor->ep.bus_type = V4L2_MBUS_PARALLEL;
+
/* get system clock (xclk) */
sensor->xclk = devm_clk_get(dev, "xclk");
if (IS_ERR(sensor->xclk)) {
--
2.17.1
[PATCH v2 3/4] media: i2c: ov5640: Add support for BT656 mode
Enable support for BT656 mode.
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
drivers/media/i2c/ov5640.c | 40 +++---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index ec444bee2ce9..08c67250042f 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -82,6 +82,7 @@
#define OV5640_REG_VFIFO_HSIZE 0x4602
#define OV5640_REG_VFIFO_VSIZE 0x4604
#define OV5640_REG_JPG_MODE_SELECT 0x4713
+#define OV5640_REG_CCIR656_CTRL00 0x4730
#define OV5640_REG_POLARITY_CTRL00 0x4740
#define OV5640_REG_MIPI_CTRL00 0x4800
#define OV5640_REG_DEBUG_MODE 0x4814
@@ -1216,6 +1217,18 @@ static int ov5640_set_autogain(struct ov5640_dev
*sensor, bool on)
BIT(1), on ? 0 : BIT(1));
}
+static int ov5640_set_stream_bt656(struct ov5640_dev *sensor, bool on)
+{
+ int ret;
+
+ ret = ov5640_write_reg(sensor, OV5640_REG_CCIR656_CTRL00, on ? 0x1 :
0x00);
+ if (ret)
+ return ret;
+
+ return ov5640_write_reg(sensor, OV5640_REG_SYS_CTRL0, on ?
+ OV5640_SOFTWARE_WAKEUP : OV5640_SOFTWARE_PWDN);
+}
+
static int ov5640_set_stream_dvp(struct ov5640_dev *sensor, bool on)
{
return ov5640_write_reg(sensor, OV5640_REG_SYS_CTRL0, on ?
@@ -2022,18 +2035,20 @@ static int ov5640_set_dvp(struct ov5640_dev *sensor,
bool on)
* datasheet and hardware, 0 is active high
* and 1 is active low...)
*/
- if (flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
- pclk_pol = 1;
- if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
- hsync_pol = 1;
- if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
- vsync_pol = 1;
+ if (sensor->ep.bus_type == V4L2_MBUS_PARALLEL) {
+ if (flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pclk_pol = 1;
+ if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ hsync_pol = 1;
+ if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
+ vsync_pol = 1;
- ret = ov5640_write_reg(sensor, OV5640_REG_POLARITY_CTRL00,
- (pclk_pol << 5) | (hsync_pol << 1) | vsync_pol);
+ ret = ov5640_write_reg(sensor, OV5640_REG_POLARITY_CTRL00,
+ (pclk_pol << 5) | (hsync_pol << 1) |
vsync_pol);
- if (ret)
- return ret;
+ if (ret)
+ return ret;
+ }
/*
* powerdown MIPI TX/RX PHY & disable MIPI
@@ -2057,7 +2072,8 @@ static int ov5640_set_dvp(struct ov5640_dev *sensor, bool
on)
* - 4: PCLK output enable
* - [3:0]: D[9:6] output enable
*/
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT_ENABLE01, 0x7f);
+ ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT_ENABLE01,
+ sensor->ep.bus_type == V4L2_MBUS_PARALLEL ? 0x7f
: 0x1f);
if (ret)
return ret;
@@ -2911,6 +2927,8 @@ static int ov5640_s_stream(struct v4l2_subdev *sd, int
enable)
if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
ret = ov5640_set_stream_mipi(sensor, enable);
+ else if (sensor->ep.bus_type == V4L2_MBUS_BT656)
+ ret = ov5640_set_stream_bt656(sensor, enable);
else
ret = ov5640_set_stream_dvp(sensor, enable);
--
2.17.1
[PATCH v2 1/4] dt-bindings: media: i2c: ov5640: Document bus-type property
Document the possible bus-type's supported by the OV5640 sensor driver. Also add the bus-type in example node. Signed-off-by: Lad Prabhakar --- Documentation/devicetree/bindings/media/i2c/ov5640.txt | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt b/Documentation/devicetree/bindings/media/i2c/ov5640.txt index c97c2f2da12d..00131dbb147e 100644 --- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt +++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt @@ -36,9 +36,15 @@ Endpoint node required properties for parallel connection are: - data-shift: shall be set to <2> for 8 bits parallel bus (lines 9:2 are used) or <0> for 10 bits parallel bus - hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively. + (Required for bus-type 5) - vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. + (Required for bus-type 5) - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock - signal. + signal. (Required for bus-type 5) +- bus-type: data bus type. Possible values are: + 4 - MIPI CSI-2 D-PHY + 5 - Parallel + 6 - Bt.656 Examples: @@ -86,6 +92,7 @@ Examples: hsync-active = <0>; vsync-active = <0>; pclk-sample = <1>; + bus-type = <5>; }; }; }; -- 2.17.1
[PATCH v2 0/4] media: i2c: ov5640 feature enhancement and fixes
Hi All, This patch series fixes DVP support and enables BT656 mode in the driver. @Jacopo Mondi - patch 1/4 will collide with your patch series [1], feel free to merge it as part of your v2. [1] https://www.spinics.net/lists/linux-renesas-soc/msg51236.html Cheers, Prabhakar Changes for v2: * Added support to fallback in parallel mode * Documented bus-type property * Added descriptive commit message for patch 2/4 as pointed by Sakari * Fixed review comments pointed by Laurent to have separate functions for mipi and dvp setup * Made sure the sensor is in power down mode during startup too for DVP mode Lad Prabhakar (4): dt-bindings: media: i2c: ov5640: Document bus-type property media: i2c: ov5640: Enable data pins on poweron for DVP mode media: i2c: ov5640: Add support for BT656 mode media: i2c: ov5640: Fallback to parallel mode .../devicetree/bindings/media/i2c/ov5640.txt | 9 +- drivers/media/i2c/ov5640.c| 333 ++ 2 files changed, 198 insertions(+), 144 deletions(-) -- 2.17.1
Re: [PATCH 2/3] pinctrl: actions: Add Actions S500 pinctrl driver
On Sun, Aug 02, 2020 at 08:48:13PM +0530, Manivannan Sadhasivam wrote: > Hi, > > Sorry for the delay. This has fallen through the cracks... Hi Mani, No problem, thanks for finding the time to review this. > On Fri, Jun 26, 2020 at 08:11:48PM +0300, Cristian Ciocaltea wrote: > > On Fri, Jun 26, 2020 at 07:59:41PM +0530, Manivannan Sadhasivam wrote: > > > On Thu, Jun 25, 2020 at 11:16:19PM +0300, Cristian Ciocaltea wrote: > > > > Add pinctrl and gpio driver for Actions Semi S500 SoC. > > > > > > > > The driver supports pinctrl, pinmux, pinconf, gpio and interrupt > > > > functions using a set of registers shared between gpio and pinctrl. > > > > > > > > Signed-off-by: Cristian Ciocaltea > > > > --- > > > > drivers/pinctrl/actions/Kconfig|6 + > > > > drivers/pinctrl/actions/Makefile |1 + > > > > drivers/pinctrl/actions/pinctrl-s500.c | 1727 > > > > 3 files changed, 1734 insertions(+) > > > > create mode 100644 drivers/pinctrl/actions/pinctrl-s500.c > > > > > > > > diff --git a/drivers/pinctrl/actions/Kconfig > > > > b/drivers/pinctrl/actions/Kconfig > > > > index 966f1c2c89d6..a1d16e8280e5 100644 > > > > --- a/drivers/pinctrl/actions/Kconfig > > > > +++ b/drivers/pinctrl/actions/Kconfig > > > > @@ -10,6 +10,12 @@ config PINCTRL_OWL > > > > help > > > > Say Y here to enable Actions Semi OWL pinctrl driver > > > > > > > > +config PINCTRL_S500 > > > > + bool "Actions Semi S500 pinctrl driver" > > > > + depends on PINCTRL_OWL > > > > + help > > > > + Say Y here to enable Actions Semi S500 pinctrl driver > > > > + > > > > config PINCTRL_S700 > > > > bool "Actions Semi S700 pinctrl driver" > > > > depends on PINCTRL_OWL > > > > diff --git a/drivers/pinctrl/actions/Makefile > > > > b/drivers/pinctrl/actions/Makefile > > > > index 61aa9107a43a..b9e2c527c9d3 100644 > > > > --- a/drivers/pinctrl/actions/Makefile > > > > +++ b/drivers/pinctrl/actions/Makefile > > > > @@ -1,4 +1,5 @@ > > > > # SPDX-License-Identifier: GPL-2.0-only > > > > obj-$(CONFIG_PINCTRL_OWL) += pinctrl-owl.o > > > > +obj-$(CONFIG_PINCTRL_S500) += pinctrl-s500.o > > > > obj-$(CONFIG_PINCTRL_S700) += pinctrl-s700.o > > > > obj-$(CONFIG_PINCTRL_S900) += pinctrl-s900.o > > > > diff --git a/drivers/pinctrl/actions/pinctrl-s500.c > > > > b/drivers/pinctrl/actions/pinctrl-s500.c > > > > new file mode 100644 > > > > index ..38e30914af6e > > > > --- /dev/null > > > > +++ b/drivers/pinctrl/actions/pinctrl-s500.c > > > > @@ -0,0 +1,1727 @@ > > > > +// SPDX-License-Identifier: GPL-2.0+ > > > > +/* > > > > + * Actions Semi S500 SoC Pinctrl driver > > > > + * > > > > + * Copyright (c) 2014 Actions Semi Inc. > > > > + * Copyright (c) 2020 Cristian Ciocaltea > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include "pinctrl-owl.h" > > > > + > > > > +/* Pinctrl registers offset */ > > > > +#define MFCTL0 (0x0040) > > > > +#define MFCTL1 (0x0044) > > > > +#define MFCTL2 (0x0048) > > > > +#define MFCTL3 (0x004C) > > > > +#define PAD_PULLCTL0 (0x0060) > > > > +#define PAD_PULLCTL1 (0x0064) > > > > +#define PAD_PULLCTL2 (0x0068) > > > > +#define PAD_ST0(0x006C) > > > > +#define PAD_ST1(0x0070) > > > > +#define PAD_CTL(0x0074) > > > > +#define PAD_DRV0 (0x0080) > > > > +#define PAD_DRV1 (0x0084) > > > > +#define PAD_DRV2 (0x0088) > > > > + > > > > +#define _GPIOA(offset) (offset) > > > > +#define _GPIOB(offset) (32 + (offset)) > > > > +#define _GPIOC(offset) (64 + (offset)) > > > > +#define _GPIOD(offset) (96 + (offset)) > > > > +#define _GPIOE(offset) (128 + (offset)) > > > > + > > > > +#define NUM_GPIOS (_GPIOE(3) + 1) > > > > +#define _PIN(offset) (NUM_GPIOS + (offset)) > > > > + > > > > +#define DNAND_DQS _GPIOA(12) > > > > +#define DNAND_DQSN _GPIOA(13) > > > > +#define ETH_TXD0 _GPIOA(14) > > > > +#define ETH_TXD1 _GPIOA(15) > > > > +#define ETH_TXEN _GPIOA(16) > > > > +#define ETH_RXER _GPIOA(17) > > > > +#define ETH_CRS_DV _GPIOA(18) > > > > +#define ETH_RXD1 _GPIOA(19) > > > > +#define ETH_RXD0 _GPIOA(20) > > > > +#define ETH_REF_CLK_GPIOA(21) > > > > +#define ETH_MDC_GPIOA(22) > > > > +#define ETH_MDIO _GPIOA(23) > > > > +#define SIRQ0 _GPIOA(24) > > > > +#define SIRQ1 _GPIOA(25) > > > > +#define SIRQ2 _GPIOA(26) > > > > +#define I2S_D0 _GPIOA(27) > > > > +#define I2S_BCLK0 _GPIOA(28) > > > > +#define I2S_LRCLK0
[PATCH v2 2/4] media: i2c: ov5640: Enable data pins on poweron for DVP mode
During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP
mode with rcar-vin bridge noticed the capture worked fine for the first run
(with yavta), but for subsequent runs the bridge driver waited for the
frame to be captured. Debugging further noticed the data lines were
enabled/disabled in stream on/off callback and dumping the register
contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct
values, but yet frame capturing failed.
To get around this issue the following actions are performed for
parallel mode (DVP):
1: Keeps the sensor in software power down mode and is woken up only in
ov5640_set_stream_dvp() callback.
2: Enables data lines in s_power callback
3: Configures HVP lines in s_power callback instead of configuring
everytime in ov5640_set_stream_dvp().
4: Disables MIPI interface.
Fixes: f22996db44e2d ("media: ov5640: add support of DVP parallel interface")
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
drivers/media/i2c/ov5640.c | 321 -
1 file changed, 172 insertions(+), 149 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 2fe4a7ac0592..ec444bee2ce9 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -94,6 +94,9 @@
#define OV5640_REG_SDE_CTRL5 0x5585
#define OV5640_REG_AVG_READOUT 0x56a1
+#define OV5640_SOFTWARE_PWDN 0x42
+#define OV5640_SOFTWARE_WAKEUP 0x02
+
enum ov5640_mode_id {
OV5640_MODE_QCIF_176_144 = 0,
OV5640_MODE_QVGA_320_240,
@@ -274,7 +277,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct
v4l2_ctrl *ctrl)
/* YUV422 UYVY VGA@30fps */
static const struct reg_value ov5640_init_setting_30fps_VGA[] = {
{0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
- {0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
+ {0x3103, 0x03, 0, 0},
{0x3630, 0x36, 0, 0},
{0x3631, 0x0e, 0, 0}, {0x3632, 0xe2, 0, 0}, {0x3633, 0x12, 0, 0},
{0x3621, 0xe0, 0, 0}, {0x3704, 0xa0, 0, 0}, {0x3703, 0x5a, 0, 0},
@@ -1120,6 +1123,11 @@ static int ov5640_load_regs(struct ov5640_dev *sensor,
val = regs->val;
mask = regs->mask;
+ /* remain in power down mode for DVP */
+ if (regs->reg_addr == OV5640_REG_SYS_CTRL0 && val ==
OV5640_SOFTWARE_WAKEUP &&
+ sensor->ep.bus_type != V4L2_MBUS_CSI2_DPHY)
+ continue;
+
if (mask)
ret = ov5640_mod_reg(sensor, reg_addr, mask, val);
else
@@ -1210,96 +1218,8 @@ static int ov5640_set_autogain(struct ov5640_dev
*sensor, bool on)
static int ov5640_set_stream_dvp(struct ov5640_dev *sensor, bool on)
{
- int ret;
- unsigned int flags = sensor->ep.bus.parallel.flags;
- u8 pclk_pol = 0;
- u8 hsync_pol = 0;
- u8 vsync_pol = 0;
-
- /*
-* Note about parallel port configuration.
-*
-* When configured in parallel mode, the OV5640 will
-* output 10 bits data on DVP data lines [9:0].
-* If only 8 bits data are wanted, the 8 bits data lines
-* of the camera interface must be physically connected
-* on the DVP data lines [9:2].
-*
-* Control lines polarity can be configured through
-* devicetree endpoint control lines properties.
-* If no endpoint control lines properties are set,
-* polarity will be as below:
-* - VSYNC: active high
-* - HREF: active low
-* - PCLK: active low
-*/
-
- if (on) {
- /*
-* configure parallel port control lines polarity
-*
-* POLARITY CTRL0
-* - [5]: PCLK polarity (0: active low, 1: active high)
-* - [1]: HREF polarity (0: active low, 1: active high)
-* - [0]: VSYNC polarity (mismatch here between
-* datasheet and hardware, 0 is active high
-* and 1 is active low...)
-*/
- if (flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
- pclk_pol = 1;
- if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
- hsync_pol = 1;
- if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
- vsync_pol = 1;
-
- ret = ov5640_write_reg(sensor,
- OV5640_REG_POLARITY_CTRL00,
- (pclk_pol << 5) |
- (hsync_pol << 1) |
- vsync_pol);
-
- if (ret)
- return ret;
- }
-
- /*
-* powerdown MIPI TX/RX PHY & disable MIPI
-*
-* MIPI CONTROL 00
-* 4:PWDN PHY TX
-* 3:PWDN
Re: [PATCH 13/17] watch_queue: Implement mount topology and attribute change notifications [ver #5]
On Mon, 2020-08-03 at 13:31 +0100, David Howells wrote: > Ian Kent wrote: > > > > I'm changing it so that the fields are 64-bit, but initialised > > > with the > > > existing mount ID in the notifications set. The fsinfo set > > > changes that > > > to a unique ID. I'm tempted to make the unique IDs start at > > > UINT_MAX+1 to > > > disambiguate them. > > > > Mmm ... so what would I use as a mount id that's not used, like > > NULL > > for strings? > > Zero is skipped, so you could use that. > > > I'm using -1 now but changing this will mean I need something > > different. > > It's 64-bits, so you're not likely to see it reach -1, even if it > does start > at UINT_MAX+1. Ha, either or, I don't think it will be a problem, there's bound to be a few changes so the components using this will need to change a bit before it's finalized, shouldn't be a big deal I think. At least not for me and shouldn't be much for libmount either I think. Ian
[PATCH] habanalabs: expose sync manager resources allocation in INFO IOCTL
From: Ofir Bitton
Although the driver defines the first user-available sync manager object
and monitor in habanalabs.h, we would like to also expose this information
via the INFO IOCTL so the runtime can get this information dynamically.
This is because in future ASICs we won't need to define it statically.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/common/habanalabs.h | 6
.../misc/habanalabs/common/habanalabs_ioctl.c | 30 ++-
drivers/misc/habanalabs/gaudi/gaudi.c | 7 +
include/uapi/misc/habanalabs.h| 23 ++
4 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/habanalabs/common/habanalabs.h
b/drivers/misc/habanalabs/common/habanalabs.h
index 8b5b4afe42c7..52a07c8d7d7c 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -65,6 +65,8 @@
#define HL_PCI_NUM_BARS6
+#define HL_MAX_DCORES 4
+
/**
* struct pgt_info - MMU hop page info.
* @node: hash linked-list node for the pgts shadow hash of pgts.
@@ -291,6 +293,8 @@ struct hl_mmu_properties {
* @max_queues: maximum amount of queues in the system
* @sync_stream_first_sob: first sync object available for sync stream use
* @sync_stream_first_mon: first monitor available for sync stream use
+ * @first_available_user_sob: first sob available for the user
+ * @first_available_user_mon: first monitor available for the user
* @tpc_enabled_mask: which TPCs are enabled.
* @completion_queues_count: number of completion queues.
*/
@@ -337,6 +341,8 @@ struct asic_fixed_properties {
u32 max_queues;
u16 sync_stream_first_sob;
u16 sync_stream_first_mon;
+ u16 first_available_user_sob[HL_MAX_DCORES];
+ u16 first_available_user_mon[HL_MAX_DCORES];
u8 tpc_enabled_mask;
u8 completion_queues_count;
};
diff --git a/drivers/misc/habanalabs/common/habanalabs_ioctl.c
b/drivers/misc/habanalabs/common/habanalabs_ioctl.c
index 4d838b1a3bbe..fe6c5534d378 100644
--- a/drivers/misc/habanalabs/common/habanalabs_ioctl.c
+++ b/drivers/misc/habanalabs/common/habanalabs_ioctl.c
@@ -8,6 +8,7 @@
#include
#include "habanalabs.h"
+#include
#include
#include
#include
@@ -314,7 +315,7 @@ static int clk_throttle_info(struct hl_fpriv *hpriv, struct
hl_info_args *args)
static int cs_counters_info(struct hl_fpriv *hpriv, struct hl_info_args *args)
{
struct hl_device *hdev = hpriv->hdev;
- struct hl_info_cs_counters cs_counters = {0};
+ struct hl_info_cs_counters cs_counters = { {0} };
u32 max_size = args->return_size;
void __user *out = (void __user *) (uintptr_t) args->return_pointer;
@@ -332,6 +333,30 @@ static int cs_counters_info(struct hl_fpriv *hpriv, struct
hl_info_args *args)
min((size_t) max_size, sizeof(cs_counters))) ? -EFAULT : 0;
}
+static int sync_manager_info(struct hl_fpriv *hpriv, struct hl_info_args *args)
+{
+ struct hl_device *hdev = hpriv->hdev;
+ struct asic_fixed_properties *prop = >asic_prop;
+ struct hl_info_sync_manager sm_info = {0};
+ u32 max_size = args->return_size;
+ void __user *out = (void __user *) (uintptr_t) args->return_pointer;
+
+ if ((!max_size) || (!out))
+ return -EINVAL;
+
+ if (args->dcore_id >= HL_MAX_DCORES)
+ return -EINVAL;
+
+ sm_info.first_available_sync_object =
+ prop->first_available_user_sob[args->dcore_id];
+ sm_info.first_available_monitor =
+ prop->first_available_user_mon[args->dcore_id];
+
+
+ return copy_to_user(out, _info, min_t(size_t, (size_t) max_size,
+ sizeof(sm_info))) ? -EFAULT : 0;
+}
+
static int _hl_info_ioctl(struct hl_fpriv *hpriv, void *data,
struct device *dev)
{
@@ -401,6 +426,9 @@ static int _hl_info_ioctl(struct hl_fpriv *hpriv, void
*data,
case HL_INFO_CLK_THROTTLE_REASON:
return clk_throttle_info(hpriv, args);
+ case HL_INFO_SYNC_MANAGER:
+ return sync_manager_info(hpriv, args);
+
default:
dev_err(dev, "Invalid request %d\n", args->op);
rc = -ENOTTY;
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 41d55a5f7f83..437219985327 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -344,6 +344,7 @@ static void gaudi_mmu_prepare(struct hl_device *hdev, u32
asid);
static int gaudi_get_fixed_properties(struct hl_device *hdev)
{
struct asic_fixed_properties *prop =
[PATCH] arm64: dts: allwinner: replace numerical constant with CCU_CLKX
From: Alexander Kochetkov Signed-off-by: Alexander Kochetkov --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index c26cc1fcaffd..dfeeb7350808 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi @@ -51,7 +51,7 @@ reg = <0>; enable-method = "psci"; next-level-cache = <>; - clocks = < 21>; + clocks = < CLK_CPUX>; clock-names = "cpu"; #cooling-cells = <2>; }; @@ -62,7 +62,7 @@ reg = <1>; enable-method = "psci"; next-level-cache = <>; - clocks = < 21>; + clocks = < CLK_CPUX>; clock-names = "cpu"; #cooling-cells = <2>; }; @@ -73,7 +73,7 @@ reg = <2>; enable-method = "psci"; next-level-cache = <>; - clocks = < 21>; + clocks = < CLK_CPUX>; clock-names = "cpu"; #cooling-cells = <2>; }; @@ -84,7 +84,7 @@ reg = <3>; enable-method = "psci"; next-level-cache = <>; - clocks = < 21>; + clocks = < CLK_CPUX>; clock-names = "cpu"; #cooling-cells = <2>; }; -- 2.17.1
