Commit-ID: 0a23ebc66a46786769dd68bfdaa3102345819b9c
Gitweb: https://git.kernel.org/tip/0a23ebc66a46786769dd68bfdaa3102345819b9c
Author: Junichi Nomura
AuthorDate: Thu, 11 Apr 2019 15:49:32 +0200
Committer: Borislav Petkov
CommitDate: Thu, 6 Jun 2019 20:28:37 +0200
x86/boot: Use
Hi Kairui,
On 5/13/19 5:02 PM, Baoquan He wrote:
> On 05/13/19 at 09:50am, Borislav Petkov wrote:
>> On Mon, May 13, 2019 at 03:32:54PM +0800, Baoquan He wrote:
>> So we're going to try it again this cycle and if there's no fallout, it
>> will go upstream. If not, it will have to be fixed. The usu
Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
in the early parsing code tries to search RSDP from EFI table but
whose address is virtual.
Since kexec(1) provides physical address of config_table via boot_params,
Hi Luis,
On 02/15/18 07:59, Luis R. Rodriguez wrote:
> curious if you ever got to adapt a test case for xfstests for your patch
> "fs: global sync to not clear error status of individual inodes", which
> got merged as of v4.4 as:
>
> aa750fd71c242dba02ee2034e15fbd7d0cdb2461 mm/filemap.c: make glo
On 05/31/17 02:59, Mikulas Patocka wrote:
>>> 2. use the PAT patch and revert the change to the function pat_ap_init
>>> - i.e. change it to the original:
>>> static void pat_ap_init(u64 pat)
>>> {
>>> if (!boot_cpu_has(X86_FEATURE_PAT)) {
>>
>> Joy.
>
> It is interesting - does it mean that t
Commit-ID: 2e86222c67bb5d942da68e8415749b32db208534
Gitweb: http://git.kernel.org/tip/2e86222c67bb5d942da68e8415749b32db208534
Author: Junichi Nomura
AuthorDate: Mon, 9 Jan 2017 12:41:47 +0100
Committer: Thomas Gleixner
CommitDate: Mon, 9 Jan 2017 23:11:15 +0100
x86/microcode/intel
Commit-ID: 9fcf5ba2ef908af916e9002891fbbca20ce4dc98
Gitweb: http://git.kernel.org/tip/9fcf5ba2ef908af916e9002891fbbca20ce4dc98
Author: Junichi Nomura
AuthorDate: Mon, 9 Jan 2017 12:41:46 +0100
Committer: Thomas Gleixner
CommitDate: Mon, 9 Jan 2017 23:11:14 +0100
x86/microcode/intel
On 01/06/17 09:02, Borislav Petkov wrote:
> On Thu, Jan 05, 2017 at 11:52:07PM +0000, Junichi Nomura wrote:
>>>> + p = kzalloc(sizeof(struct ucode_patch), GFP_KERNEL);
>>>
>>> Perhaps sizeof(*p) ?
>>
>> Yeah, that might be preferred.
>
On 01/05/17 19:17, Borislav Petkov wrote:
> On Thu, Jan 05, 2017 at 04:45:18AM +0000, Junichi Nomura wrote:
>> In generic_load_microcode(), curr_mc_size is the size of the last
>> allocated buffer and could be smaller than the actual size of the
>> buffer pointed to by "n
On 01/06/17 02:44, Andy Shevchenko wrote:
> On Thu, Jan 5, 2017 at 3:03 AM, Junichi Nomura wrote:
>> We allocate struct ucode_patch here.
>>
>> "size" is a size of microcode data and used for kmemdup() later
>> in this function.
>>
>> Signed-off-
On 01/05/17 10:02, Junichi Nomura wrote:
> In generic_load_microcode(), curr_mc_size is the size of the last
> allocated buffer and not always the size of the buffer pointed to by
> "new_mc".
...
> @@ -864,6 +864,7 @@ static enum ucode_state generic_load_microcode(int cpu,
In generic_load_microcode(), curr_mc_size is the size of the last
allocated buffer and not always the size of the buffer pointed to by
"new_mc".
Without this fix, we could get oops like this:
BUG: unable to handle kernel paging request at c9000e30f000
IP: __memcpy+0x12/0x20
...
Call T
We allocate struct ucode_patch here.
"size" is a size of microcode data and used for kmemdup() later
in this function.
Signed-off-by: Jun'ichi Nomura
Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microco
early_init_intel() calls sync_core() before rdmsr(MSR_IA32_UCODE_REV),
assuming sync_core() is effectively CPUID(eax=1). However the assumption
no longer holds since commit c198b121b1a1 ("x86/asm: Rewrite sync_core()
to use IRET-to-self").
As a result, kernel fails to detect the revision of microc
Commit 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for
SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg()
for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list.
That could lead to following list corruption problems:
1) low-level func
fs. Below is the bisect log
>>> and attached the kernel .config file. Let me know if you need any other
>>> information.
>>
>> AFAICS, it's the same one that got reported yesterday by Junichi Nomura.
>> Folks, could you check if the delta below fixes it?
>
On 12/22/15 12:59, Kent Overstreet wrote:
> reproduced it with 32 bit pae:
>
>> 1. Exclude memory above 4G line with boot param "max_addr=4G".
>
> doesn't work - max_addr=1G doesn't work either
>
>> 2. Disable highmem with "highmem=0".
>
> works!
>
>> 3. Try booting 64bit kernel.
>
> works
b
Hello Baoquan,
On 12/16/15 23:23, b...@redhat.com wrote:
> A little earlier Peter Hurley has posted a patch to fix this problem.
> https://lkml.org/lkml/2015/11/27/546
>
> It may be found firstly on arm by Pratyush Anand .
> I found it too this week on Fedora 23.
Thank you for the info! It's gre
Since kernel v4.4-rc1, kdump capture service with Fedora23 / RHEL7.2
almost always fails on my test system which uses serial console. It
used to work fine until kernel v4.3.
Kdump fails with an error like this:
kdump.sh[1040]: /bin/kdump.sh: line 8: /dev/console: Input/output error
The line 8 o
tags is freed in blk_mq_free_rq_map() and should not be used after that.
The problem doesn't manifest if CONFIG_CPUMASK_OFFSTACK is false because
free_cpumask_var() is nop.
tags->cpumask is allocated in blk_mq_init_tags() so it's natural to
free cpumask in its counter part, blk_mq_free_tags().
Fi
Commit-ID: 590f07874e8e3c83729b919312c65aea2533c8cf
Gitweb: http://git.kernel.org/tip/590f07874e8e3c83729b919312c65aea2533c8cf
Author: Junichi Nomura
AuthorDate: Mon, 14 Sep 2015 07:38:36 +
Committer: Thomas Gleixner
CommitDate: Thu, 17 Sep 2015 16:22:11 +0200
x86/pci/dma: Fix gfp
On 09/16/15 07:02, Andrew Morton wrote:
> It would be nice to capture the test case(s) somewhere permanent.
> Possibly in tools/testing/selftests, but selftests is more for
> peculiar
> linux-specific things. LTP or xfstests would be a better place.
This is a xfstests version of my test case.
(D
filemap_fdatawait() is a function to wait for on-going writeback
to complete but also consume and clear error status of the mapping
set during writeback.
The latter functionality is critical for applications to detect
writeback error with system calls like fsync(2)/fdatasync(2).
However filemap_fd
On 09/16/15 00:20, Tejun Heo wrote:
>> @@ -2121,7 +2121,13 @@ static void wait_sb_inodes(struct super_block *sb)
>> iput(old_inode);
>> old_inode = inode;
>>
>> -filemap_fdatawait(mapping);
>> +/*
>> + * Wait for on-going writeback to
On 09/16/15 07:02, Andrew Morton wrote:
> It would be nice to capture the test case(s) somewhere permanent.
> Possibly in tools/testing/selftests, but selftests is more for peculiar
> linux-specific things. LTP or xfstests would be a better place.
I'll check xfstests if I can adapt the test case
On 09/15/15 17:39, Jun'ichi Nomura wrote:
>> However if admins run a command such as sync or fsfreeze along side,
>> fsync/fdatasync may return success even if writeback has failed.
>> That could lead to data corruption.
>
> For reproducing the problem, compile the attached C program (iogen.c)
> an
filemap_fdatawait() is a function to wait for on-going writeback
to complete but also consume and clear error status of the mapping
set during writeback.
The latter functionality is critical for applications to detect
writeback error with system calls like fsync(2)/fdatasync(2).
However filemap_fd
Applications use fsync/fdatasync to make sure data is written back to
storage. It is expected that those system calls return error if
writeback has failed (e.g. disk/transport failure, memory failure..)
However if admins run a command such as sync or fsfreeze along side,
fsync/fdatasync may return
> However if admins run a command such as sync or fsfreeze along side,
> fsync/fdatasync may return success even if writeback has failed.
> That could lead to data corruption.
For reproducing the problem, compile the attached C program (iogen.c)
and run with 'runtest.sh' script in the next mail:
On 09/14/15 16:38, Junichi Nomura wrote:
> Commit 6894258eda2f reversed the order of gfp_flags adjustment in
> dma_alloc_attrs() for x86 [arch/x86/kernel/pci-dma.c]
> As a result, relevant flags set by dma_alloc_coherent_gfp_flags()
> is just discarded and causes coherent DMA memor
Commit 6894258eda2f reversed the order of gfp_flags adjustment in
dma_alloc_attrs() for x86 [arch/x86/kernel/pci-dma.c]
As a result, relevant flags set by dma_alloc_coherent_gfp_flags()
is just discarded and causes coherent DMA memory allocation failure
on some devices.
Fixes: 6894258eda2f ("dma-m
On 06/26/15 15:41, Linus Torvalds wrote:
> On Jun 25, 2015 23:17, "Junichi Nomura" <mailto:j-nom...@ce.jp.nec.com>> wrote:
>> On 06/25/15 23:37, Jens Axboe wrote:
>> > block, dm: don't copy bios for request clones
>>
>> this change sh
Hi Jens,
On 06/25/15 23:37, Jens Axboe wrote:
> block, dm: don't copy bios for request clones
this change should not be pushed to mainline yet.
Firstly, Christoph has a newer version of the patch that fixes silent
data corruption problem:
https://www.redhat.com/archives/dm-devel/2015-May
On 07/09/14 12:55, Alexey Kardashevskiy wrote:
> On 07/08/2014 08:28 PM, Junichi Nomura wrote:
>> It seems Bart's issue has gone with the attached patch:
>> http://www.redhat.com/archives/dm-devel/2014-July/msg00035.html
>> Could you try if it makes any difference on y
On 07/02/14 04:39, Mike Snitzer wrote:
> On Mon, Jun 30 2014 at 6:30am -0400,
> Paul Mackerras wrote:
>
>> I have a machine on which 3.15 usually fails to boot, and 3.14 boots
>> every time. The machine is a POWER8 2-socket server with 20 cores
>> (thus 160 CPUs), 128GB of RAM, and 7 SCSI disks
35 matches
Mail list logo
