Hi, Rafael.
I added my opinion below.
2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> Hi, Lv Zheng.
>>
>> I added my handcrafted ACPI table under your request, because
>> &quo
Hi, Lv Zheng.
I added my handcrafted ACPI table under your request, because
"acpidump -c on" and "acpidump -c off" doesn't work.
2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> Hello,
>
> I attached the test results below,
>
> 2017-02
Hi, Rafeal.
I added my opinion below.
2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> Hi, Rafael.
>>
>> I added my opinion below.
>>
>> 2017-02-24 20:50 GMT+09:0
Hi, Rafael.
I agree with you and I added my opinion below.
2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> Hi, Rafeal.
>>
>> I added my opinion below.
>>
>> 2017-02-
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without
ng, I change the split_huge_pmd() macro function to static
inline function and static inline null function.
Inline function works like a macro function, therefore there is no impact on
Linux kernel working.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
include/linux/huge_mm.h | 20 +
..@vger.kernel.org
>> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
>> Wysocki
>> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>
>> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
>> >
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I found a kernel panic while I tested latest kernel version.
The kernel panic log is as follows:
>[0.058851] BUG: unable to handle kernel NULL pointer dereference at
>0010
>[0.0
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
drivers/acpi/acpica/dswstate.c | 7 ++-
1 file changed, 6
lt;= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
drivers/acpi/acpica/nseval.c | 8
1 fil
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
Changes since V1: move stack_top into loop and change loop c
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added
, it seems that incremental patch is not needed.
If you have any request, please let me know.
Best regards.
ps) I am sending email again after removing HTML part.
2017-06-26 7:12 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> Hello, Andy.
>
> Thank you for your reply.
>
> Patch V4 is
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added
...@intel.com>:
> This might be a dumb question, but isn't the system basically hosed once the
> ACPI subsystem is shutdown?
>
>
>> -----Original Message-
>> From: Seunghun Han [mailto:kkama...@gmail.com]
>> Sent: Wednesday, June 14, 2017 4:08 AM
>> To: Zheng,
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
drivers/acpi/acpica/dsutils.c | 9 -
1 file changed,
Hello, Greg.
2018-02-23 19:52 GMT+09:00 Greg Kroah-Hartman <gre...@linuxfoundation.org>:
> On Fri, Feb 23, 2018 at 07:13:50PM +0900, Seunghun Han wrote:
>> I am Seunghun Han and a senior security researcher at National Security
>> Research Institute of South Korea.
>
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a critical security issue which can make kernel panic in userspace.
After analyzing the issue carefully, I found that MCE driver in the kernel
has a problem which can be occurred
Fix a typo in a comment line of pti.c.
Signed-off-by: Seunghun Han <kkama...@gmail.com>
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index ce38f16..631507f 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a security issue which can make kernel panic in userspace. After
analyzing the issue carefully, I found that MCE driver in the kernel has a
problem which can be occurred in SMP
Hi, Borislav.
I made new patch according to your advice.
The patch is here, https://lkml.org/lkml/2018/2/28/1230.
If you have any advice about it, please let me know.
Best regards.
Seunghun.
2018-03-01 5:31 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> I am Seunghun Han and a senior
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a security issue which can make kernel panic in userspace. After
analyzing the issue carefully, I found that MCE driver in the kernel has a
problem which can be occurred in SMP
Hi, Borislav.
Thank you for your good advice.
According to your advice, I will make and send PATCH v3.
Best regards.
Seunghun.
2018-03-02 21:14 GMT+09:00 Borislav Petkov <b...@alien8.de>:
> On Thu, Mar 01, 2018 at 05:31:31AM +0900, Seunghun Han wrote:
>> Changes since v1: add
Hello, Borislav.
2018-02-28 18:32 GMT+09:00 Borislav Petkov <b...@alien8.de>:
> On Mon, Feb 26, 2018 at 05:05:04AM +0900, Seunghun Han wrote:
>> >> It is a critical security problem because the attacker can make kernel
>> >> panic
>> >> by writing a
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a security issue which can make kernel panic in userspace. After
analyzing the issue carefully, I found that MCE driver in the kernel has a
problem which can be occurred in SMP
Hi, Borislav.
I made new patch according to your advice.
The patch is here, https://lkml.org/lkml/2018/2/28/1230.
If you have any advice about it, please let me know.
Best regards.
Seunghun.
2018-03-01 5:31 GMT+09:00 Seunghun Han :
> I am Seunghun Han and a senior security researc
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han
---
drivers/acpi/acpica/dsutils.c | 9 -
1 file changed, 8 insertions(+), 1 del
Fix a typo in a comment line of pti.c.
Signed-off-by: Seunghun Han
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index ce38f16..631507f 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -332,7 +332,7
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a critical security issue which can make kernel panic in userspace.
After analyzing the issue carefully, I found that MCE driver in the kernel
has a problem which can be occurred
Hello, Greg.
2018-02-23 19:52 GMT+09:00 Greg Kroah-Hartman :
> On Fri, Feb 23, 2018 at 07:13:50PM +0900, Seunghun Han wrote:
>> I am Seunghun Han and a senior security researcher at National Security
>> Research Institute of South Korea.
>>
>> I found a critical se
Hi, Borislav.
Thank you for your good advice.
According to your advice, I will make and send PATCH v3.
Best regards.
Seunghun.
2018-03-02 21:14 GMT+09:00 Borislav Petkov :
> On Thu, Mar 01, 2018 at 05:31:31AM +0900, Seunghun Han wrote:
>> Changes since v1: add mce_sysfs_mutex
I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.
I found a security issue which can make kernel panic in userspace. After
analyzing the issue carefully, I found that MCE driver in the kernel has a
problem which can be occurred in SMP
Hello, Borislav.
2018-02-28 18:32 GMT+09:00 Borislav Petkov :
> On Mon, Feb 26, 2018 at 05:05:04AM +0900, Seunghun Han wrote:
>> >> It is a critical security problem because the attacker can make kernel
>> >> panic
>> >> by writing a value to the check
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I found a kernel panic while I tested latest kernel version.
The kernel panic log is as follows:
>[0.058851] BUG: unable to handle kernel NULL pointer dereference at
>0010
>[0.0
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han
---
drivers/acpi/acpica/dswstate.c | 7 ++-
1 file changed, 6 insertions(+), 1 delet
lt;= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han
---
drivers/acpi/acpica/nseval.c | 8
1 file changed, 8 insertions(+)
d
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han
---
Changes since V1: move stack_top into loop and change loop condition.
drivers/acpi/ac
>
> > From: Seunghun Han
> > Sent: Friday, August 30, 2019 12:55 PM
> > To: Safford, David (GE Global Research, US)
> > Cc: Jason Gunthorpe ; Jarkko Sakkinen
> > ; Peter Huewe ;
> > open list:TPM DEVICE DRIVER ; Linux
> > Kernel Mailing List
&
>
> > From: Seunghun Han
> > Sent: Friday, August 30, 2019 12:55 PM
> > To: Safford, David (GE Global Research, US)
> > Cc: Jason Gunthorpe ; Jarkko Sakkinen
> > ; Peter Huewe ;
> > open list:TPM DEVICE DRIVER ; Linux
> > Kernel Mailing List
&
>
> On Tue, 2019-09-03 at 07:42 +0900, Seunghun Han wrote:
> > I have a question. Do you think this patch is not enough to handle
> > AMD's fTPM problem? If so, would you tell me about it? I will change
> > my patch.
>
> I have no new feedback to give at thi
> I tried your patch out on my systems with a "reserved" but not "NVS"
> region conflict, and you are correct - the region is not busy, and
> the driver is able to map the buffers with your patch.
>
> > First of all, I misunderstood your message.
> > I have to tell you about the buffer size
>
> On Tue, 2019-09-03 at 18:56 +0900, Seunghun Han wrote:
> > Thank you for your notification. I am sorry. I missed it and
> > misunderstood Jarkko's idea. So, I would like to invite Matthew
> > Garrett to this thread and attach my opinion on that. The problem is
>
I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got an AMD
system which had a Ryzen Threadripper 1950X and MSI mainboard, and I had
a problem with AMD's fTPM. My machine showed an error message below, and
the fTPM didn't work because of it.
[5.732084] tpm_crb MSFT0101:00
I'm Seunghun Han and work at the Affiliated Institute of ETRI. I found
a bug related to improper buffer size calculation in crb_fixup_cmd_size
function.
When the TPM CRB regions are two or more, the crb_map_io function calls
crb_fixup_cmd_size twice to calculate command buffer size and response
I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got
an AMD system which had a Ryzen Threadripper 1950X and MSI mainboard, and
I had a problem with AMD's fTPM. My machine showed an error message below,
and the fTPM didn't work because of it.
[ 5.732084] tpm_crb MSFT0101:00: can't
>
> On Mon, Aug 26, 2019 at 02:40:19AM +0900, Seunghun Han wrote:
> > I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got an AMD
> > system which had a Ryzen Threadripper 1950X and MSI mainboard, and I had
> > a problem with AMD's fTPM. My machine showe
>
> On Mon, Aug 26, 2019 at 04:44:00PM +0900, Seunghun Han wrote:
> > I'm Seunghun Han and work at the Affiliated Institute of ETRI. I found
>
> You can drop the first sentence from the commit message. The SoB below
> is sufficient.
Thank you, and I will remove it from next
> > From: linux-integrity-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Jarkko Sakkinen
> > Sent: Monday, August 26, 2019 1:59 AM
> > To: Seunghun Han
> > Cc: Peter Huewe ; Thomas Gleixner
> > ; linux-kernel@vger.kernel.org; linux-
> > inte
>
> On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han wrote:
> > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like
> > the reserved area so that AMD's fTPM regions could be assigned in it.
>
> drivers/acpi/nvs.c saves and restores the contents of NVS
.
Signed-off-by: Seunghun Han
---
Changes in v2: same as v1.
drivers/char/tpm/tpm_crb.c | 44 +++---
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index e59f1f91d7f3..14f486c23af2 100644
and response buffer size calculation. I also made a patch to detect TPM
regions in ACPI NVS and work around it.
Changes in v2:
- fix a warning of kbuild test robot. The link is below.
https://lkml.org/lkml/2019/8/31/217
Seunghun Han (2):
tpm: tpm_crb: enhance command and response buffer size
region and ACPI NVS before it mapped the region. If some
intersects are detected, the function just calls devm_ioremap() for
a workaround. If there is no intersect, it calls devm_ioremap_resource().
Signed-off-by: Seunghun Han
---
Changes in v2: fix a warning of kbuild test robot. The link is below
>
> On Mon, Sep 09, 2019 at 06:09:05PM +0900, Seunghun Han wrote:
> > The purpose of crb_fixup_cmd_size() function is to work around broken
> > BIOSes and get the trustable size between the ACPI region and register.
> > When the TPM has a command buffer and respo
>
> On Tue, Sep 10, 2019 at 03:42:15PM +0100, Jarkko Sakkinen wrote:
> > On Mon, Sep 09, 2019 at 06:09:06PM +0900, Seunghun Han wrote:
> > > I got an AMD system which had a Ryzen Threadripper 1950X and MSI
> > > mainboard, and I had a problem with AMD's fT
> > And why is this allocating memory inside the acpi table walker? It
> > seems to me like the memory should be allocated once the mapping is
> > made.
> >
>
> Yes, this looks bad. Letting the walker build the list and then using
> it is, probably, a better idea.
>
> > Maybe all the mappings
>
> On Thu, Aug 29, 2019 at 06:34:37PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Aug 28, 2019 at 06:36:04PM +0900, Seunghun Han wrote:
> > > >
> > > > On Wed, Aug 28, 2019 at 01:36:30AM +0900, Seunghun Han wrote:
> > > >
> > > > > I g
region and ACPI NVS before it mapped the region. If some
intersects are detected, the function just calls devm_ioremap() for
a workaround. If there is no intersect, it calls devm_ioremap_resource().
Signed-off-by: Seunghun Han
---
drivers/char/tpm/tpm_crb.c | 25 +++--
1 file
.
Signed-off-by: Seunghun Han
---
drivers/char/tpm/tpm_crb.c | 44 +++---
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index e59f1f91d7f3..14f486c23af2 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b
and response buffer size calculation. I also made a patch to detect TPM
regions in ACPI NVS and work around it.
Seunghun Han (2):
tpm: tpm_crb: enhance command and response buffer size calculation
code
tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's
fTPM
drivers
> > On Thu, Aug 29, 2019 at 06:34:37PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, Aug 28, 2019 at 06:36:04PM +0900, Seunghun Han wrote:
> > > > >
> > > > > On Wed, Aug 28, 2019 at 01:36:30AM +0900, Seunghun Han wrote:
> > > > >
> &
>
> On Fri, Aug 30, 2019 at 06:56:39PM +0900, Seunghun Han wrote:
> > I got an AMD system which had a Ryzen Threadripper 1950X and MSI
> > mainboard, and I had a problem with AMD's fTPM. My machine showed an error
> > message below, and the fTPM didn't work because of
>
> On Fri, Aug 30, 2019 at 10:54:59PM +0900, Seunghun Han wrote:
>
> > When I tested this patch in my machine, it seemed that ACPI NVS was
> > saved after TPM CRB driver sent "TPM2_Shutdown(STATE)" to the fTPM
> > while suspending. Then, ACPI NVS was restor
>
> > From: linux-integrity-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Seunghun Han
> > Sent: Friday, August 30, 2019 9:55 AM
> > To: Jason Gunthorpe
> > Cc: Jarkko Sakkinen ; Peter Huewe
> > ; open list:TPM DEVICE DRIVER > integr...@v
>
> On Fri, Aug 30, 2019 at 05:58:39PM +, Safford, David (GE Global Research,
> US) wrote:
> > > Thank you for your advice. We also discussed earlier and concluded that
> > > checking and raw remapping are enough to work around this. The link is
> > > here, https://lkml.org/lkml/2019/8/29/962
>
> On Fri, Sep 13, 2019 at 03:00:06PM +0100, Jarkko Sakkinen wrote:
> > On Wed, Sep 11, 2019 at 02:17:48PM +0900, Seunghun Han wrote:
> > > Vanya,
> > > I also made a patch series to solve AMD's fTPM. My patch link is here,
> > > https://lkml.org/lkml/20
> > > Matthew pointed out that having a hook in NVS driver is better solution
> > > because it is nil functionality if the TPM driver is loaded. We need
> > > functions to:
> > >
> > > 1. Request a region from the NVS driver (when tpm_crb loads)
> > > 2. Release a region back to the NVS Driver
Sorry for my mistake.
I misunderstood some functions in nvs.c. So I have fixed it and sent
my email again. My email is below.
> > > Matthew pointed out that having a hook in NVS driver is better solution
> > > because it is nil functionality if the TPM driver is loaded. We need
> > > functions
> Eessentially what you want to do is to detach and backup the original
> NVS resources and put them back to the list with insert_resource() when
> tpm_crb is removed. At least I think this is what should be done but you
> should CC your patch also to the ACPI list for feedback.
>
> /Jarkko
Yes,
>
> On Mon, Aug 26, 2019 at 10:40:25AM -0700, Matthew Garrett wrote:
> > On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han wrote:
> > > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like
> > > the reserved area so that AMD's fTPM regions could be a
> On Tue, Aug 27, 2019 at 1:23 AM Seunghun Han wrote:
> > If the regions allocated in the NVS region need to be handled by a
> > driver, the callback mechanism is good for it. However, this case
> > doesn't need it because the regions allocated in NVS are just I/O
>
>
> On Wed, Aug 28, 2019 at 01:36:30AM +0900, Seunghun Han wrote:
>
> > I got your point. Is there any problem if some regions which don't
> > need to be handled in NVS area are saved and restored? If there is a
> > problem, how about adding code for ignor
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added
, it seems that incremental patch is not needed.
If you have any request, please let me know.
Best regards.
ps) I am sending email again after removing HTML part.
2017-06-26 7:12 GMT+09:00 Seunghun Han :
> Hello, Andy.
>
> Thank you for your reply.
>
> Patch V4 is the last patch which
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added
ght be a dumb question, but isn't the system basically hosed once the
> ACPI subsystem is shutdown?
>
>
>> -Original Message-
>> From: Seunghun Han [mailto:kkama...@gmail.com]
>> Sent: Wednesday, June 14, 2017 4:08 AM
>> To: Zheng, Lv ; Moore, Robert
>> ;
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without
ng, I change the split_huge_pmd() macro function to static
inline function and static inline null function.
Inline function works like a macro function, therefore there is no impact on
Linux kernel working.
Signed-off-by: Seunghun Han
---
include/linux/huge_mm.h | 20
1 fil
Hi, Lv Zheng.
I added my handcrafted ACPI table under your request, because
"acpidump -c on" and "acpidump -c off" doesn't work.
2017-02-21 19:36 GMT+09:00 Seunghun Han :
> Hello,
>
> I attached the test results below,
>
> 2017-02-21 9:53 GMT+09:00 Rowafael J
Hi, Rafael.
I added my opinion below.
2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> Hi, Lv Zheng.
>>
>> I added my handcrafted ACPI table under your request, because
>> "acpidump -c on&quo
Hi, Rafeal.
I added my opinion below.
2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> Hi, Rafael.
>>
>> I added my opinion below.
>>
>> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> >
Hi, Rafael.
I agree with you and I added my opinion below.
2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> Hi, Rafeal.
>>
>> I added my opinion below.
>>
>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wyso
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
>> Wysocki
>> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>
>> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han wrote:
>> > Hi, Rafael.
>> >
>> > I agree with
Commit-ID: afabde6986911394c95c596f96d2ac833eef04cc
Gitweb: http://git.kernel.org/tip/afabde6986911394c95c596f96d2ac833eef04cc
Author: Seunghun Han <kkama...@gmail.com>
AuthorDate: Tue, 18 Jul 2017 18:20:44 +0900
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: e708e35ba6d89ff785b225cd07dcccab04fa954a
Gitweb: http://git.kernel.org/tip/e708e35ba6d89ff785b225cd07dcccab04fa954a
Author: Seunghun Han <kkama...@gmail.com>
AuthorDate: Tue, 18 Jul 2017 18:20:44 +0900
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 20
Commit-ID: c5b679f5c9e3851ee118d95961def374bb3b4ce6
Gitweb: https://git.kernel.org/tip/c5b679f5c9e3851ee118d95961def374bb3b4ce6
Author: Seunghun Han <kkama...@gmail.com>
AuthorDate: Wed, 7 Mar 2018 13:32:15 +0900
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Thu
Commit-ID: b3b7c4795ccab5be71f080774c45bbbcc75c2aaf
Gitweb: https://git.kernel.org/tip/b3b7c4795ccab5be71f080774c45bbbcc75c2aaf
Author: Seunghun Han <kkama...@gmail.com>
AuthorDate: Tue, 6 Mar 2018 15:21:43 +0100
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Thu
Commit-ID: c5b679f5c9e3851ee118d95961def374bb3b4ce6
Gitweb: https://git.kernel.org/tip/c5b679f5c9e3851ee118d95961def374bb3b4ce6
Author: Seunghun Han
AuthorDate: Wed, 7 Mar 2018 13:32:15 +0900
Committer: Thomas Gleixner
CommitDate: Thu, 8 Mar 2018 12:33:21 +0100
x86/pti: Fix a comment
Commit-ID: b3b7c4795ccab5be71f080774c45bbbcc75c2aaf
Gitweb: https://git.kernel.org/tip/b3b7c4795ccab5be71f080774c45bbbcc75c2aaf
Author: Seunghun Han
AuthorDate: Tue, 6 Mar 2018 15:21:43 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 8 Mar 2018 15:36:27 +0100
x86/MCE: Serialize
Commit-ID: afabde6986911394c95c596f96d2ac833eef04cc
Gitweb: http://git.kernel.org/tip/afabde6986911394c95c596f96d2ac833eef04cc
Author: Seunghun Han
AuthorDate: Tue, 18 Jul 2017 18:20:44 +0900
Committer: Thomas Gleixner
CommitDate: Tue, 18 Jul 2017 17:39:54 +0200
x86/ioapic: Pass
Commit-ID: e708e35ba6d89ff785b225cd07dcccab04fa954a
Gitweb: http://git.kernel.org/tip/e708e35ba6d89ff785b225cd07dcccab04fa954a
Author: Seunghun Han
AuthorDate: Tue, 18 Jul 2017 18:20:44 +0900
Committer: Ingo Molnar
CommitDate: Thu, 20 Jul 2017 10:28:10 +0200
x86/ioapic: Pass
96 matches
Mail list logo
