linux-next: manual merge of the net-next tree with the vfs tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/ipconfig.c
between commits:
3f3942aca6da ("proc: introduce proc_create_single{,_data}")
c04d2cb2009f ("ipconfig: Write NTP server IPs to
/proc/net/ipconfig/ntp_servers")
from the vfs tree and commit:
4d019b3f80dc ("ipconfig: Create /proc/net/ipconfig directory")
from the net-next tree.
I fixed it up (see below - there may be more to do) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/ipconfig.c
index bbcbcc113d19,86c9f755de3d..
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@@ -1282,6 -1317,74 +1317,61 @@@ static int pnp_seq_show(struct seq_fil
&ic_servaddr);
return 0;
}
-
-static int pnp_seq_open(struct inode *indoe, struct file *file)
-{
- return single_open(file, pnp_seq_show, NULL);
-}
-
-static const struct file_operations pnp_seq_fops = {
- .open = pnp_seq_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
-
+ /* Create the /proc/net/ipconfig directory */
+ static int __init ipconfig_proc_net_init(void)
+ {
+ ipconfig_dir = proc_net_mkdir(&init_net, "ipconfig", init_net.proc_net);
+ if (!ipconfig_dir)
+ return -ENOMEM;
+
+ return 0;
+ }
+
+ /* Create a new file under /proc/net/ipconfig */
+ static int ipconfig_proc_net_create(const char *name,
+ const struct file_operations *fops)
+ {
+ char *pname;
+ struct proc_dir_entry *p;
+
+ if (!ipconfig_dir)
+ return -ENOMEM;
+
+ pname = kasprintf(GFP_KERNEL, "%s%s", "ipconfig/", name);
+ if (!pname)
+ return -ENOMEM;
+
+ p = proc_create(pname, 0444, init_net.proc_net, fops);
+ kfree(pname);
+ if (!p)
+ return -ENOMEM;
+
+ return 0;
+ }
+
+ /* Write NTP server IP addresses to /proc/net/ipconfig/ntp_servers */
+ static int ntp_servers_seq_show(struct seq_file *seq, void *v)
+ {
+ int i;
+
+ for (i = 0; i < CONF_NTP_SERVERS_MAX; i++) {
+ if (ic_ntp_servers[i] != NONE)
+ seq_printf(seq, "%pI4\n", &ic_ntp_servers[i]);
+ }
+ return 0;
+ }
+
+ static int ntp_servers_seq_open(struct inode *inode, struct file *file)
+ {
+ return single_open(file, ntp_servers_seq_show, NULL);
+ }
+
+ static const struct file_operations ntp_servers_seq_fops = {
+ .open = ntp_servers_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+ };
#endif /* CONFIG_PROC_FS */
/*
@@@ -1356,8 -1459,20 +1446,20 @@@ static int __init ip_auto_config(void
int err;
unsigned int i;
+ /* Initialise all name servers and NTP servers to NONE (but only if the
+* "ip=" or "nfsaddrs=" kernel command line parameters weren't decoded,
+* otherwise we'll overwrite the IP addresses specified there)
+*/
+ if (ic_set_manually == 0) {
+ ic_nameservers_predef();
+ ic_ntp_servers_predef();
+ }
+
#ifdef CONFIG_PROC_FS
- proc_create("pnp", 0444, init_net.proc_net, &pnp_seq_fops);
+ proc_create_single("pnp", 0444, init_net.proc_net, pnp_seq_show);
+
+ if (ipconfig_proc_net_init() == 0)
+ ipconfig_proc_net_create("ntp_servers", &ntp_servers_seq_fops);
#endif /* CONFIG_PROC_FS */
if (!ic_enable)
pgponH_kFeiVX.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] memstick: mspro_block: fix unused variable warning
Hi Anders,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc5]
[cannot apply to next-20180516]
[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/Anders-Roxell/memstick-mspro_block-fix-unused-variable-warning/20180514-202058
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/memstick/core/mspro_block.c: In function 'mspro_block_init_disk':
>> drivers/memstick/core/mspro_block.c:1180:6: error: 'host' undeclared (first
>> use in this function); did you mean 'halt'?
if (host->dev.dma_mask && *(host->dev.dma_mask))
^~~~
halt
drivers/memstick/core/mspro_block.c:1180:6: note: each undeclared identifier
is reported only once for each function it appears in
vim +1180 drivers/memstick/core/mspro_block.c
baf8532a1 Alex Dubov 2008-02-09 1169
baf8532a1 Alex Dubov 2008-02-09 1170 static int
mspro_block_init_disk(struct memstick_dev *card)
baf8532a1 Alex Dubov 2008-02-09 1171 {
baf8532a1 Alex Dubov 2008-02-09 1172 struct mspro_block_data *msb =
memstick_get_drvdata(card);
baf8532a1 Alex Dubov 2008-02-09 1173 struct mspro_devinfo *dev_info
= NULL;
baf8532a1 Alex Dubov 2008-02-09 1174 struct mspro_sys_info *sys_info
= NULL;
baf8532a1 Alex Dubov 2008-02-09 1175 struct mspro_sys_attr *s_attr =
NULL;
baf8532a1 Alex Dubov 2008-02-09 1176 int rc, disk_id;
baf8532a1 Alex Dubov 2008-02-09 1177 u64 limit = BLK_BOUNCE_HIGH;
baf8532a1 Alex Dubov 2008-02-09 1178 unsigned long capacity;
baf8532a1 Alex Dubov 2008-02-09 1179
c4c66cf17 Greg Kroah-Hartman 2008-03-04 @1180 if (host->dev.dma_mask &&
*(host->dev.dma_mask))
c4c66cf17 Greg Kroah-Hartman 2008-03-04 1181 limit =
*(host->dev.dma_mask);
baf8532a1 Alex Dubov 2008-02-09 1182
baf8532a1 Alex Dubov 2008-02-09 1183 for (rc = 0;
msb->attr_group.attrs[rc]; ++rc) {
baf8532a1 Alex Dubov 2008-02-09 1184 s_attr =
mspro_from_sysfs_attr(msb->attr_group.attrs[rc]);
baf8532a1 Alex Dubov 2008-02-09 1185
baf8532a1 Alex Dubov 2008-02-09 1186 if (s_attr->id ==
MSPRO_BLOCK_ID_DEVINFO)
baf8532a1 Alex Dubov 2008-02-09 1187 dev_info =
s_attr->data;
baf8532a1 Alex Dubov 2008-02-09 1188 else if (s_attr->id ==
MSPRO_BLOCK_ID_SYSINFO)
baf8532a1 Alex Dubov 2008-02-09 1189 sys_info =
s_attr->data;
baf8532a1 Alex Dubov 2008-02-09 1190 }
baf8532a1 Alex Dubov 2008-02-09 1191
baf8532a1 Alex Dubov 2008-02-09 1192 if (!dev_info || !sys_info)
baf8532a1 Alex Dubov 2008-02-09 1193 return -ENODEV;
baf8532a1 Alex Dubov 2008-02-09 1194
baf8532a1 Alex Dubov 2008-02-09 1195 msb->cylinders =
be16_to_cpu(dev_info->cylinders);
baf8532a1 Alex Dubov 2008-02-09 1196 msb->heads =
be16_to_cpu(dev_info->heads);
baf8532a1 Alex Dubov 2008-02-09 1197 msb->sectors_per_track =
be16_to_cpu(dev_info->sectors_per_track);
baf8532a1 Alex Dubov 2008-02-09 1198
baf8532a1 Alex Dubov 2008-02-09 1199 msb->page_size =
be16_to_cpu(sys_info->unit_size);
baf8532a1 Alex Dubov 2008-02-09 1200
d8256d487 Alex Dubov 2011-01-12 1201
mutex_lock(&mspro_block_disk_lock);
7b51f4783 Tejun Heo 2013-02-27 1202 disk_id =
idr_alloc(&mspro_block_disk_idr, card, 0, 256, GFP_KERNEL);
d8256d487 Alex Dubov 2011-01-12 1203
mutex_unlock(&mspro_block_disk_lock);
7b51f4783 Tejun Heo 2013-02-27 1204 if (disk_id < 0)
7b51f4783 Tejun Heo 2013-02-27 1205 return disk_id;
baf8532a1 Alex Dubov 2008-02-09 1206
8e82f8c34 Alex Dubov 2008-09-13 1207 msb->disk = alloc_disk(1 <<
MSPRO_BLOCK_PART_SHIFT);
baf8532a1 Alex Dubov 2008-02-09 1208 if (!msb->disk) {
baf8532a1 Alex Dubov 2008-02-09 1209 rc = -ENOMEM;
baf8532a1 Alex Dubov 2008-02-09 1210 goto out_release_id;
baf8532a1 Alex Dubov 2008-02-09 1211 }
baf8532a1 Alex Dubov 2008-02-09 1212
f1d826980 Alex Dubov 2008-07-25 1213 msb->queue =
blk_init_queue(mspro_block_submit_req, &msb->q_lock);
baf8532a1 Alex Dubov 2008-02-09 1214 if (!msb->queue) {
baf8532a1 Alex Dubov 2008-02-09 1215 rc = -ENOMEM;
baf8532a1 Alex Dubov 2008-02-09 1216 goto out_put_disk;
baf8532a1 Ale
Re: [PATCH] PM / devfreq: Remove redundant frequency adjustment from governors
Hi,
On 2018년 05월 17일 06:10, Matthias Kaehlcke wrote:
> The performance, powersave, simpleondemand and userspace governors
> determine a target frequency and then adjust it according to the
> df->min/max_freq limits that might have been set by user space. This
> adjustment is redundant, it is done in update_devfreq() for any
> governor, right after governor->get_target_freq().
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/governor_performance.c| 10 ++
> drivers/devfreq/governor_powersave.c | 5 -
> drivers/devfreq/governor_simpleondemand.c | 7 +--
> drivers/devfreq/governor_userspace.c | 16
> 4 files changed, 7 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/devfreq/governor_performance.c
> b/drivers/devfreq/governor_performance.c
> index 4d23ecfbd948..31ee30622c00 100644
> --- a/drivers/devfreq/governor_performance.c
> +++ b/drivers/devfreq/governor_performance.c
> @@ -16,14 +16,8 @@
> static int devfreq_performance_func(struct devfreq *df,
> unsigned long *freq)
> {
> - /*
> - * target callback should be able to get floor value as
> - * said in devfreq.h
> - */
> - if (!df->max_freq)
> - *freq = UINT_MAX;
> - else
> - *freq = df->max_freq;
> + *freq = UINT_MAX;
> +
It is difficult to understand why use UINT_MAX instead of df->max_freq.
Instead, after merged the commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq
when adding the devfreq device"), df->max/min_freq have the specific frequency
value always. So, we can change it as following without UINT_MAX.
*freq = df->max_freq;
> return 0;
> }
>
> diff --git a/drivers/devfreq/governor_powersave.c
> b/drivers/devfreq/governor_powersave.c
> index 0c42f23249ef..50a891f7c92d 100644
> --- a/drivers/devfreq/governor_powersave.c
> +++ b/drivers/devfreq/governor_powersave.c
> @@ -16,11 +16,6 @@
> static int devfreq_powersave_func(struct devfreq *df,
> unsigned long *freq)
> {
> - /*
> - * target callback should be able to get ceiling value as
> - * said in devfreq.h
> - */
> - *freq = df->min_freq;
> return 0;
Each function have to keep their own function role.
Please keep '*freq = df->min_freq'.
> }
>
> diff --git a/drivers/devfreq/governor_simpleondemand.c
> b/drivers/devfreq/governor_simpleondemand.c
> index 28e0f2de7100..7ed733c528f4 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -27,7 +27,7 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
> unsigned int dfso_upthreshold = DFSO_UPTHRESHOLD;
> unsigned int dfso_downdifferential = DFSO_DOWNDIFFERENCTIAL;
> struct devfreq_simple_ondemand_data *data = df->data;
> - unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
> + unsigned long max = UINT_MAX;
Use df->max_freq instead of UINT_MAX as following.
unsigned long max = df->max_freq;
>
> err = devfreq_update_stats(df);
> if (err)
> @@ -85,11 +85,6 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
> b = div_u64(b, (dfso_upthreshold - dfso_downdifferential / 2));
> *freq = (unsigned long) b;
>
> - if (df->min_freq && *freq < df->min_freq)
> - *freq = df->min_freq;
> - if (df->max_freq && *freq > df->max_freq)
> - *freq = df->max_freq;
> -
> return 0;
> }
>
> diff --git a/drivers/devfreq/governor_userspace.c
> b/drivers/devfreq/governor_userspace.c
> index 080607c3f34d..378d84c011df 100644
> --- a/drivers/devfreq/governor_userspace.c
> +++ b/drivers/devfreq/governor_userspace.c
> @@ -26,19 +26,11 @@ static int devfreq_userspace_func(struct devfreq *df,
> unsigned long *freq)
> {
> struct userspace_data *data = df->data;
>
> - if (data->valid) {
> - unsigned long adjusted_freq = data->user_frequency;
> -
> - if (df->max_freq && adjusted_freq > df->max_freq)
> - adjusted_freq = df->max_freq;
> -
> - if (df->min_freq && adjusted_freq < df->min_freq)
> - adjusted_freq = df->min_freq;
> -
> - *freq = adjusted_freq;
> - } else {
> + if (data->valid)
> + *freq = data->user_frequency;
> + else
> *freq = df->previous_freq; /* No user freq specified yet */
> - }
> +
> return 0;
> }
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH ghak81 V3 3/3] audit: collect audit task parameters
Hi Richard,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180516]
[cannot apply to linus/master tip/sched/core v4.17-rc5 v4.17-rc4 v4.17-rc3
v4.17-rc5]
[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/Richard-Guy-Briggs/audit-group-task-params/20180517-090703
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/fork.c: In function 'copy_process':
>> kernel/fork.c:1739:3: error: 'struct task_struct' has no member named 'audit'
p->audit = NULL;
^~
vim +1739 kernel/fork.c
1728
1729 p->default_timer_slack_ns = current->timer_slack_ns;
1730
1731 task_io_accounting_init(&p->ioac);
1732 acct_clear_integrals(p);
1733
1734 posix_cpu_timers_init(p);
1735
1736 p->start_time = ktime_get_ns();
1737 p->real_start_time = ktime_get_boot_ns();
1738 p->io_context = NULL;
> 1739 p->audit = NULL;
1740 cgroup_fork(p);
1741 #ifdef CONFIG_NUMA
1742 p->mempolicy = mpol_dup(p->mempolicy);
1743 if (IS_ERR(p->mempolicy)) {
1744 retval = PTR_ERR(p->mempolicy);
1745 p->mempolicy = NULL;
1746 goto bad_fork_cleanup_threadgroup_lock;
1747 }
1748 #endif
1749 #ifdef CONFIG_CPUSETS
1750 p->cpuset_mem_spread_rotor = NUMA_NO_NODE;
1751 p->cpuset_slab_spread_rotor = NUMA_NO_NODE;
1752 seqcount_init(&p->mems_allowed_seq);
1753 #endif
1754 #ifdef CONFIG_TRACE_IRQFLAGS
1755 p->irq_events = 0;
1756 p->hardirqs_enabled = 0;
1757 p->hardirq_enable_ip = 0;
1758 p->hardirq_enable_event = 0;
1759 p->hardirq_disable_ip = _THIS_IP_;
1760 p->hardirq_disable_event = 0;
1761 p->softirqs_enabled = 1;
1762 p->softirq_enable_ip = _THIS_IP_;
1763 p->softirq_enable_event = 0;
1764 p->softirq_disable_ip = 0;
1765 p->softirq_disable_event = 0;
1766 p->hardirq_context = 0;
1767 p->softirq_context = 0;
1768 #endif
1769
1770 p->pagefault_disabled = 0;
1771
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC PATCH] PM / devfreq: Add policy notifier
Hi, Could you give some use-case of DEVFREQ_POLICY_NOTIFIER or send use-case patch with this patch? I already knew the CPUFREQ_POLICY_NOTIFIER. But, until now, there are no any requirements of DEVFREQ_POLICY_NOTIFIER. If there are no any use-case, it is not necessary codes. On 2018년 05월 16일 06:24, Matthias Kaehlcke wrote: > Policy notifiers are called before a frequency change and may adjust the > frequency, similar to CPUFREQ_ADJUST. The purpose of policy notifiers is > to support non-thermal throttling of devfreq devices. > > As of now notifiers may only select a lower frequency, but not increase it. > The reason for this limitation is that devfreq currently doesn't have an > actual policy for frequencies and OPPs > freq might be disabled by a > devfreq cooling device (see drivers/thermal/devfreq_cooling.c). > > Signed-off-by: Matthias Kaehlcke > --- > Marked as RFC since I'm aware that this isn't quite a 'policy' notifier, > but I also didn't want to make it too specific. Maybe devfreq devices should > have a policy similar to cpufreq? > > Should devfreq core be in charge of disabling/enabling OPPs instead of > the thermal cooling device? Typically we don't want to use higher OPPs > than those whitelisted by thermal, so in practice the current situation > shouldn't be much of an issue. > > drivers/devfreq/devfreq.c | 20 > include/linux/devfreq.h | 6 ++ > 2 files changed, 22 insertions(+), 4 deletions(-) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index fe2af6aa88fc..a7294c056f65 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -273,6 +273,9 @@ int update_devfreq(struct devfreq *devfreq) > if (err) > return err; > > + srcu_notifier_call_chain(&devfreq->policy_notifier_list, > + DEVFREQ_ADJUST, &freq); It is not proper to used 'freq' as the passed data. In current step,'freq' is not adjusted and is not final decided frequency. > + > /* >* Adjust the frequency with user freq, QoS and available freq. >* > @@ -640,6 +643,7 @@ struct devfreq *devfreq_add_device(struct device *dev, > devfreq->last_stat_updated = jiffies; > > srcu_init_notifier_head(&devfreq->transition_notifier_list); > + srcu_init_notifier_head(&devfreq->policy_notifier_list); > > mutex_unlock(&devfreq->lock); > > @@ -1414,7 +1418,7 @@ EXPORT_SYMBOL(devm_devfreq_unregister_opp_notifier); > * devfreq_register_notifier() - Register a driver with devfreq > * @devfreq: The devfreq object. > * @nb: The notifier block to register. > - * @list:DEVFREQ_TRANSITION_NOTIFIER. > + * @list:DEVFREQ_TRANSITION_NOTIFIER or DEVFREQ_POLICY_NOTIFIER. > */ > int devfreq_register_notifier(struct devfreq *devfreq, > struct notifier_block *nb, > @@ -1430,6 +1434,10 @@ int devfreq_register_notifier(struct devfreq *devfreq, > ret = srcu_notifier_chain_register( > &devfreq->transition_notifier_list, nb); > break; > + case DEVFREQ_POLICY_NOTIFIER: > + ret = srcu_notifier_chain_register( > + &devfreq->policy_notifier_list, nb); > + break; > default: > ret = -EINVAL; > } > @@ -1442,7 +1450,7 @@ EXPORT_SYMBOL(devfreq_register_notifier); > * devfreq_unregister_notifier() - Unregister a driver with devfreq > * @devfreq: The devfreq object. > * @nb: The notifier block to be unregistered. > - * @list:DEVFREQ_TRANSITION_NOTIFIER. > + * @list:DEVFREQ_TRANSITION_NOTIFIER or DEVFREQ_POLICY_NOTIFIER. > */ > int devfreq_unregister_notifier(struct devfreq *devfreq, > struct notifier_block *nb, > @@ -1458,6 +1466,10 @@ int devfreq_unregister_notifier(struct devfreq > *devfreq, > ret = srcu_notifier_chain_unregister( > &devfreq->transition_notifier_list, nb); > break; > + case DEVFREQ_POLICY_NOTIFIER: > + ret = srcu_notifier_chain_unregister( > + &devfreq->policy_notifier_list, nb); > + break; > default: > ret = -EINVAL; > } > @@ -1485,7 +1497,7 @@ static void devm_devfreq_notifier_release(struct device > *dev, void *res) > * @dev: The devfreq user device. (parent of devfreq) > * @devfreq: The devfreq object. > * @nb: The notifier block to be unregistered. > - * @list:DEVFREQ_TRANSITION_NOTIFIER. > + * @list:DEVFREQ_TRANSITION_NOTIFIER or DEVFREQ_POLICY_NOTIFIER. > */ > int devm_devfreq_register_notifier(struct device *dev, > struct devfreq *devfreq, > @@ -1521,7 +1533,7 @@ EXPORT_SYMBOL(devm_devfreq_register_notifier); > * @dev: The devfreq user device. (parent of devfreq) > * @devfreq: The devfreq object. > * @nb:
Re: [PATCH] MAINTAINERS: update sound/soc/intel maintainers
On 16-05-18, 14:48, Pierre-Louis Bossart wrote: > The information for Intel SoC drivers was not updated for several > years. Add myself, Liam and Keyon (Jie) as maintainers to get notified > of contributions and bug reports. As discussed with Mark and Takashi, > I'll also monitor alsa-devel and ack Intel patches as necessary. Yeah somehow never added this, thanks for getting this done. This is the right this going fwd. Acked-By: Vinod Koul -- ~Vinod signature.asc Description: PGP signature
Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> James,
>
> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> > Hi Akashi,
> >
> > On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > memory map as well as ACPI tables, from being corrupted by loading
> > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > allocation in top-down manner in addition to default bottom-up.
> > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > for available memory ranges in usable memblock list,
> > > i.e. !NOMAP & !reserved,
> >
> > > instead of system resource tree.
> >
> > Didn't we try to fix the system-resource-tree in order to fix regular-kexec
> > to
> > be safe in the EFI-memory-map/ACPI-tables case?
> >
> > It would be good to avoid having two ways of doing this, and I would like to
> > avoid having extra arch code...
>
> I know what you mean.
> /proc/iomem or system resource is, in my opinion, not the best place to
> describe memory usage of kernel but rather to describe *physical* hardware
> layout. As we are still discussing about "reserved" memory, I don't want
> to depend on it.
> Along with memblock list, we will have more accurate control over memory
> usage.
In kexec-tools, we see any usable memory as candidate which can be used
to load kexec kernel image/initrd etc. However kexec loading is a
preparation work, it just books those position for later kexec kernel
jumping after "kexec -e", that is why we need kexec_buf to remember
them and do the real content copy of kernel/initrd. Here you use
memblock to search available memory, isn't it deviating too far away
from the original design in kexec-tools. Assume kexec loading and
kexec_file loading should be consistent on loading even though they are
done in different space, kernel space and user space.
I didn't follow the earlier post, may miss something.
Thanks
Baoquan
>
> >
> > > diff --git a/arch/arm64/kernel/machine_kexec_file.c
> > > b/arch/arm64/kernel/machine_kexec_file.c
> > > new file mode 100644
> > > index ..f9ebf54ca247
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > @@ -0,0 +1,57 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * kexec_file for arm64
> > > + *
> > > + * Copyright (C) 2018 Linaro Limited
> > > + * Author: AKASHI Takahiro
> > > + *
> >
> > > + * Most code is derived from arm64 port of kexec-tools
> >
> > How does kexec-tools walk memblock?
>
> Will remove this comment from this patch.
> Obviously, this comment is for the rest of the code which will be
> added to succeeding patches (patch #5 and #7).
>
>
> >
> > > + */
> > > +
> > > +#define pr_fmt(fmt) "kexec_file: " fmt
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > + int (*func)(struct resource *, void *))
> > > +{
> > > + phys_addr_t start, end;
> > > + struct resource res;
> > > + u64 i;
> > > + int ret = 0;
> > > +
> > > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > > + return func(&crashk_res, kbuf);
> > > +
> > > + if (kbuf->top_down)
> > > + for_each_mem_range_rev(i, &memblock.memory, &memblock.reserved,
> > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > + &start, &end, NULL) {
> >
> > for_each_free_mem_range_reverse() is a more readable version of this helper.
>
> OK. I used to use my own limited list of reserved memory instead of
> memblock.reserved here to exclude verbose ranges.
>
>
> > > + if (!memblock_is_map_memory(start))
> > > + continue;
> >
> > Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.
>
> Sure, I confirmed it.
>
> >
> > > + res.start = start;
> > > + res.end = end;
> > > + ret = func(&res, kbuf);
> > > + if (ret)
> > > + break;
> > > + }
> > > + else
> > > + for_each_mem_range(i, &memblock.memory, &memblock.reserved,
> > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > + &start, &end, NULL) {
> >
> > for_each_free_mem_range()?
>
> OK.
>
> > > + if (!memblock_is_map_memory(start))
> > > + continue;
> > > +
> > > + res.start = start;
> > > + res.end = end;
> > > + ret = func(&res, kbuf);
> > > + if (ret)
> > > + break;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > >
> >
> > With these changes, what we have is almost:
> > arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> > (the difference being powerpc doesn't yet support crash-kernels here)
> >
> > If the argument is walking memblock gives a bett
Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
On 05/17/18 at 10:10am, Baoquan He wrote:
> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> > James,
> >
> > On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> > > Hi Akashi,
> > >
> > > On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > > memory map as well as ACPI tables, from being corrupted by loading
> > > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > > allocation in top-down manner in addition to default bottom-up.
> > > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > > for available memory ranges in usable memblock list,
> > > > i.e. !NOMAP & !reserved,
> > >
> > > > instead of system resource tree.
> > >
> > > Didn't we try to fix the system-resource-tree in order to fix
> > > regular-kexec to
> > > be safe in the EFI-memory-map/ACPI-tables case?
> > >
> > > It would be good to avoid having two ways of doing this, and I would like
> > > to
> > > avoid having extra arch code...
> >
> > I know what you mean.
> > /proc/iomem or system resource is, in my opinion, not the best place to
> > describe memory usage of kernel but rather to describe *physical* hardware
> > layout. As we are still discussing about "reserved" memory, I don't want
> > to depend on it.
> > Along with memblock list, we will have more accurate control over memory
> > usage.
>
> In kexec-tools, we see any usable memory as candidate which can be used
Here I said 'any', it's not accurate. Those memory which need be passed
to 2nd kernel for use need be excluded, just as we have done in
kexec-tools.
> to load kexec kernel image/initrd etc. However kexec loading is a
> preparation work, it just books those position for later kexec kernel
> jumping after "kexec -e", that is why we need kexec_buf to remember
> them and do the real content copy of kernel/initrd. Here you use
> memblock to search available memory, isn't it deviating too far away
> from the original design in kexec-tools. Assume kexec loading and
> kexec_file loading should be consistent on loading even though they are
> done in different space, kernel space and user space.
>
> I didn't follow the earlier post, may miss something.
>
> Thanks
> Baoquan
>
> >
> > >
> > > > diff --git a/arch/arm64/kernel/machine_kexec_file.c
> > > > b/arch/arm64/kernel/machine_kexec_file.c
> > > > new file mode 100644
> > > > index ..f9ebf54ca247
> > > > --- /dev/null
> > > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > > @@ -0,0 +1,57 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * kexec_file for arm64
> > > > + *
> > > > + * Copyright (C) 2018 Linaro Limited
> > > > + * Author: AKASHI Takahiro
> > > > + *
> > >
> > > > + * Most code is derived from arm64 port of kexec-tools
> > >
> > > How does kexec-tools walk memblock?
> >
> > Will remove this comment from this patch.
> > Obviously, this comment is for the rest of the code which will be
> > added to succeeding patches (patch #5 and #7).
> >
> >
> > >
> > > > + */
> > > > +
> > > > +#define pr_fmt(fmt) "kexec_file: " fmt
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > > + int (*func)(struct resource *, void *))
> > > > +{
> > > > + phys_addr_t start, end;
> > > > + struct resource res;
> > > > + u64 i;
> > > > + int ret = 0;
> > > > +
> > > > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > > > + return func(&crashk_res, kbuf);
> > > > +
> > > > + if (kbuf->top_down)
> > > > + for_each_mem_range_rev(i, &memblock.memory,
> > > > &memblock.reserved,
> > > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > > + &start, &end, NULL) {
> > >
> > > for_each_free_mem_range_reverse() is a more readable version of this
> > > helper.
> >
> > OK. I used to use my own limited list of reserved memory instead of
> > memblock.reserved here to exclude verbose ranges.
> >
> >
> > > > + if (!memblock_is_map_memory(start))
> > > > + continue;
> > >
> > > Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP
> > > memory.
> >
> > Sure, I confirmed it.
> >
> > >
> > > > + res.start = start;
> > > > + res.end = end;
> > > > + ret = func(&res, kbuf);
> > > > + if (ret)
> > > > + break;
> > > > + }
> > > > + else
> > > > + for_each_mem_range(i, &memblock.memory,
> > > > &memblock.reserved,
> > > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > > + &start, &end, NULL) {
> > >
> > > for_each_free_mem_range()?
> >
> > OK.
> >
> > >
RE: [RFC] platform: detach from PM domains on shutdown
> -Original Message-
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael
> J. Wysocki
> Sent: 2018年5月17日 5:35
> To: Ulf Hansson
> Cc: Peng Fan ; Rafael J. Wysocki
> ; Fabio Estevam ; Greg
> Kroah-Hartman ; Linux Kernel Mailing List
> ; Linux PM ;
> dl-linux-imx
> Subject: Re: [RFC] platform: detach from PM domains on shutdown
>
> On Wed, May 16, 2018 at 11:52 AM, Ulf Hansson
> wrote:
> > On 15 May 2018 at 11:01, Peng Fan wrote:
> >> When reboot Linux, the PM domains attached to a device are not
> >> shutdown. To SoCs which relys on reset the whole SoC, there is no
> >> need to shutdown PM domains, but to Linux running in a virtual
> >> machine with devices pass-through, we could not reset the whole SoC.
> >> Currently we need Linux to shutdown its PM domains when reboot.
> >
> > I am not sure I understand exactly why the PM domain needs to be
> > shutdown for these cases, could you please elaborate a bit on that.
> >
> > BTW, what platform are you running on and also what PM domains are being
> used?
> >
> > Anyway, it seems like there may be need for certain cases, but
> > certainly not all - especially since it may slow down the shutdown
> > process, when not needed.
> >
> > Can we make this runtime configurable, via sysfs or whatever that makes
> sense!?
> >
> >>
> >> commit 2d30bb0b3889 ("platform: Do not detach from PM domains on
> >> shutdown"), removes what this patch tries to add, because of a warning.
> >> commit e79aee49bcf9 ("PM: Avoid false-positive warnings in
> >> dev_pm_domain_set()") already fixes the false alarm warning. So let's
> >> detach the power domain to shutdown PM domains after driver shutdown.
> >>
> >> Signed-off-by: Peng Fan
> >> ---
> >>
> >> I do not find a better place to shutdown power domain when reboot
> >> Linux, so add back the line that commit 2d30bb0b3889 removes, because
> >> it is a false alarm warning as commit e79aee49bcf9 describes.
> >>
> >> drivers/base/platform.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/base/platform.c b/drivers/base/platform.c index
> >> 8075ddc70a17..a5929f24dc3c 100644
> >> --- a/drivers/base/platform.c
> >> +++ b/drivers/base/platform.c
> >> @@ -616,6 +616,7 @@ static void platform_drv_shutdown(struct device
> >> *_dev)
> >>
> >> if (drv->shutdown)
> >> drv->shutdown(dev);
> >> + dev_pm_domain_detach(_dev, true);
> >
> > This would somewhat work, but only for platform devices. To make this
> > fully work, we need to call dev_pm_domain_detach() from amba, spi, etc
> > as well.
> >
> > Perhaps another option to manage this more generally, an without
> > having detach devices, could be to extend the struct dev_pm_domain
> > with a new callback, "->shutdown()" and then make the driver core call
> > it from device_shutdown().
>
> I'm sensing a possible ordering slippery slope with this (it will only work
> if all of
> the drivers/bus types etc do the right thing in their
> ->shutdown callbacks so nothing depends on the domain going forward).
>
> > Typically, for genpd, I would probably count the number of calls being
> > made to ->shutdown() per PM domain, then when it reaches the number of
> > attached devices to it, allow to power off it.
> >
> > Let's see what Rafael thinks about it.
>
> I'm not sure about the use case. The hypervisor should be able to take care
> of
> turning power domains off on the client OS reboot in theory. If the client OS
> leaving the hypervisor needs to worry about what state it leaves behind, the
> design of the hypervisor is sort of questionable IMO.
This is valid concern. But moving the power domain logic into hypervisor mostly
micro-kernel design
will introduce more complexity and make certification harder.
Currently, Let Linux shutdown it's power domain is the easiest way to me and
make things work well
after reboot.
Thanks,
Peng
Re: [PATCH] mmc: block: propagate correct returned value in mmc_rpmb_ioctl
On 2018/5/17 3:20, Mathieu Malaterre wrote:
In commit 97548575bef3 ("mmc: block: Convert RPMB to a character device") a
new function `mmc_rpmb_ioctl` was added. The final return is simply
returning a value of `0` instead of propagating the correct return code.
Discovered during a compilation with W=1, silence the following gcc warning
drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not used
[-Wunused-but-set-variable]
Good catch! But hey, which gcc are you using now? Mine, gcc-linaro-
6.3.1-2017.05-x86_64_aarch64-linux-gnu, with W=1 doesn't warn about
this. And it's worth backporting to stable.
Reviewed-by: Shawn Lin
Signed-off-by: Mathieu Malaterre
---
drivers/mmc/core/block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 9e923cd1d80e..38a7586b00cc 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2485,7 +2485,7 @@ static long mmc_rpmb_ioctl(struct file *filp, unsigned
int cmd,
break;
}
- return 0;
+ return ret;
}
#ifdef CONFIG_COMPAT
Re: [PATCH net-next 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST
Hi Florian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Allow-more-drivers-with-COMPILE_TEST/20180517-092807
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/realmode.h:15:0,
from arch/x86/include/asm/acpi.h:33,
from arch/x86/include/asm/fixmap.h:19,
from arch/x86/include/asm/apic.h:10,
from arch/x86/include/asm/smp.h:13,
from include/linux/smp.h:64,
from include/linux/topology.h:33,
from include/linux/gfp.h:9,
from include/linux/idr.h:16,
from include/linux/kernfs.h:14,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from drivers/net/ethernet/ti/davinci_cpdma.c:17:
drivers/net/ethernet/ti/davinci_cpdma.c: In function 'cpdma_chan_submit':
>> drivers/net/ethernet/ti/davinci_cpdma.c:1083:17: warning: passing argument 1
>> of '__writel' makes integer from pointer without a cast [-Wint-conversion]
writel_relaxed(token, &desc->sw_token);
^
arch/x86/include/asm/io.h:88:39: note: in definition of macro
'writel_relaxed'
#define writel_relaxed(v, a) __writel(v, a)
^
arch/x86/include/asm/io.h:71:18: note: expected 'unsigned int' but argument
is of type 'void *'
build_mmio_write(__writel, "l", unsigned int, "r", )
^
arch/x86/include/asm/io.h:53:20: note: in definition of macro
'build_mmio_write'
static inline void name(type val, volatile void __iomem *addr) \
^~~~
vim +/__writel +1083 drivers/net/ethernet/ti/davinci_cpdma.c
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1029
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1030 int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
aef614e1 drivers/net/ethernet/ti/davinci_cpdma.c Sebastian Siewior 2013-04-23
1031 int len, int directed)
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1032 {
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1033 struct cpdma_ctlr *ctlr = chan->ctlr;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1034 struct cpdma_desc __iomem *desc;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1035 dma_addr_t buffer;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1036 unsigned long flags;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1037 u32 mode;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1038 int ret = 0;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1039
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1040 spin_lock_irqsave(&chan->lock, flags);
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1041
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1042 if (chan->state == CPDMA_STATE_TEARDOWN) {
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1043 ret = -EINVAL;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1044 goto unlock_ret;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1045 }
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1046
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1047 if (chan->count >= chan->desc_num) {
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1048 chan->stats.desc_alloc_fail++;
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1049 ret = -ENOMEM;
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1050 goto unlock_ret;
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1051 }
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1052
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1053 desc = cpdma_desc_alloc(ctlr->pool);
ef8c
Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system
Hi Mike, Russ and Frank, On 09/28/17 at 07:10am, Mike Travis wrote: > > > On 9/28/2017 2:01 AM, Ingo Molnar wrote: > > > > * Baoquan He wrote: > > > > > > > @@ -123,7 +124,7 @@ void __init kernel_randomize_memory(void) > > > > > CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING; > > > > > /* Adapt phyiscal memory region size based on available memory > > > > > */ > > > > > - if (memory_tb < kaslr_regions[0].size_tb) > > > > > + if (memory_tb < kaslr_regions[0].size_tb && > > > > > !is_early_uv_system()) > > > > > kaslr_regions[0].size_tb = memory_tb; > > > > This is really an ugly hack. Is kaslr_regions[] incorrect? If so then > > > > it should be > > > > corrected instead of uglifying the code that uses it... > > > > > > Thanks for looking into this! > > > > > > If on SGI UV system, the kaslr_regions[0].size_tb, namely the size of > > > the direct mapping section, is incorrect. > > > > > > Its direct mapping size includes two parts: > > > #1 RAM size of system > > > #2 MMIOH region size which only SGI UV system has. > > > > > > However, the #2 can only be got till uv_system_init() is called in > > > native_smp_prepare_cpus(). That is too late for mm KASLR calculation. > > > That's why I made this hack. > > > > > > I checked uv_system_init() code, seems not easy to know the size of > > > MMIOH region before or inside kernel_randomize_memory(). I have CCed UV > > > devel experts, not sure if they have any idea about this. Otherwise, > > > this patch could be the only way I can think of. > > > > > > Hi Mike and Russ, > > > > > > Is there any chance we can get the size of MMIOH region before mm KASLR > > > code, namely before we call kernel_randomize_memory()? > > The sizes of the MMIOL and MMIOH areas are tied into the HUB design and how > it is communicated to BIOS and the kernel. This is via some of the config > MMR's found in the HUB and it would be impossible to provide any access to > these registers as they change with each new UV architecture. > > The kernel does reserve the memory in the EFI memmap. I can send you a > console log of the full startup that includes the MMIOH reservations. Note > that it is dependent on what I/O devices are actually present as UV does not > map empty slots unless forced (because we'd quickly run out of resources.) > Also, the EFI memmap entries do not specify the exact usage of the contained > areas. This one is still a regression bug in our newer rhel since I just fixed them with rhel-only patch. Now I still need the console log which includes the MMIOH reservations. Could you help provide a console log with MMIOH info, or I need request one from redhat's lab? Or expert from HPE UV team can make a patch based on the finding and analysis? Thanks Baoquan > > > > > I don't mind system specific quirks to hardware enumeration details, as > > long as > > they don't pollute generic code with such special hacks. > > > > I.e. in this case it's wrong to allow kaslr_regions[0].size_tb to be wrong. > > Any > > other code that relies on it in the future will be wrong as well on UV > > systems. > > Which may come into play on other arches with the new upcoming memory > technologies. > > > > The right quirk would be to fix that up where it gets introduced, or > > something > > like that. > > Yes, does make sense. > > > > Thanks, > > > > Ingo > >
Re: [PATCH v6] ANDROID: binder: change down_write to down_read
On Tue, May 15, 2018 at 03:27:32PM +0900, Minchan Kim wrote:
> Hi Joel,
>
> Sorry for the late response. I was off.
>
> On Wed, May 09, 2018 at 04:19:41PM -0700, Joel Fernandes wrote:
> > On Wed, May 09, 2018 at 03:40:23PM +0900, Minchan Kim wrote:
> > > On Tue, May 08, 2018 at 04:08:13PM -0700, Joel Fernandes wrote:
> > > > On Tue, May 08, 2018 at 07:51:01PM +0900, Minchan Kim wrote:
> > > > > On Mon, May 07, 2018 at 10:28:29AM -0700, Joel Fernandes wrote:
> > > > > > On Mon, May 07, 2018 at 11:15:37PM +0900, Minchan Kim wrote:
> > > > > > > binder_update_page_range needs down_write of mmap_sem because
> > > > > > > vm_insert_page need to change vma->vm_flags to VM_MIXEDMAP unless
> > > > > > > it is set. However, when I profile binder working, it seems
> > > > > > > every binder buffers should be mapped in advance by binder_mmap.
> > > > > > > It means we could set VM_MIXEDMAP in binder_mmap time which is
> > > > > > > already hold a mmap_sem as down_write so binder_update_page_range
> > > > > > > doesn't need to hold a mmap_sem as down_write.
> > > > > > > Please use proper API down_read. It would help mmap_sem contention
> > > > > > > problem as well as fixing down_write abuse.
> > > > > > >
> > > > > > > Ganesh Mahendran tested app launching and binder throughput test
> > > > > > > and he said he couldn't find any problem and I did binder latency
> > > > > > > test per Greg KH request(Thanks Martijn to teach me how I can do)
> > > > > > > I cannot find any problem, too.
> > > > > > >
> > > > > > > Cc: Ganesh Mahendran
> > > > > > > Cc: Joe Perches
> > > > > > > Cc: Arve Hjønnevåg
> > > > > > > Cc: Todd Kjos
> > > > > > > Cc: Greg Kroah-Hartman
> > > > > > > Reviewed-by: Martijn Coenen
> > > > > > > Signed-off-by: Minchan Kim
> > > > > > > ---
> > > > > > > drivers/android/binder.c | 4 +++-
> > > > > > > drivers/android/binder_alloc.c | 6 +++---
> > > > > > > 2 files changed, 6 insertions(+), 4 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > > > > > > index 4eab5be3d00f..7b8e96f60719 100644
> > > > > > > --- a/drivers/android/binder.c
> > > > > > > +++ b/drivers/android/binder.c
> > > > > > > @@ -4730,7 +4730,9 @@ static int binder_mmap(struct file *filp,
> > > > > > > struct vm_area_struct *vma)
> > > > > > > failure_string = "bad vm_flags";
> > > > > > > goto err_bad_arg;
> > > > > > > }
> > > > > > > - vma->vm_flags = (vma->vm_flags | VM_DONTCOPY) & ~VM_MAYWRITE;
> > > > > > > + vma->vm_flags |= VM_DONTCOPY | VM_MIXEDMAP;
> > > > > > > + vma->vm_flags &= ~VM_MAYWRITE;
> > > > > > > +
> > > > > > > vma->vm_ops = &binder_vm_ops;
> > > > > > > vma->vm_private_data = proc;
> > > > > > >
> > > > > > > diff --git a/drivers/android/binder_alloc.c
> > > > > > > b/drivers/android/binder_alloc.c
> > > > > > > index 5a426c877dfb..4f382d51def1 100644
> > > > > > > --- a/drivers/android/binder_alloc.c
> > > > > > > +++ b/drivers/android/binder_alloc.c
> > > > > > > @@ -219,7 +219,7 @@ static int binder_update_page_range(struct
> > > > > > > binder_alloc *alloc, int allocate,
> > > > > > > mm = alloc->vma_vm_mm;
> > > > > > >
> > > > > > > if (mm) {
> > > > > > > - down_write(&mm->mmap_sem);
> > > > > > > + down_read(&mm->mmap_sem);
> > > > > >
> > > > > >
> > > > > > Nice. Is there a need to hold the reader-lock at all here? Just
> > > > > > curious what
> > > > > > else is it protecting (here or in vm_insert_page).
> > > > >
> > > > > It should protect vm_area_struct. IOW, when we try insert page into
> > > > > virtual address area,
> > > > > vma shouldn't be changed(ie, unmap/collapse/split).
> > > >
> > > > When you say unmap, are you talking about pages being unmapped from the
> > > > VMA
> > > > or something else?
> > >
> > > I mean to destroy vm_area_struct itself as well as unmap pages.
> > >
> > > >
> > > > For the collapse/split part, the binder VMA (vm_area_struct) itself
> > > > isn't
> > > > changed after the initial mmap (AFAIK) so I don't see a need for
> > > > protection
> > > > there.
> > >
> > > There is no way to unmap in runtime? What happens if some buggy
> > > applications
> > > do unmap by mistake?
> > > Cannot we access those B's vma from A context?
> > > If B process is exiting, the VMA would be gone while A is accessing.
> >
> > If the VMA is gone, then why is it a good idea to map pages into it anyway?
>
> Hmm, sorry about that. I couldn't understand your point.
Sorry, I was just saying that we shouldn't hit a case where a process is dead
and we are trying to map pages into its VMA.
But considering this is a read mostly usecase, I think keeping the read lock
as you are doing would be fine for performance.
> > About the unmap at runtime part, your commit message was a bit confusing.
> > You
> > said "every binder buffers should be mapped in advance by binder_mmap." but
> > I
> > think the new binder shrinker mechanism doesn't
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
Hi Baoquan,
I have reviewed the patch, I think the caculation of address has no
problem. But maybe I miss something, so I have several questions.
On Wed, May 16, 2018 at 06:05:31PM +0800, Baoquan He wrote:
>Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to
>handle conflict between KASLR and huge pages, will be used in the next patch.
>
>Function parse_gb_huge_pages() is used to parse kernel command-line to get
>how many 1GB huge pages have been specified. A static global variable
>'max_gb_huge_pages' is added to store the number.
>
>And process_gb_huge_page() is used to skip as many 1GB huge pages as possible
>from the passed in memory region according to the specified number.
>
>Signed-off-by: Baoquan He
>---
> arch/x86/boot/compressed/kaslr.c | 71
> 1 file changed, 71 insertions(+)
>
>diff --git a/arch/x86/boot/compressed/kaslr.c
>b/arch/x86/boot/compressed/kaslr.c
>index a0a50b91ecef..13bd879cdc5d 100644
>--- a/arch/x86/boot/compressed/kaslr.c
>+++ b/arch/x86/boot/compressed/kaslr.c
>@@ -215,6 +215,32 @@ static void mem_avoid_memmap(char *str)
> memmap_too_large = true;
> }
>
>+/* Store the number of 1GB huge pages which user specified.*/
>+static unsigned long max_gb_huge_pages;
>+
>+static int parse_gb_huge_pages(char *param, char* val)
>+{
>+ char *p;
>+ u64 mem_size;
>+ static bool gbpage_sz = false;
>+
>+ if (!strcmp(param, "hugepagesz")) {
>+ p = val;
>+ mem_size = memparse(p, &p);
>+ if (mem_size == PUD_SIZE) {
>+ if (gbpage_sz)
>+ warn("Repeadly set hugeTLB page size of 1G!\n");
>+ gbpage_sz = true;
>+ } else
>+ gbpage_sz = false;
>+ } else if (!strcmp(param, "hugepages") && gbpage_sz) {
>+ p = val;
>+ max_gb_huge_pages = simple_strtoull(p, &p, 0);
>+ debug_putaddr(max_gb_huge_pages);
>+ }
>+}
>+
>+
> static int handle_mem_memmap(void)
> {
> char *args = (char *)get_cmd_line_ptr();
>@@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
>unsigned long image_size)
> }
> }
>
>+/* Skip as many 1GB huge pages as possible in the passed region. */
>+static void process_gb_huge_page(struct mem_vector *region, unsigned long
>image_size)
>+{
>+ int i = 0;
>+ unsigned long addr, size;
>+ struct mem_vector tmp;
>+
>+ if (!max_gb_huge_pages) {
>+ store_slot_info(region, image_size);
>+ return;
>+ }
>+
>+ addr = ALIGN(region->start, PUD_SIZE);
>+ /* If Did we raise the address above the passed in memory entry? */
>+ if (addr < region->start + region->size)
>+ size = region->size - (addr - region->start);
>+
>+ /* Check how many 1GB huge pages can be filtered out*/
>+ while (size > PUD_SIZE && max_gb_huge_pages) {
>+ size -= PUD_SIZE;
>+ max_gb_huge_pages--;
The global variable 'max_gb_huge_pages' means how many huge pages
user specified when you get it from command line.
But here, everytime we find a position which is good for huge page
allocation, the 'max_gdb_huge_page' decreased. So in my understanding,
it is used to store how many huge pages that we still need to search memory
for good slots to filter out, right?
If it's right, maybe the name 'max_gb_huge_pages' is not very suitable.
If my understanding is wrong, please tell me.
>+ i++;
>+ }
>+
>+ if (!i) {
>+ store_slot_info(region, image_size);
>+ return;
>+ }
>+
>+ /* Process the remaining regions after filtering out. */
>+
This line may be unusable.
>+ if (addr >= region->start + image_size) {
>+ tmp.start = region->start;
>+ tmp.size = addr - region->start;
>+ store_slot_info(&tmp, image_size);
>+ }
>+
>+ size = region->size - (addr - region->start) - i * PUD_SIZE;
>+if (size >= image_size) {
>+ tmp.start = addr + i*PUD_SIZE;
>+ tmp.size = size;
>+ store_slot_info(&tmp, image_size);
>+}
I have another question not related to kaslr.
Here you try to avoid the memory from addr to (addr + i * PUD_SIZE),
but I wonder if after walking all memory regions, 'max_gb_huge_pages'
is still more than 0, which means there isn't enough memory slots for
huge page, what will happen?
Thanks,
Chao Fan
>+}
>+
> static unsigned long slots_fetch_random(void)
> {
> unsigned long slot;
>--
>2.13.6
>
>
>
[PATCH v3] vfio/mdev: Check globally for duplicate devices
When we create an mdev device, we check for duplicates against the
parent device and return -EEXIST if found, but the mdev device
namespace is global since we'll link all devices from the bus. We do
catch this later in sysfs_do_create_link_sd() to return -EEXIST, but
with it comes a kernel warning and stack trace for trying to create
duplicate sysfs links, which makes it an undesirable response.
Therefore we should really be looking for duplicates across all mdev
parent devices, or as implemented here, against our mdev device list.
Using mdev_list to prevent duplicates means that we can remove
mdev_parent.lock, but in order not to serialize mdev device creation
and removal globally, we add mdev_device.active which allows UUIDs to
be reserved such that we can drop the mdev_list_lock before the mdev
device is fully in place.
NB. there was never intended to be any serialization guarantee
provided by the mdev core with respect to creation and removal of mdev
devices, mdev_parent.lock provided this only as a side-effect of the
implementation for locking the namespace per parent. That
serialization is now removed.
Signed-off-by: Alex Williamson
---
v3: Rework locking and add a field to mdev_device so we can track
completed instances vs those added to reserve the namespace.
drivers/vfio/mdev/mdev_core.c| 94 +-
drivers/vfio/mdev/mdev_private.h |2 -
2 files changed, 34 insertions(+), 62 deletions(-)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 126991046eb7..55ea9d34ec69 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -66,34 +66,6 @@ uuid_le mdev_uuid(struct mdev_device *mdev)
}
EXPORT_SYMBOL(mdev_uuid);
-static int _find_mdev_device(struct device *dev, void *data)
-{
- struct mdev_device *mdev;
-
- if (!dev_is_mdev(dev))
- return 0;
-
- mdev = to_mdev_device(dev);
-
- if (uuid_le_cmp(mdev->uuid, *(uuid_le *)data) == 0)
- return 1;
-
- return 0;
-}
-
-static bool mdev_device_exist(struct mdev_parent *parent, uuid_le uuid)
-{
- struct device *dev;
-
- dev = device_find_child(parent->dev, &uuid, _find_mdev_device);
- if (dev) {
- put_device(dev);
- return true;
- }
-
- return false;
-}
-
/* Should be called holding parent_list_lock */
static struct mdev_parent *__find_parent_device(struct device *dev)
{
@@ -221,7 +193,6 @@ int mdev_register_device(struct device *dev, const struct
mdev_parent_ops *ops)
}
kref_init(&parent->ref);
- mutex_init(&parent->lock);
parent->dev = dev;
parent->ops = ops;
@@ -304,7 +275,7 @@ static void mdev_device_release(struct device *dev)
int mdev_device_create(struct kobject *kobj, struct device *dev, uuid_le uuid)
{
int ret;
- struct mdev_device *mdev;
+ struct mdev_device *mdev, *tmp;
struct mdev_parent *parent;
struct mdev_type *type = to_mdev_type(kobj);
@@ -312,21 +283,26 @@ int mdev_device_create(struct kobject *kobj, struct
device *dev, uuid_le uuid)
if (!parent)
return -EINVAL;
- mutex_lock(&parent->lock);
+ mutex_lock(&mdev_list_lock);
/* Check for duplicate */
- if (mdev_device_exist(parent, uuid)) {
- ret = -EEXIST;
- goto create_err;
+ list_for_each_entry(tmp, &mdev_list, next) {
+ if (!uuid_le_cmp(tmp->uuid, uuid)) {
+ mutex_unlock(&mdev_list_lock);
+ return -EEXIST;
+ }
}
mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
if (!mdev) {
- ret = -ENOMEM;
- goto create_err;
+ mutex_unlock(&mdev_list_lock);
+ return -ENOMEM;
}
memcpy(&mdev->uuid, &uuid, sizeof(uuid_le));
+ list_add(&mdev->next, &mdev_list);
+ mutex_unlock(&mdev_list_lock);
+
mdev->parent = parent;
kref_init(&mdev->ref);
@@ -352,21 +328,18 @@ int mdev_device_create(struct kobject *kobj, struct
device *dev, uuid_le uuid)
}
mdev->type_kobj = kobj;
+ mdev->active = true;
dev_dbg(&mdev->dev, "MDEV: created\n");
- mutex_unlock(&parent->lock);
-
- mutex_lock(&mdev_list_lock);
- list_add(&mdev->next, &mdev_list);
- mutex_unlock(&mdev_list_lock);
-
- return ret;
+ return 0;
create_failed:
device_unregister(&mdev->dev);
create_err:
- mutex_unlock(&parent->lock);
+ mutex_lock(&mdev_list_lock);
+ list_del(&mdev->next);
+ mutex_unlock(&mdev_list_lock);
mdev_put_parent(parent);
return ret;
}
@@ -377,44 +350,43 @@ int mdev_device_remove(struct device *dev, bool
force_remove)
struct mdev_parent *parent;
struct mdev_type *type;
int ret;
- bool found = false;
m
Re: [PATCH v2] vfio/mdev: Check globally for duplicate devices
On Thu, 17 May 2018 01:01:40 +0530
Kirti Wankhede wrote:
> On 5/16/2018 8:53 PM, Alex Williamson wrote:
> > When we create an mdev device, we check for duplicates against the
> > parent device and return -EEXIST if found, but the mdev device
> > namespace is global since we'll link all devices from the bus. We do
> > catch this later in sysfs_do_create_link_sd() to return -EEXIST, but
> > with it comes a kernel warning and stack trace for trying to create
> > duplicate sysfs links, which makes it an undesirable response.
> >
> > Therefore we should really be looking for duplicates across all mdev
> > parent devices, or as implemented here, against our mdev device list.
> >
> > Notably, mdev_parent.lock really only seems to be serializing device
> > creation and removal per parent. I'm not sure if this is necessary,
> > mdev vendor drivers could easily provide this serialization if it
> > is required, but a side-effect of holding the mdev_list_lock to
> > protect the namespace is actually greater serialization across the
> > create and remove paths,
>
> Exactly for this reason more granular lock is used and that's the reason
> mdev_parent.lock was introduced. Consider the max supported config for
> vGPU: 8 GPUs in a system with 16 mdev devices on each GPUs, i.e. 128
> mdev devices need to be created in a system, and this count will
> increase in future, all mdev device creation/removal will get serialized
> with this change.
> I agree with your concern that if there are duplicates across parents,
> its not caught earlier.
Right, thus the concern, but how often are trying to simultaneously
create or remove all those mdev devices. Anyway...
> > so mdev_parent.lock is removed. If we can
> > show that vendor drivers handle the create/remove paths themselves,
> > perhaps we can refine the locking granularity.
> >
>
> Here lock is not for create/remove routines of vendor driver, its about
> mdev device creation and device registration, which is a common code
> path, and so is part of mdev core module.
Ok, if mdev_parent.lock was only to protect the per parent device
namespace and not meant as a serialization guarantee to the vendor
drivers, then we can fix the bug and improve the parallelism.
> > Reviewed-by: Cornelia Huck
> > Signed-off-by: Alex Williamson
> > ---
> >
> > v2: Remove unnecessary ret init per Cornelia's review
> >
> > drivers/vfio/mdev/mdev_core.c| 77
> > +-
> > drivers/vfio/mdev/mdev_private.h |1
> > 2 files changed, 19 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> > index 126991046eb7..aaab3ef93e1c 100644
> > --- a/drivers/vfio/mdev/mdev_core.c
> > +++ b/drivers/vfio/mdev/mdev_core.c
> > @@ -66,34 +66,6 @@ uuid_le mdev_uuid(struct mdev_device *mdev)
> > }
> > EXPORT_SYMBOL(mdev_uuid);
> >
> > -static int _find_mdev_device(struct device *dev, void *data)
> > -{
> > - struct mdev_device *mdev;
> > -
> > - if (!dev_is_mdev(dev))
> > - return 0;
> > -
> > - mdev = to_mdev_device(dev);
> > -
> > - if (uuid_le_cmp(mdev->uuid, *(uuid_le *)data) == 0)
> > - return 1;
> > -
> > - return 0;
> > -}
> > -
> > -static bool mdev_device_exist(struct mdev_parent *parent, uuid_le uuid)
> > -{
> > - struct device *dev;
> > -
> > - dev = device_find_child(parent->dev, &uuid, _find_mdev_device);
> > - if (dev) {
> > - put_device(dev);
> > - return true;
> > - }
> > -
> > - return false;
> > -}
> > -
> > /* Should be called holding parent_list_lock */
> > static struct mdev_parent *__find_parent_device(struct device *dev)
> > {
> > @@ -221,7 +193,6 @@ int mdev_register_device(struct device *dev, const
> > struct mdev_parent_ops *ops)
> > }
> >
> > kref_init(&parent->ref);
> > - mutex_init(&parent->lock);
> >
> > parent->dev = dev;
> > parent->ops = ops;
> > @@ -304,7 +275,7 @@ static void mdev_device_release(struct device *dev)
> > int mdev_device_create(struct kobject *kobj, struct device *dev, uuid_le
> > uuid)
> > {
> > int ret;
> > - struct mdev_device *mdev;
> > + struct mdev_device *mdev, *tmp;
> > struct mdev_parent *parent;
> > struct mdev_type *type = to_mdev_type(kobj);
> >
> > @@ -312,12 +283,14 @@ int mdev_device_create(struct kobject *kobj, struct
> > device *dev, uuid_le uuid)
> > if (!parent)
> > return -EINVAL;
> >
> > - mutex_lock(&parent->lock);
> > + mutex_lock(&mdev_list_lock);
> >
> > /* Check for duplicate */
> > - if (mdev_device_exist(parent, uuid)) {
> > - ret = -EEXIST;
> > - goto create_err;
> > + list_for_each_entry(tmp, &mdev_list, next) {
> > + if (!uuid_le_cmp(tmp->uuid, uuid)) {
> > + ret = -EEXIST;
> > + goto create_err;
> > + }
> > }
> >
> Is it possible to use mdev_list_lock for as minimal portion as possible?
> By a
Re: [PATCH net-next 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST
Hi Florian, I love your patch! Perhaps something to improve: [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Allow-more-drivers-with-COMPILE_TEST/20180517-092807 config: m68k-allyesconfig (attached as .config) compiler: m68k-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 make.cross ARCH=m68k All warnings (new ones prefixed by >>): In file included from include/linux/swab.h:5:0, from include/uapi/linux/byteorder/big_endian.h:13, from include/linux/byteorder/big_endian.h:5, from arch/m68k/include/uapi/asm/byteorder.h:5, from include/asm-generic/bitops/le.h:6, from arch/m68k/include/asm/bitops.h:519, from include/linux/bitops.h:38, from include/linux/kernel.h:11, from include/linux/list.h:9, from include/linux/module.h:9, from drivers/net/ethernet/freescale/fec_main.c:24: drivers/net/ethernet/freescale/fec_main.c: In function 'fec_restart': drivers/net/ethernet/freescale/fec_main.c:959:26: error: 'FEC_RACC' undeclared (first use in this function); did you mean 'FEC_RXIC0'? val = readl(fep->hwp + FEC_RACC); ^ include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32' (__builtin_constant_p((__u32)(x)) ? \ ^ >> include/linux/byteorder/generic.h:89:21: note: in expansion of macro >> '__le32_to_cpu' #define le32_to_cpu __le32_to_cpu ^ >> arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'in_le32' #define readl(addr) in_le32(addr) ^~~ >> drivers/net/ethernet/freescale/fec_main.c:959:9: note: in expansion of macro >> 'readl' val = readl(fep->hwp + FEC_RACC); ^ drivers/net/ethernet/freescale/fec_main.c:959:26: note: each undeclared identifier is reported only once for each function it appears in val = readl(fep->hwp + FEC_RACC); ^ include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32' (__builtin_constant_p((__u32)(x)) ? \ ^ >> include/linux/byteorder/generic.h:89:21: note: in expansion of macro >> '__le32_to_cpu' #define le32_to_cpu __le32_to_cpu ^ >> arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'in_le32' #define readl(addr) in_le32(addr) ^~~ >> drivers/net/ethernet/freescale/fec_main.c:959:9: note: in expansion of macro >> 'readl' val = readl(fep->hwp + FEC_RACC); ^ In file included from arch/m68k/include/asm/io_mm.h:27:0, from arch/m68k/include/asm/io.h:5, from include/linux/scatterlist.h:9, from include/linux/dma-mapping.h:11, from include/linux/skbuff.h:34, from include/linux/if_ether.h:23, from include/uapi/linux/ethtool.h:19, from include/linux/ethtool.h:18, from include/linux/netdevice.h:41, from drivers/net/ethernet/freescale/fec_main.c:34: drivers/net/ethernet/freescale/fec_main.c:968:38: error: 'FEC_FTRL' undeclared (first use in this function); did you mean 'FEC_ECNTRL'? writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL); ^ arch/m68k/include/asm/raw_io.h:48:64: note: in definition of macro 'out_le32' #define out_le32(addr,l) (void)((*(__force volatile __le32 *) (addr)) = cpu_to_le32(l)) ^~~~ >> drivers/net/ethernet/freescale/fec_main.c:968:3: note: in expansion of macro >> 'writel' writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL); ^~ drivers/net/ethernet/freescale/fec_main.c:1034:38: error: 'FEC_R_FIFO_RSEM' undeclared (first use in this function); did you mean 'FEC_FIFO_RAM'? writel(FEC_ENET_RSEM_V, fep->hwp + FEC_R_FIFO_RSEM); ^ arch/m68k/include/asm/raw_io.h:48:64: note: in definition of macro 'out_le32' #define out_le32(addr,l) (void)((*(__force volatile __le32 *) (addr)) = cpu_to_le32(l)) ^~~~ drivers/net/ethernet/freescale/fec_main.c:1034:3: note: in expansion of macro 'writel' writel(FEC_ENET_RSEM_V, fep->hwp + FEC_R_FIFO_RSEM); ^~ drivers/net/ethernet/freescale/fec_main.c:1035:38: error: 'FEC_R_FIFO_RSFL' undeclared (first u
include/linux/mlx5/driver.h:1299:13: error: 'struct irq_desc' has no member named 'affinity_hint'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e6506eb241871d68647c53cb6d0a16299550ae97
commit: 6082d9c9c94a408d7409b5f2e4e42ac9e8b16d0d net/mlx5: Fix
mlx5_get_vector_affinity function
date: 3 weeks ago
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 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 6082d9c9c94a408d7409b5f2e4e42ac9e8b16d0d
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All error/warnings (new ones prefixed by >>):
In file included from drivers/net//ethernet/mellanox/mlx5/core/main.c:43:0:
include/linux/mlx5/driver.h: In function 'mlx5_get_vector_affinity_hint':
>> include/linux/mlx5/driver.h:1299:13: error: 'struct irq_desc' has no member
>> named 'affinity_hint'
return desc->affinity_hint;
^~
--
In file included from include/linux/mlx5/port.h:36:0,
from drivers/infiniband/hw/mlx5/main.c:52:
include/linux/mlx5/driver.h: In function 'mlx5_get_vector_affinity_hint':
>> include/linux/mlx5/driver.h:1299:13: error: 'struct irq_desc' has no member
>> named 'affinity_hint'
return desc->affinity_hint;
^~
>> include/linux/mlx5/driver.h:1300:1: warning: control reaches end of non-void
>> function [-Wreturn-type]
}
^
vim +1299 include/linux/mlx5/driver.h
1285
1286 static inline const struct cpumask *
1287 mlx5_get_vector_affinity_hint(struct mlx5_core_dev *dev, int vector)
1288 {
1289 struct irq_desc *desc;
1290 unsigned int irq;
1291 int eqn;
1292 int err;
1293
1294 err = mlx5_vector2eqn(dev, vector, &eqn, &irq);
1295 if (err)
1296 return NULL;
1297
1298 desc = irq_to_desc(irq);
> 1299 return desc->affinity_hint;
> 1300 }
1301
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 1/3] rtc: vr41xx: remove mktime usage
On Wed, May 16, 2018 at 9:55 AM, Alexandre Belloni wrote: > Hi, > > On 20/04/2018 18:14:24+0200, Arnd Bergmann wrote: >> This driver uses mktime() and rtc_time_to_tm() to convert between time >> values. This works fine on 64-bit kernels over the whole supported >> range, and the vr41xx chip is a 64-bit MIPS implementation, but it is >> inconsistent because it doesn't do the same thing on 32-bit kernels that >> overflow in 2106 or 2038. >> >> Changing it to use mktime64/rtc_time64_to_tm() should have no visible >> impact on vr41xx but gets us closer to removing the 32-bit interfaces. >> >> Signed-off-by: Arnd Bergmann >> --- >> drivers/rtc/rtc-vr41xx.c | 24 >> 1 file changed, 12 insertions(+), 12 deletions(-) >> > > I've applied the series a while ago. Thanks! We should be able to remove mktime() in the near future then, along with some other interfaces from linux/time32.h and linux/timekeeping32.h. > It should be noted that mktime64 > will fail on 32bit platforms in year 21000 or so but I pretty sure it is > not worth fixing. My understanding is that the kernel will fail in April > 2262 anyway as ktime_t will overflow. Right. > Note that I will be following up with multiple series adding proper > rtc HW range, removing set_mmss and rtc_time_to_tm/rtc_tm_to_time64. Ok, looking forward to those patches! Arnd
[PATCH net-next] vmxnet3: Replace msleep(1) with usleep_range()
As documented in Documentation/timers/timers-howto.txt,
replace msleep(1) with usleep_range().
Signed-off-by: YueHaibing
---
drivers/net/vmxnet3/vmxnet3_drv.c | 6 +++---
drivers/net/vmxnet3/vmxnet3_ethtool.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index 9ebe2a6..2234a33 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2945,7 +2945,7 @@ vmxnet3_close(struct net_device *netdev)
* completion.
*/
while (test_and_set_bit(VMXNET3_STATE_BIT_RESETTING, &adapter->state))
- msleep(1);
+ usleep_range(1000, 2000);
vmxnet3_quiesce_dev(adapter);
@@ -2995,7 +2995,7 @@ vmxnet3_change_mtu(struct net_device *netdev, int new_mtu)
* completion.
*/
while (test_and_set_bit(VMXNET3_STATE_BIT_RESETTING, &adapter->state))
- msleep(1);
+ usleep_range(1000, 2000);
if (netif_running(netdev)) {
vmxnet3_quiesce_dev(adapter);
@@ -3567,7 +3567,7 @@ static void vmxnet3_shutdown_device(struct pci_dev *pdev)
* completion.
*/
while (test_and_set_bit(VMXNET3_STATE_BIT_RESETTING, &adapter->state))
- msleep(1);
+ usleep_range(1000, 2000);
if (test_and_set_bit(VMXNET3_STATE_BIT_QUIESCED,
&adapter->state)) {
diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c
b/drivers/net/vmxnet3/vmxnet3_ethtool.c
index 2ff2731..559db05 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
@@ -600,7 +600,7 @@ vmxnet3_set_ringparam(struct net_device *netdev,
* completion.
*/
while (test_and_set_bit(VMXNET3_STATE_BIT_RESETTING, &adapter->state))
- msleep(1);
+ usleep_range(1000, 2000);
if (netif_running(netdev)) {
vmxnet3_quiesce_dev(adapter);
--
2.7.0
Re: [PATCH v3 08/14] media: v4l: Add definitions for MPEG2 frame format and header metadata
Hi Florent,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.17-rc5 next-20180516]
[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/Paul-Kocialkowski/Sunxi-Cedrus-driver-for-the-Allwinner-Video-Engine-using-media-requests/20180508-004955
base: git://linuxtv.org/media_tree.git master
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> ./usr/include/linux/v4l2-controls.h:1082: found __[us]{8,16,32,64} type
>> without #include
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
linux-next: manual merge of the usb-gadget tree with the usb tree
Hi all,
Today's linux-next merge of the usb-gadget tree got a conflict in:
drivers/usb/mtu3/Kconfig
between commit:
cd91a0e9d38f ("usb: Remove depends on HAS_DMA in case of platform dependency")
from the usb tree and commit:
f39846824cd6 ("usb: mtu3: make USB_MTU3_DUAL_ROLE depend on EXTCON but not
USB_MTU3")
from the usb-gadget tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/usb/mtu3/Kconfig
index c0c0eb88e5ea,8daf2776..
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@@ -2,7 -2,7 +2,7 @@@
config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
- depends on EXTCON && (USB || USB_GADGET)
- depends on (USB || USB_GADGET) && HAS_DMA
++ depends on (USB || USB_GADGET)
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
pgptVbhbRm97G.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
Hi Chao,
On 05/17/18 at 11:27am, Chao Fan wrote:
> >+/* Store the number of 1GB huge pages which user specified.*/
> >+static unsigned long max_gb_huge_pages;
> >+
> >+static int parse_gb_huge_pages(char *param, char* val)
> >+{
> >+char *p;
> >+u64 mem_size;
> >+static bool gbpage_sz = false;
> >+
> >+if (!strcmp(param, "hugepagesz")) {
> >+p = val;
> >+mem_size = memparse(p, &p);
> >+if (mem_size == PUD_SIZE) {
> >+if (gbpage_sz)
> >+warn("Repeadly set hugeTLB page size of 1G!\n");
> >+gbpage_sz = true;
> >+} else
> >+gbpage_sz = false;
> >+} else if (!strcmp(param, "hugepages") && gbpage_sz) {
> >+p = val;
> >+max_gb_huge_pages = simple_strtoull(p, &p, 0);
> >+debug_putaddr(max_gb_huge_pages);
> >+}
> >+}
> >+
> >+
> > static int handle_mem_memmap(void)
> > {
> > char *args = (char *)get_cmd_line_ptr();
> >@@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
> >unsigned long image_size)
> > }
> > }
> >
> >+/* Skip as many 1GB huge pages as possible in the passed region. */
> >+static void process_gb_huge_page(struct mem_vector *region, unsigned long
> >image_size)
> >+{
> >+int i = 0;
> >+unsigned long addr, size;
> >+struct mem_vector tmp;
> >+
> >+if (!max_gb_huge_pages) {
> >+store_slot_info(region, image_size);
> >+return;
> >+}
> >+
> >+addr = ALIGN(region->start, PUD_SIZE);
> >+/* If Did we raise the address above the passed in memory entry? */
> >+if (addr < region->start + region->size)
> >+size = region->size - (addr - region->start);
> >+
> >+/* Check how many 1GB huge pages can be filtered out*/
> >+while (size > PUD_SIZE && max_gb_huge_pages) {
> >+size -= PUD_SIZE;
> >+max_gb_huge_pages--;
>
> The global variable 'max_gb_huge_pages' means how many huge pages
> user specified when you get it from command line.
> But here, everytime we find a position which is good for huge page
> allocation, the 'max_gdb_huge_page' decreased. So in my understanding,
> it is used to store how many huge pages that we still need to search memory
> for good slots to filter out, right?
> If it's right, maybe the name 'max_gb_huge_pages' is not very suitable.
> If my understanding is wrong, please tell me.
No, you have understood it very right. I finished the draft patch last
week, but changed this variable name and the function names several
time, still I feel they are not good. However I can't get a better name.
Yes, 'max_gb_huge_pages' stores how many 1GB huge pages are expected
from kernel command-line. And in this function it will be decreased. But
we can't define another global variable only for decreasing in this
place.
And you can see that in this patchset I only take cares of 1GB huge
pages. While on x86 we have two kinds of huge pages, 2MB and 1GB, why
1GB only? Because 2MB is not impacted by KASLR, please check the code in
hugetlb_nrpages_setup() of mm/hugetlb.c . Only 1GB huge pages need be
pre-allocated in hugetlb_nrpages_setup(), and if you look into
hugetlb_nrpages_setup(), you will find that it will call
alloc_bootmem_huge_page() to allocate huge pages one by one, but not at
one time. That is why I always add 'gb' in the middle of the global
variable and the newly added functions.
And it will answer your below questions. When walk over all memory
regions, 'max_gb_huge_pages' is still not 0, what should we do? It's
normal and done as expected. Here hugetlb only try its best to allocate
as many as possible according to 'max_gb_huge_pages'. If can't fully
satisfied, it's fine. E.g on bare-metal machine with 16GB RAM, you add
below to command-line:
default_hugepagesz=1G hugepagesz=1G hugepages=20
Then it will get 14 good 1GB huge pages with kaslr disabled since [0,1G)
and [3G,4G) are touched by bios reservation and pci/firmware reservation.
Then this 14 huge pages are maximal value which is expected. It's not a
bug in huge page. But with kaslr enabled, it sometime only get 13 1GB
huge pages because KASLR put kernel into one of those good 1GB huge
pages. This is a bug.
I am not very familiar with huge page handling, just read code recently
because of this kaslr bug. Hope Luiz and people from his team can help
correct and clarify if anything is not right. Especially the function
names, I feel it's not good, if anyone have a better idea, I will really
appreciate that.
>
> >+i++;
> >+}
> >+
> >+if (!i) {
> >+store_slot_info(region, image_size);
> >+return;
> >+}
> >+
> >+/* Process the remaining regions after filtering out. */
> >+
> This line may be unusable.
Hmm, I made it on purpose. Because 1GB huge pages may be digged out from
the middle, then the remaing head and tail regions still need be
handled. I put it here t
Re: [PATCH net-next 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST
Hi Florian, I love your patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Allow-more-drivers-with-COMPILE_TEST/20180517-092807 config: m68k-allmodconfig (attached as .config) compiler: m68k-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 make.cross ARCH=m68k All errors (new ones prefixed by >>): In file included from include/linux/swab.h:5:0, from include/uapi/linux/byteorder/big_endian.h:13, from include/linux/byteorder/big_endian.h:5, from arch/m68k/include/uapi/asm/byteorder.h:5, from include/asm-generic/bitops/le.h:6, from arch/m68k/include/asm/bitops.h:519, from include/linux/bitops.h:38, from include/linux/kernel.h:11, from include/linux/list.h:9, from include/linux/module.h:9, from drivers/net//ethernet/freescale/fec_main.c:24: drivers/net//ethernet/freescale/fec_main.c: In function 'fec_restart': >> drivers/net//ethernet/freescale/fec_main.c:959:26: error: 'FEC_RACC' >> undeclared (first use in this function); did you mean 'FEC_RXIC1'? val = readl(fep->hwp + FEC_RACC); ^ include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32' (__builtin_constant_p((__u32)(x)) ? \ ^ include/linux/byteorder/generic.h:89:21: note: in expansion of macro '__le32_to_cpu' #define le32_to_cpu __le32_to_cpu ^ arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'in_le32' #define readl(addr) in_le32(addr) ^~~ drivers/net//ethernet/freescale/fec_main.c:959:9: note: in expansion of macro 'readl' val = readl(fep->hwp + FEC_RACC); ^ drivers/net//ethernet/freescale/fec_main.c:959:26: note: each undeclared identifier is reported only once for each function it appears in val = readl(fep->hwp + FEC_RACC); ^ include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32' (__builtin_constant_p((__u32)(x)) ? \ ^ include/linux/byteorder/generic.h:89:21: note: in expansion of macro '__le32_to_cpu' #define le32_to_cpu __le32_to_cpu ^ arch/m68k/include/asm/io_mm.h:452:26: note: in expansion of macro 'in_le32' #define readl(addr) in_le32(addr) ^~~ drivers/net//ethernet/freescale/fec_main.c:959:9: note: in expansion of macro 'readl' val = readl(fep->hwp + FEC_RACC); ^ In file included from arch/m68k/include/asm/io_mm.h:27:0, from arch/m68k/include/asm/io.h:5, from include/linux/scatterlist.h:9, from include/linux/dma-mapping.h:11, from include/linux/skbuff.h:34, from include/linux/if_ether.h:23, from include/uapi/linux/ethtool.h:19, from include/linux/ethtool.h:18, from include/linux/netdevice.h:41, from drivers/net//ethernet/freescale/fec_main.c:34: drivers/net//ethernet/freescale/fec_main.c:968:38: error: 'FEC_FTRL' undeclared (first use in this function); did you mean 'FEC_ECNTRL'? writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL); ^ arch/m68k/include/asm/raw_io.h:48:64: note: in definition of macro 'out_le32' #define out_le32(addr,l) (void)((*(__force volatile __le32 *) (addr)) = cpu_to_le32(l)) ^~~~ drivers/net//ethernet/freescale/fec_main.c:968:3: note: in expansion of macro 'writel' writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL); ^~ drivers/net//ethernet/freescale/fec_main.c:1034:38: error: 'FEC_R_FIFO_RSEM' undeclared (first use in this function); did you mean 'FEC_FIFO_RAM'? writel(FEC_ENET_RSEM_V, fep->hwp + FEC_R_FIFO_RSEM); ^ arch/m68k/include/asm/raw_io.h:48:64: note: in definition of macro 'out_le32' #define out_le32(addr,l) (void)((*(__force volatile __le32 *) (addr)) = cpu_to_le32(l)) ^~~~ drivers/net//ethernet/freescale/fec_main.c:1034:3: note: in expansion of macro 'writel' writel(FEC_ENET_RSEM_V, fep->hwp + FEC_R_FIFO_RSEM); ^~ drivers/net//ethernet/freescale/fec_main.c:1035:38: error: 'FEC_R_FIFO_RSFL' undeclared (first use in th
Re: [PATCH 1/4] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
On 5/6/2018 3:44 PM, Alim Akhtar wrote:
In the right behavior, setting the bit to '0' indicates clear and
'1' indicates no change. If host controller handles this the other way,
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 21 +++--
drivers/scsi/ufs/ufshcd.h | 5 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 00e7905..9898ce5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -675,7 +675,24 @@ static inline void ufshcd_put_tm_slot(struct ufs_hba *hba,
int slot)
*/
static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)
{
- ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+ ufshcd_writel(hba, (1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+ else
+ ufshcd_writel(hba, ~(1 << pos),
+ REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+}
+
+/**
+ * ufshcd_utmrl_clear - Clear a bit in UTRMLCLR register
+ * @hba: per adapter instance
+ * @pos: position of the bit to be cleared
+ */
+static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos)
+{
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+ ufshcd_writel(hba, (1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
+ else
+ ufshcd_writel(hba, ~(1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
}
/**
@@ -5398,7 +5415,7 @@ static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int
tag)
goto out;
spin_lock_irqsave(hba->host->host_lock, flags);
- ufshcd_writel(hba, ~(1 << tag), REG_UTP_TASK_REQ_LIST_CLEAR);
+ ufshcd_utmrl_clear(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
/* poll for max. 1 sec to clear door bell register by h/w */
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 8110dcd..43035f8 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -595,6 +595,11 @@ struct ufs_hba {
*/
#define UFSHCD_QUIRK_PRDT_BYTE_GRAN 0x80
+ /*
+* Cleaer handling for transfer/task request list is just opposite.
+*/
Spell check - should be 'Clear'
+ #define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR0x100
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
/* Device deviations from standard UFS device spec. */
Looks good to me, except the spell-check.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: Grant
I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation: http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604 Reply as soon as possible with further directives. Best Regards, Mikhail Fridman.
Re: [PATCH] sched/rt: fix call to cpufreq_update_util
On 16-05-18, 20:18, Vincent Guittot wrote:
> With commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support")
> schedutil governor uses rq->rt.rt_nr_running to detect whether a RT task is
> currently running on the CPU and to set frequency to max if necessary.
> cpufreq_update_util() is called in enqueue/dequeue_top_rt_rq() but
> rq->rt.rt_nr_running as not been updated yet when dequeue_top_rt_rq() is
> called so schedutil still considers that a RT task is running when the
> last task is dequeued. The update of rq->rt.rt_nr_running happens later
> in dequeue_rt_stack()
>
> Fixes: 8f111bc357aa ('cpufreq/schedutil: Rewrite CPUFREQ_RT support')
> Cc: # v4.16+
> Signed-off-by: Vincent Guittot
> ---
> kernel/sched/rt.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 7aef6b4..6e74d3d 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -1001,8 +1001,6 @@ dequeue_top_rt_rq(struct rt_rq *rt_rq)
> sub_nr_running(rq, rt_rq->rt_nr_running);
> rt_rq->rt_queued = 0;
>
Remove this blank line as well ?
> - /* Kick cpufreq (see the comment in kernel/sched/sched.h). */
> - cpufreq_update_util(rq, 0);
> }
>
> static void
> @@ -1288,6 +1286,9 @@ static void dequeue_rt_stack(struct sched_rt_entity
> *rt_se, unsigned int flags)
> if (on_rt_rq(rt_se))
> __dequeue_rt_entity(rt_se, flags);
> }
> +
> + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */
> + cpufreq_update_util(rq_of_rt_rq(rt_rq_of_se(back)), 0);
> }
>
> static void enqueue_rt_entity(struct sched_rt_entity *rt_se, unsigned int
> flags)
> --
> 2.7.4
--
viresh
Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
On 16-05-18, 12:24, Florian Fainelli wrote: > On 05/15/2018 09:32 PM, Viresh Kumar wrote: > > On 15-05-18, 20:49, Markus Mayer wrote: > >> From: Markus Mayer > >> > >> Most CPUfreq drivers (at least on ARM) seem to be sorting the available > >> frequencies from lowest to highest. To match this behaviour, we reverse > >> the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to > >> highest. > > > > The reasoning isn't correct. Just because everyone else is doing it > > doesn't make it right and so you shouldn't change just because of > > that. > > > > What you must written instead in the commit log is that the cpufreq > > core performs better if the table is sorted (in any order), and so we > > must sort it as well. > > Is there a reason why set_freq_table_sorted() tries an ascending or > descending sort, but does not enforce one versus another for all drivers? set_freq_table_sorted() doesn't sort the frequency table but checks if the table is already sorted in a particular order. And then cpufreq_frequency_table_target() is optimized based on this flag. We don't have to enforce any particular ordering here. > > But I feel the table is already sorted for your platform, isn't it? > > And I don't see a clear advantage of merging this patch. > > The patch changes the order to have the lowest to highest, whereas the > current implementation has them from highest to lowest. From what you > are saying, it sounds like this is unnecessary, since the sorting is > already making things efficient enough, so this is just a cosmetic thing? Right. It shouldn't make any performance improvements. -- viresh
Re: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()
On Tue, May 15, 2018 at 05:49:59PM +0300, Kirill Tkhai wrote: > >> @@ -589,13 +647,7 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int > >> nid, > >>.memcg = memcg, > >>}; > >> > >> - /* > >> - * If kernel memory accounting is disabled, we ignore > >> - * SHRINKER_MEMCG_AWARE flag and call all shrinkers > >> - * passing NULL for memcg. > >> - */ > >> - if (memcg_kmem_enabled() && > >> - !!memcg != !!(shrinker->flags & SHRINKER_MEMCG_AWARE)) > >> + if (!!memcg != !!(shrinker->flags & SHRINKER_MEMCG_AWARE)) > >>continue; > > > > I want this check gone. It's easy to achieve, actually - just remove the > > following lines from shrink_node() > > > > if (global_reclaim(sc)) > > shrink_slab(sc->gfp_mask, pgdat->node_id, NULL, > > sc->priority); > > This check is not related to the patchset. Yes, it is. This patch modifies shrink_slab which is used only by shrink_node. Simplifying shrink_node along the way looks right to me. > Let's don't mix everything in the single series of patches, because > after your last remarks it will grow at least up to 15 patches. Most of which are trivial so I don't see any problem here. > This patchset can't be responsible for everything. I don't understand why you balk at simplifying the code a bit while you are patching related functions anyway. > > >> > >>if (!(shrinker->flags & SHRINKER_NUMA_AWARE)) > >>
linux-next: manual merge of the staging tree with the v4l-dvb tree
Hi all,
Today's linux-next merge of the staging tree got a conflict in:
drivers/staging/media/atomisp/TODO
between commit:
51b8dc5163d2 ("media: staging: atomisp: Remove driver")
from the v4l-dvb tree and commit:
1bd421154821 ("staging: atomisp: Augment TODO file with GPIO work item")
from the staging tree.
I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpn0MlNOAqLq.pgp
Description: OpenPGP digital signature
Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"
On 15-05-18, 11:50, Frank Mori Hess wrote: > On Tue, May 15, 2018 at 2:21 AM, Vinod wrote: > > > > For Pause/resume data loss is _not_ expected. > > > >> > and some of the 8250 drivers like 8250_dw.c set a maxburst > 1. If it > >> > can't count on the pause/residue/terminate working without data loss > >> > then it is just broken. As is the 8250_omap.c driver. Is the > >> > description of dmaengine_pause in the documentation of "This pauses > >> > activity on the DMA channel without data loss" to be interpreted as > >> > "as long as you resume afterwards"? > >> > >> I assume that this requirement is for both - resuming and terminating. > > > > Terminate is abort, data loss may happen here. > > Wait, are you saying if you do > > dma pause no data loss > read residue here as well > dma terminate Oh yes, we aborted... > > then it is acceptable for there to be data loss, because it can be > blamed on the terminate? In that case the usage of dmaengine in all > the 8250 serial drivers is broken. Every time there is a break in the > incoming rx data, the 8250 driver does pause/residue/terminate which > could potentially cause data from the incoming data stream to be > dropped. As I said terminate is abort. It cleans up the channel and is supposed to used for cleanup not for stopping. See Documentation: - device_terminate_all - Aborts all the pending and ongoing transfers on the channel - For aborted transfers the complete callback should not be called - Can be called from atomic context or from within a complete callback of a descriptor. Must not sleep. Drivers must be able to handle this correctly. - Termination may be asynchronous. The driver does not have to wait until the currently active transfer has completely stopped. See device_synchronize. Thanks -- ~Vinod
[PATCH] of: overlay: validate offset from property fixups
From: Frank Rowand
The smatch static checker marks the data in offset as untrusted,
leading it to warn:
drivers/of/resolver.c:125 update_usages_of_a_phandle_reference()
error: buffer underflow 'prop->value' 's32min-s32max'
Add check to verify that offset is within the property data.
Reported-by: Dan Carpenter
Signed-off-by: Frank Rowand
---
drivers/of/resolver.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 65d0b7adfcd4..7edfac6f1914 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -122,6 +122,11 @@ static int update_usages_of_a_phandle_reference(struct
device_node *overlay,
goto err_fail;
}
+ if (offset < 0 || offset + sizeof(__be32) > prop->length) {
+ err = -EINVAL;
+ goto err_fail;
+ }
+
*(__be32 *)(prop->value + offset) = cpu_to_be32(phandle);
}
--
Frank Rowand
Re: [PATCH net-next 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST
Hi Florian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Allow-more-drivers-with-COMPILE_TEST/20180517-092807
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 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
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
drivers/net//ethernet/ti/davinci_cpdma.c: In function 'cpdma_chan_submit':
>> drivers/net//ethernet/ti/davinci_cpdma.c:1083:17: warning: passing argument
>> 1 of 'writel_relaxed' makes integer from pointer without a cast
>> [-Wint-conversion]
writel_relaxed(token, &desc->sw_token);
^
In file included from arch/xtensa/include/asm/io.h:83:0,
from include/linux/scatterlist.h:9,
from include/linux/dma-mapping.h:11,
from drivers/net//ethernet/ti/davinci_cpdma.c:21:
include/asm-generic/io.h:303:24: note: expected 'u32 {aka unsigned int}' but
argument is of type 'void *'
#define writel_relaxed writel_relaxed
^
>> include/asm-generic/io.h:304:20: note: in expansion of macro 'writel_relaxed'
static inline void writel_relaxed(u32 value, volatile void __iomem *addr)
^~
--
drivers/net/ethernet/ti/davinci_cpdma.c: In function 'cpdma_chan_submit':
drivers/net/ethernet/ti/davinci_cpdma.c:1083:17: warning: passing argument 1
of 'writel_relaxed' makes integer from pointer without a cast [-Wint-conversion]
writel_relaxed(token, &desc->sw_token);
^
In file included from arch/xtensa/include/asm/io.h:83:0,
from include/linux/scatterlist.h:9,
from include/linux/dma-mapping.h:11,
from drivers/net/ethernet/ti/davinci_cpdma.c:21:
include/asm-generic/io.h:303:24: note: expected 'u32 {aka unsigned int}' but
argument is of type 'void *'
#define writel_relaxed writel_relaxed
^
>> include/asm-generic/io.h:304:20: note: in expansion of macro 'writel_relaxed'
static inline void writel_relaxed(u32 value, volatile void __iomem *addr)
^~
vim +/writel_relaxed +1083 drivers/net//ethernet/ti/davinci_cpdma.c
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1029
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1030 int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
aef614e1 drivers/net/ethernet/ti/davinci_cpdma.c Sebastian Siewior 2013-04-23
1031 int len, int directed)
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1032 {
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1033 struct cpdma_ctlr *ctlr = chan->ctlr;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1034 struct cpdma_desc __iomem *desc;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1035 dma_addr_t buffer;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1036 unsigned long flags;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1037 u32 mode;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1038 int ret = 0;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1039
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1040 spin_lock_irqsave(&chan->lock, flags);
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1041
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1042 if (chan->state == CPDMA_STATE_TEARDOWN) {
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1043 ret = -EINVAL;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1044 goto unlock_ret;
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1045 }
ef8c2dab drivers/net/davinci_cpdma.c Cyril Chemparathy 2010-09-15
1046
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1047 if (chan->count >= chan->desc_num) {
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1048 chan->stats.desc_alloc_fail++;
742fb20f drivers/net/ethernet/ti/davinci_cpdma.c Grygorii Strashko 2016-06-27
1049 ret = -ENOMEM;
Re: [PATCH v7] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter
Hi,
Le 16/05/2018 à 09:56, Boris Brezillon a écrit :
On Wed, 16 May 2018 09:32:57 +0200
Chris Moore wrote:
Hi,
Le 15/05/2018 à 09:34, Boris Brezillon a écrit :
On Tue, 15 May 2018 06:45:51 +0200
Chris Moore wrote:
Hi,
Le 13/05/2018 à 06:30, Wan, Jane (Nokia - US/Sunnyvale) a écrit :
Per ONFI specification (Rev. 4.0), if all parameter pages have invalid CRC
values, the bit-wise majority may be used to recover the contents of the
parameter pages from the parameter page copies present.
Signed-off-by: Jane Wan
---
v7: change debug print messages
v6: support the cases that srcbufs are not contiguous
v5: make the bit-wise majority functon generic
v4: move the bit-wise majority code in a separate function
v3: fix warning message detected by kbuild test robot
v2: rebase the changes on top of v4.17-rc1
drivers/mtd/nand/raw/nand_base.c | 50 ++
1 file changed, 45 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89..b43b784 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5087,6 +5087,35 @@ static int nand_flash_detect_ext_param_page(struct
nand_chip *chip,
}
/*
+ * Recover data with bit-wise majority
+ */
+static void nand_bit_wise_majority(const void **srcbufs,
+ unsigned int nsrcbufs,
+ void *dstbuf,
+ unsigned int bufsize)
+{
+ int i, j, k;
+
+ for (i = 0; i < bufsize; i++) {
+ u8 cnt, val;
+
+ val = 0;
+ for (j = 0; j < 8; j++) {
+ cnt = 0;
+ for (k = 0; k < nsrcbufs; k++) {
+ const u8 *srcbuf = srcbufs[k];
+
+ if (srcbuf[i] & BIT(j))
+ cnt++;
+ }
+ if (cnt > nsrcbufs / 2)
+ val |= BIT(j);
+ }
+ ((u8 *)dstbuf)[i] = val;
+ }
+}
+
+/*
* Check if the NAND chip is ONFI compliant, returns 1 if it is, 0
otherwise.
*/
static int nand_flash_detect_onfi(struct nand_chip *chip)
@@ -5102,7 +5131,7 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
return 0;
/* ONFI chip: allocate a buffer to hold its parameter page */
- p = kzalloc(sizeof(*p), GFP_KERNEL);
+ p = kzalloc((sizeof(*p) * 3), GFP_KERNEL);
if (!p)
return -ENOMEM;
@@ -5113,21 +5142,32 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
}
for (i = 0; i < 3; i++) {
- ret = nand_read_data_op(chip, p, sizeof(*p), true);
+ ret = nand_read_data_op(chip, &p[i], sizeof(*p), true);
if (ret) {
ret = 0;
goto free_onfi_param_page;
}
- if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
+ if (onfi_crc16(ONFI_CRC_BASE, (u8 *)&p[i], 254) ==
le16_to_cpu(p->crc)) {
+ if (i)
+ memcpy(p, &p[i], sizeof(*p));
break;
}
}
if (i == 3) {
- pr_err("Could not find valid ONFI parameter page; aborting\n");
- goto free_onfi_param_page;
+ const void *srcbufs[3] = {p, p + 1, p + 2};
+
+ pr_warn("Could not find a valid ONFI parameter page, trying bit-wise
majority to recover it\n");
+ nand_bit_wise_majority(srcbufs, ARRAY_SIZE(srcbufs), p,
+ sizeof(*p));
+
+ if (onfi_crc16(ONFI_CRC_BASE, (u8 *)p, 254) !=
+ le16_to_cpu(p->crc)) {
+ pr_err("ONFI parameter recovery failed, aborting\n");
+ goto free_onfi_param_page;
+ }
}
/* Check version */
This version is still hard coded for a three sample bitwise majority vote.
So why not use the method which I suggested previously for v2 and which
I repeat below?
Because I want the nand_bit_wise_majority() function to work with
nsrcbufs > 3 (the ONFI spec says there's at least 3 copy of the param
page, but NAND vendor can decide to put more). Also, if the X copies of
the PARAM are corrupted (which is rather unlikely), that means we
already spent quite a lot of time reading the different copies and
calculating the CRC, so I think we don't care about perf optimizations
when doing bit-wise majority.
The three sample bitwise majority can be implemented without bit level
manipulation using the identity:
majority3(a, b, c) = (a & b) | (a & c) | (b & c)
This can be factorized slightly to (a & (b | c)) | (b & c)
This enables the operation to be performed 8, 16, 32 or
Re: [PATCH v5 11/13] mm: Iterate only over charged shrinkers during memcg shrink_slab()
On Tue, May 15, 2018 at 01:12:20PM +0300, Kirill Tkhai wrote:
> >> +#define root_mem_cgroup NULL
> >
> > Let's instead export mem_cgroup_is_root(). In case if MEMCG is disabled
> > it will always return false.
>
> export == move to header file
That and adding a stub function in case !MEMCG.
> >> +static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
> >> + struct mem_cgroup *memcg, int priority)
> >> +{
> >> + struct memcg_shrinker_map *map;
> >> + unsigned long freed = 0;
> >> + int ret, i;
> >> +
> >> + if (!memcg_kmem_enabled() || !mem_cgroup_online(memcg))
> >> + return 0;
> >> +
> >> + if (!down_read_trylock(&shrinker_rwsem))
> >> + return 0;
> >> +
> >> + /*
> >> + * 1)Caller passes only alive memcg, so map can't be NULL.
> >> + * 2)shrinker_rwsem protects from maps expanding.
> >
> > ^^
> > Nit: space missing here :-)
>
> I don't understand what you mean here. Please, clarify...
This is just a trivial remark regarding comment formatting. They usually
put a space between the number and the first word in the sentence, i.e.
between '1)' and 'Caller' in your case.
>
> >> + */
> >> + map = rcu_dereference_protected(MEMCG_SHRINKER_MAP(memcg, nid), true);
> >> + BUG_ON(!map);
> >> +
> >> + for_each_set_bit(i, map->map, memcg_shrinker_nr_max) {
> >> + struct shrink_control sc = {
> >> + .gfp_mask = gfp_mask,
> >> + .nid = nid,
> >> + .memcg = memcg,
> >> + };
> >> + struct shrinker *shrinker;
> >> +
> >> + shrinker = idr_find(&shrinker_idr, i);
> >> + if (!shrinker) {
> >> + clear_bit(i, map->map);
> >> + continue;
> >> + }
> >> + if (list_empty(&shrinker->list))
> >> + continue;
> >
> > I don't like using shrinker->list as an indicator that the shrinker has
> > been initialized. IMO if you do need such a check, you should split
> > shrinker_idr registration in two steps - allocate a slot in 'prealloc'
> > and set the pointer in 'register'. However, can we really encounter an
> > unregistered shrinker here? AFAIU a bit can be set in the shrinker map
> > only after the corresponding shrinker has been initialized, no?
>
> 1)No, it's not so. Here is a race:
> cpu#0cpu#1 cpu#2
> prealloc_shrinker()
> prealloc_shrinker()
>memcg_expand_shrinker_maps()
> memcg_expand_one_shrinker_map()
>memset(&new->map, 0xff);
>
> do_shrink_slab() (on uninitialized LRUs)
> init LRUs
> register_shrinker_prepared()
>
> So, the check is needed.
OK, I see.
>
> 2)Assigning NULL pointer can't be used here, since NULL pointer is already
> used
> to clear unregistered shrinkers from the map. See the check right after
> idr_find().
But it won't break anything if we clear bit for prealloc-ed, but not yet
registered shrinkers, will it?
>
> list_empty() is used since it's the already existing indicator, which does not
> require additional member in struct shrinker.
It just looks rather counter-intuitive to me to use shrinker->list to
differentiate between registered and unregistered shrinkers. May be, I'm
wrong. If you are sure that this is OK, I'm fine with it, but then
please add a comment here explaining what this check is needed for.
Thanks.
[PATCHSET] workqueue: Show the latest workqueue name in /proc/PID/{comm,stat,status}
There can be a lot of workqueue workers and they all show up with the
cryptic kworker/* names making it difficult to understand which is
doing what and how they came to be.
# ps -ef | grep kworker
root 4 2 0 Feb25 ?00:00:00 [kworker/0:0H]
root 6 2 0 Feb25 ?00:00:00 [kworker/u112:0]
root 19 2 0 Feb25 ?00:00:00 [kworker/1:0H]
root 25 2 0 Feb25 ?00:00:00 [kworker/2:0H]
root 31 2 0 Feb25 ?00:00:00 [kworker/3:0H]
...
This patchset makes workqueue workers report the latest workqueue it
was executing for through /proc/PID/{comm,stat,status}. The extra
information is appended to the kthread name with intervening '+' if
currently executing, otherwise '-'.
# cat /proc/25/comm
kworker/2:0-events_power_efficient
# cat /proc/25/stat
25 (kworker/2:0-events_power_efficient) I 2 0 0 0 -1 69238880 0 0...
# grep Name /proc/25/status
Name: kworker/2:0-events_power_efficient
For details on the design decisions, please refer to the following
thread.
http://lkml.kernel.org/r/20180516153939.gh2368...@devbig577.frc2.facebook.com
This patchset contains the following six patches.
0001-proc-Don-t-allow-empty-proc-PID-cmdline-for-user-tas.patch
0002-workqueue-Replace-pool-attach_mutex-with-global-wq_p.patch
0003-workqueue-Make-worker_attach-detach_pool-update-work.patch
0004-workqueue-Set-worker-desc-to-workqueue-name-by-defau.patch
0005-proc-Consolidate-task-comm-formatting-into-proc_task.patch
0006-workqueue-Show-the-latest-workqueue-name-in-proc-PID.patch
I'm applying the patches to wq/for-4.18. Please let me know if the
patchset need updates (the branch doesn't have any other changes
anyway). diffstat follows. Thanks.
fs/proc/array.c | 33 +++-
fs/proc/base.c | 27 +++---
fs/proc/internal.h |2
include/linux/workqueue.h |1
kernel/workqueue.c | 117
kernel/workqueue_internal.h |3 -
6 files changed, 122 insertions(+), 61 deletions(-)
--
tejun
[PATCH 6/6] workqueue: Show the latest workqueue name in /proc/PID/{comm,stat,status}
There can be a lot of workqueue workers and they all show up with the
cryptic kworker/* names making it difficult to understand which is
doing what and how they came to be.
# ps -ef | grep kworker
root 4 2 0 Feb25 ?00:00:00 [kworker/0:0H]
root 6 2 0 Feb25 ?00:00:00 [kworker/u112:0]
root 19 2 0 Feb25 ?00:00:00 [kworker/1:0H]
root 25 2 0 Feb25 ?00:00:00 [kworker/2:0H]
root 31 2 0 Feb25 ?00:00:00 [kworker/3:0H]
...
This patch makes workqueue workers report the latest workqueue it was
executing for through /proc/PID/{comm,stat,status}. The extra
information is appended to the kthread name with intervening '+' if
currently executing, otherwise '-'.
# cat /proc/25/comm
kworker/2:0-events_power_efficient
# cat /proc/25/stat
25 (kworker/2:0-events_power_efficient) I 2 0 0 0 -1 69238880 0 0...
# grep Name /proc/25/status
Name: kworker/2:0-events_power_efficient
Unfortunately, ps(1) truncates comm to 15 characters,
# ps 25
PID TTY STAT TIME COMMAND
25 ?I 0:00 [kworker/2:0-eve]
making it a lot less useful; however, this should be an easy fix from
ps(1) side.
Signed-off-by: Tejun Heo
Suggested-by: Linus Torvalds
Cc: Craig Small
---
fs/proc/array.c | 7 +--
include/linux/workqueue.h | 1 +
kernel/workqueue.c| 39 +++
3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index f29221e..bb1d361 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -99,10 +99,13 @@ void proc_task_name(struct seq_file *m, struct task_struct
*p, bool escape)
{
char *buf;
size_t size;
- char tcomm[sizeof(p->comm)];
+ char tcomm[64];
int ret;
- get_task_comm(tcomm, p);
+ if (p->flags & PF_WQ_WORKER)
+ wq_worker_comm(tcomm, sizeof(tcomm), p);
+ else
+ __get_task_comm(tcomm, sizeof(tcomm), p);
size = seq_get_buf(m, &buf);
if (escape) {
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 39a0e21..60d673e 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -494,6 +494,7 @@ extern unsigned int work_busy(struct work_struct *work);
extern __printf(1, 2) void set_worker_desc(const char *fmt, ...);
extern void print_worker_info(const char *log_lvl, struct task_struct *task);
extern void show_workqueue_state(void);
+extern void wq_worker_comm(char *buf, size_t size, struct task_struct *task);
/**
* queue_work - queue work on a workqueue
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 3fbe007..b4a39a1 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4577,6 +4577,45 @@ void show_workqueue_state(void)
rcu_read_unlock_sched();
}
+/* used to show worker information through /proc/PID/{comm,stat,status} */
+void wq_worker_comm(char *buf, size_t size, struct task_struct *task)
+{
+ struct worker *worker;
+ struct worker_pool *pool;
+ int off;
+
+ /* always show the actual comm */
+ off = strscpy(buf, task->comm, size);
+ if (off < 0)
+ return;
+
+ /* stabilize worker pool association */
+ mutex_lock(&wq_pool_attach_mutex);
+
+ worker = kthread_data(task);
+ pool = worker->pool;
+
+ if (pool) {
+ spin_lock_irq(&pool->lock);
+ /*
+* ->desc tracks information (wq name or set_worker_desc())
+* for the latest execution. If current, prepend '+',
+* otherwise '-'.
+*/
+ if (worker->desc[0] != '\0') {
+ if (worker->current_work)
+ scnprintf(buf + off, size - off, "+%s",
+ worker->desc);
+ else
+ scnprintf(buf + off, size - off, "-%s",
+ worker->desc);
+ }
+ spin_unlock_irq(&pool->lock);
+ }
+
+ mutex_unlock(&wq_pool_attach_mutex);
+}
+
/*
* CPU hotplug.
*
--
2.9.5
[PATCH 4/6] workqueue: Set worker->desc to workqueue name by default
Work functions can use set_worker_desc() to improve the visibility of
what the worker task is doing. Currently, the desc field is unset at
the beginning of each execution and there is a separate field to track
the field is set during the current execution.
Instead of leaving empty till desc is set, worker->desc can be used to
remember the last workqueue the worker worked on by default and users
that use set_worker_desc() can override it to something more
informative as necessary.
This simplifies desc handling and helps tracking the last workqueue
that the worker exected on to improve visibility.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 21 ++---
kernel/workqueue_internal.h | 1 -
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 2fde50f..3fbe007 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2088,6 +2088,12 @@ __acquires(&pool->lock)
worker->current_pwq = pwq;
work_color = get_work_color(work);
+ /*
+* Record wq name for cmdline and debug reporting, may get
+* overridden through set_worker_desc().
+*/
+ strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
+
list_del_init(&work->entry);
/*
@@ -2183,7 +2189,6 @@ __acquires(&pool->lock)
worker->current_work = NULL;
worker->current_func = NULL;
worker->current_pwq = NULL;
- worker->desc_valid = false;
pwq_dec_nr_in_flight(pwq, work_color);
}
@@ -4346,7 +4351,6 @@ void set_worker_desc(const char *fmt, ...)
va_start(args, fmt);
vsnprintf(worker->desc, sizeof(worker->desc), fmt, args);
va_end(args);
- worker->desc_valid = true;
}
}
@@ -4370,7 +4374,6 @@ void print_worker_info(const char *log_lvl, struct
task_struct *task)
char desc[WORKER_DESC_LEN] = { };
struct pool_workqueue *pwq = NULL;
struct workqueue_struct *wq = NULL;
- bool desc_valid = false;
struct worker *worker;
if (!(task->flags & PF_WQ_WORKER))
@@ -4383,22 +4386,18 @@ void print_worker_info(const char *log_lvl, struct
task_struct *task)
worker = kthread_probe_data(task);
/*
-* Carefully copy the associated workqueue's workfn and name. Keep
-* the original last '\0' in case the original contains garbage.
+* Carefully copy the associated workqueue's workfn, name and desc.
+* Keep the original last '\0' in case the original is garbage.
*/
probe_kernel_read(&fn, &worker->current_func, sizeof(fn));
probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
probe_kernel_read(name, wq->name, sizeof(name) - 1);
-
- /* copy worker description */
- probe_kernel_read(&desc_valid, &worker->desc_valid, sizeof(desc_valid));
- if (desc_valid)
- probe_kernel_read(desc, worker->desc, sizeof(desc) - 1);
+ probe_kernel_read(desc, worker->desc, sizeof(desc) - 1);
if (fn || name[0] || desc[0]) {
printk("%sWorkqueue: %s %pf", log_lvl, name, fn);
- if (desc[0])
+ if (strcmp(name, desc))
pr_cont(" (%s)", desc);
pr_cont("\n");
}
diff --git a/kernel/workqueue_internal.h b/kernel/workqueue_internal.h
index 4a182e0..66fbb5a 100644
--- a/kernel/workqueue_internal.h
+++ b/kernel/workqueue_internal.h
@@ -31,7 +31,6 @@ struct worker {
struct work_struct *current_work; /* L: work being processed */
work_func_t current_func; /* L: current_work's fn */
struct pool_workqueue *current_pwq; /* L: current_work's pwq */
- booldesc_valid; /* ->desc is valid */
struct list_headscheduled; /* L: scheduled works */
/* 64 bytes boundary on 64bit, 32 on 32bit */
--
2.9.5
[PATCH 5/6] proc: Consolidate task->comm formatting into proc_task_name()
proc shows task->comm in three places - comm, stat, status - and each
is fetching and formatting task->comm slighly differently. This patch
renames task_name() to proc_task_name(), makes it more generic, and
updates all three paths to use it.
This will enable expanding comm reporting for workqueue workers.
Signed-off-by: Tejun Heo
---
fs/proc/array.c| 26 +++---
fs/proc/base.c | 5 ++---
fs/proc/internal.h | 2 ++
3 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index ae2c807..f29221e 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -95,7 +95,7 @@
#include
#include "internal.h"
-static inline void task_name(struct seq_file *m, struct task_struct *p)
+void proc_task_name(struct seq_file *m, struct task_struct *p, bool escape)
{
char *buf;
size_t size;
@@ -104,13 +104,17 @@ static inline void task_name(struct seq_file *m, struct
task_struct *p)
get_task_comm(tcomm, p);
- seq_puts(m, "Name:\t");
-
size = seq_get_buf(m, &buf);
- ret = string_escape_str(tcomm, buf, size, ESCAPE_SPACE |
ESCAPE_SPECIAL, "\n\\");
- seq_commit(m, ret < size ? ret : -1);
+ if (escape) {
+ ret = string_escape_str(tcomm, buf, size,
+ ESCAPE_SPACE | ESCAPE_SPECIAL, "\n\\");
+ if (ret >= size)
+ ret = -1;
+ } else {
+ ret = strscpy(buf, tcomm, size);
+ }
- seq_putc(m, '\n');
+ seq_commit(m, ret);
}
/*
@@ -365,7 +369,10 @@ int proc_pid_status(struct seq_file *m, struct
pid_namespace *ns,
{
struct mm_struct *mm = get_task_mm(task);
- task_name(m, task);
+ seq_puts(m, "Name:\t");
+ proc_task_name(m, task, true);
+ seq_putc(m, '\n');
+
task_state(m, ns, pid, task);
if (mm) {
@@ -400,7 +407,6 @@ static int do_task_stat(struct seq_file *m, struct
pid_namespace *ns,
u64 cutime, cstime, utime, stime;
u64 cgtime, gtime;
unsigned long rsslim = 0;
- char tcomm[sizeof(task->comm)];
unsigned long flags;
state = *get_task_state(task);
@@ -427,8 +433,6 @@ static int do_task_stat(struct seq_file *m, struct
pid_namespace *ns,
}
}
- get_task_comm(tcomm, task);
-
sigemptyset(&sigign);
sigemptyset(&sigcatch);
cutime = cstime = utime = stime = 0;
@@ -495,7 +499,7 @@ static int do_task_stat(struct seq_file *m, struct
pid_namespace *ns,
seq_put_decimal_ull(m, "", pid_nr_ns(pid, ns));
seq_puts(m, " (");
- seq_puts(m, tcomm);
+ proc_task_name(m, task, false);
seq_puts(m, ") ");
seq_putc(m, state);
seq_put_decimal_ll(m, " ", ppid);
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 2eee4d7..eb17917ca 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1581,9 +1581,8 @@ static int comm_show(struct seq_file *m, void *v)
if (!p)
return -ESRCH;
- task_lock(p);
- seq_printf(m, "%s\n", p->comm);
- task_unlock(p);
+ proc_task_name(m, p, false);
+ seq_putc(m, '\n');
put_task_struct(p);
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 0f1692e..b823fac62 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -131,6 +131,8 @@ unsigned name_to_int(const struct qstr *qstr);
*/
extern const struct file_operations proc_tid_children_operations;
+extern void proc_task_name(struct seq_file *m, struct task_struct *p,
+ bool escape);
extern int proc_tid_stat(struct seq_file *, struct pid_namespace *,
struct pid *, struct task_struct *);
extern int proc_tgid_stat(struct seq_file *, struct pid_namespace *,
--
2.9.5
[PATCH 1/6] proc: Don't allow empty /proc/PID/cmdline for user tasks
Kernel threads have empty /proc/PID/cmdline and some userland tools
including ps(1) and older versions of systemd use this to detect
kernel threads. However, any userland program can emulate the
behavior by making its argvs unavailable and trick the affected tools
into thinking that the task is a kernel thread. Linus's reproducer
follows.
#include
#include
int main(void)
{
char empty[16384];
unsigned long ptr;
asm volatile("" :"=r" (ptr) : "0" (empty):"memory");
ptr = (ptr+4095) & ~4095;
munmap((void *)ptr, 32768);
sleep(1000);
return 0;
}
Compiling the above program into nullcmdline and running it on an
unpatche kernel shows the following behavior.
$ ./nullcmdline &
[1] 2382031
[devbig577 ~/tmp]$ hexdump -C /proc/2382031/comm
6e 75 6c 6c 63 6d 64 6c 69 6e 65 0a |nullcmdline.|
000c
$ hexdump -C /proc/2382031/cmdline
$ ps 2382031
PID TTY STAT TIME COMMAND
2382031 pts/2S 0:00 [nullcmdline]
The empty cmdline makes ps(1) think that nullcmdline is a kernel
thread and put brackets around its name (comm), which is mostly a
nuisance but it's possible that this confusion can lead to more
harmful confusions.
This patch fixes the issue by making proc_pid_cmdline_read() never
return empty string for user tasks. If the result is empty for
whatever reason, comm string is returned. Even when the comm string
is empty, it still returns the null termnation character. On a
patched kernel, running the same command as above gives us.
$ ./nullcmdline &
[1] 2317
[test ~]# hexdump -C /proc/2317/comm
6e 75 6c 6c 63 6d 64 6c 69 6e 65 0a |nullcmdline.|
000c
$ hexdump -C /proc/2317/cmdline
6e 75 6c 6c 63 6d 64 6c 69 6e 65 00 |nullcmdline.|
000c
$ ps 2317
PID TTY STAT TIME COMMAND
2317 pts/0S 0:00 nullcmdline
Note that cmdline is a dup of comm and ps(1) is no longer confused.
Signed-off-by: Tejun Heo
Suggested-by: Linus Torvalds
---
fs/proc/base.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 1b2ede6..2eee4d7 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -224,9 +224,10 @@ static ssize_t proc_pid_cmdline_read(struct file *file,
char __user *buf,
if (!tsk)
return -ESRCH;
mm = get_task_mm(tsk);
- put_task_struct(tsk);
- if (!mm)
- return 0;
+ if (!mm) {
+ rv = 0;
+ goto out_put_task;
+ }
/* Check if process spawned far enough to have cmdline. */
if (!mm->env_end) {
rv = 0;
@@ -367,8 +368,23 @@ static ssize_t proc_pid_cmdline_read(struct file *file,
char __user *buf,
free_page((unsigned long)page);
out_mmput:
mmput(mm);
+out_put_task:
+ /*
+* Some userland tools use empty cmdline to distinguish kthreads.
+* Avoid empty cmdline for user tasks by returning tsk->comm with
+* \0 termination when empty.
+*/
+ if (*pos == 0 && rv == 0 && !(tsk->flags & PF_KTHREAD)) {
+ char tcomm[TASK_COMM_LEN];
+
+ get_task_comm(tcomm, tsk);
+ rv = min(strlen(tcomm) + 1, count);
+ if (copy_to_user(buf, tsk->comm, rv))
+ rv = -EFAULT;
+ }
if (rv > 0)
*pos += rv;
+ put_task_struct(tsk);
return rv;
}
--
2.9.5
[PATCH 3/6] workqueue: Make worker_attach/detach_pool() update worker->pool
For historical reasons, the worker attach/detach functions don't
currently manage worker->pool and the callers are manually and
inconsistently updating it.
This patch moves worker->pool updates into the worker attach/detach
functions. This makes worker->pool consistent and clearly defines how
worker->pool updates are synchronized.
This will help later workqueue visibility improvements by allowing
safe access to workqueue information from worker->task.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 16
kernel/workqueue_internal.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 91fe0a6..2fde50f 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1741,6 +1741,7 @@ static void worker_attach_to_pool(struct worker *worker,
worker->flags |= WORKER_UNBOUND;
list_add_tail(&worker->node, &pool->workers);
+ worker->pool = pool;
mutex_unlock(&wq_pool_attach_mutex);
}
@@ -1748,19 +1749,21 @@ static void worker_attach_to_pool(struct worker *worker,
/**
* worker_detach_from_pool() - detach a worker from its pool
* @worker: worker which is attached to its pool
- * @pool: the pool @worker is attached to
*
* Undo the attaching which had been done in worker_attach_to_pool(). The
* caller worker shouldn't access to the pool after detached except it has
* other reference to the pool.
*/
-static void worker_detach_from_pool(struct worker *worker,
- struct worker_pool *pool)
+static void worker_detach_from_pool(struct worker *worker)
{
+ struct worker_pool *pool = worker->pool;
struct completion *detach_completion = NULL;
mutex_lock(&wq_pool_attach_mutex);
+
list_del(&worker->node);
+ worker->pool = NULL;
+
if (list_empty(&pool->workers))
detach_completion = pool->detach_completion;
mutex_unlock(&wq_pool_attach_mutex);
@@ -1799,7 +1802,6 @@ static struct worker *create_worker(struct worker_pool
*pool)
if (!worker)
goto fail;
- worker->pool = pool;
worker->id = id;
if (pool->cpu >= 0)
@@ -2236,7 +2238,7 @@ static int worker_thread(void *__worker)
set_task_comm(worker->task, "kworker/dying");
ida_simple_remove(&pool->worker_ida, worker->id);
- worker_detach_from_pool(worker, pool);
+ worker_detach_from_pool(worker);
kfree(worker);
return 0;
}
@@ -2367,7 +2369,6 @@ static int rescuer_thread(void *__rescuer)
worker_attach_to_pool(rescuer, pool);
spin_lock_irq(&pool->lock);
- rescuer->pool = pool;
/*
* Slurp in all works issued via this workqueue and
@@ -2417,10 +2418,9 @@ static int rescuer_thread(void *__rescuer)
if (need_more_worker(pool))
wake_up_worker(pool);
- rescuer->pool = NULL;
spin_unlock_irq(&pool->lock);
- worker_detach_from_pool(rescuer, pool);
+ worker_detach_from_pool(rescuer);
spin_lock_irq(&wq_mayday_lock);
}
diff --git a/kernel/workqueue_internal.h b/kernel/workqueue_internal.h
index d390d1b..4a182e0 100644
--- a/kernel/workqueue_internal.h
+++ b/kernel/workqueue_internal.h
@@ -37,7 +37,7 @@ struct worker {
/* 64 bytes boundary on 64bit, 32 on 32bit */
struct task_struct *task; /* I: worker task */
- struct worker_pool *pool; /* I: the associated pool */
+ struct worker_pool *pool; /* A: the associated pool */
/* L: for rescuers */
struct list_headnode; /* A: anchored at pool->workers
*/
/* A: runs through worker->node
*/
--
2.9.5
[PATCH 2/6] workqueue: Replace pool->attach_mutex with global wq_pool_attach_mutex
To improve workqueue visibility, we want to be able to access
workqueue information from worker tasks. The per-pool attach mutex
makes that difficult because there's no way of stabilizing task ->
worker pool association without knowing the pool first.
Worker attach/detach is a slow path and there's no need for different
pools to be able to perform them concurrently. This patch replaces
the per-pool attach_mutex with global wq_pool_attach_mutex to prepare
for visibility improvement changes.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index ca7959b..91fe0a6 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -66,7 +66,7 @@ enum {
* be executing on any CPU. The pool behaves as an unbound one.
*
* Note that DISASSOCIATED should be flipped only while holding
-* attach_mutex to avoid changing binding state while
+* wq_pool_attach_mutex to avoid changing binding state while
* worker_attach_to_pool() is in progress.
*/
POOL_MANAGER_ACTIVE = 1 << 0, /* being managed */
@@ -123,7 +123,7 @@ enum {
*cpu or grabbing pool->lock is enough for read access. If
*POOL_DISASSOCIATED is set, it's identical to L.
*
- * A: pool->attach_mutex protected.
+ * A: wq_pool_attach_mutex protected.
*
* PL: wq_pool_mutex protected.
*
@@ -166,7 +166,6 @@ struct worker_pool {
/* L: hash of busy workers */
struct worker *manager; /* L: purely informational */
- struct mutexattach_mutex; /* attach/detach exclusion */
struct list_headworkers;/* A: attached workers */
struct completion *detach_completion; /* all workers detached */
@@ -297,6 +296,7 @@ static bool wq_numa_enabled;/* unbound NUMA
affinity enabled */
static struct workqueue_attrs *wq_update_unbound_numa_attrs_buf;
static DEFINE_MUTEX(wq_pool_mutex);/* protects pools and workqueues list */
+static DEFINE_MUTEX(wq_pool_attach_mutex); /* protects worker attach/detach */
static DEFINE_SPINLOCK(wq_mayday_lock);/* protects wq->maydays list */
static DECLARE_WAIT_QUEUE_HEAD(wq_manager_wait); /* wait for manager to go
away */
@@ -399,14 +399,14 @@ static void workqueue_sysfs_unregister(struct
workqueue_struct *wq);
* @worker: iteration cursor
* @pool: worker_pool to iterate workers of
*
- * This must be called with @pool->attach_mutex.
+ * This must be called with wq_pool_attach_mutex.
*
* The if/else clause exists only for the lockdep assertion and can be
* ignored.
*/
#define for_each_pool_worker(worker, pool) \
list_for_each_entry((worker), &(pool)->workers, node) \
- if (({ lockdep_assert_held(&pool->attach_mutex); false; })) { }
\
+ if (({ lockdep_assert_held(&wq_pool_attach_mutex); false; })) {
} \
else
/**
@@ -1724,7 +1724,7 @@ static struct worker *alloc_worker(int node)
static void worker_attach_to_pool(struct worker *worker,
struct worker_pool *pool)
{
- mutex_lock(&pool->attach_mutex);
+ mutex_lock(&wq_pool_attach_mutex);
/*
* set_cpus_allowed_ptr() will fail if the cpumask doesn't have any
@@ -1733,16 +1733,16 @@ static void worker_attach_to_pool(struct worker *worker,
set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask);
/*
-* The pool->attach_mutex ensures %POOL_DISASSOCIATED remains
-* stable across this function. See the comments above the
-* flag definition for details.
+* The wq_pool_attach_mutex ensures %POOL_DISASSOCIATED remains
+* stable across this function. See the comments above the flag
+* definition for details.
*/
if (pool->flags & POOL_DISASSOCIATED)
worker->flags |= WORKER_UNBOUND;
list_add_tail(&worker->node, &pool->workers);
- mutex_unlock(&pool->attach_mutex);
+ mutex_unlock(&wq_pool_attach_mutex);
}
/**
@@ -1759,11 +1759,11 @@ static void worker_detach_from_pool(struct worker
*worker,
{
struct completion *detach_completion = NULL;
- mutex_lock(&pool->attach_mutex);
+ mutex_lock(&wq_pool_attach_mutex);
list_del(&worker->node);
if (list_empty(&pool->workers))
detach_completion = pool->detach_completion;
- mutex_unlock(&pool->attach_mutex);
+ mutex_unlock(&wq_pool_attach_mutex);
/* clear leftover flags without pool->lock after it is detached */
worker->flags &= ~(WORKER_UNBOUND | WORKER_REBOUND);
@@ -3271,7 +3271,6 @@ static int init_worker_pool(struct worker_pool *pool)
timer_setup(&pool->mayday_timer, pool_mayday_timeout
Re: [PATCH v5 13/13] mm: Clear shrinker bit if there are no objects related to memcg
On Tue, May 15, 2018 at 11:55:04AM +0300, Kirill Tkhai wrote:
> >> @@ -586,8 +586,23 @@ static unsigned long shrink_slab_memcg(gfp_t
> >> gfp_mask, int nid,
> >>continue;
> >>
> >>ret = do_shrink_slab(&sc, shrinker, priority);
> >> - if (ret == SHRINK_EMPTY)
> >> - ret = 0;
> >> + if (ret == SHRINK_EMPTY) {
> >> + clear_bit(i, map->map);
> >> + /*
> >> + * Pairs with mb in memcg_set_shrinker_bit():
> >> + *
> >> + * list_lru_add() shrink_slab_memcg()
> >> + * list_add_tail()clear_bit()
> >> + *
> >> + * set_bit() do_shrink_slab()
> >> + */
> >
> > Please improve the comment so that it isn't just a diagram.
>
> Please, say, which comment you want to see here.
I want the reader to understand why we need to invoke the shrinker twice
if it returns SHRINK_EMPTY. The diagram doesn't really help here IMO. So
I'd write Something like this:
ret = do_shrink_slab(&sc, shrinker, priority);
if (ret == SHRINK_EMPTY) {
clear_bit(i, map->map);
/*
* After the shrinker reported that it had no objects to free,
* but before we cleared the corresponding bit in the memcg
* shrinker map, a new object might have been added. To make
* sure, we have the bit set in this case, we invoke the
* shrinker one more time and re-set the bit if it reports that
* it is not empty anymore. The memory barrier here pairs with
* the barrier in memcg_set_shrinker_bit():
*
* list_lru_add() shrink_slab_memcg()
* list_add_tail()clear_bit()
*
* set_bit() do_shrink_slab()
*/
smp_mb__after_atomic();
ret = do_shrink_slab(&sc, shrinker, priority);
if (ret == SHRINK_EMPTY)
ret = 0;
else
memcg_set_shrinker_bit(memcg, nid, i);
Re: [PATCH] perf annotate: Support multiple events without group
Hi,
Any comments for this fix?
Thanks
Jin Yao
On 5/10/2018 9:59 PM, Jin Yao wrote:
See example,
perf record -e cycles,branches ./div
perf annotate main --stdio or
perf annotate main --stdio2 or
perf annotate main
The "perf annotate" should show both cycles and branches on the
left side, but actually it only shows one event cycles.
It works with events group like:
perf record -e "{cycles,branches}" ./div
It should work too even without group.
This patch uses 'symbol_conf.nr_events > 1' to check if it's the
multiple events case.
With this patch,
perf record -e cycles,branches ./div
perf annotate main --stdio2
..
for (i = 0; i < 20; i++) {
flag = compute_flag();
4.85 5.83 38: xor%eax,%eax
0.01 0.01 → callq compute_flag
count++;
4.44 2.27movcount,%edx
0.00 0.00add$0x1,%edx
..
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 5d74a30..ca8d4b1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1054,6 +1054,8 @@ annotation_line__new(struct annotate_args *args, size_t
privsize)
if (perf_evsel__is_group_event(evsel))
nr = evsel->nr_members;
+ else if (symbol_conf.nr_events > nr)
+ nr = symbol_conf.nr_events;
size += sizeof(al->samples[0]) * nr;
@@ -1326,6 +1328,8 @@ annotation_line__print(struct annotation_line *al, struct symbol *sym, u64 start
if (perf_evsel__is_group_event(evsel))
width *= evsel->nr_members;
+ else if (symbol_conf.nr_events > 1)
+ width *= symbol_conf.nr_events;
if (!*al->line)
printf(" %*s:\n", width, " ");
@@ -1967,6 +1971,8 @@ int symbol__annotate_printf(struct symbol *sym, struct
map *map,
if (perf_evsel__is_group_event(evsel))
width *= evsel->nr_members;
+ else if (symbol_conf.nr_events > 1)
+ width *= symbol_conf.nr_events;
graph_dotted_len = printf(" %-*.*s| Source code & Disassembly of %s for %s (%" PRIu64 " samples)\n",
width, width, symbol_conf.show_total_period ?
"Period" :
@@ -2578,6 +2584,8 @@ int symbol__annotate2(struct symbol *sym, struct map
*map, struct perf_evsel *ev
if (perf_evsel__is_group_event(evsel))
nr_pcnt = evsel->nr_members;
+ else if (symbol_conf.nr_events > nr_pcnt)
+ nr_pcnt = symbol_conf.nr_events;
err = symbol__annotate(sym, map, evsel, 0, parch);
if (err)
[PATCH v7 0/3] pcal6524 extensions and fixes for pca953x driver
V7: * replace PCAL register masks by hex constants 2018-05-16 19:01:29: V6: * added proper attribution to the formula used for fixing the pcal6524 register address (changes commit message only) * add back missing first patch from V2 that defines the PCA_LATCH_INT constant * removed patches already merged 2018-04-28 18:33:42: V5: * fix wrong split up between patches 1/7 and 2/7. 2018-04-26 19:35:07: V4: * introduced PCA_LATCH_INT constant to make of_table more readable (suggested by Andy Shevchenko) * converted all register constants to hex in a separate patch (suggested by Andy Shevchenko) * separated additional pcal953x and pcal6524 register definitions into separate patches (suggested by Andy Shevchenko) * made special pcal6524 address adjustment more readable (suggested by Andy Shevchenko) * moved gpio-controller and interrupt-controller to the "required" section (reviewed by Rob Herring) 2018-04-10 18:07:07: V3: * add Reported-by: and Reviewed-by: * fix wording for bindings description and example * convert all register offsets to hex * omit the LEVEL-IRQ RFC/hack commit 2018-04-04 21:00:27: V2: * added PCA_PCAL flags if matched through of-table * fix address calculation for extended PCAL6524 registers * hack to map LEVEL_LOW to EDGE_FALLING to be able to test in combination with ts3a227e driver * improve description of bindings for optional vcc-supply and interrupt-controller; 2018-03-10 09:32:53: no initial description H. Nikolaus Schaller (3): gpio: pca953x: set the PCA_PCAL flag also when matching by DT gpio: pca953x: define masks for addressing common and extended registers gpio: pca953x: fix address calculation for pcal6524 drivers/gpio/gpio-pca953x.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) -- 2.12.2
[PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524
The register constants are so far defined in a way that they fit
for the pcal9555a when shifted by the number of banks, i.e. are
multiplied by 2 in the accessor function.
Now, the pcal6524 has 3 banks which means the relative offset
is multiplied by 4 for the standard registers.
Simply applying the bit shift to the extended registers gives
a wrong result, since the base offset is already included in
the offset.
Therefore, we have to add code to the 24 bit accessor functions
that adjusts the register number for these exended registers.
The formula finally used was developed and proposed by
Andy Shevchenko .
Suggested-by: Andy Shevchenko
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpio/gpio-pca953x.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index c682921d7019..4ad553f4e41f 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -222,9 +222,11 @@ static int pca957x_write_regs_16(struct pca953x_chip
*chip, int reg, u8 *val)
static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
{
int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+ int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+ int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
return i2c_smbus_write_i2c_block_data(chip->client,
- (reg << bank_shift) | REG_ADDR_AI,
+ pinctrl | addr | REG_ADDR_AI,
NBANK(chip), val);
}
@@ -264,9 +266,11 @@ static int pca953x_read_regs_16(struct pca953x_chip *chip,
int reg, u8 *val)
static int pca953x_read_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
{
int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+ int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+ int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
return i2c_smbus_read_i2c_block_data(chip->client,
-(reg << bank_shift) | REG_ADDR_AI,
+pinctrl | addr | REG_ADDR_AI,
NBANK(chip), val);
}
--
2.12.2
[PATCH v7 1/3] gpio: pca953x: set the PCA_PCAL flag also when matching by DT
The of_device_table is missing the PCA_PCAL flag so the
pcal6524 would be operated in tca6424 compatibility mode which
does not handle the new interrupt mask registers.
Suggested-by: Andy Shevchenko
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpio/gpio-pca953x.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 7d37692d672e..2b667166e855 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -58,6 +58,7 @@
#define PCA_GPIO_MASK 0x00FF
#define PCA_INT0x0100
#define PCA_PCAL 0x0200
+#define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
#define PCA953X_TYPE 0x1000
#define PCA957X_TYPE 0x2000
#define PCA_TYPE_MASK 0xF000
@@ -946,8 +947,8 @@ static const struct of_device_id pca953x_dt_ids[] = {
{ .compatible = "nxp,pca9575", .data = OF_957X(16, PCA_INT), },
{ .compatible = "nxp,pca9698", .data = OF_953X(40, 0), },
- { .compatible = "nxp,pcal6524", .data = OF_953X(24, PCA_INT), },
- { .compatible = "nxp,pcal9555a", .data = OF_953X(16, PCA_INT), },
+ { .compatible = "nxp,pcal6524", .data = OF_953X(24, PCA_LATCH_INT), },
+ { .compatible = "nxp,pcal9555a", .data = OF_953X(16, PCA_LATCH_INT), },
{ .compatible = "maxim,max7310", .data = OF_953X( 8, 0), },
{ .compatible = "maxim,max7312", .data = OF_953X(16, PCA_INT), },
--
2.12.2
Re: linux-next: build failure after merge of the drm tree
I've applied this locally for now so I can continue arm64 builds :-)
Dave.
On 16 May 2018 at 18:09, Oded Gabbay wrote:
> On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the drm tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
>> 'init_user_pages':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit
>> declaration of function 'release_pages'; did you mean 'release_task'?
>> [-Werror=implicit-function-declaration]
>>release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
>>^
>>release_task
>>
>> Caused by commit
>>
>> 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
>>
>> I have applied the following patch for today:
>>
>> From: Stephen Rothwell
>> Date: Wed, 16 May 2018 16:43:34 +1000
>> Subject: [PATCH] drm/amdgpu: include pagemap.h for release_pages()
>>
>> Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD"
>> Cc: Felix Kuehling
>> Cc: Oded Gabbay
>> Signed-off-by: Stephen Rothwell
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 72ab2b1ffe75..ff8fd75f7ca5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -23,6 +23,7 @@
>> #define pr_fmt(fmt) "kfd2kgd: " fmt
>>
>> #include
>> +#include
>> #include
>> #include
>> #include "amdgpu_object.h"
>> --
>> 2.17.0
>>
>> --
>> Cheers,
>> Stephen Rothwell
>
> Thanks Stephen,
>
> I'll add it to amdkfd-next and send it to Dave with other fixes.
>
> Oded
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/3] gpio: pca953x: define masks for addressing common and extended registers
These mask bits are to be used to map the extended register addreseses (which are defined for an unsupported 8-bit pcal chip) to 16 and 24 bit chips (pcal6524). Reviewed-by: Andy Shevchenko Signed-off-by: H. Nikolaus Schaller --- drivers/gpio/gpio-pca953x.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 2b667166e855..c682921d7019 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -56,6 +56,10 @@ #define PCAL6524_DEBOUNCE 0x2d #define PCA_GPIO_MASK 0x00FF + +#define PCAL_GPIO_MASK 0x1f +#define PCAL_PINCTRL_MASK 0xe0 + #define PCA_INT0x0100 #define PCA_PCAL 0x0200 #define PCA_LATCH_INT (PCA_PCAL | PCA_INT) -- 2.12.2
[PATCH] clk: imx6sl: correct ocram_podf clock type
IMX6SL_CLK_OCRAM_PODF is a busy divider, its name in
CCM_CDHIPR register of Reference Manual CCM chapter
is axi_podf_busy, correct its clock type.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx6sl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx6sl.c b/drivers/clk/imx/clk-imx6sl.c
index 9642cdf..66b1dd1 100644
--- a/drivers/clk/imx/clk-imx6sl.c
+++ b/drivers/clk/imx/clk-imx6sl.c
@@ -330,7 +330,7 @@ static void __init imx6sl_clocks_init(struct device_node
*ccm_node)
clks[IMX6SL_CLK_PERIPH2] = imx_clk_busy_mux("periph2", base + 0x14, 26,
1, base + 0x48, 3, periph2_sels, ARRAY_SIZE(periph2_sels));
/* name
parent_name reg shift width */
- clks[IMX6SL_CLK_OCRAM_PODF]= imx_clk_divider("ocram_podf",
"ocram_sel", base + 0x14, 16, 3);
+ clks[IMX6SL_CLK_OCRAM_PODF]= imx_clk_busy_divider("ocram_podf",
"ocram_sel", base + 0x14, 16, 3, base + 0x48, 0);
clks[IMX6SL_CLK_PERIPH_CLK2_PODF] =
imx_clk_divider("periph_clk2_podf", "periph_clk2_sel", base + 0x14, 27, 3);
clks[IMX6SL_CLK_PERIPH2_CLK2_PODF] =
imx_clk_divider("periph2_clk2_podf", "periph2_clk2_sel", base + 0x14, 0, 3);
clks[IMX6SL_CLK_IPG] = imx_clk_divider("ipg",
"ahb", base + 0x14, 8, 2);
--
2.7.4
[PATCH] clk: imx6sx: disable unnecessary clocks during clock initialization
Disable those unnecessary clocks during kernel boot up to save power,
those modules clock should be managed by modules driver in runtime.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx6sx.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index 0178ee2..10c771b 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -97,12 +97,7 @@ static int const clks_init_on[] __initconst = {
IMX6SX_CLK_IPMUX1, IMX6SX_CLK_IPMUX2, IMX6SX_CLK_IPMUX3,
IMX6SX_CLK_WAKEUP, IMX6SX_CLK_MMDC_P0_FAST, IMX6SX_CLK_MMDC_P0_IPG,
IMX6SX_CLK_ROM, IMX6SX_CLK_ARM, IMX6SX_CLK_IPG, IMX6SX_CLK_OCRAM,
- IMX6SX_CLK_PER2_MAIN, IMX6SX_CLK_PERCLK, IMX6SX_CLK_M4,
- IMX6SX_CLK_QSPI1, IMX6SX_CLK_QSPI2, IMX6SX_CLK_UART_IPG,
- IMX6SX_CLK_UART_SERIAL, IMX6SX_CLK_I2C3, IMX6SX_CLK_ECSPI5,
- IMX6SX_CLK_CAN1_IPG, IMX6SX_CLK_CAN1_SERIAL, IMX6SX_CLK_CAN2_IPG,
- IMX6SX_CLK_CAN2_SERIAL, IMX6SX_CLK_CANFD, IMX6SX_CLK_EPIT1,
- IMX6SX_CLK_EPIT2,
+ IMX6SX_CLK_PER2_MAIN, IMX6SX_CLK_PERCLK, IMX6SX_CLK_TZASC1,
};
static const struct clk_div_table clk_enet_ref_table[] = {
--
2.7.4
Re: [PATCH RFC] schedutil: Allow cpufreq requests to be made even when kthread kicked
On 16-05-18, 15:45, Joel Fernandes (Google) wrote:
> kernel/sched/cpufreq_schedutil.c | 36 +---
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index e13df951aca7..a87fc281893d 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -92,9 +92,6 @@ static bool sugov_should_update_freq(struct sugov_policy
> *sg_policy, u64 time)
> !cpufreq_can_do_remote_dvfs(sg_policy->policy))
> return false;
>
> - if (sg_policy->work_in_progress)
> - return false;
> -
> if (unlikely(sg_policy->need_freq_update)) {
> sg_policy->need_freq_update = false;
> /*
> @@ -129,8 +126,11 @@ static void sugov_update_commit(struct sugov_policy
> *sg_policy, u64 time,
> policy->cur = next_freq;
> trace_cpu_frequency(next_freq, smp_processor_id());
> } else {
> - sg_policy->work_in_progress = true;
> - irq_work_queue(&sg_policy->irq_work);
> + /* Don't queue request if one was already queued */
> + if (!sg_policy->work_in_progress) {
Merge it above to make it "else if".
> + sg_policy->work_in_progress = true;
> + irq_work_queue(&sg_policy->irq_work);
> + }
> }
> }
>
> @@ -291,6 +291,15 @@ static void sugov_update_single(struct update_util_data
> *hook, u64 time,
>
> ignore_dl_rate_limit(sg_cpu, sg_policy);
>
> + /*
> + * For slow-switch systems, single policy requests can't run at the
> + * moment if the governor thread is already processing a pending
> + * frequency switch request, this can be fixed by acquiring update_lock
> + * while updating next_freq and work_in_progress but we prefer not to.
> + */
> + if (sg_policy->work_in_progress)
> + return;
> +
@Rafael: Do you think its worth start using the lock now for unshared
policies ?
> if (!sugov_should_update_freq(sg_policy, time))
> return;
>
> @@ -382,13 +391,24 @@ sugov_update_shared(struct update_util_data *hook, u64
> time, unsigned int flags)
> static void sugov_work(struct kthread_work *work)
> {
> struct sugov_policy *sg_policy = container_of(work, struct
> sugov_policy, work);
> + unsigned int freq;
> + unsigned long flags;
> +
> + /*
> + * Hold sg_policy->update_lock shortly to handle the case where:
> + * incase sg_policy->next_freq is read here, and then updated by
> + * sugov_update_shared just before work_in_progress is set to false
> + * here, we may miss queueing the new update.
> + */
> + raw_spin_lock_irqsave(&sg_policy->update_lock, flags);
> + freq = sg_policy->next_freq;
> + sg_policy->work_in_progress = false;
> + raw_spin_unlock_irqrestore(&sg_policy->update_lock, flags);
>
> mutex_lock(&sg_policy->work_lock);
> - __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
> + __cpufreq_driver_target(sg_policy->policy, freq,
> CPUFREQ_RELATION_L);
No need of line break anymore.
> mutex_unlock(&sg_policy->work_lock);
> -
> - sg_policy->work_in_progress = false;
> }
>
> static void sugov_irq_work(struct irq_work *irq_work)
LGTM.
--
viresh
Re: [PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode
> > > Anyway, I understand that Intel has been ignoring kernel.org instead of > > > sending forwarding their patches properly so you're doing a difficult > > > and thankless job... Thanks for that. I'm sure it's frustrating to > > > look at these patches for you as well. > > > > Thank you for the complement. Also thank you for taking time to review > > these patches. Your feedback is most welcomed and benefitical to the > > health of the lustre client. > > > > Sadly its not just Intel but other vendors that don't directly contribute > > to the linux lustre client. I have spoke to the vendors about contributing > > and they all say the same thing. No working with drivers in the staging > > tree. Sadly all the parties involved are very interested in the success > > of the lustre client. No one has ever told me directly why they don't get > > involved but I suspect it has to deal with 2 reasons. One is that staging > > drivers are not normally enabled by distributions so their clients > > normally will never deal with the staging lustre client. Secondly vendors > > just lack the man power to contribute in a meanful way. > > If staging is hurting you, why is it in staging at all? Why not just > drop it, go off and spend a few months to clean up all the issues in > your own tree (with none of those pesky requirements of easy-to-review > patches) and then submit a "clean" filesystem for inclusion in the > "real" part of the kernel tree? > > It doesn't sound like anyone is actually using this code in the tree > as-is, so why even keep it here? I never said being in staging is hurting the progression of Lustre. In fact it is the exact opposite otherwise I wouldn't be active in this work. What I was pointing out to Dan was that many vendors are reluctant to partcipate in broader open source development of this type. The whole point of this is to evolve Lustre into a proper open source project not dependent on vendors for survival. Several years ago Lustre changed hands several times and the HPC community was worried about its survival. Various institutions band togther to raise the resources to keep it alive. Over time Lustre has been migrating to a more open source community effort. An awesome example is the work the University of Indiana did for the sptlrpc layer. Now we see efforts expanding into the realm of the linux lustre client. Actually HPC sites that are community members are testing and running the linux client. In spite of the lack of vendor involvement the linux lustre client is making excellent progress. How often do you see style patches anymore? The headers are properly split between userspace UAPI headers and kernel space. One of the major barriers to leave staging was the the lack of a strong presence to continue moving the lustre client forward. That is no longer the case. The finish line is in view.
Re: Linux 4.16-rc1: regression bisected, Debian kernel package tool make-kpkg stalls indefinitely during kernel build due to commit "kconfig: remove check_stdin()"
On Tue, Feb 13, 2018 at 2:07 PM, Ulf Magnusson wrote: >> On Tue, Feb 13, 2018 at 12:33:24PM +0100, Ulf Magnusson wrote: >> Sander Eikelenboom wrote: >>> The Debian kernel-package tool make-kpkg for easy building of upstream >>> kernels on Debian fails with linux 4.16-rc1. >>> >>> Bisection turned up as culprit: >>> commit d2a04648a5dbc3d1d043b35257364f0197d4d868 >>> >>> What the commit does is to make silentoldconfig not immediately exit(1) >>> when both of the following apply: >>> >>> 1. stdin is from something that's not a terminal >>> >>> 2. New symbols are prompted for > > Shouldn't be a problem to back this one out either if it turns out to > cause massive amounts of pain in practice I guess, even if it's the > Debian tools doing something weird. > > Good to look into what it is they're doing in any case. It appears that make-kpkg is trying to extract kernel version and configuration information by including the kernel Makefile then referencing the variables it exports. The offending make-kpkg Makefile is kernel_version.mk[1] which can be simplified to the following example: -8<- make-kpkg-regression.mk - include Makefile .PHONY: debian_VERSION debian_VERSION: -8<--- Invoking this script from the root of the kernel source tree, with stderr redirected (but not stdin) demonstrates the issue: make -f make-kpkg-regression.mk debian_VERSION >/dev/null 2>&1 Before d2a04648a5db this would exit, after it will hang waiting for input. This occurs because the debian_VERSION target name isn't in no-dot-config-targets defined in Makefile, so Makefile invokes silentoldconfig automatically as necessary.[2] I think the issue is best fixed by make-kpkg, and that d2a04648a5db doesn't need to be reverted. The simple fix would be for make-kpkg to redirect stdin when redirecting stdout/stderr so that scripts/kconfig/conf will fail as it did before. The better fix would be for make-kpkg to use a supported interface for getting the variables it needs, rather than including Makefile. Best, Kevin 1. https://salsa.debian.org/srivasta/kernel-package/blob/master/kernel/ruleset/kernel_version.mk 2. Interestingly, it's not just that the target isn't in no-dot-config-targets. make-kpkg actually sets `dot-config := 1` to force silentoldconfig (since 38399c1[3]). 3. https://salsa.debian.org/srivasta/kernel-package/commit/38399c1
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On Wed, 16. May 18:05, Baoquan He wrote:
> Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to
> handle conflict between KASLR and huge pages, will be used in the next patch.
>
> Function parse_gb_huge_pages() is used to parse kernel command-line to get
> how many 1GB huge pages have been specified. A static global variable
> 'max_gb_huge_pages' is added to store the number.
>
> And process_gb_huge_page() is used to skip as many 1GB huge pages as possible
> from the passed in memory region according to the specified number.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/boot/compressed/kaslr.c | 71
>
> 1 file changed, 71 insertions(+)
>
> diff --git a/arch/x86/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index a0a50b91ecef..13bd879cdc5d 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -215,6 +215,32 @@ static void mem_avoid_memmap(char *str)
> memmap_too_large = true;
> }
>
> +/* Store the number of 1GB huge pages which user specified.*/
> +static unsigned long max_gb_huge_pages;
> +
> +static int parse_gb_huge_pages(char *param, char* val)
> +{
> + char *p;
> + u64 mem_size;
> + static bool gbpage_sz = false;
> +
> + if (!strcmp(param, "hugepagesz")) {
> + p = val;
> + mem_size = memparse(p, &p);
> + if (mem_size == PUD_SIZE) {
> + if (gbpage_sz)
> + warn("Repeadly set hugeTLB page size of 1G!\n");
> + gbpage_sz = true;
> + } else
> + gbpage_sz = false;
> + } else if (!strcmp(param, "hugepages") && gbpage_sz) {
> + p = val;
> + max_gb_huge_pages = simple_strtoull(p, &p, 0);
> + debug_putaddr(max_gb_huge_pages);
> + }
> +}
Hello,
the return value is missing for the function or not ?
regards
Damian
> +
> +
> static int handle_mem_memmap(void)
> {
> char *args = (char *)get_cmd_line_ptr();
> @@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
> unsigned long image_size)
> }
> }
>
> +/* Skip as many 1GB huge pages as possible in the passed region. */
> +static void process_gb_huge_page(struct mem_vector *region, unsigned long
> image_size)
> +{
> + int i = 0;
> + unsigned long addr, size;
> + struct mem_vector tmp;
> +
> + if (!max_gb_huge_pages) {
> + store_slot_info(region, image_size);
> + return;
> + }
> +
> + addr = ALIGN(region->start, PUD_SIZE);
> + /* If Did we raise the address above the passed in memory entry? */
> + if (addr < region->start + region->size)
> + size = region->size - (addr - region->start);
> +
> + /* Check how many 1GB huge pages can be filtered out*/
> + while (size > PUD_SIZE && max_gb_huge_pages) {
> + size -= PUD_SIZE;
> + max_gb_huge_pages--;
> + i++;
> + }
> +
> + if (!i) {
> + store_slot_info(region, image_size);
> + return;
> + }
> +
> + /* Process the remaining regions after filtering out. */
> +
> + if (addr >= region->start + image_size) {
> + tmp.start = region->start;
> + tmp.size = addr - region->start;
> + store_slot_info(&tmp, image_size);
> + }
> +
> + size = region->size - (addr - region->start) - i * PUD_SIZE;
> +if (size >= image_size) {
> + tmp.start = addr + i*PUD_SIZE;
> + tmp.size = size;
> + store_slot_info(&tmp, image_size);
> +}
> +}
> +
> static unsigned long slots_fetch_random(void)
> {
> unsigned long slot;
> --
> 2.13.6
>
Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration
On 11-05-18, 21:06, Baolin Wang wrote:
> +struct sprd_dma_config {
> + struct dma_slave_config cfg;
> + u32 block_len;
> + u32 transcation_len;
/s/transcation/transaction
now in code I see block_len and this filled by len which is sg_dma_len()?
So why two varibales when you are using only one.
Second, you are storing parameters programmed thru _prep call into
_dma_config. That is not correct.
We use these to store channel parameters and NOT transaction parameters which
would differ with each txn. No wonder you can only support only 1 txn :)
Lastly, if these are same values why not use src/dstn_max_burst?
> +static enum sprd_dma_datawidth
> +sprd_dma_get_datawidth(enum dma_slave_buswidth buswidth)
> +{
> + switch (buswidth) {
> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> + return ffs(buswidth) - 1;
> + default:
> + return SPRD_DMA_DATAWIDTH_4_BYTES;
Does default make sense, should we error out?
> +static u32 sprd_dma_get_step(enum dma_slave_buswidth buswidth)
> +{
> + switch (buswidth) {
> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> + return buswidth;
> +
> + default:
> + return SPRD_DMA_DWORD_STEP;
Does default make sense, should we error out?
> +static int sprd_dma_config(struct dma_chan *chan, struct sprd_dma_desc
> *sdesc,
> +dma_addr_t src, dma_addr_t dst,
> +struct sprd_dma_config *slave_cfg)
> +{
> + struct sprd_dma_dev *sdev = to_sprd_dma_dev(chan);
> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> + struct sprd_dma_chn_hw *hw = &sdesc->chn_hw;
> + u32 fix_mode = 0, fix_en = 0, wrap_en = 0, wrap_mode = 0;
> + u32 src_datawidth, dst_datawidth, temp;
> +
> + if (slave_cfg->cfg.slave_id)
> + schan->dev_id = slave_cfg->cfg.slave_id;
> +
> + hw->cfg = SPRD_DMA_DONOT_WAIT_BDONE << SPRD_DMA_WAIT_BDONE_OFFSET;
> +
> + temp = slave_cfg->wrap_ptr & SPRD_DMA_LOW_ADDR_MASK;
> + temp |= (src >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
> + hw->wrap_ptr = temp;
> +
> + temp = slave_cfg->wrap_to & SPRD_DMA_LOW_ADDR_MASK;
> + temp |= (dst >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
> + hw->wrap_to = temp;
> +
> + hw->src_addr = src & SPRD_DMA_LOW_ADDR_MASK;
> + hw->des_addr = dst & SPRD_DMA_LOW_ADDR_MASK;
> +
> + if ((slave_cfg->src_step != 0 && slave_cfg->dst_step != 0)
> + || (slave_cfg->src_step | slave_cfg->dst_step) == 0) {
this check doesnt seem right to me, what are you trying here?
> + fix_en = 0;
> + } else {
> + fix_en = 1;
> + if (slave_cfg->src_step)
> + fix_mode = 1;
> + else
> + fix_mode = 0;
> + }
> +
> + if (slave_cfg->wrap_ptr && slave_cfg->wrap_to) {
> + wrap_en = 1;
> + if (slave_cfg->wrap_to == src) {
> + wrap_mode = 0;
> + } else if (slave_cfg->wrap_to == dst) {
> + wrap_mode = 1;
> + } else {
> + dev_err(sdev->dma_dev.dev, "invalid wrap mode\n");
> + return -EINVAL;
> + }
> + }
> +
> + hw->intc = slave_cfg->int_mode | SPRD_DMA_CFG_ERR_INT_EN;
> +
> + src_datawidth = sprd_dma_get_datawidth(slave_cfg->cfg.src_addr_width);
> + dst_datawidth = sprd_dma_get_datawidth(slave_cfg->cfg.dst_addr_width);
> +
> + temp = src_datawidth << SPRD_DMA_SRC_DATAWIDTH_OFFSET;
> + temp |= dst_datawidth << SPRD_DMA_DES_DATAWIDTH_OFFSET;
> + temp |= slave_cfg->req_mode << SPRD_DMA_REQ_MODE_OFFSET;
> + temp |= wrap_mode << SPRD_DMA_WRAP_SEL_OFFSET;
> + temp |= wrap_en << SPRD_DMA_WRAP_EN_OFFSET;
> + temp |= fix_mode << SPRD_DMA_FIX_SEL_OFFSET;
> + temp |= fix_en << SPRD_DMA_FIX_EN_OFFSET;
> + temp |= slave_cfg->cfg.src_maxburst & SPRD_DMA_FRG_LEN_MASK;
> + hw->frg_len = temp;
> +
> + hw->blk_len = slave_cfg->block_len & SPRD_DMA_BLK_LEN_MASK;
> + hw->trsc_len = slave_cfg->transcation_len & SPRD_DMA_TRSC_LEN_MASK;
> +
> + temp = (slave_cfg->dst_step & SPRD_DMA_TRSF_STEP_MASK) <<
> + SPRD_DMA_DEST_TRSF_STEP_OFFSET;
> + temp |= (slave_cfg->src_step & SPRD_DMA_TRSF_STEP_MASK) <<
> + SPRD_DMA_SRC_TRSF_STEP_OFFSET;
> + hw->trsf_step = temp;
> +
> + hw->frg_step = 0;
> + hw->src_blk_step = 0;
> + hw->des_blk_step = 0;
> + return 0;
> +}
> +static struct dma_async_tx_descriptor *
> +sprd_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> +unsigned int sglen, enum dma_transfer_direction dir,
> +unsigned long flags, void *context)
> +{
> +
Re: [PATCH] dmaengine: qcom: bam_dma: check if the runtime pm enabled
On 14-05-18, 17:18, Srinivas Kandagatla wrote:
> Disabling pm runtime at probe is not sufficient to get BAM working
> on remotely controller instances. pm_runtime_get_sync() would return
> -EACCES in such cases.
> So check if runtime pm is enabled before returning error from bam functions.
>
> Fixes: 5b4a68952a89 ("dmaengine: qcom: bam_dma: disable runtime pm on remote
> controlled")
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/dma/qcom/bam_dma.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index d29275b97e84..5f4babebc508 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -540,7 +540,7 @@ static void bam_free_chan(struct dma_chan *chan)
> int ret;
>
> ret = pm_runtime_get_sync(bdev->dev);
> - if (ret < 0)
> + if (pm_runtime_enabled(bdev->dev) && ret < 0)
would it make sense to first check enabled and do _get_sync()
if (pm_runtime_enabled()) {
ret = pm_runtime_get_sync() {
...
}
}
thus making clear in code that we do calls only when it is enabled. Also you can
add a local macro for this code and use that rather than copy pasting :)
--
~Vinod
Re: [linux-firmware] Version in WHENCE file
On Mon, 2018-05-07 at 09:47 +0200, Sedat Dilek wrote: > On Sun, May 6, 2018 at 3:07 PM, Luciano Coelho com> wrote: > > On Sun, 2018-05-06 at 14:46 +0200, Sedat Dilek wrote: > > > Hi Luca, > > > > > > I hope I catched the correct MLs (not sure if linux-firmware has > > > a > > > ML, > > > I did not found any in the MAINTAINERS file). > > > > > > I have seen that in the WHENCE file there is "Version" with and > > > without ":", mostly iwlwifi ucodes. > > > > > > As an example: > > > > > > File: iwlwifi-8265-36.ucode > > > -Version 36.e91976c0.0 > > > +Version: 36.e91976c0.0 > > > > > > I don't know the workflow: Do you want to fix it in your tree or > > > directly in linux-firmware.git upstream? > > > My attached patch is against upstream. > > > > Thanks, Sedat! > > > > I'm going to send a new pull-request this week, so I can include > > your > > patch in my tree and as part of the pull-request. > > > > -- > > Cheers, > > Luca. > > OK, Thanks. > Attached Patch v2 is against your tree [1]. > It differs from v1 against upstream. You need to write a proper commit message and sign it off so I can apply it. -- Luca.
Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup
Christoph Hellwig writes:
> On Sat, May 05, 2018 at 07:37:33AM -0500, Eric W. Biederman wrote:
>> Christoph Hellwig writes:
>>
>> > The shole seq_file sequence already operates under a single RCU lock pair,
>> > so move the pid namespace lookup into it, and stop grabbing a reference
>> > and remove all kinds of boilerplate code.
>>
>> This is wrong.
>>
>> Move task_active_pid_ns(current) from open to seq_start actually means
>> that the results if you pass this proc file between callers the results
>> will change. So this breaks file descriptor passing.
>>
>> Open is a bad place to access current. In the middle of read/write is
>> broken.
>>
>>
>> In this particular instance looking up the pid namespace with
>> task_active_pid_ns was a personal brain fart. What the code should be
>> doing (with an appropriate helper) is:
>>
>> struct pid_namespace *pid_ns = inode->i_sb->s_fs_info;
>>
>> Because each mount of proc is bound to a pid namespace. Looking up the
>> pid namespace from the super_block is a much better way to go.
>
> What do you have in mind for the helper? For now I've thrown it in
> opencoded into my working tree, but I'd be glad to add a helper.
>
> struct pid_namespace *proc_pid_namespace(struct inode *inode)
> {
> // maybe warn on for s_magic not on procfs??
> return inode->i_sb->s_fs_info;
> }
That should work. Ideally out of line for the proc_fs.h version.
Basically it should be a cousin of PDE_DATA.
Eric
Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
On 05/17/2018 12:08 AM, Dmitry Torokhov wrote:
On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote:
On 05/16/2018 08:15 PM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
@@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
if (!info->page)
goto error_nomem;
- /* Set input abs params to match backend screen res */
- abs = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_FEAT_ABS_POINTER, 0);
- ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_WIDTH,
- ptr_size[KPARAM_X]);
- ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_HEIGHT,
- ptr_size[KPARAM_Y]);
- if (abs) {
- ret = xenbus_write(XBT_NIL, dev->nodename,
- XENKBD_FIELD_REQ_ABS_POINTER, "1");
- if (ret) {
- pr_warn("xenkbd: can't request abs-pointer\n");
- abs = 0;
- }
- }
+ /*
+* The below are reverse logic, e.g. if the feature is set, then
+* do not expose the corresponding virtual device.
+*/
+ with_kbd = !xenbus_read_unsigned(dev->nodename,
+XENKBD_FIELD_FEAT_DSBL_KEYBRD, 0);
- touch = xenbus_read_unsigned(dev->nodename,
-XENKBD_FIELD_FEAT_MTOUCH, 0);
- if (touch) {
+ with_ptr = !xenbus_read_unsigned(dev->nodename,
+XENKBD_FIELD_FEAT_DSBL_POINTER, 0);
+
+ /* Direct logic: if set, then create multi-touch device. */
+ with_mtouch = xenbus_read_unsigned(dev->nodename,
+ XENKBD_FIELD_FEAT_MTOUCH, 0);
+ if (with_mtouch) {
ret = xenbus_write(XBT_NIL, dev->nodename,
XENKBD_FIELD_REQ_MTOUCH, "1");
if (ret) {
pr_warn("xenkbd: can't request multi-touch");
- touch = 0;
+ with_mtouch = 0;
}
}
Does it make sense to still end up calling xenkbd_connect_backend() when
all interfaces (keyboard, pointer, and multitouch) are disabled? Should
we do:
if (!(with_kbd || || with_ptr || with_mtouch))
return -ENXIO;
?
It does make sense. Then we probably need to move all xenbus_read_unsigned
calls to the very beginning of the .probe, so no memory allocations are made
which will be useless if we return -ENXIO, e.g. something like
static int xenkbd_probe(struct xenbus_device *dev,
const struct xenbus_device_id *id)
{
int ret, i;
bool with_mtouch, with_kbd, with_ptr;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr, *mtouch;
if (!(with_kbd | with_ptr | with_mtouch))
return -ENXIO;
Does the above looks ok?
Yes. Another option is to keep the check where I suggested and do
if (...) {
ret = -ENXIO;
goto error;
}
Whichever you prefer is fine with me.
I will go with the change you suggested and
I'll send v4 tomorrow then.
Thanks.
Thank you,
Oleksandr
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On 05/17/18 at 07:12am, damian wrote:
> On Wed, 16. May 18:05, Baoquan He wrote:
> > Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to
> > handle conflict between KASLR and huge pages, will be used in the next
> > patch.
> >
> > Function parse_gb_huge_pages() is used to parse kernel command-line to get
> > how many 1GB huge pages have been specified. A static global variable
> > 'max_gb_huge_pages' is added to store the number.
> >
> > And process_gb_huge_page() is used to skip as many 1GB huge pages as
> > possible
> > from the passed in memory region according to the specified number.
> >
> > Signed-off-by: Baoquan He
> > ---
> > arch/x86/boot/compressed/kaslr.c | 71
> >
> > 1 file changed, 71 insertions(+)
> >
> > diff --git a/arch/x86/boot/compressed/kaslr.c
> > b/arch/x86/boot/compressed/kaslr.c
> > index a0a50b91ecef..13bd879cdc5d 100644
> > --- a/arch/x86/boot/compressed/kaslr.c
> > +++ b/arch/x86/boot/compressed/kaslr.c
> > @@ -215,6 +215,32 @@ static void mem_avoid_memmap(char *str)
> > memmap_too_large = true;
> > }
> >
> > +/* Store the number of 1GB huge pages which user specified.*/
> > +static unsigned long max_gb_huge_pages;
> > +
> > +static int parse_gb_huge_pages(char *param, char* val)
> > +{
> > + char *p;
> > + u64 mem_size;
> > + static bool gbpage_sz = false;
> > +
> > + if (!strcmp(param, "hugepagesz")) {
> > + p = val;
> > + mem_size = memparse(p, &p);
> > + if (mem_size == PUD_SIZE) {
> > + if (gbpage_sz)
> > + warn("Repeadly set hugeTLB page size of 1G!\n");
> > + gbpage_sz = true;
> > + } else
> > + gbpage_sz = false;
> > + } else if (!strcmp(param, "hugepages") && gbpage_sz) {
> > + p = val;
> > + max_gb_huge_pages = simple_strtoull(p, &p, 0);
> > + debug_putaddr(max_gb_huge_pages);
> > + }
> > +}
> Hello,
>
> the return value is missing for the function or not ?
Thanks, very good catch. It should be 'static void ', no return value
since we didn't check it. Will update when repost.
>
> > +
> > +
> > static int handle_mem_memmap(void)
> > {
> > char *args = (char *)get_cmd_line_ptr();
> > @@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
> > unsigned long image_size)
> > }
> > }
> >
> > +/* Skip as many 1GB huge pages as possible in the passed region. */
> > +static void process_gb_huge_page(struct mem_vector *region, unsigned long
> > image_size)
> > +{
> > + int i = 0;
> > + unsigned long addr, size;
> > + struct mem_vector tmp;
> > +
> > + if (!max_gb_huge_pages) {
> > + store_slot_info(region, image_size);
> > + return;
> > + }
> > +
> > + addr = ALIGN(region->start, PUD_SIZE);
> > + /* If Did we raise the address above the passed in memory entry? */
> > + if (addr < region->start + region->size)
> > + size = region->size - (addr - region->start);
> > +
> > + /* Check how many 1GB huge pages can be filtered out*/
> > + while (size > PUD_SIZE && max_gb_huge_pages) {
> > + size -= PUD_SIZE;
> > + max_gb_huge_pages--;
> > + i++;
> > + }
> > +
> > + if (!i) {
> > + store_slot_info(region, image_size);
> > + return;
> > + }
> > +
> > + /* Process the remaining regions after filtering out. */
> > +
> > + if (addr >= region->start + image_size) {
> > + tmp.start = region->start;
> > + tmp.size = addr - region->start;
> > + store_slot_info(&tmp, image_size);
> > + }
> > +
> > + size = region->size - (addr - region->start) - i * PUD_SIZE;
> > +if (size >= image_size) {
> > + tmp.start = addr + i*PUD_SIZE;
> > + tmp.size = size;
> > + store_slot_info(&tmp, image_size);
> > +}
> > +}
> > +
> > static unsigned long slots_fetch_random(void)
> > {
> > unsigned long slot;
> > --
> > 2.13.6
> >
Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules
Russell King - ARM Linux writes: > On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote: >> Hi Russell, >> >> On 10 May 2018 at 02:40, Russell King - ARM Linux >> wrote: >> > This does not leak information from other namespaces because of the >> > uniqueness of the global PID. However, what it does leak is the value >> > of the global PID which is meaningless in the namespace. So, before >> > the event stream is delivered to userspace, this value needs to be >> > re-written to the namespace's PID value. >> >> Unfortunately that can't be done. The trace stream is compressed and >> needs to be decompressed using an external library. I think the only >> option is to return an error if a user is trying to use this feature >> from a namespace. > > That sounds like a sensible approach, and that should get rid of the > vpid stuff too. > > Eric, would this solve all your concerns? It does, and I have given my ack to the respin. I am moderately concerned about using the global pid with hardware. But pids are a core abstraction that aren't going anywhere. As long as hardware does not impose constraints on pids that software already does not we should be fine. Eric
[PATCH v7 4/6] regulator: pfuze100: add fsl,pmic-stby-poweroff property
Document the new optional "fsl,pmic-stby-poweroff" property. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/regulator/pfuze100.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt b/Documentation/devicetree/bindings/regulator/pfuze100.txt index c6dd3f5e485b..91fec1a0785d 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.txt +++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt @@ -4,6 +4,13 @@ Required properties: - compatible: "fsl,pfuze100", "fsl,pfuze200", "fsl,pfuze3000" - reg: I2C slave address +Optional properties: +- fsl,pmic-stby-poweroff: if present, configure the PMIC to shutdown all + power rails when PMIC_STBY_REQ line is asserted during the power off sequence. + Use this option if the SoC should be powered off by external power + management IC (PMIC) on PMIC_STBY_REQ signal. + As opposite to PMIC_STBY_REQ boards can implement PMIC_ON_REQ signal. + Required child node: - regulators: This is the list of child nodes that specify the regulator initialization data for defined regulators. Please refer to below doc -- 2.17.0
[PATCH v7 3/6] kernel/reboot.c: export pm_power_off_prepare
Export pm_power_off_prepare. It is needed to implement power off on Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). Signed-off-by: Oleksij Rempel --- kernel/reboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/reboot.c b/kernel/reboot.c index e4ced883d8de..83810d726f3e 100644 --- a/kernel/reboot.c +++ b/kernel/reboot.c @@ -49,6 +49,7 @@ int reboot_force; */ void (*pm_power_off_prepare)(void); +EXPORT_SYMBOL_GPL(pm_power_off_prepare); /** * emergency_restart - reboot the system -- 2.17.0
[PATCH v7 5/6] regulator: pfuze100-regulator: provide pm_power_off_prepare handler
On some boards the SoC can use one pin "PMIC_STBY_REQ" to notify th PMIC
about state changes. In this case internal state of PMIC must be
preconfigured for upcomming state change.
It works fine with the current regulator framework, except with the
power-off case.
This patch is providing an optional pm_power_off_prepare handler
which will configure standby state of the PMIC to disable all power lines.
In my power consumption test on RIoTBoard, I got the following results:
power off without this patch: 320 mA
power off with this patch: 2 mA
suspend to ram: 40 mA
Signed-off-by: Oleksij Rempel
---
drivers/regulator/pfuze100-regulator.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
index 63922a2167e5..f6c276ed91d8 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#define PFUZE_NUMREGS 128
@@ -42,11 +43,17 @@
#define PFUZE100_COINVOL 0x1a
#define PFUZE100_SW1ABVOL 0x20
+#define PFUZE100_SW1ABMODE 0x23
#define PFUZE100_SW1CVOL 0x2e
+#define PFUZE100_SW1CMODE 0x31
#define PFUZE100_SW2VOL0x35
+#define PFUZE100_SW2MODE 0x38
#define PFUZE100_SW3AVOL 0x3c
+#define PFUZE100_SW3AMODE 0x3f
#define PFUZE100_SW3BVOL 0x43
+#define PFUZE100_SW3BMODE 0x46
#define PFUZE100_SW4VOL0x4a
+#define PFUZE100_SW4MODE 0x4d
#define PFUZE100_SWBSTCON1 0x66
#define PFUZE100_VREFDDRCON0x6a
#define PFUZE100_VSNVSVOL 0x6b
@@ -57,6 +64,13 @@
#define PFUZE100_VGEN5VOL 0x70
#define PFUZE100_VGEN6VOL 0x71
+#define PFUZE100_SWxMODE_MASK 0xf
+#define PFUZE100_SWxMODE_APS_APS 0x8
+#define PFUZE100_SWxMODE_APS_OFF 0x4
+
+#define PFUZE100_VGENxLPWR BIT(6)
+#define PFUZE100_VGENxSTBY BIT(5)
+
enum chips { PFUZE100, PFUZE200, PFUZE3000 = 3 };
struct pfuze_regulator {
@@ -489,6 +503,69 @@ static inline struct device_node *match_of_node(int index)
}
#endif
+static struct pfuze_chip *syspm_pfuze_chip;
+
+static void pfuze_power_off_prepare(void)
+{
+ dev_info(syspm_pfuze_chip->dev, "Configure standy mode for power off");
+
+ /* Switch from default mode: APS/APS to APS/Off */
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW1ABMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW1CMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW2MODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW3AMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW3BMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW4MODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN1VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN2VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN3VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN4VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN5VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN6VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+}
+
+static int pfuze_power_off_prepare_init(struct pfuze_chip *pfuze_chip)
+{
+ if (pfuze_chip->chip_id != PFUZE100) {
+ dev_warn(pfuze_chip->dev, "Requested pm_power_off_prepare
handler for not supported chip\n");
+ return -ENODEV;
+ }
+
+ if (pm_power_off_prepare) {
+ dev_warn(pfuze_chip->dev, "pm_power_off_prepare is already
registered.\n");
+ return -EBUSY;
+ }
+
+ if (syspm_pfuze_chip) {
+ dev_warn(pfuze_chip->dev, "syspm_pfuze_chip is already set.\n");
[PATCH v7 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set
One of the Freescale recommended sequences for power off with external
PMIC is the following:
...
3. SoC is programming PMIC for power off when standby is asserted.
4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
See:
http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
page 5083
This patch implements step 4. of this sequence.
Signed-off-by: Oleksij Rempel
---
arch/arm/mach-imx/pm-imx6.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 017539dd712b..2f5c643f62fb 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -601,6 +601,28 @@ static void __init imx6_pm_common_init(const struct
imx6_pm_socdata
IMX6Q_GPR1_GINT);
}
+static void imx6_pm_stby_poweroff(void)
+{
+ imx6_set_lpm(STOP_POWER_OFF);
+ imx6q_suspend_finish(0);
+
+ mdelay(1000);
+
+ pr_emerg("Unable to poweroff system\n");
+}
+
+static int imx6_pm_stby_poweroff_probe(void)
+{
+ if (pm_power_off) {
+ pr_warn("%s: pm_power_off already claimed %p %pf!\n",
+ __func__, pm_power_off, pm_power_off);
+ return -EBUSY;
+ }
+
+ pm_power_off = imx6_pm_stby_poweroff;
+ return 0;
+}
+
void __init imx6_pm_ccm_init(const char *ccm_compat)
{
struct device_node *np;
@@ -617,6 +639,9 @@ void __init imx6_pm_ccm_init(const char *ccm_compat)
val = readl_relaxed(ccm_base + CLPCR);
val &= ~BM_CLPCR_LPM;
writel_relaxed(val, ccm_base + CLPCR);
+
+ if (of_property_read_bool(np, "fsl,pmic-stby-poweroff"))
+ imx6_pm_stby_poweroff_probe();
}
void __init imx6q_pm_init(void)
--
2.17.0
[PATCH v7 6/6] ARM: dts: imx6: RIoTboard provide standby on power off option
This board, as well as some other boards with i.MX6 and a PMIC, uses a
"PMIC_STBY_REQ" line to notify the PMIC about a state change.
The PMIC is programmed for a specific state change before triggering the
line.
In this case, PMIC_STBY_REQ can be used for stand by, sleep
and power off modes.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-riotboard.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts
b/arch/arm/boot/dts/imx6dl-riotboard.dts
index 2e98c92adff7..a0e9753ee767 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -90,6 +90,10 @@
status = "okay";
};
+&clks {
+ fsl,pmic-stby-poweroff;
+};
+
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
@@ -170,6 +174,7 @@
reg = <0x08>;
interrupt-parent = <&gpio5>;
interrupts = <16 8>;
+ fsl,pmic-stby-poweroff;
regulators {
reg_vddcore: sw1ab {/*
VDDARM_IN */
--
2.17.0
[PATCH v7 1/6] ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property
Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/imx6q-clock.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index a45ca67a9d5f..e1308346e00d 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -6,6 +6,14 @@ Required properties: - interrupts: Should contain CCM interrupt - #clock-cells: Should be <1> +Optional properties: +- fsl,pmic-stby-poweroff: Configure CCM to assert PMIC_STBY_REQ signal + on power off. + Use this property if the SoC should be powered off by external power + management IC (PMIC) triggered via PMIC_STBY_REQ signal. + Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should + be using "syscon-poweroff" driver instead. + The clock consumer should specify the desired clock by having the clock ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h for the full list of i.MX6 Quad and DualLite clock IDs. -- 2.17.0
[PATCH v7 0/6] provide power off support for iMX6 with external PMIC
2018.05.17: update patches to version v7 This patch series is providing power off support for Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). As a first step the PMIC is configured to turn off the system if the standby pin is asserted. On second step we assert the standby pin. For this reason we need to use pm_power_off_prepare. Usage of stnadby pin for power off is described in official iMX6 documentation. 2018.03.05: As this patch set touches multiple subsystems I think it would make sense for Shawn Guo to take the all patch set. The only part which didn't receive an ACK is regulator stuff. So I would hope that Mark Brown can ACK it. Kind regards, Oleksij Rempel 2017.12.06: Adding Linus. Probably there is no maintainer for this patch set. No changes are made, tested on v4.15-rc1. 2017.10.27: Last version of this patch set was send at 20 Jun 2017, this is a rebase against kernel v4.14-rc6. Probably this set got lost. If I forgot to address some comments, please point me. changes: v7: - use EXPORT_SYMBOL_GPL(pm_power_off_prepare) instead of EXPORT_SYMBOL - call imx6q_suspend_finish() directly without cpu_suspend() v6: - rename imx6_pm_poweroff to imx6_pm_stby_poweroff - fix "MPIC_STBY_REQ" typo in the comment. v5: - remove useless includes from pm-imx6.c patch - add Acked-by to "regulator: pfuze100: add fsl,pmic-stby-poweroff property" patch v4: - update comment in "regulator: pfuze100: add fsl,pmic-stby-poweroff ..." patch - add Acked-by to "ARM: imx6q: provide documentation for new ..." patch v3: - set pm_power_off_prepare = NULL on .remove. - documentation and spelling fixes. - use %pf instead of lookup_symbol_name. Oleksij Rempel (6): ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set kernel/reboot.c: export pm_power_off_prepare regulator: pfuze100: add fsl,pmic-stby-poweroff property regulator: pfuze100-regulator: provide pm_power_off_prepare handler ARM: dts: imx6: RIoTboard provide standby on power off option .../devicetree/bindings/clock/imx6q-clock.txt | 8 ++ .../bindings/regulator/pfuze100.txt | 7 ++ arch/arm/boot/dts/imx6dl-riotboard.dts| 5 + arch/arm/mach-imx/pm-imx6.c | 25 + drivers/regulator/pfuze100-regulator.c| 92 +++ kernel/reboot.c | 1 + 6 files changed, 138 insertions(+) -- 2.17.0
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On Thu, May 17, 2018 at 12:03:43PM +0800, Baoquan He wrote:
>Hi Chao,
>
>On 05/17/18 at 11:27am, Chao Fan wrote:
>> >+/* Store the number of 1GB huge pages which user specified.*/
>> >+static unsigned long max_gb_huge_pages;
>> >+
>> >+static int parse_gb_huge_pages(char *param, char* val)
>> >+{
>> >+ char *p;
>> >+ u64 mem_size;
>> >+ static bool gbpage_sz = false;
>> >+
>> >+ if (!strcmp(param, "hugepagesz")) {
>> >+ p = val;
>> >+ mem_size = memparse(p, &p);
>> >+ if (mem_size == PUD_SIZE) {
>> >+ if (gbpage_sz)
>> >+ warn("Repeadly set hugeTLB page size of 1G!\n");
>> >+ gbpage_sz = true;
>> >+ } else
>> >+ gbpage_sz = false;
>> >+ } else if (!strcmp(param, "hugepages") && gbpage_sz) {
>> >+ p = val;
>> >+ max_gb_huge_pages = simple_strtoull(p, &p, 0);
>> >+ debug_putaddr(max_gb_huge_pages);
>> >+ }
>> >+}
>> >+
>> >+
>> > static int handle_mem_memmap(void)
>> > {
>> >char *args = (char *)get_cmd_line_ptr();
>> >@@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
>> >unsigned long image_size)
>> >}
>> > }
>> >
>> >+/* Skip as many 1GB huge pages as possible in the passed region. */
>> >+static void process_gb_huge_page(struct mem_vector *region, unsigned long
>> >image_size)
>> >+{
>> >+ int i = 0;
>> >+ unsigned long addr, size;
>> >+ struct mem_vector tmp;
>> >+
>> >+ if (!max_gb_huge_pages) {
>> >+ store_slot_info(region, image_size);
>> >+ return;
>> >+ }
>> >+
>> >+ addr = ALIGN(region->start, PUD_SIZE);
>> >+ /* If Did we raise the address above the passed in memory entry? */
>> >+ if (addr < region->start + region->size)
>> >+ size = region->size - (addr - region->start);
>> >+
>> >+ /* Check how many 1GB huge pages can be filtered out*/
>> >+ while (size > PUD_SIZE && max_gb_huge_pages) {
>> >+ size -= PUD_SIZE;
>> >+ max_gb_huge_pages--;
>>
>> The global variable 'max_gb_huge_pages' means how many huge pages
>> user specified when you get it from command line.
>> But here, everytime we find a position which is good for huge page
>> allocation, the 'max_gdb_huge_page' decreased. So in my understanding,
>> it is used to store how many huge pages that we still need to search memory
>> for good slots to filter out, right?
>> If it's right, maybe the name 'max_gb_huge_pages' is not very suitable.
>> If my understanding is wrong, please tell me.
>
>No, you have understood it very right. I finished the draft patch last
>week, but changed this variable name and the function names several
>time, still I feel they are not good. However I can't get a better name.
>
>Yes, 'max_gb_huge_pages' stores how many 1GB huge pages are expected
>from kernel command-line. And in this function it will be decreased. But
>we can't define another global variable only for decreasing in this
>place.
>
>And you can see that in this patchset I only take cares of 1GB huge
>pages. While on x86 we have two kinds of huge pages, 2MB and 1GB, why
>1GB only? Because 2MB is not impacted by KASLR, please check the code in
>hugetlb_nrpages_setup() of mm/hugetlb.c . Only 1GB huge pages need be
>pre-allocated in hugetlb_nrpages_setup(), and if you look into
>hugetlb_nrpages_setup(), you will find that it will call
>alloc_bootmem_huge_page() to allocate huge pages one by one, but not at
>one time. That is why I always add 'gb' in the middle of the global
>variable and the newly added functions.
>
>And it will answer your below questions. When walk over all memory
>regions, 'max_gb_huge_pages' is still not 0, what should we do? It's
>normal and done as expected. Here hugetlb only try its best to allocate
>as many as possible according to 'max_gb_huge_pages'. If can't fully
>satisfied, it's fine. E.g on bare-metal machine with 16GB RAM, you add
>below to command-line:
>
>default_hugepagesz=1G hugepagesz=1G hugepages=20
>
>Then it will get 14 good 1GB huge pages with kaslr disabled since [0,1G)
>and [3G,4G) are touched by bios reservation and pci/firmware reservation.
>Then this 14 huge pages are maximal value which is expected. It's not a
>bug in huge page. But with kaslr enabled, it sometime only get 13 1GB
>huge pages because KASLR put kernel into one of those good 1GB huge
>pages. This is a bug.
Thanks for your explaination, I got it.
>
>I am not very familiar with huge page handling, just read code recently
>because of this kaslr bug. Hope Luiz and people from his team can help
>correct and clarify if anything is not right. Especially the function
>names, I feel it's not good, if anyone have a better idea, I will really
>appreciate that.
>>
>> >+ i++;
>> >+ }
>> >+
>> >+ if (!i) {
>> >+ store_slot_info(region, image_size);
>> >+ return;
>> >+ }
>> >+
>> >+ /* Process the remaining regions after filtering out. */
>> >+
>> This lin
Re: [PATCH] cpuidle/powernv : init all present cpus for deep states
Yes this needs to be sent to stable.
Fixes: d405a98c ("powerpc/powernv: Move cpuidle related code from setup.c
to new file")
Re: [PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input
Hi Jacopo, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [cannot apply to renesas/next v4.17-rc5] [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/Jacopo-Mondi/arm64-dts-Draak-Enable-video-inputs-and-VIN4/20180517-102013 base: git://linuxtv.org/media_tree.git master config: arm64-defconfig (attached as .config) compiler: aarch64-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 make.cross ARCH=arm64 All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/renesas/r8a77995-draak.dts:266.1-6 Label or path >> vin4 not found >> FATAL ERROR: Syntax error parsing input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 1/5] random: fix crng_ready() test
Le 13/04/2018 à 19:00, Theodore Y. Ts'o a écrit :
On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote:
What I would like to point out that more and more folks change to
getrandom(2). As this call will now unblock much later in the boot cycle,
these systems see a significant departure from the current system behavior.
E.g. an sshd using getrandom(2) would be ready shortly after the boot finishes
as of now. Now it can be a matter minutes before it responds. Thus, is such
change in the kernel behavior something for stable?
It will have some change on the kernel behavior, but not as much as
you might think. That's because in older kernels, we were *already*
blocking until crng_init > 2 --- if the getrandom(2) call happened
while crng_init was in state 0.
Even before this patch series, we didn't wake up a process blocked on
crng_init_wait until crng_init state 2 is reached:
static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
{
...
if (crng == &primary_crng && crng_init < 2) {
invalidate_batched_entropy();
crng_init = 2;
process_random_ready_list();
wake_up_interruptible(&crng_init_wait);
pr_notice("random: crng init done\n");
}
}
This is the reason why there are reports like this: "Boot delayed for
about 90 seconds until 'random: crng init done'"[1]
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1685794
So we have the problem already. There will be more cases of this
after this patch series is applied, true. But what we have already is
an inconsistent state where if you call getrandom(2) while the kernel
is in crng_init state 0, you will block until crng_init state 2, but
if you are in crng_init state 1, you will assume the CRNG is fully
initialized.
Given the documentation of how getrandom(2) works what its documented
guarantees are, I think it does justify making its behavior both more
consistent with itself, and more consistent what the security
guarantees we have promised people.
I was a little worried that on VM's this could end up causing things
to block for a long time, but an experiment on a GCE VM shows that
isn't a problem:
[0.00] Linux version 4.16.0-rc3-ext4-9-gf6b302ebca85 (tytso@cwcc)
(gcc version 7.3.0 (Debian 7.3.0-15)) #16 SMP Thu Apr 12 16:57:17 EDT 2018
[1.282220] random: fast init done
[3.987092] random: crng init done
[4.376787] EXT4-fs (sda1): re-mounted. Opts: (null)
There are some desktops where the "crng_init done" report doesn't
happen until 45-90 seconds into the boot. I don't think I've seen
reports where it takes _minutes_ however. Can you give me some
examples of such cases?
On a powerpc embedded board which has an mpc8xx processor running at
133Mhz, I now get the startup done in more than 7 minutes instead of 30
seconds. This is due to the webserver blocking on read on /dev/random
until we get 'random: crng init done':
[0.00] Linux version 4.17.0-rc4-00415-gd2f75d40072d
(root@localhost) (gcc version 5.4.0 (GCC)) #203 PREEMPT Wed May 16
16:32:02 CEST 2018
[0.295453] random: get_random_u32 called from
bucket_table_alloc+0x84/0x1bc with crng_init=0
[1.030472] device: 'random': device_add
[1.031279] device: 'urandom': device_add
[1.420069] device: 'hw_random': device_add
[2.156853] random: fast init done
[ 462.007776] random: crng init done
This has become really critical, is there anything that can be done ?
Christophe
- Ted
P.S. Of course, in a VM environment, if the host supports virtio-rng,
the boot delay problem is completely not an issue. You just have to
enable virtio-rng in the guest kernel, which I believe is already the
case for most distro kernels.
BTW, for KVM, it's fairly simple to set it the host-side support for
virtio-rng. Just add to the kvm command-line options:
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0
[PATCH] PM / devfreq: Add support for QCOM devfreq FW
The firmware present in some QCOM chipsets offloads the steps necessary for
changing the frequency of some devices (Eg: L3). This driver implements the
devfreq interface for this firmware so that various governors could be used
to scale the frequency of these devices.
Signed-off-by: Saravana Kannan
---
.../bindings/devfreq/devfreq-qcom-fw.txt | 31 ++
drivers/devfreq/Kconfig| 14 +
drivers/devfreq/Makefile | 1 +
drivers/devfreq/devfreq_qcom_fw.c | 326 +
4 files changed, 372 insertions(+)
create mode 100644
Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
create mode 100644 drivers/devfreq/devfreq_qcom_fw.c
diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
new file mode 100644
index 000..5e1aecf
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
@@ -0,0 +1,31 @@
+QCOM Devfreq FW device
+
+Some Qualcomm Technologies, Inc. (QTI) chipsets have a FW that offloads the
+steps for frequency switching. The qcom,devfreq-fw represents this FW as a
+device. Sometimes, multiple entities want to vote on the frequency request
+that is sent to the FW. The qcom,devfreq-fw-voter represents these voters as
+child devices of the corresponding qcom,devfreq-fw device.
+
+Required properties:
+- compatible: Must be "qcom,devfreq-fw" or "qcom,devfreq-fw-voter"
+Only for qcom,devfreq-fw:
+- reg: Pairs of physical base addresses and region sizes of
+ memory mapped registers.
+- reg-names: Names of the bases for the above registers. Expected
+ bases are: "en-base", "lut-base" and "perf-base".
+
+Example:
+
+ qcom,devfreq-l3 {
+ compatible = "qcom,devfreq-fw";
+ reg-names = "en-base", "lut-base", "perf-base";
+ reg = <0x18321000 0x4>, <0x18321110 0x600>, <0x18321920 0x4>;
+
+ qcom,cpu0-l3 {
+ compatible = "qcom,devfreq-fw-voter";
+ };
+
+ qcom,cpu4-l3 {
+ compatible = "qcom,devfreq-fw-voter";
+ };
+ };
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 6a172d3..8503018 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -113,6 +113,20 @@ config ARM_RK3399_DMC_DEVFREQ
It sets the frequency for the memory controller and reads the usage
counts
from hardware.
+config ARM_QCOM_DEVFREQ_FW
+ bool "Qualcomm Technologies Inc. DEVFREQ FW driver"
+ depends on ARCH_QCOM
+ select DEVFREQ_GOV_PERFORMANCE
+ select DEVFREQ_GOV_POWERSAVE
+ select DEVFREQ_GOV_USERSPACE
+ default n
+ help
+ The firmware present in some QCOM chipsets offloads the steps
+ necessary for changing the frequency of some devices (Eg: L3). This
+ driver implements the devfreq interface for this firmware so that
+ various governors could be used to scale the frequency of these
+ devices.
+
source "drivers/devfreq/event/Kconfig"
endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 32b8d4d..f1cc8990 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
+obj-$(CONFIG_ARM_QCOM_DEVFREQ_FW) += devfreq_qcom_fw.o
# DEVFREQ Event Drivers
obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/devfreq_qcom_fw.c
b/drivers/devfreq/devfreq_qcom_fw.c
new file mode 100644
index 000..3e85f76
--- /dev/null
+++ b/drivers/devfreq/devfreq_qcom_fw.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INIT_RATE 3UL
+#define XO_RATE1920UL
+#define LUT_MAX_ENTRIES40U
+#define LUT_ROW_SIZE 32
+
+struct devfreq_qcom_fw {
+ void __iomem *perf_base;
+ struct devfreq_dev_profile dp;
+ struct list_head voters;
+ struct list_head voter;
+ unsigned int index;
+};
+
+static DEFINE_SPINLOCK(voter_lock);
+
+static int devfreq_qcom_fw_target(struct device *dev, unsigned long *freq,
+ u32 flags)
+{
+ struct devfreq_qcom_fw *d = dev_get_drvdata(dev), *pd, *v;
+ struct devfreq_dev_profile *p = &d->dp;
+ unsigned int index;
+ un
Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration
Hi Vinod,
On 17 May 2018 at 13:14, Vinod wrote:
> On 11-05-18, 21:06, Baolin Wang wrote:
>> +struct sprd_dma_config {
>> + struct dma_slave_config cfg;
>> + u32 block_len;
>> + u32 transcation_len;
>
> /s/transcation/transaction
OK.
>
> now in code I see block_len and this filled by len which is sg_dma_len()?
> So why two varibales when you are using only one.
Like I explained before, we have transaction transfer, block transfer
and fragment transfer, and we should set the length for each transfer.
In future, we we will use these two variables in cyclic mode, but for
prep_sg, we just make them equal to
>
> Second, you are storing parameters programmed thru _prep call into
> _dma_config. That is not correct.
>
> We use these to store channel parameters and NOT transaction parameters which
> would differ with each txn. No wonder you can only support only 1 txn :)
Fine, we can remove block_len/transcation_len from 'struct
sprd_dma_config'. Any other issues for the 'struct sprd_dma_config'?
>
> Lastly, if these are same values why not use src/dstn_max_burst?
The fragment length will be filled by src/dstn_max_burst,so we can not
use it again.
>
>> +static enum sprd_dma_datawidth
>> +sprd_dma_get_datawidth(enum dma_slave_buswidth buswidth)
>> +{
>> + switch (buswidth) {
>> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> + return ffs(buswidth) - 1;
>> + default:
>> + return SPRD_DMA_DATAWIDTH_4_BYTES;
>
> Does default make sense, should we error out?
Not one error, maybe we can give some warning information.
>
>> +static u32 sprd_dma_get_step(enum dma_slave_buswidth buswidth)
>> +{
>> + switch (buswidth) {
>> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> + return buswidth;
>> +
>> + default:
>> + return SPRD_DMA_DWORD_STEP;
>
> Does default make sense, should we error out?
Ditto.
>
>> +static int sprd_dma_config(struct dma_chan *chan, struct sprd_dma_desc
>> *sdesc,
>> +dma_addr_t src, dma_addr_t dst,
>> +struct sprd_dma_config *slave_cfg)
>> +{
>> + struct sprd_dma_dev *sdev = to_sprd_dma_dev(chan);
>> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
>> + struct sprd_dma_chn_hw *hw = &sdesc->chn_hw;
>> + u32 fix_mode = 0, fix_en = 0, wrap_en = 0, wrap_mode = 0;
>> + u32 src_datawidth, dst_datawidth, temp;
>> +
>> + if (slave_cfg->cfg.slave_id)
>> + schan->dev_id = slave_cfg->cfg.slave_id;
>> +
>> + hw->cfg = SPRD_DMA_DONOT_WAIT_BDONE << SPRD_DMA_WAIT_BDONE_OFFSET;
>> +
>> + temp = slave_cfg->wrap_ptr & SPRD_DMA_LOW_ADDR_MASK;
>> + temp |= (src >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
>> + hw->wrap_ptr = temp;
>> +
>> + temp = slave_cfg->wrap_to & SPRD_DMA_LOW_ADDR_MASK;
>> + temp |= (dst >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
>> + hw->wrap_to = temp;
>> +
>> + hw->src_addr = src & SPRD_DMA_LOW_ADDR_MASK;
>> + hw->des_addr = dst & SPRD_DMA_LOW_ADDR_MASK;
>> +
>> + if ((slave_cfg->src_step != 0 && slave_cfg->dst_step != 0)
>> + || (slave_cfg->src_step | slave_cfg->dst_step) == 0) {
>
> this check doesnt seem right to me, what are you trying here?
This is SPRD DMA internal feature: address-fix transfer. If the src
step and dst step both are 0 or both are not 0, that means we can not
enable the fix mode.
If one is 0 and another one is not, we can enable the fix mode.
>
>> + fix_en = 0;
>> + } else {
>> + fix_en = 1;
>> + if (slave_cfg->src_step)
>> + fix_mode = 1;
>> + else
>> + fix_mode = 0;
>> + }
>> +
>> + if (slave_cfg->wrap_ptr && slave_cfg->wrap_to) {
>> + wrap_en = 1;
>> + if (slave_cfg->wrap_to == src) {
>> + wrap_mode = 0;
>> + } else if (slave_cfg->wrap_to == dst) {
>> + wrap_mode = 1;
>> + } else {
>> + dev_err(sdev->dma_dev.dev, "invalid wrap mode\n");
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + hw->intc = slave_cfg->int_mode | SPRD_DMA_CFG_ERR_INT_EN;
>> +
>> + src_datawidth = sprd_dma_get_datawidth(slave_cfg->cfg.src_addr_width);
>> + dst_datawidth = sprd_dma_get_datawidth(slave_cfg->cfg.dst_addr_width);
>> +
>> + temp = src_datawidth << SPRD_DMA_SRC_DATAWIDTH_OFFSET;
>> + temp |= dst_datawidth << SPRD_DMA_DES_DATAWIDTH_OFFSET;
>> + temp |= slave_cfg->req_mode << SPRD_DMA_REQ_MODE_OFFSET;
>> + temp |= wrap_mode << SPRD_DMA_WRAP_SEL_OFFSET;
>> + temp |= wrap_en << SPRD_DMA_WRAP_EN_OFFSET;
>> + temp |= fix_mode << SPRD_DMA_FIX_SEL_OF
Re: [PATCH 0/3] Add support to disable sensor groups in P9
On 05/15/2018 08:32 PM, Guenter Roeck wrote: > On Thu, Mar 22, 2018 at 04:24:32PM +0530, Shilpasri G Bhat wrote: >> This patch series adds support to enable/disable OCC based >> inband-sensor groups at runtime. The environmental sensor groups are >> managed in HWMON and the remaining platform specific sensor groups are >> managed in /sys/firmware/opal. >> >> The firmware changes required for this patch is posted below: >> https://lists.ozlabs.org/pipermail/skiboot/2018-March/010812.html >> > > Sorry for not getting back earlier. This is a tough one. > Thanks for the reply. I have tried to answer your questions according to my understanding below: > Key problem is that you are changing the ABI with those new attributes. > On top of that, the attributes _do_ make some sense (many chips support > enabling/disabling of individual sensors), suggesting that those or > similar attributes may or even should at some point be added to the ABI. > > At the same time, returning "0" as measurement values when sensors are > disabled does not seem like a good idea, since "0" is a perfectly valid > measurement, at least for most sensors. I agree. > > Given that, we need to have a discussion about adding _enable attributes to > the ABI > what is the scope, IIUC the scope should be RW and the attribute is defined for each supported sensor group > when should the attributes exist and when not, We control this currently via device-tree > do we want/need power_enable or powerX_enable or both, and so on), and We need power_enable right now > what to return if a sensor is disabled (such as -ENODATA). -ENODATA sounds good. Thanks and Regards, Shilpa Once we have an > agreement, we can continue with an implementation. > > Guenter > >> Shilpasri G Bhat (3): >> powernv:opal-sensor-groups: Add support to enable sensor groups >> hwmon: ibmpowernv: Add attributes to enable/disable sensor groups >> powernv: opal-sensor-groups: Add attributes to disable/enable sensors >> >> .../ABI/testing/sysfs-firmware-opal-sensor-groups | 34 ++ >> Documentation/hwmon/ibmpowernv | 31 - >> arch/powerpc/include/asm/opal-api.h| 4 +- >> arch/powerpc/include/asm/opal.h| 2 + >> .../powerpc/platforms/powernv/opal-sensor-groups.c | 104 - >> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 + >> drivers/hwmon/ibmpowernv.c | 127 >> +++-- >> 7 files changed, 265 insertions(+), 38 deletions(-) >> create mode 100644 >> Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups >> >> -- >> 1.8.3.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration
On 17-05-18, 14:02, Baolin Wang wrote:
> Hi Vinod,
>
> On 17 May 2018 at 13:14, Vinod wrote:
> > On 11-05-18, 21:06, Baolin Wang wrote:
> >> +struct sprd_dma_config {
> >> + struct dma_slave_config cfg;
> >> + u32 block_len;
> >> + u32 transcation_len;
> >
> > /s/transcation/transaction
>
> OK.
>
> >
> > now in code I see block_len and this filled by len which is sg_dma_len()?
> > So why two varibales when you are using only one.
>
> Like I explained before, we have transaction transfer, block transfer
> and fragment transfer, and we should set the length for each transfer.
> In future, we we will use these two variables in cyclic mode, but for
> prep_sg, we just make them equal to
Please add them when you have use for it. Sorry linux kernel is not a place for
dumping future use work
>
> >
> > Second, you are storing parameters programmed thru _prep call into
> > _dma_config. That is not correct.
> >
> > We use these to store channel parameters and NOT transaction parameters
> > which
> > would differ with each txn. No wonder you can only support only 1 txn :)
>
> Fine, we can remove block_len/transcation_len from 'struct
> sprd_dma_config'. Any other issues for the 'struct sprd_dma_config'?
Yes see the comments on prep_
>
> >
> > Lastly, if these are same values why not use src/dstn_max_burst?
>
> The fragment length will be filled by src/dstn_max_burst,so we can not
> use it again.
>
> >
> >> +static enum sprd_dma_datawidth
> >> +sprd_dma_get_datawidth(enum dma_slave_buswidth buswidth)
> >> +{
> >> + switch (buswidth) {
> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> >> + return ffs(buswidth) - 1;
> >> + default:
> >> + return SPRD_DMA_DATAWIDTH_4_BYTES;
> >
> > Does default make sense, should we error out?
>
> Not one error, maybe we can give some warning information.
well client programmed a wrong value, so I expect this to error out.
>
> >
> >> +static u32 sprd_dma_get_step(enum dma_slave_buswidth buswidth)
> >> +{
> >> + switch (buswidth) {
> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> >> + return buswidth;
> >> +
> >> + default:
> >> + return SPRD_DMA_DWORD_STEP;
> >
> > Does default make sense, should we error out?
>
> Ditto.
>
> >
> >> +static int sprd_dma_config(struct dma_chan *chan, struct sprd_dma_desc
> >> *sdesc,
> >> +dma_addr_t src, dma_addr_t dst,
> >> +struct sprd_dma_config *slave_cfg)
> >> +{
> >> + struct sprd_dma_dev *sdev = to_sprd_dma_dev(chan);
> >> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> >> + struct sprd_dma_chn_hw *hw = &sdesc->chn_hw;
> >> + u32 fix_mode = 0, fix_en = 0, wrap_en = 0, wrap_mode = 0;
> >> + u32 src_datawidth, dst_datawidth, temp;
> >> +
> >> + if (slave_cfg->cfg.slave_id)
> >> + schan->dev_id = slave_cfg->cfg.slave_id;
> >> +
> >> + hw->cfg = SPRD_DMA_DONOT_WAIT_BDONE << SPRD_DMA_WAIT_BDONE_OFFSET;
> >> +
> >> + temp = slave_cfg->wrap_ptr & SPRD_DMA_LOW_ADDR_MASK;
> >> + temp |= (src >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
> >> + hw->wrap_ptr = temp;
> >> +
> >> + temp = slave_cfg->wrap_to & SPRD_DMA_LOW_ADDR_MASK;
> >> + temp |= (dst >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
> >> + hw->wrap_to = temp;
> >> +
> >> + hw->src_addr = src & SPRD_DMA_LOW_ADDR_MASK;
> >> + hw->des_addr = dst & SPRD_DMA_LOW_ADDR_MASK;
> >> +
> >> + if ((slave_cfg->src_step != 0 && slave_cfg->dst_step != 0)
> >> + || (slave_cfg->src_step | slave_cfg->dst_step) == 0) {
> >
> > this check doesnt seem right to me, what are you trying here?
>
> This is SPRD DMA internal feature: address-fix transfer. If the src
> step and dst step both are 0 or both are not 0, that means we can not
> enable the fix mode.
> If one is 0 and another one is not, we can enable the fix mode.
A comment here would help explain this :)
>
> >
> >> + fix_en = 0;
> >> + } else {
> >> + fix_en = 1;
> >> + if (slave_cfg->src_step)
> >> + fix_mode = 1;
> >> + else
> >> + fix_mode = 0;
> >> + }
> >> +
> >> + if (slave_cfg->wrap_ptr && slave_cfg->wrap_to) {
> >> + wrap_en = 1;
> >> + if (slave_cfg->wrap_to == src) {
> >> + wrap_mode = 0;
> >> + } else if (slave_cfg->wrap_to == dst) {
> >> + wrap_mode = 1;
> >> + } else {
> >> + dev_err(sdev->dma_dev.dev, "invalid wrap mode\n");
> >> + return -EINVAL;
> >> + }
> >> + }
> >> +
> >> + hw->intc = slave_
[RFC] hexagon: Drop the unused variable zero_page_mask
Hexagon arch does not seem to have subscribed to _HAVE_COLOR_ZERO_PAGE framework. Hence zero_page_mask variable is not needed. Signed-off-by: Anshuman Khandual --- I will have to request some one with hexagon system to compile and test this patch. Dont have access to hardware. arch/hexagon/include/asm/pgtable.h | 1 - arch/hexagon/mm/init.c | 3 --- 2 files changed, 4 deletions(-) diff --git a/arch/hexagon/include/asm/pgtable.h b/arch/hexagon/include/asm/pgtable.h index aef02f7ca8aa..65125d0b02dd 100644 --- a/arch/hexagon/include/asm/pgtable.h +++ b/arch/hexagon/include/asm/pgtable.h @@ -30,7 +30,6 @@ /* A handy thing to have if one has the RAM. Declared in head.S */ extern unsigned long empty_zero_page; -extern unsigned long zero_page_mask; /* * The PTE model described here is that of the Hexagon Virtual Machine, diff --git a/arch/hexagon/mm/init.c b/arch/hexagon/mm/init.c index 192584d5ac2f..1495d45e472d 100644 --- a/arch/hexagon/mm/init.c +++ b/arch/hexagon/mm/init.c @@ -39,9 +39,6 @@ unsigned long __phys_offset; /* physical kernel offset >> 12 */ /* Set as variable to limit PMD copies */ int max_kernel_seg = 0x303; -/* think this should be (page_size-1) the way it's used...*/ -unsigned long zero_page_mask; - /* indicate pfn's of high memory */ unsigned long highstart_pfn, highend_pfn; -- 2.11.0
[PATCH] KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in unmap_stage2_range
I ever met a panic under memory pressure tests(start 20 guests and run memhog in the host). -begin [35380.800950] BUG: Bad page state in process qemu-kvm pfn:dd0b6 [35380.805825] page:7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 [35380.815024] flags: 0x1fffc000() [35380.818845] raw: 1fffc000 ecf98147 [35380.826569] raw: dead0100 dead0200 8017c001c000 [35380.805825] page:7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 [35380.815024] flags: 0x1fffc000() [35380.818845] raw: 1fffc000 ecf98147 [35380.826569] raw: dead0100 dead0200 8017c001c000 [35380.834294] page dumped because: nonzero _refcount [35380.839069] Modules linked in: vhost_net vhost tap ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter fcoe libfcoe libfc 8021q garp mrp stp llc scsi_transport_fc openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_defrag_ipv6 nf_nat nf_conntrack vfat fat rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm mlx5_ib ib_core crc32_ce ipmi_ssif tpm_tis tpm_tis_core sg nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_multipath ip_tables xfs libcrc32c mlx5_core mlxfw devlink ahci_platform libahci_platform libahci qcom_emac sdhci_acpi sdhci hdma mmc_core hdma_mgmt i2c_qup dm_mirror dm_region_hash dm_log dm_mod [35380.908341] CPU: 29 PID: 18323 Comm: qemu-kvm Tainted: G W 4.14.15-5.hxt.aarch64 #1 [35380.917107] Hardware name: [35380.930909] Call trace: [35380.933345] [] dump_backtrace+0x0/0x22c [35380.938723] [] show_stack+0x24/0x2c [35380.943759] [] dump_stack+0x8c/0xb0 [35380.948794] [] bad_page+0xf4/0x154 [35380.953740] [] free_pages_check_bad+0x90/0x9c [35380.959642] [] free_pcppages_bulk+0x464/0x518 [35380.965545] [] free_hot_cold_page+0x22c/0x300 [35380.971448] [] __put_page+0x54/0x60 [35380.976484] [] unmap_stage2_range+0x170/0x2b4 [35380.982385] [] kvm_unmap_hva_handler+0x30/0x40 [35380.988375] [] handle_hva_to_gpa+0xb0/0xec [35380.994016] [] kvm_unmap_hva_range+0x5c/0xd0 [35380.999833] [] kvm_mmu_notifier_invalidate_range_start+0x60/0xb0 [35381.007387] [] __mmu_notifier_invalidate_range_start+0x64/0x8c [35381.014765] [] try_to_unmap_one+0x78c/0x7a4 [35381.020493] [] rmap_walk_ksm+0x124/0x1a0 [35381.025961] [] rmap_walk+0x94/0x98 [35381.030909] [] try_to_unmap+0x100/0x124 [35381.036293] [] unmap_and_move+0x480/0x6fc [35381.041847] [] migrate_pages+0x10c/0x288 [35381.047318] [] compact_zone+0x238/0x954 [35381.052697] [] compact_zone_order+0xc4/0xe8 [35381.058427] [] try_to_compact_pages+0x160/0x294 [35381.064503] [] __alloc_pages_direct_compact+0x68/0x194 [35381.071187] [] __alloc_pages_nodemask+0xc20/0xf7c [35381.077437] [] alloc_pages_vma+0x1a4/0x1c0 [35381.083080] [] do_huge_pmd_anonymous_page+0x128/0x324 [35381.089677] [] __handle_mm_fault+0x71c/0x7e8 [35381.095492] [] handle_mm_fault+0xf8/0x194 [35381.101049] [] __get_user_pages+0x124/0x34c [35381.106777] [] populate_vma_page_range+0x90/0x9c [35381.112941] [] __mm_populate+0xc4/0x15c [35381.118322] [] SyS_mlockall+0x100/0x164 [35381.123705] Exception stack(0x800dce5f3ec0 to 0x800dce5f4000) [35381.130128] 3ec0: 0003 d6e6024cc9b87e00 be94f000 [35381.137940] 3ee0: 0002 cf6fc3c0 [35381.145753] 3f00: 00e6 cf6fc490 eeeab0f0 d6e6024cc9b87e00 [35381.153565] 3f20: be81b3c0 0020 9e53eff806b5 [35381.161379] 3f40: be94de48 a7c269b0 0011 eeeabf68 [35381.169190] 3f60: ceacfe60 be94f000 be9ba358 be7ffb80 [35381.177003] 3f80: be9ba000 be959f64 be94f000 [35381.184815] 3fa0: eeeabdb0 be5f3bf8 eeeabdb0 [35381.192628] 3fc0: a7c269b8 6000 0003 00e6 [35381.200440] 3fe0: [35381.208254] [] __sys_trace_return+0x0/0x4 [35381.213809] Disabling lock debugging due to kernel taint end-- The root cause might be what I fixed at [1]. But from arm kvm points of view, it would be better we caught the exception earlier and clearer. If the size is not PAGE_SIZE aligned, unmap_stage2_range might unmap the wrong(more or less) page range. Hence it caused the "BUG: Bad page state" [1] https://lkml.org/lkml/2018/5/3/1042 Signed-off-by: jia...@hxt-semitech.com --- virt/kvm/arm/mmu.c | 2 ++ 1 file changed
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On 05/17/18 at 01:53pm, Chao Fan wrote:
> On Thu, May 17, 2018 at 12:03:43PM +0800, Baoquan He wrote:
> >Hi Chao,
> >
> >On 05/17/18 at 11:27am, Chao Fan wrote:
> >> >+/* Store the number of 1GB huge pages which user specified.*/
> >> >+static unsigned long max_gb_huge_pages;
> >> >+
> >> >+static int parse_gb_huge_pages(char *param, char* val)
> >> >+{
> >> >+ char *p;
> >> >+ u64 mem_size;
> >> >+ static bool gbpage_sz = false;
> >> >+
> >> >+ if (!strcmp(param, "hugepagesz")) {
> >> >+ p = val;
> >> >+ mem_size = memparse(p, &p);
> >> >+ if (mem_size == PUD_SIZE) {
> >> >+ if (gbpage_sz)
> >> >+ warn("Repeadly set hugeTLB page size of 1G!\n");
> >> >+ gbpage_sz = true;
> >> >+ } else
> >> >+ gbpage_sz = false;
> >> >+ } else if (!strcmp(param, "hugepages") && gbpage_sz) {
> >> >+ p = val;
> >> >+ max_gb_huge_pages = simple_strtoull(p, &p, 0);
> >> >+ debug_putaddr(max_gb_huge_pages);
> >> >+ }
> >> >+}
> >> >+
> >> >+
> >> > static int handle_mem_memmap(void)
> >> > {
> >> > char *args = (char *)get_cmd_line_ptr();
> >> >@@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector
> >> >*region, unsigned long image_size)
> >> > }
> >> > }
> >> >
> >> >+/* Skip as many 1GB huge pages as possible in the passed region. */
> >> >+static void process_gb_huge_page(struct mem_vector *region, unsigned
> >> >long image_size)
> >> >+{
> >> >+ int i = 0;
> >> >+ unsigned long addr, size;
> >> >+ struct mem_vector tmp;
> >> >+
> >> >+ if (!max_gb_huge_pages) {
> >> >+ store_slot_info(region, image_size);
> >> >+ return;
> >> >+ }
> >> >+
> >> >+ addr = ALIGN(region->start, PUD_SIZE);
> >> >+ /* If Did we raise the address above the passed in memory entry? */
> >> >+ if (addr < region->start + region->size)
> >> >+ size = region->size - (addr - region->start);
> >> >+
> >> >+ /* Check how many 1GB huge pages can be filtered out*/
> >> >+ while (size > PUD_SIZE && max_gb_huge_pages) {
> >> >+ size -= PUD_SIZE;
> >> >+ max_gb_huge_pages--;
> >>
> >> The global variable 'max_gb_huge_pages' means how many huge pages
> >> user specified when you get it from command line.
> >> But here, everytime we find a position which is good for huge page
> >> allocation, the 'max_gdb_huge_page' decreased. So in my understanding,
> >> it is used to store how many huge pages that we still need to search memory
> >> for good slots to filter out, right?
> >> If it's right, maybe the name 'max_gb_huge_pages' is not very suitable.
> >> If my understanding is wrong, please tell me.
> >
> >No, you have understood it very right. I finished the draft patch last
> >week, but changed this variable name and the function names several
> >time, still I feel they are not good. However I can't get a better name.
> >
> >Yes, 'max_gb_huge_pages' stores how many 1GB huge pages are expected
> >from kernel command-line. And in this function it will be decreased. But
> >we can't define another global variable only for decreasing in this
> >place.
> >
> >And you can see that in this patchset I only take cares of 1GB huge
> >pages. While on x86 we have two kinds of huge pages, 2MB and 1GB, why
> >1GB only? Because 2MB is not impacted by KASLR, please check the code in
> >hugetlb_nrpages_setup() of mm/hugetlb.c . Only 1GB huge pages need be
> >pre-allocated in hugetlb_nrpages_setup(), and if you look into
> >hugetlb_nrpages_setup(), you will find that it will call
> >alloc_bootmem_huge_page() to allocate huge pages one by one, but not at
> >one time. That is why I always add 'gb' in the middle of the global
> >variable and the newly added functions.
> >
> >And it will answer your below questions. When walk over all memory
> >regions, 'max_gb_huge_pages' is still not 0, what should we do? It's
> >normal and done as expected. Here hugetlb only try its best to allocate
> >as many as possible according to 'max_gb_huge_pages'. If can't fully
> >satisfied, it's fine. E.g on bare-metal machine with 16GB RAM, you add
> >below to command-line:
> >
> >default_hugepagesz=1G hugepagesz=1G hugepages=20
> >
> >Then it will get 14 good 1GB huge pages with kaslr disabled since [0,1G)
> >and [3G,4G) are touched by bios reservation and pci/firmware reservation.
> >Then this 14 huge pages are maximal value which is expected. It's not a
> >bug in huge page. But with kaslr enabled, it sometime only get 13 1GB
> >huge pages because KASLR put kernel into one of those good 1GB huge
> >pages. This is a bug.
>
> Thanks for your explaination, I got it.
>
> >
> >I am not very familiar with huge page handling, just read code recently
> >because of this kaslr bug. Hope Luiz and people from his team can help
> >correct and clarify if anything is not right. Especially the function
> >names, I feel it's not good, if anyone have a better idea, I will really
> >appreciate that.
> >>
> >> >+ i++;
> >> >+ }
Re: [PATCH] mmc: block: propagate correct returned value in mmc_rpmb_ioctl
On Thu, May 17, 2018 at 4:45 AM, Shawn Lin wrote:
>
> On 2018/5/17 3:20, Mathieu Malaterre wrote:
>>
>> In commit 97548575bef3 ("mmc: block: Convert RPMB to a character device")
>> a
>> new function `mmc_rpmb_ioctl` was added. The final return is simply
>> returning a value of `0` instead of propagating the correct return code.
>>
>> Discovered during a compilation with W=1, silence the following gcc
>> warning
>>
>>drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not
>> used [-Wunused-but-set-variable]
>>
>
> Good catch! But hey, which gcc are you using now? Mine, gcc-linaro-
> 6.3.1-2017.05-x86_64_aarch64-linux-gnu, with W=1 doesn't warn about
> this.
$ powerpc-linux-gnu-gcc --version
powerpc-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is the default powerpc cross compiler on Debian stable (no
change). Config is simply a ppc32 (with some minor customization).
> And it's worth backporting to stable.
I am not familiar with the process, do I need to submit a v2 to add the line:
Cc: # v4.15+
?
> Reviewed-by: Shawn Lin
>
>
>> Signed-off-by: Mathieu Malaterre
>> ---
>> drivers/mmc/core/block.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
>> index 9e923cd1d80e..38a7586b00cc 100644
>> --- a/drivers/mmc/core/block.c
>> +++ b/drivers/mmc/core/block.c
>> @@ -2485,7 +2485,7 @@ static long mmc_rpmb_ioctl(struct file *filp,
>> unsigned int cmd,
>> break;
>> }
>> - return 0;
>> + return ret;
>> }
>> #ifdef CONFIG_COMPAT
>>
>
[PATCH v4 00/31] kconfig: move compiler capability tests to Kconfig
[Introduction] The motivation of this work is to move the compiler option tests to Kconfig from Makefile. A number of kernel features require the compiler support. Enabling such features blindly in Kconfig ends up with a lot of nasty build-time testing in Makefiles. If a chosen feature turns out unsupported by the compiler, what the build system can do is either to disable it (silently!) or to forcibly break the build, despite Kconfig has let the user to enable it. By moving the compiler capability tests to Kconfig, Kconfig entries will be visible only when they are available. [Major Changes in V4] - In V4, I slightly change the syntax of a function call. I chose grammatical consistency and simplicity. Anyway, Kconfig is deviating from Make behavior already. In v3, a function call looked like this: $(func-name arg1,arg2,arg3) In v4, a function is invoked like follows: $(func-name,arg1,arg2,arg3) The difference is that the function name and the first argument are separated by a comma. - V3 supported single-letter variable like $X. V4 dropped it because we do not need multiple ways to do the same thing. You must always enclose a variable name like $(X). - Support lazy argument expansion. This is necessary for implementing 'if', 'and', 'or' functions as in Make. - Add more built-in functions: 'if', 'error', 'filename', 'lineno' - Error out if a recursive variable references itself eventually. For example, X = $(X) ends up with a circular expansion. It must be terminated since the expansion would continue eternally. - Update Documentation and unit-tests, accordingly. [Major Changes in V3] This version looks more like Make. - Use = operator instead of 'macro' keyword to define a user-defined function. - 'Recursively expanded variable' is implemented as a side-effect. A variable is a function with zero argument. - Support simply expanded variable which is defined by := operator - Support += operator. Probably, this feature will be useful to accumulate compiler flags. At least, Clang needs some prerequisite flags such as triplet to test other compiler flags. - Support $(info ...) and $(warning ...) built-in functions, which were useful while I was debugging this. - Add documentation - Add unit tests - Collect helpers to scripts/Kconfig.include [Old Versions] V3: https://lkml.org/lkml/2018/4/13/37 V2: https://lkml.org/lkml/2018/2/16/610 V1: https://lkml.org/lkml/2018/2/16/610 RFC: https://lkml.org/lkml/2018/2/8/429 Masahiro Yamada (31): kbuild: remove kbuild cache kbuild: remove CONFIG_CROSS_COMPILE support kconfig: reference environment variables directly and remove 'option env=' kconfig: remove string expansion in file_lookup() kconfig: remove string expansion for mainmenu after yyparse() kconfig: remove sym_expand_string_value() kconfig: add built-in function support kconfig: add 'shell' built-in function kconfig: replace $(UNAME_RELEASE) with function call kconfig: begin PARAM state only when seeing a command keyword kconfig: support user-defined function and recursively expanded variable kconfig: support simply expanded variable kconfig: support append assignment operator kconfig: expand lefthand side of assignment statement kconfig: add 'info', 'warning', and 'error' built-in functions kconfig: add 'if' built-in function kconfig: add 'filename' and 'lineno' built-in variables kconfig: error out if a recursive variable references itself Documentation: kconfig: document a new Kconfig macro language kconfig: test: add Kconfig macro language tests kconfig: show compiler version text in the top comment kconfig: add basic helper macros to scripts/Kconfig.include stack-protector: test compiler capability in Kconfig and drop AUTO mode kconfig: add CC_IS_GCC and GCC_VERSION kconfig: add CC_IS_CLANG and CLANG_VERSION gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT kcov: test compiler capability in Kconfig and correct dependency gcc-plugins: move GCC version check for PowerPC to Kconfig gcc-plugins: test plugin support in Kconfig and clean up Makefile gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig Documentation/kbuild/kconfig-language.txt | 8 - Documentation/kbuild/kconfig-macro-language.txt| 252 Kconfig| 10 +- MAINTAINERS| 3 +- Makefile | 105 +--- arch/Kconfig | 49 +- arch/arm64/Kconfig | 1 + arch/arm64/Makefile| 6 - arch/powerpc/Kconfig | 2 +- arch/sh/Kconfig| 4 +- arch/sparc/Kconfig
[PATCH v4 05/31] kconfig: remove string expansion for mainmenu after yyparse()
Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.
The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
main menus during parsing") can go away.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Simplify the patch. Just remove the text expansion.
scripts/kconfig/zconf.y | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 3a4a0fa..22e318c 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -109,7 +109,7 @@ static struct menu *current_menu, *current_entry;
%%
input: nl start | start;
-start: mainmenu_stmt stmt_list | no_mainmenu_stmt stmt_list;
+start: mainmenu_stmt stmt_list | stmt_list;
/* mainmenu entry */
@@ -118,19 +118,6 @@ mainmenu_stmt: T_MAINMENU prompt nl
menu_add_prompt(P_MENU, $2, NULL);
};
-/* Default main menu, if there's no mainmenu entry */
-
-no_mainmenu_stmt: /* empty */
-{
- /*
-* Hack: Keep the main menu title on the heap so we can safely free it
-* later regardless of whether it comes from the 'prompt' in
-* mainmenu_stmt or here
-*/
- menu_add_prompt(P_MENU, xstrdup("Linux Kernel Configuration"), NULL);
-};
-
-
stmt_list:
/* empty */
| stmt_list common_stmt
@@ -528,7 +515,6 @@ word_opt: /* empty */ { $$ = NULL; }
void conf_parse(const char *name)
{
- const char *tmp;
struct symbol *sym;
int i;
@@ -544,10 +530,10 @@ void conf_parse(const char *name)
if (!modules_sym)
modules_sym = sym_find( "n" );
- tmp = rootmenu.prompt->text;
- rootmenu.prompt->text = _(rootmenu.prompt->text);
- rootmenu.prompt->text = sym_expand_string_value(rootmenu.prompt->text);
- free((char*)tmp);
+ if (!menu_has_prompt(&rootmenu)) {
+ current_entry = &rootmenu;
+ menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);
+ }
menu_finalize(&rootmenu);
for_all_symbols(i, sym) {
--
2.7.4
[PATCH v4 27/31] kcov: test compiler capability in Kconfig and correct dependency
As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
be used with care - it forces a lower limit of another symbol, ignoring
the dependency. Currently, KCOV can select GCC_PLUGINS even if arch
does not select HAVE_GCC_PLUGINS. This could cause the unmet direct
dependency.
Now that Kconfig can test compiler capability, let's handle this in a
more sophisticated way.
There are two ways to enable KCOV; use the compiler that natively
supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
the compiler has ability to build GCC plugins. Hence, the correct
dependency for KCOV is:
depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
You do not need to build the SANCOV plugin if the compiler already
supports -fsanitize-coverage=trace-pc. Hence, the select should be:
select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
scripts/Makefile.gcc-plugins can be cleaner.
I also cleaned up Kconfig and scripts/Makefile.kcov as well.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- Replace the previous 'select -> imply' patch with
a new approach
Changes in v2:
- Drop depends on GCC_VERSION
Makefile | 2 +-
lib/Kconfig.debug| 11 +++
scripts/Makefile.gcc-plugins | 6 +-
scripts/Makefile.kcov| 10 ++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index 12c222d..b5c1301 100644
--- a/Makefile
+++ b/Makefile
@@ -623,7 +623,7 @@ all: vmlinux
KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call
cc-disable-warning,maybe-uninitialized,)
-export CFLAGS_GCOV CFLAGS_KCOV
+export CFLAGS_GCOV
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..bba2298 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -736,12 +736,15 @@ config ARCH_HAS_KCOV
only for x86_64. KCOV requires testing on other archs, and most likely
disabling of instrumentation for some early boot code.
+config CC_HAS_SANCOV_TRACE_PC
+ def_bool $(cc-option, -fsanitize-coverage=trace-pc)
+
config KCOV
bool "Code coverage for fuzzing"
depends on ARCH_HAS_KCOV
+ depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
select DEBUG_FS
- select GCC_PLUGINS if !COMPILE_TEST
- select GCC_PLUGIN_SANCOV if !COMPILE_TEST
+ select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
help
KCOV exposes kernel code coverage information in a form suitable
for coverage-guided fuzzing (randomized testing).
@@ -755,7 +758,7 @@ config KCOV
config KCOV_ENABLE_COMPARISONS
bool "Enable comparison operands collection by KCOV"
depends on KCOV
- default n
+ depends on $(cc-option, -fsanitize-coverage=trace-cmp)
help
KCOV also exposes operands of every comparison in the instrumented
code along with operand sizes and PCs of the comparison instructions.
@@ -765,7 +768,7 @@ config KCOV_ENABLE_COMPARISONS
config KCOV_INSTRUMENT_ALL
bool "Instrument all code by default"
depends on KCOV
- default y if KCOV
+ default y
help
If you are doing generic system call fuzzing (like e.g. syzkaller),
then you will want to instrument the whole kernel and you should
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 7f5c862..0ce3802 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -14,16 +14,12 @@ ifdef CONFIG_GCC_PLUGINS
endif
ifdef CONFIG_GCC_PLUGIN_SANCOV
-ifeq ($(strip $(CFLAGS_KCOV)),)
# It is needed because of the gcc-plugin.sh and gcc version checks.
gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so
- ifneq ($(PLUGINCC),)
-CFLAGS_KCOV := $(SANCOV_PLUGIN)
- else
+ ifeq ($(PLUGINCC),)
$(warning warning: cannot use CONFIG_KCOV:
-fsanitize-coverage=trace-pc is not supported by compiler)
endif
-endif
endif
gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so
diff --git a/scripts/Makefile.kcov b/scripts/Makefile.kcov
index 5cc7203..d71ba73 100644
--- a/scripts/Makefile.kcov
+++ b/scripts/Makefile.kcov
@@ -1,7 +1,9 @@
ifdef CONFIG_KCOV
-CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
-ifeq ($(CONFIG_KCOV_ENABLE_COMPARISONS),y)
-CFLAGS_KCOV += $(call cc-option,-fsanitize-coverage=trace-cmp,)
-endif
+
+kcov-flags-$(CONFIG_CC_HAS_SANCOV_TRACE_PC)+= -fsanitize-coverage=trace-pc
+kcov-flags-$(CONFIG_KCOV_ENABLE_COMPARISONS) += -fsanitize-coverage=trace-cmp
+kcov-flags-$(CONFIG_GCC_PLUGIN_SANKOV) +=
-fplugin=$(objtree)/scripts/gcc-plugi
[PATCH v4 16/31] kconfig: add 'if' built-in function
The 'if' function is invoked in the form:
$(if,condition,then-part,else-part)
The behavior is slightly different from that of Make.
In Make, the condition is true if the expansion contains any characters
(even space). That is why we sometimes need $(strip ...) in the
condition part.
I thought it was a nasty part in Make, so I changed it for Kconfig;
the condition is true if the expansion contains any characters except
whitespaces.
Unlike the other functions, the parameters passed to 'if' are lazily
expanded. The then-part is expanded only when the condition true,
and the else-part when false. If the parameters were evaluated
before passed to the 'if' function, $(if,$(cond),$(error,...))
would terminate the parsing regardless of $(cond).
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Newly added
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 591bcf7..88844a7 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -111,6 +111,32 @@ static char *do_error(int argc, char *argv[], int
old_argc, char *old_argv[])
return NULL;
}
+static char *do_if(int argc, char *argv[], int old_argc, char *old_argv[])
+{
+ char *cond, *p, *res;
+ const char *sel;
+
+ cond = expand_string_with_args(argv[0], old_argc, old_argv);
+ p = cond;
+
+ /* condition is true if any character except whitespaces is contained */
+ while (*p == ' ' || *p == '\t')
+ p++;
+
+ if (*p)
+ sel = argv[1];
+ else if (argc >= 3)
+ sel = argv[2];
+ else
+ sel = "";
+
+ res = expand_string_with_args(sel, old_argc, old_argv);
+
+ free(cond);
+
+ return res;
+}
+
static char *do_info(int argc, char *argv[], int old_argc, char *old_argv[])
{
printf("%s\n", argv[0]);
@@ -168,6 +194,7 @@ static char *do_warning(int argc, char *argv[], int
old_argc, char *old_argv[])
static const struct function function_table[] = {
/* Name MIN MAX EXP?Function */
{ "error", 1, 1, true, do_error },
+ { "if", 2, 3, false, do_if },
{ "info", 1, 1, true, do_info },
{ "shell", 1, 1, true, do_shell },
{ "warning",1, 1, true, do_warning },
--
2.7.4
[PATCH v4 14/31] kconfig: expand lefthand side of assignment statement
Make expands the lefthand side of assignment statements. In fact,
Kbuild relies on it since kernel makefiles mostly look like follows:
obj-$(CONFIG_FOO) += foo.o
Do likewise in Kconfig.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
scripts/kconfig/zconf.l | 7 +++
1 file changed, 7 insertions(+)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index c68ca56b..ae33e9b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,6 +114,13 @@ n [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
+ ({n}|$)+{
+ /* this token includes at least one '$' */
+ yylval.string = expand_token(yytext, yyleng);
+ if (strlen(yylval.string))
+ return T_VARIABLE;
+ free(yylval.string);
+ }
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return
T_ASSIGN; }
"+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return
T_ASSIGN; }
--
2.7.4
[PATCH v4 20/31] kconfig: test: add Kconfig macro language tests
Here are the test cases I used for developing the text expansion
feature.
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Adjust for the change in function call syntax.
- Remove unnecessarily tricky tests.
Changes in v3:
- newly added
Changes in v2: None
.../kconfig/tests/preprocess/builtin_func/Kconfig | 29 +
.../tests/preprocess/builtin_func/__init__.py | 8
.../tests/preprocess/builtin_func/expected_stderr | 7
.../tests/preprocess/builtin_func/expected_stdout | 1 +
.../tests/preprocess/circular_expansion/Kconfig| 3 ++
.../preprocess/circular_expansion/__init__.py | 10 +
.../preprocess/circular_expansion/expected_stderr | 1 +
scripts/kconfig/tests/preprocess/escape/Kconfig| 21 ++
.../kconfig/tests/preprocess/escape/__init__.py| 7
.../tests/preprocess/escape/expected_stderr| 5 +++
scripts/kconfig/tests/preprocess/variable/Kconfig | 48 ++
.../kconfig/tests/preprocess/variable/__init__.py | 7
.../tests/preprocess/variable/expected_stderr | 9
13 files changed, 156 insertions(+)
create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/Kconfig
create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/__init__.py
create mode 100644
scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
create mode 100644
scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
create mode 100644 scripts/kconfig/tests/preprocess/circular_expansion/Kconfig
create mode 100644
scripts/kconfig/tests/preprocess/circular_expansion/__init__.py
create mode 100644
scripts/kconfig/tests/preprocess/circular_expansion/expected_stderr
create mode 100644 scripts/kconfig/tests/preprocess/escape/Kconfig
create mode 100644 scripts/kconfig/tests/preprocess/escape/__init__.py
create mode 100644 scripts/kconfig/tests/preprocess/escape/expected_stderr
create mode 100644 scripts/kconfig/tests/preprocess/variable/Kconfig
create mode 100644 scripts/kconfig/tests/preprocess/variable/__init__.py
create mode 100644 scripts/kconfig/tests/preprocess/variable/expected_stderr
diff --git a/scripts/kconfig/tests/preprocess/builtin_func/Kconfig
b/scripts/kconfig/tests/preprocess/builtin_func/Kconfig
new file mode 100644
index 000..5f51135
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/builtin_func/Kconfig
@@ -0,0 +1,29 @@
+# 'info' prints the argument to stdout.
+$(info,hello world 0)
+
+# 'warning' is similar, but it sends its argument to stderr,
+# and the message is prefixed with the current file name and line number.
+$(warning,hello world 1)
+
+# 'shell' executes a command, and returns its stdout.
+$(warning,$(shell,echo hello world 3))
+
+# Every newline in the output is replaced with a space,
+# but any trailing newlines are deleted.
+$(warning,$(shell,printf 'hello\nworld\n\n4\n\n\n'))
+
+# 'filename' is expanded to the currently parsed file name,
+# 'lineno' to the line number.
+$(warning,filename=$(filename))
+$(warning,lineno=$(lineno))
+
+# 'if' selects which argument to expand
+# depending on the condition part.
+cond := 1
+$(warning,$(if,$(cond),y,n))
+cond :=
+$(warning,$(if,$(cond),y,n))
+
+# 'if' delays the expansion of arguments.
+# In the following, the 'error' function should not be evaluated.
+$(if,,$(error,this should not be expanded))
diff --git a/scripts/kconfig/tests/preprocess/builtin_func/__init__.py
b/scripts/kconfig/tests/preprocess/builtin_func/__init__.py
new file mode 100644
index 000..ec7c3e2
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/builtin_func/__init__.py
@@ -0,0 +1,8 @@
+"""
+Built-in function tests.
+"""
+
+def test(conf):
+assert conf.oldaskconfig() == 0
+assert conf.stdout_contains('expected_stdout')
+assert conf.stderr_matches('expected_stderr')
diff --git a/scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
b/scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
new file mode 100644
index 000..a4f27a6
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
@@ -0,0 +1,7 @@
+Kconfig:6: hello world 1
+Kconfig:9: hello world 3
+Kconfig:13: hello world 4
+Kconfig:17: filename=Kconfig
+Kconfig:18: lineno=18
+Kconfig:23: y
+Kconfig:25: n
diff --git a/scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
b/scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
new file mode 100644
index 000..82de3a7
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
@@ -0,0 +1 @@
+hello world 0
diff --git a/scripts/kconfig/tests/preprocess/circular_expansion/Kconfig
b/scripts/kconfig/tests/preprocess/circular_expansion/Kconfig
new file mode 100644
index 000..54debf1
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/circular_expansion/Kconfig
@@ -0,0 +1,3 @@
+X = $(Y)
+Y = $(X)
+$(info $(X))
diff --git a/scripts/kconfig/tests/preprocess/circular_expansion/__init__.py
b/scripts/kconfig/tests/preprocess/circular
[PATCH v4 12/31] kconfig: support simply expanded variable
The previous commit added variable and user-defined function. They
work similarly in the sense that the evaluation is deferred until
they are used.
This commit adds another type of variable, simply expanded variable,
as we see in Make.
The := operator defines a simply expanded variable, expanding the
righthand side immediately. This works like traditional programming
language variables.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 7 ++-
scripts/kconfig/preprocess.c | 6 --
scripts/kconfig/zconf.l | 3 ++-
scripts/kconfig/zconf.y | 5 +++--
4 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 2b16d6e..6303193 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -49,8 +49,13 @@ const char * sym_get_string_value(struct symbol *sym);
const char * prop_get_type_name(enum prop_type type);
/* preprocess.c */
+enum variable_flavor {
+ VAR_SIMPLE,
+ VAR_RECURSIVE,
+};
void env_write_dep(FILE *f, const char *auto_conf_name);
-void variable_add(const char *name, const char *value);
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor);
void variable_all_del(void);
char *expand_string(const char *in);
char *expand_dollar(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 88580c4..5d7bd9d 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -246,7 +246,8 @@ static char *variable_expand(const char *name, int argc,
char *argv[],
return res;
}
-void variable_add(const char *name, const char *value)
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor)
{
struct variable *v;
@@ -259,7 +260,8 @@ void variable_add(const char *name, const char *value)
list_add_tail(&v->node, &variable_list);
}
- v->value = xstrdup(value);
+ v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+ xstrdup(value);
}
static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 19e5ebf..aa76942 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,7 +114,8 @@ n [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
- "=" { BEGIN(ASSIGN_VAL); return T_ASSIGN; }
+ "=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return
T_ASSIGN; }
+ ":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return
T_ASSIGN; }
[[:blank:]]+
. warn_ignored_character(*yytext);
\n {
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 6201119..16432d0 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -41,6 +41,7 @@ static struct menu *current_menu, *current_entry;
struct expr *expr;
struct menu *menu;
const struct kconf_id *id;
+ enum variable_flavor flavor;
}
%token T_MAINMENU
@@ -78,7 +79,7 @@ static struct menu *current_menu, *current_entry;
%token T_OPEN_PAREN
%token T_EOL
%token T_VARIABLE
-%token T_ASSIGN
+%token T_ASSIGN
%token T_ASSIGN_VAL
%left T_OR
@@ -517,7 +518,7 @@ word_opt: /* empty */ { $$ = NULL; }
/* assignment statement */
-assignment_stmt: T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3);
free($1); free($3); }
+assignment_stmt: T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3,
$2); free($1); free($3); }
assign_val:
/* empty */ { $$ = xstrdup(""); };
--
2.7.4
[PATCH v4 31/31] arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig
This becomes much neater in Kconfig. Signed-off-by: Masahiro Yamada Acked-by: Will Deacon Reviewed-by: Kees Cook --- Changes in v4: - Rebase Changes in v3: - Newly added Changes in v2: None arch/arm64/Kconfig | 1 + arch/arm64/Makefile | 6 -- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index eb2cf49..119b18e 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -43,6 +43,7 @@ config ARM64 select ARCH_USE_QUEUED_RWLOCKS select ARCH_SUPPORTS_MEMORY_FAILURE select ARCH_SUPPORTS_ATOMIC_RMW + select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 5 || CC_IS_CLANG select ARCH_SUPPORTS_NUMA_BALANCING select ARCH_WANT_COMPAT_IPC_PARSE_VERSION select ARCH_WANT_FRAME_POINTERS diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 87f7d2f..cefd1e9 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -56,12 +56,6 @@ KBUILD_AFLAGS+= $(lseinstr) $(brokengasinst) KBUILD_CFLAGS += $(call cc-option,-mabi=lp64) KBUILD_AFLAGS += $(call cc-option,-mabi=lp64) -ifeq ($(cc-name),clang) -KBUILD_CFLAGS += -DCONFIG_ARCH_SUPPORTS_INT128 -else -KBUILD_CFLAGS += $(call cc-ifversion, -ge, 0500, -DCONFIG_ARCH_SUPPORTS_INT128) -endif - ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) KBUILD_CPPFLAGS+= -mbig-endian CHECKFLAGS += -D__AARCH64EB__ -- 2.7.4
[PATCH v4 24/31] kconfig: add CC_IS_GCC and GCC_VERSION
This will be useful to specify the required compiler version, like this: config FOO bool "Use Foo" depends on GCC_VERSION >= 40800 help This feature requires GCC 4.8 or newer. Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v4: None Changes in v3: None Changes in v2: None init/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/init/Kconfig b/init/Kconfig index 66f0463..c6ac856 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -8,6 +8,14 @@ config DEFCONFIG_LIST default ARCH_DEFCONFIG default "arch/$(ARCH)/defconfig" +config CC_IS_GCC + def_bool $(success, $(CC) --version | grep -q gcc) + +config GCC_VERSION + int + default $(shell, $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 's/^0*//') if CC_IS_GCC + default 0 + config CONSTRUCTORS bool depends on !UML -- 2.7.4
[PATCH v4 28/31] gcc-plugins: move GCC version check for PowerPC to Kconfig
For PowerPC, GCC 5.2 is the requirement for GCC plugins. Move the version check to Kconfig so that the GCC plugin menus will be hidden if an older compiler is in use. Signed-off-by: Masahiro Yamada Acked-by: Andrew Donnellan --- Changes in v4: None Changes in v3: - Move comment to Kconfig as well Changes in v2: None arch/powerpc/Kconfig | 2 +- scripts/Makefile.gcc-plugins | 8 2 files changed, 1 insertion(+), 9 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index c32a181..17e53e6 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -195,7 +195,7 @@ config PPC select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER - select HAVE_GCC_PLUGINS + select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200 # plugin support on gcc <= 5.1 is buggy on PPC select HAVE_GENERIC_GUP select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx) select HAVE_IDE diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 0ce3802..1e92353 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@ -53,14 +53,6 @@ gcc-plugins-check: FORCE ifdef CONFIG_GCC_PLUGINS ifeq ($(PLUGINCC),) ifneq ($(GCC_PLUGINS_CFLAGS),) - # Various gccs between 4.5 and 5.1 have bugs on powerpc due to missing - # header files. gcc <= 4.6 doesn't work at all, gccs from 4.8 to 5.1 have - # issues with 64-bit targets. - ifeq ($(ARCH),powerpc) -ifeq ($(call cc-ifversion, -le, 0501, y), y) - @echo "Cannot use CONFIG_GCC_PLUGINS: plugin support on gcc <= 5.1 is buggy on powerpc, please upgrade to gcc 5.2 or newer" >&2 && exit 1 -endif - endif ifeq ($(call cc-ifversion, -ge, 0405, y), y) $(Q)$(srctree)/scripts/gcc-plugin.sh --show-error "$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)" || true @echo "Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?" >&2 && exit 1 -- 2.7.4
[PATCH v4 22/31] kconfig: add basic helper macros to scripts/Kconfig.include
Kconfig got text processing tools like we see in Make. Add Kconfig
helper macros to scripts/Kconfig.include like we collect Makefile
macros in scripts/Kbuild.include.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v4:
- source scripts/Kconfig.include
from arch/x86/um/Kconfig since UML is special
- Use { $(1); } for 'success' macro for better performance
- Use -E instead of -c for 'cc-option' macro for better performance
- Add 'if-success' macro
Changes in v3:
- Move helpers to scripts/Kconfig.include
Changes in v2: None
Kconfig | 2 ++
MAINTAINERS | 1 +
arch/x86/um/Kconfig | 2 ++
scripts/Kconfig.include | 24
4 files changed, 29 insertions(+)
create mode 100644 scripts/Kconfig.include
diff --git a/Kconfig b/Kconfig
index 5b55d87..a90d9f9 100644
--- a/Kconfig
+++ b/Kconfig
@@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
comment "Compiler: $(CC_VERSION_TEXT)"
+source "scripts/Kconfig.include"
+
source "arch/$(SRCARCH)/Kconfig"
diff --git a/MAINTAINERS b/MAINTAINERS
index b7d7ae61..1667cee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7634,6 +7634,7 @@ L:linux-kbu...@vger.kernel.org
S: Maintained
F: Documentation/kbuild/kconfig*
F: scripts/kconfig/
+F: scripts/Kconfig.include
KDUMP
M: Dave Young
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index a992f8e..9d529f2 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -3,6 +3,8 @@ mainmenu "User Mode Linux/$(SUBARCH) $(KERNELVERSION) Kernel
Configuration"
comment "Compiler: $(CC_VERSION_TEXT)"
+source "scripts/Kconfig.include"
+
source "arch/um/Kconfig.common"
menu "UML-specific options"
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
new file mode 100644
index 000..b1502f4
--- /dev/null
+++ b/scripts/Kconfig.include
@@ -0,0 +1,24 @@
+# Kconfig helper macros
+
+# Convenient variables
+comma := ,
+quote := "
+squote := '
+empty :=
+space := $(empty) $(empty)
+
+# $(if-success,,,)
+# if exits with 0, otherwise.
+if-success = $(shell, { $(1); } >/dev/null 2>&1 && echo "$(2)" || echo "$(3)")
+
+# $(success,)
+# y if exits with 0, n otherwise
+success = $(if-success, $(1),y,n)
+
+# $(cc-option,)
+# y if the compiler supports , n otherwise
+cc-option = $(success, $(CC) -Werror $(1) -E -x c /dev/null -o /dev/null)
+
+# $(ld-option,)
+# y if the linker supports , n otherwise
+ld-option = $(success, $(LD) -v $(1))
--
2.7.4
[PATCH v4 30/31] gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
Now that the compiler's plugin support is checked in Kconfig,
all{yes,mod}config will not be bothered.
Remove 'depends on !COMPILE_TEST' for GCC_PLUGINS.
'depends on !COMPILE_TEST' for the following three are still kept:
GCC_PLUGIN_CYC_COMPLEXITY
GCC_PLUGIN_STRUCTLEAK_VERBOSE
GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
Kees said to do so because the first two are too noisy, and the last
one would reduce the compile test coverage. I commented the reasons
in arch/Kconfig.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- Add comment about reason
Changes in v2: None
arch/Kconfig | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 70f585f..6e8f0cf 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -420,7 +420,6 @@ menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
depends on PLUGIN_HOSTCC != ""
- depends on !COMPILE_TEST
help
GCC plugins are loadable modules that provide extra features to the
compiler. They are useful for runtime instrumentation and static
analysis.
@@ -430,7 +429,7 @@ menuconfig GCC_PLUGINS
config GCC_PLUGIN_CYC_COMPLEXITY
bool "Compute the cyclomatic complexity of a function" if EXPERT
depends on GCC_PLUGINS
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# too noisy
help
The complexity M of a function's control flow graph is defined as:
M = E - N + 2P
@@ -497,7 +496,7 @@ config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# too noisy
help
This option will cause a warning to be printed each time the
structleak plugin finds a variable it thinks needs to be
@@ -537,7 +536,7 @@ config GCC_PLUGIN_RANDSTRUCT
config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
bool "Use cacheline-aware structure randomization"
depends on GCC_PLUGIN_RANDSTRUCT
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# do not reduce test coverage
help
If you say Y here, the RANDSTRUCT randomization will make a
best effort at restricting randomization to cacheline-sized
--
2.7.4
[PATCH v4 23/31] stack-protector: test compiler capability in Kconfig and drop AUTO mode
Move the test for -fstack-protector(-strong) option to Kconfig.
If the compiler does not support the option, the corresponding menu
is automatically hidden. If STRONG is not supported, it will fall
back to REGULAR. If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly handled by the dependency solver of
Kconfig, hence removed.
I also turned the 'choice' into only two boolean symbols. The use of
'choice' is not a good idea here, because all of all{yes,mod,no}config
would choose the first visible value, while we want allnoconfig to
disable as many features as possible.
X86 has additional shell scripts in case the compiler supports those
options, but generates broken code. I added CC_HAS_SANE_STACKPROTECTOR
to test this. I had to add -m32 to gcc-x86_32-has-stack-protector.sh
to make it work correctly.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Makefile | 93 ++-
arch/Kconfig | 32 ---
arch/x86/Kconfig | 11 +++-
scripts/gcc-x86_32-has-stack-protector.sh | 7 +--
scripts/gcc-x86_64-has-stack-protector.sh | 5 --
5 files changed, 28 insertions(+), 120 deletions(-)
diff --git a/Makefile b/Makefile
index 7529825..12c222d 100644
--- a/Makefile
+++ b/Makefile
@@ -672,55 +672,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
endif
-# This selects the stack protector compiler flag. Testing it is delayed
-# until after .config has been reprocessed, in the prepare-compiler-check
-# target.
-ifdef CONFIG_CC_STACKPROTECTOR_AUTO
- stackp-flag := $(call cc-option,-fstack-protector-strong,$(call
cc-option,-fstack-protector))
- stackp-name := AUTO
-else
-ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
- stackp-flag := -fstack-protector
- stackp-name := REGULAR
-else
-ifdef CONFIG_CC_STACKPROTECTOR_STRONG
- stackp-flag := -fstack-protector-strong
- stackp-name := STRONG
-else
- # If either there is no stack protector for this architecture or
- # CONFIG_CC_STACKPROTECTOR_NONE is selected, we're done, and $(stackp-name)
- # is empty, skipping all remaining stack protector tests.
- #
- # Force off for distro compilers that enable stack protector by default.
- KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
-endif
-endif
-endif
-# Find arch-specific stack protector compiler sanity-checking script.
-ifdef stackp-name
-ifneq ($(stackp-flag),)
- stackp-path :=
$(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh
- stackp-check := $(wildcard $(stackp-path))
- # If the wildcard test matches a test script, run it to check functionality.
- ifdef stackp-check
-ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS)
$(biarch)),y)
- stackp-broken := y
-endif
- endif
- ifndef stackp-broken
-# If the stack protector is functional, enable code that depends on it.
-KBUILD_CPPFLAGS += -DCONFIG_CC_STACKPROTECTOR
-# Either we've already detected the flag (for AUTO) or we'll fail the
-# build in the prepare-compiler-check rule (for specific flag).
-KBUILD_CFLAGS += $(stackp-flag)
- else
-# We have to make sure stack protector is unconditionally disabled if
-# the compiler is broken (in case we're going to continue the build in
-# AUTO mode).
-KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
- endif
-endif
-endif
+stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR) := -fstack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG) := -fstack-protector-strong
+
+KBUILD_CFLAGS += $(stackp-flags-y)
ifeq ($(cc-name),clang)
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
@@ -1099,7 +1055,7 @@ endif
# prepare2 creates a makefile if using a separate output directory.
# From this point forward, .config has been reprocessed, so any rules
# that need to depend on updated CONFIG_* values can be checked here.
-prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic
+prepare2: prepare3 outputmakefile asm-generic
prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
include/config/auto.conf
@@ -1125,43 +1081,6 @@ uapi-asm-generic:
PHONY += prepare-objtool
prepare-objtool: $(objtool_target)
-# Check for CONFIG flags that require compiler support. Abort the build
-# after .config has been processed, but before the kernel build starts.
-#
-# For security-sensitive CONFIG options, we don't want to fallback and/or
-# silently change which compiler flags will be used, since that leads to
-# producing kernels with different security feature characteristics
-# depending on the compiler used. (For example, "But I selected
-# CC_STACKPROTECTOR_STRONG! Why did it build with _REGULAR?!")
-PHONY += prepare-compiler-check
-prepare-co
[GIT PULL] s390 patches for 4.17-rc6
Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: A few more additional changes for 4.17: * A fix for the vfio ccw translation code * Update an incorrect email address in the MAINTAINERS file * Fix a division by zero oops in the cpum_sf code found by trinity * Two fixes for the error handling of the qdio code * Several spectre related patches to convert all left-over indirect branches in the kernel to expoline branches * Update defconfigs to avoid warnings due to the netfilter Kconfig changes * Avoid several compiler warnings in the kexec_file code for s390 Halil Pasic (1): vfio: ccw: fix cleanup if cp_prefetch fails Harald Freudenberger (1): MAINTAINERS: update s390 zcrypt maintainers email address Hendrik Brueckner (1): s390/cpum_sf: ensure sample frequency of perf event attributes is non-zero Julian Wiedmann (2): s390/qdio: fix access to uninitialized qdio_q fields s390/qdio: don't release memory in qdio_setup_irq() Martin Schwidefsky (9): s390: move expoline assembler macros to a header s390/crc32-vx: use expoline for indirect branches s390/lib: use expoline for indirect branches s390/ftrace: use expoline for indirect branches s390/kernel: use expoline for indirect branches s390: move spectre sysfs attribute code s390: remove indirect branch from do_softirq_own_stack s390: extend expoline to BC instructions s390: use expoline thunks in the BPF JIT Sebastian Ott (2): s390: update defconfigs s390/kexec_file: add declaration of purgatory related globals MAINTAINERS | 2 +- arch/s390/configs/debug_defconfig | 9 +- arch/s390/configs/performance_defconfig | 8 +- arch/s390/crypto/crc32be-vx.S | 5 +- arch/s390/crypto/crc32le-vx.S | 4 +- arch/s390/include/asm/nospec-insn.h | 196 arch/s390/include/asm/purgatory.h | 6 + arch/s390/kernel/Makefile | 1 + arch/s390/kernel/asm-offsets.c | 1 + arch/s390/kernel/base.S | 24 ++-- arch/s390/kernel/entry.S| 105 - arch/s390/kernel/irq.c | 5 +- arch/s390/kernel/mcount.S | 14 ++- arch/s390/kernel/nospec-branch.c| 44 --- arch/s390/kernel/nospec-sysfs.c | 21 arch/s390/kernel/perf_cpum_sf.c | 4 + arch/s390/kernel/reipl.S| 7 +- arch/s390/kernel/swsusp.S | 10 +- arch/s390/lib/mem.S | 19 ++-- arch/s390/net/bpf_jit.S | 16 ++- arch/s390/net/bpf_jit_comp.c| 63 +- drivers/s390/cio/qdio_setup.c | 12 +- drivers/s390/cio/vfio_ccw_cp.c | 13 ++- 23 files changed, 422 insertions(+), 167 deletions(-) create mode 100644 arch/s390/include/asm/nospec-insn.h create mode 100644 arch/s390/kernel/nospec-sysfs.c diff --git a/MAINTAINERS b/MAINTAINERS index dd66ae9..2ad3306 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12239,7 +12239,7 @@ F: Documentation/s390/vfio-ccw.txt F: include/uapi/linux/vfio_ccw.h S390 ZCRYPT DRIVER -M: Harald Freudenberger +M: Harald Freudenberger L: linux-s...@vger.kernel.org W: http://www.ibm.com/developerworks/linux/linux390/ S: Supported diff --git a/arch/s390/configs/debug_defconfig b/arch/s390/configs/debug_defconfig index 6176fe9..941d8cc 100644 --- a/arch/s390/configs/debug_defconfig +++ b/arch/s390/configs/debug_defconfig @@ -261,9 +261,9 @@ CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_IP_VS_PE_SIP=m CONFIG_NF_CONNTRACK_IPV4=m -CONFIG_NF_TABLES_IPV4=m +CONFIG_NF_TABLES_IPV4=y CONFIG_NFT_CHAIN_ROUTE_IPV4=m -CONFIG_NF_TABLES_ARP=m +CONFIG_NF_TABLES_ARP=y CONFIG_NFT_CHAIN_NAT_IPV4=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_AH=m @@ -284,7 +284,7 @@ CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_NF_CONNTRACK_IPV6=m -CONFIG_NF_TABLES_IPV6=m +CONFIG_NF_TABLES_IPV6=y CONFIG_NFT_CHAIN_ROUTE_IPV6=m CONFIG_NFT_CHAIN_NAT_IPV6=m CONFIG_IP6_NF_IPTABLES=m @@ -305,7 +305,7 @@ CONFIG_IP6_NF_RAW=m CONFIG_IP6_NF_SECURITY=m CONFIG_IP6_NF_NAT=m CONFIG_IP6_NF_TARGET_MASQUERADE=m -CONFIG_NF_TABLES_BRIDGE=m +CONFIG_NF_TABLES_BRIDGE=y CONFIG_RDS=m CONFIG_RDS_RDMA=m CONFIG_RDS_TCP=m @@ -604,7 +604,6 @@ CONFIG_DETECT_HUNG_TASK=y CONFIG_WQ_WATCHDOG=y CONFIG_PANIC_ON_OOPS=y CONFIG_DEBUG_TIMEKEEPING=y -CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y CONFIG_PROVE_LOCKING=y CONFIG_LOCK_STAT=y CONFIG_DEBUG_LOCKDEP=y diff --git a/arch/s390/configs/performance_defconfig b/arch/s390/configs/performance_defconfig index c105bcc..eb6f75f 100644 --- a/arch/s390/configs/performance_defconfig +++ b/arch/s390/configs/performance_defconfig @@ -259,9 +259,9 @@ CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONF
[PATCH v4 25/31] kconfig: add CC_IS_CLANG and CLANG_VERSION
This will be useful to describe the clang version dependency.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
init/Kconfig | 7 +++
scripts/clang-version.sh | 18 --
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index c6ac856..3aeb37a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -16,6 +16,13 @@ config GCC_VERSION
default $(shell, $(srctree)/scripts/gcc-version.sh -p $(CC) | sed
's/^0*//') if CC_IS_GCC
default 0
+config CC_IS_CLANG
+ def_bool $(success, $(CC) --version | grep -q clang)
+
+config CLANG_VERSION
+ int
+ default $(shell, $(srctree)/scripts/clang-version.sh $(CC))
+
config CONSTRUCTORS
bool
depends on !UML
diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh
index 9780efa..dbf0a31 100755
--- a/scripts/clang-version.sh
+++ b/scripts/clang-version.sh
@@ -10,24 +10,14 @@
# clang-5.0.1 etc.
#
-if [ "$1" = "-p" ] ; then
- with_patchlevel=1;
- shift;
-fi
-
compiler="$*"
-if [ ${#compiler} -eq 0 ]; then
- echo "Error: No compiler specified."
- printf "Usage:\n\t$0 \n"
+if !( $compiler --version | grep -q clang) ; then
+ echo 0
exit 1
fi
MAJOR=$(echo __clang_major__ | $compiler -E -x c - | tail -n 1)
MINOR=$(echo __clang_minor__ | $compiler -E -x c - | tail -n 1)
-if [ "x$with_patchlevel" != "x" ] ; then
- PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n
1)
- printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
-else
- printf "%02d%02d\\n" $MAJOR $MINOR
-fi
+PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n 1)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.7.4
[PATCH v3 3/4] dt-bindings: serial: Add compatible for Mediatek MT8183
This adds dt-binding documentation of uart for Mediatek MT8183 SoC Platform. Signed-off-by: Erin Lo --- Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index f73abff..4783336 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -15,6 +15,7 @@ Required properties: * "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS + * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS * "mediatek,mt6577-uart" for MT6577 and all of the above - reg: The base address of the UART register bank. -- 1.9.1
[PATCH v3 4/4] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
From: Ben Ho
Add basic chip support for Mediatek 8183
Signed-off-by: Ben Ho
Signed-off-by: Erin Lo
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 31 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 182
3 files changed, 214 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index ac17f60..2836261 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -5,3 +5,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
new file mode 100644
index 000..9b52559
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+/dts-v1/;
+#include "mt8183.dtsi"
+
+/ {
+ model = "MediaTek MT8183 evaluation board";
+ compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x8000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
new file mode 100644
index 000..03edf9c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8183";
+ interrupt-parent = <&sysirq>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core2 {
+ cpu = <&cpu6>;
+ };
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+ };
+
+ cpu0: cpu@000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x002>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x003>;
+ enable-method = "psci";
+ };
+
+ cpu4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x100>;
+ enable-method = "psci";
+ };
+
+ cpu5: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x101>;
+ enable-method = "ps
[PATCH v3 2/4] dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183
This adds dt-binding documentation of SYSIRQ for Mediatek MT8183 SoC Platform. Signed-off-by: Erin Lo --- .../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt index 07bf0b9..5ff48a8 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -5,6 +5,7 @@ interrupt. Required properties: - compatible: should be + "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183 "mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173 "mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135 "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127 -- 1.9.1
[PATCH v4 21/31] kconfig: show compiler version text in the top comment
The kernel configuration phase is now tightly coupled with the compiler in use. It will be nice to show the compiler information in Kconfig. The compiler information will be displayed like this: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config scripts/kconfig/conf --oldaskconfig Kconfig * * Linux/arm64 4.16.0-rc1 Kernel Configuration * * * Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011 * * * General setup * Compile also drivers which will not load (COMPILE_TEST) [N/y/?] If you use GUI methods such as menuconfig, it will be displayed in the top menu. This is simply implemented by using the 'comment' statement. So, it will be saved into the .config file as well. This commit has a very important meaning. If the compiler is upgraded, Kconfig must be re-run since different compilers have different sets of supported options. All referenced environments are written to include/config/auto.conf.cmd so that any environment change triggers syncconfig, and prompt the user to input new values if needed. With this commit, something like follows will be added to include/config/auto.conf.cmd ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011" include/config/auto.conf: FORCE endif Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v4: - Add comment to arch/x86/um/Kconfig as well Changes in v3: None Changes in v2: None Kconfig | 2 ++ Makefile| 2 ++ arch/x86/um/Kconfig | 2 ++ 3 files changed, 6 insertions(+) diff --git a/Kconfig b/Kconfig index 4af1b42..5b55d87 100644 --- a/Kconfig +++ b/Kconfig @@ -5,4 +5,6 @@ # mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration" +comment "Compiler: $(CC_VERSION_TEXT)" + source "arch/$(SRCARCH)/Kconfig" diff --git a/Makefile b/Makefile index 01b2211..7529825 100644 --- a/Makefile +++ b/Makefile @@ -442,6 +442,8 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL export KBUILD_ARFLAGS +export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1) + # When compiling out-of-tree modules, put MODVERDIR in the module # tree rather than in the kernel tree. The kernel tree might # even be read-only. diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig index 6a15c4d..a992f8e 100644 --- a/arch/x86/um/Kconfig +++ b/arch/x86/um/Kconfig @@ -1,6 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 mainmenu "User Mode Linux/$(SUBARCH) $(KERNELVERSION) Kernel Configuration" +comment "Compiler: $(CC_VERSION_TEXT)" + source "arch/um/Kconfig.common" menu "UML-specific options" -- 2.7.4
