Re: [PATCH 1/2] ARM: drop unnecessary WASM
On 06.03.2019 00:39, Robin Murphy wrote:
> Hi Stefan,
>
> On 2019-03-05 10:18 pm, Stefan Agner wrote:
>> The W macro for generating wide instructions when targeting Thumb-2
>> is not required for the preload data instructions (pld, pldw) since
>> they are only available as wide instructions. The GNU assembler seems
>> to work with or without the .w appended when compiling an Thumb-2
>> kernel. However, Clang's integrated assembler does not consider the
>> .w variants as valid instructions:
>>
>>./arch/arm/include/asm/processor.h:133:5: error: invalid instruction
>>"pldw.w\t%a0 \n"
>> ^
>>:2:1: note: instantiated into assembly here
>>pldw.w [r0]
>>^
>>1 error generated.
>
> Have you filed a bug against Clang for that? Something like "pldwal.w"
> may be super-redundant, but it's still perfectly valid syntax. The
> "Standard assembler syntax fields" section of the Arm ARM even calls
> out that "...the .W qualifier has no effect" on ARM/A32 instructions
> since they are inherently 32-bit; that should equally apply for 32-bit
> only Thumb/T32 instructions. There are certainly a few instructions
> which don't allow a condition code (even "AL"), but off-hand I don't
> remember any not having the optional {} field in their syntax.
Good point, bug filed:
https://bugs.llvm.org/show_bug.cgi?id=40972
Will send a v2 and note that this is a work around for Clang and
reference the bug.
--
Stefan
>
> That said, obviously the patch itself is no problem since the syntax
> *is* redundant here, but it really is just a workaround for an
> assembler bug.
>
> Robin.
>
>> Drop the macro to make sure non-wide variants of pld and pldw are
>> emitted in all cases.
>>
>> Signed-off-by: Stefan Agner
>> ---
>> arch/arm/include/asm/processor.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/processor.h
>> b/arch/arm/include/asm/processor.h
>> index 120f4c9bbfde..042d77cf686d 100644
>> --- a/arch/arm/include/asm/processor.h
>> +++ b/arch/arm/include/asm/processor.h
>> @@ -131,8 +131,8 @@ static inline void prefetchw(const void *ptr)
>> __asm__ __volatile__(
>> ".arch_extensionmp\n"
>> __ALT_SMP_ASM(
>> -WASM(pldw) "\t%a0",
>> -WASM(pld) "\t%a0"
>> +"pldw\t%a0",
>> +"pld\t%a0"
>> )
>> :: "p" (ptr));
>> }
>>
Re: [PATCH] x86/boot/KASLR: skip the specified crashkernel reserved region
On Wed, Feb 27, 2019 at 3:40 PM Borislav Petkov wrote: > > + Kees. > > @Kees, you might want to go upthread a bit for context. > Seems not reply from Kees. > On Wed, Feb 27, 2019 at 09:30:34AM +0800, Baoquan He wrote: > > Agree that 'crashkernel=x' should be encouraged to use as the first > > choice when reserve crashkernel. If we decide to not obsolete > > 'crashkernel=x@y', it will leave a unstable kernel parameter. > > Is anyone even talking about obsoleting this? > > And if anyone is, anyone can think a bit why we can't do this. > As Dave said, some un-relocatable code should be loaded to a specified space. Also the param is used by archs beside x86 > > Another worry is that KASLR won't always fail 'crashkernel=x@y', > > customer may set and check in testing stage, then later in production > > environment one time of neglect to not check may cause carashed kernel > > uncaptured. > > > > IMHO, 'crashkernel=x@y' is similar to those specified memmap=ss[#$!]nn > > which have been avoided in boot stage KASLR. > > So my worry is that by specifying too many exclusion ranges, we might > limit the kaslr space too much and make it too predictable. Especially > since distros slap those things automatically and most users take them > for granted. > Kernel has already done this excluding 1gb pages. Do we need to worry about 200-400 MB for crashkernel? And I think if a user specify the region, then he/she should be aware of the limit of KASLR (can printk to warn him/her). > But I might be way off here because of something else I'm missing ... > So how do you think about this now? Just leaving a unstable kernel parameter, or printk some info when crashkernel=x@y fails. Thanks, Pingfan > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v5 5/8] drivers: devfreq: add DMC driver for Exynos5422
Hi Lukasz,
As you knew, I replied the comments on v4 patch[1].
But, this patch does apply some comments from me
and some comments doesn't not applied.
My comments may not be always right. But, If you pick up some comments
and drop the some comments without discussion, it makes the confusion
for the review.
So, on v4 patch[1], please reply why do you agree some comments
and disagree some comments.
- [v4,4/8] drivers: devfreq: add DMC driver for Exynos542
[1] https://patchwork.kernel.org/patch/10793297/
On 19. 3. 5. 오후 7:19, Lukasz Luba wrote:
> This patch adds driver for Exynos5422 Dynamic Memory Controller.
> The driver provides support for dynamic frequency and voltage scaling for
> DMC and DRAM. It supports changing timings of DRAM running with different
> frequency.
> The patch also contains needed MAINTAINERS file update.
>
> Signed-off-by: Lukasz Luba
> ---
> MAINTAINERS |8 +
> drivers/devfreq/Kconfig | 13 +
> drivers/devfreq/Makefile |1 +
> drivers/devfreq/exynos5422-dmc.c | 1154
> ++
> 4 files changed, 1176 insertions(+)
> create mode 100644 drivers/devfreq/exynos5422-dmc.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dce5c09..e20172b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3323,6 +3323,14 @@ S: Maintained
> F: drivers/devfreq/exynos-bus.c
> F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>
> +DMC FREQUENCY DRIVER FOR SAMSUNG EXYNOS5422
> +M: Lukasz Luba
> +L: linux...@vger.kernel.org
> +L: linux-samsung-...@vger.kernel.org
> +S: Maintained
> +F: drivers/devfreq/exynos5422-dmc.c
> +F: Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
> +
> BUSLOGIC SCSI DRIVER
> M: Khalid Aziz
> L: linux-s...@vger.kernel.org
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 6a172d3..a476477 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -113,6 +113,19 @@ config ARM_RK3399_DMC_DEVFREQ
>It sets the frequency for the memory controller and reads the
> usage counts
>from hardware.
>
> +config ARM_EXYNOS5422_DMC_DEVFREQ
> + tristate "ARM EXYNOS5422 DMC DEVFREQ Driver"
> + depends on ARCH_EXYNOS || COMPILE_TEST
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select DEVFREQ_GOV_USERSPACE
> + select PM_DEVFREQ_EVENT
> + select PM_OPP
> + help
> + This adds DEVFREQ driver for Exynos5422 DMC (Dynamic Memory
> Controller).
> + The driver provides support for Dynamic Voltage and Frequency Scaling
> in
> + DMC and DRAM. It also supports changing timings of DRAM running with
> + different frequency.
> +
> source "drivers/devfreq/event/Kconfig"
>
> endif # PM_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 32b8d4d..e3620ff 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
>
> # DEVFREQ Drivers
> obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
> +obj-$(CONFIG_ARM_EXYNOS5422_DMC_DEVFREQ) += exynos5422-dmc.o
> obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
> obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra-devfreq.o
>
> diff --git a/drivers/devfreq/exynos5422-dmc.c
> b/drivers/devfreq/exynos5422-dmc.c
> new file mode 100644
> index 000..0505a99
> --- /dev/null
> +++ b/drivers/devfreq/exynos5422-dmc.c
> @@ -0,0 +1,1154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 Samsung Electronics Co., Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define EXYNOS5_DREXI_TIMINGAREF (0x0030)
> +#define EXYNOS5_DREXI_TIMINGROW0 (0x0034)
> +#define EXYNOS5_DREXI_TIMINGDATA0(0x0038)
> +#define EXYNOS5_DREXI_TIMINGPOWER0 (0x003C)
> +#define EXYNOS5_DREXI_TIMINGROW1 (0x00E4)
> +#define EXYNOS5_DREXI_TIMINGDATA1(0x00E8)
> +#define EXYNOS5_DREXI_TIMINGPOWER1 (0x00EC)
> +
> +#define EXYNOS5_AREF_NORMAL (0x2e)
> +
> +#define IS_MEM_2GB(val) \
> + ( \
> + (((val) & 0xf0) & 0x20) ? 1 : \
> + (((val) & 0xf0) & 0x30) ? 1 : 0 \
> + )
> +
> +#define EXYNOS5_POP_OPTIONS(val) (((val >> 4) & 0x3UL) << 4)
> +#define EXYNOS5_DDR_TYPE(val)(((val >> 14) & 0x1UL))
> +
> +#define EXYNOS5_CHIP_PROD_ID (0)
> +#define EXYNOS5_CHIP_PKG_ID (4)
> +
> +#define PPMU_PMCNT_CONST_RATIO_MUL 15
> +#define PPMU_PMCNT_CONST_RATIO_DIV 10
> +
> +/**
> + * enum dmc_slot_id - An enum with slots in DMC
> + */
> +enum dmc_slot_id {
> + DMC0_0,
> + DMC0_1,
> + DMC1_0,
> + DMC1_1,
> + DMC_SLOTS_END
> +};
> +
>
Re: [PATCH] spi-pxa2xx.c: modify the chip selection timing when spi transfer
Hi
On 3/6/19 5:05 AM, xiao jin wrote:
From: "he, bo"
We find spi can't work on board. More debug shows it's related
to the following patch that changed the chip selection assert and
deassert timing.
^^ timing caught my attention. More below.
@@ -610,6 +596,7 @@ static void int_transfer_complete(struct driver_data
*drv_data)
if (!pxa25x_ssp_comp(drv_data))
pxa2xx_spi_write(drv_data, SSTO, 0);
+ cs_deassert(drv_data);
spi_finalize_current_transfer(drv_data->master);
This
@@ -1070,6 +1057,7 @@ static int pxa2xx_spi_transfer_one(struct spi_controller
*master,
pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
}
+ cs_assert(drv_data);
and this is not correct with core message loop. It will cause the chip
select is toggled with each transfer in PIO mode. If there is no
cs_change flag set then there shouldn't be CS toggling between the
transfers if SPI message consists of multiple transfers.
More over this patch also will regress with DMA mode since there won't
be CS deassert at all.
Timing reminded me I've seen two cases where there was a timing related
glitch in CS output:
d0283eb2dbc1 ("spi: pxa2xx: Add output control for multiple Intel LPSS
chip selects")
7a8d44bc89e5 ("spi: pxa2xx: Fix too early chipselect deassert")
Do you have a possibility to measure with an oscilloscope what goes
wrong with the CS after d5898e19c0d7 ("spi: pxa2xx: Use core message
processing loop")?
Can you share your setup if I can reproduce it here? E.g. SPI clock
frequency, single or multiple CS, frequency of occurrence, etc
--
Jarkko
Re: [PATCH] sched/cpufreq: Fix 32bit math overflow
On Tue, Mar 5, 2019 at 4:32 PM Peter Zijlstra wrote:
>
> On Mon, Mar 04, 2019 at 07:11:01PM +, Quentin Perret wrote:
>
> > So yeah, that works for me.
>
> Chunyan, Vincent; can you verify the below cures your ill?
Verified by Vincent, the patch below can fix the problem Vincent found
on our platform before.
Thanks,
Chunyan
>
> ---
> Subject: sched/cpufreq: Fix 32bit math overflow
>
> Vincent Wang reported that get_next_freq() has a mult overflow issue on
> 32bit platforms in the IOWAIT boost case, since in that case {util,max}
> are in freq units instead of capacity units.
>
> Solve this by moving the IOWAIT boost to capacity units. And since this
> means @max is constant; simplify the code.
>
> Cc: Chunyan Zhang
> Reported-by: Vincent Wang
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> kernel/sched/cpufreq_schedutil.c | 58
> +---
> 1 file changed, 24 insertions(+), 34 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index 2efe629425be..72b62ac1c7c2 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -48,10 +48,10 @@ struct sugov_cpu {
>
> booliowait_boost_pending;
> unsigned intiowait_boost;
> - unsigned intiowait_boost_max;
> u64 last_update;
>
> unsigned long bw_dl;
> + unsigned long min;
> unsigned long max;
>
> /* The field below is for single-CPU policies only: */
> @@ -303,8 +303,7 @@ static bool sugov_iowait_reset(struct sugov_cpu *sg_cpu,
> u64 time,
> if (delta_ns <= TICK_NSEC)
> return false;
>
> - sg_cpu->iowait_boost = set_iowait_boost
> - ? sg_cpu->sg_policy->policy->min : 0;
> + sg_cpu->iowait_boost = set_iowait_boost ? sg_cpu->min : 0;
> sg_cpu->iowait_boost_pending = set_iowait_boost;
>
> return true;
> @@ -344,14 +343,12 @@ static void sugov_iowait_boost(struct sugov_cpu
> *sg_cpu, u64 time,
>
> /* Double the boost at each request */
> if (sg_cpu->iowait_boost) {
> - sg_cpu->iowait_boost <<= 1;
> - if (sg_cpu->iowait_boost > sg_cpu->iowait_boost_max)
> - sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
> + sg_cpu->iowait_boost = min(sg_cpu->iowait_boost << 1,
> SCHED_CAPACITY_SCALE);
> return;
> }
>
> /* First wakeup after IO: start with minimum boost */
> - sg_cpu->iowait_boost = sg_cpu->sg_policy->policy->min;
> + sg_cpu->iowait_boost = sg_cpu->min;
> }
>
> /**
> @@ -373,47 +370,38 @@ static void sugov_iowait_boost(struct sugov_cpu
> *sg_cpu, u64 time,
> * This mechanism is designed to boost high frequently IO waiting tasks,
> while
> * being more conservative on tasks which does sporadic IO operations.
> */
> -static void sugov_iowait_apply(struct sugov_cpu *sg_cpu, u64 time,
> - unsigned long *util, unsigned long *max)
> +static unsigned long sugov_iowait_apply(struct sugov_cpu *sg_cpu, u64 time,
> + unsigned long util, unsigned long max)
> {
> - unsigned int boost_util, boost_max;
> + unsigned long boost;
>
> /* No boost currently required */
> if (!sg_cpu->iowait_boost)
> - return;
> + return util;
>
> /* Reset boost if the CPU appears to have been idle enough */
> if (sugov_iowait_reset(sg_cpu, time, false))
> - return;
> + return util;
>
> - /*
> -* An IO waiting task has just woken up:
> -* allow to further double the boost value
> -*/
> - if (sg_cpu->iowait_boost_pending) {
> - sg_cpu->iowait_boost_pending = false;
> - } else {
> + if (!sg_cpu->iowait_boost_pending) {
> /*
> -* Otherwise: reduce the boost value and disable it when we
> -* reach the minimum.
> +* No boost pending; reduce the boost value.
> */
> sg_cpu->iowait_boost >>= 1;
> - if (sg_cpu->iowait_boost < sg_cpu->sg_policy->policy->min) {
> + if (sg_cpu->iowait_boost < sg_cpu->min) {
> sg_cpu->iowait_boost = 0;
> - return;
> + return util;
> }
> }
>
> + sg_cpu->iowait_boost_pending = false;
> +
> /*
> -* Apply the current boost value: a CPU is boosted only if its current
> -* utilization is smaller then the current IO boost level.
> +* @util is already in capacity scale; convert iowait_boost
> +* into the same scale so we can compare.
> */
> - boost_util = sg_cpu->iowait_boost;
> - boost_max =
Re: [PATCH v5 4/8] dt-bindings: devfreq: add Exynos5422 DMC device description
Hi Lukasz,
On 19. 3. 6. 오후 4:14, Lukasz Luba wrote:
> Hi Chanwoo,
>
> On 3/6/19 5:18 AM, Chanwoo Choi wrote:
>> Hi Lukasz,
>>
>> On 19. 3. 5. 오후 7:19, Lukasz Luba wrote:
>>> The patch adds description for DT binding for a new Exynos5422 Dynamic
>>> Memory Controller device.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> .../devicetree/bindings/devfreq/exynos5422-dmc.txt | 177
>>> +
>>> 1 file changed, 177 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>> b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>> new file mode 100644
>>> index 000..0e73e98
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>> @@ -0,0 +1,177 @@
>>> +* Exynos5422 frequency and voltage scaling for Dynamic Memory Controller
>>> device
>>> +
>>> +The Samsung Exynos5422 SoC has DMC (Dynamic Memory Controller) to which
>>> the DRAM
>>> +memory chips are connected. The driver is to monitor the controller in
>>> runtime
>>> +and switch frequency and voltage. To monitor the usage of the controller in
>>> +runtime, the driver uses the PPMU (Platform Performance Monitoring Unit),
>>> which
>>> +is able to measure the current load of the memory.
>>> +When 'userspace' governor is used for the driver, an application is able to
>>> +switch the DMC frequency.
>>> +
>>> +Required properties for DMC device for Exynos5422:
>>> +- compatible: Should be "samsung,exynos5422-bus".
>>> +- clock-names : the name of clock used by the bus, "bus".
>>> +- clocks : phandles for clock specified in "clock-names" property.
>>> +- devfreq-events : phandles for PPMU devices connected to this DMC.
>>
>>
>> I already replied with following comments on v4 patch[1].
>> But, you didn't reply anything. We can reduce the duplicate
>> review by keeping the basic review rule.
> I have lost these changes while I was adding the OPPs, timings into the
> dt-binding.
>>
>> - Re: [PATCH v4 5/8] dt-bindings: devfreq: add Exynos5422 DMC device
>> description
>> [1] https://do-db2.lkml.org/lkml/2019/2/3/64
>>
>>
>> [Following comments were replied on v4 patch[1]]
>>
>>> +- compatible: Should be "samsung,exynos5422-bus".
>>
>> The compatible name is wrong.
>> - exynos5422-bus -> exynos5422-dmc
>>
>>> +- clock-names : the name of clock used by the bus, "bus".
>>
>> 'bus' is right?
> right
As I knew, the clocks of exynos5422-dmc is for DMC.
Why do you think 'bus' is right insted of DMC?.
I think that it is not a 'bus' driver.
>>
>>> +- clocks : phandles for clock specified in "clock-names" property.
>>> +- devfreq-events : phandles for PPMU devices connected to this DMC.
>>
>> The dt-binging file doesn't contain the any description for 'reg' properties.
> There are 3 regs: cdrex0, cdrex1, chip_id. I will add this description.
>
> The patch set has this OPPs and timings coming from DT as you requested
> but I am not sure if it is in the right place in the DT.
> Thus dt-binding you may consider as 'in-progress' till the DT entries
> are fixed
>
> Regards,
> Lukasz
>>
>>
>>
>>> +
>>> +The example definition of a DMC and PPMU devices declared in DT is shown
>>> below:
>>> +
>>> + ppmu_dmc0_0: ppmu@10d0 {
>>> + compatible = "samsung,exynos-ppmu";
>>> + reg = <0x10d0 0x2000>;
>>> + clocks = < CLK_PCLK_PPMU_DREX0_0>;
>>> + clock-names = "ppmu";
>>> + status = "okay";
>>> + events {
>>> + ppmu_event_dmc0_0: ppmu-event3-dmc0_0 {
>>> + event-name = "ppmu-event3-dmc0_0";
>>> + };
>>> + };
>>> + };
>>> +
>>> +
>>> + ppmu_dmc0_1: ppmu@10d1 {
>>> + compatible = "samsung,exynos-ppmu";
>>> + reg = <0x10d1 0x2000>;
>>> + clocks = < CLK_PCLK_PPMU_DREX0_1>;
>>> + clock-names = "ppmu";
>>> + status = "okay";
>>> + events {
>>> + ppmu_event_dmc0_1: ppmu-event3-dmc0_1 {
>>> + event-name = "ppmu-event3-dmc0_1";
>>> + };
>>> + };
>>> + };
>>> +
>>> + ppmu_dmc1_0: ppmu@10d1 {
>>> + compatible = "samsung,exynos-ppmu";
>>> + reg = <0x10d6 0x2000>;
>>> + clocks = < CLK_PCLK_PPMU_DREX1_0>;
>>> + clock-names = "ppmu";
>>> + status = "okay";
>>> + events {
>>> + ppmu_event_dmc1_0: ppmu-event3-dmc1_0 {
>>> + event-name = "ppmu-event3-dmc1_0";
>>> + };
>>> + };
>>> + };
>>> +
>>> + ppmu_dmc1_1: ppmu@10d7 {
>>> + compatible = "samsung,exynos-ppmu";
>>> + reg = <0x10d7 0x2000>;
>>> + clocks = < CLK_PCLK_PPMU_DREX1_1>;
>>> + clock-names = "ppmu";
>>> + status = "okay";
>>> + events {
>>> +
[GIT PULL] scheduler updates for v5.1
Linus,
Please pull the latest sched-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-core-for-linus
# HEAD: ad01423aedaa7c6dd62d560b73a3cb39e6da3901 kthread: Do not use
TIMER_IRQSAFE
The main changes in this cycle were:
- refcount conversions
- Solve the rq->leaf_cfs_rq_list can of worms for real.
- improve power-aware scheduling
- add sysctl knob for Energy Aware Scheduling
- documentation updates
- misc other changes
Thanks,
Ingo
-->
Andrea Parri (1):
sched/core: Use READ_ONCE()/WRITE_ONCE() in
move_queued_task()/task_rq_lock()
Dietmar Eggemann (1):
sched/fair: Simplify post_init_entity_util_avg() by calling it with a
task_struct pointer argument
Elena Reshetova (5):
sched/core: Convert sighand_struct.count to refcount_t
sched/core: Convert signal_struct.sigcnt to refcount_t
sched/fair: Convert numa_group.refcount to refcount_t
sched/core: Convert task_struct.usage to refcount_t
sched/core: Convert task_struct.stack_refcount to refcount_t
Hidetoshi Seto (1):
sched/debug: Initialize sd_sysctl_cpus if !CONFIG_CPUMASK_OFFSTACK
Hugo Lefeuvre (1):
sched/wait: Use freezable_schedule() when possible
Julia Cartwright (1):
kthread: Convert worker lock to raw spinlock
Luc Van Oostenryck (1):
sched/topology: Fix percpu data types in struct sd_data & struct s_data
Lukas Bulwahn (1):
MAINTAINERS, sched: Drop PREEMPTIBLE KERNEL section entry
Peter Zijlstra (3):
sched/core: Give DCE a fighting chance
sched/fair: Robustify CFS-bandwidth timer locking
sched/fair: Add tmp_alone_branch assertion
Quentin Perret (3):
sched/topology: Introduce a sysctl for Energy Aware Scheduling
PM/EM: Document the Energy Model framework
sched/doc: Document Energy Aware Scheduling
Sebastian Andrzej Siewior (1):
kthread: Do not use TIMER_IRQSAFE
Thomas Gleixner (1):
sched: Remove stale PF_MUTEX_TESTER bit
Valentin Schneider (3):
sched/fair: Simplify nohz_balancer_kick()
sched/fair: Explain LLC nohz kick condition
sched/fair: Prune, fix and simplify the nohz_balancer_kick() comment block
Vincent Guittot (9):
sched/fair: Trigger asym_packing during idle load balance
sched/fair: Fix rounding bug for asym packing
sched/fair: Fix unnecessary increase of balance interval
sched/fair: Move the rq_of() helper function
sched/fair: Update scale invariance of PELT
sched/pelt: Skip updating util_est when utilization is higher than CPU's
capacity
sched/fair: Fix insertion in rq->leaf_cfs_rq_list
sched/fair: Optimize update_blocked_averages()
sched/fair: Fix O(nr_cgroups) in the load balancing path
Viresh Kumar (2):
sched/fair: Remove unused 'sd' parameter from select_idle_smt()
sched/fair: Use non-atomic cpumask_{set,clear}_cpu()
Documentation/power/energy-model.txt | 144 ++
Documentation/scheduler/sched-energy.txt | 425
Documentation/sysctl/kernel.txt | 12 +
MAINTAINERS | 9 +-
fs/exec.c| 4 +-
fs/proc/task_nommu.c | 2 +-
include/linux/init_task.h| 1 +
include/linux/kthread.h | 9 +-
include/linux/sched.h| 33 +--
include/linux/sched/signal.h | 5 +-
include/linux/sched/sysctl.h | 7 +
include/linux/sched/task.h | 4 +-
include/linux/sched/task_stack.h | 2 +-
include/linux/sched/topology.h | 8 +-
include/linux/wait.h | 6 +-
init/init_task.c | 6 +-
kernel/fork.c| 24 +-
kernel/kthread.c | 43 +--
kernel/sched/core.c | 12 +-
kernel/sched/deadline.c | 6 +-
kernel/sched/debug.c | 4 +
kernel/sched/fair.c | 458 ++-
kernel/sched/isolation.c | 2 +-
kernel/sched/pelt.c | 45 +--
kernel/sched/pelt.h | 114 +++-
kernel/sched/rt.c| 6 +-
kernel/sched/sched.h | 54 +++-
kernel/sched/topology.c | 33 ++-
kernel/sysctl.c | 11 +
29 files changed, 1165 insertions(+), 324 deletions(-)
create mode 100644 Documentation/power/energy-model.txt
create mode 100644 Documentation/scheduler/sched-energy.txt
Re: [PATCH] staging/board/board.c: Fix compiler error of_find_all_nodes()
Change the subsystem prefix to: [PATCH] Staging: board: ... On Tue, Mar 05, 2019 at 11:39:30PM +, Arnold J Chand wrote: > Fix implicit-function-declaration error by 'extern'-ing the function in > the file > > Signed-off-by: Arnold Chand > --- > drivers/staging/board/board.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/staging/board/board.c b/drivers/staging/board/board.c > index cb6feb34dd40..3025ee9f5517 100644 > --- a/drivers/staging/board/board.c > +++ b/drivers/staging/board/board.c > @@ -22,6 +22,8 @@ > static struct device_node *irqc_node __initdata; > static unsigned int irqc_base __initdata; > > +extern struct device_node *of_find_all_nodes(struct device_node *prev); > + We already include so what's going on here? The driver compiles for me. Anyway, fix the includes, don't do this. regards, dan carpenter
Re: KASAN: use-after-free Read in get_mem_cgroup_from_mm
On 2019/3/6 14:26, Mike Rapoport wrote: > Hi, > > On Wed, Mar 06, 2019 at 01:53:12PM +0800, zhong jiang wrote: >> On 2019/3/6 10:05, Andrea Arcangeli wrote: >>> Hello everyone, >>> >>> [ CC'ed Mike and Peter ] >>> >>> On Tue, Mar 05, 2019 at 02:42:00PM +0800, zhong jiang wrote: On 2019/3/5 14:26, Dmitry Vyukov wrote: > On Mon, Mar 4, 2019 at 4:32 PM zhong jiang wrote: >> On 2019/3/4 22:11, Dmitry Vyukov wrote: >>> On Mon, Mar 4, 2019 at 3:00 PM zhong jiang >>> wrote: On 2019/3/4 15:40, Dmitry Vyukov wrote: > On Sun, Mar 3, 2019 at 5:19 PM zhong jiang > wrote: >> Hi, guys >> >> I also hit the following issue. but it fails to reproduce the issue >> by the log. >> >> it seems to the case that we access the mm->owner and deference it >> will result in the UAF. >> But it should not be possible that we specify the incomplete process >> to be the mm->owner. >> >> Any thoughts? > FWIW syzbot was able to reproduce this with this reproducer. > This looks like a very subtle race (threaded reproducer that runs > repeatedly in multiple processes), so most likely we are looking for > something like few instructions inconsistency window. > I has a little doubtful about the instrustions inconsistency window. I guess that you mean some smb barriers should be taken into account.:-) Because IMO, It should not be the lock case to result in the issue. >>> Since the crash was triggered on x86 _most likley_ this is not a >>> missed barrier. What I meant is that one thread needs to executed some >>> code, while another thread is stopped within few instructions. >>> >>> >> It is weird and I can not find any relationship you had said with the >> issue.:-( >> >> Because It is the cause that mm->owner has been freed, whereas we still >> deference it. >> >> From the lastest freed task call trace, It fails to create process. >> >> Am I miss something or I misunderstand your meaning. Please correct me. > Your analysis looks correct. I am just saying that the root cause of > this use-after-free seems to be a race condition. > > > Yep, Indeed, I can not figure out how the race works. I will dig up further. >>> Yes it's a race condition. >>> >>> We were aware about the non-cooperative fork userfaultfd feature >>> creating userfaultfd file descriptor that gets reported to the parent >>> uffd, despite they belong to mm created by failed forks. >>> >>> https://www.spinics.net/lists/linux-mm/msg136357.html >>> >> Hi, Andrea >> >> I still not clear why uffd ioctl can use the incomplete process as the >> mm->owner. >> and how to produce the race. > There is a C reproducer in the syzcaller report: > > https://syzkaller.appspot.com/x/repro.c?x=172fa5a340 > >> From your above explainations, My underdtanding is that the process >> handling do_exexve >> will have a temporary mm, which will be used by the UUFD ioctl. > The race is between userfaultfd operation and fork() failure: > > forking thread | userfaultfd monitor thread > +--- > fork() | > dup_mmap()| > dup_userfaultfd() | > dup_userfaultfd_complete() | > | read(UFFD_EVENT_FORK) > | uffdio_copy() > |mmget_not_zero() > goto bad_fork_something | > ... | > bad_fork_free: | > free_task() | > | mem_cgroup_from_task() > | /* access stale mm->owner */ > Hi, Mike forking thread fails to create the process ,and then free the allocated task struct. Other userfaultfd monitor thread should not access the stale mm->owner. The parent process and child process do not share the mm struct. Userfaultfd monitor thread's mm->owner should not point to the freed child task_struct. and due to the existence of tasklist_lock, we can not specify the mm->owner to freed task_struct. I miss something,=-O Thanks, zhong jiang >> Thanks, >> zhong jiang
Re: [PATCH v5 4/8] dt-bindings: devfreq: add Exynos5422 DMC device description
Hi Krzysztof,
On 3/5/19 12:35 PM, Krzysztof Kozlowski wrote:
> On Tue, 5 Mar 2019 at 11:19, Lukasz Luba wrote:
>>
>> The patch adds description for DT binding for a new Exynos5422 Dynamic
>> Memory Controller device.
>>
>> Signed-off-by: Lukasz Luba
>> ---
>> .../devicetree/bindings/devfreq/exynos5422-dmc.txt | 177
>> +
>> 1 file changed, 177 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>> b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>> new file mode 100644
>> index 000..0e73e98
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>> @@ -0,0 +1,177 @@
>> +* Exynos5422 frequency and voltage scaling for Dynamic Memory Controller
>> device
>> +
>> +The Samsung Exynos5422 SoC has DMC (Dynamic Memory Controller) to which the
>> DRAM
>> +memory chips are connected. The driver is to monitor the controller in
>> runtime
>> +and switch frequency and voltage. To monitor the usage of the controller in
>> +runtime, the driver uses the PPMU (Platform Performance Monitoring Unit),
>> which
>> +is able to measure the current load of the memory.
>> +When 'userspace' governor is used for the driver, an application is able to
>> +switch the DMC frequency.
>> +
>> +Required properties for DMC device for Exynos5422:
>> +- compatible: Should be "samsung,exynos5422-bus".
>> +- clock-names : the name of clock used by the bus, "bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- devfreq-events : phandles for PPMU devices connected to this DMC.
>> +
>> +The example definition of a DMC and PPMU devices declared in DT is shown
>> below:
>> +
>> + ppmu_dmc0_0: ppmu@10d0 {
>> + compatible = "samsung,exynos-ppmu";
>> + reg = <0x10d0 0x2000>;
>> + clocks = < CLK_PCLK_PPMU_DREX0_0>;
>> + clock-names = "ppmu";
>> + status = "okay";
>> + events {
>> + ppmu_event_dmc0_0: ppmu-event3-dmc0_0 {
>> + event-name = "ppmu-event3-dmc0_0";
>> + };
>> + };
>> + };
>> +
>> +
>> + ppmu_dmc0_1: ppmu@10d1 {
>> + compatible = "samsung,exynos-ppmu";
>> + reg = <0x10d1 0x2000>;
>> + clocks = < CLK_PCLK_PPMU_DREX0_1>;
>> + clock-names = "ppmu";
>> + status = "okay";
>> + events {
>> + ppmu_event_dmc0_1: ppmu-event3-dmc0_1 {
>> + event-name = "ppmu-event3-dmc0_1";
>> + };
>> + };
>> + };
>> +
>> + ppmu_dmc1_0: ppmu@10d1 {
>> + compatible = "samsung,exynos-ppmu";
>> + reg = <0x10d6 0x2000>;
>> + clocks = < CLK_PCLK_PPMU_DREX1_0>;
>> + clock-names = "ppmu";
>> + status = "okay";
>> + events {
>> + ppmu_event_dmc1_0: ppmu-event3-dmc1_0 {
>> + event-name = "ppmu-event3-dmc1_0";
>> + };
>> + };
>> + };
>> +
>> + ppmu_dmc1_1: ppmu@10d7 {
>> + compatible = "samsung,exynos-ppmu";
>> + reg = <0x10d7 0x2000>;
>> + clocks = < CLK_PCLK_PPMU_DREX1_1>;
>> + clock-names = "ppmu";
>> + status = "okay";
>> + events {
>> + ppmu_event_dmc1_1: ppmu-event3-dmc1_1 {
>> + event-name = "ppmu-event3-dmc1_1";
>> + };
>> + };
>> + };
>> +
>> + dmc: memory-controller@10c2 {
>> + compatible = "samsung,exynos5422-dmc";
>> + reg = <0x10c2 0x1>, <0x10c3 0x1>,
>> + <0x1000 0x1000>;
>> + clocks =< CLK_FOUT_SPLL>,
>> + < CLK_MOUT_SCLK_SPLL>,
>> + < CLK_FF_DOUT_SPLL2>,
>> + < CLK_FOUT_BPLL>,
>> + < CLK_MOUT_BPLL>,
>> + < CLK_SCLK_BPLL>,
>> + < CLK_MOUT_MX_MSPLL_CCORE>,
>> + < CLK_MOUT_MX_MSPLL_CCORE_PHY>,
>> + < CLK_MOUT_MCLK_CDREX>,
>> + < CLK_DOUT_CLK2X_PHY0>,
>> + < CLK_CLKM_PHY0>,
>> + < CLK_CLKM_PHY1>,
>> + < CLK_CDREX_PAUSE>,
>> + < CLK_CDREX_TIMING_SET>;
>> + clock-names = "fout_spll",
>> + "mout_sclk_spll",
>> +
Re: Banana Pi-R1 stabil
On Tue, Mar 05, 2019 at 08:21:02PM +0100, Gerhard Wiesinger wrote: > > > > Run > > > > https://github.com/ssvb/cpuburn-arm/blob/master/cpufreq-ljt-stress-test > > > > > > > > > But it doesn't explaing that it works with kernel 4.7.4 without any > > > > > problems. > > > > My best guess would be that cpufreq wasn't enabled at that time, or > > > > without voltage scaling. > > > > > > > Where can I see the voltage scaling parameters? > > > > > > on DTS I don't see any difference between kernel 4.7.4 and 4.20.10 > > > regarding > > > voltage: > > > > > > dtc -I dtb -O dts -o > > > /boot/dtb-4.20.10-200.fc29.armv7hl/sun7i-a20-lamobo-r1.dts > > > /boot/dtb-4.20.10-200.fc29.armv7hl/sun7i-a20-lamobo-r1.dtb > > This can be also due to configuration being changed, driver support, etc. > > Where will the voltages for scaling then be set in detail (drivers, etc.)? The operating points are in the DT, but how to change it (cpufreq drivers, clock drivers, regulators drivers) aren't, and the configuration will tell if those drivers are included, and which governor is going to be the default. > > > There is another strange thing (tested with > > > kernel-5.0.0-0.rc8.git1.1.fc31.armv7hl, kernel-4.19.8-300.fc29.armv7hl, > > > kernel-4.20.13-200.fc29.armv7hl, kernel-4.20.10-200.fc29.armv7hl): > > > > > > There is ALWAYS high CPU of around 10% in kworker: > > > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > > 18722 root 20 0 0 0 0 I 9.5 0.0 0:47.52 > > > [kworker/1:3-events_freezable_power_] > > > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > > 776 root 20 0 0 0 0 I 8.6 0.0 0:02.77 > > > [kworker/0:4-events] > > The first one looks like it's part of the workqueue code. > > Any guessed reason for that? None, I'm not familiar with the workqueue code. > > > BTW: Still stable at aboout 2,5days on both devices. So solution IS the > > > performance governor. > > No, the performance governor prevents any change in frequency. My > > guess is that a lower frequency operating point is not working and is > > crashing the CPU. > > > > Yes, there might at least 2 scenarios: > > 1.) Frequency switching itself is the problem But that code is also the one being used by the BananaPro, which you reported as stable. > 2.) lower frequency/voltage operating points are not stable. > > For both scenarios: it might be possible that the crash happens on idle CPU, > high CPU load or just randomly. Therefore just "waiting" might be better > than 100% CPU utilization.But will test also 100% CPU. > > Therefore it would be good to see where the voltages for different > frequencies for the SoC are defined (to compare). In the device tree. > I'm currently testing 2 different settings on the 2 new Banana Pi R1 with > newest kernel (see below), so 2 static frequencies: > > # Set to specific frequency 144000 (currently testing on Banana Pi R1 #1) > > # Set to specific frequency 312000 (currently testing on Banana Pi R1 #2) > > If that's fine I'll test also further frequencies (with different loads). Look, you can come up with whatever program you want for this, but if I insist on running that cpustress program (for the 4th time now), is that it's actually good at it and caught all the cpufreq issues we've seen so far. Feel free to not trust me on this, but I'm not sure how the discussion can continue if you do. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[PATCH] xfrm: Reset secpath in xfrm failure
In esp4_gro_receive() and esp6_gro_receive(), secpath can be allocated
without adding xfrm state to xvec. Then, sp->xvec[sp->len - 1] would
fail and result in dereferencing invalid pointer in esp4_gso_segment()
and esp6_gso_segment(). Reset secpath if xfrm function returns error.
Reported-by: syzbot+b69368fd933c6c592...@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung
---
net/ipv4/esp4_offload.c | 9 +++--
net/ipv6/esp6_offload.c | 9 +++--
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/esp4_offload.c b/net/ipv4/esp4_offload.c
index 8756e0e790d2..7329e40c73f6 100644
--- a/net/ipv4/esp4_offload.c
+++ b/net/ipv4/esp4_offload.c
@@ -51,14 +51,18 @@ static struct sk_buff *esp4_gro_receive(struct list_head
*head,
if (!sp)
goto out;
- if (sp->len == XFRM_MAX_DEPTH)
+ if (sp->len == XFRM_MAX_DEPTH) {
+ secpath_reset(skb);
goto out;
+ }
x = xfrm_state_lookup(dev_net(skb->dev), skb->mark,
(xfrm_address_t *)_hdr(skb)->daddr,
spi, IPPROTO_ESP, AF_INET);
- if (!x)
+ if (!x) {
+ secpath_reset(skb);
goto out;
+ }
sp->xvec[sp->len++] = x;
sp->olen++;
@@ -66,6 +70,7 @@ static struct sk_buff *esp4_gro_receive(struct list_head
*head,
xo = xfrm_offload(skb);
if (!xo) {
xfrm_state_put(x);
+ secpath_reset(skb);
goto out;
}
}
diff --git a/net/ipv6/esp6_offload.c b/net/ipv6/esp6_offload.c
index d46b4eb645c2..399c688d192e 100644
--- a/net/ipv6/esp6_offload.c
+++ b/net/ipv6/esp6_offload.c
@@ -73,14 +73,18 @@ static struct sk_buff *esp6_gro_receive(struct list_head
*head,
if (!sp)
goto out;
- if (sp->len == XFRM_MAX_DEPTH)
+ if (sp->len == XFRM_MAX_DEPTH) {
+ secpath_reset(skb);
goto out;
+ }
x = xfrm_state_lookup(dev_net(skb->dev), skb->mark,
(xfrm_address_t *)_hdr(skb)->daddr,
spi, IPPROTO_ESP, AF_INET6);
- if (!x)
+ if (!x) {
+ secpath_reset(skb);
goto out;
+ }
sp->xvec[sp->len++] = x;
sp->olen++;
@@ -88,6 +92,7 @@ static struct sk_buff *esp6_gro_receive(struct list_head
*head,
xo = xfrm_offload(skb);
if (!xo) {
xfrm_state_put(x);
+ secpath_reset(skb);
goto out;
}
}
--
2.17.1
[PATCH v3 1/2] iio/chemical/bme680: Report temperature in millidegrees
The standard unit for temperature is millidegrees Celcius. Adapt the
driver to report in millidegrees instead of degrees.
Signed-off-by: Mike Looijmans
---
v2: Remove unused 'addr7' variable
v3: Split patch into temperature and SPI
drivers/iio/chemical/bme680_core.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/chemical/bme680_core.c
b/drivers/iio/chemical/bme680_core.c
index 70c1fe4..fefe32b 100644
--- a/drivers/iio/chemical/bme680_core.c
+++ b/drivers/iio/chemical/bme680_core.c
@@ -583,8 +583,7 @@ static int bme680_gas_config(struct bme680_data *data)
return ret;
}
-static int bme680_read_temp(struct bme680_data *data,
- int *val, int *val2)
+static int bme680_read_temp(struct bme680_data *data, int *val)
{
struct device *dev = regmap_get_device(data->regmap);
int ret;
@@ -617,10 +616,9 @@ static int bme680_read_temp(struct bme680_data *data,
* compensate_press/compensate_humid to get compensated
* pressure/humidity readings.
*/
- if (val && val2) {
- *val = comp_temp;
- *val2 = 100;
- return IIO_VAL_FRACTIONAL;
+ if (val) {
+ *val = comp_temp * 10; /* Centidegrees to millidegrees */
+ return IIO_VAL_INT;
}
return ret;
@@ -635,7 +633,7 @@ static int bme680_read_press(struct bme680_data *data,
s32 adc_press;
/* Read and compensate temperature to get a reading of t_fine */
- ret = bme680_read_temp(data, NULL, NULL);
+ ret = bme680_read_temp(data, NULL);
if (ret < 0)
return ret;
@@ -668,7 +666,7 @@ static int bme680_read_humid(struct bme680_data *data,
u32 comp_humidity;
/* Read and compensate temperature to get a reading of t_fine */
- ret = bme680_read_temp(data, NULL, NULL);
+ ret = bme680_read_temp(data, NULL);
if (ret < 0)
return ret;
@@ -761,7 +759,7 @@ static int bme680_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_PROCESSED:
switch (chan->type) {
case IIO_TEMP:
- return bme680_read_temp(data, val, val2);
+ return bme680_read_temp(data, val);
case IIO_PRESSURE:
return bme680_read_press(data, val, val2);
case IIO_HUMIDITYRELATIVE:
--
1.9.1
[PATCH v3 2/2] iio/chemical/bme680: Fix SPI read interface
The SPI interface implementation was completely broken.
When using the SPI interface, there are only 7 address bits, the upper bit
is controlled by a page select register. The core needs access to both
ranges, so implement register read/write for both regions. The regmap
paging functionality didn't agree with a register that needs to be read
and modified, so I implemented a custom paging algorithm.
This fixes that the device wouldn't even probe in SPI mode.
The SPI interface then isn't different from I2C, merged them into the core,
and the I2C/SPI named registers are no longer needed.
Implemented register value caching for the registers to reduce the I2C/SPI
data transfers considerably.
The calibration set reads as all zeroes until some undefined point in time,
and I couldn't determine what makes it valid. The datasheet mentions these
registers but does not provide any hints on when they become valid, and they
aren't even enumerated in the memory map. So check the calibration and
retry reading it from the device after each measurement until it provides
something valid.
Signed-off-by: Mike Looijmans
---
v2: Remove unused 'addr7' variable
v3: Split patch into temperature and SPI
drivers/iio/chemical/bme680.h | 6 +-
drivers/iio/chemical/bme680_core.c | 38
drivers/iio/chemical/bme680_i2c.c | 21 ---
drivers/iio/chemical/bme680_spi.c | 115 +
4 files changed, 118 insertions(+), 62 deletions(-)
diff --git a/drivers/iio/chemical/bme680.h b/drivers/iio/chemical/bme680.h
index 0ae89b87..4edc5d21 100644
--- a/drivers/iio/chemical/bme680.h
+++ b/drivers/iio/chemical/bme680.h
@@ -2,11 +2,9 @@
#ifndef BME680_H_
#define BME680_H_
-#define BME680_REG_CHIP_I2C_ID 0xD0
-#define BME680_REG_CHIP_SPI_ID 0x50
+#define BME680_REG_CHIP_ID 0xD0
#define BME680_CHIP_ID_VAL 0x61
-#define BME680_REG_SOFT_RESET_I2C 0xE0
-#define BME680_REG_SOFT_RESET_SPI 0x60
+#define BME680_REG_SOFT_RESET 0xE0
#define BME680_CMD_SOFTRESET 0xB6
#define BME680_REG_STATUS 0x73
#define BME680_SPI_MEM_PAGE_BIT BIT(4)
diff --git a/drivers/iio/chemical/bme680_core.c
b/drivers/iio/chemical/bme680_core.c
index fefe32b..ccde4c6 100644
--- a/drivers/iio/chemical/bme680_core.c
+++ b/drivers/iio/chemical/bme680_core.c
@@ -63,9 +63,23 @@ struct bme680_data {
s32 t_fine;
};
+static const struct regmap_range bme680_volatile_ranges[] = {
+ regmap_reg_range(BME680_REG_MEAS_STAT_0, BME680_REG_GAS_R_LSB),
+ regmap_reg_range(BME680_REG_STATUS, BME680_REG_STATUS),
+ regmap_reg_range(BME680_T2_LSB_REG, BME680_GH3_REG),
+};
+
+static const struct regmap_access_table bme680_volatile_table = {
+ .yes_ranges = bme680_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(bme680_volatile_ranges),
+};
+
const struct regmap_config bme680_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
+ .max_register = 0xef,
+ .volatile_table = _volatile_table,
+ .cache_type = REGCACHE_RBTREE,
};
EXPORT_SYMBOL(bme680_regmap_config);
@@ -316,6 +330,10 @@ static s16 bme680_compensate_temp(struct bme680_data *data,
s64 var1, var2, var3;
s16 calc_temp;
+ /* If the calibration is invalid, attempt to reload it */
+ if (!calib->par_t2)
+ bme680_read_calib(data, calib);
+
var1 = (adc_temp >> 3) - (calib->par_t1 << 1);
var2 = (var1 * calib->par_t2) >> 11;
var3 = ((var1 >> 1) * (var1 >> 1)) >> 12;
@@ -865,8 +883,28 @@ int bme680_core_probe(struct device *dev, struct regmap
*regmap,
{
struct iio_dev *indio_dev;
struct bme680_data *data;
+ unsigned int val;
int ret;
+ ret = regmap_write(regmap, BME680_REG_SOFT_RESET,
+ BME680_CMD_SOFTRESET);
+ if (ret < 0) {
+ dev_err(dev, "Failed to reset chip\n");
+ return ret;
+ }
+
+ ret = regmap_read(regmap, BME680_REG_CHIP_ID, );
+ if (ret < 0) {
+ dev_err(dev, "Error reading chip ID\n");
+ return ret;
+ }
+
+ if (val != BME680_CHIP_ID_VAL) {
+ dev_err(dev, "Wrong chip ID, got %x expected %x\n",
+ val, BME680_CHIP_ID_VAL);
+ return -ENODEV;
+ }
+
indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
if (!indio_dev)
return -ENOMEM;
diff --git a/drivers/iio/chemical/bme680_i2c.c
b/drivers/iio/chemical/bme680_i2c.c
index 06d4be5..cfc4449 100644
--- a/drivers/iio/chemical/bme680_i2c.c
+++ b/drivers/iio/chemical/bme680_i2c.c
@@ -23,8 +23,6 @@ static int bme680_i2c_probe(struct i2c_client *client,
{
struct regmap *regmap;
const char *name = NULL;
- unsigned int val;
- int ret;
regmap =
Re: [Xen-devel] [PATCH v4.9 1/1] jiffies: use jiffies64_to_nsecs() to fix 100% steal usage for xen vcpu hotplug
Thanks to Joe Jin's reminding, this patch is applicable to mainline linux
kernel, although there is no issue due to this kind of bug in mainline kernel.
Therefore, can I first submit this patch to mainline kernel and then backport it
to stable linux with more detailed explanation how the issue is reproduced on
xen?
This would help synchronize stable with mainline better.
Thank you very much!
Dongli Zhang
On 3/5/19 3:59 PM, Dongli Zhang wrote:
> [ Not relevant upstream, therefore no upstream commit. ]
>
> To fix, use jiffies64_to_nsecs() directly instead of deriving the result
> according to jiffies_to_usecs().
>
> As the return type of jiffies_to_usecs() is 'unsigned int', when the return
> value is more than the size of 'unsigned int', the leading 32 bits would be
> discarded.
>
> Suppose USEC_PER_SEC=100L and HZ=1000, below are the expected and
> actual incorrect result of jiffies_to_usecs(0x7770ef70):
>
> - expected : jiffies_to_usecs(0x7770ef70) = 0x01d291274d80
> - incorrect : jiffies_to_usecs(0x7770ef70) = 0x91274d80
>
> The leading 0x01d2 is discarded.
>
> After xen vcpu hotplug and when the new vcpu steal clock is calculated for
> the first time, the result of this_rq()->prev_steal_time in
> steal_account_process_tick() would be far smaller than the expected
> value, due to that jiffies_to_usecs() discards the leading 32 bits.
>
> As a result, the diff between current steal and this_rq()->prev_steal_time
> is always very large. Steal usage would become 100% when the initial steal
> clock obtained from xen hypervisor is very large during xen vcpu hotplug,
> that is, when the guest is already up for a long time.
>
> The bug can be detected by doing the following:
>
> * Boot xen guest with vcpus=2 and maxvcpus=4
> * Leave the guest running for a month so that the initial steal clock for
> the new vcpu would be very large
> * Hotplug 2 extra vcpus
> * The steal time of new vcpus in /proc/stat would increase abnormally and
> sometimes steal usage in top can become 100%
>
> This was incidentally fixed in the patch set starting by
> commit 93825f2ec736 ("jiffies: Reuse TICK_NSEC instead of NSEC_PER_JIFFY")
> and ended with
> commit b672592f0221 ("sched/cputime: Remove generic asm headers").
>
> This version applies to the v4.9 series.
>
> Link: https://lkml.org/lkml/2019/2/28/1373
> Suggested-by: Juergen Gross
> Signed-off-by: Dongli Zhang
> ---
> include/linux/jiffies.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
> index 734377a..94aff43 100644
> --- a/include/linux/jiffies.h
> +++ b/include/linux/jiffies.h
> @@ -287,13 +287,13 @@ extern unsigned long preset_lpj;
> extern unsigned int jiffies_to_msecs(const unsigned long j);
> extern unsigned int jiffies_to_usecs(const unsigned long j);
>
> +extern u64 jiffies64_to_nsecs(u64 j);
> +
> static inline u64 jiffies_to_nsecs(const unsigned long j)
> {
> - return (u64)jiffies_to_usecs(j) * NSEC_PER_USEC;
> + return jiffies64_to_nsecs(j);
> }
>
> -extern u64 jiffies64_to_nsecs(u64 j);
> -
> extern unsigned long __msecs_to_jiffies(const unsigned int m);
> #if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
> /*
>
[GIT PULL] perf changes for v5.1
Linus,
Please pull the latest perf-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus
# HEAD: c978b9460fe1d4a1e1effa0abd6bd69b18a098a8 Merge tag
'perf-core-for-mingo-5.1-20190225' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
Lots of tooling updates - too many to list, here's a few highlights:
- Various subcommand updates to 'perf trace', 'perf report',
'perf record', 'perf annotate', 'perf script', 'perf test', etc.
- CPU and NUMA topology and affinity handling improvements,
- HW tracing and HW support updates:
- Intel PT updates
- ARM CoreSight updates
- vendor HW event updates
- BPF updates
- Tons of infrastructure updates, both on the build system and the
library support side
- Documentation updates.
- ... and lots of other changes, see the changelog for details.
Kernel side updates:
- Tighten up kprobes blacklist handling, reduce the number of places
where developers can install a kprobe and hang/crash the system.
- Fix/enhance vma address filter handling.
- Various PMU driver updates, small fixes and additions.
- refcount_t conversions
- BPF updates
- error code propagation enhancements
- misc other changes.
NOTE: I'm really sorry about 306563985819 which got a weird title early
in the cycle and I'd have to rebase much of the tree to get rid of it.
Will rebase if it's unacceptable. :-/
Thanks,
Ingo
-->
Adrian Hunter (22):
perf tools: Fix split_kallsyms_for_kcore() for trampoline symbols
perf thread-stack: Tidy thread_stack__push_cp() usage
perf thread-stack: Tidy thread_stack__no_call_return() by adding more
local variables
perf thread-stack: Represent jmps to the start of a different symbol
perf auxtrace: Define auxtrace record alignment
perf intel-pt: Fix overlap calculation for padding
perf intel-pt: Fix CYC timestamp calculation after OVF
perf intel-pt: Packet splitting can happen only on 32-bit
perf auxtrace: Add timestamp to auxtrace errors
perf thread-stack: Improve thread_stack__no_call_return()
perf thread-stack: Hide x86 retpolines
perf scripts python: exported-sql-viewer.py: Fix missing shebang
perf scripts python: exported-sql-viewer.py: Remove leftover debugging
prints
perf scripts python: exported-sql-viewer.py: Hide Call Graph option if no
calls table
perf scripts python: exported-sql-viewer.py: Move column headers
perf scripts python: exported-sql-viewer.py: Factor out ReportDialogBase
perf scripts python: exported-sql-viewer.py: Factor out ReportVars
perf scripts python: exported-sql-viewer.py: Move report name into
ReportVars
perf scripts python: exported-sql-viewer.py: Create new dialog data item
classes
perf scripts python: exported-sql-viewer.py: Remove SQLTableDialogDataItem
perf scripts python: exported-sql-viewer.py: Remove no selection error
perf scripts python: exported-sql-viewer.py: Add top calls report
Alexander Shishkin (2):
perf: Copy parent's address filter offsets on clone
perf, pt, coresight: Fix address filters for vmas with non-zero offset
Alexey Budankov (4):
perf record: Allocate affinity masks
perf record: Bind the AIO user space buffers to nodes
perf record: Apply affinity masks when reading mmap buffers
perf record: Implement --affinity=node|cpu option
Andi Kleen (3):
perf/x86/kvm: Avoid unnecessary work in guest filtering
perf script: Handle missing fields with -F +..
perf tools: Add perf_exe() helper to find perf binary
Andrea Righi (1):
kprobes: Prohibit probing on bsearch()
Andrew Murray (12):
perf/doc: Update design.txt for exclude_{host|guest} flags
perf/core: Add function to test for event exclusion flags
perf/core: Add PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs
perf/core, arch/alpha: Strengthen exclusion checks with
PERF_PMU_CAP_NO_EXCLUDE
perf/core, arch/arm: Use PERF_PMU_CAP_NO_EXCLUDE conditionally
perf/core, arch/arm: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable
PMUs
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will prevent us from
handling events where any exclusion flags are set. Let's also remove the now
unnecessary check for exclusion flags.
perf/drivers: Strengthen exclusion checks with PERF_PMU_CAP_NO_EXCLUDE
perf/core, arch/powerpc: use PERF_PMU_CAP_NO_EXCLUDE for exclusion
incapable PMUs
perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable
PMUs
perf/core, arch/x86: Strengthen exclusion checks with
PERF_PMU_CAP_NO_EXCLUDE
perf/core: Remove unused perf_flags
Arnaldo Carvalho de Melo (54):
perf: Make perf_event_output() propagate the output() return
perf top:
Re: [PATCH v2] iio/chemical/bme680: Fix SPI read interface
On 03-03-19 17:57, Jonathan Cameron wrote:
> On Thu, 21 Feb 2019 10:20:49 +0100
> Mike Looijmans wrote:
>
>> The SPI interface implementation was completely broken.
>>
>> When using the SPI interface, there are only 7 address bits, the upper bit
>> is controlled by a page select register. The core needs access to both
>> ranges, so implement register read/write for both regions. The regmap
>> paging functionality didn't agree with a register that needs to be read
>> and modified, so I implemented a custom paging algorithm.
>>
>> This fixes that the device wouldn't even probe in SPI mode.
>>
>> The SPI interface then isn't different from I2C, merged them into the core,
>> and the I2C/SPI named registers are no longer needed.
>>
>> Implemented register value caching for the registers to reduce the I2C/SPI
>> data transfers considerably.
>>
>> The calibration set reads as all zeroes until some undefined point in time,
>> and I couldn't determine what makes it valid. The datasheet mentions these
>> registers but does not provide any hints on when they become valid, and they
>> aren't even enumerated in the memory map. So check the calibration and
>> retry reading it from the device after each measurement until it provides
>> something valid.
>>
>> Report temperature in millidegrees Celcius instead of degrees.
> Hi Mike,
>
> This last bit is an unrelated issue. Would you mind splitting the patch into
> two?
> Please put the temperature one first as that is definitely a stable
> worthy patch. The larger one is more debatable as it seems that it
> never worked and is a fairly large patch.
>
> I'll probably mark them both for stable, but it is possible not all
> the stable branches will pick them both up.
Splitting the patch was easy enough, the're independent, I'll post a v3 with
both patches.
>
> Thanks,
>
> Jonathan
>
>>
>> Signed-off-by: Mike Looijmans
>> ---
>> v2: Remove unused 'addr7' variable
>>
>> drivers/iio/chemical/bme680.h | 6 +-
>> drivers/iio/chemical/bme680_core.c | 54 ++---
>> drivers/iio/chemical/bme680_i2c.c | 21 ---
>> drivers/iio/chemical/bme680_spi.c | 115
>> +
>> 4 files changed, 125 insertions(+), 71 deletions(-)
>>
>> diff --git a/drivers/iio/chemical/bme680.h b/drivers/iio/chemical/bme680.h
>> index 0ae89b87..4edc5d21 100644
>> --- a/drivers/iio/chemical/bme680.h
>> +++ b/drivers/iio/chemical/bme680.h
>> @@ -2,11 +2,9 @@
>> #ifndef BME680_H_
>> #define BME680_H_
>>
>> -#define BME680_REG_CHIP_I2C_ID 0xD0
>> -#define BME680_REG_CHIP_SPI_ID 0x50
>> +#define BME680_REG_CHIP_ID 0xD0
>> #define BME680_CHIP_ID_VAL 0x61
>> -#define BME680_REG_SOFT_RESET_I2C 0xE0
>> -#define BME680_REG_SOFT_RESET_SPI 0x60
>> +#define BME680_REG_SOFT_RESET 0xE0
>> #define BME680_CMD_SOFTRESET 0xB6
>> #define BME680_REG_STATUS 0x73
>> #define BME680_SPI_MEM_PAGE_BIT BIT(4)
>> diff --git a/drivers/iio/chemical/bme680_core.c
>> b/drivers/iio/chemical/bme680_core.c
>> index 70c1fe4..ccde4c6 100644
>> --- a/drivers/iio/chemical/bme680_core.c
>> +++ b/drivers/iio/chemical/bme680_core.c
>> @@ -63,9 +63,23 @@ struct bme680_data {
>> s32 t_fine;
>> };
>>
>> +static const struct regmap_range bme680_volatile_ranges[] = {
>> +regmap_reg_range(BME680_REG_MEAS_STAT_0, BME680_REG_GAS_R_LSB),
>> +regmap_reg_range(BME680_REG_STATUS, BME680_REG_STATUS),
>> +regmap_reg_range(BME680_T2_LSB_REG, BME680_GH3_REG),
>> +};
>> +
>> +static const struct regmap_access_table bme680_volatile_table = {
>> +.yes_ranges = bme680_volatile_ranges,
>> +.n_yes_ranges = ARRAY_SIZE(bme680_volatile_ranges),
>> +};
>> +
>> const struct regmap_config bme680_regmap_config = {
>> .reg_bits = 8,
>> .val_bits = 8,
>> +.max_register = 0xef,
>> +.volatile_table = _volatile_table,
>> +.cache_type = REGCACHE_RBTREE,
>> };
>> EXPORT_SYMBOL(bme680_regmap_config);
>>
>> @@ -316,6 +330,10 @@ static s16 bme680_compensate_temp(struct bme680_data
>> *data,
>> s64 var1, var2, var3;
>> s16 calc_temp;
>>
>> +/* If the calibration is invalid, attempt to reload it */
>> +if (!calib->par_t2)
>> +bme680_read_calib(data, calib);
>> +
>> var1 = (adc_temp >> 3) - (calib->par_t1 << 1);
>> var2 = (var1 * calib->par_t2) >> 11;
>> var3 = ((var1 >> 1) * (var1 >> 1)) >> 12;
>> @@ -583,8 +601,7 @@ static int bme680_gas_config(struct bme680_data *data)
>> return ret;
>> }
>>
>> -static int bme680_read_temp(struct bme680_data *data,
>> -int *val, int *val2)
>> +static int bme680_read_temp(struct bme680_data *data, int *val)
>> {
>> struct device *dev = regmap_get_device(data->regmap);
>> int ret;
>> @@ -617,10 +634,9 @@ static int bme680_read_temp(struct
[PATCH] appletalk: Correctly handle return value of register_snap_client
From: YueHaibing
register_snap_client may return NULL, all the callers
check it, but only print a warning. This will result in
NULL pointer dereference in unregister_snap_client and other
places.
It has always been used like this since v2.6
Reported-by: Dan Carpenter
Signed-off-by: YueHaibing
---
include/linux/atalk.h | 2 +-
net/appletalk/aarp.c | 10 ++
net/appletalk/ddp.c | 20
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/include/linux/atalk.h b/include/linux/atalk.h
index 5a90f28..0e5265a 100644
--- a/include/linux/atalk.h
+++ b/include/linux/atalk.h
@@ -108,7 +108,7 @@ static __inline__ struct elapaarp *aarp_hdr(struct sk_buff
*skb)
#define AARP_RESOLVE_TIME (10 * HZ)
extern struct datalink_proto *ddp_dl, *aarp_dl;
-extern void aarp_proto_init(void);
+extern int aarp_proto_init(void);
/* Inter module exports */
diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index 49a16ce..e047853 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -879,15 +879,17 @@ static struct notifier_block aarp_notifier = {
static unsigned char aarp_snap_id[] = { 0x00, 0x00, 0x00, 0x80, 0xF3 };
-void __init aarp_proto_init(void)
+int __init aarp_proto_init(void)
{
aarp_dl = register_snap_client(aarp_snap_id, aarp_rcv);
- if (!aarp_dl)
- printk(KERN_CRIT "Unable to register AARP with SNAP.\n");
+ if (!aarp_dl) {
+ pr_crit("Unable to register AARP with SNAP.\n");
+ return -ENOMEM;
+ }
timer_setup(_timer, aarp_expire_timeout, 0);
aarp_timer.expires = jiffies + sysctl_aarp_expiry_time;
add_timer(_timer);
- register_netdevice_notifier(_notifier);
+ return register_netdevice_notifier(_notifier);
}
/* Remove the AARP entries associated with a device. */
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index 795fbc6..709d254 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -1904,9 +1904,6 @@ static unsigned char ddp_snap_id[] = { 0x08, 0x00, 0x07,
0x80, 0x9B };
EXPORT_SYMBOL(atrtr_get_dev);
EXPORT_SYMBOL(atalk_find_dev_addr);
-static const char atalk_err_snap[] __initconst =
- KERN_CRIT "Unable to register DDP with SNAP.\n";
-
/* Called by proto.c on kernel start up */
static int __init atalk_init(void)
{
@@ -1921,17 +1918,22 @@ static int __init atalk_init(void)
goto out_proto;
ddp_dl = register_snap_client(ddp_snap_id, atalk_rcv);
- if (!ddp_dl)
- printk(atalk_err_snap);
+ if (!ddp_dl) {
+ pr_crit("Unable to register DDP with SNAP.\n");
+ goto out_sock;
+ }
dev_add_pack(_packet_type);
dev_add_pack(_packet_type);
rc = register_netdevice_notifier(_notifier);
if (rc)
- goto out_sock;
+ goto out_snap;
+
+ rc = aarp_proto_init();
+ if (rc)
+ goto out_dev;
- aarp_proto_init();
rc = atalk_proc_init();
if (rc)
goto out_aarp;
@@ -1945,11 +1947,13 @@ static int __init atalk_init(void)
atalk_proc_exit();
out_aarp:
aarp_cleanup_module();
+out_dev:
unregister_netdevice_notifier(_notifier);
-out_sock:
+out_snap:
dev_remove_pack(_packet_type);
dev_remove_pack(_packet_type);
unregister_snap_client(ddp_dl);
+out_sock:
sock_unregister(PF_APPLETALK);
out_proto:
proto_unregister(_proto);
--
2.7.0
2264f5132f ("xarray: Add xas_create_range"): watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/0:1]
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 2264f5132fe45571139727ebdeb78696b35d1506 Author: Matthew Wilcox AuthorDate: Mon Dec 4 00:11:48 2017 -0500 Commit: Matthew Wilcox CommitDate: Sun Oct 21 10:45:59 2018 -0400 xarray: Add xas_create_range This hopefully temporary function is useful for users who have not yet been converted to multi-index entries. Signed-off-by: Matthew Wilcox 4e99d4e957 xarray: Add xas_for_each_conflict 2264f5132f xarray: Add xas_create_range 3717f613f4 Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip baf5a9d1f9 Add linux-next specific files for 20190305 +++++---+ || 4e99d4e957 | 2264f5132f | 3717f613f4 | next-20190305 | +++++---+ | boot_successes | 823| 268| 196| 21| | boot_failures | 0 | 13 | 85 | 5 | | BUG:soft_lockup-CPU##stuck_for#s | 0 | 13 | 85 | 5 | | EIP:arch_local_irq_restore | 0 | 9 | | | | Kernel_panic-not_syncing:softlockup:hung_tasks | 0 | 13 | 85 | 5 | | EIP:do_raw_spin_lock | 0 | 1 | | | | EIP:xas_alloc | 0 | 1 | 1 | | | EIP:xas_descend| 0 | 1 | 4 | | | EIP:arch_local_save_flags | 0 | 1 | | | | EIP:_raw_spin_unlock_irqrestore| 0 | 0 | 51 | 5 | | EIP:xas_load | 0 | 0 | 4 | | | EIP:xa_is_node | 0 | 0 | 2 | | | EIP:xas_store | 0 | 0 | 6 | | | EIP:__xas_next | 0 | 0 | 1 | | | EIP:_find_next_bit | 0 | 0 | 2 | | | EIP:xas_next_marked| 0 | 0 | 3 | | | EIP:xas_result | 0 | 0 | 1 | | | EIP:check_find_3 | 0 | 0 | 1 | | | EIP:xa_erase_index | 0 | 0 | 1 | | | EIP:xas_init_marks | 0 | 0 | 2 | | | EIP:xas_start | 0 | 0 | 1 | | | EIP:xas_find_marked| 0 | 0 | 1 | | | EIP:__call_rcu | 0 | 0 | 1 | | | EIP:xas_clear_mark | 0 | 0 | 1 | | | EIP:xas_create | 0 | 0 | 1 | | | EIP:xa_load| 0 | 0 | 1 | | +++++---+ [ 20.348565] test_firmware: interface ready [ 20.739595] IDA: 147321 of 147321 tests passed [ 20.751639] test_printf: crng possibly not yet initialized. plain 'p' buffer contains "(ptrval)" [ 20.752775] test_printf: all 240 tests passed [ 20.773777] test_uuid: all 18 tests passed [ 46.091442] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [swapper/0:1] [ 46.111602] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc5-00256-g2264f51 #1 [ 46.121589] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 46.131615] EIP: arch_local_irq_restore+0x2/0x7 [ 46.141580] Code: 2d b2 00 75 13 68 6a fc e1 b1 68 e2 0e e1 b1 e8 5d 53 fd ff 0f 0b 58 5a c7 43 20 00 00 00 00 5b c3 9c 58 8d 74 26 00 c3 50 9d <8d> 74 26 00 c3 fa 90 8d 74 26 00 c3 fb 90 8d 74 26 00 c3 3d b0 2e [ 46.171652] EAX: 00200206 EBX: 00200206 ECX: EDX: 00200206 [ 46.181601] ESI: b231907c EDI: 00043eb8 EBP: b1f8b740 ESP: cdc31e34 [ 46.191
Re: [PATCH v5 6/8] DT: arm: exynos: add DMC device for exynos5422
Hi Krzysztof,
On 3/5/19 12:36 PM, Krzysztof Kozlowski wrote:
> On Tue, 5 Mar 2019 at 11:19, Lukasz Luba
> wrote:>> Add description of Dynamic Memory Controller and PPMU
> counters.> They are used by exynos5422-dmc driver.>> Signed-off-by:
> Lukasz Luba In previous email I asked to
> fix the subject prefix in case of resend. Please fix it.
>
>> ---
>> arch/arm/boot/dts/exynos5420.dtsi | 83
>> +
>> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 87
>> +++
>> 2 files changed, 170 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index aaff158..fc00fda 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -235,6 +235,41 @@
>> status = "disabled";
>> };
>>
>> + dmc: memory-controller@10c2 {
>> + compatible = "samsung,exynos5422-dmc";
>> + reg = <0x10c2 0x1>, <0x10c3 0x1>,
>> + <0x1000 0x1000>;
>> + clocks = < CLK_FOUT_SPLL>,
>> +< CLK_MOUT_SCLK_SPLL>,
>> +< CLK_FF_DOUT_SPLL2>,
>> +< CLK_FOUT_BPLL>,
>> +< CLK_MOUT_BPLL>,
>> +< CLK_SCLK_BPLL>,
>> +< CLK_MOUT_MX_MSPLL_CCORE>,
>> +< CLK_MOUT_MX_MSPLL_CCORE_PHY>,
>> +< CLK_MOUT_MCLK_CDREX>,
>> +< CLK_DOUT_CLK2X_PHY0>,
>> +< CLK_CLKM_PHY0>,
>> +< CLK_CLKM_PHY1>,
>> +< CLK_CDREX_PAUSE>,
>> +< CLK_CDREX_TIMING_SET>;
>> + clock-names = "fout_spll",
>> + "mout_sclk_spll",
>> + "ff_dout_spll2",
>> + "fout_bpll",
>> + "mout_bpll",
>> + "sclk_bpll",
>> + "mout_mx_mspll_ccore",
>> + "mout_mx_mspll_ccore_phy",
>> + "mout_mclk_cdrex",
>> + "dout_clk2x_phy0",
>> + "clkm_phy0",
>> + "clkm_phy1",
>> + "clk_cdrex_pause",
>> + "clk_cdrex_timing_set";
>> + status = "disabled";
>> + };
>> +
>> nocp_mem0_0: nocp@10ca1000 {
>> compatible = "samsung,exynos5420-nocp";
>> reg = <0x10CA1000 0x200>;
>> @@ -271,6 +306,54 @@
>> status = "disabled";
>> };
>>
>> + ppmu_dmc0_0: ppmu@10d0 {
>> + compatible = "samsung,exynos-ppmu";
>> + reg = <0x10d0 0x2000>;
>> + clocks = < CLK_PCLK_PPMU_DREX0_0>;
>> + clock-names = "ppmu";
>> + events {
>> + ppmu_event_dmc0_0: ppmu-event3-dmc0_0 {
>> + event-name = "ppmu-event3-dmc0_0";
>> + };
>> + };
>> + };
>> +
>> + ppmu_dmc0_1: ppmu@10d1 {
>> + compatible = "samsung,exynos-ppmu";
>> + reg = <0x10d1 0x2000>;
>> + clocks = < CLK_PCLK_PPMU_DREX0_1>;
>> + clock-names = "ppmu";
>> + events {
>> + ppmu_event_dmc0_1: ppmu-event3-dmc0_1 {
>> + event-name = "ppmu-event3-dmc0_1";
>> + };
>> + };
>> + };
>> +
>> + ppmu_dmc1_0: ppmu@10d1 {
>> + compatible = "samsung,exynos-ppmu";
>> + reg = <0x10d6 0x2000>;
>> + clocks = < CLK_PCLK_PPMU_DREX1_0>;
>> + clock-names = "ppmu";
>> + events {
>> + ppmu_event_dmc1_0: ppmu-event3-dmc1_0 {
>> + event-name = "ppmu-event3-dmc1_0";
>> + };
>> + };
>> + };
>> +
>> + ppmu_dmc1_1: ppmu@10d7 {
>> + compatible = "samsung,exynos-ppmu";
>> + reg = <0x10d7 0x2000>;
>> + clocks = <
[RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address
It was noticed that the copy_user() friends that was used to access
virtqueue metdata tends to be very expensive for dataplane
implementation like vhost since it involves lots of software checks,
speculation barrier, hardware feature toggling (e.g SMAP). The
extra cost will be more obvious when transferring small packets since
the time spent on metadata accessing become more significant.
This patch tries to eliminate those overheads by accessing them
through kernel virtual address by vmap(). To make the pages can be
migrated, instead of pinning them through GUP, we use MMU notifiers to
invalidate vmaps and re-establish vmaps during each round of metadata
prefetching if necessary. It looks to me .invalidate_range() is
sufficient for catching this since we don't need extra TLB flush. For
devices that doesn't use metadata prefetching, the memory accessors
fallback to normal copy_user() implementation gracefully. The
invalidation was synchronized with datapath through vq mutex, and in
order to avoid hold vq mutex during range checking, MMU notifier was
teared down when trying to modify vq metadata.
Dirty page checking is done by calling set_page_dirty_locked()
explicitly for the page that used ring stay after each round of
processing.
Note that this was only done when device IOTLB is not enabled. We
could use similar method to optimize it in the future.
Tests shows at most about 22% improvement on TX PPS when using
virtio-user + vhost_net + xdp1 + TAP on 2.6GHz Broadwell:
SMAP on | SMAP off
Before: 5.0Mpps | 6.6Mpps
After: 6.1Mpps | 7.4Mpps
Cc:
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 2 +
drivers/vhost/vhost.c | 281 +-
drivers/vhost/vhost.h | 16 +++
3 files changed, 297 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index bf55f99..c276371 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -982,6 +982,7 @@ static void handle_tx(struct vhost_net *net)
else
handle_tx_copy(net, sock);
+ vq_meta_prefetch_done(vq);
out:
mutex_unlock(>mutex);
}
@@ -1250,6 +1251,7 @@ static void handle_rx(struct vhost_net *net)
vhost_net_enable_vq(net, vq);
out:
vhost_net_signal_used(nvq);
+ vq_meta_prefetch_done(vq);
mutex_unlock(>mutex);
}
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 1015464..36ccf7c 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -434,6 +434,74 @@ static size_t vhost_get_desc_size(struct vhost_virtqueue
*vq, int num)
return sizeof(*vq->desc) * num;
}
+static void vhost_uninit_vmap(struct vhost_vmap *map)
+{
+ if (map->addr) {
+ vunmap(map->unmap_addr);
+ kfree(map->pages);
+ map->pages = NULL;
+ map->npages = 0;
+ }
+
+ map->addr = NULL;
+ map->unmap_addr = NULL;
+}
+
+static void vhost_invalidate_vmap(struct vhost_virtqueue *vq,
+ struct vhost_vmap *map,
+ unsigned long ustart,
+ size_t size,
+ unsigned long start,
+ unsigned long end)
+{
+ if (end < ustart || start > ustart - 1 + size)
+ return;
+
+ dump_stack();
+ mutex_lock(>mutex);
+ vhost_uninit_vmap(map);
+ mutex_unlock(>mutex);
+}
+
+
+static void vhost_invalidate(struct vhost_dev *dev,
+unsigned long start, unsigned long end)
+{
+ int i;
+
+ for (i = 0; i < dev->nvqs; i++) {
+ struct vhost_virtqueue *vq = dev->vqs[i];
+
+ vhost_invalidate_vmap(vq, >avail_ring,
+ (unsigned long)vq->avail,
+ vhost_get_avail_size(vq, vq->num),
+ start, end);
+ vhost_invalidate_vmap(vq, >desc_ring,
+ (unsigned long)vq->desc,
+ vhost_get_desc_size(vq, vq->num),
+ start, end);
+ vhost_invalidate_vmap(vq, >used_ring,
+ (unsigned long)vq->used,
+ vhost_get_used_size(vq, vq->num),
+ start, end);
+ }
+}
+
+
+static void vhost_invalidate_range(struct mmu_notifier *mn,
+ struct mm_struct *mm,
+ unsigned long start, unsigned long end)
+{
+ struct vhost_dev *dev = container_of(mn, struct vhost_dev,
+mmu_notifier);
+
+ vhost_invalidate(dev, start, end);
+}
+
+static const struct mmu_notifier_ops vhost_mmu_notifier_ops = {
+ .invalidate_range = vhost_invalidate_range,
+};
+
void vhost_dev_init(struct
[RFC PATCH V2 3/5] vhost: rename vq_iotlb_prefetch() to vq_meta_prefetch()
Rename the function to be more accurate since it actually tries to
prefetch vq metadata address in IOTLB. And this will be used by
following patch to prefetch metadata virtual addresses.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 4 ++--
drivers/vhost/vhost.c | 4 ++--
drivers/vhost/vhost.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index df51a35..bf55f99 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -971,7 +971,7 @@ static void handle_tx(struct vhost_net *net)
if (!sock)
goto out;
- if (!vq_iotlb_prefetch(vq))
+ if (!vq_meta_prefetch(vq))
goto out;
vhost_disable_notify(>dev, vq);
@@ -1140,7 +1140,7 @@ static void handle_rx(struct vhost_net *net)
if (!sock)
goto out;
- if (!vq_iotlb_prefetch(vq))
+ if (!vq_meta_prefetch(vq))
goto out;
vhost_disable_notify(>dev, vq);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 29709e7..2025543 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1309,7 +1309,7 @@ static bool iotlb_access_ok(struct vhost_virtqueue *vq,
return true;
}
-int vq_iotlb_prefetch(struct vhost_virtqueue *vq)
+int vq_meta_prefetch(struct vhost_virtqueue *vq)
{
size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
unsigned int num = vq->num;
@@ -1328,7 +1328,7 @@ int vq_iotlb_prefetch(struct vhost_virtqueue *vq)
num * sizeof(*vq->used->ring) + s,
VHOST_ADDR_USED);
}
-EXPORT_SYMBOL_GPL(vq_iotlb_prefetch);
+EXPORT_SYMBOL_GPL(vq_meta_prefetch);
/* Can we log writes? */
/* Caller should have device mutex but not vq mutex */
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 9490e7d..7a7fc00 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -209,7 +209,7 @@ void vhost_add_used_and_signal_n(struct vhost_dev *, struct
vhost_virtqueue *,
int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
unsigned int log_num, u64 len,
struct iovec *iov, int count);
-int vq_iotlb_prefetch(struct vhost_virtqueue *vq);
+int vq_meta_prefetch(struct vhost_virtqueue *vq);
struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type);
void vhost_enqueue_msg(struct vhost_dev *dev,
--
1.8.3.1
[RFC PATCH V2 2/5] vhost: fine grain userspace memory accessors
This is used to hide the metadata address from virtqueue helpers. This
will allow to implement a vmap based fast accessing to metadata.
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 94 +--
1 file changed, 77 insertions(+), 17 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 400aa78..29709e7 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -869,6 +869,34 @@ static inline void __user *__vhost_get_user(struct
vhost_virtqueue *vq,
ret; \
})
+static inline int vhost_put_avail_event(struct vhost_virtqueue *vq)
+{
+ return vhost_put_user(vq, cpu_to_vhost16(vq, vq->avail_idx),
+ vhost_avail_event(vq));
+}
+
+static inline int vhost_put_used(struct vhost_virtqueue *vq,
+struct vring_used_elem *head, int idx,
+int count)
+{
+ return vhost_copy_to_user(vq, vq->used->ring + idx, head,
+ count * sizeof(*head));
+}
+
+static inline int vhost_put_used_flags(struct vhost_virtqueue *vq)
+
+{
+ return vhost_put_user(vq, cpu_to_vhost16(vq, vq->used_flags),
+ >used->flags);
+}
+
+static inline int vhost_put_used_idx(struct vhost_virtqueue *vq)
+
+{
+ return vhost_put_user(vq, cpu_to_vhost16(vq, vq->last_used_idx),
+ >used->idx);
+}
+
#define vhost_get_user(vq, x, ptr, type) \
({ \
int ret; \
@@ -907,6 +935,43 @@ static void vhost_dev_unlock_vqs(struct vhost_dev *d)
mutex_unlock(>vqs[i]->mutex);
}
+static inline int vhost_get_avail_idx(struct vhost_virtqueue *vq,
+ __virtio16 *idx)
+{
+ return vhost_get_avail(vq, *idx, >avail->idx);
+}
+
+static inline int vhost_get_avail_head(struct vhost_virtqueue *vq,
+ __virtio16 *head, int idx)
+{
+ return vhost_get_avail(vq, *head,
+ >avail->ring[idx & (vq->num - 1)]);
+}
+
+static inline int vhost_get_avail_flags(struct vhost_virtqueue *vq,
+ __virtio16 *flags)
+{
+ return vhost_get_avail(vq, *flags, >avail->flags);
+}
+
+static inline int vhost_get_used_event(struct vhost_virtqueue *vq,
+ __virtio16 *event)
+{
+ return vhost_get_avail(vq, *event, vhost_used_event(vq));
+}
+
+static inline int vhost_get_used_idx(struct vhost_virtqueue *vq,
+__virtio16 *idx)
+{
+ return vhost_get_used(vq, *idx, >used->idx);
+}
+
+static inline int vhost_get_desc(struct vhost_virtqueue *vq,
+struct vring_desc *desc, int idx)
+{
+ return vhost_copy_from_user(vq, desc, vq->desc + idx, sizeof(*desc));
+}
+
static int vhost_new_umem_range(struct vhost_umem *umem,
u64 start, u64 size, u64 end,
u64 userspace_addr, int perm)
@@ -1840,8 +1905,7 @@ int vhost_log_write(struct vhost_virtqueue *vq, struct
vhost_log *log,
static int vhost_update_used_flags(struct vhost_virtqueue *vq)
{
void __user *used;
- if (vhost_put_user(vq, cpu_to_vhost16(vq, vq->used_flags),
- >used->flags) < 0)
+ if (vhost_put_used_flags(vq))
return -EFAULT;
if (unlikely(vq->log_used)) {
/* Make sure the flag is seen before log. */
@@ -1858,8 +1922,7 @@ static int vhost_update_used_flags(struct vhost_virtqueue
*vq)
static int vhost_update_avail_event(struct vhost_virtqueue *vq, u16
avail_event)
{
- if (vhost_put_user(vq, cpu_to_vhost16(vq, vq->avail_idx),
- vhost_avail_event(vq)))
+ if (vhost_put_avail_event(vq))
return -EFAULT;
if (unlikely(vq->log_used)) {
void __user *used;
@@ -1895,7 +1958,7 @@ int vhost_vq_init_access(struct vhost_virtqueue *vq)
r = -EFAULT;
goto err;
}
- r = vhost_get_used(vq, last_used_idx, >used->idx);
+ r = vhost_get_used_idx(vq, _used_idx);
if (r) {
vq_err(vq, "Can't access used idx at %p\n",
>used->idx);
@@ -2094,7 +2157,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
last_avail_idx = vq->last_avail_idx;
if (vq->avail_idx == vq->last_avail_idx) {
- if (unlikely(vhost_get_avail(vq, avail_idx, >avail->idx))) {
+ if (unlikely(vhost_get_avail_idx(vq, _idx))) {
vq_err(vq, "Failed to access avail idx at %p\n",
>avail->idx);
return -EFAULT;
@@ -2121,8 +2184,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
/* Grab the next descriptor number they're advertising, and increment
* the index we've seen. */
-
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
This series tries to access virtqueue metadata through kernel virtual address instead of copy_user() friends since they had too much overheads like checks, spec barriers or even hardware feature toggling. This is done through setup kernel address through vmap() and resigter MMU notifier for invalidation. Test shows about 24% improvement on TX PPS. TCP_STREAM doesn't see obvious improvement. Thanks Changes from V4: - use invalidate_range() instead of invalidate_range_start() - track dirty pages Changes from V3: - don't try to use vmap for file backed pages - rebase to master Changes from V2: - fix buggy range overlapping check - tear down MMU notifier during vhost ioctl to make sure invalidation request can read metadata userspace address and vq size without holding vq mutex. Changes from V1: - instead of pinning pages, use MMU notifier to invalidate vmaps and remap duing metadata prefetch - fix build warning on MIPS Jason Wang (5): vhost: generalize adding used elem vhost: fine grain userspace memory accessors vhost: rename vq_iotlb_prefetch() to vq_meta_prefetch() vhost: introduce helpers to get the size of metadata area vhost: access vq metadata through kernel virtual address drivers/vhost/net.c | 6 +- drivers/vhost/vhost.c | 434 -- drivers/vhost/vhost.h | 18 ++- 3 files changed, 407 insertions(+), 51 deletions(-) -- 1.8.3.1
[RFC PATCH V2 4/5] vhost: introduce helpers to get the size of metadata area
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 46 --
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 2025543..1015464 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -413,6 +413,27 @@ static void vhost_dev_free_iovecs(struct vhost_dev *dev)
vhost_vq_free_iovecs(dev->vqs[i]);
}
+static size_t vhost_get_avail_size(struct vhost_virtqueue *vq, int num)
+{
+ size_t event = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
+
+ return sizeof(*vq->avail) +
+ sizeof(*vq->avail->ring) * num + event;
+}
+
+static size_t vhost_get_used_size(struct vhost_virtqueue *vq, int num)
+{
+ size_t event = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
+
+ return sizeof(*vq->used) +
+ sizeof(*vq->used->ring) * num + event;
+}
+
+static size_t vhost_get_desc_size(struct vhost_virtqueue *vq, int num)
+{
+ return sizeof(*vq->desc) * num;
+}
+
void vhost_dev_init(struct vhost_dev *dev,
struct vhost_virtqueue **vqs, int nvqs, int iov_limit)
{
@@ -1253,13 +1274,9 @@ static bool vq_access_ok(struct vhost_virtqueue *vq,
unsigned int num,
struct vring_used __user *used)
{
- size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
-
- return access_ok(desc, num * sizeof *desc) &&
- access_ok(avail,
-sizeof *avail + num * sizeof *avail->ring + s) &&
- access_ok(used,
- sizeof *used + num * sizeof *used->ring + s);
+ return access_ok(desc, vhost_get_desc_size(vq, num)) &&
+ access_ok(avail, vhost_get_avail_size(vq, num)) &&
+ access_ok(used, vhost_get_used_size(vq, num));
}
static void vhost_vq_meta_update(struct vhost_virtqueue *vq,
@@ -1311,22 +1328,18 @@ static bool iotlb_access_ok(struct vhost_virtqueue *vq,
int vq_meta_prefetch(struct vhost_virtqueue *vq)
{
- size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
unsigned int num = vq->num;
if (!vq->iotlb)
return 1;
return iotlb_access_ok(vq, VHOST_ACCESS_RO, (u64)(uintptr_t)vq->desc,
- num * sizeof(*vq->desc), VHOST_ADDR_DESC) &&
+ vhost_get_desc_size(vq, num), VHOST_ADDR_DESC) &&
iotlb_access_ok(vq, VHOST_ACCESS_RO, (u64)(uintptr_t)vq->avail,
- sizeof *vq->avail +
- num * sizeof(*vq->avail->ring) + s,
+ vhost_get_avail_size(vq, num),
VHOST_ADDR_AVAIL) &&
iotlb_access_ok(vq, VHOST_ACCESS_WO, (u64)(uintptr_t)vq->used,
- sizeof *vq->used +
- num * sizeof(*vq->used->ring) + s,
- VHOST_ADDR_USED);
+ vhost_get_used_size(vq, num), VHOST_ADDR_USED);
}
EXPORT_SYMBOL_GPL(vq_meta_prefetch);
@@ -1343,13 +1356,10 @@ bool vhost_log_access_ok(struct vhost_dev *dev)
static bool vq_log_access_ok(struct vhost_virtqueue *vq,
void __user *log_base)
{
- size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
-
return vq_memory_access_ok(log_base, vq->umem,
vhost_has_feature(vq, VHOST_F_LOG_ALL)) &&
(!vq->log_used || log_access_ok(log_base, vq->log_addr,
- sizeof *vq->used +
- vq->num * sizeof *vq->used->ring + s));
+ vhost_get_used_size(vq, vq->num)));
}
/* Can we start vq? */
--
1.8.3.1
[RFC PATCH V2 1/5] vhost: generalize adding used elem
Use one generic vhost_copy_to_user() instead of two dedicated
accessor. This will simplify the conversion to fine grain
accessors. About 2% improvement of PPS were seen during vitio-user
txonly test.
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index a2e5dc7..400aa78 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2251,16 +2251,7 @@ static int __vhost_add_used_n(struct vhost_virtqueue *vq,
start = vq->last_used_idx & (vq->num - 1);
used = vq->used->ring + start;
- if (count == 1) {
- if (vhost_put_user(vq, heads[0].id, >id)) {
- vq_err(vq, "Failed to write used id");
- return -EFAULT;
- }
- if (vhost_put_user(vq, heads[0].len, >len)) {
- vq_err(vq, "Failed to write used len");
- return -EFAULT;
- }
- } else if (vhost_copy_to_user(vq, used, heads, count * sizeof *used)) {
+ if (vhost_copy_to_user(vq, used, heads, count * sizeof *used)) {
vq_err(vq, "Failed to write used");
return -EFAULT;
}
--
1.8.3.1
[PATCH v6 perf,bpf 02/15] bpf: libbpf: introduce bpf_program__get_prog_info_linear()
Currently, bpf_prog_info includes 9 arrays. The user has the option to
fetch any combination of these arrays. However, this requires a lot of
handling of these arrays. This work becomes more tricky when we need to
store bpf_prog_info to a file, because these arrays are allocated
independently.
This patch introduces struct bpf_prog_info_linear, which stores arrays
of bpf_prog_info in continues memory. Helper functions are introduced
to unify the work to get different information of bpf_prog_info.
Specifically, bpf_program__get_prog_info_linear() allows the user to
select which arrays to fetch, and handles details for the user.
Plesae see the comments before enum bpf_prog_info_array for more details
and examples.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Song Liu
---
tools/lib/bpf/libbpf.c | 251 +++
tools/lib/bpf/libbpf.h | 63 ++
tools/lib/bpf/libbpf.map | 3 +
3 files changed, 317 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index f5eb60379c8d..ca00ce5cbae0 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -112,6 +112,11 @@ void libbpf_print(enum libbpf_print_level level, const
char *format, ...)
# define LIBBPF_ELF_C_READ_MMAP ELF_C_READ
#endif
+static inline __u64 ptr_to_u64(const void *ptr)
+{
+ return (__u64) (unsigned long) ptr;
+}
+
struct bpf_capabilities {
/* v4.14: kernel support for program & map names. */
__u32 name:1;
@@ -2997,3 +3002,249 @@ bpf_perf_event_read_simple(void *mmap_mem, size_t
mmap_size, size_t page_size,
ring_buffer_write_tail(header, data_tail);
return ret;
}
+
+struct bpf_prog_info_array_desc {
+ int array_offset; /* e.g. offset of jited_prog_insns */
+ int count_offset; /* e.g. offset of jited_prog_len */
+ int size_offset;/* > 0: offset of rec size,
+* < 0: fix size of -size_offset
+*/
+};
+
+static struct bpf_prog_info_array_desc bpf_prog_info_array_desc[] = {
+ [BPF_PROG_INFO_JITED_INSNS] = {
+ offsetof(struct bpf_prog_info, jited_prog_insns),
+ offsetof(struct bpf_prog_info, jited_prog_len),
+ -1,
+ },
+ [BPF_PROG_INFO_XLATED_INSNS] = {
+ offsetof(struct bpf_prog_info, xlated_prog_insns),
+ offsetof(struct bpf_prog_info, xlated_prog_len),
+ -1,
+ },
+ [BPF_PROG_INFO_MAP_IDS] = {
+ offsetof(struct bpf_prog_info, map_ids),
+ offsetof(struct bpf_prog_info, nr_map_ids),
+ -(int)sizeof(__u32),
+ },
+ [BPF_PROG_INFO_JITED_KSYMS] = {
+ offsetof(struct bpf_prog_info, jited_ksyms),
+ offsetof(struct bpf_prog_info, nr_jited_ksyms),
+ -(int)sizeof(__u64),
+ },
+ [BPF_PROG_INFO_JITED_FUNC_LENS] = {
+ offsetof(struct bpf_prog_info, jited_func_lens),
+ offsetof(struct bpf_prog_info, nr_jited_func_lens),
+ -(int)sizeof(__u32),
+ },
+ [BPF_PROG_INFO_FUNC_INFO] = {
+ offsetof(struct bpf_prog_info, func_info),
+ offsetof(struct bpf_prog_info, nr_func_info),
+ offsetof(struct bpf_prog_info, func_info_rec_size),
+ },
+ [BPF_PROG_INFO_LINE_INFO] = {
+ offsetof(struct bpf_prog_info, line_info),
+ offsetof(struct bpf_prog_info, nr_line_info),
+ offsetof(struct bpf_prog_info, line_info_rec_size),
+ },
+ [BPF_PROG_INFO_JITED_LINE_INFO] = {
+ offsetof(struct bpf_prog_info, jited_line_info),
+ offsetof(struct bpf_prog_info, nr_jited_line_info),
+ offsetof(struct bpf_prog_info, jited_line_info_rec_size),
+ },
+ [BPF_PROG_INFO_PROG_TAGS] = {
+ offsetof(struct bpf_prog_info, prog_tags),
+ offsetof(struct bpf_prog_info, nr_prog_tags),
+ -(int)sizeof(__u8) * BPF_TAG_SIZE,
+ },
+
+};
+
+static __u32 bpf_prog_info_read_offset_u32(struct bpf_prog_info *info, int
offset)
+{
+ __u32 *array = (__u32 *)info;
+
+ if (offset >= 0)
+ return array[offset / sizeof(__u32)];
+ return -(int)offset;
+}
+
+static __u64 bpf_prog_info_read_offset_u64(struct bpf_prog_info *info, int
offset)
+{
+ __u64 *array = (__u64 *)info;
+
+ if (offset >= 0)
+ return array[offset / sizeof(__u64)];
+ return -(int)offset;
+}
+
+static void bpf_prog_info_set_offset_u32(struct bpf_prog_info *info, int
offset,
+__u32 val)
+{
+ __u32 *array = (__u32 *)info;
+
+ if (offset >= 0)
+ array[offset / sizeof(__u32)] = val;
+}
+
+static void bpf_prog_info_set_offset_u64(struct bpf_prog_info *info, int
offset,
+__u64 val)
+{
+
[PATCH v6 perf,bpf 03/15] bpf: bpftool: use bpf_program__get_prog_info_linear() in prog.c:do_dump()
This patches uses bpf_program__get_prog_info_linear() to simplify the
logic in prog.c do_dump().
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Song Liu
---
tools/bpf/bpftool/prog.c | 266 +--
1 file changed, 59 insertions(+), 207 deletions(-)
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index 8ef80d65a474..d2be5a06c339 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -401,41 +401,31 @@ static int do_show(int argc, char **argv)
static int do_dump(int argc, char **argv)
{
- unsigned int finfo_rec_size, linfo_rec_size, jited_linfo_rec_size;
- void *func_info = NULL, *linfo = NULL, *jited_linfo = NULL;
- unsigned int nr_finfo, nr_linfo = 0, nr_jited_linfo = 0;
+ struct bpf_prog_info_linear *info_linear;
struct bpf_prog_linfo *prog_linfo = NULL;
- unsigned long *func_ksyms = NULL;
- struct bpf_prog_info info = {};
- unsigned int *func_lens = NULL;
+ enum {DUMP_JITED, DUMP_XLATED} mode;
const char *disasm_opt = NULL;
- unsigned int nr_func_ksyms;
- unsigned int nr_func_lens;
+ struct bpf_prog_info *info;
struct dump_data dd = {};
- __u32 len = sizeof(info);
+ void *func_info = NULL;
struct btf *btf = NULL;
- unsigned int buf_size;
char *filepath = NULL;
bool opcodes = false;
bool visual = false;
char func_sig[1024];
unsigned char *buf;
bool linum = false;
- __u32 *member_len;
- __u64 *member_ptr;
+ __u32 member_len;
+ __u64 arrays;
ssize_t n;
- int err;
int fd;
if (is_prefix(*argv, "jited")) {
if (disasm_init())
return -1;
-
- member_len = _prog_len;
- member_ptr = _prog_insns;
+ mode = DUMP_JITED;
} else if (is_prefix(*argv, "xlated")) {
- member_len = _prog_len;
- member_ptr = _prog_insns;
+ mode = DUMP_XLATED;
} else {
p_err("expected 'xlated' or 'jited', got: %s", *argv);
return -1;
@@ -474,175 +464,50 @@ static int do_dump(int argc, char **argv)
return -1;
}
- err = bpf_obj_get_info_by_fd(fd, , );
- if (err) {
- p_err("can't get prog info: %s", strerror(errno));
- return -1;
- }
-
- if (!*member_len) {
- p_info("no instructions returned");
- close(fd);
- return 0;
- }
+ if (mode == DUMP_JITED)
+ arrays = 1UL << BPF_PROG_INFO_JITED_INSNS;
+ else
+ arrays = 1UL << BPF_PROG_INFO_XLATED_INSNS;
- buf_size = *member_len;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_KSYMS;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_FUNC_LENS;
+ arrays |= 1UL << BPF_PROG_INFO_FUNC_INFO;
+ arrays |= 1UL << BPF_PROG_INFO_LINE_INFO;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_LINE_INFO;
- buf = malloc(buf_size);
- if (!buf) {
- p_err("mem alloc failed");
- close(fd);
+ info_linear = bpf_program__get_prog_info_linear(fd, arrays);
+ close(fd);
+ if (IS_ERR_OR_NULL(info_linear)) {
+ p_err("can't get prog info: %s", strerror(errno));
return -1;
}
- nr_func_ksyms = info.nr_jited_ksyms;
- if (nr_func_ksyms) {
- func_ksyms = malloc(nr_func_ksyms * sizeof(__u64));
- if (!func_ksyms) {
- p_err("mem alloc failed");
- close(fd);
- goto err_free;
- }
- }
-
- nr_func_lens = info.nr_jited_func_lens;
- if (nr_func_lens) {
- func_lens = malloc(nr_func_lens * sizeof(__u32));
- if (!func_lens) {
- p_err("mem alloc failed");
- close(fd);
+ info = _linear->info;
+ if (mode == DUMP_JITED) {
+ if (info->jited_prog_len == 0) {
+ p_info("no instructions returned");
goto err_free;
}
- }
-
- nr_finfo = info.nr_func_info;
- finfo_rec_size = info.func_info_rec_size;
- if (nr_finfo && finfo_rec_size) {
- func_info = malloc(nr_finfo * finfo_rec_size);
- if (!func_info) {
- p_err("mem alloc failed");
- close(fd);
+ buf = (unsigned char *)(info->jited_prog_insns);
+ member_len = info->jited_prog_len;
+ } else {/* DUMP_XLATED */
+ if (info->xlated_prog_len == 0) {
+ p_err("error retrieving insn dump: kernel.kptr_restrict
set?");
goto err_free;
}
+ buf = (unsigned char
[PATCH v6 perf,bpf 07/15] perf, bpf: save bpf_prog_info information as headers to perf.data
This patch enables perf-record to save bpf_prog_info information as
headers to perf.data. A new header type HEADER_BPF_PROG_INFO is
introduced for this data.
Signed-off-by: Song Liu
---
tools/perf/util/header.c | 149 ++-
tools/perf/util/header.h | 1 +
2 files changed, 149 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 4b88de5e9192..cd19b7891db7 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "evlist.h"
#include "evsel.h"
@@ -39,6 +40,7 @@
#include "tool.h"
#include "time-utils.h"
#include "units.h"
+#include "bpf-event.h"
#include "sane_ctype.h"
@@ -1074,6 +1076,54 @@ static int write_clockid(struct feat_fd *ff,
sizeof(ff->ph->env.clockid_res_ns));
}
+static int write_bpf_prog_info(struct feat_fd *ff,
+ struct perf_evlist *evlist __maybe_unused)
+{
+ struct perf_env *env = >ph->env;
+ struct rb_root *root;
+ struct rb_node *next;
+ u32 count = 0;
+ int ret;
+
+ down_read(>bpf_progs.lock);
+
+ root = >bpf_progs.infos;
+ next = rb_first(root);
+ while (next) {
+ ++count;
+ next = rb_next(next);
+ }
+
+ ret = do_write(ff, , sizeof(count));
+ if (ret < 0)
+ goto out;
+
+ next = rb_first(root);
+ while (next) {
+ struct bpf_prog_info_node *node;
+ size_t len;
+
+ node = rb_entry(next, struct bpf_prog_info_node, rb_node);
+ next = rb_next(>rb_node);
+ len = sizeof(struct bpf_prog_info_linear) +
+ node->info_linear->data_len;
+
+ /* before writing to file, translate address to offset */
+ bpf_program__bpil_addr_to_offs(node->info_linear);
+ ret = do_write(ff, node->info_linear, len);
+ /*
+* translate back to address even when do_write() fails,
+* so that this function never changes the data.
+*/
+ bpf_program__bpil_offs_to_addr(node->info_linear);
+ if (ret < 0)
+ goto out;
+ }
+out:
+ up_read(>bpf_progs.lock);
+ return ret;
+}
+
static int cpu_cache_level__sort(const void *a, const void *b)
{
struct cpu_cache_level *cache_a = (struct cpu_cache_level *)a;
@@ -1554,6 +1604,29 @@ static void print_clockid(struct feat_fd *ff, FILE *fp)
ff->ph->env.clockid_res_ns * 1000);
}
+static void print_bpf_prog_info(struct feat_fd *ff, FILE *fp)
+{
+ struct perf_env *env = >ph->env;
+ struct rb_root *root;
+ struct rb_node *next;
+
+ down_read(>bpf_progs.lock);
+
+ root = >bpf_progs.infos;
+ next = rb_first(root);
+
+ while (next) {
+ struct bpf_prog_info_node *node;
+
+ node = rb_entry(next, struct bpf_prog_info_node, rb_node);
+ next = rb_next(>rb_node);
+ fprintf(fp, "# bpf_prog_info of id %u\n",
+ node->info_linear->info.id);
+ }
+
+ up_read(>bpf_progs.lock);
+}
+
static void free_event_desc(struct perf_evsel *events)
{
struct perf_evsel *evsel;
@@ -2586,6 +2659,79 @@ static int process_clockid(struct feat_fd *ff,
return 0;
}
+static int process_bpf_prog_info(struct feat_fd *ff,
+void *data __maybe_unused)
+{
+ struct bpf_prog_info_linear *info_linear;
+ struct bpf_prog_info_node *info_node;
+ struct perf_env *env = >ph->env;
+ u32 count, i;
+ int err = -1;
+
+ if (do_read_u32(ff, ))
+ return -1;
+
+ if (ff->ph->needs_swap)
+ pr_warning("interpreting bpf_prog_info from systems with
endianity is not yet supported\n");
+
+ down_write(>bpf_progs.lock);
+
+ for (i = 0; i < count; ++i) {
+ u32 info_len, data_len;
+
+ info_linear = NULL;
+ info_node = NULL;
+ if (do_read_u32(ff, _len))
+ goto out;
+ if (do_read_u32(ff, _len))
+ goto out;
+
+ if (info_len > sizeof(struct bpf_prog_info)) {
+ pr_warning("detected invalid bpf_prog_info\n");
+ goto out;
+ }
+
+ info_linear = malloc(sizeof(struct bpf_prog_info_linear) +
+data_len);
+ if (!info_linear)
+ goto out;
+ info_linear->info_len = sizeof(struct bpf_prog_info);
+ info_linear->data_len = data_len;
+ if (do_read_u64(ff, (u64 *)(_linear->arrays)))
+ goto out;
+ if (__do_read(ff, _linear->info, info_len))
+
[PATCH v6 perf,bpf 08/15] perf, bpf: save btf in a rbtree in perf_env
btf contains information necessary to annotate bpf programs. This patch
saves btf for bpf programs loaded in the system.
Signed-off-by: Song Liu
---
tools/perf/util/bpf-event.c | 23 +
tools/perf/util/bpf-event.h | 7
tools/perf/util/env.c | 65 +
tools/perf/util/env.h | 4 +++
4 files changed, 99 insertions(+)
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index ce81b2c43a51..536ca95df5f4 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -34,6 +34,28 @@ int machine__process_bpf_event(struct machine *machine
__maybe_unused,
return 0;
}
+static int perf_env__fetch_btf(struct perf_env *env,
+ u32 btf_id,
+ struct btf *btf)
+{
+ struct btf_node *node;
+ u32 data_size;
+ const void *data;
+
+ data = btf__get_raw_data(btf, _size);
+
+ node = malloc(data_size + sizeof(struct btf_node));
+ if (!node)
+ return -1;
+
+ node->id = btf_id;
+ node->data_size = data_size;
+ memcpy(node->data, data, data_size);
+
+ perf_env__insert_btf(env, node);
+ return 0;
+}
+
/*
* Synthesize PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT for one bpf
* program. One PERF_RECORD_BPF_EVENT is generated for the program. And
@@ -113,6 +135,7 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_session *session,
goto out;
}
has_btf = true;
+ perf_env__fetch_btf(env, info->btf_id, btf);
}
/* Synthesize PERF_RECORD_KSYMBOL */
diff --git a/tools/perf/util/bpf-event.h b/tools/perf/util/bpf-event.h
index fad932f7404f..b9ec394dc7c7 100644
--- a/tools/perf/util/bpf-event.h
+++ b/tools/perf/util/bpf-event.h
@@ -16,6 +16,13 @@ struct bpf_prog_info_node {
struct rb_node rb_node;
};
+struct btf_node {
+ struct rb_node rb_node;
+ u32 id;
+ u32 data_size;
+ chardata[];
+};
+
#ifdef HAVE_LIBBPF_SUPPORT
int machine__process_bpf_event(struct machine *machine, union perf_event
*event,
struct perf_sample *sample);
diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
index cdda46f2633f..9e4ee7b0a3d1 100644
--- a/tools/perf/util/env.c
+++ b/tools/perf/util/env.c
@@ -63,6 +63,57 @@ struct bpf_prog_info_node
*perf_env__find_bpf_prog_info(struct perf_env *env,
return node;
}
+void perf_env__insert_btf(struct perf_env *env, struct btf_node *btf_node)
+{
+ struct rb_node *parent = NULL;
+ __u32 btf_id = btf_node->id;
+ struct btf_node *node;
+ struct rb_node **p;
+
+ down_write(>bpf_progs.lock);
+ p = >bpf_progs.btfs.rb_node;
+
+ while (*p != NULL) {
+ parent = *p;
+ node = rb_entry(parent, struct btf_node, rb_node);
+ if (btf_id < node->id) {
+ p = &(*p)->rb_left;
+ } else if (btf_id > node->id) {
+ p = &(*p)->rb_right;
+ } else {
+ pr_debug("duplicated btf %u\n", btf_id);
+ goto out;
+ }
+ }
+
+ rb_link_node(_node->rb_node, parent, p);
+ rb_insert_color(_node->rb_node, >bpf_progs.btfs);
+out:
+ up_write(>bpf_progs.lock);
+}
+
+struct btf_node *perf_env__find_btf(struct perf_env *env, __u32 btf_id)
+{
+ struct btf_node *node = NULL;
+ struct rb_node *n;
+
+ down_read(>bpf_progs.lock);
+ n = env->bpf_progs.btfs.rb_node;
+
+ while (n) {
+ node = rb_entry(n, struct btf_node, rb_node);
+ if (btf_id < node->id)
+ n = n->rb_left;
+ else if (btf_id > node->id)
+ n = n->rb_right;
+ else
+ break;
+ }
+
+ up_read(>bpf_progs.lock);
+ return node;
+}
+
/* purge data in bpf_progs.infos tree */
static void perf_env__purge_bpf(struct perf_env *env)
{
@@ -82,6 +133,19 @@ static void perf_env__purge_bpf(struct perf_env *env)
rb_erase_init(>rb_node, root);
free(node);
}
+
+ root = >bpf_progs.btfs;
+ next = rb_first(root);
+
+ while (next) {
+ struct btf_node *node;
+
+ node = rb_entry(next, struct btf_node, rb_node);
+ next = rb_next(>rb_node);
+ rb_erase_init(>rb_node, root);
+ free(node);
+ }
+
up_write(>bpf_progs.lock);
}
@@ -119,6 +183,7 @@ void perf_env__exit(struct perf_env *env)
void perf_env__init(struct perf_env *env)
{
env->bpf_progs.infos = RB_ROOT;
+ env->bpf_progs.btfs = RB_ROOT;
init_rwsem(>bpf_progs.lock);
}
diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h
index
[PATCH v6 perf,bpf 11/15] perf: add -lopcodes to feature-libbfd
Both libbfd and libopcodes are distributed with binutil-dev/devel. When libbfd presents, it is OK to assume libopcodes also presents. This has been a safe assumption for bpftool. This patch adds -lopcodes to perf/Makefile.config. libopcodes will be used in the next commit for bpf annotation. Signed-off-by: Song Liu --- tools/perf/Makefile.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index b441c88cafa1..e0bafbc273af 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -701,7 +701,7 @@ else endif ifeq ($(feature-libbfd), 1) - EXTLIBS += -lbfd + EXTLIBS += -lbfd -lopcodes else # we are on a system that requires -liberty and (maybe) -lz # to link against -lbfd; test each case individually here -- 2.17.1
[PATCH v6 perf,bpf 10/15] perf-top: add option --no-bpf-event
bpf events should be tracked by default for perf-top. This patch makes it
on by default, and adds option to disable bpf events.
Signed-off-by: Song Liu
---
tools/perf/builtin-top.c | 3 +++
tools/perf/util/top.h| 1 +
2 files changed, 4 insertions(+)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 27d8d42e0a4d..ccdf5689452f 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1492,6 +1492,7 @@ int cmd_top(int argc, const char **argv)
"Display raw encoding of assembly instructions (default)"),
OPT_BOOLEAN(0, "demangle-kernel", _conf.demangle_kernel,
"Enable kernel symbol demangling"),
+ OPT_BOOLEAN(0, "no-bpf-event", _bpf_event, "do not record bpf
events"),
OPT_STRING(0, "objdump", _opts.objdump_path, "path",
"objdump binary to use for disassembly and annotations"),
OPT_STRING('M', "disassembler-style",
_opts.disassembler_style, "disassembler style",
@@ -1651,6 +1652,8 @@ int cmd_top(int argc, const char **argv)
signal(SIGWINCH, winch_sig);
}
+ top.record_opts.bpf_event = !top.no_bpf_event;
+
status = __cmd_top();
out_delete_evlist:
diff --git a/tools/perf/util/top.h b/tools/perf/util/top.h
index 19f95eaf75c8..862a37bd27ea 100644
--- a/tools/perf/util/top.h
+++ b/tools/perf/util/top.h
@@ -32,6 +32,7 @@ struct perf_top {
bool use_tui, use_stdio;
bool vmlinux_warned;
bool dump_symtab;
+ bool no_bpf_event;
struct hist_entry *sym_filter_entry;
struct perf_evsel *sym_evsel;
struct perf_session *session;
--
2.17.1
[PATCH v6 perf,bpf 06/15] perf, bpf: save bpf_prog_info in a rbtree in perf_env
bpf_prog_info contains information necessary to annotate bpf programs.
This patch saves bpf_prog_info for bpf programs loaded in the system.
Some big picture of the next few patches:
To fully annotate BPF programs with source code mapping, 4 different
information are needed:
1) PERF_RECORD_KSYMBOL
2) PERF_RECORD_BPF_EVENT
3) bpf_prog_info
4) btf
Before this set, 1) and 2) in the list are already saved to perf.data
file. For BPF programs that are already loaded before perf run, 1) and 2)
are synthesized by perf_event__synthesize_bpf_events(). For short living
BPF programs, 1) and 2) are generated by kernel.
This set handles 3) and 4) from the list. Again, it is necessary to handle
existing BPF program and short living program separately.
This patch handles 3) for exising BPF programs while synthesizing 1) and
2) in perf_event__synthesize_bpf_events(). These data are stored in
perf_env. The next patch saves these data from perf_env to perf.data as
headers.
Similarly, the two patches after the next saves 4) of existing BPF
programs to perf_env and perf.data.
Another patch later will handle 3) and 4) for short living BPF programs
by monitoring 1) and 2) in a dedicate thread.
Signed-off-by: Song Liu
---
tools/perf/perf.c | 1 +
tools/perf/util/bpf-event.c | 32 +-
tools/perf/util/bpf-event.h | 7 +++-
tools/perf/util/env.c | 84 +
tools/perf/util/env.h | 18
tools/perf/util/session.c | 1 +
6 files changed, 141 insertions(+), 2 deletions(-)
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index a11cb006f968..72df4b6fa36f 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -298,6 +298,7 @@ static int run_builtin(struct cmd_struct *p, int argc,
const char **argv)
use_pager = 1;
commit_pager_choice();
+ perf_env__init(_env);
perf_env__set_cmdline(_env, argc, argv);
status = p->fn(argc, argv);
perf_config__exit();
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index ff7ee149ec46..ce81b2c43a51 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -10,6 +10,7 @@
#include "debug.h"
#include "symbol.h"
#include "machine.h"
+#include "env.h"
#include "session.h"
#define ptr_to_u64(ptr)((__u64)(unsigned long)(ptr))
@@ -54,17 +55,28 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_session *session,
struct bpf_event *bpf_event = >bpf_event;
struct bpf_prog_info_linear *info_linear;
struct perf_tool *tool = session->tool;
+ struct bpf_prog_info_node *info_node;
struct bpf_prog_info *info;
struct btf *btf = NULL;
bool has_btf = false;
+ struct perf_env *env;
u32 sub_prog_cnt, i;
int err = 0;
u64 arrays;
+ /*
+* for perf-record and perf-report use header.env;
+* otherwise, use global perf_env.
+*/
+ env = session->data ? >header.env : _env;
+
arrays = 1UL << BPF_PROG_INFO_JITED_KSYMS;
arrays |= 1UL << BPF_PROG_INFO_JITED_FUNC_LENS;
arrays |= 1UL << BPF_PROG_INFO_FUNC_INFO;
arrays |= 1UL << BPF_PROG_INFO_PROG_TAGS;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_INSNS;
+ arrays |= 1UL << BPF_PROG_INFO_LINE_INFO;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_LINE_INFO;
info_linear = bpf_program__get_prog_info_linear(fd, arrays);
if (IS_ERR_OR_NULL(info_linear)) {
@@ -153,8 +165,8 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_session *session,
machine, process);
}
- /* Synthesize PERF_RECORD_BPF_EVENT */
if (opts->bpf_event) {
+ /* Synthesize PERF_RECORD_BPF_EVENT */
*bpf_event = (struct bpf_event){
.header = {
.type = PERF_RECORD_BPF_EVENT,
@@ -167,6 +179,24 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_session *session,
memcpy(bpf_event->tag, info->tag, BPF_TAG_SIZE);
memset((void *)event + event->header.size, 0,
machine->id_hdr_size);
event->header.size += machine->id_hdr_size;
+
+ /* save bpf_prog_info to env */
+ info_node = malloc(sizeof(struct bpf_prog_info_node));
+
+ /*
+* Do not bail out for !info_node, as we still want to
+* call perf_tool__process_synth_event()
+*/
+ if (info_node) {
+ info_node->info_linear = info_linear;
+ perf_env__insert_bpf_prog_info(env, info_node);
+ info_linear = NULL;
+ }
+
+ /*
+* process after saving bpf_prog_info to env, so that
+* required information is ready for look up
+*/
[PATCH v6 perf,bpf 05/15] perf: change prototype of perf_event__synthesize_bpf_events()
This patch changes the arguments of perf_event__synthesize_bpf_events()
to include perf_session* instead of perf_tool*. perf_session will be used
in the next patch.
Signed-off-by: Song Liu
---
tools/perf/builtin-record.c | 2 +-
tools/perf/builtin-top.c| 2 +-
tools/perf/util/bpf-event.c | 8 +---
tools/perf/util/bpf-event.h | 4 ++--
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 88ea11d57c6f..2355e0a9eda0 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1083,7 +1083,7 @@ static int record__synthesize(struct record *rec, bool
tail)
return err;
}
- err = perf_event__synthesize_bpf_events(tool, process_synthesized_event,
+ err = perf_event__synthesize_bpf_events(session,
process_synthesized_event,
machine, opts);
if (err < 0)
pr_warning("Couldn't synthesize bpf events.\n");
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 5a486d4de56e..27d8d42e0a4d 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1216,7 +1216,7 @@ static int __cmd_top(struct perf_top *top)
init_process_thread(top);
- ret = perf_event__synthesize_bpf_events(>tool, perf_event__process,
+ ret = perf_event__synthesize_bpf_events(top->session,
perf_event__process,
>session->machines.host,
>record_opts);
if (ret < 0)
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index e6dfb95029e5..ff7ee149ec46 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -10,6 +10,7 @@
#include "debug.h"
#include "symbol.h"
#include "machine.h"
+#include "session.h"
#define ptr_to_u64(ptr)((__u64)(unsigned long)(ptr))
@@ -42,7 +43,7 @@ int machine__process_bpf_event(struct machine *machine
__maybe_unused,
* -1 for failures;
* -2 for lack of kernel support.
*/
-static int perf_event__synthesize_one_bpf_prog(struct perf_tool *tool,
+static int perf_event__synthesize_one_bpf_prog(struct perf_session *session,
perf_event__handler_t process,
struct machine *machine,
int fd,
@@ -52,6 +53,7 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_tool *tool,
struct ksymbol_event *ksymbol_event = >ksymbol_event;
struct bpf_event *bpf_event = >bpf_event;
struct bpf_prog_info_linear *info_linear;
+ struct perf_tool *tool = session->tool;
struct bpf_prog_info *info;
struct btf *btf = NULL;
bool has_btf = false;
@@ -175,7 +177,7 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_tool *tool,
return err ? -1 : 0;
}
-int perf_event__synthesize_bpf_events(struct perf_tool *tool,
+int perf_event__synthesize_bpf_events(struct perf_session *session,
perf_event__handler_t process,
struct machine *machine,
struct record_opts *opts)
@@ -209,7 +211,7 @@ int perf_event__synthesize_bpf_events(struct perf_tool
*tool,
continue;
}
- err = perf_event__synthesize_one_bpf_prog(tool, process,
+ err = perf_event__synthesize_one_bpf_prog(session, process,
machine, fd,
event, opts);
close(fd);
diff --git a/tools/perf/util/bpf-event.h b/tools/perf/util/bpf-event.h
index 7890067e1a37..6698683612a7 100644
--- a/tools/perf/util/bpf-event.h
+++ b/tools/perf/util/bpf-event.h
@@ -15,7 +15,7 @@ struct record_opts;
int machine__process_bpf_event(struct machine *machine, union perf_event
*event,
struct perf_sample *sample);
-int perf_event__synthesize_bpf_events(struct perf_tool *tool,
+int perf_event__synthesize_bpf_events(struct perf_session *session,
perf_event__handler_t process,
struct machine *machine,
struct record_opts *opts);
@@ -27,7 +27,7 @@ static inline int machine__process_bpf_event(struct machine
*machine __maybe_unu
return 0;
}
-static inline int perf_event__synthesize_bpf_events(struct perf_tool *tool
__maybe_unused,
+static inline int perf_event__synthesize_bpf_events(struct perf_session
*session __maybe_unused,
perf_event__handler_t
process __maybe_unused,
struct machine *machine
__maybe_unused,
[PATCH v6 perf,bpf 15/15] perf, bpf: save bpf_prog_info and btf of short living bpf programs
To fully annotate BPF programs with source code mapping, 4 different
information are needed:
1) PERF_RECORD_KSYMBOL
2) PERF_RECORD_BPF_EVENT
3) bpf_prog_info
4) btf
This patch handles 3) and 4) for short living BPF programs. For timely
process of these information, a dedicated event is added to the side
band evlist. When PERF_RECORD_BPF_EVENT is received via the side band
event, the polling thread gathers 3) and 4) vis sys_bpf and store them
in perf_env. These information are saved to perf.data at the end of
perf-record.
Signed-off-by: Song Liu
---
tools/perf/builtin-record.c | 2 +
tools/perf/builtin-top.c| 2 +
tools/perf/util/bpf-event.c | 95 +
tools/perf/util/bpf-event.h | 15 ++
4 files changed, 114 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 435b94f1f3b3..8d197762a499 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1207,6 +1207,8 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
goto out_child;
}
+ if (opts->bpf_event)
+ bpf_event__add_sb_event(_evlist, >header.env);
perf_evlist__start_sb_thread(sb_evlist, >opts.target);
err = record__synthesize(rec, false);
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index ec69eb040933..0d0da834dd9d 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1655,6 +1655,8 @@ int cmd_top(int argc, const char **argv)
top.record_opts.bpf_event = !top.no_bpf_event;
+ if (top.record_opts.bpf_event)
+ bpf_event__add_sb_event(_evlist, _env);
perf_evlist__start_sb_thread(sb_evlist, target);
status = __cmd_top();
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index 9e3eae44c1d5..78e85832c1b4 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -12,6 +12,7 @@
#include "machine.h"
#include "env.h"
#include "session.h"
+#include "evlist.h"
#define ptr_to_u64(ptr)((__u64)(unsigned long)(ptr))
@@ -331,3 +332,97 @@ int perf_event__synthesize_bpf_events(struct perf_session
*session,
free(event);
return err;
}
+
+static void perf_env__add_bpf_info(struct perf_env *env, u32 id)
+{
+ struct bpf_prog_info_linear *info_linear;
+ struct bpf_prog_info_node *info_node;
+ struct btf *btf = NULL;
+ u64 arrays;
+ u32 btf_id;
+ int fd;
+
+ fd = bpf_prog_get_fd_by_id(id);
+ if (fd < 0)
+ return;
+
+ arrays = 1UL << BPF_PROG_INFO_JITED_KSYMS;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_FUNC_LENS;
+ arrays |= 1UL << BPF_PROG_INFO_FUNC_INFO;
+ arrays |= 1UL << BPF_PROG_INFO_PROG_TAGS;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_INSNS;
+ arrays |= 1UL << BPF_PROG_INFO_LINE_INFO;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_LINE_INFO;
+
+ info_linear = bpf_program__get_prog_info_linear(fd, arrays);
+ if (IS_ERR_OR_NULL(info_linear)) {
+ pr_debug("%s: failed to get BPF program info. aborting\n",
__func__);
+ goto out;
+ }
+
+ btf_id = info_linear->info.btf_id;
+
+ info_node = malloc(sizeof(struct bpf_prog_info_node));
+ if (info_node) {
+ info_node->info_linear = info_linear;
+ perf_env__insert_bpf_prog_info(env, info_node);
+ } else
+ free(info_linear);
+
+ if (btf_id == 0)
+ goto out;
+
+ if (btf__get_from_id(btf_id, )) {
+ pr_debug("%s: failed to get BTF of id %u, aborting\n",
+__func__, btf_id);
+ goto out;
+ }
+ perf_env__fetch_btf(env, btf_id, btf);
+
+out:
+ free(btf);
+ close(fd);
+}
+
+static int bpf_event__sb_cb(union perf_event *event, void *data)
+{
+ struct perf_env *env = data;
+
+ if (event->header.type != PERF_RECORD_BPF_EVENT)
+ return -1;
+
+ switch (event->bpf_event.type) {
+ case PERF_BPF_EVENT_PROG_LOAD:
+ perf_env__add_bpf_info(env, event->bpf_event.id);
+
+ case PERF_BPF_EVENT_PROG_UNLOAD:
+ /*
+* Do not free bpf_prog_info and btf of the program here,
+* as annotation still need them. They will be freed at
+* the end of the session.
+*/
+ break;
+ default:
+ pr_debug("unexpected bpf_event type of %d\n",
+event->bpf_event.type);
+ break;
+ }
+
+ return 0;
+}
+
+int bpf_event__add_sb_event(struct perf_evlist **evlist,
+ struct perf_env *env)
+{
+ struct perf_event_attr attr = {
+ .type = PERF_TYPE_SOFTWARE,
+ .config = PERF_COUNT_SW_DUMMY,
+ .sample_id_all= 1,
+
[PATCH v6 perf,bpf 14/15] perf: introduce side band thread
This patch introduces side band thread that captures extended information
for events like PERF_RECORD_BPF_EVENT.
This new thread uses its own evlist that uses ring buffer with very low
watermark for lower latency.
To use side band thread, we need to:
1. add side band event(s) by calling perf_evlist__add_sb_event();
2. calls perf_evlist__start_sb_thread();
3. at the end of perf run, perf_evlist__stop_sb_thread().
In the next patch, we use this thread to handle PERF_RECORD_BPF_EVENT.
Signed-off-by: Song Liu
---
tools/perf/builtin-record.c | 5 ++
tools/perf/builtin-top.c| 5 ++
tools/perf/util/evlist.c| 113
tools/perf/util/evlist.h| 13 +
tools/perf/util/evsel.h | 6 ++
5 files changed, 142 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2355e0a9eda0..435b94f1f3b3 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1106,6 +1106,7 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
struct perf_data *data = >data;
struct perf_session *session;
bool disabled = false, draining = false;
+ struct perf_evlist *sb_evlist = NULL;
int fd;
atexit(record__sig_exit);
@@ -1206,6 +1207,8 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
goto out_child;
}
+ perf_evlist__start_sb_thread(sb_evlist, >opts.target);
+
err = record__synthesize(rec, false);
if (err < 0)
goto out_child;
@@ -1456,6 +1459,8 @@ static int __cmd_record(struct record *rec, int argc,
const char **argv)
out_delete_session:
perf_session__delete(session);
+
+ perf_evlist__stop_sb_thread(sb_evlist);
return status;
}
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index ccdf5689452f..ec69eb040933 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1524,6 +1524,7 @@ int cmd_top(int argc, const char **argv)
"number of thread to run event synthesize"),
OPT_END()
};
+ struct perf_evlist *sb_evlist = NULL;
const char * const top_usage[] = {
"perf top []",
NULL
@@ -1654,8 +1655,12 @@ int cmd_top(int argc, const char **argv)
top.record_opts.bpf_event = !top.no_bpf_event;
+ perf_evlist__start_sb_thread(sb_evlist, target);
+
status = __cmd_top();
+ perf_evlist__stop_sb_thread(sb_evlist);
+
out_delete_evlist:
perf_evlist__delete(top.evlist);
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 8c902276d4b4..a06a4f54b083 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -19,6 +19,7 @@
#include "debug.h"
#include "units.h"
#include "asm/bug.h"
+#include "bpf-event.h"
#include
#include
@@ -1841,3 +1842,115 @@ struct perf_evsel *perf_evlist__reset_weak_group(struct
perf_evlist *evsel_list,
}
return leader;
}
+
+int perf_evlist__add_sb_event(struct perf_evlist **evlist,
+ struct perf_event_attr *attr,
+ perf_evsel__sb_cb_t cb,
+ void *data)
+{
+ struct perf_evsel *evsel;
+ bool new_evlist = (*evlist) == NULL;
+
+ if (*evlist == NULL)
+ *evlist = perf_evlist__new();
+ if (*evlist == NULL)
+ return -1;
+
+ if (!attr->sample_id_all) {
+ pr_warning("enabling sample_id_all for all side band events\n");
+ attr->sample_id_all = 1;
+ }
+
+ evsel = perf_evsel__new_idx(attr, (*evlist)->nr_entries);
+ if (!evsel)
+ goto out_err;
+
+ evsel->side_band.cb = cb;
+ evsel->side_band.data = data;
+ perf_evlist__add(*evlist, evsel);
+ return 0;
+
+out_err:
+ if (new_evlist) {
+ perf_evlist__delete(*evlist);
+ *evlist = NULL;
+ }
+ return -1;
+}
+
+static void *perf_evlist__poll_thread(void *arg)
+{
+ struct perf_evlist *evlist = arg;
+ int i;
+
+ while (!(evlist->thread.done)) {
+ perf_evlist__poll(evlist, 1000);
+
+ for (i = 0; i < evlist->nr_mmaps; i++) {
+ struct perf_mmap *map = >mmap[i];
+ union perf_event *event;
+
+ if (perf_mmap__read_init(map))
+ continue;
+ while ((event = perf_mmap__read_event(map)) != NULL) {
+ struct perf_evsel *evsel =
perf_evlist__event2evsel(evlist, event);
+
+ if (evsel && evsel->side_band.cb)
+ evsel->side_band.cb(event,
evsel->side_band.data);
+ else
+ pr_warning("cannot locate proper evsel
for the
[PATCH v6 perf,bpf 12/15] perf, bpf: enable annotation of bpf program
This patch enables the annotation of bpf program.
A new dso type DSO_BINARY_TYPE__BPF_PROG_INFO is introduced to for BPF
programs. In symbol__disassemble(), DSO_BINARY_TYPE__BPF_PROG_INFO dso
calls into a new function symbol__disassemble_bpf(), where annotation
line information is filled based bpf_prog_info and btf saved in given
perf_env.
symbol__disassemble_bpf() uses libbfd to disassemble bpf programs.
Signed-off-by: Song Liu
---
tools/build/Makefile.feature | 6 +-
tools/perf/Makefile.config | 4 +
tools/perf/util/annotate.c | 150 ++-
tools/perf/util/dso.c| 1 +
tools/perf/util/dso.h| 33 +---
tools/perf/util/symbol.c | 1 +
6 files changed, 181 insertions(+), 14 deletions(-)
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 5467c6bf9ceb..4f35e9ff1e00 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -71,7 +71,8 @@ FEATURE_TESTS_BASIC := \
sdt\
setns \
libopencsd \
-libaio
+libaio \
+disassembler-four-args
# FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list
# of all feature tests
@@ -118,7 +119,8 @@ FEATURE_DISPLAY ?= \
lzma \
get_cpuid \
bpf \
- libaio
+ libaio\
+ disassembler-four-args
# Set FEATURE_CHECK_(C|LD)FLAGS-all for all FEATURE_TESTS features.
# If in the future we need per-feature checks/flags for features not
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index e0bafbc273af..ab223239f1fb 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -796,6 +796,10 @@ ifdef HAVE_KVM_STAT_SUPPORT
CFLAGS += -DHAVE_KVM_STAT_SUPPORT
endif
+ifeq ($(feature-disassembler-four-args), 1)
+CFLAGS += -DDISASM_FOUR_ARGS_SIGNATURE
+endif
+
ifeq (${IS_64_BIT}, 1)
ifndef NO_PERF_READ_VDSO32
$(call feature_check,compile-32)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 70de8f6b3aee..e467aa0ef0c2 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -9,6 +9,10 @@
#include
#include
+#include
+#include
+#include
+#include
#include "util.h"
#include "ui/ui.h"
#include "sort.h"
@@ -22,6 +26,7 @@
#include "annotate.h"
#include "evsel.h"
#include "evlist.h"
+#include "bpf-event.h"
#include "block-range.h"
#include "string2.h"
#include "arch/common.h"
@@ -29,6 +34,9 @@
#include
#include
#include
+#include
+#include
+#include
/* FIXME: For the HE_COLORSET */
#include "ui/browser.h"
@@ -1672,6 +1680,144 @@ static int dso__disassemble_filename(struct dso *dso,
char *filename, size_t fil
return 0;
}
+static int symbol__disassemble_bpf(struct symbol *sym,
+ struct annotate_args *args)
+{
+ struct annotation *notes = symbol__annotation(sym);
+ struct annotation_options *opts = args->options;
+ struct bpf_prog_info_linear *info_linear;
+ struct bpf_prog_linfo *prog_linfo = NULL;
+ struct bpf_prog_info_node *info_node;
+ int len = sym->end - sym->start;
+ disassembler_ftype disassemble;
+ struct map *map = args->ms.map;
+ struct disassemble_info info;
+ struct dso *dso = map->dso;
+ int pc = 0, count, sub_id;
+ struct btf *btf = NULL;
+ char tpath[PATH_MAX];
+ size_t buf_size;
+ int nr_skip = 0;
+ int ret = -1;
+ char *buf;
+ bfd *bfdf;
+ FILE *s;
+
+ if (dso->binary_type != DSO_BINARY_TYPE__BPF_PROG_INFO)
+ return -1;
+
+ pr_debug("%s: handling sym %s addr %lx len %lx\n", __func__,
+sym->name, sym->start, sym->end - sym->start);
+
+ memset(tpath, 0, sizeof(tpath));
+ perf_exe(tpath, sizeof(tpath));
+
+ bfdf = bfd_openr(tpath, NULL);
+ assert(bfdf);
+ assert(bfd_check_format(bfdf, bfd_object));
+
+ s = open_memstream(, _size);
+ if (!s)
+ goto out;
+ init_disassemble_info(, s,
+ (fprintf_ftype) fprintf);
+
+ info.arch = bfd_get_arch(bfdf);
+ info.mach = bfd_get_mach(bfdf);
+
+ info_node = perf_env__find_bpf_prog_info(dso->bpf_prog.env,
+dso->bpf_prog.id);
+ if (!info_node)
+ goto out;
+ info_linear = info_node->info_linear;
+ sub_id = dso->bpf_prog.sub_id;
+
+ info.buffer = (void *)(info_linear->info.jited_prog_insns);
+ info.buffer_length = info_linear->info.jited_prog_len;
+
+ if (info_linear->info.nr_line_info)
+ prog_linfo = bpf_prog_linfo__new(_linear->info);
+
+ if (info_linear->info.btf_id) {
+
[PATCH v6 perf,bpf 09/15] perf, bpf: save btf information as headers to perf.data
This patch enables perf-record to save btf information as headers to
perf.data A new header type HEADER_BPF_BTF is introduced for this data.
Signed-off-by: Song Liu
---
tools/perf/util/header.c | 111 ++-
tools/perf/util/header.h | 1 +
2 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index cd19b7891db7..1a329da6011b 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1124,6 +1124,45 @@ static int write_bpf_prog_info(struct feat_fd *ff,
return ret;
}
+static int write_bpf_btf(struct feat_fd *ff,
+struct perf_evlist *evlist __maybe_unused)
+{
+ struct perf_env *env = >ph->env;
+ struct rb_root *root;
+ struct rb_node *next;
+ u32 count = 0;
+ int ret;
+
+ down_read(>bpf_progs.lock);
+
+ root = >bpf_progs.btfs;
+ next = rb_first(root);
+ while (next) {
+ ++count;
+ next = rb_next(next);
+ }
+
+ ret = do_write(ff, , sizeof(count));
+
+ if (ret < 0)
+ goto out;
+
+ next = rb_first(root);
+ while (next) {
+ struct btf_node *node;
+
+ node = rb_entry(next, struct btf_node, rb_node);
+ next = rb_next(>rb_node);
+ ret = do_write(ff, >id,
+ sizeof(u32) * 2 + node->data_size);
+ if (ret < 0)
+ goto out;
+ }
+out:
+ up_read(>bpf_progs.lock);
+ return ret;
+}
+
static int cpu_cache_level__sort(const void *a, const void *b)
{
struct cpu_cache_level *cache_a = (struct cpu_cache_level *)a;
@@ -1627,6 +1666,28 @@ static void print_bpf_prog_info(struct feat_fd *ff, FILE
*fp)
up_read(>bpf_progs.lock);
}
+static void print_bpf_btf(struct feat_fd *ff, FILE *fp)
+{
+ struct perf_env *env = >ph->env;
+ struct rb_root *root;
+ struct rb_node *next;
+
+ down_read(>bpf_progs.lock);
+
+ root = >bpf_progs.btfs;
+ next = rb_first(root);
+
+ while (next) {
+ struct btf_node *node;
+
+ node = rb_entry(next, struct btf_node, rb_node);
+ next = rb_next(>rb_node);
+ fprintf(fp, "# btf info of id %u\n", node->id);
+ }
+
+ up_read(>bpf_progs.lock);
+}
+
static void free_event_desc(struct perf_evsel *events)
{
struct perf_evsel *evsel;
@@ -2732,6 +2793,53 @@ static int process_bpf_prog_info(struct feat_fd *ff,
return err;
}
+static int process_bpf_btf(struct feat_fd *ff, void *data __maybe_unused)
+{
+ struct perf_env *env = >ph->env;
+ u32 count, i;
+
+ if (do_read_u32(ff, ))
+ return -1;
+
+ if (ff->ph->needs_swap)
+ pr_warning("interpreting btf from systems with endianity is not
yet supported\n");
+
+ down_write(>bpf_progs.lock);
+
+ for (i = 0; i < count; ++i) {
+ struct btf_node *node;
+ u32 id, data_size;
+
+ if (do_read_u32(ff, ))
+ return -1;
+ if (do_read_u32(ff, _size))
+ return -1;
+
+ node = malloc(sizeof(struct btf_node) + data_size);
+ if (!node)
+ return -1;
+
+ node->id = id;
+ node->data_size = data_size;
+
+ if (__do_read(ff, node->data, data_size)) {
+ free(node);
+ return -1;
+ }
+
+ /* endian mismatch, drop the btf, continue */
+ if (ff->ph->needs_swap) {
+ free(node);
+ continue;
+ }
+
+ perf_env__insert_btf(env, node);
+ }
+
+ up_write(>bpf_progs.lock);
+ return 0;
+}
+
struct feature_ops {
int (*write)(struct feat_fd *ff, struct perf_evlist *evlist);
void (*print)(struct feat_fd *ff, FILE *fp);
@@ -2792,7 +2900,8 @@ static const struct feature_ops
feat_ops[HEADER_LAST_FEATURE] = {
FEAT_OPR(SAMPLE_TIME, sample_time,false),
FEAT_OPR(MEM_TOPOLOGY, mem_topology, true),
FEAT_OPR(CLOCKID, clockid,false),
- FEAT_OPR(BPF_PROG_INFO, bpf_prog_info, false)
+ FEAT_OPR(BPF_PROG_INFO, bpf_prog_info, false),
+ FEAT_OPR(BPF_BTF, bpf_btf,false)
};
struct header_print_data {
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index 0785c91b4c3a..9e7d931f7c0d 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -40,6 +40,7 @@ enum {
HEADER_MEM_TOPOLOGY,
HEADER_CLOCKID,
HEADER_BPF_PROG_INFO,
+ HEADER_BPF_BTF,
HEADER_LAST_FEATURE,
HEADER_FEAT_BITS= 256,
};
--
2.17.1
Re: [PATCH 0/8] qcom: spmi/ssbi gpio: correct gpio hogging
On Wed, Mar 6, 2019 at 1:53 AM Brian Masney wrote: > Here are some patches that fix gpio hogging for all boards that use > spmi-gpio and ssbi-gpio. This series: Reviewed-by: Linus Walleij Thanks for your perseverance! Yours, Linus Walleij
Re: [PATCH v5 4/8] dt-bindings: devfreq: add Exynos5422 DMC device description
Hi Chanwoo,
On 3/6/19 5:18 AM, Chanwoo Choi wrote:
> Hi Lukasz,
>
> On 19. 3. 5. 오후 7:19, Lukasz Luba wrote:
>> The patch adds description for DT binding for a new Exynos5422 Dynamic
>> Memory Controller device.
>>
>> Signed-off-by: Lukasz Luba
>> ---
>> .../devicetree/bindings/devfreq/exynos5422-dmc.txt | 177
>> +
>> 1 file changed, 177 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>> b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>> new file mode 100644
>> index 000..0e73e98
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>> @@ -0,0 +1,177 @@
>> +* Exynos5422 frequency and voltage scaling for Dynamic Memory Controller
>> device
>> +
>> +The Samsung Exynos5422 SoC has DMC (Dynamic Memory Controller) to which the
>> DRAM
>> +memory chips are connected. The driver is to monitor the controller in
>> runtime
>> +and switch frequency and voltage. To monitor the usage of the controller in
>> +runtime, the driver uses the PPMU (Platform Performance Monitoring Unit),
>> which
>> +is able to measure the current load of the memory.
>> +When 'userspace' governor is used for the driver, an application is able to
>> +switch the DMC frequency.
>> +
>> +Required properties for DMC device for Exynos5422:
>> +- compatible: Should be "samsung,exynos5422-bus".
>> +- clock-names : the name of clock used by the bus, "bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- devfreq-events : phandles for PPMU devices connected to this DMC.
>
>
> I already replied with following comments on v4 patch[1].
> But, you didn't reply anything. We can reduce the duplicate
> review by keeping the basic review rule.
I have lost these changes while I was adding the OPPs, timings into the
dt-binding.
>
> - Re: [PATCH v4 5/8] dt-bindings: devfreq: add Exynos5422 DMC device
> description
> [1] https://do-db2.lkml.org/lkml/2019/2/3/64
>
>
> [Following comments were replied on v4 patch[1]]
>
>> +- compatible: Should be "samsung,exynos5422-bus".
>
> The compatible name is wrong.
> - exynos5422-bus -> exynos5422-dmc
>
>> +- clock-names : the name of clock used by the bus, "bus".
>
> 'bus' is right?
right
>
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- devfreq-events : phandles for PPMU devices connected to this DMC.
>
> The dt-binging file doesn't contain the any description for 'reg' properties.
There are 3 regs: cdrex0, cdrex1, chip_id. I will add this description.
The patch set has this OPPs and timings coming from DT as you requested
but I am not sure if it is in the right place in the DT.
Thus dt-binding you may consider as 'in-progress' till the DT entries
are fixed
Regards,
Lukasz
>
>
>
>> +
>> +The example definition of a DMC and PPMU devices declared in DT is shown
>> below:
>> +
>> +ppmu_dmc0_0: ppmu@10d0 {
>> +compatible = "samsung,exynos-ppmu";
>> +reg = <0x10d0 0x2000>;
>> +clocks = < CLK_PCLK_PPMU_DREX0_0>;
>> +clock-names = "ppmu";
>> +status = "okay";
>> +events {
>> +ppmu_event_dmc0_0: ppmu-event3-dmc0_0 {
>> +event-name = "ppmu-event3-dmc0_0";
>> +};
>> +};
>> +};
>> +
>> +
>> +ppmu_dmc0_1: ppmu@10d1 {
>> +compatible = "samsung,exynos-ppmu";
>> +reg = <0x10d1 0x2000>;
>> +clocks = < CLK_PCLK_PPMU_DREX0_1>;
>> +clock-names = "ppmu";
>> +status = "okay";
>> +events {
>> +ppmu_event_dmc0_1: ppmu-event3-dmc0_1 {
>> +event-name = "ppmu-event3-dmc0_1";
>> +};
>> +};
>> +};
>> +
>> +ppmu_dmc1_0: ppmu@10d1 {
>> +compatible = "samsung,exynos-ppmu";
>> +reg = <0x10d6 0x2000>;
>> +clocks = < CLK_PCLK_PPMU_DREX1_0>;
>> +clock-names = "ppmu";
>> +status = "okay";
>> +events {
>> +ppmu_event_dmc1_0: ppmu-event3-dmc1_0 {
>> +event-name = "ppmu-event3-dmc1_0";
>> +};
>> +};
>> +};
>> +
>> +ppmu_dmc1_1: ppmu@10d7 {
>> +compatible = "samsung,exynos-ppmu";
>> +reg = <0x10d7 0x2000>;
>> +clocks = < CLK_PCLK_PPMU_DREX1_1>;
>> +clock-names = "ppmu";
>> +status = "okay";
>> +events {
>> +ppmu_event_dmc1_1: ppmu-event3-dmc1_1 {
>> +event-name = "ppmu-event3-dmc1_1";
>> +};
>> +};
>> +};
>> +
>> +dmc: memory-controller@10c2 {
>> +compatible = "samsung,exynos5422-dmc";
>> +
[PATCH v6 perf,bpf 13/15] perf, bpf: process PERF_BPF_EVENT_PROG_LOAD for annotation
This patch adds processing of PERF_BPF_EVENT_PROG_LOAD, which sets proper
DSO type/id/etc of memory regions mapped to BPF programs to
DSO_BINARY_TYPE__BPF_PROG_INFO
Signed-off-by: Song Liu
---
tools/perf/util/bpf-event.c | 53 +
1 file changed, 53 insertions(+)
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index 536ca95df5f4..9e3eae44c1d5 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -25,12 +25,65 @@ static int snprintf_hex(char *buf, size_t size, unsigned
char *data, size_t len)
return ret;
}
+static int machine__process_bpf_event_load(struct machine *machine,
+ union perf_event *event,
+ struct perf_sample *sample
__maybe_unused)
+{
+ struct bpf_prog_info_linear *info_linear;
+ struct bpf_prog_info_node *info_node;
+ struct perf_env *env = machine->env;
+ int id = event->bpf_event.id;
+ unsigned int i;
+
+ /* perf-record, no need to handle bpf-event */
+ if (env == NULL)
+ return 0;
+
+ info_node = perf_env__find_bpf_prog_info(env, id);
+ if (!info_node)
+ return 0;
+ info_linear = info_node->info_linear;
+
+ for (i = 0; i < info_linear->info.nr_jited_ksyms; i++) {
+ u64 *addrs = (u64 *)(info_linear->info.jited_ksyms);
+ u64 addr = addrs[i];
+ struct map *map;
+
+ map = map_groups__find(>kmaps, addr);
+
+ if (map) {
+ map->dso->binary_type = DSO_BINARY_TYPE__BPF_PROG_INFO;
+ map->dso->bpf_prog.id = id;
+ map->dso->bpf_prog.sub_id = i;
+ map->dso->bpf_prog.env = env;
+ }
+ }
+ return 0;
+}
+
int machine__process_bpf_event(struct machine *machine __maybe_unused,
union perf_event *event,
struct perf_sample *sample __maybe_unused)
{
if (dump_trace)
perf_event__fprintf_bpf_event(event, stdout);
+
+ switch (event->bpf_event.type) {
+ case PERF_BPF_EVENT_PROG_LOAD:
+ return machine__process_bpf_event_load(machine, event, sample);
+
+ case PERF_BPF_EVENT_PROG_UNLOAD:
+ /*
+* Do not free bpf_prog_info and btf of the program here,
+* as annotation still need them. They will be freed at
+* the end of the session.
+*/
+ break;
+ default:
+ pr_debug("unexpected bpf_event type of %d\n",
+event->bpf_event.type);
+ break;
+ }
return 0;
}
--
2.17.1
[PATCH v6 perf,bpf 04/15] perf, bpf: synthesize bpf events with bpf_program__get_prog_info_linear()
With bpf_program__get_prog_info_linear, we can simplify the logic that
synthesizes bpf events.
This patch doesn't change the behavior of the code.
Signed-off-by: Song Liu
---
tools/perf/util/bpf-event.c | 118
1 file changed, 40 insertions(+), 78 deletions(-)
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index 796ef793f4ce..e6dfb95029e5 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -3,7 +3,9 @@
#include
#include
#include
+#include
#include
+#include
#include "bpf-event.h"
#include "debug.h"
#include "symbol.h"
@@ -49,99 +51,62 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_tool *tool,
{
struct ksymbol_event *ksymbol_event = >ksymbol_event;
struct bpf_event *bpf_event = >bpf_event;
- u32 sub_prog_cnt, i, func_info_rec_size = 0;
- u8 (*prog_tags)[BPF_TAG_SIZE] = NULL;
- struct bpf_prog_info info = { .type = 0, };
- u32 info_len = sizeof(info);
- void *func_infos = NULL;
- u64 *prog_addrs = NULL;
+ struct bpf_prog_info_linear *info_linear;
+ struct bpf_prog_info *info;
struct btf *btf = NULL;
- u32 *prog_lens = NULL;
bool has_btf = false;
- char errbuf[512];
+ u32 sub_prog_cnt, i;
int err = 0;
+ u64 arrays;
- /* Call bpf_obj_get_info_by_fd() to get sizes of arrays */
- err = bpf_obj_get_info_by_fd(fd, , _len);
+ arrays = 1UL << BPF_PROG_INFO_JITED_KSYMS;
+ arrays |= 1UL << BPF_PROG_INFO_JITED_FUNC_LENS;
+ arrays |= 1UL << BPF_PROG_INFO_FUNC_INFO;
+ arrays |= 1UL << BPF_PROG_INFO_PROG_TAGS;
- if (err) {
- pr_debug("%s: failed to get BPF program info: %s, aborting\n",
-__func__, str_error_r(errno, errbuf, sizeof(errbuf)));
+ info_linear = bpf_program__get_prog_info_linear(fd, arrays);
+ if (IS_ERR_OR_NULL(info_linear)) {
+ info_linear = NULL;
+ pr_debug("%s: failed to get BPF program info. aborting\n",
__func__);
return -1;
}
- if (info_len < offsetof(struct bpf_prog_info, prog_tags)) {
+
+ if (info_linear->info_len < offsetof(struct bpf_prog_info, prog_tags)) {
pr_debug("%s: the kernel is too old, aborting\n", __func__);
return -2;
}
+ info = _linear->info;
+
/* number of ksyms, func_lengths, and tags should match */
- sub_prog_cnt = info.nr_jited_ksyms;
- if (sub_prog_cnt != info.nr_prog_tags ||
- sub_prog_cnt != info.nr_jited_func_lens)
+ sub_prog_cnt = info->nr_jited_ksyms;
+ if (sub_prog_cnt != info->nr_prog_tags ||
+ sub_prog_cnt != info->nr_jited_func_lens)
return -1;
/* check BTF func info support */
- if (info.btf_id && info.nr_func_info && info.func_info_rec_size) {
+ if (info->btf_id && info->nr_func_info && info->func_info_rec_size) {
/* btf func info number should be same as sub_prog_cnt */
- if (sub_prog_cnt != info.nr_func_info) {
+ if (sub_prog_cnt != info->nr_func_info) {
pr_debug("%s: mismatch in BPF sub program count and BTF
function info count, aborting\n", __func__);
- return -1;
- }
- if (btf__get_from_id(info.btf_id, )) {
- pr_debug("%s: failed to get BTF of id %u, aborting\n",
__func__, info.btf_id);
- return -1;
+ err = -1;
+ goto out;
}
- func_info_rec_size = info.func_info_rec_size;
- func_infos = calloc(sub_prog_cnt, func_info_rec_size);
- if (!func_infos) {
- pr_debug("%s: failed to allocate memory for func_infos,
aborting\n", __func__);
- return -1;
+ if (btf__get_from_id(info->btf_id, )) {
+ pr_debug("%s: failed to get BTF of id %u, aborting\n",
__func__, info->btf_id);
+ err = -1;
+ btf = NULL;
+ goto out;
}
has_btf = true;
}
- /*
-* We need address, length, and tag for each sub program.
-* Allocate memory and call bpf_obj_get_info_by_fd() again
-*/
- prog_addrs = calloc(sub_prog_cnt, sizeof(u64));
- if (!prog_addrs) {
- pr_debug("%s: failed to allocate memory for prog_addrs,
aborting\n", __func__);
- goto out;
- }
- prog_lens = calloc(sub_prog_cnt, sizeof(u32));
- if (!prog_lens) {
- pr_debug("%s: failed to allocate memory for prog_lens,
aborting\n", __func__);
- goto out;
- }
- prog_tags = calloc(sub_prog_cnt, BPF_TAG_SIZE);
- if (!prog_tags) {
-
[PATCH v6 perf,bpf 00/15] perf annotation of BPF programs
Changes v5 to v6:
1. Improve side band evlist interface;
2. Minor style fixes.
Changes v4 to v5:
1. Rebase to latest bpf-next;
2. Add dependency of 94816add0005 from Arnaldo's tree;
3. More details in change logs;
4. Add perf_env__init() to init bpf related lock and rbtrees;
5. Small clean ups.
Changes v3 to v4:
1. Incorporate feedbacks from Jiri and Namhyung;
2. Fixed compilation error with different feature-disassembler-four-args;
3. Split some patches to smaller patches;
4. Improved error handleing in symbol__disassemble_bpf();
5. Made side band thread more generic;
6. Added comments as suggested.
Changes v2 to v3:
1. Remove unnecessary include in header files;
2. Improved error handling;
3. Better naming of functions, variables, etc.;
4. Enable bpf events by default for perf-top.
Changes v1 to v2:
1. Fix compilation error with different feature-disassembler-four-args;
2. Fix a segfault in perf-record;
3. Split patches 5/9 and 6/9 so that perf_env changes and perf.data changes
are in separate patches.
This series enables annotation of BPF programs in perf.
perf tool gathers information via sys_bpf and (optionally) stores them in
perf.data as headers.
Patch 1/15 fixes a minor issue in kernel;
Patch 2/15 to 4/15 introduce new helper functions and use them in perf and
bpftool;
Patch 5/15 to 9/15 saves information of bpf program in perf_env;
Patch 10/15 adds --bpf-event options to perf-top;
Patch 11/15 to 13/15 enables annotation of bpf progs based on information
gathered in 5/15 to 9/15;
Patch 14/15 introduces side band polling thread that gathers information
for special kernel events during perf-record or perf-top.
Patch 15/15 handles information of short living BPF program using the new
side band polling thread.
Commands tested during developments are perf-top, perf-record, perf-report,
and perf-annotate.
= Note on patch dependency
This set has dependency in both bpf-next tree and tip/perf/core. Current
version is developed on bpf-next tree with the following commits
cherry-picked from tip/perf/core (or acme/perf/core):
(from 1/11 to 11/11)
commit 76193a94522f ("perf, bpf: Introduce PERF_RECORD_KSYMBOL")
commit d764ac646491 ("tools headers uapi: Sync
tools/include/uapi/linux/perf_event.h")
commit 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT")
commit df063c83aa2c ("tools headers uapi: Sync
tools/include/uapi/linux/perf_event.h")
commit 9aa0bfa370b2 ("perf tools: Handle PERF_RECORD_KSYMBOL")
commit 45178a928a4b ("perf tools: Handle PERF_RECORD_BPF_EVENT")
commit 7b612e291a5a ("perf tools: Synthesize PERF_RECORD_* for loaded BPF
programs")
commit a40b95bcd30c ("perf top: Synthesize BPF events for pre-existing loaded
BPF programs")
commit 6934058d9fb6 ("bpf: Add module name [bpf] to ksymbols for bpf programs")
commit 811184fb6977 ("perf bpf: Fix synthesized PERF_RECORD_KSYMBOL/BPF_EVENT")
comimt 94816add0005 ("perf tools: Add perf_exe() helper to find perf binary")
This set is also available at:
https://github.com/liu-song-6/linux/tree/bpf-annotation
Thanks!!
Song Liu (15):
perf, bpf: consider events with attr.bpf_event as side-band events
bpf: libbpf: introduce bpf_program__get_prog_info_linear()
bpf: bpftool: use bpf_program__get_prog_info_linear() in
prog.c:do_dump()
perf, bpf: synthesize bpf events with
bpf_program__get_prog_info_linear()
perf: change prototype of perf_event__synthesize_bpf_events()
perf, bpf: save bpf_prog_info in a rbtree in perf_env
perf, bpf: save bpf_prog_info information as headers to perf.data
perf, bpf: save btf in a rbtree in perf_env
perf, bpf: save btf information as headers to perf.data
perf-top: add option --no-bpf-event
perf: add -lopcodes to feature-libbfd
perf, bpf: enable annotation of bpf program
perf, bpf: process PERF_BPF_EVENT_PROG_LOAD for annotation
perf: introduce side band thread
perf, bpf: save bpf_prog_info and btf of short living bpf programs
kernel/events/core.c | 3 +-
tools/bpf/bpftool/prog.c | 266 +++-
tools/build/Makefile.feature | 6 +-
tools/lib/bpf/libbpf.c | 251 ++
tools/lib/bpf/libbpf.h | 63 +++
tools/lib/bpf/libbpf.map | 3 +
tools/perf/Makefile.config | 6 +-
tools/perf/builtin-record.c | 9 +-
tools/perf/builtin-top.c | 12 +-
tools/perf/perf.c| 1 +
tools/perf/util/annotate.c | 150 +++-
tools/perf/util/bpf-event.c | 329 ++-
tools/perf/util/bpf-event.h | 33 +++-
tools/perf/util/dso.c| 1 +
tools/perf/util/dso.h| 33 ++--
tools/perf/util/env.c| 149
tools/perf/util/env.h| 22 +++
tools/perf/util/evlist.c | 113
tools/perf/util/evlist.h | 13 ++
tools/perf/util/evsel.h | 6 +
[PATCH v6 perf,bpf 01/15] perf, bpf: consider events with attr.bpf_event as side-band events
Events with bpf_event should be considered as side-band event, as they
carry information about BPF programs.
Fixes: 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT")
Signed-off-by: Song Liu
---
kernel/events/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f1a26c8f15b3..4a59cb9b29ee 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4238,7 +4238,8 @@ static bool is_sb_event(struct perf_event *event)
if (attr->mmap || attr->mmap_data || attr->mmap2 ||
attr->comm || attr->comm_exec ||
attr->task || attr->ksymbol ||
- attr->context_switch)
+ attr->context_switch ||
+ attr->bpf_event)
return true;
return false;
}
--
2.17.1
Re: [GIT PULL] RCU updates for v5.1
* Linus Torvalds wrote: > On Tue, Mar 5, 2019 at 4:03 AM Ingo Molnar wrote: > > > > Please pull the latest core-rcu-for-linus git tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > core-rcu-for-linus > > Hmm. I think this made my build time explode. > > I'm bisecting, but it looks like my allmodconfig builds went from ~31 > min to ~39 min with this pull. > > NOTE! I'm not saying that the kernel slowed down. Just the *build* > (with the same kernel) slowed down. > > It's odd, and maybe I did something wrong, so I'll have to > double-check the numbers, but I thought I'd mention it in case > somebody goes "Ahh, I did X to the include files, so now every > compiler invocation probably sees all of xyz and that will slow things > down enormously". Could it be the locking tree? In particular the atomics auto-generation slowed down the build before, but this build regression was thought to be fixed with: 0cf264b3133d: locking/atomics: Check atomic headers with sha1sum but maybe that's not the whole story? Or it's an unreported slowdown related to the RCU tree, as you say. Thanks, Ingo
[PATCH RESEND] eventfd: prepare id to userspace via fdinfo
Finding endpoints of an IPC channel is one of essential task to understand how a user program works. Procfs and netlink socket provide enough hints to find endpoints for IPC channels like pipes, unix sockets, and pseudo terminals. However, there is no simple way to find endpoints for an eventfd file from userland. An inode number doesn't hint. Unlike pipe, all eventfd files share the same inode object. To provide the way to find endpoints of an eventfd file, this patch adds "eventfd-id" field to fdinfo of eventfd as identifier. Address for eventfd context is used as id. Typical applicaiton utilizing the information is lsof. Signed-off-by: Masatake YAMATO --- fs/eventfd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/eventfd.c b/fs/eventfd.c index 08d3bd602f73..fc63ad43d962 100644 --- a/fs/eventfd.c +++ b/fs/eventfd.c @@ -297,6 +297,7 @@ static void eventfd_show_fdinfo(struct seq_file *m, struct file *f) seq_printf(m, "eventfd-count: %16llx\n", (unsigned long long)ctx->count); spin_unlock_irq(>wqh.lock); + seq_printf(m, "eventfd-id: %p\n", ctx); } #endif -- 2.17.2
Re: [PATCH v5 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC
Hi Chanwoo,
On 3/6/19 2:31 AM, Chanwoo Choi wrote:
> Hi Lukasz,
>
> I'm talking about it repeatedly. How many times already, I mentioned
> that you have to resend the patch after completed the discussion.
>
>
> I replied this v3 patch[2]. But, you didn't reply or answer anything
> and then just send the same patch without any consent.
>
> - Re: [PATCH v3 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC
> [2] https://lkml.org/lkml/2019/2/11/198
The second table from the example is not compiled and never be.
The rates where tested and they work. As I said the BPLL is used only
for DMC, thus it can be used instead of the default
exynos5420_pll2550x_24mhz_tbl.
It is worth to keep it as a separate table because adding
these entries to generic PLL table might cause issues for other PLLs.
Regards,
Lukasz
>
>
>
> On 19. 3. 5. 오후 7:19, Lukasz Luba wrote:
>> Add new table rate for BPLL for Exynos5422 SoC supporting Dynamic Memory
>> Controller frequencies for driver's DRAM timings.
>>
>> Signed-off-by: Lukasz Luba
>> ---
>> drivers/clk/samsung/clk-exynos5420.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 6da5875..6f5db70 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -1331,6 +1331,17 @@ static const struct samsung_pll_rate_table
>> exynos5420_pll2550x_24mhz_tbl[] __ini
>> PLL_35XX_RATE(24 * MHZ, 2, 200, 3, 3),
>> };
>>
>> +static const struct samsung_pll_rate_table exynos5422_bpll_rate_table[] = {
>> +PLL_35XX_RATE(24 * MHZ, 82500, 275, 4, 1),
>> +PLL_35XX_RATE(24 * MHZ, 72800, 182, 3, 1),
>> +PLL_35XX_RATE(24 * MHZ, 63300, 211, 4, 1),
>> +PLL_35XX_RATE(24 * MHZ, 54300, 181, 2, 2),
>> +PLL_35XX_RATE(24 * MHZ, 41300, 413, 6, 2),
>> +PLL_35XX_RATE(24 * MHZ, 27500, 275, 3, 3),
>> +PLL_35XX_RATE(24 * MHZ, 20600, 206, 3, 3),
>> +PLL_35XX_RATE(24 * MHZ, 16500, 110, 2, 3),
>> +};
>> +
>> static const struct samsung_pll_rate_table exynos5420_epll_24mhz_tbl[] = {
>> PLL_36XX_RATE(24 * MHZ, 6U, 100, 2, 1, 0),
>> PLL_36XX_RATE(24 * MHZ, 4U, 200, 3, 2, 0),
>> @@ -1473,7 +1484,7 @@ static void __init exynos5x_clk_init(struct
>> device_node *np,
>> exynos5x_plls[apll].rate_table = exynos5420_pll2550x_24mhz_tbl;
>> exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
>> exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
>> -exynos5x_plls[bpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
>> +exynos5x_plls[bpll].rate_table = exynos5422_bpll_rate_table;
>> }
>>
>> samsung_clk_register_pll(ctx, exynos5x_plls, ARRAY_SIZE(exynos5x_plls),
>>
>
>
Re: [PATCH 4/4] iommu/vt-d: Remove lazy allocation of domains
Hi,
On 3/5/19 7:46 PM, James Sewart wrote:
Hey Lu,
On 5 Mar 2019, at 06:59, Lu Baolu wrote:
Hi,
It's hard for me to understand why do we remove the rmrr related
code in this patch.
The RMRR code removed here requires the lazy allocation of domains to
exist, as it is run before iommu.c would assign IOMMU groups and attach a
domain. Before patch 3, removing this code would mean the RMRR regions are
never mapped for a domain: iommu.c will allocate a default domain for the
group that a device is about to be put in, it will attach the domain to
the device, then for each region returned by get_resv_regions it will
create an identity map, this is where the RMRRs are setup for the default
domain. >
And, now we have two places to hold a domain for a device: group and
dev->info. We can consider to optimize the use of per device iommu
arch data. This should be later work anyway.
More comments inline.
On 3/4/19 11:47 PM, James Sewart wrote:
The generic IOMMU code will allocate and attach a dma ops domain to each
device that comes online, replacing any lazy allocated domain. Removes
RMRR application at iommu init time as we won't have a domain attached
to any device. iommu.c will do this after attaching a device using
create_direct_mappings.
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 202 ++--
1 file changed, 8 insertions(+), 194 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 71cd6bbfec05..282257e2628d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2595,118 +2595,6 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
return domain;
}
-static int get_last_alias(struct pci_dev *pdev, u16 alias, void *opaque)
-{
- *(u16 *)opaque = alias;
- return 0;
-}
-
-static struct dmar_domain *find_or_alloc_domain(struct device *dev, int gaw)
-{
- struct device_domain_info *info = NULL;
- struct dmar_domain *domain = NULL;
- struct intel_iommu *iommu;
- u16 dma_alias;
- unsigned long flags;
- u8 bus, devfn;
-
- iommu = device_to_iommu(dev, , );
- if (!iommu)
- return NULL;
-
- if (dev_is_pci(dev)) {
- struct pci_dev *pdev = to_pci_dev(dev);
-
- pci_for_each_dma_alias(pdev, get_last_alias, _alias);
-
- spin_lock_irqsave(_domain_lock, flags);
- info = dmar_search_domain_by_dev_info(pci_domain_nr(pdev->bus),
- PCI_BUS_NUM(dma_alias),
- dma_alias & 0xff);
- if (info) {
- iommu = info->iommu;
- domain = info->domain;
- }
- spin_unlock_irqrestore(_domain_lock, flags);
-
- /* DMA alias already has a domain, use it */
- if (info)
- goto out;
- }
-
- /* Allocate and initialize new domain for the device */
- domain = alloc_domain(0);
- if (!domain)
- return NULL;
- if (domain_init(domain, iommu, gaw)) {
- domain_exit(domain);
- return NULL;
- }
-
-out:
-
- return domain;
-}
-
-static struct dmar_domain *set_domain_for_dev(struct device *dev,
- struct dmar_domain *domain)
-{
- struct intel_iommu *iommu;
- struct dmar_domain *tmp;
- u16 req_id, dma_alias;
- u8 bus, devfn;
-
- iommu = device_to_iommu(dev, , );
- if (!iommu)
- return NULL;
-
- req_id = ((u16)bus << 8) | devfn;
-
- if (dev_is_pci(dev)) {
- struct pci_dev *pdev = to_pci_dev(dev);
-
- pci_for_each_dma_alias(pdev, get_last_alias, _alias);
-
- /* register PCI DMA alias device */
- if (req_id != dma_alias) {
- tmp = dmar_insert_one_dev_info(iommu,
PCI_BUS_NUM(dma_alias),
- dma_alias & 0xff, NULL, domain);
-
- if (!tmp || tmp != domain)
- return tmp;
- }
- }
-
- tmp = dmar_insert_one_dev_info(iommu, bus, devfn, dev, domain);
- if (!tmp || tmp != domain)
- return tmp;
-
- return domain;
-}
-
-static struct dmar_domain *get_domain_for_dev(struct device *dev, int gaw)
-{
- struct dmar_domain *domain, *tmp;
-
- domain = find_domain(dev);
- if (domain)
- goto out;
-
- domain = find_or_alloc_domain(dev, gaw);
- if (!domain)
- goto out;
-
- tmp = set_domain_for_dev(dev, domain);
- if (!tmp || domain != tmp) {
- domain_exit(domain);
- domain = tmp;
- }
-
-out:
-
- return domain;
-}
-
static int iommu_domain_identity_map(struct
Re: [PATCH v2] scripts: checkpatch: Check multiple blank lines when deleting code
On 3/5/19 6:17 PM, Joe Perches wrote:
On Tue, 2019-03-05 at 02:12 -0500, Alexandre Ghiti wrote:
By matching only current line starting with '+', we miss the case
when deleting code makes consecutive blank lines appear: this patch
then makes it possible to detect this case by also matching current
line starting with ' ', which is an already existing blank line.
[]
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
@@ -2081,10 +2081,15 @@ sub fix_inserted_deleted_lines {
}
while (defined($inserted) && ${$inserted}{'LINENR'} == $old_linenr) {
+ my $len = 1;
push(@lines, ${$inserted}{'LINE'});
+ # Do not increment the length when inserting a deletion
line.
+ if (${$inserted}{'LINE'} =~ /^\-/) {
+ $len = 0;
+ }
$inserted = @{$insertedRef}[$next_insert++];
$new_linenr++;
- fixup_current_range(\$lines[$range_last_linenr],
$delta_offset++, 1);
+ fixup_current_range(\$lines[$range_last_linenr],
$delta_offset++, $len);
I think this is confusing and unnecessary.
Using --fix can not delete context lines from a patch.
Ok, I was expecting your comment on that, I agree with you.
So I'll get rid of the possibility to fix the deletion case, this will
only be a warning.
}
if ($save_line) {
@@ -3298,12 +3303,18 @@ sub process {
# check for multiple consecutive blank lines
if ($prevline =~ /^[\+ ]\s*$/ &&
- $line =~ /^\+\s*$/ &&
+ $line =~ /^[\+ ]\s*$/ &&
$last_blank_line != ($linenr - 1)) {
if (CHK("LINE_SPACING",
"Please don't use multiple blank lines\n" . $hereprev)
&&
$fix) {
It's simpler to add a check that $line starts /^\+/ before $fix
Maybe it'd be better to have a separate test for this to make
the output message clearer too.
Something like
"Avoid deleting lines that create consecutive blank lines"
Ok,
Thanks for your comments,
fix_delete_line($fixlinenr, $rawline);
+ if ($line =~ /^ \s*$/) {
+ # If the line is not an inserted blank
line, the multiple
+ # consecutive blank lines are caused by
deletion: fix this
+ # by replacing the blank line with a
deletion line.
+ fix_insert_line($fixlinenr, "\-");
+ }
}
$last_blank_line = $linenr;
Re: [PATCH v11] f2fs: guarantee journalled quota data by checkpoint
Hi Jaegeuk,
On 2018/9/20 20:05, Chao Yu wrote:
> @@ -3456,3 +3477,16 @@
>
> extern void f2fs_build_fault_attr(struct f2fs_sb_info *sbi, unsigned int
> rate,
>
> #endif
> #endif
> +
> +static inline bool is_journalled_quota(struct f2fs_sb_info *sbi)
> +{
> +#ifdef CONFIG_QUOTA
> + if (f2fs_sb_has_quota_ino(sbi->sb))
> + return true;
> + if (F2FS_OPTION(sbi).s_qf_names[USRQUOTA] ||
> + F2FS_OPTION(sbi).s_qf_names[GRPQUOTA] ||
> + F2FS_OPTION(sbi).s_qf_names[PRJQUOTA])
> + return true;
> +#endif
> + return false;
> +}
I checked dev branch, and found one patch we didn't send to mailing list,
could you please send it out?
f2fs: fix wrong #endif
I think my quota patch caused this 'wrong #endif' issue, could you add
single line comment to notice which #if the last #endif is corresponding
to? so that we can avoid same mistake as quota patch made.
Thanks,
linux-next: Signed-off-by missing for commit in the nds32 tree
Hi Greentime,
Commit
90ef626b651d ("nds32: fix semicolon code style issue")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgphQsoImRxXC.pgp
Description: OpenPGP digital signature
linux-next: Tree for Mar 6
Hi all, Please do not add any code destined for v5.2 to your linux-next included branches until after v5.1-rc1 has been released. News: I will not be doing linux-next releases from next Thursday (Mar 7) to the following Friday (Mar 15). Sorry this happened to fall across most of the merge window. Changes since 20190305: The dma-mapping tree gained a conflict against Linus' tree. The tip tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 8126 8141 files changed, 348941 insertions(+), 168077 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 297 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (d9862cfbe209 Merge tag 'mips_5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux) Merging fixes/master (2648624cfe7f adfs: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (1f7ae812f87e x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (207a369e3c08 sh: fix build error for invisible CONFIG_BUILTIN_DTB_SOURCE) Merging arc-current/for-curr (6dd356d8fc06 ARC: unaligned: relax the check for gcc supporting -mno-unaligned-access) Merging arm-current/fixes (d410a8a49e3e ARM: 8849/1: NOMMU: Fix encodings for PMSAv8's PRBAR4/PRLAR4) Merging arm64-fixes/for-next/fixes (74698f6971f2 arm64: Relax GIC version check during early boot) Merging m68k-current/for-linus (28713169d879 m68k: Add -ffreestanding to CFLAGS) Merging powerpc-fixes/fixes (8f5b27347e88 powerpc/powernv/sriov: Register IOMMU groups for VFs) Merging sparc/master (7d762d69145a afs: Fix manually set volume location server list) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (0e63208915a8 tipc: fix RDM/DGRAM connect() regression) Merging bpf/master (822e44b45eb9 qmi_wwan: Add support for Quectel EG12/EM12) Merging ipsec/master (b805d78d300b xfrm: policy: Fix out-of-bound array accesses in __xfrm_policy_unlink) Merging netfilter/master (822e44b45eb9 qmi_wwan: Add support for Quectel EG12/EM12) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (d5fa9c55e5f3 Merge tag 'mlx5-updates-2019-03-01' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux) Merging mac80211/master (d235c48b40d3 net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390X) Merging rdma-fixes/for-rc (f09ef134a7ca iw_cxgb4: cq/qp mask depends on bar2 pages in a host page) Merging sound-current/for-linus (a634090a0f24 ALSA: usb-audio: Add quirk for MOTU MicroBook II) Merging sound-asoc-fixes/for-linus (b4c5079b6613 Merge branch 'asoc-5.0' into asoc-linus) CONFLICT (content): Merge conflict in sound/soc/codecs/tlv320aic3x.c Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (078d354f8d7f Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (410fc2aa4a53 Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f57a98e1b713 PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX)) Merging driver-core.current/driver-core-linus (d13937116f1e Linux 5.0-rc6) Merging tty.current/tty-linus (d13937116f1e Li
Re: [f2fs-dev] [PATCH v2] f2fs: fix to check inline_xattr_size boundary correctly
Ping, On 2019/3/4 14:39, Chao Yu wrote: > Hi Jaegeuk, > > On 2019/2/15 0:08, Chao Yu wrote: >> --- >> v2: >> - fix lower bound check, inline xattr size should be larger than >> xattr_header's size at least. > > ... > >> +if (F2FS_OPTION(sbi).inline_xattr_size < >> +sizeof(struct f2fs_xattr_header) / sizeof(__le32) > > No sure we should set this low bound as above... now I guess original > non-zero check is enough. > > How do you think of setting inline_xattr_size range as > (0, MAX_INLINE_XATTR_SIZE]? > > Thanks, > > > > ___ > Linux-f2fs-devel mailing list > linux-f2fs-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > >
Re: [PATCH 0/4] iommu/vt-d: Fix-up device-domain relationship by refactoring to use iommu group default domain.
Hi, On 3/5/19 7:14 PM, James Sewart wrote: Hey Lu, The motivation for this is buggy domain <-> IOMMU group relationship when using find_or_alloc_domain. From what I have read it should be the case that an IOMMU domain is shared by all devices in the same group, thus the same mappings. This is because the IOMMU group is determined by things like ACS settings on pci switches which determines whether devices can talk to each other. Yes, exactly. This is a known issue. In find_or_alloc_domain we only determine domain sharing based on devices returned by pci_for_each_dma_alias, whereas there are many more checks in pci_device_group(e.g. ACS settings of intermediary pci switches), which is used for determining which IOMMU group a device is in. This discontinuity means it can be the case that each device within an IOMMU group will have different domains. Yes. Agree again. We see issues as it is supposed to be safe to assume that devices within a group should be considered to be in the same address space, but if each device has its own domain then any mapping created won’t be valid for the other devices, and even could be mapped differently for each device. This also could cause issues with a device whose RMRR's are not applied to the domains of other devices within its group, these regions could be remapped for the other devices resulting in unexpected behaviour during peer-to-peer transfers. Yes, fair enough. I asked this question because I am interested to know whether multiple domains per group due to lack of ACS consideration will cause any issues that we need to fix in the stable kernels. Best regards, Lu Baolu Cheers, James On 5 Mar 2019, at 06:05, Lu Baolu wrote: Hi James, Very glad to see this. Thank you! On 3/4/19 11:41 PM, James Sewart wrote: Hey, This patchset moves IOMMU_DOMAIN_DMA iommu domain management to iommu.c. This avoids the use of find_or_alloc_domain whose domain assignment is inconsistent with the iommu grouping as determined by pci_device_group. Is this a bug fix or an improvement? What's the real issue will it cause if we go without this patch set? Best regards, Lu Baolu Patch 3 permits domain type IOMMU_DOMAIN_DMA to be allocated via the iommu_ops api, allowing the default_domain of an iommu group to be set in iommu.c. This domain will be attached to every device that is brought up with an iommu group, and the devices reserved regions will be mapped using regions returned by get_resv_regions. In intel_iommu_domain_alloc we don’t know the IOMMU this domain will be associated with so we defer full initialisation until intel_iommu_attach_device. Currently iommu.c:iommu_group_add_device will try to map a devices reserved regions before attaching the domain which would cause issue if the domain is not fully initialised. This is addressed in patch 1 by moving the mapping to after attaching. Patch 2 implements function apply_resv_region, used in iommu_group_create_direct_mappings to mark the reserved regions as non mappable for the dma_map_ops api. Patch 4 removes the domain lazy allocation logic. Before this patch the lazy allocation logic would not be used as any domain allocated using these paths would be replaced when attaching the group default domain. Default domain allocation has been tested with and without this patch on 4.19. Cheers, James. James Sewart (4): iommu: Move iommu_group_create_direct_mappings to after device_attach iommu/vt-d: Implement apply_resv_region for reserving IOVA ranges iommu/vt-d: Allow IOMMU_DOMAIN_DMA and IOMMU_DOMAIN_IDENTITY to be allocated iommu/vt-d: Remove lazy allocation of domains drivers/iommu/intel-iommu.c | 329 drivers/iommu/iommu.c | 4 +- 2 files changed, 108 insertions(+), 225 deletions(-)
Re: [PATCH 1/2] f2fs: fix to add refcount once page is tagged PG_private
On 2019/3/6 11:46, Jaegeuk Kim wrote:
> On 03/05, Chao Yu wrote:
>> As Gao Xiang reported in bugzilla:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=202749
>>
>> f2fs may skip pageout() due to incorrect page reference count.
>>
>> The problem here is that MM defined the rule [1] very clearly that
>> once page was set with PG_private flag, we should increment the
>> refcount in that page, also main flows like pageout(), migrate_page()
>> will assume there is one additional page reference count if
>> page_has_private() returns true.
>>
>> But currently, f2fs won't add/del refcount when changing PG_private
>> flag. Anyway, f2fs should follow MM's rule to make MM's related flows
>> running as expected.
>>
>> [1]
>> https://lore.kernel.org/lkml/2b19b3c4-2bc4-15fa-15cc-27a13e5c7...@aol.com/
>>
>> Reported-by: Gao Xiang
>> Signed-off-by: Chao Yu
>> ---
>> fs/f2fs/checkpoint.c | 11 +--
>> fs/f2fs/data.c | 32
>> fs/f2fs/dir.c| 6 +-
>> fs/f2fs/node.c | 6 +-
>> fs/f2fs/segment.c| 23 +--
>> 5 files changed, 56 insertions(+), 22 deletions(-)
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index c65a1e8e1e95..4e0e93af5ce0 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -406,7 +406,11 @@ static int f2fs_set_meta_page_dirty(struct page *page)
>> if (!PageDirty(page)) {
>> __set_page_dirty_nobuffers(page);
>> inc_page_count(F2FS_P_SB(page), F2FS_DIRTY_META);
>> -SetPagePrivate(page);
>> +
>> +if (!PagePrivate(page)) {
>> +get_page(page);
>> +SetPagePrivate(page);
>
> Can we add generic functions?
>
> f2fs_set_page_private(page)
> {
> if (PagePrivate(page))
> return;
>
> SetPagePrivate(page);
> get_page(page);
> }
>
> f2fs_clear_page_private(page)
> {
> if (!PagePrivate(page))
> return;
>
> set_page_private(page, 0);
> ClearPagePrivate(page);
> f2fs_put_page(page, 0);
> }
Done. :)
Thanks,
>
>>
>> +}
>> f2fs_trace_pid(page);
>> return 1;
>> }
>> @@ -957,7 +961,10 @@ void f2fs_update_dirty_page(struct inode *inode, struct
>> page *page)
>> inode_inc_dirty_pages(inode);
>> spin_unlock(>inode_lock[type]);
>>
>> -SetPagePrivate(page);
>> +if (!PagePrivate(page)) {
>> +get_page(page);
>> +SetPagePrivate(page);
>> +}
>> f2fs_trace_pid(page);
>> }
>>
>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>> index 3f3becd46362..46924d4f69d0 100644
>> --- a/fs/f2fs/data.c
>> +++ b/fs/f2fs/data.c
>> @@ -2715,8 +2715,11 @@ void f2fs_invalidate_page(struct page *page, unsigned
>> int offset,
>> if (IS_ATOMIC_WRITTEN_PAGE(page))
>> return f2fs_drop_inmem_page(inode, page);
>>
>> -set_page_private(page, 0);
>> -ClearPagePrivate(page);
>> +if (PagePrivate(page)) {
>> +set_page_private(page, 0);
>> +ClearPagePrivate(page);
>> +f2fs_put_page(page, 0);
>> +}
>> }
>>
>> int f2fs_release_page(struct page *page, gfp_t wait)
>> @@ -2730,8 +2733,11 @@ int f2fs_release_page(struct page *page, gfp_t wait)
>> return 0;
>>
>> clear_cold_data(page);
>> -set_page_private(page, 0);
>> -ClearPagePrivate(page);
>> +if (PagePrivate(page)) {
>> +set_page_private(page, 0);
>> +ClearPagePrivate(page);
>> +f2fs_put_page(page, 0);
>> +}
>> return 1;
>> }
>>
>> @@ -2799,12 +2805,8 @@ int f2fs_migrate_page(struct address_space *mapping,
>> return -EAGAIN;
>> }
>>
>> -/*
>> - * A reference is expected if PagePrivate set when move mapping,
>> - * however F2FS breaks this for maintaining dirty page counts when
>> - * truncating pages. So here adjusting the 'extra_count' make it work.
>> - */
>> -extra_count = (atomic_written ? 1 : 0) - page_has_private(page);
>> +/* one extra reference was held for atomic_write page */
>> +extra_count = atomic_written ? 1 : 0;
>> rc = migrate_page_move_mapping(mapping, newpage,
>> page, mode, extra_count);
>> if (rc != MIGRATEPAGE_SUCCESS) {
>> @@ -2825,9 +2827,15 @@ int f2fs_migrate_page(struct address_space *mapping,
>> get_page(newpage);
>> }
>>
>> -if (PagePrivate(page))
>> +if (PagePrivate(page)) {
>> +get_page(newpage);
>> SetPagePrivate(newpage);
>> -set_page_private(newpage, page_private(page));
>> +set_page_private(newpage, page_private(page));
>> +
>> +set_page_private(page, 0);
>> +ClearPagePrivate(page);
>> +f2fs_put_page(page, 0);
>> +}
>>
>> if (mode != MIGRATE_SYNC_NO_COPY)
>> migrate_page_copy(newpage, page);
>> diff --git
[PATCH V2 4/8] spi: lpspi: add the error info of transfer speed setting
Add a error info when set a speed which greater than half of per-clk of
spi module.
The minimum SCK period is 2 cycles(CCR[SCKDIV]). So the maximum transfer
speed is half of spi per-clk.
Signed-off-by: Clark Wang
---
V2:
- No change. Resend for applying.
---
drivers/spi/spi-fsl-lpspi.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 84dcb9e176b8..69635cde0e22 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -255,6 +255,13 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data
*fsl_lpspi)
u8 prescale;
perclk_rate = clk_get_rate(fsl_lpspi->clk_per);
+
+ if (config.speed_hz > perclk_rate / 2) {
+ dev_err(fsl_lpspi->dev,
+ "per-clk should be at least two times of transfer speed");
+ return -EINVAL;
+ }
+
for (prescale = 0; prescale < 8; prescale++) {
scldiv = perclk_rate /
(clkdivs[prescale] * config.speed_hz) - 2;
@@ -304,7 +311,7 @@ static int fsl_lpspi_config(struct fsl_lpspi_data
*fsl_lpspi)
return 0;
}
-static void fsl_lpspi_setup_transfer(struct spi_device *spi,
+static int fsl_lpspi_setup_transfer(struct spi_device *spi,
struct spi_transfer *t)
{
struct fsl_lpspi_data *fsl_lpspi =
@@ -337,7 +344,7 @@ static void fsl_lpspi_setup_transfer(struct spi_device *spi,
else
fsl_lpspi->watermark = fsl_lpspi->txfifosize;
- fsl_lpspi_config(fsl_lpspi);
+ return fsl_lpspi_config(fsl_lpspi);
}
static int fsl_lpspi_slave_abort(struct spi_controller *controller)
@@ -429,7 +436,10 @@ static int fsl_lpspi_transfer_one_msg(struct
spi_controller *controller,
msg->actual_length = 0;
list_for_each_entry(xfer, >transfers, transfer_list) {
- fsl_lpspi_setup_transfer(spi, xfer);
+ ret = fsl_lpspi_setup_transfer(spi, xfer);
+ if (ret < 0)
+ goto complete;
+
fsl_lpspi_set_cmd(fsl_lpspi, is_first_xfer);
is_first_xfer = false;
--
2.17.1
[PATCH V2 2/8] doc: lpspi: Document DT bindings for LPSPI clocks
Add introductions of clocks and clock-names strings.
Signed-off-by: Clark Wang
---
V2:
- Add this DT-bindings string in this version.
---
.../devicetree/bindings/spi/spi-fsl-lpspi.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
index 6cc3c6fe25a3..e71b81a41ac0 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
@@ -7,7 +7,11 @@ Required properties:
- reg : address and length of the lpspi master registers
- interrupt-parent : core interrupt controller
- interrupts : lpspi interrupt
-- clocks : lpspi clock specifier
+- clocks : lpspi clock specifier. Its number and order need to correspond to
the
+ value in clock-names.
+- clock-names : Corresponding to per clock and ipg clock in "clocks"
+ respectively. In i.MX7ULP, it only has per clk, so use CLK_DUMMY
+ to fill the "ipg" blank.
- spi-slave : spi slave mode support. In slave mode, add this attribute without
value. In master mode, remove it.
@@ -18,6 +22,8 @@ lpspi2: lpspi@4029 {
reg = <0x4029 0x1>;
interrupt-parent = <>;
interrupts = ;
- clocks = < IMX7ULP_CLK_LPSPI2>;
+ clocks = < IMX7ULP_CLK_LPSPI2>,
+< IMX7ULP_CLK_DUMMY>;
+ clock-names = "per", "ipg";
spi-slave;
};
--
2.17.1
[PATCH V2 3/8] spi: lpspi: enable runtime pm for lpspi
From: Han Xu
Enable the runtime power management for lpspi module.
Do some adaptation work from kernel 4.9 to 4.14.
Signed-off-by: Clark Wang
Signed-off-by: Han Xu
Reviewed-by: Frank Li
---
V2:
- Fix the comment format.
---
drivers/spi/spi-fsl-lpspi.c | 117
1 file changed, 92 insertions(+), 25 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index f363c000d24a..84dcb9e176b8 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -16,7 +16,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -24,6 +26,8 @@
#define DRIVER_NAME "fsl_lpspi"
+#define FSL_LPSPI_RPM_TIMEOUT 50 /* 50ms */
+
/* i.MX7ULP LPSPI registers */
#define IMX7ULP_VERID 0x0
#define IMX7ULP_PARAM 0x4
@@ -154,13 +158,9 @@ static int lpspi_prepare_xfer_hardware(struct
spi_controller *controller)
spi_controller_get_devdata(controller);
int ret;
- ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
- if (ret)
- return ret;
-
- ret = clk_prepare_enable(fsl_lpspi->clk_per);
- if (ret) {
- clk_disable_unprepare(fsl_lpspi->clk_ipg);
+ ret = pm_runtime_get_sync(fsl_lpspi->dev);
+ if (ret < 0) {
+ dev_err(fsl_lpspi->dev, "failed to enable clock\n");
return ret;
}
@@ -172,8 +172,8 @@ static int lpspi_unprepare_xfer_hardware(struct
spi_controller *controller)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
- clk_disable_unprepare(fsl_lpspi->clk_ipg);
- clk_disable_unprepare(fsl_lpspi->clk_per);
+ pm_runtime_mark_last_busy(fsl_lpspi->dev);
+ pm_runtime_put_autosuspend(fsl_lpspi->dev);
return 0;
}
@@ -480,6 +480,45 @@ static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
return IRQ_NONE;
}
+int fsl_lpspi_runtime_resume(struct device *dev)
+{
+ struct fsl_lpspi_data *fsl_lpspi = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_per);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+ if (ret) {
+ clk_disable_unprepare(fsl_lpspi->clk_per);
+ return ret;
+ }
+
+ return 0;
+}
+
+int fsl_lpspi_runtime_suspend(struct device *dev)
+{
+ struct fsl_lpspi_data *fsl_lpspi = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(fsl_lpspi->clk_per);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
+
+ return 0;
+}
+
+static int fsl_lpspi_init_rpm(struct fsl_lpspi_data *fsl_lpspi)
+{
+ struct device *dev = fsl_lpspi->dev;
+
+ pm_runtime_enable(dev);
+ pm_runtime_set_autosuspend_delay(dev, FSL_LPSPI_RPM_TIMEOUT);
+ pm_runtime_use_autosuspend(dev);
+
+ return 0;
+}
+
static int fsl_lpspi_probe(struct platform_device *pdev)
{
struct fsl_lpspi_data *fsl_lpspi;
@@ -505,6 +544,7 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi = spi_controller_get_devdata(controller);
fsl_lpspi->dev = >dev;
+ dev_set_drvdata(>dev, fsl_lpspi);
fsl_lpspi->is_slave = of_property_read_bool((>dev)->of_node,
"spi-slave");
@@ -551,28 +591,21 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
goto out_controller_put;
}
- ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
- if (ret) {
- dev_err(>dev,
- "can't enable lpspi ipg clock, ret=%d\n", ret);
+ /* enable the clock */
+ ret = fsl_lpspi_init_rpm(fsl_lpspi);
+ if (ret)
goto out_controller_put;
- }
- ret = clk_prepare_enable(fsl_lpspi->clk_per);
- if (ret) {
- dev_err(>dev,
- "can't enable lpspi per clock, ret=%d\n", ret);
- clk_disable_unprepare(fsl_lpspi->clk_ipg);
- goto out_controller_put;
+ ret = pm_runtime_get_sync(fsl_lpspi->dev);
+ if (ret < 0) {
+ dev_err(fsl_lpspi->dev, "failed to enable clock\n");
+ return ret;
}
temp = readl(fsl_lpspi->base + IMX7ULP_PARAM);
fsl_lpspi->txfifosize = 1 << (temp & 0x0f);
fsl_lpspi->rxfifosize = 1 << ((temp >> 8) & 0x0f);
- clk_disable_unprepare(fsl_lpspi->clk_per);
- clk_disable_unprepare(fsl_lpspi->clk_ipg);
-
ret = devm_spi_register_controller(>dev, controller);
if (ret < 0) {
dev_err(>dev, "spi_register_controller error.\n");
@@ -593,16 +626,50 @@ static int fsl_lpspi_remove(struct platform_device *pdev)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
- clk_disable_unprepare(fsl_lpspi->clk_per);
-
[PATCH V2 5/8] spi: lpspi: use the core way to implement cs-gpio function
Use the default implementation of transfer_one_msg/chipselect/setup
functions in spi core to implement cs-gpio control.
Use fsl_lpspi_prepare_message to init the cs_gpio pin.
Signed-off-by: Clark Wang
Acked-by: Fugang Duan
---
V2:
- use core way to implement cs-gpio control. Removed the redundant code
in the driver.
---
drivers/spi/spi-fsl-lpspi.c | 101 +++-
1 file changed, 66 insertions(+), 35 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 69635cde0e22..a25e0e03f058 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -16,8 +17,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -91,6 +94,7 @@ struct fsl_lpspi_data {
struct clk *clk_ipg;
struct clk *clk_per;
bool is_slave;
+ bool is_first_byte;
void *rx_buf;
const void *tx_buf;
@@ -106,6 +110,8 @@ struct fsl_lpspi_data {
struct completion xfer_done;
bool slave_aborted;
+
+ int chipselect[0];
};
static const struct of_device_id fsl_lpspi_dt_ids[] = {
@@ -178,6 +184,20 @@ static int lpspi_unprepare_xfer_hardware(struct
spi_controller *controller)
return 0;
}
+static int fsl_lpspi_prepare_message(struct spi_controller *controller,
+struct spi_message *msg)
+{
+ struct fsl_lpspi_data *fsl_lpspi =
+ spi_controller_get_devdata(controller);
+ struct spi_device *spi = msg->spi;
+ int gpio = fsl_lpspi->chipselect[spi->chip_select];
+
+ if (gpio_is_valid(gpio))
+ gpio_direction_output(gpio, spi->mode & SPI_CS_HIGH ? 0 : 1);
+
+ return 0;
+}
+
static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data *fsl_lpspi)
{
u8 txfifo_cnt;
@@ -210,8 +230,7 @@ static void fsl_lpspi_read_rx_fifo(struct fsl_lpspi_data
*fsl_lpspi)
fsl_lpspi->rx(fsl_lpspi);
}
-static void fsl_lpspi_set_cmd(struct fsl_lpspi_data *fsl_lpspi,
- bool is_first_xfer)
+static void fsl_lpspi_set_cmd(struct fsl_lpspi_data *fsl_lpspi)
{
u32 temp = 0;
@@ -227,7 +246,7 @@ static void fsl_lpspi_set_cmd(struct fsl_lpspi_data
*fsl_lpspi,
* For subsequent transfer, set TCR_CONTC to keep SS asserted.
*/
temp |= TCR_CONT;
- if (is_first_xfer)
+ if (fsl_lpspi->is_first_byte)
temp &= ~TCR_CONTC;
else
temp |= TCR_CONTC;
@@ -396,8 +415,7 @@ static int fsl_lpspi_reset(struct fsl_lpspi_data *fsl_lpspi)
return 0;
}
-static int fsl_lpspi_transfer_one(struct spi_controller *controller,
- struct spi_device *spi,
+static int fsl_lpspi_pio_transfer(struct spi_controller *controller,
struct spi_transfer *t)
{
struct fsl_lpspi_data *fsl_lpspi =
@@ -422,40 +440,27 @@ static int fsl_lpspi_transfer_one(struct spi_controller
*controller,
return 0;
}
-static int fsl_lpspi_transfer_one_msg(struct spi_controller *controller,
- struct spi_message *msg)
+static int fsl_lpspi_transfer_one(struct spi_controller *controller,
+ struct spi_device *spi,
+ struct spi_transfer *t)
{
struct fsl_lpspi_data *fsl_lpspi =
- spi_controller_get_devdata(controller);
- struct spi_device *spi = msg->spi;
- struct spi_transfer *xfer;
- bool is_first_xfer = true;
- int ret = 0;
-
- msg->status = 0;
- msg->actual_length = 0;
-
- list_for_each_entry(xfer, >transfers, transfer_list) {
- ret = fsl_lpspi_setup_transfer(spi, xfer);
- if (ret < 0)
- goto complete;
-
- fsl_lpspi_set_cmd(fsl_lpspi, is_first_xfer);
-
- is_first_xfer = false;
+ spi_controller_get_devdata(controller);
+ int ret;
- ret = fsl_lpspi_transfer_one(controller, spi, xfer);
- if (ret < 0)
- goto complete;
+ fsl_lpspi->is_first_byte = true;
+ ret = fsl_lpspi_setup_transfer(spi, t);
+ if (ret < 0)
+ return ret;
- msg->actual_length += xfer->len;
- }
+ fsl_lpspi_set_cmd(fsl_lpspi);
+ fsl_lpspi->is_first_byte = false;
-complete:
- msg->status = ret;
- spi_finalize_current_message(controller);
+ ret = fsl_lpspi_pio_transfer(controller, t);
+ if (ret < 0)
+ return ret;
- return ret;
+ return 0;
}
static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
@@
[PATCH v2] f2fs: fix to add refcount once page is tagged PG_private
As Gao Xiang reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=202749
f2fs may skip pageout() due to incorrect page reference count.
The problem here is that MM defined the rule [1] very clearly that
once page was set with PG_private flag, we should increment the
refcount in that page, also main flows like pageout(), migrate_page()
will assume there is one additional page reference count if
page_has_private() returns true.
But currently, f2fs won't add/del refcount when changing PG_private
flag. Anyway, f2fs should follow MM's rule to make MM's related flows
running as expected.
[1] https://lore.kernel.org/lkml/2b19b3c4-2bc4-15fa-15cc-27a13e5c7...@aol.com/
Reported-by: Gao Xiang
Signed-off-by: Chao Yu
---
v2:
- introduce generic function f2fs_{set,clear}_page_private() to wrap related
operations as Jaegeuk suggested.
fs/f2fs/checkpoint.c | 4 ++--
fs/f2fs/data.c | 23 ++-
fs/f2fs/dir.c| 2 +-
fs/f2fs/f2fs.h | 19 +++
fs/f2fs/node.c | 2 +-
fs/f2fs/segment.c| 8 +++-
6 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index c65a1e8e1e95..9ce38a0ad2fe 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -406,7 +406,7 @@ static int f2fs_set_meta_page_dirty(struct page *page)
if (!PageDirty(page)) {
__set_page_dirty_nobuffers(page);
inc_page_count(F2FS_P_SB(page), F2FS_DIRTY_META);
- SetPagePrivate(page);
+ f2fs_set_page_private(page);
f2fs_trace_pid(page);
return 1;
}
@@ -957,7 +957,7 @@ void f2fs_update_dirty_page(struct inode *inode, struct
page *page)
inode_inc_dirty_pages(inode);
spin_unlock(>inode_lock[type]);
- SetPagePrivate(page);
+ f2fs_set_page_private(page);
f2fs_trace_pid(page);
}
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 3f3becd46362..14ee7dd0c6bc 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2715,8 +2715,7 @@ void f2fs_invalidate_page(struct page *page, unsigned int
offset,
if (IS_ATOMIC_WRITTEN_PAGE(page))
return f2fs_drop_inmem_page(inode, page);
- set_page_private(page, 0);
- ClearPagePrivate(page);
+ f2fs_clear_page_private(page);
}
int f2fs_release_page(struct page *page, gfp_t wait)
@@ -2730,8 +2729,7 @@ int f2fs_release_page(struct page *page, gfp_t wait)
return 0;
clear_cold_data(page);
- set_page_private(page, 0);
- ClearPagePrivate(page);
+ f2fs_clear_page_private(page);
return 1;
}
@@ -2799,12 +2797,8 @@ int f2fs_migrate_page(struct address_space *mapping,
return -EAGAIN;
}
- /*
-* A reference is expected if PagePrivate set when move mapping,
-* however F2FS breaks this for maintaining dirty page counts when
-* truncating pages. So here adjusting the 'extra_count' make it work.
-*/
- extra_count = (atomic_written ? 1 : 0) - page_has_private(page);
+ /* one extra reference was held for atomic_write page */
+ extra_count = atomic_written ? 1 : 0;
rc = migrate_page_move_mapping(mapping, newpage,
page, mode, extra_count);
if (rc != MIGRATEPAGE_SUCCESS) {
@@ -2825,9 +2819,12 @@ int f2fs_migrate_page(struct address_space *mapping,
get_page(newpage);
}
- if (PagePrivate(page))
- SetPagePrivate(newpage);
- set_page_private(newpage, page_private(page));
+ if (PagePrivate(page)) {
+ f2fs_set_page_private(newpage);
+ set_page_private(newpage, page_private(page));
+
+ f2fs_clear_page_private(page);
+ }
if (mode != MIGRATE_SYNC_NO_COPY)
migrate_page_copy(newpage, page);
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 103f3686a045..fb647e58edb5 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -728,7 +728,7 @@ void f2fs_delete_entry(struct f2fs_dir_entry *dentry,
struct page *page,
!f2fs_truncate_hole(dir, page->index, page->index + 1)) {
f2fs_clear_page_cache_dirty_tag(page);
clear_page_dirty_for_io(page);
- ClearPagePrivate(page);
+ f2fs_clear_page_private(page);
ClearPageUptodate(page);
clear_cold_data(page);
inode_dec_dirty_pages(dir);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 3007759dd2dd..883354777d25 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2835,6 +2835,25 @@ static inline bool is_valid_data_blkaddr(struct
f2fs_sb_info *sbi,
return true;
}
+static inline void f2fs_set_page_private(struct page *page)
+{
+ if (PagePrivate(page))
+ return;
+
+ get_page(page);
+ SetPagePrivate(page);
+}
+
+static inline void
[PATCH V2 0/8] spi: lpspi: Fix bugs and Add some functions support
Hi Mark, Sorry for replying so late. This patchset contains changes based on your and other reviewers' comments. As subject, these fucntions support, including: - Support i.MX8 series boards; - Support cs-gpio fucntion; - Support DMA mode for both master and salve mode. These are some notes about cs-gpio and DMA: - cs-gpio: Because LPSPI driver don't use default implementation of transfer_one_message(), I do the cs-gpio control way as same as the way used in spi core; - DMA: Any frame length longer than half txfifosize will be sent by DMA mode. For now, there are some limits: 1. The maximum transfer speed in master mode depends on the slave device, at least 40MHz on i.MX8 series (tested by spi-nor on 8qm-lpddr4-arm2 base board); 2. The maximum transfer speed I test in slave mode is 15MHz(i.MX7ULP), 20MHz(i.MX8 series). In order to reach the maximum speed which is mentioned in datasheet, the load of connect wires between master and slave should be less than 15pF. Each patch in this patchset should base on the previous one when applied. Thank you! Clark Wang (7): spi: lpspi: Add i.MX8 boards support for lpspi doc: lpspi: Document DT bindings for LPSPI clocks spi: lpspi: add the error info of transfer speed setting spi: lpspi: use the core way to implement cs-gpio function spi: lpspi: add dma mode support spi: lpspi: Add the missing NULL check spi: lpspi: Code cleanup Han Xu (1): spi: lpspi: enable runtime pm for lpspi .../devicetree/bindings/spi/spi-fsl-lpspi.txt | 10 +- drivers/spi/spi-fsl-lpspi.c | 543 -- 2 files changed, 495 insertions(+), 58 deletions(-) -- 2.17.1
[PATCH V2 8/8] spi: lpspi: Code cleanup
Delete the extra space. Signed-off-by: Clark Wang --- V2: - add this patch in this version --- drivers/spi/spi-fsl-lpspi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c index 2ac3ac5ea50a..1860f066f838 100644 --- a/drivers/spi/spi-fsl-lpspi.c +++ b/drivers/spi/spi-fsl-lpspi.c @@ -345,7 +345,7 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data *fsl_lpspi) writel(scldiv | (scldiv << 8) | ((scldiv >> 1) << 16), fsl_lpspi->base + IMX7ULP_CCR); - dev_dbg(fsl_lpspi->dev, "perclk=%d, speed=%d, prescale =%d, scldiv=%d\n", + dev_dbg(fsl_lpspi->dev, "perclk=%d, speed=%d, prescale=%d, scldiv=%d\n", perclk_rate, config.speed_hz, prescale, scldiv); return 0; -- 2.17.1
[PATCH V2 6/8] spi: lpspi: add dma mode support
Add dma mode support for LPSPI. Any frame longer than half txfifosize will
be sent by dma mode.
For now, there are some limits:
1. The maximum transfer speed in master mode depends on the slave device,
at least 40MHz(tested by spi-nor on 8qm-lpddr4-arm2 base board);
2. The maximum transfer speed in slave mode is 15MHz(imx7ulp),
22MHz(8qm/qxp). In order to reach the maximum speed which is mentioned
in datasheet, the load of connect wires between master and slave
should be less than 15pF.
Signed-off-by: Clark Wang
Acked-by: Fugang Duan
---
V2:
- replace a if judgement by switch statement
- seperate a Debug print fix into next patch
---
drivers/spi/spi-fsl-lpspi.c | 312 ++--
1 file changed, 301 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index a25e0e03f058..9ff32fb67a29 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -20,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,6 +34,9 @@
#define FSL_LPSPI_RPM_TIMEOUT 50 /* 50ms */
+/* The maximum bytes that edma can transfer once.*/
+#define FSL_LPSPI_MAX_EDMA_BYTES ((1 << 15) - 1)
+
/* i.MX7ULP LPSPI registers */
#define IMX7ULP_VERID 0x0
#define IMX7ULP_PARAM 0x4
@@ -64,6 +70,8 @@
#define IER_FCIE BIT(9)
#define IER_RDIE BIT(1)
#define IER_TDIE BIT(0)
+#define DER_RDDE BIT(1)
+#define DER_TDDE BIT(0)
#define CFGR1_PCSCFG BIT(27)
#define CFGR1_PINCFG (BIT(24)|BIT(25))
#define CFGR1_PCSPOL BIT(8)
@@ -91,6 +99,7 @@ struct lpspi_config {
struct fsl_lpspi_data {
struct device *dev;
void __iomem *base;
+ unsigned long base_phys;
struct clk *clk_ipg;
struct clk *clk_per;
bool is_slave;
@@ -111,6 +120,11 @@ struct fsl_lpspi_data {
bool slave_aborted;
+ /* DMA */
+ bool usedma;
+ struct completion dma_rx_completion;
+ struct completion dma_tx_completion;
+
int chipselect[0];
};
@@ -158,6 +172,35 @@ static void fsl_lpspi_intctrl(struct fsl_lpspi_data
*fsl_lpspi,
writel(enable, fsl_lpspi->base + IMX7ULP_IER);
}
+static int fsl_lpspi_bytes_per_word(const int bpw)
+{
+ return DIV_ROUND_UP(bpw, BITS_PER_BYTE);
+}
+
+static bool fsl_lpspi_can_dma(struct spi_controller *controller,
+ struct spi_device *spi,
+ struct spi_transfer *transfer)
+{
+ unsigned int bytes_per_word;
+
+ if (!controller->dma_rx)
+ return false;
+
+ bytes_per_word = fsl_lpspi_bytes_per_word(transfer->bits_per_word);
+
+ switch (bytes_per_word)
+ {
+ case 1:
+ case 2:
+ case 4:
+ break;
+ default:
+ return false;
+ }
+
+ return true;
+}
+
static int lpspi_prepare_xfer_hardware(struct spi_controller *controller)
{
struct fsl_lpspi_data *fsl_lpspi =
@@ -245,11 +288,13 @@ static void fsl_lpspi_set_cmd(struct fsl_lpspi_data
*fsl_lpspi)
* For the first transfer, clear TCR_CONTC to assert SS.
* For subsequent transfer, set TCR_CONTC to keep SS asserted.
*/
- temp |= TCR_CONT;
- if (fsl_lpspi->is_first_byte)
- temp &= ~TCR_CONTC;
- else
- temp |= TCR_CONTC;
+ if (!fsl_lpspi->usedma) {
+ temp |= TCR_CONT;
+ if (fsl_lpspi->is_first_byte)
+ temp &= ~TCR_CONTC;
+ else
+ temp |= TCR_CONTC;
+ }
}
writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
@@ -260,7 +305,11 @@ static void fsl_lpspi_set_watermark(struct fsl_lpspi_data
*fsl_lpspi)
{
u32 temp;
- temp = fsl_lpspi->watermark >> 1 | (fsl_lpspi->watermark >> 1) << 16;
+ if (!fsl_lpspi->usedma)
+ temp = fsl_lpspi->watermark >> 1 |
+ (fsl_lpspi->watermark >> 1) << 16;
+ else
+ temp = fsl_lpspi->watermark >> 1;
writel(temp, fsl_lpspi->base + IMX7ULP_FCR);
@@ -302,6 +351,53 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data
*fsl_lpspi)
return 0;
}
+static int fsl_lpspi_dma_configure(struct spi_controller *controller)
+{
+ int ret;
+ enum dma_slave_buswidth buswidth;
+ struct dma_slave_config rx = {}, tx = {};
+ struct fsl_lpspi_data *fsl_lpspi =
+ spi_controller_get_devdata(controller);
+
+ switch (fsl_lpspi_bytes_per_word(fsl_lpspi->config.bpw)) {
+ case 4:
+ buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ break;
+
[PATCH V2 7/8] spi: lpspi: Add the missing NULL check
The spi_transfer *t will be used in one transfer whatever. If t is NULL, there has no need to try sending data, so add an error return here. Signed-off-by: Clark Wang Acked-by: Fugang Duan --- V2: - add this patch in this version --- drivers/spi/spi-fsl-lpspi.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c index 9ff32fb67a29..2ac3ac5ea50a 100644 --- a/drivers/spi/spi-fsl-lpspi.c +++ b/drivers/spi/spi-fsl-lpspi.c @@ -438,9 +438,12 @@ static int fsl_lpspi_setup_transfer(struct spi_controller *controller, struct fsl_lpspi_data *fsl_lpspi = spi_controller_get_devdata(spi->controller); + if (t == NULL) + return -EINVAL; + fsl_lpspi->config.mode = spi->mode; - fsl_lpspi->config.bpw = t ? t->bits_per_word : spi->bits_per_word; - fsl_lpspi->config.speed_hz = t ? t->speed_hz : spi->max_speed_hz; + fsl_lpspi->config.bpw = t->bits_per_word; + fsl_lpspi->config.speed_hz = t->speed_hz; fsl_lpspi->config.chip_select = spi->chip_select; if (!fsl_lpspi->config.speed_hz) -- 2.17.1
[PATCH V2 1/8] spi: lpspi: Add i.MX8 boards support for lpspi
Add both ipg and per clock for lpspi to support i.MX8QM/QXP boards.
Signed-off-by: Clark Wang
---
V2:
- No change. But add DT-bindings string at the next patch.
---
drivers/spi/spi-fsl-lpspi.c | 52 +
1 file changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 391863914043..f363c000d24a 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -84,7 +84,8 @@ struct lpspi_config {
struct fsl_lpspi_data {
struct device *dev;
void __iomem *base;
- struct clk *clk;
+ struct clk *clk_ipg;
+ struct clk *clk_per;
bool is_slave;
void *rx_buf;
@@ -151,8 +152,19 @@ static int lpspi_prepare_xfer_hardware(struct
spi_controller *controller)
{
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
+ int ret;
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_per);
+ if (ret) {
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
+ return ret;
+ }
- return clk_prepare_enable(fsl_lpspi->clk);
+ return 0;
}
static int lpspi_unprepare_xfer_hardware(struct spi_controller *controller)
@@ -160,7 +172,8 @@ static int lpspi_unprepare_xfer_hardware(struct
spi_controller *controller)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
- clk_disable_unprepare(fsl_lpspi->clk);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
+ clk_disable_unprepare(fsl_lpspi->clk_per);
return 0;
}
@@ -241,7 +254,7 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data
*fsl_lpspi)
unsigned int perclk_rate, scldiv;
u8 prescale;
- perclk_rate = clk_get_rate(fsl_lpspi->clk);
+ perclk_rate = clk_get_rate(fsl_lpspi->clk_per);
for (prescale = 0; prescale < 8; prescale++) {
scldiv = perclk_rate /
(clkdivs[prescale] * config.speed_hz) - 2;
@@ -526,15 +539,30 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
goto out_controller_put;
}
- fsl_lpspi->clk = devm_clk_get(>dev, "ipg");
- if (IS_ERR(fsl_lpspi->clk)) {
- ret = PTR_ERR(fsl_lpspi->clk);
+ fsl_lpspi->clk_per = devm_clk_get(>dev, "per");
+ if (IS_ERR(fsl_lpspi->clk_per)) {
+ ret = PTR_ERR(fsl_lpspi->clk_per);
+ goto out_controller_put;
+ }
+
+ fsl_lpspi->clk_ipg = devm_clk_get(>dev, "ipg");
+ if (IS_ERR(fsl_lpspi->clk_ipg)) {
+ ret = PTR_ERR(fsl_lpspi->clk_ipg);
+ goto out_controller_put;
+ }
+
+ ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+ if (ret) {
+ dev_err(>dev,
+ "can't enable lpspi ipg clock, ret=%d\n", ret);
goto out_controller_put;
}
- ret = clk_prepare_enable(fsl_lpspi->clk);
+ ret = clk_prepare_enable(fsl_lpspi->clk_per);
if (ret) {
- dev_err(>dev, "can't enable lpspi clock, ret=%d\n", ret);
+ dev_err(>dev,
+ "can't enable lpspi per clock, ret=%d\n", ret);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
goto out_controller_put;
}
@@ -542,7 +570,8 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi->txfifosize = 1 << (temp & 0x0f);
fsl_lpspi->rxfifosize = 1 << ((temp >> 8) & 0x0f);
- clk_disable_unprepare(fsl_lpspi->clk);
+ clk_disable_unprepare(fsl_lpspi->clk_per);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
ret = devm_spi_register_controller(>dev, controller);
if (ret < 0) {
@@ -564,7 +593,8 @@ static int fsl_lpspi_remove(struct platform_device *pdev)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
- clk_disable_unprepare(fsl_lpspi->clk);
+ clk_disable_unprepare(fsl_lpspi->clk_per);
+ clk_disable_unprepare(fsl_lpspi->clk_ipg);
return 0;
}
--
2.17.1
Re: [PATCH 08/14] Move EM_NDS32 to uapi/linux/elf-em.h
Vincent Chen 於 2019年3月5日 週二 上午8:26寫道： > > Dmitry V. Levin 於 2019年2月27日 週三 下午11:30寫道： > > > > > > This should never have been defined in the arch tree to begin with, > > and now uapi/linux/audit.h header is going to use EM_NDS32 > > in order to define AUDIT_ARCH_NDS32 which is needed to implement > > syscall_get_arch() which in turn is required to extend > > the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. > > > > Acked-by: Paul Moore > > Cc: Greentime Hu > > Cc: Vincent Chen > > Cc: Elvira Khabirova > > Cc: Eugene Syromyatnikov > > Cc: Oleg Nesterov > > Cc: Andy Lutomirski > > Cc: linux-au...@redhat.com > > Signed-off-by: Dmitry V. Levin > > --- > > This is just a gentle ping, the patch is unchanged. > > > > arch/nds32/include/asm/elf.h | 3 +-- > > include/uapi/linux/elf-em.h | 2 ++ > > 2 files changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/arch/nds32/include/asm/elf.h b/arch/nds32/include/asm/elf.h > > index 95f3ea253e4c..02250626b9f0 100644 > > --- a/arch/nds32/include/asm/elf.h > > +++ b/arch/nds32/include/asm/elf.h > > @@ -10,14 +10,13 @@ > > > > #include > > #include > > +#include > > > > typedef unsigned long elf_greg_t; > > typedef unsigned long elf_freg_t[3]; > > > > extern unsigned int elf_hwcap; > > > > -#define EM_NDS32 167 > > - > > #define R_NDS32_NONE 0 > > #define R_NDS32_16_RELA19 > > #define R_NDS32_32_RELA20 > > diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h > > index bd02325028d8..4b8df722330e 100644 > > --- a/include/uapi/linux/elf-em.h > > +++ b/include/uapi/linux/elf-em.h > > @@ -40,6 +40,8 @@ > > #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core > > processor */ > > #define EM_TI_C6000140 /* TI C6X DSPs */ > > #define EM_HEXAGON 164 /* QUALCOMM Hexagon */ > > +#define EM_NDS32 167 /* Andes Technology compact code size > > + embedded RISC processor family */ > > #define EM_AARCH64 183 /* ARM 64 bit */ > > #define EM_TILEPRO 188 /* Tilera TILEPro */ > > #define EM_MICROBLAZE 189 /* Xilinx MicroBlaze */ > > -- > > ldv > > Thanks for fixing this. > > Acked-by Vincent Chen Thank you. I add his email address. :P Acked-by: Vincent Chen Acked-by: Greentime Hu
Re: KASAN: use-after-free Read in get_mem_cgroup_from_mm
Hi, On Wed, Mar 06, 2019 at 01:53:12PM +0800, zhong jiang wrote: > On 2019/3/6 10:05, Andrea Arcangeli wrote: > > Hello everyone, > > > > [ CC'ed Mike and Peter ] > > > > On Tue, Mar 05, 2019 at 02:42:00PM +0800, zhong jiang wrote: > >> On 2019/3/5 14:26, Dmitry Vyukov wrote: > >>> On Mon, Mar 4, 2019 at 4:32 PM zhong jiang wrote: > On 2019/3/4 22:11, Dmitry Vyukov wrote: > > On Mon, Mar 4, 2019 at 3:00 PM zhong jiang > > wrote: > >> On 2019/3/4 15:40, Dmitry Vyukov wrote: > >>> On Sun, Mar 3, 2019 at 5:19 PM zhong jiang > >>> wrote: > Hi, guys > > I also hit the following issue. but it fails to reproduce the issue > by the log. > > it seems to the case that we access the mm->owner and deference it > will result in the UAF. > But it should not be possible that we specify the incomplete process > to be the mm->owner. > > Any thoughts? > >>> FWIW syzbot was able to reproduce this with this reproducer. > >>> This looks like a very subtle race (threaded reproducer that runs > >>> repeatedly in multiple processes), so most likely we are looking for > >>> something like few instructions inconsistency window. > >>> > >> I has a little doubtful about the instrustions inconsistency window. > >> > >> I guess that you mean some smb barriers should be taken into > >> account.:-) > >> > >> Because IMO, It should not be the lock case to result in the issue. > > Since the crash was triggered on x86 _most likley_ this is not a > > missed barrier. What I meant is that one thread needs to executed some > > code, while another thread is stopped within few instructions. > > > > > It is weird and I can not find any relationship you had said with the > issue.:-( > > Because It is the cause that mm->owner has been freed, whereas we still > deference it. > > From the lastest freed task call trace, It fails to create process. > > Am I miss something or I misunderstand your meaning. Please correct me. > >>> Your analysis looks correct. I am just saying that the root cause of > >>> this use-after-free seems to be a race condition. > >>> > >>> > >>> > >> Yep, Indeed, I can not figure out how the race works. I will dig up > >> further. > > Yes it's a race condition. > > > > We were aware about the non-cooperative fork userfaultfd feature > > creating userfaultfd file descriptor that gets reported to the parent > > uffd, despite they belong to mm created by failed forks. > > > > https://www.spinics.net/lists/linux-mm/msg136357.html > > > > Hi, Andrea > > I still not clear why uffd ioctl can use the incomplete process as the > mm->owner. > and how to produce the race. There is a C reproducer in the syzcaller report: https://syzkaller.appspot.com/x/repro.c?x=172fa5a340 > From your above explainations, My underdtanding is that the process > handling do_exexve > will have a temporary mm, which will be used by the UUFD ioctl. The race is between userfaultfd operation and fork() failure: forking thread | userfaultfd monitor thread +--- fork() | dup_mmap()| dup_userfaultfd() | dup_userfaultfd_complete() | | read(UFFD_EVENT_FORK) | uffdio_copy() |mmget_not_zero() goto bad_fork_something | ... | bad_fork_free: | free_task() | | mem_cgroup_from_task() | /* access stale mm->owner */ > Thanks, > zhong jiang -- Sincerely yours, Mike.
Re: [PATCH 09/14] nds32: define syscall_get_arch()
Vincent Chen 於 2019年3月5日 週二 上午7:50寫道：
>
> Dmitry V. Levin 於 2019年2月27日 週三 下午11:30寫道：
>
> >
> > syscall_get_arch() is required to be implemented on all architectures
> > in addition to already implemented syscall_get_nr(),
> > syscall_get_arguments(), syscall_get_error(), and
> > syscall_get_return_value() functions in order to extend the generic
> > ptrace API with PTRACE_GET_SYSCALL_INFO request.
> >
> > Acked-by: Paul Moore
> > Cc: Elvira Khabirova
> > Cc: Eugene Syromyatnikov
> > Cc: Greentime Hu
> > Cc: Vincent Chen
> > Cc: Oleg Nesterov
> > Cc: Andy Lutomirski
> > Cc: linux-au...@redhat.com
> > Signed-off-by: Dmitry V. Levin
> > ---
> > This is just a gentle ping, the patch is unchanged.
> >
> > arch/nds32/include/asm/syscall.h | 9 +
> > include/uapi/linux/audit.h | 2 ++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/arch/nds32/include/asm/syscall.h
> > b/arch/nds32/include/asm/syscall.h
> > index f7e5e86765fe..cc56a3962f8b 100644
> > --- a/arch/nds32/include/asm/syscall.h
> > +++ b/arch/nds32/include/asm/syscall.h
> > @@ -5,6 +5,7 @@
> > #ifndef _ASM_NDS32_SYSCALL_H
> > #define _ASM_NDS32_SYSCALL_H 1
> >
> > +#include
> > #include
> > struct task_struct;
> > struct pt_regs;
> > @@ -185,4 +186,12 @@ void syscall_set_arguments(struct task_struct *task,
> > struct pt_regs *regs,
> >
> > memcpy(>uregs[0] + i, args, n * sizeof(args[0]));
> > }
> > +
> > +static inline int
> > +syscall_get_arch(void)
> > +{
> > + return IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)
> > + ? AUDIT_ARCH_NDS32BE : AUDIT_ARCH_NDS32;
> > +}
> > +
> > #endif /* _ASM_NDS32_SYSCALL_H */
> > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > index b1602dcc13bc..1568ddc1c945 100644
> > --- a/include/uapi/linux/audit.h
> > +++ b/include/uapi/linux/audit.h
> > @@ -401,6 +401,8 @@ enum {
> > #define AUDIT_ARCH_MIPSEL64(EM_MIPS|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> > #define AUDIT_ARCH_MIPSEL64N32
> > (EM_MIPS|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE|\
> > __AUDIT_ARCH_CONVENTION_MIPS64_N32)
> > +#define AUDIT_ARCH_NDS32 (EM_NDS32|__AUDIT_ARCH_LE)
> > +#define AUDIT_ARCH_NDS32BE (EM_NDS32)
> > #define AUDIT_ARCH_OPENRISC(EM_OPENRISC)
> > #define AUDIT_ARCH_PARISC (EM_PARISC)
> > #define AUDIT_ARCH_PARISC64(EM_PARISC|__AUDIT_ARCH_64BIT)
> > --
> > ldv
>
> Thanks for fixing this.
>
> Acked-by Vincent Chen
Thank you. I add his email address. :P
Acked-by: Vincent Chen
Acked-by: Greentime Hu
[PATCH] media: mtk-vcodec: fix access to vb2_v4l2_buffer struct
Commit 0650a91499e0 ("media: mtk-vcodec: Correct return type for mem2mem
buffer helpers") fixed the return types for mem2mem buffer helper
functions, but omitted two occurrences that are accessed in the
mtk_v4l2_debug() macro. These only trigger compiler errors when DEBUG is
defined.
Fixes: 0650a91499e0 ("media: mtk-vcodec: Correct return type for mem2mem buffer
helpers")
Signed-off-by: Alexandre Courbot
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index d022c65bb34c..a85c7cc8328e 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1158,7 +1158,7 @@ static void vb2ops_vdec_buf_queue(struct vb2_buffer *vb)
src_mem.size = (size_t)src_buf->planes[0].bytesused;
mtk_v4l2_debug(2,
"[%d] buf id=%d va=%p dma=%pad size=%zx",
- ctx->id, src_buf->index,
+ ctx->id, src_buf->vb2_buf.index,
src_mem.va, _mem.dma_addr,
src_mem.size);
@@ -1182,7 +1182,7 @@ static void vb2ops_vdec_buf_queue(struct vb2_buffer *vb)
}
mtk_v4l2_debug(ret ? 0 : 1,
"[%d] vdec_if_decode() src_buf=%d, size=%zu,
fail=%d, res_chg=%d",
- ctx->id, src_buf->index,
+ ctx->id, src_buf->vb2_buf.index,
src_mem.size, ret, res_chg);
return;
}
--
2.21.0.352.gf09ad66450-goog
Re: [PATCH v2 01/15] ARM: actions: fix a leaked reference by addingmissing of_node_put
On Wed, 6 Mar 2019, wen.yan...@zte.com.cn wrote:
> On Tue, Mar 05, 2019 at 07:41 PM +0800, RussellKing wrote:
> > Subject: Re: [PATCH v2 01/15] ARM: actions: fix a leaked reference by
> > addingmissing of_node_put
> > On Tue, Mar 05, 2019 at 07:33:52PM +0800, Wen Yang wrote:
> > > The call to of_get_next_child returns a node pointer with refcount
> > > incremented thus it must be explicitly decremented after the last
> > > usage.
> > >
> > > Detected by coccinelle with the following warnings:
> > > ./arch/arm/mach-actions/platsmp.c:112:2-8: ERROR: missing of_node_put;
> > > acquired a node pointer with refcount incremented on line 103, but
> > > without a corresponding object release within this function.
> > > ./arch/arm/mach-actions/platsmp.c:124:2-8: ERROR: missing of_node_put;
> > > acquired a node pointer with refcount incremented on line 115, but
> > > without a corresponding object release within this function.
> > > ./arch/arm/mach-actions/platsmp.c:137:3-9: ERROR: missing of_node_put;
> > > acquired a node pointer with refcount incremented on line 128, but
> > > without a corresponding object release within this function.
> >
> > I question this. Your reasoning is that the node is no longer used
> > so the reference count needs to be put.
Is the concern about the warning message? Or will doing the put cause an
error? Or is the concern that adding the put will clutter the code or
cause unwanted churn? I see that you say below that having the count hit
0 would be a bug, but would it actually hit 0, since there has been a get
in all of the accessing function calls? The semantic patch that produces
the message requires that the device node is only stored in a local
variable, so the current access to it will not be accessible any more when
the function is over.
The version of the semantic patch that Wen Yang is currently working
on, also checks that there is a put of the same data elsewhere in the
function, so perhaps that will alleviate the concern about puts where they
are not needed, while still making it possible to find the ones that are
needed.
thanks,
julia
> >
> > However, in all these cases, data is read from the nodes properties
> > and the device remains in-use for the life of the kernel. There is
> > a big difference here.
> >
> > With normal drivers, each device is bound to their associated device
> > node associated with the device. When the device node goes away, then
> > the corresponding device goes away too, which causes the driver to be
> > unbound from the device.
> >
> > However, there is another class of "driver" which are the ones below,
> > where they are "permanent" devices. These can never go away, even if
> > the device node refcount hits zero and the device node is freed - the
> > device is still present and in-use in the system.
>
> Hi Russel,
> Thank you very much for your comments.
> The problem we want to solve is "fix the reference leaks of device_node".
> We use the following coccinelle script to achieve the goal:
> @search exists@
> local idexpression struct device_node * node;
> expression e, e1;
> position p1,p2;
> type T,T1,T2;
> @@
>
> node = @p1\(of_find_compatible_node\|of_find_node_by_name\|of_parse_phandle\|
> of_find_node_by_type\|of_find_node_by_name\|of_find_all_nodes\|
> of_get_cpu_node\|of_get_parent\|of_get_next_parent\|
> of_get_next_child\|of_get_next_available_child\|of_get_next_cpu_node\|
> of_get_compatible_child\|of_get_child_by_name\|of_find_node_opts_by_path\|
>
> of_find_node_with_property\|of_find_matching_node_and_match\|of_find_node_by_phandle\|
> of_parse_phandle\)(...)
> ... when != e = (T)node
> if (node == NULL || ...) { ... return ...; }
> ... when != of_node_put(node)
> when != if (node) { ... of_node_put(node) ... }
> when != e1 = (T1)node
> (
> return (T2)node;
> | return@p2 ...;
> )
>
> Using the script above, we found the issues for this file in the patch:
> arch/arm/mach-actions/platsmp.c
> 99 static void __init s500_smp_prepare_cpus(unsigned int max_cpus)
> 100 {
> 101 struct device_node *node;
> 102
> 103 node = of_find_compatible_node(NULL, NULL, "actions,s500-timer");
> ...
> 109 timer_base_addr = of_iomap(node, 0);
> 110 if (!timer_base_addr) {
> 111 pr_err("%s: could not map timer registers\n", __func__);
> 112 return;
> 113 }
> 114
> 115 node = of_find_compatible_node(NULL, NULL, "actions,s500-sps");
> ...
>
> The comment for of_find_compatible_node writes:
> “Returns a node pointer with refcount incremented, use of_node_put() on it
> when done.”
> the node is a local variable obtained by of_find_compatible_node.
> But the code does not call on_node_put() to reduce the reference count,
> the function returns directly, or directly reassigns it.
> This leads to a reference leak.
>
> > So, having the
> > device node refcount hit zero is actually a bug: what that's saying
> > is the system device (eg, SCU) has gone away. If you somehow were to
> > remove the SCU from
Re: [PATCH] media: uvcvideo: Add boottime clock support
On Fri, Nov 23, 2018 at 11:46 PM Tomasz Figa wrote: > > Hi Laurent, > > On Fri, Nov 2, 2018 at 12:03 AM Lars-Peter Clausen wrote: > > > > On 11/01/2018 03:30 PM, Tomasz Figa wrote: > > > On Thu, Nov 1, 2018 at 11:03 PM Laurent Pinchart > > > wrote: > > >> > > >> Hi Alexandru, > > >> > > >> On Thursday, 18 October 2018 20:28:06 EET Alexandru M Stan wrote: > > >>> On Wed, Oct 17, 2018 at 9:31 PM, Tomasz Figa wrote: > > On Thu, Oct 18, 2018 at 5:50 AM Laurent Pinchart wrote: > > > On Wednesday, 17 October 2018 11:28:52 EEST Tomasz Figa wrote: > > >> On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart wrote: > > >>> On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote: > > Android requires camera timestamps to be reported with > > CLOCK_BOOTTIME to sync timestamp with other sensor sources. > > >>> > > >>> What's the rationale behind this, why can't CLOCK_MONOTONIC work ? > > >>> If > > >>> the monotonic clock has shortcomings that make its use impossible > > >>> for > > >>> proper synchronization, then we should consider switching to > > >>> CLOCK_BOOTTIME globally in V4L2, not in selected drivers only. > > >> > > >> CLOCK_BOOTTIME includes the time spent in suspend, while > > >> CLOCK_MONOTONIC doesn't. I can imagine the former being much more > > >> useful for anything that cares about the actual, long term, time > > >> tracking. Especially important since suspend is a very common event > > >> on > > >> Android and doesn't stop the time flow there, i.e. applications might > > >> wake up the device to perform various tasks at necessary times. > > > > > > Sure, but this patch mentions timestamp synchronization with other > > > sensors, and from that point of view, I'd like to know what is wrong > > > with > > > the monotonic clock if all devices use it. > > > > AFAIK the sensors mentioned there are not camera sensors, but rather > > things we normally put under IIO, e.g. accelerometers, gyroscopes and > > so on. I'm not sure how IIO deals with timestamps, but Android seems > > to operate in the CLOCK_BOTTIME domain. Let me add some IIO folks. > > > > Gwendal, Alexandru, do you think you could shed some light on how we > > handle IIO sensors timestamps across the kernel, Chrome OS and > > Android? > > >>> > > >>> On our devices of interest have a specialized "sensor" that comes via > > >>> IIO (from the EC, cros-ec-ring driver) that can be used to more > > >>> accurately timestamp each frame (since it's recorded with very low > > >>> jitter by a realtime-ish OS). In some high level userspace thing > > >>> (specifically the Android Camera HAL) we try to pick the best > > >>> timestamp from the IIO, whatever's closest to what the V4L stuff gives > > >>> us. > > >>> > > >>> I guess the Android convention is for sensor timestamps to be in > > >>> CLOCK_BOOTTIME (maybe because it likes sleeping so much). There's > > >>> probably no advantage to using one over the other, but the important > > >>> thing is that they have to be the same, otherwise the closest match > > >>> logic would fail. > > >> > > >> That's my understanding too, I don't think CLOCK_BOOTTIME really brings > > >> much > > >> benefit in this case, > > > > > > I think it does have a significant benefit. CLOCK_MONOTONIC stops when > > > the device is sleeping, but the sensors can still capture various > > > actions. We would lose the time keeping of those actions if we use > > > CLOCK_MONOTONIC. > > > > > >> but it's important than all timestamps use the same > > >> clock. The question is thus which clock we should select. Mainline > > >> mostly uses > > >> CLOCK_MONOTONIC, and Android CLOCK_BOOTTIME. Would you like to submit > > >> patches > > >> to switch Android to CLOCK_MONOTONIC ? :-) > > > > > > Is it Android using CLOCK_BOOTTIME or the sensors (IIO?). I have > > > almost zero familiarity with the IIO subsystem and was hoping someone > > > from there could comment on what time domain is used for those > > > sensors. > > > > IIO has the option to choose between BOOTTIME or MONOTONIC (and a few > > others) for the timestamp on a per device basis. > > > > There was a bit of a discussion about this a while back. See > > https://lkml.org/lkml/2018/7/10/432 and the following thread. > > Given that IIO supports BOOTTIME in upstream already and also the > important advantage of using it over MONOTONIC for systems which keep > capturing events during sleep, do you think we could move on with some > way to support it in uvcvideo or preferably V4L2 in general? Gentle ping. Best regards, Tomasz
Re: KASAN: use-after-free Read in get_mem_cgroup_from_mm
On 2019/3/6 10:05, Andrea Arcangeli wrote: > Hello everyone, > > [ CC'ed Mike and Peter ] > > On Tue, Mar 05, 2019 at 02:42:00PM +0800, zhong jiang wrote: >> On 2019/3/5 14:26, Dmitry Vyukov wrote: >>> On Mon, Mar 4, 2019 at 4:32 PM zhong jiang wrote: On 2019/3/4 22:11, Dmitry Vyukov wrote: > On Mon, Mar 4, 2019 at 3:00 PM zhong jiang wrote: >> On 2019/3/4 15:40, Dmitry Vyukov wrote: >>> On Sun, Mar 3, 2019 at 5:19 PM zhong jiang >>> wrote: Hi, guys I also hit the following issue. but it fails to reproduce the issue by the log. it seems to the case that we access the mm->owner and deference it will result in the UAF. But it should not be possible that we specify the incomplete process to be the mm->owner. Any thoughts? >>> FWIW syzbot was able to reproduce this with this reproducer. >>> This looks like a very subtle race (threaded reproducer that runs >>> repeatedly in multiple processes), so most likely we are looking for >>> something like few instructions inconsistency window. >>> >> I has a little doubtful about the instrustions inconsistency window. >> >> I guess that you mean some smb barriers should be taken into account.:-) >> >> Because IMO, It should not be the lock case to result in the issue. > Since the crash was triggered on x86 _most likley_ this is not a > missed barrier. What I meant is that one thread needs to executed some > code, while another thread is stopped within few instructions. > > It is weird and I can not find any relationship you had said with the issue.:-( Because It is the cause that mm->owner has been freed, whereas we still deference it. From the lastest freed task call trace, It fails to create process. Am I miss something or I misunderstand your meaning. Please correct me. >>> Your analysis looks correct. I am just saying that the root cause of >>> this use-after-free seems to be a race condition. >>> >>> >>> >> Yep, Indeed, I can not figure out how the race works. I will dig up further. > Yes it's a race condition. > > We were aware about the non-cooperative fork userfaultfd feature > creating userfaultfd file descriptor that gets reported to the parent > uffd, despite they belong to mm created by failed forks. > > https://www.spinics.net/lists/linux-mm/msg136357.html > > The fork failure in my testcase happened because of signal pending > that interrupted fork after the failed-fork uffd context, was already > pushed to the userfaultfd reader/monitor. CRIU then takes care of > filtering the failed fork cases so we didn't want to make the fork > code more complicated just for userfaultfd. > > In reality if MEMCG is enabled at build time, mm->owner maintainance > code now creates a race condition in the above case, with any fork > failure. > > I pinged Mike yesterday to ask if my theory could be true for this bug > and one solution he suggested is to do the userfaultfd_dup at a point > where fork cannot fail anymore. That's precisely what we were > wondering to do back then to avoid the failed fork reports to the > non cooperative uffd monitor. > > That will solve the false positive deliveries that CRIU manager > currently filters out too. From a theoretical standpoint it's also > quite strange to even allow any uffd ioctl to run on a otherwise long > gone mm created for a process that in the end wasn't even created (the > mm got temporarily fully created, but no child task really ever used > such mm). However that mm is on its way to exit_mmap as soon as the > ioclt returns and this only ever happens during race conditions, so > the way CRIU monitor works there wasn't anything fundamentally > concerning about this detail, despite it's remarkably "strange". Our > priority was to keep the fork code as simple as possible and keep > userfaultfd as non intrusive as possible. Hi, Andrea I still not clear why uffd ioctl can use the incomplete process as the mm->owner. and how to produce the race. >From your above explainations, My underdtanding is that the process handling >do_exexve will have a temporary mm, which will be used by the UUFD ioctl. Thanks, zhong jiang > One alternative solution I'm wondering about for this memcg issue is > to free the task struct with RCU also when fork has failed and to add > the mm_update_next_owner before mmput. That will still report failed > forks to the uffd monitor, so it's not the ideal fix, but since it's > probably simpler I'm posting it below. Also I couldn't reproduce the > problem with the testcase here yet. > > >From 6cbf9d377b705476e5226704422357176f79e32c Mon Sep 17 00:00:00 2001 > From: Andrea Arcangeli > Date: Tue, 5 Mar 2019 19:21:37 -0500 > Subject: [PATCH 1/1] userfaultfd: use RCU to free the task struct when fork > fails if MEMCG > > MEMCG depends on the task structure not to be
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/um/Kconfig
between commit:
eac616557050 ("x86: Deprecate a.out support")
from Linus' tree and commit:
942fa985e9f1 ("32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config
option")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/um/Kconfig
index 494eeb51e4e1,ab14e6f73ca4..a9e80e44178c
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@@ -16,6 -16,8 +16,7 @@@ config 64BI
config X86_32
def_bool !64BIT
- select HAVE_AOUT
+ select ARCH_32BIT_OFF_T
select ARCH_WANT_IPC_PARSE_VERSION
select MODULES_USE_ELF_REL
select CLONE_BACKWARDS
pgpmYHszayOPS.pgp
Description: OpenPGP digital signature
[PATCH] clk: qcom: gcc-qcs404: Add CDSP related clocks and resets
Add the clocks and resets need in order to control the Turing
remoteproc.
Signed-off-by: Bjorn Andersson
---
drivers/clk/qcom/gcc-qcs404.c | 90 +
include/dt-bindings/clock/qcom,gcc-qcs404.h | 5 ++
2 files changed, 95 insertions(+)
diff --git a/drivers/clk/qcom/gcc-qcs404.c b/drivers/clk/qcom/gcc-qcs404.c
index 5a62f64ada93..a54807eb3b28 100644
--- a/drivers/clk/qcom/gcc-qcs404.c
+++ b/drivers/clk/qcom/gcc-qcs404.c
@@ -260,6 +260,20 @@ static const char * const gcc_parent_names_15[] = {
"core_bi_pll_test_se",
};
+static const struct parent_map gcc_parent_map_16[] = {
+ { P_XO, 0 },
+ { P_GPLL0_OUT_MAIN, 1 },
+ { P_GPLL0_OUT_AUX, 2 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_16[] = {
+ "cxo",
+ "gpll0_out_main",
+ "gpll0_out_aux",
+ "core_bi_pll_test_se",
+};
+
static struct clk_fixed_factor cxo = {
.mult = 1,
.div = 1,
@@ -1194,6 +1208,28 @@ static struct clk_rcg2 vsync_clk_src = {
},
};
+static const struct freq_tbl ftbl_cdsp_bimc_clk_src[] = {
+ F(1920, P_XO, 1, 0, 0),
+ F(1, P_GPLL0_OUT_MAIN, 6, 0, 0),
+ F(26667, P_GPLL0_OUT_MAIN, 3, 0, 0),
+ F(32000, P_GPLL0_OUT_MAIN, 2.5, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 cdsp_bimc_clk_src = {
+ .cmd_rcgr = 0x5e010,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = gcc_parent_map_16,
+ .freq_tbl = ftbl_cdsp_bimc_clk_src,
+ .clkr.hw.init = &(struct clk_init_data) {
+ .name = "cdsp_bimc_clk_src",
+ .parent_names = gcc_parent_names_16,
+ .num_parents = 4,
+ .ops = _rcg2_ops,
+ },
+};
+
static struct clk_branch gcc_apss_ahb_clk = {
.halt_reg = 0x4601c,
.halt_check = BRANCH_HALT_VOTED,
@@ -1255,6 +1291,24 @@ static struct clk_branch gcc_bimc_gpu_clk = {
},
};
+static struct clk_branch gcc_bimc_cdsp_clk = {
+ .halt_reg = 0x31030,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x31030,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data) {
+ .name = "gcc_bimc_cdsp_clk",
+ .parent_names = (const char *[]) {
+ "cdsp_bimc_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = _branch2_ops,
+ },
+ },
+};
+
static struct clk_branch gcc_bimc_mdss_clk = {
.halt_reg = 0x31038,
.halt_check = BRANCH_HALT,
@@ -1792,6 +1846,24 @@ static struct clk_branch gcc_gfx_tbu_clk = {
},
};
+static struct clk_branch gcc_cdsp_tbu_clk = {
+ .halt_reg = 0x1203c,
+ .halt_check = BRANCH_VOTED,
+ .clkr = {
+ .enable_reg = 0x13020,
+ .enable_mask = BIT(9),
+ .hw.init = &(struct clk_init_data) {
+ .name = "gcc_cdsp_tbu_clk",
+ .parent_names = (const char *[]) {
+ "cdsp_bimc_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = _branch2_ops,
+ },
+ },
+};
+
static struct clk_branch gcc_gp1_clk = {
.halt_reg = 0x8000,
.halt_check = BRANCH_HALT,
@@ -2304,6 +2376,19 @@ static struct clk_branch gcc_sdcc1_ice_core_clk = {
},
};
+static struct clk_branch gcc_cdsp_cfg_ahb_clk = {
+ .halt_reg = 0x5e004,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x5e004,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data) {
+ .name = "gcc_cdsp_cfg_ahb_cbcr",
+ .ops = _branch2_ops,
+ },
+ },
+};
+
static struct clk_branch gcc_sdcc2_ahb_clk = {
.halt_reg = 0x4301c,
.halt_check = BRANCH_HALT,
@@ -2548,6 +2633,7 @@ static struct clk_regmap *gcc_qcs404_clocks[] = {
[GCC_ESC0_CLK_SRC] = _clk_src.clkr,
[GCC_APSS_AHB_CLK] = _apss_ahb_clk.clkr,
[GCC_BIMC_GFX_CLK] = _bimc_gfx_clk.clkr,
+ [GCC_BIMC_CDSP_CLK] = _bimc_cdsp_clk.clkr,
[GCC_BIMC_MDSS_CLK] = _bimc_mdss_clk.clkr,
[GCC_BLSP1_AHB_CLK] = _blsp1_ahb_clk.clkr,
[GCC_BLSP1_QUP0_I2C_APPS_CLK] = _blsp1_qup0_i2c_apps_clk.clkr,
@@ -2605,6 +2691,7 @@ static struct clk_regmap *gcc_qcs404_clocks[] = {
[GCC_SDCC1_AHB_CLK] = _sdcc1_ahb_clk.clkr,
[GCC_SDCC1_APPS_CLK] = _sdcc1_apps_clk.clkr,
[GCC_SDCC1_ICE_CORE_CLK] = _sdcc1_ice_core_clk.clkr,
+ [GCC_CDSP_CFG_AHB_CLK] = _cdsp_cfg_ahb_clk.clkr,
[GCC_SDCC2_AHB_CLK] = _sdcc2_ahb_clk.clkr,
[GCC_SDCC2_APPS_CLK] = _sdcc2_apps_clk.clkr,
Re: [PATCH] Bluetooth: hci_qca: Remove redundant initializations to zero
On 2019-03-06 02:34, Matthias Kaehlcke wrote: The qca_data structure is allocated with kzalloc() and hence zero-initialized. Remove a bunch of unnecessary explicit initializations of struct members to zero. Signed-off-by: Matthias Kaehlcke --- drivers/bluetooth/hci_qca.c | 19 --- 1 file changed, 19 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 237aea34b69f1..8dccbb934e384 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -480,26 +480,7 @@ static int qca_open(struct hci_uart *hu) qca->tx_ibs_state = HCI_IBS_TX_ASLEEP; qca->rx_ibs_state = HCI_IBS_RX_ASLEEP; - /* clocks actually on, but we start votes off */ - qca->tx_vote = false; - qca->rx_vote = false; - qca->flags = 0; - - qca->ibs_sent_wacks = 0; - qca->ibs_sent_slps = 0; - qca->ibs_sent_wakes = 0; - qca->ibs_recv_wacks = 0; - qca->ibs_recv_slps = 0; - qca->ibs_recv_wakes = 0; qca->vote_last_jif = jiffies; - qca->vote_on_ms = 0; - qca->vote_off_ms = 0; - qca->votes_on = 0; - qca->votes_off = 0; - qca->tx_votes_on = 0; - qca->tx_votes_off = 0; - qca->rx_votes_on = 0; - qca->rx_votes_off = 0; hu->priv = qca; Reviewed-by: Balakrishna Godavarthi -- Regards Balakrishna.
RE: [RFC net-next 0/8] Introducing subdev bus and devlink extension
Hi Kirti, > -Original Message- > From: Kirti Wankhede > Sent: Tuesday, March 5, 2019 9:51 PM > To: Parav Pandit ; Jakub Kicinski > > Cc: Or Gerlitz ; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; michal.l...@markovi.net; da...@davemloft.net; > gre...@linuxfoundation.org; Jiri Pirko > Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension > > > > On 3/6/2019 6:14 AM, Parav Pandit wrote: > > Hi Greg, Kirti, > > > >> -Original Message- > >> From: Parav Pandit > >> Sent: Tuesday, March 5, 2019 5:45 PM > >> To: Parav Pandit ; Kirti Wankhede > >> ; Jakub Kicinski > > >> Cc: Or Gerlitz ; net...@vger.kernel.org; linux- > >> ker...@vger.kernel.org; michal.l...@markovi.net; > da...@davemloft.net; > >> gre...@linuxfoundation.org; Jiri Pirko > >> Subject: RE: [RFC net-next 0/8] Introducing subdev bus and devlink > >> extension > >> > >> > >> > >>> -Original Message- > >>> From: linux-kernel-ow...@vger.kernel.org >>> ow...@vger.kernel.org> On Behalf Of Parav Pandit > >>> Sent: Tuesday, March 5, 2019 5:17 PM > >>> To: Kirti Wankhede ; Jakub Kicinski > >>> > >>> Cc: Or Gerlitz ; net...@vger.kernel.org; > >>> linux- ker...@vger.kernel.org; michal.l...@markovi.net; > >>> da...@davemloft.net; gre...@linuxfoundation.org; Jiri Pirko > >>> > >>> Subject: RE: [RFC net-next 0/8] Introducing subdev bus and devlink > >>> extension > >>> > >>> Hi Kirti, > >>> > -Original Message- > From: Kirti Wankhede > Sent: Tuesday, March 5, 2019 4:40 PM > To: Parav Pandit ; Jakub Kicinski > > Cc: Or Gerlitz ; net...@vger.kernel.org; > linux- ker...@vger.kernel.org; michal.l...@markovi.net; > da...@davemloft.net; gre...@linuxfoundation.org; Jiri Pirko > > Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink > extension > > > > > I am novice at mdev level too. mdev or vfio mdev. > > Currently by default we bind to same vendor driver, but when it > > was > created as passthrough device, vendor driver won't create netdevice > or rdma device for it. > > And vfio/mdev or whatever mature available driver would bind at > > that > point. > > > > Using mdev framework, if you want to partition a physical device > into multiple logic devices, you can bind those devices to same > vendor driver through vfio-mdev, where as if you want to > passthrough the device bind it to vfio-pci. If I understand > correctly, that is what you are > >>> looking for. > > > >>> We cannot bind a whole PCI device to vfio-pci, reason is, A given > >>> PCI device has existing protocol devices on it such as netdevs and rdma > dev. > >>> This device is partitioned while those protocol devices exist and > >>> mlx5_core, mlx5_ib drivers are loaded on it. > >>> And we also need to connect these objects rightly to eswitch exposed > >>> by devlink interface (net/core/devlink.c) that supports eswitch > >>> binding, health, registers, parameters, ports support. > >>> It also supports existing PCI VFs. > >>> > >>> I don’t think we want to replicate all of this again in mdev subsystem > >>> [1]. > >>> > >>> [1] > >>> https://www.kernel.org/doc/Documentation/vfio-mediated-device.txt > >>> > >>> So devlink interface to migrate users from managing VFs to non_VF > >>> sub device is natural progression. > >>> > >>> However, in future, I believe we would be creating mediated devices > >>> on user request, to use mdev modules and map them to VM. > >>> > >>> Also 'mdev_bus' is created as a class and not as a bus. This limits > >>> to not use devlink interface whose handle is bus+device name. > >>> > >>> So one option is to change mdev from class to bus. > >>> devlink will create mdevs on the bus, mdev driver can probe these > >>> devices on host system by default. > >>> And if told to do passthrough, a different driver exposes them to VM. > >>> How feasible is this? > >>> > >> Wait, I do see a mdev bus and mdevs are created on this bus using > >> mdev_device_create(). > >> So how about we create mdevs on this bus using devlink, instead of sysfs? > >> And driver side on host gets the mdev_register_driver()->probe()? > >> > > > > Thinking more and reviewing more mdev code, I believe mdev fits this > > need a lot better than new subdev bus, mfd, platform device, or devlink > subport. > > For coming future, to map this sub device (mdev) to VM will also be easier > by using mdev bus. > > > > Thanks for taking close look at mdev code. > > Assigning mdev to VM support is already in place, QEMU and libvirt have > support to assign mdev device to VM. > > > I also believe we can use the sysfs interface for mdev life cycle. > > Here when mdev are created it will register as devlink instance and > > will be able to query/config parameters before driver probe the device. > > (instead of having life cycle via devlink) > > > > Few enhancements would be needed for mdev
RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal binding
Ping... Hi, Eduardo Looks like we are going around in circle, can we make decision of which direction to go? Best Regards! Anson Huang > -Original Message- > From: Anson Huang > Sent: 2019年3月1日 9:41 > To: 'Rob Herring' ; edubez...@gmail.com > Cc: mark.rutl...@arm.com; shawn...@kernel.org; > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com; > catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com; > edubez...@gmail.com; daniel.lezc...@linaro.org; Aisheng Dong > ; ulf.hans...@linaro.org; sb...@kernel.org; > Daniel Baluta ; Andy Gross > ; horms+rene...@verge.net.au; he...@sntech.de; > a...@arndb.de; maxime.rip...@bootlin.com; bjorn.anders...@linaro.org; > ja...@amarulasolutions.com; enric.balle...@collabora.com; > marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > p...@vger.kernel.org; dl-linux-imx > Subject: RE: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal binding > > Hi, Rob/Eduardo > > Best Regards! > Anson Huang > > > -Original Message- > > From: Rob Herring [mailto:r...@kernel.org] > > Sent: 2019年2月28日 22:49 > > To: Anson Huang > > Cc: mark.rutl...@arm.com; shawn...@kernel.org; > s.ha...@pengutronix.de; > > ker...@pengutronix.de; feste...@gmail.com; catalin.mari...@arm.com; > > will.dea...@arm.com; rui.zh...@intel.com; edubez...@gmail.com; > > daniel.lezc...@linaro.org; Aisheng Dong ; > > ulf.hans...@linaro.org; sb...@kernel.org; Daniel Baluta > > ; Andy Gross ; > > horms+rene...@verge.net.au; he...@sntech.de; a...@arndb.de; > > maxime.rip...@bootlin.com; bjorn.anders...@linaro.org; > > ja...@amarulasolutions.com; enric.balle...@collabora.com; > > marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org; > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > linux- p...@vger.kernel.org; dl-linux-imx > > Subject: Re: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal > > binding > > > > On Wed, Feb 27, 2019 at 6:48 PM Anson Huang > > wrote: > > > > > > Hi, Rob > > > > > > Best Regards! > > > Anson Huang > > > > > > > -Original Message- > > > > From: Rob Herring [mailto:r...@kernel.org] > > > > Sent: 2019年2月28日 7:55 > > > > To: Anson Huang > > > > Cc: mark.rutl...@arm.com; shawn...@kernel.org; > > > > s.ha...@pengutronix.de; ker...@pengutronix.de; > feste...@gmail.com; > > > > catalin.mari...@arm.com; will.dea...@arm.com; > rui.zh...@intel.com; > > > > edubez...@gmail.com; daniel.lezc...@linaro.org; Aisheng Dong > > > > ; ulf.hans...@linaro.org; sb...@kernel.org; > > > > Daniel Baluta ; Andy Gross > > > > ; horms+rene...@verge.net.au; > > > > he...@sntech.de; a...@arndb.de; maxime.rip...@bootlin.com; > > > > bjorn.anders...@linaro.org; ja...@amarulasolutions.com; > > > > enric.balle...@collabora.com; marc.w.gonza...@free.fr; > > > > o...@lixom.net; devicet...@vger.kernel.org; > > > > linux-kernel@vger.kernel.org; > > > > linux-arm-ker...@lists.infradead.org; > > > > linux- p...@vger.kernel.org; dl-linux-imx > > > > Subject: Re: [PATCH V10 1/4] dt-bindings: fsl: scu: add thermal > > > > binding > > > > > > > > On Wed, Feb 27, 2019 at 08:46:21AM +, Anson Huang wrote: > > > > > 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 thermal sensors etc. management, Linux kernel > > > > > has to communicate with system controller via MU (message unit) > > > > > IPC to get temperature from thermal sensors, this patch adds > > > > > binding doc for i.MX system controller thermal driver. > > > > > > > > > > Signed-off-by: Anson Huang > > > > > --- > > > > > Changes since V9: > > > > > - change #thermal-sensor-cells value in example to 1, since > > > > > there are > > > > other > > > > > thermal sensors inside system controller, it is just > > > > > because there are > > > > still > > > > > some issue, so system controller does NOT expose them for > > > > > now, > > > > they could > > > > > be exposed later, so it should be 1 from HW perspective. > > > > > --- > > > > > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 21 > > > > + > > > > > 1 file changed, 21 insertions(+) > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > > > > > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > > > > > index 72d481c..855270b 100644 > > > > > --- > > > > > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > > > > > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.tx > > > > > +++ t > > > > > @@ -122,6 +122,21 @@ RTC bindings based on SCU Message > Protocol > > > > > Required properties: > > > > > - compatible: should be "fsl,imx8qxp-sc-rtc"; > > > > > > > > > > +Thermal bindings based on SCU Message Protocol > > > > >
RE: [PATCH] EDAC, dmc520:: add DMC520 EDAC driver
Hi James, > On Tuesday, February 5, 2019 9:31 AM, James Morse wrote: >> We have firmware to config the memory controller and want to have an EDAC >> driver to report ECC status. >> Could you please elaborate a bit on the security concern on this >> approach? Like some malicious app/driver can access memory controller >> registers can cause issue? > I'm remembering this: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-arm-kernel%2F9b9c4cd5-4428-c08d-d4a3-7352c6c80583%40arm.com%2Fdata=02%7C01%7Cruizhao%40microsoft.com%7C02f5b12bbf01452f9d1208d68b8fc748%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636849846981772601sdata=DhwIPDGAucHiVN%2Byfa10yHDZz5zZwi5OlyrKHE4KUNQ%3Dreserved=0 > Robin Murphy wrote: > | [ For anyone interested, it puts the DRAM controller into sleep mode. > | The kernel can't even panic if all the memory suddenly disappears :D ] > This would be a problem if you need your Secure-world software needs to keep > working, and depends on the memory behind this controller. > It might be that your secure-world software only uses some other memory, in > which case this wouldn't matter. > It may be linux _is_ your secure-world software, in which case it wouldn't > matter either. We had internal discussion with our security team and in our product we do trust Linux. I'll send an updated patch to move platform specific settings like interrupt config to DT and include DT bindings doc for this driver. Thanks, Rui
Re: [PATCH V3] parport_serial.c change for fix hanging problem.
On Tue, Feb 19, 2019 at 9:23 AM saumah wrote:
>
> parport_serial.c change for fix hanging problem while suspend machine.
> parport_seria.c support the same vendor id and device id definition as sunix
> multi-I/O card driver, when the sunix multi-io borad driver is
> installed,there are two drivers to support the same sunix multi-io card,it
> will cause operation error.
>
Please use checkpatch to check your patch.
> Signed-off-by: saumah
> ---
> parport_serial.c | 180 +--
> 1 file changed, 1 insertion(+), 179 deletions(-)
>
> diff --git a/parport_serial.c b/parport_serial.c
> index ae9e01e..f54d1d3 100644
> --- a/parport_serial.c
> +++ b/parport_serial.c
This doesnot apply. git is showing error:
error: parport_serial.c: No such file or directory
> @@ -38,29 +38,10 @@ enum parport_pc_pci_cards {
> siig_2p1s_20x,
>
> /* each element directly indexed from enum list, above */
> @@ -127,29 +108,10 @@ static struct parport_pc_pci cards[] = {
> /* siig_2p1s_20x */ { 2, { { 1, 2 }, { 3, 4 }, } },
> /* siig_1s1p_20x */ { 1, { { 1, 2 }, } },
> /* siig_2s1p_20x */ { 1, { { 2, 3 }, } },
> - /* timedia_4078a */ { 1, { { 2, -1 }, } },
You are removing support for the parallel port of these boards. Can
you please point me to the driver with which it conflicts.
--
Regards
Sudip
Re: [PATCH v3 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks
Hi, On 19. 3. 6. 오전 4:22, Hans de Goede wrote: > Hi, > > On 03-03-19 21:16, Yauhen Kharuzhy wrote: >> At implementation of charging support for Lenovo Yoga Book (Intel Cherry >> Trail based with Whiskey Cove PMIC), two pitfalls were found: >> >> - for detection of charger type by PMIC, bit 6 in the CHGRCTRL1 register >> should be set in 0 (and set to 1 for Host mode). Pick up its definition >> and logic from from Intel code drop[1]; >> >> - "#CHARGE ENABLE" signal of external charger (bq25892) in Yoga Book is >> connected to one of PMIC outputs controlled by CHGDISCTRL register. >> Enable charging at driver initialization. Pick up this from Lenovo's code >> drop[2,3]. >> >> >> v3 changes: >> - Don't restore of initial state of CHGDISCTRL and CHGRCTRL0 at exit but >> switch them into HW-controlled mode (as discussed in mailing list); >> - Use regmap_update_bits() instead of regmap_readi()/regmap_write() in >> the cht_wc_extcon_set_otgmode(); >> - Coding style and constant names changed as Andy and Hans recommended. > > Series looks good to me now, and I've also tested that it does not > cause any charging or 5v boost related regressions on a GPD pocket > laptop, so for the series: > > Reviewed-by: Hans de Goede > Tested-by: Hans de Goede > > Regards, > > Hans > Applied it. Thanks. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH -next & mmotm] extcon: fix EXTCON_PTP5150 kconfig warnings and build errors
Hi, Applied it for v5.1-rc2. I'll send the pull request it for v5.1-rc2. Best Regards, Chanwoo Choi On 19. 2. 26. 오전 9:17, Randy Dunlap wrote: > From: Randy Dunlap > > Having COMPILE_TEST here is causing problems. I reported one > last week and have another one today. Although I support > using COMPILE_TEST when possible, this one is better removed. > > Fixes these warnings and build errors: > > WARNING: unmet direct dependencies detected for REGMAP_I2C > Depends on [m]: I2C [=m] > Selected by [y]: > - EXTCON_PTN5150 [=y] && EXTCON [=y] && (I2C [=m] && GPIOLIB [=y] || > COMPILE_TEST [=y]) > Selected by [m]: > - EEPROM_AT24 [=m] && I2C [=m] && SYSFS [=y] > - KEYBOARD_CAP11XX [=m] && !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && OF > [=y] && I2C [=m] > - I2C_MUX_LTC4306 [=m] && I2C [=m] && I2C_MUX [=m] > - GPIO_TS4900 [=m] && GPIOLIB [=y] && I2C [=m] && (SOC_IMX6 || COMPILE_TEST > [=y]) > - SENSORS_LTC2945 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_LTC4222 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_MAX6621 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_LM75 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_NCT7802 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_EMC1403 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_ADS7828 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_INA2XX [=m] && HWMON [=y] && I2C [=m] > - SENSORS_INA3221 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_TMP102 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_TMP103 [=m] && HWMON [=y] && I2C [=m] > - MFD_BCM590XX [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_AXP20X_I2C [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_MADERA_I2C [=m] && HAS_IOMEM [=y] && MFD_MADERA [=m] && I2C [=m] > - MFD_DA9062 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_DA9063 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_DA9150 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_MC13XXX_I2C [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_88PM800 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_88PM805 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_MAX14577 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_MAX77686 [=m] && HAS_IOMEM [=y] && I2C [=m] && (OF [=y] || > COMPILE_TEST [=y]) > - MFD_MAX8907 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_RT5033 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_RN5T618 [=m] && HAS_IOMEM [=y] && I2C [=m] && OF [=y] > - MFD_SI476X_CORE [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_SKY81452 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_TI_LMU [=m] && HAS_IOMEM [=y] && I2C [=m] > - TPS6105X [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_TPS65086 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_TPS65217 [=m] && HAS_IOMEM [=y] && I2C [=m] && OF [=y] > - MFD_TI_LP873X [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_TPS65218 [=m] && HAS_IOMEM [=y] && I2C [=m] && OF [=y] > - MFD_TPS65912_I2C [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_LM3533 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_WM8994 [=m] && HAS_IOMEM [=y] && I2C [=m] > - REGULATOR_88PG86X [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_DA9211 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_FAN53555 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_LTC3676 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_MAX8649 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_MT6311 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_PFUZE100 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_PV88060 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_PV88080 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_SY8106A [=m] && REGULATOR [=y] && I2C [=m] && (OF [=y] || > COMPILE_TEST [=y]) > - REGULATOR_TPS62360 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_TPS65023 [=m] && REGULATOR [=y] && I2C [=m] > - DRM_ANALOGIX_ANX78XX [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] > - DRM_TOSHIBA_TC358767 [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE > [=y] && OF [=y] > - DRM_TI_SN65DSI86 [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && > OF [=y] > - DRM_I2C_ADV7511 [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && > OF [=y] > - BACKLIGHT_LM3630A [=m] && HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=y] && > BACKLIGHT_CLASS_DEVICE [=m] && I2C [=m] && PWM [=y] > - BACKLIGHT_LM3639 [=m] && HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=y] && > BACKLIGHT_CLASS_DEVICE [=m] && I2C [=m] > - LEDS_LM3642 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=m] > - LEDS_LP8860 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=m] && OF > [=y] > - LEDS_TLC591XX [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=m] > - LEDS_LM355x [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=m] > - LEDS_IS31FL319X [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=m] && > OF [=y] > - EXTCON_RT8973A [=m] && EXTCON [=y] && I2C [=m] > - ADXL345_I2C [=m] && IIO [=y] && INPUT_ADXL34X [=n]=n && I2C [=m] > - BMC150_ACCEL_I2C [=m] && IIO [=y] > - MMA7455_I2C [=m] && IIO [=y] && I2C [=m] > - MXC4005 [=m] && IIO [=y] && I2C [=m] > - MXC6255 [=m] && IIO [=y] && I2C [=m] > - TI_ADS1015
Re: DMCA takedown notice
The fact that you even spend this much time on trying to take back your gift to the community instead of just accepting your responsibility for your own actions is impressive. And unless you sign with your legal name and your copyright notices uses your legal name as well as details of your location then your claims have no effect at all because it is literally impossible to even speculate that you are the copyright holder - let alone proving it beyond any reasonable doubt that it is the case. So if you are serious about this and not just simulating a possible angle of attack on the GPL that somebody else could take to illustrate a possible weakness in the GPL, then stop hiding behind anonymity and file an actual real claim with a court. Should your effort succeed then it is a problem with the law and not with the license. A license that grants certain rights to a copy of a work provided that certain conditions outlined in the license are met should never be revocable from THAT particular copy of the work, unless the terms of the license itself are broken. Having the possibility to arbitrarily revoke rights granted by a license for any other reason than conditions that the licensee was aware of when they accepted the license would have tremendous negative consequences and disruptions to many areas of the society. If the law has a loophole like that then the best thing that we all can do is ensure that it doesn't have it anymore in the near future. On Tue, Feb 12, 2019 at 12:10 AM wrote: > > You take it down or I sue you, simple as that. > > I have revoked the license from a number of people, including the John > Doe who has chosen to violate my copyright thence-forth. > > I have signed using my 2 decades long held pen-name. > > The U.S. Code defines an electronic signature for the purpose of US law > as "an electronic sound, symbol, or process, attached to or logically > associated with a contract or other record and executed or adopted by a > person with the intent to sign the record." > > My signing with my pen-name suffices for this purpose. What is important > is my intent to sign the record, which I have evinced. > > I have also posted the information on my long-held project page, so that > you may know that I am me: > https://sourceforge.net/projects/gpcslots2/files/notes/ > > https://sourceforge.net/projects/gpcslots2/files/notes/tkdnreq_github.txt/download > https://sourceforge.net/projects/gpcslots2/files/notes/takedownreq_vs_johndoe-of-8ch.txt/download > > (I have also uploaded this response to said /notes/ directory) > > In addition to many other places. > Your contention that I must do anything greater at this point is legally > inefficacious. > > I _DEMAND_ that you take the offending material down immediately. > > --MikeeUSA-- > (Author of GPC-Slots 2) > (electronic signature) > > On 2019-02-06 21:20, GitHub Staff wrote: > > Hi MikeeUSA, > > > > Thank you for your notices, the most recent of which is included below > > for reference. > > > > This DMCA notice is incomplete. It lacks "A physical or electronic > > signature of a person authorized to act on behalf of the owner of an > > exclusive right that is allegedly infringed" and "Information > > reasonably sufficient to permit the service provider to contact the > > complaining party." > > > > Unfortunately, an electronic signature must be a legal name, not a > > monicker or username, and we cannot accept disposable or temporary > > email addresses as reliable contact information for a DMCA notice. > > > > Once you've revised your notice to include the required details, > > please send back the entire revised notice, and not only the corrected > > sections. Once we've received a complete and actionable notice, we'll > > process it expeditiously. > > > > Thanks, > > > > GitHub Staff > > - > > > > I have a good faith belief that use of the copyrighted materials > > described above on the infringing web pages is not authorized by the > > copyright owner, or its agent, or the law. I have taken fair use into > > consideration. > > > > I swear, under penalty of perjury, that the information in this > > notification is accurate and that I am the copyright owner, or am > > authorized to act on behalf of the owner, of an exclusive right that > > is allegedly infringed. > > : > > > > As you may know, In the United States; a license, absent an attached > > interest, is revocable. > > > > A "John Doe" had his non-exclusive license regarding the game > > "GPC-Slots2" terminated by the copyright owner (me: MikeeUSA). > > The copyright owner may do this as-of-right, unless there is an > > attached interest (ie: unless the licensee paid good consideration for > > the license). > > > > The "John Doe" then proceeded to belligerently upload a copy of > > "GPC-Slots2" to your host, GitHub. > > This violated Author's (my) copyright, since "John Doe"'s gratuitous > > bare license had been terminated by the copyright holder (me). > > >
Re: [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem
On Tue, Mar 5, 2019 at 2:16 PM Andrew Morton wrote: > > On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams > wrote: > > > > > > > > Another way to help allay these worries is commit to no new exports > > > > without in-tree users. In general, that should go without saying for > > > > any core changes for new or future hardware. > > > > > > I always intend to have an upstream user the issue is that the device > > > driver tree and the mm tree move a different pace and there is always > > > a chicken and egg problem. I do not think Andrew wants to have to > > > merge driver patches through its tree, nor Linus want to have to merge > > > drivers and mm trees in specific order. So it is easier to introduce > > > mm change in one release and driver change in the next. This is what > > > i am doing with ODP. Adding things necessary in 5.1 and working with > > > Mellanox to have the ODP HMM patch fully tested and ready to go in > > > 5.2 (the patch is available today and Mellanox have begin testing it > > > AFAIK). So this is the guideline i will be following. Post mm bits > > > with driver patches, push to merge mm bits one release and have the > > > driver bits in the next. I do hope this sound fine to everyone. > > > > The track record to date has not been "merge HMM patch in one release > > and merge the driver updates the next". If that is the plan going > > forward that's great, and I do appreciate that this set came with > > driver changes, and maintain hope the existing exports don't go > > user-less for too much longer. > > Decision time. Jerome, how are things looking for getting these driver > changes merged in the next cycle? > > Dan, what's your overall take on this series for a 5.1-rc1 merge? My hesitation would be drastically reduced if there was a plan to avoid dangling unconsumed symbols and functionality. Specifically one or more of the following suggestions: * EXPORT_SYMBOL_GPL on all exports to avoid a growing liability surface for out-of-tree consumers to come grumble at us when we continue to refactor the kernel as we are wont to do. * A commitment to consume newly exported symbols in the same merge window, or the following merge window. When that goal is missed revert the functionality until such time that it can be consumed, or otherwise abandoned. * No new symbol exports and functionality while existing symbols go unconsumed. These are the minimum requirements I would expect my work, or any core-mm work for that matter, to be held to, I see no reason why HMM could not meet the same. On this specific patch I would ask that the changelog incorporate the motivation that was teased out of our follow-on discussion, not "There is no reason not to support that case." which isn't a justification.
Re: [PATCH v5 4/8] dt-bindings: devfreq: add Exynos5422 DMC device description
Hi Lukasz,
On 19. 3. 5. 오후 7:19, Lukasz Luba wrote:
> The patch adds description for DT binding for a new Exynos5422 Dynamic
> Memory Controller device.
>
> Signed-off-by: Lukasz Luba
> ---
> .../devicetree/bindings/devfreq/exynos5422-dmc.txt | 177
> +
> 1 file changed, 177 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
> b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
> new file mode 100644
> index 000..0e73e98
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
> @@ -0,0 +1,177 @@
> +* Exynos5422 frequency and voltage scaling for Dynamic Memory Controller
> device
> +
> +The Samsung Exynos5422 SoC has DMC (Dynamic Memory Controller) to which the
> DRAM
> +memory chips are connected. The driver is to monitor the controller in
> runtime
> +and switch frequency and voltage. To monitor the usage of the controller in
> +runtime, the driver uses the PPMU (Platform Performance Monitoring Unit),
> which
> +is able to measure the current load of the memory.
> +When 'userspace' governor is used for the driver, an application is able to
> +switch the DMC frequency.
> +
> +Required properties for DMC device for Exynos5422:
> +- compatible: Should be "samsung,exynos5422-bus".
> +- clock-names : the name of clock used by the bus, "bus".
> +- clocks : phandles for clock specified in "clock-names" property.
> +- devfreq-events : phandles for PPMU devices connected to this DMC.
I already replied with following comments on v4 patch[1].
But, you didn't reply anything. We can reduce the duplicate
review by keeping the basic review rule.
- Re: [PATCH v4 5/8] dt-bindings: devfreq: add Exynos5422 DMC device description
[1] https://do-db2.lkml.org/lkml/2019/2/3/64
[Following comments were replied on v4 patch[1]]
> +- compatible: Should be "samsung,exynos5422-bus".
The compatible name is wrong.
- exynos5422-bus -> exynos5422-dmc
> +- clock-names : the name of clock used by the bus, "bus".
'bus' is right?
> +- clocks : phandles for clock specified in "clock-names" property.
> +- devfreq-events : phandles for PPMU devices connected to this DMC.
The dt-binging file doesn't contain the any description for 'reg' properties.
> +
> +The example definition of a DMC and PPMU devices declared in DT is shown
> below:
> +
> + ppmu_dmc0_0: ppmu@10d0 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10d0 0x2000>;
> + clocks = < CLK_PCLK_PPMU_DREX0_0>;
> + clock-names = "ppmu";
> + status = "okay";
> + events {
> + ppmu_event_dmc0_0: ppmu-event3-dmc0_0 {
> + event-name = "ppmu-event3-dmc0_0";
> + };
> + };
> + };
> +
> +
> + ppmu_dmc0_1: ppmu@10d1 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10d1 0x2000>;
> + clocks = < CLK_PCLK_PPMU_DREX0_1>;
> + clock-names = "ppmu";
> + status = "okay";
> + events {
> + ppmu_event_dmc0_1: ppmu-event3-dmc0_1 {
> + event-name = "ppmu-event3-dmc0_1";
> + };
> + };
> + };
> +
> + ppmu_dmc1_0: ppmu@10d1 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10d6 0x2000>;
> + clocks = < CLK_PCLK_PPMU_DREX1_0>;
> + clock-names = "ppmu";
> + status = "okay";
> + events {
> + ppmu_event_dmc1_0: ppmu-event3-dmc1_0 {
> + event-name = "ppmu-event3-dmc1_0";
> + };
> + };
> + };
> +
> + ppmu_dmc1_1: ppmu@10d7 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10d7 0x2000>;
> + clocks = < CLK_PCLK_PPMU_DREX1_1>;
> + clock-names = "ppmu";
> + status = "okay";
> + events {
> + ppmu_event_dmc1_1: ppmu-event3-dmc1_1 {
> + event-name = "ppmu-event3-dmc1_1";
> + };
> + };
> + };
> +
> + dmc: memory-controller@10c2 {
> + compatible = "samsung,exynos5422-dmc";
> + reg = <0x10c2 0x1>, <0x10c3 0x1>,
> + <0x1000 0x1000>;
> + clocks =< CLK_FOUT_SPLL>,
> + < CLK_MOUT_SCLK_SPLL>,
> + < CLK_FF_DOUT_SPLL2>,
> + < CLK_FOUT_BPLL>,
> + < CLK_MOUT_BPLL>,
> + < CLK_SCLK_BPLL>,
> + < CLK_MOUT_MX_MSPLL_CCORE>,
> + < CLK_MOUT_MX_MSPLL_CCORE_PHY>,
> +
Wir haben Sie als einen von fünf glücklichen Gewinnern ausgewählt, die eine Spende in Höhe von 4.800.000,00 Euro erhalten haben.
Ich bin Neil Trotter, ein 41-jhriger Mechaniker aus London, und ich mchte Sie wissen lassen, dass Sie mit Euromillionen 4,8 Millionen Pfund im Wert von 108 Millionen Euro verdient haben. Ihre E-Mail-Adresse lautet: Senden Sie das beste Webverzeichnis und die legale Suchmaschine. Sie haben diese E-Mail erhalten, weil wir Sie als einen unserer drei glcklichen Empfnger aufgefhrt haben, die dieses Geschenk erhalten haben. Wir empfehlen Ihnen, mit dieser Nachricht auf Ihre private E-Mail-Adresse zu antworten und weitere Informationen zu Ihrer Zahlung zu erhalten. in Hhe von 4.800.000,00 EUR. E-Mail [neiltra...@gmail.com], um den Spendenbetrag sofort in Hhe von EUR 4.800.000,00 zu zahlen, wenn der Betrag auf Ihrem Bankkonto eingezahlt ist.
Re: [PATCH v2 1/6] clk: Remove recursion in clk_core_{prepare,enable}()
On Tue, Mar 5, 2019 at 5:35 PM dbasehore . wrote: > > On Tue, Mar 5, 2019 at 10:49 AM Stephen Boyd wrote: > > > > Quoting Derek Basehore (2019-03-04 20:49:31) > > > From: Stephen Boyd > > > > > > Enabling and preparing clocks can be written quite naturally with > > > recursion. We start at some point in the tree and recurse up the > > > tree to find the oldest parent clk that needs to be enabled or > > > prepared. Then we enable/prepare and return to the caller, going > > > back to the clk we started at and enabling/preparing along the > > > way. This also unroll the recursion in unprepare,disable which can > > > just be done in the order of walking up the clk tree. > > > > > > The problem is recursion isn't great for kernel code where we > > > have a limited stack size. Furthermore, we may be calling this > > > code inside clk_set_rate() which also has recursion in it, so > > > we're really not looking good if we encounter a tall clk tree. > > > > > > Let's create a stack instead by looping over the parent chain and > > > collecting clks of interest. Then the enable/prepare becomes as > > > simple as iterating over that list and calling enable. > > > > > > Modified verison of https://lore.kernel.org/patchwork/patch/814369/ > > > -Fixed kernel warning > > > -unrolled recursion in unprepare/disable too > > > > > > Cc: Jerome Brunet > > > Signed-off-by: Stephen Boyd > > > Signed-off-by: Derek Basehore > > > --- > > > > From the original post: > > > > "I have some vague fear that this may not work if a clk op is framework > > reentrant and attemps to call consumer clk APIs from within the clk ops. > > If the reentrant call tries to add a clk that's already in the list then > > we'll corrupt the list. Ugh." > > > > Do we have this sort of problem here? Or are you certain that we don't > > have clks that prepare or enable something that is already in the > > process of being prepared or enabled? > > I can look into whether anything's doing this and add a WARN_ON which > returns an error if we ever hit that case. If this is happening on > some platform, we'd want to correct that anyways. > Also, if we're ever able to move to another locking scheme (hopefully soon...), we can make the prepare/enable locks non-reentrant. Then if anyone recursively calls back into the framework for another prepare/enable, they will deadlock. I guess that's one way of making sure no one does that. > >
[PATCH] vxlan: do not need BH again in vxlan_cleanup()
vxlan_cleanup() is a timer callback, it is already
and only running in BH context.
Signed-off-by: Litao Jiao
---
drivers/net/vxlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 2aae11f..98dde11 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2616,7 +2616,7 @@ static void vxlan_cleanup(struct timer_list *t)
for (h = 0; h < FDB_HASH_SIZE; ++h) {
struct hlist_node *p, *n;
- spin_lock_bh(>hash_lock);
+ spin_lock(>hash_lock);
hlist_for_each_safe(p, n, >fdb_head[h]) {
struct vxlan_fdb *f
= container_of(p, struct vxlan_fdb, hlist);
@@ -2638,7 +2638,7 @@ static void vxlan_cleanup(struct timer_list *t)
} else if (time_before(timeout, next_timer))
next_timer = timeout;
}
- spin_unlock_bh(>hash_lock);
+ spin_unlock(>hash_lock);
}
mod_timer(>age_timer, next_timer);
--
1.9.1
[PATCH] OPP: Fix handling of multiple power domains
We seem to rely on the number of phandles specified in the
'required-opps' property to identify cases where a device is
associated with multiple power domains and hence would have
multiple virtual devices that have to be dealt with.
In cases where we do have devices with multiple power domains
but with only one of them being scalable, this logic seems to
fail.
Instead read the number of power domains from DT to identify
such cases.
Signed-off-by: Rajendra Nayak
---
drivers/opp/of.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 06f0f632ec47..443c305ae100 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -172,7 +172,7 @@ static void _opp_table_alloc_required_tables(struct
opp_table *opp_table,
struct opp_table **required_opp_tables;
struct device **genpd_virt_devs = NULL;
struct device_node *required_np, *np;
- int count, i;
+ int count, count_pd, i;
/* Traversing the first OPP node is all we need */
np = of_get_next_available_child(opp_np, NULL);
@@ -185,7 +185,19 @@ static void _opp_table_alloc_required_tables(struct
opp_table *opp_table,
if (!count)
goto put_np;
- if (count > 1) {
+ /*
+* Check the number of power-domains to know if we need to deal
+* with virtual devices. In some cases we have devices with multiple
+* power domains but with only one of them being scalable, hence
+* 'count' could be 1, but we still have to deal with multiple genpds
+* and virtual devices.
+*/
+ count_pd = of_count_phandle_with_args(dev->of_node, "power-domains",
+ "#power-domain-cells");
+ if (!count_pd)
+ goto put_np;
+
+ if (count_pd > 1) {
genpd_virt_devs = kcalloc(count, sizeof(*genpd_virt_devs),
GFP_KERNEL);
if (!genpd_virt_devs)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
WARNING: locking bug in __icmp_send
Hello, syzbot found the following crash on: HEAD commit:d9862cfbe209 Merge tag 'mips_5.1' of git://git.kernel.org/.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=10dfb0e720 kernel config: https://syzkaller.appspot.com/x/.config?x=73d88a42238825ad dashboard link: https://syzkaller.appspot.com/bug?extid=173d67242daa7ce45f85 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=153d692320 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+173d67242daa7ce45...@syzkaller.appspotmail.com Enabling of bearer rejected, already enabled Enabling of bearer rejected, already enabled Enabling of bearer rejected, already enabled [ cut here ] DEBUG_LOCKS_WARN_ON(class_idx > MAX_LOCKDEP_KEYS) WARNING: CPU: 0 PID: 9 at kernel/locking/lockdep.c:3315 __lock_acquire+0x13bf/0x4700 kernel/locking/lockdep.c:3315 Enabling of bearer rejected, already enabled Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.0.0+ #109 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+0x172/0x1f0 lib/dump_stack.c:113 Enabling of bearer rejected, already enabled panic+0x2cb/0x65c kernel/panic.c:214 kobject: 'loop0' (f02900e9): kobject_uevent_env kobject: 'loop0' (f02900e9): fill_kobj_path: path = '/devices/virtual/block/loop0' __warn.cold+0x20/0x45 kernel/panic.c:571 report_bug+0x263/0x2b0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] fixup_bug arch/x86/kernel/traps.c:173 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290 kobject: 'loop2' (763050ef): kobject_uevent_env invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 RIP: 0010:__lock_acquire+0x13bf/0x4700 kernel/locking/lockdep.c:3315 kobject: 'loop2' (763050ef): fill_kobj_path: path = '/devices/virtual/block/loop2' Code: 8b 1d 69 20 06 08 45 85 db 0f 85 d6 f4 ff ff 48 c7 c6 80 a4 6b 87 48 c7 c7 e0 78 6b 87 44 89 9c 24 98 00 00 00 e8 0f 26 ec ff <0f> 0b 44 8b 9c 24 98 00 00 00 e9 af f4 ff ff 8b 3d bc e4 fe 08 85 RSP: 0018:8880aa26f300 EFLAGS: 00010082 RAX: RBX: 66c4c53a RCX: RDX: 0100 RSI: 815a65c6 RDI: ed101544de52 RBP: 8880aa26f4d0 R08: 8880aa25c240 R09: fbfff115 R10: fbfff114 R11: 88a3 R12: 8880aa25cb28 R13: 8880aa25cb32 R14: 66c4c53a R15: 8880aa25c240 Enabling of bearer rejected, already enabled lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841 kobject: 'loop5' (02a93434): kobject_uevent_env kobject: 'loop5' (02a93434): fill_kobj_path: path = '/devices/virtual/block/loop5' __raw_spin_trylock include/linux/spinlock_api_smp.h:90 [inline] _raw_spin_trylock+0x62/0x80 kernel/locking/spinlock.c:128 spin_trylock include/linux/spinlock.h:339 [inline] icmp_xmit_lock net/ipv4/icmp.c:219 [inline] __icmp_send+0x553/0x1400 net/ipv4/icmp.c:666 Enabling of bearer rejected, already enabled kobject: 'loop0' (f02900e9): kobject_uevent_env kobject: 'loop0' (f02900e9): fill_kobj_path: path = '/devices/virtual/block/loop0' kobject: 'loop1' (4f39548c): kobject_uevent_env icmp_send include/net/icmp.h:47 [inline] __udp4_lib_rcv+0x1fb6/0x2c50 net/ipv4/udp.c:2323 kobject: 'loop1' (4f39548c): fill_kobj_path: path = '/devices/virtual/block/loop1' udp_rcv+0x22/0x30 net/ipv4/udp.c:2482 ip_protocol_deliver_rcu+0x60/0x8f0 net/ipv4/ip_input.c:208 ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234 kobject: 'loop2' (763050ef): kobject_uevent_env NF_HOOK include/linux/netfilter.h:289 [inline] NF_HOOK include/linux/netfilter.h:283 [inline] ip_local_deliver+0x1e9/0x520 net/ipv4/ip_input.c:255 kobject: 'loop2' (763050ef): fill_kobj_path: path = '/devices/virtual/block/loop2' dst_input include/net/dst.h:450 [inline] ip_rcv_finish+0x1e1/0x300 net/ipv4/ip_input.c:414 NF_HOOK include/linux/netfilter.h:289 [inline] NF_HOOK include/linux/netfilter.h:283 [inline] ip_rcv+0xe8/0x3f0 net/ipv4/ip_input.c:524 __netif_receive_skb_one_core+0x115/0x1a0 net/core/dev.c:4973 __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083 process_backlog+0x206/0x750 net/core/dev.c:5923 napi_poll net/core/dev.c:6346 [inline] net_rx_action+0x4fa/0x1070 net/core/dev.c:6412 __do_softirq+0x266/0x95a kernel/softirq.c:292 run_ksoftirqd kernel/softirq.c:654 [inline] run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646 smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164 kthread+0x357/0x430 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain
Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension
On 3/6/2019 6:14 AM, Parav Pandit wrote: > Hi Greg, Kirti, > >> -Original Message- >> From: Parav Pandit >> Sent: Tuesday, March 5, 2019 5:45 PM >> To: Parav Pandit ; Kirti Wankhede >> ; Jakub Kicinski >> Cc: Or Gerlitz ; net...@vger.kernel.org; linux- >> ker...@vger.kernel.org; michal.l...@markovi.net; da...@davemloft.net; >> gre...@linuxfoundation.org; Jiri Pirko >> Subject: RE: [RFC net-next 0/8] Introducing subdev bus and devlink extension >> >> >> >>> -Original Message- >>> From: linux-kernel-ow...@vger.kernel.org >> ow...@vger.kernel.org> On Behalf Of Parav Pandit >>> Sent: Tuesday, March 5, 2019 5:17 PM >>> To: Kirti Wankhede ; Jakub Kicinski >>> >>> Cc: Or Gerlitz ; net...@vger.kernel.org; linux- >>> ker...@vger.kernel.org; michal.l...@markovi.net; da...@davemloft.net; >>> gre...@linuxfoundation.org; Jiri Pirko >>> Subject: RE: [RFC net-next 0/8] Introducing subdev bus and devlink >>> extension >>> >>> Hi Kirti, >>> -Original Message- From: Kirti Wankhede Sent: Tuesday, March 5, 2019 4:40 PM To: Parav Pandit ; Jakub Kicinski Cc: Or Gerlitz ; net...@vger.kernel.org; linux- ker...@vger.kernel.org; michal.l...@markovi.net; da...@davemloft.net; gre...@linuxfoundation.org; Jiri Pirko Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension > I am novice at mdev level too. mdev or vfio mdev. > Currently by default we bind to same vendor driver, but when it > was created as passthrough device, vendor driver won't create netdevice or rdma device for it. > And vfio/mdev or whatever mature available driver would bind at > that point. > Using mdev framework, if you want to partition a physical device into multiple logic devices, you can bind those devices to same vendor driver through vfio-mdev, where as if you want to passthrough the device bind it to vfio-pci. If I understand correctly, that is what you are >>> looking for. >>> We cannot bind a whole PCI device to vfio-pci, reason is, A given PCI >>> device has existing protocol devices on it such as netdevs and rdma dev. >>> This device is partitioned while those protocol devices exist and >>> mlx5_core, mlx5_ib drivers are loaded on it. >>> And we also need to connect these objects rightly to eswitch exposed >>> by devlink interface (net/core/devlink.c) that supports eswitch >>> binding, health, registers, parameters, ports support. >>> It also supports existing PCI VFs. >>> >>> I don’t think we want to replicate all of this again in mdev subsystem [1]. >>> >>> [1] https://www.kernel.org/doc/Documentation/vfio-mediated-device.txt >>> >>> So devlink interface to migrate users from managing VFs to non_VF sub >>> device is natural progression. >>> >>> However, in future, I believe we would be creating mediated devices on >>> user request, to use mdev modules and map them to VM. >>> >>> Also 'mdev_bus' is created as a class and not as a bus. This limits to >>> not use devlink interface whose handle is bus+device name. >>> >>> So one option is to change mdev from class to bus. >>> devlink will create mdevs on the bus, mdev driver can probe these >>> devices on host system by default. >>> And if told to do passthrough, a different driver exposes them to VM. >>> How feasible is this? >>> >> Wait, I do see a mdev bus and mdevs are created on this bus using >> mdev_device_create(). >> So how about we create mdevs on this bus using devlink, instead of sysfs? >> And driver side on host gets the mdev_register_driver()->probe()? >> > > Thinking more and reviewing more mdev code, I believe mdev fits > this need a lot better than new subdev bus, mfd, platform device, or devlink > subport. > For coming future, to map this sub device (mdev) to VM will also be easier by > using mdev bus. > Thanks for taking close look at mdev code. Assigning mdev to VM support is already in place, QEMU and libvirt have support to assign mdev device to VM. > I also believe we can use the sysfs interface for mdev life cycle. > Here when mdev are created it will register as devlink instance and > will be able to query/config parameters before driver probe the device. > (instead of having life cycle via devlink) > > Few enhancements would be needed for mdev side. > 1. making iommu optional. Currently mdev devices are not IOMMU aware, vendor driver is responsible for programming IOMMU for mdev device, if required. IOMMU aware mdev device patch set is almost reviewed and ready to get pulled. This is optional, vendor driver have to decide whether mdev device should be associated with its parents IOMMU or not. I'm testing it and I think Alex is on vacation and this will get pulled when Alex will be back from vacation. https://lwn.net/Articles/779650/ > 2. configuring mdev device parameters during creation time > Mdev framework provides a way to define multiple types for creation
Re: device tree binding for poly-phased regulators
On Fri, Feb 22, 2019 at 7:21 PM Torsten Duwe wrote:
>
> Hi!
>
> Documentation/devicetree/bindings/mfd/axp20x.txt nicely describes the
> capabilities of the X-powers PMICs; however, it seems polyphasing is
> left to comments only.
>
> May I suggest to add a property "poly-phased", just to get the discussion
> started? It could be a simple property in the current case for the axp803
> and axp806 ("poly-phased with you-know-which") or a phandle in the future.
These PMICs are customized in a way that the outputs are poly-phased by
default. They are customized to match a specific SoC, and that is about
the only use for them. As such, there's really no way to test whether a
poly-phase property and implementation works or not. If you get it wrong
you risk frying your device.
A poly-phase property in genernal would be nice, however I don't think
this is the right device to start with.
> BTW the axp803 datasheet is quite terse in that respect: is there one
> "master" reulator whose settings are copied or does a driver have to keep
> them in sync.
The datasheet says, when outputs are poly-phased, only the settings of the
first phase applies, i.e. the other settings are ignored, not even copied.
ChenYu
Re: [PATCH 1/2] f2fs: fix to add refcount once page is tagged PG_private
On 03/05, Chao Yu wrote:
> As Gao Xiang reported in bugzilla:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=202749
>
> f2fs may skip pageout() due to incorrect page reference count.
>
> The problem here is that MM defined the rule [1] very clearly that
> once page was set with PG_private flag, we should increment the
> refcount in that page, also main flows like pageout(), migrate_page()
> will assume there is one additional page reference count if
> page_has_private() returns true.
>
> But currently, f2fs won't add/del refcount when changing PG_private
> flag. Anyway, f2fs should follow MM's rule to make MM's related flows
> running as expected.
>
> [1] https://lore.kernel.org/lkml/2b19b3c4-2bc4-15fa-15cc-27a13e5c7...@aol.com/
>
> Reported-by: Gao Xiang
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/checkpoint.c | 11 +--
> fs/f2fs/data.c | 32
> fs/f2fs/dir.c| 6 +-
> fs/f2fs/node.c | 6 +-
> fs/f2fs/segment.c| 23 +--
> 5 files changed, 56 insertions(+), 22 deletions(-)
>
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index c65a1e8e1e95..4e0e93af5ce0 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -406,7 +406,11 @@ static int f2fs_set_meta_page_dirty(struct page *page)
> if (!PageDirty(page)) {
> __set_page_dirty_nobuffers(page);
> inc_page_count(F2FS_P_SB(page), F2FS_DIRTY_META);
> - SetPagePrivate(page);
> +
> + if (!PagePrivate(page)) {
> + get_page(page);
> + SetPagePrivate(page);
Can we add generic functions?
f2fs_set_page_private(page)
{
if (PagePrivate(page))
return;
SetPagePrivate(page);
get_page(page);
}
f2fs_clear_page_private(page)
{
if (!PagePrivate(page))
return;
set_page_private(page, 0);
ClearPagePrivate(page);
f2fs_put_page(page, 0);
}
>
> + }
> f2fs_trace_pid(page);
> return 1;
> }
> @@ -957,7 +961,10 @@ void f2fs_update_dirty_page(struct inode *inode, struct
> page *page)
> inode_inc_dirty_pages(inode);
> spin_unlock(>inode_lock[type]);
>
> - SetPagePrivate(page);
> + if (!PagePrivate(page)) {
> + get_page(page);
> + SetPagePrivate(page);
> + }
> f2fs_trace_pid(page);
> }
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 3f3becd46362..46924d4f69d0 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -2715,8 +2715,11 @@ void f2fs_invalidate_page(struct page *page, unsigned
> int offset,
> if (IS_ATOMIC_WRITTEN_PAGE(page))
> return f2fs_drop_inmem_page(inode, page);
>
> - set_page_private(page, 0);
> - ClearPagePrivate(page);
> + if (PagePrivate(page)) {
> + set_page_private(page, 0);
> + ClearPagePrivate(page);
> + f2fs_put_page(page, 0);
> + }
> }
>
> int f2fs_release_page(struct page *page, gfp_t wait)
> @@ -2730,8 +2733,11 @@ int f2fs_release_page(struct page *page, gfp_t wait)
> return 0;
>
> clear_cold_data(page);
> - set_page_private(page, 0);
> - ClearPagePrivate(page);
> + if (PagePrivate(page)) {
> + set_page_private(page, 0);
> + ClearPagePrivate(page);
> + f2fs_put_page(page, 0);
> + }
> return 1;
> }
>
> @@ -2799,12 +2805,8 @@ int f2fs_migrate_page(struct address_space *mapping,
> return -EAGAIN;
> }
>
> - /*
> - * A reference is expected if PagePrivate set when move mapping,
> - * however F2FS breaks this for maintaining dirty page counts when
> - * truncating pages. So here adjusting the 'extra_count' make it work.
> - */
> - extra_count = (atomic_written ? 1 : 0) - page_has_private(page);
> + /* one extra reference was held for atomic_write page */
> + extra_count = atomic_written ? 1 : 0;
> rc = migrate_page_move_mapping(mapping, newpage,
> page, mode, extra_count);
> if (rc != MIGRATEPAGE_SUCCESS) {
> @@ -2825,9 +2827,15 @@ int f2fs_migrate_page(struct address_space *mapping,
> get_page(newpage);
> }
>
> - if (PagePrivate(page))
> + if (PagePrivate(page)) {
> + get_page(newpage);
> SetPagePrivate(newpage);
> - set_page_private(newpage, page_private(page));
> + set_page_private(newpage, page_private(page));
> +
> + set_page_private(page, 0);
> + ClearPagePrivate(page);
> + f2fs_put_page(page, 0);
> + }
>
> if (mode != MIGRATE_SYNC_NO_COPY)
> migrate_page_copy(newpage, page);
> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> index 103f3686a045..fbbafb04a431 100644
> --- a/fs/f2fs/dir.c
> +++ b/fs/f2fs/dir.c
> @@ -728,7 +728,11 @@ void
Re: [PATCH v3 07/15] ARM: dts: sunxi: h3/h5: Add msgbox node
On 03/01/19 22:29, Samuel Holland wrote:
> The H3 and H5 SoCs contain a message box that can be used to send
> messages and interrupts back and forth between the ARM application CPUs
> and the ARISC coprocessor. Add a device tree node for it.
>
> Signed-off-by: Samuel Holland
> ---
> arch/arm/boot/dts/sunxi-h3-h5.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index a4c757c0b741..a42fd3f9739e 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -227,6 +227,16 @@
> #size-cells = <0>;
> };
>
> + msgbox: mailbox@1c17000 {
> + compatible = "allwinner,sun8i-h3-msgbox",
> + "allwinner,sun6i-a31-msgbox";
> + reg = <0x01c17000 0x1000>;
> + clocks = < CLK_BUS_MSGBOX>;
> + resets = < RST_BUS_MSGBOX>;
> + interrupts = ;
> + #mbox-cells = <2>;
This should be 1. And it was caught by the new DTB schema validation :)
> + };
> +
> usb_otg: usb@1c19000 {
> compatible = "allwinner,sun8i-h3-musb";
> reg = <0x01c19000 0x400>;
>
[PATCH V2 net] net: hns3: add dma_rmb() for rx description
From: Jian Shen
HW can not guarantee complete write desc->rx.size, even though
HNS3_RXD_VLD_B has been set. Driver needs to add dma_rmb()
instruction to make sure desc->rx.size is always valid.
Fixes: e55970950556 ("net: hns3: Add handling of GRO Pkts not fully RX'ed in
NAPI poll")
Signed-off-by: Jian Shen
Signed-off-by: Huazhong Tan
---
V1->V2: fixes comment from David Miller
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 3cb43b1..3b8598a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2472,6 +2472,8 @@ static int hns3_add_frag(struct hns3_enet_ring *ring,
struct hns3_desc *desc,
desc = >desc[ring->next_to_clean];
desc_cb = >desc_cb[ring->next_to_clean];
bd_base_info = le32_to_cpu(desc->rx.bd_base_info);
+ /* make sure HW write desc complete */
+ dma_rmb();
if (!(bd_base_info & BIT(HNS3_RXD_VLD_B)))
return -ENXIO;
--
2.7.4
答复: [PATCH] audit: fix a memleak caused by auditing load module
> -邮件原件- > 发件人: Paul Moore [mailto:p...@paul-moore.com] > 发送时间: 2019年3月5日 22:18 > 收件人: Li,Rongqing > 抄送: Eric Paris ; linux-au...@redhat.com; > linux-kernel@vger.kernel.org > 主题: Re: [PATCH] audit: fix a memleak caused by auditing load module > > On Tue, Mar 5, 2019 at 6:14 AM Li RongQing wrote: > > we should always free context->module.name, since it will be allocated > > unconditionally and audit_log_start() can fail with other reasons, and > > audit_log_exit maybe not called > > > > unreferenced object 0x88af90837d20 (size 8): > > comm "modprobe", pid 1036, jiffies 4294704867 (age 3069.138s) > > hex dump (first 8 bytes): > > 69 78 67 62 65 00 ff ff ixgbe... > > backtrace: > > [<08da28fe>] __audit_log_kern_module+0x33/0x80 > > [] load_module+0x64f/0x3850 > > [<7fc9ae3f>] __do_sys_init_module+0x218/0x250 > > [<00d4a478>] do_syscall_64+0x117/0x400 > > [<4924ded8>] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [<7dc331dd>] 0x > > > > Fixes: ca86cad7380e3 ("audit: log module name on init_module") > > Signed-off-by: Zhang Yu > > Signed-off-by: Li RongQing > > --- > > kernel/auditsc.c | 22 -- > > 1 file changed, 20 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c index > > b2d1f043f..2bd80375f 100644 > > --- a/kernel/auditsc.c > > +++ b/kernel/auditsc.c > > @@ -1186,8 +1186,13 @@ static void show_special(struct audit_context > *context, int *call_panic) > > int i; > > > > ab = audit_log_start(context, GFP_KERNEL, context->type); > > - if (!ab) > > + if (!ab) { > > + if (context->type == AUDIT_KERN_MODULE) { > > + kfree(context->module.name); > > + context->module.name = NULL; > > + } > > return; > > + } > > Hello. > > Thanks for the patch, but I have to ask if you've considered freeing the > module > name in audit_free_context()? That seems like the correct way to solve this > issue. > It does not work that move the freeing of module.name in audit_free_context Since we should free module.name based on context->types is AUDIT_KERN_MODULE, but __audit_syscall_exit is called first, and will set context->type to 0, When audit_free_context is called, context->type is 0, will cause to fail. I will change this patches as below: commit ee32ec2354b47a824e5e63d4f46567d577a02824 (HEAD -> master) Author: Li RongQing Date: Tue Mar 5 15:42:09 2019 +0800 audit: fix a memleak caused by auditing load module module.name will be allocated unconditionally when auditing load module, and audit_log_start() can fail with other reasons, or audit_log_exit maybe not called, caused module.name is released so always free module.name in audit_free_context unreferenced object 0x88af90837d20 (size 8): comm "modprobe", pid 1036, jiffies 4294704867 (age 3069.138s) hex dump (first 8 bytes): 69 78 67 62 65 00 ff ff ixgbe... backtrace: [<08da28fe>] __audit_log_kern_module+0x33/0x80 [ ] load_module+0x64f/0x3850 [<7fc9ae3f>] __do_sys_init_module+0x218/0x250 [<00d4a478>] do_syscall_64+0x117/0x400 [<4924ded8>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<7dc331dd>] 0x Fixes: ca86cad7380e3 ("audit: log module name on init_module") Signed-off-by: Zhang Yu Signed-off-by: Li RongQing diff --git a/kernel/auditsc.c b/kernel/auditsc.c index b2d1f043f..07728b07a 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -964,6 +964,9 @@ int audit_alloc(struct task_struct *tsk) static inline void audit_free_context(struct audit_context *context) { + if (context->type == AUDIT_KERN_MODULE) + kfree(context->module.name); + audit_free_names(context); unroll_tree_refs(context, NULL, 0); free_tree_refs(context); @@ -1282,6 +1285,8 @@ static void show_special(struct audit_context *context, int *call_panic) if (context->module.name) { audit_log_untrustedstring(ab, context->module.name); kfree(context->module.name); + context->module.name = NULL; + context->type = 0; } else audit_log_format(ab, "(null)"); @@ -1583,6 +1588,11 @@ void __audit_syscall_exit(int success, long return_code) if (!list_empty(>killed_trees)) audit_kill_trees(>killed_trees); + if (context->type == AUDIT_KERN_MODULE) { + kfree(context->module.name); + context->module.name = NULL; + } + audit_free_names(context); unroll_tree_refs(context, NULL, 0);
Re: [PATCH] cpufreq: Improve kerneldoc comments for cpufreq_cpu_get/put()
On 05-03-19, 11:44, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Fix the formatting of the cpufreq_cpu_get() and cpufreq_cpu_put()
> kerneldoc comments and rework them to be somewhat easier to follow.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/cpufreq.c | 24 +---
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -201,17 +201,15 @@ unsigned int cpufreq_generic_get(unsigne
> EXPORT_SYMBOL_GPL(cpufreq_generic_get);
>
> /**
> - * cpufreq_cpu_get: returns policy for a cpu and marks it busy.
> + * cpufreq_cpu_get - Return policy for a CPU and mark it as busy.
> + * @cpu: CPU to find the policy for.
> *
> - * @cpu: cpu to find policy for.
> + * Call cpufreq_cpu_get_raw() to obtain a cpufreq policy for @cpu and
> increment
> + * the kobject reference counter of that policy. Return a valid policy on
> + * success or NULL on failure.
> *
> - * This returns policy for 'cpu', returns NULL if it doesn't exist.
> - * It also increments the kobject reference count to mark it busy and so
> would
> - * require a corresponding call to cpufreq_cpu_put() to decrement it back.
> - * If corresponding call cpufreq_cpu_put() isn't made, the policy wouldn't be
> - * freed as that depends on the kobj count.
> - *
> - * Return: A valid policy on success, otherwise NULL on failure.
> + * The policy returned by this function has to be released with the help of
> + * cpufreq_cpu_put() to balance its kobject reference counter properly.
> */
> struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
> {
> @@ -238,12 +236,8 @@ struct cpufreq_policy *cpufreq_cpu_get(u
> EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
>
> /**
> - * cpufreq_cpu_put: Decrements the usage count of a policy
> - *
> - * @policy: policy earlier returned by cpufreq_cpu_get().
> - *
> - * This decrements the kobject reference count incremented earlier by calling
> - * cpufreq_cpu_get().
Shouldn't we always try to keep some description?
> + * cpufreq_cpu_put - Decrement kobject usage counter for cpufreq policy.
> + * @policy: cpufreq policy returned by cpufreq_cpu_get().
> */
> void cpufreq_cpu_put(struct cpufreq_policy *policy)
> {
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH 1/4] ARM: brcmstb: fix a leaked reference by adding missing of_node_put
On 3/5/2019 3:32 AM, Wen Yang wrote: > The call to of_get_next_child returns a node pointer with refcount > incremented thus it must be explicitly decremented after the last > usage. > > Detected by coccinelle with the following warnings: > ./arch/arm/mach-bcm/platsmp-brcmstb.c:337:2-8: ERROR: missing of_node_put; > acquired a node pointer with refcount incremented on line 329, but without a > corresponding object release within this function. > ./arch/arm/mach-bcm/platsmp-brcmstb.c:341:2-8: ERROR: missing of_node_put; > acquired a node pointer with refcount incremented on line 329, but without a > corresponding object release within this functio > ./arch/arm/mach-bcm/bcm63xx_smp.c:150:1-7: ERROR: missing of_node_put; > acquired a node pointer with refcount incremented on line 130, but without a > corresponding object release within this function. I would actually lump that in your [PATCH v2 02/15] ARM: bcm: fix a leaked reference by adding missing of_node_put patch since the subject of that one is correct. Thanks! -- Florian
Re: [PATCH v2 1/7] mfd: yeeloong_kb3310b: support KB3310B EC for Lemote Yeeloong laptops.
On Tue, Mar 05, 2019 at 11:50:51PM +, Paul Burton wrote:
> Hi Tom,
>
> Overall I think this is much better than the older out of tree platform
> driver - thanks for cleaning it up.
I'm glad to hear that.
> One general comment - it would be good to run the patches through
> ./scripts/checkpatch.pl & fix up any warnings it gives unless you have a
> good reason to disagree with them.
The entire patchset has already been checked by checkpatch.pl, and all
generated warnings have been corrected before submission. So I don't think
the script can help me improving the style beyond this point. Thanks for
pointing out all the additional style issues.
> Nit: the lines of asterisks aren't part of the kernel's general comment
> style & I think it would looks cleaner to remove them.
Sure, I will remove these asterisks banners.
In fact I learned to use these asterisks from other kernel drivers to
separate logical sections... and as a said, checkpatch.pl does not generate
a warning about it, so I suspect that, historically, a clear policy about
asterisks banners was never enforced. After finish working on these patches,
perhaps it would a good time to patch checkpatch.pl and add a check for it?
> I'm not sure I follow why the power management code prevents use of
> regmap?
>
> Are you talking about the wakeup_loongson() function? Perhaps it would
> make sense for the suspend code to be part of one of the possible
> subdrivers you mention. The lemote-2f seems to be the only system that
> provides an implementation of wakeup_loongson() so perhaps a driver
> could instead just register its own struct platform_suspend_ops & avoid
> the need for code in arch/mips to care about the EC.
I'll reword my misleading commit message about using regmap.
Let me clarify it - nothing prevents the use of regmap. I originally thought
it would be a good idea since the manual locking can be eliminated.
But later I realized it would mean more changes. In particular, not only pm.c
needs to be a new subdriver, the shutdown code in ml2f_reboot() also calls
ec_write(), and it needs to be converted to a subdriver in drivers/power/reset/
too. Yes, it would be good to refactor these code and move them to a more
suitable place, but currently, the primary goal is to add platform drivers,
not to touch functions I've just fixed and possibly introduce new regressions...
As you've seen, there is a TODO item in [PATCH 6/7] in this series, it says the
CS5536 code also needs some major refactoring: the GPIO needs to be changed,
the clocksource driver needs to be merged with the clockevent driver under
drivers/clocksource, etc. I think we can, as well, save the pm.c/reset.c for
later. Currently, I think it's better to focus on the platform drivers first.
If you still have objections on it, please let me know.
> > +#define DRV_NAME "yeeloong_kb3310b: "
>
> Defining pr_fmt() would be cleaner - you wouldn't need to manually
> include DRV_NAME in your messages later.
Noted.
> > +static struct kb3310b_chip *kb3310b_fwinfo;
> > +
> > +static const struct mfd_cell kb3310b_cells[] = {
> > + {
> > + .name = "yeeloong_sci"
> > + },
> > + {
> > + .name = "yeeloong_hwmon"
> > + },
> > + {
> > + .name = "yeeloong_battery"
> > + },
> > + {
> > + .name = "yeeloong_backlight"
> > + },
> > + {
> > + .name = "yeeloong_lcd"
> > + },
> > + {
> > + .name = "yeeloong_hotkey"
> > + },
>
> Nit: I think it'd look cleaner if you remove the newlines within each
> array entry, eg:
>
> { .name = "yeeloong_sci" },
> { .name = "yeelong_hwmon" },
> ...
Yes.
> > +
> > +static DEFINE_SPINLOCK(kb3310b_command_lock);
>
> Since this is only used in kb3310b_query_seq() could you just declare it
> (still static) inside that function?
No problem.
Thanks for your review, I'll correct all the issues above and send v3 today,
if there's no addition problem in v3, I will start sending the actual platform
drivers (battery/hwmon/etc) for the next round of review.
P.S: This time, I hope Lee Jones, as the MFD subsystem maintainer, has
received my mail and my patch, including this one. Unfortunately, all signs
indicated he hasn't received it. Jones, if you have received this mail but
currently too busy to review, please reply to confirm, thanks!
Sincerely yours,
Tom Li
Re: [PATCH][next] net/mlx5e: Remove redundant assignment
From: Saeed Mahameed
Date: Tue, 5 Mar 2019 22:21:39 +
> On Mon, 2019-03-04 at 08:26 +0200, Leon Romanovsky wrote:
>> On Sun, Mar 03, 2019 at 03:20:57PM +, Roi Dayan wrote:
>> >
>> > On 02/03/2019 21:39, Gustavo A. R. Silva wrote:
>> > > Remove redundant assignment to tun_entropy->enabled.
>> > >
>> > > Addesses-Coverity-ID: 1477328 ("Unused value")
>> > > Fixes: 97417f6182f8 ("net/mlx5e: Fix GRE key by controlling port
>> > > tunnel entropy calculation")
>> >
>> > the commit doesn't fix any real issue but is more of a cleanup.
>> > so I'm not sure if fixes line is relevant or not.
>> > beside that looks ok.
>>
>> It doesn't matter if it is real issue or not, the code is wrong and
>> should be fixed. This alone is enough to see the Fixes line.
>>
>> Thanks,
>> Acked-by: Leon Romanovsky
>
> Acked-by: Saeed Mahameed
> Dave, Do you think such patch should go to net, or do you want me to
> send it in my next pull request to net-next, once it is open of course
> ?
This feels more like net-next stuff to me, thanks for asking.
INFO: trying to register non-static key in __icmp_send
Hello, syzbot found the following crash on: HEAD commit:63bdf4284c38 Merge branch 'linus' of git://git.kernel.org/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=112c679f20 kernel config: https://syzkaller.appspot.com/x/.config?x=872be05707464aaa dashboard link: https://syzkaller.appspot.com/bug?extid=f09d845ad631ed93737b compiler: gcc (GCC) 9.0.0 20181231 (experimental) userspace arch: i386 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1739d54f20 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+f09d845ad631ed937...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready 8021q: adding VLAN 0 to HW filter on device batadv0 Started in network mode Own node identity ac1414aa, cluster identity 4711 New replicast peer: 172.20.20.187 INFO: trying to register non-static key. Enabled bearer , priority 10 the code is fine but needs lockdep annotation. Enabling of bearer rejected, already enabled turning off the locking correctness validator. Started in network mode CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0+ #7 Own node identity ac1414aa, cluster identity 4711 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 New replicast peer: 172.20.20.187 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 assign_lock_key kernel/locking/lockdep.c:731 [inline] register_lock_class+0x1bdc/0x1bf0 kernel/locking/lockdep.c:757 __lock_acquire+0x11f/0x4700 kernel/locking/lockdep.c:3224 Enabled bearer , priority 10 Enabling of bearer rejected, already enabled Enabling of bearer rejected, already enabled lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841 Enabling of bearer rejected, already enabled __raw_spin_trylock include/linux/spinlock_api_smp.h:90 [inline] _raw_spin_trylock+0x62/0x80 kernel/locking/spinlock.c:128 spin_trylock include/linux/spinlock.h:339 [inline] icmp_xmit_lock net/ipv4/icmp.c:219 [inline] __icmp_send+0x553/0x1400 net/ipv4/icmp.c:666 Enabling of bearer rejected, already enabled Enabling of bearer rejected, already enabled kobject: 'loop3' (853c4d7c): kobject_uevent_env kobject: 'loop3' (853c4d7c): fill_kobj_path: path = '/devices/virtual/block/loop3' icmp_send include/net/icmp.h:47 [inline] __udp4_lib_rcv+0x1fb6/0x2c50 net/ipv4/udp.c:2323 Enabling of bearer rejected, already enabled udp_rcv+0x22/0x30 net/ipv4/udp.c:2482 Enabling of bearer rejected, already enabled ip_protocol_deliver_rcu+0x60/0x8f0 net/ipv4/ip_input.c:208 kobject: 'loop3' (853c4d7c): kobject_uevent_env kobject: 'loop3' (853c4d7c): fill_kobj_path: path = '/devices/virtual/block/loop3' ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234 NF_HOOK include/linux/netfilter.h:289 [inline] NF_HOOK include/linux/netfilter.h:283 [inline] ip_local_deliver+0x1e9/0x520 net/ipv4/ip_input.c:255 dst_input include/net/dst.h:450 [inline] ip_rcv_finish+0x1e1/0x300 net/ipv4/ip_input.c:414 Enabling of bearer rejected, already enabled NF_HOOK include/linux/netfilter.h:289 [inline] NF_HOOK include/linux/netfilter.h:283 [inline] ip_rcv+0xe8/0x3f0 net/ipv4/ip_input.c:524 Enabling of bearer rejected, already enabled __netif_receive_skb_one_core+0x115/0x1a0 net/core/dev.c:4973 __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083 process_backlog+0x206/0x750 net/core/dev.c:5923 napi_poll net/core/dev.c:6346 [inline] net_rx_action+0x4fa/0x1070 net/core/dev.c:6412 __do_softirq+0x266/0x95a kernel/softirq.c:292 kobject: 'loop3' (853c4d7c): kobject_uevent_env run_ksoftirqd kernel/softirq.c:654 [inline] run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646 smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164 Enabling of bearer rejected, already enabled kthread+0x357/0x430 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 kasan: CONFIG_KASAN_INLINE enabled kobject: 'loop3' (853c4d7c): fill_kobj_path: path = '/devices/virtual/block/loop3' kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0+ #7 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__ip_append_data.isra.0+0x2e6/0x2dd0 net/ipv4/ip_output.c:898 Code: c7 85 cc fe ff ff 00 00 00 00 0f 85 28 13 00 00 e8 1f a6 99 fb 48 8b 95 38 ff ff ff 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 73 28 00 00 48 8b 85 38 ff ff ff 48 8b 18 48 b8 RSP: 0018:8880aa2c72a0 EFLAGS: 00010246 RAX: dc00 RBX: RCX: 85d63de1 RDX: RSI: 85d63e61 RDI: 0001 RBP: 8880aa2c7410 R08: 8880aa2b2440 R09: 85e694d0 R10: 8880aa2c7580 R11: 88808e459b43 R12: 88808e774a70 R13: 88808e774f10 R14:
