I don't know if fix is functional correct, but at least it compiles now.
It failed before with a config for an AMD CPU.
Bug was introduced with commit d01b1f96a82e5dd7841a1d39db3abfdaf95f70ab
"perf/x86/intel: Make cpuc allocations consistent" which was merged
with 004cc08675b761fd82288bab1b5ba5e1ca746eca.
Signed-off-by: Alexander Holler <holler(a)ahsoftware.de>
Cc: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
---
arch/x86/events/perf_event.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index b04ae6c..a759557 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -1033,12 +1033,12 @@ static inline int intel_pmu_init(void)
return 0;
}
-static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
+static inline int intel_cpuc_prepare(struct cpu_hw_events *cpuc, int cpu)
{
return 0;
}
-static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
+static inline void intel_cpuc_finish(struct cpu_hw_events *cpuc)
{
}
--
2.9.5
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
The additional hardware support would be helpful in the 4.4 long term tree.
e1000e: Initial support for KabeLake
i219 (4) and i219 (5) are the next LOM generations that will be
available on the next Intel platform (KabeLake).
This patch provides the initial support for the devices.
Signed-off-by: Raanan Avargil <raanan.avargil(a)intel.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
--
Pat Riehecky
Fermi National Accelerator Laboratory
www.fnal.govwww.scientificlinux.org
Hi,
On Tue, Mar 05, 2019 at 10:23:15PM +0100, Peter Zijlstra (Intel) wrote:
> The cpuc data structure allocation is different between fake and real
> cpuc's; use the same code to init/free both.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
With allmodconfig-CONFIG_CPU_SUP_INTEL, this patch results in:
In file included from arch/x86/events/amd/core.c:8:0:
arch/x86/events/amd/../perf_event.h:1036:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
^~~~~~~~~~~~
arch/x86/events/amd/../perf_event.h:1041:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
^~~~~~~~~~~~
With -Werror, this is fatal, and I think it may be buggy (should it be
cpu_hw_events) ?
The patch has been applied to stable releases. Any idea, anyone, why
this is the case ? It doesn't look like a bug fix to me, and reverting
it from v4.14.106 didn't seem to have a negative impact.
Guenter
Ext4 needs to serialize unaligned direct AIO because the zeroing of
partial blocks of two competing unaligned AIOs can result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still into the same block, it has
the potential of corrupting the previous unaligned write to the same
block.
This is (very simplified) reproducer from Frank
// 41472 = (10 * 4096) + 512
// 37376 = 41472 - 4096
ftruncate(fd, 41472);
io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376);
io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472);
io_submit(io_ctx, 1, &iocbs[1]);
io_submit(io_ctx, 1, &iocbs[2]);
io_getevents(io_ctx, 2, 2, events, NULL);
Without this patch the 512B range from 40960 up to the start of the
second unaligned write (41472) is going to be zeroed overwriting the data
written by the first write. This is a data corruption.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
With this patch the data corruption is avoided because we will recognize
the unaligned_aio and wait for the unwritten extent conversion.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
*
0000b200
Reported-by: Frank Sorenson <fsorenso(a)redhat.com>
Signed-off-by: Lukas Czerner <lczerner(a)redhat.com>
Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO")
Cc: <stable(a)vger.kernel.org>
---
fs/ext4/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 69d65d49837b..98ec11f69cd4 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -125,7 +125,7 @@ ext4_unaligned_aio(struct inode *inode, struct iov_iter *from, loff_t pos)
struct super_block *sb = inode->i_sb;
int blockmask = sb->s_blocksize - 1;
- if (pos >= i_size_read(inode))
+ if (pos >= ALIGN(i_size_read(inode), sb->s_blocksize))
return 0;
if ((pos | iov_iter_alignment(from)) & blockmask)
--
2.20.1
On Thu, Mar 14, 2019 at 07:59:00PM +0000, Alan J. Wylie wrote:
> Greg KH <gregkh(a)linuxfoundation.org> writes:
>
> > I'm announcing the release of the 5.0.2 kernel.
>
> There is a regression for AMD-only builds.
Adding the stable list, which people should do...
>
> See also Alec Ari's report:
> https://lkml.org/lkml/2019/3/13/1113
>
> > If CONFIG_CPU_SUP_INTEL is disabled with either the 5.0.2 or 4.20.16
> > kernel, it errors out right away:
>
> $ grep "CONFIG_CPU_SUP_" .config
> # CONFIG_CPU_SUP_INTEL is not set
> CONFIG_CPU_SUP_AMD=y
> # CONFIG_CPU_SUP_HYGON is not set
> # CONFIG_CPU_SUP_CENTAUR is not set
>
> CC arch/x86/events/core.o
> In file included from arch/x86/events/core.c:44:
> arch/x86/events/perf_event.h:1035:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
> static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
> ^~~~~~~~~~~~
> arch/x86/events/perf_event.h:1040:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
> static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
> ^~~~~~~~~~~~
> arch/x86/events/core.c: In function ‘free_fake_cpuc’:
> arch/x86/events/core.c:1998:20: error: passing argument 1 of ‘intel_cpuc_finish’ from incompatible pointer type [-Werror=incompatible-pointer-types]
> intel_cpuc_finish(cpuc);
> ^~~~
> In file included from arch/x86/events/core.c:44:
> arch/x86/events/perf_event.h:1040:59: note: expected ‘struct cpu_hw_event *’ but argument is of type ‘struct cpu_hw_events *’
> static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
> ~~~~~~~~~~~~~~~~~~~~~^~~~
> arch/x86/events/core.c: In function ‘allocate_fake_cpuc’:
> arch/x86/events/core.c:2012:25: error: passing argument 1 of ‘intel_cpuc_prepare’ from incompatible pointer type [-Werror=incompatible-pointer-types]
> if (intel_cpuc_prepare(cpuc, cpu))
> ^~~~
> In file included from arch/x86/events/core.c:44:
> arch/x86/events/perf_event.h:1035:59: note: expected ‘struct cpu_hw_event *’ but argument is of type ‘struct cpu_hw_events *’
> static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
> ~~~~~~~~~~~~~~~~~~~~~^~~~
> cc1: some warnings being treated as errors
Is this a regression? If so, what commit caused this? Is this also an
issue in Linus's tree right now?
thanks,
greg k-h
Hello!
While trying to add Perf tests to LKFT [1], we encountered some
problems building it for two specific combinations:
* 4.4 and x86-64
* 4.14 and x86-32
On 4.4, this is what the build failure looks like:
| bench/mem-memcpy-x86-64-asm.S:4:10: fatal error:
../../../arch/x86/lib/memcpy_64.S: No such file or directory
| #include "../../../arch/x86/lib/memcpy_64.S"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This was fixed in mainline by commit 7d7d1bf1d1da ("perf bench: Copy
kernel files needed to build mem{cpy,set} x86_64 benchmarks"). Instead
of just cherry-picking, it requires a proper backport as it needs to
copy the existing files in 4.4, not the ones contained in that commit
(which are from v4.7-rc5+).
On 4.14, this is what the build failure looks like:
| In file included from util/libunwind/x86_32.c:33:0:
| util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function
'libunwind__x86_reg_id':
| util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: error:
'EINVAL' undeclared (first use in this function); did you mean
'UNW_EINVAL'?
| return -EINVAL;
| ^~~~~~
| UNW_EINVAL
This was fixed by 44df1afdb174 ("perf tools: Fix compile error with
libunwind x86"); it applies cleanly on top of v4.14.106.
Thanks and greetings!
Daniel Díaz
daniel.diaz(a)linaro.org
[1] https://lkft.linaro.org/about/