Re: [RFC PATCH 4/5] arm: dts: zynq: rename board zed to zedboard
Hi Michal,
On Thu, Jun 28, 2018 at 2:40 AM Michal Simek wrote:
> > diff --git a/arch/arm/boot/dts/zynq-zed.dts
> > b/arch/arm/boot/dts/zynq-zedboard.dts
> > similarity index 93%
> > rename from arch/arm/boot/dts/zynq-zed.dts
> > rename to arch/arm/boot/dts/zynq-zedboard.dts
> > index bf3e26dbf..540581c56 100644
> > --- a/arch/arm/boot/dts/zynq-zed.dts
> > +++ b/arch/arm/boot/dts/zynq-zedboard.dts
> > @@ -8,7 +8,7 @@
> >
> > / {
> > model = "Avnet ZedBoard board";
> > - compatible = "avnet,zynq-zed", "xlnx,zynq-7000";
> > + compatible = "avnet,zynq-zedboard", "xlnx,zynq-7000";
> >
> > aliases {
> > ethernet0 = &gem0;
> >
>
> It will just cause confusion and I can't see any benefit to rename this
> file. If you want to state different compatible string with full board
> name I am fine with that but that's it.
Ok, I'll drop this patch for V2.
Thanks,
Luis Araneda.
Re: [PATCH v7 1/4] mfd: bd71837: mfd driver for ROHM BD71837 PMIC
On Tue, 26 Jun 2018, Enric Balletbo Serra wrote:
> Hi Matti,
>
> Missatge de Matti Vaittinen del
> dia dt., 26 de juny 2018 a les 14:03:
> >
> > Hello Again Eric,
> >
> > On Tue, Jun 26, 2018 at 01:40:40PM +0200, Enric Balletbo Serra wrote:
> > > Hi Matti,
> > > Missatge de Matti Vaittinen del
> > > dia dt., 26 de juny 2018 a les 13:25:
> > > > On Tue, Jun 26, 2018 at 11:06:33AM +0200, Enric Balletbo Serra wrote:
> > > > > Missatge de Matti Vaittinen del
> > > > > dia dt., 19 de juny 2018 a les 12:57:
> > > >
> > > > > > +static const struct of_device_id bd71837_of_match[] = {
> > > > > > + { .compatible = "rohm,bd71837", .data = (void *)0},
> > > > > > + { },
> > > > >
> > > > > nit: { /* sentinel */ }
> > > >
> > > > I am sorry but I didn't quite get the point here. Could you please
> > > > explain what did you expect to be added here?
> > > >
> > >
> > > It's a nit but It is a good practice to specify that the last entry is
> > > a sentinel. Just this.
> > >
> > > +static const struct of_device_id bd71837_of_match[] = {
> > > + { .compatible = "rohm,bd71837", .data = (void *)0},
> > > + { /* sentinel */ }
> > > +};
> >
> > Oh, I see. Finally something I can disagree =) I quickly opened few
> > random drivers which declare match table. None of them practiced this
> > good practice. So I guess it is not such a standard after all. And I
> > guess the meaning of last entry in match table should be quite obvious.
> > Adding the comment /* sentinel */ sounds like stating the obvious at
> > best - at worst it gets one just to wonder what the "sentinel" means =)
> >
>
> git grep "/\* sentinel \*/"
>
> Anyway, I marked this change as a nit, so you don't need to change. I
> just commented because at some point I received a "complain" when I
> didn't add it. But this is up to the maintainer and I am not sure if
> the "complain" was received in this subsystem :)
Certainly not from me. I don't agree with the practice.
I'd like to know who is enforcing this!
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v7 1/4] mfd: bd71837: mfd driver for ROHM BD71837 PMIC
On Tue, 26 Jun 2018, Enric Balletbo Serra wrote:
> Hi Matti,
> Missatge de Matti Vaittinen del
> dia dt., 26 de juny 2018 a les 13:25:
> >
> > Hello Eric,
> >
> > Thanks for the comments! I'll be addressing these in patch series v8
> > - except the regmap wrapper one which will be taken care of by another
> > patch set.
> >
> > On Tue, Jun 26, 2018 at 11:06:33AM +0200, Enric Balletbo Serra wrote:
> > > Hi Matti,
> > >
> > > Thanks for the patch, a few comments below, some are feedback I
> > > received when I sent some patches to this subsystem.
> > >
> > > Missatge de Matti Vaittinen del
> > > dia dt., 19 de juny 2018 a les 12:57:
> > > >
> > > > ROHM BD71837 PMIC MFD driver providing interrupts and support
> > > > for two subsystems:
> > > > - clk
> > > > - Regulators
> > > >
> > > > Signed-off-by: Matti Vaittinen
> > > > ---
> > > > drivers/mfd/Kconfig | 13 ++
> > > > drivers/mfd/Makefile| 1 +
> > > > drivers/mfd/bd71837.c | 221 ++
> > > > include/linux/mfd/bd71837.h | 367
> > > >
> > > > 4 files changed, 602 insertions(+)
> > > > create mode 100644 drivers/mfd/bd71837.c
> > > > create mode 100644 include/linux/mfd/bd71837.h
[...]
> > > > +static const struct of_device_id bd71837_of_match[] = {
> > > > + { .compatible = "rohm,bd71837", .data = (void *)0},
> > > > + { },
> > >
> > > nit: { /* sentinel */ }
> >
> > I am sorry but I didn't quite get the point here. Could you please
> > explain what did you expect to be added here?
> >
>
> It's a nit but It is a good practice to specify that the last entry is
> a sentinel. Just this.
>
> +static const struct of_device_id bd71837_of_match[] = {
> + { .compatible = "rohm,bd71837", .data = (void *)0},
> + { /* sentinel */ }
> +};
I would not say this is "good practice" at all.
We all know what empty brackets mean. No need for obvious comments.
When authors put this, I let it go because "sentinel" is a cool word -
and nothing more! ;)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [RFC PATCH 2/5] dt-bindings: xilinx: Add missing zynq boards
Hi Michal, On Thu, Jun 28, 2018 at 2:44 AM Michal Simek wrote: > > -- Xilinx internal board cc108 > > +- Xilinx CC108 board > > No reason to remove internal word from here. Ok. Thanks, Luis Araneda.
[PATCH] md/r5cache: remove redundant pointer bio
From: Colin Ian King
Pointer bio is being assigned but is never used hence it is redundant
and can be removed.
Cleans up clang warning:
warning: variable 'bio' set but not used [-Wunused-but-set-variable]
Signed-off-by: Colin Ian King
---
drivers/md/raid5-cache.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 2b775abf377b..7416db70c6cc 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -717,7 +717,6 @@ static void r5c_disable_writeback_async(struct work_struct
*work)
static void r5l_submit_current_io(struct r5l_log *log)
{
struct r5l_io_unit *io = log->current_io;
- struct bio *bio;
struct r5l_meta_block *block;
unsigned long flags;
u32 crc;
@@ -730,7 +729,6 @@ static void r5l_submit_current_io(struct r5l_log *log)
block->meta_size = cpu_to_le32(io->meta_offset);
crc = crc32c_le(log->uuid_checksum, block, PAGE_SIZE);
block->checksum = cpu_to_le32(crc);
- bio = io->current_bio;
log->current_io = NULL;
spin_lock_irqsave(&log->io_list_lock, flags);
--
2.17.1
Re: [RFC PATCH 1/5] arm: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed boards
Hi Michal, On Thu, Jun 28, 2018 at 2:37 AM Michal Simek wrote: > > On 28.6.2018 07:42, Luis Araneda wrote: > Unfortunately we don't know who is parsing this string. It means please > keep that origin compatible string there. > > I have no problem with this. > compatible = "avnet,zynq-zed", "xlnx,zynq-zed", "xlnx,zynq-7000"; Ok, I'll change that for V2, and I'll keep it in mind for the rest of the series too. Thanks for reviewing, Luis Araneda.
[PATCH] x86/mm/32: Initialize CR4 shadow before __flush_tlb_all()
In x86_32, __flush_tlb_all() may have read cr4 shadow before the initialization of cr4 shadow in cpuinit(). Fix it by adding cr4_init_shadow() call ahead of __flush_tlb_all(). Signed-off-by: Zhenzhong Duan Cc: Srinivas Reddy Eeda --- arch/x86/kernel/smpboot.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index c2f7d1d..db9656e 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -221,6 +221,11 @@ static void notrace start_secondary(void *unused) #ifdef CONFIG_X86_32 /* switch away from the initial page table */ load_cr3(swapper_pg_dir); + /* +* Initialize the CR4 shadow before doing anything that could +* try to read it. +*/ + cr4_init_shadow(); __flush_tlb_all(); #endif load_current_idt(); -- 1.7.3
[PATCH] autofs - fix slab out of bounds read in getname_kernel()
Initial patch contributed by Tomas Bortoli.
The autofs subsystem does not check that the "path" parameter is
present for all cases where it is required when it is passed in
via the "param" struct.
In particular it isn't checked for the AUTOFS_DEV_IOCTL_OPENMOUNT_CMD
ioctl command.
To solve it, modify validate_dev_ioctl() function to check that a
path has been provided for ioctl commands that require it.
Signed-off-by: Tomas Bortoli
Signed-off-by: Ian Kent
Reported-by: syzbot+60c837b428dc84e83...@syzkaller.appspotmail.com
---
fs/autofs/dev-ioctl.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/fs/autofs/dev-ioctl.c b/fs/autofs/dev-ioctl.c
index ea4ca1445ab7..86eafda4a652 100644
--- a/fs/autofs/dev-ioctl.c
+++ b/fs/autofs/dev-ioctl.c
@@ -135,6 +135,15 @@ static int validate_dev_ioctl(int cmd, struct
autofs_dev_ioctl *param)
cmd);
goto out;
}
+ } else {
+ unsigned int inr = _IOC_NR(cmd);
+
+ if (inr == AUTOFS_DEV_IOCTL_OPENMOUNT_CMD ||
+ inr == AUTOFS_DEV_IOCTL_REQUESTER_CMD ||
+ inr == AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD) {
+ err = -EINVAL;
+ goto out;
+ }
}
err = 0;
@@ -271,7 +280,8 @@ static int autofs_dev_ioctl_openmount(struct file *fp,
dev_t devid;
int err, fd;
- /* param->path has already been checked */
+ /* param->path has been checked in validate_dev_ioctl() */
+
if (!param->openmount.devid)
return -EINVAL;
@@ -433,10 +443,7 @@ static int autofs_dev_ioctl_requester(struct file *fp,
dev_t devid;
int err = -ENOENT;
- if (param->size <= AUTOFS_DEV_IOCTL_SIZE) {
- err = -EINVAL;
- goto out;
- }
+ /* param->path has been checked in validate_dev_ioctl() */
devid = sbi->sb->s_dev;
@@ -521,10 +528,7 @@ static int autofs_dev_ioctl_ismountpoint(struct file *fp,
unsigned int devid, magic;
int err = -ENOENT;
- if (param->size <= AUTOFS_DEV_IOCTL_SIZE) {
- err = -EINVAL;
- goto out;
- }
+ /* param->path has been checked in validate_dev_ioctl() */
name = param->path;
type = param->ismountpoint.in.type;
[tip:x86/cache] x86/intel_rdt: Make CPU information accessible for pseudo-locked regions
Commit-ID: 33dc3e410a0d99f394905143b26d34f1fd64c962
Gitweb: https://git.kernel.org/tip/33dc3e410a0d99f394905143b26d34f1fd64c962
Author: Reinette Chatre
AuthorDate: Sat, 30 Jun 2018 22:17:33 -0700
Committer: Thomas Gleixner
CommitDate: Tue, 3 Jul 2018 08:38:40 +0200
x86/intel_rdt: Make CPU information accessible for pseudo-locked regions
When a resource group enters pseudo-locksetup mode it reflects that the
platform supports cache pseudo-locking and the resource group is unused,
ready to be used for a pseudo-locked region. Until it is set up as a
pseudo-locked region the resource group is "locked down" such that no new
tasks or cpus can be assigned to it. This is accomplished in a user visible
way by making the cpus, cpus_list, and tasks resctrl files inaccassible
(user cannot read from or write to these files).
When the resource group changes to pseudo-locked mode it represents a cache
pseudo-locked region. While not appropriate to make any changes to the cpus
assigned to this region it is useful to make it easy for the user to see
which cpus are associated with the pseudo-locked region.
Modify the permissions of the cpus/cpus_list file when the resource group
changes to pseudo-locked mode to support reading (not writing). The
information presented to the user when reading the file are the cpus
associated with the pseudo-locked region.
Signed-off-by: Reinette Chatre
Signed-off-by: Thomas Gleixner
Cc: fenghua...@intel.com
Cc: tony.l...@intel.com
Cc: vikas.shiva...@linux.intel.com
Cc: gavin.hind...@intel.com
Cc: jithu.jos...@intel.com
Cc: dave.han...@intel.com
Cc: h...@zytor.com
Link:
https://lkml.kernel.org/r/12756b7963b6abc1bffe8fb560b87b75da827bd1.1530421961.git.reinette.cha...@intel.com
---
Documentation/x86/intel_rdt_ui.txt | 3 +++
arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 3 +++
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c| 8 ++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/x86/intel_rdt_ui.txt
b/Documentation/x86/intel_rdt_ui.txt
index acac30b67c62..f662d3c530e5 100644
--- a/Documentation/x86/intel_rdt_ui.txt
+++ b/Documentation/x86/intel_rdt_ui.txt
@@ -178,6 +178,9 @@ All groups contain the following files:
CPUs to/from this group. As with the tasks file a hierarchy is
maintained where MON groups may only include CPUs owned by the
parent CTRL_MON group.
+ When the resouce group is in pseudo-locked mode this file will
+ only be readable, reflecting the CPUs associated with the
+ pseudo-locked region.
"cpus_list":
diff --git a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
index 5dfe4008c58f..751c78f9992f 100644
--- a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
+++ b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
@@ -1303,6 +1303,9 @@ int rdtgroup_pseudo_lock_create(struct rdtgroup *rdtgrp)
rdtgrp->mode = RDT_MODE_PSEUDO_LOCKED;
closid_free(rdtgrp->closid);
+ rdtgroup_kn_mode_restore(rdtgrp, "cpus", 0444);
+ rdtgroup_kn_mode_restore(rdtgrp, "cpus_list", 0444);
+
ret = 0;
goto out;
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index c20b51afd62d..d6d7ea7349d0 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -265,8 +265,12 @@ static int rdtgroup_cpus_show(struct kernfs_open_file *of,
rdtgrp = rdtgroup_kn_lock_live(of->kn);
if (rdtgrp) {
- seq_printf(s, is_cpu_list(of) ? "%*pbl\n" : "%*pb\n",
- cpumask_pr_args(&rdtgrp->cpu_mask));
+ if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED)
+ seq_printf(s, is_cpu_list(of) ? "%*pbl\n" : "%*pb\n",
+ cpumask_pr_args(&rdtgrp->plr->d->cpu_mask));
+ else
+ seq_printf(s, is_cpu_list(of) ? "%*pbl\n" : "%*pb\n",
+ cpumask_pr_args(&rdtgrp->cpu_mask));
} else {
ret = -ENOENT;
}
Re: [PATCH 09/15] arm: dts: omap: Add missing cooling device properties for CPUs
* Viresh Kumar [180525 03:35]: > The cooling device properties, like "#cooling-cells" and > "dynamic-power-coefficient", should either be present for all the CPUs > of a cluster or none. If these are present only for a subset of CPUs of > a cluster then things will start falling apart as soon as the CPUs are > brought online in a different order. For example, this will happen > because the operating system looks for such properties in the CPU node > it is trying to bring up, so that it can register a cooling device. > > Add such missing properties. > > Fix other missing properties (clocks, supply, clock latency) as well to > make it all work. Applying this too into omap-for-v4.19/dt thanks. Tony
Re: [PATCH 08/15] arm: dts: dra74x: Add missing cooling device properties for CPUs
* Viresh Kumar [180525 03:35]: > The cooling device properties, like "#cooling-cells" and > "dynamic-power-coefficient", should either be present for all the CPUs > of a cluster or none. If these are present only for a subset of CPUs of > a cluster then things will start falling apart as soon as the CPUs are > brought online in a different order. For example, this will happen > because the operating system looks for such properties in the CPU node > it is trying to bring up, so that it can register a cooling device. > > Add such missing properties. > > Fix other missing properties (clocks, supply, clock latency) as well to > make it all work. Applying this one into omap-for-v4.19/dt thanks. Regards, Tony
[tip:x86/cache] x86/intel_rdt: Support restoration of subset of permissions
Commit-ID: 392487def48e4b596526a4a8c2c2ec4cfe73bf13
Gitweb: https://git.kernel.org/tip/392487def48e4b596526a4a8c2c2ec4cfe73bf13
Author: Reinette Chatre
AuthorDate: Sat, 30 Jun 2018 22:17:32 -0700
Committer: Thomas Gleixner
CommitDate: Tue, 3 Jul 2018 08:38:40 +0200
x86/intel_rdt: Support restoration of subset of permissions
As the mode of a resource group changes, the operations it can support may
also change. One way in which the supported operations are managed is to
modify the permissions of the files within the resource group's resctrl
directory.
At the moment only two possible permissions are supported: the default
permissions or no permissions in support for when the operation is "locked
down". It is possible where an operation on a resource group may have more
possibilities. For example, if by default changes can be made to the
resource group by writing to a resctrl file while the current settings can
be obtained by reading from the file, then it may be possible that in
another mode it is only possible to read the current settings, and not
change them.
Make it possible to modify some of the permissions of a resctrl file in
support of a more flexible way to manage the operations on a resource
group. In this preparation work the original behavior is maintained where
all permissions are restored.
Signed-off-by: Reinette Chatre
Signed-off-by: Thomas Gleixner
Cc: fenghua...@intel.com
Cc: tony.l...@intel.com
Cc: vikas.shiva...@linux.intel.com
Cc: gavin.hind...@intel.com
Cc: jithu.jos...@intel.com
Cc: dave.han...@intel.com
Cc: h...@zytor.com
Link:
https://lkml.kernel.org/r/8773aadfade7bcb2c48a45fa294a04d2c03bb0a1.1530421961.git.reinette.cha...@intel.com
---
arch/x86/kernel/cpu/intel_rdt.h | 3 ++-
arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 14 +++---
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c| 6 --
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt.h b/arch/x86/kernel/cpu/intel_rdt.h
index 2d9cbb9d7a58..4e588f36228f 100644
--- a/arch/x86/kernel/cpu/intel_rdt.h
+++ b/arch/x86/kernel/cpu/intel_rdt.h
@@ -512,7 +512,8 @@ void rdt_ctrl_update(void *arg);
struct rdtgroup *rdtgroup_kn_lock_live(struct kernfs_node *kn);
void rdtgroup_kn_unlock(struct kernfs_node *kn);
int rdtgroup_kn_mode_restrict(struct rdtgroup *r, const char *name);
-int rdtgroup_kn_mode_restore(struct rdtgroup *r, const char *name);
+int rdtgroup_kn_mode_restore(struct rdtgroup *r, const char *name,
+umode_t mask);
struct rdt_domain *rdt_find_domain(struct rdt_resource *r, int id,
struct list_head **pos);
ssize_t rdtgroup_schemata_write(struct kernfs_open_file *of,
diff --git a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
index 8fd79c281ee6..5dfe4008c58f 100644
--- a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
+++ b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
@@ -590,11 +590,11 @@ static int rdtgroup_locksetup_user_restrict(struct
rdtgroup *rdtgrp)
goto out;
err_cpus_list:
- rdtgroup_kn_mode_restore(rdtgrp, "cpus_list");
+ rdtgroup_kn_mode_restore(rdtgrp, "cpus_list", 0777);
err_cpus:
- rdtgroup_kn_mode_restore(rdtgrp, "cpus");
+ rdtgroup_kn_mode_restore(rdtgrp, "cpus", 0777);
err_tasks:
- rdtgroup_kn_mode_restore(rdtgrp, "tasks");
+ rdtgroup_kn_mode_restore(rdtgrp, "tasks", 0777);
out:
return ret;
}
@@ -615,20 +615,20 @@ static int rdtgroup_locksetup_user_restore(struct
rdtgroup *rdtgrp)
{
int ret;
- ret = rdtgroup_kn_mode_restore(rdtgrp, "tasks");
+ ret = rdtgroup_kn_mode_restore(rdtgrp, "tasks", 0777);
if (ret)
return ret;
- ret = rdtgroup_kn_mode_restore(rdtgrp, "cpus");
+ ret = rdtgroup_kn_mode_restore(rdtgrp, "cpus", 0777);
if (ret)
goto err_tasks;
- ret = rdtgroup_kn_mode_restore(rdtgrp, "cpus_list");
+ ret = rdtgroup_kn_mode_restore(rdtgrp, "cpus_list", 0777);
if (ret)
goto err_cpus;
if (rdt_mon_capable) {
- ret = rdtgroup_kn_mode_restore(rdtgrp, "mon_groups");
+ ret = rdtgroup_kn_mode_restore(rdtgrp, "mon_groups", 0777);
if (ret)
goto err_cpus_list;
}
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 7b4a09d81a30..c20b51afd62d 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -1405,13 +1405,15 @@ int rdtgroup_kn_mode_restrict(struct rdtgroup *r, const
char *name)
* rdtgroup_kn_mode_restore - Restore user access to named resctrl file
* @r: The resource group with which the file is associated.
* @name: Name of the file
+ * @mask: Mask of permissions that should be restored
*
* Restore the permissions of the named file. If @name is a directory the
[tip:x86/cache] x86/intel_rdt: Fix cleanup of plr structure on error
Commit-ID: 546d3c74277398a3d76d059bd2db47186bb47fc8
Gitweb: https://git.kernel.org/tip/546d3c74277398a3d76d059bd2db47186bb47fc8
Author: Reinette Chatre
AuthorDate: Sat, 30 Jun 2018 22:03:03 -0700
Committer: Thomas Gleixner
CommitDate: Tue, 3 Jul 2018 08:38:39 +0200
x86/intel_rdt: Fix cleanup of plr structure on error
When a resource group enters pseudo-locksetup mode a pseudo_lock_region is
associated with it. When the user writes to the resource group's schemata
file the CBM of the requested pseudo-locked region is entered into the
pseudo_lock_region struct. If any part of pseudo-lock region creation fails
the resource group will remain in pseudo-locksetup mode with the
pseudo_lock_region associated with it.
In case of failure during pseudo-lock region creation care needs to be
taken to ensure that the pseudo_lock_region struct associated with the
resource group is cleared from any pseudo-locking data - especially the
CBM. This is because the existence of a pseudo_lock_region struct with a
CBM is significant in other areas of the code, for example, the display of
bit_usage and initialization of a new resource group.
Fix the error path of pseudo-lock region creation to ensure that the
pseudo_lock_region struct is cleared at each error exit.
Fixes: 018961ae5579 ("x86/intel_rdt: Pseudo-lock region creation/removal core")
Signed-off-by: Reinette Chatre
Signed-off-by: Thomas Gleixner
Cc: fenghua...@intel.com
Cc: tony.l...@intel.com
Cc: vikas.shiva...@linux.intel.com
Cc: gavin.hind...@intel.com
Cc: jithu.jos...@intel.com
Cc: dave.han...@intel.com
Cc: h...@zytor.com
Link:
https://lkml.kernel.org/r/49b4782f6d204d122cee3499e642b2772a98d2b4.1530421026.git.reinette.cha...@intel.com
---
arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
index 1860ec10302d..8fd79c281ee6 100644
--- a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
+++ b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
@@ -290,6 +290,7 @@ static void pseudo_lock_region_clear(struct
pseudo_lock_region *plr)
static int pseudo_lock_region_init(struct pseudo_lock_region *plr)
{
struct cpu_cacheinfo *ci;
+ int ret;
int i;
/* Pick the first cpu we find that is associated with the cache. */
@@ -298,7 +299,8 @@ static int pseudo_lock_region_init(struct
pseudo_lock_region *plr)
if (!cpu_online(plr->cpu)) {
rdt_last_cmd_printf("cpu %u associated with cache not online\n",
plr->cpu);
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_region;
}
ci = get_cpu_cacheinfo(plr->cpu);
@@ -312,8 +314,11 @@ static int pseudo_lock_region_init(struct
pseudo_lock_region *plr)
}
}
+ ret = -1;
rdt_last_cmd_puts("unable to determine cache line size\n");
- return -1;
+out_region:
+ pseudo_lock_region_clear(plr);
+ return ret;
}
/**
@@ -365,16 +370,23 @@ static int pseudo_lock_region_alloc(struct
pseudo_lock_region *plr)
*/
if (plr->size > KMALLOC_MAX_SIZE) {
rdt_last_cmd_puts("requested region exceeds maximum size\n");
- return -E2BIG;
+ ret = -E2BIG;
+ goto out_region;
}
plr->kmem = kzalloc(plr->size, GFP_KERNEL);
if (!plr->kmem) {
rdt_last_cmd_puts("unable to allocate memory\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out_region;
}
- return 0;
+ ret = 0;
+ goto out;
+out_region:
+ pseudo_lock_region_clear(plr);
+out:
+ return ret;
}
/**
[tip:x86/cache] x86/intel_rdt: Move pseudo_lock_region_clear()
Commit-ID: ce730f1cc1255be152c879a2bc5f295d341d8036
Gitweb: https://git.kernel.org/tip/ce730f1cc1255be152c879a2bc5f295d341d8036
Author: Reinette Chatre
AuthorDate: Sat, 30 Jun 2018 22:03:02 -0700
Committer: Thomas Gleixner
CommitDate: Tue, 3 Jul 2018 08:38:39 +0200
x86/intel_rdt: Move pseudo_lock_region_clear()
The pseudo_lock_region_clear() function is moved to earlier in the file in
preparation for its use in functions that currently appear before it. No
functional change.
Signed-off-by: Reinette Chatre
Signed-off-by: Thomas Gleixner
Cc: fenghua...@intel.com
Cc: tony.l...@intel.com
Cc: vikas.shiva...@linux.intel.com
Cc: gavin.hind...@intel.com
Cc: jithu.jos...@intel.com
Cc: dave.han...@intel.com
Cc: h...@zytor.com
Link:
https://lkml.kernel.org/r/ef098ec2a45501e23792289bff80ae3152141e2f.1530421026.git.reinette.cha...@intel.com
---
arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 46 ++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
index 6e83f61552a5..1860ec10302d 100644
--- a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
+++ b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
@@ -246,6 +246,29 @@ out_err:
return ret;
}
+/**
+ * pseudo_lock_region_clear - Reset pseudo-lock region data
+ * @plr: pseudo-lock region
+ *
+ * All content of the pseudo-locked region is reset - any memory allocated
+ * freed.
+ *
+ * Return: void
+ */
+static void pseudo_lock_region_clear(struct pseudo_lock_region *plr)
+{
+ plr->size = 0;
+ plr->line_size = 0;
+ kfree(plr->kmem);
+ plr->kmem = NULL;
+ plr->r = NULL;
+ if (plr->d)
+ plr->d->plr = NULL;
+ plr->d = NULL;
+ plr->cbm = 0;
+ plr->debugfs_dir = NULL;
+}
+
/**
* pseudo_lock_region_init - Initialize pseudo-lock region information
* @plr: pseudo-lock region
@@ -318,29 +341,6 @@ static int pseudo_lock_init(struct rdtgroup *rdtgrp)
return 0;
}
-/**
- * pseudo_lock_region_clear - Reset pseudo-lock region data
- * @plr: pseudo-lock region
- *
- * All content of the pseudo-locked region is reset - any memory allocated
- * freed.
- *
- * Return: void
- */
-static void pseudo_lock_region_clear(struct pseudo_lock_region *plr)
-{
- plr->size = 0;
- plr->line_size = 0;
- kfree(plr->kmem);
- plr->kmem = NULL;
- plr->r = NULL;
- if (plr->d)
- plr->d->plr = NULL;
- plr->d = NULL;
- plr->cbm = 0;
- plr->debugfs_dir = NULL;
-}
-
/**
* pseudo_lock_region_alloc - Allocate kernel memory that will be pseudo-locked
* @plr: pseudo-lock region
Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines
Hi I've run into an odd performance issue in the kernel, and not being a kernel dev or knowing terribly much about cgroups, am looking for advice on diagnosing the problem further (I discovered this while trying to pin down high CPU load in cadvisor). On some machines in our production system, cat /sys/fs/cgroup/memory/memory.stat is extremely slow (500ms on one machine), while on other nominally identical machines it is fast (2ms). One other thing I've noticed is that the affected machines generally have much larger values for SUnreclaim in /proc/memstat (up to several GB), and slabtop reports >1GB of dentry. Before I tracked the original problem (high CPU usage in cadvisor) down to this, I rebooted one of the machines and the original problem went away, so it seems to be cleared by a reboot; I'm reluctant to reboot more machines to confirm since I don't have a sure-fire way to reproduce the problem again to debug it. The machines are running Ubuntu 16.04 with kernel 4.13.0-41-generic. They're running Docker, which creates a bunch of cgroups, but not an excessive number: there are 106 memory.stat files in /sys/fs/cgroup/memory. Digging a bit further, cat /sys/fs/cgroup/memory/system.slice/memory.stat also takes ~500ms, but "find /sys/fs/cgroup/memory/system.slice -mindepth 2 -name memory.stat | xargs cat" takes only 8ms. Any thoughts, particularly on what I should compare between the good and bad machines to narrow down the cause, or even better, how to prevent it happening? Thanks Bruce -- Bruce Merry Senior Science Processing Developer SKA South Africa
Re: [PATCH V2] ARM: dts: imx6: correct anatop regulators range
On Mon, Jul 02, 2018 at 10:04:36AM +0800, Anson Huang wrote: > According to i.MX6 datasheet, the LDO_1P1's typical > programming operating range is 1.0V to 1.2V, and > the LDO_2P5's typical programming operating range > is 2.25V to 2.75V, correct LDO_1P1 and LDO_2P5's > regulator range settings for i.MX6 SoCs. > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH v3 6/8] serial: Add Tegra Combined UART driver
On 02.07.2018 16:47, Thierry Reding wrote: On Mon, Jul 02, 2018 at 04:30:07PM +0300, Mikko Perttunen wrote: On 02.07.2018 16:18, Thierry Reding wrote: On Mon, Jul 02, 2018 at 02:40:31PM +0300, Mikko Perttunen wrote: The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows multiplexing multiple "virtual UARTs" into a single hardware serial port. The TCU is the primary serial port on Tegra194 devices. Add a TCU driver utilizing the mailbox framework, as the used mailboxes are part of Tegra HSP blocks that are already controlled by the Tegra HSP mailbox driver. Signed-off-by: Mikko Perttunen --- Notes: v2: - Removed (void) casts for unused variables. - Changed the uart_set_options() call to be on one line, even if its over 80 characters. - Added defines for magic numbers. - Style fixes. - Changed Kconfig entry to depend on the Tegra HSP driver instead of just the mailbox framework. v3: - Removed FLUSH bit, as it's unnecessary and slows down printing - Removed call to uart_set_options - Added mbox_free_channel calls to remove() drivers/tty/serial/Kconfig | 9 ++ drivers/tty/serial/Makefile | 1 + drivers/tty/serial/tegra-tcu.c | 291 +++ include/uapi/linux/serial_core.h | 3 + 4 files changed, 304 insertions(+) create mode 100644 drivers/tty/serial/tegra-tcu.c The driver looks good to me. But for my own understanding, is there some way we can make use of the multiplexing? That is, could we add a mechanism to have the driver filter out only a specific stream? Could we also specify which stream to send data back to? What happens by default? Which stream is data sent to? There is no multiplexing on the producer/device side (i.e. what this driver does). The mailbox specified in device tree specifies the stream we send stuff to. The mailboxes are per-CPU (we use the CCPLEX mailbox here), so it cannot really be changed. Oh, I see, so there is one stream per pair of mailboxes? That is, the mailboxes we specify in the DT define which stream we receive from and send to? Correct. Mikko Thierry
Re: [PATCH upstream] KASAN: slab-out-of-bounds Read in getname_kernel
On Tue, 2018-07-03 at 07:48 +0200, Dmitry Vyukov wrote: > On Tue, Jul 3, 2018 at 3:34 AM, Ian Kent wrote: > > On Mon, 2018-07-02 at 14:15 +0200, Dmitry Vyukov wrote: > > > On Mon, Jul 2, 2018 at 1:55 PM, tomas wrote: > > > > Yes, thanks. Please use my full name, Tomas Bortoli. > > > > > > > > > Please also include: > > > > > > Reported-by: syzbot+60c837b428dc84e83...@syzkaller.appspotmail.com > > > > Done. > > > > > > > > from the original bug report. This this help to keep automatic testing > > > process running. > > > > Umm ... should I include this email address on the actual cc when > > submitting the patch? > > It does not matter. It's a real email address too, so CCing it is > fine. So if git does it automatically (does it?) then just go with it. > If you are doing it manually, then it's not necessary to add it to CC. Right, I thought a mail would probably be sent at merge time (or perhaps when Andrew adds it to mmotm) so I didn't think it sensible to cc when submitting. Personally I use StGIT to manage patches and that will only send to addresses specified when patches are emailed. > > syzbot will scrape git log later to discover the tag and mark the bug fixed. > > Thanks > > > > > On 07/02/2018 12:20 PM, Ian Kent wrote: > > > > > On Mon, 2018-07-02 at 10:31 +0200, tomas wrote: > > > > > > Hi Ian, > > > > > > > > > > > > you are welcome! > > > > > > > > > > > > yes your patch is much better. You should just put the "_IOC_NR" > > > > > > macro > > > > > > around "cmd" in the lines added to "validate_dev_ioctl" to make it > > > > > > work. > > > > > > > > > > LOL, yes, that was a dumb mistake. > > > > > > > > > > I'll send it to Andrew Morton, after some fairly simple sanity > > > > > testing, > > > > > with both our Signed-off-by added. > > > > > > > > > > > Tomas > > > > > > > > > > > > > > > > > > On 07/02/2018 03:42 AM, Ian Kent wrote: > > > > > > > On Mon, 2018-07-02 at 09:10 +0800, Ian Kent wrote: > > > > > > > > On Mon, 2018-07-02 at 00:04 +0200, tomas wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I've looked into this issue found by Syzbot and I made a > > > > > > > > > patch: > > > > > > > > > > > > > > > > > > https://syzkaller.appspot.com/bug?id=d03abd8b42847f7f69b1d1d7f > > > > > > > > > 9720 > > > > > > > > > 8ae425 > > > > > > > > > b116 > > > > > > > > > 3 > > > > > > > > > > > > > > > > Umm ... oops! > > > > > > > > > > > > > > > > Thanks for looking into this Tomas. > > > > > > > > > > > > > > > > > The autofs subsystem does not check that the "path" parameter > > > > > > > > > is > > > > > > > > > present > > > > > > > > > within the "param" struct passed by the userspace in case the > > > > > > > > > AUTOFS_DEV_IOCTL_OPENMOUNT_CMD command is passed. Indeed, it > > > > > > > > > assumes a > > > > > > > > > path is always provided (though a path is not always present, > > > > > > > > > as > > > > > > > > > per how > > > > > > > > > the struct is defined: > > > > > > > > > https://github.com/torvalds/linux/blob/master/include/uapi/lin > > > > > > > > > ux/a > > > > > > > > > uto_de > > > > > > > > > v-io > > > > > > > > > ct > > > > > > > > > l.h#L89). > > > > > > > > > Skipping the check provokes an oob read in "strlen", called by > > > > > > > > > "getname_kernel", in turn called by the autofs to assess the > > > > > > > > > length of > > > > > > > > > the non-existing path. > > > > > > > > > > > > > > > > > > To solve it, modify the "validate_dev_ioctl" function to check > > > > > > > > > also that > > > > > > > > > a path has been provided if the command is > > > > > > > > > AUTOFS_DEV_IOCTL_OPENMOUNT_CMD. > > > > > > > > > > > > > > > > > > > > > > > > > > > --- b/fs/autofs/dev-ioctl.c2018-07-01 23:10:16.059728621 > > > > > > > > > +0200around > > > > > > > > > +++ a/fs/autofs/dev-ioctl.c2018-07-01 23:10:24.311792133 > > > > > > > > > +0200 > > > > > > > > > @@ -136,6 +136,9 @@ static int validate_dev_ioctl(int cmd, s > > > > > > > > > goto out; > > > > > > > > > } > > > > > > > > > } > > > > > > > > > +/* AUTOFS_DEV_IOCTL_OPENMOUNT_CMD without path */ > > > > > > > > > +else if(_IOC_NR(cmd) == AUTOFS_DEV_IOCTL_OPENMOUNT_CMD) > > > > > > > > > +return -EINVAL; > > > > > > > > > > > > > > > > My preference is to put the comment inside the else but ... > > > > > > > > > > > > > > > > There's another question, should the check be done in > > > > > > > > autofs_dev_ioctl_openmount() in the same way it's checked in > > > > > > > > other > > > > > > > > ioctls that need a path, such as in autofs_dev_ioctl_requester() > > > > > > > > and autofs_dev_ioctl_ismountpoint()? > > > > > > > > > > > > > > > > For consistency I'd say it should. > > > > > > > > > > > > > > > > > > > > > > > > > > err = 0;You should just put the "_IOC_NR" directive > > > > > > > > > around > > > > > > > > > "cmd" in > > > > > > > > > the lines added to "validate_dev_ioctl" to make it work. > > > > > > > >
Re: [PATCH 1/1] ARM: dts: imx6ull: add operating points
On Mon, Jul 02, 2018 at 10:22:05AM +0530, Viresh Kumar wrote:
> On 29-06-18, 16:52, Sébastien Szymanski wrote:
> > i.MX6ULL has different operating ranges than i.MX6UL so add the
> > operating points for the i.MX6ULL and removed them form board device
>
> s/removed/remove/
> s/form/from/
I fixed them up and applied the patch.
Shawn
>
> > trees. A 25mV offset is added to the minimum allowed values like for the
> > i.MX6UL.
> > The valid frequencies are now selected by the cpufreq driver according
> > to ratings stored in fuses since commit 0aa9abd4c212 ("cpufreq: imx6q:
> > check speed grades for i.MX6ULL")
> >
> > Signed-off-by: Sébastien Szymanski
Re: [PATCH] staging: mt7621-pinctrl: Style fixes to pinctrl-rt2880
On Tue, Jul 03, 2018 at 01:20:47AM -0400, Peter Vernia wrote:
> Replaces instances of "unsigned" with "unsigned int"; fixes comma and tab
> spacing.
>
> Signed-off-by: Peter Vernia
> ---
> drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 35
> +
> 1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
> b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
> index 0c3e498..6894510 100644
> --- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
> +++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
> @@ -54,7 +54,7 @@ static int rt2880_get_group_count(struct pinctrl_dev
> *pctrldev)
> }
>
> static const char *rt2880_get_group_name(struct pinctrl_dev *pctrldev,
> - unsigned group)
> + unsigned int group)
> {
> struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
>
> @@ -65,9 +65,9 @@ static const char *rt2880_get_group_name(struct pinctrl_dev
> *pctrldev,
> }
>
> static int rt2880_get_group_pins(struct pinctrl_dev *pctrldev,
> - unsigned group,
> - const unsigned **pins,
> - unsigned *num_pins)
> + unsigned int group,
> + const unsigned int **pins,
> + unsigned int *num_pins)
> {
> struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
>
> @@ -81,7 +81,8 @@ static int rt2880_get_group_pins(struct pinctrl_dev
> *pctrldev,
> }
>
> static void rt2880_pinctrl_dt_free_map(struct pinctrl_dev *pctrldev,
> - struct pinctrl_map *map, unsigned num_maps)
> + struct pinctrl_map *map,
> + unsigned int num_maps)
> {
> int i;
>
> @@ -94,7 +95,7 @@ static void rt2880_pinctrl_dt_free_map(struct pinctrl_dev
> *pctrldev,
>
> static void rt2880_pinctrl_pin_dbg_show(struct pinctrl_dev *pctrldev,
> struct seq_file *s,
> - unsigned offset)
> + unsigned int offset)
> {
> seq_printf(s, "ralink pio");
> }
> @@ -103,7 +104,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
> pinctrl_dev *pctrldev,
> struct device_node *np,
> struct pinctrl_map **map)
> {
> -const char *function;
> + const char *function;
> int func = of_property_read_string(np, "ralink,function", &function);
> int grps = of_property_count_strings(np, "ralink,group");
> int i;
> @@ -112,7 +113,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
> pinctrl_dev *pctrldev,
> return;
>
> for (i = 0; i < grps; i++) {
> - const char *group;
> + const char *group;
>
> of_property_read_string_index(np, "ralink,group", i, &group);
>
> @@ -127,7 +128,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
> pinctrl_dev *pctrldev,
> static int rt2880_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrldev,
> struct device_node *np_config,
> struct pinctrl_map **map,
> - unsigned *num_maps)
> + unsigned int *num_maps)
> {
> int max_maps = 0;
> struct pinctrl_map *tmp;
> @@ -173,7 +174,7 @@ static int rt2880_pmx_func_count(struct pinctrl_dev
> *pctrldev)
> }
>
> static const char *rt2880_pmx_func_name(struct pinctrl_dev *pctrldev,
> - unsigned func)
> + unsigned int func)
> {
> struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
>
> @@ -181,7 +182,7 @@ static const char *rt2880_pmx_func_name(struct
> pinctrl_dev *pctrldev,
> }
>
> static int rt2880_pmx_group_get_groups(struct pinctrl_dev *pctrldev,
> - unsigned func,
> + unsigned int func,
> const char * const **groups,
> unsigned * const num_groups)
> {
> @@ -198,11 +199,11 @@ static int rt2880_pmx_group_get_groups(struct
> pinctrl_dev *pctrldev,
> }
>
> static int rt2880_pmx_group_enable(struct pinctrl_dev *pctrldev,
> - unsigned func,
> - unsigned group)
> + unsigned int func,
> + unsigned int group)
> {
> struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
> -u32 mode = 0;
> + u32 mode = 0;
> u32 reg = SYSC_REG_GPIO_MODE;
> int i;
> int shift;
> @@ -243,7 +244,7 @@ static int rt2880_pmx_group_enable(struct pinctrl_dev
> *pctrldev,
>
> static int rt2880_pmx_group_gpio_req
Re: [PATCH 4.9 000/101] 4.9.111-stable review
On Mon, Jul 02, 2018 at 09:47:59AM -0700, Linus Torvalds wrote: > On Mon, Jul 2, 2018 at 3:24 AM Greg KH wrote: > > > > On Mon, Jul 02, 2018 at 11:57:36AM +0200, Geert Uytterhoeven wrote: > > > > > > > Pseudo-Shortlog of commits: > > > > > > Given you do publish a git tree with these changes, is there any specific > > > reason > > > you're not using a real shortlog? Sorting and grouping would make it > > > easier to see > > > which patches of mine you have backported. > > > > Many years ago Linus wanted it in this type of format as it was easier > > to see what was being applied to the trees. > > I think you refer to an old email of mine where I said: > > "I think Greg has a script he uses, so I'm cc'ing him here too. i'm not > sure I really like his one-liner format, but I'm not sure what the > right format would be. I *think* the format I'd prefer would be a > two-liner one (with a newline in between), something like > > git log --abbrev=12 --format="%h %aN <%aE>%n%s%n" > > but that's more of a "maybe something along those lines.." than anything > else" > > Note that "maybe something along those lines", and in fact the format > Greg uses doesn't have the commit ID in it, so it's more like > > git log --format="%aN <%aE>%n%s%n" > > I forget what the original format Greg used was, but I don't think it > was "shortlog". This is from almost a decade ago, and I couldn't > actually find any of Greg's emails with the original format that I > found to be inconvenient. I think it was something really dense and > incomprehensible based on my " i'm not sure I really like his > one-liner format", but.. > > Maybe just "shortlog" would be better. I agree that it's likely easier > for authors to see what commits got done from them, thanks to the > author grouping. I don't think I was using git originally when I was creating these patches and announcements as the stable trees started up just before git was created. But that changed years ago, let me mess with my scripts to see if I can change this for future -rc announcements. thanks, greg k-h
Re: [PATCH 2/3] arm/arm64: configs: Remove the MFD_ prefix for MFD_CROS_EC_I2C/SPI symbols.
On Mon, 02 Jul 2018, Benson Leung wrote: > On Mon, Jul 02, 2018 at 01:05:40PM +0200, Krzysztof Kozlowski wrote: > > On 2 July 2018 at 12:22, Enric Balletbo i Serra > > wrote: > > > The cros-ec I2C and SPI transport drivers have been moved from MFD > > > subsystem to platform/chrome, at the same time, the config symbol has > > > been renamed and lost the MFD_ prefix, so update all configs to the new > > > config symbol name. > > > > > > Signed-off-by: Enric Balletbo i Serra > > > --- > > > > > > arch/arm/configs/exynos_defconfig | 4 ++-- > > > arch/arm/configs/multi_v7_defconfig | 4 ++-- > > > arch/arm/configs/pxa_defconfig | 4 ++-- > > > arch/arm64/configs/defconfig| 4 ++-- > > > 4 files changed, 8 insertions(+), 8 deletions(-) > > > > Since you put in one patch multiple defconfigs belonging to multiple > > maintainers, I assume you are pushing this through arm-soc or Russell. > > In such case, for Exynos boards: > > Acked-by: Krzysztof Kozlowski > > > > Best regards, > > Krzysztof > > I was planning on creating an immutable branch for this series and merging it > through platform/chrome. > > Lee, Russell, Dmitry, what do you think? Fine by me. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/3] platform/chrome: Move cros-ec transport drivers to drivers/platform.
On Mon, 02 Jul 2018, Enric Balletbo i Serra wrote:
> There are some cros-ec transport drivers (I2C, SPI) living in MFD, while
> others (LPC) living in drivers/platform. The transport drivers are more
> platform specific. So, move the I2C and SPI transport drivers to the
> platform/chrome directory. The patch also removes the MFD_ prefix of
> their Kconfig symbols.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> drivers/mfd/Kconfig | 20 ---
> drivers/mfd/Makefile | 2 --
> drivers/platform/chrome/Kconfig | 20 +++
> drivers/platform/chrome/Makefile | 2 ++
> .../{mfd => platform/chrome}/cros_ec_i2c.c| 0
> .../{mfd => platform/chrome}/cros_ec_spi.c| 0
> 6 files changed, 22 insertions(+), 22 deletions(-)
> rename drivers/{mfd => platform/chrome}/cros_ec_i2c.c (100%)
> rename drivers/{mfd => platform/chrome}/cros_ec_spi.c (100%)
Acked-by: Lee Jones
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 4.17 000/220] 4.17.4-stable review
On Mon, Jul 02, 2018 at 09:33:13AM -0700, Guenter Roeck wrote: > On Sun, Jul 01, 2018 at 06:20:24PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.17.4 release. > > There are 220 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Jul 3 16:08:27 UTC 2018. > > Anything received after that time might be too late. > > > > Build results: > total: 134 pass: 134 fail: 0 > Qemu test results: > total: 158 pass: 158 fail: 0 > > Details are available at http://kerneltests.org/builders. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH] bus: imx-weim: Remove VLA usage
On Fri, Jun 29, 2018 at 01:02:36PM -0700, Kees Cook wrote: > On Fri, Jun 29, 2018 at 12:45 PM, Rob Herring wrote: > > On Fri, Jun 29, 2018 at 12:52 PM Kees Cook wrote: > >> > >> In the quest to remove all stack VLA usage from the kernel[1], this > >> switches to using a maximum size and adds a sanity check. > >> > >> [1] > >> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > >> > >> Cc: Maxime Ripard > >> Cc: Arnd Bergmann > >> Cc: Rob Herring > >> Signed-off-by: Kees Cook > > > > Not sure how you came up with the CC list, but you should probably > > have some i.MX folks CC'ed. > > Automation for the lose, apparently. :) Looks like maybe the > MAINTAINER entry for IMX needs a drivers/bus/imx* line added. :) > > Adding more CCs... Acked-by: Shawn Guo
Re: [PATCH] ARM: dts: am33xx: Add pinmux data for mmc1 in am335x-evm, evmsk and beaglebone
Hi,
On Monday 02 July 2018 04:20 PM, Tony Lindgren wrote:
> * Robert Nelson [180618 14:00]:
>> On Wed, Apr 11, 2018 at 6:48 AM, Faiz Abbas wrote:
>>> am335x-evm, am335x-evmsk and am335x-beaglebone are currently relying on
>>> pinmux set by the bootloader to set the correct value for mmc1. Fix
>>> this by adding pinmux data for the same in kernel.
>>>
>>> Signed-off-by: Faiz Abbas
>>> ---
>>> arch/arm/boot/dts/am335x-bone-common.dtsi | 9 -
>>> arch/arm/boot/dts/am335x-evm.dts | 9 -
>>> arch/arm/boot/dts/am335x-evmsk.dts| 9 -
>>> 3 files changed, 24 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
>>> b/arch/arm/boot/dts/am335x-bone-common.dtsi
>>> index e67b4d6..f9e8667 100644
>>> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
>>> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
>>> @@ -161,7 +161,14 @@
>>>
>>> mmc1_pins: pinmux_mmc1_pins {
>>> pinctrl-single,pins = <
>>> - AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7) /*
>>> GPIO0_6 */
>>> + AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7)
>>> /* spio0_cs1.gpio0_6 */
>>> + AM33XX_IOPAD(0x8fc, PIN_INPUT_PULLUP | MUX_MODE0)
>>> /* mmc0_dat0.mmc0_dat0 */
>>> + AM33XX_IOPAD(0x8f8, PIN_INPUT_PULLUP | MUX_MODE0)
>>> /* mmc0_dat1.mmc0_dat1 */
>>> + AM33XX_IOPAD(0x8f4, PIN_INPUT_PULLUP | MUX_MODE0)
>>> /* mmc0_dat2.mmc0_dat2 */
>>> + AM33XX_IOPAD(0x8f0, PIN_INPUT_PULLUP | MUX_MODE0)
>>> /* mmc0_dat3.mmc0_dat3 */
>>> + AM33XX_IOPAD(0x904, PIN_INPUT_PULLUP | MUX_MODE0)
>>> /* mmc0_cmd.mmc0_cmd */
>>> + AM33XX_IOPAD(0x900, PIN_INPUT_PULLUP | MUX_MODE0)
>>> /* mmc0_clk.mmc0_clk */
>>> + AM33XX_IOPAD(0x9a0, PIN_INPUT | MUX_MODE4)
>>> /* mcasp0_aclkr.mmc0_sdwp */
>>
>> We went one pin too far on the Beagle's here:
>>
>> 0x9a0 ( mcasp0_aclkr.mmc0_sdwp ) = Routed to P9_42, (muxed with C18,
>> to a shared pin on the header), so not connected to the microSD
>> socket...
>>
>> https://github.com/beagleboard/beaglebone-black/blob/master/BBB_SCH.pdf
>>
>> Looking at this evm schematic, it looks like 0x9a0 should be removed
>> too, but I'm not sure on all revisions:
>>
>> http://processors.wiki.ti.com/images/a/a2/TMDSSK3358_3H0009_REV1_2B_SCH.pdf
>
> Hmm care to post a fix for this?
>
Apologies for not replying here earlier.
You're right. The sdwp pin needs to be removed from bone and evm sk. It
needs to stay only for gp evm. Looks like this needs to be fixed for
bone in U-boot also.
Thanks,
Faiz
[PATCH][RESEND] component: enhance handling of devres group for master
From: Banajit Goswami
The devres group opened for a master is left open-ended (without
devres_group_close) even after bind() is complete. Similarly, while
releasing the devres resources for master, the most recently opened
devres group is selected, and released without identifying the
targeted group. As the devres group opened before master bind was
never closed, there may have unintended consequences of releasing
devres resources that were allocated after master bind() function
was complete.
Change adds a devres_group_close() after bind() call to master, to
encapsulate the resources allocated during bind, and then use a
group ID to specifically identify the group in release, so that
during master unbind, only the resources that are part of that
specific devres group, are released.
Signed-off-by: Banajit Goswami
---
drivers/base/component.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 89b032f..f9ce937 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -155,17 +155,19 @@ static int try_to_bring_up_master(struct master *master,
return 0;
}
- if (!devres_open_group(master->dev, NULL, GFP_KERNEL))
+ if (!devres_open_group(master->dev, master, GFP_KERNEL))
return -ENOMEM;
/* Found all components */
ret = master->ops->bind(master->dev);
if (ret < 0) {
- devres_release_group(master->dev, NULL);
+ devres_release_group(master->dev, master);
dev_info(master->dev, "master bind failed: %d\n", ret);
return ret;
}
+ devres_close_group(master->dev, master);
+
master->bound = true;
return 1;
}
@@ -190,7 +192,7 @@ static void take_down_master(struct master *master)
{
if (master->bound) {
master->ops->unbind(master->dev);
- devres_release_group(master->dev, NULL);
+ devres_release_group(master->dev, master);
master->bound = false;
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3 1/6] KVM: X86: Add kvm hypervisor init time platform setup callback
From: Wanpeng Li
Add kvm hypervisor init time platform setup callback which
will be used to replace native apic hooks by pararvirtual
hooks.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Vitaly Kuznetsov
Signed-off-by: Wanpeng Li
---
arch/x86/kernel/kvm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 5b2300b..591bcf2 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -624,12 +624,22 @@ static uint32_t __init kvm_detect(void)
return kvm_cpuid_base();
}
+static void __init kvm_apic_init(void)
+{
+}
+
+static void __init kvm_init_platform(void)
+{
+ x86_platform.apic_post_init = kvm_apic_init;
+}
+
const __initconst struct hypervisor_x86 x86_hyper_kvm = {
.name = "KVM",
.detect = kvm_detect,
.type = X86_HYPER_KVM,
.init.guest_late_init = kvm_guest_init,
.init.x2apic_available = kvm_para_available,
+ .init.init_platform = kvm_init_platform,
};
static __init int activate_jump_labels(void)
--
2.7.4
[PATCH v3 2/6] KVM: X86: Implement PV IPIs in linux guest
From: Wanpeng Li
Implement paravirtual apic hooks to enable PV IPIs.
apic->send_IPI_mask
apic->send_IPI_mask_allbutself
apic->send_IPI_allbutself
apic->send_IPI_all
The PV IPIs supports maximal 128 vCPUs VM, it is big enough for cloud
environment currently, supporting more vCPUs needs to introduce more
complex logic, in the future this might be extended if needed.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Vitaly Kuznetsov
Signed-off-by: Wanpeng Li
---
arch/x86/include/uapi/asm/kvm_para.h | 1 +
arch/x86/kernel/kvm.c| 70
include/uapi/linux/kvm_para.h| 1 +
3 files changed, 72 insertions(+)
diff --git a/arch/x86/include/uapi/asm/kvm_para.h
b/arch/x86/include/uapi/asm/kvm_para.h
index 0ede697..19980ec 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -28,6 +28,7 @@
#define KVM_FEATURE_PV_UNHALT 7
#define KVM_FEATURE_PV_TLB_FLUSH 9
#define KVM_FEATURE_ASYNC_PF_VMEXIT10
+#define KVM_FEATURE_PV_SEND_IPI11
#define KVM_HINTS_REALTIME 0
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 591bcf2..2fe1420 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -454,6 +454,71 @@ static void __init sev_map_percpu_data(void)
}
#ifdef CONFIG_SMP
+
+#ifdef CONFIG_X86_64
+static void __send_ipi_mask(const struct cpumask *mask, int vector)
+{
+ unsigned long flags, ipi_bitmap_low = 0, ipi_bitmap_high = 0;
+ int cpu, apic_id;
+
+ if (cpumask_empty(mask))
+ return;
+
+ local_irq_save(flags);
+
+ for_each_cpu(cpu, mask) {
+ apic_id = per_cpu(x86_cpu_to_apicid, cpu);
+ if (apic_id < BITS_PER_LONG)
+ __set_bit(apic_id, &ipi_bitmap_low);
+ else if (apic_id < 2 * BITS_PER_LONG)
+ __set_bit(apic_id - BITS_PER_LONG, &ipi_bitmap_high);
+ }
+
+ kvm_hypercall3(KVM_HC_SEND_IPI, ipi_bitmap_low, ipi_bitmap_high,
vector);
+
+ local_irq_restore(flags);
+}
+
+static void kvm_send_ipi_mask(const struct cpumask *mask, int vector)
+{
+ __send_ipi_mask(mask, vector);
+}
+
+static void kvm_send_ipi_mask_allbutself(const struct cpumask *mask, int
vector)
+{
+ unsigned int this_cpu = smp_processor_id();
+ struct cpumask new_mask;
+ const struct cpumask *local_mask;
+
+ cpumask_copy(&new_mask, mask);
+ cpumask_clear_cpu(this_cpu, &new_mask);
+ local_mask = &new_mask;
+ __send_ipi_mask(local_mask, vector);
+}
+
+static void kvm_send_ipi_allbutself(int vector)
+{
+ kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
+}
+
+static void kvm_send_ipi_all(int vector)
+{
+ __send_ipi_mask(cpu_online_mask, vector);
+}
+
+/*
+ * Set the IPI entry points
+ */
+static void kvm_setup_pv_ipi(void)
+{
+ apic->send_IPI_mask = kvm_send_ipi_mask;
+ apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
+ apic->send_IPI_allbutself = kvm_send_ipi_allbutself;
+ apic->send_IPI_all = kvm_send_ipi_all;
+ pr_info("KVM setup pv IPIs\n");
+}
+#endif
+
static void __init kvm_smp_prepare_cpus(unsigned int max_cpus)
{
native_smp_prepare_cpus(max_cpus);
@@ -626,6 +691,11 @@ static uint32_t __init kvm_detect(void)
static void __init kvm_apic_init(void)
{
+#if defined(CONFIG_SMP) && defined(CONFIG_X86_64)
+ if (kvm_para_has_feature(KVM_FEATURE_PV_SEND_IPI) &&
+ num_possible_cpus() <= 2 * BITS_PER_LONG)
+ kvm_setup_pv_ipi();
+#endif
}
static void __init kvm_init_platform(void)
diff --git a/include/uapi/linux/kvm_para.h b/include/uapi/linux/kvm_para.h
index dcf629d..84f8fe3 100644
--- a/include/uapi/linux/kvm_para.h
+++ b/include/uapi/linux/kvm_para.h
@@ -26,6 +26,7 @@
#define KVM_HC_MIPS_EXIT_VM7
#define KVM_HC_MIPS_CONSOLE_OUTPUT 8
#define KVM_HC_CLOCK_PAIRING 9
+#define KVM_HC_SEND_IPI10
/*
* hypercalls use architecture specific
--
2.7.4
[PATCH v3 3/6] KVM: X86: Fallback to original apic hooks when bad happens
From: Wanpeng Li
Fallback to original apic hooks when apic id is sparse and larger
than 128 or kvm fails to add the pending IRQ to lapic.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Vitaly Kuznetsov
Signed-off-by: Wanpeng Li
---
arch/x86/kernel/kvm.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 2fe1420..81be75b 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -47,6 +47,7 @@
#include
#include
+static struct apic orig_apic;
static int kvmapf = 1;
static int __init parse_no_kvmapf(char *arg)
@@ -456,13 +457,13 @@ static void __init sev_map_percpu_data(void)
#ifdef CONFIG_SMP
#ifdef CONFIG_X86_64
-static void __send_ipi_mask(const struct cpumask *mask, int vector)
+static int __send_ipi_mask(const struct cpumask *mask, int vector)
{
unsigned long flags, ipi_bitmap_low = 0, ipi_bitmap_high = 0;
- int cpu, apic_id;
+ int cpu, apic_id, ret = 0;
if (cpumask_empty(mask))
- return;
+ return 0;
local_irq_save(flags);
@@ -472,16 +473,23 @@ static void __send_ipi_mask(const struct cpumask *mask,
int vector)
__set_bit(apic_id, &ipi_bitmap_low);
else if (apic_id < 2 * BITS_PER_LONG)
__set_bit(apic_id - BITS_PER_LONG, &ipi_bitmap_high);
+ else {
+ ret = -EFAULT;
+ goto irq_restore_exit;
+ }
}
- kvm_hypercall3(KVM_HC_SEND_IPI, ipi_bitmap_low, ipi_bitmap_high,
vector);
+ ret = kvm_hypercall3(KVM_HC_SEND_IPI, ipi_bitmap_low, ipi_bitmap_high,
vector);
+irq_restore_exit:
local_irq_restore(flags);
+ return ret;
}
static void kvm_send_ipi_mask(const struct cpumask *mask, int vector)
{
- __send_ipi_mask(mask, vector);
+ if (__send_ipi_mask(mask, vector))
+ orig_apic.send_IPI_mask(mask, vector);
}
static void kvm_send_ipi_mask_allbutself(const struct cpumask *mask, int
vector)
@@ -493,7 +501,8 @@ static void kvm_send_ipi_mask_allbutself(const struct
cpumask *mask, int vector)
cpumask_copy(&new_mask, mask);
cpumask_clear_cpu(this_cpu, &new_mask);
local_mask = &new_mask;
- __send_ipi_mask(local_mask, vector);
+ if (__send_ipi_mask(local_mask, vector))
+ orig_apic.send_IPI_mask_allbutself(mask, vector);
}
static void kvm_send_ipi_allbutself(int vector)
@@ -503,7 +512,8 @@ static void kvm_send_ipi_allbutself(int vector)
static void kvm_send_ipi_all(int vector)
{
- __send_ipi_mask(cpu_online_mask, vector);
+ if (__send_ipi_mask(cpu_online_mask, vector))
+ orig_apic.send_IPI_all(vector);
}
/*
@@ -511,6 +521,8 @@ static void kvm_send_ipi_all(int vector)
*/
static void kvm_setup_pv_ipi(void)
{
+ orig_apic = *apic;
+
apic->send_IPI_mask = kvm_send_ipi_mask;
apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
apic->send_IPI_allbutself = kvm_send_ipi_allbutself;
--
2.7.4
[PATCH v3 4/6] KVM: X86: Implement PV IPIs send hypercall
From: Wanpeng Li
Using hypercall to send IPIs by one vmexit instead of one by one for
xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster
mode. Intel guest can enter x2apic cluster mode when interrupt remmaping
is enabled in qemu, however, latest AMD EPYC still just supports xapic
mode which can get great improvement by PV IPIs.
Hardware: Xeon Skylake 2.5GHz, 2 sockets, 40 cores, 80 threads, the VM
is 80 vCPUs, IPI microbenchmark(https://lkml.org/lkml/2017/12/19/141):
x2apic cluster mode, vanilla
Dry-run: 0,2392199 ns
Self-IPI: 6907514, 15027589 ns
Normal IPI: 223910476, 251301666 ns
Broadcast IPI: 0, 9282161150 ns
Broadcast lock: 0, 8812934104 ns
x2apic cluster mode, pv-ipi
Dry-run: 0,2449341 ns
Self-IPI: 6720360, 15028732 ns
Normal IPI: 228643307, 255708477 ns
Broadcast IPI: 0, 7572293590 ns => 22% performance
boost
Broadcast lock: 0, 8316124651 ns
x2apic physical mode, vanilla
Dry-run: 0,3135933 ns
Self-IPI: 8572670, 17901757 ns
Normal IPI: 226444334, 255421709 ns
Broadcast IPI: 0,19845070887 ns
Broadcast lock: 0,19827383656 ns
x2apic physical mode, pv-ipi
Dry-run: 0,2446381 ns
Self-IPI: 6788217, 15021056 ns
Normal IPI: 219454441, 249583458 ns
Broadcast IPI: 0, 7806540019 ns => 154% performance
boost
Broadcast lock: 0, 9143618799 ns
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Vitaly Kuznetsov
Signed-off-by: Wanpeng Li
---
Documentation/virtual/kvm/hypercalls.txt | 6 ++
arch/x86/kvm/x86.c | 36
2 files changed, 42 insertions(+)
diff --git a/Documentation/virtual/kvm/hypercalls.txt
b/Documentation/virtual/kvm/hypercalls.txt
index a890529..a771ee8 100644
--- a/Documentation/virtual/kvm/hypercalls.txt
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -121,3 +121,9 @@ compute the CLOCK_REALTIME for its clock, at the same
instant.
Returns KVM_EOPNOTSUPP if the host does not use TSC clocksource,
or if clock type is different than KVM_CLOCK_PAIRING_WALLCLOCK.
+
+6. KVM_HC_SEND_IPI
+
+Architecture: x86
+Status: active
+Purpose: Hypercall used to send IPIs.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0046aa7..46657ef 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6689,6 +6689,39 @@ static void kvm_pv_kick_cpu_op(struct kvm *kvm, unsigned
long flags, int apicid)
kvm_irq_delivery_to_apic(kvm, NULL, &lapic_irq, NULL);
}
+/*
+ * Return 0 if successfully added and 1 if discarded.
+ */
+static int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
+ unsigned long ipi_bitmap_high, int vector)
+{
+ int i;
+ struct kvm_apic_map *map;
+ struct kvm_vcpu *vcpu;
+ struct kvm_lapic_irq irq = {
+ .delivery_mode = APIC_DM_FIXED,
+ .vector = vector,
+ };
+
+ rcu_read_lock();
+ map = rcu_dereference(kvm->arch.apic_map);
+
+ for_each_set_bit(i, &ipi_bitmap_low, BITS_PER_LONG) {
+ vcpu = map->phys_map[i]->vcpu;
+ if (!kvm_apic_set_irq(vcpu, &irq, NULL))
+ return 1;
+ }
+
+ for_each_set_bit(i, &ipi_bitmap_high, BITS_PER_LONG) {
+ vcpu = map->phys_map[i + BITS_PER_LONG]->vcpu;
+ if (!kvm_apic_set_irq(vcpu, &irq, NULL))
+ return 1;
+ }
+
+ rcu_read_unlock();
+ return 0;
+}
+
void kvm_vcpu_deactivate_apicv(struct kvm_vcpu *vcpu)
{
vcpu->arch.apicv_active = false;
@@ -6737,6 +6770,9 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
case KVM_HC_CLOCK_PAIRING:
ret = kvm_pv_clock_pairing(vcpu, a0, a1);
break;
+ case KVM_HC_SEND_IPI:
+ ret = kvm_pv_send_ipi(vcpu->kvm, a0, a1, a2);
+ break;
#endif
default:
ret = -KVM_ENOSYS;
--
2.7.4
[PATCH v3 5/6] KVM: X86: Add NMI support to PV IPIs
From: Wanpeng Li
The NMI delivery mode of ICR is used to deliver an NMI to the processor,
and the vector information is ignored.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Vitaly Kuznetsov
Signed-off-by: Wanpeng Li
---
arch/x86/kernel/kvm.c | 13 +++--
arch/x86/kvm/x86.c| 16 +++-
2 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 81be75b..b866518 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -459,7 +459,7 @@ static void __init sev_map_percpu_data(void)
#ifdef CONFIG_X86_64
static int __send_ipi_mask(const struct cpumask *mask, int vector)
{
- unsigned long flags, ipi_bitmap_low = 0, ipi_bitmap_high = 0;
+ unsigned long flags, ipi_bitmap_low = 0, ipi_bitmap_high = 0, icr = 0;
int cpu, apic_id, ret = 0;
if (cpumask_empty(mask))
@@ -479,7 +479,16 @@ static int __send_ipi_mask(const struct cpumask *mask, int
vector)
}
}
- ret = kvm_hypercall3(KVM_HC_SEND_IPI, ipi_bitmap_low, ipi_bitmap_high,
vector);
+ switch (vector) {
+ default:
+ icr = APIC_DM_FIXED | vector;
+ break;
+ case NMI_VECTOR:
+ icr = APIC_DM_NMI;
+ break;
+ }
+
+ ret = kvm_hypercall3(KVM_HC_SEND_IPI, ipi_bitmap_low, ipi_bitmap_high,
icr);
irq_restore_exit:
local_irq_restore(flags);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 46657ef..2e4c4d7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6693,15 +6693,21 @@ static void kvm_pv_kick_cpu_op(struct kvm *kvm,
unsigned long flags, int apicid)
* Return 0 if successfully added and 1 if discarded.
*/
static int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
- unsigned long ipi_bitmap_high, int vector)
+ unsigned long ipi_bitmap_high, unsigned long icr)
{
int i;
struct kvm_apic_map *map;
struct kvm_vcpu *vcpu;
- struct kvm_lapic_irq irq = {
- .delivery_mode = APIC_DM_FIXED,
- .vector = vector,
- };
+ struct kvm_lapic_irq irq = {0};
+
+ switch (icr & APIC_VECTOR_MASK) {
+ default:
+ irq.vector = icr & APIC_VECTOR_MASK;
+ break;
+ case NMI_VECTOR:
+ break;
+ }
+ irq.delivery_mode = icr & APIC_MODE_MASK;
rcu_read_lock();
map = rcu_dereference(kvm->arch.apic_map);
--
2.7.4
[PATCH v3 0/6] KVM: X86: Implement PV IPIs support
Using hypercall to send IPIs by one vmexit instead of one by one for xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster mode. Intel guest can enter x2apic cluster mode when interrupt remmaping is enabled in qemu, however, latest AMD EPYC still just supports xapic mode which can get great improvement by PV IPIs. This patchset supports PV IPIs for maximal 128 vCPUs VM, it is big enough for cloud environment currently, supporting more vCPUs needs to introduce more complex logic, in the future this might be extended if needed. Hardware: Xeon Skylake 2.5GHz, 2 sockets, 40 cores, 80 threads, the VM is 80 vCPUs, IPI microbenchmark(https://lkml.org/lkml/2017/12/19/141): x2apic cluster mode, vanilla Dry-run: 0,2392199 ns Self-IPI: 6907514, 15027589 ns Normal IPI: 223910476, 251301666 ns Broadcast IPI: 0, 9282161150 ns Broadcast lock: 0, 8812934104 ns x2apic cluster mode, pv-ipi Dry-run: 0,2449341 ns Self-IPI: 6720360, 15028732 ns Normal IPI: 228643307, 255708477 ns Broadcast IPI: 0, 7572293590 ns => 22% performance boost Broadcast lock: 0, 8316124651 ns x2apic physical mode, vanilla Dry-run: 0,3135933 ns Self-IPI: 8572670, 17901757 ns Normal IPI: 226444334, 255421709 ns Broadcast IPI: 0,19845070887 ns Broadcast lock: 0,19827383656 ns x2apic physical mode, pv-ipi Dry-run: 0,2446381 ns Self-IPI: 6788217, 15021056 ns Normal IPI: 219454441, 249583458 ns Broadcast IPI: 0, 7806540019 ns => 154% performance boost Broadcast lock: 0, 9143618799 ns v2 -> v3: * rename ipi_mask_done to irq_restore_exit, __send_ipi_mask return int instead of bool * fix build errors reported by 0day * split patches, nothing change v1 -> v2: * sparse apic id > 128, or any other errors, fallback to original apic hooks * have two bitmask arguments so that one hypercall handles 128 vCPUs * fix KVM_FEATURE_PV_SEND_IPI doc * document hypercall * fix NMI selftest fails * fix build errors reported by 0day Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Vitaly Kuznetsov Wanpeng Li (6): KVM: X86: Add kvm hypervisor init time platform setup callback KVM: X86: Implement PV IPIs in linux guest KVM: X86: Fallback to original apic hooks when bad happens KVM: X86: Implement PV IPIs send hypercall KVM: X86: Add NMI support to PV IPIs KVM: X86: Expose PV_SEND_IPI CPUID feature bit to guest Documentation/virtual/kvm/cpuid.txt | 4 ++ Documentation/virtual/kvm/hypercalls.txt | 6 ++ arch/x86/include/uapi/asm/kvm_para.h | 1 + arch/x86/kernel/kvm.c| 101 +++ arch/x86/kvm/cpuid.c | 3 +- arch/x86/kvm/x86.c | 42 + include/uapi/linux/kvm_para.h| 1 + 7 files changed, 157 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH v3 6/6] KVM: X86: Expose PV_SEND_IPI CPUID feature bit to guest
From: Wanpeng Li Expose PV_SEND_IPI feature bit to guest, the guest can check this feature bit before using paravirtualized send IPIs. Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Vitaly Kuznetsov Signed-off-by: Wanpeng Li --- Documentation/virtual/kvm/cpuid.txt | 4 arch/x86/kvm/cpuid.c| 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index ab022dc..97ca194 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt @@ -62,6 +62,10 @@ KVM_FEATURE_ASYNC_PF_VMEXIT||10 || paravirtualized async PF VM exit || || can be enabled by setting bit 2 || || when writing to msr 0x4b564d02 -- +KVM_FEATURE_PV_SEND_IPI||11 || guest checks this feature bit + || || before using paravirtualized + || || send IPIs. +-- KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side || || per-cpu warps are expected in || || kvmclock. diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 7e042e3..7bcfa61 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -621,7 +621,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) | (1 << KVM_FEATURE_PV_UNHALT) | (1 << KVM_FEATURE_PV_TLB_FLUSH) | -(1 << KVM_FEATURE_ASYNC_PF_VMEXIT); +(1 << KVM_FEATURE_ASYNC_PF_VMEXIT) | +(1 << KVM_FEATURE_PV_SEND_IPI); if (sched_info_on()) entry->eax |= (1 << KVM_FEATURE_STEAL_TIME); -- 2.7.4
Re: [PATCH] IB/mlx4: Test port number before querying type.
On Mon, Jul 02, 2018 at 02:02:34PM -0700, Tarick Bedeir wrote:
> rdma_ah_find_type() can reach into ib_device->port_immutable with a
> potentially out-of-bounds port number, so check that the port number is
> valid first.
>
> Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
> Signed-off-by: Tarick Bedeir
> ---
> drivers/infiniband/hw/mlx4/qp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
> index f045491f2c14..4f1dabecf9a5 100644
> --- a/drivers/infiniband/hw/mlx4/qp.c
> +++ b/drivers/infiniband/hw/mlx4/qp.c
> @@ -4034,9 +4034,9 @@ static void to_rdma_ah_attr(struct mlx4_ib_dev *ibdev,
> u8 port_num = path->sched_queue & 0x40 ? 2 : 1;
>
> memset(ah_attr, 0, sizeof(*ah_attr));
> - ah_attr->type = rdma_ah_find_type(&ibdev->ib_dev, port_num);
> if (port_num == 0 || port_num > dev->caps.num_ports)
Did you get any warning from any checker about out-of-bounds access?
According to the line above, port_num can be 2 or 1 which are valid ports for
mlx4
and the check above doesn't do much.
> return;
> + ah_attr->type = rdma_ah_find_type(&ibdev->ib_dev, port_num);
>
> if (ah_attr->type == RDMA_AH_ATTR_TYPE_ROCE)
> rdma_ah_set_sl(ah_attr, ((path->sched_queue >> 3) & 0x7) |
> --
> 2.18.0.399.gad0ab374a1-goog
>
signature.asc
Description: PGP signature
Re: [PATCH] ARM: imx: enable bus auto clock gating function for i.mx6sll
On Sun, 01 Jul 2018, Shawn Guo wrote: > On Fri, Jun 22, 2018 at 01:32:48PM +0800, Anson Huang wrote: > > i.MX6SLL has HW bus auto clock gating function, enable > > it by default to save VDD_SOC_IN power, about 5% ~ 20% > > saved depends on different use cases. > > > > Signed-off-by: Anson Huang > > Applied, thanks. Since this touches MFD, please apply my Ack to the patch. Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] bus: ti-sysc: Use 2-factor allocator arguments
* Kees Cook [180702 16:17]: > On Mon, Jul 2, 2018 at 4:27 AM, Tony Lindgren wrote: > > * Kees Cook [180627 21:59]: > >> On Mon, Jun 18, 2018 at 10:45 AM, Kees Cook wrote: > >> > This adjusts the allocator calls to use 2-factor argument call style, as > >> > done treewide already for improved defense against allocation overflows. > >> > > >> > Signed-off-by: Kees Cook > >> > >> Friendly ping! :) This is the last 2-factor devm* allocation left in > >> 4.18 to be fixed. > > > > Sorry for the delay on this one. As we're already at -rc3, I'll apply > > this into omap-for-v4.19/ti-sysc. Seems there should not be need to rush > > this into v4.18-rc cycle, but please do let me know if that is not the > > case. > > I'd like to be able to reason about multiplication vs allocator uses > in 4.18 and later. Since all other allocators got fixed in 4.18, I'd > really like to have this one fixed too, then the scripts that check > for multiplications in single-argument allocators will run clean for > 4.18. > > So, it's not strictly a "rush", but it would be appreciated. :) OK I'll merge that commit also into omap-for-v4.18/fixes branch too. Regards, Tony
Re: Build regressions/improvements in v4.18-rc3
On 03.07.2018 03:09, Michael Ellerman wrote: > Helge Deller writes: > >> On 02.07.2018 16:09, Geert Uytterhoeven wrote: >>> On Mon, Jul 2, 2018 at 4:01 PM Geert Uytterhoeven >>> wrote: JFYI, when comparing v4.18-rc3[1] to v4.18-rc2[3], the summaries are: >>> ... >> >> Both of the following are simply happening because of old compiler which is >> being used: >> [Deleted 26903 lines about "warning: ... [-Wpointer-sign]" on parisc-allmodconfig] > > It's GCC 4.6.3. Are you saying that's not supported anymore? > > I can update to 8.1.0 if that's more useful. Yes, please. Any version >= 7.2.1 should be better. Helge
Re: linux-next: Signed-off-by missing for commit in the omap tree
* Stephen Rothwell [180702 22:23]:
> Hi Tony,
>
> Commit
>
> 5322c19b117a ("ARM: OMAP1: ams-delta: Hog "keybrd_dataout" GPIO pin")
>
> is missing a Signed-off-by from its committer.
Oops sorry about that, I'll set up a omap-for-v4.19/omap1-v2
branch to fix this today.
Regards,
Tony
Re: [RFC v3 PATCH 5/5] x86: check VM_DEAD flag in page fault
On Mon 02-07-18 11:10:23, Yang Shi wrote: > On 7/2/18 10:57 AM, Michal Hocko wrote: [...] > > Why would you even care about shared mappings? > > Just thought about we are dealing with VM_DEAD, which means the vma will be > tore down soon regardless it is shared or non-shared. > > MMF_UNSTABLE doesn't care about !shared case. Let me clarify some more. MMF_UNSTABLE is there to prevent from unexpected page faults when the mm is torn down by the oom reaper. And oom reaper only cares about private mappings because we do not touch shared ones. Disk based shared mappings should be a non-issue for VM_DEAD because even if you race and refault a page back then you know it is the same one you have seen before. Memory backed shared mappings are a different story because you can get a fresh new page. oom_reaper doesn't care because it doesn't tear those down. You would have to but my primary point was that we already have MMF_UNSTABLE so all you need is to extend it to memory backed shared mappings (shmem and hugetlb). -- Michal Hocko SUSE Labs
Re: [PATCH v1] ARM: dts: imx51-zii-rdu1: correct touchscreen axis inversion
On Thu, Jun 28, 2018 at 11:56:26PM +0100, Nick Dyer wrote: > The RMI4 touchscreen driver applied inversion and axis swap in the > wrong order, violating the DT binding for those properties. This was fixed in > 645a397, so correct the RDU1 DT to apply the inversion to the > correct axis. > > Tested on Zii RDU1 00-5105-30 rev B > > Signed-off-by: Nick Dyer Applied, thanks.
Re: [RFC v3 PATCH 4/5] mm: mmap: zap pages with read mmap_sem for large mapping
On Mon 02-07-18 13:48:45, Andrew Morton wrote: > On Mon, 2 Jul 2018 16:05:02 +0200 Michal Hocko wrote: > > > On Fri 29-06-18 20:15:47, Andrew Morton wrote: > > [...] > > > Would one of your earlier designs have addressed all usecases? I > > > expect the dumb unmap-a-little-bit-at-a-time approach would have? > > > > It has been already pointed out that this will not work. > > I said "one of". There were others. Well, I was aware only about two potential solutions. Either do the heavy lifting under the shared lock and do the rest with the exlusive one and this, drop the lock per parts. Maybe I have missed others? > > You simply > > cannot drop the mmap_sem during unmap because another thread could > > change the address space under your feet. So you need some form of > > VM_DEAD and handle concurrent and conflicting address space operations. > > Unclear that this is a problem. If a thread does an unmap of a range > of virtual address space, there's no guarantee that upon return some > other thread has not already mapped new stuff into that address range. > So what's changed? Well, consider the following scenario: Thread A = calling mmap(NULL, sizeA) Thread B = calling munmap(addr, sizeB) They do not use any external synchronization and rely on the atomic munmap. Thread B only munmaps range that it knows belongs to it (e.g. called mmap in the past). It should be clear that ThreadA should not get an address from the addr, sizeB range, right? In the most simple case it will not happen. But let's say that the addr, sizeB range has unmapped holes for what ever reasons. Now anytime munmap drops the exclusive lock after handling one VMA, Thread A might find its sizeA range and use it. ThreadB then might remove this new range as soon as it gets its exclusive lock again. Is such a code safe? No it is not and I would call it fragile at best but people tend to do weird things and atomic munmap behavior is something they can easily depend on. Another example would be an atomic address range probing by MAP_FIXED_NOREPLACE. It would simply break for similar reasons. I remember my attempt to make MAP_LOCKED consistent with mlock (if the population fails then return -ENOMEM) and that required to drop the shared mmap_sem and take it in exclusive mode (because we do not have upgrade_read) and Linus was strongly against [1][2] for very similar reasons. If you drop the lock you simply do not know what happened under your feet. [1] http://lkml.kernel.org/r/CA+55aFydkG-BgZzry5DrTzueVh9VvEcVJdLV8iOyUphQk=0...@mail.gmail.com [2] http://lkml.kernel.org/r/ca+55afyajquhghw59qnwkgk4dbv0tpmdd7-1xqpo7dzwvo_...@mail.gmail.com -- Michal Hocko SUSE Labs
Re: [PATCH 3/3] pinctrl: qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant
Quoting Douglas Anderson (2018-07-02 15:59:39)
> If you do this on an sdm845 board:
> grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups
>
> ...it looks like nonsense. For every pin you see listed:
> input bias disabled, input bias high impedance, input bias pull down, input
> bias pull up, ...
>
> That's because pmic_gpio_config_get() isn't complying with the rules
> that pinconf_generic_dump_one() expects. Specifically for boolean
> parameters (anything with a "struct pin_config_item" where has_arg is
> false) the function expects that the function should return its value
> not through the "config" parameter but should return "0" if the value
> is set and "-EINVAL" if the value isn't set.
>
> Let's fix this.
>
> From a quick sample of other pinctrl drivers, it appears to be
> tradition to also return 1 through the config parameter for these
> boolean parameters when they exist. I'm not one to knock tradition,
> so I'll follow tradition and return 1 in these cases. While I'm at
> it, I'll also continue searching for four leaf clovers, kocking on
Small typo here.
> wood three times, and trying not to break mirrors.
>
> NOTE: This also fixes an apparent typo for reading
> PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally
> using "=" instead of "==" and thus was setting some internal
> state when you tried to query PIN_CONFIG_BIAS_DISABLE. Oops.
Awesome!
>
> Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver")
> Signed-off-by: Douglas Anderson
We should fix the ssbi-gpio/mpp and spmi-mpp drivers too. All those
drivers are designed on the same buggy original driver.
Re: [PATCHv2 1/2] ARM: dts: imx53: PPD: Add fixed-regulator information
On Thu, Jun 28, 2018 at 06:36:38PM +0200, Sebastian Reichel wrote: > Add information about 3V3 power rail to avoid kernel warnings, > that dummy regulators have been added. > > Signed-off-by: Sebastian Reichel I changed subject prefix to 'ARM: dts: imx53-ppd: ...', and applied both. Shawn
Re: [PATCH v2] stop_machine: Disable preemption when waking two stopper threads
Hi Peter,
Thanks for the feedback. I'll make sure to incorporate it into my next
patch, and send that soon.
Thanks,
Isaac Manjarres
On 2018-07-02 05:15, Peter Zijlstra wrote:
On Fri, Jun 29, 2018 at 01:55:12PM -0700, Isaac J. Manjarres wrote:
When cpu_stop_queue_two_works() begins to wake the stopper
threads, it does so without preemption disabled, which leads
to the following race condition:
The source CPU calls cpu_stop_queue_two_works(), with cpu1
as the source CPU, and cpu2 as the destination CPU. When
adding the stopper threads to the wake queue used in this
function, the source CPU stopper thread is added first,
and the destination CPU stopper thread is added last.
When wake_up_q() is invoked to wake the stopper threads, the
threads are woken up in the order that they are queued in,
so the source CPU's stopper thread is woken up first, and
it preempts the thread running on the source CPU.
The stopper thread will then execute on the source CPU,
disable preemption, and begin executing multi_cpu_stop(),
and wait for an ack from the destination CPU's stopper thread,
with preemption still disabled. Since the worker thread that
woke up the stopper thread on the source CPU is affine to the
source CPU, and preemption is disabled on the source CPU, that
thread will never run to dequeue the destination CPU's stopper
thread from the wake queue, and thus, the destination CPU's
stopper thread will never run, causing the source CPU's stopper
thread to wait forever, and stall.
Disable preemption when waking the stopper threads in
cpu_stop_queue_two_works() to ensure that the worker thread
that is waking up the stopper threads isn't preempted
by the source CPU's stopper thread, and permanently
scheduled out, leaving the remaining stopper thread asleep
in the wake queue.
Co-developed-by: Pavankumar Kondeti
Signed-off-by: Prasad Sodagudi
Signed-off-by: Pavankumar Kondeti
Signed-off-by: Isaac J. Manjarres
That SoB chain is broken, if Prasad wrote the ptch then there needs to
be a From: line somewhere.
But yes, that looks about right.
---
kernel/stop_machine.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index f89014a..1ff523d 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -270,7 +270,11 @@ static int cpu_stop_queue_two_works(int cpu1,
struct cpu_stop_work *work1,
goto retry;
}
- wake_up_q(&wakeq);
+ if (!err) {
+ preempt_disable();
+ wake_up_q(&wakeq);
+ preempt_enable();
+ }
return err;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
Re: [PATCH upstream] KASAN: slab-out-of-bounds Read in getname_kernel
On Tue, Jul 3, 2018 at 3:34 AM, Ian Kent wrote: > On Mon, 2018-07-02 at 14:15 +0200, Dmitry Vyukov wrote: >> On Mon, Jul 2, 2018 at 1:55 PM, tomas wrote: >> > Yes, thanks. Please use my full name, Tomas Bortoli. >> >> >> Please also include: >> >> Reported-by: syzbot+60c837b428dc84e83...@syzkaller.appspotmail.com > > Done. > >> >> from the original bug report. This this help to keep automatic testing >> process running. > > Umm ... should I include this email address on the actual cc when > submitting the patch? It does not matter. It's a real email address too, so CCing it is fine. So if git does it automatically (does it?) then just go with it. If you are doing it manually, then it's not necessary to add it to CC. syzbot will scrape git log later to discover the tag and mark the bug fixed. Thanks >> > On 07/02/2018 12:20 PM, Ian Kent wrote: >> > > On Mon, 2018-07-02 at 10:31 +0200, tomas wrote: >> > > > Hi Ian, >> > > > >> > > > you are welcome! >> > > > >> > > > yes your patch is much better. You should just put the "_IOC_NR" macro >> > > > around "cmd" in the lines added to "validate_dev_ioctl" to make it >> > > > work. >> > > >> > > LOL, yes, that was a dumb mistake. >> > > >> > > I'll send it to Andrew Morton, after some fairly simple sanity testing, >> > > with both our Signed-off-by added. >> > > >> > > > Tomas >> > > > >> > > > >> > > > On 07/02/2018 03:42 AM, Ian Kent wrote: >> > > > > On Mon, 2018-07-02 at 09:10 +0800, Ian Kent wrote: >> > > > > > On Mon, 2018-07-02 at 00:04 +0200, tomas wrote: >> > > > > > > Hi, >> > > > > > > >> > > > > > > I've looked into this issue found by Syzbot and I made a patch: >> > > > > > > >> > > > > > > https://syzkaller.appspot.com/bug?id=d03abd8b42847f7f69b1d1d7f9720 >> > > > > > > 8ae425 >> > > > > > > b116 >> > > > > > > 3 >> > > > > > >> > > > > > Umm ... oops! >> > > > > > >> > > > > > Thanks for looking into this Tomas. >> > > > > > >> > > > > > > The autofs subsystem does not check that the "path" parameter is >> > > > > > > present >> > > > > > > within the "param" struct passed by the userspace in case the >> > > > > > > AUTOFS_DEV_IOCTL_OPENMOUNT_CMD command is passed. Indeed, it >> > > > > > > assumes a >> > > > > > > path is always provided (though a path is not always present, as >> > > > > > > per how >> > > > > > > the struct is defined: >> > > > > > > https://github.com/torvalds/linux/blob/master/include/uapi/linux/a >> > > > > > > uto_de >> > > > > > > v-io >> > > > > > > ct >> > > > > > > l.h#L89). >> > > > > > > Skipping the check provokes an oob read in "strlen", called by >> > > > > > > "getname_kernel", in turn called by the autofs to assess the >> > > > > > > length of >> > > > > > > the non-existing path. >> > > > > > > >> > > > > > > To solve it, modify the "validate_dev_ioctl" function to check >> > > > > > > also that >> > > > > > > a path has been provided if the command is >> > > > > > > AUTOFS_DEV_IOCTL_OPENMOUNT_CMD. >> > > > > > > >> > > > > > > >> > > > > > > --- b/fs/autofs/dev-ioctl.c2018-07-01 23:10:16.059728621 >> > > > > > > +0200around >> > > > > > > +++ a/fs/autofs/dev-ioctl.c2018-07-01 23:10:24.311792133 >> > > > > > > +0200 >> > > > > > > @@ -136,6 +136,9 @@ static int validate_dev_ioctl(int cmd, s >> > > > > > > goto out; >> > > > > > > } >> > > > > > > } >> > > > > > > +/* AUTOFS_DEV_IOCTL_OPENMOUNT_CMD without path */ >> > > > > > > +else if(_IOC_NR(cmd) == AUTOFS_DEV_IOCTL_OPENMOUNT_CMD) >> > > > > > > +return -EINVAL; >> > > > > > >> > > > > > My preference is to put the comment inside the else but ... >> > > > > > >> > > > > > There's another question, should the check be done in >> > > > > > autofs_dev_ioctl_openmount() in the same way it's checked in other >> > > > > > ioctls that need a path, such as in autofs_dev_ioctl_requester() >> > > > > > and autofs_dev_ioctl_ismountpoint()? >> > > > > > >> > > > > > For consistency I'd say it should. >> > > > > > >> > > > > > > >> > > > > > > err = 0;You should just put the "_IOC_NR" directive around >> > > > > > > "cmd" in >> > > > > > > the lines added to "validate_dev_ioctl" to make it work. >> > > > > > > out: >> > > > > > > >> > > > > > > >> > > > > > > Tested and solves the issue on Linus' main git tree. >> > > > > > > >> > > > > > > >> > > > > >> > > > > Or perhaps this (not even compile tested) patch would be better? >> > > > > >> > > > > autofs - fix slab out of bounds read in getname_kernel() >> > > > > >> > > > > From: Ian Kent >> > > > > >> > > > > The autofs subsystem does not check that the "path" parameter is >> > > > > present for all cases where it is required when it is passed in >> > > > > via the "param" struct. >> > > > > >> > > > > In particular it isn't checked for the AUTOFS_DEV_IOCTL_OPENMOUNT_CMD >> > > > > ioctl command. >> > > > > >> > > > > To solve it, modify validate_dev_ioctl() function to check that a >> > > > > path has been provided for ioctl commands that require it. >> >
Re: [PATCH 2/2] ARM: dts: imx51-babbage: Make use of pinctrl_usbh1reg
On Wed, Jun 27, 2018 at 09:37:13PM -0700, Andrey Smirnov wrote: > Pinctrl_usbh1reg defines pinmux setting for reset GPIO used by > usbh1phy, but is not referenced by that node. Fix that. > > Cc: Fabio Estevam > Cc: Shawn Guo > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Andrey Smirnov Applied, thanks.
Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009
Hi,
Just gently ping.
May this patch be reviewed and merged?
Thanks,
Jian-Hong Pan
2018-05-25 17:54 GMT+08:00 Jian-Hong Pan :
> Without this patch we cannot turn on the Bluethooth adapter on HP
> 14-bs007la.
>
> T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0bda ProdID=b009 Rev= 2.00
> S: Manufacturer=Realtek
> S: Product=802.11n WLAN Adapter
> S: SerialNumber=00e04c01
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> Signed-off-by: Jian-Hong Pan
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3a477b6b3ce6..d93b25faeed9 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -374,6 +374,7 @@ static const struct usb_device_id blacklist_table[] = {
> { USB_DEVICE(0x7392, 0xa611), .driver_info = BTUSB_REALTEK },
>
> /* Additional Realtek 8723DE Bluetooth devices */
> + { USB_DEVICE(0x0bda, 0xb009), .driver_info = BTUSB_REALTEK },
> { USB_DEVICE(0x2ff8, 0xb011), .driver_info = BTUSB_REALTEK },
>
> /* Additional Realtek 8821AE Bluetooth devices */
> --
> 2.11.0
>
Re: [PATCH v8 00/26] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM)
Rafael, On 20 June 2018 at 19:22, Ulf Hansson wrote: > Changes in v8: > - Added some tags for reviews and acks. > - Cleanup timer patch (patch6) according to comments from Rafael. > - Rebased series on top of v4.18rc1 - it applied cleanly, except for patch 5. > - While adopting patch 5 to new genpd changes, I took the opportunity to >improve the new function description a bit. > - Corrected malformed SPDX-License-Identifier in patch20. There have only been a minor comment from you at patch3 (about squashing it with patch21), with that fixed and assuming there are no further comments - would you like me to collect the changes and send it to you as a pull request? [...] Kind regards Uffe
[PATCH] tg: show the sum wait time of an task group
Although we can rely on cpuacct to present the cpu usage of task
group, it is hard to tell how intense the competition is between
these groups on cpu resources.
Monitoring the wait time of each process or sched_debug could cost
too much, and there is no good way to accurately represent the
conflict with these info, we need the wait time on group dimension.
Thus we introduced group's wait_sum represent the conflict between
task groups, which is simply sum the wait time of group's cfs_rq.
The 'cpu.stat' is modified to show the statistic, like:
nr_periods 0
nr_throttled 0
throttled_time 0
wait_sum 2035098795584
Now we can monitor the changing on wait_sum to tell how suffering
a task group is in the fight of cpu resources.
For example:
(wait_sum - last_wait_sum) * 100 / (nr_cpu * period_ns) == X%
means the task group paid X percentage of period on waiting
for the cpu.
Signed-off-by: Michael Wang
---
Since RFC:
redesigned the way to acquire wait_sum
kernel/sched/core.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78d8fac..cbff06b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6781,6 +6781,8 @@ static int __cfs_schedulable(struct task_group
*tg, u64 period, u64 quota)
static int cpu_cfs_stat_show(struct seq_file *sf, void *v)
{
+ int i;
+ u64 wait_sum = 0;
struct task_group *tg = css_tg(seq_css(sf));
struct cfs_bandwidth *cfs_b = &tg->cfs_bandwidth;
@@ -6788,6 +6790,12 @@ static int cpu_cfs_stat_show(struct seq_file *sf,
void *v)
seq_printf(sf, "nr_throttled %d\n", cfs_b->nr_throttled);
seq_printf(sf, "throttled_time %llu\n", cfs_b->throttled_time);
+ if (schedstat_enabled()) {
+ for_each_possible_cpu(i)
+ wait_sum += tg->se[i]->statistics.wait_sum;
+ seq_printf(sf, "wait_sum %llu\n", wait_sum);
+ }
+
return 0;
}
#endif /* CONFIG_CFS_BANDWIDTH */
--
1.8.3.1
Re: [GIT PULL] tee driver for v4.18
On Mon, Jul 2, 2018 at 7:18 PM, Olof Johansson wrote: > Hi Jens, > > > On Mon, Jul 2, 2018 at 5:10 AM, Jens Wiklander > wrote: >> Hello arm-soc maintainers, >> >> Please pull these small tee driver enhancements. There's a new config >> option for the OP-TEE driver, OPTEE_SHM_NUM_PRIV_PAGES. Also the OP-TEE >> driver reads current time with ktime_get_real_ts64() from now on. >> >> Thanks, >> Jens >> >> The following changes since commit 29dcea88779c856c7dc92040a0c01233263101d4: >> >> Linux 4.17 (2018-06-03 14:15:21 -0700) >> >> are available in the Git repository at: >> >> git://git.linaro.org/people/jens.wiklander/linux-tee.git >> tags/tee-drv-for-4.18 >> >> for you to fetch changes up to 3249527f19d660c5adfb2b6f4ffd4ca0506b8755: >> >> tee: optee: making OPTEE_SHM_NUM_PRIV_PAGES configurable via Kconfig >> (2018-06-20 11:20:36 +0200) >> >> >> Misc enhancement for tee driver subsystem >> >> * Replaces getnstimeofday64() with ktime_get_real_ts64() >> * Adds OPTEE_SHM_NUM_PRIV_PAGES to configure how many pages should be >> statically reserved for driver private allocations >> >> >> Arnd Bergmann (1): >> tee: replace getnstimeofday64() with ktime_get_real_ts64() >> >> Sahil Malhotra (1): >> tee: optee: making OPTEE_SHM_NUM_PRIV_PAGES configurable via Kconfig > > This doesn't seem to be bugfixes (and not regression fixes in > particular), so I took the liberty of queuing these for 4.19 (in > next/drivers) instead of fixes for v4.18. > > Let me know if this was an inaccurate assessment and I can move them over. I'm sorry, my mistake. I meant 4.19, you did the right thing. Thanks for reading my mind correctly! :-) /Jens
Re: [PATCH v1] ARM: dts: imx6sl-evk: keep sw4 always on
On Mon, Jul 02, 2018 at 02:12:52AM +, Robin Gong wrote: > But in fact, the original dts is not correct without 'regulator-always- > on'since SW4 is the critical DDR power rail, although, it's kept on in > the previous kernel by no switches enable/disable interfaces provided > in pfuze driver. Adding new property which can be done totally by the > common 'regulator-always-on' is not a good choice. Keep the dts patch > adding 'regulator-always-on' ahead of pfuze driver pach adding > enable/disable interface is enough for such case I think. We can not just break the installed DTBs like this. If patching regulator driver with a new property is really difficult, we could migrate the existing users in a 'soft' way: - Add required regulator-always-on for regulator nodes in DTS. - Patch i.MX platform code to check the presence of regulator-always-on property for critical regulators, and give a big warning if it's missing. - Wait for a couple of release cycles for users to migrate. - Add regulator driver patch back and break users who keep ignoring the warning. Shawn
[PATCH] fat: Add FITRIM ioctl for FAT file system
From: Wentao Wang
Add FITRIM ioctl for FAT file system
[hirof...@mail.parknet.co.jp: bug fixes, coding style fixes, add signal check]
Signed-off-by: Wentao Wang
Signed-off-by: OGAWA Hirofumi
---
fs/fat/fat.h|1
fs/fat/fatent.c | 102 +++
fs/fat/file.c | 33 +
3 files changed, 136 insertions(+)
diff -puN fs/fat/fat.h~fat-fitrim fs/fat/fat.h
--- linux/fs/fat/fat.h~fat-fitrim 2018-06-04 13:55:42.328356395 +0900
+++ linux-hirofumi/fs/fat/fat.h 2018-06-04 13:55:42.331356390 +0900
@@ -357,6 +357,7 @@ extern int fat_alloc_clusters(struct ino
int nr_cluster);
extern int fat_free_clusters(struct inode *inode, int cluster);
extern int fat_count_free_clusters(struct super_block *sb);
+extern int fat_trim_fs(struct inode *inode, struct fstrim_range *range);
/* fat/file.c */
extern long fat_generic_ioctl(struct file *filp, unsigned int cmd,
diff -puN fs/fat/fatent.c~fat-fitrim fs/fat/fatent.c
--- linux/fs/fat/fatent.c~fat-fitrim2018-06-04 13:55:42.329356393 +0900
+++ linux-hirofumi/fs/fat/fatent.c 2018-06-04 14:00:18.550894746 +0900
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "fat.h"
struct fatent_operations {
@@ -690,3 +691,104 @@ out:
unlock_fat(sbi);
return err;
}
+
+static int fat_trim_clusters(struct super_block *sb, u32 clus, u32 nr_clus)
+{
+ struct msdos_sb_info *sbi = MSDOS_SB(sb);
+ return sb_issue_discard(sb, fat_clus_to_blknr(sbi, clus),
+ nr_clus * sbi->sec_per_clus, GFP_NOFS, 0);
+}
+
+int fat_trim_fs(struct inode *inode, struct fstrim_range *range)
+{
+ struct super_block *sb = inode->i_sb;
+ struct msdos_sb_info *sbi = MSDOS_SB(sb);
+ const struct fatent_operations *ops = sbi->fatent_ops;
+ struct fat_entry fatent;
+ u64 ent_start, ent_end, minlen;
+ u32 free = 0, trimmed = 0;
+ unsigned long reada_blocks, reada_mask, cur_block = 0;
+ int err = 0;
+
+ /*
+* FAT data is organized as clusters, trim at the granulary of cluster.
+*
+* fstrim_range is in byte, convert vaules to cluster index.
+* Treat sectors before data region as all used, not to trim them.
+*/
+ ent_start = max_t(u64, range->start>>sbi->cluster_bits, FAT_START_ENT);
+ ent_end = ent_start + (range->len >> sbi->cluster_bits) - 1;
+ minlen = range->minlen >> sbi->cluster_bits;
+
+ if (ent_start >= sbi->max_cluster || range->len < sbi->cluster_size)
+ return -EINVAL;
+ if (ent_end >= sbi->max_cluster)
+ ent_end = sbi->max_cluster - 1;
+
+ reada_blocks = FAT_READA_SIZE >> sb->s_blocksize_bits;
+ reada_mask = reada_blocks - 1;
+
+ fatent_init(&fatent);
+ lock_fat(sbi);
+ fatent_set_entry(&fatent, ent_start);
+ while (fatent.entry <= ent_end) {
+ /* readahead of fat blocks */
+ if ((cur_block & reada_mask) == 0) {
+ unsigned long rest = sbi->fat_length - cur_block;
+ fat_ent_reada(sb, &fatent, min(reada_blocks, rest));
+ }
+ cur_block++;
+
+ err = fat_ent_read_block(sb, &fatent);
+ if (err)
+ goto error;
+ do {
+ if (ops->ent_get(&fatent) == FAT_ENT_FREE) {
+ free++;
+ } else if (free) {
+ if (free >= minlen) {
+ u32 clus = fatent.entry - free;
+
+ err = fat_trim_clusters(sb, clus, free);
+ if (err && err != -EOPNOTSUPP)
+ goto error;
+ if (!err)
+ trimmed += free;
+ err = 0;
+ }
+ free = 0;
+ }
+ } while (fat_ent_next(sbi, &fatent) && fatent.entry <= ent_end);
+
+ if (fatal_signal_pending(current)) {
+ err = -ERESTARTSYS;
+ goto error;
+ }
+
+ if (need_resched()) {
+ fatent_brelse(&fatent);
+ unlock_fat(sbi);
+ cond_resched();
+ lock_fat(sbi);
+ }
+ }
+ /* handle scenario when tail entries are all free */
+ if (free && free >= minlen) {
+ u32 clus = fatent.entry - free;
+
+ err = fat_trim_clusters(sb, clus, free);
+ if (err && err != -EOPNOTSUPP)
+ goto error;
+ if (!err)
+ trimmed += free;
+ err = 0;
+
Re: [PATCH V2] mmc: core: cd_label must be last entry of mmc_gpio struct
On 3 July 2018 at 04:25, Fabio Estevam wrote:
> On Mon, Jul 2, 2018 at 11:13 PM, Anson Huang wrote:
>
>> I think either way is OK, since flexible array is used in kernel code quite
>> commonly,
>> so I prefer to make code change as small as possible, the original patch can
>> also prevent
>> similar bug in future. And like below commit Fabio pointed out, it also has
>> same kind
>> of fix: a158531f3c92 ("gpio: 74x164: Fix crash during .remove()"). Thanks.
>
> I am also fine with this patch or the one from Linus.
>
> Maybe Anson's patch could be applied to 4.18-rc as a bug fix and
> Linus' patch could be applied to 4.19-rc1 as a cleanup/improvement?
Good idea!
I have queued up Anson's v2 patch as a fix for 4.18.
Linus, can please re-post a re-based version of your change on top!? I
guess you can add Anson's and Fabio's reviewed by tags for it as well.
Kind regards
Uffe
Re: [PATCH -mm -v4 08/21] mm, THP, swap: Support to read a huge swap cluster for swapin a THP
Matthew Wilcox writes:
> On Fri, Jun 22, 2018 at 11:51:38AM +0800, Huang, Ying wrote:
>> +++ b/mm/swap_state.c
>> @@ -426,33 +447,37 @@ struct page *__read_swap_cache_async(swp_entry_t
>> entry, gfp_t gfp_mask,
>> /*
>> * call radix_tree_preload() while we can wait.
>> */
>> -err = radix_tree_maybe_preload(gfp_mask & GFP_KERNEL);
>> +err = radix_tree_maybe_preload_order(gfp_mask & GFP_KERNEL,
>> + compound_order(new_page));
>> if (err)
>> break;
>
> There's no more preloading in the XArray world, so this can just be dropped.
Sure.
>> /*
>> * Swap entry may have been freed since our caller observed it.
>> */
>> +err = swapcache_prepare(hentry, huge_cluster);
>> +if (err) {
>> radix_tree_preload_end();
>> -break;
>> +if (err == -EEXIST) {
>> +/*
>> + * We might race against get_swap_page() and
>> + * stumble across a SWAP_HAS_CACHE swap_map
>> + * entry whose page has not been brought into
>> + * the swapcache yet.
>> + */
>> +cond_resched();
>> +continue;
>> +} else if (err == -ENOTDIR) {
>> +/* huge swap cluster is split under us */
>> +continue;
>> +} else /* swp entry is obsolete ? */
>> +break;
>
> I'm not entirely happy about -ENOTDIR being overloaded to mean this.
> Maybe we can return a new enum rather than an errno?
Can we use -ESTALE instead? The "huge swap cluster is split under us"
means the swap entry is kind of "staled".
> Also, I'm not sure that a true/false parameter is the right approach for
> "is this a huge page". I think we'll have usecases for swap entries which
> are both larger and smaller than PMD_SIZE.
OK. I can change the interface to number of swap entries style to make
it more flexible.
> I was hoping to encode the swap entry size into the entry; we only need one
> extra bit to do that (no matter the size of the entry). I detailed the
> encoding scheme here:
>
> https://plus.google.com/117536210417097546339/posts/hvctn17WUZu
>
> (let me know if that doesn't work for you; I'm not very experienced with
> this G+ thing)
The encoding method looks good. To use it, we need to
- Encode swap entry and size into swap_entry_size
- Call function with swap_entry_size
- Decode swap_entry_size to swap entry and size
It appears that there is no real benefit?
Best Regards,
Huang, Ying
[PATCH] cpuidle:powernv: Add the CPUIDLE_FLAG_POLLING for snooze
From: "Gautham R. Shenoy"
In the situations where snooze is the only cpuidle state due to
firmware not exposing any platform idle states, the idle CPUs will
remain in snooze for a long time with interrupts disabled causing the
Hard-lockup detector to complain.
watchdog: CPU 51 detected hard LOCKUP on other CPUs 59
watchdog: CPU 51 TB:535296107736, last SMP heartbeat TB:527472229239 (15281ms
ago)
watchdog: CPU 59 Hard LOCKUP
watchdog: CPU 59 TB:535296252849, last heartbeat TB:526554725466 (17073ms ago)
Fix this by adding CPUIDLE_FLAG_POLLING flag to the state, so that the
cpuidle governor will do the right thing, such as not stopping the
tick if it is going to put the idle cpu to snooze.
Reported-by: Akshay Adiga
Cc: Nicholas Piggin
Signed-off-by: Gautham R. Shenoy
---
drivers/cpuidle/cpuidle-powernv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index d29e4f0..b73041b 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -156,6 +156,7 @@ static int stop_loop(struct cpuidle_device *dev,
{ /* Snooze */
.name = "snooze",
.desc = "snooze",
+ .flags = CPUIDLE_FLAG_POLLING,
.exit_latency = 0,
.target_residency = 0,
.enter = snooze_loop },
--
1.9.4
Re: [PATCHi v2] mm: do not drop unused pages when userfaultd is running
On 07/02/2018 11:06 PM, Andrew Morton wrote:
> On Mon, 2 Jul 2018 09:50:49 +0200 Christian Borntraeger
> wrote:
>
>> KVM guests on s390 can notify the host of unused pages. This can result
>> in pte_unused callbacks to be true for KVM guest memory.
>>
>> If a page is unused (checked with pte_unused) we might drop this page
>> instead of paging it. This can have side-effects on userfaultd, when the
>> page in question was already migrated:
>>
>> The next access of that page will trigger a fault and a user fault
>> instead of faulting in a new and empty zero page. As QEMU does not
>> expect a userfault on an already migrated page this migration will fail.
>>
>> The most straightforward solution is to ignore the pte_unused hint if a
>> userfault context is active for this VMA.
>>
>> ...
>>
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -64,6 +64,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -1481,7 +1482,7 @@ static bool try_to_unmap_one(struct page *page, struct
>> vm_area_struct *vma,
>> set_pte_at(mm, address, pvmw.pte, pteval);
>> }
>>
>> -} else if (pte_unused(pteval)) {
>> +} else if (pte_unused(pteval) && !userfaultfd_armed(vma)) {
>> /*
>> * The guest indicated that the page content is of no
>> * interest anymore. Simply discard the pte, vmscan
>
> A reader of this code will wonder why we're checking
> userfaultfd_armed(). So the writer of this code should add a comment
> which explains this to them ;) Please.
>
Something like:/*
* The guest indicated that the page content is of no
* interest anymore. Simply discard the pte, vmscan
* will take care of the rest.
* A future reference will then fault in a new zero
* page. When userfaultfd is active, we must not drop
* this page though, as its main user (postcopy
* migration) will not expect userfaults on already
* copied pages.
*/
?
Re: [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier
On Tue, 2018-07-03 at 12:39 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote:
> > On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds
> > wrote:
> > >
> > > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT
> > > USE UNDER ANY CIRCUMSTANCES. Think of it more as a "something like
> > > this might work, but probably doesn't". Maybe it gives you an idea,
> > > although that idea might be "Linus has finally lost it".
> >
> > Even if it were to work, it should probably just be done inside kernfs
> > and exposed as some kind of "kernfs_remove_if_empty()" function.
>
> That would be harder, we'd have to expose it via a
> kobject_del_if_empty() then.
>
> Since we control completely when things are added/removed from the
> gluedir and have a big fat mutex for it, I don't think locking is much
> of an issue. At least in that specific case.
Ok, kernfs was a tad tougher to crack than I hoped but here's a
prototype lightly tested.
Tejun, Greg, does it look reasonable to you ?
Cheers,
Ben.
diff --git a/drivers/base/core.c b/drivers/base/core.c
index b610816eb887..9166f68276c6 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1570,6 +1570,8 @@ static void cleanup_glue_dir(struct device *dev, struct
kobject *glue_dir)
return;
mutex_lock(&gdp_mutex);
+ if (!kobject_has_children(glue_dir))
+ kobject_del(glue_dir);
kobject_put(glue_dir);
mutex_unlock(&gdp_mutex);
}
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 89d1dc19340b..e4bec09bc602 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -1251,6 +1251,29 @@ void kernfs_activate(struct kernfs_node *kn)
mutex_unlock(&kernfs_mutex);
}
+bool kernfs_has_children(struct kernfs_node *kn)
+{
+ bool has_children = false;
+ struct kernfs_node *pos;
+
+ /* Lockless shortcut */
+ if (RB_EMPTY_NODE(&kn->rb))
+ return false;
+
+ /* Now check for active children */
+ mutex_lock(&kernfs_mutex);
+ pos = NULL;
+ while ((pos = kernfs_next_descendant_post(pos, kn)) && pos != kn) {
+ if (kernfs_active(pos)) {
+ has_children = true;
+ break;
+ }
+ }
+ mutex_unlock(&kernfs_mutex);
+
+ return has_children;
+}
+
static void __kernfs_remove(struct kernfs_node *kn)
{
struct kernfs_node *pos;
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index ab25c8b6d9e3..776350ac1cbc 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -300,6 +300,12 @@ static inline bool kernfs_ns_enabled(struct kernfs_node
*kn)
return kn->flags & KERNFS_NS;
}
+/**
+ * kernfs_has_children - Returns whether a kernfs node has children.
+ * @kn: the node to test
+ */
+bool kernfs_has_children(struct kernfs_node *kn);
+
int kernfs_name(struct kernfs_node *kn, char *buf, size_t buflen);
int kernfs_path_from_node(struct kernfs_node *root_kn, struct kernfs_node *kn,
char *buf, size_t buflen);
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 7f6f93c3df9c..1e3294ab95f0 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -116,6 +116,17 @@ extern void kobject_put(struct kobject *kobj);
extern const void *kobject_namespace(struct kobject *kobj);
extern char *kobject_get_path(struct kobject *kobj, gfp_t flag);
+/**
+ * kobject_has_children - Returns whether a kobject has children.
+ * @kobj: the object to test
+ */
+static inline bool kobject_has_children(struct kobject *kobj)
+{
+ WARN_ON_ONCE(kref_read(&kobj->kref) == 0);
+
+ return kobj->sd && kernfs_has_children(kobj->sd);
+}
+
struct kobj_type {
void (*release)(struct kobject *kobj);
const struct sysfs_ops *sysfs_ops;
[PATCH] staging: mt7621-pinctrl: Style fixes to pinctrl-rt2880
Replaces instances of "unsigned" with "unsigned int"; fixes comma and tab
spacing.
Signed-off-by: Peter Vernia
---
drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 35 +
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
index 0c3e498..6894510 100644
--- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
+++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
@@ -54,7 +54,7 @@ static int rt2880_get_group_count(struct pinctrl_dev
*pctrldev)
}
static const char *rt2880_get_group_name(struct pinctrl_dev *pctrldev,
-unsigned group)
+unsigned int group)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -65,9 +65,9 @@ static const char *rt2880_get_group_name(struct pinctrl_dev
*pctrldev,
}
static int rt2880_get_group_pins(struct pinctrl_dev *pctrldev,
-unsigned group,
-const unsigned **pins,
-unsigned *num_pins)
+unsigned int group,
+const unsigned int **pins,
+unsigned int *num_pins)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -81,7 +81,8 @@ static int rt2880_get_group_pins(struct pinctrl_dev *pctrldev,
}
static void rt2880_pinctrl_dt_free_map(struct pinctrl_dev *pctrldev,
- struct pinctrl_map *map, unsigned num_maps)
+ struct pinctrl_map *map,
+ unsigned int num_maps)
{
int i;
@@ -94,7 +95,7 @@ static void rt2880_pinctrl_dt_free_map(struct pinctrl_dev
*pctrldev,
static void rt2880_pinctrl_pin_dbg_show(struct pinctrl_dev *pctrldev,
struct seq_file *s,
- unsigned offset)
+ unsigned int offset)
{
seq_printf(s, "ralink pio");
}
@@ -103,7 +104,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
pinctrl_dev *pctrldev,
struct device_node *np,
struct pinctrl_map **map)
{
-const char *function;
+ const char *function;
int func = of_property_read_string(np, "ralink,function", &function);
int grps = of_property_count_strings(np, "ralink,group");
int i;
@@ -112,7 +113,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
pinctrl_dev *pctrldev,
return;
for (i = 0; i < grps; i++) {
- const char *group;
+ const char *group;
of_property_read_string_index(np, "ralink,group", i, &group);
@@ -127,7 +128,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
pinctrl_dev *pctrldev,
static int rt2880_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrldev,
struct device_node *np_config,
struct pinctrl_map **map,
- unsigned *num_maps)
+ unsigned int *num_maps)
{
int max_maps = 0;
struct pinctrl_map *tmp;
@@ -173,7 +174,7 @@ static int rt2880_pmx_func_count(struct pinctrl_dev
*pctrldev)
}
static const char *rt2880_pmx_func_name(struct pinctrl_dev *pctrldev,
-unsigned func)
+unsigned int func)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -181,7 +182,7 @@ static const char *rt2880_pmx_func_name(struct pinctrl_dev
*pctrldev,
}
static int rt2880_pmx_group_get_groups(struct pinctrl_dev *pctrldev,
- unsigned func,
+ unsigned int func,
const char * const **groups,
unsigned * const num_groups)
{
@@ -198,11 +199,11 @@ static int rt2880_pmx_group_get_groups(struct pinctrl_dev
*pctrldev,
}
static int rt2880_pmx_group_enable(struct pinctrl_dev *pctrldev,
- unsigned func,
- unsigned group)
+ unsigned int func,
+ unsigned int group)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
-u32 mode = 0;
+ u32 mode = 0;
u32 reg = SYSC_REG_GPIO_MODE;
int i;
int shift;
@@ -243,7 +244,7 @@ static int rt2880_pmx_group_enable(struct pinctrl_dev
*pctrldev,
static int rt2880_pmx_group_gpio_request_enable(struct pinctrl_dev *pctrldev,
struct pinctrl_gpio_range *range,
- unsigned pin)
+ unsigned int pin)
{
struc
linux-next: Tree for Jul 3
Hi all,
Changes since 20180702:
The net-next tree gained a build failure due to an interaction with Linus'
tree for which I applied a merge fix patch.
The akpm-current tree still had its build failure for which I reverted
a commit.
Non-merge commits (relative to Linus' tree): 3320
3593 files changed, 124822 insertions(+), 71456 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 282 trees (counting Linus' and 65 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (d0fbad0aec1d Merge branch 'for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (883c9ab9eb59 Merge branch 'parisc-4.18-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging arc-current/for-curr (3d561d86e99f ARC: Enable CONFIG_SWAP)
Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage)
Merging arm64-fixes/for-next/fixes (24fe1b0efad4 arm64: Remove unnecessary ISBs
from set_{pte,pmd,pud})
Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for
platform devices)
Merging powerpc-fixes/fixes (22db552b50fa powerpc/powermac: Fix rtc read/write
functions)
Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (e48e09799643 Merge branch 'qed-fixes')
Merging bpf/master (1236f22fbae1 tcp: prevent bogus FRTO undos with non-SACK
flows)
Merging ipsec/master (7284fdf39a91 esp6: fix memleak on error path in
esp6_input)
Merging netfilter/master (24ac3a08e658 net/smc: rebuild nonblocking connect)
Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits)
Merging wireless-drivers/master (4fa9433f950a Merge ath-current from
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git)
Merging mac80211/master (95bca62fb723 nl80211: check nla_parse_nested() return
values)
Merging rdma-fixes/for-rc (b697d7d8c741 IB/hfi1: Fix incorrect mixing of
ERR_PTR and NULL return values)
Merging sound-current/for-linus (aaa23f86001b ALSA: hda - Handle pm failure
during hotplug)
Merging sound-asoc-fixes/for-linus (0a4e7a01714d Merge branch 'asoc-4.18' into
asoc-linus)
Merging regmap-fixes/for-linus (7daf201d7fe8 Linux 4.18-rc2)
Merging regulator-fixes/for-linus (d7f72bec775d Merge branch 'regulator-4.18'
into regulator-linus)
Merging spi-fixes/for-linus (0928e2b9c66f Merge branch 'spi-4.18' into
spi-linus)
Merging pci-current/for-linus (83235822b8b4 nfp: stop limiting VFs to 0)
Merging driver-core.current/driver-core-linus (7daf201d7fe8 Linux 4.18-rc2)
Merging tty.current/tty-linus (021c91791a5e Linux 4.18-rc3)
Merging usb.current/usb-linus (b3a653288e1a i2c-cht-wc: Fix bq24190 supplier)
Merging usb-gadget-fixes/fixes (1d8e5c002758 dwc2: gadget: Fix ISOC IN DDMA PID
bitfield value calculation)
Merging usb-serial-fixes/usb-linus (021c91791a5e Linux 4.18-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (90f26cc6bb90 usb: chipidea: host:
fix
Re: [PATCH] thermal: ti-soc-thermal: remove dead code
On Monday 02 July 2018 10:00 PM, Eduardo Valentin wrote:
> Keerthy,
>
> On Fri, Jun 29, 2018 at 06:10:26PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Wednesday, May 02, 2018 03:20:35 PM Bartlomiej Zolnierkiewicz wrote:
>>> Majority of this code (i.e. functions from ti-bandgap.c) has been
>>> introduced in May 2013 by commit eb982001dbd8 ("thermal: introduce TI
>>> SoC thermal driver"). Just remove it altogether (in case it is needed
>>> it can be easily resurrected from git repo).
>>>
>>> While at it fix incorrect "not used" comments.
>>>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz
>>> ---
>>> drivers/thermal/ti-soc-thermal/dra752-bandgap.h | 68 ---
>>> drivers/thermal/ti-soc-thermal/dra752-thermal-data.c | 65 ---
>>> drivers/thermal/ti-soc-thermal/omap3-thermal-data.c |6
>>> drivers/thermal/ti-soc-thermal/omap4-thermal-data.c | 10
>>> drivers/thermal/ti-soc-thermal/omap4xxx-bandgap.h| 10
>>> drivers/thermal/ti-soc-thermal/omap5-thermal-data.c | 46 --
>>> drivers/thermal/ti-soc-thermal/omap5xxx-bandgap.h| 41 --
>>> drivers/thermal/ti-soc-thermal/ti-bandgap.c | 370
>>> ---
>>> drivers/thermal/ti-soc-thermal/ti-bandgap.h | 43 --
>>> 9 files changed, 5 insertions(+), 654 deletions(-)
>>
>> Gentle ping.
>>
>> It would be great to see this patch in v4.19.
>
> Any objections on this removal / cleanup?
Tested the patch on dra72-EVM.
cpufreq cooling works well.
Tested-by: Keerthy
Acked-by: Keerthy
Thanks for the clean up Bartalomiej!
>
Re: [PATCH] staging: mt7621-pinctrl: Replaces "unsigned" with "unsigned int", fixes mixed indentation, and puts spaces after commas.
> The subject is over 72 characters or whatever the limit is and there > isn't a commit message. Dan, thanks for your help, I realize where I went wrong now. I will re-submit the patch fresh to fix the message subject. --Peter
Re: Linux 3.18.111
On Mon, Jul 2, 2018 at 9:43 PM Seung-Woo Kim wrote:
>
> I think the commit itself is required. Simple, but not reliable,
> workaround fix is like below:
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index a34d401..7c751f2 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1879,6 +1879,8 @@ void d_instantiate_new(struct dentry *entry,
> struct inode *inode)
> BUG_ON(!hlist_unhashed(&entry->d_u.d_alias));
> BUG_ON(!inode);
> lockdep_annotate_inode_mutex_key(inode);
> + /* WORKAROUND for calling security_d_instantiate() */
> + entry->d_inode = inode;
> security_d_instantiate(entry, inode);
> spin_lock(&inode->i_lock);
> __d_instantiate(entry, inode);
Ugh. That looks horrible even if it might avoid the oops.
I think a much better solution is to back-port commit b296821a7c42
("xattr_handler: pass dentry and inode as separate arguments of
->get()") to older kernels. Then the inode is passed down all the way,
and you don't have people try to get it from the (not yet initialized)
dentry.
But there might be other parts missing too, and I didn't look at how
easy/painful that backport would be.
Al - comments? This is all because of commit 1e2e547a93a0 ("do
d_instantiate/unlock_new_inode combinations safely") being marked for
stable, and various cases of security_d_instantiate() calling down to
getxattr. Which used to not get the inode at all, so those older
kernels use d_inode(dentry), which doesn't work in this path since
dentry->d_inode hasn't been instantiated yet..
Linus
Re: [PATCH v7 0/4] ARM: davinci: complete the conversion to using the reset framework
On Monday 02 July 2018 08:57 PM, David Lechner wrote: > On 07/02/2018 07:08 AM, Sekhar Nori wrote: >> Hi Bjorn, >> >> On Thursday 21 June 2018 05:11 PM, Bartosz Golaszewski wrote: >>> 2018-06-21 12:52 GMT+02:00 Sekhar Nori : Hi Bartosz, On Thursday 21 June 2018 01:07 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > These are the remaining patches that still need to be merged in order > to complete the conversion of the davinci dsp driver to using the > reset > framework. > > They apply on top of v4.18-rc1 with David Lechner's remaining patches > merged. Series looks good to me. To preserve bisect, shouldn't the order of applying be patch #3, #4, #1 and #2 ? Given the dependencies and to preserve bisect its easiest if I take the series with acks from remoteproc and clock maintainers. Open to other suggestions as well. Thanks, Sekhar >>> >>> Oops you're right about the order. Do you want me to resend? >> >> With your ack, I can queue 1/4 for v4.19 and provide an immutable commit >> to you (on top of v4.18-rc1) for you to merge any further changes you >> want to queue from your tree. >> >> Bartosz, given the number of moving pieces, I think its better to keep >> 2/4 for v4.20 release - once all other other dependencies have been >> merged. > > I was thinking the same thing as well. I will pick it up in a > clk-davinci-4.20 branch if that sounds OK. Sounds good. Just check that there really are no users of that API before queuing :) Regards, Sekhar
Re: Linux 3.18.111
On 2018년 07월 03일 13:36, Greg KH wrote: > On Tue, Jul 03, 2018 at 12:24:59PM +0900, Seung-Woo Kim wrote: >> Hello, >> >> On 2018년 05월 30일 16:32, Greg KH wrote: >>> I'm announcing the release of the 3.18.111 kernel. >>> >>> All users of the 3.18 kernel series must upgrade. >>> >>> The updated 3.18.y git tree can be found at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git >>> linux-3.18.y >>> and can be browsed at the normal kernel.org git web browser: >>> >>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary >>> >>> thanks, >>> >>> greg k-h >>> >>> >> >> >> >>> do d_instantiate/unlock_new_inode combinations safely >> >> Recent my test in 3.18.113 kernel with security smack showed following >> crash during mkdir on ext4 fs. >> >> Unable to handle kernel paging request at virtual address ff98 >> pgd = ffc012411000 >> [ff98] *pgd=, *pud= >> [ cut here ] >> Kernel BUG at ffc0007d9430 [verbose debug info unavailable] >> Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP >> CPU: 0 MPIDR: 8000 PID: 1237 Comm: mkdir Not tainted >> 3.18.113-00083-g1bfc02f-dirty #29-Tizen >> task: ffc02cbc2340 ti: ffc02b7fc000 task.ti: ffc02b7fc000 >> PC is at down_read+0x24/0x54 >> LR is at down_read+0x24/0x54 >> [...] >> Call trace: >> [] down_read+0x24/0x54 >> [] ext4_xattr_get+0x74/0x1f4 >> [] ext4_xattr_security_get+0x28/0x38 >> [] generic_getxattr+0x4c/0x60 >> [] smk_fetch.isra.6+0x8c/0xe0 >> [] smack_d_instantiate+0x194/0x324 >> [] security_d_instantiate+0x24/0x30 >> [] d_instantiate_new+0x34/0x94 >> [] ext4_mkdir+0x284/0x354 >> [] vfs_mkdir+0xc0/0x150 >> [] SyS_mkdirat+0x88/0xb8 >> [] SyS_mkdir+0x18/0x20 >> Code: aa0003f3 b00017c0 912e1000 97e38943 (c85f7e60) >> ---[ end trace b1ad797d63dae9c5 ]--- >> >> It is because d_instantiate_new() added from above commit calls >> security_d_instantiate() before calling __d_instantiate() and >> dentry->d_inode is not yet set and null. In 3.18.113 kernel, >> inode->i_op_getxattr() of ext4 is still generic_getxattr() and it only >> has dentry parameter without inode, so it tries to access dentry->d_inode. >> >> I did not test with selinux, but selinux also calls >> inode->i_op_getxattr() from selinux_d_instantiate(), so maybe there is >> also same issue. > > So should I revert something or do you have a proposed fix for this? I think the commit itself is required. Simple, but not reliable, workaround fix is like below: diff --git a/fs/dcache.c b/fs/dcache.c index a34d401..7c751f2 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1879,6 +1879,8 @@ void d_instantiate_new(struct dentry *entry, struct inode *inode) BUG_ON(!hlist_unhashed(&entry->d_u.d_alias)); BUG_ON(!inode); lockdep_annotate_inode_mutex_key(inode); + /* WORKAROUND for calling security_d_instantiate() */ + entry->d_inode = inode; security_d_instantiate(entry, inode); spin_lock(&inode->i_lock); __d_instantiate(entry, inode); --- But I am not familiar with dentry/inode locking and there is no lock consideration at all. Thanks, - Seung-Woo Kim > > thanks, > > greg k-h > > > -- Seung-Woo Kim Samsung Research --
Re: [PATCH 2/2] fs: xfs: use BUG_ON if writepage call comes from direct reclaim
On Tue, Jul 03, 2018 at 12:11:19PM +0800, Yang Shi wrote:
> direct reclaim doesn't write out filesystem page, only kswapd could do
> this. So, if it is called from direct relaim, it is definitely a bug.
>
> And, Mel Gorman mentioned "Ultimately, this will be a BUG_ON." in commit
> 94054fa3fca1fd78db02cb3d68d5627120f0a1d4 ("xfs: warn if direct reclaim
> tries to writeback pages"),
>
> It has been many years since that commit, so it should be safe to
> elevate WARN_ON to BUG_ON now.
NACK.
The existing code warns and then handles the situation gracefully -
this is the appropriate way to handle incorrect calling contexts.
There is absolutely no good reason to panic production kernels
in situations like this.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
Re: Linux 3.18.111
On Tue, Jul 03, 2018 at 12:24:59PM +0900, Seung-Woo Kim wrote: > Hello, > > On 2018년 05월 30일 16:32, Greg KH wrote: > > I'm announcing the release of the 3.18.111 kernel. > > > > All users of the 3.18 kernel series must upgrade. > > > > The updated 3.18.y git tree can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > > linux-3.18.y > > and can be browsed at the normal kernel.org git web browser: > > > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary > > > > thanks, > > > > greg k-h > > > > > > > > > do d_instantiate/unlock_new_inode combinations safely > > Recent my test in 3.18.113 kernel with security smack showed following > crash during mkdir on ext4 fs. > > Unable to handle kernel paging request at virtual address ff98 > pgd = ffc012411000 > [ff98] *pgd=, *pud= > [ cut here ] > Kernel BUG at ffc0007d9430 [verbose debug info unavailable] > Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP > CPU: 0 MPIDR: 8000 PID: 1237 Comm: mkdir Not tainted > 3.18.113-00083-g1bfc02f-dirty #29-Tizen > task: ffc02cbc2340 ti: ffc02b7fc000 task.ti: ffc02b7fc000 > PC is at down_read+0x24/0x54 > LR is at down_read+0x24/0x54 > [...] > Call trace: > [] down_read+0x24/0x54 > [] ext4_xattr_get+0x74/0x1f4 > [] ext4_xattr_security_get+0x28/0x38 > [] generic_getxattr+0x4c/0x60 > [] smk_fetch.isra.6+0x8c/0xe0 > [] smack_d_instantiate+0x194/0x324 > [] security_d_instantiate+0x24/0x30 > [] d_instantiate_new+0x34/0x94 > [] ext4_mkdir+0x284/0x354 > [] vfs_mkdir+0xc0/0x150 > [] SyS_mkdirat+0x88/0xb8 > [] SyS_mkdir+0x18/0x20 > Code: aa0003f3 b00017c0 912e1000 97e38943 (c85f7e60) > ---[ end trace b1ad797d63dae9c5 ]--- > > It is because d_instantiate_new() added from above commit calls > security_d_instantiate() before calling __d_instantiate() and > dentry->d_inode is not yet set and null. In 3.18.113 kernel, > inode->i_op_getxattr() of ext4 is still generic_getxattr() and it only > has dentry parameter without inode, so it tries to access dentry->d_inode. > > I did not test with selinux, but selinux also calls > inode->i_op_getxattr() from selinux_d_instantiate(), so maybe there is > also same issue. So should I revert something or do you have a proposed fix for this? thanks, greg k-h
Re: [PATCH v2 5/6] mm: track gup pages with page->dma_pinned_* fields
On 07/02/2018 05:08 PM, Christopher Lameter wrote: > On Mon, 2 Jul 2018, John Hubbard wrote: > >>> >>> These two are just wrong. You cannot make any page reference for >>> PageDmaPinned() account against a pin count. First, it is just conceptually >>> wrong as these references need not be long term pins, second, you can >>> easily race like: >>> >>> Pinner Random process >>> get_page(page) >>> pin_page_for_dma() >>> put_page(page) >>> -> oops, page gets unpinned too early >>> >> >> I'll drop this approach, without mentioning any of the locking that is >> hiding in >> there, since that was probably breaking other rules anyway. :) Thanks for >> your >> patience in reviewing this. > > Mayb the following would work: > > If you establish a reference to a page then increase the page count. If > the reference is a dma pin action also then increase the pinned count. > > That way you know how many of the references to the page are dma > pins and you can correctly manage the state of the page if the dma pins go > away. > I think this sounds like what this patch already does, right? See: __put_page_for_pinned_dma(), __get_page_for_pinned_dma(), and pin_page_for_dma(). The locking seems correct to me, but I suspect it's too heavyweight for such a hot path. But without adding a new put_user_page() call, that was the best I could come up with. What I'm hearing now from Jan and Michal is that the desired end result is a separate API call, put_user_pages(), so that we can explicitly manage these pinned pages. thanks, -- John Hubbard NVIDIA
Re: printk() from NMI backtrace can delay a lot
Cc-ing Linus, Tejun, Andrew
[I'll keep the entire lockdep report]
On (07/02/18 19:26), Tetsuo Handa wrote:
[..]
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606834] swapper/0/0 is trying
> to acquire lock:
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606835] 316e1432
> (console_owner){-.-.}, at: console_unlock+0x1ce/0x8b0
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606840]
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606841] but task is already
> holding lock:
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606842] 9b45dcb4
> (&(&pool->lock)->rlock){-.-.}, at: show_workqueue_state+0x3b2/0x900
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606847]
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606848] which lock already
> depends on the new lock.
> ...
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606851] the existing
> dependency chain (in reverse order) is:
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606852]
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606852] -> #4
> (&(&pool->lock)->rlock){-.-.}:
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606857]
> _raw_spin_lock+0x2a/0x40
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606858]
> __queue_work+0xfb/0x780
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606859]
> queue_work_on+0xde/0x110
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606861]
> put_pwq+0x85/0x90
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606862]
> put_pwq_unlocked.part.29+0x1d/0x30
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606863]
> destroy_workqueue+0x2df/0x320
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606865]
> tipc_topsrv_stop+0x1a0/0x290
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606866]
> tipc_exit_net+0x15/0x40
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606867]
> ops_exit_list.isra.8+0x4e/0x90
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606869]
> cleanup_net+0x219/0x390
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606870]
> process_one_work+0x2ec/0x800
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606871]
> worker_thread+0x45/0x4d0
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606872]
> kthread+0x14c/0x170
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606874]
> ret_from_fork+0x3a/0x50
I assume this one is
pwq->pool->lock -> last_pool->lock ?
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606874]
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606875] -> #3
> (&pool->lock/1){-.-.}:
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606880]
> _raw_spin_lock+0x2a/0x40
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606881]
> __queue_work+0xfb/0x780
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606882]
> queue_work_on+0xde/0x110
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606884]
> tty_flip_buffer_push+0x2f/0x40
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606885]
> pty_write+0xb0/0xc0
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606886]
> n_tty_write+0x244/0x620
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606887]
> tty_write+0x1e3/0x3f0
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606888]
> __vfs_write+0x54/0x270
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606890]
> vfs_write+0xf0/0x230
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606891]
> redirected_tty_write+0x61/0xb0
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606892]
> do_iter_write+0x1ce/0x220
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606893]
> vfs_writev+0xb0/0x140
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606895]
> do_writev+0x6d/0x120
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606896]
> __x64_sys_writev+0x20/0x30
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606897]
> do_syscall_64+0x81/0x260
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606899]
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
So #3 is
tty_port->lock -> WQ pool->lock
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606900] -> #2
> (&(&port->lock)->rlock){-.-.}:
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606905]
> _raw_spin_lock_irqsave+0x56/0x70
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606906]
> tty_port_tty_get+0x20/0x60
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606907]
> tty_port_default_wakeup+0x15/0x40
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606909]
> tty_port_tty_wakeup+0x20/0x30
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606910]
> uart_write_wakeup+0x26/0x40
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606911]
> serial8250_tx_chars+0x1ae/0x2d0
> 2018-07-02 12:13:13 192.168.159.129: [ 151.606913]
> serial8250_handle_irq.part.23+0x108/0x130
> 2018-07-02 12:13:13 192.168.15
RE: [[LINUX PATCH v10] 4/4] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi Linus, > -Original Message- > From: Linus Walleij [mailto:linus.wall...@linaro.org] > Sent: Monday, July 2, 2018 7:18 PM > To: Naga Sureshkumar Relli > Cc: Boris Brezillon ; Richard Weinberger > ; > David Woodhouse ; Brian Norris > ; Mark Vasut ; Florian > Fainelli > ; Markus Mayer ; Roger Quadros > ; Ladislav Michl ; a...@thorsis.com; > honghui.zh...@mediatek.com; Miquèl Raynal ; linux- > m...@lists.infradead.org; linux-kernel@vger.kernel.org; > nagasureshkumarre...@gmail.com; > Michal Simek > Subject: Re: [[LINUX PATCH v10] 4/4] mtd: rawnand: pl353: Add basic driver > for arm > pl353 smc nand interface > > On Fri, Jun 29, 2018 at 6:15 AM Naga Sureshkumar Relli > wrote: > > > On Thu, Jun 28, 2018 at 2:13 PM Naga Sureshkumar Relli > > > > wrote: > > > > > > > > > > > This driver has the same problem as the other patches: > > > > > use the ARM_AMBA primecell magic numbers detection, and the PrimeCell > > > > > bus. > > > > > > > > Here the child is NAND controller and the parent is PL353 SMC, so > > > > do we need to update this also as AMBA driver? > > > > > > No, sorry. The parent is spawning another device and you should > > > indeed use a platform device for that. > > > > > Ok, you mean platform driver model is sufficient for both pl353-smc.c and > > pl353_nand.c > drivers? > > Or AMBA model is for pl353-smc and platform driver model is for pl353-nand? > > The latter, AMBA primecell bus for pl353-smc and platform device for the nand > subdevice. > > Platform device is for anything that cannot be autodetected with e.g. > magic hardare numbers, and the first device can be autodetected as a prime > cell but not the > subdevice. Thanks for your inputs, I already started updating this. I will send v11. Thanks, Naga Sureshkumar Relli. > > Yours, > Linus Walleij
Re: [PATCH 12/15] arm: dts: highbank: Add missing OPP properties for CPUs
On 02-07-18, 16:27, Olof Johansson wrote: > On Mon, Jul 02, 2018 at 02:25:40PM -0600, Rob Herring wrote: > > On Fri, May 25, 2018 at 4:32 AM Viresh Kumar > > wrote: > > > > > > The OPP properties, like "operating-points", should either be present > > > for all the CPUs of a cluster or none. If these are present only for a > > > subset of CPUs of a cluster then things will start falling apart as soon > > > as the CPUs are brought online in a different order. For example, this > > > will happen because the operating system looks for such properties in > > > the CPU node it is trying to bring up, so that it can create an OPP > > > table. > > > > > > Add such missing properties. > > > > > > Fix other missing property (clock latency) as well to make it all > > > work. > > > > > > Signed-off-by: Viresh Kumar > > > --- > > > arch/arm/boot/dts/highbank.dts | 30 ++ > > > 1 file changed, 30 insertions(+) > > > > Acked-by: Rob Herring > > > > ARM-SOC maintainers, Please apply this. > > Applied to next/dt. Thanks Olof. Can you also apply other patches in this series, that haven't been applied yet by SoC maintainers ? And same for the arm64 series.. -- viresh
[PATCH 1/2] fs: ext4: use BUG_ON if writepage call comes from direct reclaim
direct reclaim doesn't write out filesystem page, only kswapd could do
it. So, if the call comes from direct reclaim, it is definitely a bug.
And, Mel Gormane also mentioned "Ultimately, this will be a BUG_ON." In
commit 94054fa3fca1fd78db02cb3d68d5627120f0a1d4 ("xfs: warn if direct
reclaim tries to writeback pages").
Although it is for xfs, ext4 has the similar behavior, so elevate
WARN_ON to BUG_ON.
And, correct the comment accordingly.
Cc: Mel Gorman
Cc: "Theodore Ts'o"
Cc: Andreas Dilger
Signed-off-by: Yang Shi
---
fs/ext4/inode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 2ea07ef..089e388 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2071,7 +2071,7 @@ static int __ext4_journalled_writepage(struct page *page,
* This function can get called via...
* - ext4_writepages after taking page lock (have journal handle)
* - journal_submit_inode_data_buffers (no journal handle)
- * - shrink_page_list via the kswapd/direct reclaim (no journal handle)
+ * - shrink_page_list via the kswapd (no journal handle)
* - grab_page_cache when doing write_begin (have journal handle)
*
* We don't do any block allocation in this function. If we have page with
@@ -2148,10 +2148,10 @@ static int ext4_writepage(struct page *page,
(inode->i_sb->s_blocksize == PAGE_SIZE)) {
/*
* For memory cleaning there's no point in writing only
-* some buffers. So just bail out. Warn if we came here
-* from direct reclaim.
+* some buffers. So just bail out. It is a bug if we
+* came here from direct reclaim.
*/
- WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD))
+ BUG_ON((current->flags & (PF_MEMALLOC|PF_KSWAPD))
== PF_MEMALLOC);
unlock_page(page);
return 0;
--
1.8.3.1
[PATCH 2/2] fs: xfs: use BUG_ON if writepage call comes from direct reclaim
direct reclaim doesn't write out filesystem page, only kswapd could do
this. So, if it is called from direct relaim, it is definitely a bug.
And, Mel Gorman mentioned "Ultimately, this will be a BUG_ON." in commit
94054fa3fca1fd78db02cb3d68d5627120f0a1d4 ("xfs: warn if direct reclaim
tries to writeback pages"),
It has been many years since that commit, so it should be safe to
elevate WARN_ON to BUG_ON now.
Cc: Mel Gorman
Cc: Darrick J. Wong
Cc: Dave Chinner
Signed-off-by: Yang Shi
---
fs/xfs/xfs_aops.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 8eb3ba3..7efc2d2 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -1080,11 +1080,9 @@ static inline int xfs_bio_add_buffer(struct bio *bio,
struct buffer_head *bh)
* allow reclaim from kswapd as the stack usage there is relatively low.
*
* This should never happen except in the case of a VM regression so
-* warn about it.
+* BUG about it.
*/
- if (WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD)) ==
- PF_MEMALLOC))
- goto redirty;
+ BUG_ON((current->flags & (PF_MEMALLOC|PF_KSWAPD)) == PF_MEMALLOC);
/*
* Given that we do not allow direct reclaim to call us, we should
--
1.8.3.1
[rcu:dev 117/117] kernel//rcu/tree.c:2996:6: error: redefinition of 'call_rcu_sched'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev head: 3981406d6621b8a72a873bdc88d0a95d2e928c9e commit: 3981406d6621b8a72a873bdc88d0a95d2e928c9e [117/117] rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds config: x86_64-randconfig-x018-201826 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: git checkout 3981406d6621b8a72a873bdc88d0a95d2e928c9e # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): >> kernel//rcu/tree.c:2996:6: error: redefinition of 'call_rcu_sched' void call_rcu_sched(struct rcu_head *head, rcu_callback_t func) ^~ In file included from include/linux/rcupdate_wait.h:9:0, from kernel//rcu/tree.c:38: include/linux/rcupdate.h:53:18: note: previous definition of 'call_rcu_sched' was here #define call_rcu call_rcu_sched ^ >> kernel//rcu/tree.c:2983:6: note: in expansion of macro 'call_rcu' void call_rcu(struct rcu_head *head, rcu_callback_t func) ^~~~ vim +/call_rcu_sched +2996 kernel//rcu/tree.c 64db4cff kernel/rcutree.c Paul E. McKenney 2008-12-18 2950 a68a2bb2 kernel/rcu/tree.c Paul E. McKenney 2017-05-03 2951 /** 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2952 * call_rcu() - Queue an RCU callback for invocation after a grace period. a68a2bb2 kernel/rcu/tree.c Paul E. McKenney 2017-05-03 2953 * @head: structure to be used for queueing the RCU updates. a68a2bb2 kernel/rcu/tree.c Paul E. McKenney 2017-05-03 2954 * @func: actual callback function to be invoked after the grace period a68a2bb2 kernel/rcu/tree.c Paul E. McKenney 2017-05-03 2955 * a68a2bb2 kernel/rcu/tree.c Paul E. McKenney 2017-05-03 2956 * The callback function will be invoked some time after a full grace 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2957 * period elapses, in other words after all pre-existing RCU read-side 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2958 * critical sections have completed. However, the callback function 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2959 * might well execute concurrently with RCU read-side critical sections 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2960 * that started after call_rcu() was invoked. RCU read-side critical 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2961 * sections are delimited by rcu_read_lock() and rcu_read_unlock(), 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2962 * and may be nested. 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2963 * 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2964 * Note that all CPUs must agree that the grace period extended beyond 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2965 * all pre-existing RCU read-side critical section. On systems with more 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2966 * than one CPU, this means that when "func()" is invoked, each CPU is 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2967 * guaranteed to have executed a full memory barrier since the end of its 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2968 * last RCU read-side critical section whose beginning preceded the call 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2969 * to call_rcu(). It also means that each CPU executing an RCU read-side 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2970 * critical section that continues beyond the start of "func()" must have 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2971 * executed a memory barrier after the call_rcu() but before the beginning 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2972 * of that RCU read-side critical section. Note that these guarantees 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2973 * include CPUs that are offline, idle, or executing in user mode, as 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2974 * well as CPUs that are executing in the kernel. 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2975 * 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2976 * Furthermore, if CPU A invoked call_rcu() and CPU B invoked the 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2977 * resulting RCU callback function "func()", then both CPU A and CPU B are 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2978 * guaranteed to execute a full memory barrier during the time interval 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2979 * between the call to call_rcu() and the invocation of "func()" -- even 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2980 * if CPU A and CPU B are the same CPU (but again only if the system has 3981406d kernel/rcu/tree.c Paul E. McKenney 2018-07-02 2981 * more
[rcu:dev 117/117] include/linux/export.h:61:20: error: redefinition of '__kstrtab_call_rcu_sched'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev head: 3981406d6621b8a72a873bdc88d0a95d2e928c9e commit: 3981406d6621b8a72a873bdc88d0a95d2e928c9e [117/117] rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds config: x86_64-randconfig-x019-201826 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: git checkout 3981406d6621b8a72a873bdc88d0a95d2e928c9e # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): kernel//rcu/tree.c:2996:6: error: redefinition of 'call_rcu_sched' void call_rcu_sched(struct rcu_head *head, rcu_callback_t func) ^~ In file included from include/linux/rcupdate_wait.h:9:0, from kernel//rcu/tree.c:38: include/linux/rcupdate.h:53:18: note: previous definition of 'call_rcu_sched' was here #define call_rcu call_rcu_sched ^ kernel//rcu/tree.c:2983:6: note: in expansion of macro 'call_rcu' void call_rcu(struct rcu_head *head, rcu_callback_t func) ^~~~ In file included from include/linux/linkage.h:7:0, from include/linux/kernel.h:7, from kernel//rcu/tree.c:34: >> include/linux/export.h:61:20: error: redefinition of >> '__kstrtab_call_rcu_sched' static const char __kstrtab_##sym[]\ ^ include/linux/export.h:94:25: note: in expansion of macro '___EXPORT_SYMBOL' #define __EXPORT_SYMBOL ___EXPORT_SYMBOL ^~~~ include/linux/export.h:101:2: note: in expansion of macro '__EXPORT_SYMBOL' __EXPORT_SYMBOL(sym, "_gpl") ^~~ >> kernel//rcu/tree.c:3000:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL' EXPORT_SYMBOL_GPL(call_rcu_sched); ^ include/linux/export.h:61:20: note: previous definition of '__kstrtab_call_rcu_sched' was here static const char __kstrtab_##sym[]\ ^ include/linux/export.h:94:25: note: in expansion of macro '___EXPORT_SYMBOL' #define __EXPORT_SYMBOL ___EXPORT_SYMBOL ^~~~ include/linux/export.h:101:2: note: in expansion of macro '__EXPORT_SYMBOL' __EXPORT_SYMBOL(sym, "_gpl") ^~~ kernel//rcu/tree.c:2987:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL' EXPORT_SYMBOL_GPL(call_rcu); ^ include/linux/export.h:64:36: error: redefinition of '__ksymtab_call_rcu_sched' static const struct kernel_symbol __ksymtab_##sym \ ^ include/linux/export.h:94:25: note: in expansion of macro '___EXPORT_SYMBOL' #define __EXPORT_SYMBOL ___EXPORT_SYMBOL ^~~~ include/linux/export.h:101:2: note: in expansion of macro '__EXPORT_SYMBOL' __EXPORT_SYMBOL(sym, "_gpl") ^~~ >> kernel//rcu/tree.c:3000:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL' EXPORT_SYMBOL_GPL(call_rcu_sched); ^ include/linux/export.h:64:36: note: previous definition of '__ksymtab_call_rcu_sched' was here static const struct kernel_symbol __ksymtab_##sym \ ^ include/linux/export.h:94:25: note: in expansion of macro '___EXPORT_SYMBOL' #define __EXPORT_SYMBOL ___EXPORT_SYMBOL ^~~~ include/linux/export.h:101:2: note: in expansion of macro '__EXPORT_SYMBOL' __EXPORT_SYMBOL(sym, "_gpl") ^~~ kernel//rcu/tree.c:2987:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL' EXPORT_SYMBOL_GPL(call_rcu); ^ -- kernel/rcu/tree.c:2996:6: error: redefinition of 'call_rcu_sched' void call_rcu_sched(struct rcu_head *head, rcu_callback_t func) ^~ In file included from include/linux/rcupdate_wait.h:9:0, from kernel/rcu/tree.c:38: include/linux/rcupdate.h:53:18: note: previous definition of 'call_rcu_sched' was here #define call_rcu call_rcu_sched ^ kernel/rcu/tree.c:2983:6: note: in expansion of macro 'call_rcu' void call_rcu(struct rcu_head *head, rcu_callback_t func) ^~~~ In file included from include/linux/linkage.h:7:0, from include/linux/kernel.h:7, from kernel/rcu/tree.c:34: >> include/linux/export.h:61:20: error: redefinition of >> '__kstrtab_call_rcu_sched' static const char __kstrtab_##sym[]\ ^ include/linux/export.h:94:25: note: in expansion of macro '___EXPORT_SYMBOL' #define __EXPORT_SYMBOL ___EXPORT_SYMBOL ^~~~ include/linux/export.h:101:2: note: in expansion of macro '__EXPORT_SYMBOL' __EXPORT_SYMBOL(sym, "_gpl") ^~~ kernel/rcu/tree.c:3000:1: note: in expansion of macro 'EX
Re: WARN_ON_ONCE() in process_one_work()?
On Mon, Jul 02, 2018 at 02:05:40PM -0700, Tejun Heo wrote:
> Hello, Paul.
>
> Sorry about the late reply.
>
> On Wed, Jun 20, 2018 at 12:29:01PM -0700, Paul E. McKenney wrote:
> > I have hit this WARN_ON_ONCE() in process_one_work:
> >
> > WARN_ON_ONCE(!(pool->flags & POOL_DISASSOCIATED) &&
> > raw_smp_processor_id() != pool->cpu);
> >
> > This looks like it is my rcu_gp workqueue (see splat below), and it
> > appears to be intermittent. This happens on rcutorture scenario SRCU-N,
> > which does random CPU-hotplug operations (in case that helps).
> >
> > Is this related to the recent addition of WQ_MEM_RECLAIM? Either way,
> > what should I do to further debug this?
>
> Hmm... I checked the code paths but couldn't spot anything suspicious.
> Can you please apply the following patch and see whether it triggers
> before hitting the warn and if so report what it says?
I will apply this, but be advised that I have not seen that WARN_ON_ONCE()
trigger since. :-/
Thanx, Paul
> Thanks.
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 0db8938fbb23..81caab9643b2 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -79,6 +79,15 @@ static struct lockdep_map cpuhp_state_up_map =
> static struct lockdep_map cpuhp_state_down_map =
> STATIC_LOCKDEP_MAP_INIT("cpuhp_state-down", &cpuhp_state_down_map);
>
> +int cpuhp_current_state(int cpu)
> +{
> + return per_cpu_ptr(&cpuhp_state, cpu)->state;
> +}
> +
> +int cpuhp_target_state(int cpu)
> +{
> + return per_cpu_ptr(&cpuhp_state, cpu)->target;
> +}
>
> static inline void cpuhp_lock_acquire(bool bringup)
> {
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 78b192071ef7..365cf6342808 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1712,6 +1712,9 @@ static struct worker *alloc_worker(int node)
> return worker;
> }
>
> +int cpuhp_current_state(int cpu);
> +int cpuhp_target_state(int cpu);
> +
> /**
> * worker_attach_to_pool() - attach a worker to a pool
> * @worker: worker to be attached
> @@ -1724,13 +1727,20 @@ static struct worker *alloc_worker(int node)
> static void worker_attach_to_pool(struct worker *worker,
> struct worker_pool *pool)
> {
> + int ret;
> +
> mutex_lock(&wq_pool_attach_mutex);
>
> /*
>* set_cpus_allowed_ptr() will fail if the cpumask doesn't have any
>* online CPUs. It'll be re-applied when any of the CPUs come up.
>*/
> - set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask);
> + ret = set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask);
> + if (ret && pool->cpu >= 0 && worker->rescue_wq)
> + printk("XXX rescuer failed to attach: ret=%d pool=%d
> this_cpu=%d target_cpu=%d cpuhp_state=%d chuhp_target=%d\n",
> +ret, pool->id, raw_smp_processor_id(), pool->cpu,
> +cpuhp_current_state(pool->cpu),
> +cpuhp_target_state(pool->cpu));
>
> /*
>* The wq_pool_attach_mutex ensures %POOL_DISASSOCIATED remains
>
Re: [PATCH V2 01/19] csky: Build infrastructure
On Sun, Jul 1, 2018 at 11:36 AM Guo Ren wrote: > > Signed-off-by: Guo Ren > --- [...] > +config CSKY_BUILTIN_DTB > + bool "Use kernel builtin dtb" > + > +config CSKY_BUILTIN_DTB_NAME > + string "kernel builtin dtb name" > + depends on CSKY_BUILTIN_DTB > +endmenu These options generally exist for backwards compatibility with legacy bootloaders that don't support DT which shouldn't apply here given this is a new arch. If we need this for other reasons, it should not be an architecture specific option. Rob
Re: [PATCH v4 00/15] Update for QCOM NAND driver
On 2018-07-01 23:39, Miquel Raynal wrote: Hi Abhishek, Abhishek Sahu wrote on Wed, 20 Jun 2018 12:57:27 +0530: * v4: 1. Added patch to make other ECC configurations function static. 2. Clubbed the DT update patches. 3. Removed the bad block related patch. Discussion is going on related with for proper solution so planning to submit separate patch series for all bad block related changes. 4. Made the single codeword raw read function and used the same for raw page read. 5. Changes in erased codeword detection to raw read function. * v3: 1. Addressed all review comments in v2. 2. Added patch for removing redundant nand-ecc-step-size DT property. 3. Renamed ECC configuration setup function with minor code changes. 4. Modified comments and commit message for few patches. * v2: 1. Addressed all review comments in v1. 1. Make the generic helper function for NAND ECC parameters setup and used this helper function for QCOM and Denali nand driver for ECC setup. 2. Modified commit message for some of the patches and added more comments. 3. Added new patch for fixing ‘return 0’ for raw read. 4. Removed the read last codeword part for nand oob write. 5. Reorganized bad block check function and removed the read_last_cw function completely. * v1: This patch series mainly deals with error handling and erased page bitflip detection for QCOM NAND driver. 1. The error handling was missing for some of the cases so fixed the same. 2. Add the support for taking ECC strength from ONFI parameter. The earlier QCOM boards were coming with 4-bit ECC chip but now the same boards are coming with 8-bit ECC chip since the earlier 4-bit parts are obsolete from some vendors. 3. We got few issues related with NAND erased page bitflips. The QCOM NAND controller can’t detect the bitflip in completely erased page so added the support to detect the same. It implemented the logic mentioned in patch [1] which didn’t go in mainline and later the generic functions were provided [2] to count the number of bitflips and make all 0xff. This patch series did some optimization logic to prevent the unnecessary full page raw read and data copy from QCOM NAND controller to DMA. 4. Following are the testing done for these patches in QCOM IPQ8074 HK01 (4-bit and 8-bit ECC chip) and IPQ806x AP148 boards. a. Run all mtd test and check if it passes b. Introduce custom bitflips in erased page and check if it returns no error/EUCLEAN/EBADMSG depending upon number of bitflips and position. c. Introduce failure condition for operational failure and check if it detects the same. [1]: https://patchwork.ozlabs.org/patch/328994/ [2]: https://patchwork.ozlabs.org/patch/509970/ Abhishek Sahu (15): mtd: rawnand: helper function for setting up ECC configuration mtd: rawnand: denali: use helper function for ecc setup dt-bindings: qcom_nandc: update for ECC strength and step size mtd: rawnand: qcom: remove dt property nand-ecc-step-size mtd: rawnand: qcom: use the ecc strength from device parameter mtd: rawnand: qcom: wait for desc completion in all BAM channels mtd: rawnand: qcom: erased page detection for uncorrectable errors only mtd: rawnand: qcom: fix null pointer access for erased page detection mtd: rawnand: qcom: parse read errors for read oob also mtd: rawnand: qcom: modify write_oob to remove read codeword part mtd: rawnand: qcom: fix return value for raw page read mtd: rawnand: qcom: check for operation errors in case of raw read mtd: rawnand: qcom: code reorganization for raw read mtd: rawnand: qcom: erased page bitflips detection mtd: rawnand: provide only single helper function for ECC conf .../devicetree/bindings/mtd/qcom_nandc.txt | 7 +- drivers/mtd/nand/raw/denali.c | 30 +- drivers/mtd/nand/raw/nand_base.c | 72 ++- drivers/mtd/nand/raw/qcom_nandc.c | 491 ++--- include/linux/mtd/rawnand.h| 10 +- 5 files changed, 380 insertions(+), 230 deletions(-) Thank you very much for the series and the changes you have done. Thanks a lot Miquel for your great support and help in reviewing and merging these patches :-) Applied all patches but "erased page bitflips detection" because I'm waiting for one small modification on this one. Sure. I will send that updated patch. Regards, Abhishek
[rcu:dev 117/117] ERROR: ".rcu_note_context_switch" [arch/powerpc/kvm/kvm.ko] undefined!
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev head: 673d4e1483611783d502fe63317483b294f1bba0 commit: 673d4e1483611783d502fe63317483b294f1bba0 [117/117] rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds config: powerpc-defconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 673d4e1483611783d502fe63317483b294f1bba0 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=powerpc All errors (new ones prefixed by >>): >> ERROR: ".rcu_note_context_switch" [arch/powerpc/kvm/kvm.ko] undefined! >> ERROR: ".rcu_note_context_switch" [arch/powerpc/kvm/kvm-hv.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH V2 19/19] irqchip: add C-SKY irqchip drivers
On Sun, Jul 1, 2018 at 11:35 AM Guo Ren wrote: > Commit message needed. > Signed-off-by: Guo Ren > --- > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-csky-v1.c | 126 > drivers/irqchip/irq-csky-v2.c | 191 > + > drivers/irqchip/irq-nationalchip.c | 131 + > 4 files changed, 449 insertions(+) > create mode 100644 drivers/irqchip/irq-csky-v1.c > create mode 100644 drivers/irqchip/irq-csky-v2.c > create mode 100644 drivers/irqchip/irq-nationalchip.c > > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile > index d27e3e3..51e7316 100644 > --- a/drivers/irqchip/Makefile > +++ b/drivers/irqchip/Makefile > @@ -85,3 +85,4 @@ obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += > irq-uniphier-aidet.o > obj-$(CONFIG_ARCH_SYNQUACER) += irq-sni-exiu.o > obj-$(CONFIG_MESON_IRQ_GPIO) += irq-meson-gpio.o > obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o > +obj-$(CONFIG_CSKY) += irq-csky-v1.o irq-csky-v2.o > irq-nationalchip.o > diff --git a/drivers/irqchip/irq-csky-v1.c b/drivers/irqchip/irq-csky-v1.c > new file mode 100644 > index 000..64ea564 > --- /dev/null > +++ b/drivers/irqchip/irq-csky-v1.c > @@ -0,0 +1,126 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd. > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#ifdef CONFIG_CSKY_VECIRQ_LEGENCY Do you mean "legacy"? It would be better to make this run-time so you can support multiple platforms in one build. You should be able to determine this from DT. > +#include > +#endif [...] > +IRQCHIP_DECLARE(csky_intc_v1, "csky,intc-v1", csky_intc_v1_init); DT bindings must be documented. And the vendor prefix must also be registered in vendor-prefixes.txt. [...] > +IRQCHIP_DECLARE(csky_intc_v2, "csky,intc-v2", csky_intc_v2_init); And this one. Use of v1, v2, etc. is generally discouraged unless there is some strict versioning behind it. Most bindings use implementation specific compatible strings (which typically means the SoC name/number as part of it). [...] > +IRQCHIP_DECLARE(nationalchip_intc_v1_ave, "nationalchip,intc-v1,ave", > intc_init); Here too. And your timers as well. You'll also need to do cpu bindings as well especially for SMP. Rob
Re: Linux 3.18.111
Hello, On 2018년 05월 30일 16:32, Greg KH wrote: > I'm announcing the release of the 3.18.111 kernel. > > All users of the 3.18 kernel series must upgrade. > > The updated 3.18.y git tree can be found at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > linux-3.18.y > and can be browsed at the normal kernel.org git web browser: > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary > > thanks, > > greg k-h > > > do d_instantiate/unlock_new_inode combinations safely Recent my test in 3.18.113 kernel with security smack showed following crash during mkdir on ext4 fs. Unable to handle kernel paging request at virtual address ff98 pgd = ffc012411000 [ff98] *pgd=, *pud= [ cut here ] Kernel BUG at ffc0007d9430 [verbose debug info unavailable] Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP CPU: 0 MPIDR: 8000 PID: 1237 Comm: mkdir Not tainted 3.18.113-00083-g1bfc02f-dirty #29-Tizen task: ffc02cbc2340 ti: ffc02b7fc000 task.ti: ffc02b7fc000 PC is at down_read+0x24/0x54 LR is at down_read+0x24/0x54 [...] Call trace: [] down_read+0x24/0x54 [] ext4_xattr_get+0x74/0x1f4 [] ext4_xattr_security_get+0x28/0x38 [] generic_getxattr+0x4c/0x60 [] smk_fetch.isra.6+0x8c/0xe0 [] smack_d_instantiate+0x194/0x324 [] security_d_instantiate+0x24/0x30 [] d_instantiate_new+0x34/0x94 [] ext4_mkdir+0x284/0x354 [] vfs_mkdir+0xc0/0x150 [] SyS_mkdirat+0x88/0xb8 [] SyS_mkdir+0x18/0x20 Code: aa0003f3 b00017c0 912e1000 97e38943 (c85f7e60) ---[ end trace b1ad797d63dae9c5 ]--- It is because d_instantiate_new() added from above commit calls security_d_instantiate() before calling __d_instantiate() and dentry->d_inode is not yet set and null. In 3.18.113 kernel, inode->i_op_getxattr() of ext4 is still generic_getxattr() and it only has dentry parameter without inode, so it tries to access dentry->d_inode. I did not test with selinux, but selinux also calls inode->i_op_getxattr() from selinux_d_instantiate(), so maybe there is also same issue. Best Regards, - Seung-Woo Kim -- Seung-Woo Kim Samsung Research --
Re: [PATCH V2 02/19] csky: defconfig
On Sun, Jul 1, 2018 at 11:34 AM Guo Ren wrote: > Needs a commit msg. Perhaps some overview of what's in each config. > Signed-off-by: Guo Ren > --- > arch/csky/configs/gx66xx_defconfig | 549 > + > arch/csky/configs/qemu_ck807_defconfig | 541 > 2 files changed, 1090 insertions(+) > create mode 100644 arch/csky/configs/gx66xx_defconfig > create mode 100644 arch/csky/configs/qemu_ck807_defconfig Are these configs mutually exclusive? We try to have one kernel build serve many platforms. So you'd probably want to divide things between the 2 ABIs. It looks like you still have lots of options enabled that I wouldn't expect you to need. Start with something more minimal for what you need to boot and support upstream. For a full config, you can use allmodconfig at least to build test. Rob
Re: [PATCH v9 2/6] mm: page_alloc: remain memblock_next_valid_pfn() on arm/arm64
Can you put it into memblock.c > Do you think it looks ok if I add the inline prefix? I would say no, this function is a too complex, and is not in some critical path to be always inlined. I would put it into memblock.c, and have #ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID around it. Thank you, Pavel
[lkp-robot] 9a93848fe7 [ 1.383411] WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 9a93848fe787a53aec404e4e00d8f7f9bbdaebb4 Author: Peter Zijlstra AuthorDate: Thu Feb 2 14:43:51 2017 +0100 Commit: Ingo Molnar CommitDate: Mon Mar 27 10:20:28 2017 +0200 x86/debug: Implement __WARN() using UD0 By using "UD0" for WARN()s we remove the function call and its possible __FILE__ and __LINE__ immediate arguments from the instruction stream. Total image size will not change much, what we win in the instruction stream we'll lose because of the __bug_table entries. Still, saves on I$ footprint and the total image size does go down a bit. textdata filename 107021234530992defconfig-build/vmlinux.orig 106824604530992defconfig-build/vmlinux.patched (UML didn't seem to use GENERIC_BUG at all, so remove it) Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Josh Poimboeuf Cc: Arjan van de Ven Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Richard Weinberger Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar 1fa9d67a2f x86/ftrace: Use Makefile logic instead of #ifdef for compiling ftrace_*.o 9a93848fe7 x86/debug: Implement __WARN() using UD0 883c9ab9eb Merge branch 'parisc-4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux e3c7283c19 Add linux-next specific files for 20180629 +-++++---+ | | 1fa9d67a2f | 9a93848fe7 | 883c9ab9eb | next-20180629 | +-++++---+ | boot_successes | 0 | 0 | 2 | 0 | | boot_failures | 55 | 22 | 22 | 6 | | WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 55 | 22 | 22 | 6 | | EIP:note_page | 0 | 22 | 22 | 6 | | Mem-Info| 0 | 0 | 1 | | +-++++---+ [1.379767] Write protecting the kernel text: 7716k [1.380913] Write protecting the kernel read-only data: 3232k [1.381556] NX-protecting the kernel data: 6620k [1.382399] x86/mm: Found insecure W+X mapping at address 400a/0x400a [1.382947] [ cut here ] [1.383411] WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page+0x73d/0x970 [1.384159] Modules linked in: [1.384461] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-00046-g9a93848 #58 [1.385012] task: 4f43c000 task.stack: 4f43e000 [1.385611] EIP: note_page+0x73d/0x970 [1.386058] EFLAGS: 00210216 CPU: 0 [1.386490] EAX: 0041 EBX: 4f43ff40 ECX: 0228 EDX: [1.387184] ESI: 8000 EDI: EBP: 4f43ff10 ESP: 4f43fed8 [1.387897] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [1.388523] CR0: 80050033 CR2: CR3: 0907 CR4: 001406b0 [1.389239] DR0: DR1: DR2: DR3: [1.389938] DR6: fffe0ff0 DR7: 0400 [1.390390] Call Trace: [1.390679] ? preempt_schedule_common+0x48/0x60 [1.391217] ptdump_walk_pgd_level_core+0x36e/0x4a0 [1.391773] ptdump_walk_pgd_level_checkwx+0x16/0x20 [1.392354] mark_rodata_ro+0xed/0x110 [1.392780] ? rest_init+0xb0/0xb0 [1.393219] kernel_init+0x2c/0x100 [1.393628] ? rest_init+0xb0/0xb0 [1.394018] ret_from_fork+0x21/0x2c [1.394451] Code: 00 00 00 b8 a0 54 f6 48 c6 05 44 df ec 48 01 e8 3a ab 0e 00 8b 43 0c c7 04 24 60 0f dd 48 89 44 24 08 89 44 24 04 e8 81 93 12 00 <0f> ff 31 c9 ba 01 00 00 00 c7 04 24 01 00 00 00 b8 88 54 f6 48 [1.396683] ---[ end trace b027e07a36e0a3c3 ]--- [1.397351] x86/mm: Checked W+X mappings: FAILED, 96 W+X pages found. # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start v4.12 v4.11 -- git bisect bad f3926e4c2a4b53c25a998de168d4eef6d0360369 # 17:32 B 0 1 19 4 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad 677375cef8cb7763ef620e007873117b9bad72a0 # 17:44 B 0 3 26 9 Merge tag 'fscrypt_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt git bisect bad 76f1948a79b26d5f57a5ee9941876b745c6baaea # 17:53 B 0 5 22 3 Merge branch 'f
Re: [PATCH v5 0/7] add virt-dma support for imx-sdma
On 一, 2018-07-02 at 18:47 +0530, Vinod wrote: > On 02-07-18, 02:32, Robin Gong wrote: > > > > Hi Vinod, > > Do you have any comment for this patchset? Lucas and Sascha > > acked it and tty patch already merged in. > I was actually waiting for ACK/action on patch 1 :) > > I have reviewed the series, some nitpicks nothing major, so I have > applied this good cleanup and conversion :) along with fixes for > typos > in code, GFP_ fix and removed unused variable. > > My buildchain noticed warns (with W=1) on this file, esp now that > structs are moved around. Pls fix the struct descriptions. Okay, I'll send another patch to fix such build warning issue later. BTW, patch 1 has already been in linux-next tree :). > > Thanks
Re: [PATCH V2 07/19] csky: MMU and page table management
On Mon, Jul 02, 2018 at 06:29:15AM -0700, Christoph Hellwig wrote: > This commit is missing an explanation. The patch is for abiv1 & abiv2 CPU series' MMU support. - abiv1 CPU (CK610) is VIPT cache and it doesn't support highmem. - abiv2 CPUs are all PIPT cache and they could support highmem. We seperate abiv1 and abiv2 into two direcotries for coding convention. > For the dma-mapping code please use the generic kernel/dma/noncoherent.c > code instead of duplicating it. Thx for the tips and I think you mean the lib/dma-noncoherent.c in the lastest kernel source and not in linux-4.16.2. I'll rebase on the newest RC version of linux in next version patch and reuse the code in lib/dma-noncoherent.c. Current csky_dma_alloc implementation is not good, it use 512MB uncached area to mirror the Normal cachable-512MB area. In next version patch, we will increase the max-Normal memory zone to (1GB + 768MB). In csky_dma_alloc we will seperate the atomic_dma and non-atomic_dma and reserve the area in fixmap area. Here is my memory layout plan in next version patch: Fixmap : 0xffc02000 – 0xf000 (4 MB - 12KB) kmap_atomic, dma_atomic ... Pkmap: 0xff80 – 0xffc0 (4 MB)PTR_PER_PTE = 1024 Vmalloc : 0xf020 – 0xff00 (238 MB) max: 238MB + 256MB + 1GB Lowmem : 0x8000 – 0xf000 (1G + 768 MB) Guo Ren
[lkp-robot] ee410f15b1 BUG: kernel hang in boot stage
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit ee410f15b1418f2f4428e79980674c979081bcb7 Author: Thierry Escande AuthorDate: Thu Jun 14 15:28:15 2018 -0700 Commit: Linus Torvalds CommitDate: Fri Jun 15 07:55:25 2018 +0900 lib/test_printf.c: call wait_for_random_bytes() before plain %p tests If the test_printf module is loaded before the crng is initialized, the plain 'p' tests will fail because the printed address will not be hashed and the buffer will contain '(ptrval)' instead. This patch adds a call to wait_for_random_bytes() before plain 'p' tests to make sure the crng is initialized. Link: http://lkml.kernel.org/r/20180604113708.11554-1-thierry.esca...@linaro.org Signed-off-by: Thierry Escande Acked-by: Tobin C. Harding Reviewed-by: Andrew Morton Cc: David Miller Cc: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds 608dbdfb1f hexagon: drop the unused variable zero_page_mask ee410f15b1 lib/test_printf.c: call wait_for_random_bytes() before plain %p tests 883c9ab9eb Merge branch 'parisc-4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux e3c7283c19 Add linux-next specific files for 20180629 +---++++---+ | | 608dbdfb1f | ee410f15b1 | 883c9ab9eb | next-20180629 | +---++++---+ | boot_successes| 35 | 0 | 19 | 13 | | boot_failures | 0 | 15 || | | BUG:kernel_hang_in_boot_stage | 0 | 15 || | +---++++---+ [9.488584] - [9.491008] Testing concurrent rhashtable access from 10 threads [ 21.577749] test 3125 add/delete pairs into rhlist [ 21.734553] test 3125 random rhlist add/delete operations [ 21.813107] Started 10 threads, 0 failed, rhltable test returns 0 BUG: kernel hang in boot stage # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start 7daf201d7fe8334e2d2364d4e8ed3394ec9af819 v4.17 -- git bisect good a16afaf7928b74c30a4727cdcaa67bd10675a55d # 08:00 G 11 00 0 Merge tag 'for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply git bisect good dc594c39f7a9dcdfd5dbb1a446ac6d06182e2472 # 08:13 G 11 00 0 Merge tag 'ceph-for-4.18-rc1' of git://github.com/ceph/ceph-client git bisect bad 81e97f01371f4e1701feeafe484665112cd9ddc2 # 08:33 B 0 1 15 0 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid git bisect bad 35773c93817c5f2df264d013978e7551056a063a # 08:55 B 0 1 15 0 Merge branch 'afs-proc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad 8949170cf48e91da7e4e69a59e2842d81d9a5885 # 09:26 B 0 1 15 0 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect bad becfc5e97cbab00b25a592aabc36838ec7217d1f # 09:49 B 0 10 24 0 Merge tag 'drm-next-2018-06-15' of git://anongit.freedesktop.org/drm/drm git bisect good 7a932516f55cdf430c7cce78df2010ff7db6b874 # 10:21 G 11 00 0 Merge tag 'vfs-timespec64' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground git bisect bad b5d903c2d656e9bc54bc76554a477d796a63120d # 10:44 B 0 1 15 0 Merge branch 'akpm' (patches from Andrew) git bisect good 3fb3894b84c2e0f83cb1e4f4e960243742e6b3a6 # 11:06 G 10 00 0 kernel/relay.c: change return type to vm_fault_t git bisect good 14f28f5776927be30717986f86b765d49eec392c # 11:20 G 10 00 0 ipc: use new return type vm_fault_t git bisect good fe6bdfc8e1e131720abbe77a2eb990c94c9024cb # 11:44 G 10 00 0 mm: fix oom_kill event handling git bisect good 608dbdfb1f0299f4500e56d62b0d84c44dcfa3be # 11:56 G 11 00 0 hexagon: drop the unused variable zero_page_mask git bisect bad ee410f15b1418f2f4428e79980674c979081bcb7 # 12:16 B 0 1 15 0 lib/test_printf.c: call wait_for_random_bytes() before plain %p tests # first bad commit: [ee410f15b1418f2f4428e79980674c979081bcb7] lib/test_printf.c: call wait_for_random_bytes() before plain %p tests git bisect good 608dbdfb1f0299f4500e56d62b0d84c44dcfa3be # 12:42 G 30 00 0 hexagon: drop the unused variable zero_page_mask # extra tests with debug options git bisect bad ee410f15b1418f2f4428e79980674c979081bcb7 # 13:00 B 0 11 25 0 lib/test_printf.c: call wait_for_random_by
Re: [PATCH 0/2] serial: 8250_dw: add fractional divisor support
On Tue, 3 Jul 2018 10:22:57 +0800 Jisheng Zhang wrote:
> Hi,
>
> On Mon, 2 Jul 2018 14:51:03 +0300 Andy Shevchenko wrote:
>
> > On Mon, 2018-07-02 at 13:18 +0300, Andy Shevchenko wrote:
> > > On Mon, 2018-07-02 at 18:04 +0800, Jisheng Zhang wrote:
> > > > For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
> > > > valid divisor latch fraction register. The fractional divisor width
> > > > is
> > > > 4bits ~ 6bits.
> > > >
> > >
> > > There are several serial IPs that have fractional divider built-in.
> > > None
> > > is using any specific hooks. Why do you need in your case, esp. taking
> > > into consideration that we have a custom ->set_termios() callback?
> >
> > Okay, I see that in 8250 we have hooks embedded into 8250_port.c which
> > is not the best solution.
> >
> > For example it prevents better splitting Exar code.
> > So, we would need these hooks, but better to integrate them in the same
> > way like it's done for the rest of 8250 ones, i.e.
> > - rename existing to have a "do" word
> > - create new functions which would be a replacement that choose between
> > "do" variant and custom one
> > - not sure if we need to export "do" variants (at least for now)
>
> So you mean add the support as following:
>
> 1.rename current serial8250_set_divisor as serial8250_do_set_divisor
>
> 2.add a new serial8250_set_divisor which will be as simple as
>
> static void serial8250_set_divisor(struct uart_port *port, ...)
> {
> struct uart_8250_port *up = up_to_u8250p(port);
>
> if (up->set_divisor)
> up->set_divisor(...);
> else
> serial8250_do_set_divisor(...);
> }
>
> could you please confirm?
>
> Another issue is I'm not sure which struct to add the hook,
> struct uart_port or struct uart_8250_port? Currently, it seems that only
> uart_8250_port needs this hook, sure, adding the hook to struct uart_port
> is fine either. Could you please kindly give some suggestions?
patching struct uart_port seems a bit overhead. After reading the code
again, I propose another solution, similar as what dl_write() is used in
8250 core:
1.introduce the hook to struct uart_8250_port as my previous patches do,
2.rename current serial8250_set_divisor() as default_serial_get_divisor()
then introduce a new serial8250_set_divisor() as:
static inline void serial8250_set_divisor(struct uart_8250_port *up,)
{
up->set_divisor();
}
and point up->set-divisor to default_serial_get_divisor
what do you think about this solution?
Thanks
>
> Thanks,
> Jisheng
Re: [PATCH v7 00/10] Introduce the Counter subsystem
On Mon, Jul 02, 2018 at 01:13:40PM -0500, David Lechner wrote: >On 06/21/2018 04:06 PM, William Breathitt Gray wrote: >> I decided to strip down these devices to arrive at the core essence of >> what constitutes a "counter device" and therefore design a "generic >> counter" abstraction to better represent these devices and prevent the >> ambiguity we discovered with the existing IIO Counter interface. This >> abstraction became the Generic Counter paradigm, which is explained in >> detail within the Documentation/driver-api/generic-counter.rst file >> introduced by this patchset. > >I'm curious if you have given any thought to the time aspect of counters. >I am interested in the rate at which the counters are counting (e.g. how >many counts per second). I realize that you can calculate this in >userspace or in the kernel using the system timer, but it is not very >accurate since Linux is not a realtime OS. So, I would like to get the >rate directly from the hardware. For example, the TI eQEP[1], like the >one found in BeagleBones, has a couple ways of measuring time (see link >for details). > >[1]: http://www.ti.com/lit/ug/sprug05a/sprug05a.pdf Ah yes, I see you initially attempted adding a frequency channel type to the IIO code. I agree with you that this calculation is best kept away from the operating system, not just because of the realtime requirement considerations, but also because the hardware likely knows best its own data, so let's expose it! Regarding the Generic Counter interface, a frequency attribute can be added quite easily in a technical sense, so this discussion should be focused more on the warrant for exposing this data. I understand from the discussion thread on your initial patch submission that you're working with hot-swappable encoder wheels and would like to expose a counting rate since you have trouble otherwise knowing the number of counts equal to one revolution due to the various possible encoder wheels that could be installed -- do I understand this correctly? Luckily the Generic Counter interface is a more abstract paradigm, so the hot-swappable encoder wheels should not be a problem for us as long as we nail down a consistent and thorough definition for this attribute. To that end, since the Generic Counter paradigm is designed to abstract away specifics of counter devices in order to present the final data of interest to users (e.g. the count value, the mode of operation, etc.), let's make sure frequency is actually what we want to expose and not just a middle-step datum on the path to the final result. What is the real life use-case for this information (are you tracking position)? Does the relevant hardware report the number of counts equal to one revolution, or are you calculating this from frequency? Are you using this frequency to simply track the number of revolutions? Should revolution count also be exposed? Is frequency useful for other applications on its own (perhaps velocity of an automobile device equipped with an encoder wheel for some reason or other)? Once we figure out how this data is used, we can determine the best design and place to introduce it into the Generic Counter interface, then move on to integration from there. William Breathitt Gray
Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs
On Mon, Jul 2, 2018 at 7:30 PM Mathieu Desnoyers wrote: > > > Is it really ? Last time we had this discussion, not all architectures > guaranteed that reading a 64-bit integer would happen in two atomic > 32-bit sub-parts. All architectures that matter do. Please don't overdesign this, or try to make a problem out of something that isn't a problem. Sure, maybe some toy architecture does a 8-byte "get_user()" as a "copy_from_user()" one byte at a time, because that's the best way to do unaligned accesses. But nobody will ever care about rseq on such a thing anyway. Let it go. Linus
Re: [PATCH 2/2] ARM: dts: pxa: add mioa701 board description
Hi Robert, I love your patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on v4.18-rc3 next-20180702] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Robert-Jarzmik/ARM-dts-pxa-add-pincontrol-helpers/20180702-140342 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: arm-u8500_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: Input tree has errors, aborting (use -f to force output) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 2/4] KVM: Add tlb remote flush callback in kvm_x86_ops.
Hi Tianyu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.18-rc3 next-20180702]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tianyu-Lan/KVM-x86-hyper-V-Introduce-PV-guest-address-space-mapping-flush-support/20180703-012046
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function
'kvm_flush_remote_tlbs':
>> arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:265:6: error: 'kvm_x86_ops'
>> undeclared (first use in this function); did you mean 'kvm_xive_ops'?
if (kvm_x86_ops->tlb_remote_flush &&
^~~
kvm_xive_ops
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:265:6: note: each undeclared
identifier is reported only once for each function it appears in
vim +265 arch/powerpc/kvm/../../../virt/kvm/kvm_main.c
255
256 #ifndef CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL
257 void kvm_flush_remote_tlbs(struct kvm *kvm)
258 {
259 long dirty_count;
260
261 /*
262 * Call tlb_remote_flush first and go back old way when
263 * return failure.
264 */
> 265 if (kvm_x86_ops->tlb_remote_flush &&
266 !kvm_x86_ops->tlb_remote_flush(kvm))
267 return;
268
269 /*
270 * Read tlbs_dirty before setting KVM_REQ_TLB_FLUSH in
271 * kvm_make_all_cpus_request.
272 */
273 dirty_count = smp_load_acquire(&kvm->tlbs_dirty);
274
275 /*
276 * We want to publish modifications to the page tables before
reading
277 * mode. Pairs with a memory barrier in arch-specific code.
278 * - x86: smp_mb__after_srcu_read_unlock in vcpu_enter_guest
279 * and smp_mb in walk_shadow_page_lockless_begin/end.
280 * - powerpc: smp_mb in kvmppc_prepare_to_enter.
281 *
282 * There is already an smp_mb__after_atomic() before
283 * kvm_make_all_cpus_request() reads vcpu->mode. We reuse that
284 * barrier here.
285 */
286 if (kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH))
287 ++kvm->stat.remote_tlb_flush;
288 cmpxchg(&kvm->tlbs_dirty, dirty_count, 0);
289 }
290 EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs);
291 #endif
292
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier
On Mon, 2018-07-02 at 19:26 -0700, Linus Torvalds wrote: > On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds > wrote: > > > > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT > > USE UNDER ANY CIRCUMSTANCES. Think of it more as a "something like > > this might work, but probably doesn't". Maybe it gives you an idea, > > although that idea might be "Linus has finally lost it". > > Even if it were to work, it should probably just be done inside kernfs > and exposed as some kind of "kernfs_remove_if_empty()" function. That would be harder, we'd have to expose it via a kobject_del_if_empty() then. Since we control completely when things are added/removed from the gluedir and have a big fat mutex for it, I don't think locking is much of an issue. At least in that specific case. > We happen to know that we hold the lock that creates all the entries > in the glue directory (and we don't allow users to move or create > stuff, afaik, even if we alloc chmod etc), so there should be no > races, but a generic kernfs helper function would probably have to get > proper locks and check it the right way. Yes that or document very clearly under what circumstances that function can be used. > Linus
Re: [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier
On Mon, 2018-07-02 at 19:15 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2018 at 5:57 PM Benjamin Herrenschmidt
> wrote:
> >
> > I'll have a look see if I can find a way to check that the sysfs dir is
> > empty without adding that childcount, that would at least alleviate
> > some of your objection, and would probably make the patch
> > smaller/simpler.
>
> That would definitely make me happier.
>
> Right now we already remove the actual device node sysfs associations
> synchronously with "kobject_del()" (even if it still then stays around
> as a kobject), and that does the remove for the object itself - just
> not the glue directory.
>
> If we then just did a "if glue dir is empty, delete the glue dir too"
> in cleanup_glue_dir(), at least ther patch would be prettier.
>
> I *think* that should be easy. Maybe. Something almost, but not quite,
> entirely unlike the below UNTESTED hack?
Yes, something like that. I have a bunch of other things I need to
attend to today, so I might not come up with a patch before some time
tomorrow but I'll have a look.
> It's whitespace-damaged on purpose. It's probably broken shit. DO NOT
> USE UNDER ANY CIRCUMSTANCES. Think of it more as a "something like
> this might work, but probably doesn't". Maybe it gives you an idea,
> although that idea might be "Linus has finally lost it".
>
> I suspect it's broken because kernfs has this notion of inactive
> nodes, so just testing for the rbtree being empty is probably wrong. I
> think maybe it needs to test for there not being any active nodes, but
> then you'd need the kernfs_mutex etc, so that would make things much
> worse.
There's also a "subdirs" in kernfs_node which we could use. That's a
bit ugly because it only account directories but we happen to know that
the gluedirs only contain directories, so it would work fine in
practice for that case.
> I really haven't touched the kernfs code much, thus the "this may be
> complete and utter garbage" warning.
>
> Adding Tejun to the participants, he should know. Or Greg, who has
> been silent, presumably because he's still getting over his crazy
> travels.
Cheers,
Ben.
> Linus
>
> ---
>
> --- a/drivers/base/core.c
>+++ b/drivers/base/core.c
>@@ -1585,6 +1585,12 @@ static inline struct kobject
> *get_glue_dir(struct device *dev)
> return dev->kobj.parent;
> }
>
>+static inline bool has_children(struct kobject *dir)
>+{
>+struct kernfs_node *kn = dir->sd;
>+return kn && kn->dir.children.rb_node;
>+}
>+
> /*
> * make sure cleaning up dir as the last step, we need to make
> * sure .release handler of kobject is run with holding the
>@@ -1597,6 +1603,10 @@ static void cleanup_glue_dir(struct device
> *dev, struct kobject *glue_dir)
> return;
>
> mutex_lock(&gdp_mutex);
>-kobject_put(glue_dir);
>+if (has_children(glue_dir))
>+kobject_put(glue_dir);
>+else
>+kobject_del(glue_dir);
> mutex_unlock(&gdp_mutex);
> }
Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs
On Mon, Jul 2, 2018 at 7:30 PM, Mathieu Desnoyers wrote: > - On Jul 2, 2018, at 10:18 PM, Linus Torvalds > torva...@linux-foundation.org wrote: > >> On Mon, Jul 2, 2018 at 7:01 PM Mathieu Desnoyers >> wrote: >>> >>> One thing to consider is how we will implement the load of that pointer >>> on the kernel side. >> >> Use "get_user()". It works for 64-bit objects too, and it will be >> atomic in the 32-bit sub-parts on a 32-bit architecture. > > Is it really ? Last time we had this discussion, not all architectures > guaranteed that reading a 64-bit integer would happen in two atomic > 32-bit sub-parts. This was the main motivation for the LINUX_FIELD_u32_u64() > macro as it stands today (rather than using a union). > If you're nervous, you could do this by open-coding: #if BITS_PER_LONG == 64 get_user(...) #else get_user(...); get_user(...); #endif No need to make the header more complicated just for this.
Re: [PATCH v6 1/8] dt-bindings: reset: Add AOSS reset bindings for SDM845 SoCs
On Wed, Jun 27, 2018 at 07:54:42PM +0530, Sibi Sankar wrote: > Add SDM845 AOSS (always on subsystem) reset controller binding > > Signed-off-by: Sibi Sankar > --- > > Not including Rob's earlier Reviewed-by due to change in compatible > > .../bindings/reset/qcom,aoss-reset.txt| 52 +++ > include/dt-bindings/reset/qcom,sdm845-aoss.h | 17 ++ > 2 files changed, 69 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt > create mode 100644 include/dt-bindings/reset/qcom,sdm845-aoss.h Reviewed-by: Rob Herring
Re: [PATCH v22 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit
On Wed, Jun 27, 2018 at 07:16:09PM +0800, Houlong Wei wrote:
> This adds documentation for the MediaTek Global Command Engine (GCE) unit
> found in MT8173 SoCs.
>
> Signed-off-by: Houlong Wei
> Signed-off-by: HS Liao
> ---
> Hi Rob,
> I don't add your ACK in this version since the dt-binding description
> has been changed. Thanks.
> ---
> .../devicetree/bindings/mailbox/mtk-gce.txt| 65
>
> include/dt-bindings/gce/mt8173-gce.h | 48 +++
> 2 files changed, 113 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 include/dt-bindings/gce/mt8173-gce.h
>
> diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> new file mode 100644
> index 000..26f65a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> @@ -0,0 +1,65 @@
> +MediaTek GCE
> +===
> +
> +The Global Command Engine (GCE) is used to help read/write registers with
> +critical time limitation, such as updating display configuration during the
> +vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
> +
> +CMDQ driver uses mailbox framework for communication. Please refer to
> +mailbox.txt for generic information about mailbox device-tree bindings.
> +
> +Required properties:
> +- compatible: Must be "mediatek,mt8173-gce"
> +- reg: Address range of the GCE unit
> +- interrupts: The interrupt signal from the GCE block
> +- clock: Clocks according to the common clock binding
> +- clock-names: Must be "gce" to stand for GCE clock
> +- thread-num: Maximum threads count of GCE.
mediatek,thread-num
Is this needed for anything other than error checking the thread id in
the mbox cells? if that's it, then drop it.
> +- #mbox-cells: Should be 4.
> + <&phandle channel timeout priority atomic_exec>
> + phandle: Label name of a gce node.
> + channel: Channel of mailbox. Be equal to the thread id of GCE.
> + timeout: Maximum time of software waiting GCE processing done, in unit
> + of millisecond.
> + priority: Priority of GCE thread.
> + atomic_exec: GCE processing continuous packets of commands in atomic
> + way.
> +
> +Required properties for a client device:
> +- mboxes: Client use mailbox to communicate with GCE, it should have this
> + property and list of phandle, mailbox specifiers.
> +- gce-subsys: Specify the sub-system id which is corresponding to the
> register
> + address.
What is this for?
> +
> +Optional properties for a client device:
> +- gce-event: Specify the event if the client has any. Because the event is
> + parsed by client, so client can replace 'gce-event' with other meaningful
> + name.
If the client sets the name, then no point having here. It must be
documented in the client binding. But then, what is this for in the
first place?
> +
> +Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'.
> Such as
> +thread number, sub-system ids, thread priority, event ids.
> +
> +Example:
> +
> + gce: gce@10212000 {
mailbox@...
> + compatible = "mediatek,mt8173-gce";
> + reg = <0 0x10212000 0 0x1000>;
> + interrupts = ;
> + clocks = <&infracfg CLK_INFRA_GCE>;
> + clock-names = "gce";
> + thread-num = CMDQ_THR_MAX_COUNT;
> + #mbox-cells = <4>;
> + };
> +
> +Example for a client device:
> +
> + mmsys: clock-controller@1400 {
> + compatible = "mediatek,mt8173-mmsys";
> + mboxes = <&gce 0 2000 CMDQ_THR_PRIO_LOWEST 1>,
> + <&gce 1 2000 CMDQ_THR_PRIO_LOWEST 1>;
> + gce-subsys = ;
> + mutex-event-eof = + CMDQ_EVENT_MUTEX1_STREAM_EOF>;
> +
> + ...
> + };
Re: [RFC PATCH for 4.18] rseq: use __u64 for rseq_cs fields, validate user inputs
- On Jul 2, 2018, at 10:18 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Mon, Jul 2, 2018 at 7:01 PM Mathieu Desnoyers > wrote: >> >> One thing to consider is how we will implement the load of that pointer >> on the kernel side. > > Use "get_user()". It works for 64-bit objects too, and it will be > atomic in the 32-bit sub-parts on a 32-bit architecture. Is it really ? Last time we had this discussion, not all architectures guaranteed that reading a 64-bit integer would happen in two atomic 32-bit sub-parts. This was the main motivation for the LINUX_FIELD_u32_u64() macro as it stands today (rather than using a union). > > Again: there is no point in trying to be atomic in the full 64 bits > (when you're running on 32-bit). The upper bits don't have to "match" > the lower bits. They just have to be zero. So doing it as two loads is > fine - the same way it's perfectly fine to do it as two stores (since > the store to the upper bits will always be zero). I'd be fine with two atomic loads, but I'd rather have a strong confirmation about this, because last time around there were architectures where it was not true as far as I recall. Thanks, Mathieu > > Linus -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
RE: [PATCHv3 0/9] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems
Hi, > -Original Message- > From: Morten Rasmussen > Sent: Wednesday, June 20, 2018 6:06 PM > To: pet...@infradead.org; mi...@redhat.com > Cc: valentin.schnei...@arm.com; dietmar.eggem...@arm.com; > vincent.guit...@linaro.org; Gaku Inami > ; linux-kernel@vger.kernel.org; Morten Rasmussen > > Subject: [PATCHv3 0/9] sched/fair: Migrate 'misfit' tasks on asymmetric > capacity systems [snip] > > The patches have been tested on: >1. Arm Juno (r0): 2+4 Cortex A57/A53 >2. Hikey960: 4+4 Cortex A73/A53 > > Test case: > Big cpus are always kept busy. Pin a shorter running sysbench tasks to > big cpus, while creating a longer running set of unpinned sysbench > tasks. I have tested v3 patches on Renesas SoC again. It looks fine. You can add: Tested-by: Gaku Inami The patches have been tested on: 3. Renesas R-Car H3 : 4+4 Cortex A57/A53 Results: Single runs with completion time of each task R-Car H3 (tip) total time: 0.9391s total time: 0.9865s total time: 1.3691s total time: 1.6740s R-Car H3 (misfit) total time: 0.9368s total time: 0.9475s total time: 0.9471s total time: 0.9505s 10 run summary (tracking longest running task for each run) R-Car H3 avg max tip 1.6742 1.6750 misfit 0.9784 0.9905 Regards, Inami [snip]
Re: [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier
On Mon, Jul 2, 2018 at 7:15 PM Linus Torvalds wrote: > > It's whitespace-damaged on purpose. It's probably broken shit. DO NOT > USE UNDER ANY CIRCUMSTANCES. Think of it more as a "something like > this might work, but probably doesn't". Maybe it gives you an idea, > although that idea might be "Linus has finally lost it". Even if it were to work, it should probably just be done inside kernfs and exposed as some kind of "kernfs_remove_if_empty()" function. We happen to know that we hold the lock that creates all the entries in the glue directory (and we don't allow users to move or create stuff, afaik, even if we alloc chmod etc), so there should be no races, but a generic kernfs helper function would probably have to get proper locks and check it the right way. Linus
