On Intel CoffeeLake it's observed tsc is always marked unstable
unexpectedly after entering idle state Package C10(PC10), and then clock
source is switched to hpet. This patch marks tsc as reliable when CPUID
matches CoffeeLake.
The single caller passes a string to delta_ipc_open, which copies with a
fixed size larger than the string. So it copies some random data after
the original string the ro segment.
If the string was at the end of a page it may fault.
Just copy the string with a normal strcpy after clearing the field.
Found by a LTO build (which errors out)
because the compiler inlines the functions and can resolve
the string sizes and triggers the compile time checks in memcpy.
In function `memcpy',
inlined from `delta_ipc_open.constprop' at linux/drivers/media/platform/sti/delta/delta-ipc.c:178:0,
inlined from `delta_mjpeg_ipc_open' at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:227:0,
inlined from `delta_mjpeg_decode' at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:403:0:
/home/andi/lsrc/linux/include/linux/string.h:337:0: error: call to `__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
53ba373...
by
Dan Carpenter <email address hidden>
drivers/virt/fsl_hypervisor.c: prevent integer overflow in ioctl
The "param.count" value is a u64 thatcomes from the user. The code later
in the function assumes that param.count is at least one and if it's not
then it leads to an Oops when we dereference the ZERO_SIZE_PTR.
Also the addition can have an integer overflow which would lead us to
allocate a smaller "pages" array than required. I can't immediately tell
what the possible run times implications are, but it's safest to prevent
the overflow.
Link: http://lkml.kernel.org/r/20181218082129.GE32567@kadam
Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver")
Signed-off-by: Dan Carpenter <email address hidden>
Reviewed-by: Andrew Morton <email address hidden>
Cc: Timur Tabi <email address hidden>
Cc: Mihai Caraman <email address hidden>
Cc: Kumar Gala <email address hidden>
Cc: <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Stephen Rothwell <email address hidden>
0cca9b6...
by
Dan Carpenter <email address hidden>
drivers/virt/fsl_hypervisor.c: dereferencing error pointers in ioctl
strndup_user() returns error pointers on error, and then in the error
handling we pass the error pointers to kfree(). It will cause an Oops.
Link: http://lkml.kernel.org/r/20181218082003.GD32567@kadam
Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver")
Signed-off-by: Dan Carpenter <email address hidden>
Reviewed-by: Andrew Morton <email address hidden>
Cc: Timur Tabi <email address hidden>
Cc: Mihai Caraman <email address hidden>
Cc: Kumar Gala <email address hidden>
Cc: <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Stephen Rothwell <email address hidden>
memory.stat and other files already consider subtrees in their output, and
we should too in order to not present an inconsistent interface.
The current situation is fairly confusing, because people interacting with
cgroups expect hierarchical behaviour in the vein of memory.stat,
cgroup.events, and other files. For example, this causes confusion when
debugging reclaim events under low, as currently these always read "0" at
non-leaf memcg nodes, which frequently causes people to misdiagnose breach
behaviour. The same confusion applies to other counters in this file when
debugging issues.
Aggregation is done at write time instead of at read-time since these
counters aren't hot (unlike memory.stat which is per-page, so it does it
at read time), and it makes sense to bundle this with the file
notifications.
After this patch, events are propagated up the hierarchy:
[root@ktst ~]# cat /sys/fs/cgroup/system.slice/memory.events
low 0
high 0
max 0
oom 0
oom_kill 0
[root@ktst ~]# systemd-run -p MemoryMax=1 true
Running as unit: run-r251162a189fb4562b9dabfdc9b0422f5.service
[root@ktst ~]# cat /sys/fs/cgroup/system.slice/memory.events
low 0
high 0
max 7
oom 1
oom_kill 1
As this is a change in behaviour, this can be reverted to the old
behaviour by mounting with the `memory_localevents' flag set. However, we
use the new behaviour by default as there's a lack of evidence that there
are any current users of memory.events that would find this change
undesirable.
Link: http://<email address hidden>
Signed-off-by: Chris Down <email address hidden>
Acked-by: Johannes Weiner <email address hidden>
Cc: Michal Hocko <email address hidden>
Cc: Tejun Heo <email address hidden>
Cc: Roman Gushchin <email address hidden>
Cc: Dennis Zhou <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Stephen Rothwell <email address hidden>
mm, memcg: rename ambiguously named memory.stat counters and functions
I spent literally an hour trying to work out why an earlier version of my
memory.events aggregation code doesn't work properly, only to find out I
was calling memcg->events instead of memcg->memory_events, which is fairly
confusing.
This naming seems in need of reworking, so make it harder to do the wrong
thing by using vmevents instead of events, which makes it more clear that
these are vm counters rather than memcg-specific counters.
There are also a few other inconsistent names in both the percpu and
aggregated structs, so these are all cleaned up to be more coherent and
easy to understand.
This commit contains code cleanup only: there are no logic changes.
Link: http://<email address hidden>
Signed-off-by: Chris Down <email address hidden>
Acked-by: Johannes Weiner <email address hidden>
Cc: Michal Hocko <email address hidden>
Cc: Tejun Heo <email address hidden>
Cc: Roman Gushchin <email address hidden>
Cc: Dennis Zhou <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Stephen Rothwell <email address hidden>
d4504bd...
by
Masahiro Yamada <email address hidden>
