RE: [PATCH 1/2] dt-bindings: pwm: Convert imx pwm to json-schema
> From: Anson Huang
> Sent: Thursday, May 14, 2020 2:54 PM
>
> Convert the imx pwm binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang
> ---
> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 27 -
> Documentation/devicetree/bindings/pwm/imx-pwm.yaml | 66
> ++
> 2 files changed, 66 insertions(+), 27 deletions(-) delete mode 100644
> Documentation/devicetree/bindings/pwm/imx-pwm.txt
> create mode 100644
> Documentation/devicetree/bindings/pwm/imx-pwm.yaml
>
> diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> deleted file mode 100644
> index 22f1c3d..000
> --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -Freescale i.MX PWM controller
> -
> -Required properties:
> -- compatible : should be "fsl,-pwm" and one of the following
> - compatible strings:
> - - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
> - - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
> -- reg: physical base address and length of the controller's registers
> -- #pwm-cells: 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml
> - in this directory for a description of the cells format.
> -- clocks : Clock specifiers for both ipg and per clocks.
> -- clock-names : Clock names should include both "ipg" and "per"
> -See the clock consumer binding,
> - Documentation/devicetree/bindings/clock/clock-bindings.txt
> -- interrupts: The interrupt for the pwm controller
> -
> -Example:
> -
> -pwm1: pwm@53fb4000 {
> - #pwm-cells = <3>;
> - compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> - reg = <0x53fb4000 0x4000>;
> - clocks = < IMX5_CLK_PWM1_IPG_GATE>,
> - < IMX5_CLK_PWM1_HF_GATE>;
> - clock-names = "ipg", "per";
> - interrupts = <61>;
> -};
> diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> new file mode 100644
> index 000..4b62af2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +$id:
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> +tree.org%2Fschemas%2Fpwm%2Fimx-pwm.yaml%23data=02%7C01%
> 7Caisheng.d
> +ong%40nxp.com%7C9b5cc1814a4b47d1cb0d08d7f7d4f594%7C686ea1d3bc
> 2b4c6fa92c
> +d99c5c301635%7C0%7C0%7C637250366331627865sdata=M2RPcty
> wz61WZrpAW6S
> +O3NJbr2wj2qXwnMMmBwCbInk%3Dreserved=0
> +$schema:
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> +tree.org%2Fmeta-schemas%2Fcore.yaml%23data=02%7C01%7Caishen
> g.dong%
> +40nxp.com%7C9b5cc1814a4b47d1cb0d08d7f7d4f594%7C686ea1d3bc2b4c
> 6fa92cd99c
> +5c301635%7C0%7C0%7C637250366331627865sdata=UxgYSClanyOjt
> BmlyNrMZyF
> +3%2F5awD%2FM3yaVPqgNKgxs%3Dreserved=0
> +
> +title: Freescale i.MX PWM controller
> +
> +maintainers:
> + - Philipp Zabel
> +
> +properties:
> + "#pwm-cells":
> +description: |
> + Should be 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml
> + in this directory for a description of the cells format.
Should we add the reference to pwm.yaml?
BTW, strange, I didn't see format description in pwm.yaml.
> +enum:
> + - 2
> + - 3
> +
> + compatible:
> +enum:
> + - fsl,imx1-pwm
> + - fsl,imx27-pwm
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: SoC PWM ipg clock
> + - description: SoC PWM per clock
> +maxItems: 2
> +
> + clock-names:
> +items:
> + - const: ipg
> + - const: per
> +maxItems: 2
> +
> + interrupts:
> +maxItems: 1
> +
> +required:
> + - "#pwm-cells"
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +pwm@53fb4000 {
> +#pwm-cells = <3>;
> +compatible = "fsl,imx27-pwm";
> +reg = <0x53fb4000 0x4000>;
> +clocks = < IMX5_CLK_PWM1_IPG_GATE>,
> + < IMX5_CLK_PWM1_HF_GATE>;
> +clock-names = "ipg", "per";
> +interrupts = <61>;
> +};
> --
> 2.7.4
[PATCH 4/4] fs: Include FMODE_EXEC when converting flags to f_mode
Include FMODE_EXEC when building the f_mode field, so that code can
actually test the correct field and values. Only three places actually
examine f_flags for FMODE_EXEC:
fs/open.c: if (unlikely((f->f_mode & FMODE_EXEC) &&
!S_ISREG(inode->i_mode))) {
include/linux/fsnotify.h: if (file->f_mode & FMODE_EXEC) {
include/linux/fsnotify.h: if (file->f_mode & FMODE_EXEC)
Signed-off-by: Kees Cook
---
I assume there must be some reason for FMODE_EXEC not being pulled into
f_mode, but I couldn't find it. I guess this is my attempt to either fix
an oversight or to learn by flames. :)
---
fs/namei.c | 4 ++--
include/linux/fs.h | 3 ++-
include/linux/fsnotify.h | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 6bb1b6624bad..362b1cc75f5c 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3213,8 +3213,8 @@ static int do_open(struct nameidata *nd,
return -ENOTDIR;
/* Opening for execution requires a regular file on an exec mnt. */
- if ((file->f_flags & FMODE_EXEC) && (!d_is_reg(nd->path.dentry) ||
-path_noexec(>path)))
+ if ((file->f_mode & FMODE_EXEC) && (!d_is_reg(nd->path.dentry) ||
+ path_noexec(>path)))
return -EACCES;
do_truncate = false;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 4f6f59b4f22a..8a2cabdcf531 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3545,10 +3545,11 @@ int __init get_filesystem_list(char *buf);
#define __FMODE_EXEC ((__force int) FMODE_EXEC)
#define __FMODE_NONOTIFY ((__force int) FMODE_NONOTIFY)
+#define __SMUGGLED_FMODE_FLAGS (__FMODE_EXEC | __FMODE_NONOTIFY)
#define ACC_MODE(x) ("\004\002\006\006"[(x)_ACCMODE])
#define OPEN_FMODE(flag) ((__force fmode_t)(((flag + 1) & O_ACCMODE) | \
- (flag & __FMODE_NONOTIFY)))
+ (flag & __SMUGGLED_FMODE_FLAGS)))
static inline bool is_sxid(umode_t mode)
{
diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 5ab28f6c7d26..86761ed4b434 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -90,7 +90,7 @@ static inline int fsnotify_perm(struct file *file, int mask)
if (mask & MAY_OPEN) {
fsnotify_mask = FS_OPEN_PERM;
- if (file->f_flags & __FMODE_EXEC) {
+ if (file->f_mode & FMODE_EXEC) {
ret = fsnotify_file(file, FS_OPEN_EXEC_PERM);
if (ret)
@@ -264,7 +264,7 @@ static inline void fsnotify_open(struct file *file)
{
__u32 mask = FS_OPEN;
- if (file->f_flags & __FMODE_EXEC)
+ if (file->f_mode & FMODE_EXEC)
mask |= FS_OPEN_EXEC;
fsnotify_file(file, mask);
--
2.20.1
[PATCH 3/4] exec: Relocate path_noexec() check
The path_noexec() check, like the regular file check, was happening too
late, letting LSMs see impossible execve()s. Check it earlier as well
and collect the redundant fs/exec.c path_noexec() test under the same
robustness comment as the S_ISREG() check.
My notes on the call path, and related arguments, checks, etc:
do_open_execat()
struct open_flags open_exec_flags = {
.open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, ...
do_filp_open(dfd, filename, open_flags)
path_openat(nameidata, open_flags, flags)
/* f_mode populated from open_flags in alloc_empty_file() */
file = alloc_empty_file(open_flags, current_cred());
do_open(nameidata, file, open_flags)
/* new location of FMODE_EXEC vs path_noexec() test */
may_open(path, acc_mode, open_flag)
inode_permission(inode, MAY_OPEN | acc_mode)
security_inode_permission(inode, acc_mode)
vfs_open(path, file)
do_dentry_open(file, path->dentry->d_inode, open)
security_file_open(f)
open()
/* old location of path_noexec() test */
Signed-off-by: Kees Cook
---
fs/exec.c | 6 ++
fs/namei.c | 5 +++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index f0c80a8b9ccd..a34093323aa1 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -140,13 +140,12 @@ SYSCALL_DEFINE1(uselib, const char __user *, library)
goto out;
/*
-* do_open() has already checked for this, but we can be extra
+* do_open() has already checked for these, but we can be extra
* cautious and check again at the very end too.
*/
error = -EACCES;
if (!S_ISREG(file_inode(file)->i_mode))
goto exit;
-
if (path_noexec(>f_path))
goto exit;
@@ -865,13 +864,12 @@ static struct file *do_open_execat(int fd, struct
filename *name, int flags)
goto out;
/*
-* do_open() has already checked for this, but we can be extra
+* do_open() has already checked for these, but we can be extra
* cautious and check again at the very end too.
*/
err = -EACCES;
if (!S_ISREG(file_inode(file)->i_mode))
goto exit;
-
if (path_noexec(>f_path))
goto exit;
diff --git a/fs/namei.c b/fs/namei.c
index b9408aacaaa4..6bb1b6624bad 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3212,8 +3212,9 @@ static int do_open(struct nameidata *nd,
if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
return -ENOTDIR;
- /* Any file opened for execution has to be a regular file. */
- if ((file->f_flags & FMODE_EXEC) && !d_is_reg(nd->path.dentry))
+ /* Opening for execution requires a regular file on an exec mnt. */
+ if ((file->f_flags & FMODE_EXEC) && (!d_is_reg(nd->path.dentry) ||
+path_noexec(>path)))
return -EACCES;
do_truncate = false;
--
2.20.1
[PATCH 2/4] exec: Relocate S_ISREG() check
The execve(2)/uselib(2) syscalls have always rejected non-regular
files. Recently, it was noticed that a deadlock was introduced when trying
to execute pipes, as the S_ISREG() test was happening too late. This was
fixed in commit 73601ea5b7b1 ("fs/open.c: allow opening only regular files
during execve()"), but it was added after inode_permission() had already
run, which meant LSMs could see bogus attempts to execute non-regular
files. Move the test earlier.
Also include a comment with the redundant S_ISREG() checks at the end of
execve(2)/uselib(2) to note that they are present to avoid any mistakes.
Finally, instead of dereferencing the inode, use dcache for S_ISREG()
test.
My notes on the call path, and related arguments, checks, etc:
do_open_execat()
struct open_flags open_exec_flags = {
.open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, ...
do_filp_open(dfd, filename, open_flags)
path_openat(nameidata, open_flags, flags)
/* f_mode populated from open_flags in alloc_empty_file() */
file = alloc_empty_file(open_flags, current_cred());
do_open(nameidata, file, open_flags)
/* new location of FMODE_EXEC vs S_ISREG() test */
may_open(path, acc_mode, open_flag)
inode_permission(inode, MAY_OPEN | acc_mode)
security_inode_permission(inode, acc_mode)
vfs_open(path, file)
do_dentry_open(file, path->dentry->d_inode, open)
/* old location of FMODE_EXEC vs S_ISREG() test */
security_file_open(f)
open()
Signed-off-by: Kees Cook
---
fs/exec.c | 8
fs/namei.c | 4
fs/open.c | 6 --
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 30735ce1dc0e..f0c80a8b9ccd 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -139,6 +139,10 @@ SYSCALL_DEFINE1(uselib, const char __user *, library)
if (IS_ERR(file))
goto out;
+ /*
+* do_open() has already checked for this, but we can be extra
+* cautious and check again at the very end too.
+*/
error = -EACCES;
if (!S_ISREG(file_inode(file)->i_mode))
goto exit;
@@ -860,6 +864,10 @@ static struct file *do_open_execat(int fd, struct filename
*name, int flags)
if (IS_ERR(file))
goto out;
+ /*
+* do_open() has already checked for this, but we can be extra
+* cautious and check again at the very end too.
+*/
err = -EACCES;
if (!S_ISREG(file_inode(file)->i_mode))
goto exit;
diff --git a/fs/namei.c b/fs/namei.c
index a320371899cf..b9408aacaaa4 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3212,6 +3212,10 @@ static int do_open(struct nameidata *nd,
if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
return -ENOTDIR;
+ /* Any file opened for execution has to be a regular file. */
+ if ((file->f_flags & FMODE_EXEC) && !d_is_reg(nd->path.dentry))
+ return -EACCES;
+
do_truncate = false;
acc_mode = op->acc_mode;
if (file->f_mode & FMODE_CREATED) {
diff --git a/fs/open.c b/fs/open.c
index 719b320ede52..bb16e4e3cd57 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -753,12 +753,6 @@ static int do_dentry_open(struct file *f,
return 0;
}
- /* Any file opened for execve()/uselib() has to be a regular file. */
- if (unlikely(f->f_flags & FMODE_EXEC && !S_ISREG(inode->i_mode))) {
- error = -EACCES;
- goto cleanup_file;
- }
-
if (f->f_mode & FMODE_WRITE && !special_file(inode->i_mode)) {
error = get_write_access(inode);
if (unlikely(error))
--
2.20.1
[PATCH 0/4] Relocate execve() sanity checks
Hi, While looking at the code paths for the proposed O_MAYEXEC flag, I saw some things that looked like they should be fixed up. exec: Change uselib(2) IS_SREG() failure to EACCES This just regularizes the return code on uselib(2). exec: Relocate S_ISREG() check This moves the S_ISREG() check even earlier than it was already. exec: Relocate path_noexec() check This adds the path_noexec() check to the same place as the S_ISREG() check. fs: Include FMODE_EXEC when converting flags to f_mode This seemed like an oversight, but I suspect there is some reason I couldn't find for why FMODE_EXEC doesn't get set in f_mode and just stays in f_flags. Thanks! -Kees Kees Cook (4): exec: Change uselib(2) IS_SREG() failure to EACCES exec: Relocate S_ISREG() check exec: Relocate path_noexec() check fs: Include FMODE_EXEC when converting flags to f_mode fs/exec.c| 13 + fs/namei.c | 5 + fs/open.c| 6 -- include/linux/fs.h | 3 ++- include/linux/fsnotify.h | 4 ++-- 5 files changed, 18 insertions(+), 13 deletions(-) -- 2.20.1
[PATCH 1/4] exec: Change uselib(2) IS_SREG() failure to EACCES
Change uselib(2)' S_ISREG() error return to EACCES instead of EINVAL so the behavior matches execve(2), and the seemingly documented value. The "not a regular file" failure mode of execve(2) is explicitly documented[1], but it is not mentioned in uselib(2)[2] which does, however, say that open(2) and mmap(2) errors may apply. The documentation for open(2) does not include a "not a regular file" error[3], but mmap(2) does[4], and it is EACCES. [1] http://man7.org/linux/man-pages/man2/execve.2.html#ERRORS [2] http://man7.org/linux/man-pages/man2/uselib.2.html#ERRORS [3] http://man7.org/linux/man-pages/man2/open.2.html#ERRORS [4] http://man7.org/linux/man-pages/man2/mmap.2.html#ERRORS Signed-off-by: Kees Cook --- fs/exec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index 06b4c550af5d..30735ce1dc0e 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -139,11 +139,10 @@ SYSCALL_DEFINE1(uselib, const char __user *, library) if (IS_ERR(file)) goto out; - error = -EINVAL; + error = -EACCES; if (!S_ISREG(file_inode(file)->i_mode)) goto exit; - error = -EACCES; if (path_noexec(>f_path)) goto exit; -- 2.20.1
Re: Default enable RCU list lockdep debugging with PROVE_RCU
On 5/18/20 5:47 AM, Paul E. McKenney wrote: On Fri, May 15, 2020 at 02:36:26PM -0400, Qian Cai wrote: On May 14, 2020, at 2:13 PM, Paul E. McKenney wrote: Fair enough! And yes, the Linux kernel is quite large, so I certainly am not asking you to test the whole thing yourself. Ok, I saw 0day bot also started to report those which is good. For example, lkml.org/lkml/2020/5/12/1358 which so far is nit blocking 0day on linux-next since it does not use panic_on_warn yet (while syzbot does). Thus, I am more convinced that we should not revert the commit just for syzbot until someone could also convince 0day to select RCU_EXPERT and then DEBUG_RCU_LIST? Let's ask the 0day people, now CCed, if they would be willing to build with CONFIG_RCU_EXPERT=y and CONFIG_DEBUG_RCU_LIST=y on some fraction of their testing. ;-) Thanx, Paul Hi, Thanks for your advice, we'll support it in the near future. Best Regards, Rong Chen
Re: [PATCH v2] staging: wfx: Typo fix
On Mon, May 18, 2020 at 07:47:29AM +0200, Mohamed Dawod wrote: > Fixing some typo errors in traces.h file > > Signed-off-by: Mohamed Dawod > --- > drivers/staging/wfx/traces.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) What changed from v1? Always put that below the --- line. Please fix that up and send v3. thanks, greg k-h
Re: [PATCH] swap: Add percpu cluster_next to reduce lock contention on swap cache
Hi, Andrew,
Andrew Morton writes:
> On Thu, 14 May 2020 15:04:24 +0800 Huang Ying wrote:
>> diff --git a/mm/swapfile.c b/mm/swapfile.c
>> index 35be7a7271f4..9f1343b066c1 100644
>> --- a/mm/swapfile.c
>> +++ b/mm/swapfile.c
>> @@ -746,7 +746,16 @@ static int scan_swap_map_slots(struct swap_info_struct
>> *si,
>> */
>>
>> si->flags += SWP_SCANNING;
>> -scan_base = offset = si->cluster_next;
>> +/*
>> + * Use percpu scan base for SSD to reduce lock contention on
>> + * cluster and swap cache. For HDD, sequential access is more
>> + * important.
>> + */
>> +if (si->flags & SWP_SOLIDSTATE)
>> +scan_base = this_cpu_read(*si->cluster_next_cpu);
>> +else
>> +scan_base = si->cluster_next;
>> +offset = scan_base;
>
> Do we need to make SSD differ from spinning here? Do bad things happen
> if !SWP_SOLIDSTATE devices use the per-cpu cache?
I think the swapout throughput may be affected. Because HDD seek is
necessary to swapout for multiple CPUs, if per-cpu cluster_next is used.
But I just realized that per-cpu swap slots cache will cause seek too.
If we really care about the performance to use HDD as swap, maybe we
should disable per-cpu swap slots cache for HDD too?
>> /* SSD algorithm */
>> if (si->cluster_info) {
>> @@ -835,7 +844,10 @@ static int scan_swap_map_slots(struct swap_info_struct
>> *si,
>> unlock_cluster(ci);
>>
>> swap_range_alloc(si, offset, 1);
>> -si->cluster_next = offset + 1;
>> +if (si->flags & SWP_SOLIDSTATE)
>> +this_cpu_write(*si->cluster_next_cpu, offset + 1);
>> +else
>> +si->cluster_next = offset + 1;
>> slots[n_ret++] = swp_entry(si->type, offset);
>>
>> /* got enough slots or reach max slots? */
>> @@ -2828,6 +2840,11 @@ static struct swap_info_struct *alloc_swap_info(void)
>> p = kvzalloc(struct_size(p, avail_lists, nr_node_ids), GFP_KERNEL);
>> if (!p)
>> return ERR_PTR(-ENOMEM);
>> +p->cluster_next_cpu = alloc_percpu(unsigned int);
>> +if (!p->cluster_next_cpu) {
>> +kvfree(p);
>> +return ERR_PTR(-ENOMEM);
>> +}
>>
>> spin_lock(_lock);
>> for (type = 0; type < nr_swapfiles; type++) {
>> @@ -2962,6 +2979,8 @@ static unsigned long read_swap_header(struct
>> swap_info_struct *p,
>>
>> p->lowest_bit = 1;
>> p->cluster_next = 1;
>> +for_each_possible_cpu(i)
>> +per_cpu(*p->cluster_next_cpu, i) = 1;
>> p->cluster_nr = 0;
>>
>> maxpages = max_swapfile_size();
>> @@ -3204,6 +3223,10 @@ SYSCALL_DEFINE2(swapon, const char __user *,
>> specialfile, int, swap_flags)
>> * SSD
>> */
>> p->cluster_next = 1 + prandom_u32_max(p->highest_bit);
>
> We shouldn't need to do this now?
Yes. Thanks for pointing this out. Will delete this in the future
version.
>> +for_each_possible_cpu(cpu) {
>> +per_cpu(*p->cluster_next_cpu, cpu) =
>> +1 + prandom_u32_max(p->highest_bit);
>> +}
>
> Would there be any benefit in spreading these out evenly? Intervals of
> (p->highest_bit/num_possible_cpus())? That would reduce collisions,
> but not for very long I guess.
These may be spread more evenly with
(p->highest_bit/num_possible_cpus()). I just worry about the possible
situation that num_possible_cpus() >> num_online_cpus(). Where current
method works better?
> Speaking of which, I wonder if there are failure modes in which all the
> CPUs end up getting into sync.
>
> And is it the case that if two or more CPUs have the same (or similar)
> per_cpu(*p->cluster_next_cpu, cpu), they'll each end up pointlessly
> scanning slots which another CPU has just scanned, thus rather
> defeating the purpose of having the cluster_next cache?
>
> IOW, should there be some additional collision avoidance scheme to
> prevent a CPU from pointing its cluster_ext into a 64MB trunk which
> another CPU is already using?
Yes. That sounds reasonable. How about something as below,
When per-cpu cluster_next is assigned, if the new value is in a
different 64MB (or larger) trunk of the old value, we will assign a
random value between p->lowest_bit and p->highest_bit to per-cpu
cluster_next.
This can reduce the possibility of collision to be almost 0 if there's
enough free swap slots. And this is easy to be implemented, especially
considering the following situation,
(p->highest_bit - p->lowest_bit) / 64MB < num_online_cpus()
> And should it really be a per-cpu thing? That's rather arbitrary.
> Perhaps we would get better swap locality by making swap_cluster_next a
> per-process (per-mm_struct) thing?
I think per-cpu is enough. Because this is a scalability issue, as long
as we work on different 64MB trunks on different CPUs, the scalability
will be good. I don't find there's any value to use differnt 64MB
trunks on a single CPU.
Best Regards,
Re: [patch V6 04/37] x86: Make hardware latency tracing explicit
On Sun, May 17, 2020 at 1:48 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner wrote:
> >>
> >>
> >> The hardware latency tracer calls into trace_sched_clock and ends up in
> >> various instrumentable functions which is problemeatic vs. the kprobe
> >> handling especially the text poke machinery. It's invoked from
> >> nmi_enter/exit(), i.e. non-instrumentable code.
> >>
> >> Use nmi_enter/exit_notrace() instead. These variants do not invoke the
> >> hardware latency tracer which avoids chasing down complex callchains to
> >> make them non-instrumentable.
> >>
> >> The real interesting measurement is the actual NMI handler. Add an explicit
> >> invocation for the hardware latency tracer to it.
> >>
> >> #DB and #BP are uninteresting as they really should not be in use when
> >> analzying hardware induced latencies.
> >>
> >
> >> @@ -849,7 +851,7 @@ static void noinstr handle_debug(struct
> >> static __always_inline void exc_debug_kernel(struct pt_regs *regs,
> >> unsigned long dr6)
> >> {
> >> - nmi_enter();
> >> + nmi_enter_notrace();
> >
> > Why can't exc_debug_kernel() handle instrumentation? We shouldn't
> > recurse into #DB since we've already cleared DR7, right?
>
> It can later on. The point is that the trace stuff calls into the world
> and some more before the entry handling is complete.
>
> Remember this is about ensuring that all the state is properly
> established before any of this instrumentation muck can happen.
>
> DR7 handling is specific to #DB and done even before nmi_enter to
> prevent recursion.
So why is this change needed?
[PATCH v2] staging: wfx: Typo fix
Fixing some typo errors in traces.h file
Signed-off-by: Mohamed Dawod
---
drivers/staging/wfx/traces.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wfx/traces.h b/drivers/staging/wfx/traces.h
index bb9f7e9..80e131c 100644
--- a/drivers/staging/wfx/traces.h
+++ b/drivers/staging/wfx/traces.h
@@ -32,16 +32,16 @@
* xxx_name(XXX) \
* ...
*
- * 3. Instanciate that list_names:
+ * 3. Instantiate that list_names:
*
* list_names
*
- * 4. Redefine xxx_name() as a entry of array for __print_symbolic()
+ * 4. Redefine xxx_name() as an entry of array for __print_symbolic()
*
* #undef xxx_name
* #define xxx_name(msg) { msg, #msg },
*
- * 5. list_name can now nearlu be used with __print_symbolic() but,
+ * 5. list_name can now nearly be used with __print_symbolic() but,
* __print_symbolic() dislike last comma of list. So we define a new list
* with a dummy element:
*
--
2.7.4
Re: [PATCH 0/3] arm64: perf: Add support for Perf NMI interrupts
+ Julien Hi Lecopzer, On Sat, 16 May 2020 at 18:20, Lecopzer Chen wrote: > > These series implement Perf NMI funxtionality and depends on > Pseudo NMI [1] which has been upstreamed. > > In arm64 with GICv3, Pseudo NMI was implemented for NMI-like interruts. > That can be extended to Perf NMI which is the prerequisite for hard-lockup > detector which had already a standard interface inside Linux. > > Thus the first step we need to implement perf NMI interface and make sure > it works fine. > This is something that is already implemented via Julien's patch-set [1]. Its v4 has been floating since July, 2019 and I couldn't find any major blocking comments but not sure why things haven't progressed further. Maybe Julien or Arm maintainers can provide updates on existing patch-set [1] and how we should proceed further with this interesting feature. And regarding hard-lockup detection, I have been able to enable it based on perf NMI events using Julien's perf patch-set [1]. Have a look at the patch here [2]. [1] https://patchwork.kernel.org/cover/11047407/ [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732227.html -Sumit > Perf NMI has been test by dd if=/dev/urandom of=/dev/null like the link [2] > did. > > [1] https://lkml.org/lkml/2019/1/31/535 > [2] https://www.linaro.org/blog/debugging-arm-kernels-using-nmifiq > > > Lecopzer Chen (3): > arm_pmu: Add support for perf NMI interrupts registration > arm64: perf: Support NMI context for perf event ISR > arm64: Kconfig: Add support for the Perf NMI > > arch/arm64/Kconfig | 10 +++ > arch/arm64/kernel/perf_event.c | 36 ++-- > drivers/perf/arm_pmu.c | 51 ++ > include/linux/perf/arm_pmu.h | 6 > 4 files changed, 88 insertions(+), 15 deletions(-) > > -- > 2.25.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: linux-next: manual merge of the kvm tree with the rcu tree
Hi all,
On Mon, 18 May 2020 15:42:40 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the kvm tree got a conflict in:
>
> arch/x86/kvm/svm/svm.c
>
> between commit:
>
> 9f24847d8fdb ("kvm/svm: Disable KCSAN for svm_vcpu_run()")
>
> from the rcu tree and commits:
>
> a9ab13ff6e84 ("KVM: X86: Improve latency for single target IPI fastpath")
> 404d5d7bff0d ("KVM: X86: Introduce more exit_fastpath_completion enum
> values")
>
> from the kvm 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/kvm/svm/svm.c
index dca2bdbe34a7,4e9cd2a73ad0..
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@@ -3279,10 -3315,21 +3315,21 @@@ static void svm_cancel_injection(struc
svm_complete_interrupts(svm);
}
+ static fastpath_t svm_exit_handlers_fastpath(struct kvm_vcpu *vcpu)
+ {
+ if (!is_guest_mode(vcpu) &&
+ to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_MSR &&
+ to_svm(vcpu)->vmcb->control.exit_info_1)
+ return handle_fastpath_set_msr_irqoff(vcpu);
+
+ return EXIT_FASTPATH_NONE;
+ }
+
void __svm_vcpu_run(unsigned long vmcb_pa, unsigned long *regs);
- static __no_kcsan void svm_vcpu_run(struct kvm_vcpu *vcpu)
-static fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu)
++static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu)
{
+ fastpath_t exit_fastpath;
struct vcpu_svm *svm = to_svm(vcpu);
svm->vmcb->save.rax = vcpu->arch.regs[VCPU_REGS_RAX];
s
pgpvqXeGOeYlw.pgp
Description: OpenPGP digital signature
Re: general protection fault vs Oops
On Mon, May 18, 2020 at 2:16 AM Cong Wang wrote: > > On Sat, May 16, 2020 at 9:16 AM Subhashini Rao Beerisetty > wrote: > > Yes, those are out-of-tree modules. Basically, my question is, in > > general what is the difference between 'general protection fault' and > > 'Oops' failure in kernel mode. > > For your case, they are likely just different consequences of a same > memory error. Let's assume it is a use-after-free, the behavior is UAF > is undefined: If that memory freed by kernel is also unmapped from > kernel address space, you would get a page fault when using it > afterward, that is an Oops. Or if that memory freed by kernel gets > reallocated and remapped as read-only, you would get a general > protection error when you writing to it afterward. Cool, thanks for the clarification.
linux-next: manual merge of the kvm tree with the rcu tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/x86/kvm/svm/svm.c
between commit:
9f24847d8fdb ("kvm/svm: Disable KCSAN for svm_vcpu_run()")
from the rcu tree and commits:
a9ab13ff6e84 ("KVM: X86: Improve latency for single target IPI fastpath")
404d5d7bff0d ("KVM: X86: Introduce more exit_fastpath_completion enum values")
from the kvm 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
pgp_Uf7fDPa8g.pgp
Description: OpenPGP digital signature
[PATCH] drm/etnaviv: convert get_user_pages() --> pin_user_pages()
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: John Hubbard
---
Hi,
Note that I have only compile-tested this patch, although that does
also include cross-compiling for a few other arches.
thanks,
John Hubbard
NVIDIA
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index dc9ef302f517..0f4578dc169d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -675,10 +675,10 @@ static int etnaviv_gem_userptr_get_pages(struct
etnaviv_gem_object *etnaviv_obj)
uint64_t ptr = userptr->ptr + pinned * PAGE_SIZE;
struct page **pages = pvec + pinned;
- ret = get_user_pages_fast(ptr, num_pages,
+ ret = pin_user_pages_fast(ptr, num_pages,
!userptr->ro ? FOLL_WRITE : 0, pages);
if (ret < 0) {
- release_pages(pvec, pinned);
+ unpin_user_pages(pvec, pinned);
kvfree(pvec);
return ret;
}
@@ -702,7 +702,7 @@ static void etnaviv_gem_userptr_release(struct
etnaviv_gem_object *etnaviv_obj)
if (etnaviv_obj->pages) {
int npages = etnaviv_obj->base.size >> PAGE_SHIFT;
- release_pages(etnaviv_obj->pages, npages);
+ unpin_user_pages(etnaviv_obj->pages, npages);
kvfree(etnaviv_obj->pages);
}
}
--
2.26.2
[PATCH 1/1] ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme
The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec
requires a similar workaround for Clevo laptops to enforce the
DAC/mixer connection path. Set up a quirk entry for that.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275
Signed-off-by: Christian Lachner
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index dc2302171a71..23315b69ac38 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -2457,6 +2457,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = {
SND_PCI_QUIRK(0x1458, 0xa002, "Gigabyte EP45-DS3/Z87X-UD3H",
ALC889_FIXUP_FRONT_HP_NO_PRESENCE),
SND_PCI_QUIRK(0x1458, 0xa0b8, "Gigabyte AZ370-Gaming",
ALC1220_FIXUP_GB_DUAL_CODECS),
SND_PCI_QUIRK(0x1458, 0xa0cd, "Gigabyte X570 Aorus Master",
ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1458, 0xa0ce, "Gigabyte X570 Aorus Xtreme",
ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1462, 0x1228, "MSI-GP63", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1462, 0x1275, "MSI-GL63", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1462, 0x1276, "MSI-GL73", ALC1220_FIXUP_CLEVO_P950),
--
2.26.2
[PATCH 0/1] Fix silent output on Gigabyte X570 Aorus Xtreme
The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec requires a similar workaround for Clevo laptops to enforce the DAC/mixer connection path. This patch sets up a quirk entry for that. It was successfully tested by a user on BugZilla (see BugLink). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275 Christian Lachner (1): ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) -- 2.26.2
Re: [PATCH 2/9] fs/ext4: Disallow verity if inode is DAX
On Fri, May 15, 2020 at 06:49:16PM -0700, Eric Biggers wrote: > On Tue, May 12, 2020 at 10:43:17PM -0700, ira.we...@intel.com wrote: > > From: Ira Weiny > > > > Verity and DAX are incompatible. Changing the DAX mode due to a verity > > flag change is wrong without a corresponding address_space_operations > > update. > > > > Make the 2 options mutually exclusive by returning an error if DAX was > > set first. > > > > (Setting DAX is already disabled if Verity is set first.) > > > > Signed-off-by: Ira Weiny > > > > --- > > Changes: > > remove WARN_ON_ONCE > > Add documentation for DAX/Verity exclusivity > > --- > > Documentation/filesystems/ext4/verity.rst | 7 +++ > > fs/ext4/verity.c | 3 +++ > > 2 files changed, 10 insertions(+) > > > > diff --git a/Documentation/filesystems/ext4/verity.rst > > b/Documentation/filesystems/ext4/verity.rst > > index 3e4c0ee0e068..51ab1aa17e59 100644 > > --- a/Documentation/filesystems/ext4/verity.rst > > +++ b/Documentation/filesystems/ext4/verity.rst > > @@ -39,3 +39,10 @@ is encrypted as well as the data itself. > > > > Verity files cannot have blocks allocated past the end of the verity > > metadata. > > + > > +Verity and DAX > > +-- > > + > > +Verity and DAX are not compatible and attempts to set both of these flags > > on a > > +file will fail. > > + > > If you build the documentation, this shows up as its own subsection > "2.13. Verity and DAX" alongside "2.12. Verity files", which looks odd. > I think you should delete this new subsection header so that this paragraph > goes > in the existing "Verity files" subsection. Ok... I'll fix it up... > > Also, Documentation/filesystems/fsverity.rst already mentions DAX (similar to > fscrypt.rst). Is it intentional that you added this to the ext4-specific > documentation instead? I proposed this text[1] and there were no objections... I was looking at ext4 because only ext4 supports verity and DAX. I think having this in both the ext4 docs and the verity docs helps. Ira [1] https://lore.kernel.org/lkml/20200415191451.ga2305...@iweiny-desk2.sc.intel.com/ > > - Eric
RE: [PATCH] dt-bindings: pwm: Convert mxs pwm to json-schema
> Subject: RE: [PATCH] dt-bindings: pwm: Convert mxs pwm to json-schema > > > +title: Freescale MXS PWM controller > > + > > +maintainers: > > + - Shawn Guo > > + - Anson Huang > > + > > +properties: > > + compatible: > > +enum: > > + - fsl,imx23-pwm > > + > > + reg: > > +maxItems: 1 > > + > > + "#pwm-cells": > > +const: 3 > > Seems you missed the reference to pwm.yaml. It is because many pwm yaml files also has no "#pwm-cells" reference, so I am NOT sure if it is a MUST: Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml ... Anson
[PATCH] vlan: fix the bug that cannot create vlan4095
According to the 8021q standard, the VLAN id range is 1 to 4095. But in the register_vlan_device function, the range is 1 to 4094, because ">= VLAN_VID_MASK" is used to determine whether the id is illegal. This will prevent the creation of the vlan4095 interface: $ vconfig add sit0 4095 vconfig: ioctl error for add: Numerical result out of range To fix this error, this patch uses ">= VLAN_N_VID" instead to determine if the id is illegal. Signed-off-by: Huang Qijun --- net/8021q/vlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c index d4bcfd8f95bf..5de7861ddf64 100644 --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -219,7 +219,7 @@ static int register_vlan_device(struct net_device *real_dev, u16 vlan_id) char name[IFNAMSIZ]; int err; - if (vlan_id >= VLAN_VID_MASK) + if (vlan_id >= VLAN_N_VID) return -ERANGE; err = vlan_check_real_dev(real_dev, htons(ETH_P_8021Q), vlan_id, -- 2.17.1
RE: [PATCH] dt-bindings: pwm: Convert mxs pwm to json-schema
> +title: Freescale MXS PWM controller
> +
> +maintainers:
> + - Shawn Guo
> + - Anson Huang
> +
> +properties:
> + compatible:
> +enum:
> + - fsl,imx23-pwm
> +
> + reg:
> +maxItems: 1
> +
> + "#pwm-cells":
> +const: 3
Seems you missed the reference to pwm.yaml.
Regards
Aisheng
> +
> + fsl,pwm-number:
> +$ref: '/schemas/types.yaml#/definitions/uint32'
> +description: u32 value representing the number of PWM devices
> +
> +required:
> + - compatible
> + - reg
> + - "#pwm-cells"
> + - fsl,pwm-number
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +pwm@80064000 {
> +compatible = "fsl,imx23-pwm";
> +reg = <0x80064000 0x2000>;
> +#pwm-cells = <3>;
> +fsl,pwm-number = <8>;
> +};
> --
> 2.7.4
RE: [PATCH] dt-bindings: interrupt-controller: Convert imx irqsteer to json-schema
> Subject: RE: [PATCH] dt-bindings: interrupt-controller: Convert imx irqsteer > to > json-schema > > ... > > + > > +title: Freescale IRQSTEER Interrupt multiplexer > > + > > +maintainers: > > + - Lucas Stach > > + > > +properties: > > + compatible: > > +const: fsl,imx-irqsteer > > You changed binding here without comments? It is because drivers/irqchip/irq-imx-irqsteer.c ONLY has "fsl,imx-irqsteer" as valid compatible, so take this chance to fix it in this patch. Anson
Re: [PATCH v5 27/38] xen: gntdev: fix common struct sg_table related issues
On 13.05.20 15:32, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().
struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).
It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.
To avoid such issues, lets use a common dma-mapping wrappers operating
directly on the struct sg_table objects and use scatterlist page
iterators where possible. This, almost always, hides references to the
nents and orig_nents entries, making the code robust, easier to follow
and copy/paste safe.
Signed-off-by: Marek Szyprowski
Acked-by: Juergen Gross
Juergen
Re: linux-next: build failure after merge of the qcom tree
Hi all,
On Mon, 20 Apr 2020 19:41:56 -0700 John Stultz wrote:
>
> On Mon, Apr 20, 2020 at 4:29 PM Stephen Rothwell
> wrote:
> >
> > On Tue, 14 Apr 2020 18:18:11 -0700 John Stultz
> > wrote:
> > >
> > > On Tue, Apr 14, 2020 at 5:41 PM Stephen Rothwell
> > > wrote:
> > > >
> > > > After merging the qcom tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > drivers/soc/qcom/rpmh-rsc.c: In function '__tcs_buffer_write':
> > > > drivers/soc/qcom/rpmh-rsc.c:484:3: error: implicit declaration of
> > > > function 'trace_rpmh_send_msg_rcuidle'; did you mean
> > > > 'trace_rpmh_send_msg_enabled'? [-Werror=implicit-function-declaration]
> > > > 484 | trace_rpmh_send_msg_rcuidle(drv, tcs_id, j, msgid, cmd);
> > > > | ^~~
> > > > | trace_rpmh_send_msg_enabled
> > > > cc1: some warnings being treated as errors
> > > >
> > > > I don't know why this error only started happening today. However
> > > > reverting commit
> > > >
> > > > 1d3c6f86fd3f ("soc: qcom: rpmh: Allow RPMH driver to be loaded as a
> > > > module")
> > > >
> > > > fixes the build, so I have done that for today.
> > >
> > >
> > > Ah. I'm guessing the newly added rpmh-rsc code depends on rpmh being
> > > built in.
> > >
> > > I'll take a look at it.
> >
> > I am still reverting that commit.
>
> Yea. I've stirred up some discussion on it, but its fairly
> complicated. Unfortunately I suspect it will take some time to confirm
> and justify the change I think is needed, so I think reverting this is
> the best short term plan.
I am still reverting that commit. It is probably time (we are beyond
-rc6 now) that it is either reverted or fixed in the qcom tree, please.
--
Cheers,
Stephen Rothwell
pgpIsbx1KxOmS.pgp
Description: OpenPGP digital signature
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:
include/linux/compiler.h
between commit:
a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
from Linus' tree and commit:
f670269a42bf ("x86: Fix early boot crash on gcc-10, next try")
from the tip tree.
I fixed it up (I just used Linus' tree version) 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
pgp5lDpmcG89O.pgp
Description: OpenPGP digital signature
[PATCH v3 3/3] mm/memory.c: Add memory read privilege before filling PTE entry
On mips platform, hw PTE entry valid bit is set in pte_mkyoung function, it is used to set physical page with readable privilege. Here add pte_mkyoung function to make page readable on MIPS platform during page fault handling. This patch improves page fault latency about 10% on my MIPS machine with lmbench lat_pagefault case. Signed-off-by: Bibo Mao --- mm/memory.c | 3 +++ mm/mprotect.c | 2 ++ 2 files changed, 5 insertions(+) diff --git a/mm/memory.c b/mm/memory.c index 2eb59a9..2399dcb 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2704,6 +2704,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf) } flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte)); entry = mk_pte(new_page, vma->vm_page_prot); + entry = pte_mkyoung(entry); entry = maybe_mkwrite(pte_mkdirty(entry), vma); /* * Clear the pte entry and flush it first, before updating the @@ -3378,6 +3379,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf) __SetPageUptodate(page); entry = mk_pte(page, vma->vm_page_prot); + entry = pte_mkyoung(entry); if (vma->vm_flags & VM_WRITE) entry = pte_mkwrite(pte_mkdirty(entry)); @@ -3660,6 +3662,7 @@ vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct mem_cgroup *memcg, flush_icache_page(vma, page); entry = mk_pte(page, vma->vm_page_prot); + entry = pte_mkyoung(entry); if (write) entry = maybe_mkwrite(pte_mkdirty(entry), vma); /* copy-on-write page */ diff --git a/mm/mprotect.c b/mm/mprotect.c index 494192ca..673f1cd 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -131,6 +131,8 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd, ptent = pte_clear_uffd_wp(ptent); } + if (vma->vm_flags & VM_READ) + ptent = pte_mkyoung(ptent); /* Avoid taking write faults for known dirty pages */ if (dirty_accountable && pte_dirty(ptent) && (pte_soft_dirty(ptent) || -- 1.8.3.1
[PATCH v3 2/3] mm/memory.c: Update local TLB if PTE entry exists
If two threads concurrently fault at the same address, the thread that
won the race updates the PTE and its local TLB. For now, the other
thread gives up, simply does nothing, and continues.
It could happen that this second thread triggers another fault, whereby
it only updates its local TLB while handling the fault. Instead of
triggering another fault, let's directly update the local TLB of the
second thread.
It is only useful to architectures where software can update TLB, it may
bring out some negative effect if update_mmu_cache is used for other
purpose also. It seldom happens where multiple threads access the same
page at the same time, so the negative effect is limited on other arches.
Signed-off-by: Bibo Mao
---
mm/memory.c | 44 +++-
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index f703fe8..2eb59a9 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1770,8 +1770,8 @@ static vm_fault_t insert_pfn(struct vm_area_struct *vma,
unsigned long addr,
}
entry = pte_mkyoung(*pte);
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- if (ptep_set_access_flags(vma, addr, pte, entry, 1))
- update_mmu_cache(vma, addr, pte);
+ ptep_set_access_flags(vma, addr, pte, entry, 1);
+ update_mmu_cache(vma, addr, pte);
}
goto out_unlock;
}
@@ -2436,17 +2436,16 @@ static inline bool cow_user_page(struct page *dst,
struct page *src,
if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
/*
* Other thread has already handled the fault
-* and we don't need to do anything. If it's
-* not the case, the fault will be triggered
-* again on the same address.
+* and update local tlb only
*/
+ update_mmu_cache(vma, addr, vmf->pte);
ret = false;
goto pte_unlock;
}
entry = pte_mkyoung(vmf->orig_pte);
- if (ptep_set_access_flags(vma, addr, vmf->pte, entry, 0))
- update_mmu_cache(vma, addr, vmf->pte);
+ ptep_set_access_flags(vma, addr, vmf->pte, entry, 0);
+ update_mmu_cache(vma, addr, vmf->pte);
}
/*
@@ -2463,7 +2462,8 @@ static inline bool cow_user_page(struct page *dst, struct
page *src,
vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr, >ptl);
locked = true;
if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
- /* The PTE changed under us. Retry page fault. */
+ /* The PTE changed under us, update local tlb */
+ update_mmu_cache(vma, addr, vmf->pte);
ret = false;
goto pte_unlock;
}
@@ -2618,8 +2618,8 @@ static inline void wp_page_reuse(struct vm_fault *vmf)
flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
entry = pte_mkyoung(vmf->orig_pte);
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- if (ptep_set_access_flags(vma, vmf->address, vmf->pte, entry, 1))
- update_mmu_cache(vma, vmf->address, vmf->pte);
+ ptep_set_access_flags(vma, vmf->address, vmf->pte, entry, 1);
+ update_mmu_cache(vma, vmf->address, vmf->pte);
pte_unmap_unlock(vmf->pte, vmf->ptl);
}
@@ -2752,6 +2752,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
new_page = old_page;
page_copied = 1;
} else {
+ update_mmu_cache(vma, vmf->address, vmf->pte);
mem_cgroup_cancel_charge(new_page, memcg, false);
}
@@ -2812,6 +2813,7 @@ vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf)
* pte_offset_map_lock.
*/
if (!pte_same(*vmf->pte, vmf->orig_pte)) {
+ update_mmu_cache(vmf->vma, vmf->address, vmf->pte);
pte_unmap_unlock(vmf->pte, vmf->ptl);
return VM_FAULT_NOPAGE;
}
@@ -2936,6 +2938,7 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf)
vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
vmf->address, >ptl);
if (!pte_same(*vmf->pte, vmf->orig_pte)) {
+ update_mmu_cache(vma, vmf->address, vmf->pte);
unlock_page(vmf->page);
pte_unmap_unlock(vmf->pte, vmf->ptl);
put_page(vmf->page);
@@ -3341,8 +3344,10 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
[PATCH v3 1/3] MIPS: Do not flush tlb page when updating PTE entry
It is not necessary to flush tlb page on all CPUs if suitable PTE
entry exists already during page fault handling, just updating
TLB is fine.
Here redefine flush_tlb_fix_spurious_fault as empty on MIPS system.
Change in v2:
- split flush_tlb_fix_spurious_fault and tlb update into two patches
- comments typo modification
- separate tlb update and add pte readable privilege into two patches
Change in V3:
- add detailed changelog, modify typo issue in patch V2
Signed-off-by: Bibo Mao
---
arch/mips/include/asm/pgtable.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index 9b01d2d..0d625c2 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -478,6 +478,8 @@ static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
return __pgprot(prot);
}
+#define flush_tlb_fix_spurious_fault(vma, address) do { } while (0)
+
/*
* Conversion functions: convert a page and protection to a page entry,
* and a page entry and page directory to the page they refer to.
--
1.8.3.1
Re: [PATCH] clk/ti/adpll: Add a NULL check for devm_kasprintf()
Hi Xu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v5.7-rc6 next-20200515]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Xu-Wang/clk-ti-adpll-Add-a-NULL-check-for-devm_kasprintf/20200518-114748
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: i386-allyesconfig (attached as .config)
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-193-gb8fad4bc-dirty
# save the attached .config to linux build tree
make C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/clk/ti/adpll.c:200:32: sparse: sparse: incorrect type in return
>> expression (different base types) @@expected char const * @@got t *
>> @@
>> drivers/clk/ti/adpll.c:200:32: sparse:expected char const *
>> drivers/clk/ti/adpll.c:200:32: sparse:got int
vim +200 drivers/clk/ti/adpll.c
181
182 static const char *ti_adpll_clk_get_name(struct ti_adpll_data *d,
183 int output_index,
184 const char *postfix)
185 {
186 const char *name;
187 int err;
188
189 if (output_index >= 0) {
190 err = of_property_read_string_index(d->np,
191
"clock-output-names",
192 output_index,
193 );
194 if (err)
195 return NULL;
196 } else {
197 name = devm_kasprintf(d->dev, GFP_KERNEL,
"%08lx.adpll.%s",
198d->pa, postfix);
199 if (!name)
> 200 return -ENOMEM;
201 }
202
203 return name;
204 }
205
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[RFC PATCH linus] RISC-V: gp_in_global can be static
Fixes: 52e7c52d2ded ("RISC-V: Stop relying on GCC's register allocator's
hueristics")
Signed-off-by: kbuild test robot
---
process.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 610c11e916068..3b2933839d492 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -22,7 +22,7 @@
#include
#include
-unsigned long gp_in_global __asm__("gp");
+static unsigned long gp_in_global __asm__("gp");
extern asmlinkage void ret_from_fork(void);
extern asmlinkage void ret_from_kernel_thread(void);
Re: [PATCH 3/9] fs/ext4: Disallow encryption if inode is DAX
On Fri, May 15, 2020 at 07:02:53PM -0700, Eric Biggers wrote:
> On Tue, May 12, 2020 at 10:43:18PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Encryption and DAX are incompatible. Changing the DAX mode due to a
> > change in Encryption mode is wrong without a corresponding
> > address_space_operations update.
> >
> > Make the 2 options mutually exclusive by returning an error if DAX was
> > set first.
> >
> > Furthermore, clarify the documentation of the exclusivity and how that
> > will work.
> >
> > Signed-off-by: Ira Weiny
> >
> > ---
> > Changes:
> > remove WARN_ON_ONCE
> > Add documentation to the encrypt doc WRT DAX
> > ---
> > Documentation/filesystems/fscrypt.rst | 4 +++-
> > fs/ext4/super.c | 10 +-
> > 2 files changed, 4 insertions(+), 10 deletions(-)
> >
> > diff --git a/Documentation/filesystems/fscrypt.rst
> > b/Documentation/filesystems/fscrypt.rst
> > index aa072112cfff..1475b8d52fef 100644
> > --- a/Documentation/filesystems/fscrypt.rst
> > +++ b/Documentation/filesystems/fscrypt.rst
> > @@ -1038,7 +1038,9 @@ astute users may notice some differences in behavior:
> > - The ext4 filesystem does not support data journaling with encrypted
> >regular files. It will fall back to ordered data mode instead.
> >
> > -- DAX (Direct Access) is not supported on encrypted files.
> > +- DAX (Direct Access) is not supported on encrypted files. Attempts to
> > enable
> > + DAX on an encrypted file will fail. Mount options will _not_ enable DAX
> > on
> > + encrypted files.
> >
> > - The st_size of an encrypted symlink will not necessarily give the
> >length of the symlink target as required by POSIX. It will actually
> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > index bf5fcb477f66..9873ab27e3fa 100644
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> > @@ -1320,7 +1320,7 @@ static int ext4_set_context(struct inode *inode,
> > const void *ctx, size_t len,
> > if (inode->i_ino == EXT4_ROOT_INO)
> > return -EPERM;
> >
> > - if (WARN_ON_ONCE(IS_DAX(inode) && i_size_read(inode)))
> > + if (IS_DAX(inode))
> > return -EINVAL;
> >
> > res = ext4_convert_inline_data(inode);
> > @@ -1344,10 +1344,6 @@ static int ext4_set_context(struct inode *inode,
> > const void *ctx, size_t len,
> > ext4_set_inode_flag(inode, EXT4_INODE_ENCRYPT);
> > ext4_clear_inode_state(inode,
> > EXT4_STATE_MAY_INLINE_DATA);
> > - /*
> > -* Update inode->i_flags - S_ENCRYPTED will be enabled,
> > -* S_DAX may be disabled
> > -*/
> > ext4_set_inode_flags(inode);
> > }
> > return res;
> > @@ -1371,10 +1367,6 @@ static int ext4_set_context(struct inode *inode,
> > const void *ctx, size_t len,
> > ctx, len, 0);
> > if (!res) {
> > ext4_set_inode_flag(inode, EXT4_INODE_ENCRYPT);
> > - /*
> > -* Update inode->i_flags - S_ENCRYPTED will be enabled,
> > -* S_DAX may be disabled
> > -*/
> > ext4_set_inode_flags(inode);
> > res = ext4_mark_inode_dirty(handle, inode);
> > if (res)
>
> I'm confused by the ext4_set_context() change.
>
> ext4_set_context() is only called when FS_IOC_SET_ENCRYPTION_POLICY sets an
> encryption policy on an empty directory, *or* when a new inode (regular, dir,
> or
> symlink) is created in an encrypted directory (thus inheriting encryption from
> its parent).
I don't see the check which prevents FS_IOC_SET_ENCRYPTION_POLICY on a file?
On inode creation, encryption will always usurp S_DAX...
>
> So when is it reachable when IS_DAX()? Is the issue that the DAX flag can now
> be set on directories? The commit message doesn't seem to be talking about
> directories. Is the behavior we want is that on an (empty) directory with the
> DAX flag set, FS_IOC_SET_ENCRYPTION_POLICY should fail with EINVAL?
We would want that but AFIAK S_DAX is never set on directories. Perhaps this
is another place where S_DAX needs to be changed to the new inode flag?
However, this would not be appropriate at this point in the series. At this
point in the series S_DAX is still set based on the mount option and I'm 99%
sure that only happens on regular files, not directories. So I'm confused now.
This is, AFAICS, not going to affect correctness. It will only be confusing
because the user will be able to set both DAX and encryption on the directory
but files there will only see encryption being used... :-(
Assuming you are correct about this call path only being valid on directories.
It seems this IS_DAX() needs to be changed to check for EXT4_DAX_FL in
"fs/ext4: Introduce DAX inode flag"? Then at that point we can prevent DAX and
encryption on a directory. ... and at
Re: [PATCH v2] drm/exynos: dsi: Remove bridge node reference in error handling path in probe function
20. 5. 16. 오후 7:57에 Christophe JAILLET 이(가) 쓴 글:
> 'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'.
> This must be released in the error handling path.
Picked it up.
Thanks,
Inki Dae
>
> In order to do that, add an error handling path and move the
> 'exynos_dsi_parse_dt()' call from the beginning to the end of the probe
> function to ease the error handling path.
> This function only sets some variables which are used only in the
> 'transfer' function.
>
> The call chain is:
>.transfer
> --> exynos_dsi_host_transfer
> --> exynos_dsi_init
> --> exynos_dsi_enable_clock (use burst_clk_rate and esc_clk_rate)
> --> exynos_dsi_set_pll (use pll_clk_rate)
>
> While at it, also handle cases where 'component_add()' fails.
>
> This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge
> node reference in removal")
> which fixed the issue in the remove function.
>
> Signed-off-by: Christophe JAILLET
> ---
> A Fixes tag could be required, but I've not been able to figure out which
> one to use.
>
> v2: move around 'exynos_dsi_parse_dt' instead of adding many gotos
> handle component_add failures
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 902938d2568f..a9d24402fabf 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1759,10 +1759,6 @@ static int exynos_dsi_probe(struct platform_device
> *pdev)
> dsi->dev = dev;
> dsi->driver_data = of_device_get_match_data(dev);
>
> - ret = exynos_dsi_parse_dt(dsi);
> - if (ret)
> - return ret;
> -
> dsi->supplies[0].supply = "vddcore";
> dsi->supplies[1].supply = "vddio";
> ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
> @@ -1823,11 +1819,25 @@ static int exynos_dsi_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> + ret = exynos_dsi_parse_dt(dsi);
> + if (ret)
> + return ret;
> +
> platform_set_drvdata(pdev, >encoder);
>
> pm_runtime_enable(dev);
>
> - return component_add(dev, _dsi_component_ops);
> + ret = component_add(dev, _dsi_component_ops);
> + if (ret)
> + goto err_disable_runtime;
> +
> + return 0;
> +
> +err_disable_runtime:
> + pm_runtime_disable(dev);
> + of_node_put(dsi->in_bridge_node);
> +
> + return ret;
> }
>
> static int exynos_dsi_remove(struct platform_device *pdev)
>
[GIT PULL] exfat fixes for 5.7-rc7
Hi Linus, This is exfat fixes pull request for v5.7-rc7. I add description of this pull request on below. Please pull exfat with following fixes. Thanks! The following changes since commit b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce: Linux 5.7-rc6 (2020-05-17 16:48:37 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git tags/for-5.7-rc7 for you to fetch changes up to 94182167ec730dadcaea5fbc6bb8f1136966ef66: exfat: fix possible memory leak in exfat_find() (2020-05-18 11:51:44 +0900) Description for this pull request: - Fix potential memory leak in exfat_find. - Set exfat's splice_write to iter_file_splice_write to fix the splice failure on direct-opened file Eric Sandeen (1): exfat: use iter_file_splice_write Wei Yongjun (1): exfat: fix possible memory leak in exfat_find() fs/exfat/file.c | 13 +++-- fs/exfat/namei.c | 1 + 2 files changed, 8 insertions(+), 6 deletions(-)
linux-next: build failure after merge of the keys tree
Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_read':
big_key.c:(.text+0x562): undefined reference to `chacha20poly1305_decrypt'
x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_preparse':
big_key.c:(.text+0x825): undefined reference to `chacha20poly1305_encrypt'
Caused by commit
e0a715753a88 ("security/keys: rewrite big_key crypto to use library
interface")
I have used the version from next-20200512 again tdoay.
--
Cheers,
Stephen Rothwell
pgpNUjVU01j40.pgp
Description: OpenPGP digital signature
Re: [PATCH] staging: qlge: unmap dma when lock failed
On 2020-05-17 13:46 +0800, Xiangyang Zhang wrote:
> DMA not unmapped when lock failed, this patch fixed it.
>
Fixes: 4322c5bee85e ("qlge: Expand coverage of hw lock for config register.")
> Signed-off-by: Xiangyang Zhang
> ---
> drivers/staging/qlge/qlge_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Re: [PATCH] kvm: x86: Use KVM CPU capabilities to determine CR4 reserved bits
On 5/6/2020 5:44 PM, Paolo Bonzini wrote: Using CPUID data can be useful for the processor compatibility check, but that's it. Using it to compute guest-reserved bits can have both false positives (such as LA57 and UMIP which we are already handling) and false negatives: in particular, with this patch we don't allow anymore a KVM guest to set CR4.PKE when CR4.PKE is clear on the host. A common question about whether a feature can be exposed to guest: Given a feature, there is a CPUID bit to enumerate it, and a CR4 bit to turn it on/off. Whether the feature can be exposed to guest only depends on host CR4 setting? I.e., if CPUID bit is not cleared in cpu_data in host but host kernel doesn't set the corresponding CR4 bit to turn it on, we cannot expose the feature to guest. right?
Re: [PATCH v3 3/5] serial: 8250: Support separate rs485 rx-enable GPIO
On Sun, May 17, 2020 at 11:56:08PM +0200, Heiko Stuebner wrote:
> @@ -1457,6 +1458,7 @@ void serial8250_em485_stop_tx(struct uart_8250_port *p)
>* Enable previously disabled RX interrupts.
>*/
> if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
> + gpiod_set_value(port->rs485_re_gpio, 1);
> serial8250_clear_and_reinit_fifos(p);
>
> p->ier |= UART_IER_RLSI | UART_IER_RDI;
The added line needs to be conditional on if (port->rs485_re_gpio)
because the gpiod could be NULL and gpiod_set_value() doesn't check
for that.
> @@ -1597,9 +1599,12 @@ static inline void __start_tx(struct uart_port *port)
> void serial8250_em485_start_tx(struct uart_8250_port *up)
> {
> unsigned char mcr = serial8250_in_MCR(up);
> + struct uart_port *port = >port;
>
> - if (!(up->port.rs485.flags & SER_RS485_RX_DURING_TX))
> + if (!(up->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
> + gpiod_set_value(port->rs485_re_gpio, 0);
> serial8250_stop_rx(>port);
> + }
Same here.
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -253,6 +253,7 @@ struct uart_port {
> const struct attribute_group **tty_groups; /* all attributes
> (serial core use only) */
> struct serial_rs485 rs485;
> struct gpio_desc*rs485_term_gpio; /* enable RS485 bus
> termination */
> + struct gpio_desc*rs485_re_gpio; /* gpio RS485 receive
> enable */
Nit: I'd probably document this as "enable RS485 receiver" because it's
already apparent from the variable type and name that it's a gpio,
making it unnecessary to repeat that in the code comment. But I guess
that's a matter of personal preference.
There's something else: You need to amend serial8250_em485_config()
to toggle the GPIO depending on whether SER_RS485_RX_DURING_TX is
set. Right now you enable the receiver by default and then disable
it when starting to transmit if half-duplex mode is selected and
likewise re-enable it when stopping to transmit. But user space
may write some stuff to the tty while in half-duplex mode, then
immediately issue a TIOCSRS485 ioctl to switch to full-duplex mode.
If the ->rs485_config callback is executed while transmitting is
still ongoing, then you'll not re-enable the receiver when transmitting
finally stops. The ->rs485_config callback is invoked under the
uart port spinlock but the lock may be briefly released and later
re-acquired by the IRQ handler if the TX FIFO is full. (Unless
I'm missing something.)
Thanks,
Lukas
[PATCH] selftests/exec: Verify execve of non-regular files fail
Add a named pipe as an exec target to make sure that non-regular
files are rejected by execve() with EACCES. This can help verify
commit 73601ea5b7b1 ("fs/open.c: allow opening only regular files
during execve()").
Signed-off-by: Kees Cook
---
tools/testing/selftests/exec/.gitignore | 1 +
tools/testing/selftests/exec/Makefile | 2 +-
tools/testing/selftests/exec/execveat.c | 8
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/exec/.gitignore
b/tools/testing/selftests/exec/.gitignore
index c078ece12ff0..94b02a18f230 100644
--- a/tools/testing/selftests/exec/.gitignore
+++ b/tools/testing/selftests/exec/.gitignore
@@ -9,3 +9,4 @@ execveat.ephemeral
execveat.denatured
/recursion-depth
*
+pipe
diff --git a/tools/testing/selftests/exec/Makefile
b/tools/testing/selftests/exec/Makefile
index 9e31e365..cfafa1f8a2fa 100644
--- a/tools/testing/selftests/exec/Makefile
+++ b/tools/testing/selftests/exec/Makefile
@@ -4,7 +4,7 @@ CFLAGS += -Wno-nonnull
CFLAGS += -D_GNU_SOURCE
TEST_GEN_PROGS := execveat
-TEST_GEN_FILES := execveat.symlink execveat.denatured script subdir
+TEST_GEN_FILES := execveat.symlink execveat.denatured script subdir pipe
# Makefile is a run-time dependency, since it's accessed by the execveat test
TEST_FILES := Makefile
diff --git a/tools/testing/selftests/exec/execveat.c
b/tools/testing/selftests/exec/execveat.c
index cbb6efbdb786..67bf7254a48f 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
@@ -5,7 +5,9 @@
* Selftests for execveat(2).
*/
+#ifndef _GNU_SOURCE
#define _GNU_SOURCE /* to get O_PATH, AT_EMPTY_PATH */
+#endif
#include
#include
#include
@@ -311,6 +313,10 @@ static int run_tests(void)
fail += check_execveat_fail(AT_FDCWD, fullname_symlink,
AT_SYMLINK_NOFOLLOW, ELOOP);
+ /* Non-regular file failure */
+ fail += check_execveat_fail(dot_dfd, "pipe", 0, EACCES);
+ unlink("pipe");
+
/* Shell script wrapping executable file: */
/* dfd + path */
fail += check_execveat(subdir_dfd, "../script", 0);
@@ -384,6 +390,8 @@ static void prerequisites(void)
fd = open("subdir.ephemeral/script", O_RDWR|O_CREAT|O_TRUNC, 0755);
write(fd, script, strlen(script));
close(fd);
+
+ mkfifo("pipe", 0755);
}
int main(int argc, char **argv)
--
2.20.1
--
Kees Cook
[PATCH] ASoC: amd: raven: Make the driver name consistent across files
This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
With this patch:
$find /sys/devices -name modalias -print0 | xargs -0 grep -i acp3x
/sys/devices/pci:00/:00:08.1/:03:00.5/acp3x_i2s_playcap.2/
modalias:platform:acp3x_i2s_playcap
/sys/devices/pci:00/:00:08.1/:03:00.5/acp3x_i2s_playcap.0/
modalias:platform:acp3x_i2s_playcap
/sys/devices/pci:00/:00:08.1/:03:00.5/acp3x_rv_i2s_dma.0/
modalias:platform:acp3x_rv_i2s_dma
/sys/devices/pci:00/:00:08.1/:03:00.5/acp3x_i2s_playcap.1/
modalias:platform:acp3x_i2s_playcap
Signed-off-by: Akshu Agrawal
---
Resending the patch https://patchwork.kernel.org/patch/11355713/
sound/soc/amd/raven/acp3x-i2s.c | 6 +++---
sound/soc/amd/raven/acp3x-pcm-dma.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/amd/raven/acp3x-i2s.c b/sound/soc/amd/raven/acp3x-i2s.c
index f160d35a6832..a532e01a2622 100644
--- a/sound/soc/amd/raven/acp3x-i2s.c
+++ b/sound/soc/amd/raven/acp3x-i2s.c
@@ -15,7 +15,7 @@
#include "acp3x.h"
-#define DRV_NAME "acp3x-i2s"
+#define DRV_NAME "acp3x_i2s_playcap"
static int acp3x_i2s_set_fmt(struct snd_soc_dai *cpu_dai,
unsigned int fmt)
@@ -269,7 +269,7 @@ static struct snd_soc_dai_ops acp3x_i2s_dai_ops = {
};
static const struct snd_soc_component_driver acp3x_dai_component = {
- .name = "acp3x-i2s",
+ .name = DRV_NAME,
};
static struct snd_soc_dai_driver acp3x_i2s_dai = {
@@ -348,4 +348,4 @@ module_platform_driver(acp3x_dai_driver);
MODULE_AUTHOR("vishnuvardhanrao.ravulap...@amd.com");
MODULE_DESCRIPTION("AMD ACP 3.x PCM Driver");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:" DRV_NAME);
+MODULE_ALIAS("platform:"DRV_NAME);
diff --git a/sound/soc/amd/raven/acp3x-pcm-dma.c
b/sound/soc/amd/raven/acp3x-pcm-dma.c
index a36c5cb848cd..620b568bc414 100644
--- a/sound/soc/amd/raven/acp3x-pcm-dma.c
+++ b/sound/soc/amd/raven/acp3x-pcm-dma.c
@@ -15,7 +15,7 @@
#include "acp3x.h"
-#define DRV_NAME "acp3x-i2s-audio"
+#define DRV_NAME "acp3x_rv_i2s_dma"
static const struct snd_pcm_hardware acp3x_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
@@ -542,4 +542,4 @@ MODULE_AUTHOR("maruthi.bayyavar...@amd.com");
MODULE_AUTHOR("vijendar.muku...@amd.com");
MODULE_DESCRIPTION("AMD ACP 3.x PCM Driver");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:" DRV_NAME);
+MODULE_ALIAS("platform:"DRV_NAME);
--
2.17.1
RE: [PATCH] ALSA: pcm: fix incorrect hw_base increase
> > I tried to imagine a negative impact for this hw_ptr_jiffies update when the > DMA position is not updated from the driver and I haven't found any so far. > > Let's apply this and we'll see in future :-) > > And yes, the patch description should be improved (DMA ptr is not updated / > streaming is inactive). > > Reviewed-by: Jaroslav Kysela Hi Jaroslav and Takashi, Thank you for the review. Patch V2 has been uploaded. Regards, Brent > > > > > > > thanks, > > > > Takashi > > > > > -- > Jaroslav Kysela > Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
[PATCH v2] ALSA: pcm: fix incorrect hw_base increase
There is a corner case that ALSA keeps increasing the hw_ptr but DMA
already stop working/updating the position for a long time.
In following log we can see the position returned from DMA driver does
not move at all but the hw_ptr got increased at some point of time so
snd_pcm_avail() will return a large number which seems to be a buffer
underrun event from user space program point of view. The program
thinks there is space in the buffer and fill more data.
[ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554
...
[ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362
[ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
[ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368
This is because the hw_base will be increased by runtime->buffer_size
frames unconditionally if the hw_ptr is not updated for over half of
buffer time. As the hw_base increases, so does the hw_ptr increased
by the same number.
The avail value returned from snd_pcm_avail() could exceed the limit
(buffer_size) easily becase the hw_ptr itself got increased by same
buffer_size samples when the corner case happens. In following log,
the buffer_size is 16368 samples but the avail is 21810 samples so
CRAS server complains about it.
[ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442
[ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810
cras_server[1907]: pcm_avail returned frames larger than buf_size:
sof-glkda7219max: :0,5: 21810 > 16368
By updating runtime->hw_ptr_jiffies each time the HWSYNC is called,
the hw_base will keep the same when buffer stall happens at long as
the interval between each HWSYNC call is shorter than half of buffer
time.
Following is a log captured by a patched kernel. The hw_base/hw_ptr
value is fixed in this corner case and user space program should be
aware of the buffer stall and handle it.
[ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584
[ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488
[ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392
[ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
...
[ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
Signed-off-by: Brent Lu
---
sound/core/pcm_lib.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 872a852..d531e1b 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -433,6 +433,7 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream
*substream,
no_delta_check:
if (runtime->status->hw_ptr == new_hw_ptr) {
+ runtime->hw_ptr_jiffies = curr_jiffies;
update_audio_tstamp(substream, _tstamp, _tstamp);
return 0;
}
--
2.7.4
Re: [PATCH V3 07/15] arch/kunmap_atomic: Consolidate duplicate code
On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote: > On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote: > > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@intel.com wrote: > > > From: Ira Weiny > > > > > > Every single architecture (including !CONFIG_HIGHMEM) calls... > > > > > > pagefault_enable(); > > > preempt_enable(); > > > > > > ... before returning from __kunmap_atomic(). Lift this code into the > > > kunmap_atomic() macro. > > > > > > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to > > > be consistent. > > > > > > Reviewed-by: Christoph Hellwig > > > Signed-off-by: Ira Weiny > > > > This patch results in: > > > > Starting init: /bin/sh exists but couldn't execute it (error -14) > > > > when trying to boot microblazeel:petalogix-ml605 in qemu. > > Thanks for the report. I'm not readily seeing the issue. > > Do you have a kernel config? Specifically is CONFIG_HIGHMEM set? > See below. Yes, CONFIG_HIGHMEM is set. The scripts used to build and boot the image are at: https://github.com/groeck/linux-build-test/tree/master/rootfs/microblazeel Hope this helps, Guenter --- CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_AUDIT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_BLK_DEV_INITRD=y # CONFIG_BASE_FULL is not set CONFIG_KALLSYMS_ALL=y CONFIG_EMBEDDED=y CONFIG_SLAB=y CONFIG_KERNEL_BASE_ADDR=0x5000 CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1 CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR=1 CONFIG_XILINX_MICROBLAZE0_USE_BARREL=1 CONFIG_XILINX_MICROBLAZE0_USE_DIV=1 CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL=2 CONFIG_XILINX_MICROBLAZE0_USE_FPU=2 CONFIG_XILINX_MICROBLAZE0_HW_VER="10.0.a" CONFIG_HZ_100=y CONFIG_MMU=y CONFIG_HIGHMEM=y CONFIG_PCI_XILINX=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y # CONFIG_EFI_PARTITION is not set CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IPV6 is not set CONFIG_BRIDGE=m CONFIG_PCI=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_CFI_AMDSTD=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_NETDEVICES=y CONFIG_XILINX_EMACLITE=y CONFIG_XILINX_LL_TEMAC=y # CONFIG_INPUT is not set # CONFIG_SERIO is not set # CONFIG_VT is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_UARTLITE=y CONFIG_SERIAL_UARTLITE_CONSOLE=y # CONFIG_HW_RANDOM is not set CONFIG_XILINX_HWICAP=y CONFIG_I2C=y CONFIG_I2C_XILINX=y CONFIG_SPI=y CONFIG_SPI_XILINX=y CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_XILINX=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_XILINX_WATCHDOG=y CONFIG_FB=y CONFIG_FB_XILINX=y # CONFIG_USB_SUPPORT is not set CONFIG_UIO=y CONFIG_UIO_PDRV_GENIRQ=y CONFIG_UIO_DMEM_GENIRQ=y CONFIG_EXT2_FS=y # CONFIG_DNOTIFY is not set CONFIG_CRAMFS=y CONFIG_ROMFS_FS=y CONFIG_NFS_FS=y CONFIG_CIFS=y CONFIG_CIFS_STATS2=y CONFIG_ENCRYPTED_KEYS=y CONFIG_DEBUG_INFO=y CONFIG_KGDB=y CONFIG_KGDB_TESTS=y CONFIG_KGDB_KDB=y CONFIG_DEBUG_SLAB=y CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_SPINLOCK=y
linux-next: build failure after merge of the mmc tree
Hi all,
After merging the mmc tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/mmc/host/meson-mx-sdhc-clkc.o
see include/linux/module.h for more information
ERROR: modpost: "meson_mx_sdhc_register_clkc"
[drivers/mmc/host/meson-mx-sdhc.ko] undefined!
Caused by commit
53ded1b676d1 ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson
SDHC host")
I have used the mmc tree from next-20200515 for today.
--
Cheers,
Stephen Rothwell
pgpO8nbVUCcQ8.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 09/10] arm64: efi: Export screen_info
On 5/13/20 7:56 PM, Nikhil Mahale wrote: > On 3/20/20 3:16 AM, Michael Kelley wrote: >> From: Arnd Bergmann Sent: Wednesday, March 18, 2020 2:27 AM >>> >>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley >>> wrote: From: Arnd Bergmann > On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley > wrote: >> >> The Hyper-V frame buffer driver may be built as a module, and >> it needs access to screen_info. So export screen_info. >> >> Signed-off-by: Michael Kelley > > Is there any chance of using a more modern KMS based driver for the screen > than the old fbdev subsystem? I had hoped to one day completely remove > support for the old CONFIG_VIDEO_FBDEV and screen_info from modern > architectures. > The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V frame buffer device. That driver builds and runs on both ARM64 and x86. I'm not knowledgeable about video/graphics drivers, but when you say "a more modern KMS based driver", are you meaning one based on DRM & KMS? Does DRM make sense for a "dumb" frame buffer device? Are there any drivers that would be a good pattern to look at? >>> >>> It used to be a lot harder to write a DRM driver compared to an fbdev >>> driver, but this has changed to the opposite over the years. >>> >>> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c >>> or anything in drivers/gpu/drm/tiny/, but you may want to look at the >>> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c, >>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c, >>> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c. >>> >> >> Thanks for the pointers, especially for the other hypervisors. >> > Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times. > I had configured by email client incorrectly to reply. > > screen_info is still useful with a modern KMS-based driver. It exposes > the mode parameters that the GOP driver chose. This information is > needed to implement seamless or glitchless boot, by both ensuring that > the scanout parameters don't change and being able to read back the > scanout image to populate the initial contents of the new surface. > > This works today on arches which implement (U)EFI and export > screen_info, including x86 and powerpc, but doesn't work on arm or > arm64. As arm64 systems that implement UEFI with real GOP drivers > become more prevalent, it would be nice to be have these features there > as well. In addition to this, even if a driver doesn't implement a framebuffer console, or if it does but has an option to disable it, the driver still needs to know whether the EFI console is using resources on the GPU so it can avoid clobbering them. For example screen_info provides information like offset and size of EFI console, using this information driver can reserve memory used by console and prevent corruption on it. I think arm64 should export screen_info. > Thanks, > Nikhil Mahale > >> Michael >>
Re: [RFC PATCH v3 1/2] arm64: tlb: Detect the ARMv8.4 TLBI RANGE feature
On 05/11/2020 05:55 PM, Zhenyu Ye wrote:
> On 2020/5/5 18:14, Mark Rutland wrote:
>> On Tue, Apr 14, 2020 at 07:28:34PM +0800, Zhenyu Ye wrote:
>>> ARMv8.4-TLBI provides TLBI invalidation instruction that apply to a
>>> range of input addresses. This patch detect this feature.
>>>
>>> Signed-off-by: Zhenyu Ye
>>> ---
>>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>>> arch/arm64/include/asm/sysreg.h | 4
>>> arch/arm64/kernel/cpufeature.c | 11 +++
>>> 3 files changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/include/asm/cpucaps.h
>>> b/arch/arm64/include/asm/cpucaps.h
>>> index 8eb5a088ae65..950095a72617 100644
>>> --- a/arch/arm64/include/asm/cpucaps.h
>>> +++ b/arch/arm64/include/asm/cpucaps.h
>>> @@ -61,7 +61,8 @@
>>> #define ARM64_HAS_AMU_EXTN 51
>>> #define ARM64_HAS_ADDRESS_AUTH 52
>>> #define ARM64_HAS_GENERIC_AUTH 53
>>> +#define ARM64_HAS_TLBI_RANGE 54
>>>
>>> -#define ARM64_NCAPS54
>>> +#define ARM64_NCAPS55
>>>
>>> #endif /* __ASM_CPUCAPS_H */
>>> diff --git a/arch/arm64/include/asm/sysreg.h
>>> b/arch/arm64/include/asm/sysreg.h
>>> index ebc622432831..ac1b98650234 100644
>>> --- a/arch/arm64/include/asm/sysreg.h
>>> +++ b/arch/arm64/include/asm/sysreg.h
>>> @@ -592,6 +592,7 @@
>>>
>>> /* id_aa64isar0 */
>>> #define ID_AA64ISAR0_RNDR_SHIFT60
>>> +#define ID_AA64ISAR0_TLBI_RANGE_SHIFT 56
>>> #define ID_AA64ISAR0_TS_SHIFT 52
>>> #define ID_AA64ISAR0_FHM_SHIFT 48
>>> #define ID_AA64ISAR0_DP_SHIFT 44
>>> @@ -605,6 +606,9 @@
>>> #define ID_AA64ISAR0_SHA1_SHIFT8
>>> #define ID_AA64ISAR0_AES_SHIFT 4
>>>
>>> +#define ID_AA64ISAR0_TLBI_RANGE_NI 0x0
>>> +#define ID_AA64ISAR0_TLBI_RANGE0x2
>>> +
>>> /* id_aa64isar1 */
>>> #define ID_AA64ISAR1_I8MM_SHIFT52
>>> #define ID_AA64ISAR1_DGH_SHIFT 48
>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>> index 9fac745aa7bb..31bcfd0722b5 100644
>>> --- a/arch/arm64/kernel/cpufeature.c
>>> +++ b/arch/arm64/kernel/cpufeature.c
>>> @@ -124,6 +124,7 @@ static bool __system_matches_cap(unsigned int n);
>>> */
>>> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
>>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>>> ID_AA64ISAR0_RNDR_SHIFT, 4, 0),
>>> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>>> ID_AA64ISAR0_TLBI_RANGE_SHIFT, 4, 0),
Hello Zhenyu,
This is already being added through another patch [1] in a series [2] which
primarily
has cpufeature changes. I will soon update the series making this feature
FTR_HIDDEN.
[1] https://patchwork.kernel.org/patch/11523881/
[2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=281211
I am planning to respin the series (V4) based on arm64 tree
(for-next/cpufeature). So
could you please rebase this patch (probably dropping cpufeature related
changes) on
upcoming V4, so that all the changes will be based on arm64 tree
(for-next/cpufeature).
- Anshuman
Re: [PATCH v5] hugetlbfs: Get unmapped area below TASK_UNMAPPED_BASE for hugetlbfs
On 5/16/20 12:47 AM, Hushijie wrote: >> On 5/14/20 7:31 AM, Shijie Hu wrote: >>> + if (mm->get_unmapped_area == arch_get_unmapped_area) >>> + return hugetlb_get_unmapped_area_bottomup(file, addr, len, >>> + pgoff, flags); >>> + return hugetlb_get_unmapped_area_topdown(file, addr, len, >>> + pgoff, flags); >> >> I like this code using the value of mm->get_unmapped_area to determine >> which routine to call. It is used by a few architectures. However, I >> noticed that on at least one architecture (powerpc) mm->get_unmapped_area >> may be assigned to routines other than arch_get_unmapped_area or >> arch_get_unmapped_area_topdown. In such a case, we would call the 'new' >> topdown routine. I would prefer that we call the bottomup routine in this >> default case. >> >> In reality, this does not impact powerpc as that architecture has it's >> own hugetlb_get_unmapped_area routine. >> > > Yes, I also noticed this before, powerpc uses > radix__arch_get_unmapped_area*() > when CONFIG_PPC_RADIX_MMU opened as 'y' and radix_enabled() returns > true. However, powerpc implemented its own hugetlb_get_unmapped_area(). This > patch actually has no effect on powerpc. > >> Because of this, I suggest we add a comment above this code and switch >> the if/else order. For example, >> >> + /* >> +* Use mm->get_unmapped_area value as a hint to use topdown routine. >> +* If architectures have special needs, they should define their own >> +* version of hugetlb_get_unmapped_area. >> +*/ >> + if (mm->get_unmapped_area == arch_get_unmapped_area_topdown) >> + return hugetlb_get_unmapped_area_topdown(file, addr, len, >> + pgoff, flags); >> + return hugetlb_get_unmapped_area_bottomup(file, addr, len, >> + pgoff, flags); >> >> Thoughts? >> -- >> Mike Kravetz >> > I agree with you. It's clever to switch the if/else order. If there is such > a case, mm->get_unmapped_area() is neihter arch_get_unmapped_area() nor > arch_get_unmapped_area_topdown(), it is indeed more appropriate to make the > bottomup routine as the default behavior. > > May I put this code and comment you show above into patch v6 and add > "Signed-off-by: Mike Kravetz " to it? Feel free to add this code and my Signed-off-by. I assume this still works for your use case. Correct? -- Mike Kravetz
Nice to Meet you
How are you and your family? my name is Prashant Wong Lin, i am a native of Hong Kong but resides and a citizen of United Kingdom. I work with an Oil and Gas Company here in London, tell me about you? Your work etc -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[PATCH] drivers/mic/scif: convert get_user_pages() --> pin_user_pages()
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
Note that this effectively changes the code's behavior as well: it now
ultimately calls set_page_dirty_lock(), instead of SetPageDirty(). This
is probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [3]
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
[3] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Signed-off-by: John Hubbard
---
Hi,
Note that I have only compile-tested this patch, although that does
also include cross-compiling for a few other arches.
thanks,
John Hubbard
NVIDIA
drivers/misc/mic/scif/scif_rma.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/misc/mic/scif/scif_rma.c b/drivers/misc/mic/scif/scif_rma.c
index 01e27682ea30..406cd5abfa72 100644
--- a/drivers/misc/mic/scif/scif_rma.c
+++ b/drivers/misc/mic/scif/scif_rma.c
@@ -113,14 +113,17 @@ static int scif_destroy_pinned_pages(struct
scif_pinned_pages *pin)
int writeable = pin->prot & SCIF_PROT_WRITE;
int kernel = SCIF_MAP_KERNEL & pin->map_flags;
- for (j = 0; j < pin->nr_pages; j++) {
- if (pin->pages[j] && !kernel) {
- if (writeable)
- SetPageDirty(pin->pages[j]);
- put_page(pin->pages[j]);
+ if (kernel) {
+ for (j = 0; j < pin->nr_pages; j++) {
+ if (pin->pages[j] && !kernel) {
+ if (writeable)
+ set_page_dirty_lock(pin->pages[j]);
+ put_page(pin->pages[j]);
+ }
}
- }
-
+ } else
+ unpin_user_pages_dirty_lock(pin->pages, pin->nr_pages,
+ writeable);
scif_free(pin->pages,
pin->nr_pages * sizeof(*pin->pages));
scif_free(pin, sizeof(*pin));
@@ -1375,7 +1378,7 @@ int __scif_pin_pages(void *addr, size_t len, int
*out_prot,
}
}
- pinned_pages->nr_pages = get_user_pages_fast(
+ pinned_pages->nr_pages = pin_user_pages_fast(
(u64)addr,
nr_pages,
(prot & SCIF_PROT_WRITE) ? FOLL_WRITE : 0,
@@ -1385,11 +1388,8 @@ int __scif_pin_pages(void *addr, size_t len, int
*out_prot,
if (ulimit)
__scif_dec_pinned_vm_lock(mm, nr_pages);
/* Roll back any pinned pages */
- for (i = 0; i < pinned_pages->nr_pages; i++) {
- if (pinned_pages->pages[i])
- put_page(
- pinned_pages->pages[i]);
- }
+ unpin_user_pages(pinned_pages->pages,
+pinned_pages->nr_pages);
prot &= ~SCIF_PROT_WRITE;
try_upgrade = false;
goto retry;
--
2.26.2
Re:Re: Re:Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong format
发件人：Liviu Dudau
发送日期：2020-05-15 22:41:49
收件人：Bernard
抄送人：Brian Starkey ,David Airlie
,Daniel Vetter
,dri-de...@lists.freedesktop.org,linux-kernel@vger.kernel.org,opensource.ker...@vivo.com
主题：Re: Re:Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong
format>Hi Bernard,
>
>On Fri, May 08, 2020 at 04:47:17PM +0800, Bernard wrote:
>> From: "赵军奎"
>> Date: 2020-04-24 19:37:36
>> To: Liviu Dudau
>> Cc: Brian Starkey ,David Airlie
>> ,Daniel Vetter
>> ,dri-de...@lists.freedesktop.org,linux-kernel@vger.kernel.org,opensource.ker...@vivo.com
>> Subject: Re:Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong
>> format
>>
>>
>>
>>
>> From: Liviu Dudau
>> Date: 2020-04-24 19:09:50
>> To: Bernard Zhao
>> Cc: Brian Starkey ,David Airlie
>> ,Daniel Vetter
>> ,dri-de...@lists.freedesktop.org,linux-kernel@vger.kernel.org,opensource.ker...@vivo.com
>> Subject: Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong
>> format>Hi Bernand,
>> >
>> >On Thu, Apr 23, 2020 at 11:35:51PM -0700, Bernard Zhao wrote:
>> >> The pixel clock is still enabled when the format is wrong.
>> >> no error branch handle, and also some register is not set
>> >> in this case, e.g: HDLCD_REG__SELECT. Maybe we
>> >> should disable this clock and throw an warn message when
>> >> this happened.
>> >> With this change, the code maybe a bit more readable.
>> >>
>> >> Signed-off-by: Bernard Zhao
>> >>
>> >> Changes since V1:
>> >> *add format error handle, if format is not correct, throw
>> >> an warning message and disable this clock.
>> >>
>> >> Link for V1:
>> >> *https://lore.kernel.org/patchwork/patch/1228501/
>> >> ---
>> >> drivers/gpu/drm/arm/hdlcd_crtc.c | 13 +
>> >> 1 file changed, 9 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
>> >> b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> >> index af67fefed38d..f3945dee2b7d 100644
>> >> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
>> >> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> >> @@ -96,7 +96,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>> >> }
>> >>
>> >> if (WARN_ON(!format))
>> >> - return 0;
>> >> + return -EINVAL;
>> >
>> >That is the right fix!
>> >
>> >>
>> >> /* HDLCD uses 'bytes per pixel', zero means 1 byte */
>> >> btpp = (format->bits_per_pixel + 7) / 8;
>> >> @@ -125,7 +125,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>> >> return 0;
>> >> }
>> >>
>> >> -static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
>> >> +static int hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
>> >
>> >But this is not. We don't need to propagate the error further, just
>> >
>> >> {
>> >> struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>> >> struct drm_display_mode *m = >state->adjusted_mode;
>> >> @@ -162,9 +162,10 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc
>> >> *crtc)
>> >>
>> >> err = hdlcd_set_pxl_fmt(crtc);
>> >> if (err)
>> >> - return;
>> >
>>
>> My previous understanding was that when such an exception occurred, it was
>> caught
>> in the atomic_enable interface, and then disable pixel clock. I am not sure
>> is this ok or
>> i have to do more register clean operaction.
>>
>> >... return here so that we don't call clk_set_rate();
>> And for this part, i am a little confused :
>> 1 clk_set_rate must be set even if format is wrong?
>> 2 The original code logic shows that If format is not correct, we will not
>> set registers
>> HDLCD_REG_PIXEL_FORMAT & HDLCD_REG__SELECT, will this bring in
>> any problems?
>> 3 if 1 the rate must set & 2 registers above doesn`t matter, then maybe
>> there is no
>> need to disable pixel clock.
>> Am i misunderstanding
>
>You are right, the pixel format check should not happen inside
>hdlcd_crtc_atomic_enable()
>hook, it should be moved into a separate function hdlcd_crtc_atomic_check()
>and that needs
>to be hooked into .atomic_check() for hdlcd_crtc_helper_funcs().
>
>If you want to have another go I'll be happy to review and Ack your patch.
>
>Best regards,
>Liviu
>
Hi
Sure, i will check this and re-subbmit one patch.
Regards,
Bernard
>>
>> Regards,
>> Bernard
>>
>> >> + return err;
>> >>
>> >> clk_set_rate(hdlcd->clk, m->crtc_clock * 1000);
>> >> + return 0;
>> >> }
>> >>
>> >> static void hdlcd_crtc_atomic_enable(struct drm_crtc *crtc,
>> >> @@ -173,7 +174,11 @@ static void hdlcd_crtc_atomic_enable(struct drm_crtc
>> >> *crtc,
>> >> struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>> >>
>> >> clk_prepare_enable(hdlcd->clk);
>> >> - hdlcd_crtc_mode_set_nofb(crtc);
>> >> + if (hdlcd_crtc_mode_set_nofb(crtc)) {
>> >> + DRM_DEBUG_KMS("Invalid format, pixel clock enable failed!\n");
>> >> + clk_disable_unprepare(hdlcd->clk);
>> >> + return;
>> >> + }
>> >> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
>> >> drm_crtc_vblank_on(crtc);
>> >> }
>> >> --
>> >> 2.26.2
>> >>
>> >
>> >--
>>
Re: [PATCH v5 01/10] input: elants: document some registers and values
On Sun, Apr 26, 2020 at 07:47:49PM +0200, Michał Mirosław wrote: > Add information found in downstream kernels, to make the code less > magic. > > Signed-off-by: Michał Mirosław > Reviewed-by: Dmitry Osipenko > Tested-by: Dmitry Osipenko > --- > drivers/input/touchscreen/elants_i2c.c | 29 +- > 1 file changed, 24 insertions(+), 5 deletions(-) > > diff --git a/drivers/input/touchscreen/elants_i2c.c > b/drivers/input/touchscreen/elants_i2c.c > index 2289f9638116..d2175fb6209a 100644 > --- a/drivers/input/touchscreen/elants_i2c.c > +++ b/drivers/input/touchscreen/elants_i2c.c > @@ -81,7 +81,11 @@ > > #define HEADER_REPORT_10_FINGER 0x62 > > -/* Header (4 bytes) plus 3 fill 10-finger packets */ > +/* Power state */ > +#define PWR_STATE_DEEP_SLEEP 0 > +#define PWR_STATE_NORMAL 1 > + > +/* Header (4 bytes) plus 3 full 10-finger packets */ > #define MAX_PACKET_SIZE 169 > > #define BOOT_TIME_DELAY_MS 50 > @@ -91,10 +95,21 @@ > #define E_ELAN_INFO_BC_VER 0x10 > #define E_ELAN_INFO_TEST_VER 0xE0 > #define E_ELAN_INFO_FW_ID0xF0 > +#define E_POWER_MODE 0x40 > +#define E_POWER_STATE0x50 > +#define E_INFO_X_RES 0x60 > +#define E_INFO_Y_RES 0x63 I would prefer if we introduced these in the patches that use them. > #define E_INFO_OSR 0xD6 > #define E_INFO_PHY_SCAN 0xD7 > #define E_INFO_PHY_DRIVER0xD8 > > +/* FW write command, 0x54 0x?? 0x0, 0x01 */ > +#define E_POWER_MODE_BATTERY 0x40 > +#define E_POWER_MODE_AC 0x41 > +#define E_POWER_MODE_USB 0x42 What is this for? > +#define E_POWER_STATE_SLEEP 0x50 > +#define E_POWER_STATE_RESUME 0x58 Thanks. -- Dmitry
Re: [PATCH v5 07/10] input: elants: support 0x66 reply opcode for reporting touches
On Sun, Apr 26, 2020 at 07:47:52PM +0200, Michał Mirosław wrote: > From: Dmitry Osipenko > > eKTF3624 touchscreen firmware uses two variants of the reply opcodes for > reporting touch events: one is 0x63 (used by older firmware) and other is > 0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of > eKTH3500, while 0x63 needs small adjustment of the touch pressure value. > > Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for > reporting touch events, let's support it now. Other devices, eg. ASUS TF300T, > use 0x63. > > Note: CMD_HEADER_REK is used for replying to calibration requests, it has > the same 0x66 opcode number which eKTF3624 uses for reporting touches. > The calibration replies are handled separately from the the rest of the > commands in the driver by entering into ELAN_WAIT_RECALIBRATION state > and thus this change shouldn't change the old behavior. Is it possible to know what format a device will use by querying it at probe time? Thanks. -- Dmitry
Re: [PATCH v5 05/10] input: elants: refactor elants_i2c_execute_command()
On Sun, Apr 26, 2020 at 07:47:51PM +0200, Michał Mirosław wrote: > Apply some DRY-ing to elants_i2c_execute_command() callers. This pulls > polling and error printk()s into a single function. > > Signed-off-by: Michał Mirosław Applied, thank you. -- Dmitry
Re: [PATCH v5 04/10] input: elants: override touchscreen info with DT properties
On Sun, Apr 26, 2020 at 07:47:51PM +0200, Michał Mirosław wrote: > Allow overriding of information from hardware and support additional > common DT properties like axis inversion. This is required for eg. > Nexus 7 and TF300T where the programmed values in firmware differ > from reality. > > Signed-off-by: Dmitry Osipenko > [moved "prop" before DMA buffer] > Signed-off-by: Michał Mirosław Applied, thank you. -- Dmitry
Re: [RESEND][V5 PATCH 2/2] ASoC: max98390: Added Amplifier Driver
Hi Steve,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v5.7-rc6 next-20200515]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Steve-Lee/dt-bindings-Added-device-tree-binding-for-max98390/20200518-085308
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
for-next
config: i386-randconfig-a004-20200518 (attached as .config)
compiler: gcc-4.9 (Ubuntu 4.9.3-13ubuntu2) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from include/linux/dynamic_debug.h:6:0,
from include/linux/printk.h:326,
from include/linux/kernel.h:15,
from include/linux/list.h:9,
from include/linux/kobject.h:19,
from include/linux/of.h:17,
from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from sound/soc/codecs/max98390.c:9:
sound/soc/codecs/max98390.c: In function 'max98390_dsm_init':
>> include/linux/jump_label.h:471:59: warning: format '%ld' expects argument of
>> type 'long int', but argument 4 has type 'size_t' [-Wformat=]
else if (__builtin_types_compatible_p(typeof(*x), struct static_key_false))
^
include/linux/dynamic_debug.h:105:2: note: in expansion of macro
'static_branch_unlikely'
static_branch_unlikely(_key_false)
^
include/linux/dynamic_debug.h:124:6: note: in expansion of macro
'DYNAMIC_DEBUG_BRANCH'
if (DYNAMIC_DEBUG_BRANCH(id))^
include/linux/dynamic_debug.h:143:2: note: in expansion of macro
'__dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^
include/linux/dynamic_debug.h:157:2: note: in expansion of macro
'_dynamic_func_call'
_dynamic_func_call(fmt,__dynamic_dev_dbg,^
include/linux/dev_printk.h:114:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
^
sound/soc/codecs/max98390.c:780:2: note: in expansion of macro 'dev_dbg'
dev_dbg(component->dev,
^
vim +471 include/linux/jump_label.h
11276d5306b8e5 Peter Zijlstra 2015-07-24 465
11276d5306b8e5 Peter Zijlstra 2015-07-24 466 #define
static_branch_unlikely(x)\
11276d5306b8e5 Peter Zijlstra 2015-07-24 467 ({
\
11276d5306b8e5 Peter Zijlstra 2015-07-24 468 bool branch;
\
11276d5306b8e5 Peter Zijlstra 2015-07-24 469 if
(__builtin_types_compatible_p(typeof(*x), struct static_key_true)) \
11276d5306b8e5 Peter Zijlstra 2015-07-24 470 branch =
arch_static_branch_jump(&(x)->key, false); \
11276d5306b8e5 Peter Zijlstra 2015-07-24 @471 else if
(__builtin_types_compatible_p(typeof(*x), struct static_key_false)) \
11276d5306b8e5 Peter Zijlstra 2015-07-24 472 branch =
arch_static_branch(&(x)->key, false); \
11276d5306b8e5 Peter Zijlstra 2015-07-24 473 else
\
11276d5306b8e5 Peter Zijlstra 2015-07-24 474 branch =
wrong_branch_error(); \
81dcf89f03204d Peter Zijlstra 2018-01-18 475 unlikely(branch);
\
11276d5306b8e5 Peter Zijlstra 2015-07-24 476 })
11276d5306b8e5 Peter Zijlstra 2015-07-24 477
:: The code at line 471 was first introduced by commit
:: 11276d5306b8e5b438a36bbff855fe792d7eaa61 locking/static_keys: Add a new
static_key interface
:: TO: Peter Zijlstra
:: CC: Ingo Molnar
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v3 4/4] watchdog: move watchdog sysctl interface to watchdog.c
Move watchdog syscl interface to watchdog.c.
Use register_sysctl() to register the sysctl interface to avoid
merge conflicts when different features modify sysctl.c at the same time.
Signed-off-by: Xiaoming Ni
Reviewed-by: Kees Cook
---
kernel/sysctl.c | 96 ---
kernel/watchdog.c | 101 ++
2 files changed, 101 insertions(+), 96 deletions(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 90e3ea8..cd85a1c 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -97,9 +97,6 @@
#ifdef CONFIG_STACKLEAK_RUNTIME_DISABLE
#include
#endif
-#ifdef CONFIG_LOCKUP_DETECTOR
-#include
-#endif
#if defined(CONFIG_SYSCTL)
@@ -120,9 +117,6 @@
#endif
/* Constants used for minimum and maximum */
-#ifdef CONFIG_LOCKUP_DETECTOR
-static int sixty = 60;
-#endif
static unsigned long zero_ul;
static unsigned long one_ul = 1;
@@ -883,96 +877,6 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.mode = 0444,
.proc_handler = proc_dointvec,
},
-#if defined(CONFIG_LOCKUP_DETECTOR)
- {
- .procname = "watchdog",
- .data = _user_enabled,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_watchdog,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- },
- {
- .procname = "watchdog_thresh",
- .data = _thresh,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_watchdog_thresh,
- .extra1 = SYSCTL_ZERO,
- .extra2 = ,
- },
- {
- .procname = "nmi_watchdog",
- .data = _watchdog_user_enabled,
- .maxlen = sizeof(int),
- .mode = NMI_WATCHDOG_SYSCTL_PERM,
- .proc_handler = proc_nmi_watchdog,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- },
- {
- .procname = "watchdog_cpumask",
- .data = _cpumask_bits,
- .maxlen = NR_CPUS,
- .mode = 0644,
- .proc_handler = proc_watchdog_cpumask,
- },
-#ifdef CONFIG_SOFTLOCKUP_DETECTOR
- {
- .procname = "soft_watchdog",
- .data = _watchdog_user_enabled,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_soft_watchdog,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- },
- {
- .procname = "softlockup_panic",
- .data = _panic,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_minmax,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- },
-#ifdef CONFIG_SMP
- {
- .procname = "softlockup_all_cpu_backtrace",
- .data = _softlockup_all_cpu_backtrace,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_minmax,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- },
-#endif /* CONFIG_SMP */
-#endif
-#ifdef CONFIG_HARDLOCKUP_DETECTOR
- {
- .procname = "hardlockup_panic",
- .data = _panic,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_minmax,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- },
-#ifdef CONFIG_SMP
- {
- .procname = "hardlockup_all_cpu_backtrace",
- .data = _hardlockup_all_cpu_backtrace,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_minmax,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- },
-#endif /* CONFIG_SMP */
-#endif
-#endif
-
#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86)
{
.procname = "unknown_nmi_panic",
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index b6b1f54..8c833b6 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -756,6 +756,106 @@ int proc_watchdog_cpumask(struct ctl_table *table, int
write,
mutex_unlock(_mutex);
return err;
}
+
+static const int sixty = 60;
+
+static struct ctl_table watchdog_sysctls[]
[PATCH v3 0/4] cleaning up the sysctls table (hung_task watchdog)
Kernel/sysctl.c contains more than 190 interface files, and there are a
large number of config macro controls. When modifying the sysctl
interface directly in kernel/sysctl.c, conflicts are very easy to occur.
E.g: https://lkml.org/lkml/2020/5/10/413.
Use register_sysctl() to register the sysctl interface to avoid
merge conflicts when different features modify sysctl.c at the same time.
So consider cleaning up the sysctls table, details are in:
https://kernelnewbies.org/KernelProjects/proc
https://lkml.org/lkml/2020/5/13/990
The current patch set extracts register_sysctl_init and some sysctl_vals
variables, and clears the interface of hung_task and watchdog in sysctl.c.
The current patch set is based on commit b9bbe6ed63b2b9 ("Linux 5.7-rc6"),
which conflicts with the latest branch of linux-next:
9b4caf6941fc41d ("kernel / hung_task.c: introduce sysctl to print
all traces when a hung task is detected")
Should I modify to make patch based on the "linux-next" branch to avoid
conflicts, or other branches?
changes in v3:
1. make hung_task_timeout_max to be const
2. fix build warning:
kernel/watchdog.c:779:14: warning: initialization discards 'const'
qualifier from pointer target type [-Wdiscarded-qualifiers]
.extra2 = ,
^
V2: https://lkml.org/lkml/2020/5/16/81
changes in v2:
1. Adjusted the order of patches, first do public function
extraction, then do feature code movement
2. Move hung_task sysctl to hung_task.c instead of adding new file
3. Extract multiple common variables instead of only neg_one, and keep
the order of member values in sysctl_vals
4. Add const modification to the variable sixty in watchdog sysctl
V1: https://lkml.org/lkml/2020/5/15/17
Xiaoming Ni (4):
sysctl: Add register_sysctl_init() interface
sysctl: Move some boundary constants form sysctl.c to sysctl_vals
hung_task: Move hung_task sysctl interface to hung_task.c
watchdog: move watchdog sysctl interface to watchdog.c
fs/proc/proc_sysctl.c| 2 +-
include/linux/sched/sysctl.h | 8 +-
include/linux/sysctl.h | 13 ++-
kernel/hung_task.c | 63 +-
kernel/sysctl.c | 202 ---
kernel/watchdog.c| 101 ++
6 files changed, 210 insertions(+), 179 deletions(-)
--
1.8.5.6
[PATCH v3 3/4] hung_task: Move hung_task sysctl interface to hung_task.c
Move hung_task sysctl interface to hung_task.c.
Use register_sysctl() to register the sysctl interface to avoid
merge conflicts when different features modify sysctl.c at the same time.
Signed-off-by: Xiaoming Ni
Reviewed-by: Kees Cook
---
include/linux/sched/sysctl.h | 8 +-
kernel/hung_task.c | 63 +++-
kernel/sysctl.c | 50 ---
3 files changed, 63 insertions(+), 58 deletions(-)
diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index d4f6215..c075e09 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -7,14 +7,8 @@
struct ctl_table;
#ifdef CONFIG_DETECT_HUNG_TASK
-extern int sysctl_hung_task_check_count;
-extern unsigned int sysctl_hung_task_panic;
+/* used for hung_task and block/ */
extern unsigned long sysctl_hung_task_timeout_secs;
-extern unsigned long sysctl_hung_task_check_interval_secs;
-extern int sysctl_hung_task_warnings;
-extern int proc_dohung_task_timeout_secs(struct ctl_table *table, int write,
-void __user *buffer,
-size_t *lenp, loff_t *ppos);
#else
/* Avoid need for ifdefs elsewhere in the code */
enum { sysctl_hung_task_timeout_secs = 0 };
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index 14a625c..d010c96 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -215,10 +215,11 @@ static long hung_timeout_jiffies(unsigned long
last_checked,
MAX_SCHEDULE_TIMEOUT;
}
+#ifdef CONFIG_SYSCTL
/*
* Process updating of timeout sysctl
*/
-int proc_dohung_task_timeout_secs(struct ctl_table *table, int write,
+static int proc_dohung_task_timeout_secs(struct ctl_table *table, int write,
void __user *buffer,
size_t *lenp, loff_t *ppos)
{
@@ -235,6 +236,65 @@ int proc_dohung_task_timeout_secs(struct ctl_table *table,
int write,
return ret;
}
+/*
+ * This is needed for proc_doulongvec_minmax of sysctl_hung_task_timeout_secs
+ * and hung_task_check_interval_secs
+ */
+static const unsigned long hung_task_timeout_max = (LONG_MAX / HZ);
+static struct ctl_table hung_task_sysctls[] = {
+ {
+ .procname = "hung_task_panic",
+ .data = _hung_task_panic,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ },
+ {
+ .procname = "hung_task_check_count",
+ .data = _hung_task_check_count,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ },
+ {
+ .procname = "hung_task_timeout_secs",
+ .data = _hung_task_timeout_secs,
+ .maxlen = sizeof(unsigned long),
+ .mode = 0644,
+ .proc_handler = proc_dohung_task_timeout_secs,
+ .extra2 = (void *)_task_timeout_max,
+ },
+ {
+ .procname = "hung_task_check_interval_secs",
+ .data = _hung_task_check_interval_secs,
+ .maxlen = sizeof(unsigned long),
+ .mode = 0644,
+ .proc_handler = proc_dohung_task_timeout_secs,
+ .extra2 = (void *)_task_timeout_max,
+ },
+ {
+ .procname = "hung_task_warnings",
+ .data = _hung_task_warnings,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = SYSCTL_NEG_ONE,
+ },
+ {}
+};
+
+static void __init hung_task_sysctl_init(void)
+{
+ register_sysctl_init("kernel", hung_task_sysctls, "hung_task_sysctls");
+}
+#else
+#define hung_task_sysctl_init() do { } while (0)
+#endif
+
+
static atomic_t reset_hung_task = ATOMIC_INIT(0);
void reset_hung_task_detector(void)
@@ -304,6 +364,7 @@ static int __init hung_task_init(void)
pm_notifier(hungtask_pm_notify, 0);
watchdog_task = kthread_run(watchdog, NULL, "khungtaskd");
+ hung_task_sysctl_init();
return 0;
}
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 76c3237..90e3ea8 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -144,13 +144,6 @@
static int ngroups_max = NGROUPS_MAX;
static const int cap_last_cap = CAP_LAST_CAP;
-/*
- * This is needed for proc_doulongvec_minmax of sysctl_hung_task_timeout_secs
- * and hung_task_check_interval_secs
- */
-#ifdef CONFIG_DETECT_HUNG_TASK
-static unsigned long
[PATCH v3 1/4] sysctl: Add register_sysctl_init() interface
In order to eliminate the duplicate code for registering the sysctl
interface during the initialization of each feature, add the
register_sysctl_init() interface
Signed-off-by: Xiaoming Ni
Reviewed-by: Kees Cook
---
include/linux/sysctl.h | 2 ++
kernel/sysctl.c| 19 +++
2 files changed, 21 insertions(+)
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 02fa844..43f8ef9 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -206,6 +206,8 @@ struct ctl_table_header *register_sysctl_paths(const struct
ctl_path *path,
void unregister_sysctl_table(struct ctl_table_header * table);
extern int sysctl_init(void);
+extern void register_sysctl_init(const char *path, struct ctl_table *table,
+const char *table_name);
extern struct ctl_table sysctl_mount_point[];
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8a176d8..c96122f 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1968,6 +1968,25 @@ int __init sysctl_init(void)
return 0;
}
+/*
+ * The sysctl interface is used to modify the interface value,
+ * but the feature interface has default values. Even if register_sysctl fails,
+ * the feature body function can also run. At the same time, malloc small
+ * fragment of memory during the system initialization phase, almost does
+ * not fail. Therefore, the function return is designed as void
+ */
+void __init register_sysctl_init(const char *path, struct ctl_table *table,
+const char *table_name)
+{
+ struct ctl_table_header *hdr = register_sysctl(path, table);
+
+ if (unlikely(!hdr)) {
+ pr_err("failed when register_sysctl %s to %s\n", table_name,
path);
+ return;
+ }
+ kmemleak_not_leak(hdr);
+}
+
#endif /* CONFIG_SYSCTL */
/*
--
1.8.5.6
[PATCH v3 2/4] sysctl: Move some boundary constants form sysctl.c to sysctl_vals
Some boundary (.extra1 .extra2) constants (E.g: neg_one two) in
sysctl.c are used in multiple features. Move these variables to
sysctl_vals to avoid adding duplicate variables when cleaning up
sysctls table.
Signed-off-by: Xiaoming Ni
Reviewed-by: Kees Cook
---
fs/proc/proc_sysctl.c | 2 +-
include/linux/sysctl.h | 11 ---
kernel/sysctl.c| 37 -
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index b6f5d45..3f77e64 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -23,7 +23,7 @@
static const struct inode_operations proc_sys_dir_operations;
/* shared constants to be used in various sysctls */
-const int sysctl_vals[] = { 0, 1, INT_MAX };
+const int sysctl_vals[] = { -1, 0, 1, 2, 4, 100, 1000, INT_MAX };
EXPORT_SYMBOL(sysctl_vals);
/* Support for permanently empty directories */
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 43f8ef9..bf97c30 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -38,9 +38,14 @@
struct ctl_dir;
/* Keep the same order as in fs/proc/proc_sysctl.c */
-#define SYSCTL_ZERO((void *)_vals[0])
-#define SYSCTL_ONE ((void *)_vals[1])
-#define SYSCTL_INT_MAX ((void *)_vals[2])
+#define SYSCTL_NEG_ONE ((void *)_vals[0])
+#define SYSCTL_ZERO((void *)_vals[1])
+#define SYSCTL_ONE ((void *)_vals[2])
+#define SYSCTL_TWO ((void *)_vals[3])
+#define SYSCTL_FOUR((void *)_vals[4])
+#define SYSCTL_ONE_HUNDRED ((void *)_vals[5])
+#define SYSCTL_ONE_THOUSAND((void *)_vals[6])
+#define SYSCTL_INT_MAX ((void *)_vals[7])
extern const int sysctl_vals[];
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c96122f..76c3237 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -124,14 +124,9 @@
static int sixty = 60;
#endif
-static int __maybe_unused neg_one = -1;
-static int __maybe_unused two = 2;
-static int __maybe_unused four = 4;
static unsigned long zero_ul;
static unsigned long one_ul = 1;
static unsigned long long_max = LONG_MAX;
-static int one_hundred = 100;
-static int one_thousand = 1000;
#ifdef CONFIG_PRINTK
static int ten_thousand = 1;
#endif
@@ -547,7 +542,7 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
- .extra1 = _one,
+ .extra1 = SYSCTL_NEG_ONE,
.extra2 = SYSCTL_ONE,
},
#endif
@@ -878,7 +873,7 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.mode = 0644,
.proc_handler = proc_dointvec_minmax_sysadmin,
.extra1 = SYSCTL_ZERO,
- .extra2 = ,
+ .extra2 = SYSCTL_TWO,
},
#endif
{
@@ -1187,7 +1182,7 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.mode = 0644,
.proc_handler = perf_cpu_time_max_percent_handler,
.extra1 = SYSCTL_ZERO,
- .extra2 = _hundred,
+ .extra2 = SYSCTL_ONE_HUNDRED,
},
{
.procname = "perf_event_max_stack",
@@ -1205,7 +1200,7 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.mode = 0644,
.proc_handler = perf_event_max_stack_handler,
.extra1 = SYSCTL_ZERO,
- .extra2 = _thousand,
+ .extra2 = SYSCTL_ONE_THOUSAND,
},
#endif
{
@@ -1280,7 +1275,7 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
.extra1 = SYSCTL_ZERO,
- .extra2 = ,
+ .extra2 = SYSCTL_TWO,
},
{
.procname = "panic_on_oom",
@@ -1289,7 +1284,7 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
.extra1 = SYSCTL_ZERO,
- .extra2 = ,
+ .extra2 = SYSCTL_TWO,
},
{
.procname = "oom_kill_allocating_task",
@@ -1334,7 +1329,7 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.mode = 0644,
.proc_handler = dirty_background_ratio_handler,
.extra1 = SYSCTL_ZERO,
- .extra2 = _hundred,
+ .extra2 = SYSCTL_ONE_HUNDRED,
},
{
.procname = "dirty_background_bytes",
@@ -1351,7 +1346,7 @@ static
Re: [PATCH] clk/ti/adpll: Add a NULL check for devm_kasprintf()
On Mon, 2020-05-18 at 03:46 +, Xu Wang wrote:
> devm_kasprintf() may fail, so we should better add a NULL check
> and propagate an error on failure.
You didn't compile this.
All the return values of this function are already checked.
> Signed-off-by: Xu Wang
> ---
> drivers/clk/ti/adpll.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
> index bb2f283..f18a672 100644
> --- a/drivers/clk/ti/adpll.c
> +++ b/drivers/clk/ti/adpll.c
> @@ -196,6 +196,8 @@ static const char *ti_adpll_clk_get_name(struct
> ti_adpll_data *d,
> } else {
> name = devm_kasprintf(d->dev, GFP_KERNEL, "%08lx.adpll.%s",
> d->pa, postfix);
> + if (!name)
> + return -ENOMEM;
> }
>
> return name;
Re: [PATCH] block: Remove unused flush_queue_delayed in struct blk_flush_queue
On Sun, May 17, 2020 at 7:51 PM Baolin Wang wrote:
>
> The flush_queue_delayed was introdued to hold queue if flush is
> running for non-queueable flush drive by commit 3ac0cc450870
> ("hold queue if flush is running for non-queueable flush drive"),
> but the non mq parts of the flush code had been removed by
> commit 7e992f847a08 ("block: remove non mq parts from the flush code"),
> as well as removing the usage of the flush_queue_delayed flag.
> Thus remove the unused flush_queue_delayed flag.
>
> Signed-off-by: Baolin Wang
> ---
> block/blk-flush.c | 1 -
> block/blk.h | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/block/blk-flush.c b/block/blk-flush.c
> index c7f396e3d5e2..b733f7ac75c7 100644
> --- a/block/blk-flush.c
> +++ b/block/blk-flush.c
> @@ -258,7 +258,6 @@ static void flush_end_io(struct request *flush_rq,
> blk_status_t error)
> blk_flush_complete_seq(rq, fq, seq, error);
> }
>
> - fq->flush_queue_delayed = 0;
> spin_unlock_irqrestore(>mq_flush_lock, flags);
> }
>
> diff --git a/block/blk.h b/block/blk.h
> index fc00537026a0..6cab33a11f90 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -19,7 +19,6 @@ extern struct dentry *blk_debugfs_root;
> #endif
>
> struct blk_flush_queue {
> - unsigned intflush_queue_delayed:1;
> unsigned intflush_pending_idx:1;
> unsigned intflush_running_idx:1;
> blk_status_trq_status;
> --
> 2.17.1
>
Reviewed-by: Ming Lei
--
Ming Lei
Re: [PATCH V3 07/15] arch/kunmap_atomic: Consolidate duplicate code
On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> On Thu, May 07, 2020 at 07:59:55AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Every single architecture (including !CONFIG_HIGHMEM) calls...
> >
> > pagefault_enable();
> > preempt_enable();
> >
> > ... before returning from __kunmap_atomic(). Lift this code into the
> > kunmap_atomic() macro.
> >
> > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> > be consistent.
> >
> > Reviewed-by: Christoph Hellwig
> > Signed-off-by: Ira Weiny
>
> This patch results in:
>
> Starting init: /bin/sh exists but couldn't execute it (error -14)
>
> when trying to boot microblazeel:petalogix-ml605 in qemu.
Thanks for the report. I'm not readily seeing the issue.
Do you have a kernel config? Specifically is CONFIG_HIGHMEM set?
>
> Bisect log attached.
>
> Guenter
>
> ---
> # bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific
> files for 20200515
> # good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
> git bisect start 'HEAD' 'v5.7-rc5'
> # good: [3674d7aa7a8e61d993886c2fb7c896c5ef85e988] Merge remote-tracking
> branch 'crypto/master'
> git bisect good 3674d7aa7a8e61d993886c2fb7c896c5ef85e988
> # good: [87f6f21783522e6d62127cf33ae5e95f50874beb] Merge remote-tracking
> branch 'spi/for-next'
> git bisect good 87f6f21783522e6d62127cf33ae5e95f50874beb
> # good: [5c428e8277d5d97c85126387d4e00aa5adde4400] Merge remote-tracking
> branch 'staging/staging-next'
> git bisect good 5c428e8277d5d97c85126387d4e00aa5adde4400
> # good: [f68de67ed934e7bdef4799fdc86f33f14982] Merge remote-tracking
> branch 'hyperv/hyperv-next'
> git bisect good f68de67ed934e7bdef4799fdc86f33f14982
> # bad: [54acd2dc52b069da59639eea0d0c92726f32fb01] mm/memblock: fix a typo in
> comment "implict"->"implicit"
> git bisect bad 54acd2dc52b069da59639eea0d0c92726f32fb01
> # good: [784a17aa58a529b84f7cc50f351ed4acf3bd11f3] mm: remove the pgprot
> argument to __vmalloc
> git bisect good 784a17aa58a529b84f7cc50f351ed4acf3bd11f3
> # good: [6cd8137ff37e9a37aee2d2a8889c8beb8eab192f] khugepaged: replace the
> usage of system(3) in the test
> git bisect good 6cd8137ff37e9a37aee2d2a8889c8beb8eab192f
> # bad: [6987da379826ed01b8a1cf046b67cc8cc10117cc] sparc: remove unnecessary
> includes
> git bisect bad 6987da379826ed01b8a1cf046b67cc8cc10117cc
> # good: [bc17b545388f64c09e83e367898e28f60277c584] mm/hugetlb: define a
> generic fallback for is_hugepage_only_range()
> git bisect good bc17b545388f64c09e83e367898e28f60277c584
> # bad: [9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011]
> arch-kmap_atomic-consolidate-duplicate-code-checkpatch-fixes
> git bisect bad 9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011
> # good: [0941a38ff0790c1004270f952067a5918a4ba32d] arch/kmap: remove
> redundant arch specific kmaps
> git bisect good 0941a38ff0790c1004270f952067a5918a4ba32d
> # good: [56e635a64c2cbfa815c851af10e0f811e809977b]
> arch-kunmap-remove-duplicate-kunmap-implementations-fix
> git bisect good 56e635a64c2cbfa815c851af10e0f811e809977b
> # bad: [60f96b2233c790d4f1c49317643051f1670bcb29] arch/kmap_atomic:
> consolidate duplicate code
> git bisect bad 60f96b2233c790d4f1c49317643051f1670bcb29
> # good: [7b3708dc3bf72a647243064fe7ddf9a76248ddfd]
> {x86,powerpc,microblaze}/kmap: move preempt disable
> git bisect good 7b3708dc3bf72a647243064fe7ddf9a76248ddfd
> # first bad commit: [60f96b2233c790d4f1c49317643051f1670bcb29]
> arch/kmap_atomic: consolidate duplicate code
I'm confused by this. This points to an earlier commit being bad?
commit 60f96b2233c790d4f1c49317643051f1670bcb29
Author: Ira Weiny
Date: Thu May 14 13:39:54 2020 +1000
arch/kmap_atomic: consolidate duplicate code
Every arch has the same code to ensure atomic operations and a check for
!HIGHMEM page.
Remove the duplicate code by defining a core kmap_atomic() which only
calls the arch specific kmap_atomic_high() when the page is high memory.
Link: http://lkml.kernel.org/r/20200507150004.1423069-7-ira.we...@intel.com
Signed-off-by: Ira Weiny
Reviewed-by: Christoph Hellwig
Cc: Al Viro
Cc: Andy Lutomirski
Cc: Benjamin Herrenschmidt
Cc: Borislav Petkov
[PATCH] clk/ti/adpll: Add a NULL check for devm_kasprintf()
devm_kasprintf() may fail, so we should better add a NULL check
and propagate an error on failure.
Signed-off-by: Xu Wang
---
drivers/clk/ti/adpll.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
index bb2f283..f18a672 100644
--- a/drivers/clk/ti/adpll.c
+++ b/drivers/clk/ti/adpll.c
@@ -196,6 +196,8 @@ static const char *ti_adpll_clk_get_name(struct
ti_adpll_data *d,
} else {
name = devm_kasprintf(d->dev, GFP_KERNEL, "%08lx.adpll.%s",
d->pa, postfix);
+ if (!name)
+ return -ENOMEM;
}
return name;
--
2.7.4
RE: [PATCH] tty: serial: fsl_lpuart: Use __maybe_unused instead of #if CONFIG_PM_SLEEP
> From: Anson Huang
> Sent: Friday, May 15, 2020 8:58 PM
>
> Use __maybe_unused for power management related functions to simplify the
> code.
>
> Signed-off-by: Anson Huang
Reviewed-by: Dong Aisheng
Regards
Aisheng
> ---
> drivers/tty/serial/fsl_lpuart.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/fsl_lpuart.c
> b/drivers/tty/serial/fsl_lpuart.c index
> 6a9909e..cca485d 100644
> --- a/drivers/tty/serial/fsl_lpuart.c
> +++ b/drivers/tty/serial/fsl_lpuart.c
> @@ -2662,8 +2662,7 @@ static int lpuart_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int lpuart_suspend(struct device *dev)
> +static int __maybe_unused lpuart_suspend(struct device *dev)
> {
> struct lpuart_port *sport = dev_get_drvdata(dev);
> unsigned long temp;
> @@ -2721,7 +2720,7 @@ static int lpuart_suspend(struct device *dev)
> return 0;
> }
>
> -static int lpuart_resume(struct device *dev)
> +static int __maybe_unused lpuart_resume(struct device *dev)
> {
> struct lpuart_port *sport = dev_get_drvdata(dev);
> bool irq_wake = irqd_is_wakeup_set(irq_get_irq_data(sport->port.irq));
> @@ -2752,7 +2751,6 @@ static int lpuart_resume(struct device *dev)
>
> return 0;
> }
> -#endif
>
> static SIMPLE_DEV_PM_OPS(lpuart_pm_ops, lpuart_suspend, lpuart_resume);
>
> --
> 2.7.4
RE: [patch v2 1/2] ls1043ardb: add qe node to ls1043ardb
On Wed, Apr 29, 2020 at 04:20:51PM +0800, Shawn Guo wrote:
> -Original Message-
> From: Shawn Guo
> Sent: 2020年5月17日 22:10
> To: Qiang Zhao
> Cc: Leo Li ; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [patch v2 1/2] ls1043ardb: add qe node to ls1043ardb
>
> On Wed, Apr 29, 2020 at 04:20:51PM +0800, Qiang Zhao wrote:
> > From: Zhao Qiang
> >
> > Add qe node to fsl-ls1043a.dtsi and fsl-ls1043a-rdb.dts
> >
> > Signed-off-by: Zhao Qiang
>
> Subject prefix should be like 'arm64: dts: ...'
>
>
> > ---
> > v2:
> > - add commit msg and drop a new blank line
> >
> > arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++
> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 65
> +++
> > 2 files changed, 81 insertions(+)
> >
> > + compatible = "fsl,qe", "simple-bus";
> > + ranges = <0x0 0x0 0x240 0x4>;
> > + reg = <0x0 0x240 0x0 0x480>;
> > + brg-frequency = <1>;
> > + bus-frequency = <2>;
> > + fsl,qe-num-riscs = <1>;
> > + fsl,qe-num-snums = <28>;
> > +
> > + qeic: qeic@80 {
> > + compatible = "fsl,qe-ic";
> > + reg = <0x80 0x80>;
> > + #address-cells = <0>;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + interrupts = <0 77 0x04 0 77 0x04>;
>
> Two identical interrupts?
Thank you for comments.
On some boards for QE, There are two different interrupts.
And On others, there is only one interrupt.
In order to make it compatible, QE interrupts used to be wrote like this.
The driver also handle the situation like this.
Best Regards
Qiang Zhao
RE: [PATCH] dt-bindings: interrupt-controller: Convert imx irqsteer to json-schema
...
> +
> +title: Freescale IRQSTEER Interrupt multiplexer
> +
> +maintainers:
> + - Lucas Stach
> +
> +properties:
> + compatible:
> +const: fsl,imx-irqsteer
You changed binding here without comments?
Regards
Aisheng
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +description: |
> + should contain the up to 8 parent interrupt lines used to multiplex
> + the input interrupts. They should be specified sequentially from
> + output 0 to 7.
> +items:
> + - description: irqsteer channel 0
> + - description: irqsteer channel 1
> + - description: irqsteer channel 2
> + - description: irqsteer channel 3
> + - description: irqsteer channel 4
> + - description: irqsteer channel 5
> + - description: irqsteer channel 6
> + - description: irqsteer channel 7
> +minItems: 1
> +maxItems: 8
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names:
> +const: ipg
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> +const: 1
> +
> + fsl,channel:
> +$ref: '/schemas/types.yaml#/definitions/uint32'
> +description: |
> + u32 value representing the output channel that all input IRQs should be
> + steered into.
> +
> + fsl,num-irqs:
> +$ref: '/schemas/types.yaml#/definitions/uint32'
> +description: |
> + u32 value representing the number of input interrupts of this channel,
> + should be multiple of 32 input interrupts and up to 512 interrupts.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - interrupt-controller
> + - "#interrupt-cells"
> + - fsl,channel
> + - fsl,num-irqs
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +interrupt-controller@32e2d000 {
> +compatible = "fsl,imx-irqsteer";
> +reg = <0x32e2d000 0x1000>;
> +interrupts = ;
> +clocks = < IMX8MQ_CLK_DISP_APB_ROOT>;
> +clock-names = "ipg";
> +fsl,channel = <0>;
> +fsl,num-irqs = <64>;
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +};
> --
> 2.7.4
Re: [PATCH v5 03/10] input: elants: remove unused axes
On Sun, Apr 26, 2020 at 07:47:50PM +0200, Michał Mirosław wrote: > Driver only ever reports MT events and input_mt_init_slots() sets up > emulated axes already. Clear the capabilities not generated directly > and move MT axes setup, so they are visible by input_mt_init_slots(). > > Signed-off-by: Michał Mirosław > Reviewed-by: Dmitry Osipenko > Tested-by: Dmitry Osipenko Applied, thank you. -- Dmitry
Re: mm/memory.c: Add update local tlb for smp race
On 05/16/2020 05:34 PM, maobibo wrote:
>
>
> On 05/15/2020 09:50 PM, David Hildenbrand wrote:
>> On 14.05.20 08:50, Bibo Mao wrote:
>>> If there are two threads hitting page fault at the address, one
>>> thread updates pte entry and local tlb, the other thread can update
>>> local tlb also, rather than give up and let page fault happening
>>> again.
>>
>> Let me suggest
>>
>> "mm/memory: optimize concurrent page faults at same address
>>
>> If two threads concurrently fault at the same address, the thread that
>> won the race updates the PTE and its local TLB. For now, the other
>> thread gives up, simply does nothing, and continues.
>>
>> It could happen that this second thread triggers another fault, whereby
>> it only updates its local TLB while handling the fault. Instead of
>> triggering another fault, let's directly update the local TLB of the
>> second thread.
>> "
>>
>> If I got the intention of this patch correctly.
>>
>> Are there any performance numbers to support this patch?
>>
>> (I can't say too much about the correctness and/or usefulness of this patch)
>
> yes, that is the situation. On MIPS platform software can update TLB,
> so update_mmu_cache is used here. This does not happen frequently, and with
> the three series patches in later mail. I test lat_pagefault in lmbench, here
> is is result:
>
> with these three series patches,
> # ./lat_pagefault -N 10 /tmp/1
> Pagefaults on /tmp/1: 1.4973 microseconds
> # ./lat_pagefault -P 4 -N 10 /tmp/1
> Pagefaults on /tmp/1: 1.5716 microseconds
>
> original version, without these three series patch
> # ./lat_pagefault -N 10 /tmp/1
> Pagefaults on /tmp/1: 1.6489 microseconds
> # ./lat_pagefault -P 4 -N 10 /tmp/1
> Pagefaults on /tmp/1: 1.7214 microseconds
>
I tested the three patches one by one, there is no obvious improvement with
lat_pagefault case, I guess that it happens seldom where multiple threads access
the same page at the same time.
The improvement is because of another modification where pte_mkyoung is added
to get readable privilege on MIPS system.
regards
bibo, mao
>>>
>>> modified: mm/memory.c
>>
>> This does not belong into a patch description.
>
> well, I will modify the patch description.
>
> regards
> bibo,mao
>
>
>>
>>
>>> Signed-off-by: Bibo Mao
>>> ---
>>> mm/memory.c | 30 ++
>>> 1 file changed, 22 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index f703fe8..3a741ce 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -2436,11 +2436,10 @@ static inline bool cow_user_page(struct page *dst,
>>> struct page *src,
>>> if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
>>> /*
>>> * Other thread has already handled the fault
>>> -* and we don't need to do anything. If it's
>>> -* not the case, the fault will be triggered
>>> -* again on the same address.
>>> +* and update local tlb only
>>> */
>>> ret = false;
>>> + update_mmu_cache(vma, addr, vmf->pte);
>>> goto pte_unlock;
>>> }
>>>
>>> @@ -2463,8 +2462,9 @@ static inline bool cow_user_page(struct page *dst,
>>> struct page *src,
>>> vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr, >ptl);
>>> locked = true;
>>> if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
>>> - /* The PTE changed under us. Retry page fault. */
>>> + /* The PTE changed under us. update local tlb */
>>> ret = false;
>>> + update_mmu_cache(vma, addr, vmf->pte);
>>> goto pte_unlock;
>>> }
>>>
>>> @@ -2704,6 +2704,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
>>> }
>>> flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
>>> entry = mk_pte(new_page, vma->vm_page_prot);
>>> + entry = pte_mkyoung(entry);
>>> entry = maybe_mkwrite(pte_mkdirty(entry), vma);
>>> /*
>>> * Clear the pte entry and flush it first, before updating the
>>> @@ -2752,6 +2753,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
>>> new_page = old_page;
>>> page_copied = 1;
>>> } else {
>>> + update_mmu_cache(vma, vmf->address, vmf->pte);
>>> mem_cgroup_cancel_charge(new_page, memcg, false);
>>> }
>>>
>>> @@ -2812,6 +2814,7 @@ vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf)
>>> * pte_offset_map_lock.
>>> */
>>> if (!pte_same(*vmf->pte, vmf->orig_pte)) {
>>> + update_mmu_cache(vmf->vma, vmf->address, vmf->pte);
>>> pte_unmap_unlock(vmf->pte, vmf->ptl);
>>> return VM_FAULT_NOPAGE;
>>> }
>>> @@ -2936,6 +2939,7 @@ static vm_fault_t do_wp_page(struct vm_fault
Re: [PATCH] perf evsel: Get group fd from CPU0 for system wide event
Hi Jiri,
On 5/15/2020 4:33 PM, Jiri Olsa wrote:
On Fri, May 15, 2020 at 02:04:57PM +0800, Jin, Yao wrote:
SNIP
I think I get the root cause. That should be a serious bug in get_group_fd,
access violation!
For a group mixed with system-wide event and per-core event and the group
leader is system-wide event, access violation will happen.
perf_evsel__alloc_fd allocates one FD member for system-wide event (only
FD(evsel, 0, 0) is valid).
But for per core event, perf_evsel__alloc_fd allocates N FD members (N =
ncpus). For example, for ncpus is 8, FD(evsel, 0, 0) to FD(evsel, 7, 0) are
valid.
get_group_fd(struct evsel *evsel, int cpu, int thread)
{
struct evsel *leader = evsel->leader;
fd = FD(leader, cpu, thread);/* access violation may happen here */
}
If leader is system-wide event, only the FD(leader, 0, 0) is valid.
When get_group_fd accesses FD(leader, 1, 0), access violation happens.
My fix is:
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 28683b0eb738..db05b8a1e1a8 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1440,6 +1440,9 @@ static int get_group_fd(struct evsel *evsel, int cpu, int
thread)
if (evsel__is_group_leader(evsel))
return -1;
+ if (leader->core.system_wide && !evsel->core.system_wide)
+ return -2;
so this effectively stops grouping system_wide events with others,
and I think it's correct, how about events that differ in cpumask?
My understanding for the events that differ in cpumaks is, if the leader's cpumask is not fully
matched with the evsel's cpumask then we stop the grouping. Is this understanding correct?
I have done some tests and get some conclusions:
1. If the group is mixed with core and uncore events, the system_wide checking
can distinguish them.
2. If the group is mixed with core and uncore events and "-a" is specified, the system_wide for core
event is also false. So system_wide checking can distinguish them too
3. In my test, the issue only occurs when we collect the metric which is mixed with uncore event and
core event, so maybe checking the system_wide is OK.
should we perhaps ensure this before we call open? go throught all
groups and check they are on the same cpus?
The issue doesn't happen at most of the time (only for the metric consisting of uncore event and
core event), so fallback to stop grouping if call open is failed looks reasonable.
Thanks
Jin Yao
thanks,
jirka
+
/*
* Leader must be already processed/open,
* if not it's a bug.
@@ -1665,6 +1668,11 @@ static int evsel__open_cpu(struct evsel *evsel, struct
perf_cpu_map *cpus,
pid = perf_thread_map__pid(threads, thread);
group_fd = get_group_fd(evsel, cpu, thread);
+ if (group_fd == -2) {
+ errno = EINVAL;
+ err = -EINVAL;
+ goto out_close;
+ }
retry_open:
test_attr__ready();
It enables the perf_evlist__reset_weak_group. And in the second_pass (in
__run_perf_stat), the events will be opened successfully.
I have tested OK for this fix on cascadelakex.
Thanks
Jin Yao
Re: [PATCH] vhost: missing __user tags
On 2020/5/15 下午11:33, Michael S. Tsirkin wrote:
sparse warns about converting void * to void __user *. This is not new
but only got noticed now that vhost is built on more systems.
This is just a question of __user tags missing in a couple of places,
so fix it up.
Fixes: f88949138058 ("vhost: introduce O(1) vq metadata cache")
Reported-by: kbuild test robot
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index d450e16c5c25..21a59b598ed8 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -730,7 +730,7 @@ static inline void __user *vhost_vq_meta_fetch(struct
vhost_virtqueue *vq,
if (!map)
return NULL;
- return (void *)(uintptr_t)(map->addr + addr - map->start);
+ return (void __user *)(uintptr_t)(map->addr + addr - map->start);
}
/* Can we switch to this memory table? */
@@ -869,7 +869,7 @@ static void __user *__vhost_get_user_slow(struct
vhost_virtqueue *vq,
* not happen in this case.
*/
static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
- void *addr, unsigned int size,
+ void __user *addr, unsigned int
size,
int type)
{
void __user *uaddr = vhost_vq_meta_fetch(vq,
Acked-by: Jason Wang
WARNING in get_probe_ref
Hello, syzbot found the following crash on: HEAD commit:24085f70 Merge tag 'trace-v5.7-rc4' of git://git.kernel.or.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=117087fa10 kernel config: https://syzkaller.appspot.com/x/.config?x=efdde85c3af536b5 dashboard link: https://syzkaller.appspot.com/bug?extid=8672dcb9d10011c0a160 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c09dc10 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=178fa32c10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+8672dcb9d10011c0a...@syzkaller.appspotmail.com RBP: 0006 R08: 0002 R09: 02003033 R10: R11: 0246 R12: 00402f60 R13: 00402ff0 R14: R15: [ cut here ] WARNING: CPU: 0 PID: 7052 at kernel/trace/blktrace.c:1115 blk_register_tracepoints kernel/trace/blktrace.c:1115 [inline] WARNING: CPU: 0 PID: 7052 at kernel/trace/blktrace.c:1115 get_probe_ref+0x327/0x3e0 kernel/trace/blktrace.c:324 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 7052 Comm: syz-executor149 Not tainted 5.7.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:221 __warn.cold+0x2f/0x35 kernel/panic.c:582 report_bug+0x27b/0x2f0 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:175 [inline] fixup_bug arch/x86/kernel/traps.c:170 [inline] do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:267 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027 RIP: 0010:blk_register_tracepoints kernel/trace/blktrace.c:1115 [inline] RIP: 0010:get_probe_ref+0x327/0x3e0 kernel/trace/blktrace.c:324 Code: 8a e8 3d d3 fb ff 31 ff 89 c3 89 c6 e8 62 56 fa ff 85 db 0f 84 1e fd ff ff e8 e5 54 fa ff 0f 0b e9 12 fd ff ff e8 d9 54 fa ff <0f> 0b e9 45 fd ff ff e8 cd 54 fa ff 0f 0b e9 66 fd ff ff e8 c1 54 RSP: 0018:c900016a7b88 EFLAGS: 00010293 RAX: 8880953ba600 RBX: fff4 RCX: 8178dbdb RDX: RSI: 8178de97 RDI: 0005 RBP: 8880a4640700 R08: 8880953ba600 R09: fbfff133f1c1 R10: 899f8e07 R11: fbfff133f1c0 R12: 8880a019d100 R13: 888089d24a10 R14: R15: 8880a4640730 do_blk_trace_setup+0x7d3/0xb30 kernel/trace/blktrace.c:550 __blk_trace_setup+0xca/0x180 kernel/trace/blktrace.c:571 blk_trace_setup+0x43/0x60 kernel/trace/blktrace.c:589 sg_ioctl_common+0x2f8/0x2720 drivers/scsi/sg.c:1120 sg_ioctl+0x8f/0x120 drivers/scsi/sg.c:1163 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl+0x11a/0x180 fs/ioctl.c:771 __do_sys_ioctl fs/ioctl.c:780 [inline] __se_sys_ioctl fs/ioctl.c:778 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:778 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x445ca9 Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b ce fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff1c9ef988 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7fff1c9ef990 RCX: 00445ca9 RDX: 2140 RSI: c0481273 RDI: 0004 RBP: 0006 R08: 0002 R09: 02003033 R10: R11: 0246 R12: 00402f60 R13: 00402ff0 R14: R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
[QEMU RFC PATCH v4] hw/vfio/pci: remap bar region irq
Added an irq type VFIO_IRQ_TYPE_REMAP_BAR_REGION to
dynamically query and remap BAR regions.
QEMU decodes the index of the BARs by reading cnt of eventfd.
If bit n is set, the corresponding BAR will be requeried and
its subregions will be remapped according to the its new flags.
rely on [1] "vfio: Add a funtion to return a specific irq capabilities"
[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg621645.html
Signed-off-by: Yan Zhao
---
hw/vfio/common.c | 50
hw/vfio/pci.c | 90 +++
hw/vfio/pci.h | 2 +
include/hw/vfio/vfio-common.h | 2 +
linux-headers/linux/vfio.h| 11 ++
5 files changed, 155 insertions(+)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index a041c3b..cf24293 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1284,6 +1284,56 @@ void vfio_region_unmap(VFIORegion *region)
}
}
+/*
+ * re-query a region's flags,
+ * and update its mmap'd subregions.
+ * It does not support change a region's size.
+ */
+void vfio_region_reset_mmap(VFIODevice *vbasedev, VFIORegion *region, int
index)
+{
+struct vfio_region_info *new;
+
+if (!region->mem) {
+return;
+}
+
+if (vfio_get_region_info(vbasedev, index, )) {
+goto out;
+}
+
+if (region->size != new->size) {
+error_report("vfio: resetting of region size is not supported");
+goto out;
+}
+
+if (region->flags == new->flags) {
+goto out;
+}
+
+/* ummap old mmap'd subregions, if any */
+vfio_region_unmap(region);
+region->nr_mmaps = 0;
+g_free(region->mmaps);
+region->mmaps = NULL;
+
+/* setup new mmap'd subregions*/
+region->flags = new->flags;
+if (vbasedev->no_mmap ||
+!(region->flags & VFIO_REGION_INFO_FLAG_MMAP)) {
+goto out;
+}
+
+if (vfio_setup_region_sparse_mmaps(region, new)) {
+region->nr_mmaps = 1;
+region->mmaps = g_new0(VFIOMmap, region->nr_mmaps);
+region->mmaps[0].offset = 0;
+region->mmaps[0].size = region->size;
+}
+vfio_region_mmap(region);
+out:
+g_free(new);
+}
+
void vfio_region_exit(VFIORegion *region)
{
int i;
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index c70f153..12998c5 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -2883,6 +2883,94 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice
*vdev)
vdev->req_enabled = false;
}
+static void vfio_remap_bar_notifier_handler(void *opaque)
+{
+VFIOPCIDevice *vdev = opaque;
+uint64_t bars;
+ssize_t ret;
+int i;
+
+ret = read(vdev->remap_bar_notifier.rfd, , sizeof(bars));
+if (ret != sizeof(bars)) {
+return;
+}
+for (i = 0; i < PCI_ROM_SLOT; i++) {
+VFIORegion *region = >bars[i].region;
+
+if (!test_bit(i, )) {
+continue;
+}
+
+vfio_region_reset_mmap(>vbasedev, region, i);
+}
+
+/* write 0 to notify kernel that we're done */
+bars = 0;
+write(vdev->remap_bar_notifier.wfd, , sizeof(bars));
+}
+
+static void vfio_register_remap_bar_notifier(VFIOPCIDevice *vdev)
+{
+int ret;
+struct vfio_irq_info *irq;
+Error *err = NULL;
+int32_t fd;
+
+ret = vfio_get_dev_irq_info(>vbasedev,
+VFIO_IRQ_TYPE_REMAP_BAR_REGION,
+VFIO_IRQ_SUBTYPE_REMAP_BAR_REGION,
+);
+if (ret) {
+return;
+}
+ret = event_notifier_init(>remap_bar_notifier, 0);
+if (ret) {
+error_report("vfio: Failed to init event notifier for remap bar irq");
+return;
+}
+
+fd = event_notifier_get_fd(>remap_bar_notifier);
+qemu_set_fd_handler(fd, vfio_remap_bar_notifier_handler, NULL, vdev);
+
+if (vfio_set_irq_signaling(>vbasedev, irq->index, 0,
+ VFIO_IRQ_SET_ACTION_TRIGGER, fd, )) {
+error_reportf_err(err, VFIO_MSG_PREFIX, vdev->vbasedev.name);
+qemu_set_fd_handler(fd, NULL, NULL, vdev);
+event_notifier_cleanup(>remap_bar_notifier);
+} else {
+vdev->remap_bar_enabled = true;
+}
+};
+
+static void vfio_unregister_remap_bar_notifier(VFIOPCIDevice *vdev)
+{
+struct vfio_irq_info *irq;
+Error *err = NULL;
+int ret;
+
+if (!vdev->remap_bar_enabled) {
+return;
+}
+
+ret = vfio_get_dev_irq_info(>vbasedev,
+VFIO_IRQ_TYPE_REMAP_BAR_REGION,
+VFIO_IRQ_SUBTYPE_REMAP_BAR_REGION,
+);
+if (ret) {
+return;
+}
+
+if (vfio_set_irq_signaling(>vbasedev, irq->index, 0,
+ VFIO_IRQ_SET_ACTION_TRIGGER, -1, )) {
+error_reportf_err(err, VFIO_MSG_PREFIX, vdev->vbasedev.name);
+}
+qemu_set_fd_handler(event_notifier_get_fd(>remap_bar_notifier),
+NULL, NULL, vdev);
+
[RFC PATCH v4 10/10] i40e/vf_migration: vendor defined irq_type to support dynamic bar map
This patch gives an example implementation to support vendor defined
irq_type.
- on this vendor driver open, it registers an irq of type
VFIO_IRQ_TYPE_REMAP_BAR_REGION, and reports to driver vfio-pci there's
1 vendor irq.
- after userspace detects and enables the irq of type
VFIO_IRQ_TYPE_REMAP_BAR_REGION, this vendor driver will setup a virqfd
to monitor file write to the fd of this irq.
(1) when migration starts
(the device state is set to _SAVING & _RUNNING),
a. this vendor driver will signal the irq VFIO_IRQ_TYPE_REMAP_BAR_REGION
to ask userspace to remap pci bars. It packs the target bar number in
the ctx count. i.e. 1 << bar_number. if there are multiple bars to remap,
the numbers are or'ed.
b. on receiving this eventfd signal, userspace will read the bar number,
re-query the bar flags (like READ/WRITE/MMAP/SPARSE ranges), and remap
the bar's subregions.
c. vendor driver reports bar 0 to be trapped (not MMAP'd).
d. after remapping completion, it writes 0 to the eventfd so that the
vendor driver waiting for it would complete too.
(2) as the bar 0 is remapped to be trapped, vendor driver is able to
start tracking dirty pages in software way.
(3) when migration stops, similar to what's done in migration start, the
vendor driver would signal to remap the bar back to un-trapped (MMAP'd),
but it would not wait for the userspace writing back for remapping
completion.
- on releasing this vendor driver, it frees resources to vendor defined
irqs.
Cc: Kevin Tian
Cc: Shaopeng He
Signed-off-by: Yan Zhao
---
drivers/net/ethernet/intel/Kconfig| 2 +-
.../ethernet/intel/i40e/i40e_vf_migration.c | 322 +-
.../ethernet/intel/i40e/i40e_vf_migration.h | 26 ++
3 files changed, 346 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/Kconfig
b/drivers/net/ethernet/intel/Kconfig
index 31780d9a59f1..6a52a197c4d8 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -266,7 +266,7 @@ config I40E_DCB
config I40E_VF_MIGRATION
tristate "XL710 Family VF live migration support -- loadable modules
only"
- depends on I40E && VFIO_PCI && m
+ depends on I40E && VFIO_PCI && VFIO_VIRQFD && m
help
Say m if you want to enable live migration of
Virtual Functions of Intel(R) Ethernet Controller XL710
diff --git a/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
b/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
index 107a291909b3..188829efaa19 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
@@ -19,6 +19,266 @@
#define DRIVER_AUTHOR "Intel Corporation"
#define TEST_DIRTY_IOVA_PFN 0
+static int i40e_vf_remap_bars(struct i40e_vf_migration *i40e_vf_dev, bool wait)
+{
+ int bar_num = 0;
+
+ if (!i40e_vf_dev->remap_irq_ctx.init)
+ return -ENODEV;
+
+ /* set cnt to 2 as it will enter wait_handler too times.
+* one from this eventfd_signal,
+* one from userspace ack back
+*/
+ atomic_set(_vf_dev->remap_irq_ctx.cnt, 2);
+ eventfd_signal(i40e_vf_dev->remap_irq_ctx.trigger, 1 << bar_num);
+
+ if (!wait)
+ return 0;
+
+ /* the wait cannot be executed in vcpu threads, as the eventfd write
+* from userspace we are waiting for is waiting on the lock vcpu
+* threads hold
+*/
+ wait_event_killable(i40e_vf_dev->remap_irq_ctx.waitq,
+ !atomic_read(_vf_dev->remap_irq_ctx.cnt));
+
+ return 0;
+}
+
+static int i40e_vf_remap_bar_wait_handler(void *opaque, void *unused)
+{
+ struct i40e_vf_migration *i40e_vf_dev = opaque;
+
+ atomic_dec_if_positive(_vf_dev->remap_irq_ctx.cnt);
+ wake_up(_vf_dev->remap_irq_ctx.waitq);
+ return 0;
+}
+
+static void i40e_vf_disable_remap_bars_irq(struct i40e_vf_migration *vf_dev)
+{
+ if (!vf_dev->remap_irq_ctx.init)
+ return;
+
+ if (vf_dev->remap_irq_ctx.sync)
+ vfio_virqfd_disable(_dev->remap_irq_ctx.sync);
+
+ atomic_set(_dev->remap_irq_ctx.cnt, 0);
+ wake_up(_dev->remap_irq_ctx.waitq);
+
+ eventfd_ctx_put(vf_dev->remap_irq_ctx.trigger);
+ vf_dev->remap_irq_ctx.trigger = NULL;
+ vf_dev->remap_irq_ctx.init = false;
+}
+
+static int i40e_vf_enable_remap_bars_irq(struct i40e_vf_migration *vf_dev,
+struct eventfd_ctx *ctx, int32_t fd)
+{
+ int ret;
+
+ if (vf_dev->remap_irq_ctx.init)
+ return -EEXIST;
+
+ ret = vfio_virqfd_enable((void *)vf_dev,
+i40e_vf_remap_bar_wait_handler, NULL, ctx,
+_dev->remap_irq_ctx.sync, fd);
+ if (ret) {
+ eventfd_ctx_put(ctx);
+ return ret;
+ }
+
+
[RFC PATCH v4 09/10] i40e/vf_migration: register a migration vendor region
This patch let the vendor driver register a migration region, so that
the migration detection code in userspace will be able to see this
region and triggers the migration flow according to VFIO migration
protocol.
This migration region works based on VFIO migration series with some
minor fixes:
[1] kernel v17: https://patchwork.kernel.org/cover/11466129/
[2] qemu v16: https://patchwork.kernel.org/cover/11456557/
Cc: Shaopeng He
Signed-off-by: Yan Zhao
---
.../ethernet/intel/i40e/i40e_vf_migration.c | 429 +-
.../ethernet/intel/i40e/i40e_vf_migration.h | 34 ++
2 files changed, 460 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
b/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
index 96026dcf5c9d..107a291909b3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
@@ -17,6 +17,351 @@
#define VERSION_STRING "0.1"
#define DRIVER_AUTHOR "Intel Corporation"
+#define TEST_DIRTY_IOVA_PFN 0
+
+static int i40e_vf_iommu_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ if (action == VFIO_IOMMU_NOTIFY_DMA_UNMAP) {
+ struct vfio_iommu_type1_dma_unmap *unmap = data;
+ unsigned long iova_pfn, end_iova_pfn;
+
+ iova_pfn = unmap->iova >> PAGE_SHIFT;
+ end_iova_pfn = iova_pfn + unmap->size / PAGE_SIZE;
+
+ pr_info("DMA UNMAP iova_pfn=%lx, end=%lx\n", iova_pfn,
+ end_iova_pfn);
+ }
+
+ return NOTIFY_OK;
+}
+
+/* transient pinning a page
+ */
+static int i40e_vf_set_page_dirty(struct i40e_vf_migration *i40e_vf_dev,
+ unsigned long dirty_iova_pfn)
+{
+ unsigned long dirty_pfn, cnt = 1;
+ int ret;
+
+ ret = vfio_group_pin_pages(i40e_vf_dev->vfio_group,
+ _iova_pfn, cnt,
+ IOMMU_READ | IOMMU_WRITE, _pfn);
+ if (ret != cnt) {
+ pr_err("failed to track dirty of page of iova pfn %lx\n",
+ dirty_iova_pfn);
+ return ret < 0 ? ret : -EFAULT;
+ }
+
+ vfio_group_unpin_pages(i40e_vf_dev->vfio_group, _iova_pfn, cnt);
+
+ return 0;
+}
+
+/* alloc dirty page tracking resources and
+ * do the first round dirty page scanning
+ */
+static int i40e_vf_prepare_dirty_track(struct i40e_vf_migration *i40e_vf_dev)
+{
+ struct vfio_group *vfio_group;
+ unsigned long events;
+ int ret;
+ struct device *dev = _vf_dev->vf_dev->dev;
+
+ if (i40e_vf_dev->in_dirty_track) {
+ pr_warn("%s, previous dirty track resources found\n",
+ __func__);
+ return 0;
+ }
+
+ i40e_vf_dev->iommu_notifier.notifier_call = i40e_vf_iommu_notifier;
+
+ events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;
+ ret = vfio_register_notifier(dev, VFIO_IOMMU_NOTIFY, ,
+_vf_dev->iommu_notifier);
+ if (ret) {
+ pr_err("failed to register vfio iommu notifier\n");
+ return ret;
+ }
+
+ vfio_group = vfio_group_get_external_user_from_dev(dev);
+ if (IS_ERR_OR_NULL(vfio_group)) {
+ ret = PTR_ERR(vfio_group);
+ pr_err("failed to get vfio group from dev\n");
+ goto out;
+ }
+
+ i40e_vf_dev->vfio_group = vfio_group;
+
+ ret = i40e_vf_set_page_dirty(i40e_vf_dev, TEST_DIRTY_IOVA_PFN);
+
+ if (ret) {
+ pr_err("failed to set dirty for test page\n");
+ goto out_group;
+ }
+
+ i40e_vf_dev->in_dirty_track = true;
+ return 0;
+
+out_group:
+ vfio_unregister_notifier(dev, VFIO_IOMMU_NOTIFY,
+_vf_dev->iommu_notifier);
+out:
+ vfio_group_put_external_user(i40e_vf_dev->vfio_group);
+ return ret;
+}
+
+static void i40e_vf_stop_dirty_track(struct i40e_vf_migration *i40e_vf_dev)
+{
+ if (!i40e_vf_dev->in_dirty_track)
+ return;
+
+ vfio_unregister_notifier(_vf_dev->vf_dev->dev,
+VFIO_IOMMU_NOTIFY,
+_vf_dev->iommu_notifier);
+ vfio_group_put_external_user(i40e_vf_dev->vfio_group);
+ i40e_vf_dev->in_dirty_track = false;
+}
+
+static size_t i40e_vf_set_device_state(struct i40e_vf_migration *i40e_vf_dev,
+ u32 state)
+{
+ int ret = 0;
+ struct vfio_device_migration_info *mig_ctl = i40e_vf_dev->mig_ctl;
+
+ if (state == mig_ctl->device_state)
+ return 0;
+
+ switch (state) {
+ case VFIO_DEVICE_STATE_RUNNING:
+ break;
+ case VFIO_DEVICE_STATE_SAVING | VFIO_DEVICE_STATE_RUNNING:
+ ret = i40e_vf_prepare_dirty_track(i40e_vf_dev);
+ break;
+ case
[RFC PATCH v4 08/10] i40e/vf_migration: VF live migration - pass-through VF first
This driver intercepts all device operations as long as it's probed
successfully by vfio-pci driver.
It will process regions and irqs of its interest and then forward
operations to default handlers exported from vfio pci if it wishes to.
In this patch, this driver does nothing but pass through VFs to guest
by calling to exported handlers from driver vfio-pci.
Cc: Shaopeng He
Signed-off-by: Yan Zhao
---
drivers/net/ethernet/intel/Kconfig| 10 ++
drivers/net/ethernet/intel/i40e/Makefile | 2 +
.../ethernet/intel/i40e/i40e_vf_migration.c | 165 ++
.../ethernet/intel/i40e/i40e_vf_migration.h | 59 +++
4 files changed, 236 insertions(+)
create mode 100644 drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
create mode 100644 drivers/net/ethernet/intel/i40e/i40e_vf_migration.h
diff --git a/drivers/net/ethernet/intel/Kconfig
b/drivers/net/ethernet/intel/Kconfig
index ad34e4335df2..31780d9a59f1 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -264,6 +264,16 @@ config I40E_DCB
If unsure, say N.
+config I40E_VF_MIGRATION
+ tristate "XL710 Family VF live migration support -- loadable modules
only"
+ depends on I40E && VFIO_PCI && m
+ help
+ Say m if you want to enable live migration of
+ Virtual Functions of Intel(R) Ethernet Controller XL710
+ Family of devices. It must be a module.
+ This module serves as vendor module of module vfio_pci.
+ VFs bind to module vfio_pci directly.
+
# this is here to allow seamless migration from I40EVF --> IAVF name
# so that CONFIG_IAVF symbol will always mirror the state of CONFIG_I40EVF
config IAVF
diff --git a/drivers/net/ethernet/intel/i40e/Makefile
b/drivers/net/ethernet/intel/i40e/Makefile
index 2f21b3e89fd0..b80c224c2602 100644
--- a/drivers/net/ethernet/intel/i40e/Makefile
+++ b/drivers/net/ethernet/intel/i40e/Makefile
@@ -27,3 +27,5 @@ i40e-objs := i40e_main.o \
i40e_xsk.o
i40e-$(CONFIG_I40E_DCB) += i40e_dcb.o i40e_dcb_nl.o
+
+obj-$(CONFIG_I40E_VF_MIGRATION) += i40e_vf_migration.o
diff --git a/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
b/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
new file mode 100644
index ..96026dcf5c9d
--- /dev/null
+++ b/drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright(c) 2013 - 2019 Intel Corporation. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "i40e.h"
+#include "i40e_vf_migration.h"
+
+#define VERSION_STRING "0.1"
+#define DRIVER_AUTHOR "Intel Corporation"
+
+static int i40e_vf_open(void *device_data)
+{
+ struct i40e_vf_migration *i40e_vf_dev =
+ vfio_pci_vendor_data(device_data);
+ int ret;
+ struct vfio_device_migration_info *mig_ctl = NULL;
+
+ if (!try_module_get(THIS_MODULE))
+ return -ENODEV;
+
+ mutex_lock(_vf_dev->reflock);
+ if (!i40e_vf_dev->refcnt) {
+ vfio_pci_set_vendor_regions(device_data, 0);
+ vfio_pci_set_vendor_irqs(device_data, 0);
+ }
+
+ ret = vfio_pci_open(device_data);
+ if (ret)
+ goto error;
+
+ i40e_vf_dev->refcnt++;
+ mutex_unlock(_vf_dev->reflock);
+ return 0;
+error:
+ if (!i40e_vf_dev->refcnt) {
+ vfio_pci_set_vendor_regions(device_data, 0);
+ vfio_pci_set_vendor_irqs(device_data, 0);
+ }
+ module_put(THIS_MODULE);
+ mutex_unlock(_vf_dev->reflock);
+ return ret;
+}
+
+void i40e_vf_release(void *device_data)
+{
+ struct i40e_vf_migration *i40e_vf_dev =
+ vfio_pci_vendor_data(device_data);
+
+ mutex_lock(_vf_dev->reflock);
+ if (!--i40e_vf_dev->refcnt) {
+ vfio_pci_set_vendor_regions(device_data, 0);
+ vfio_pci_set_vendor_irqs(device_data, 0);
+ }
+ vfio_pci_release(device_data);
+ mutex_unlock(_vf_dev->reflock);
+ module_put(THIS_MODULE);
+}
+
+static long i40e_vf_ioctl(void *device_data,
+ unsigned int cmd, unsigned long arg)
+{
+ return vfio_pci_ioctl(device_data, cmd, arg);
+}
+
+static ssize_t i40e_vf_read(void *device_data, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ return vfio_pci_read(device_data, buf, count, ppos);
+}
+
+static ssize_t i40e_vf_write(void *device_data, const char __user *buf,
+size_t count, loff_t *ppos)
+{
+ return vfio_pci_write(device_data, buf, count, ppos);
+}
+
+static int i40e_vf_mmap(void *device_data, struct vm_area_struct *vma)
+{
+ return vfio_pci_mmap(device_data, vma);
+}
+
+static void i40e_vf_request(void *device_data, unsigned int count)
+{
+ vfio_pci_request(device_data, count);
+}
+
+static struct vfio_device_ops
[PATCH] platform-msi: Fix typos in comment
Fix up one typos @nev -> @nr_irqs. Cc: Marc Zyngier Signed-off-by: Shaokun Zhang --- drivers/base/platform-msi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c index 8da314b81eab..c4a17e5edf8b 100644 --- a/drivers/base/platform-msi.c +++ b/drivers/base/platform-msi.c @@ -387,7 +387,7 @@ void platform_msi_domain_free(struct irq_domain *domain, unsigned int virq, * * @domain:The platform-msi domain * @virq: The base irq from which to perform the allocate operation - * @nvec: How many interrupts to free from @virq + * @nr_irqs: How many interrupts to free from @virq * * Return 0 on success, or an error code on failure. Must be called * with irq_domain_mutex held (which can only be done as part of a -- 2.7.4
[RFC PATCH v4 07/10] vfio/pci: introduce a new irq type VFIO_IRQ_TYPE_REMAP_BAR_REGION
This is a virtual irq type.
vendor driver triggers this irq when it wants to notify userspace to
remap PCI BARs.
1. vendor driver triggers this irq and packs the target bar number in
the ctx count. i.e. "1 << bar_number".
if a bit is set, the corresponding bar is to be remapped.
2. userspace requery the specified PCI BAR from kernel and if flags of
the bar regions are changed, it removes the old subregions and attaches
subregions according to the new flags.
3. userspace notifies back to kernel by writing one to the eventfd of
this irq.
Please check the corresponding qemu implementation from the reply of this
patch, and a sample usage in vendor driver in patch [10/10].
Cc: Kevin Tian
Signed-off-by: Yan Zhao
---
include/uapi/linux/vfio.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 2d0d85c7c4d4..55895f75d720 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -704,6 +704,17 @@ struct vfio_irq_info_cap_type {
__u32 subtype; /* type specific */
};
+/* Bar Region Query IRQ TYPE */
+#define VFIO_IRQ_TYPE_REMAP_BAR_REGION (1)
+
+/* sub-types for VFIO_IRQ_TYPE_REMAP_BAR_REGION */
+/*
+ * This irq notifies userspace to re-query BAR region and remaps the
+ * subregions.
+ */
+#define VFIO_IRQ_SUBTYPE_REMAP_BAR_REGION (0)
+
+
/**
* VFIO_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct vfio_irq_set)
*
--
2.17.1
[RFC PATCH v4 06/10] vfio: Define device specific irq type capability
From: Tina Zhang
Cap the number of irqs with fixed indexes and use capability chains
to chain device specific irqs.
v2:
- Irq capability index starts from 1.
Signed-off-by: Tina Zhang
Signed-off-by: Eric Auger
---
include/uapi/linux/vfio.h | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 0fe7c9a6f211..2d0d85c7c4d4 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -683,11 +683,27 @@ struct vfio_irq_info {
#define VFIO_IRQ_INFO_MASKABLE (1 << 1)
#define VFIO_IRQ_INFO_AUTOMASKED (1 << 2)
#define VFIO_IRQ_INFO_NORESIZE (1 << 3)
+#define VFIO_IRQ_INFO_FLAG_CAPS(1 << 4) /* Info supports caps
*/
__u32 index; /* IRQ index */
__u32 count; /* Number of IRQs within this index */
+ __u32 cap_offset; /* Offset within info struct of first cap */
};
#define VFIO_DEVICE_GET_IRQ_INFO _IO(VFIO_TYPE, VFIO_BASE + 9)
+/*
+ * The irq type capability allows irqs unique to a specific device or
+ * class of devices to be exposed.
+ *
+ * The structures below define version 1 of this capability.
+ */
+#define VFIO_IRQ_INFO_CAP_TYPE 1
+
+struct vfio_irq_info_cap_type {
+ struct vfio_info_cap_header header;
+ __u32 type; /* global per bus driver */
+ __u32 subtype; /* type specific */
+};
+
/**
* VFIO_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct vfio_irq_set)
*
@@ -789,7 +805,8 @@ enum {
VFIO_PCI_MSIX_IRQ_INDEX,
VFIO_PCI_ERR_IRQ_INDEX,
VFIO_PCI_REQ_IRQ_INDEX,
- VFIO_PCI_NUM_IRQS
+ VFIO_PCI_NUM_IRQS = 5 /* Fixed user ABI, IRQ indexes >=5 use */
+ /* device specific cap to define content */
};
/*
--
2.17.1
[RFC PATCH v4 05/10] vfio/pci: export vfio_pci_get_barmap
This allows vendor driver to read/write to bars directly which is useful
in security checking condition.
Cc: Kevin Tian
Signed-off-by: Yan Zhao
---
drivers/vfio/pci/vfio_pci_rdwr.c | 10 ++
include/linux/vfio.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index a87992892a9f..e4085311ab28 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -153,6 +153,16 @@ static int vfio_pci_setup_barmap(struct vfio_pci_device
*vdev, int bar)
return 0;
}
+void __iomem *vfio_pci_get_barmap(void *device_data, int bar)
+{
+ int ret;
+ struct vfio_pci_device *vdev = device_data;
+
+ ret = vfio_pci_setup_barmap(vdev, bar);
+ return ret ? ERR_PTR(ret) : vdev->barmap[bar];
+}
+EXPORT_SYMBOL_GPL(vfio_pci_get_barmap);
+
ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char __user *buf,
size_t count, loff_t *ppos, bool iswrite)
{
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 6310c53f9d36..0c786fec4602 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -234,6 +234,7 @@ extern void *vfio_pci_vendor_data(void *device_data);
extern int vfio_pci_set_vendor_regions(void *device_data,
int num_vendor_regions);
extern int vfio_pci_set_vendor_irqs(void *device_data, int num_vendor_irqs);
+extern void __iomem *vfio_pci_get_barmap(void *device_data, int bar);
struct vfio_pci_vendor_driver_ops {
char*name;
--
2.17.1
[RFC PATCH v4 04/10] vfio/pci: let vfio_pci know number of vendor regions and vendor irqs
This allows a simpler VFIO_DEVICE_GET_INFO ioctl in vendor driver
Cc: Kevin Tian
Signed-off-by: Yan Zhao
---
drivers/vfio/pci/vfio_pci.c | 23 +--
drivers/vfio/pci/vfio_pci_private.h | 2 ++
include/linux/vfio.h| 3 +++
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 290b7ab55ecf..30137c1c5308 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -105,6 +105,24 @@ void *vfio_pci_vendor_data(void *device_data)
}
EXPORT_SYMBOL_GPL(vfio_pci_vendor_data);
+int vfio_pci_set_vendor_regions(void *device_data, int num_vendor_regions)
+{
+ struct vfio_pci_device *vdev = device_data;
+
+ vdev->num_vendor_regions = num_vendor_regions;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_pci_set_vendor_regions);
+
+
+int vfio_pci_set_vendor_irqs(void *device_data, int num_vendor_irqs)
+{
+ struct vfio_pci_device *vdev = device_data;
+
+ vdev->num_vendor_irqs = num_vendor_irqs;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_pci_set_vendor_irqs);
/*
* Our VGA arbiter participation is limited since we don't know anything
* about the device itself. However, if the device is the only VGA device
@@ -797,8 +815,9 @@ long vfio_pci_ioctl(void *device_data,
if (vdev->reset_works)
info.flags |= VFIO_DEVICE_FLAGS_RESET;
- info.num_regions = VFIO_PCI_NUM_REGIONS + vdev->num_regions;
- info.num_irqs = VFIO_PCI_NUM_IRQS;
+ info.num_regions = VFIO_PCI_NUM_REGIONS + vdev->num_regions +
+ vdev->num_vendor_regions;
+ info.num_irqs = VFIO_PCI_NUM_IRQS + vdev->num_vendor_irqs;
return copy_to_user((void __user *)arg, , minsz) ?
-EFAULT : 0;
diff --git a/drivers/vfio/pci/vfio_pci_private.h
b/drivers/vfio/pci/vfio_pci_private.h
index 7758a20546fa..c6cfc4605987 100644
--- a/drivers/vfio/pci/vfio_pci_private.h
+++ b/drivers/vfio/pci/vfio_pci_private.h
@@ -110,6 +110,8 @@ struct vfio_pci_device {
int num_ctx;
int irq_type;
int num_regions;
+ int num_vendor_regions;
+ int num_vendor_irqs;
struct vfio_pci_region *region;
u8 msi_qmax;
u8 msix_bar;
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 6ededceb1964..6310c53f9d36 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -231,6 +231,9 @@ extern void vfio_pci_release(void *device_data);
extern int vfio_pci_match(void *device_data, char *buf);
extern void *vfio_pci_vendor_data(void *device_data);
+extern int vfio_pci_set_vendor_regions(void *device_data,
+ int num_vendor_regions);
+extern int vfio_pci_set_vendor_irqs(void *device_data, int num_vendor_irqs);
struct vfio_pci_vendor_driver_ops {
char*name;
--
2.17.1
[RFC PATCH v4 03/10] vfio/pci: export vendor_data, irq_type, num_regions, pdev and functions in vfio_pci_ops
export functions vfio_pci_vendor_data(), vfio_pci_irq_type(),
vfio_pci_num_regions(), vfio_pci_pdev(), and functions in vfio_pci_ops,
so they are able to be called from outside modules and make them a kind of
inherited by vfio_device_ops provided by vendor modules
Cc: Kevin Tian
Suggested-by: Alex Williamson
Signed-off-by: Yan Zhao
---
drivers/vfio/pci/vfio_pci.c | 56 +++--
include/linux/vfio.h| 18
2 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 43d10d34cbc2..290b7ab55ecf 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -73,6 +73,38 @@ static struct vfio_pci {
struct list_head vendor_drivers_list;
} vfio_pci;
+struct pci_dev *vfio_pci_pdev(void *device_data)
+{
+ struct vfio_pci_device *vdev = device_data;
+
+ return vdev->pdev;
+}
+EXPORT_SYMBOL_GPL(vfio_pci_pdev);
+
+int vfio_pci_num_regions(void *device_data)
+{
+ struct vfio_pci_device *vdev = device_data;
+
+ return vdev->num_regions;
+}
+EXPORT_SYMBOL_GPL(vfio_pci_num_regions);
+
+int vfio_pci_irq_type(void *device_data)
+{
+ struct vfio_pci_device *vdev = device_data;
+
+ return vdev->irq_type;
+}
+EXPORT_SYMBOL_GPL(vfio_pci_irq_type);
+
+void *vfio_pci_vendor_data(void *device_data)
+{
+ struct vfio_pci_device *vdev = device_data;
+
+ return vdev->vendor_data;
+}
+EXPORT_SYMBOL_GPL(vfio_pci_vendor_data);
+
/*
* Our VGA arbiter participation is limited since we don't know anything
* about the device itself. However, if the device is the only VGA device
@@ -514,7 +546,7 @@ static void vfio_pci_vf_token_user_add(struct
vfio_pci_device *vdev, int val)
vfio_device_put(pf_dev);
}
-static void vfio_pci_release(void *device_data)
+void vfio_pci_release(void *device_data)
{
struct vfio_pci_device *vdev = device_data;
@@ -530,8 +562,9 @@ static void vfio_pci_release(void *device_data)
module_put(THIS_MODULE);
}
+EXPORT_SYMBOL_GPL(vfio_pci_release);
-static int vfio_pci_open(void *device_data)
+int vfio_pci_open(void *device_data)
{
struct vfio_pci_device *vdev = device_data;
int ret = 0;
@@ -556,6 +589,7 @@ static int vfio_pci_open(void *device_data)
module_put(THIS_MODULE);
return ret;
}
+EXPORT_SYMBOL_GPL(vfio_pci_open);
static int vfio_pci_get_irq_count(struct vfio_pci_device *vdev, int irq_type)
{
@@ -741,7 +775,7 @@ int vfio_pci_register_dev_region(struct vfio_pci_device
*vdev,
return 0;
}
-static long vfio_pci_ioctl(void *device_data,
+long vfio_pci_ioctl(void *device_data,
unsigned int cmd, unsigned long arg)
{
struct vfio_pci_device *vdev = device_data;
@@ -1253,6 +1287,7 @@ static long vfio_pci_ioctl(void *device_data,
return -ENOTTY;
}
+EXPORT_SYMBOL_GPL(vfio_pci_ioctl);
static ssize_t vfio_pci_rw(void *device_data, char __user *buf,
size_t count, loff_t *ppos, bool iswrite)
@@ -1286,7 +1321,7 @@ static ssize_t vfio_pci_rw(void *device_data, char __user
*buf,
return -EINVAL;
}
-static ssize_t vfio_pci_read(void *device_data, char __user *buf,
+ssize_t vfio_pci_read(void *device_data, char __user *buf,
size_t count, loff_t *ppos)
{
if (!count)
@@ -1294,8 +1329,9 @@ static ssize_t vfio_pci_read(void *device_data, char
__user *buf,
return vfio_pci_rw(device_data, buf, count, ppos, false);
}
+EXPORT_SYMBOL_GPL(vfio_pci_read);
-static ssize_t vfio_pci_write(void *device_data, const char __user *buf,
+ssize_t vfio_pci_write(void *device_data, const char __user *buf,
size_t count, loff_t *ppos)
{
if (!count)
@@ -1303,8 +1339,9 @@ static ssize_t vfio_pci_write(void *device_data, const
char __user *buf,
return vfio_pci_rw(device_data, (char __user *)buf, count, ppos, true);
}
+EXPORT_SYMBOL_GPL(vfio_pci_write);
-static int vfio_pci_mmap(void *device_data, struct vm_area_struct *vma)
+int vfio_pci_mmap(void *device_data, struct vm_area_struct *vma)
{
struct vfio_pci_device *vdev = device_data;
struct pci_dev *pdev = vdev->pdev;
@@ -1365,8 +1402,9 @@ static int vfio_pci_mmap(void *device_data, struct
vm_area_struct *vma)
return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
req_len, vma->vm_page_prot);
}
+EXPORT_SYMBOL_GPL(vfio_pci_mmap);
-static void vfio_pci_request(void *device_data, unsigned int count)
+void vfio_pci_request(void *device_data, unsigned int count)
{
struct vfio_pci_device *vdev = device_data;
struct pci_dev *pdev = vdev->pdev;
@@ -1386,6 +1424,7 @@ static void vfio_pci_request(void *device_data, unsigned
int count)
mutex_unlock(>igate);
}
+EXPORT_SYMBOL_GPL(vfio_pci_request);
static int vfio_pci_validate_vf_token(struct
[RFC PATCH v4 02/10] vfio/pci: macros to generate module_init and module_exit for vendor modules
vendor modules call macro module_vfio_pci_register_vendor_handler to
generate module_init and module_exit.
It is necessary to ensure that vendor modules always call
vfio_pci_register_vendor_driver() on driver loading and
vfio_pci_unregister_vendor_driver on driver unloading,
because
(1) at compiling time, there's only a dependency of vendor modules on
vfio_pci.
(2) at runtime,
- vendor modules add refs of vfio_pci on a successful calling of
vfio_pci_register_vendor_driver() and deref of vfio_pci on a
successful calling of vfio_pci_unregister_vendor_driver().
- vfio_pci only adds refs of vendor module on a successful probe of vendor
driver.
vfio_pci derefs vendor module when unbinding from a device.
So, after vfio_pci is unbound from a device, the vendor module to that
device is free to get unloaded. However, if that vendor module does not
call vfio_pci_unregister_vendor_driver() in its module_exit, vfio_pci may
hold a stale pointer to vendor module.
Cc: Kevin Tian
Suggested-by: Alex Williamson
Signed-off-by: Yan Zhao
---
include/linux/vfio.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 3e53deb012b6..f3746608c2d9 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -223,4 +223,31 @@ struct vfio_pci_vendor_driver_ops {
};
int __vfio_pci_register_vendor_driver(struct vfio_pci_vendor_driver_ops *ops);
void vfio_pci_unregister_vendor_driver(struct vfio_device_ops *device_ops);
+
+#define vfio_pci_register_vendor_driver(__name, __probe, __remove, \
+ __device_ops) \
+static struct vfio_pci_vendor_driver_ops __ops ## _node = { \
+ .owner = THIS_MODULE, \
+ .name = __name, \
+ .probe = __probe, \
+ .remove = __remove, \
+ .device_ops = __device_ops, \
+}; \
+__vfio_pci_register_vendor_driver(&__ops ## _node)
+
+#define module_vfio_pci_register_vendor_handler(name, probe, remove, \
+ device_ops) \
+static int __init device_ops ## _module_init(void) \
+{ \
+ vfio_pci_register_vendor_driver(name, probe, remove,\
+ device_ops);\
+ return 0; \
+}; \
+static void __exit device_ops ## _module_exit(void)\
+{ \
+ vfio_pci_unregister_vendor_driver(device_ops); \
+}; \
+module_init(device_ops ## _module_init); \
+module_exit(device_ops ## _module_exit)
+
#endif /* VFIO_H */
--
2.17.1
[PATCH] arm64: dts: meson: add ethernet interrupt to wetek dtsi
Add Ethernet interrupt details to the WeTek Hub/Play2 dtsi to resolve an issue with Ethernet probing in mainline u-boot. Signed-off-by: Christian Hewitt --- arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi index d6133af09d64..ad812854a107 100644 --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi @@ -149,6 +149,10 @@ reset-assert-us = <1>; reset-deassert-us = <3>; reset-gpios = < GPIOZ_14 GPIO_ACTIVE_LOW>; + + interrupt-parent = <_intc>; + /* MAC_INTR on GPIOZ_15 */ + interrupts = <29 IRQ_TYPE_LEVEL_LOW>; }; }; }; -- 2.17.1
[RFC PATCH v4 01/10] vfio/pci: register/unregister vfio_pci_vendor_driver_ops
vfio_pci_vendor_driver_ops includes two parts:
(1) .probe() and .remove() interface to be called by vfio_pci_probe()
and vfio_pci_remove().
(2) pointer to struct vfio_device_ops. It will be registered as ops of vfio
device if .probe() succeeds.
Suggested-by: Alex Williamson
Signed-off-by: Yan Zhao
---
drivers/vfio/pci/vfio_pci.c | 102 +++-
drivers/vfio/pci/vfio_pci_private.h | 7 ++
include/linux/vfio.h| 9 +++
3 files changed, 117 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 6c6b37b5c04e..43d10d34cbc2 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -68,6 +68,11 @@ static inline bool vfio_vga_disabled(void)
#endif
}
+static struct vfio_pci {
+ struct mutex vendor_drivers_lock;
+ struct list_head vendor_drivers_list;
+} vfio_pci;
+
/*
* Our VGA arbiter participation is limited since we don't know anything
* about the device itself. However, if the device is the only VGA device
@@ -1570,6 +1575,35 @@ static int vfio_pci_bus_notifier(struct notifier_block
*nb,
return 0;
}
+static int probe_vendor_drivers(struct vfio_pci_device *vdev)
+{
+ struct vfio_pci_vendor_driver *driver;
+ int ret = -ENODEV;
+
+ request_module("vfio-pci:%x-%x", vdev->pdev->vendor,
+vdev->pdev->device);
+
+ mutex_lock(_pci.vendor_drivers_lock);
+ list_for_each_entry(driver, _pci.vendor_drivers_list, next) {
+ void *data;
+
+ if (!try_module_get(driver->ops->owner))
+ continue;
+
+ data = driver->ops->probe(vdev->pdev);
+ if (IS_ERR(data)) {
+ module_put(driver->ops->owner);
+ continue;
+ }
+ vdev->vendor_driver = driver;
+ vdev->vendor_data = data;
+ ret = 0;
+ break;
+ }
+ mutex_unlock(_pci.vendor_drivers_lock);
+ return ret;
+}
+
static int vfio_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct vfio_pci_device *vdev;
@@ -1609,7 +1643,12 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
mutex_init(>ioeventfds_lock);
INIT_LIST_HEAD(>ioeventfds_list);
- ret = vfio_add_group_dev(>dev, _pci_ops, vdev);
+ if (probe_vendor_drivers(vdev))
+ ret = vfio_add_group_dev(>dev, _pci_ops, vdev);
+ else
+ ret = vfio_add_group_dev(>dev,
+vdev->vendor_driver->ops->device_ops,
+vdev);
if (ret)
goto out_free;
@@ -1698,6 +1737,11 @@ static void vfio_pci_remove(struct pci_dev *pdev)
if (!disable_idle_d3)
vfio_pci_set_power_state(vdev, PCI_D0);
+ if (vdev->vendor_driver) {
+ vdev->vendor_driver->ops->remove(vdev->vendor_data);
+ module_put(vdev->vendor_driver->ops->owner);
+ }
+
kfree(vdev->pm_save);
kfree(vdev);
@@ -2035,6 +2079,8 @@ static int __init vfio_pci_init(void)
vfio_pci_fill_ids();
+ mutex_init(_pci.vendor_drivers_lock);
+ INIT_LIST_HEAD(_pci.vendor_drivers_list);
return 0;
out_driver:
@@ -2042,6 +2088,60 @@ static int __init vfio_pci_init(void)
return ret;
}
+int __vfio_pci_register_vendor_driver(struct vfio_pci_vendor_driver_ops *ops)
+{
+ struct vfio_pci_vendor_driver *driver, *tmp;
+
+ if (!ops || !ops->device_ops)
+ return -EINVAL;
+
+ driver = kzalloc(sizeof(*driver), GFP_KERNEL);
+ if (!driver)
+ return -ENOMEM;
+
+ driver->ops = ops;
+
+ mutex_lock(_pci.vendor_drivers_lock);
+
+ /* Check for duplicates */
+ list_for_each_entry(tmp, _pci.vendor_drivers_list, next) {
+ if (tmp->ops->device_ops == ops->device_ops) {
+ mutex_unlock(_pci.vendor_drivers_lock);
+ kfree(driver);
+ return -EINVAL;
+ }
+ }
+
+ list_add(>next, _pci.vendor_drivers_list);
+
+ mutex_unlock(_pci.vendor_drivers_lock);
+
+ if (!try_module_get(THIS_MODULE))
+ return -ENODEV;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(__vfio_pci_register_vendor_driver);
+
+void vfio_pci_unregister_vendor_driver(struct vfio_device_ops *device_ops)
+{
+ struct vfio_pci_vendor_driver *driver, *tmp;
+
+ mutex_lock(_pci.vendor_drivers_lock);
+ list_for_each_entry_safe(driver, tmp,
+_pci.vendor_drivers_list, next) {
+ if (driver->ops->device_ops == device_ops) {
+ list_del(>next);
+ mutex_unlock(_pci.vendor_drivers_lock);
+
[RFC PATCH v4 00/10] Introduce vendor ops in vfio-pci
When using vfio-pci to pass through devices, though it's desired to use
its default implementations in most of time, it is also sometimes
necessary to call vendors specific operations.
For example, in order to do device live migration, the way of dirty
pages detection and device state save-restore may be varied from device
to device.
Vendors may want to add a vendor device region or may want to
intercept writes to a BAR region.
So, in this series, we introduce a way to allow vendors to provide vendor
specific ops for VFIO devices and meanwhile export several vfio-pci
interfaces as default implementations to simplify code of vendor driver
and avoid duplication.
Vendor driver registration/unregistration goes like this:
(1) macros are provided to let vendor drivers register/unregister
vfio_pci_vendor_driver_ops to vfio_pci in their module_init() and
module_exit().
vfio_pci_vendor_driver_ops contains callbacks probe() and remove() and a
pointer to vfio_device_ops.
(2) vendor drivers define their module aliases as
"vfio-pci:$vendor_id-$device_id".
E.g. A vendor module for VF devices of Intel(R) Ethernet Controller XL710
family can define its module alias as MODULE_ALIAS("vfio-pci:8086-154c").
(3) when module vfio_pci is bound to a device, it would call modprobe in
user space for modules of alias "vfio-pci:$vendor_id-$device_id", which
would trigger unloaded vendor drivers to register their
vfio_pci_vendor_driver_ops to vfio_pci.
Then it searches registered ops list and calls probe() to test whether this
vendor driver supports this physical device.
A success probe() would make bind vfio device to vendor provided
vfio_device_ops, which would call exported default implementations in
vfio_pci_ops if necessary.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
__ (un)register vendor ops | ______ |
| |<|VF| | |
| vfio-pci | | | vendor | | PF driver | |
|__|>| driver | |___|
| probe/remove()| --- | |
| |
| |_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _|
\|/ \|/
---
|VF | |PF|
---
a typical usage in SRIOV
Ref counts:
(1) vendor drivers must be a module and compiled to depend on module
vfio_pci.
(2) In vfio_pci, a successful register would add refs of itself, and a
successful unregister would derefs of itself.
(3) In vfio_pci, a successful probe() of a vendor driver would add ref of
the vendor module. It derefs of the vendor module after calling remove().
(4) macro provided to make sure vendor module always unregister itself in
its module_exit
Those are to prevent below conditions:
a. vfio_pci is unloaded after a successful register from vendor driver.
Though vfio_pci would later call modprobe to ask the vendor module to
register again, it cannot help if vendor driver remain as loaded
across unloading-loading of vfio_pci.
b. vendor driver unregisters itself after successfully probed by vfio_pci.
c. circular dependency between vfio_pci and the vendor driver.
if vfio_pci adds refs to both vfio_pci and vendor driver on a successful
register and if vendor driver only do the unregistration in its module_exit,
then it would have no chance to do the unregistration.
Patch Overview
patches 1-2 provide register/unregister interfaces for vendor drivers
Patch 3 exports several members in vdev, including vendor_data, and
exports functions in vfio_pci_ops to allow them accessible
from vendor drivers.
patches 4-5 export some more vdev members to vendor driver to simplify
their implementations.
patch 6 is from Tina Zhang to define vendor specific Irq type
capability.
patch 7 introduces a new vendor defined irq type
VFIO_IRQ_TYPE_REMAP_BAR_REGION.
patches 8-10
use VF live migration driver for Intel's 710 SRIOV devices
as an example of how to implement this vendor ops interface.
patch 8 first let the vendor ops pass through VFs.
patch 9 implements a migration region based on migration protocol
defined in [1][2].
(Some dirty page tracking functions are intentionally
commented out and would send out later in future.)
patch 10 serves as an example of how to define vendor specific irq
type. This irq will trigger qemu to dynamic map BAR regions
in order to implement software based dirty page track.
Changelog:
RFC
Re: [PATCH] KVM: Fix the indentation to match coding style
On Mon, 18 May 2020 at 09:32, Haiwei Li wrote:
>
> From: Haiwei Li
>
> There is a bad indentation in next branch. The patch looks like
> fixes nothing though it fixes the indentation.
>
> Before fixing:
>
> if (!handle_fastpath_set_x2apic_icr_irqoff(vcpu, data)) {
> kvm_skip_emulated_instruction(vcpu);
> ret = EXIT_FASTPATH_EXIT_HANDLED;
> }
> break;
> case MSR_IA32_TSCDEADLINE:
>
> After fixing:
>
> if (!handle_fastpath_set_x2apic_icr_irqoff(vcpu, data)) {
> kvm_skip_emulated_instruction(vcpu);
> ret = EXIT_FASTPATH_EXIT_HANDLED;
> }
> break;
> case MSR_IA32_TSCDEADLINE:
>
Reviewed-by: Wanpeng Li
>
> Signed-off-by: Haiwei Li
> ---
> arch/x86/kvm/x86.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 471fccf..446f747 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1631,7 +1631,7 @@ fastpath_t handle_fastpath_set_msr_irqoff(struct
> kvm_vcpu *vcpu)
> if (!handle_fastpath_set_x2apic_icr_irqoff(vcpu, data)) {
> kvm_skip_emulated_instruction(vcpu);
> ret = EXIT_FASTPATH_EXIT_HANDLED;
> - }
> + }
> break;
> case MSR_IA32_TSCDEADLINE:
> data = kvm_read_edx_eax(vcpu);
> --
> 1.8.3.1
Re: Documentation/trace/events.rst: wrong numbering of sections
>Hi, > >On Fri, 2020-05-15 at 09:11 -0400, Steven Rostedt wrote: >> It's best to Cc the maintainers of the file. Nobody reads linux- >> kernel (it >> produces 800 emails a day!). Luckily, I happen to monitor the >> linux-trace-devel list (which is mostly for userland tools), >> otherwise this >> email would have been lost to the LKML abyss. >> >> On Fri, 15 May 2020 15:43:43 +0800 >> "Li Xinhai" wrote: >> >> > This document has below numbering of its sections: >> > >> > 1. Introduction >> > 2. Using Event Tracing >> > 2.1 Via the 'set_event' interface >> > 2.2 Via the 'enable' toggle >> > 2.3 Boot option >> > 3. Defining an event-enabled tracepoint >> > 4. Event formats >> > 5. Event filtering >> > 5.1 Expression syntax >> > 5.2 Setting filters >> > 5.3 Clearing filters >> > 5.3 Subsystem filters >> > 5.4 PID filtering >> > 6. Event triggers >> > 6.1 Expression syntax >> > 6.2 Supported trigger commands >> > 6.3 In-kernel trace event API >> > 6.3.1 Dyamically creating synthetic event definitions >> > 6.3.3 Tracing synthetic events from in-kernel code >> > 6.3.3.1 Tracing a synthetic event all at once >> > 6.3.3.1 Tracing a synthetic event piecewise >> > 6.3.4 Dyamically creating kprobe and kretprobe event definitions >> > 6.3.4 The "dynevent_cmd" low-level API >> > >> > It seems wrong numbering within 6.3 section. >> > or, would it be better to have separated chapter #7, for 'In-kernel >> > trace >> > event API'? it seems not belong to 'Event triggers'. >> >> Yeah, 6.3.4 (both of them) probably should have been under a new top >> level >> section. (#7). >> > >Yeah, aside from duplicate numbering in a couple of places, it would >make more sense for everything starting from '6.3 In-kernel trace event >API' to be in a section 7. > >Would you like to submit a patch for that, Li, or should I? > I am not sure the correct organization of these part, you maybe better to fix it, thanks. >Thanks, > >Tom > >> -- Steve >
UBSAN: array-index-out-of-bounds in kernel/bpf/arraymap.c:177
With Clang 9.0.1, return array->value + array->elem_size * (index & array->index_mask); but array->value is, char value[0] __aligned(8); [ 506.031548][ T4134] LTP: starting bpf_prog02 [ 506.125326][ T4352] [ 506.134603][ T4352] UBSAN: array-index-out-of-bounds in kernel/bpf/arraymap.c:177:22 [ 506.142521][ T4352] index 8 is out of range for type 'char [0]' [ 506.148613][ T4352] CPU: 222 PID: 4352 Comm: bpf_prog02 Tainted: G L5.7.0-rc5-next-20200515 #2 [ 506.158632][ T4352] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019 [ 506.169084][ T4352] Call trace: [ 506.172256][ T4352] dump_backtrace+0x0/0x22c [ 506.176634][ T4352] show_stack+0x28/0x34 [ 506.180666][ T4352] dump_stack+0x104/0x194 [ 506.184877][ T4352] __ubsan_handle_out_of_bounds+0xf0/0x120 [ 506.190565][ T4352] array_map_lookup_elem+0x90/0x94 [ 506.195560][ T4352] bpf_map_lookup_elem+0x48/0x60 [ 506.200383][ T4352] ___bpf_prog_run+0xe9c/0x2840 [ 506.205109][ T4352] __bpf_prog_run32+0x80/0xac [ 506.209673][ T4352] __bpf_prog_run_save_cb+0x104/0x46c [ 506.214919][ T4352] sk_filter_trim_cap+0x21c/0x2c4 [ 506.219823][ T4352] unix_dgram_sendmsg+0x45c/0x860 [ 506.224725][ T4352] sock_sendmsg+0x4c/0x74 [ 506.228935][ T4352] sock_write_iter+0x158/0x1a4 [ 506.233584][ T4352] __vfs_write+0x190/0x1d8 [ 506.237874][ T4352] vfs_write+0x13c/0x1b8 [ 506.241992][ T4352] ksys_write+0xb0/0x120 [ 506.246108][ T4352] __arm64_sys_write+0x54/0x88 [ 506.250747][ T4352] do_el0_svc+0x128/0x1dc [ 506.254957][ T4352] el0_sync_handler+0xd0/0x268 [ 506.259594][ T4352] el0_sync+0x164/0x180 [ 506.263747][ T4352]
Re: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects
On 5/16/20 8:27 PM, Balbir Singh wrote:
On 14/5/20 10:00 pm, Matthew Wilcox wrote:
On Thu, May 14, 2020 at 09:00:40PM +1000, Balbir Singh wrote:
I wonder if the right thing to do is also to disable pre-emption, just so that
the thread does not linger on with sensitive data.
void kvfree_sensitive(const void *addr, size_t len)
{
preempt_disable();
if (likely(!ZERO_OR_NULL_PTR(addr))) {
memzero_explicit((void *)addr, len);
kvfree(addr);
}
preempt_enable();
}
EXPORT_SYMBOL(kvfree_sensitive);
If it's _that_ sensitive then the caller should have disabled preemption.
Because preemption could otherwise have occurred immediately before
kvfree_sensitive() was called.
May be, but the callers of the API have to be explictly aware of the contract.
I don't disagree with you on what you've said, but I was referring to the
intent of freeing sensitive data vs the turn around time for doing so.
We can't disable preemption like that. The vfree() call may potentially
sleep. It could be a mess to keep track of the preemption state to make
that works.
The purpose of this API is to make sure that a newly allocated memory
block won't contain secret left behind from another task. There is no
guarantee on how long the freeing process will take.
Cheers,
Longman
Re: [PATCH] MIPS: Loongson: Add support for serial console
On 2020/5/18 09:08, Tiezhu Yang wrote:
On 05/16/2020 07:09 PM, WANG Xuerui wrote:
On 5/16/20 3:03 PM, Tiezhu Yang wrote:
After commit 87fcfa7b7fe6 ("MIPS: Loongson64: Add generic dts"),
there already exists the node and property of Loongson CPU UART0
in loongson3-package.dtsi:
cpu_uart0: serial@1fe001e0 {
compatible = "ns16550a";
reg = <0 0x1fe001e0 0x8>;
clock-frequency = <3300>;
interrupt-parent = <>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
no-loopback-test;
};
In order to support for serial console on the Loongson platform,
add CONFIG_SERIAL_OF_PLATFORM=y to loongson3_defconfig.
With this patch, we can see the following boot message:
[ 1.877745] printk: console [ttyS0] disabled
[ 1.881979] 1fe001e0.serial: ttyS0 at MMIO 0x1fe001e0 (irq = 16,
base_baud = 2062500) is a 16550A
[ 1.890838] printk: console [ttyS0] enabled
And also, we can login normally from the serial console.
Signed-off-by: Tiezhu Yang
---
Hi Jiaxun,
Thank you very much for your suggestion.
arch/mips/configs/loongson3_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/configs/loongson3_defconfig
b/arch/mips/configs/loongson3_defconfig
index 6768c16..cd95f08 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -217,6 +217,7 @@ CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
+CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_HW_RANDOM=y
CONFIG_RAW_DRIVER=m
CONFIG_I2C_CHARDEV=y
Hi,
The patch title is again exaggerating things. This is a defconfig
change, so please refer to `git log` output of `arch/mips/configs`
and use something like "MIPS: Loongson: loongson3_defconfig: enable
serial console" or "MIPS: Loongson: enable serial console in
defconfig". The current title reads as if Loongson kernels never were
able to use a serial console in the past.
Hi Xuerui,
Thanks for your suggestion.
We can not use the serial console without this patch,
so I use the current patch subject.
One can always use their own config to build in whatever support they
want. Only people blindly following defconfig are affected. That's why I
think the original patch title is exaggerating.
Anyway, let me modify the patch subject to make it more accurate,
I think the following is better:
"MIPS: Loongson: Enable devicetree based probing for 8250 ports"
drivers/tty/serial/8250/Kconfig:
config SERIAL_OF_PLATFORM
tristate "Devicetree based probing for 8250 ports"
I will send v2 later.
No problem. Just make it clear that these are defconfig changes so
people don't misunderstand, even if they're otherwise unfamiliar with
the current state of things.
Thanks,
Tiezhu Yang
[PATCH v3 5/5] arm64: dts: meson-g12b-gtking-pro: add initial device-tree
The Shenzen AZW (Beelink) GT-King Pro is based on the Amlogic W400
reference board with an S922X chip.
- 4GB LPDDR4 RAM
- 64GB eMMC storage
- 10/100/1000 Base-T Ethernet
- AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
- HDMI 2.1 video
- Analogue audio output
- 1x RS232 port
- 2x USB 2.0 port
- 2x USB 3.0 ports
- IR receiver
- 1x micro SD card slot
- 1x Power on/off button
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../dts/amlogic/meson-g12b-gtking-pro.dts | 125 ++
2 files changed, 126 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 66691090b30c..38bb1f6e6ef6 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-tanix-tx5max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-s922x-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
new file mode 100644
index ..f0c56a16af3d
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ * Copyright (c) 2019 Christian Hewitt
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-w400.dtsi"
+#include
+
+/ {
+ compatible = "azw,gtking", "amlogic,g12b";
+ model = "Beelink GT-King Pro";
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <100>;
+
+ power-button {
+ label = "power";
+ linux,code = ;
+ gpios = <_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ white {
+ label = "power:white";
+ gpios = <_ao GPIOAO_11 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "G12B-GTKING-PRO";
+ audio-aux-devs = <_b>;
+ audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+ "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+ "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+ "TDM_B Playback", "TDMOUT_B OUT";
+
+ assigned-clocks = < CLKID_MPLL2>,
+ < CLKID_MPLL0>,
+ < CLKID_MPLL1>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <_a>;
+ };
+
+ dai-link-1 {
+ sound-dai = <_b>;
+ };
+
+ dai-link-2 {
+ sound-dai = <_c>;
+ };
+
+ /* 8ch hdmi interface */
+ dai-link-3 {
+ sound-dai = <_b>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-0 = <1 1>;
+ dai-tdm-slot-tx-mask-1 = <1 1>;
+ dai-tdm-slot-tx-mask-2 = <1 1>;
+ dai-tdm-slot-tx-mask-3 = <1 1>;
+ mclk-fs = <256>;
+
+ codec {
+ sound-dai = < TOHDMITX_I2S_IN_B>;
+ };
+ };
+
+ dai-link-4 {
+ sound-dai = < TOHDMITX_I2S_OUT>;
+
+ codec {
+ sound-dai = <_tx>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+_audio {
+ status = "okay";
+};
+
+_a {
+ status = "okay";
+};
+
+_b {
+ status = "okay";
+};
+
+_c {
+ status = "okay";
+};
+
+_b {
+ status = "okay";
+};
+
+_b {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
2.17.1
[PATCH v3 4/5] dt-bindings: arm: amlogic: add support for the Beelink GT-King Pro
The Shenzen AZW (Beelink) GT-King Pro is based on the Amlogic W400 reference board with an S922X chip. Acked-by: Rob Herring Signed-off-by: Christian Hewitt --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 25e118b8a97b..46cb6359f530 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -152,6 +152,7 @@ properties: items: - enum: - azw,gtking + - azw,gtking-pro - hardkernel,odroid-n2 - khadas,vim3 - ugoos,am6 -- 2.17.1
[PATCH v3 3/5] arm64: dts: meson-g12b-gtking: add initial device-tree
The Shenzen AZW (Beelink) GT-King is based on the Amlogic W400 reference
board with an S922X chip.
- 4GB LPDDR4 RAM
- 64GB eMMC storage
- 10/100/1000 Base-T Ethernet
- AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
- HDMI 2.1 video
- S/PDIF optical output
- Analogue audio output
- 1x USB 2.0 port
- 2x USB 3.0 ports
- IR receiver
- 1x micro SD card slot
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-g12b-gtking.dts| 145 ++
2 files changed, 146 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 01e32415e252..66691090b30c 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-sei510.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-tanix-tx5max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-s922x-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
new file mode 100644
index ..eeb7bc5539ef
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ * Copyright (c) 2019 Christian Hewitt
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-w400.dtsi"
+#include
+
+/ {
+ compatible = "azw,gtking", "amlogic,g12b";
+ model = "Beelink GT-King";
+
+ spdif_dit: audio-codec-1 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ status = "okay";
+ sound-name-prefix = "DIT";
+ };
+
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "G12B-GTKING";
+ audio-aux-devs = <_b>;
+ audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+ "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+ "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+ "TDM_B Playback", "TDMOUT_B OUT",
+ "SPDIFOUT IN 0", "FRDDR_A OUT 3",
+ "SPDIFOUT IN 1", "FRDDR_B OUT 3",
+ "SPDIFOUT IN 2", "FRDDR_C OUT 3";
+
+ assigned-clocks = < CLKID_MPLL2>,
+ < CLKID_MPLL0>,
+ < CLKID_MPLL1>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <_a>;
+ };
+
+ dai-link-1 {
+ sound-dai = <_b>;
+ };
+
+ dai-link-2 {
+ sound-dai = <_c>;
+ };
+
+ /* 8ch hdmi interface */
+ dai-link-3 {
+ sound-dai = <_b>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-0 = <1 1>;
+ dai-tdm-slot-tx-mask-1 = <1 1>;
+ dai-tdm-slot-tx-mask-2 = <1 1>;
+ dai-tdm-slot-tx-mask-3 = <1 1>;
+ mclk-fs = <256>;
+
+ codec {
+ sound-dai = < TOHDMITX_I2S_IN_B>;
+ };
+ };
+
+ /* spdif hdmi or toslink interface */
+ dai-link-4 {
+ sound-dai = <>;
+
+ codec-0 {
+ sound-dai = <_dit>;
+ };
+
+ codec-1 {
+ sound-dai = < TOHDMITX_SPDIF_IN_A>;
+ };
+ };
+
+ /* spdif hdmi interface */
+ dai-link-5 {
+ sound-dai = <_b>;
+
+ codec {
+ sound-dai = < TOHDMITX_SPDIF_IN_B>;
+ };
+ };
+
+ /* hdmi glue */
+ dai-link-6 {
+ sound-dai = < TOHDMITX_I2S_OUT>;
+
+ codec {
+ sound-dai = <_tx>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+_audio {
+ status = "okay";
+};
+
+_a {
+ status = "okay";
+};
+
+_b {
+ status =
[PATCH v3 2/5] dt-bindings: arm: amlogic: add support for the Beelink GT-King
The Shenzen AZW (Beelink) GT-King is based on the Amlogic W400 reference board with an S922X chip. Acked-by: Rob Herring Signed-off-by: Christian Hewitt --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 5180a548bd94..25e118b8a97b 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -151,6 +151,7 @@ properties: - description: Boards with the Amlogic Meson G12B S922X SoC items: - enum: + - azw,gtking - hardkernel,odroid-n2 - khadas,vim3 - ugoos,am6 -- 2.17.1
[PATCH v3 1/5] arm64: dts: meson: convert ugoos-am6 to common w400 dtsi
Convert the Ugoos AM6 dts into meson-g12b-w400.dtsi, and then create
a new AM6 dts that references it. This is in preparation for several
new G12B devices that will share the common w400 dtsi.
Signed-off-by: Christian Hewitt
---
.../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 410 +
.../boot/dts/amlogic/meson-g12b-w400.dtsi | 423 ++
2 files changed, 424 insertions(+), 409 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
index fdaacfd96b97..73637de80c21 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
@@ -7,42 +7,13 @@
/dts-v1/;
-#include "meson-g12b.dtsi"
-#include "meson-g12b-s922x.dtsi"
-#include
-#include
+#include "meson-g12b-w400.dtsi"
#include
/ {
compatible = "ugoos,am6", "amlogic,s922x", "amlogic,g12b";
model = "Ugoos AM6";
- aliases {
- serial0 = _AO;
- ethernet0 =
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x4000>;
- };
-
- emmc_pwrseq: emmc-pwrseq {
- compatible = "mmc-pwrseq-emmc";
- reset-gpios = < BOOT_12 GPIO_ACTIVE_LOW>;
- };
-
- sdio_pwrseq: sdio-pwrseq {
- compatible = "mmc-pwrseq-simple";
- reset-gpios = < GPIOX_6 GPIO_ACTIVE_LOW>;
- clocks = <>;
- clock-names = "ext_clock";
- };
-
spdif_dit: audio-codec-1 {
#sound-dai-cells = <0>;
compatible = "linux,spdif-dit";
@@ -50,154 +21,6 @@
sound-name-prefix = "DIT";
};
- flash_1v8: regulator-flash_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "FLASH_1V8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- vin-supply = <_3v3>;
- regulator-always-on;
- };
-
- main_12v: regulator-main_12v {
- compatible = "regulator-fixed";
- regulator-name = "12V";
- regulator-min-microvolt = <1200>;
- regulator-max-microvolt = <1200>;
- regulator-always-on;
- };
-
- vcc_5v: regulator-vcc_5v {
- compatible = "regulator-fixed";
- regulator-name = "VCC_5V";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <_12v>;
-
- gpio = < GPIOH_8 GPIO_OPEN_DRAIN>;
- enable-active-high;
- };
-
- vcc_1v8: regulator-vcc_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- vin-supply = <_3v3>;
- regulator-always-on;
- };
-
- vcc_3v3: regulator-vcc_3v3 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_3V3";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- vin-supply = <_3v3>;
- regulator-always-on;
- /* FIXME: actually controlled by VDDCPU_B_EN */
- };
-
- vddcpu_a: regulator-vddcpu-a {
- /*
-* MP1653 Regulator.
-*/
- compatible = "pwm-regulator";
-
- regulator-name = "VDDCPU_A";
- regulator-min-microvolt = <721000>;
- regulator-max-microvolt = <1022000>;
-
- vin-supply = <_12v>;
-
- pwms = <_ab 0 1250 0>;
- pwm-dutycycle-range = <100 0>;
-
- regulator-boot-on;
- regulator-always-on;
- };
-
- vddcpu_b: regulator-vddcpu-b {
- /*
-* MP1652 Regulator.
-*/
- compatible = "pwm-regulator";
-
- regulator-name = "VDDCPU_B";
- regulator-min-microvolt = <721000>;
- regulator-max-microvolt = <1022000>;
-
- vin-supply = <_12v>;
-
- pwms = <_AO_cd 1 1250 0>;
- pwm-dutycycle-range = <100 0>;
-
- regulator-boot-on;
- regulator-always-on;
- };
-
- usb1_pow: regulator-usb1-pow {
- compatible = "regulator-fixed";
- regulator-name = "USB1_POW";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <_5v>;
-
- /* connected to SY6280A Power Switch */
-
[PATCH v3 0/5] arm64: dts: meson: add W400 dtsi and GT-King/Pro devices
This series combines patch 2 from [1] which converts the existing Ugoos AM6 device-tree to a common W400 dtsi and dts, and then reworks the Beelink GT-King/GT-King Pro serries from [2] to use the dtsi, but this time without the offending common audio dtsi approach. I've carried forwards acks on bindings from Rob as these did not change. v3 - amend author full-name on bindings patch [1] https://patchwork.kernel.org/patch/11497105/ [2] https://patchwork.kernel.org/project/linux-amlogic/list/?series=273483 Christian Hewitt (5): arm64: dts: meson: convert ugoos-am6 to common w400 dtsi dt-bindings: arm: amlogic: add support for the Beelink GT-King arm64: dts: meson-g12b-gtking: add initial device-tree dt-bindings: arm: amlogic: add support for the Beelink GT-King Pro arm64: dts: meson-g12b-gtking-pro: add initial device-tree .../devicetree/bindings/arm/amlogic.yaml | 2 + arch/arm64/boot/dts/amlogic/Makefile | 2 + .../dts/amlogic/meson-g12b-gtking-pro.dts | 125 ++ .../boot/dts/amlogic/meson-g12b-gtking.dts| 145 ++ .../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 410 + .../boot/dts/amlogic/meson-g12b-w400.dtsi | 423 ++ 6 files changed, 698 insertions(+), 409 deletions(-) create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi -- 2.17.1
linux-next: manual merge of the jc_docs tree with the vfs and net-next trees
Hi all,
Today's linux-next merge of the jc_docs tree got a conflict in:
kernel/sysctl.c
between commit:
f461d2dcd511 ("sysctl: avoid forward declarations")
from the vfs tree and commit:
2f4c33063ad7 ("docs: sysctl/kernel: document ngroups_max")
from the jc_docs 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 kernel/sysctl.c
index 7858930d843f,2ba9f449d273..
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@@ -1576,1734 -3358,83 +1576,1734 @@@ int proc_do_large_bitmap(struct ctl_tab
return -ENOSYS;
}
-int proc_douintvec_minmax(struct ctl_table *table, int write,
-void __user *buffer, size_t *lenp, loff_t *ppos)
-{
- return -ENOSYS;
-}
+#endif /* CONFIG_PROC_SYSCTL */
+
+#if defined(CONFIG_SYSCTL)
+int proc_do_static_key(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct static_key *key = (struct static_key *)table->data;
+ static DEFINE_MUTEX(static_key_mutex);
+ int val, ret;
+ struct ctl_table tmp = {
+ .data = ,
+ .maxlen = sizeof(val),
+ .mode = table->mode,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ };
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ mutex_lock(_key_mutex);
+ val = static_key_enabled(key);
+ ret = proc_dointvec_minmax(, write, buffer, lenp, ppos);
+ if (write && !ret) {
+ if (val)
+ static_key_enable(key);
+ else
+ static_key_disable(key);
+ }
+ mutex_unlock(_key_mutex);
+ return ret;
+}
+
+static struct ctl_table kern_table[] = {
+ {
+ .procname = "sched_child_runs_first",
+ .data = _sched_child_runs_first,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+#ifdef CONFIG_SCHED_DEBUG
+ {
+ .procname = "sched_min_granularity_ns",
+ .data = _sched_min_granularity,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = sched_proc_update_handler,
+ .extra1 = _sched_granularity_ns,
+ .extra2 = _sched_granularity_ns,
+ },
+ {
+ .procname = "sched_latency_ns",
+ .data = _sched_latency,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = sched_proc_update_handler,
+ .extra1 = _sched_granularity_ns,
+ .extra2 = _sched_granularity_ns,
+ },
+ {
+ .procname = "sched_wakeup_granularity_ns",
+ .data = _sched_wakeup_granularity,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = sched_proc_update_handler,
+ .extra1 = _wakeup_granularity_ns,
+ .extra2 = _wakeup_granularity_ns,
+ },
+#ifdef CONFIG_SMP
+ {
+ .procname = "sched_tunable_scaling",
+ .data = _sched_tunable_scaling,
+ .maxlen = sizeof(enum sched_tunable_scaling),
+ .mode = 0644,
+ .proc_handler = sched_proc_update_handler,
+ .extra1 = _sched_tunable_scaling,
+ .extra2 = _sched_tunable_scaling,
+ },
+ {
+ .procname = "sched_migration_cost_ns",
+ .data = _sched_migration_cost,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
+ .procname = "sched_nr_migrate",
+ .data = _sched_nr_migrate,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+#ifdef CONFIG_SCHEDSTATS
+ {
+ .procname = "sched_schedstats",
+ .data = NULL,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = sysctl_schedstats,
+ .extra1
[PATCH v2 5/5] arm64: dts: meson-g12b-gtking-pro: add initial device-tree
The Shenzen AZW (Beelink) GT-King Pro is based on the Amlogic W400
reference board with an S922X chip.
- 4GB LPDDR4 RAM
- 64GB eMMC storage
- 10/100/1000 Base-T Ethernet
- AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
- HDMI 2.1 video
- Analogue audio output
- 1x RS232 port
- 2x USB 2.0 port
- 2x USB 3.0 ports
- IR receiver
- 1x micro SD card slot
- 1x Power on/off button
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../dts/amlogic/meson-g12b-gtking-pro.dts | 125 ++
2 files changed, 126 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 66691090b30c..38bb1f6e6ef6 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-tanix-tx5max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-s922x-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
new file mode 100644
index ..f0c56a16af3d
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ * Copyright (c) 2019 Christian Hewitt
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-w400.dtsi"
+#include
+
+/ {
+ compatible = "azw,gtking", "amlogic,g12b";
+ model = "Beelink GT-King Pro";
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <100>;
+
+ power-button {
+ label = "power";
+ linux,code = ;
+ gpios = <_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ white {
+ label = "power:white";
+ gpios = <_ao GPIOAO_11 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "G12B-GTKING-PRO";
+ audio-aux-devs = <_b>;
+ audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+ "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+ "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+ "TDM_B Playback", "TDMOUT_B OUT";
+
+ assigned-clocks = < CLKID_MPLL2>,
+ < CLKID_MPLL0>,
+ < CLKID_MPLL1>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <_a>;
+ };
+
+ dai-link-1 {
+ sound-dai = <_b>;
+ };
+
+ dai-link-2 {
+ sound-dai = <_c>;
+ };
+
+ /* 8ch hdmi interface */
+ dai-link-3 {
+ sound-dai = <_b>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-0 = <1 1>;
+ dai-tdm-slot-tx-mask-1 = <1 1>;
+ dai-tdm-slot-tx-mask-2 = <1 1>;
+ dai-tdm-slot-tx-mask-3 = <1 1>;
+ mclk-fs = <256>;
+
+ codec {
+ sound-dai = < TOHDMITX_I2S_IN_B>;
+ };
+ };
+
+ dai-link-4 {
+ sound-dai = < TOHDMITX_I2S_OUT>;
+
+ codec {
+ sound-dai = <_tx>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+_audio {
+ status = "okay";
+};
+
+_a {
+ status = "okay";
+};
+
+_b {
+ status = "okay";
+};
+
+_c {
+ status = "okay";
+};
+
+_b {
+ status = "okay";
+};
+
+_b {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
2.17.1
Re: [f2fs-dev] [PATCH] f2fs: fix checkpoint=disable:%u%%
On 2020/5/16 9:04, Jaegeuk Kim wrote: > When parsing the mount option, we don't have sbi->user_block_count. > Should do it after getting it. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,
