Re: [RFC PATCH 8/9] soundwire: intel: remove platform devices and provide new interface
On Mon, Sep 16, 2019 at 04:23:41PM -0500, Pierre-Louis Bossart wrote:
> +/**
> + * sdw_intel_probe() - SoundWire Intel probe routine
> + * @parent_handle: ACPI parent handle
> + * @res: resource data
> + *
> + * This creates SoundWire Master and Slave devices below the controller.
> + * All the information necessary is stored in the context, and the res
> + * argument pointer can be freed after this step.
> + */
> +struct sdw_intel_ctx
> +*sdw_intel_probe(struct sdw_intel_res *res)
> +{
> + return sdw_intel_probe_controller(res);
> +}
> +EXPORT_SYMBOL(sdw_intel_probe);
> +
> +/**
> + * sdw_intel_startup() - SoundWire Intel startup
> + * @ctx: SoundWire context allocated in the probe
> + *
> + */
> +int sdw_intel_startup(struct sdw_intel_ctx *ctx)
> +{
> + return sdw_intel_startup_controller(ctx);
> +}
> +EXPORT_SYMBOL(sdw_intel_startup);
Why are you exporting these functions if no one calls them?
thanks,
greg k-h
Re: [PATCH] staging: exfat: add exfat filesystem code to
On Tue, Sep 17, 2019 at 02:31:34PM +0900, Park Ju Hyung wrote: > On Tue, 17 Sep 2019 00:19:36 -0400, "Valdis Klētnieks" said: > > I'm working off a somewhat cleaned up copy of Samsung's original driver, > > because that's what I had knowledge of. If the sdfat driver is closer to > > being > > mergeable, I'd not object if that got merged instead. > > Greg, as Valdis mentioned here, the staging tree driver is just another exFAT > fork > from Samsung. > What's the point of using a much older driver? It's the fact that it actually was in a form that could be merged, no one has done that with the sdfat code :) > sdFAT is clearly more matured and been put into more recent production > softwares. > And as I wrote in previous email, it does include some real fixes. What fixes? That's what I'm asking here. How do we "know" that this is better than what we currently have today? We don't, so it's a bit hard to tell someone, "delete the work you did and replace it with this other random chunk of code, causing you a bunch more work in the process for no specific reason other than it looks 'newer'." :( > As Namjae said too, Samsung would be more interested in merging sdFAT to > upstream. > If we diverge, Samsung will have less reasons to contribute their patches to > upstream. Are they going to do this if we do take the sdfat code? If so, great, but I need to get someone to agree that this will happen. > Also, I think it makes much more sense to make Samsung the maintainer of this > driver > (if they're willing to put in the manpower to do so). Asking them would be > the first > step in doing so. They are more than willing to start contributing and being a co-maintainer of it, it needs all the help it can get. But "someone" from samsung, or anywhere else, has to be willing to step up here and do this work. Without that happening, I don't see a reason to change at this point in time. Rembember, kernel development happens because people do the work, which Valdis did, and continues to do. Throwing that away because of the thought that someone else might do some work in the future is not how we work. I recommend looking at what we have in the tree now, and seeing what is missing compared to "sdfat". I know a lot of places in the exfat code that needs to be fixed up, odds are they are the same stuff that needs to be resolved in sdfat as well. thanks, greg k-h
Re: [PATCH 4/5] clk: qcom: Initialise clock drivers earlier
On Tue, Sep 17, 2019 at 1:24 AM Stephen Boyd wrote: > > Quoting Amit Kucheria (2019-09-11 15:32:33) > > Initialise the clock drivers on sdm845 and qcs404 in core_initcall so we > > can have earlier access to cpufreq during booting. > > > > Signed-off-by: Amit Kucheria > > --- > > Did you want this patch to go through clk tree? Yes, This patch can go in via the clk tree regardless of the rest of the series. Regards, Amit
Re: pci: endpoint test BUG
On 16/09/19 4:52 PM, Lorenzo Pieralisi wrote:
> On Mon, Sep 16, 2019 at 10:06:30AM +0800, Hillf Danton wrote:
>>
>> On Sun, 15 Sep 2019 09:34:37 -0700
>>>
>>> Kernel is 5.3-rc8 on x86_64.
>>>
>>> Loading and removing the pci-epf-test module causes a BUG.
>>>
>>>
>>> [40928.435755] calling pci_epf_test_init+0x0/0x1000 [pci_epf_test] @ 12132
>>> [40928.436717] initcall pci_epf_test_init+0x0/0x1000 [pci_epf_test]
>>> returned 0 after 891 usecs
>>> [40936.996081]
>>> ==
>>> [40936.996125] BUG: KASAN: use-after-free in pci_epf_remove_cfs+0x1ae/0x1f0
>>> [40936.996153] Write of size 8 at addr 88810a22a068 by task rmmod/12139
>>
>> Fix fb0de5b8dcc6 and ef1433f717a2 if the current group::group_entry
>> used by pci epf does not break how configfs uses it.
>>
>> --- a/drivers/pci/endpoint/pci-epf-core.c
>> +++ b/drivers/pci/endpoint/pci-epf-core.c
>> @@ -153,9 +153,11 @@ static void pci_epf_remove_cfs(struct pc
>> return;
>>
>> mutex_lock(_epf_mutex);
>> -list_for_each_entry_safe(group, tmp, >epf_group, group_entry)
>> +list_for_each_entry_safe(group, tmp, >epf_group,
>> +group_entry) {
>> +list_del_init(>group_entry);
>> pci_ep_cfs_remove_epf_group(group);
>> -list_del(>epf_group);
>> +}
>> mutex_unlock(_epf_mutex);
>> }
Acked-by: Kishon Vijay Abraham I
>
> Thank you Hillf. Kishon, can you confirm that's the proper fix for
> this bug please ? I would like to turn this into a patch and merge
> it in the upcoming merge window PR so it ought to be fairly quick,
> please let me know asap.
>
> Lorenzo
>
Re: [PATCH] staging: exfat: add exfat filesystem code to
On Tue, 17 Sep 2019 00:19:36 -0400, "Valdis Klētnieks" said: > I'm working off a somewhat cleaned up copy of Samsung's original driver, > because that's what I had knowledge of. If the sdfat driver is closer to > being > mergeable, I'd not object if that got merged instead. Greg, as Valdis mentioned here, the staging tree driver is just another exFAT fork from Samsung. What's the point of using a much older driver? sdFAT is clearly more matured and been put into more recent production softwares. And as I wrote in previous email, it does include some real fixes. As Namjae said too, Samsung would be more interested in merging sdFAT to upstream. If we diverge, Samsung will have less reasons to contribute their patches to upstream. Also, I think it makes much more sense to make Samsung the maintainer of this driver (if they're willing to put in the manpower to do so). Asking them would be the first step in doing so. > But here's the problem... Samsung has their internal sdfat code, Park Yu Hyung > has what appears to be a fork of that code from some point (and it's unclear , > and it's unclear which one has had more bugfixes and cleanups to get it to > somewhere near mainline mergeable. I made it extremely clear on where I took the code. The initial commit: "sdfat: import from G973FXXU3ASG8" states which kernel source I used. You can simply search "G973FXXU3ASG8" on http://opensource.samsung.com and download the source code. It'll match exactly with my initial commit. My repository is basically rename + clean-up + older kernel compat. I think we can all agree that using the sdFAT naming on non-Android is very misleading, which is why I renamed it to exFAT. sdFAT includes support for fat16/32, and as also mentioned in https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next=58985a9d2d03e977db93bf574a16162766a318fe this isn't desirable, especially in mainline. I cleaned it up and removed some other Samsung's code that relies on proprietary userspace tools such as defrag. I believe my repository is in the cleanest state for getting merged to mainline, compared to other drivers avilable out there. If we happen to pick it to mainline, I think it'll also be quite trivial for Samsung to pick mainline patches back to their sdFAT drivers used in Galaxy devices. > Can you provide a pointer to what Samsung is *currently* using? We probably > need to stop and actually look at the code bases and see what's in the best > shape currently. Namjae could probably elaborate here, but if I were to guess, there wasn't a noticeable difference in recent sdFAT releases. Even the lastest Note10 kernel only had some uevent changes. I think the current latest public source's driver is the best one available. Thanks.
Dear Friend,
Dear Friend, I came across your e-mail contact prior a private search while in need of your assistance. My name is Aisha Gaddafi a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi). I have investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00 ) and i need a trusted investment Manager/Partner because of my current refugee status, however, I am interested in you for investment project assistance in your country, may be from there, we can build business relationship in the nearest future. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project on my behalf kindly reply urgent to enable me provide you more information about the investment funds. Your Urgent Reply Will Be Appreciated. Best Regards Mrs Aisha Gaddafi (gaisha...@gmail.com)
Re: Linux 5.3-rc8
On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote: > >Well, the patch actually made getrandom() return en error too, but you > >seem more interested in the hypotheticals than in arguing actualities. > > If you want to be safe, terminate the process. This is an interesting approach. At least it will cause bug reports in application using getrandom() in an unreliable way and they will check for other options. Because one of the issues with systems that do not finish to boot is that usually the user doesn't know what process is hanging. Anyway regarding the impact on applications relying on getrandom() for security, I'm in favor of not *silently* changing their behavior and provide a new flag to help others get insecure randoms without waiting. With your option above we could then have this way to go: - GRND_SECURE: the application wants secure randoms, i.e. like the current getrandom(0), waiting for entropy. - GRND_INSECURE: the application never wants to wait, it just wants a replacement for /dev/urandom. - GRND_RANDOM: unchanged, or subject to CAP_xxx, or maybe just emit a "deprecated" warning if called without a certain capability, to spot potentially harmful applications. - by default (0), the application continues to wait but when the timeout strikes (30 seconds ?), it gets terminated with a message in the logs for users to report the issue. After some time all relevant applications which accidently misuse getrandom() will be fixed to either use GRND_INSECURE or GRND_SECURE and be able to wait longer if they want (likely SECURE|NONBLOCK). Willy
RE: [v2,1/3] soc: fsl: fix that flextimer cannot wakeup system in deep sleep on LS1021A
Hi all,
the linux patches depended by RCPM driver,FlexTimer driver and
FlexTimer dts, need apply these patches as follows:
1. RCPM driver:
https://patchwork.kernel.org/series/162731/mbox/
(https://patchwork.kernel.org/patch/11105279/)
2. FlexTimer dts:
https://lore.kernel.org/patchwork/series/405653/mbox/
(https://lore.kernel.org/patchwork/patch/1112493/)
3. FlexTimer driver:
https://patchwork.ozlabs.org/series/124718/mbox/
(https://patchwork.ozlabs.org/patch/1145999/)
https://patchwork.ozlabs.org/series/126942/mbox/
(https://patchwork.ozlabs.org/patch/1152085/)
4. Adjust drivers/soc/fsl/Makefile:
remove the line 'obj-y += ftm_alarm.o' in
drivers/soc/fsl/Makefile to resolve a compilation error
> Why:
> - Cannot write register RCPM_IPPDEXPCR1 on LS1021A,
> Register RCPM_IPPDEXPCR1's default value is zero.
> So the register value that reading from register
> RCPM_IPPDEXPCR1 is always zero.
>
> How:
> - Save register RCPM_IPPDEXPCR1's value to
> register SCFG_SPARECR8.(uboot's psci also
> need reading value from the register SCFG_SPARECR8
> to set register RCPM_IPPDEXPCR1)
>
> Signed-off-by: Biwen Li
> ---
> Change in v2:
> - fix stype problems
>
> drivers/soc/fsl/rcpm.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c index
> 82c0ad5e663e..0b710c24999c 100644
> --- a/drivers/soc/fsl/rcpm.c
> +++ b/drivers/soc/fsl/rcpm.c
> @@ -13,6 +13,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #define RCPM_WAKEUP_CELL_MAX_SIZE7
>
> @@ -63,6 +65,31 @@ static int rcpm_pm_prepare(struct device *dev)
> tmp |= value[i + 1];
> iowrite32be(tmp, rcpm->ippdexpcr_base +
> i * 4);
> }
> + #ifdef CONFIG_SOC_LS1021A
> + /* Workaround: There is a bug of register
> ippdexpcr1,
> + * cannot write it but can read it.Tt's default
> value is zero,
> + * then read it will always returns zero.
> + * So save ippdexpcr1's value to register
> SCFG_SPARECR8.
> + * And the value of ippdexpcr1 will be read from
> SCFG_SPARECR8.
> + */
> + {
> + struct regmap *rcpm_scfg_regmap = NULL;
> + u32
> reg_offset[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
> + u32 reg_value = 0;
> +
> + rcpm_scfg_regmap =
> syscon_regmap_lookup_by_phandle(np, "fsl,rcpm-scfg");
> + if (rcpm_scfg_regmap) {
> + if
> (of_property_read_u32_array(dev->of_node,
> + "fsl,rcpm-scfg", reg_offset,
> rcpm->wakeup_cells + 1)) {
> + rcpm_scfg_regmap = NULL;
> + continue;
> + }
> + regmap_read(rcpm_scfg_regmap,
> reg_offset[i + 1],
> _value);
> + /* Write value to register
> SCFG_SPARECR8 */
> + regmap_write(rcpm_scfg_regmap,
> reg_offset[i +
> 1], tmp | reg_value);
> + }
> + }
> + #endif //CONFIG_SOC_LS1021A
> }
> }
> } while (ws = wakeup_source_get_next(ws));
> --
> 2.17.1
Re: [PATCH] staging: exfat: add exfat filesystem code to
Hi, On Tue, Sep 17, 2019 at 12:02:01PM +0900, Namjae Jeon wrote: > We are excited to see this happening and would like to state that we > appreciate > time and > effort which people put into upstreaming exfat. Thank you! > > However, if possible, can we step back a little bit and re-consider it? We > would prefer to > see upstream the code which we are currently using in our products - sdfat - > as > this can > be mutually benefitial from various points of view. (Only represent my personal views) I'd like to know the detailed commit history as an individual Android hobbyist. I noticed sdfat years ago and there is a difference from the previous exfat driver. I have no idea it's a good way to blindly keep the code from some opensource tar on some website. and so many forks on github (hard to know which one is more stable, cleaner or latest)... someone could take more time and play a role in that actively in the community and maybe draw a roadmap of this so I could study more and maybe contribute a little in my spare time. And I think if it permits, development on multiple branches could be avoided... If I am wrong, please ignore me... Thanks, Gao Xiang > > Thanks! > > > -- Forwarded message - > > : Ju Hyung Park > > Date: 2019?? 9?? 16?? (??) 3:49 > > Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to > > To: Greg KH > > Cc: , , > fsde...@vger.kernel.org>, , Valdis Kletnieks > > > > > > > > Hi Greg, > > > > On Sun, Sep 15, 2019 at 10:54 PM Greg KH wrote: > > > Note, this just showed up publically on August 12, where were you with > > > all of this new code before then? :) > > > > My sdFAT port, exfat-nofuse and the one on the staging tree, were all > > made by Samsung. > > And unless you guys had a chance to talk to Samsung developers > > directly, those all share the same faith of lacking proper development > > history. > > > > The source I used was from http://opensource.samsung.com, which > > provides kernel sources as tar.gz files. > > There is no code history available. > > > > > For the in-kernel code, we would have to rip out all of the work you did > > > for all older kernels, so that's a non-starter right there. > > > > I'm aware. > > I'm just letting mainline know that there is potentially another (much > > better) base that could be upstreamed. > > > > If you want me to rip out older kernel support for upstreaming, I'm > > more than happy to do so. > > > > > As for what codebase to work off of, I don't want to say it is too late, > > > but really, this shows up from nowhere and we had to pick something so > > > we found the best we could at that point in time. > > > > To be honest, whole public exFAT sources are all from nowhere unless > > you had internal access to Samsung's development archive. > > The one in the current staging tree isn't any better. > > > > I'm not even sure where the staging driver is from, actually. > > > > Samsung used the 1.2.x versioning until they switched to a new code > > base - sdFAT. > > The one in the staging tree is marked version 1.3.0(exfat_super.c). > > I failed to find anything 1.3.x from Samsung's public kernel sources. > > > > The last time exFAT 1.2.x was used was in Galaxy S7(released in 2016). > > Mine was originally based on sdFAT 2.1.10, used in Galaxy S10(released > > in March 2019) and it just got updated to 2.2.0, used in Galaxy > > Note10(released in August 2019). > > > > > Is there anything specific in the codebase you have now, that is lacking > > > in the in-kernel code? Old-kernel-support doesn't count here, as we > > > don't care about that as it is not applicable. But functionality does > > > matter, what has been added here that we can make use of? > > > > This is more of a suggestion of > > "Let's base on a *much more recent* snapshot for the community to work on", > > since the current one on the staging tree also lacks development history. > > > > The diff is way too big to even start understanding the difference. > > > > > > With that said though, I do have some vague but real reason as to why > > sdFAT base is better. > > > > With some major Android vendors showing interests in supporting exFAT, > > Motorola notably published their work on public Git repository with > > full development history(the only vendor to do this that I'm aware > > of). > > Commits like this: > > https://github.com/MotorolaMobilityLLC/kernel-msm/commit/7ab1657 is > > not merged to exFAT(including the current staging tree one) while it > > did for sdFAT. > > > > > > The only thing I regret is not working on porting sdFAT sooner. > > I definitely didn't anticipate Microsoft to suddenly lift legal issues > > on upstreaming exFAT just around when I happen to gain interest in > > porting sdFAT. > > > > If my port happened sooner, it would have been a no-brainer for it to > > be considered as a top candidate for upstreaming. > > > > > And do you have any "real" development
[PATCH] tracing/kprobe: Fix NULL pointer access in trace_porbe_unlink()
Fix NULL pointer access in trace_probe_unlink() by initializing
trace_probe.list correctly in trace_probe_init().
In the error case of trace_probe_init(), it can call trace_probe_unlink()
before initializing trace_probe.list member. This causes NULL pointer
dereference at list_del_init() in trace_probe_unlink().
Syzbot reported :
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8633 Comm: syz-executor797 Not tainted 5.3.0-rc8-next-20190915
#0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__list_del_entry_valid+0x85/0xf5 lib/list_debug.c:51
Code: 0f 84 e1 00 00 00 48 b8 22 01 00 00 00 00 ad de 49 39 c4 0f 84 e2 00
00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75
53 49 8b 14 24 4c 39 f2 0f 85 99 00 00 00 49 8d 7d
RSP: 0018:888090a7f9d8 EFLAGS: 00010246
RAX: dc00 RBX: 88809b6f90c0 RCX: 817c0ca9
RDX: RSI: 817c0a73 RDI: 88809b6f90c8
RBP: 888090a7f9f0 R08: 88809a04e600 R09: ed1015d26aed
R10: ed1015d26aec R11: 8880ae935763 R12:
R13: R14: 88809b6f90c0 R15: 88809b6f90d0
FS: 56f99880() GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 006cc090 CR3: 962b2000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
__list_del_entry include/linux/list.h:131 [inline]
list_del_init include/linux/list.h:190 [inline]
trace_probe_unlink+0x1f/0x200 kernel/trace/trace_probe.c:959
trace_probe_cleanup+0xd3/0x110 kernel/trace/trace_probe.c:973
trace_probe_init+0x3f2/0x510 kernel/trace/trace_probe.c:1011
alloc_trace_uprobe+0x5e/0x250 kernel/trace/trace_uprobe.c:353
create_local_trace_uprobe+0x109/0x4a0 kernel/trace/trace_uprobe.c:1508
perf_uprobe_init+0x131/0x210 kernel/trace/trace_event_perf.c:314
perf_uprobe_event_init+0x106/0x1a0 kernel/events/core.c:8898
perf_try_init_event+0x135/0x590 kernel/events/core.c:10184
perf_init_event kernel/events/core.c:10228 [inline]
perf_event_alloc.part.0+0x1b89/0x33d0 kernel/events/core.c:10505
perf_event_alloc kernel/events/core.c:10887 [inline]
__do_sys_perf_event_open+0xa2d/0x2d00 kernel/events/core.c:10989
__se_sys_perf_event_open kernel/events/core.c:10871 [inline]
__x64_sys_perf_event_open+0xbe/0x150 kernel/events/core.c:10871
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Reported-by: syzbot+2f807f4d3a2a4e87f...@syzkaller.appspotmail.com
Fixes: ca89bc071d5e ("tracing/kprobe: Add multi-probe per event support")
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_probe.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 1e67fef06e53..baf58a3612c0 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -986,6 +986,12 @@ int trace_probe_init(struct trace_probe *tp, const char
*event,
if (!tp->event)
return -ENOMEM;
+ INIT_LIST_HEAD(>event->files);
+ INIT_LIST_HEAD(>event->class.fields);
+ INIT_LIST_HEAD(>event->probes);
+ INIT_LIST_HEAD(>list);
+ list_add(>event->probes, >list);
+
call = trace_probe_event_call(tp);
call->class = >event->class;
call->name = kstrdup(event, GFP_KERNEL);
@@ -999,11 +1005,6 @@ int trace_probe_init(struct trace_probe *tp, const char
*event,
ret = -ENOMEM;
goto error;
}
- INIT_LIST_HEAD(>event->files);
- INIT_LIST_HEAD(>event->class.fields);
- INIT_LIST_HEAD(>event->probes);
- INIT_LIST_HEAD(>list);
- list_add(>event->probes, >list);
return 0;
Re: [PATCH v2] sched: fix migration to invalid cpu in __set_cpus_allowed_ptr
On Mon, Sep 16, 2019 at 06:53:28AM +, KeMeng Shi wrote:
> Oops occur when running qemu on arm64:
> Unable to handle kernel paging request at virtual address 08effe40
> Internal error: Oops: 9607 [#1] SMP
> Process migration/0 (pid: 12, stack limit = 0x084e3736)
> pstate: 2085 (nzCv daIf -PAN -UAO)
> pc : __ll_sc___cmpxchg_case_acq_4+0x4/0x20
> lr : move_queued_task.isra.21+0x124/0x298
> ...
> Call trace:
> __ll_sc___cmpxchg_case_acq_4+0x4/0x20
> __migrate_task+0xc8/0xe0
> migration_cpu_stop+0x170/0x180
> cpu_stopper_thread+0xec/0x178
> smpboot_thread_fn+0x1ac/0x1e8
> kthread+0x134/0x138
> ret_from_fork+0x10/0x18
>
> __set_cpus_allowed_ptr will choose an active dest_cpu in affinity mask to
> migrage the process if process is not currently running on any one of the
> CPUs specified in affinity mask. __set_cpus_allowed_ptr will choose an
> invalid dest_cpu (dest_cpu >= nr_cpu_ids, 1024 in my virtual machine) if
> CPUS in an affinity mask are deactived by cpu_down after cpumask_intersects
> check. cpumask_test_cpu of dest_cpu afterwards is overflow and may pass if
> corresponding bit is coincidentally set. As a consequence, kernel will
> access an invalid rq address associate with the invalid cpu in
> migration_cpu_stop->__migrate_task->move_queued_task and the Oops occurs.
>
> Process as follows may trigger the Oops:
> 1) A process repeatedly binds itself to cpu0 and cpu1 in turn by calling
> sched_setaffinity.
> 2) A shell script repeatedly "echo 0 > /sys/devices/system/cpu/cpu1/online"
> and "echo 1 > /sys/devices/system/cpu/cpu1/online" in turn.
> 3) Oops appears if the invalid cpu is set in memory after tested cpumask.
>
> Signed-off-by: KeMeng Shi
> Reviewed-by: Valentin Schneider
> ---
> Changes in v2:
> -solve format problems in log
>
> kernel/sched/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3c7b90bcbe4e..087f4ac30b60 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1656,7 +1656,8 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
> if (cpumask_equal(p->cpus_ptr, new_mask))
> goto out;
>
> - if (!cpumask_intersects(new_mask, cpu_valid_mask)) {
> + dest_cpu = cpumask_any_and(cpu_valid_mask, new_mask);
> + if (dest_cpu >= nr_cpu_ids) {
> ret = -EINVAL;
> goto out;
> }
> @@ -1677,7 +1678,6 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
> if (cpumask_test_cpu(task_cpu(p), new_mask))
> goto out;
>
> - dest_cpu = cpumask_any_and(cpu_valid_mask, new_mask);
> if (task_running(rq, p) || p->state == TASK_WAKING) {
> struct migration_arg arg = { p, dest_cpu };
> /* Need help from migration thread: drop lock and wait. */
> --
> 2.19.1
>
>
The cpu_active_mask might have changed in between. Your fix looks good to me.
Thanks,
Pavan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: linux-next: Tree for Sep 16 (kernel/sched/core.c)
On 9/16/19 3:38 PM, Mark Brown wrote:
> Hi all,
>
> Changes since 20190915:
>
on x86_64:
when CONFIG_CGROUPS is not set:
CC kernel/sched/core.o
../kernel/sched/core.c: In function ‘uclamp_update_active_tasks’:
../kernel/sched/core.c:1081:23: error: storage size of ‘it’ isn’t known
struct css_task_iter it;
^~
CC kernel/printk/printk_safe.o
../kernel/sched/core.c:1084:2: error: implicit declaration of function
‘css_task_iter_start’; did you mean ‘__sg_page_iter_start’?
[-Werror=implicit-function-declaration]
css_task_iter_start(css, 0, );
^~~
__sg_page_iter_start
../kernel/sched/core.c:1085:14: error: implicit declaration of function
‘css_task_iter_next’; did you mean ‘__sg_page_iter_next’?
[-Werror=implicit-function-declaration]
while ((p = css_task_iter_next())) {
^~
__sg_page_iter_next
../kernel/sched/core.c:1091:2: error: implicit declaration of function
‘css_task_iter_end’; did you mean ‘get_task_cred’?
[-Werror=implicit-function-declaration]
css_task_iter_end();
^
get_task_cred
../kernel/sched/core.c:1081:23: warning: unused variable ‘it’
[-Wunused-variable]
struct css_task_iter it;
^~
--
~Randy
Re: [PATCH] staging: exfat: add exfat filesystem code to
On Tue, Sep 17, 2019 at 12:02:01PM +0900, Namjae Jeon wrote: > We are excited to see this happening and would like to state that we > appreciate > time and > effort which people put into upstreaming exfat. Thank you! > > However, if possible, can we step back a little bit and re-consider it? We > would prefer to see upstream the code which we are currently using in > our products - sdfat - as this can be mutually benefitial from various > points of view. What is "different" in it from the code that is currently in linux-next? What is supported "better"? The code we have today seems to work for people, so what are we missing here? Also, submitting patches for this codebase to bring it up to the level of functionality you need would be wonderful, can you do that? thanks, greg k-h
[v2,3/3] Documentation: dt: binding: fsl: Add 'fsl,rcpm-scfg' property
The 'fsl,rcpm-scfg' property is used to fix a bug
that FlexTimer cannot wakeup system in deep sleep on LS1021A
Signed-off-by: Biwen Li
---
Change in v2:
- update desc of the property 'fsl,rcpm-scfg'
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index 5a33619d881d..f8dce247357a 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -34,6 +34,11 @@ Chassis Version Example Chips
Optional properties:
- little-endian : RCPM register block is Little Endian. Without it RCPM
will be Big Endian (default case).
+ - fsl,rcpm-scfg : LS1021A has defect of failing to get data when
+ reading ippdexpcr. So add this property to help store one
+ copy to specified scfg_scrachpad_addr register for others
+ (such as U-Boot) reference. The first entry must be a link to the
+ SCFG device node, then followed by the offset of registers of SCFG.
Example:
The RCPM node for T4240:
@@ -43,6 +48,14 @@ The RCPM node for T4240:
#fsl,rcpm-wakeup-cells = <2>;
};
+The RCPM node for LS1021A:
+ rcpm: rcpm@1ee2140 {
+ compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
+ reg = <0x0 0x1ee2140 0x0 0x8>;
+ #fsl,rcpm-wakeup-cells = <2>;
+ fsl,rcpm-scfg = < 0x0 0x51c>; /* SCFG_SPARECR8 */
+ };
+
* Freescale RCPM Wakeup Source Device Tree Bindings
---
Required fsl,rcpm-wakeup property should be added to a device node if the
device
--
2.17.1
[v2,1/3] soc: fsl: fix that flextimer cannot wakeup system in deep sleep on LS1021A
Why:
- Cannot write register RCPM_IPPDEXPCR1 on LS1021A,
Register RCPM_IPPDEXPCR1's default value is zero.
So the register value that reading from register
RCPM_IPPDEXPCR1 is always zero.
How:
- Save register RCPM_IPPDEXPCR1's value to
register SCFG_SPARECR8.(uboot's psci also
need reading value from the register SCFG_SPARECR8
to set register RCPM_IPPDEXPCR1)
Signed-off-by: Biwen Li
---
Change in v2:
- fix stype problems
drivers/soc/fsl/rcpm.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index 82c0ad5e663e..0b710c24999c 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#define RCPM_WAKEUP_CELL_MAX_SIZE 7
@@ -63,6 +65,31 @@ static int rcpm_pm_prepare(struct device *dev)
tmp |= value[i + 1];
iowrite32be(tmp, rcpm->ippdexpcr_base +
i * 4);
}
+ #ifdef CONFIG_SOC_LS1021A
+ /* Workaround: There is a bug of register
ippdexpcr1,
+* cannot write it but can read it.Tt's default
value is zero,
+* then read it will always returns zero.
+* So save ippdexpcr1's value to register
SCFG_SPARECR8.
+* And the value of ippdexpcr1 will be read
from SCFG_SPARECR8.
+*/
+ {
+ struct regmap *rcpm_scfg_regmap = NULL;
+ u32
reg_offset[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
+ u32 reg_value = 0;
+
+ rcpm_scfg_regmap =
syscon_regmap_lookup_by_phandle(np, "fsl,rcpm-scfg");
+ if (rcpm_scfg_regmap) {
+ if
(of_property_read_u32_array(dev->of_node,
+ "fsl,rcpm-scfg",
reg_offset, rcpm->wakeup_cells + 1)) {
+ rcpm_scfg_regmap = NULL;
+ continue;
+ }
+ regmap_read(rcpm_scfg_regmap,
reg_offset[i + 1], _value);
+ /* Write value to register
SCFG_SPARECR8 */
+ regmap_write(rcpm_scfg_regmap,
reg_offset[i + 1], tmp | reg_value);
+ }
+ }
+ #endif //CONFIG_SOC_LS1021A
}
}
} while (ws = wakeup_source_get_next(ws));
--
2.17.1
[v2,2/3] arm: dts: ls1021a: fix that FlexTimer cannot wakeup system in deep sleep
The patch fix a bug that FlexTimer cannot
wakeup system in deep sleep.
Signed-off-by: Biwen Li
---
Change in v2:
- None
arch/arm/boot/dts/ls1021a.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index e3973b611c3a..377bb4717584 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -1000,12 +1000,13 @@
compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
reg = <0x0 0x1ee2140 0x0 0x8>;
#fsl,rcpm-wakeup-cells = <2>;
+ fsl,rcpm-scfg = < 0x0 0x51c>; /* SCFG_SPARECR8 */
};
ftm_alarm0: timer0@29d {
compatible = "fsl,ls1021a-ftm-alarm";
reg = <0x0 0x29d 0x0 0x1>;
- fsl,rcpm-wakeup = < 0x0 0x2000>;
+ fsl,rcpm-wakeup = < 0x0 0x3000>; /* FlexTimer1
and OCRAM1 are not powerdown during LPM20(sleep) */
interrupts = ;
big-endian;
};
--
2.17.1
Re: [PATCH V7 3/3] arm64/mm: Enable memory hot remove
On 09/13/2019 03:39 PM, Catalin Marinas wrote:
> On Fri, Sep 13, 2019 at 11:28:01AM +0530, Anshuman Khandual wrote:
>> On 09/13/2019 01:45 AM, Catalin Marinas wrote:
>>> On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
@@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(unsigned long start,
unsigned long end, int node,
void vmemmap_free(unsigned long start, unsigned long end,
struct vmem_altmap *altmap)
{
+#ifdef CONFIG_MEMORY_HOTPLUG
+ /*
+ * FIXME: We should have called remove_pagetable(start, end, true).
+ * vmemmap and vmalloc virtual range might share intermediate kernel
+ * page table entries. Removing vmemmap range page table pages here
+ * can potentially conflict with a concurrent vmalloc() allocation.
+ *
+ * This is primarily because vmalloc() does not take init_mm ptl for
+ * the entire page table walk and it's modification. Instead it just
+ * takes the lock while allocating and installing page table pages
+ * via [p4d|pud|pmd|pte]_alloc(). A concurrently vanishing page table
+ * entry via memory hot remove can cause vmalloc() kernel page table
+ * walk pointers to be invalid on the fly which can cause corruption
+ * or worst, a crash.
+ *
+ * So free_empty_tables() gets called where vmalloc and vmemmap range
+ * do not overlap at any intermediate level kernel page table entry.
+ */
+ unmap_hotplug_range(start, end, true);
+ if (!vmalloc_vmemmap_overlap)
+ free_empty_tables(start, end);
+#endif
}
>>>
>>> So, I see the risk with overlapping and I guess for some kernel
>>> configurations (PAGE_SIZE == 64K) we may not be able to avoid it. If we
>>
>> Did not see 64K config options to have overlap, do you suspect they might ?
>> After the 52 bit KVA series has been merged, following configurations have
>> the vmalloc-vmemmap range overlap problem.
>>
>> - 4K page size with 48 bit VA space
>> - 16K page size with 48 bit VA space
>
> OK. I haven't checked, so it was just a guess that 64K has this problem
> since the pgd entry coverage is fairly large.
>
>>> can, that's great, otherwise could we rewrite the above functions to
>>> handle floor and ceiling similar to free_pgd_range()? (I wonder how this
>>> function works if you called it on init_mm and kernel address range). By
>>
>> Hmm, never tried that. Are you wondering if this can be used directly ?
>> There are two distinct elements which make it very specific to user page
>> tables, mmu_gather based TLB tracking and mm->pgtable_bytes accounting
>> with mm_dec_nr_pxx().
>
> Ah, I missed the mm_dec_nr_*(). So I don't think it would work directly.
> We could, however, use the same approach for kernel page tables.
Right.
>
>>> having the vmemmap start/end information it avoids freeing partially
>>> filled page table pages.
>>
>> Did you mean page table pages which can partially overlap with vmalloc ?
>
> Overlapping with the vmalloc range, not necessarily with a mapped
> vmalloc area.
>
>> The problem (race) is not because of the inability to deal with partially
>> filled table. We can handle that correctly as explained below [1]. The
>> problem is with inadequate kernel page table locking during vmalloc()
>> which might be accessing intermediate kernel page table pointers which is
>> being freed with free_empty_tables() concurrently. Hence we cannot free
>> any page table page which can ever have entries from vmalloc() range.
>
> The way you deal with the partially filled table in this patch is to
> avoid freeing if there is a non-empty entry (!p*d_none()). This is what
> causes the race with vmalloc. If you simply avoid freeing a pmd page,
> for example, if the range floor/ceiling is not aligned to PUD_SIZE,
> irrespective of whether the other entries are empty or not, you
> shouldn't have this problem. You do free the pte page if the range is
Right, the floor/ceiling alignment check should abort the process before
scanning for non-empty entries.
> aligned to PMD_SIZE but in this case it wouldn't overlap with the
> vmalloc space. That's how free_pgd_range() works.
Like free_pgd_range(), page table pages can be freed at lower levels when
they have the right alignment wrt floor/ceiling. I will change all existing
free_pxx_table() functions to accommodate floor/ceiling alignment checks to
achieve this.
>
> We may have some pgtable pages not freed at both ends of the range
> (maximum 6 in total) but I don't really see this an issue. They could be
> reused if something else gets mapped in that range.
I assume that the number 6 for maximum page possibility came from
(floor edge + ceiling edge) * (PTE table + PMD table + PUD table)
>
>> Though not completely sure, whether I really understood the suggestion above
>> with respect to the floor-ceiling mechanism as in free_pgd_range(). Are you
>> suggesting that we
Re: [PATCH 2/5] powerpc: Map & release OpenCAPI LPC memory
Hi Alastair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190916]
[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/Alastair-D-Silva/ocxl-Allow-external-drivers-to-access-LPC-memory/20190917-094857
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/powerpc/platforms/powernv/ocxl.c: In function
'pnv_ocxl_platform_lpc_setup':
>> arch/powerpc/platforms/powernv/ocxl.c:492:7: error: implicit declaration of
>> function 'check_hotplug_memory_addressable'
>> [-Werror=implicit-function-declaration]
rc = check_hotplug_memory_addressable(base_addr, base_addr + size);
^~~~
cc1: some warnings being treated as errors
vim +/check_hotplug_memory_addressable +492
arch/powerpc/platforms/powernv/ocxl.c
477
478 u64 pnv_ocxl_platform_lpc_setup(struct pci_dev *pdev, u64 size)
479 {
480 struct pci_controller *hose = pci_bus_to_host(pdev->bus);
481 struct pnv_phb *phb = hose->private_data;
482 struct pci_dn *pdn = pci_get_pdn(pdev);
483 u32 bdfn = (pdn->busno << 8) | pdn->devfn;
484 u64 base_addr = 0;
485
486 int rc = opal_npu_mem_alloc(phb->opal_id, bdfn, size,
_addr);
487
488 WARN_ON(rc);
489
490 base_addr = be64_to_cpu(base_addr);
491
> 492 rc = check_hotplug_memory_addressable(base_addr, base_addr +
> size);
493 if (rc) {
494 dev_warn(>dev,
495 "LPC memory range 0x%llx-0x%llx is not fully
addressable",
496 base_addr, base_addr + size - 1);
497 return 0;
498 }
499
500
501 return base_addr;
502 }
503 EXPORT_SYMBOL_GPL(pnv_ocxl_platform_lpc_setup);
504
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] staging: exfat: add exfat filesystem code to
On Tue, 17 Sep 2019 12:02:01 +0900, "Namjae Jeon" said: > We are excited to see this happening and would like to state that we > appreciate time and > effort which people put into upstreaming exfat. Thank you! The hard part - getting Microsoft to OK merging an exfat driver - is done. All we need now is to get a driver cleaned up. :) > However, if possible, can we step back a little bit and re-consider it? We > would prefer to > see upstream the code which we are currently using in our products - sdfat - > as > this can be mutually benefitial from various points of view. I'm working off a somewhat cleaned up copy of Samsung's original driver, because that's what I had knowledge of. If the sdfat driver is closer to being mergeable, I'd not object if that got merged instead. But here's the problem... Samsung has their internal sdfat code, Park Yu Hyung has what appears to be a fork of that code from some point (and it's unclear , and it's unclear which one has had more bugfixes and cleanups to get it to somewhere near mainline mergeable. Can you provide a pointer to what Samsung is *currently* using? We probably need to stop and actually look at the code bases and see what's in the best shape currently. pgpPCazp_DYH8.pgp Description: PGP signature
[PATCH] fs/affs: release memory if affs_init_bitmap fails
In affs_init_bitmap, on error handling path we may release the allocated memory. Signed-off-by: Navid Emamdoost --- fs/affs/bitmap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/affs/bitmap.c b/fs/affs/bitmap.c index 5ba9ef2742f6..745ed2cc4b51 100644 --- a/fs/affs/bitmap.c +++ b/fs/affs/bitmap.c @@ -347,6 +347,7 @@ int affs_init_bitmap(struct super_block *sb, int *flags) out: affs_brelse(bh); affs_brelse(bmap_bh); + kfree(sbi->s_bitmap); return res; } -- 2.17.1
[GIT PULL] soundwire updates for v5.4-rc1
Hi greg, First apologies for sending this very late, I had to go out of town and didn't have internet access, but I should have done better Anyhow, here are the changes collected for v5.4-rc1 and as usual they have been sitting in linux-next. The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git tags/soundwire-5.4-rc1 for you to fetch changes up to dfcff3f8a5f18a0cfa233522b5647c2e6035fcb5: soundwire: stream: make stream name a const pointer (2019-09-04 14:57:28 +0530) soundwire updates for v5.4-rc1 This includes DT support thanks to Srini and more work done by Intel (Pierre) on improving cadence and intel support. Details: - Add DT bindings and DT support in core - Add debugfs support for soundwire properties - Improvements on streaming handling to core - Improved handling of Cadence module - More updates and improvements to Intel driver Andy Shevchenko (1): soundwire: mipi_disco: Switch to use fwnode_property_count_uXX() Bard Liao (1): soundwire: bus: set initial value to port_status Bard liao (1): soundwire: include mod_devicetable.h to avoid compiling warnings Pierre-Louis Bossart (21): soundwire: intel: remove BIOS work-arounds soundwire: cadence_master: simplify bus clash interrupt clear soundwire: bus: split handling of Device0 events soundwire: intel: prevent possible dereference in hw_params soundwire: intel: fix channel number reported by hardware soundwire: cadence_master: revisit interrupt settings soundwire: bus: improve dynamic debug comments for enumeration soundwire: export helpers to find row and column values soundwire: cadence_master: use firmware defaults for frame shape soundwire: stream: fix disable sequence soundwire: stream: remove unnecessary variable initializations soundwire: add new mclk_freq field for properties soundwire: intel: read mclk_freq property from firmware soundwire: cadence_master: make use of mclk_freq property soundwire: intel_init: add kernel module parameter to filter out links soundwire: cadence_master: add kernel parameter to override interrupt mask soundwire: intel: move shutdown() callback and don't export symbol soundwire: add debugfs support soundwire: cadence_master: add debugfs register dump soundwire: intel: add debugfs register dump soundwire: intel: handle disabled links Rander Wang (1): soundwire: cadence_master: fix divider setting in clock register Srinivas Kandagatla (3): dt-bindings: soundwire: add slave bindings soundwire: core: add device tree support for slave devices soundwire: stream: make stream name a const pointer Vinod Koul (2): soundwire: intel: remove unused variables soundwire: Add compute_params callback .../bindings/soundwire/soundwire-controller.yaml | 82 drivers/soundwire/Makefile | 4 + drivers/soundwire/bus.c| 20 +- drivers/soundwire/bus.h| 24 ++- drivers/soundwire/bus_type.c | 3 + drivers/soundwire/cadence_master.c | 211 + drivers/soundwire/cadence_master.h | 6 +- drivers/soundwire/debugfs.c| 151 +++ drivers/soundwire/intel.c | 211 +++-- drivers/soundwire/intel_init.c | 11 ++ drivers/soundwire/mipi_disco.c | 18 +- drivers/soundwire/slave.c | 53 ++ drivers/soundwire/stream.c | 105 ++ include/linux/soundwire/sdw.h | 20 +- include/linux/soundwire/sdw_intel.h| 1 + 15 files changed, 819 insertions(+), 101 deletions(-) create mode 100644 Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml create mode 100644 drivers/soundwire/debugfs.c Thanks -- ~Vinod signature.asc Description: PGP signature
[PATCH v2] ixgbe: Use memset_explicit directly in crypto cases
It's better to use memset_explicit() to replace memset() in crypto cases. Signed-off-by: zhong jiang --- drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c index 31629fc..7e4f32f 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c @@ -960,10 +960,10 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf) return 0; err_aead: - memset(xs->aead, 0, sizeof(*xs->aead)); + memzero_explicit(xs->aead, sizeof(*xs->aead)); kfree(xs->aead); err_xs: - memset(xs, 0, sizeof(*xs)); + memzero_explicit(xs, sizeof(*xs)); kfree(xs); err_out: msgbuf[1] = err; @@ -1049,7 +1049,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf) ixgbe_ipsec_del_sa(xs); /* remove the xs that was made-up in the add request */ - memset(xs, 0, sizeof(*xs)); + memzero_explicit(xs, sizeof(*xs)); kfree(xs); return 0; -- 1.7.12.4
Re: [PATCH V5 2/5] input: keyboard: imx_sc: Add i.MX system controller key support
Hi Anson,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190916]
[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/Anson-Huang/dt-bindings-fsl-scu-add-scu-key-binding/20190917-105937
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=ia64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from drivers/input/keyboard/imx_sc_key.c:6:0:
drivers/input/keyboard/imx_sc_key.c: In function 'imx_sc_check_for_events':
>> drivers/input/keyboard/imx_sc_key.c:76:60: error: 'ret' undeclared (first
>> use in this function); did you mean 'net'?
dev_err(>dev, "read imx sc key failed, ret %d\n", ret);
^
include/linux/device.h:1499:32: note: in definition of macro 'dev_err'
_dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~
drivers/input/keyboard/imx_sc_key.c:76:60: note: each undeclared identifier
is reported only once for each function it appears in
dev_err(>dev, "read imx sc key failed, ret %d\n", ret);
^
include/linux/device.h:1499:32: note: in definition of macro 'dev_err'
_dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~
vim +76 drivers/input/keyboard/imx_sc_key.c
> 6 #include
7 #include
8 #include
9 #include
10 #include
11 #include
12 #include
13 #include
14 #include
15 #include
16 #include
17 #include
18
19 #define DEBOUNCE_TIME 30
20 #define REPEAT_INTERVAL 60
21
22 #define SC_IRQ_BUTTON 1
23 #define SC_IRQ_GROUP_WAKE 3
24 #define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
25
26 struct imx_key_drv_data {
27 int keycode;
28 bool keystate; /* 1: pressed, 0: release */
29 struct delayed_work check_work;
30 struct input_dev *input;
31 struct imx_sc_ipc *key_ipc_handle;
32 struct notifier_block key_notifier;
33 };
34
35 struct imx_sc_msg_key {
36 struct imx_sc_rpc_msg hdr;
37 u8 state;
38 };
39
40 static int imx_sc_key_notify(struct notifier_block *nb,
41 unsigned long event, void *group)
42 {
43 struct imx_key_drv_data *priv =
44 container_of(nb,
45struct imx_key_drv_data,
46key_notifier);
47
48 if ((event & SC_IRQ_BUTTON) && (*(u8 *)group ==
SC_IRQ_GROUP_WAKE)) {
49 schedule_delayed_work(>check_work,
50msecs_to_jiffies(DEBOUNCE_TIME));
51 pm_wakeup_event(priv->input->dev.parent, 0);
52 }
53
54 return 0;
55 }
56
57 static void imx_sc_check_for_events(struct work_struct *work)
58 {
59 struct imx_key_drv_data *priv =
60 container_of(work,
61struct imx_key_drv_data,
62check_work.work);
63 struct input_dev *input = priv->input;
64 struct imx_sc_msg_key msg;
65 struct imx_sc_rpc_msg *hdr =
66 bool state;
67 int error;
68
69 hdr->ver = IMX_SC_RPC_VERSION;
70 hdr->svc = IMX_SC_RPC_SVC_MISC;
71 hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
72 hdr->size = 1;
73
74 error = imx_scu_call_rpc(priv->key_ipc_handle, , true);
75 if (error) {
> 76 dev_err(>dev, "read imx sc key failed, ret
%d\n", ret);
77 return;
78 }
79
80 state = (bool)msg.state;
81
82 if (state ^ priv->keystate) {
83 priv->keystate = state;
84 input_event(input, EV_KEY, priv->keycode, state);
85 input_sync(input);
86 if (!priv->keystate)
87
[git pull] m68knommu changes for v5.4
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change, fix up header include in ColdFire specific GPIO handling code. Regards Greg The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e: Linux 5.3-rc8 (2019-09-08 13:33:15 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to 372ea263b3d9cdeb70f8cffa025b2e0875e51b62: m68k: coldfire: Include the GPIO driver header (2019-09-09 09:32:32 +1000) Linus Walleij (1): m68k: coldfire: Include the GPIO driver header arch/m68k/coldfire/gpio.c | 1 + 1 file changed, 1 insertion(+)
Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
On 2019/9/17 上午9:02, Tiwei Bie wrote: This RFC is to demonstrate below ideas, a) Build vhost-mdev on top of the same abstraction defined in the virtio-mdev series [1]; b) Introduce /dev/vhost-mdev to do vhost ioctls and support setting mdev device as backend; Now the userspace API looks like this: - Userspace generates a compatible mdev device; - Userspace opens this mdev device with VFIO API (including doing IOMMU programming for this mdev device with VFIO's container/group based interface); - Userspace opens /dev/vhost-mdev and gets vhost fd; - Userspace uses vhost ioctls to setup vhost (userspace should do VHOST_MDEV_SET_BACKEND ioctl with VFIO group fd and device fd first before doing other vhost ioctls); Only compile test has been done for this series for now. Have a hard thought on the architecture: 1) Create a vhost char device and pass vfio mdev device fd to it as a backend and translate vhost-mdev ioctl to virtio mdev transport (e.g read/write). DMA was done through the VFIO DMA mapping on the container that is attached. We have two more choices: 2) Use vfio-mdev but do not create vhost-mdev device, instead, just implement vhost ioctl on vfio_device_ops, and translate them into virtio-mdev transport or just pass ioctl to parent. 3) Don't use vfio-mdev, create a new vhost-mdev driver, during probe still try to add dev to vfio group and talk to parent with device specific ops So I have some questions: 1) Compared to method 2, what's the advantage of creating a new vhost char device? I guess it's for keep the API compatibility? 2) For method 2, is there any easy way for user/admin to distinguish e.g ordinary vfio-mdev for vhost from ordinary vfio-mdev? I saw you introduce ops matching helper but it's not friendly to management. 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that assumes the parameter comes from userspace, it prevents support kernel virtio drivers. 4) So comes the idea of method 3, since it register a new vhost-mdev driver, we can use device specific ops instead of VFIO ones, then we can have a common API between vDPA parent and vhost-mdev/virtio-mdev drivers. What's your thoughts? Thanks RFCv3: https://patchwork.kernel.org/patch/7785/ [1] https://lkml.org/lkml/2019/9/10/135 Tiwei Bie (3): vfio: support getting vfio device from device fd vfio: support checking vfio driver by device ops vhost: introduce mdev based hardware backend drivers/vfio/mdev/vfio_mdev.c| 3 +- drivers/vfio/vfio.c | 32 +++ drivers/vhost/Kconfig| 9 + drivers/vhost/Makefile | 3 + drivers/vhost/mdev.c | 462 +++ drivers/vhost/vhost.c| 39 ++- drivers/vhost/vhost.h| 6 + include/linux/vfio.h | 11 + include/uapi/linux/vhost.h | 10 + include/uapi/linux/vhost_types.h | 5 + 10 files changed, 573 insertions(+), 7 deletions(-) create mode 100644 drivers/vhost/mdev.c
[PATCH] rpmsg: char: release allocated memory
In rpmsg_eptdev_write_iter, if copy_from_iter_full fails the allocated
buffer needs to be released.
Signed-off-by: Navid Emamdoost
---
drivers/rpmsg/rpmsg_char.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index eea5ebbb5119..c655074c07c2 100644
--- a/drivers/rpmsg/rpmsg_char.c
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -227,8 +227,10 @@ static ssize_t rpmsg_eptdev_write_iter(struct kiocb *iocb,
if (!kbuf)
return -ENOMEM;
- if (!copy_from_iter_full(kbuf, len, from))
- return -EFAULT;
+ if (!copy_from_iter_full(kbuf, len, from)) {
+ ret = -EFAULT;
+ goto free_kbuf;
+ }
if (mutex_lock_interruptible(>ept_lock)) {
ret = -ERESTARTSYS;
--
2.17.1
Re: [PATCH v1 0/2] spi: cadence-qspi: Add cadence-qspi support for Intel LGM SoC
Hi Vignesh, Thank you for the review comments and suggestions. On 17/9/2019 12:50 AM, Vignesh Raghavendra wrote: Hi, On 16/09/19 1:08 PM, Ramuthevar,Vadivel MuruganX wrote: patch 1: Add YAML for cadence-qspi devicetree cdocumentation. patch 2: cadence-qspi controller driver to support QSPI-NAND flash using existing spi-nand framework with legacy spi protocol. Nope, you cannot have two drivers for the same IP (i.e Cadence QSPI) just to support to different types of SPI memories. This is the reason why spi_mem_ops was introduced. Please rewrite this driver over to use spi_mem_ops (instead of using generic SPI xfers) so that same driver supports both SPI-NOR and SPI-NAND flashes. Once that's done drivers/mtd/spi-nor/cadence-quadspi.c can be deleted. There are few existing examples of spi_mem_ops users in drivers/spi/ (git grep spi_mem_ops) and materials here on how to write such a driver: [1] https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/ [2] https://www.youtube.com/watch?v=PkWbuLM_gmU Agreed!, Surely let me go through the above link and put my effort to rewrite the drivers as per your suggestions. --- With Best Regards Vadivel Murugan R Ramuthevar Vadivel Murugan (2): dt-bindings: spi: Add support for cadence-qspi IP Intel LGM SoC spi: cadence-qspi: Add QSPI support for Intel LGM SoC .../devicetree/bindings/spi/cadence,qspi-nand.yaml | 84 +++ drivers/spi/Kconfig| 9 + drivers/spi/Makefile | 1 + drivers/spi/spi-cadence-qspi-apb.c | 644 + drivers/spi/spi-cadence-qspi-apb.h | 174 ++ drivers/spi/spi-cadence-qspi.c | 461 +++ drivers/spi/spi-cadence-qspi.h | 73 +++ 7 files changed, 1446 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/cadence,qspi-nand.yaml create mode 100644 drivers/spi/spi-cadence-qspi-apb.c create mode 100644 drivers/spi/spi-cadence-qspi-apb.h create mode 100644 drivers/spi/spi-cadence-qspi.c create mode 100644 drivers/spi/spi-cadence-qspi.h
Re: [PATCH 1/3] ixgbe: Use kzfree() rather than its implementation.
On 2019/9/17 10:43, Jakub Kicinski wrote: > On Wed, 4 Sep 2019 10:39:10 +0800, zhong jiang wrote: >> Use kzfree() instead of memset() + kfree(). >> >> Signed-off-by: zhong jiang >> --- >> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 9 +++-- >> 1 file changed, 3 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c >> b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c >> index 31629fc..113f608 100644 >> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c >> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c >> @@ -960,11 +960,9 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter >> *adapter, u32 *msgbuf, u32 vf) >> return 0; >> >> err_aead: >> -memset(xs->aead, 0, sizeof(*xs->aead)); >> -kfree(xs->aead); >> +kzfree(xs->aead); >> err_xs: >> -memset(xs, 0, sizeof(*xs)); >> -kfree(xs); >> +kzfree(xs); >> err_out: >> msgbuf[1] = err; >> return err; >> @@ -1049,8 +1047,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter >> *adapter, u32 *msgbuf, u32 vf) >> ixgbe_ipsec_del_sa(xs); >> >> /* remove the xs that was made-up in the add request */ >> -memset(xs, 0, sizeof(*xs)); >> -kfree(xs); >> +kzfree(xs); >> >> return 0; >> } > All the crypto cases should really be converted to memzero_explicit(). It's better to do that. I will repost it in v2. Thanks, zhong jiang
[PATCH RESEND V5 3/5] arm64: dts: imx8qxp: Add scu key node
Add scu key node for i.MX8QXP, disabled by default as it
depends on board design.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 1133b41..71e38c1 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -174,6 +175,12 @@
#power-domain-cells = <1>;
};
+ scu_key: scu-key {
+ compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
+ linux,keycode = ;
+ status = "disabled";
+ };
+
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
--
2.7.4
RE: [PATCH V5 1/5] dt-bindings: fsl: scu: add scu key binding
Sorry, please ignore this version, it has build issue, just resent the patch
series.
Anson.
> Subject: [PATCH V5 1/5] dt-bindings: fsl: scu: add scu key binding
>
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> controller, the system controller is in charge of system power, clock and scu
> key event etc. management, Linux kernel has to communicate with system
> controller via MU (message unit) IPC to get scu key event, add binding doc for
> i.MX system controller key driver.
>
> Signed-off-by: Anson Huang
> ---
> No changes.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14
> ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index c149fad..5eab7d0 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -157,6 +157,15 @@ Required properties:
> Optional properties:
> - timeout-sec: contains the watchdog timeout in seconds.
>
> +SCU key bindings based on SCU Message Protocol
> +
> +
> +Required properties:
> +- compatible: should be:
> + "fsl,imx8qxp-sc-key"
> + followed by "fsl,imx-sc-key";
> +- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
> +
> Example (imx8qxp):
> -
> aliases {
> @@ -220,6 +229,11 @@ firmware {
> compatible = "fsl,imx8qxp-sc-rtc";
> };
>
> + scu_key: scu-key {
> + compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
> + linux,keycode = ;
> + };
> +
> watchdog {
> compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
> timeout-sec = <60>;
> --
> 2.7.4
[PATCH RESEND V5 1/5] dt-bindings: fsl: scu: add scu key binding
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and scu key event etc. management, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key event, add binding doc for i.MX system controller
key driver.
Signed-off-by: Anson Huang
---
No changes.
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index c149fad..5eab7d0 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -157,6 +157,15 @@ Required properties:
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
+SCU key bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: should be:
+ "fsl,imx8qxp-sc-key"
+ followed by "fsl,imx-sc-key";
+- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
+
Example (imx8qxp):
-
aliases {
@@ -220,6 +229,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-rtc";
};
+ scu_key: scu-key {
+ compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
+ linux,keycode = ;
+ };
+
watchdog {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
--
2.7.4
[PATCH RESEND V5 2/5] input: keyboard: imx_sc: Add i.MX system controller key support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and scu key etc..
Adds i.MX system controller key driver support, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key's status.
Signed-off-by: Anson Huang
---
Changes since V4:
- reduce debounce time from 100mS to 30mS;
- remove unnecessary delay_check for button release interrupt which is
NOT existing at all;
- using error instead of ret;
- move pm_wakeup_event() to interrupt notify and ONLY calling
pm_relax() when button is released;
- remove unnecessary logic code of avoiding quick button press/release.
---
drivers/input/keyboard/Kconfig | 7 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/imx_sc_key.c | 184
3 files changed, 192 insertions(+)
create mode 100644 drivers/input/keyboard/imx_sc_key.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 8911bc2..00f8428 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -469,6 +469,13 @@ config KEYBOARD_IMX
To compile this driver as a module, choose M here: the
module will be called imx_keypad.
+config KEYBOARD_IMX_SC_KEY
+ tristate "IMX SCU Key Driver"
+ depends on IMX_SCU
+ help
+ This is the system controller key driver for NXP i.MX SoCs with
+ system controller inside.
+
config KEYBOARD_NEWTON
tristate "Newton keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 9510325..f5b1752 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL)+= hil_kbd.o
obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
+obj-$(CONFIG_KEYBOARD_IMX_SC_KEY) += imx_sc_key.o
obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
diff --git a/drivers/input/keyboard/imx_sc_key.c
b/drivers/input/keyboard/imx_sc_key.c
new file mode 100644
index 000..43485bd
--- /dev/null
+++ b/drivers/input/keyboard/imx_sc_key.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEBOUNCE_TIME 30
+#define REPEAT_INTERVAL60
+
+#define SC_IRQ_BUTTON 1
+#define SC_IRQ_GROUP_WAKE 3
+#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
+
+struct imx_key_drv_data {
+ int keycode;
+ bool keystate; /* 1: pressed, 0: release */
+ struct delayed_work check_work;
+ struct input_dev *input;
+ struct imx_sc_ipc *key_ipc_handle;
+ struct notifier_block key_notifier;
+};
+
+struct imx_sc_msg_key {
+ struct imx_sc_rpc_msg hdr;
+ u8 state;
+};
+
+static int imx_sc_key_notify(struct notifier_block *nb,
+unsigned long event, void *group)
+{
+ struct imx_key_drv_data *priv =
+container_of(nb,
+ struct imx_key_drv_data,
+ key_notifier);
+
+ if ((event & SC_IRQ_BUTTON) && (*(u8 *)group == SC_IRQ_GROUP_WAKE)) {
+ schedule_delayed_work(>check_work,
+ msecs_to_jiffies(DEBOUNCE_TIME));
+ pm_wakeup_event(priv->input->dev.parent, 0);
+ }
+
+ return 0;
+}
+
+static void imx_sc_check_for_events(struct work_struct *work)
+{
+ struct imx_key_drv_data *priv =
+container_of(work,
+ struct imx_key_drv_data,
+ check_work.work);
+ struct input_dev *input = priv->input;
+ struct imx_sc_msg_key msg;
+ struct imx_sc_rpc_msg *hdr =
+ bool state;
+ int error;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
+ hdr->size = 1;
+
+ error = imx_scu_call_rpc(priv->key_ipc_handle, , true);
+ if (error) {
+ dev_err(>dev, "read imx sc key failed, error %d\n",
error);
+ return;
+ }
+
+ state = (bool)msg.state;
+
+ if (state ^ priv->keystate) {
+ priv->keystate = state;
+ input_event(input, EV_KEY, priv->keycode, state);
+ input_sync(input);
+ if (!priv->keystate)
+
[PATCH RESEND V5 5/5] arm64: defconfig: Enable CONFIG_KEYBOARD_IMX_SC_KEY as module
Select CONFIG_KEYBOARD_IMX_SC_KEY as module by default to support i.MX8QXP scu key driver. Signed-off-by: Anson Huang --- No changes. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 0a70e10..9c83014 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -314,6 +314,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_ADC=m CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_SNVS_PWRKEY=m +CONFIG_KEYBOARD_IMX_SC_KEY=m CONFIG_KEYBOARD_CROS_EC=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ATMEL_MXT=m -- 2.7.4
[PATCH RESEND V5 4/5] arm64: dts: imx8qxp-mek: Enable scu key
Enable scu key for i.MX8QXP MEK board.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 1946805..88dd9132 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -234,3 +234,7 @@
_dsp {
status = "okay";
};
+
+_key {
+ status = "okay";
+};
--
2.7.4
Re: [PATCH] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()
On 09/16/2019 02:20 PM, Anshuman Khandual wrote:
>
>
> On 09/16/2019 12:06 PM, Mike Rapoport wrote:
>> On Mon, Sep 16, 2019 at 11:17:37AM +0530, Anshuman Khandual wrote:
>>> In add_memory_resource() the memory range to be hot added first gets into
>>> the memblock via memblock_add() before arch_add_memory() is called on it.
>>> Reverse sequence should be followed during memory hot removal which already
>>> is being followed in add_memory_resource() error path. This now ensures
>>> required re-order between memblock_[free|remove]() and arch_remove_memory()
>>> during memory hot-remove.
>>>
>>> Cc: Andrew Morton
>>> Cc: Oscar Salvador
>>> Cc: Michal Hocko
>>> Cc: David Hildenbrand
>>> Cc: Pavel Tatashin
>>> Cc: Dan Williams
>>> Signed-off-by: Anshuman Khandual
>>> ---
>>> Original patch https://lkml.org/lkml/2019/9/3/327
>>>
>>> Memory hot remove now works on arm64 without this because a recent commit
>>> 60bb462fc7ad ("drivers/base/node.c: simplify
>>> unregister_memory_block_under_nodes()").
>>>
>>> David mentioned that re-ordering should still make sense for consistency
>>> purpose (removing stuff in the reverse order they were added). This patch
>>> is now detached from arm64 hot-remove series.
>>>
>>> https://lkml.org/lkml/2019/9/3/326
>>>
>>> mm/memory_hotplug.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index c73f09913165..355c466e0621 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -1770,13 +1770,13 @@ static int __ref try_remove_memory(int nid, u64
>>> start, u64 size)
>>>
>>> /* remove memmap entry */
>>> firmware_map_remove(start, start + size, "System RAM");
>>> - memblock_free(start, size);
>>> - memblock_remove(start, size);
>>>
>>> /* remove memory block devices before removing memory */
>>> remove_memory_block_devices(start, size);
>>>
>>> arch_remove_memory(nid, start, size, NULL);
>>> + memblock_free(start, size);
>>
>> I don't see memblock_reserve() anywhere in memory_hotplug.c, so the
>> memblock_free() call here seems superfluous. I think it can be simply
>> dropped.
>
> I had observed that previously but was not sure whether or not there are
> still scenarios where it might be true. Error path in add_memory_resource()
> even just calls memblock_remove() not memblock_free(). Unless there is any
> objection, can just drop it.
Hello Mike,
Looks like we might need memblock_free() here as well. As you mentioned
before there might not be any memblock_reserve() in mm/memory_hotplug.c
but that does not guarantee that there could not have been a previous
memblock_reserve() or memblock_alloc_XXX() allocation which came from
the current hot remove range.
memblock_free() followed by memblock_remove() on the entire hot-remove
range ensures that memblock.memory and memblock.reserve are in sync and
the entire range is guaranteed to be removed from both the memory types.
Or am I missing something here.
- Anshuman
Re: [PATCH 2/3] nfp: Drop unnecessary continue in nfp_net_pf_alloc_vnics
On 2019/9/17 10:45, Jakub Kicinski wrote:
> On Wed, 4 Sep 2019 11:46:23 +0800, zhong jiang wrote:
>> Continue is not needed at the bottom of a loop.
>>
>> Signed-off-by: zhong jiang
>> ---
>> drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
>> b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
>> index 986464d..68db47d 100644
>> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
>> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
>> @@ -205,10 +205,8 @@ static void nfp_net_pf_free_vnics(struct nfp_pf *pf)
>> ctrl_bar += NFP_PF_CSR_SLICE_SIZE;
>>
>> /* Kill the vNIC if app init marked it as invalid */
>> -if (nn->port && nn->port->type == NFP_PORT_INVALID) {
>> +if (nn->port && nn->port->type == NFP_PORT_INVALID)
>> nfp_net_pf_free_vnic(pf, nn);
>> -continue;
>> -}
> Ugh, I already nack at least one patch like this, this continue makes
> the _intent_ of the code more clear, the compiler will ignore it anyway.
Thanks, I miss that information you object to above modification.
Sincerely,
zhong jiang
> I guess there's no use in fighting the bots..
>
>> }
>>
>> if (list_empty(>vnics))
>
> .
>
Re: [PATCH] lockdep: Make print_lock() address visible
On Mon, Sep 16, 2019 at 06:39:46PM -0700, keesc...@chromium.org wrote: > commit 519248f36d6f3c80e176f6fa844c10d94f1f5990 > Author: Paul E. McKenney > Date: Thu May 30 05:39:25 2019 -0700 > > lockdep: Make print_lock() address visible > > Security is a wonderful thing, but so is the ability to debug based on > lockdep warnings. This commit therefore makes lockdep lock addresses > visible in the clear. > > Signed-off-by: Paul E. McKenney > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 4861cf8e274b..4aca3f4379d2 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -620,7 +620,7 @@ static void print_lock(struct held_lock *hlock) > return; > } > > - printk(KERN_CONT "%p", hlock->instance); > + printk(KERN_CONT "%px", hlock->instance); > print_lock_name(lock); > printk(KERN_CONT ", at: %pS\n", (void *)hlock->acquire_ip); > } Just to clarify: this is only visible under CONFIG_LOCKDEP, yes? That's not a state anyone would run a production system under, I'd hope. -- Kees Cook
Re: [PATCH] usercopy: Skip HIGHMEM page checking
On Mon, Sep 16, 2019 at 05:32:09PM -0700, Matthew Wilcox wrote: > On Mon, Sep 16, 2019 at 02:32:56PM -0700, Kees Cook wrote: > > When running on a system with >512MB RAM with a 32-bit kernel built with: > > > > CONFIG_DEBUG_VIRTUAL=y > > CONFIG_HIGHMEM=y > > CONFIG_HARDENED_USERCOPY=y > > > > all execve()s will fail due to argv copying into kmap()ed pages, and on > > usercopy checking the calls ultimately of virt_to_page() will be looking > > for "bad" kmap (highmem) pointers due to CONFIG_DEBUG_VIRTUAL=y: > > I don't understand why you want to skip the check. We must not cross a > page boundary of a kmapped page. That requires a new test which hasn't existed before. First I need to fix the bug, and then we can add a new test and get that into -next, etc. -- Kees Cook
Re: [GIT PULL] platform-drivers-x86 for 5.4-1
The pull request you sent on Fri, 13 Sep 2019 20:06:55 +0300: > git://git.infradead.org/linux-platform-drivers-x86.git > tags/platform-drivers-x86-v5.4-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ad062195731bea1624ce7160e79e0fcdaa25c1b5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
RE: [PATCH] staging: exfat: add exfat filesystem code to
We are excited to see this happening and would like to state that we appreciate time and effort which people put into upstreaming exfat. Thank you! However, if possible, can we step back a little bit and re-consider it? We would prefer to see upstream the code which we are currently using in our products - sdfat - as this can be mutually benefitial from various points of view. Thanks! > -- Forwarded message - > 보낸사람: Ju Hyung Park > Date: 2019년 9월 16일 (월) 오전 3:49 > Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to > To: Greg KH > Cc: , , fsde...@vger.kernel.org>, , Valdis Kletnieks > > > > Hi Greg, > > On Sun, Sep 15, 2019 at 10:54 PM Greg KH wrote: > > Note, this just showed up publically on August 12, where were you with > > all of this new code before then? :) > > My sdFAT port, exfat-nofuse and the one on the staging tree, were all > made by Samsung. > And unless you guys had a chance to talk to Samsung developers > directly, those all share the same faith of lacking proper development > history. > > The source I used was from http://opensource.samsung.com, which > provides kernel sources as tar.gz files. > There is no code history available. > > > For the in-kernel code, we would have to rip out all of the work you did > > for all older kernels, so that's a non-starter right there. > > I'm aware. > I'm just letting mainline know that there is potentially another (much > better) base that could be upstreamed. > > If you want me to rip out older kernel support for upstreaming, I'm > more than happy to do so. > > > As for what codebase to work off of, I don't want to say it is too late, > > but really, this shows up from nowhere and we had to pick something so > > we found the best we could at that point in time. > > To be honest, whole public exFAT sources are all from nowhere unless > you had internal access to Samsung's development archive. > The one in the current staging tree isn't any better. > > I'm not even sure where the staging driver is from, actually. > > Samsung used the 1.2.x versioning until they switched to a new code > base - sdFAT. > The one in the staging tree is marked version 1.3.0(exfat_super.c). > I failed to find anything 1.3.x from Samsung's public kernel sources. > > The last time exFAT 1.2.x was used was in Galaxy S7(released in 2016). > Mine was originally based on sdFAT 2.1.10, used in Galaxy S10(released > in March 2019) and it just got updated to 2.2.0, used in Galaxy > Note10(released in August 2019). > > > Is there anything specific in the codebase you have now, that is lacking > > in the in-kernel code? Old-kernel-support doesn't count here, as we > > don't care about that as it is not applicable. But functionality does > > matter, what has been added here that we can make use of? > > This is more of a suggestion of > "Let's base on a *much more recent* snapshot for the community to work on", > since the current one on the staging tree also lacks development history. > > The diff is way too big to even start understanding the difference. > > > With that said though, I do have some vague but real reason as to why > sdFAT base is better. > > With some major Android vendors showing interests in supporting exFAT, > Motorola notably published their work on public Git repository with > full development history(the only vendor to do this that I'm aware > of). > Commits like this: > https://github.com/MotorolaMobilityLLC/kernel-msm/commit/7ab1657 is > not merged to exFAT(including the current staging tree one) while it > did for sdFAT. > > > The only thing I regret is not working on porting sdFAT sooner. > I definitely didn't anticipate Microsoft to suddenly lift legal issues > on upstreaming exFAT just around when I happen to gain interest in > porting sdFAT. > > If my port happened sooner, it would have been a no-brainer for it to > be considered as a top candidate for upstreaming. > > > And do you have any "real" development history to look at instead of the > > "one giant commit" of the initial code drop? That is where we could > > actually learn what has changed over time. Your repo as-is shows none > > of the interesting bits :( > > As I mentioned, development history is unobtainable, even for the > current staging tree or exfat-nofuse. > (If you guys took exfat-nofuse, you can also see that there's barely > any real exFAT-related development done in that tree. Everything is > basically fixes for newer kernel versions.) > > The best I could do, if someone's interested, is to diff all versions > of exFAT/sdFAT throughout the Samsung's kernel versions, but that > still won't give us reasons as to why the changes were made. > > TL;DR > My suggestion - Let's base on a much newer driver that's matured more, > contains more fixes, gives (slightly?) better performance and > hopefully has better code quality. > > Both drivers are horrible. > You said it yourself(for the current staging one), and even for my
[PATCH V5 2/5] input: keyboard: imx_sc: Add i.MX system controller key support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and scu key etc..
Adds i.MX system controller key driver support, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key's status.
Signed-off-by: Anson Huang
---
Changes since V4:
- reduce debounce time from 100mS to 30mS;
- remove unnecessary delay_check for button release interrupt which is
NOT existing at all;
- using error instead of ret;
- move pm_wakeup_event() to interrupt notify and ONLY calling
pm_relax() when button is released;
- remove unnecessary logic code of avoiding quick button press/release.
---
drivers/input/keyboard/Kconfig | 7 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/imx_sc_key.c | 184
3 files changed, 192 insertions(+)
create mode 100644 drivers/input/keyboard/imx_sc_key.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 8911bc2..00f8428 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -469,6 +469,13 @@ config KEYBOARD_IMX
To compile this driver as a module, choose M here: the
module will be called imx_keypad.
+config KEYBOARD_IMX_SC_KEY
+ tristate "IMX SCU Key Driver"
+ depends on IMX_SCU
+ help
+ This is the system controller key driver for NXP i.MX SoCs with
+ system controller inside.
+
config KEYBOARD_NEWTON
tristate "Newton keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 9510325..f5b1752 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL)+= hil_kbd.o
obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
+obj-$(CONFIG_KEYBOARD_IMX_SC_KEY) += imx_sc_key.o
obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
diff --git a/drivers/input/keyboard/imx_sc_key.c
b/drivers/input/keyboard/imx_sc_key.c
new file mode 100644
index 000..173e377
--- /dev/null
+++ b/drivers/input/keyboard/imx_sc_key.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEBOUNCE_TIME 30
+#define REPEAT_INTERVAL60
+
+#define SC_IRQ_BUTTON 1
+#define SC_IRQ_GROUP_WAKE 3
+#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
+
+struct imx_key_drv_data {
+ int keycode;
+ bool keystate; /* 1: pressed, 0: release */
+ struct delayed_work check_work;
+ struct input_dev *input;
+ struct imx_sc_ipc *key_ipc_handle;
+ struct notifier_block key_notifier;
+};
+
+struct imx_sc_msg_key {
+ struct imx_sc_rpc_msg hdr;
+ u8 state;
+};
+
+static int imx_sc_key_notify(struct notifier_block *nb,
+unsigned long event, void *group)
+{
+ struct imx_key_drv_data *priv =
+container_of(nb,
+ struct imx_key_drv_data,
+ key_notifier);
+
+ if ((event & SC_IRQ_BUTTON) && (*(u8 *)group == SC_IRQ_GROUP_WAKE)) {
+ schedule_delayed_work(>check_work,
+ msecs_to_jiffies(DEBOUNCE_TIME));
+ pm_wakeup_event(priv->input->dev.parent, 0);
+ }
+
+ return 0;
+}
+
+static void imx_sc_check_for_events(struct work_struct *work)
+{
+ struct imx_key_drv_data *priv =
+container_of(work,
+ struct imx_key_drv_data,
+ check_work.work);
+ struct input_dev *input = priv->input;
+ struct imx_sc_msg_key msg;
+ struct imx_sc_rpc_msg *hdr =
+ bool state;
+ int error;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
+ hdr->size = 1;
+
+ error = imx_scu_call_rpc(priv->key_ipc_handle, , true);
+ if (error) {
+ dev_err(>dev, "read imx sc key failed, ret %d\n", ret);
+ return;
+ }
+
+ state = (bool)msg.state;
+
+ if (state ^ priv->keystate) {
+ priv->keystate = state;
+ input_event(input, EV_KEY, priv->keycode, state);
+ input_sync(input);
+ if (!priv->keystate)
+ pm_relax(priv->input->dev.parent);
+
[PATCH V5 4/5] arm64: dts: imx8qxp-mek: Enable scu key
Enable scu key for i.MX8QXP MEK board.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 1946805..88dd9132 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -234,3 +234,7 @@
_dsp {
status = "okay";
};
+
+_key {
+ status = "okay";
+};
--
2.7.4
[PATCH V5 1/5] dt-bindings: fsl: scu: add scu key binding
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and scu key event etc. management, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key event, add binding doc for i.MX system controller
key driver.
Signed-off-by: Anson Huang
---
No changes.
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index c149fad..5eab7d0 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -157,6 +157,15 @@ Required properties:
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
+SCU key bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: should be:
+ "fsl,imx8qxp-sc-key"
+ followed by "fsl,imx-sc-key";
+- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
+
Example (imx8qxp):
-
aliases {
@@ -220,6 +229,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-rtc";
};
+ scu_key: scu-key {
+ compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
+ linux,keycode = ;
+ };
+
watchdog {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
--
2.7.4
[PATCH V5 5/5] arm64: defconfig: Enable CONFIG_KEYBOARD_IMX_SC_KEY as module
Select CONFIG_KEYBOARD_IMX_SC_KEY as module by default to support i.MX8QXP scu key driver. Signed-off-by: Anson Huang --- No changes. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 0a70e10..9c83014 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -314,6 +314,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_ADC=m CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_SNVS_PWRKEY=m +CONFIG_KEYBOARD_IMX_SC_KEY=m CONFIG_KEYBOARD_CROS_EC=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ATMEL_MXT=m -- 2.7.4
[PATCH V5 3/5] arm64: dts: imx8qxp: Add scu key node
Add scu key node for i.MX8QXP, disabled by default as it
depends on board design.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 1133b41..71e38c1 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -174,6 +175,12 @@
#power-domain-cells = <1>;
};
+ scu_key: scu-key {
+ compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
+ linux,keycode = ;
+ status = "disabled";
+ };
+
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
--
2.7.4
Re: [PATCH 1/1] powerpc: mm: Check if serialize_against_pte_lookup() really needs to run
On 9/17/19 2:25 AM, Leonardo Bras wrote:
If a process (qemu) with a lot of CPUs (128) try to munmap() a large chunk
of memory (496GB) mapped with THP, it takes an average of 275 seconds,
which can cause a lot of problems to the load (in qemu case, the guest
will lock for this time).
Trying to find the source of this bug, I found out most of this time is
spent on serialize_against_pte_lookup(). This function will take a lot of
time in smp_call_function_many() if there is more than a couple CPUs
running the user process. Since it has to happen to all THP mapped, it will
take a very long time for large amounts of memory.
By the docs, serialize_against_pte_lookup() is needed in order to avoid
pmd_t to pte_t casting inside find_current_mm_pte() to happen concurrently
with the next part of the functions it's called in.
It does so by calling a do_nothing() on each CPU in mm->cpu_bitmap[];
So, by what I could understand, if there is no find_current_mm_pte()
running, there is no need to call serialize_against_pte_lookup().
So, to avoid the cost of running serialize_against_pte_lookup(), I propose
a counter that keeps track of how many find_current_mm_pte() are currently
running, and if there is none, just skip smp_call_function_many().
On my workload (qemu), I could see munmap's time reduction from 275 seconds
to 418ms.
Signed-off-by: Leonardo Bras
We could possibly avoid that serialize for a full task exit unmap. ie,
when tlb->fullmm == 1 . But that won't help the Qemu case because it
does an umap of the guest ram range for which tlb->fullmm != 1.
---
I need more experienced people's help in order to understand if this is
really a valid improvement, and if mm_struct is the best place to put such
counter.
Thanks!
---
arch/powerpc/include/asm/pte-walk.h | 3 +++
arch/powerpc/mm/book3s64/pgtable.c | 2 ++
include/linux/mm_types.h| 1 +
3 files changed, 6 insertions(+)
diff --git a/arch/powerpc/include/asm/pte-walk.h
b/arch/powerpc/include/asm/pte-walk.h
index 33fa5dd8ee6a..3b82cb3bd563 100644
--- a/arch/powerpc/include/asm/pte-walk.h
+++ b/arch/powerpc/include/asm/pte-walk.h
@@ -40,6 +40,8 @@ static inline pte_t *find_current_mm_pte(pgd_t *pgdir,
unsigned long ea,
{
pte_t *pte;
+ atomic64_inc(>mm->lockless_ptlookup_count);
+
VM_WARN(!arch_irqs_disabled(), "%s called with irq enabled\n",
__func__);
VM_WARN(pgdir != current->mm->pgd,
"%s lock less page table lookup called on wrong mm\n",
__func__);
@@ -53,6 +55,7 @@ static inline pte_t *find_current_mm_pte(pgd_t *pgdir,
unsigned long ea,
if (hshift)
WARN_ON(*hshift);
#endif
+ atomic64_dec(>mm->lockless_ptlookup_count);
return pte;
}
That is not correct. We need to keep the count updated across the
local_irq_disable()/local_irq_enable(). That is we mostly should have a
variant like start_lockless_pgtbl_walk()/end_lockless_pgtbl_walk(). Also
there is hash_page_mm which we need to make sure we are protected
against w.r.t collapse pmd.
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index 7d0e0d0d22c4..8f6fc2f80071 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -95,6 +95,8 @@ static void do_nothing(void *unused)
void serialize_against_pte_lookup(struct mm_struct *mm)
{
smp_mb();
+ if (atomic64_read(>lockless_ptlookup_count) == 0)
+ return;
smp_call_function_many(mm_cpumask(mm), do_nothing, NULL, 1);
}
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6a7a1083b6fb..97fb2545e967 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -518,6 +518,7 @@ struct mm_struct {
#endif
} __randomize_layout;
+ atomic64_t lockless_ptlookup_count;
/*
* The mm_cpumask needs to be at the end of mm_struct, because it
* is dynamically sized based on nr_cpu_ids.
Move that to ppc64 specific mm_context_t.
-aneesh
Re: [GIT PULL] x86/hyperv changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 15:18:51 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-hyperv-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e2bddc20b562ee23046ad541cf29314e4aebd934 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] x86/asm changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 14:34:54 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-asm-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/df4c0b18f2a2798f1e3ae9dcf58c024bb33e4202 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] x86/mm changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 15:25:10 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ac51667b5b95f1209aa97af780cecf0cf6f4003f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] x86/cpu changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 14:53:27 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cpu-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/22331f895298bd23ca9f99f6a237aae883c9e1c7 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] x86/vmware changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 15:36:46 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-vmware-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7ac63f6ba5db5e2e81e4674551d6f9ec58e70618 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] x86/entry changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 14:58:11 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-entry-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e0d60a1e68a3fbf42cdf3546004e00230d9048ba Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] x86/build change for v5.4
The pull request you sent on Mon, 16 Sep 2019 14:42:56 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-build-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fc6fd1392a8f3d5f3d722ad9c92314477c1a2a35 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] x86/platform changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 15:31:09 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > x86-platform-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6f24671485d0d0eaeaccd910fa8148db72aac089 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] x86/boot change for v5.4
The pull request you sent on Mon, 16 Sep 2019 14:39:43 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-boot-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/49a21e52a6baeea076301fd944268fd0d1f75be1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 2/3] nfp: Drop unnecessary continue in nfp_net_pf_alloc_vnics
On Wed, 4 Sep 2019 11:46:23 +0800, zhong jiang wrote:
> Continue is not needed at the bottom of a loop.
>
> Signed-off-by: zhong jiang
> ---
> drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> index 986464d..68db47d 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> @@ -205,10 +205,8 @@ static void nfp_net_pf_free_vnics(struct nfp_pf *pf)
> ctrl_bar += NFP_PF_CSR_SLICE_SIZE;
>
> /* Kill the vNIC if app init marked it as invalid */
> - if (nn->port && nn->port->type == NFP_PORT_INVALID) {
> + if (nn->port && nn->port->type == NFP_PORT_INVALID)
> nfp_net_pf_free_vnic(pf, nn);
> - continue;
> - }
Ugh, I already nack at least one patch like this, this continue makes
the _intent_ of the code more clear, the compiler will ignore it anyway.
I guess there's no use in fighting the bots..
> }
>
> if (list_empty(>vnics))
Re: [PATCH v4 3/5] vimc: move duplicated IS_SRC and IS_SINK to common header
On 9/16/19 4:42 AM, Helen Koike wrote: On 9/15/19 8:52 PM, Shuah Khan wrote: On 9/15/19 1:25 PM, Helen Koike wrote: Hi Shuah, On 9/6/19 11:42 PM, Shuah Khan wrote: Move duplicated IS_SRC and IS_SINK dfines to common header. Rename them to VIMC_IS_SRC and VIM_IS_SINK. Signed-off-by: Shuah Khan --- drivers/media/platform/vimc/vimc-common.h | 4 drivers/media/platform/vimc/vimc-debayer.c | 11 --- drivers/media/platform/vimc/vimc-scaler.c | 8 +++- 3 files changed, 11 insertions(+), 12 deletions(-) diff --git a/drivers/media/platform/vimc/vimc-common.h b/drivers/media/platform/vimc/vimc-common.h index 87ee84f78322..236412ad7548 100644 --- a/drivers/media/platform/vimc/vimc-common.h +++ b/drivers/media/platform/vimc/vimc-common.h @@ -27,6 +27,10 @@ #define VIMC_FRAME_INDEX(lin, col, width, bpp) ((lin * width + col) * bpp) +/* Source and sink pad checks */ +#define VIMC_IS_SRC(pad) (pad) +#define VIMC_IS_SINK(pad) (!(pad)) This is true now, but it might not be true in the future. In the output video device (that was sent by André but not yet upstream) for instance, only have a single source pad (which I suppose the index will be 0), and this macro won't be true. Maybe we could check pad flags in sd->entity->pads[index].flags ? I think this change should be done in André's patch? Could be yes, making it generic since the start would be nice, but I don't mind updating this latter when needed. Let's go with that then. This way we can get this series in and then we can clean this up in André's patch. Then: Acked-by: Helen Koike thanks, -- Shuah
Re: [PATCH 1/3] ixgbe: Use kzfree() rather than its implementation.
On Wed, 4 Sep 2019 10:39:10 +0800, zhong jiang wrote: > Use kzfree() instead of memset() + kfree(). > > Signed-off-by: zhong jiang > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c > b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c > index 31629fc..113f608 100644 > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c > @@ -960,11 +960,9 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, > u32 *msgbuf, u32 vf) > return 0; > > err_aead: > - memset(xs->aead, 0, sizeof(*xs->aead)); > - kfree(xs->aead); > + kzfree(xs->aead); > err_xs: > - memset(xs, 0, sizeof(*xs)); > - kfree(xs); > + kzfree(xs); > err_out: > msgbuf[1] = err; > return err; > @@ -1049,8 +1047,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter > *adapter, u32 *msgbuf, u32 vf) > ixgbe_ipsec_del_sa(xs); > > /* remove the xs that was made-up in the add request */ > - memset(xs, 0, sizeof(*xs)); > - kfree(xs); > + kzfree(xs); > > return 0; > } All the crypto cases should really be converted to memzero_explicit().
RE: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system controller key support
Hi, Dmitry
> On Mon, Sep 16, 2019 at 10:52:50AM +0800, Anson Huang wrote:
> > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> > inside, the system controller is in charge of controlling power, clock
> > and scu key etc..
> >
> > Adds i.MX system controller key driver support, Linux kernel has to
> > communicate with system controller via MU (message unit) IPC to get
> > scu key's status.
> >
> > Signed-off-by: Anson Huang
> > ---
> > Changes since V3:
> > - switch the debounce and repeat interval time for delay work
> schdule;
> > - add .remove to handle group irq and notify etc..
> > ---
> > drivers/input/keyboard/Kconfig | 7 ++
> > drivers/input/keyboard/Makefile | 1 +
> > drivers/input/keyboard/imx_sc_key.c | 190
> >
> > 3 files changed, 198 insertions(+)
> > create mode 100644 drivers/input/keyboard/imx_sc_key.c
> >
> > diff --git a/drivers/input/keyboard/Kconfig
> > b/drivers/input/keyboard/Kconfig index 8911bc2..00f8428 100644
> > --- a/drivers/input/keyboard/Kconfig
> > +++ b/drivers/input/keyboard/Kconfig
> > @@ -469,6 +469,13 @@ config KEYBOARD_IMX
> > To compile this driver as a module, choose M here: the
> > module will be called imx_keypad.
> >
> > +config KEYBOARD_IMX_SC_KEY
> > + tristate "IMX SCU Key Driver"
> > + depends on IMX_SCU
> > + help
> > + This is the system controller key driver for NXP i.MX SoCs with
> > + system controller inside.
> > +
> > config KEYBOARD_NEWTON
> > tristate "Newton keyboard"
> > select SERIO
> > diff --git a/drivers/input/keyboard/Makefile
> > b/drivers/input/keyboard/Makefile index 9510325..f5b1752 100644
> > --- a/drivers/input/keyboard/Makefile
> > +++ b/drivers/input/keyboard/Makefile
> > @@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL)+= hil_kbd.o
> > obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
> > obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
> > obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
> > +obj-$(CONFIG_KEYBOARD_IMX_SC_KEY) += imx_sc_key.o
> > obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
> > obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
> > obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
> > diff --git a/drivers/input/keyboard/imx_sc_key.c
> > b/drivers/input/keyboard/imx_sc_key.c
> > new file mode 100644
> > index 000..59c68fa
> > --- /dev/null
> > +++ b/drivers/input/keyboard/imx_sc_key.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright 2019 NXP.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DEBOUNCE_TIME 100
> > +#define REPEAT_INTERVAL60
> > +
> > +#define SC_IRQ_BUTTON 1
> > +#define SC_IRQ_GROUP_WAKE 3
> > +#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
> > +
> > +struct imx_key_drv_data {
> > + int keycode;
> > + bool keystate; /* 1: pressed, 0: release */
> > + bool delay_check;
> > + struct delayed_work check_work;
> > + struct input_dev *input;
> > + struct imx_sc_ipc *key_ipc_handle;
> > + struct notifier_block key_notifier;
> > +};
> > +
> > +struct imx_sc_msg_key {
> > + struct imx_sc_rpc_msg hdr;
> > + u8 state;
> > +};
> > +
> > +static int imx_sc_key_notify(struct notifier_block *nb,
> > +unsigned long event, void *group) {
> > + struct imx_key_drv_data *priv =
> > +container_of(nb,
> > + struct imx_key_drv_data,
> > + key_notifier);
> > +
> > + if ((event & SC_IRQ_BUTTON) && (*(u8 *)group ==
> SC_IRQ_GROUP_WAKE)
> > + && !priv->delay_check) {
> > + priv->delay_check = 1;
> > + schedule_delayed_work(>check_work,
> > + msecs_to_jiffies(DEBOUNCE_TIME));
>
> If I am reading this right, you are trying to avoid scheduling the work again
> if
> it is already scheduled. You do not need to do that, as
> schedule_delayed_work() will take care of that (if you want to make sure the
> work is re-scheduled with updated expiration, you need to use
> mod_delayed_work).
The original code here is to skip the event of button release, try to ONLY
handle the press interrupt, the release
event is handled by busy loop check, but I double check the SCU FW's behavior,
it does NOT send out interrupt
for button release event at all, so it is NOT needed any more, I will remove
the priv->delay_check completely in this driver.
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void imx_sc_check_for_events(struct work_struct *work) {
> > + struct imx_key_drv_data *priv =
> > +container_of(work,
> > + struct imx_key_drv_data,
> > +
Re: [RFC PATCH v2] mm: initialize struct pages reserved by ZONE_DEVICE driver.
On 2019/09/09 16:46, David Hildenbrand wrote:
> Let's take a step back here to understand the issues I am aware of. I
> think we should solve this for good now:
>
> A PFN walker takes a look at a random PFN at a random point in time. It
> finds a PFN with SECTION_MARKED_PRESENT && !SECTION_IS_ONLINE. The
> options are:
>
> 1. It is buddy memory (add_memory()) that has not been online yet. The
> memmap contains garbage. Don't access.
>
> 2. It is ZONE_DEVICE memory with a valid memmap. Access it.
>
> 3. It is ZONE_DEVICE memory with an invalid memmap, because the section
> is only partially present: E.g., device starts at offset 64MB within a
> section or the device ends at offset 64MB within a section. Don't access it.
I don't agree with case #3. In the case, struct page area is not allocated on
ZONE_DEVICE, but is allocated on system memory. So I think we can access the
struct pages. What do you mean "invalid memmap"?
>
> 4. It is ZONE_DEVICE memory with an invalid memmap, because the memmap
> was not initialized yet. memmap_init_zone_device() did not yet succeed
> after dropping the mem_hotplug lock in mm/memremap.c. Don't access it.
>
> 5. It is reserved ZONE_DEVICE memory ("pages mapped, but reserved for
> driver") with an invalid memmap. Don't access it.
>
> I can see that your patch tries to make #5 vanish by initializing the
> memmap, fair enough. #3 and #4 can't be detected. The PFN walker could
> still stumble over uninitialized memmaps.
>
[PATCH] staging: comedi: drivers: prevent memory leak
In das1800_attach, the buffer allocated via kmalloc_array needs to be
released if an error happens.
Signed-off-by: Navid Emamdoost
---
drivers/staging/comedi/drivers/das1800.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/das1800.c
b/drivers/staging/comedi/drivers/das1800.c
index f16aa7e9f4f3..5f2d5f7a6229 100644
--- a/drivers/staging/comedi/drivers/das1800.c
+++ b/drivers/staging/comedi/drivers/das1800.c
@@ -1237,12 +1237,16 @@ static int das1800_attach(struct comedi_device *dev,
dev->pacer = comedi_8254_init(dev->iobase + DAS1800_COUNTER,
I8254_OSC_BASE_5MHZ, I8254_IO8, 0);
- if (!dev->pacer)
+ if (!dev->pacer) {
+ kfree(devpriv->fifo_buf);
return -ENOMEM;
+ }
ret = comedi_alloc_subdevices(dev, 4);
- if (ret)
+ if (ret) {
+ kfree(devpriv->fifo_buf);
return ret;
+ }
/*
* Analog Input subdevice
@@ -1290,8 +1294,10 @@ static int das1800_attach(struct comedi_device *dev,
s->insn_write = das1800_ao_insn_write;
ret = comedi_alloc_subdev_readback(s);
- if (ret)
+ if (ret) {
+ kfree(devpriv->fifo_buf);
return ret;
+ }
/* initialize all channels to 0V */
for (i = 0; i < s->n_chan; i++) {
--
2.17.1
Re: Re: [PATCH] connector: report comm change event when modifying /proc/pid/task/tid/comm
>(2) What prevents proc_comm_connector(p) running concurrently with itself > via the prctl()? The locking seems to be confined to set_task_comm(). To be honest, I did not consider the concurrence problem at beginning. And some comm change events may lost or are reported repeatly as follows: set name via procfs set name via prctl set_task_comm set_task_comm proc_comm_connector proc_comm_connector Comm change event belong to procfs losts and the fresh comm change belong to prctl is reported twice. Actually, there is also concurrence problem without this update as follows: set name via procfs set name via prctl set_task_comm set_task_comm proc_comm_connector Comm change event from procfs is reported instead of prctl, this may bothers user who only care the comm change via prctl. There is no matter if user only care the latest comm change otherwise, put setting name and reporting event in crtical region may be the only answer. Thanks for review. KeMeng Shi
RE: [PATCH v6 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
Hi Rafael, On Wednesday, August 21, 2019 11:16, Ran Wang wrote: > > Some user might want to go through all registered wakeup sources and doing > things accordingly. For example, SoC PM driver might need to do HW > programming to prevent powering down specific IP which wakeup source > depending on. So add this API to help walk through all registered wakeup > source > objects on that list and return them one by one. > > Signed-off-by: Ran Wang > --- > Change in v6: > - Add wakeup_source_get_star() and wakeup_source_get_stop() to > aligned > with wakeup_sources_stats_seq_start/nex/stop. How about this version, could you please give any comment? Thanks. Regards, Ran
Re: [PATCH RFC 01/14] mm: memcg: subpage charging API
On Mon, Sep 16, 2019 at 02:56:11PM +0200, Johannes Weiner wrote:
> On Thu, Sep 05, 2019 at 02:45:45PM -0700, Roman Gushchin wrote:
> > Introduce an API to charge subpage objects to the memory cgroup.
> > The API will be used by the new slab memory controller. Later it
> > can also be used to implement percpu memory accounting.
> > In both cases, a single page can be shared between multiple cgroups
> > (and in percpu case a single allocation is split over multiple pages),
> > so it's not possible to use page-based accounting.
> >
> > The implementation is based on percpu stocks. Memory cgroups are still
> > charged in pages, and the residue is stored in perpcu stock, or on the
> > memcg itself, when it's necessary to flush the stock.
>
> Did you just implement a slab allocator for page_counter to track
> memory consumed by the slab allocator?
:)
>
> > @@ -2500,8 +2577,9 @@ void mem_cgroup_handle_over_high(void)
> > }
> >
> > static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> > - unsigned int nr_pages)
> > + unsigned int amount, bool subpage)
> > {
> > + unsigned int nr_pages = subpage ? ((amount >> PAGE_SHIFT) + 1) : amount;
> > unsigned int batch = max(MEMCG_CHARGE_BATCH, nr_pages);
> > int nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
> > struct mem_cgroup *mem_over_limit;
> > @@ -2514,7 +2592,9 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t
> > gfp_mask,
> > if (mem_cgroup_is_root(memcg))
> > return 0;
> > retry:
> > - if (consume_stock(memcg, nr_pages))
> > + if (subpage && consume_subpage_stock(memcg, amount))
> > + return 0;
> > + else if (!subpage && consume_stock(memcg, nr_pages))
> > return 0;
>
> The layering here isn't clean. We have an existing per-cpu cache to
> batch-charge the page counter. Why does the new subpage allocator not
> sit on *top* of this, instead of wedged in between?
>
> I think what it should be is a try_charge_bytes() that simply gets one
> page from try_charge() and then does its byte tracking, regardless of
> how try_charge() chooses to implement its own page tracking.
>
> That would avoid the awkward @amount + @subpage multiplexing, as well
> as annotating all existing callsites of try_charge() with a
> non-descript "false" parameter.
>
> You can still reuse the stock data structures, use the lower bits of
> stock->nr_bytes for a different cgroup etc., but the charge API should
> really be separate.
Hm, I kinda like the idea, however there is a complication: for the subpage
accounting the css reference management is done in a different way, so that
all existing code should avoid changing the css refcounter. So I'd need
to pass a boolean argument anyway.
But let me try to write this down, hopefully v2 will be cleaner.
Thank you!
Re: [PATCH RFC 04/14] mm: vmstat: convert slab vmstat counter to bytes
On Mon, Sep 16, 2019 at 02:38:40PM +0200, Johannes Weiner wrote: > On Thu, Sep 05, 2019 at 02:45:48PM -0700, Roman Gushchin wrote: > > In order to prepare for per-object slab memory accounting, > > convert NR_SLAB_RECLAIMABLE and NR_SLAB_UNRECLAIMABLE vmstat > > items to bytes. > > > > To make sure that these vmstats are in bytes, rename them > > to NR_SLAB_RECLAIMABLE_B and NR_SLAB_UNRECLAIMABLE_B (similar to > > NR_KERNEL_STACK_KB). > > > > The size of slab memory shouldn't exceed 4Gb on 32-bit machines, > > so it will fit into atomic_long_t we use for vmstats. > > > > Signed-off-by: Roman Gushchin Hello Johannes! Thank you for looking into the patchset! > > Maybe a crazy idea, but instead of mixing bytes and pages, would it be > difficult to account all vmstat items in bytes internally? And provide > two general apis, byte and page based, to update and query the counts, > instead of tying the unit it to individual items? > > The vmstat_item_in_bytes() conditional shifting is pretty awkward in > code that has a recent history littered with subtle breakages. > > The translation helper node_page_state_pages() will yield garbage if > used with the page-based counters, which is another easy to misuse > interface. > > We already have many places that multiply with PAGE_SIZE to get the > stats in bytes or kb units. > > And _B/_KB suffixes are kinda clunky. > > The stats use atomic_long_t, so switching to atomic64_t doesn't make a > difference on 64-bit and is backward compatible with 32-bit. I fully agree here, that having different stats in different units adds a lot of mess to the code. But I always thought that 64-bit atomics are slow on a 32-bit machine, so it might be a noticeable performance regression. Don't you think so? I'm happy to prepare such a patch(set), only I'd prefer to keep it separately from this one. It can precede or follow the slab controller rework, either way will work. Slab controller rework is already not so small, so adding more code (and potential issues) here will only make the review more complex. > > The per-cpu batch size you have to raise from s8 either way. Yeah, tbh I don't know why those are just not unsigned long by default. Space savings are miserable here, and I don't see any other reasons. It could be even slightly faster to use a larger type. I kinda tried to keep the patchset as small as possible (at least for the RFC version), so tried to avoid any non-necessary changes. But overall using s8 or s16 here doesn't make much sense to me. > > It seems to me that would make the code and API a lot simpler and > easier to use / harder to misuse.
Re: Linux 5.3-rc8
On 16 September 2019 18:41:36 GMT-07:00, Linus Torvalds wrote: >On Mon, Sep 16, 2019 at 6:24 PM Matthew Garrett >wrote: >> >> Exactly the scenario where you want getrandom() to block, yes. > >It *would* block. Just not forever. It's already not forever - there's enough running in the background of that system that it'll unblock eventually. >And btw, the whole "generate key at boot when nothing else is going >on" is already broken, so presumably nobody actually does it. If nothing ever did this, why was getrandom() designed in a way to protect against this situation? >See why I'm saying "hypothetical"? You're doing it again. > >> >Then you have to ignore the big warning too. >> >> The big warning that's only printed in dmesg? > >Well, the patch actually made getrandom() return en error too, but you >seem more interested in the hypotheticals than in arguing actualities. If you want to be safe, terminate the process. -- Matthew Garrett | mj...@srcf.ucam.org
Re: [PATCH] mm: remove redundant assignment of entry
On Mon, Sep 16, 2019 at 10:15:16PM +0100, Will Deacon wrote: >On Sat, Sep 14, 2019 at 12:03:26AM +, Wei Yang wrote: >> On Mon, Jul 08, 2019 at 04:27:40PM +0800, Wei Yang wrote: >> >Since ptent will not be changed after previous assignment of entry, it >> >is not necessary to do the assignment again. >> > >> >> Sounds this one is lost in the time line :-) > >Don't think so -- looks like it's in linux-next [1] via akpm to me. > Ah, thanks. I may miss some message. >Will > >[1] >https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b47011719e5c05aa9dc78fe76a7e46075f422a45 -- Wei Yang Help you, Help me
Re: BUG: sleeping function called from invalid context in tcf_chain0_head_change_cb_del
On Mon, Sep 16, 2019 at 4:39 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:1609d760 Merge tag 'for-linus' of git://git.kernel.org/pub..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10236abe60
> kernel config: https://syzkaller.appspot.com/x/.config?x=ed2b148cd67382ec
> dashboard link: https://syzkaller.appspot.com/bug?extid=ac54455281db908c581e
> compiler: clang version 9.0.0 (/home/glider/llvm/clang
> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116c4b1160
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15ff270d60
>
> The bug was bisected to:
>
> commit c266f64dbfa2a970a13b0574246c0ddfec492365
> Author: Vlad Buslov
> Date: Mon Feb 11 08:55:32 2019 +
>
> net: sched: protect block state with mutex
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16e7ca6560
> final crash:https://syzkaller.appspot.com/x/report.txt?x=15e7ca6560
> console output: https://syzkaller.appspot.com/x/log.txt?x=11e7ca6560
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ac54455281db908c5...@syzkaller.appspotmail.com
> Fixes: c266f64dbfa2 ("net: sched: protect block state with mutex")
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:909
> in_atomic(): 1, irqs_disabled(): 0, pid: 9297, name: syz-executor942
> INFO: lockdep is turned off.
> Preemption disabled at:
> [] spin_lock_bh include/linux/spinlock.h:343 [inline]
> [] sch_tree_lock include/net/sch_generic.h:570 [inline]
> [] sfb_change+0x284/0xd30 net/sched/sch_sfb.c:519
> CPU: 0 PID: 9297 Comm: syz-executor942 Not tainted 5.3.0-rc8+ #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
> ___might_sleep+0x3ff/0x530 kernel/sched/core.c:6608
> __might_sleep+0x8f/0x100 kernel/sched/core.c:6561
> __mutex_lock_common+0x4e/0x2820 kernel/locking/mutex.c:909
> __mutex_lock kernel/locking/mutex.c:1077 [inline]
> mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1092
> tcf_chain0_head_change_cb_del+0x30/0x390 net/sched/cls_api.c:932
> tcf_block_put_ext+0x3d/0x2a0 net/sched/cls_api.c:1502
> tcf_block_put+0x6e/0x90 net/sched/cls_api.c:1515
> sfb_destroy+0x47/0x70 net/sched/sch_sfb.c:467
> qdisc_destroy+0x147/0x4d0 net/sched/sch_generic.c:968
> qdisc_put+0x58/0x90 net/sched/sch_generic.c:992
> sfb_change+0x52d/0xd30 net/sched/sch_sfb.c:522
I don't think we have to hold the qdisc tree lock when destroying
the old qdisc. Does the following change make sense?
diff --git a/net/sched/sch_sfb.c b/net/sched/sch_sfb.c
index 1dff8506a715..726d0fa956b1 100644
--- a/net/sched/sch_sfb.c
+++ b/net/sched/sch_sfb.c
@@ -488,7 +488,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
struct netlink_ext_ack *extack)
{
struct sfb_sched_data *q = qdisc_priv(sch);
- struct Qdisc *child;
+ struct Qdisc *child, *tmp;
struct nlattr *tb[TCA_SFB_MAX + 1];
const struct tc_sfb_qopt *ctl = _default_ops;
u32 limit;
@@ -519,7 +519,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
sch_tree_lock(sch);
qdisc_tree_flush_backlog(q->qdisc);
- qdisc_put(q->qdisc);
+ tmp = q->qdisc;
q->qdisc = child;
q->rehash_interval = msecs_to_jiffies(ctl->rehash_interval);
@@ -543,6 +543,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
sch_tree_unlock(sch);
+ qdisc_put(tmp);
return 0;
}
What do you think, Vlad?
Re: [PATCH v4 9/9] hugetlb_cgroup: Add hugetlb_cgroup reservation docs
On 9/10/19 5:31 PM, Mina Almasry wrote: Add docs for how to use hugetlb_cgroup reservations, and their behavior. Signed-off-by: Mina Almasry Acked-by: Hillf Danton --- .../admin-guide/cgroup-v1/hugetlb.rst | 84 --- 1 file changed, 73 insertions(+), 11 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v1/hugetlb.rst b/Documentation/admin-guide/cgroup-v1/hugetlb.rst index a3902aa253a96..cc6eb859fc722 100644 --- a/Documentation/admin-guide/cgroup-v1/hugetlb.rst +++ b/Documentation/admin-guide/cgroup-v1/hugetlb.rst @@ -2,13 +2,6 @@ HugeTLB Controller == -The HugeTLB controller allows to limit the HugeTLB usage per control group and -enforces the controller limit during page fault. Since HugeTLB doesn't -support page reclaim, enforcing the limit at page fault time implies that, -the application will get SIGBUS signal if it tries to access HugeTLB pages -beyond its limit. This requires the application to know beforehand how much -HugeTLB pages it would require for its use. - HugeTLB controller can be created by first mounting the cgroup filesystem. # mount -t cgroup -o hugetlb none /sys/fs/cgroup @@ -28,10 +21,14 @@ process (bash) into it. Brief summary of control files:: - hugetlb..limit_in_bytes # set/show limit of "hugepagesize" hugetlb usage - hugetlb..max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded - hugetlb..usage_in_bytes # show current usage for "hugepagesize" hugetlb - hugetlb..failcnt # show the number of allocation failure due to HugeTLB limit + hugetlb..reservation_limit_in_bytes # set/show limit of "hugepagesize" hugetlb reservations + hugetlb..reservation_max_usage_in_bytes # show max "hugepagesize" hugetlb reservations recorded + hugetlb..reservation_usage_in_bytes # show current reservations for "hugepagesize" hugetlb + hugetlb..reservation_failcnt# show the number of allocation failure due to HugeTLB reservation limit + hugetlb..limit_in_bytes # set/show limit of "hugepagesize" hugetlb faults + hugetlb..max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded + hugetlb..usage_in_bytes # show current usage for "hugepagesize" hugetlb + hugetlb..failcnt# show the number of allocation failure due to HugeTLB usage limit For a system supporting three hugepage sizes (64k, 32M and 1G), the control files include:: @@ -40,11 +37,76 @@ files include:: hugetlb.1GB.max_usage_in_bytes hugetlb.1GB.usage_in_bytes hugetlb.1GB.failcnt + hugetlb.1GB.reservation_limit_in_bytes + hugetlb.1GB.reservation_max_usage_in_bytes + hugetlb.1GB.reservation_usage_in_bytes + hugetlb.1GB.reservation_failcnt hugetlb.64KB.limit_in_bytes hugetlb.64KB.max_usage_in_bytes hugetlb.64KB.usage_in_bytes hugetlb.64KB.failcnt + hugetlb.64KB.reservation_limit_in_bytes + hugetlb.64KB.reservation_max_usage_in_bytes + hugetlb.64KB.reservation_usage_in_bytes + hugetlb.64KB.reservation_failcnt hugetlb.32MB.limit_in_bytes hugetlb.32MB.max_usage_in_bytes hugetlb.32MB.usage_in_bytes hugetlb.32MB.failcnt + hugetlb.32MB.reservation_limit_in_bytes + hugetlb.32MB.reservation_max_usage_in_bytes + hugetlb.32MB.reservation_usage_in_bytes + hugetlb.32MB.reservation_failcnt + + +1. Reservation limits + +The HugeTLB controller allows to limit the HugeTLB reservations per control +group and enforces the controller limit at reservation time. Reservation limits +are superior to Page fault limits (see section 2), since Reservation limits are +enforced at reservation time, and never causes the application to get SIGBUS +signal. Instead, if the application is violating its limits, then it gets an +error on reservation time, i.e. the mmap or shmget return an error. + + +2. Page fault limits + +The HugeTLB controller allows to limit the HugeTLB usage (page fault) per +control group and enforces the controller limit during page fault. Since HugeTLB +doesn't support page reclaim, enforcing the limit at page fault time implies +that, the application will get SIGBUS signal if it tries to access HugeTLB +pages beyond its limit. This requires the application to know beforehand how +much HugeTLB pages it would require for its use. + + +3. Caveats with shared memory + +a. Charging and uncharging: + +For shared hugetlb memory, both hugetlb reservation and usage (page faults) are +charged to the first task that causes the memory to be reserved or faulted, +and all subsequent uses of this reserved or faulted memory is done without +charging. + +Shared hugetlb memory is only uncharged when it is unreseved or deallocated. Spelling? +This is usually when the hugetlbfs file is deleted, and not when the task that +caused the reservation or fault has exited. + +b. Interaction between reservation limit and fault limit. + +Generally, it's not recommended to set both of the reservation limit and
Re: [PATCH v4 8/9] hugetlb_cgroup: Add hugetlb_cgroup reservation tests
On 9/10/19 5:31 PM, Mina Almasry wrote:
The tests use both shared and private mapped hugetlb memory, and
monitors the hugetlb usage counter as well as the hugetlb reservation
counter. They test different configurations such as hugetlb memory usage
via hugetlbfs, or MAP_HUGETLB, or shmget/shmat, and with and without
MAP_POPULATE.
Signed-off-by: Mina Almasry
---
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 4 +
.../selftests/vm/charge_reserved_hugetlb.sh | 440 ++
.../selftests/vm/write_hugetlb_memory.sh | 22 +
.../testing/selftests/vm/write_to_hugetlbfs.c | 252 ++
5 files changed, 719 insertions(+)
create mode 100755 tools/testing/selftests/vm/charge_reserved_hugetlb.sh
create mode 100644 tools/testing/selftests/vm/write_hugetlb_memory.sh
create mode 100644 tools/testing/selftests/vm/write_to_hugetlbfs.c
diff --git a/tools/testing/selftests/vm/.gitignore
b/tools/testing/selftests/vm/.gitignore
index 31b3c98b6d34d..d3bed9407773c 100644
--- a/tools/testing/selftests/vm/.gitignore
+++ b/tools/testing/selftests/vm/.gitignore
@@ -14,3 +14,4 @@ virtual_address_range
gup_benchmark
va_128TBswitch
map_fixed_noreplace
+write_to_hugetlbfs
diff --git a/tools/testing/selftests/vm/Makefile
b/tools/testing/selftests/vm/Makefile
index 9534dc2bc9295..8d37d5409b52c 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -18,6 +18,7 @@ TEST_GEN_FILES += transhuge-stress
TEST_GEN_FILES += userfaultfd
TEST_GEN_FILES += va_128TBswitch
TEST_GEN_FILES += virtual_address_range
+TEST_GEN_FILES += write_to_hugetlbfs
TEST_PROGS := run_vmtests
@@ -29,3 +30,6 @@ include ../lib.mk
$(OUTPUT)/userfaultfd: LDLIBS += -lpthread
$(OUTPUT)/mlock-random-test: LDLIBS += -lcap
+
+# Why does adding $(OUTPUT)/ like above not apply this flag..?
Can you verify the following and remove this comment, once you figure
out if you need $(OUTPUT)/
+write_to_hugetlbfs: CFLAGS += -static
It should. Did you test "make O=" and "KBUILD_OUTPUT" kselftest
use-cases?
diff --git a/tools/testing/selftests/vm/charge_reserved_hugetlb.sh
b/tools/testing/selftests/vm/charge_reserved_hugetlb.sh
new file mode 100755
index 0..09e90e8f6fab4
--- /dev/null
+++ b/tools/testing/selftests/vm/charge_reserved_hugetlb.sh
@@ -0,0 +1,440 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+set -e
+
+cgroup_path=/dev/cgroup/memory
+if [[ ! -e $cgroup_path ]]; then
+ mkdir -p $cgroup_path
+ mount -t cgroup -o hugetlb,memory cgroup $cgroup_path
+fi
+
Does this test need root access? If yes, please add root check
and skip the test when a non-root runs the test.
+cleanup () {
+ echo $$ > $cgroup_path/tasks
+
+ set +e
+ if [[ "$(pgrep write_to_hugetlbfs)" != "" ]]; then
+ kill -2 write_to_hugetlbfs
+ # Wait for hugetlbfs memory to get depleted.
+ sleep 0.5
This time looks arbitrary. How can you be sure it gets depleted?
Is there another way to check for it.
+ fi
+ set -e
+
+ if [[ -e /mnt/huge ]]; then
+ rm -rf /mnt/huge/*
+ umount /mnt/huge || echo error
+ rmdir /mnt/huge
+ fi
+ if [[ -e $cgroup_path/hugetlb_cgroup_test ]]; then
+ rmdir $cgroup_path/hugetlb_cgroup_test
+ fi
+ if [[ -e $cgroup_path/hugetlb_cgroup_test1 ]]; then
+ rmdir $cgroup_path/hugetlb_cgroup_test1
+ fi
+ if [[ -e $cgroup_path/hugetlb_cgroup_test2 ]]; then
+ rmdir $cgroup_path/hugetlb_cgroup_test2
+ fi
+ echo 0 > /proc/sys/vm/nr_hugepages
+ echo CLEANUP DONE
+}
+
+cleanup
+
+function expect_equal() {
+ local expected="$1"
+ local actual="$2"
+ local error="$3"
+
+ if [[ "$expected" != "$actual" ]]; then
+ echo "expected ($expected) != actual ($actual): $3"
+ cleanup
+ exit 1
+ fi
+}
+
+function setup_cgroup() {
+ local name="$1"
+ local cgroup_limit="$2"
+ local reservation_limit="$3"
+
+ mkdir $cgroup_path/$name
+
+ echo writing cgroup limit: "$cgroup_limit"
+ echo "$cgroup_limit" > $cgroup_path/$name/hugetlb.2MB.limit_in_bytes
+
+ echo writing reseravation limit: "$reservation_limit"
+ echo "$reservation_limit" > \
+ $cgroup_path/$name/hugetlb.2MB.reservation_limit_in_bytes
+ echo 0 > $cgroup_path/$name/cpuset.cpus
+ echo 0 > $cgroup_path/$name/cpuset.mems
+}
+
+function write_hugetlbfs_and_get_usage() {
+ local cgroup="$1"
+ local size="$2"
+ local populate="$3"
+ local write="$4"
+ local path="$5"
+ local method="$6"
+ local private="$7"
+ local expect_failure="$8"
+
+ # Function return values.
+ reservation_failed=0
+ oom_killed=0
+ hugetlb_difference=0
+ reserved_difference=0
+
+ local
Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen wrote: > > On 8/12/19 10:32 AM, Kalle Valo wrote: > >> Signed-off-by: Jes Sorensen > > > > This is marked as RFC so I'm not sure what's the plan. Should I apply > > this? > > I think it's at a point where it's worth applying - I kinda wish I had > had time to test it, but I won't be near my stash of USB dongles for a > little while. > > Cheers, > Jes > Gentle ping. Any suggestions for the next step? Chris
[PATCH 5/5] ocxl: Provide additional metadata to userspace
From: Alastair D'Silva
This patch exposes the OpenCAPI device serial number to
userspace.
It also includes placeholders for the LPC & special purpose
memory information (which will be populated in a subsequent patch)
to avoid creating excessive versions of the IOCTL.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c | 46 ++
drivers/misc/ocxl/file.c | 3 ++-
include/misc/ocxl.h| 1 +
include/uapi/misc/ocxl.h | 9 +++-
4 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index fb0c3b6f8312..a9203c309365 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -71,6 +71,51 @@ static int find_dvsec_afu_ctrl(struct pci_dev *dev, u8
afu_idx)
return 0;
}
+/**
+ * Find a related PCI device (function 0)
+ * @device: PCI device to match
+ *
+ * Returns a pointer to the related device, or null if not found
+ */
+static struct pci_dev *get_function_0(struct pci_dev *dev)
+{
+ unsigned int devfn = PCI_DEVFN(PCI_SLOT(dev->devfn), 0); // Look for
function 0
+
+ return pci_get_domain_bus_and_slot(pci_domain_nr(dev->bus),
+ dev->bus->number, devfn);
+}
+
+static void read_serial(struct pci_dev *dev, struct ocxl_fn_config *fn)
+{
+ u32 low, high;
+ int pos;
+
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DSN);
+ if (pos) {
+ pci_read_config_dword(dev, pos + 0x04, );
+ pci_read_config_dword(dev, pos + 0x08, );
+
+ fn->serial = low | ((u64)high) << 32;
+
+ return;
+ }
+
+ if (PCI_FUNC(dev->devfn) != 0) {
+ struct pci_dev *related = get_function_0(dev);
+
+ if (!related) {
+ fn->serial = 0;
+ return;
+ }
+
+ read_serial(related, fn);
+ pci_dev_put(related);
+ return;
+ }
+
+ fn->serial = 0;
+}
+
static void read_pasid(struct pci_dev *dev, struct ocxl_fn_config *fn)
{
u16 val;
@@ -208,6 +253,7 @@ int ocxl_config_read_function(struct pci_dev *dev, struct
ocxl_fn_config *fn)
int rc;
read_pasid(dev, fn);
+ read_serial(dev, fn);
rc = read_dvsec_tl(dev, fn);
if (rc) {
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 2870c25da166..08f6f594a11d 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -98,13 +98,14 @@ static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
memset(, 0, sizeof(arg));
- arg.version = 0;
+ arg.version = 1;
arg.afu_version_major = ctx->afu->config.version_major;
arg.afu_version_minor = ctx->afu->config.version_minor;
arg.pasid = ctx->pasid;
arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
arg.global_mmio_size = ctx->afu->config.global_mmio_size;
+ arg.serial = ctx->afu->fn->config.serial;
if (copy_to_user(uarg, , sizeof(arg)))
return -EFAULT;
diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
index a1897737908d..da75db149e6c 100644
--- a/include/misc/ocxl.h
+++ b/include/misc/ocxl.h
@@ -46,6 +46,7 @@ struct ocxl_fn_config {
int dvsec_afu_info_pos; /* offset of the AFU information DVSEC */
s8 max_pasid_log;
s8 max_afu_index;
+ u64 serial;
};
enum ocxl_endian {
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 6d29a60a896a..d4c6bf10580c 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -45,7 +45,14 @@ struct ocxl_ioctl_metadata {
/* End version 0 fields */
- __u64 reserved[13]; /* Total of 16*u64 */
+ // Version 1 fields
+ __u64 lpc_mem_size;
+ __u64 special_purpose_mem_size;
+ __u64 serial; // Device serial number
+
+ // End version 1 fields
+
+ __u64 reserved[10]; // Total of 16*u64
};
struct ocxl_ioctl_p9_wait {
--
2.21.0
[PATCH 4/5] ocxl: Add functions to map/unmap LPC memory
From: Alastair D'Silva
Add functions to map/unmap LPC memory
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c| 4 +++
drivers/misc/ocxl/core.c | 50 +++
drivers/misc/ocxl/link.c | 4 +--
drivers/misc/ocxl/ocxl_internal.h | 10 +--
include/misc/ocxl.h | 18 +++
5 files changed, 82 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index c8e19bfb5ef9..fb0c3b6f8312 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -568,6 +568,10 @@ static int read_afu_lpc_memory_info(struct pci_dev *dev,
afu->special_purpose_mem_size =
total_mem_size - lpc_mem_size;
}
+
+ dev_info(>dev, "Probed LPC memory of %#llx bytes and special
purpose memory of %#llx bytes\n",
+ afu->lpc_mem_size, afu->special_purpose_mem_size);
+
return 0;
}
diff --git a/drivers/misc/ocxl/core.c b/drivers/misc/ocxl/core.c
index fdfe4e0a34e1..eb24bb9d655f 100644
--- a/drivers/misc/ocxl/core.c
+++ b/drivers/misc/ocxl/core.c
@@ -210,6 +210,55 @@ static void unmap_mmio_areas(struct ocxl_afu *afu)
release_fn_bar(afu->fn, afu->config.global_mmio_bar);
}
+int ocxl_map_lpc_mem(struct ocxl_afu *afu)
+{
+ struct pci_dev *dev = to_pci_dev(afu->fn->dev.parent);
+
+ if ((afu->config.lpc_mem_size + afu->config.special_purpose_mem_size)
== 0)
+ return 0;
+
+ afu->lpc_base_addr = ocxl_link_lpc_online(afu->fn->link, dev);
+ if (afu->lpc_base_addr == 0)
+ return -EINVAL;
+
+ if (afu->config.lpc_mem_size) {
+ afu->lpc_res.start = afu->lpc_base_addr +
afu->config.lpc_mem_offset;
+ afu->lpc_res.end = afu->lpc_res.start +
afu->config.lpc_mem_size - 1;
+ }
+
+ if (afu->config.special_purpose_mem_size) {
+ afu->special_purpose_res.start = afu->lpc_base_addr +
+
afu->config.special_purpose_mem_offset;
+ afu->special_purpose_res.end = afu->special_purpose_res.start +
+
afu->config.special_purpose_mem_size - 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(ocxl_map_lpc_mem);
+
+struct resource *ocxl_afu_lpc_mem(struct ocxl_afu *afu)
+{
+ return >lpc_res;
+}
+EXPORT_SYMBOL(ocxl_afu_lpc_mem);
+
+static void unmap_lpc_mem(struct ocxl_afu *afu)
+{
+ struct pci_dev *dev = to_pci_dev(afu->fn->dev.parent);
+
+ if (afu->lpc_res.start || afu->special_purpose_res.start) {
+ void *link = afu->fn->link;
+
+ ocxl_link_lpc_offline(link, dev);
+
+ afu->lpc_res.start = 0;
+ afu->lpc_res.end = 0;
+ afu->special_purpose_res.start = 0;
+ afu->special_purpose_res.end = 0;
+ }
+}
+
static int configure_afu(struct ocxl_afu *afu, u8 afu_idx, struct pci_dev *dev)
{
int rc;
@@ -250,6 +299,7 @@ static int configure_afu(struct ocxl_afu *afu, u8 afu_idx,
struct pci_dev *dev)
static void deconfigure_afu(struct ocxl_afu *afu)
{
+ unmap_lpc_mem(afu);
unmap_mmio_areas(afu);
reclaim_afu_pasid(afu);
reclaim_afu_actag(afu);
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 2874811a4398..9e303a5f4d85 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -738,7 +738,7 @@ int ocxl_link_add_lpc_mem(void *link_handle, u64 size)
}
EXPORT_SYMBOL_GPL(ocxl_link_add_lpc_mem);
-u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev *pdev)
+u64 ocxl_link_lpc_online(void *link_handle, struct pci_dev *pdev)
{
struct ocxl_link *link = (struct ocxl_link *) link_handle;
@@ -759,7 +759,7 @@ u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev
*pdev)
return link->lpc_mem;
}
-void ocxl_link_lpc_release(void *link_handle, struct pci_dev *pdev)
+void ocxl_link_lpc_offline(void *link_handle, struct pci_dev *pdev)
{
struct ocxl_link *link = (struct ocxl_link *) link_handle;
diff --git a/drivers/misc/ocxl/ocxl_internal.h
b/drivers/misc/ocxl/ocxl_internal.h
index db2647a90fc8..5656a4aab5b7 100644
--- a/drivers/misc/ocxl/ocxl_internal.h
+++ b/drivers/misc/ocxl/ocxl_internal.h
@@ -52,6 +52,12 @@ struct ocxl_afu {
void __iomem *global_mmio_ptr;
u64 pp_mmio_start;
void *private;
+ u64 lpc_base_addr; /* Covers both LPC & special purpose memory */
+ struct bin_attribute attr_global_mmio;
+ struct bin_attribute attr_lpc_mem;
+ struct resource lpc_res;
+ struct bin_attribute attr_special_purpose_mem;
+ struct resource special_purpose_res;
};
enum ocxl_context_status {
@@ -170,7 +176,7 @@ extern u64 ocxl_link_get_lpc_mem_sz(void *link_handle);
* @link_handle: The OpenCAPI link handle
* @pdev: A device that is on the link
*/
-u64 ocxl_link_lpc_map(void *link_handle,
[PATCH 2/5] powerpc: Map & release OpenCAPI LPC memory
From: Alastair D'Silva
Map & release OpenCAPI LPC memory.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/pnv-ocxl.h | 2 ++
arch/powerpc/platforms/powernv/ocxl.c | 42 +++
2 files changed, 44 insertions(+)
diff --git a/arch/powerpc/include/asm/pnv-ocxl.h
b/arch/powerpc/include/asm/pnv-ocxl.h
index 7de82647e761..f8f8ffb48aa8 100644
--- a/arch/powerpc/include/asm/pnv-ocxl.h
+++ b/arch/powerpc/include/asm/pnv-ocxl.h
@@ -32,5 +32,7 @@ extern int pnv_ocxl_spa_remove_pe_from_cache(void
*platform_data, int pe_handle)
extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr);
extern void pnv_ocxl_free_xive_irq(u32 irq);
+extern u64 pnv_ocxl_platform_lpc_setup(struct pci_dev *pdev, u64 size);
+extern void pnv_ocxl_platform_lpc_release(struct pci_dev *pdev);
#endif /* _ASM_PNV_OCXL_H */
diff --git a/arch/powerpc/platforms/powernv/ocxl.c
b/arch/powerpc/platforms/powernv/ocxl.c
index 8c65aacda9c8..81393728d6a3 100644
--- a/arch/powerpc/platforms/powernv/ocxl.c
+++ b/arch/powerpc/platforms/powernv/ocxl.c
@@ -475,6 +475,48 @@ void pnv_ocxl_spa_release(void *platform_data)
}
EXPORT_SYMBOL_GPL(pnv_ocxl_spa_release);
+u64 pnv_ocxl_platform_lpc_setup(struct pci_dev *pdev, u64 size)
+{
+ struct pci_controller *hose = pci_bus_to_host(pdev->bus);
+ struct pnv_phb *phb = hose->private_data;
+ struct pci_dn *pdn = pci_get_pdn(pdev);
+ u32 bdfn = (pdn->busno << 8) | pdn->devfn;
+ u64 base_addr = 0;
+
+ int rc = opal_npu_mem_alloc(phb->opal_id, bdfn, size, _addr);
+
+ WARN_ON(rc);
+
+ base_addr = be64_to_cpu(base_addr);
+
+ rc = check_hotplug_memory_addressable(base_addr, base_addr + size);
+ if (rc) {
+ dev_warn(>dev,
+"LPC memory range 0x%llx-0x%llx is not fully
addressable",
+base_addr, base_addr + size - 1);
+ return 0;
+ }
+
+
+ return base_addr;
+}
+EXPORT_SYMBOL_GPL(pnv_ocxl_platform_lpc_setup);
+
+void pnv_ocxl_platform_lpc_release(struct pci_dev *pdev)
+{
+ struct pci_controller *hose = pci_bus_to_host(pdev->bus);
+ struct pnv_phb *phb = hose->private_data;
+ struct pci_dn *pdn = pci_get_pdn(pdev);
+ u32 bdfn;
+ int rc;
+
+ bdfn = (pdn->busno << 8) | pdn->devfn;
+ rc = opal_npu_mem_release(phb->opal_id, bdfn);
+ WARN_ON(rc);
+}
+EXPORT_SYMBOL_GPL(pnv_ocxl_platform_lpc_release);
+
+
int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle)
{
struct spa_data *data = (struct spa_data *) platform_data;
--
2.21.0
[PATCH 1/5] powerpc: Add OPAL calls for LPC memory alloc/release
From: Alastair D'Silva Add OPAL calls for LPC memory alloc/release Signed-off-by: Alastair D'Silva --- arch/powerpc/include/asm/opal-api.h| 4 +++- arch/powerpc/include/asm/opal.h| 3 +++ arch/powerpc/platforms/powernv/opal-call.c | 2 ++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h index 383242eb0dea..c58161cd7cfb 100644 --- a/arch/powerpc/include/asm/opal-api.h +++ b/arch/powerpc/include/asm/opal-api.h @@ -208,7 +208,9 @@ #define OPAL_HANDLE_HMI2 166 #defineOPAL_NX_COPROC_INIT 167 #define OPAL_XIVE_GET_VP_STATE 170 -#define OPAL_LAST 170 +#define OPAL_NPU_MEM_ALLOC 171 +#define OPAL_NPU_MEM_RELEASE 172 +#define OPAL_LAST 172 #define QUIESCE_HOLD 1 /* Spin all calls at entry */ #define QUIESCE_REJECT 2 /* Fail all calls with OPAL_BUSY */ diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h index 57bd029c715e..8c957a003be4 100644 --- a/arch/powerpc/include/asm/opal.h +++ b/arch/powerpc/include/asm/opal.h @@ -39,6 +39,9 @@ int64_t opal_npu_spa_clear_cache(uint64_t phb_id, uint32_t bdfn, uint64_t PE_handle); int64_t opal_npu_tl_set(uint64_t phb_id, uint32_t bdfn, long cap, uint64_t rate_phys, uint32_t size); +int64_t opal_npu_mem_alloc(uint64_t phb_id, uint32_t bdfn, + uint64_t size, uint64_t *bar); +int64_t opal_npu_mem_release(uint64_t phb_id, uint32_t bdfn); int64_t opal_console_write(int64_t term_number, __be64 *length, const uint8_t *buffer); int64_t opal_console_read(int64_t term_number, __be64 *length, diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c index 29ca523c1c79..09a280446507 100644 --- a/arch/powerpc/platforms/powernv/opal-call.c +++ b/arch/powerpc/platforms/powernv/opal-call.c @@ -287,3 +287,5 @@ OPAL_CALL(opal_pci_set_pbcq_tunnel_bar, OPAL_PCI_SET_PBCQ_TUNNEL_BAR); OPAL_CALL(opal_sensor_read_u64,OPAL_SENSOR_READ_U64); OPAL_CALL(opal_sensor_group_enable,OPAL_SENSOR_GROUP_ENABLE); OPAL_CALL(opal_nx_coproc_init, OPAL_NX_COPROC_INIT); +OPAL_CALL(opal_npu_mem_alloc, OPAL_NPU_MEM_ALLOC); +OPAL_CALL(opal_npu_mem_release,OPAL_NPU_MEM_RELEASE); -- 2.21.0
[PATCH 3/5] ocxl: Tally up the LPC memory on a link & allow it to be mapped
From: Alastair D'Silva
Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/core.c | 9 +
drivers/misc/ocxl/link.c | 61 +++
drivers/misc/ocxl/ocxl_internal.h | 42 +
3 files changed, 112 insertions(+)
diff --git a/drivers/misc/ocxl/core.c b/drivers/misc/ocxl/core.c
index b7a09b21ab36..fdfe4e0a34e1 100644
--- a/drivers/misc/ocxl/core.c
+++ b/drivers/misc/ocxl/core.c
@@ -230,8 +230,17 @@ static int configure_afu(struct ocxl_afu *afu, u8 afu_idx,
struct pci_dev *dev)
if (rc)
goto err_free_pasid;
+ if (afu->config.lpc_mem_size || afu->config.special_purpose_mem_size) {
+ rc = ocxl_link_add_lpc_mem(afu->fn->link,
+ afu->config.lpc_mem_size +
afu->config.special_purpose_mem_size);
+ if (rc)
+ goto err_free_mmio;
+ }
+
return 0;
+err_free_mmio:
+ unmap_mmio_areas(afu);
err_free_pasid:
reclaim_afu_pasid(afu);
err_free_actag:
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 58d111afd9f6..2874811a4398 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -84,6 +84,11 @@ struct ocxl_link {
int dev;
atomic_t irq_available;
struct spa *spa;
+ struct mutex lpc_mem_lock;
+ u64 lpc_mem_sz; /* Total amount of LPC memory presented on the link */
+ u64 lpc_mem;
+ int lpc_consumers;
+
void *platform_data;
};
static struct list_head links_list = LIST_HEAD_INIT(links_list);
@@ -396,6 +401,8 @@ static int alloc_link(struct pci_dev *dev, int PE_mask,
struct ocxl_link **out_l
if (rc)
goto err_spa;
+ mutex_init(>lpc_mem_lock);
+
/* platform specific hook */
rc = pnv_ocxl_spa_setup(dev, link->spa->spa_mem, PE_mask,
>platform_data);
@@ -711,3 +718,57 @@ void ocxl_link_free_irq(void *link_handle, int hw_irq)
atomic_inc(>irq_available);
}
EXPORT_SYMBOL_GPL(ocxl_link_free_irq);
+
+int ocxl_link_add_lpc_mem(void *link_handle, u64 size)
+{
+ struct ocxl_link *link = (struct ocxl_link *) link_handle;
+
+ u64 orig_size;
+ bool good = false;
+
+ mutex_lock(>lpc_mem_lock);
+ orig_size = link->lpc_mem_sz;
+ link->lpc_mem_sz += size;
+
+ good = orig_size < link->lpc_mem_sz;
+ mutex_unlock(>lpc_mem_lock);
+
+ // Check for overflow
+ return (good) ? 0 : -EINVAL;
+}
+EXPORT_SYMBOL_GPL(ocxl_link_add_lpc_mem);
+
+u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev *pdev)
+{
+ struct ocxl_link *link = (struct ocxl_link *) link_handle;
+
+ mutex_lock(>lpc_mem_lock);
+ if (link->lpc_mem) {
+ u64 lpc_mem = link->lpc_mem;
+
+ link->lpc_consumers++;
+ mutex_unlock(>lpc_mem_lock);
+ return lpc_mem;
+ }
+
+ link->lpc_mem = pnv_ocxl_platform_lpc_setup(pdev, link->lpc_mem_sz);
+ if (link->lpc_mem)
+ link->lpc_consumers++;
+ mutex_unlock(>lpc_mem_lock);
+
+ return link->lpc_mem;
+}
+
+void ocxl_link_lpc_release(void *link_handle, struct pci_dev *pdev)
+{
+ struct ocxl_link *link = (struct ocxl_link *) link_handle;
+
+ mutex_lock(>lpc_mem_lock);
+ link->lpc_consumers--;
+ if (link->lpc_consumers == 0) {
+ pnv_ocxl_platform_lpc_release(pdev);
+ link->lpc_mem = 0;
+ }
+
+ mutex_unlock(>lpc_mem_lock);
+}
diff --git a/drivers/misc/ocxl/ocxl_internal.h
b/drivers/misc/ocxl/ocxl_internal.h
index 97415afd79f3..db2647a90fc8 100644
--- a/drivers/misc/ocxl/ocxl_internal.h
+++ b/drivers/misc/ocxl/ocxl_internal.h
@@ -141,4 +141,46 @@ int ocxl_irq_offset_to_id(struct ocxl_context *ctx, u64
offset);
u64 ocxl_irq_id_to_offset(struct ocxl_context *ctx, int irq_id);
void ocxl_afu_irq_free_all(struct ocxl_context *ctx);
+/**
+ * Increment the amount of memory required by an OpenCAPI link
+ *
+ * link_handle: The OpenCAPI link handle
+ * size: The amount of memory to increment by
+ *
+ * Return 0 on success, negative on overflow
+ */
+extern int ocxl_link_add_lpc_mem(void *link_handle, u64 size);
+
+/**
+ * Get the amount of memory required by an OpenCAPI link
+ *
+ * link_handle: The OpenCAPI link handle
+ *
+ * Return the amount of memory required by the link, this value is undefined if
+ * ocxl_link_add_lpc_mem failed.
+ */
+extern u64 ocxl_link_get_lpc_mem_sz(void *link_handle);
+
+/**
+ * Map the LPC memory for an OpenCAPI device
+ *
+ * Since LPC memory belongs to a link, the whole LPC memory available
+ * on the link bust be mapped in order to make it accessible to a device.
+ *
+ * @link_handle: The OpenCAPI link handle
+ * @pdev: A device that is on the link
+ */
+u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev *pdev);
+
+/**
+ * Release the LPC
[PATCH 0/5] ocxl: Allow external drivers to access LPC memory
From: Alastair D'Silva This series provides the prerequisite infrastructure to allow external drivers to map & access OpenCAPI LPC memory. Alastair D'Silva (5): powerpc: Add OPAL calls for LPC memory alloc/release powerpc: Map & release OpenCAPI LPC memory ocxl: Tally up the LPC memory on a link & allow it to be mapped ocxl: Add functions to map/unmap LPC memory ocxl: Provide additional metadata to userspace arch/powerpc/include/asm/opal-api.h| 4 +- arch/powerpc/include/asm/opal.h| 3 ++ arch/powerpc/include/asm/pnv-ocxl.h| 2 + arch/powerpc/platforms/powernv/ocxl.c | 42 +++ arch/powerpc/platforms/powernv/opal-call.c | 2 + drivers/misc/ocxl/config.c | 50 ++ drivers/misc/ocxl/core.c | 59 + drivers/misc/ocxl/file.c | 3 +- drivers/misc/ocxl/link.c | 61 ++ drivers/misc/ocxl/ocxl_internal.h | 48 + include/misc/ocxl.h| 19 +++ include/uapi/misc/ocxl.h | 9 +++- 12 files changed, 299 insertions(+), 3 deletions(-) -- 2.21.0
Re: [PATCH] quota: fix wrong condition in is_quota_modification()
On 2019/9/16 16:23, Jan Kara wrote:
> On Mon 16-09-19 10:53:08, Chao Yu wrote:
>> On 2019/9/12 18:06, Jan Kara wrote:
>>> On Wed 11-09-19 17:36:50, Chao Yu wrote:
diff --git a/include/linux/quotaops.h b/include/linux/quotaops.h
index dc905a4ff8d7..bd30acad3a7f 100644
--- a/include/linux/quotaops.h
+++ b/include/linux/quotaops.h
@@ -22,7 +22,7 @@ static inline struct quota_info *sb_dqopt(struct
super_block *sb)
/* i_mutex must being held */
static inline bool is_quota_modification(struct inode *inode, struct
iattr *ia)
{
- return (ia->ia_valid & ATTR_SIZE && ia->ia_size != inode->i_size) ||
+ return (ia->ia_valid & ATTR_SIZE && ia->ia_size <= inode->i_size) ||
(ia->ia_valid & ATTR_UID && !uid_eq(ia->ia_uid, inode->i_uid))
||
(ia->ia_valid & ATTR_GID && !gid_eq(ia->ia_gid, inode->i_gid));
}
>>>
>>> OK, but your change makes i_size extension not to be quota modification
>>
>> I just try to adapt below rules covered with generic/092, which restrict
>> to not trim preallocate blocks beyond i_size, in that case, filesystem
>> won't change i_blocks.
>>
>> 1) truncate(i_size) will trim all blocks past i_size.
>> 2) truncate(x) where x > i_size will not trim all blocks past i_size.
>
> Ah, OK.
>
>> However, I'm okay with your change, because there could be filesystems won't
>> follow above rule.
>
> Yes, I'm concerned that some filesystem may change i_blocks in some corner
> case when growing inode size (e.g. when it decides to convert inode from
> inline format to a normal block based format or something like that). So I
> don't think the optimization is really worth the chance for breakage.
Agreed, :)
Thanks,
>
> Honza
>
Re: Linux 5.3-rc8
On Mon, Sep 16, 2019 at 6:24 PM Matthew Garrett wrote: > > Exactly the scenario where you want getrandom() to block, yes. It *would* block. Just not forever. And btw, the whole "generate key at boot when nothing else is going on" is already broken, so presumably nobody actually does it. See why I'm saying "hypothetical"? You're doing it again. > >Then you have to ignore the big warning too. > > The big warning that's only printed in dmesg? Well, the patch actually made getrandom() return en error too, but you seem more interested in the hypotheticals than in arguing actualities. Linus
[git pull] work.mount - infrastructure
Infrastructure bits of mount API conversions; the rest is more of per-filesystem patches and it'll go in a separate pull request. Requests, actually, since some are (thankfully) in the individual filesystem trees now (a huge NFS pile, for example). The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1: Linux 5.3-rc5 (2019-08-18 14:31:08 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.mount-base for you to fetch changes up to 0f071004109d9c8de7023b9a64fa2ba3fa87cbed: mtd: Provide fs_context-aware mount_mtd() replacement (2019-09-05 14:34:23 -0400) Al Viro (1): new helper: get_tree_keyed() David Howells (2): vfs: Create fs_context-aware mount_bdev() replacement mtd: Provide fs_context-aware mount_mtd() replacement Eric Biggers (1): vfs: set fs_context::user_ns for reconfigure drivers/mtd/mtdcore.h | 1 + drivers/mtd/mtdsuper.c | 179 - fs/fs_context.c| 4 +- fs/nfsd/nfsctl.c | 3 +- fs/proc/root.c | 3 +- fs/super.c | 104 ++ include/linux/fs_context.h | 12 ++- include/linux/mtd/super.h | 3 + ipc/mqueue.c | 3 +- net/sunrpc/rpc_pipe.c | 3 +- 10 files changed, 301 insertions(+), 14 deletions(-)
[PATCH] arch/microblaze: support get_user() of size 8 bytes
From: Randy Dunlap
arch/microblaze/ is missing support for get_user() of size 8 bytes,
so add it by using __copy_from_user().
While there, also drop a lot of the code duplication.
Fixes these build errors:
drivers/infiniband/core/uverbs_main.o: In function `ib_uverbs_write':
drivers/infiniband/core/.tmp_gl_uverbs_main.o:(.text+0x13a4): undefined
reference to `__user_bad'
drivers/android/binder.o: In function `binder_thread_write':
drivers/android/.tmp_gl_binder.o:(.text+0xda6c): undefined reference to
`__user_bad'
drivers/android/.tmp_gl_binder.o:(.text+0xda98): undefined reference to
`__user_bad'
drivers/android/.tmp_gl_binder.o:(.text+0xdf10): undefined reference to
`__user_bad'
drivers/android/.tmp_gl_binder.o:(.text+0xe498): undefined reference to
`__user_bad'
drivers/android/binder.o:drivers/android/.tmp_gl_binder.o:(.text+0xea78):
more undefined references to `__user_bad' follow
'make allmodconfig' now builds successfully for arch/microblaze/.
Fixes: 538722ca3b76 ("microblaze: fix get_user/put_user side-effects")
Reported-by: kbuild test robot
Signed-off-by: Randy Dunlap
Acked-by: Linus Torvalds
Cc: Al Viro
Cc: Steven J. Magnani
Cc: Michal Simek
Cc: Jason Gunthorpe
Cc: Leon Romanovsky
Cc: Andrew Morton
Cc: Doug Ledford
---
v4: drop code duplication (Linus).
arch/microblaze/include/asm/uaccess.h | 42 +---
1 file changed, 9 insertions(+), 33 deletions(-)
--- lnx-53.orig/arch/microblaze/include/asm/uaccess.h
+++ lnx-53/arch/microblaze/include/asm/uaccess.h
@@ -163,44 +163,15 @@ extern long __user_bad(void);
* Returns zero on success, or -EFAULT on error.
* On error, the variable @x is set to zero.
*/
-#define get_user(x, ptr) \
- __get_user_check((x), (ptr), sizeof(*(ptr)))
-
-#define __get_user_check(x, ptr, size) \
-({ \
- unsigned long __gu_val = 0; \
- const typeof(*(ptr)) __user *__gu_addr = (ptr); \
- int __gu_err = 0; \
- \
- if (access_ok(__gu_addr, size)) { \
- switch (size) { \
- case 1: \
- __get_user_asm("lbu", __gu_addr, __gu_val, \
- __gu_err); \
- break; \
- case 2: \
- __get_user_asm("lhu", __gu_addr, __gu_val, \
- __gu_err); \
- break; \
- case 4: \
- __get_user_asm("lw", __gu_addr, __gu_val, \
- __gu_err); \
- break; \
- default:\
- __gu_err = __user_bad();\
- break; \
- } \
- } else {\
- __gu_err = -EFAULT; \
- } \
- x = (__force typeof(*(ptr)))__gu_val; \
- __gu_err; \
+#define get_user(x, ptr) ({\
+ const typeof(*(ptr)) __user *__gu_ptr = (ptr); \
+ access_ok(__gu_ptr, sizeof(*__gu_ptr)) ?\
+ __get_user(x, __gu_ptr) : -EFAULT; \
})
#define __get_user(x, ptr) \
({ \
unsigned long __gu_val = 0; \
- /*unsigned long __gu_ptr = (unsigned long)(ptr);*/ \
long __gu_err; \
switch (sizeof(*(ptr))) { \
case 1: \
@@ -212,6 +183,11 @@ extern long __user_bad(void);
case 4: \
__get_user_asm("lw", (ptr), __gu_val, __gu_err);\
break;
[git pull] d_path fixup
d_absolute_path() regression in the last cycle (felt by tomoyo, mostly) The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.dcache for you to fetch changes up to f2683bd8d5bdebb929f05ae26ce6d9b578927ce5: [PATCH] fix d_absolute_path() interplay with fsmount() (2019-08-30 19:31:09 -0400) Al Viro (1): fix d_absolute_path() interplay with fsmount() fs/d_path.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
Re: [PATCH v4 2/9] hugetlb_cgroup: add interface for charge/uncharge hugetlb reservations
On 9/10/19 5:31 PM, Mina Almasry wrote:
Augements hugetlb_cgroup_charge_cgroup to be able to charge hugetlb
usage or hugetlb reservation counter.
Augments?
Adds a new interface to uncharge a hugetlb_cgroup counter via
hugetlb_cgroup_uncharge_counter.
Integrates the counter with hugetlb_cgroup, via hugetlb_cgroup_init,
hugetlb_cgroup_have_usage, and hugetlb_cgroup_css_offline.
Signed-off-by: Mina Almasry
---
include/linux/hugetlb_cgroup.h | 13 --
mm/hugetlb.c | 6 ++-
mm/hugetlb_cgroup.c| 82 +++---
3 files changed, 80 insertions(+), 21 deletions(-)
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index 063962f6dfc6a..c467715dd8fb8 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -52,14 +52,19 @@ static inline bool hugetlb_cgroup_disabled(void)
}
extern int hugetlb_cgroup_charge_cgroup(int idx, unsigned long nr_pages,
- struct hugetlb_cgroup **ptr);
+ struct hugetlb_cgroup **ptr,
+ bool reserved);
extern void hugetlb_cgroup_commit_charge(int idx, unsigned long nr_pages,
struct hugetlb_cgroup *h_cg,
struct page *page);
extern void hugetlb_cgroup_uncharge_page(int idx, unsigned long nr_pages,
struct page *page);
extern void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
- struct hugetlb_cgroup *h_cg);
+ struct hugetlb_cgroup *h_cg,
+ bool reserved);
+extern void hugetlb_cgroup_uncharge_counter(struct page_counter *p,
+ unsigned long nr_pages);
+
extern void hugetlb_cgroup_file_init(void) __init;
extern void hugetlb_cgroup_migrate(struct page *oldhpage,
struct page *newhpage);
@@ -83,7 +88,7 @@ static inline bool hugetlb_cgroup_disabled(void)
static inline int
hugetlb_cgroup_charge_cgroup(int idx, unsigned long nr_pages,
-struct hugetlb_cgroup **ptr)
+struct hugetlb_cgroup **ptr, bool reserved)
Please line the arguments.
{
return 0;
}
@@ -102,7 +107,7 @@ hugetlb_cgroup_uncharge_page(int idx, unsigned long
nr_pages, struct page *page)
static inline void
hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
- struct hugetlb_cgroup *h_cg)
+ struct hugetlb_cgroup *h_cg, bool reserved)
Same here.
{
}
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6d7296dd11b83..e975f55aede94 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2078,7 +2078,8 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
gbl_chg = 1;
}
- ret = hugetlb_cgroup_charge_cgroup(idx, pages_per_huge_page(h), _cg);
+ ret = hugetlb_cgroup_charge_cgroup(idx, pages_per_huge_page(h), _cg,
+ false);
if (ret)
goto out_subpool_put;
@@ -2126,7 +2127,8 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
return page;
out_uncharge_cgroup:
- hugetlb_cgroup_uncharge_cgroup(idx, pages_per_huge_page(h), h_cg);
+ hugetlb_cgroup_uncharge_cgroup(idx, pages_per_huge_page(h), h_cg,
+ false);
Please be consistent with indentation. Line this up like you did above.
out_subpool_put:
if (map_chg || avoid_reserve)
hugepage_subpool_put_pages(spool, 1);
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 51a72624bd1ff..2ab36a98d834e 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -38,8 +38,8 @@ struct hugetlb_cgroup {
static struct hugetlb_cgroup *root_h_cgroup __read_mostly;
static inline
-struct page_counter *hugetlb_cgroup_get_counter(struct hugetlb_cgroup *h_cg,
int idx,
-bool reserved)
+struct page_counter *hugetlb_cgroup_get_counter(struct hugetlb_cgroup *h_cg,
+ int idx, bool reserved)
Same here.
{
if (reserved)
return _cg->reserved_hugepage[idx];
@@ -74,8 +74,12 @@ static inline bool hugetlb_cgroup_have_usage(struct
hugetlb_cgroup *h_cg)
int idx;
for (idx = 0; idx < hugetlb_max_hstate; idx++) {
- if (page_counter_read(_cg->hugepage[idx]))
+ if (page_counter_read(hugetlb_cgroup_get_counter(h_cg, idx,
+ true)) ||
+ page_counter_read(hugetlb_cgroup_get_counter(h_cg, idx,
+ false))) {
return true;
+ }
}
Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
On 2019/9/17 上午9:02, Tiwei Bie wrote: This RFC is to demonstrate below ideas, a) Build vhost-mdev on top of the same abstraction defined in the virtio-mdev series [1]; b) Introduce /dev/vhost-mdev to do vhost ioctls and support setting mdev device as backend; Now the userspace API looks like this: - Userspace generates a compatible mdev device; - Userspace opens this mdev device with VFIO API (including doing IOMMU programming for this mdev device with VFIO's container/group based interface); - Userspace opens /dev/vhost-mdev and gets vhost fd; - Userspace uses vhost ioctls to setup vhost (userspace should do VHOST_MDEV_SET_BACKEND ioctl with VFIO group fd and device fd first before doing other vhost ioctls); Only compile test has been done for this series for now. RFCv3: https://patchwork.kernel.org/patch/7785/ [1] https://lkml.org/lkml/2019/9/10/135 Thanks a lot for the patches. Per Michael request, the API in [1] might need some tweak, I want to introduce some device specific parent_ops instead of vfio specific one. This RFC has been posted at https://lkml.org/lkml/2019/9/12/151. Tiwei Bie (3): vfio: support getting vfio device from device fd vfio: support checking vfio driver by device ops vhost: introduce mdev based hardware backend drivers/vfio/mdev/vfio_mdev.c| 3 +- drivers/vfio/vfio.c | 32 +++ drivers/vhost/Kconfig| 9 + drivers/vhost/Makefile | 3 + drivers/vhost/mdev.c | 462 +++ drivers/vhost/vhost.c| 39 ++- drivers/vhost/vhost.h| 6 + include/linux/vfio.h | 11 + include/uapi/linux/vhost.h | 10 + include/uapi/linux/vhost_types.h | 5 + 10 files changed, 573 insertions(+), 7 deletions(-) create mode 100644 drivers/vhost/mdev.c
Re: Linux 5.3-rc8
On 16 September 2019 18:05:57 GMT-07:00, Linus Torvalds wrote: >On Mon, Sep 16, 2019 at 4:29 PM Ahmed S. Darwish >wrote: >> >> Linus, in all honesty, the other case is _not_ a hypothetical . > >Oh yes it is. > >You're confusing "use" with "breakage". > >The _use_ of getrandom(0) for key generation isn't hypothetical. > >But the _breakage_ from the suggested patch that makes it time out is. > >See the difference? > >The thing is, to break, you have to > > (a) do that key generation at boot time > > (b) do it on an idle machine that doesn't have entropy Exactly the scenario where you want getrandom() to block, yes. >in order to basically reproduce the current boot-time hang situation >with the broken gdm, except with an actual "generate key". > >Then you have to ignore the big warning too. The big warning that's only printed in dmesg? -- Matthew Garrett | mj...@srcf.ucam.org
Re: [PATCH v2] selftests: watchdog: Validate optional file argument
On 9/16/19 12:49 PM, George G. Davis wrote:
As reported by Eugeniu Rosca, a side of affect of commit c3f2490d6e92
("selftests: watchdog: Add optional file argument") is that arbitrary files
may be opened for watchdog testing, e.g.
You don't need to say this here since you are already have a
Reported-by tag. You are missing the Fixes tag.
./watchdog-test -f /dev/zero
Watchdog Ticking Away!
To prevent watchdog-test from operating on non-watchdog device files,
validate that a file is indeed a watchdog device via an
ioctl(WDIOC_GETSUPPORT) call.
While we're at it, since the watchdog_info is available as a result of the
ioctl(WDIOC_GETSUPPORT) call, add a command line option to optionally show
the watchdog_info.
Let's try this again. I want two patches. The first one with Fixes tag.
The first patch might be candidate for going into stables.
The -i (info) should be a separate patch. This won't go into stables.
Please write a clear commit log. The following will help:
https://chris.beams.io/posts/git-commit/
Reported-by: Eugeniu Rosca
Tested-by: Eugeniu Rosca
Signed-off-by: George G. Davis
Signed-off-by: Eugeniu Rosca
---
v1: Applied/tested on commit ce54eab71e210f ("kunit: fix failure to build without
printk") of
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/log/?h=next
v2: Squashed [1] and [2], and update commit description as discussed in [3].
[1] https://patchwork.kernel.org/patch/11136283/
[2] https://patchwork.kernel.org/patch/11136285/
[3] https://patchwork.kernel.org/patch/11136285/#22883573
---
tools/testing/selftests/watchdog/watchdog-test.c | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/watchdog/watchdog-test.c
b/tools/testing/selftests/watchdog/watchdog-test.c
index afff120c7be6..f45e510500c0 100644
--- a/tools/testing/selftests/watchdog/watchdog-test.c
+++ b/tools/testing/selftests/watchdog/watchdog-test.c
@@ -19,7 +19,7 @@
int fd;
const char v = 'V';
-static const char sopts[] = "bdehp:t:Tn:NLf:";
+static const char sopts[] = "bdehp:t:Tn:NLf:i";
static const struct option lopts[] = {
{"bootstatus", no_argument, NULL, 'b'},
{"disable", no_argument, NULL, 'd'},
@@ -32,6 +32,7 @@ static const struct option lopts[] = {
{"getpretimeout", no_argument, NULL, 'N'},
{"gettimeleft", no_argument, NULL, 'L'},
{"file", required_argument, NULL, 'f'},
+ {"info", no_argument, NULL, 'i'},
{NULL, no_argument, NULL, 0x0}
};
@@ -72,6 +73,7 @@ static void usage(char *progname)
printf("Usage: %s [options]\n", progname);
printf(" -f, --file\t\tOpen watchdog device file\n");
printf("\t\t\tDefault is /dev/watchdog\n");
+ printf(" -i, --info\t\tShow watchdog_info\n");
printf(" -b, --bootstatus\tGet last boot status (Watchdog/POR)\n");
printf(" -d, --disable\t\tTurn off the watchdog timer\n");
printf(" -e, --enable\t\tTurn on the watchdog timer\n");
@@ -97,6 +99,7 @@ int main(int argc, char *argv[])
int c;
int oneshot = 0;
char *file = "/dev/watchdog";
+ struct watchdog_info info;
setbuf(stdout, NULL);
@@ -118,6 +121,16 @@ int main(int argc, char *argv[])
exit(-1);
}
+ /*
+* Validate that `file` is a watchdog device
+*/
+ ret = ioctl(fd, WDIOC_GETSUPPORT, );
+ if (ret) {
+ printf("WDIOC_GETSUPPORT error '%s'\n", strerror(errno));
+ close(fd);
+ exit(ret);
+ }
+
optind = 0;
while ((c = getopt_long(argc, argv, sopts, lopts, NULL)) != -1) {
@@ -205,6 +218,18 @@ int main(int argc, char *argv[])
case 'f':
/* Handled above */
break;
+ case 'i':
+ /*
+* watchdog_info was obtained as part of file open
+* validation. So we just show it here.
+*/
+ oneshot = 1;
+ printf("watchdog_info:\n");
+ printf(" identity:\t\t%s\n", info.identity);
+ printf(" firmware_version:\t%u\n",
+ info.firmware_version);
+ printf(" options:\t\t%08x\n", info.options);
+ break;
default:
usage(argv[0]);
thanks,
-- Shuah
Re: [v4,1/2] dt-bindings: rtc: pcf85263/pcf85363: add some properties
On Tue, Sep 10, 2019 at 5:53 AM Biwen Li wrote:
>
> Add some properties for pcf85263/pcf85363 as follows:
> - nxp,rtc-interrupt-type: integer type
> - nxp,rtc-interrupt-output-pin: string type
> - quartz-load-femtofarads: integer type
> - nxp,quartz-drive-strength: integer type
> - nxp,quartz-low-jitter: bool type
> - wakeup-source: bool type
>
> Signed-off-by: Martin Fuzzey
> Signed-off-by: Biwen Li
> ---
> Change in v4:
> - Drop robust defines in include/dt-bindings/rtc/pcf85363.h
> - Add nxp,rtc-interrupt-type property
> - Replace interrupt-output-pin with nxp,rtc-interrupt-output-pin
>
> Change in v3:
> - None
>
> Change in v2:
> - Replace properties name
> quartz-load-capacitance -> quartz-load-femtofarads
> quartz-drive-strength -> nxp,quartz-drive-strength
> quartz-low-jitter -> nxp,quartz-low-jitter
> - Replace drive strength name
> PCF85263_QUARTZDRIVE_NORMAL -> PCF85263_QUARTZDRIVE_100ko
> PCF85263_QUARTZDRIVE_LOW -> PCF85263_QUARTZDRIVE_60ko
> PCF85263_QUARTZDRIVE_HIGH -> PCF85263_QUARTZDRIVE_500ko
> - Set default interrupt-output-pin as "INTA"
>
> .../devicetree/bindings/rtc/pcf85363.txt | 44 ++-
> include/dt-bindings/rtc/pcf85363.h| 14 ++
> 2 files changed, 57 insertions(+), 1 deletion(-)
> create mode 100644 include/dt-bindings/rtc/pcf85363.h
>
> diff --git a/Documentation/devicetree/bindings/rtc/pcf85363.txt
> b/Documentation/devicetree/bindings/rtc/pcf85363.txt
> index 94adc1cf93d9..fc1579463657 100644
> --- a/Documentation/devicetree/bindings/rtc/pcf85363.txt
> +++ b/Documentation/devicetree/bindings/rtc/pcf85363.txt
> @@ -8,10 +8,52 @@ Required properties:
> Optional properties:
> - interrupts: IRQ line for the RTC (not implemented).
>
> +- nxp,rtc-interrupt-type: integer property, represent the interrupt's
> + type. Valid values are
> + INT_PIE(periodic interrupt enable),
> + INT_OIE(offset correction interrupt enable),
> + INT_A1IE(alarm1 interrupt enable),
> + INT_A2IE(alarm2 interrupt enable),
> + INT_TSRIE(timestamp register interrupt enable)
> + INT_BSIE(battery switch interrupt enable),
> + INT_WDIE(WatchDog interrupt enable,and
> + compose these values such as: INT_A1IE | INT_A2IE,
> + but currently only support INT_A1IE, default value is INT_A1IE.
> + The property and property nxp,rtc-interrupt-output-pin
> + work together to generate some interrupts on some pins.
> +
> +- nxp,rtc-interrupt-output-pin: The interrupt output pin must be
> + "INTA" or "INTB", default value is "INTA". The property and property
> + nxp,rtc-interrupt-type work together to generate some interrupts on
> + some pins.
> +
> +- quartz-load-femtofarads: The internal capacitor to select for the quartz,
> + expressed in femto Farad (fF). Valid values are 6000, 7000 and 12500.
> + Default value is 12500fF.
> +
> +- nxp,quartz-drive-strength: Drive strength for the quartz,
> + expressed in kilo ohms (kOhm) Valid values are 60, 100 and 500.
> + Default value is 100kOhm.
This needs a unit as defined in property-units.txt.
> +
> +- nxp,quartz-low-jitter: Boolean property, if present enables low jitter mode
> + which reduces jitter at the cost of increased power consumption.
> +
> +- wakeup-source: Boolean property, Please refer to
> + Documentation/devicetree/bindings/power/wakeup-source.txt
> +
> Example:
>
> pcf85363: pcf85363@51 {
> compatible = "nxp,pcf85363";
> reg = <0x51>;
> -};
>
> + interrupt-parent = <>;
> + interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
> +
> + wakeup-source;
> + nxp,rtc-interrupt-output-pin = "INTA";
> + nxp,rtc-interrupt-type = ;
> + quartz-load-femtofarads = <12500>;
> + nxp,quartz-drive-strength = <60>;
> + nxp,quartz-low-jitter;
> +};
> diff --git a/include/dt-bindings/rtc/pcf85363.h
> b/include/dt-bindings/rtc/pcf85363.h
> new file mode 100644
> index ..6340bf2da8f5
> --- /dev/null
> +++ b/include/dt-bindings/rtc/pcf85363.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _DT_BINDINGS_RTC_PCF85363_H
> +#define _DT_BINDINGS_RTC_PCF85363_H
> +
> +/* Interrupt type */
> +#define INT_WDIE (1 << 0)
> +#define INT_BSIE (1 << 1)
> +#define INT_TSRIE (1 << 2)
> +#define INT_A2IE (1 << 3)
> +#define INT_A1IE (1 << 4)
> +#define INT_OIE(1 << 5)
> +#define INT_PIE(1 << 6)
> +
> +#endif /* _DT_BINDINGS_RTC_PCF85363_H */
> --
> 2.17.1
>
[PATCH v3 2/2] mm: Add a bounds check in devm_memremap_pages()
From: Alastair D'Silva
The call to check_hotplug_memory_addressable() validates that the memory
is fully addressable.
Without this call, it is possible that we may remap pages that is
not physically addressable, resulting in bogus section numbers
being returned from __section_nr().
Signed-off-by: Alastair D'Silva
---
mm/memremap.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/mm/memremap.c b/mm/memremap.c
index 86432650f829..de2b67586401 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -175,6 +175,11 @@ void *devm_memremap_pages(struct device *dev, struct
dev_pagemap *pgmap)
int error, nid, is_ram;
bool need_devmap_managed = true;
+ error = check_hotplug_memory_addressable(res->start,
+resource_size(res));
+ if (error)
+ return ERR_PTR(error);
+
switch (pgmap->type) {
case MEMORY_DEVICE_PRIVATE:
if (!IS_ENABLED(CONFIG_DEVICE_PRIVATE)) {
--
2.21.0
[PATCH v3 1/2] memory_hotplug: Add a bounds check to check_hotplug_memory_range()
From: Alastair D'Silva
On PowerPC, the address ranges allocated to OpenCAPI LPC memory
are allocated from firmware. These address ranges may be higher
than what older kernels permit, as we increased the maximum
permissable address in commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB"). It is
possible that the addressable range may change again in the
future.
In this scenario, we end up with a bogus section returned from
__section_nr (see the discussion on the thread "mm: Trigger bug on
if a section is not found in __section_nr").
Adding a check here means that we fail early and have an
opportunity to handle the error gracefully, rather than rumbling
on and potentially accessing an incorrect section.
Further discussion is also on the thread ("powerpc: Perform a bounds
check in arch_add_memory").
Signed-off-by: Alastair D'Silva
---
include/linux/memory_hotplug.h | 1 +
mm/memory_hotplug.c| 13 -
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index f46ea71b4ffd..bc477e98a310 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -110,6 +110,7 @@ extern void __online_page_increment_counters(struct page
*page);
extern void __online_page_free(struct page *page);
extern int try_online_node(int nid);
+int check_hotplug_memory_addressable(u64 start, u64 size);
extern int arch_add_memory(int nid, u64 start, u64 size,
struct mhp_restrictions *restrictions);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c73f09913165..02cb9a74f561 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1030,6 +1030,17 @@ int try_online_node(int nid)
return ret;
}
+int check_hotplug_memory_addressable(u64 start, u64 size)
+{
+#ifdef MAX_PHYSMEM_BITS
+ if ((start + size - 1) >> MAX_PHYSMEM_BITS)
+ return -E2BIG;
+#endif
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(check_hotplug_memory_addressable);
+
static int check_hotplug_memory_range(u64 start, u64 size)
{
/* memory range must be block size aligned */
@@ -1040,7 +1051,7 @@ static int check_hotplug_memory_range(u64 start, u64 size)
return -EINVAL;
}
- return 0;
+ return check_hotplug_memory_addressable(start, size);
}
static int online_memory_block(struct memory_block *mem, void *arg)
--
2.21.0
[PATCH v3 0/2] Add bounds check for Hotplugged memory
From: Alastair D'Silva This series adds bounds checks for hotplugged memory, ensuring that it is within the physically addressable range (for platforms that define MAX_(POSSIBLE_)PHYSMEM_BITS. This allows for early failure, rather than attempting to access bogus section numbers. Changelog: V3: - Perform the addressable check before we take the hotplug lock V2: - Don't use MAX_POSSIBLE_PHYSMEM_BITS as it's wider that what may be available Alastair D'Silva (2): memory_hotplug: Add a bounds check to check_hotplug_memory_range() mm: Add a bounds check in devm_memremap_pages() include/linux/memory_hotplug.h | 1 + mm/memory_hotplug.c| 13 - mm/memremap.c | 5 + 3 files changed, 18 insertions(+), 1 deletion(-) -- 2.21.0
Re: Linux 5.3-rc8
On Mon, Sep 16, 2019 at 4:29 PM Ahmed S. Darwish wrote: > > Linus, in all honesty, the other case is _not_ a hypothetical . Oh yes it is. You're confusing "use" with "breakage". The _use_ of getrandom(0) for key generation isn't hypothetical. But the _breakage_ from the suggested patch that makes it time out is. See the difference? The thing is, to break, you have to (a) do that key generation at boot time (b) do it on an idle machine that doesn't have entropy in order to basically reproduce the current boot-time hang situation with the broken gdm, except with an actual "generate key". Then you have to ignore the big warning too. Linus
[RFC v4 3/3] vhost: introduce mdev based hardware backend
More details about this patch can be found from the cover
letter for now. Only compile test has been done for now.
Signed-off-by: Tiwei Bie
---
drivers/vhost/Kconfig| 9 +
drivers/vhost/Makefile | 3 +
drivers/vhost/mdev.c | 462 +++
drivers/vhost/vhost.c| 39 ++-
drivers/vhost/vhost.h| 6 +
include/uapi/linux/vhost.h | 10 +
include/uapi/linux/vhost_types.h | 5 +
7 files changed, 528 insertions(+), 6 deletions(-)
create mode 100644 drivers/vhost/mdev.c
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 3d03ccbd1adc..ef9783156d2e 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -34,6 +34,15 @@ config VHOST_VSOCK
To compile this driver as a module, choose M here: the module will be
called
vhost_vsock.
+config VHOST_MDEV
+ tristate "Mediated device based hardware vhost accelerator"
+ depends on EVENTFD && VFIO && VFIO_MDEV
+ select VHOST
+ default n
+ ---help---
+ Say Y here to enable the vhost_mdev module
+ for use with hardware vhost accelerators
+
config VHOST
tristate
---help---
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 6c6df24f770c..ad9c0f8c6d8c 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -10,4 +10,7 @@ vhost_vsock-y := vsock.o
obj-$(CONFIG_VHOST_RING) += vringh.o
+obj-$(CONFIG_VHOST_MDEV) += vhost_mdev.o
+vhost_mdev-y := mdev.o
+
obj-$(CONFIG_VHOST)+= vhost.o
diff --git a/drivers/vhost/mdev.c b/drivers/vhost/mdev.c
new file mode 100644
index ..8c6597aff45e
--- /dev/null
+++ b/drivers/vhost/mdev.c
@@ -0,0 +1,462 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018-2019 Intel Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vhost.h"
+
+struct vhost_mdev {
+ struct mutex mutex;
+ struct vhost_dev dev;
+ struct vhost_virtqueue *vqs;
+ int nvqs;
+ u64 state;
+ u64 features;
+ u64 acked_features;
+ struct vfio_group *vfio_group;
+ struct vfio_device *vfio_device;
+ struct mdev_device *mdev;
+};
+
+/*
+ * XXX
+ * We assume virtio_mdev.ko exposes below symbols for now, as we
+ * don't have a proper way to access parent ops directly yet.
+ *
+ * virtio_mdev_readl()
+ * virtio_mdev_writel()
+ */
+extern u32 virtio_mdev_readl(struct mdev_device *mdev, loff_t off);
+extern void virtio_mdev_writel(struct mdev_device *mdev, loff_t off, u32 val);
+
+static u8 mdev_get_status(struct mdev_device *mdev)
+{
+ return virtio_mdev_readl(mdev, VIRTIO_MDEV_STATUS);
+}
+
+static void mdev_set_status(struct mdev_device *mdev, u8 status)
+{
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_STATUS, status);
+}
+
+static void mdev_add_status(struct mdev_device *mdev, u8 status)
+{
+ status |= mdev_get_status(mdev);
+ mdev_set_status(mdev, status);
+}
+
+static void mdev_reset(struct mdev_device *mdev)
+{
+ mdev_set_status(mdev, 0);
+}
+
+static void handle_vq_kick(struct vhost_work *work)
+{
+ struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
+ poll.work);
+ struct vhost_mdev *m = container_of(vq->dev, struct vhost_mdev, dev);
+
+ virtio_mdev_writel(m->mdev, VIRTIO_MDEV_QUEUE_NOTIFY, vq - m->vqs);
+}
+
+static long vhost_mdev_start_backend(struct vhost_mdev *m)
+{
+ struct mdev_device *mdev = m->mdev;
+ u64 features = m->acked_features;
+ u64 addr;
+ struct vhost_virtqueue *vq;
+ int queue_id;
+
+ features |= 1ULL << VIRTIO_F_IOMMU_PLATFORM;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES_SEL, 1);
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES,
+ (u32)(features >> 32));
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES_SEL, 0);
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES,
+ (u32)features);
+
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_FEATURES_OK);
+ if (!(mdev_get_status(mdev) & VIRTIO_CONFIG_S_FEATURES_OK))
+ return -ENODEV;
+
+ for (queue_id = 0; queue_id < m->nvqs; queue_id++) {
+ vq = >vqs[queue_id];
+
+ if (!vq->desc || !vq->avail || !vq->used)
+ break;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_NUM, vq->num);
+
+ if (!vhost_translate_ring_addr(vq, (u64)vq->desc,
+ vhost_get_desc_size(vq, vq->num),
+ ))
+ return -EINVAL;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_DESC_LOW, addr);
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_DESC_HIGH,
+ (addr >> 32));
+
+
[RFC v4 2/3] vfio: support checking vfio driver by device ops
This patch introduces the support for checking the VFIO driver
by device ops. And vfio-mdev's device ops is also exported to
make it possible to check whether a VFIO device is based on a
mdev device.
Signed-off-by: Tiwei Bie
---
drivers/vfio/mdev/vfio_mdev.c | 3 ++-
drivers/vfio/vfio.c | 7 +++
include/linux/vfio.h | 7 +++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
index 30964a4e0a28..e0f31c5a5db2 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -98,7 +98,7 @@ static int vfio_mdev_mmap(void *device_data, struct
vm_area_struct *vma)
return parent->ops->mmap(mdev, vma);
}
-static const struct vfio_device_ops vfio_mdev_dev_ops = {
+const struct vfio_device_ops vfio_mdev_dev_ops = {
.name = "vfio-mdev",
.open = vfio_mdev_open,
.release= vfio_mdev_release,
@@ -107,6 +107,7 @@ static const struct vfio_device_ops vfio_mdev_dev_ops = {
.write = vfio_mdev_write,
.mmap = vfio_mdev_mmap,
};
+EXPORT_SYMBOL_GPL(vfio_mdev_dev_ops);
static int vfio_mdev_probe(struct device *dev)
{
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 697fd079bb3f..1145110909e4 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1806,6 +1806,13 @@ long vfio_external_check_extension(struct vfio_group
*group, unsigned long arg)
}
EXPORT_SYMBOL_GPL(vfio_external_check_extension);
+bool vfio_device_ops_match(struct vfio_device *device,
+ const struct vfio_device_ops *ops)
+{
+ return device->ops == ops;
+}
+EXPORT_SYMBOL_GPL(vfio_device_ops_match);
+
/**
* Sub-module support
*/
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index e75b24fd7c5c..741c5bb567a8 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -56,6 +56,8 @@ extern struct vfio_device *vfio_device_get_from_fd(struct
vfio_group *group,
int device_fd);
extern void vfio_device_put(struct vfio_device *device);
extern void *vfio_device_data(struct vfio_device *device);
+extern bool vfio_device_ops_match(struct vfio_device *device,
+ const struct vfio_device_ops *ops);
/**
* struct vfio_iommu_driver_ops - VFIO IOMMU driver callbacks
@@ -199,4 +201,9 @@ extern int vfio_virqfd_enable(void *opaque,
void *data, struct virqfd **pvirqfd, int fd);
extern void vfio_virqfd_disable(struct virqfd **pvirqfd);
+/*
+ * VFIO device ops
+ */
+extern const struct vfio_device_ops vfio_mdev_dev_ops;
+
#endif /* VFIO_H */
--
2.17.1
[RFC v4 1/3] vfio: support getting vfio device from device fd
This patch introduces the support for getting VFIO device
from VFIO device fd. With this support, it's possible for
vhost to get VFIO device from the group fd and device fd
set by the userspace.
Signed-off-by: Tiwei Bie
---
drivers/vfio/vfio.c | 25 +
include/linux/vfio.h | 4
2 files changed, 29 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 388597930b64..697fd079bb3f 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -890,6 +890,31 @@ static struct vfio_device
*vfio_device_get_from_name(struct vfio_group *group,
return device;
}
+struct vfio_device *vfio_device_get_from_fd(struct vfio_group *group,
+ int device_fd)
+{
+ struct fd f;
+ struct vfio_device *it, *device = ERR_PTR(-ENODEV);
+
+ f = fdget(device_fd);
+ if (!f.file)
+ return ERR_PTR(-EBADF);
+
+ mutex_lock(>device_lock);
+ list_for_each_entry(it, >device_list, group_next) {
+ if (it == f.file->private_data) {
+ device = it;
+ vfio_device_get(device);
+ break;
+ }
+ }
+ mutex_unlock(>device_lock);
+
+ fdput(f);
+ return device;
+}
+EXPORT_SYMBOL_GPL(vfio_device_get_from_fd);
+
/*
* Caller must hold a reference to the vfio_device
*/
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index e42a711a2800..e75b24fd7c5c 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -15,6 +15,8 @@
#include
#include
+struct vfio_group;
+
/**
* struct vfio_device_ops - VFIO bus driver device callbacks
*
@@ -50,6 +52,8 @@ extern int vfio_add_group_dev(struct device *dev,
extern void *vfio_del_group_dev(struct device *dev);
extern struct vfio_device *vfio_device_get_from_dev(struct device *dev);
+extern struct vfio_device *vfio_device_get_from_fd(struct vfio_group *group,
+ int device_fd);
extern void vfio_device_put(struct vfio_device *device);
extern void *vfio_device_data(struct vfio_device *device);
--
2.17.1
[RFC v4 0/3] vhost: introduce mdev based hardware backend
This RFC is to demonstrate below ideas, a) Build vhost-mdev on top of the same abstraction defined in the virtio-mdev series [1]; b) Introduce /dev/vhost-mdev to do vhost ioctls and support setting mdev device as backend; Now the userspace API looks like this: - Userspace generates a compatible mdev device; - Userspace opens this mdev device with VFIO API (including doing IOMMU programming for this mdev device with VFIO's container/group based interface); - Userspace opens /dev/vhost-mdev and gets vhost fd; - Userspace uses vhost ioctls to setup vhost (userspace should do VHOST_MDEV_SET_BACKEND ioctl with VFIO group fd and device fd first before doing other vhost ioctls); Only compile test has been done for this series for now. RFCv3: https://patchwork.kernel.org/patch/7785/ [1] https://lkml.org/lkml/2019/9/10/135 Tiwei Bie (3): vfio: support getting vfio device from device fd vfio: support checking vfio driver by device ops vhost: introduce mdev based hardware backend drivers/vfio/mdev/vfio_mdev.c| 3 +- drivers/vfio/vfio.c | 32 +++ drivers/vhost/Kconfig| 9 + drivers/vhost/Makefile | 3 + drivers/vhost/mdev.c | 462 +++ drivers/vhost/vhost.c| 39 ++- drivers/vhost/vhost.h| 6 + include/linux/vfio.h | 11 + include/uapi/linux/vhost.h | 10 + include/uapi/linux/vhost_types.h | 5 + 10 files changed, 573 insertions(+), 7 deletions(-) create mode 100644 drivers/vhost/mdev.c -- 2.17.1
Re: [GIT PULL] objtool change for v5.3
The pull request you sent on Mon, 16 Sep 2019 13:15:30 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > core-objtool-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d75a43c645c26ab58118bd35405666a12971350d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] core/stacktrace change for v5.4
The pull request you sent on Mon, 16 Sep 2019 13:28:06 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > core-stacktrace-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/98c82b4b8be60b05bc96aa4ab664ca0b0e39001f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] RCU changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 13:26:41 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/94d18ee9340e00ee3455bb45661484093e3b2674 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] scheduler changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 14:30:47 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-core-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7e67a859997aad47727aff9c5a32e160da079ce3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] locking changes for v5.4
The pull request you sent on Mon, 16 Sep 2019 13:41:10 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking-core-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c7eba51cfdf9cd1ca7ed4201b30be8b2bef15ff5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
