[PATCH v3] ACPI/processor_idle: Remove dummy wait if kernel is in guest mode

will trap to hyervisor. It's not needed to do dummy wait after the inb() call. So we remove the dummy io port access to avoid unnecessary VMexit. We keep dummy io port access to maintain timing for native environment. Signed-off-by: Yin Fengwei --- ChangeLog: v2 -> v3: - Remove dummy i

Re: [PATCH v2] ACPI / processor_idle: use ndelay instead of io port access for wait

On 2019/10/18 下午6:12, Rafael J. Wysocki wrote: On Wednesday, October 16, 2019 7:56:17 AM CEST Yin, Fengwei wrote: Hi David, On 10/15/2019 7:48 PM, David Laight wrote: From: Yin Fengwei Sent: 15 October 2019 09:04 In function acpi_idle_do_entry(), an ioport access is used for dummy wait to

Re: [PATCH v2] ACPI / processor_idle: use ndelay instead of io port access for wait

On 10/18/2019 6:12 PM, Rafael J. Wysocki wrote: On Wednesday, October 16, 2019 7:56:17 AM CEST Yin, Fengwei wrote: Hi David, On 10/15/2019 7:48 PM, David Laight wrote: From: Yin Fengwei Sent: 15 October 2019 09:04 In function acpi_idle_do_entry(), an ioport access is used for dummy wait to

Re: [PATCH v2] ACPI / processor_idle: use ndelay instead of io port access for wait

Hi David, On 10/15/2019 7:48 PM, David Laight wrote: From: Yin Fengwei Sent: 15 October 2019 09:04 In function acpi_idle_do_entry(), an ioport access is used for dummy wait to guarantee hardware behavior. But it could trigger unnecessary vmexit in virtualization environment. If we run linux

[PATCH v2] ACPI / processor_idle: use ndelay instead of io port access for wait

of io port access to guarantee hardware behavior and avoid unnecessary VMexit. Signed-off-by: Yin Fengwei --- ChangeLog: v1 -> v2: - Use ndelay instead of dead loop for dummy delay. drivers/acpi/processor_idle.c | 28 +--- 1 file changed, 25 insertions(+), 3 deleti

Re: [RESEND] ACPI / processor_idle: use dead loop instead of io port access for wait

On 10/14/2019 5:38 PM, Rafael J. Wysocki wrote: On Friday, October 11, 2019 3:30:41 PM CEST Yin, Fengwei wrote: On 10/11/2019 5:05 PM, Rafael J. Wysocki wrote: Sorry for the delay. No problem. On Monday, September 9, 2019 9:39:37 AM CEST Yin Fengwei wrote: In function acpi_idle_do_entry

Re: [RESEND] ACPI / processor_idle: use dead loop instead of io port access for wait

On 10/14/2019 5:38 PM, Rafael J. Wysocki wrote: On Friday, October 11, 2019 3:30:41 PM CEST Yin, Fengwei wrote: On 10/11/2019 5:05 PM, Rafael J. Wysocki wrote: Sorry for the delay. No problem. On Monday, September 9, 2019 9:39:37 AM CEST Yin Fengwei wrote: In function acpi_idle_do_entry

Re: [RESEND] ACPI / processor_idle: use dead loop instead of io port access for wait

On 10/11/2019 5:05 PM, Rafael J. Wysocki wrote: Sorry for the delay. No problem. On Monday, September 9, 2019 9:39:37 AM CEST Yin Fengwei wrote: In function acpi_idle_do_entry(), we do an io port access to guarantee hardware behavior. But it could trigger unnecessary vmexit for

[RESEND] ACPI / processor_idle: use dead loop instead of io port access for wait

oid unnecessary vmexit. Signed-off-by: Yin Fengwei --- drivers/acpi/processor_idle.c | 33 ++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index ed56c6d20b08..676553228e8f 100644 --- a/driv

Re: About compiler memory barrier for atomic_set/atomic_read on x86

Hi Peter, On 9/4/2019 7:38 AM, Yin, Fengwei wrote: Hi Peter, On 9/3/2019 10:06 PM, Peter Zijlstra wrote: On Tue, Sep 03, 2019 at 09:23:41PM +0800, Yin, Fengwei wrote: Hi Peter, There is one question regarding following commit: commit 69d927bba39517d0980462efc051875b7f4db185 Author: Peter

Re: About compiler memory barrier for atomic_set/atomic_read on x86

Hi Peter, On 9/3/2019 10:06 PM, Peter Zijlstra wrote: On Tue, Sep 03, 2019 at 09:23:41PM +0800, Yin, Fengwei wrote: Hi Peter, There is one question regarding following commit: commit 69d927bba39517d0980462efc051875b7f4db185 Author: Peter Zijlstra Date: Wed Apr 24 13:38:23 2019 +0200

About compiler memory barrier for atomic_set/atomic_read on x86

lso include compiler memory barrier on x86? Thanks. Regards Yin, Fengwei

[PATCH v2] fs: fs_parser: avoid NULL param->string to kstrtouint

gt;string is passed to kstrtouint and trigger NULL pointer access. Reported-by: syzbot+398343b7c1b1b9892...@syzkaller.appspotmail.com Fixes: 71cbb7570a9a ("vfs: Move the subtype parameter into fuse") Signed-off-by: Yin Fengwei --- ChangeLog: v1 -> v2: - Fix typo in v1 - Remove

[PATCH] fs: fs_parser: avoid NULL param->string to kstrtouint

gt;string is passed to kstrtouint and trigger NULL pointer access. Reported-by: syzbot+398343b7c1b1b9892...@syzkaller.appspotmail.com Fixes: 71cbb7570a9a ("vfs: Move the subtype parameter into fuse") Signed-off-by: Yin Fengwei --- fs/fs_parser.c | 4 1 file changed, 4 insertions(

[PATCH] ACPI / processor_idle: use dead loop instead of io port access for wait

oid unnecessary trap to HV. Signed-off-by: Yin Fengwei --- drivers/acpi/processor_idle.c | 33 ++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index abb559cd28d7..dcc447e59885 100644 --

[PATCH] mmc: block: remove the check for whole block device for ioctl.

From: Fengwei Yin a5f5774c55a2e3ed75f4d6c5556b7bfcb726e6f0 introduced the whole block device checking for MMC_IOC_CMD while the old code has no such check. It breaks some ioctl call like BLKROSET from user space. An example is "adb remount" cmd. It prints out following error message: "remount of

Is this a preempt issue in drivers/input/evdev.c

evdev->open++ and input_open_devie() <- reschedule input_close_device() Should we introduce a mutex here? Or do I miss something? Thanks. Regards Yin, Fengwei - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in th