Re: [PATCH v2 3/4] perf augmented_raw_syscalls: Support arm64 raw syscalls
On Thu, Jun 13, 2019 at 03:15:14PM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> > > > diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> > > > index 1a2a605cf068..eb70a4b71755 100644
> > > > --- a/tools/perf/builtin-trace.c
> > > > +++ b/tools/perf/builtin-trace.c
> > > > @@ -1529,6 +1529,7 @@ static int trace__read_syscall_info(struct trace
> > > > *trace, int id)
> > > > static int trace__validate_ev_qualifier(struct trace *trace)
> > > > {
> > > > int err = 0, i;
> > > > + bool printed_invalid_prefix = false;
> > > > size_t nr_allocated;
> > > > struct str_node *pos;
> > > >
> > > > @@ -1555,14 +1556,15 @@ static int trace__validate_ev_qualifier(struct
> > > > trace *trace)
> > > > if (id >= 0)
> > > > goto matches;
> > > >
> > > > - if (err == 0) {
> > > > - fputs("Error:\tInvalid syscall ",
> > > > trace->output);
> > > > - err = -EINVAL;
> > > > + if (!printed_invalid_prefix) {
> > > > + pr_debug("Skipping unknown syscalls: ");
> > > > + printed_invalid_prefix = true;
> > > > } else {
> > > > - fputs(", ", trace->output);
> > > > + pr_debug(", ");
> > > > }
> > > >
> > > > - fputs(sc, trace->output);
> > > > + pr_debug("%s", sc);
> > > > + continue;
> > >
> > > Here adds 'continue' so that we want to let ev_qualifier_ids.entries
> > > to only store valid system call ids. But this is not sufficient,
> > > because we have initialized ev_qualifier_ids.nr at the beginning of
> > > the function:
> > >
> > > trace->ev_qualifier_ids.nr = strlist__nr_entries(trace->ev_qualifier);
> > > This sentence will set ids number to the string table's length; but
> > > actually some strings are not really supported; this leads to some
> > > items in trace->ev_qualifier_ids.entries[] will be not initialized
> > > properly.
> > >
> > > If we want to get neat entries and entry number, I suggest at the
> > > beginning of the function we use variable 'nr_allocated' to store
> > > string table length and use it to allocate entries:
> > >
> > > nr_allocated = strlist__nr_entries(trace->ev_qualifier);
> > > trace->ev_qualifier_ids.entries = malloc(nr_allocated *
> > >
> > > sizeof(trace->ev_qualifier_ids.entries[0]));
> > >
> > > If we find any matched string, then increment the nr field under
> > > 'matches' tag:
> > >
> > > matches:
> > > trace->ev_qualifier_ids.nr++;
> > > trace->ev_qualifier_ids.entries[i++] = id;
> > >
> > > This can ensure the entries[0..nr-1] has valid id and we can use
> > > ev_qualifier_ids.nr to maintain the valid system call numbers.
> >
> > yeah, you're right, I'll address these issues in a followup patch,
> > tomorrow.
>
> This is equivalent and I think the smallest patch, I'll add one on top
> doing what you suggested about nr_allocated getting the
> strlist__nr_entries() and also will rename i to nr_used to contrast with
> nr_allocated, and then at the end set ev_qualifier_ids.nr to nr_used.
Thanks for this patch, I tested below changes and 'perf trace' works
well. You could add my test tag:
Tested-by: Leo Yan
> - Arnaldo
>
> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index eb70a4b71755..bd1f00e7a2eb 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -1528,9 +1528,9 @@ static int trace__read_syscall_info(struct trace
> *trace, int id)
>
> static int trace__validate_ev_qualifier(struct trace *trace)
> {
> - int err = 0, i;
> + int err = 0;
> bool printed_invalid_prefix = false;
> - size_t nr_allocated;
> + size_t nr_allocated, i;
> struct str_node *pos;
>
> trace->ev_qualifier_ids.nr = strlist__nr_entries(trace->ev_qualifier);
> @@ -1575,7 +1575,7 @@ static int trace__validate_ev_qualifier(struct trace
> *trace)
> id = syscalltbl__strglobmatch_next(trace->sctbl, sc,
> _next);
> if (id < 0)
> break;
> - if (nr_allocated == trace->ev_qualifier_ids.nr) {
> + if (nr_allocated == i) {
> void *entries;
>
> nr_allocated += 8;
> @@ -1588,11 +1588,11 @@ static int trace__validate_ev_qualifier(struct trace
> *trace)
> }
> trace->ev_qualifier_ids.entries = entries;
> }
> - trace->ev_qualifier_ids.nr++;
> trace->ev_qualifier_ids.entries[i++] = id;
> }
Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
On Fri, Jun 14, 2019 at 04:09:35PM -0600, James Feeney wrote: > Hey Everyone > > On 4/24/19 10:41 AM, Benjamin Tissoires wrote: > >>> For a patch to be picked up by stable, it first needs to go in Linus' > >>> tree. Currently we are working on 5.1, so any stable patches need to > >>> go in 5.1 first. Then, once they hit Linus' tree, the stable team will > >>> pick them and backport them in the appropriate stable tree. > > Hmm - so, I just booted linux 5.1.9, and this patch set is *still* missing > from the kernel. > > Is there anything that we can do about this? What is the git commit id of the patch in Linus's tree? As I said before, it can not be backported until it shows up there first. thanks, greg k-h
Re: [PATCH AUTOSEL 5.1 17/59] fpga: dfl: expand minor range when registering chrdev region
On Fri, Jun 14, 2019 at 04:28:01PM -0400, Sasha Levin wrote:
> From: Chengguang Xu
>
> [ Upstream commit de9a7f6f5f1967d275311cca9163b4a3ffe9b0ae ]
>
> Actually, total amount of available minor number
> for a single major is MINORMASK + 1. So expand
> minor range when registering chrdev region.
>
> Signed-off-by: Chengguang Xu
> Acked-by: Wu Hao
> Acked-by: Alan Tull
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Sasha Levin
> ---
> drivers/fpga/dfl.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index c25217cde5ca..4b66aaa32b5a 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -322,7 +322,7 @@ static void dfl_chardev_uinit(void)
> for (i = 0; i < DFL_FPGA_DEVT_MAX; i++)
> if (MAJOR(dfl_chrdevs[i].devt)) {
> unregister_chrdev_region(dfl_chrdevs[i].devt,
> - MINORMASK);
> + MINORMASK + 1);
> dfl_chrdevs[i].devt = MKDEV(0, 0);
> }
> }
> @@ -332,8 +332,8 @@ static int dfl_chardev_init(void)
> int i, ret;
>
> for (i = 0; i < DFL_FPGA_DEVT_MAX; i++) {
> - ret = alloc_chrdev_region(_chrdevs[i].devt, 0, MINORMASK,
> - dfl_chrdevs[i].name);
> + ret = alloc_chrdev_region(_chrdevs[i].devt, 0,
> + MINORMASK + 1, dfl_chrdevs[i].name);
> if (ret)
> goto exit;
> }
Not a bugfix, so not needed for stable kernels, thanks.
greg k-h
Re: [PATCH AUTOSEL 5.1 16/59] fpga: dfl: Add lockdep classes for pdata->lock
On Fri, Jun 14, 2019 at 04:28:00PM -0400, Sasha Levin wrote:
> From: Scott Wood
>
> [ Upstream commit dfe3de8d397bf878b31864d4e489d41118ec475f ]
>
> struct dfl_feature_platform_data (and it's mutex) is used
> by both fme and port devices, and when lockdep is enabled it
> complains about nesting between these locks. Tell lockdep about
> the difference so it can track each class separately.
>
> Here's the lockdep complaint:
> [ 409.680668] WARNING: possible recursive locking detected
> [ 409.685983] 5.1.0-rc3.fpga+ #1 Tainted: GE
> [ 409.691469]
> [ 409.696779] fpgaconf/9348 is trying to acquire lock:
> [ 409.701746] a443fe2e (>lock){+.+.}, at:
> port_enable_set+0x24/0x60 [dfl_afu]
> [ 409.710006]
> [ 409.710006] but task is already holding lock:
> [ 409.715837] 63b78782 (>lock){+.+.}, at:
> fme_pr_ioctl+0x21d/0x330 [dfl_fme]
> [ 409.724012]
> [ 409.724012] other info that might help us debug this:
> [ 409.730535] Possible unsafe locking scenario:
> [ 409.730535]
> [ 409.736457]CPU0
> [ 409.738910]
> [ 409.741360] lock(>lock);
> [ 409.744679] lock(>lock);
> [ 409.747999]
> [ 409.747999] *** DEADLOCK ***
> [ 409.747999]
> [ 409.753920] May be due to missing lock nesting notation
> [ 409.753920]
> [ 409.760704] 4 locks held by fpgaconf/9348:
> [ 409.764805] #0: 63b78782 (>lock){+.+.}, at:
> fme_pr_ioctl+0x21d/0x330 [dfl_fme]
> [ 409.773408] #1: 213c8a66 (>mutex){+.+.}, at:
> fpga_region_program_fpga+0x24/0x200 [fpga_region]
> [ 409.783489] #2: fe63afb9 (>ref_mutex){+.+.}, at:
> fpga_mgr_lock+0x15/0x40 [fpga_mgr]
> [ 409.792354] #3: 0b2285c5 (>mutex){+.+.}, at:
> __fpga_bridge_get+0x26/0xa0 [fpga_bridge]
> [ 409.801740]
> [ 409.801740] stack backtrace:
> [ 409.806102] CPU: 45 PID: 9348 Comm: fpgaconf Kdump: loaded Tainted: G
> E 5.1.0-rc3.fpga+ #1
> [ 409.815658] Hardware name: Intel Corporation S2600BT/S2600BT, BIOS
> SE5C620.86B.01.00.0763.022420181017 02/24/2018
> [ 409.825911] Call Trace:
> [ 409.828369] dump_stack+0x5e/0x8b
> [ 409.831686] __lock_acquire+0xf3d/0x10e0
> [ 409.835612] ? find_held_lock+0x3c/0xa0
> [ 409.839451] lock_acquire+0xbc/0x1d0
> [ 409.843030] ? port_enable_set+0x24/0x60 [dfl_afu]
> [ 409.847823] ? port_enable_set+0x24/0x60 [dfl_afu]
> [ 409.852616] __mutex_lock+0x86/0x970
> [ 409.856195] ? port_enable_set+0x24/0x60 [dfl_afu]
> [ 409.860989] ? port_enable_set+0x24/0x60 [dfl_afu]
> [ 409.865777] ? __mutex_unlock_slowpath+0x4b/0x290
> [ 409.870486] port_enable_set+0x24/0x60 [dfl_afu]
> [ 409.875106] fpga_bridges_disable+0x36/0x50 [fpga_bridge]
> [ 409.880502] fpga_region_program_fpga+0xea/0x200 [fpga_region]
> [ 409.886338] fme_pr_ioctl+0x13e/0x330 [dfl_fme]
> [ 409.890870] fme_ioctl+0x66/0xe0 [dfl_fme]
> [ 409.894973] do_vfs_ioctl+0xa9/0x720
> [ 409.898548] ? lockdep_hardirqs_on+0xf0/0x1a0
> [ 409.902907] ksys_ioctl+0x60/0x90
> [ 409.906225] __x64_sys_ioctl+0x16/0x20
> [ 409.909981] do_syscall_64+0x5a/0x220
> [ 409.913644] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 409.918698] RIP: 0033:0x7f9d31b9b8d7
> [ 409.922276] Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7
> c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48
> [ 409.941020] RSP: 002b:7ffe4cae0d68 EFLAGS: 0202 ORIG_RAX:
> 0010
> [ 409.948588] RAX: ffda RBX: 7f9d32ade6a0 RCX:
> 7f9d31b9b8d7
> [ 409.955719] RDX: 7ffe4cae0df0 RSI: b680 RDI:
> 0003
> [ 409.962852] RBP: 0003 R08: 7f9d2b70a177 R09:
> 7ffe4cae0e40
> [ 409.969984] R10: 7ffe4cae0160 R11: 0202 R12:
> 7ffe4cae0df0
> [ 409.977115] R13: b680 R14: R15:
> 7ffe4cae0f60
>
> Signed-off-by: Scott Wood
> Acked-by: Wu Hao
> Acked-by: Alan Tull
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Sasha Levin
> ---
> drivers/fpga/dfl.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
Adding lockdep stuff is not really needed for stable kernels, please
drop this from all trees.
thanks,
greg k-h
Re: [PATCH -next] soc: qcom: fix QCOM_AOSS_QMP dependency and build errors
On Fri 14 Jun 14:47 PDT 2019, Randy Dunlap wrote: > From: Randy Dunlap > > Fix Kconfig warning and subsequent build errors that are caused > when PM_GENERIC_DOMAINS=y but CONFIG_PM is not set/enabled. > Thanks Randy, I thought I had all angles covered here. Applied to our -next branch. Regards, Bjorn > WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS > Depends on [n]: PM [=n] > Selected by [m]: > - QCOM_AOSS_QMP [=m] && (ARCH_QCOM || COMPILE_TEST [=y]) && MAILBOX [=y] && > COMMON_CLK [=y] > > Fixes these build errors: > > ../drivers/base/power/domain.c: In function ‘genpd_queue_power_off_work’: > ../drivers/base/power/domain.c:485:13: error: ‘pm_wq’ undeclared (first use > in this function) > queue_work(pm_wq, >power_off_work); > ../drivers/base/power/domain.c:485:13: note: each undeclared identifier is > reported only once for each function it appears in > ../drivers/base/power/domain.c: In function ‘genpd_dev_pm_qos_notifier’: > ../drivers/base/power/domain.c:675:25: error: ‘struct dev_pm_info’ has no > member named ‘ignore_children’ >if (!dev || dev->power.ignore_children) > ../drivers/base/power/domain.c: In function ‘rtpm_status_str’: > ../drivers/base/power/domain.c:2754:16: error: ‘struct dev_pm_info’ has no > member named ‘runtime_error’ > if (dev->power.runtime_error) > ../drivers/base/power/domain.c:2756:21: error: ‘struct dev_pm_info’ has no > member named ‘disable_depth’ > else if (dev->power.disable_depth) > ../drivers/base/power/domain.c:2758:21: error: ‘struct dev_pm_info’ has no > member named ‘runtime_status’ > else if (dev->power.runtime_status < ARRAY_SIZE(status_lookup)) > ../drivers/base/power/domain.c:2759:31: error: ‘struct dev_pm_info’ has no > member named ‘runtime_status’ >p = status_lookup[dev->power.runtime_status]; > ../drivers/base/power/domain_governor.c: In function ‘default_suspend_ok’: > ../drivers/base/power/domain_governor.c:82:17: error: ‘struct dev_pm_info’ > has no member named ‘ignore_children’ > > Signed-off-by: Randy Dunlap > Cc: Bjorn Andersson > Cc: Bjorn Andersson > Cc: Andy Gross > Cc: David Brown > --- > drivers/soc/qcom/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-next-20190614.orig/drivers/soc/qcom/Kconfig > +++ linux-next-20190614/drivers/soc/qcom/Kconfig > @@ -8,7 +8,7 @@ config QCOM_AOSS_QMP > tristate "Qualcomm AOSS Driver" > depends on ARCH_QCOM || COMPILE_TEST > depends on MAILBOX > - depends on COMMON_CLK > + depends on COMMON_CLK && PM > select PM_GENERIC_DOMAINS > help > This driver provides the means of communicating with and controlling > >
Re: [PATCH v2 4/5] x86/bpf: Fix 64-bit JIT frame pointer usage
On Fri, Jun 14, 2019 at 9:27 PM Josh Poimboeuf wrote: > > On Fri, Jun 14, 2019 at 05:02:36PM -0700, Alexei Starovoitov wrote: > > On Fri, Jun 14, 2019 at 4:54 PM Josh Poimboeuf wrote: > > > The previous patch you posted has my patch description, push/pop and > > > comment changes, with no credit: > > > > > > https://lkml.kernel.org/r/20190614210555.q4ictql3tzzji...@ast-mbp.dhcp.thefacebook.com > > > > I'm sorry for reusing one sentence from your commit log and > > not realizing you want credit for that. > > Will not happen again. > > Um. What are you talking about? The entire patch was clearly derived > from mine. Not just "one sentence from your commit log". The title, > the pushes/pops in the prologue/epilogue, the removal of the > "ebpf_from_cbpf" argument, the code spacing, and some of the non trivial > comment changes were the same. > > > I also suggest you never touch anything bpf related. > > Just to avoid this credit claims and threads like this one. > > Wth. I made a simple request for credit. Anybody can see the patch was > derived from mine. It's not like I really care. It's just basic human > decency. derived? do you really think so ? Please fix your orc stuff that is still broken. Human decency is fixing stuff that you're responsible for. Your commit d15d356887e7 on April 23 broke stack traces. And we reported it 3 weeks ago. Yet instead of fixing it you kept arguing about JIT frame pointers that is orthogonal issue and was in this state for the last 2 years.
RE: [PATCHv5 18/20] PCI: mobiveil: Disable IB and OB windows set by bootloader
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 2019年6月13日 0:24
> To: Z.q. Hou ; bhelg...@google.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> catalin.mari...@arm.com; will.dea...@arm.com; Mingkai Hu
> ; M.h. Lian ; Xiaowei Bao
>
> Subject: Re: [PATCHv5 18/20] PCI: mobiveil: Disable IB and OB windows set
> by bootloader
>
> On Fri, Apr 12, 2019 at 08:37:00AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Disable all inbound and outbound windows before set up the windows in
> > kernel, in case transactions match the window set by bootloader.
>
> There must be no PCI transactions ongoing at bootloader<->OS handover.
>
Yes, exact.
> The bootloader needs fixing and this patch should be dropped, the host bridge
> driver assumes the host bridge state is disabled,
The host bridge driver should not assumes the host state is disabled, actually
u-boot enable/initialize the host and without disabling it when transfer the
control to Linux.
> it will program the bridge
> apertures from scratch with no ongoing transactions, anything deviating from
> this behaviour is a bootloader bug and a recipe for disaster.
The point of this patch is not to fix the ongoing transaction issue, it is to
avoid
a potential issue which is caused by the outbound window enabled by bootloader
overlapping with Linux enabled.
Thanks,
Zhiqiang
> Lorenzo
>
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - No functionality change.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 8dc87c7a600e..411e9779da12 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -565,6 +565,24 @@ static int mobiveil_bringup_link(struct
> mobiveil_pcie *pcie)
> > return -ETIMEDOUT;
> > }
> >
> > +static void mobiveil_pcie_disable_ib_win(struct mobiveil_pcie *pcie,
> > +int idx) {
> > + u32 val;
> > +
> > + val = csr_readl(pcie, PAB_PEX_AMAP_CTRL(idx));
> > + val &= ~(1 << AMAP_CTRL_EN_SHIFT);
> > + csr_writel(pcie, val, PAB_PEX_AMAP_CTRL(idx)); }
> > +
> > +static void mobiveil_pcie_disable_ob_win(struct mobiveil_pcie *pcie,
> > +int idx) {
> > + u32 val;
> > +
> > + val = csr_readl(pcie, PAB_AXI_AMAP_CTRL(idx));
> > + val &= ~(1 << WIN_ENABLE_SHIFT);
> > + csr_writel(pcie, val, PAB_AXI_AMAP_CTRL(idx)); }
> > +
> > static void mobiveil_pcie_enable_msi(struct mobiveil_pcie *pcie) {
> > phys_addr_t msg_addr = pcie->pcie_reg_base; @@ -585,6 +603,13 @@
> > static int mobiveil_host_init(struct mobiveil_pcie *pcie) {
> > u32 value, pab_ctrl, type;
> > struct resource_entry *win;
> > + int i;
> > +
> > + /* Disable all inbound/outbound windows */
> > + for (i = 0; i < pcie->apio_wins; i++)
> > + mobiveil_pcie_disable_ob_win(pcie, i);
> > + for (i = 0; i < pcie->ppio_wins; i++)
> > + mobiveil_pcie_disable_ib_win(pcie, i);
> >
> > /* setup bus numbers */
> > value = csr_readl(pcie, PCI_PRIMARY_BUS);
> > --
> > 2.17.1
> >
RE: [PATCH net] hvsock: fix epollout hang from race condition
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Dexuan Cui
> Sent: Friday, June 14, 2019 8:23 PM
> To: David Miller ; Sunil Muthuswamy
>
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; sas...@kernel.org; Michael Kelley
> ; net...@vger.kernel.org;
> linux-hyp...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH net] hvsock: fix epollout hang from race condition
>
> > From: linux-hyperv-ow...@vger.kernel.org
> > On Behalf Of David Miller
> > Sent: Friday, June 14, 2019 7:15 PM
> > To: Sunil Muthuswamy
> >
> > This adds lots of new warnings:
> >
> > net/vmw_vsock/hyperv_transport.c: In function ‘hvs_probe’:
> > net/vmw_vsock/hyperv_transport.c:205:20: warning: ‘vnew’ may be used
> > uninitialized in this function [-Wmaybe-uninitialized]
> >remote->svm_port = host_ephemeral_port++;
> >~^~~
> > net/vmw_vsock/hyperv_transport.c:332:21: note: ‘vnew’ was declared
> here
> > struct vsock_sock *vnew;
> > ^~~~
> > net/vmw_vsock/hyperv_transport.c:406:22: warning: ‘hvs_new’ may be
> > used uninitialized in this function [-Wmaybe-uninitialized]
> >hvs_new->vm_srv_id = *if_type;
> >~~~^~
> > net/vmw_vsock/hyperv_transport.c:333:23: note: ‘hvs_new’ was declared
> > here
> > struct hvsock *hvs, *hvs_new;
> >^~~
>
> Hi David,
> These warnings are not introduced by this patch from Sunil.
Well, technically speaking, the warnings are caused by Suni's patch, but I
think it should
be a bug of gcc (I'm using "gcc (Ubuntu 8.2.0-12ubuntu1) 8.2.0"). As you can
see, the
line numbers given by gcc, i.e. line 205, line 406, are not related to the
warnings.
Actually, the same warnings can repro with the below one-line patch on this
commit of
today's net.git:
9a33629ba6b2 ("hv_netvsc: Set probe mode to sync")
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -403,6 +403,7 @@ static void hvs_open_connection(struct vmbus_channel *chan)
set_per_channel_state(chan, conn_from_host ? new : sk);
vmbus_set_chn_rescind_callback(chan, hvs_close_connection);
+ asm ("nop");
if (conn_from_host) {
new->sk_state = TCP_ESTABLISHED;
It looks a simple inline assembly code can confuse gcc. I'm not sure if I should
report a bug for gcc...
I posted a patch to suppress these bogus warnings just now. The Subject is:
[PATCH net] hv_sock: Suppress bogus "may be used uninitialized" warnings
Thanks,
-- Dexuan
[PATCH net] hv_sock: Suppress bogus "may be used uninitialized" warnings
gcc 8.2.0 may report these bogus warnings under some condition: warning: ‘vnew’ may be used uninitialized in this function warning: ‘hvs_new’ may be used uninitialized in this function Actually, the 2 pointers are only initialized and used if the variable "conn_from_host" is true. The code is not buggy here. Signed-off-by: Dexuan Cui --- net/vmw_vsock/hyperv_transport.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c index 8d1ea9eda8a2..cd3f47f54fa7 100644 --- a/net/vmw_vsock/hyperv_transport.c +++ b/net/vmw_vsock/hyperv_transport.c @@ -329,8 +329,8 @@ static void hvs_open_connection(struct vmbus_channel *chan) struct sockaddr_vm addr; struct sock *sk, *new = NULL; - struct vsock_sock *vnew; - struct hvsock *hvs, *hvs_new; + struct vsock_sock *vnew = NULL; + struct hvsock *hvs, *hvs_new = NULL; int ret; if_type = >offermsg.offer.if_type; -- 2.19.1
Re: [PATCH V3] i2c: busses: tegra: Add suspend-resume support
> > Without a maintainer ack, this is an exception this time. Should we add > > Dmitry as another maintainer or reviewer at least? > > > I shall followup with Maintainer for ACK in future I2C tegra patches. This comment was not directed at you, sorry if that was not clear. It was more for Laxman, Thierry, Jonathan, and Dmitry (if he is interested). signature.asc Description: PGP signature
[PATCH 1/2] staging: rtl8723bs: hal: Using comparison to true is error prone
fix below issue reported by checkpatch
CHECK: Using comparison to true is error prone
CHECK: Using comparison to false is error prone
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
b/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
index 9cf8da7..215335c 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
@@ -17,8 +17,8 @@ static u8 rtw_sdio_wait_enough_TxOQT_space(struct adapter
*padapter, u8 agg_num)
while (pHalData->SdioTxOQTFreeSpace < agg_num) {
if (
- (padapter->bSurpriseRemoved == true) ||
- (padapter->bDriverStopped == true)
+ (padapter->bSurpriseRemoved) ||
+ (padapter->bDriverStopped)
) {
DBG_871X("%s: bSurpriseRemoved or bDriverStopped (wait
TxOQT)\n", __func__);
return false;
@@ -58,7 +58,7 @@ static s32 rtl8723_dequeue_writeport(struct adapter *padapter)
ret = ret || check_fwstate(pmlmepriv, _FW_UNDER_SURVEY);
- if (ret == true)
+ if (ret)
pxmitbuf = dequeue_pending_xmitbuf_under_survey(pxmitpriv);
else
pxmitbuf = dequeue_pending_xmitbuf(pxmitpriv);
@@ -85,7 +85,7 @@ static s32 rtl8723_dequeue_writeport(struct adapter *padapter)
query_free_page:
/* check if hardware tx fifo page is enough */
- if (false == rtw_hal_sdio_query_tx_freepage(pri_padapter, PageIdx,
pxmitbuf->pg_num)) {
+ if (!rtw_hal_sdio_query_tx_freepage(pri_padapter, PageIdx,
pxmitbuf->pg_num)) {
if (!bUpdatePageNum) {
/* Total number of page is NOT available, so update
current FIFO status */
HalQueryTxBufferStatus8723BSdio(padapter);
@@ -99,8 +99,8 @@ static s32 rtl8723_dequeue_writeport(struct adapter *padapter)
}
if (
- (padapter->bSurpriseRemoved == true) ||
- (padapter->bDriverStopped == true)
+ (padapter->bSurpriseRemoved) ||
+ (padapter->bDriverStopped)
) {
RT_TRACE(
_module_hal_xmit_c_,
@@ -153,7 +153,7 @@ s32 rtl8723bs_xmit_buf_handler(struct adapter *padapter)
return _FAIL;
}
- ret = (padapter->bDriverStopped == true) || (padapter->bSurpriseRemoved
== true);
+ ret = (padapter->bDriverStopped) || (padapter->bSurpriseRemoved);
if (ret) {
RT_TRACE(
_module_hal_xmit_c_,
@@ -170,7 +170,7 @@ s32 rtl8723bs_xmit_buf_handler(struct adapter *padapter)
queue_pending = check_pending_xmitbuf(pxmitpriv);
- if (queue_pending == false)
+ if (!queue_pending)
return _SUCCESS;
ret = rtw_register_tx_alive(padapter);
@@ -235,8 +235,8 @@ static s32 xmit_xmitframes(struct adapter *padapter, struct
xmit_priv *pxmitpriv
phwxmit = hwxmits + inx[idx];
if (
- (check_pending_xmitbuf(pxmitpriv) == true) &&
- (padapter->mlmepriv.LinkDetectInfo.bHigherBusyTxTraffic
== true)
+ (check_pending_xmitbuf(pxmitpriv)) &&
+ (padapter->mlmepriv.LinkDetectInfo.bHigherBusyTxTraffic)
) {
if ((phwxmit->accnt > 0) && (phwxmit->accnt < 5)) {
err = -2;
@@ -425,8 +425,8 @@ static s32 rtl8723bs_xmit_handler(struct adapter *padapter)
next:
if (
- (padapter->bDriverStopped == true) ||
- (padapter->bSurpriseRemoved == true)
+ (padapter->bDriverStopped) ||
+ (padapter->bSurpriseRemoved)
) {
RT_TRACE(
_module_hal_xmit_c_,
@@ -569,7 +569,7 @@ s32 rtl8723bs_hal_xmit(
(pxmitframe->attrib.ether_type != 0x888e) &&
(pxmitframe->attrib.dhcp_pkt != 1)
) {
- if (padapter->mlmepriv.LinkDetectInfo.bBusyTraffic == true)
+ if (padapter->mlmepriv.LinkDetectInfo.bBusyTraffic)
rtw_issue_addbareq_cmd(padapter, pxmitframe);
}
--
2.7.4
[PATCH 2/2] staging: rtl8723bs: hal: spaces preferred around unary operator
This patch fixes below issues reported by checkpatch
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '/' (ctx:VxV)
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
b/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
index 215335c..b44e902 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c
@@ -284,7 +284,7 @@ static s32 xmit_xmitframes(struct adapter *padapter, struct
xmit_priv *pxmitpriv
txlen = txdesc_size +
rtw_wlan_pkt_size(pxmitframe);
if( !pxmitbuf ||
((_RND(pxmitbuf->len, 8) + txlen) >
max_xmit_len) ||
- (k >=
(rtw_hal_sdio_max_txoqt_free_space(padapter)-1))
+ (k >=
(rtw_hal_sdio_max_txoqt_free_space(padapter) - 1))
) {
if (pxmitbuf) {
/* pxmitbuf->priv_data will be
NULL, and will crash here */
@@ -355,8 +355,8 @@ static s32 xmit_xmitframes(struct adapter *padapter, struct
xmit_priv *pxmitpriv
rtw_count_tx_stats(padapter,
pxmitframe, pxmitframe->attrib.last_txcmdsz);
txlen = txdesc_size +
pxmitframe->attrib.last_txcmdsz;
- pxmitframe->pg_num = (txlen + 127)/128;
- pxmitbuf->pg_num += (txlen + 127)/128;
+ pxmitframe->pg_num = (txlen + 127) /
128;
+ pxmitbuf->pg_num += (txlen + 127) / 128;
/* if (k != 1) */
/* ((struct
xmit_frame*)pxmitbuf->priv_data)->pg_num += pxmitframe->pg_num; */
pxmitbuf->ptail += _RND(txlen, 8); /*
round to 8 bytes alignment */
@@ -522,7 +522,7 @@ s32 rtl8723bs_mgnt_xmit(
rtl8723b_update_txdesc(pmgntframe, pmgntframe->buf_addr);
pxmitbuf->len = txdesc_size + pattrib->last_txcmdsz;
- pxmitbuf->pg_num = (pxmitbuf->len + 127)/128; /* 128 is tx page size */
+ pxmitbuf->pg_num = (pxmitbuf->len + 127) / 128; /* 128 is tx page size
*/
pxmitbuf->ptail = pmgntframe->buf_addr + pxmitbuf->len;
pxmitbuf->ff_hwaddr = rtw_get_ff_hwaddr(pmgntframe);
--
2.7.4
Re: [PATCH V3] i2c: busses: tegra: Add suspend-resume support
On 6/14/19 2:11 PM, Wolfram Sang wrote: On Thu, Jun 06, 2019 at 10:37:47PM -0700, Bitan Biswas wrote: Post suspend I2C registers have power on reset values. Before any transfer initialize I2C registers to prevent I2C transfer timeout and implement suspend and resume callbacks needed. Fix below errors post suspend: 1) Tegra I2C transfer timeout during jetson tx2 resume: [ 27.520613] pca953x 1-0074: calling pca953x_resume+0x0/0x1b0 @ 2939, parent: i2c-1 [ 27.633623] tegra-i2c 316.i2c: i2c transfer timed out [ 27.639162] pca953x 1-0074: Unable to sync registers 0x3-0x5. -110 [ 27.645336] pca953x 1-0074: Failed to sync GPIO dir registers: -110 [ 27.651596] PM: dpm_run_callback(): pca953x_resume+0x0/0x1b0 returns -110 [ 27.658375] pca953x 1-0074: pca953x_resume+0x0/0x1b0 returned -110 after 127152 usecs [ 27.666194] PM: Device 1-0074 failed to resume: error -110 2) Tegra I2C transfer timeout error on jetson Xavier post resume. Remove i2c bus lock-unlock calls in resume callback as i2c_mark_adapter_* (suspended-resumed) help ensure i2c core calls from client are not executed before i2c-tegra resume. Signed-off-by: Bitan Biswas Applied to for-next, thanks! Without a maintainer ack, this is an exception this time. Should we add Dmitry as another maintainer or reviewer at least? I shall followup with Maintainer for ACK in future I2C tegra patches. Probably maintainers or reviewers should comment here.
When SME is enabled on Dell PowerEdge R7425(AMD) machine, the first kernel can not successfully boot because of the megaraid_sas failure
Hi, On the Dell PowerEdge R7425(AMD) machine, when SME is enabled, the first kernel can not successfully boot because of the following failure: .. [ 211.950273] megaraid_sas :61:00.0: Init cmd return status FAILED for SCSI host 0 [ 211.982750] megaraid_sas :61:00.0: Failed from megasas_init_fw 5900 .. Please refer to the kernel log. Thanks. Lianbo Kernel log: [0.00] Linux version 5.2.0-rc4+ (r...@dell-per7425-02.khw.lab.eng.bos.redhat.com) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Fri Jun 14 23:28:09 EDT 2019 [0.00] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.2.0-rc4+ root=/dev/mapper/rhel_dell--per7425--02-root ro crashkernel=auto resume=/dev/mapper/rhel_dell--per7425--02-swap rd.lvm.lv=rhel_dell-per7425-02/root rd.lvm.lv=rhel_dell-per7425-02/swap console=ttyS0,115200n81 mem_encrypt=on [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0008efff] usable [0.00] BIOS-e820: [mem 0x0008f000-0x0008] ACPI NVS [0.00] BIOS-e820: [mem 0x0009-0x0009] usable [0.00] BIOS-e820: [mem 0x0010-0x6cacefff] usable [0.00] BIOS-e820: [mem 0x6cacf000-0x6efcefff] reserved [0.00] BIOS-e820: [mem 0x6efcf000-0x6fdfefff] ACPI NVS [0.00] BIOS-e820: [mem 0x6fdff000-0x6fffefff] ACPI data [0.00] BIOS-e820: [mem 0x6000-0x6fff] usable [0.00] BIOS-e820: [mem 0x7000-0x8fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed80fff] reserved [0.00] BIOS-e820: [mem 0x0001-0x00107eff] usable [0.00] BIOS-e820: [mem 0x00107f00-0x00107fff] reserved [0.00] NX (Execute Disable) protection: active [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0008efff] usable [0.00] reserve setup_data: [mem 0x0008f000-0x0008] ACPI NVS [0.00] reserve setup_data: [mem 0x0009-0x0009] usable [0.00] reserve setup_data: [mem 0x0010-0x49e2401f] usable [0.00] reserve setup_data: [mem 0x49e24020-0x49e8345f] usable [0.00] reserve setup_data: [mem 0x49e83460-0x49e8401f] usable [0.00] reserve setup_data: [mem 0x49e84020-0x49ee345f] usable [0.00] reserve setup_data: [mem 0x49ee3460-0x62c7801f] usable [0.00] reserve setup_data: [mem 0x62c78020-0x62c8f45f] usable [0.00] reserve setup_data: [mem 0x62c8f460-0x62c9001f] usable [0.00] reserve setup_data: [mem 0x62c90020-0x62c9805f] usable [0.00] reserve setup_data: [mem 0x62c98060-0x62c9901f] usable [0.00] reserve setup_data: [mem 0x62c99020-0x62cfb65f] usable [0.00] reserve setup_data: [mem 0x62cfb660-0x62cfc01f] usable [0.00] reserve setup_data: [mem 0x62cfc020-0x62d5e65f] usable [0.00] reserve setup_data: [mem 0x62d5e660-0x6cacefff] usable [0.00] reserve setup_data: [mem 0x6cacf000-0x6efcefff] reserved [0.00] reserve setup_data: [mem 0x6efcf000-0x6fdfefff] ACPI NVS [0.00] reserve setup_data: [mem 0x6fdff000-0x6fffefff] ACPI data [0.00] reserve setup_data: [mem 0x6000-0x6fff] usable [0.00] reserve setup_data: [mem 0x7000-0x8fff] reserved [0.00] reserve setup_data: [mem 0xfec1-0xfec10fff] reserved [0.00] reserve setup_data: [mem 0xfed8-0xfed80fff] reserved [0.00] reserve setup_data: [mem 0x0001-0x00107eff] usable [0.00] reserve setup_data: [mem 0x00107f00-0x00107fff] reserved [0.00] efi: EFI v2.50 by Dell Inc. [0.00] efi: ACPI=0x6fffe000 ACPI 2.0=0x6fffe014 SMBIOS=0x6eab3000 SMBIOS 3.0=0x6eab1000 [0.00] SMBIOS 3.0.0 present. [0.00] DMI: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.7.6 01/14/2019 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 1996.202 MHz processor [
Re: [PATCH v2 4/5] x86/bpf: Fix 64-bit JIT frame pointer usage
On Fri, Jun 14, 2019 at 05:02:36PM -0700, Alexei Starovoitov wrote: > On Fri, Jun 14, 2019 at 4:54 PM Josh Poimboeuf wrote: > > The previous patch you posted has my patch description, push/pop and > > comment changes, with no credit: > > > > https://lkml.kernel.org/r/20190614210555.q4ictql3tzzji...@ast-mbp.dhcp.thefacebook.com > > I'm sorry for reusing one sentence from your commit log and > not realizing you want credit for that. > Will not happen again. Um. What are you talking about? The entire patch was clearly derived from mine. Not just "one sentence from your commit log". The title, the pushes/pops in the prologue/epilogue, the removal of the "ebpf_from_cbpf" argument, the code spacing, and some of the non trivial comment changes were the same. > I also suggest you never touch anything bpf related. > Just to avoid this credit claims and threads like this one. Wth. I made a simple request for credit. Anybody can see the patch was derived from mine. It's not like I really care. It's just basic human decency. -- Josh
Re: [RFC] Disable lockref on arm64
tl;dr: if arm/arm64 can catch overflow, untested dec-to-zero, and inc-from-zero, while performing better than existing REFCOUNT_FULL, it's a no-brainer to switch. Minimum parity to x86 would be to catch overflow and untested dec-to-zero. Minimum viable protection would be to catch overflow. LKDTM is your friend. Details below... On Fri, Jun 14, 2019 at 11:38:50AM +0100, Will Deacon wrote: > On Fri, Jun 14, 2019 at 12:24:54PM +0200, Ard Biesheuvel wrote: > > On Fri, 14 Jun 2019 at 11:58, Will Deacon wrote: > > > On Fri, Jun 14, 2019 at 07:09:26AM +, Jayachandran Chandrasekharan > > > Nair wrote: > > > > x86 added a arch-specific fast refcount implementation - and the commit > > > > specifically notes that it is faster than cmpxchg based code[1]. > > > > > > > > There seems to be an ongoing effort to move over more and more > > > > subsystems > > > > from atomic_t to refcount_t(e.g.[2]), specifically because refcount_t on > > > > x86 is fast enough and you get some error checking atomic_t that does > > > > not > > > > have. For clarity: the choices on x86 are: full or fast, where both catch the condition that leads to use-after-free that can be unconditionally mitigated (i.e. refcount overflow-wrapping to zero: the common missing ref count decrement). The _underflow_ case (the less common missing ref count increment) can be exploited but nothing can be done to mitigate it. Only a later increment from zero can indicate that something went wrong _in the past_. There is not a way to build x86 without the overflow protection, and that was matched on arm/arm64 by making REFCOUNT_FULL unconditionally enabled. So, from the perspective of my take on weakening the protection level, I'm totally fine if arm/arm64 falls back to a non-FULL implementation as long as it catches the overflow case (which the prior "fast" patches totally did). > > > Correct, but there are also some cases that are only caught by > > > REFCOUNT_FULL. > > > > > Yes, but do note that my arm64 implementation catches > > increment-from-zero as well. FWIW, the vast majority of bugs that refcount_t has found has been inc-from-zero (the overflow case doesn't tend to ever get exercised, but it's easy for syzkaller and other fuzzers to underflow when such a path is found). And those are only found on REFCOUNT_FULL kernels presently, so it'd be nice to have that case covered in the "fast" arm/arm64 case too. > Ok, so it's just the silly racy cases that are problematic? > > > > > Do you think Ard's patch needs changes before it can be considered? I > > > > can take a look at that. > > > > > > I would like to see how it performs if we keep the checking inline, yes. > > > I suspect Ard could spin this in short order. > > > > Moving the post checks before the stores you mean? That shouldn't be > > too difficult, I suppose, but it will certainly cost performance. > > That's what I'd like to assess, since the major complaint seems to be the > use of cmpxchg() as opposed to inline branching. > > > > > > Whatever we do, I prefer to keep REFCOUNT_FULL the default option for > > > > > arm64, > > > > > so if we can't keep the semantics when we remove the cmpxchg, you'll > > > > > need to > > > > > opt into this at config time. > > > > > > > > Only arm64 and arm selects REFCOUNT_FULL in the default config. So > > > > please > > > > reconsider this! This is going to slow down arm64 vs. other archs and it > > > > will become worse when more code adopts refcount_t. > > > > > > Maybe, but faced with the choice between your micro-benchmark results and > > > security-by-default for people using the arm64 Linux kernel, I really > > > think > > > that's a no-brainer. I'm well aware that not everybody agrees with me on > > > that. > > > > I think the question whether the benchmark is valid is justified, but > > otoh, we are obsessed with hackbench which is not that representative > > of a real workload either. It would be better to discuss these changes > > in the context of known real-world use cases where refcounts are a > > true bottleneck. > > I wasn't calling into question the validity of the benchmark (I really have > no clue about that), but rather that you can't have your cake and eat it. > Faced with the choice, I'd err on the security side because it's far easier > to explain to somebody that the default is full mitigation at a cost than it > is to explain why a partial mitigation is acceptable (and in the end it's > often subjective because people have different thresholds). I'm happy to call into question the validity of the benchmark though! ;) Seriously, it came up repeatedly in the x86 port, where there was a claim of "it's slower" (which is certainly objectively true: more cycles are spent), but no one could present a real-world workload where the difference was measurable. > > Also, I'd like to have Kees's view on the gap between REFCOUNT_FULL > > and the fast version on arm64. I'm not convinced the cases we are not > > covering
Re: [GIT PULL] cgroup fixes for v5.2-rc4
The pull request you sent on Fri, 14 Jun 2019 13:02:53 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-5.2-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0011572c883082a95e02d47f45fc4a42dc0e8634 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: pagecache locking (was: bcachefs status update) merged)
On Thu, Jun 13, 2019 at 5:08 PM Linus Torvalds wrote: > > I do not believe that posix itself actually requires that at all, > although extended standards may. So I tried to see if I could find what this perhaps alludes to. And I suspect it's not in the read/write thing, but the pthreads side talks about atomicity. Interesting, but I doubt if that's actually really intentional, since the non-thread read/write behavior specifically seems to avoid the whole concurrency issue. The pthreads atomicity thing seems to be about not splitting up IO and doing it in chunks when you have m:n threading models, but can be (mis-)construed to have threads given higher atomicity guarantees than processes. Linus
RE: [RFC PATCH 0/1] security: add SECURE_KEEP_FSUID to preserve fsuid/fsgid across execve
On Sat, 15 Jun 2019, Lubashev, Igor wrote:
> > On Friday, June 14, 2019, James Morris wrote:
> Unfortunately, perf is using uid==0 and euid==0 as a "capability bits".
>
>
> In tools/perf/util/evsel.c:
> static bool perf_event_can_profile_kernel(void)
> {
> return geteuid() == 0 || perf_event_paranoid() == -1;
> }
>
> In tools/perf/util/symbol.c:
> static bool symbol__read_kptr_restrict(void)
> {
> ...
> value = ((geteuid() != 0) || (getuid() != 0)) ?
> (atoi(line) != 0) :
> (atoi(line) == 2);
> ...
> }
These are bugs. They should be checking for CAP_SYS_ADMIN.
>
> > Have you considered the example security configuration in
> > Documentation/admin-guide/perf-security.rst ?
>
> Unfortunately, this configuration does not work, unless you reset
> /proc/sys/kernel/perf_event_paranoid to a permissive level (see code
> above). We have perf_event_paranoid set to 2. If it worked, we could had
> implemented the same capability-based policy in the wrapper.
This is not necessary for a process which has CAP_SYS_ADMIN.
--
James Morris
RE: [PATCH net] hvsock: fix epollout hang from race condition
> From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of David Miller > Sent: Friday, June 14, 2019 7:15 PM > To: Sunil Muthuswamy > > This adds lots of new warnings: > > net/vmw_vsock/hyperv_transport.c: In function ‘hvs_probe’: > net/vmw_vsock/hyperv_transport.c:205:20: warning: ‘vnew’ may be used > uninitialized in this function [-Wmaybe-uninitialized] >remote->svm_port = host_ephemeral_port++; >~^~~ > net/vmw_vsock/hyperv_transport.c:332:21: note: ‘vnew’ was declared here > struct vsock_sock *vnew; > ^~~~ > net/vmw_vsock/hyperv_transport.c:406:22: warning: ‘hvs_new’ may be > used uninitialized in this function [-Wmaybe-uninitialized] >hvs_new->vm_srv_id = *if_type; >~~~^~ > net/vmw_vsock/hyperv_transport.c:333:23: note: ‘hvs_new’ was declared > here > struct hvsock *hvs, *hvs_new; >^~~ Hi David, These warnings are not introduced by this patch from Sunil. I'm not sure why I didn't notice these warnings before. Probably my gcc version is not new eought? Actually these warnings are bogus, as I checked the related functions, which may confuse the compiler's static analysis. I'm going to make a patch to initialize the pointers to NULL to suppress the warnings. My patch will be based on the latest's net.git + this patch from Sunil. Thanks, -- Dexuan
Re: [PATCH net-next v2 0/4] net: dsa: use switchdev attr and obj handlers
From: Vivien Didelot Date: Fri, 14 Jun 2019 13:49:18 -0400 > This series reduces boilerplate in the handling of switchdev attribute and > object operations by using the switchdev_handle_* helpers, which check the > targeted devices and recurse into their lower devices. > > This also brings back the ability to inspect operations targeting the bridge > device itself (where .orig_dev and .dev were originally the bridge device), > even though that is of no use yet and skipped by this series. > > Changes in v2: Only VLAN and (non-host) MDB objects not directly targeting > the slave device are unsupported at the moment, so only skip these cases. Series applied.
Re: [PATCH v2 1/2] x86/asm: Pin sensitive CR4 bits
On Fri, Jun 14, 2019 at 04:57:36PM +0200, Thomas Gleixner wrote:
> Wouldn't it make sense to catch situations where a regular caller provides
> @val with pinned bits unset? I.e. move the OR into this code path after
> storing bits_missing.
I mentioned this in the commit log, but maybe I wasn't very clear:
> > Since these bits are global state (once established by the boot CPU
> > and kernel boot parameters), they are safe to write to secondary CPUs
> > before those CPUs have finished feature detection. As such, the bits are
> > written with an "or" performed before the register write as that is both
> > easier and uses a few bytes less storage of a location we don't have:
> > read-only per-CPU data. (Note that initialization via cr4_init_shadow()
> > isn't early enough to avoid early native_write_cr4() calls.)
Basically, there are calls of native_write_cr4() made very early in
secondary CPU init that would hit the "eek missing bit" case, and using
the cr4_init_shadow() trick mentioned by Linus still wasn't early
enough. So, since feature detection for these bits is "done" (i.e.
secondary CPUs will match the boot CPU's for these bits), it's safe to
set them "early". To avoid this, we'd need a per-cpu "am I ready to set
these bits?" state, and it'd need to be read-only-after-init, which is
not a section that exists and seems wasteful to create (4095 bytes
unused) for this feature alone.
> Something like this:
>
> unsigned long bits_missing = 0;
>
> again:
> asm volatile("mov %0,%%cr4": "+r" (val), "+m" (cr4_pinned_bits));
>
> if (static_branch_likely(_pinning)) {
> if (unlikely((val & cr4_pinned_bits) != cr4_pinned_bits)) {
> bits_missing = ~val & cr4_pinned_bits;
> val |= cr4_pinned_bits;
> goto again;
> }
> /* Warn after we've set the missing bits. */
> WARN_ONCE(bits_missing, "CR4 bits went missing: %lx!?\n",
> bits_missing);
> }
Yup, that's actually exactly what I had tried. Should I try to track down
the very early callers and OR in the bits at the call sites instead? (This
had occurred to me also, but it seemed operationally equivalent to ORing
at the start of native_write_cr4(), so I didn't even bother trying it).
--
Kees Cook
Re: general protection fault in oom_unkillable_task
On Fri, Jun 14, 2019 at 6:08 PM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:3f310e51 Add linux-next specific files for 20190607 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=15ab8771a0 > kernel config: https://syzkaller.appspot.com/x/.config?x=5d176e1849bbc45 > dashboard link: https://syzkaller.appspot.com/bug?extid=d0fc9d3c166bc5e4a94b > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+d0fc9d3c166bc5e4a...@syzkaller.appspotmail.com > > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] PREEMPT SMP KASAN > CPU: 0 PID: 28426 Comm: syz-executor.5 Not tainted 5.2.0-rc3-next-20190607 > #11 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline] > RIP: 0010:has_intersects_mems_allowed mm/oom_kill.c:84 [inline] It seems like oom_unkillable_task() is broken for memcg OOMs. It should not be calling has_intersects_mems_allowed() for memcg OOMs. > RIP: 0010:oom_unkillable_task mm/oom_kill.c:168 [inline] > RIP: 0010:oom_unkillable_task+0x180/0x400 mm/oom_kill.c:155 > Code: c1 ea 03 80 3c 02 00 0f 85 80 02 00 00 4c 8b a3 10 07 00 00 48 b8 00 > 00 00 00 00 fc ff df 4d 8d 74 24 10 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f > 85 67 02 00 00 49 8b 44 24 10 4c 8d a0 68 fa ff ff > RSP: 0018:888000127490 EFLAGS: 00010a03 > RAX: dc00 RBX: 8880a4cd5438 RCX: 818dae9c > RDX: 1c3cc602 RSI: 818dac8d RDI: 0001 > RBP: 8880001274d0 R08: 88886180 R09: ed1015d26be0 > R10: ed1015d26bdf R11: 8880ae935efb R12: 800061e63007 > R13: R14: 800061e63017 R15: 11124ea6 > FS: 561f5940() GS:8880ae80() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 00607304 CR3: 9237e000 CR4: 001426f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0600 > Call Trace: > oom_evaluate_task+0x49/0x520 mm/oom_kill.c:321 > mem_cgroup_scan_tasks+0xcc/0x180 mm/memcontrol.c:1169 > select_bad_process mm/oom_kill.c:374 [inline] > out_of_memory mm/oom_kill.c:1088 [inline] > out_of_memory+0x6b2/0x1280 mm/oom_kill.c:1035 > mem_cgroup_out_of_memory+0x1ca/0x230 mm/memcontrol.c:1573 > mem_cgroup_oom mm/memcontrol.c:1905 [inline] > try_charge+0xfbe/0x1480 mm/memcontrol.c:2468 > mem_cgroup_try_charge+0x24d/0x5e0 mm/memcontrol.c:6073 > mem_cgroup_try_charge_delay+0x1f/0xa0 mm/memcontrol.c:6088 > do_huge_pmd_wp_page_fallback+0x24f/0x1680 mm/huge_memory.c:1201 > do_huge_pmd_wp_page+0x7fc/0x2160 mm/huge_memory.c:1359 > wp_huge_pmd mm/memory.c:3793 [inline] > __handle_mm_fault+0x164c/0x3eb0 mm/memory.c:4006 > handle_mm_fault+0x3b7/0xa90 mm/memory.c:4053 > do_user_addr_fault arch/x86/mm/fault.c:1455 [inline] > __do_page_fault+0x5ef/0xda0 arch/x86/mm/fault.c:1521 > do_page_fault+0x71/0x57d arch/x86/mm/fault.c:1552 > page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1156 > RIP: 0033:0x400590 > Code: 06 e9 49 01 00 00 48 8b 44 24 10 48 0b 44 24 28 75 1f 48 8b 14 24 48 > 8b 7c 24 20 be 04 00 00 00 e8 f5 56 00 00 48 8b 74 24 08 <89> 06 e9 1e 01 > 00 00 48 8b 44 24 08 48 8b 14 24 be 04 00 00 00 8b > RSP: 002b:7fff7bc49780 EFLAGS: 00010206 > RAX: 0001 RBX: 0076 RCX: > RDX: RSI: 2000cffc RDI: 0001 > RBP: fffe R08: R09: > R10: 0075 R11: 0246 R12: 00760008 > R13: 004c55f2 R14: R15: 7fff7bc499b0 > Modules linked in: > ---[ end trace a65689219582 ]--- > RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline] > RIP: 0010:has_intersects_mems_allowed mm/oom_kill.c:84 [inline] > RIP: 0010:oom_unkillable_task mm/oom_kill.c:168 [inline] > RIP: 0010:oom_unkillable_task+0x180/0x400 mm/oom_kill.c:155 > Code: c1 ea 03 80 3c 02 00 0f 85 80 02 00 00 4c 8b a3 10 07 00 00 48 b8 00 > 00 00 00 00 fc ff df 4d 8d 74 24 10 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f > 85 67 02 00 00 49 8b 44 24 10 4c 8d a0 68 fa ff ff > RSP: 0018:888000127490 EFLAGS: 00010a03 > RAX: dc00 RBX: 8880a4cd5438 RCX: 818dae9c > RDX: 1c3cc602 RSI: 818dac8d RDI: 0001 > RBP: 8880001274d0 R08: 88886180 R09: ed1015d26be0 > R10: ed1015d26bdf R11: 8880ae935efb R12: 800061e63007 > R13: R14: 800061e63017 R15: 11124ea6 > FS: 561f5940() GS:8880ae80()
Re: [PATCH -next] x86/amd_nb: Make hygon_nb_misc_ids static
On 2019/6/15 1:51, Borislav Petkov wrote: > On Fri, Jun 14, 2019 at 11:54:41PM +0800, YueHaibing wrote: >> Fix sparse warning: >> >> arch/x86/kernel/amd_nb.c:74:28: warning: >> symbol 'hygon_nb_misc_ids' was not declared. Should it be static? >> >> Reported-by: Hulk Robot > ^ > > Ha, what is that? :) > > A new test bot? Yes, our internal CI robot. >
Re: [PATCH 1/3] lib/vsprintf: add snprintf_noterm
On Sat, 2019-06-15 at 10:41 +0800, Yan, Zheng wrote: > On Fri, Jun 14, 2019 at 9:48 PM Jeff Layton wrote: > > The getxattr interface returns a length after filling out the value > > buffer, and the convention with xattrs is to not NULL terminate string > > data. > > > > CephFS implements some virtual xattrs by using snprintf to fill the > > buffer, but that always NULL terminates the string. If userland sends > > down a buffer that is just the right length to hold the text without > > termination then we end up truncating the value. > > > > Factor the formatting piece of vsnprintf into a separate helper > > function, and have vsnprintf call that and then do the NULL termination > > afterward. Then add a snprintf_noterm function that calls the new helper > > to populate the string but skips the termination. Is this function really necessary enough to add the additional stack use to the generic case? Why not add have this function call vsnprintf and then terminate the string separately?
Re: [PATCH next] of/fdt: Fix defined but not used compiler warning
On 2019/6/14 21:53, Rob Herring wrote: > On Wed, Jun 12, 2019 at 12:29 PM Frank Rowand wrote: >> >> On 6/12/19 10:00 AM, Rob Herring wrote: >>> On Wed, Jun 12, 2019 at 10:45 AM Frank Rowand >>> wrote: Hi Kefeng, If Rob agrees, I'd like to see one more change in this patch. Since the only caller of of_fdt_match() is of_flat_dt_match(), can you move the body of of_fdt_match() into of_flat_dt_match() and eliminate of_fdt_match()? >>> >>> That's fine as long as we think there's never any use for of_fdt_match >>> after init? Fixup of nodes in an overlay for example. >> >> We can always re-expose the functionality as of_fdt_match() in the future >> if the need arises. But Stephen's recent patch was moving in the opposite >> direction, removing of_fdt_match() from the header file and making it >> static. > > Yes, we can, but it is just churn if we think it is likely needed. > > OTOH, we probably want users to just use libfdt API directly and > should add this to libfdt if needed. > > So yes, please implement Frank's suggestion. OK，done in patch v2. > > Rob > > . >
[PATCH] fsi: cf-fsi-fw: Use the correct style for SPDX License Identifier
This patch corrects the SPDX License Identifier style in header file related to Drivers for FRU Support Interface. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 Suggested-by: Joe Perches Signed-off-by: Nishad Kamdar --- drivers/fsi/cf-fsi-fw.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fsi/cf-fsi-fw.h b/drivers/fsi/cf-fsi-fw.h index 712df0461911..1118eaf7ee39 100644 --- a/drivers/fsi/cf-fsi-fw.h +++ b/drivers/fsi/cf-fsi-fw.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0+ +/* SPDX-License-Identifier: GPL-2.0+ */ #ifndef __CF_FSI_FW_H #define __CF_FSI_FW_H -- 2.17.1
[PATCH next v2] of/fdt: Fix defined but not used compiler warning
When CONFIG_OF_EARLY_FLATTREE is disabled, there is a compiler
warning,
drivers/of/fdt.c:129:19: warning: ‘of_fdt_match’ defined but not used
[-Wunused-function]
static int __init of_fdt_match(const void *blob, unsigned long node,
Since the only caller of of_fdt_match() is of_flat_dt_match(),
let's move the body of of_fdt_match() into of_flat_dt_match()
and eliminate of_fdt_match().
Meanwhile, move of_fdt_is_compatible() under CONFIG_OF_EARLY_FLATTREE,
as all callers are over there.
Cc: Stephen Boyd
Cc: Rob Herring
Cc: Frank Rowand
Signed-off-by: Kefeng Wang
---
v2:
-Move the body of of_fdt_match() into of_flat_dt_match(), suggested by Frank.
drivers/of/fdt.c | 99 ++--
1 file changed, 45 insertions(+), 54 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 3d36b5afd9bd..cd17dc62a719 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -78,38 +78,6 @@ void __init of_fdt_limit_memory(int limit)
}
}
-/**
- * of_fdt_is_compatible - Return true if given node from the given blob has
- * compat in its compatible list
- * @blob: A device tree blob
- * @node: node to test
- * @compat: compatible string to compare with compatible list.
- *
- * On match, returns a non-zero value with smaller values returned for more
- * specific compatible values.
- */
-static int of_fdt_is_compatible(const void *blob,
- unsigned long node, const char *compat)
-{
- const char *cp;
- int cplen;
- unsigned long l, score = 0;
-
- cp = fdt_getprop(blob, node, "compatible", );
- if (cp == NULL)
- return 0;
- while (cplen > 0) {
- score++;
- if (of_compat_cmp(cp, compat, strlen(compat)) == 0)
- return score;
- l = strlen(cp) + 1;
- cp += l;
- cplen -= l;
- }
-
- return 0;
-}
-
static bool of_fdt_device_is_available(const void *blob, unsigned long node)
{
const char *status = fdt_getprop(blob, node, "status", NULL);
@@ -123,27 +91,6 @@ static bool of_fdt_device_is_available(const void *blob,
unsigned long node)
return false;
}
-/**
- * of_fdt_match - Return true if node matches a list of compatible values
- */
-static int __init of_fdt_match(const void *blob, unsigned long node,
- const char *const *compat)
-{
- unsigned int tmp, score = 0;
-
- if (!compat)
- return 0;
-
- while (*compat) {
- tmp = of_fdt_is_compatible(blob, node, *compat);
- if (tmp && (score == 0 || (tmp < score)))
- score = tmp;
- compat++;
- }
-
- return score;
-}
-
static void *unflatten_dt_alloc(void **mem, unsigned long size,
unsigned long align)
{
@@ -764,6 +711,38 @@ const void *__init of_get_flat_dt_prop(unsigned long node,
const char *name,
return fdt_getprop(initial_boot_params, node, name, size);
}
+/**
+ * of_fdt_is_compatible - Return true if given node from the given blob has
+ * compat in its compatible list
+ * @blob: A device tree blob
+ * @node: node to test
+ * @compat: compatible string to compare with compatible list.
+ *
+ * On match, returns a non-zero value with smaller values returned for more
+ * specific compatible values.
+ */
+static int of_fdt_is_compatible(const void *blob,
+ unsigned long node, const char *compat)
+{
+ const char *cp;
+ int cplen;
+ unsigned long l, score = 0;
+
+ cp = fdt_getprop(blob, node, "compatible", );
+ if (cp == NULL)
+ return 0;
+ while (cplen > 0) {
+ score++;
+ if (of_compat_cmp(cp, compat, strlen(compat)) == 0)
+ return score;
+ l = strlen(cp) + 1;
+ cp += l;
+ cplen -= l;
+ }
+
+ return 0;
+}
+
/**
* of_flat_dt_is_compatible - Return true if given node has compat in
compatible list
* @node: node to test
@@ -779,7 +758,19 @@ int __init of_flat_dt_is_compatible(unsigned long node,
const char *compat)
*/
static int __init of_flat_dt_match(unsigned long node, const char *const
*compat)
{
- return of_fdt_match(initial_boot_params, node, compat);
+ unsigned int tmp, score = 0;
+
+ if (!compat)
+ return 0;
+
+ while (*compat) {
+ tmp = of_fdt_is_compatible(initial_boot_params, node, *compat);
+ if (tmp && (score == 0 || (tmp < score)))
+ score = tmp;
+ compat++;
+ }
+
+ return score;
}
/**
--
2.20.1
Re: [PATCH net] hv_netvsc: Set probe mode to sync
From: Haiyang Zhang
Date: Thu, 13 Jun 2019 21:06:53 +
> For better consistency of synthetic NIC names, we set the probe mode to
> PROBE_FORCE_SYNCHRONOUS. So the names can be aligned with the vmbus
> channel offer sequence.
>
> Fixes: af0a5646cb8d ("use the new async probing feature for the hyperv
> drivers")
> Signed-off-by: Haiyang Zhang
Applied and queued up for -stable.
Re: [PATCH v2] arm64/mm: Correct the cache line size warning with non coherent device
Hi Masayoshi,
A few trivial comments inline.
On 2019/6/14 21:11, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> If the cache line size is greater than ARCH_DMA_MINALIGN (128),
> the warning shows and it's tainted as TAINT_CPU_OUT_OF_SPEC.
>
> However, it's not good because as discussed in the thread [1], the cpu
> cache line size will be problem only on non-coherent devices.
>
> Since the coherent flag is already introduced to struct device,
> show the warning only if the device is non-coherent device and
> ARCH_DMA_MINALIGN is smaller than the cpu cache size.
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20180514145703.celnlobzn3uh5tc2@localhost/
>
> Signed-off-by: Masayoshi Mizuma
> Reviewed-by: Hidetoshi Seto
> Tested-by: Zhang Lei
> ---
> arch/arm64/include/asm/cache.h | 7 +++
> arch/arm64/kernel/cacheinfo.c | 4 +---
> arch/arm64/mm/dma-mapping.c| 14 ++
> 3 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
> index 758af6340314..d24b7c1ecd9b 100644
> --- a/arch/arm64/include/asm/cache.h
> +++ b/arch/arm64/include/asm/cache.h
> @@ -91,6 +91,13 @@ static inline u32 cache_type_cwg(void)
>
> #define __read_mostly __attribute__((__section__(".data..read_mostly")))
>
> +static inline int cache_line_size_of_cpu(void)
> +{
> + u32 cwg = cache_type_cwg();
> +
> + return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
> +}
> +
> int cache_line_size(void);
>
> /*
> diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
> index 6eaf1c07aa4e..7fa6828bb488 100644
> --- a/arch/arm64/kernel/cacheinfo.c
> +++ b/arch/arm64/kernel/cacheinfo.c
> @@ -19,12 +19,10 @@
>
> int cache_line_size(void)
> {
> - u32 cwg = cache_type_cwg();
> -
> if (coherency_max_size != 0)
> return coherency_max_size;
>
> - return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
> + return cache_line_size_of_cpu();
> }
How about simplify it as this?
int cache_line_size(void)
{
return coherency_max_size ? coherency_max_size :
cache_line_size_of_cpu();
}
> EXPORT_SYMBOL_GPL(cache_line_size);
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 1669618db08a..379589dc7113 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -38,10 +38,6 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
>
> static int __init arm64_dma_init(void)
> {
> - WARN_TAINT(ARCH_DMA_MINALIGN < cache_line_size(),
> -TAINT_CPU_OUT_OF_SPEC,
> -"ARCH_DMA_MINALIGN smaller than CTR_EL0.CWG (%d < %d)",
> -ARCH_DMA_MINALIGN, cache_line_size());
> return dma_atomic_pool_init(GFP_DMA32, __pgprot(PROT_NORMAL_NC));
> }
> arch_initcall(arm64_dma_init);
> @@ -56,7 +52,17 @@ void arch_teardown_dma_ops(struct device *dev)
> void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> const struct iommu_ops *iommu, bool coherent)
> {
> + int cls = cache_line_size_of_cpu();
whether we need this local variable, how about use cache_line_size_of_cpu
directly in WARN_TAINT just like before.
Thanks,
Shaokun
> +
> dev->dma_coherent = coherent;
> +
> + if (!coherent)
> + WARN_TAINT(cls > ARCH_DMA_MINALIGN,
> + TAINT_CPU_OUT_OF_SPEC,
> + "%s %s: ARCH_DMA_MINALIGN smaller than CTR_EL0.CWG (%d
> < %d)",
> + dev_driver_string(dev), dev_name(dev),
> + ARCH_DMA_MINALIGN, cls);
> +
> if (iommu)
> iommu_setup_dma_ops(dev, dma_base, size);
>
>
Re: [PATCH 1/3] lib/vsprintf: add snprintf_noterm
On Fri, Jun 14, 2019 at 9:48 PM Jeff Layton wrote:
>
> The getxattr interface returns a length after filling out the value
> buffer, and the convention with xattrs is to not NULL terminate string
> data.
>
> CephFS implements some virtual xattrs by using snprintf to fill the
> buffer, but that always NULL terminates the string. If userland sends
> down a buffer that is just the right length to hold the text without
> termination then we end up truncating the value.
>
> Factor the formatting piece of vsnprintf into a separate helper
> function, and have vsnprintf call that and then do the NULL termination
> afterward. Then add a snprintf_noterm function that calls the new helper
> to populate the string but skips the termination.
>
> Signed-off-by: Jeff Layton
> ---
> include/linux/kernel.h | 2 +
> lib/vsprintf.c | 145 -
> 2 files changed, 103 insertions(+), 44 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 2d14e21c16c0..2f305a347482 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -462,6 +462,8 @@ extern int num_to_str(char *buf, int size,
> extern __printf(2, 3) int sprintf(char *buf, const char * fmt, ...);
> extern __printf(2, 0) int vsprintf(char *buf, const char *, va_list);
> extern __printf(3, 4)
> +int snprintf_noterm(char *buf, size_t size, const char *fmt, ...);
> +extern __printf(3, 4)
> int snprintf(char *buf, size_t size, const char *fmt, ...);
> extern __printf(3, 0)
> int vsnprintf(char *buf, size_t size, const char *fmt, va_list args);
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 791b6fa36905..ad5f4990eda3 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2296,53 +2296,24 @@ set_precision(struct printf_spec *spec, int prec)
> }
>
> /**
> - * vsnprintf - Format a string and place it in a buffer
> + * vsnprintf_noterm - Format a string and place it in a buffer without NULL
> + * terminating it
> * @buf: The buffer to place the result into
> - * @size: The size of the buffer, including the trailing null space
> + * @end: The end of the buffer
> * @fmt: The format string to use
> * @args: Arguments for the format string
> *
> - * This function generally follows C99 vsnprintf, but has some
> - * extensions and a few limitations:
> - *
> - * - ``%n`` is unsupported
> - * - ``%p*`` is handled by pointer()
> - *
> - * See pointer() or Documentation/core-api/printk-formats.rst for more
> - * extensive description.
> - *
> - * **Please update the documentation in both places when making changes**
> - *
> - * The return value is the number of characters which would
> - * be generated for the given input, excluding the trailing
> - * '\0', as per ISO C99. If you want to have the exact
> - * number of characters written into @buf as return value
> - * (not including the trailing '\0'), use vscnprintf(). If the
> - * return is greater than or equal to @size, the resulting
> - * string is truncated.
> - *
> - * If you're not already dealing with a va_list consider using snprintf().
> + * See the documentation over vsnprintf. This function does NOT add any NULL
> + * termination to the buffer. The caller must do that if necessary.
> */
> -int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
> +static int vsnprintf_noterm(char *buf, char *end, const char *fmt,
> + va_list args)
> {
> unsigned long long num;
> - char *str, *end;
> + char *str;
> struct printf_spec spec = {0};
>
> - /* Reject out-of-range values early. Large positive sizes are
> - used for unknown buffer sizes. */
> - if (WARN_ON_ONCE(size > INT_MAX))
> - return 0;
> -
> str = buf;
> - end = buf + size;
> -
> - /* Make sure end is always >= buf */
> - if (end < buf) {
> - end = ((void *)-1);
> - size = end - buf;
> - }
> -
> while (*fmt) {
> const char *old_fmt = fmt;
> int read = format_decode(fmt, );
> @@ -2462,18 +2433,69 @@ int vsnprintf(char *buf, size_t size, const char
> *fmt, va_list args)
> str = number(str, end, num, spec);
> }
> }
> -
> out:
> + /* the trailing null byte doesn't count towards the total */
> + return str-buf;
> +}
> +EXPORT_SYMBOL(vsnprintf_noterm);
export static function?
> +
> +/**
> + * vsnprintf - Format a string and place it in a buffer
> + * @buf: The buffer to place the result into
> + * @size: The size of the buffer, including the trailing null space
> + * @fmt: The format string to use
> + * @args: Arguments for the format string
> + *
> + * This function generally follows C99 vsnprintf, but has some
> + * extensions and a few limitations:
> + *
> + * - ``%n`` is unsupported
> + * - ``%p*`` is handled by pointer()
> + *
> + * See pointer() or
RE: [PATCHv5 17/20] PCI: mobiveil: Complete initialization of host even if no PCIe link
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 2019年6月12日 22:35
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 17/20] PCI: mobiveil: Complete initialization of host
> even if no PCIe link
>
> On Fri, Apr 12, 2019 at 08:36:54AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Sometimes there is not a PCIe Endpoint stalled in the slot, so do not
> > exit when the PCIe link is not up. And degrade the print level of link
> > up info.
>
> So what's the point of probing if the link does not initialize ?
A simple case is plug in a PCIe device after the Linux boot up, then rescan the
device.
If exit when PCIe link is not up, the PCIe controller is not initialized
completely, the
rescan cannot work.
Thanks,
Zhiqiang
> Lorenzo
>
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 1ee3ea2570c0..8dc87c7a600e 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -560,7 +560,7 @@ static int mobiveil_bringup_link(struct
> mobiveil_pcie *pcie)
> > usleep_range(LINK_WAIT_MIN, LINK_WAIT_MAX);
> > }
> >
> > - dev_err(>pdev->dev, "link never came up\n");
> > + dev_info(>pdev->dev, "link never came up\n");
> >
> > return -ETIMEDOUT;
> > }
> > @@ -926,10 +926,8 @@ static int mobiveil_pcie_probe(struct
> platform_device *pdev)
> > bridge->swizzle_irq = pci_common_swizzle;
> >
> > ret = mobiveil_bringup_link(pcie);
> > - if (ret) {
> > + if (ret)
> > dev_info(dev, "link bring-up failed\n");
> > - goto error;
> > - }
> >
> > /* setup the kernel resources for the newly added PCIe root bus */
> > ret = pci_scan_root_bus_bridge(bridge);
> > --
> > 2.17.1
> >
Re: [PATCH net-next 0/2] enable and use static_branch_deferred_inc
From: Willem de Bruijn Date: Thu, 13 Jun 2019 11:08:14 -0400 > From: Willem de Bruijn > > 1. make static_branch_deferred_inc available if !CONFIG_JUMP_LABEL > 2. convert the existing STATIC_KEY_DEFERRED_FALSE user to this api Series applied.
Re: [PATCH v3] net: dsa: fix warning same module names
From: Anders Roxell Date: Thu, 13 Jun 2019 13:35:03 +0200 > When building with CONFIG_NET_DSA_REALTEK_SMI and CONFIG_REALTEK_PHY > enabled as loadable modules, we see the following warning: > > warning: same module names found: > drivers/net/phy/realtek.ko > drivers/net/dsa/realtek.ko > > Rework so the driver name is realtek-smi instead of realtek. > > Reviewed-by: Linus Walleij > Reviewed-by: Andrew Lunn > Signed-off-by: Anders Roxell Applied.
Re: [PATCH net-next 00/12] net: hns3: some code optimizations & cleanups & bugfixes
From: Huazhong Tan Date: Thu, 13 Jun 2019 17:12:20 +0800 > This patch-set includes code optimizations, cleanups and bugfixes for > the HNS3 ethernet controller driver. > > [patch 1/12 - 6/12] adds some code optimizations and bugfixes about RAS > and MSI-X HW error. > > [patch 7/12] fixes a loading issue. > > [patch 8/12 - 11/12] adds some bugfixes. > > [patch 12/12] adds some cleanups, which does not change the logic of code. Series applied.
Re: [PATCH net] hvsock: fix epollout hang from race condition
This adds lots of new warnings: net/vmw_vsock/hyperv_transport.c: In function ‘hvs_probe’: net/vmw_vsock/hyperv_transport.c:205:20: warning: ‘vnew’ may be used uninitialized in this function [-Wmaybe-uninitialized] remote->svm_port = host_ephemeral_port++; ~^~~ net/vmw_vsock/hyperv_transport.c:332:21: note: ‘vnew’ was declared here struct vsock_sock *vnew; ^~~~ net/vmw_vsock/hyperv_transport.c:406:22: warning: ‘hvs_new’ may be used uninitialized in this function [-Wmaybe-uninitialized] hvs_new->vm_srv_id = *if_type; ~~~^~ net/vmw_vsock/hyperv_transport.c:333:23: note: ‘hvs_new’ was declared here struct hvsock *hvs, *hvs_new; ^~~
Re: [PATCH net-next v2 1/1] net: stmmac: use GPIO descriptors in stmmac_mdio_reset
From: Martin Blumenstingl Date: Wed, 12 Jun 2019 21:31:15 +0200 > Switch stmmac_mdio_reset to use GPIO descriptors. GPIO core handles the > "snps,reset-gpio" for GPIO descriptors so we don't need to take care of > it inside the driver anymore. > > The advantage of this is that we now preserve the GPIO flags which are > passed via devicetree. This is required on some newer Amlogic boards > which use an Open Drain pin for the reset GPIO. This pin can only output > a LOW signal or switch to input mode but it cannot output a HIGH signal. > There are already devicetree bindings for these special cases and GPIO > core already takes care of them but only if we use GPIO descriptors > instead of GPIO numbers. > > Signed-off-by: Martin Blumenstingl > Reviewed-by: Linus Walleij Applied.
Re: [PULL REQUEST] i2c for 5.2
The pull request you sent on Fri, 14 Jun 2019 18:45:53 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5dcedf4600f8708150b89485d25cead88bff08a4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] SCSI fixes for 5.2-rc4
The pull request you sent on Fri, 14 Jun 2019 15:24:03 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1ed1fa5f9c311a74f031cabb18a415b4defdfa03 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH net-next] net: ethernet: ti: cpsw_ethtool: simplify slave loops
From: Ivan Khoronzhuk Date: Wed, 12 Jun 2019 00:59:40 +0300 > Only for consistency reasons, do it like in main cpsw.c module > and use ndev reference but not by means of slave. > > Signed-off-by: Ivan Khoronzhuk Applied.
Re: [PATCH net-next] net: ethernet: ti: cpsw: use cpsw as drv data
From: Ivan Khoronzhuk Date: Wed, 12 Jun 2019 00:49:03 +0300 > No need to set ndev for drvdata when mainly cpsw reference is needed, > so correct this legacy decision. > > Reviewed-by: Grygorii Strashko > Signed-off-by: Ivan Khoronzhuk > --- > > Based on net-next/master Applied.
RE: [PATCHv5 04/20] PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 2019年6月12日 21:08
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> MSI_FLAG_MULTI_PCI_MSI
>
> On Wed, Jun 12, 2019 at 11:34:51AM +, Z.q. Hou wrote:
> > Hi Lorenzo,
> >
> > Thanks a lot for your comments!
> >
> > > -Original Message-
> > > From: Lorenzo Pieralisi
> > > Sent: 2019年6月12日 1:00
> > > To: Z.q. Hou
> > > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> > > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> > > ; catalin.mari...@arm.com;
> will.dea...@arm.com;
> > > Mingkai Hu ; M.h. Lian
> ;
> > > Xiaowei Bao
> > > Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> > > MSI_FLAG_MULTI_PCI_MSI
> > >
> > > On Fri, Apr 12, 2019 at 08:35:36AM +, Z.q. Hou wrote:
> > > > From: Hou Zhiqiang
> > > >
> > > > The current code does not support multiple MSIs, so remove the
> > > > corresponding flag from the msi_domain_info structure.
> > >
> > > Please explain me what's the problem before removing multi MSI support.
> >
> > NXP LX2 PCIe use the GIC-ITS instead of Mobiveil IP internal MSI
> > controller, so, I didn't encounter problem.
>
> Well, you sent a patch to fix an issue, explain me the issue you are fixing
> then,
> aka what have you sent this patch for ?
I did not face issue, as I have explained NXP does not use the Mobiveil IP's
MSI controller.
But obviously the MSI allocate function does not support multiple MSI, so I
submitted this patch.
Thanks,
Zhiqiang
>
> Lorenzo
>
> > Subbu, did you test with Endpoint supporting multi MSI?
> >
> > Thanks,
> > Zhiqiang
> >
> > >
> > > Thanks,
> > > Lorenzo
> > >
> > > > Fixes: 1e913e58335f ("PCI: mobiveil: Add MSI support")
> > > > Signed-off-by: Hou Zhiqiang
> > > > Reviewed-by: Minghuan Lian
> > > > ---
> > > > V5:
> > > > - Corrected the subject.
> > > >
> > > > drivers/pci/controller/pcie-mobiveil.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > > > b/drivers/pci/controller/pcie-mobiveil.c
> > > > index 563210e731d3..a0dd337c6214 100644
> > > > --- a/drivers/pci/controller/pcie-mobiveil.c
> > > > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > > > @@ -703,7 +703,7 @@ static struct irq_chip mobiveil_msi_irq_chip =
> > > > {
> > > >
> > > > static struct msi_domain_info mobiveil_msi_domain_info = {
> > > > .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> > > MSI_FLAG_USE_DEF_CHIP_OPS |
> > > > - MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
> > > > + MSI_FLAG_PCI_MSIX),
> > > > .chip = _msi_irq_chip,
> > > > };
> > > >
> > > > --
> > > > 2.17.1
> > > >
Re: [PATCH] MAINTAINERS: Update my email address to use @kernel.org
On Fri, Jun 14, 2019 at 6:21 AM Will Deacon wrote: > > When I say "stop working" I really mean "will go to my line manager", so > send patches there at your peril because they may reply with roadmaps > and spreadsheets. You have been warned. Oh we'd better avoid _that_. > Unless Linus wants to pick this up directly, I can include it in the > arm64 pull request next week. Just thought I'd send it out now as an > 'FYI' for the people on CC. I'll wait for the real pull request, it doesn't look like this is timing crtitical yet. And at worst, I'm sure I can handle a spreadsheet or two. But now I'm replying to your arm.com email anyway, because that's what the Reply-to was set for. Linus
RE: [RFC PATCH 0/1] security: add SECURE_KEEP_FSUID to preserve fsuid/fsgid across execve
> On Friday, June 14, 2019, James Morris wrote:
> On Thu, 13 Jun 2019, Igor Lubashev wrote:
>
> > I've posted this in March but received no response. Reposting.
> >
> > This patch introduces SECURE_KEEP_FSUID to allow fsuid/fsgid to be
> > preserved across execve. It is currently impossible to execve a
> > program such that effective and filesystem uid differ.
> >
> > The need for this functionality arose from a desire to allow certain
> > non-privileged users to run perf. To do this, we install perf without
> > set-uid-root and have a set-uid-root wrapper decide who is allowed to
> > run perf (and with what arguments).
> >
> > The wrapper must execve perf with real and effective root uid, because
> > perf and KASLR require this. However, that presently resets fsuid to
> > root, giving the user ability to read and overwrite any file owned by
> > root (perf report -i, perf record -o). Also, perf record will create
> > perf.data that cannot be deleted by the user.
> >
> > We cannot reset /proc/sys/kernel/perf_event_paranoid to a permissive
> > level, since we must be selective which users have the permissions.
> >
> > Of course, we could fix our problem by a patch to perf to allow
> > passing a username on the command line and having perf execute
> > setfsuid before opening files. However, perf is not the only program
> > that uses kernel features that require root uid/euid, so a general
> > solution that does not involve updating all such programs seems
> > warranted.
> This seems like a very specific corner case, depending on fsuid!=0 for an
> euid=0 process, along with a whitelist policy for perf arguments. It would be
> a
> great way to escalate to root via a bug in an executed app or via a wrapper
> misconfiguration.
Any set-uid-root app is a hazard. This wrapper's purpose is to reduce the risk
inherent in running apps with elevated privs.
It removes all capabilities (CAT_SETUID, CAT_SETPCAP, CAP_DAC_OVERRIDE, etc.)
except for the required ones before execve(). It has a list of users allowed
run apps (and a per-user whitelist of arguments, and it manages resources and
time used by apps).
The wrapper works great for things like tcpdump -- it is executed with the
user's uid and just CAP_NET_CAP and CAP_NET_ADMIN set.
Unfortunately, perf is using uid==0 and euid==0 as a "capability bits".
In tools/perf/util/evsel.c:
static bool perf_event_can_profile_kernel(void)
{
return geteuid() == 0 || perf_event_paranoid() == -1;
}
In tools/perf/util/symbol.c:
static bool symbol__read_kptr_restrict(void)
{
...
value = ((geteuid() != 0) || (getuid() != 0)) ?
(atoi(line) != 0) :
(atoi(line) == 2);
...
}
> Have you considered the example security configuration in
> Documentation/admin-guide/perf-security.rst ?
Unfortunately, this configuration does not work, unless you reset
/proc/sys/kernel/perf_event_paranoid to a permissive level (see code above). We
have perf_event_paranoid set to 2. If it worked, we could had implemented the
same capability-based policy in the wrapper.
> It also adds complexity to kernel credential handling -- it's yet another
> thing
> to consider when trying to reason about this.
I really wish that there were only two concepts that mattered: capability sets
and fsuid/fsgid. The proposed patch allows one to switch to such mode -- a much
simpler mode. Yes, the patch does add a "new feature", but what matters most
for the complexity question is whether this feature is a move in the right
direction. I am leaning that way, but I am not 100% positive -- hence this RFC
patch.
> What are some other examples of programs that could utilize this scheme?
That's everything, like our wrapper, that needs to allow non-root users to run
apps (like perf) that use uid/euid as capabilities. It is a required, if the
apps could interact with a filesystem (and accessing root-owned files is not a
desired effect). It is a good idea from the security perspective even if those
apps do not normally interact with a filesystem.
I do not have a clear view about a variety of Linux apps ever written, but I
suspect that there are many apps that fall into "use uid/euid as capabilities"
category. There are at least two in the kernel's tools directory. There is
also use of uid/eiud in the kernel itself, and anything that uses this
functionality cannot be fixed w/o fixing the kernel. It may be a bit hard to
find all such uses, but a good start is:
grep -rE '(uid_eq|uid\(\)).*\b(GLOBAL_ROOT_ID|0)\b'
- Igor
Re: pagecache locking (was: bcachefs status update) merged)
On Thu, Jun 13, 2019 at 9:31 PM Dave Chinner wrote: > > Yes, they do, I see plenty of cases where the page cache works just > fine because it is still faster than most storage. But that's _not > what I said_. I only quoted one small part of your email, because I wanted to point out how you again dismissed caches. And yes, that literally _is_ what you said. In other parts of that same email you said "..it's getting to the point where the only reason for having a page cache is to support mmap() and cheap systems with spinning rust storage" and "That's my beef with relying on the page cache - the page cache is rapidly becoming a legacy structure that only serves to slow modern IO subsystems down" and your whole email was basically a rant against the page cache. So I only quoted the bare minimum, and pointed out that caching is still damn important. Because most loads cache well. How you are back-tracking a bit from your statements, but don't go saying was misreading you. How else would the above be read? You really were saying that caching was "legacy". I called you out on it. Now you're trying to back-track. Yes, you have loads that don't cache well. But that does not mean that caching has somehow become irrelevant in the big picture or a "legacy" thing at all. The thing is, I don't even hate DIO. But we always end up clashing because you seem to have this mindset where nothing else matters (which really came through in that email I replied to). Do you really wonder why I point out that caching is important? Because you seem to actively claim caching doesn't matter. Are you happier now that I quoted more of your emails back to you? > IOWs, you've taken _one > single statement_ I made from a huge email about complexities in > dealing with IO concurency, the page cache and architectural flaws n > the existing code, quoted it out of context, fabricated a completely > new context and started ranting about how I know nothing about how > caches or the page cache work. See above. I cut things down a lot, but it wasn't a single statement at all. I just boiled it down to the basics. > Linus, nobody can talk about direct IO without you screaming and > tossing all your toys out of the crib. Dave, look in the mirror some day. You might be surprised. > So, in the interests of further _civil_ discussion, let me clarify > my statement for you: for a highly concurrent application that is > crunching through bulk data on large files on high throughput > storage, the page cache is still far, far slower than direct IO. .. and Christ, Dave, we even _agree_ on this. But when DIO becomes an issue is when you try to claim it makes the page cache irrelevant, or a problem. I also take issue with you then making statements that seem to be explicitly designed to be misleading. For DIO, you talk about how XFS has no serialization and gets great performance. Then in the very next email, you talk about how you think buffered IO has to be excessively serialized, and how XFS is the only one who does it properly, and how that is a problem for performance. But as far as I can tell, the serialization rule you quote is simply not true. But for you it is, and only for buffered IO. It's really as if you were actively trying to make the non-DIO case look bad by picking and choosing your rules. And the thing is, I suspect that the overlap between DIO and cached IO shouldn't even need to be there. We've generally tried to just not have them interact at all, by just having DIO invalidate the caches (which is really really cheap if they don't exist - which should be the common case by far!). People almost never mix the two at all, and we might be better off aiming to separate them out even more than we do now. That's actually the part I like best about the page cache add lock - I may not be a great fan of yet another ad-hoc lock - but I do like how it adds minimal overhead to the cached case (because by definition, the good cached case is when you don't need to add new pages), while hopefully working well together with the whole "invalidate existing caches" case for DIO. I know you don't like the cache flush and invalidation stuff for some reason, but I don't even understand why you care. Again, if you're actually just doing all DIO, the caches will be empty and not be in your way. So normally all that should be really really cheap. Flushing and invalidating caches that don't exists isn't really complicated, is it? And if cached state *does* exist, and if it can't be invalidated (for example, existing busy mmap or whatever), maybe the solution there is "always fall back to buffered/cached IO". For the cases you care about, that should never happen, after all. IOW, if anything, I think we should strive for a situation where the whole DIO vs cached becomes even _more_ independent. If there are busy caches, just fall back to cached IO. It will have lower IO throughput, but that's one of the
RE: [PATCHv5 19/20] PCI: mobiveil: Add 8-bit and 16-bit register accessors
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 2019年6月12日 21:54
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 19/20] PCI: mobiveil: Add 8-bit and 16-bit register
> accessors
>
> On Fri, Apr 12, 2019 at 08:37:05AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > There are some 8-bit and 16-bit registers in PCIe configuration space,
> > so add accessors for them.
> >
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> > - No functionality change.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 411e9779da12..456adfee393c 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -268,11 +268,31 @@ static u32 csr_readl(struct mobiveil_pcie *pcie,
> u32 off)
> > return csr_read(pcie, off, 0x4);
> > }
> >
> > +static u32 csr_readw(struct mobiveil_pcie *pcie, u32 off) {
> > + return csr_read(pcie, off, 0x2);
> > +}
> > +
> > +static u32 csr_readb(struct mobiveil_pcie *pcie, u32 off) {
> > + return csr_read(pcie, off, 0x1);
> > +}
> > +
> > static void csr_writel(struct mobiveil_pcie *pcie, u32 val, u32 off)
> > {
> > csr_write(pcie, val, off, 0x4);
> > }
> >
> > +static void csr_writew(struct mobiveil_pcie *pcie, u32 val, u32 off)
> > +{
> > + csr_write(pcie, val, off, 0x2);
> > +}
> > +
> > +static void csr_writeb(struct mobiveil_pcie *pcie, u32 val, u32 off)
> > +{
> > + csr_write(pcie, val, off, 0x1);
> > +}
> > +
>
> They are not used so you should drop this patch.
NXP Layerscape PCIe Gen4 controller driver will use them, so don't drop it.
Thanks,
Zhiqiang
>
> Lorenzo
>
> > static bool mobiveil_pcie_link_up(struct mobiveil_pcie *pcie) {
> > return (csr_readl(pcie, LTSSM_STATUS) &
> > --
> > 2.17.1
> >
Re: general protection fault in oom_unkillable_task
I'm not sure this patch is correct/safe. Can you try memcg OOM torture
test (including memcg group OOM killing enabled) with this patch applied?
>From a436624c73d106fad9b880a6cef5abd83b2329a2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 15 Jun 2019 10:06:00 +0900
Subject: [PATCH] memcg: Protect whole mem_cgroup_scan_tasks() using RCU.
syzbot is reporting a GFP at for_each_thread() from a memcg OOM event [1].
While select_bad_process() in a global OOM event traverses whole threads
under RCU, select_bad_process() in a memcg OOM event is traversing threads
without RCU, and I guess that this can result in traversing bogus pointer.
Suppose a process containing three threads T1, T2, T3 is in a memcg.
T3 invokes memcg OOM killer, and starts traversing from T1. T3 elevates
refcount on T1, but T3 is preempted before oom_unkillable_task(T1) check.
Then, T1 reaches do_exit() and T1 does list_del_rcu(>thread_node).
do_exit() {
cgroup_exit() {
css_set_move_task(tsk, cset, NULL, false);
}
exit_notify() {
release_task() {
__exit_signal() {
__unhash_process() {
list_del_rcu(>thread_node);
}
}
}
}
}
Then, T2 also reaches do_exit() and does list_del_rcu(>thread_node).
Since the refcount of T1 was kept elevated by T3, T1 cannot be freed. But
since the refcount of T2 was not elevated by T3, T2 can complete do_exit()
and T2 is freed as soon as RCU grace period elapsed. At this point, since
T1 was removed from thread group before T2 was removed, T1's next thread
remains already freed T2. If memory used for T2 was reallocated before T3
resumes execution, accessing T1's next thread will not be reported as
use-after-free but memory referenced as T1's next thread contains bogus
values.
Thus, I think that the rule is: when traversing threads inside a section
between css_task_iter_start() and css_task_iter_end(), each thread must
not involve e.g. for_each_thread() unless whole section is protected by
RCU.
[1]
https://syzkaller.appspot.com/bug?id=4559bc383e7c73a35bc6c8336557635459fb7a62
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
---
mm/memcontrol.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index ba9138a..8e01f01 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1159,6 +1159,7 @@ int mem_cgroup_scan_tasks(struct mem_cgroup *memcg,
BUG_ON(memcg == root_mem_cgroup);
+ rcu_read_lock();
for_each_mem_cgroup_tree(iter, memcg) {
struct css_task_iter it;
struct task_struct *task;
@@ -1172,6 +1173,7 @@ int mem_cgroup_scan_tasks(struct mem_cgroup *memcg,
break;
}
}
+ rcu_read_unlock();
return ret;
}
--
1.8.3.1
[PATCH 3/4] arm_pmu: acpi: spe: Add initial MADT/SPE probing
ACPI 6.3 adds additional fields to the MADT GICC
structure to describe SPE PPI's. We pick these out
of the cached reference to the madt_gicc structure
similarly to the core PMU code. We then create a platform
device referring to the IRQ and let the user/module loader
decide whether to load the SPE driver.
Signed-off-by: Jeremy Linton
---
arch/arm64/include/asm/acpi.h | 3 ++
drivers/perf/arm_pmu_acpi.c | 75 +++
include/linux/perf/arm_pmu.h | 2 +
3 files changed, 80 insertions(+)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 7628efbe6c12..d10399b9f998 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -41,6 +41,9 @@
(!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \
(unsigned long)(entry) + (entry)->header.length > (end))
+#define ACPI_MADT_GICC_SPE (ACPI_OFFSET(struct acpi_madt_generic_interrupt, \
+ spe_interrupt) + sizeof(u16))
+
/* Basic configuration for ACPI */
#ifdef CONFIG_ACPI
pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
index 0f197516d708..f5df100bc4f4 100644
--- a/drivers/perf/arm_pmu_acpi.c
+++ b/drivers/perf/arm_pmu_acpi.c
@@ -74,6 +74,79 @@ static void arm_pmu_acpi_unregister_irq(int cpu)
acpi_unregister_gsi(gsi);
}
+#if IS_ENABLED(CONFIG_ARM_SPE_PMU)
+static struct resource spe_resources[] = {
+ {
+ /* irq */
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct platform_device spe_dev = {
+ .name = ARMV8_SPE_PDEV_NAME,
+ .id = -1,
+ .resource = spe_resources,
+ .num_resources = ARRAY_SIZE(spe_resources)
+};
+
+/*
+ * For lack of a better place, hook the normal PMU MADT walk
+ * and create a SPE device if we detect a recent MADT with
+ * a homogeneous PPI mapping.
+ */
+static int arm_spe_acpi_register_device(void)
+{
+ int cpu, hetid, irq, ret;
+ bool first = true;
+ u16 gsi = 0;
+
+ /*
+* sanity check all the GICC tables for the same interrupt number
+* for now we only support homogeneous ACPI/SPE machines.
+*/
+ for_each_possible_cpu(cpu) {
+ struct acpi_madt_generic_interrupt *gicc;
+
+ gicc = acpi_cpu_get_madt_gicc(cpu);
+ if (gicc->header.length < ACPI_MADT_GICC_SPE)
+ return -ENODEV;
+
+ if (first) {
+ gsi = gicc->spe_interrupt;
+ if (!gsi)
+ return -ENODEV;
+ hetid = find_acpi_cpu_topology_hetero_id(cpu);
+ first = false;
+ } else if ((gsi != gicc->spe_interrupt) ||
+ (hetid != find_acpi_cpu_topology_hetero_id(cpu))) {
+ pr_warn("ACPI: SPE must be homogeneous\n");
+ return -EINVAL;
+ }
+ }
+
+ irq = acpi_register_gsi(NULL, gsi, ACPI_LEVEL_SENSITIVE,
+ ACPI_ACTIVE_HIGH);
+ if (irq < 0) {
+ pr_warn("ACPI: SPE Unable to register interrupt: %d\n", gsi);
+ return irq;
+ }
+
+ spe_resources[0].start = irq;
+ ret = platform_device_register(_dev);
+ if (ret < 0) {
+ pr_warn("ACPI: SPE: Unable to register device\n");
+ acpi_unregister_gsi(gsi);
+ }
+
+ return ret;
+}
+#else
+static inline int arm_spe_acpi_register_device(void)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_ARM_SPE_PMU */
+
static int arm_pmu_acpi_parse_irqs(void)
{
int irq, cpu, irq_cpu, err;
@@ -279,6 +352,8 @@ static int arm_pmu_acpi_init(void)
if (acpi_disabled)
return 0;
+ arm_spe_acpi_register_device(); /* failures are expected */
+
ret = arm_pmu_acpi_parse_irqs();
if (ret)
return ret;
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 4641e850b204..784bc58f165a 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -175,4 +175,6 @@ void armpmu_free_irq(int irq, int cpu);
#endif /* CONFIG_ARM_PMU */
+#define ARMV8_SPE_PDEV_NAME "arm,spe-v1"
+
#endif /* __ARM_PMU_H__ */
--
2.21.0
[PATCH v4 0/4] arm64: SPE ACPI enablement
This patch series enables the Arm Statistical Profiling Extension (SPE) on ACPI platforms. This is possible because ACPI 6.3 uses a previously reserved field in the MADT to store the SPE interrupt number, similarly to how the normal PMU is described. If a consistent valid interrupt exists across all the cores in the system, a platform device is registered. That then triggers the SPE module, which runs as normal. We also add the ability to parse the PPTT for IDENTICAL cores. We then use this to sanity check the single SPE device we create. This creates a bit of a problem with respect to the specification though. The specification says that its legal for multiple tree's to exist in the PPTT. We handle this fine, but what happens in the case of multiple tree's is that the lack of a common node with IDENTICAL set forces us to assume that there are multiple non-IDENTICAL cores in the machine. v3->v4: Rebase to 5.2. Minor formatting, patch rearrangement. Add missing `inline` in static header definition. Drop ARM_SPE_ACPI and just use ARM_SPE_PMU. v2->v3: Previously a function pointer was being used to handle the more complex node checking required by the IDENTICAL flag. This version simply checks for the IDENTICAL flag and calls flag_identical() to preform the revision and next node checks. (I think after reading Raphael's comments for the Nth time, this is actually what he was suggesting, which I initially miss interpreted). Modify subject of first patch so that its clear a that its a capitalization change rather, than a logical C 'case' change. v1->v2: Wrap the code which creates the SPE device in a new CONFIG_ARM_SPE_ACPI ifdef. Move arm,spe-v1 device name into common header file Some comment/case sensitivity/function name changes. Jeremy Linton (4): ACPI/PPTT: Modify node flag detection to find last IDENTICAL ACPI/PPTT: Add function to return ACPI 6.3 Identical tokens arm_pmu: acpi: spe: Add initial MADT/SPE probing perf: arm_spe: Enable ACPI/Platform automatic module loading arch/arm64/include/asm/acpi.h | 3 ++ drivers/acpi/pptt.c | 61 +--- drivers/perf/arm_pmu_acpi.c | 75 +++ drivers/perf/arm_spe_pmu.c| 12 +- include/linux/acpi.h | 5 +++ include/linux/perf/arm_pmu.h | 2 + 6 files changed, 150 insertions(+), 8 deletions(-) -- 2.21.0
[PATCH 1/4] ACPI/PPTT: Modify node flag detection to find last IDENTICAL
The ACPI specification implies that the IDENTICAL flag should be
set on all non leaf nodes where the children are identical.
This means that we need to be searching for the last node with
the identical flag set rather than the first one.
Since this flag is also dependent on the table revision, we
need to add a bit of extra code to verify the table revision,
and the next node's state in the traversal. Since we want to
avoid function pointers here, lets just special case
the IDENTICAL flag.
Reviewed-by: Sudeep Holla
Signed-off-by: Jeremy Linton
---
drivers/acpi/pptt.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
index b72e6afaa8fb..05344413f199 100644
--- a/drivers/acpi/pptt.c
+++ b/drivers/acpi/pptt.c
@@ -432,17 +432,40 @@ static void cache_setup_acpi_cpu(struct acpi_table_header
*table,
}
}
+static bool flag_identical(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu)
+{
+ struct acpi_pptt_processor *next;
+
+ /* heterogeneous machines must use PPTT revision > 1 */
+ if (table_hdr->revision < 2)
+ return false;
+
+ /* Locate the last node in the tree with IDENTICAL set */
+ if (cpu->flags & ACPI_PPTT_ACPI_IDENTICAL) {
+ next = fetch_pptt_node(table_hdr, cpu->parent);
+ if (!(next && next->flags & ACPI_PPTT_ACPI_IDENTICAL))
+ return true;
+ }
+
+ return false;
+}
+
/* Passing level values greater than this will result in search termination */
#define PPTT_ABORT_PACKAGE 0xFF
-static struct acpi_pptt_processor *acpi_find_processor_package_id(struct
acpi_table_header *table_hdr,
- struct
acpi_pptt_processor *cpu,
- int level,
int flag)
+static struct acpi_pptt_processor *acpi_find_processor_tag(struct
acpi_table_header *table_hdr,
+ struct
acpi_pptt_processor *cpu,
+ int level, int flag)
{
struct acpi_pptt_processor *prev_node;
while (cpu && level) {
- if (cpu->flags & flag)
+ /* special case the identical flag to find last identical */
+ if (flag == ACPI_PPTT_ACPI_IDENTICAL) {
+ if (flag_identical(table_hdr, cpu))
+ break;
+ } else if (cpu->flags & flag)
break;
pr_debug("level %d\n", level);
prev_node = fetch_pptt_node(table_hdr, cpu->parent);
@@ -480,8 +503,8 @@ static int topology_get_acpi_cpu_tag(struct
acpi_table_header *table,
cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
if (cpu_node) {
- cpu_node = acpi_find_processor_package_id(table, cpu_node,
- level, flag);
+ cpu_node = acpi_find_processor_tag(table, cpu_node,
+ level, flag);
/*
* As per specification if the processor structure represents
* an actual processor, then ACPI processor ID must be valid.
--
2.21.0
[PATCH 4/4] perf: arm_spe: Enable ACPI/Platform automatic module loading
Lets add the MODULE_TABLE and platform id_table entries so that
the SPE driver can attach to the ACPI platform device created by
the core pmu code.
Signed-off-by: Jeremy Linton
Reviewed-by: Sudeep Holla
---
drivers/perf/arm_spe_pmu.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index e120f933412a..4fb65c61c8ea 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1168,7 +1169,13 @@ static const struct of_device_id arm_spe_pmu_of_match[]
= {
};
MODULE_DEVICE_TABLE(of, arm_spe_pmu_of_match);
-static int arm_spe_pmu_device_dt_probe(struct platform_device *pdev)
+static const struct platform_device_id arm_spe_match[] = {
+ { ARMV8_SPE_PDEV_NAME, 0},
+ { }
+};
+MODULE_DEVICE_TABLE(platform, arm_spe_match);
+
+static int arm_spe_pmu_device_probe(struct platform_device *pdev)
{
int ret;
struct arm_spe_pmu *spe_pmu;
@@ -1228,11 +1235,12 @@ static int arm_spe_pmu_device_remove(struct
platform_device *pdev)
}
static struct platform_driver arm_spe_pmu_driver = {
+ .id_table = arm_spe_match,
.driver = {
.name = DRVNAME,
.of_match_table = of_match_ptr(arm_spe_pmu_of_match),
},
- .probe = arm_spe_pmu_device_dt_probe,
+ .probe = arm_spe_pmu_device_probe,
.remove = arm_spe_pmu_device_remove,
};
--
2.21.0
[PATCH 2/4] ACPI/PPTT: Add function to return ACPI 6.3 Identical tokens
ACPI 6.3 adds a flag to indicate that child nodes are all
identical cores. This is useful to authoritatively determine
if a set of (possibly offline) cores are identical or not.
Since the flag doesn't give us a unique id we can generate
one and use it to create bitmaps of sibling nodes, or simply
in a loop to determine if a subset of cores are identical.
Reviewed-by: Sudeep Holla
Signed-off-by: Jeremy Linton
---
drivers/acpi/pptt.c | 26 ++
include/linux/acpi.h | 5 +
2 files changed, 31 insertions(+)
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
index 05344413f199..1e7ac0bd0d3a 100644
--- a/drivers/acpi/pptt.c
+++ b/drivers/acpi/pptt.c
@@ -683,3 +683,29 @@ int find_acpi_cpu_topology_package(unsigned int cpu)
return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE,
ACPI_PPTT_PHYSICAL_PACKAGE);
}
+
+/**
+ * find_acpi_cpu_topology_hetero_id() - Get a core architecture tag
+ * @cpu: Kernel logical CPU number
+ *
+ * Determine a unique heterogeneous tag for the given CPU. CPUs with the same
+ * implementation should have matching tags.
+ *
+ * The returned tag can be used to group peers with identical implementation.
+ *
+ * The search terminates when a level is found with the identical
implementation
+ * flag set or we reach a root node.
+ *
+ * Due to limitations in the PPTT data structure, there may be rare situations
+ * where two cores in a heterogeneous machine may be identical, but won't have
+ * the same tag.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the CPU cannot be found.
+ * Otherwise returns a value which represents a group of identical cores
+ * similar to this CPU.
+ */
+int find_acpi_cpu_topology_hetero_id(unsigned int cpu)
+{
+ return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE,
+ ACPI_PPTT_ACPI_IDENTICAL);
+}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index d315d86844e4..5bcd23e5ccd6 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1303,6 +1303,7 @@ static inline int lpit_read_residency_count_address(u64
*address)
#ifdef CONFIG_ACPI_PPTT
int find_acpi_cpu_topology(unsigned int cpu, int level);
int find_acpi_cpu_topology_package(unsigned int cpu);
+int find_acpi_cpu_topology_hetero_id(unsigned int cpu);
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
#else
static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
@@ -1313,6 +1314,10 @@ static inline int
find_acpi_cpu_topology_package(unsigned int cpu)
{
return -EINVAL;
}
+static inline int find_acpi_cpu_topology_hetero_id(unsigned int cpu)
+{
+ return -EINVAL;
+}
static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
{
return -EINVAL;
--
2.21.0
general protection fault in oom_unkillable_task
Hello, syzbot found the following crash on: HEAD commit:3f310e51 Add linux-next specific files for 20190607 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=15ab8771a0 kernel config: https://syzkaller.appspot.com/x/.config?x=5d176e1849bbc45 dashboard link: https://syzkaller.appspot.com/bug?extid=d0fc9d3c166bc5e4a94b compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d0fc9d3c166bc5e4a...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 28426 Comm: syz-executor.5 Not tainted 5.2.0-rc3-next-20190607 #11 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline] RIP: 0010:has_intersects_mems_allowed mm/oom_kill.c:84 [inline] RIP: 0010:oom_unkillable_task mm/oom_kill.c:168 [inline] RIP: 0010:oom_unkillable_task+0x180/0x400 mm/oom_kill.c:155 Code: c1 ea 03 80 3c 02 00 0f 85 80 02 00 00 4c 8b a3 10 07 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8d 74 24 10 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 67 02 00 00 49 8b 44 24 10 4c 8d a0 68 fa ff ff RSP: 0018:888000127490 EFLAGS: 00010a03 RAX: dc00 RBX: 8880a4cd5438 RCX: 818dae9c RDX: 1c3cc602 RSI: 818dac8d RDI: 0001 RBP: 8880001274d0 R08: 88886180 R09: ed1015d26be0 R10: ed1015d26bdf R11: 8880ae935efb R12: 800061e63007 R13: R14: 800061e63017 R15: 11124ea6 FS: 561f5940() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00607304 CR3: 9237e000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 Call Trace: oom_evaluate_task+0x49/0x520 mm/oom_kill.c:321 mem_cgroup_scan_tasks+0xcc/0x180 mm/memcontrol.c:1169 select_bad_process mm/oom_kill.c:374 [inline] out_of_memory mm/oom_kill.c:1088 [inline] out_of_memory+0x6b2/0x1280 mm/oom_kill.c:1035 mem_cgroup_out_of_memory+0x1ca/0x230 mm/memcontrol.c:1573 mem_cgroup_oom mm/memcontrol.c:1905 [inline] try_charge+0xfbe/0x1480 mm/memcontrol.c:2468 mem_cgroup_try_charge+0x24d/0x5e0 mm/memcontrol.c:6073 mem_cgroup_try_charge_delay+0x1f/0xa0 mm/memcontrol.c:6088 do_huge_pmd_wp_page_fallback+0x24f/0x1680 mm/huge_memory.c:1201 do_huge_pmd_wp_page+0x7fc/0x2160 mm/huge_memory.c:1359 wp_huge_pmd mm/memory.c:3793 [inline] __handle_mm_fault+0x164c/0x3eb0 mm/memory.c:4006 handle_mm_fault+0x3b7/0xa90 mm/memory.c:4053 do_user_addr_fault arch/x86/mm/fault.c:1455 [inline] __do_page_fault+0x5ef/0xda0 arch/x86/mm/fault.c:1521 do_page_fault+0x71/0x57d arch/x86/mm/fault.c:1552 page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1156 RIP: 0033:0x400590 Code: 06 e9 49 01 00 00 48 8b 44 24 10 48 0b 44 24 28 75 1f 48 8b 14 24 48 8b 7c 24 20 be 04 00 00 00 e8 f5 56 00 00 48 8b 74 24 08 <89> 06 e9 1e 01 00 00 48 8b 44 24 08 48 8b 14 24 be 04 00 00 00 8b RSP: 002b:7fff7bc49780 EFLAGS: 00010206 RAX: 0001 RBX: 0076 RCX: RDX: RSI: 2000cffc RDI: 0001 RBP: fffe R08: R09: R10: 0075 R11: 0246 R12: 00760008 R13: 004c55f2 R14: R15: 7fff7bc499b0 Modules linked in: ---[ end trace a65689219582 ]--- RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline] RIP: 0010:has_intersects_mems_allowed mm/oom_kill.c:84 [inline] RIP: 0010:oom_unkillable_task mm/oom_kill.c:168 [inline] RIP: 0010:oom_unkillable_task+0x180/0x400 mm/oom_kill.c:155 Code: c1 ea 03 80 3c 02 00 0f 85 80 02 00 00 4c 8b a3 10 07 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8d 74 24 10 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 67 02 00 00 49 8b 44 24 10 4c 8d a0 68 fa ff ff RSP: 0018:888000127490 EFLAGS: 00010a03 RAX: dc00 RBX: 8880a4cd5438 RCX: 818dae9c RDX: 1c3cc602 RSI: 818dac8d RDI: 0001 RBP: 8880001274d0 R08: 88886180 R09: ed1015d26be0 R10: ed1015d26bdf R11: 8880ae935efb R12: 800061e63007 R13: R14: 800061e63017 R15: 11124ea6 FS: 561f5940() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b2f823000 CR3: 9237e000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more
[ANNOUNCE] 4.19.50-rt22
Dear RT Folks, I'm pleased to announce the 4.19.50-rt22 stable release. This release is just an update to the new stable 4.19.50 version and no RT specific changes have been made. *** NOTE *** The 4.19 stable fixed a "use after free" bug in kernel/irq/manage.c, which was the use case of implementing a new work queue and removing the old one. But if the old one was in transit, the data could be used after it was freed. This was fixed in stable by canceling the work before freeing it. The problem is that RT uses swork instead of the normal work queues, and swork does not implement a cancel operation. I simply kept the bug in as is (no regressions, it will fail just like it has always done ;-). Then I will need to backport the rt-devel code which makes it possible to use normal work queues in interrupt context. But that change was too big for a "stable merge" release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.19-rt Head SHA1: 858848641fbecd42437e36adc9291b0ce5db379e Or to build 4.19.50-rt22 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.19.tar.xz http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.19.50.xz http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.50-rt22.patch.xz Enjoy, -- Steve
Re: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME
On Fri, Jun 14, 2019 at 01:51:37PM +0200, Peter Zijlstra wrote:
> On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote:
snip
> > /*
> > - * When pkey==NO_KEY we get legacy mprotect behavior here.
> > + * do_mprotect_ext() supports the legacy mprotect behavior plus extensions
> > + * for Protection Keys and Memory Encryption Keys. These extensions are
> > + * mutually exclusive and the behavior is:
> > + * (pkey==NO_KEY && keyid==NO_KEY) ==> legacy mprotect
> > + * (pkey is valid) ==> legacy mprotect plus Protection Key extensions
> > + * (keyid is valid) ==> legacy mprotect plus Encryption Key extensions
> > */
> > static int do_mprotect_ext(unsigned long start, size_t len,
> > - unsigned long prot, int pkey)
> > + unsigned long prot, int pkey, int keyid)
> > {
snip
>
> I've missed the part where pkey && keyid results in a WARN or error or
> whatever.
>
I wasn't so sure about that since do_mprotect_ext()
is the call 'behind' the system calls.
legacy mprotect always calls with: NO_KEY, NO_KEY
pkey_mprotect always calls with: pkey, NO_KEY
encrypt_mprotect always calls with NO_KEY, keyid
Would a check on those arguments be debug only
to future proof this?
Re: [PATCH] Smack: Restore the smackfsdef mount option and add missing prefixes
On Fri, Jun 14, 2019 at 1:08 PM Casey Schaufler wrote: > > Al, are you going to take this, or should I find another way > to get it in for 5.2? I guess I can take it directly. I was assuming it would come through either Al (which is how I got the commit it fixes) or Casey (as smack maintainer), so I ignored the patch. Linus
[PATCH] KVM: improve definition of KVM_GET/SET_NESTED_STATE structs
Liran sent me a patch with a large overhaul of the
KVM_GET/SET_NESTED_STATE structs. However, I am wary of changing the
userspace ABI in backwards-incompatible ways, so here is the bare minimum
that is needed to achieve the same functionality.
Namely, the format of VMX nested state is detailed in a struct, and is
accessible through struct kvm_vmx_nested_state. Unfortunately, to avoid
changing the size of the structs it has to be accessed as "vmx.data[0]"
rather than just "vmx.data".
Also, the values of the "format" field are defined as macros, which is
easy and not controversial.
Signed-off-by: Paolo Bonzini
---
arch/x86/include/uapi/asm/kvm.h | 11 +++
arch/x86/kvm/vmx/nested.c | 3 +++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 7a0e64ccd6ff..06b8727a3b58 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -383,6 +383,9 @@ struct kvm_sync_regs {
#define KVM_X86_QUIRK_LAPIC_MMIO_HOLE (1 << 2)
#define KVM_X86_QUIRK_OUT_7E_INC_RIP (1 << 3)
+#define KVM_STATE_NESTED_FORMAT_VMX0
+#define KVM_STATE_NESTED_FORMAT_SVM1
+
#define KVM_STATE_NESTED_GUEST_MODE0x0001
#define KVM_STATE_NESTED_RUN_PENDING 0x0002
#define KVM_STATE_NESTED_EVMCS 0x0004
@@ -390,6 +393,11 @@ struct kvm_sync_regs {
#define KVM_STATE_NESTED_SMM_GUEST_MODE0x0001
#define KVM_STATE_NESTED_SMM_VMXON 0x0002
+struct kvm_vmx_nested_state_data {
+ __u8 vmcs12[0x1000];
+ __u8 shadow_vmcs12[0x1000];
+};
+
struct kvm_vmx_nested_state {
__u64 vmxon_pa;
__u64 vmcs_pa;
@@ -397,6 +405,9 @@ struct kvm_vmx_nested_state {
struct {
__u16 flags;
} smm;
+
+ __u8 pad[120 - 18];
+ struct kvm_vmx_nested_state_data data[0];
};
/* for KVM_CAP_NESTED_STATE */
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 0c601d079cd2..d97b87ef209b 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -5269,6 +5269,9 @@ static int vmx_get_nested_state(struct kvm_vcpu *vcpu,
.vmx.vmcs_pa = -1ull,
};
+ BUILD_BUG_ON(sizeof(struct kvm_vmx_nested_state)
+!= sizeof_field(struct kvm_nested_state, pad));
+
if (!vcpu)
return kvm_state.size + 2 * VMCS12_SIZE;
--
2.21.0
[PATCH 5.2 1/2] mwifiex: Don't abort on small, spec-compliant vendor IEs
Per the 802.11 specification, vendor IEs are (at minimum) only required
to contain an OUI. A type field is also included in ieee80211.h (struct
ieee80211_vendor_ie) but doesn't appear in the specification. The
remaining fields (subtype, version) are a convention used in WMM
headers.
Thus, we should not reject vendor-specific IEs that have only the
minimum length (3 bytes) -- we should skip over them (since we only want
to match longer IEs, that match either WMM or WPA formats). We can
reject elements that don't have the minimum-required 3 byte OUI.
While we're at it, move the non-standard subtype and version fields into
the WMM structs, to avoid this confusion in the future about generic
"vendor header" attributes.
Fixes: 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor element")
Cc: Takashi Iwai
Signed-off-by: Brian Norris
---
It appears that commit 685c9b7750bf is on its way to 5.2, so I labeled
this bugfix for 5.2 as well.
drivers/net/wireless/marvell/mwifiex/fw.h | 12 +---
drivers/net/wireless/marvell/mwifiex/scan.c| 18 +++---
.../net/wireless/marvell/mwifiex/sta_ioctl.c | 4 ++--
drivers/net/wireless/marvell/mwifiex/wmm.c | 2 +-
4 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h
b/drivers/net/wireless/marvell/mwifiex/fw.h
index b73f99dc5a72..1fb76d2f5d3f 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -1759,9 +1759,10 @@ struct mwifiex_ie_types_wmm_queue_status {
struct ieee_types_vendor_header {
u8 element_id;
u8 len;
- u8 oui[4]; /* 0~2: oui, 3: oui_type */
- u8 oui_subtype;
- u8 version;
+ struct {
+ u8 oui[3];
+ u8 oui_type;
+ } __packed oui;
} __packed;
struct ieee_types_wmm_parameter {
@@ -1775,6 +1776,9 @@ struct ieee_types_wmm_parameter {
* Version [1]
*/
struct ieee_types_vendor_header vend_hdr;
+ u8 oui_subtype;
+ u8 version;
+
u8 qos_info_bitmap;
u8 reserved;
struct ieee_types_wmm_ac_parameters ac_params[IEEE80211_NUM_ACS];
@@ -1792,6 +1796,8 @@ struct ieee_types_wmm_info {
* Version [1]
*/
struct ieee_types_vendor_header vend_hdr;
+ u8 oui_subtype;
+ u8 version;
u8 qos_info_bitmap;
} __packed;
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
b/drivers/net/wireless/marvell/mwifiex/scan.c
index c269a0de9413..e2786ab612ca 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1361,21 +1361,25 @@ int mwifiex_update_bss_desc_with_ie(struct
mwifiex_adapter *adapter,
break;
case WLAN_EID_VENDOR_SPECIFIC:
- if (element_len + 2 < sizeof(vendor_ie->vend_hdr))
- return -EINVAL;
-
vendor_ie = (struct ieee_types_vendor_specific *)
current_ptr;
- if (!memcmp
- (vendor_ie->vend_hdr.oui, wpa_oui,
-sizeof(wpa_oui))) {
+ /* 802.11 requires at least 3-byte OUI. */
+ if (element_len < sizeof(vendor_ie->vend_hdr.oui.oui))
+ return -EINVAL;
+
+ /* Not long enough for a match? Skip it. */
+ if (element_len < sizeof(wpa_oui))
+ break;
+
+ if (!memcmp(_ie->vend_hdr.oui, wpa_oui,
+ sizeof(wpa_oui))) {
bss_entry->bcn_wpa_ie =
(struct ieee_types_vendor_specific *)
current_ptr;
bss_entry->wpa_offset = (u16)
(current_ptr - bss_entry->beacon_buf);
- } else if (!memcmp(vendor_ie->vend_hdr.oui, wmm_oui,
+ } else if (!memcmp(_ie->vend_hdr.oui, wmm_oui,
sizeof(wmm_oui))) {
if (total_ie_len ==
sizeof(struct ieee_types_wmm_parameter) ||
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index ebc0e41e5d3b..74e50566db1f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -1351,7 +1351,7 @@ mwifiex_set_gen_ie_helper(struct mwifiex_private *priv,
u8 *ie_data_ptr,
/* Test to see if it is a WPA IE, if not, then
* it is a gen IE
*/
- if (!memcmp(pvendor_ie->oui, wpa_oui,
+ if
[PATCH 2/2] mwifiex: use 'total_ie_len' in mwifiex_update_bss_desc_with_ie()
This is clearer than copy/pasting the magic number '+ 2' around, and it even saves the need for one existing comment. Cc: Takashi Iwai Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/scan.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c index e2786ab612ca..707e5159262f 100644 --- a/drivers/net/wireless/marvell/mwifiex/scan.c +++ b/drivers/net/wireless/marvell/mwifiex/scan.c @@ -1269,7 +1269,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter, break; case WLAN_EID_FH_PARAMS: - if (element_len + 2 < sizeof(*fh_param_set)) + if (total_ie_len < sizeof(*fh_param_set)) return -EINVAL; fh_param_set = (struct ieee_types_fh_param_set *) current_ptr; @@ -1279,7 +1279,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter, break; case WLAN_EID_DS_PARAMS: - if (element_len + 2 < sizeof(*ds_param_set)) + if (total_ie_len < sizeof(*ds_param_set)) return -EINVAL; ds_param_set = (struct ieee_types_ds_param_set *) current_ptr; @@ -1292,7 +1292,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter, break; case WLAN_EID_CF_PARAMS: - if (element_len + 2 < sizeof(*cf_param_set)) + if (total_ie_len < sizeof(*cf_param_set)) return -EINVAL; cf_param_set = (struct ieee_types_cf_param_set *) current_ptr; @@ -1302,7 +1302,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter, break; case WLAN_EID_IBSS_PARAMS: - if (element_len + 2 < sizeof(*ibss_param_set)) + if (total_ie_len < sizeof(*ibss_param_set)) return -EINVAL; ibss_param_set = (struct ieee_types_ibss_param_set *) @@ -1459,10 +1459,8 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter, break; } - current_ptr += element_len + 2; - - /* Need to account for IE ID and IE Len */ - bytes_left -= (element_len + 2); + current_ptr += total_ie_len; + bytes_left -= total_ie_len; } /* while (bytes_left > 2) */ return ret; -- 2.22.0.410.gd8fdbe21b5-goog
Re: [PATCH v2 2/5] objtool: Fix ORC unwinding in non-JIT BPF generated code
On Fri, Jun 14, 2019 at 5:02 PM Josh Poimboeuf wrote: > > On Fri, Jun 14, 2019 at 04:30:15PM -0700, Alexei Starovoitov wrote: > > On Fri, Jun 14, 2019 at 4:17 PM Josh Poimboeuf wrote: > > > > > > On Fri, Jun 14, 2019 at 02:22:59PM -0700, Alexei Starovoitov wrote: > > > > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf > > > > wrote: > > > > > > > > > > > > > > > > > > +#define JUMP_TABLE_SYM_PREFIX "jump_table." > > > > > > > > > > > > > > > > since external tool will be looking at it should it be named > > > > > > > > "bpf_jump_table." to avoid potential name conflicts? > > > > > > > > Or even more unique name? > > > > > > > > Like "bpf_interpreter_jump_table." ? > > > > > > > > > > > > > > No, the point is that it's a generic feature which can also be > > > > > > > used any > > > > > > > non-BPF code which might also have a jump table. > > > > > > > > > > > > and you're proposing to name all such jump tables in the kernel > > > > > > as static foo jump_table[] ? > > > > > > > > > > That's the idea. > > > > > > > > Then it needs much wider discussion. > > > > > > Why would it need wider discussion? It only has one user. If you > > > honestly believe that it will be controversial to require future users > > > to call a static jump table "jump_table" then we can have that > > > discussion when it comes up. > > > > It's clearly controversial. > > I nacked it already on pointless name change > > from "jumptable" to "jump_table" and now you're saying > > that no one will complain about "jump_table" name > > for all jump tables in the kernel that will ever appear? > > Let me get this straight. You're saying that "jumptable" and > "bpf_interpreter_jump_table" are both acceptable. > > But NACK to "jump_table". > > Ok... Correct. I think I explained the reasons behind, right?
Re: [PATCH v2 2/5] objtool: Fix ORC unwinding in non-JIT BPF generated code
Maybe add more multidimensional arrays? Sent from my iPhone >> On Jun 14, 2019, at 5:02 PM, Josh Poimboeuf wrote: >> >>> On Fri, Jun 14, 2019 at 04:30:15PM -0700, Alexei Starovoitov wrote: On Fri, Jun 14, 2019 at 4:17 PM Josh Poimboeuf wrote: On Fri, Jun 14, 2019 at 02:22:59PM -0700, Alexei Starovoitov wrote: On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote: > > +#define JUMP_TABLE_SYM_PREFIX "jump_table." since external tool will be looking at it should it be named "bpf_jump_table." to avoid potential name conflicts? Or even more unique name? Like "bpf_interpreter_jump_table." ? >>> >>> No, the point is that it's a generic feature which can also be used any >>> non-BPF code which might also have a jump table. >> >> and you're proposing to name all such jump tables in the kernel >> as static foo jump_table[] ? > > That's the idea. Then it needs much wider discussion. >>> >>> Why would it need wider discussion? It only has one user. If you >>> honestly believe that it will be controversial to require future users >>> to call a static jump table "jump_table" then we can have that >>> discussion when it comes up. >> >> It's clearly controversial. >> I nacked it already on pointless name change >> from "jumptable" to "jump_table" and now you're saying >> that no one will complain about "jump_table" name >> for all jump tables in the kernel that will ever appear? > > Let me get this straight. You're saying that "jumptable" and > "bpf_interpreter_jump_table" are both acceptable. > > But NACK to "jump_table". > > Ok... > > -- > Josh
Re: [PATCH, RFC 47/62] mm: Restrict MKTME memory encryption to anonymous VMAs
On Fri, Jun 14, 2019 at 01:55:20PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:07PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield > > > > Memory encryption is only supported for mappings that are ANONYMOUS. > > Test the VMA's in an encrypt_mprotect() request to make sure they all > > meet that requirement before encrypting any. > > > > The encrypt_mprotect syscall will return -EINVAL and will not encrypt > > any VMA's if this check fails. > > > > Signed-off-by: Alison Schofield > > Signed-off-by: Kirill A. Shutemov > > This should be folded back into the initial implemention, methinks. It is part of the initial implementation. I looked for places to split the implementation into smaller, reviewable patches, hence this split. None of it gets built until the CONFIG_X86_INTEL_MKTME is introduced in a later patch. The encrypt_mprotect() patchset is ordered like this: 1) generalize mprotect to support the mktme extension 2) wire up encrypt_mprotect() 3) implement encrypt_mprotect() 4) keep reference counts on encryption keys (was VMAs) 5) (this patch) restrict to anonymous VMAs. I thought Patch 5) was a small, but meaningful split. It accentuates the fact that MKTME is restricted to anonymous memory. Alas, I want to make it logical to review, so I'll move it.
Re: [PATCH v2 4/5] x86/bpf: Fix 64-bit JIT frame pointer usage
On Fri, Jun 14, 2019 at 4:54 PM Josh Poimboeuf wrote: > > On Fri, Jun 14, 2019 at 04:23:41PM -0700, Alexei Starovoitov wrote: > > On Fri, Jun 14, 2019 at 4:13 PM Josh Poimboeuf wrote: > > > > > > On Fri, Jun 14, 2019 at 02:27:30PM -0700, Alexei Starovoitov wrote: > > > > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf > > > > wrote: > > > > > > > > > > On Fri, Jun 14, 2019 at 02:05:56PM -0700, Alexei Starovoitov wrote: > > > > > > Have you tested it ? > > > > > > I really doubt, since in my test both CONFIG_UNWINDER_ORC and > > > > > > CONFIG_UNWINDER_FRAME_POINTER failed to unwind through such odd > > > > > > frame. > > > > > > > > > > Hm, are you seeing selftest failures? They seem to work for me. > > > > > > > > > > > Here is much simple patch that I mentioned in the email yesterday, > > > > > > but you failed to listen instead of focusing on perceived 'code > > > > > > readability'. > > > > > > > > > > > > It makes one proper frame and both frame and orc unwinders are > > > > > > happy. > > > > > > > > > > I'm on my way out the door and I just skimmed it, but it looks fine. > > > > > > > > > > Some of the code and patch description look familiar, please be sure > > > > > to > > > > > give me proper credit. > > > > > > > > credit means something positive. > > > > > > So you only give credit for *good* stolen code. I must have missed that > > > section of the kernel patch guidelines. > > > > what are you talking about? > > you've posted one bad patch. I pointed out multiple issues in it. > > Then proposed another bad idea. I pointed out another set of issues. > > Than David proposed yet another idea that you've implemented > > and claimed that it's working when it was not. > > Then I got fed up with this thread and fix it for real by reverting > > that old commit that I mentioned way earlier. > > https://patchwork.ozlabs.org/patch/1116307/ > > Where do you see your code or ideas being used? > > I see none. > > Obviously I wasn't referring to this new whitewashed patch for which I > wasn't even on Cc, despite being one of the people (along with Peter Z) > who convinced you that there was a problem to begin with. vger has a small limit on cc list. I always trim it to the minimum. > The previous patch you posted has my patch description, push/pop and > comment changes, with no credit: I'm sorry for reusing one sentence from your commit log and not realizing you want credit for that. Will not happen again. I also suggest you never touch anything bpf related. Just to avoid this credit claims and threads like this one.
Re: [PATCH v2 2/5] objtool: Fix ORC unwinding in non-JIT BPF generated code
On Fri, Jun 14, 2019 at 04:30:15PM -0700, Alexei Starovoitov wrote: > On Fri, Jun 14, 2019 at 4:17 PM Josh Poimboeuf wrote: > > > > On Fri, Jun 14, 2019 at 02:22:59PM -0700, Alexei Starovoitov wrote: > > > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf > > > wrote: > > > > > > > > > > > > > > > > +#define JUMP_TABLE_SYM_PREFIX "jump_table." > > > > > > > > > > > > > > since external tool will be looking at it should it be named > > > > > > > "bpf_jump_table." to avoid potential name conflicts? > > > > > > > Or even more unique name? > > > > > > > Like "bpf_interpreter_jump_table." ? > > > > > > > > > > > > No, the point is that it's a generic feature which can also be used > > > > > > any > > > > > > non-BPF code which might also have a jump table. > > > > > > > > > > and you're proposing to name all such jump tables in the kernel > > > > > as static foo jump_table[] ? > > > > > > > > That's the idea. > > > > > > Then it needs much wider discussion. > > > > Why would it need wider discussion? It only has one user. If you > > honestly believe that it will be controversial to require future users > > to call a static jump table "jump_table" then we can have that > > discussion when it comes up. > > It's clearly controversial. > I nacked it already on pointless name change > from "jumptable" to "jump_table" and now you're saying > that no one will complain about "jump_table" name > for all jump tables in the kernel that will ever appear? Let me get this straight. You're saying that "jumptable" and "bpf_interpreter_jump_table" are both acceptable. But NACK to "jump_table". Ok... -- Josh
Re: [PATCH v2 4/5] x86/bpf: Fix 64-bit JIT frame pointer usage
On Fri, Jun 14, 2019 at 04:23:41PM -0700, Alexei Starovoitov wrote: > On Fri, Jun 14, 2019 at 4:13 PM Josh Poimboeuf wrote: > > > > On Fri, Jun 14, 2019 at 02:27:30PM -0700, Alexei Starovoitov wrote: > > > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf > > > wrote: > > > > > > > > On Fri, Jun 14, 2019 at 02:05:56PM -0700, Alexei Starovoitov wrote: > > > > > Have you tested it ? > > > > > I really doubt, since in my test both CONFIG_UNWINDER_ORC and > > > > > CONFIG_UNWINDER_FRAME_POINTER failed to unwind through such odd frame. > > > > > > > > Hm, are you seeing selftest failures? They seem to work for me. > > > > > > > > > Here is much simple patch that I mentioned in the email yesterday, > > > > > but you failed to listen instead of focusing on perceived 'code > > > > > readability'. > > > > > > > > > > It makes one proper frame and both frame and orc unwinders are happy. > > > > > > > > I'm on my way out the door and I just skimmed it, but it looks fine. > > > > > > > > Some of the code and patch description look familiar, please be sure to > > > > give me proper credit. > > > > > > credit means something positive. > > > > So you only give credit for *good* stolen code. I must have missed that > > section of the kernel patch guidelines. > > what are you talking about? > you've posted one bad patch. I pointed out multiple issues in it. > Then proposed another bad idea. I pointed out another set of issues. > Than David proposed yet another idea that you've implemented > and claimed that it's working when it was not. > Then I got fed up with this thread and fix it for real by reverting > that old commit that I mentioned way earlier. > https://patchwork.ozlabs.org/patch/1116307/ > Where do you see your code or ideas being used? > I see none. Obviously I wasn't referring to this new whitewashed patch for which I wasn't even on Cc, despite being one of the people (along with Peter Z) who convinced you that there was a problem to begin with. The previous patch you posted has my patch description, push/pop and comment changes, with no credit: https://lkml.kernel.org/r/20190614210555.q4ictql3tzzji...@ast-mbp.dhcp.thefacebook.com -- Josh
[PATCH] scsi: storvsc: Add ability to change scsi queue depth
Adding functionality to allow the SCSI queue depth to be changed,
by utilizing the "scsi_change_queue_depth" function.
Signed-off-by: Branden Bonaby
---
drivers/scsi/storvsc_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 8472de1007ff..719ca9906fc2 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -387,6 +387,7 @@ enum storvsc_request_type {
static int storvsc_ringbuffer_size = (128 * 1024);
static u32 max_outstanding_req_per_channel;
+static int storvsc_change_queue_depth(struct scsi_device *sdev, int
queue_depth);
static int storvsc_vcpus_per_sub_channel = 4;
@@ -1711,6 +1712,7 @@ static struct scsi_host_template scsi_driver = {
.dma_boundary = PAGE_SIZE-1,
.no_write_same =1,
.track_queue_depth =1,
+ .change_queue_depth = storvsc_change_queue_depth,
};
enum {
@@ -1917,6 +1919,15 @@ static int storvsc_probe(struct hv_device *device,
return ret;
}
+/* Change a scsi target's queue depth */
+static int storvsc_change_queue_depth(struct scsi_device *sdev, int
queue_depth)
+{
+ if (queue_depth > scsi_driver.can_queue){
+ queue_depth = scsi_driver.can_queue;
+ }
+ return scsi_change_queue_depth(sdev, queue_depth);
+}
+
static int storvsc_remove(struct hv_device *dev)
{
struct storvsc_device *stor_device = hv_get_drvdata(dev);
--
2.17.1
RE: [PATCH] ACPI: PM: Export the function acpi_sleep_state_supported()
> From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of Russell King > On Fri, Jun 14, 2019 at 10:19:02PM +, Dexuan Cui wrote: > > It looks ARM does not support the ACPI S4 state, then how do we know > > if an ARM host supports hibernation or not? > > Don't forget that Linux does not support ACPI on 32-bit ARM, which is > quite different from the situation on 64-bit ARM. > > arch/arm/kernel/hibernate.c is only for 32-bit ARM, and is written with > the assumption that there is no interaction required with any firmware > to save state, and later restore state upon resuming. > > Or am I missing something? Hi Russell, Thanks for your reply and please excuse me for my ignorance of ARM. So 32-bit ARM Linux can hibernate even if it doesn't support ACPI, but I guess not all 32-bit ARM machines support hibernation? If my guess is correct, is there any standard capability bit or something that can be used to tell if an ARM machine supports hibernation? I'm purely curious. :-) Do you imply 64-bit ARM Linux supports ACPI and the ACPI S4 state? If not, how can we tell if a 64-bit ARM machine supports hibernation or not? Thanks, -- Dexuan
Re: [PATCH 2/3] hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race
On 6/14/19 2:56 PM, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: ebed4bfc8da8 [PATCH] hugetlb: fix absurd HugePages_Rsvd. > > How should we proceed with this patch? > I hope you do nothing with this as the patch is not upstream. -- Mike Kravetz
Re: [PATCH v2 2/5] objtool: Fix ORC unwinding in non-JIT BPF generated code
On Fri, Jun 14, 2019 at 4:17 PM Josh Poimboeuf wrote: > > On Fri, Jun 14, 2019 at 02:22:59PM -0700, Alexei Starovoitov wrote: > > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote: > > > > > > > > > > > > > > +#define JUMP_TABLE_SYM_PREFIX "jump_table." > > > > > > > > > > > > since external tool will be looking at it should it be named > > > > > > "bpf_jump_table." to avoid potential name conflicts? > > > > > > Or even more unique name? > > > > > > Like "bpf_interpreter_jump_table." ? > > > > > > > > > > No, the point is that it's a generic feature which can also be used > > > > > any > > > > > non-BPF code which might also have a jump table. > > > > > > > > and you're proposing to name all such jump tables in the kernel > > > > as static foo jump_table[] ? > > > > > > That's the idea. > > > > Then it needs much wider discussion. > > Why would it need wider discussion? It only has one user. If you > honestly believe that it will be controversial to require future users > to call a static jump table "jump_table" then we can have that > discussion when it comes up. It's clearly controversial. I nacked it already on pointless name change from "jumptable" to "jump_table" and now you're saying that no one will complain about "jump_table" name for all jump tables in the kernel that will ever appear?
Re: [PATCH] arm64: dts: meson-g12a-x96-max: add sound card
Neil Armstrong writes: > Enable the sound card on the X96 Max, enabling HDMI output using the > TDM interface B, being aligned on other boards sound cards. > SPDI/F support is also enabled to the physical toslink port and to HDMI. > > The internal DAC connected to the audio jack will be added later on, when > driver support is added. > > Tested by running: > tinymix set "FRDDR_A SRC 1 EN Switch" 1 > tinymix set "FRDDR_A SINK 1 SEL" "OUT 1" > tinymix set "FRDDR_B SRC 1 EN Switch" 1 > tinymix set "FRDDR_B SINK 1 SEL" "OUT 1" > tinymix set "FRDDR_C SRC 1 EN Switch" 1 > tinymix set "FRDDR_C SINK 1 SEL" "OUT 1" > tinymix set "TOHDMITX I2S SRC" "I2S B" > tinymix set "TOHDMITX Switch" 1 > > then: > tinymix set "TDMOUT_B SRC SEL" "IN 0" > speaker-test -Dhw:0,0 -c2 > > then: > tinymix set "TDMOUT_B SRC SEL" "IN 1" > speaker-test -Dhw:0,1 -c2 > > then: > tinymix set "TDMOUT_B SRC SEL" "IN 2" > speaker-test -Dhw:0,2 -c2 > > testing HDMI audio output from the all 3 ASoC playback interfaces. > > Signed-off-by: Neil Armstrong Queued for v5.3, Thanks, Kevin
Re: [PATCH 0/2] Use Media Dev Allocator to fix vimc dev lifetime bugs
On 6/13/19 7:24 AM, Helen Koike wrote: On 6/13/19 2:44 AM, Hans Verkuil wrote: On 5/24/19 5:31 AM, Shuah Khan wrote: media_device is embedded in struct vimc_device and when vimc is removed vimc_device and the embedded media_device goes with it, while the active stream and vimc_capture continue to access it. Fix the media_device lifetime problem by changing vimc to create shared media_device using Media Device Allocator API and vimc_capture getting a reference to vimc module. With this change, vimc module can be removed only when the references are gone. vimc can be removed after vimc_capture is removed. Media Device Allocator API supports just USB devices. Enhance it adding a genetic device allocate interface to support other media drivers. The new interface takes pointer to struct device instead and creates media device. This interface allows a group of drivers that have a common root device to share media device resource and ensure media device doesn't get deleted as long as one of the drivers holds its reference. The new interface has been tested with vimc component driver to fix panics when vimc module is removed while streaming is in progress. Helen, can you review this series? I'm not sure this is the right approach for a driver like vimc, and even if it is, then it is odd that vimc-capture is the only vimc module that's handled here. Hi Hans, Yes, I can take a look. Sorry, I've been a bit busy these days but I'll try to take a look at this patch series (and the others) asap. Helen My gut feeling is that this should be handled inside vimc directly and not using the media-dev-allocator. Hi Hans and Helen, I explored fixing the problem within vimc before I went down the path to use Media Device Allocator API. I do think that it is cleaner to go this way and easier to maintain. vimc is a group pf component drivers that rely on the media device vimc in vimc and falls into the use-case Media Device Allocator API is added to address. The release and life-time management happens without vimc component drivers being changed other than using the API to get and put media device reference. thanks, -- Shuah
Re: [PATCH] arm64: dts: meson-g12b-odroid-n2: add sound card
Neil Armstrong writes: > Enable the sound card on the Hardkernel Odroid-N2, enabling HDMI output > using the TDM interface B, being aligned on other boards sound cards. > > The internal DAC connected to the audio jack will be added later on, when > driver support is added. > > Tested by running: > tinymix set "FRDDR_A SRC 1 EN Switch" 1 > tinymix set "FRDDR_A SINK 1 SEL" "OUT 1" > tinymix set "FRDDR_B SRC 1 EN Switch" 1 > tinymix set "FRDDR_B SINK 1 SEL" "OUT 1" > tinymix set "FRDDR_C SRC 1 EN Switch" 1 > tinymix set "FRDDR_C SINK 1 SEL" "OUT 1" > tinymix set "TOHDMITX I2S SRC" "I2S B" > tinymix set "TOHDMITX Switch" 1 > > then: > tinymix set "TDMOUT_B SRC SEL" "IN 0" > speaker-test -Dhw:0,0 -c2 > > then: > tinymix set "TDMOUT_B SRC SEL" "IN 1" > speaker-test -Dhw:0,1 -c2 > > then: > tinymix set "TDMOUT_B SRC SEL" "IN 2" > speaker-test -Dhw:0,2 -c2 > > testing HDMI audio output from the all 3 ASoC playback interfaces. > > Signed-off-by: Neil Armstrong Queued for v5.3, Thanks, Kevin
Re: [PATCH bpf-next] bpf: Fix build error without CONFIG_INET
On 06/12/2019 11:18 AM, YueHaibing wrote:
> If CONFIG_INET is not set, building fails:
>
> kernel/bpf/verifier.o: In function `check_mem_access':
> verifier.c: undefined reference to `bpf_xdp_sock_is_valid_access'
> kernel/bpf/verifier.o: In function `convert_ctx_accesses':
> verifier.c: undefined reference to `bpf_xdp_sock_convert_ctx_access'
>
> Reported-by: Hulk Robot
> Fixes: fada7fdc83c0 ("bpf: Allow bpf_map_lookup_elem() on an xskmap")
> Signed-off-by: YueHaibing
Applied, thanks!
Re: [PATCH v2 4/5] x86/bpf: Fix 64-bit JIT frame pointer usage
On Fri, Jun 14, 2019 at 4:13 PM Josh Poimboeuf wrote: > > On Fri, Jun 14, 2019 at 02:27:30PM -0700, Alexei Starovoitov wrote: > > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote: > > > > > > On Fri, Jun 14, 2019 at 02:05:56PM -0700, Alexei Starovoitov wrote: > > > > Have you tested it ? > > > > I really doubt, since in my test both CONFIG_UNWINDER_ORC and > > > > CONFIG_UNWINDER_FRAME_POINTER failed to unwind through such odd frame. > > > > > > Hm, are you seeing selftest failures? They seem to work for me. > > > > > > > Here is much simple patch that I mentioned in the email yesterday, > > > > but you failed to listen instead of focusing on perceived 'code > > > > readability'. > > > > > > > > It makes one proper frame and both frame and orc unwinders are happy. > > > > > > I'm on my way out the door and I just skimmed it, but it looks fine. > > > > > > Some of the code and patch description look familiar, please be sure to > > > give me proper credit. > > > > credit means something positive. > > So you only give credit for *good* stolen code. I must have missed that > section of the kernel patch guidelines. what are you talking about? you've posted one bad patch. I pointed out multiple issues in it. Then proposed another bad idea. I pointed out another set of issues. Than David proposed yet another idea that you've implemented and claimed that it's working when it was not. Then I got fed up with this thread and fix it for real by reverting that old commit that I mentioned way earlier. https://patchwork.ozlabs.org/patch/1116307/ Where do you see your code or ideas being used? I see none.
Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux
On Thu, Jun 13, 2019 at 05:46:00PM -0700, Sean Christopherson wrote: Good afternoon, I hope the week is ending well for everyone. > On Thu, Jun 13, 2019 at 01:02:17PM -0400, Stephen Smalley wrote: > > Given the complexity tradeoff, what is the clear motivating > > example for why #1 isn't the obvious choice? That the enclave > > loader has no way of knowing a priori whether the enclave will > > require W->X or WX? But aren't we better off requiring enclaves > > to be explicitly marked as needing such so that we can make a more > > informed decision about whether to load them in the first place? > Andy and/or Cedric, can you please weigh in with a concrete (and > practical) use case that will break if we go with #1? The auditing > issues for #2/#3 are complex to say the least... So we are back to choosing door 1, door 2 or door 3. That brings us back to our previous e-mail, where we suggested that the most fundamental question to answer with the LSM issue is how much effective security is being purchased at what complexity cost. We are practical guys at our company, we direct the development and deployment of practical SGX systems, including an independent implementation of SGX runtime/attestation/provisioning et.al. Our comments, for whatever they are worth, are meant to reflect the real world deployment of this technology. Lets start big picture. One of the clients we are consulting with on this technology is running well north of 1400 Linux systems. Every one of which has selinux=0 in /proc/cmdline and will do so until approximately the heat death of the Universe. Our AI LSM will use any SGX LSM driver hooks that eventuate from these discussions, so we support the notion of the LSM getting a look at permissions of executable code. However, our client isn't unique in their configuration choice, so we believe this fact calls the question as to how much SGX specific complexity should be injected into the LSM. So, as we noted in our previous e-mail, there are only two relevant security questions the LSM needs to answer: 1.) Should a page of memory with executable content be allowed into an enclave? 2.) Should an enclave be allowed to possess one or more pages of executable memory which will have WX permissions sometime during its lifetime? Sean is suggesting the strategy of an ioctl to call out pages that conform to question 2 (EAUG'ed pages). That doesn't seem like an onerous requirement, since all of the current enclave loaders already have all of the metadata infrastructure to map/load page ranges. The EAUG WX range would simply be another layout type that gets walked over when the enclave image is built. Given that, we were somewhat surprised to hear Sean say that he had been advised that door 1 was a non-starter. Presumably this was because of the need to delineate a specific cohort of pages that will be permitted WX. If that is the case, the question that needs to be called, as Stephen alludes to above, is whether or not WX privileges should be considered a characterizing feature of the VMA that defines an enclave rather then a per page attribute. Do we realistically believe that an LSM will be implemented that reacts differently when the 357th page of WX memory is added as opposed to the first? The operative security question is whether or not the platform owner is willing to allow arbitrary executable code, that they may have no visibility into, to be executed on their platform. We talk to people that, as a technology, SGX is about building 'security archipelagos', islands of trusted execution on potentially multiple platforms that interact to deliver a service, all of which consider their surrounding platforms and the network in between them as adversarial. This model is, by definition, adverserial to the notion and function of the LSM. With respect to SGX dynamic code loading, the future for security concious architectures, will be to pull the code from remotely attested repository servers over the network. The only relevant security question that can be answered is whether or not a platform owner feels comfortable with that model. Best wishes for a pleasant weekend to everyone. Dr. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "My spin on the meeting? I lie somewhere between the individual who feels that we are all going to join hands and march forward carrying the organization into the information age and Dr. Wettstein. Who feels that they are holding secret meetings at 6 o'clock in the morning plotting strategy on how to replace our system." -- Paul S. Etzell, M.D. Medical Director, Roger Maris Cancer
[PATCH] kexec: fix warnig of crash_zero_bytes in crash.c
This patch fixes the following sparse warning:
arch/x86/kernel/crash.c:59:15:
warning: symbol 'crash_zero_bytes' was not declared. Should it be static?
In addition, crash_zero_bytes is used when CONFIG_KEXEC_FILE is
set, so make it only available under CONFIG_KEXEC_FILE. Otherwise,
if CONFIG_KEXEC_FILE is not set, the following warning will appear:
arch/x86/kernel/crash.c:59:22:
warning: ‘crash_zero_bytes’ defined but not used [-Wunused-variable]
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Tiezhu Yang
Cc: Vivek Goyal
---
arch/x86/kernel/crash.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 576b2e1..f13480e 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -56,7 +56,9 @@ struct crash_memmap_data {
*/
crash_vmclear_fn __rcu *crash_vmclear_loaded_vmcss = NULL;
EXPORT_SYMBOL_GPL(crash_vmclear_loaded_vmcss);
-unsigned long crash_zero_bytes;
+#ifdef CONFIG_KEXEC_FILE
+static unsigned long crash_zero_bytes;
+#endif
static inline void cpu_crash_vmclear_loaded_vmcss(void)
{
--
1.8.3.1
Re: [PATCH v2 2/5] objtool: Fix ORC unwinding in non-JIT BPF generated code
On Fri, Jun 14, 2019 at 02:22:59PM -0700, Alexei Starovoitov wrote: > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote: > > > > > > > > > > > > +#define JUMP_TABLE_SYM_PREFIX "jump_table." > > > > > > > > > > since external tool will be looking at it should it be named > > > > > "bpf_jump_table." to avoid potential name conflicts? > > > > > Or even more unique name? > > > > > Like "bpf_interpreter_jump_table." ? > > > > > > > > No, the point is that it's a generic feature which can also be used any > > > > non-BPF code which might also have a jump table. > > > > > > and you're proposing to name all such jump tables in the kernel > > > as static foo jump_table[] ? > > > > That's the idea. > > Then it needs much wider discussion. Why would it need wider discussion? It only has one user. If you honestly believe that it will be controversial to require future users to call a static jump table "jump_table" then we can have that discussion when it comes up. -- Josh
[PATCH v3 1/3] dt-bindings: power: reset: qcom: Add qcom,pm8998-pon compatibility line
Update bindings to support for qcom,pm8998-pon which uses gen2 pon Cc: Andy Gross Cc: David Brown Cc: Bjorn Andersson Cc: Amit Pundir Cc: Rob Herring Cc: Mark Rutland Cc: Sebastian Reichel Cc: linux-arm-...@vger.kernel.org Cc: devicet...@vger.kernel.org Reviewed-by: Bjorn Andersson Signed-off-by: John Stultz --- v3: Typo fix in commit log suggeted by Marc Gonzalez --- Documentation/devicetree/bindings/power/reset/qcom,pon.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.txt b/Documentation/devicetree/bindings/power/reset/qcom,pon.txt index 5705f575862df..0c0dc3a1e693e 100644 --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.txt +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.txt @@ -9,6 +9,7 @@ Required Properties: -compatible: Must be one of: "qcom,pm8916-pon" "qcom,pms405-pon" + "qcom,pm8998-pon" -reg: Specifies the physical address of the pon register -- 2.17.1
[PATCH v3 3/3] arm64: dts: qcom: pm8998: Use qcom,pm8998-pon binding for second gen pon
This changes pm8998 to use the new qcom,pm8998-pon compatible
string for the pon in order to support the gen2 pon
functionality properly.
Cc: Andy Gross
Cc: David Brown
Cc: Bjorn Andersson
Cc: Amit Pundir
Cc: Rob Herring
Cc: Mark Rutland
Cc: Sebastian Reichel
Cc: linux-arm-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Reviewed-by: Bjorn Andersson
Signed-off-by: John Stultz
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi
b/arch/arm64/boot/dts/qcom/pm8998.dtsi
index d3ca35a940fb6..051a52df80f9e 100644
--- a/arch/arm64/boot/dts/qcom/pm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8998.dtsi
@@ -39,7 +39,7 @@
#size-cells = <0>;
pm8998_pon: pon@800 {
- compatible = "qcom,pm8916-pon";
+ compatible = "qcom,pm8998-pon";
reg = <0x800>;
mode-bootloader = <0x2>;
--
2.17.1
[PATCH v3 2/3] reset: qcom-pon: Add support for gen2 pon
Add support for gen2 pon register so "reboot bootloader" can
work on pixel3 and db845.
Cc: Andy Gross
Cc: David Brown
Cc: Bjorn Andersson
Cc: Amit Pundir
Cc: Rob Herring
Cc: Mark Rutland
Cc: Sebastian Reichel
Cc: linux-arm-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Reviewed-by: Bjorn Andersson
Signed-off-by: John Stultz
v2:
* Split out dts changes into separate path
* Minor cleanups and remove unused variables
---
drivers/power/reset/qcom-pon.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/power/reset/qcom-pon.c b/drivers/power/reset/qcom-pon.c
index 3fa1642d4c543..22a743a0bf28c 100644
--- a/drivers/power/reset/qcom-pon.c
+++ b/drivers/power/reset/qcom-pon.c
@@ -14,11 +14,15 @@
#define PON_SOFT_RB_SPARE 0x8f
+#define GEN1_REASON_SHIFT 2
+#define GEN2_REASON_SHIFT 1
+
struct pm8916_pon {
struct device *dev;
struct regmap *regmap;
u32 baseaddr;
struct reboot_mode_driver reboot_mode;
+ long reason_shift;
};
static int pm8916_reboot_mode_write(struct reboot_mode_driver *reboot,
@@ -30,7 +34,7 @@ static int pm8916_reboot_mode_write(struct reboot_mode_driver
*reboot,
ret = regmap_update_bits(pon->regmap,
pon->baseaddr + PON_SOFT_RB_SPARE,
-0xfc, magic << 2);
+0xfc, magic << pon->reason_shift);
if (ret < 0)
dev_err(pon->dev, "update reboot mode bits failed\n");
@@ -60,6 +64,7 @@ static int pm8916_pon_probe(struct platform_device *pdev)
return error;
pon->reboot_mode.dev = >dev;
+ pon->reason_shift = (long)of_device_get_match_data(>dev);
pon->reboot_mode.write = pm8916_reboot_mode_write;
error = devm_reboot_mode_register(>dev, >reboot_mode);
if (error) {
@@ -73,8 +78,9 @@ static int pm8916_pon_probe(struct platform_device *pdev)
}
static const struct of_device_id pm8916_pon_id_table[] = {
- { .compatible = "qcom,pm8916-pon" },
- { .compatible = "qcom,pms405-pon" },
+ { .compatible = "qcom,pm8916-pon", .data = (void *)GEN1_REASON_SHIFT },
+ { .compatible = "qcom,pms405-pon", .data = (void *)GEN1_REASON_SHIFT },
+ { .compatible = "qcom,pm8998-pon", .data = (void *)GEN2_REASON_SHIFT },
{ }
};
MODULE_DEVICE_TABLE(of, pm8916_pon_id_table);
--
2.17.1
Re: [PATCH v2 4/5] x86/bpf: Fix 64-bit JIT frame pointer usage
On Fri, Jun 14, 2019 at 02:27:30PM -0700, Alexei Starovoitov wrote: > On Fri, Jun 14, 2019 at 2:19 PM Josh Poimboeuf wrote: > > > > On Fri, Jun 14, 2019 at 02:05:56PM -0700, Alexei Starovoitov wrote: > > > Have you tested it ? > > > I really doubt, since in my test both CONFIG_UNWINDER_ORC and > > > CONFIG_UNWINDER_FRAME_POINTER failed to unwind through such odd frame. > > > > Hm, are you seeing selftest failures? They seem to work for me. > > > > > Here is much simple patch that I mentioned in the email yesterday, > > > but you failed to listen instead of focusing on perceived 'code > > > readability'. > > > > > > It makes one proper frame and both frame and orc unwinders are happy. > > > > I'm on my way out the door and I just skimmed it, but it looks fine. > > > > Some of the code and patch description look familiar, please be sure to > > give me proper credit. > > credit means something positive. So you only give credit for *good* stolen code. I must have missed that section of the kernel patch guidelines. Ironically you posted this patch right after you accused me of removing Song's SOB (which I didn't). > your contribution to bpf jit fix was negative. You have a delightful personality. -- Josh
RE: [PATCH 2/2] hv_balloon: Reorganize the probe function
> From: Michael Kelley
> Sent: Friday, June 14, 2019 2:56 PM
> > ...
> > + ret = balloon_connect_vsp(dev);
> > + if (ret != 0)
> > + return ret;
> > +
> > dm_device.state = DM_INITIALIZED;
> > - last_post_time = jiffies;
>
> I was curious about the above deletion. But I guess the line
> is not needed as the time_after() check in post_status() should
> handle an initial value of 0 for last_post_time just fine.
In a 32-bit kernel, sizeof(unsigned long) is 4, and the global 32-bit
varilable "jiffies" can overflow in 49.7 days if HZ is defined as 1000;
so in theory there is a tiny chance time_after() can not work as
expected here (i.e. we're loading hv_balloon driver when the
"jiffies" is just about to overflow, which is highly unlikely in practice);
even if that happens, we do not care, since the consequence is
just that the memory pressure reporting is delayed by 1 second. :-)
> > +
> > + dm_device.thread =
> > +kthread_run(dm_thread_func, _device, "hv_balloon");
> > + if (IS_ERR(dm_device.thread)) {
> > + ret = PTR_ERR(dm_device.thread);
> > + goto probe_error;
> > + }
>
> Just an observation: this thread creation now happens at the end of the
> probing process. But that's good, because in the old code, the thread
> was started and could run before the protocol version had been
> negotiated. So I'll assume your change here is intentional.
Yes, this is intentional.
> >
> > return 0;
> >
> > -probe_error2:
> > +probe_error:
> > + vmbus_close(dev->channel);
> > #ifdef CONFIG_MEMORY_HOTPLUG
> > + unregister_memory_notifier(_memory_nb);
>
> Hmmm. Evidently the above cleanup was missing in the
> old code.
Yes.
> > restore_online_page_callback(_online_page);
> > #endif
> > - kthread_stop(dm_device.thread);
> > -
> > -probe_error1:
> > - vmbus_close(dev->channel);
> > return ret;
> > }
> >
> > @@ -1734,11 +1742,11 @@ static int balloon_remove(struct hv_device
> *dev)
> > cancel_work_sync(>balloon_wrk.wrk);
> > cancel_work_sync(>ha_wrk.wrk);
> >
> > - vmbus_close(dev->channel);
> > kthread_stop(dm->thread);
> > + vmbus_close(dev->channel);
>
> Presumably this is an intentional ordering change as well.
> The kthread should be stopped before closing the channel.
Yes. The old code is buggy: after the vmbus_close(), there is
a small window in which the old code can still try to send
messages to the host via a freed ringbuffer, causing panic.
> > #ifdef CONFIG_MEMORY_HOTPLUG
> > - restore_online_page_callback(_online_page);
> > unregister_memory_notifier(_memory_nb);
> > + restore_online_page_callback(_online_page);
>
> And you've changed the ordering of these steps so they are
> the inverse of when they are set up. Also a good cleanup
Yes. The change is not really necessary, but let's just do it
in a better manner.
>
> Reviewed-by: Michael Kelley
Thaks for the detailed comments!
Thanks,
-- Dexuan
[PATCH bpf] bpf, x64: fix stack layout of JITed bpf code
Since commit 177366bf7ceb the %rbp stopped pointing to %rbp of the
previous stack frame. That broke frame pointer based stack unwinding.
This commit is a partial revert of it.
Note that the location of tail_call_cnt is fixed, since the verifier
enforces MAX_BPF_STACK stack size for programs with tail calls.
Fixes: 177366bf7ceb ("bpf: change x86 JITed program stack layout")
Signed-off-by: Alexei Starovoitov
---
arch/x86/net/bpf_jit_comp.c | 74 +++--
1 file changed, 21 insertions(+), 53 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index afabf597c855..d88bc0935886 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -190,9 +190,7 @@ struct jit_context {
#define BPF_MAX_INSN_SIZE 128
#define BPF_INSN_SAFETY64
-#define AUX_STACK_SPACE40 /* Space for RBX, R13, R14, R15,
tailcnt */
-
-#define PROLOGUE_SIZE 37
+#define PROLOGUE_SIZE 20
/*
* Emit x86-64 prologue code for BPF program and check its size.
@@ -203,44 +201,19 @@ static void emit_prologue(u8 **pprog, u32 stack_depth,
bool ebpf_from_cbpf)
u8 *prog = *pprog;
int cnt = 0;
- /* push rbp */
- EMIT1(0x55);
-
- /* mov rbp,rsp */
- EMIT3(0x48, 0x89, 0xE5);
-
- /* sub rsp, rounded_stack_depth + AUX_STACK_SPACE */
- EMIT3_off32(0x48, 0x81, 0xEC,
- round_up(stack_depth, 8) + AUX_STACK_SPACE);
-
- /* sub rbp, AUX_STACK_SPACE */
- EMIT4(0x48, 0x83, 0xED, AUX_STACK_SPACE);
-
- /* mov qword ptr [rbp+0],rbx */
- EMIT4(0x48, 0x89, 0x5D, 0);
- /* mov qword ptr [rbp+8],r13 */
- EMIT4(0x4C, 0x89, 0x6D, 8);
- /* mov qword ptr [rbp+16],r14 */
- EMIT4(0x4C, 0x89, 0x75, 16);
- /* mov qword ptr [rbp+24],r15 */
- EMIT4(0x4C, 0x89, 0x7D, 24);
-
+ EMIT1(0x55); /* push rbp */
+ EMIT3(0x48, 0x89, 0xE5); /* mov rbp, rsp */
+ /* sub rsp, rounded_stack_depth */
+ EMIT3_off32(0x48, 0x81, 0xEC, round_up(stack_depth, 8));
+ EMIT1(0x53); /* push rbx */
+ EMIT2(0x41, 0x55); /* push r13 */
+ EMIT2(0x41, 0x56); /* push r14 */
+ EMIT2(0x41, 0x57); /* push r15 */
if (!ebpf_from_cbpf) {
- /*
-* Clear the tail call counter (tail_call_cnt): for eBPF tail
-* calls we need to reset the counter to 0. It's done in two
-* instructions, resetting RAX register to 0, and moving it
-* to the counter location.
-*/
-
- /* xor eax, eax */
- EMIT2(0x31, 0xc0);
- /* mov qword ptr [rbp+32], rax */
- EMIT4(0x48, 0x89, 0x45, 32);
-
+ /* zero init tail_call_cnt */
+ EMIT2(0x6a, 0x00);
BUILD_BUG_ON(cnt != PROLOGUE_SIZE);
}
-
*pprog = prog;
}
@@ -285,13 +258,13 @@ static void emit_bpf_tail_call(u8 **pprog)
* if (tail_call_cnt > MAX_TAIL_CALL_CNT)
* goto out;
*/
- EMIT2_off32(0x8B, 0x85, 36); /* mov eax, dword ptr [rbp +
36] */
+ EMIT2_off32(0x8B, 0x85, -36 - MAX_BPF_STACK); /* mov eax, dword ptr
[rbp - 548] */
EMIT3(0x83, 0xF8, MAX_TAIL_CALL_CNT); /* cmp eax, MAX_TAIL_CALL_CNT
*/
#define OFFSET2 (30 + RETPOLINE_RAX_BPF_JIT_SIZE)
EMIT2(X86_JA, OFFSET2); /* ja out */
label2 = cnt;
EMIT3(0x83, 0xC0, 0x01); /* add eax, 1 */
- EMIT2_off32(0x89, 0x85, 36); /* mov dword ptr [rbp + 36],
eax */
+ EMIT2_off32(0x89, 0x85, -36 - MAX_BPF_STACK); /* mov dword ptr [rbp
-548], eax */
/* prog = array->ptrs[index]; */
EMIT4_off32(0x48, 0x8B, 0x84, 0xD6, /* mov rax, [rsi + rdx * 8 +
offsetof(...)] */
@@ -1040,19 +1013,14 @@ xadd: if (is_imm8(insn->off))
seen_exit = true;
/* Update cleanup_addr */
ctx->cleanup_addr = proglen;
- /* mov rbx, qword ptr [rbp+0] */
- EMIT4(0x48, 0x8B, 0x5D, 0);
- /* mov r13, qword ptr [rbp+8] */
- EMIT4(0x4C, 0x8B, 0x6D, 8);
- /* mov r14, qword ptr [rbp+16] */
- EMIT4(0x4C, 0x8B, 0x75, 16);
- /* mov r15, qword ptr [rbp+24] */
- EMIT4(0x4C, 0x8B, 0x7D, 24);
-
- /* add rbp, AUX_STACK_SPACE */
- EMIT4(0x48, 0x83, 0xC5, AUX_STACK_SPACE);
- EMIT1(0xC9); /* leave */
- EMIT1(0xC3); /* ret */
+ if (!bpf_prog_was_classic(bpf_prog))
+ EMIT1(0x5B); /* get rid of tail_call_cnt */
+ EMIT2(0x41, 0x5F); /* pop r15 */
+
Re: [PATCH] Smack: Restore the smackfsdef mount option and add missing prefixes
On 6/3/2019 4:07 PM, Casey Schaufler wrote: > On 6/3/2019 3:42 PM, James Morris wrote: >> On Fri, 31 May 2019, David Howells wrote: >> >>> Should this go via Al's tree, James's tree, Casey's tree or directly to >>> Linus? >> If it's specific to one LSM (as this is), via Casey, who can decide to >> forward to Al or Linus. > I would very much appreciate it if Al could send this fix along. > I am not fully set up for sending directly to Linus. Al, are you going to take this, or should I find another way to get it in for 5.2?
Re: [PATCH v3 1/3] thermal: sun8i: add thermal driver for h6
On Wed, Jun 12, 2019 at 9:50 AM Frank Lee wrote: > > > If you have a git tree I'll be happy to contribute A64 support. IIRC > > it was quite similar to H3. > > I built a ths branch and I will do some work later. > > https://github.com/TinyWindzz/linux/tree/ths Looks like you forgot to add your patches to this branch.
Re: [PATCH 3/4] ARM: dts: rockchip: add display nodes for rk322x
Stephen,
Am Freitag, 14. Juni 2019, 22:36:09 CEST schrieb Stephen Boyd:
> Quoting Heiko Stuebner (2019-06-14 12:33:12)
> > Am Freitag, 14. Juni 2019, 20:32:35 CEST schrieb Justin Swartz:
> > > On 2019-06-14 19:45, Stephen Boyd wrote:
> > > >> diff --git a/arch/arm/boot/dts/rk322x.dtsi
> > > >> b/arch/arm/boot/dts/rk322x.dtsi
> > > >> index da102fff96a2..148f9b5157ea 100644
> > > >> --- a/arch/arm/boot/dts/rk322x.dtsi
> > > >> +++ b/arch/arm/boot/dts/rk322x.dtsi
> > > >> @@ -143,6 +143,11 @@
> > > >> #clock-cells = <0>;
> > > >> };
> > > >>
> > > >> + display_subsystem: display-subsystem {
> > > >> + compatible = "rockchip,display-subsystem";
> > > >> + ports = <_out>;
> > > >> + };
> > > >> +
> > > >
> > > > What is this? It doesn't have a reg property so it looks like a virtual
> > > > device. Why is it in DT?
> > >
> > > This is a virtual device.
> > >
> > > I assumed it would be acceptable to it find in a device tree due to
> > > binding documentation,
> > > "Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt,
> > > which states:
> > >
> > >
> > > The Rockchip DRM master device is a virtual device needed to list all
> > > vop devices or other display interface nodes that comprise the
> > > graphics subsystem.
> > >
> > >
> > > Without the "display_subsystem" device node, the HDMI PHY and
> > > rockchipdrmfb frame buffer device are not initialized.
> > >
> > > Perhaps I should have included this in my commit message? :)
> >
> > As Justin said, that is very much common as the root of the components
> > that make up the drm device and pretty much common in a lot of devicetrees
> > for the last 5 years and longer ;-) .
> >
> > Also gpio-keys also don't have a reg property ;-) .
> >
>
> Do you have a SoC node? If so, this virtual device should live in the
> root, away from the nodes that have reg properties and are thus in the
> SoC node.
no we don't have any soc node and that display-subsystem is really the
same on _all_ currently supported Rockchip socs ... has gone through
dt-reviews numerous times for multiple socs, so I'm somewhat
confident that we're not doing something terrible wrong.
Heiko
Re: [PATCH net-next 2/2 v5] netns: restrict uevents
Hi Christian,
On Sun, Apr 29, 2018 at 3:45 AM Christian Brauner
wrote:
>
> commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces")
>abhishe...@google.com
> enabled sending hotplug events into all network namespaces back in 2010.
> Over time the set of uevents that get sent into all network namespaces has
> shrunk. We have now reached the point where hotplug events for all devices
> that carry a namespace tag are filtered according to that namespace.
> Specifically, they are filtered whenever the namespace tag of the kobject
> does not match the namespace tag of the netlink socket.
> Currently, only network devices carry namespace tags (i.e. network
> namespace tags). Hence, uevents for network devices only show up in the
> network namespace such devices are created in or moved to.
>
> However, any uevent for a kobject that does not have a namespace tag
> associated with it will not be filtered and we will broadcast it into all
> network namespaces. This behavior stopped making sense when user namespaces
> were introduced.
>
> This patch simplifies and fixes couple of things:
> - Split codepath for sending uevents by kobject namespace tags:
> 1. Untagged kobjects - uevent_net_broadcast_untagged():
> Untagged kobjects will be broadcast into all uevent sockets recorded
> in uevent_sock_list, i.e. into all network namespacs owned by the
> intial user namespace.
> 2. Tagged kobjects - uevent_net_broadcast_tagged():
> Tagged kobjects will only be broadcast into the network namespace they
> were tagged with.
> Handling of tagged kobjects in 2. does not cause any semantic changes.
> This is just splitting out the filtering logic that was handled by
> kobj_bcast_filter() before.
> Handling of untagged kobjects in 1. will cause a semantic change. The
> reasons why this is needed and ok have been discussed in [1]. Here is a
> short summary:
> - Userspace ignores uevents from network namespaces that are not owned by
> the intial user namespace:
> Uevents are filtered by userspace in a user namespace because the
> received uid != 0. Instead the uid associated with the event will be
> 65534 == "nobody" because the global root uid is not mapped.
> This means we can safely and without introducing regressions modify the
> kernel to not send uevents into all network namespaces whose owning
> user namespace is not the initial user namespace because we know that
> userspace will ignore the message because of the uid anyway.
> I have a) verified that is is true for every udev implementation out
> there b) that this behavior has been present in all udev
> implementations from the very beginning.
Unfortunately udev is not the only consumer of uevents, for example on
Android there is healthd that also consumes uevents, and this
particular change broke Android running in a container on Chrome OS.
Can this be reverted? Or, if we want to keep this, how can containers
that use separate user namespace still listen to uevents?
Thanks.
--
Dmitry
[PATCH] Revert "ARM: dts: rockchip: set PWM delay backlight settings for Minnie"
This reverts commit 288ceb85b505c19abe1895df068dda5ed20cf482.
According to the commit message the AUO B101EAN01 panel on minnie
requires a PWM delay of 200 ms, however this is not what the
datasheet says. The datasheet mentions a *max* delay of 200 ms
for T2 ("delay from LCDVDD to black video generation") and T3
("delay from LCDVDD to HPD high"), which aren't related to the
PWM. The backlight power sequence does not specify min/max
constraints for T15 (time from PWM on to BL enable) or T16
(time from BL disable to PWM off).
Signed-off-by: Matthias Kaehlcke
---
Enric, if you think I misinterpreted the datasheet please holler!
---
arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index 468a1818545d..28cbe07f96ec 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -86,8 +86,6 @@
240 241 242 243 244 245 246 247
248 249 250 251 252 253 254 255>;
power-supply = <_regulator>;
- post-pwm-on-delay-ms = <200>;
- pwm-off-delay-ms = <200>;
};
{
--
2.22.0.410.gd8fdbe21b5-goog
Re: [PATCH, RFC 20/62] mm/page_ext: Export lookup_page_ext() symbol
On Fri, Jun 14, 2019 at 01:12:59PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:43:40PM +0300, Kirill A. Shutemov wrote: > > page_keyid() is inline funcation that uses lookup_page_ext(). KVM is > > going to use page_keyid() and since KVM can be built as a module > > lookup_page_ext() has to be exported. > > I _really_ hate having to export world+dog for KVM. This one might not > be a real issue, but I itch every time I see an export for KVM these > days. Is there any better way? Do we need to invent EXPORT_SYMBOL_KVM()? :P -- Kirill A. Shutemov
Re: [PATCH, RFC 18/62] x86/mm: Implement syncing per-KeyID direct mappings
On Fri, Jun 14, 2019 at 11:51:32AM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:43:38PM +0300, Kirill A. Shutemov wrote: > > For MKTME we use per-KeyID direct mappings. This allows kernel to have > > access to encrypted memory. > > > > sync_direct_mapping() sync per-KeyID direct mappings with a canonical > > one -- KeyID-0. > > > > The function tracks changes in the canonical mapping: > > - creating or removing chunks of the translation tree; > > - changes in mapping flags (i.e. protection bits); > > - splitting huge page mapping into a page table; > > - replacing page table with a huge page mapping; > > > > The function need to be called on every change to the direct mapping: > > hotplug, hotremove, changes in permissions bits, etc. > > And yet I don't see anything in pageattr.c. You're right. I've hooked up the sync in the wrong place. > > Also, this seems like an expensive scheme; if you know where the changes > where, a more fine-grained update would be faster. Do we have any hot enough pageattr users that makes it crucial? I'll look into this anyway. -- Kirill A. Shutemov
Re: [PATCH, RFC 13/62] x86/mm: Add hooks to allocate and free encrypted pages
On Fri, Jun 14, 2019 at 03:43:35PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 14, 2019 at 04:28:36PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Jun 14, 2019 at 01:04:58PM +0200, Peter Zijlstra wrote:
> > > On Fri, Jun 14, 2019 at 11:34:09AM +0200, Peter Zijlstra wrote:
> > > > On Wed, May 08, 2019 at 05:43:33PM +0300, Kirill A. Shutemov wrote:
> > > >
> > > > > + lookup_page_ext(page)->keyid = keyid;
> > >
> > > > > + lookup_page_ext(page)->keyid = 0;
> > >
> > > Also, perhaps paranoid; but do we want something like:
> > >
> > > static inline void page_set_keyid(struct page *page, int keyid)
> > > {
> > > /* ensure nothing creeps after changing the keyid */
> > > barrier();
> > > WRITE_ONCE(lookup_page_ext(page)->keyid, keyid);
> > > barrier();
> > > /* ensure nothing creeps before changing the keyid */
> > > }
> > >
> > > And this is very much assuming there is no concurrency through the
> > > allocator locks.
> >
> > There's no concurrency for this page: it has been off the free list, but
> > have not yet passed on to user. Nobody else sees the page before
> > allocation is finished.
> >
> > And barriers/WRITE_ONCE() looks excessive to me. It's just yet another bit
> > of page's metadata and I don't see why it's has to be handled in a special
> > way.
> >
> > Does it relax your paranoia? :P
>
> Not really, it all 'works' because clflush_cache_range() includes mb()
> and page_address() has an address dependency on the store, and there are
> no other sites that will ever change 'keyid', which is all kind of
> fragile.
Hm. I don't follow how the mb() in clflush_cache_range() relevant...
Any following access of page's memory by kernel will go through
page_keyid() and therefore I believe there's always address dependency on
the store.
Am I missing something?
> At the very least that should be explicitly called out in a comment.
>
--
Kirill A. Shutemov
Re: [PATCH v2 bpf-next] bpf: sk_storage: Fix out of bounds memory access
On 06/15/2019 12:31 AM, Andrii Nakryiko wrote: > On Fri, Jun 14, 2019 at 2:45 AM Arthur Fabre wrote: >> >> bpf_sk_storage maps use multiple spin locks to reduce contention. >> The number of locks to use is determined by the number of possible CPUs. >> With only 1 possible CPU, bucket_log == 0, and 2^0 = 1 locks are used. >> >> When updating elements, the correct lock is determined with hash_ptr(). >> Calling hash_ptr() with 0 bits is undefined behavior, as it does: >> >> x >> (64 - bits) >> >> Using the value results in an out of bounds memory access. >> In my case, this manifested itself as a page fault when raw_spin_lock_bh() >> is called later, when running the self tests: >> >> ./tools/testing/selftests/bpf/test_verifier 773 775 >> >> [ 16.366342] BUG: unable to handle page fault for address: 8fe7a66f93f8 >> [ 16.367139] #PF: supervisor write access in kernel mode >> [ 16.367751] #PF: error_code(0x0002) - not-present page >> [ 16.368323] PGD 35a01067 P4D 35a01067 PUD 0 >> [ 16.368796] Oops: 0002 [#1] SMP PTI >> [ 16.369175] CPU: 0 PID: 189 Comm: test_verifier Not tainted 5.2.0-rc2+ #10 >> [ 16.369960] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >> 1.12.0-1 04/01/2014 >> [ 16.371021] RIP: 0010:_raw_spin_lock_bh >> (/home/afabre/linux/./include/trace/events/initcall.h:48) >> [ 16.371571] Code: 02 00 00 31 c0 ba ff 00 00 00 3e 0f b1 17 75 01 c3 e9 82 >> 12 5f ff 66 90 65 81 05 ad 14 6f 41 00 02 00 00 31 c0 ba 01 00 00 00 <3e> 0f >> b1 17 75 01 c3 89 c6 e9 f0 02 5f ff b8 00 02 00 00 3e 0f c1 >> All code >> >>0: 02 00 add(%rax),%al >>2: 00 31 add%dh,(%rcx) >>4: c0 ba ff 00 00 00 3esarb $0x3e,0xff(%rdx) >>b: 0f b1 17cmpxchg %edx,(%rdi) >>e: 75 01 jne0x11 >> 10: c3 retq >> 11: e9 82 12 5f ff jmpq 0xff5f1298 >> 16: 66 90 xchg %ax,%ax >> 18: 65 81 05 ad 14 6f 41addl $0x200,%gs:0x416f14ad(%rip)# >> 0x416f14d0 >> 1f: 00 02 00 00 >> 23: 31 c0 xor%eax,%eax >> 25: ba 01 00 00 00 mov$0x1,%edx >> 2a: 3e 0f b1 17 cmpxchg %edx,%ds:*(%rdi)<-- >> trapping instruction >> 2e: 75 01 jne0x31 >> 30: c3 retq >> 31: 89 c6 mov%eax,%esi >> 33: e9 f0 02 5f ff jmpq 0xff5f0328 >> 38: b8 00 02 00 00 mov$0x200,%eax >> 3d: 3e ds >> 3e: 0f .byte 0xf >> 3f: c1 .byte 0xc1 >> >> Code starting with the faulting instruction >> === >>0: 3e 0f b1 17 cmpxchg %edx,%ds:(%rdi) >>4: 75 01 jne0x7 >>6: c3 retq >>7: 89 c6 mov%eax,%esi >>9: e9 f0 02 5f ff jmpq 0xff5f02fe >>e: b8 00 02 00 00 mov$0x200,%eax >> 13: 3e ds >> 14: 0f .byte 0xf >> 15: c1 .byte 0xc1 >> [ 16.373398] RSP: 0018:a759809d3be0 EFLAGS: 00010246 >> [ 16.373954] RAX: RBX: 8fe7a66f93f0 RCX: >> 0040 >> [ 16.374645] RDX: 0001 RSI: 8fdaf9f0d180 RDI: >> 8fe7a66f93f8 >> [ 16.375338] RBP: 8fdaf9f0d180 R08: 8fdafba2c320 R09: >> 8fdaf9f0d0c0 >> [ 16.376028] R10: R11: R12: >> 8fdafa346700 >> [ 16.376719] R13: 8fe7a66f93f8 R14: 8fdaf9f0d0c0 R15: >> 0001 >> [ 16.377413] FS: 7fda724c0740() GS:8fdafba0() >> knlGS: >> [ 16.378204] CS: 0010 DS: ES: CR0: 80050033 >> [ 16.378763] CR2: 8fe7a66f93f8 CR3: 000139d1c006 CR4: >> 00360ef0 >> [ 16.379453] DR0: DR1: DR2: >> >> [ 16.380144] DR3: DR6: fffe0ff0 DR7: >> 0400 >> [ 16.380864] Call Trace: >> [ 16.381112] selem_link_map >> (/home/afabre/linux/./include/linux/compiler.h:221 >> /home/afabre/linux/net/core/bpf_sk_storage.c:243) >> [ 16.381476] sk_storage_update >> (/home/afabre/linux/net/core/bpf_sk_storage.c:355 >> /home/afabre/linux/net/core/bpf_sk_storage.c:414) >> [ 16.381888] bpf_sk_storage_get >> (/home/afabre/linux/net/core/bpf_sk_storage.c:760 >> /home/afabre/linux/net/core/bpf_sk_storage.c:741) >> [ 16.382285] ___bpf_prog_run (/home/afabre/linux/kernel/bpf/core.c:1447) >> [ 16.382679] ? __bpf_prog_run32 (/home/afabre/linux/kernel/bpf/core.c:1603) >> [ 16.383074] ? alloc_file_pseudo (/home/afabre/linux/fs/file_table.c:232) >> [ 16.383486] ? kvm_clock_get_cycles >> (/home/afabre/linux/arch/x86/kernel/kvmclock.c:98) >> [ 16.383906] ?
Re: [PATCH] ACPI: PM: Export the function acpi_sleep_state_supported()
Hi, On Fri, Jun 14, 2019 at 10:19:02PM +, Dexuan Cui wrote: > > -Original Message- > > From: Michael Kelley > > Sent: Friday, June 14, 2019 1:48 PM > > To: Dexuan Cui ; linux-a...@vger.kernel.org; > > r...@rjwysocki.net; l...@kernel.org; robert.mo...@intel.com; > > erik.schma...@intel.com > > Cc: linux-hyp...@vger.kernel.org; linux-kernel@vger.kernel.org; KY > > Srinivasan > > ; Stephen Hemminger ; > > Haiyang Zhang ; Sasha Levin > > ; o...@aepfle.de; a...@canonical.com; > > jasow...@redhat.com; vkuznets ; > > marcelo.ce...@canonical.com > > Subject: RE: [PATCH] ACPI: PM: Export the function > > acpi_sleep_state_supported() > > > > It seems that sleep.c isn't built when on the ARM64 architecture. Using > > acpi_sleep_state_supported() directly in hv_balloon.c will be problematic > > since hv_balloon.c needs to be architecture independent when the > > Hyper-V ARM64 support is added. If that doesn't change, a per-architecture > > wrapper will be needed to give hv_balloon.c the correct information. This > > may affect whether acpi_sleep_state_supported() needs to be exported vs. > > just removing the "static". I'm not sure what the best approach is. > > > > Michael > > + some ARM experts who worked on arch/arm/kernel/hibernate.c. > > drivers/acpi/sleep.c is only built if ACPI_SYSTEM_POWER_STATES_SUPPORT > is defined, but it looks this option is not defined on ARM. > > It looks ARM does not support the ACPI S4 state, then how do we know > if an ARM host supports hibernation or not? Don't forget that Linux does not support ACPI on 32-bit ARM, which is quite different from the situation on 64-bit ARM. arch/arm/kernel/hibernate.c is only for 32-bit ARM, and is written with the assumption that there is no interaction required with any firmware to save state, and later restore state upon resuming. Or am I missing something? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
[PATCH v2 2/2] arm64: topology: Use PPTT to determine if PE is a thread
ACPI 6.3 adds a thread flag to represent if a CPU/PE is
actually a thread. Given that the MPIDR_MT bit may not
represent this information consistently on homogeneous machines
we should prefer the PPTT flag if its available.
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/topology.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 0825c4a856e3..cbbedb53cf06 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -346,11 +346,9 @@ void remove_cpu_topology(unsigned int cpu)
*/
static int __init parse_acpi_topology(void)
{
- bool is_threaded;
+ int is_threaded;
int cpu, topology_id;
- is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
-
for_each_possible_cpu(cpu) {
int i, cache_id;
@@ -358,6 +356,10 @@ static int __init parse_acpi_topology(void)
if (topology_id < 0)
return topology_id;
+ is_threaded = acpi_pptt_cpu_is_thread(cpu);
+ if (is_threaded < 0)
+ is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
+
if (is_threaded) {
cpu_topology[cpu].thread_id = topology_id;
topology_id = find_acpi_cpu_topology(cpu, 1);
--
2.21.0
[PATCH v2 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
ACPI 6.3 adds a flag to the CPU node to indicate whether
the given PE is a thread. Add a function to return that
information for a given linux logical CPU.
Signed-off-by: Jeremy Linton
---
drivers/acpi/pptt.c | 53 +++-
include/linux/acpi.h | 5 +
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
index b72e6afaa8fb..6f45f8c07b46 100644
--- a/drivers/acpi/pptt.c
+++ b/drivers/acpi/pptt.c
@@ -517,6 +517,43 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu,
int level, int flag)
return retval;
}
+/**
+ * check_acpi_cpu_flag() - Determine if CPU node has a flag set
+ * @cpu: Kernel logical CPU number
+ * @rev: The PPTT revision defining the flag
+ * @flag: The flag itself
+ *
+ * Check the node representing a CPU for a given flag.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found or
+ *the table revision isn't new enough.
+ * Otherwise returns flag value
+ */
+static int check_acpi_cpu_flag(unsigned int cpu, int rev, u32 flag)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ struct acpi_pptt_processor *cpu_node = NULL;
+ int ret = -ENOENT;
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, );
+ if (ACPI_FAILURE(status)) {
+ acpi_pptt_warn_missing();
+ return ret;
+ }
+
+ if (table->revision >= rev)
+ cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
+
+ if (cpu_node)
+ ret = cpu_node->flags & flag;
+
+ acpi_put_table(table);
+
+ return ret;
+}
+
/**
* acpi_find_last_cache_level() - Determines the number of cache levels for a
PE
* @cpu: Kernel logical CPU number
@@ -581,6 +618,21 @@ int cache_setup_acpi(unsigned int cpu)
return status;
}
+/**
+ * acpi_pptt_cpu_is_thread() - Determine if CPU is a thread
+ * @cpu: Kernel logical CPU number
+ *
+ *
+ * Return: 1, a thread
+ * 0, not a thread
+ * -ENOENT ,if the PPTT doesn't exist, the CPU cannot be found or
+ * the table revision isn't new enough.
+ */
+int acpi_pptt_cpu_is_thread(unsigned int cpu)
+{
+ return check_acpi_cpu_flag(cpu, 2, ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD);
+}
+
/**
* find_acpi_cpu_topology() - Determine a unique topology value for a given CPU
* @cpu: Kernel logical CPU number
@@ -641,7 +693,6 @@ int find_acpi_cpu_cache_topology(unsigned int cpu, int
level)
return ret;
}
-
/**
* find_acpi_cpu_topology_package() - Determine a unique CPU package value
* @cpu: Kernel logical CPU number
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index d315d86844e4..3e339375e213 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1301,10 +1301,15 @@ static inline int lpit_read_residency_count_address(u64
*address)
#endif
#ifdef CONFIG_ACPI_PPTT
+int acpi_pptt_cpu_is_thread(unsigned int cpu);
int find_acpi_cpu_topology(unsigned int cpu, int level);
int find_acpi_cpu_topology_package(unsigned int cpu);
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
#else
+static inline int acpi_pptt_cpu_is_thread(unsigned int cpu)
+{
+ return -EINVAL;
+}
static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
{
return -EINVAL;
--
2.21.0
[PATCH v2 0/2] arm64/PPTT ACPI 6.3 thread flag support
ACPI 6.3 adds a flag to the CPU node to indicate whether the given CPU is a thread. Add a function to return that information for a given linux logical CPU and then utilize it while building the arm64 topology. v1->v2: Return ENOENT instead on ENONET. Jeremy Linton (2): ACPI/PPTT: Add support for ACPI 6.3 thread flag arm64: topology: Use PPTT to determine if PE is a thread arch/arm64/kernel/topology.c | 8 -- drivers/acpi/pptt.c | 53 +++- include/linux/acpi.h | 5 3 files changed, 62 insertions(+), 4 deletions(-) -- 2.21.0
Re: [PATCH v2 bpf-next] bpf: sk_storage: Fix out of bounds memory access
On Fri, Jun 14, 2019 at 2:45 AM Arthur Fabre wrote: > > bpf_sk_storage maps use multiple spin locks to reduce contention. > The number of locks to use is determined by the number of possible CPUs. > With only 1 possible CPU, bucket_log == 0, and 2^0 = 1 locks are used. > > When updating elements, the correct lock is determined with hash_ptr(). > Calling hash_ptr() with 0 bits is undefined behavior, as it does: > > x >> (64 - bits) > > Using the value results in an out of bounds memory access. > In my case, this manifested itself as a page fault when raw_spin_lock_bh() > is called later, when running the self tests: > > ./tools/testing/selftests/bpf/test_verifier 773 775 > > [ 16.366342] BUG: unable to handle page fault for address: 8fe7a66f93f8 > [ 16.367139] #PF: supervisor write access in kernel mode > [ 16.367751] #PF: error_code(0x0002) - not-present page > [ 16.368323] PGD 35a01067 P4D 35a01067 PUD 0 > [ 16.368796] Oops: 0002 [#1] SMP PTI > [ 16.369175] CPU: 0 PID: 189 Comm: test_verifier Not tainted 5.2.0-rc2+ #10 > [ 16.369960] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.12.0-1 04/01/2014 > [ 16.371021] RIP: 0010:_raw_spin_lock_bh > (/home/afabre/linux/./include/trace/events/initcall.h:48) > [ 16.371571] Code: 02 00 00 31 c0 ba ff 00 00 00 3e 0f b1 17 75 01 c3 e9 82 > 12 5f ff 66 90 65 81 05 ad 14 6f 41 00 02 00 00 31 c0 ba 01 00 00 00 <3e> 0f > b1 17 75 01 c3 89 c6 e9 f0 02 5f ff b8 00 02 00 00 3e 0f c1 > All code > >0: 02 00 add(%rax),%al >2: 00 31 add%dh,(%rcx) >4: c0 ba ff 00 00 00 3esarb $0x3e,0xff(%rdx) >b: 0f b1 17cmpxchg %edx,(%rdi) >e: 75 01 jne0x11 > 10: c3 retq > 11: e9 82 12 5f ff jmpq 0xff5f1298 > 16: 66 90 xchg %ax,%ax > 18: 65 81 05 ad 14 6f 41addl $0x200,%gs:0x416f14ad(%rip)# > 0x416f14d0 > 1f: 00 02 00 00 > 23: 31 c0 xor%eax,%eax > 25: ba 01 00 00 00 mov$0x1,%edx > 2a: 3e 0f b1 17 cmpxchg %edx,%ds:*(%rdi)<-- > trapping instruction > 2e: 75 01 jne0x31 > 30: c3 retq > 31: 89 c6 mov%eax,%esi > 33: e9 f0 02 5f ff jmpq 0xff5f0328 > 38: b8 00 02 00 00 mov$0x200,%eax > 3d: 3e ds > 3e: 0f .byte 0xf > 3f: c1 .byte 0xc1 > > Code starting with the faulting instruction > === >0: 3e 0f b1 17 cmpxchg %edx,%ds:(%rdi) >4: 75 01 jne0x7 >6: c3 retq >7: 89 c6 mov%eax,%esi >9: e9 f0 02 5f ff jmpq 0xff5f02fe >e: b8 00 02 00 00 mov$0x200,%eax > 13: 3e ds > 14: 0f .byte 0xf > 15: c1 .byte 0xc1 > [ 16.373398] RSP: 0018:a759809d3be0 EFLAGS: 00010246 > [ 16.373954] RAX: RBX: 8fe7a66f93f0 RCX: > 0040 > [ 16.374645] RDX: 0001 RSI: 8fdaf9f0d180 RDI: > 8fe7a66f93f8 > [ 16.375338] RBP: 8fdaf9f0d180 R08: 8fdafba2c320 R09: > 8fdaf9f0d0c0 > [ 16.376028] R10: R11: R12: > 8fdafa346700 > [ 16.376719] R13: 8fe7a66f93f8 R14: 8fdaf9f0d0c0 R15: > 0001 > [ 16.377413] FS: 7fda724c0740() GS:8fdafba0() > knlGS: > [ 16.378204] CS: 0010 DS: ES: CR0: 80050033 > [ 16.378763] CR2: 8fe7a66f93f8 CR3: 000139d1c006 CR4: > 00360ef0 > [ 16.379453] DR0: DR1: DR2: > > [ 16.380144] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 16.380864] Call Trace: > [ 16.381112] selem_link_map > (/home/afabre/linux/./include/linux/compiler.h:221 > /home/afabre/linux/net/core/bpf_sk_storage.c:243) > [ 16.381476] sk_storage_update > (/home/afabre/linux/net/core/bpf_sk_storage.c:355 > /home/afabre/linux/net/core/bpf_sk_storage.c:414) > [ 16.381888] bpf_sk_storage_get > (/home/afabre/linux/net/core/bpf_sk_storage.c:760 > /home/afabre/linux/net/core/bpf_sk_storage.c:741) > [ 16.382285] ___bpf_prog_run (/home/afabre/linux/kernel/bpf/core.c:1447) > [ 16.382679] ? __bpf_prog_run32 (/home/afabre/linux/kernel/bpf/core.c:1603) > [ 16.383074] ? alloc_file_pseudo (/home/afabre/linux/fs/file_table.c:232) > [ 16.383486] ? kvm_clock_get_cycles > (/home/afabre/linux/arch/x86/kernel/kvmclock.c:98) > [ 16.383906] ? ktime_get (/home/afabre/linux/kernel/time/timekeeping.c:265 > /home/afabre/linux/kernel/time/timekeeping.c:369 >
Re: [PATCH v1 2/4] ASoC: Add codec driver for ST TDA7802
On 06/11/19 19:49, Thomas Preston wrote:
> Add an I2C based codec driver for ST TDA7802 amplifier. By default, the
> amplifier supports 4 audio channels but can support up to 16 with
> multiple devices. Input is configurable for I2S or TDM.
>
> The unified device properties API is used to get board-specific config from
> device tree / ACPI.
>
> Signed-off-by: Thomas Preston
> Cc: Patrick Glaser
> Cc: Rob Duncan
> Cc: Nate Case
> ---
> sound/soc/codecs/Kconfig | 6 +
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/tda7802.c | 580
> +
> 3 files changed, 588 insertions(+)
> create mode 100644 sound/soc/codecs/tda7802.c
>
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index e730d47ac85b..1d30c2333cb1 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -176,6 +176,7 @@ config SND_SOC_ALL_CODECS
> select SND_SOC_TAS5720 if I2C
> select SND_SOC_TAS6424 if I2C
> select SND_SOC_TDA7419 if I2C
> + select SND_SOC_TDA7802 if I2C
> select SND_SOC_TFA9879 if I2C
> select SND_SOC_TLV320AIC23_I2C if I2C
> select SND_SOC_TLV320AIC23_SPI if SPI_MASTER
> @@ -1078,6 +1079,11 @@ config SND_SOC_TDA7419
> depends on I2C
> select REGMAP_I2C
>
> +config SND_SOC_TDA7802
> + tristate "ST TDA7802 audio processor"
> + depends on I2C
> + select REGMAP_I2C
> +
> config SND_SOC_TFA9879
> tristate "NXP Semiconductors TFA9879 amplifier"
> depends on I2C
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index aa7720a7a0aa..fc3fc672bc4b 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -187,6 +187,7 @@ snd-soc-tas571x-objs := tas571x.o
> snd-soc-tas5720-objs := tas5720.o
> snd-soc-tas6424-objs := tas6424.o
> snd-soc-tda7419-objs := tda7419.o
> +snd-soc-tda7802-objs := tda7802.o
> snd-soc-tfa9879-objs := tfa9879.o
> snd-soc-tlv320aic23-objs := tlv320aic23.o
> snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o
> @@ -460,6 +461,7 @@ obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o
> obj-$(CONFIG_SND_SOC_TAS5720)+= snd-soc-tas5720.o
> obj-$(CONFIG_SND_SOC_TAS6424)+= snd-soc-tas6424.o
> obj-$(CONFIG_SND_SOC_TDA7419)+= snd-soc-tda7419.o
> +obj-$(CONFIG_SND_SOC_TDA7802)+= snd-soc-tda7802.o
> obj-$(CONFIG_SND_SOC_TFA9879)+= snd-soc-tfa9879.o
> obj-$(CONFIG_SND_SOC_TLV320AIC23)+= snd-soc-tlv320aic23.o
> obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C)+= snd-soc-tlv320aic23-i2c.o
> diff --git a/sound/soc/codecs/tda7802.c b/sound/soc/codecs/tda7802.c
> new file mode 100644
> index ..38ca52de85f0
> --- /dev/null
> +++ b/sound/soc/codecs/tda7802.c
> @@ -0,0 +1,580 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * tda7802.c -- codec driver for ST TDA7802
> + *
> + * Copyright (C) 2016-2019 Tesla Motors, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum tda7802_type {
> + tda7802_base,
> +};
> +
> +#define I2C_BUS 4
> +
> +#define CHANNELS_PER_AMP4
> +#define MAX_NUM_AMPS4
> +
> +#define ENABLE_DELAY_MS 10
> +
> +#define TDA7802_IB0 0x00
> +#define TDA7802_IB1 0x01
> +#define TDA7802_IB2 0x02
> +#define TDA7802_IB3 0x03
> +#define TDA7802_IB4 0x04
> +#define TDA7802_IB5 0x05
> +
> +#define TDA7802_DB0 0x10
> +#define TDA7802_DB1 0x11
> +#define TDA7802_DB2 0x12
> +#define TDA7802_DB3 0x13
> +#define TDA7802_DB4 0x14
> +#define TDA7802_DB5 0x15
> +
> +#define IB0_CH4_TRISTATE_ON (1 << 7)
> +#define IB0_CH3_TRISTATE_ON (1 << 6)
> +#define IB0_CH2_TRISTATE_ON (1 << 5)
> +#define IB0_CH1_TRISTATE_ON (1 << 4)
> +#define IB0_CH4_HIGH_EFF(0 << 3)
> +#define IB0_CH4_CLASS_AB(1 << 3)
> +#define IB0_CH3_HIGH_EFF(0 << 2)
> +#define IB0_CH3_CLASS_AB(1 << 2)
> +#define IB0_CH2_HIGH_EFF(0 << 0)
> +#define IB0_CH2_CLASS_AB(1 << 1)
> +#define IB0_CH1_HIGH_EFF(0 << 0)
> +#define IB0_CH1_CLASS_AB(1 << 0)
> +
> +#define IB1_REAR_IMPEDANCE_2_OHM(0 << 7)
> +#define IB1_REAR_IMPEDANCE_4_OHM(1 << 7)
> +#define IB1_LONG_DIAG_TIMING_x1 (0 << 5)
> +#define IB1_LONG_DIAG_TIMING_x2
[GIT PULL] SCSI fixes for 5.2-rc4
A single bug fix for hpsa. The user visible consequences aren't clear,
but the ioaccel2 raid acceleration may misfire on the malformed request
assuming the payload is big enough to require chaining (more than 31 sg
entries).
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Don Brace (1):
scsi: hpsa: correct ioaccel2 chaining
And the diffstat:
drivers/scsi/hpsa.c | 7 ++-
drivers/scsi/hpsa_cmd.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
With full diff below.
James
---
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 1bef1da273c2..8068520cf89e 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4940,7 +4940,7 @@ static int hpsa_scsi_ioaccel2_queue_command(struct
ctlr_info *h,
curr_sg->reserved[0] = 0;
curr_sg->reserved[1] = 0;
curr_sg->reserved[2] = 0;
- curr_sg->chain_indicator = 0x80;
+ curr_sg->chain_indicator = IOACCEL2_CHAIN;
curr_sg = h->ioaccel2_cmd_sg_list[c->cmdindex];
}
@@ -4957,6 +4957,11 @@ static int hpsa_scsi_ioaccel2_queue_command(struct
ctlr_info *h,
curr_sg++;
}
+ /*
+* Set the last s/g element bit
+*/
+ (curr_sg - 1)->chain_indicator = IOACCEL2_LAST_SG;
+
switch (cmd->sc_data_direction) {
case DMA_TO_DEVICE:
cp->direction &= ~IOACCEL2_DIRECTION_MASK;
diff --git a/drivers/scsi/hpsa_cmd.h b/drivers/scsi/hpsa_cmd.h
index 21a726e2eec6..f6afca4b2319 100644
--- a/drivers/scsi/hpsa_cmd.h
+++ b/drivers/scsi/hpsa_cmd.h
@@ -517,6 +517,7 @@ struct ioaccel2_sg_element {
u8 reserved[3];
u8 chain_indicator;
#define IOACCEL2_CHAIN 0x80
+#define IOACCEL2_LAST_SG 0x40
};
/*
Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
Hey Everyone On 4/24/19 10:41 AM, Benjamin Tissoires wrote: >>> For a patch to be picked up by stable, it first needs to go in Linus' >>> tree. Currently we are working on 5.1, so any stable patches need to >>> go in 5.1 first. Then, once they hit Linus' tree, the stable team will >>> pick them and backport them in the appropriate stable tree. Hmm - so, I just booted linux 5.1.9, and this patch set is *still* missing from the kernel. Is there anything that we can do about this? James
