The reference to '__vermagic' is a relict from v2.5 times. And even
there it had a very short life time, from v2.5.59 (commit 1d411b80ee18
("Module Sanity Check") in the historic tree) to v2.5.69 (commit
67ac5b866bda ("[PATCH] complete modinfo section")).
Neither current kernels nor modules contain a '__vermagic' section any
more, so get rid of it.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: Jessica Yu <[email protected]>
Signed-off-by: Jessica Yu <[email protected]>
As mentioned in the info pages of gas, the '.align' pseudo op's
interpretation of the alignment value is architecture specific.
It might either be a byte value or taken to the power of two.
On ARM it's actually the latter which leads to unnecessary large
alignments of 16 bytes for 32 bit builds or 256 bytes for 64 bit
builds.
Fix this by switching to '.balign' instead which is consistent
across all architectures.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Commit 565f0fa902 ("xfrm: use a dedicated slab cache for struct
xfrm_state") moved xfrm state objects to use their own slab cache.
However, it missed to adapt xfrm_user to use this new cache when
freeing xfrm states.
Fix this by introducing and make use of a new helper for freeing
xfrm_state objects.
Fixes: 565f0fa902 ("xfrm: use a dedicated slab cache for struct xfrm_state")
Reported-by: Pan Bian <[email protected]>
Cc: <[email protected]> # v4.18+
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Herbert Xu <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
struct xfrm_state is rather large (768 bytes here) and therefore wastes
quite a lot of memory as it falls into the kmalloc-1024 slab cache,
leaving 256 bytes of unused memory per XFRM state object -- a net waste
of 25%.
Using a dedicated slab cache for struct xfrm_state reduces the level of
internal fragmentation to a minimum.
On my configuration SLUB chooses to create a slab cache covering 4
pages holding 21 objects, resulting in an average memory waste of ~13
bytes per object -- a net waste of only 1.6%.
In my tests this led to memory savings of roughly 2.3MB for 10k XFRM
states.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
The alt_max_short() macro in asm/alternative.h does not work as
intended, leading to nasty bugs. E.g. alt_max_short("1", "3")
evaluates to 3, but alt_max_short("3", "1") evaluates to 1 -- not
exactly the maximum of 1 and 3.
In fact, I had to learn it the hard way by crashing my kernel in not
so funny ways by attempting to make use of the ALTENATIVE_2 macro
with alternatives where the first one was larger than the second
one.
According to [1] and commit dbe4058a6a ("x86/alternatives: Fix
ALTERNATIVE_2 padding generation properly") the right handed side
should read "-(-(a < b))" not "-(-(a - b))". Fix that, to make the
macro work as intended.
While at it, fix up the comments regarding the additional "-", too.
It's not about gas' usage of s32 but brain dead logic of having a
"true" value of -1 for the < operator ... *sigh*
Btw., the one in asm/alternative-asm.h is correct. And, apparently,
all current users of ALTERNATIVE_2() pass same sized alternatives,
avoiding to hit the bug.
[1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
Reviewed-and-tested-by: Borislav Petkov <[email protected]>
Fixes: dbe4058a6a ("x86/alternatives: Fix ALTERNATIVE_2 padding generation properly")
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
If the algorithm we're parallelizing is asynchronous we might change
CPUs between padata_do_parallel() and padata_do_serial(). However, we
don't expect this to happen as we need to enqueue the padata object into
the per-cpu reorder queue we took it from, i.e. the same-cpu's parallel
queue.
Ensure we're not switching CPUs for a given padata object by tracking
the CPU within the padata object. If the serial callback gets called on
the wrong CPU, defer invoking padata_reorder() via a kernel worker on
the CPU we're expected to run on.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The reorder timer function runs on the CPU where the timer interrupt was
handled which is not necessarily one of the CPUs of the 'pcpu' CPU mask
set.
Ensure the padata_reorder() callback runs on the correct CPU, which is
one in the 'pcpu' CPU mask set and, preferrably, the next expected one.
Do so by comparing the current CPU with the expected target CPU. If they
match, call padata_reorder() right away. If they differ, schedule a work
item on the target CPU that does the padata_reorder() call for us.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The parallel queue per-cpu data structure gets initialized only for CPUs
in the 'pcpu' CPU mask set. This is not sufficient as the reorder timer
may run on a different CPU and might wrongly decide it's the target CPU
for the next reorder item as per-cpu memory gets memset(0) and we might
be waiting for the first CPU in cpumask.pcpu, i.e. cpu_index 0.
Make the '__this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index'
compare in padata_get_next() fail in this case by initializing the
cpu_index member of all per-cpu parallel queues. Use -1 for unused ones.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The memory reserved to dump the ID of the xfrm state includes a padding
byte in struct xfrm_usersa_id added by the compiler for alignment. To
prevent the heap info leak, memset(0) the sa_id before filling it.
Cc: Jamal Hadi Salim <[email protected]>
Fixes: d51d081d65 ("[IPSEC]: Sync series - user")
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
The memory reserved to dump the expired xfrm state includes padding
bytes in struct xfrm_user_expire added by the compiler for alignment. To
prevent the heap info leak, memset(0) the remainder of the struct.
Initializing the whole structure isn't needed as copy_to_user_state()
already takes care of clearing the padding bytes within the 'state'
member.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
The memory reserved to dump the ID of the xfrm state includes a padding
byte in struct xfrm_usersa_id added by the compiler for alignment. To
prevent the heap info leak, memset(0) the whole struct before filling
it.
Cc: Herbert Xu <[email protected]>
Fixes: 0603eac0d6 ("[IPSEC]: Add XFRMA_SA/XFRMA_POLICY for delete notification")
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
The memory reserved to dump the xfrm offload state includes padding
bytes of struct xfrm_user_offload added by the compiler for alignment.
Add an explicit memset(0) before filling the buffer to avoid the heap
info leak.
Cc: Steffen Klassert <[email protected]>
Fixes: d77e38e612 ("xfrm: Add an IPsec hardware offloading API")
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
vdso_enabled can be set to arbitrary integer values via the kernel command
line 'vdso32=' parameter or via 'sysctl abi.vsyscall32'.
load_vdso32() only maps VDSO if vdso_enabled == 1, but ARCH_DLINFO_IA32
merily checks for vdso_enabled != 0. As a consequence the AT_SYSINFO_EHDR
auxiliary vector for the VDSO_ENTRY is emitted with a NULL pointer which
causes a segfault when the application tries to use the VDSO.
Restrict the valid arguments on the command line and the sysctl to 0 and 1.
Fixes: b0b49f2673 ("x86, vdso: Remove compat vdso support")
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Andy Lutomirski <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: [email protected]
Cc: Roland McGrath <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
It's unused for ages, used to be required for ksyms.c back in the v1.1
times.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: David S. Miller <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Remove the wp_works_ok member of struct cpuinfo_x86. It's an
optimization back from Linux v0.99 times where we had no fixup support
yet and did the CR0.WP test via special code in the page fault handler.
The < 0 test was an optimization to not do the special casing for each
NULL ptr access violation but just for the first one doing the WP test.
Today it serves no real purpose as the test no longer needs special code
in the page fault handler and the only call side -- mem_init() -- calls
it just once, anyway. However, Xen pre-initializes it to 1, to skip the
test.
Doing the test again for Xen should be no issue at all, as even the
commit introducing skipping the test (commit d560bc6157 ("x86, xen:
Suppress WP test on Xen")) mentioned it being ban aid only. And, in
fact, testing the patch on Xen showed nothing breaks.
The pre-fixup times are long gone and with the removal of the fallback
handling code in commit a5c2a893db ("x86, 386 removal: Remove
CONFIG_X86_WP_WORKS_OK") the kernel requires a working CR0.WP anyway.
So just get rid of the "optimization" and do the test unconditionally.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Cc: Jesper Nilsson <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
Cc: Arnd Hannemann <[email protected]>
Cc: Mikael Starvik <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: "David S. Miller" <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
The macro TEST_VERIFY_AREA can never be defined as there's no
wp_works_ok variable. So just remove the dead code.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
We miss to check if the netlink message is actually big enough to contain
a struct if_stats_msg.
Add a check to prevent userland from sending us short messages that would
make us access memory beyond the end of the message.
Fixes: 10c9ead9f3 ("rtnetlink: add new RTM_GETSTATS message to dump...")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Roopa Prabhu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
To avoid having dangling function pointers left behind, reset calcit in
rtnl_unregister(), too.
This is no issue so far, as only the rtnl core registers a netlink
handler with a calcit hook which won't be unregistered, but may become
one if new code makes use of the calcit hook.
Fixes: c7ac8679be ("rtnetlink: Compute and store minimum ifinfo...")
Cc: Jeff Kirsher <[email protected]>
Cc: Greg Rose <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
When we fail to attach the security context in xfrm_state_construct()
we'll return 0 as error value which, in turn, will wrongly claim success
to userland when, in fact, we won't be adding / updating the XFRM state.
This is a regression introduced by commit fd21150a0f ("[XFRM] netlink:
Inline attach_encap_tmpl(), attach_sec_ctx(), and attach_one_addr()").
Fix it by propagating the error returned by security_xfrm_state_alloc()
in this case.
Fixes: fd21150a0f ("[XFRM] netlink: Inline attach_encap_tmpl()...")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Thomas Graf <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Commit 9aa867e465 ("crypto: user - Add CRYPTO_MSG_DELRNG")
accidentally removed the minimum size check for CRYPTO_MSG_GETALG
netlink messages. This allows userland to send a truncated
CRYPTO_MSG_GETALG message as short as a netlink header only making
crypto_report() operate on uninitialized memory by accessing data
beyond the end of the netlink message.
Fix this be re-adding the minimum required size of CRYPTO_MSG_GETALG
messages to the crypto_msg_min[] array.
Fixes: 9aa867e465 ("crypto: user - Add CRYPTO_MSG_DELRNG")
Cc: [email protected] # v4.2
Signed-off-by: Mathias Krause <[email protected]>
Cc: Steffen Klassert <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
There is only a single user of dma_buf_debugfs_create_file() and that
one got the function pointer cast wrong. With that one fixed, there is
no need to have a wrapper for debugfs_create_file(), just call it
directly.
With no users left, we can remove dma_buf_debugfs_create_file().
While at it, simplify the error handling in dma_buf_init_debugfs()
slightly.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Sumit Semwal <[email protected]>
Cc: Daniel Vetter <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Sumit Semwal <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Change the error handling in dma_buf_init_debugfs() to remove the
"dma_buf" directory if creating the "bufinfo" file fails. No need to
have an empty debugfs directory around.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Sumit Semwal <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Sumit Semwal <[email protected]>
The callback function dma_buf_describe() returns an int not void so the
function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can
also fail when acquiring the mutex gets interrupted so always returning
0 in dma_buf_show() is wrong, too.
Fix both issues by avoiding the indirection via dma_buf_show() and call
dma_buf_describe() directly. Rename it to dma_buf_debug_show() to get it
in line with the other functions.
This type mismatch was caught by the PaX RAP plugin.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Sumit Semwal <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: PaX Team <[email protected]>
Signed-off-by: Sumit Semwal <[email protected]>
The GFP_DMA flag is obviously misunderstood in the mwifiex driver. It's
meant for legacy ISA DMA memory mappings only -- the lower 16MB on x86.
That doesn't apply to PCIe or SDIO devices, I guess.
Remove the GFP_DMA flag to reduce the need to place the socket buffer
allocation into the low mem DMA area, which might already be in use by
other drivers.
This misuse was flagged by the PaX USERCOPY feature by chance, as it
detected the user copy operation from a DMA buffer in the recvfrom()
syscall path.
Signed-off-by: Mathias Krause <[email protected]>
Tested-by: Dennis Wassenberg <[email protected]>
Cc: Amitkumar Karwar <[email protected]>
Cc: Nishant Sarmukadam <[email protected]>
Cc: Xinming Hu <[email protected]>
Cc: Kalle Valo <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: PaX Team <[email protected]>
Acked-by: Amitkumar Karwar <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
The x86 exception table sorting was changed in commit 29934b0fb8
("x86/extable: use generic search and sort routines") to use the arch
independent code in lib/extable.c. However, the patch was mangled
somehow on its way into the kernel from the last version posted at [1].
The committed version kind of attempted to incorporate the changes of
commit 548acf1923 ("x86/mm: Expand the exception table logic to allow
new handling options") as in _completely_ _ignoring_ the x86 specific
'handler' member of struct exception_table_entry. This effectively
broke the sorting as entries will only partly be swapped now.
Fortunately, the x86 Kconfig selects BUILDTIME_EXTABLE_SORT, so the
exception table doesn't need to be sorted at runtime. However, in case
that ever changes, we better not break the exception table sorting just
because of that.
[ Ard Biesheuvel points out that BUILDTIME_EXTABLE_SORT applies to the
core image only, but we still rely on the sorting routines for modules
in that case - Linus ]
Fix this by providing a swap_ex_entry_fixup() macro that takes care of
the 'handler' member.
[1] https://lkml.org/lkml/2016/1/27/232
Signed-off-by: Mathias Krause <[email protected]>
Fixes: 29934b0fb8 ("x86/extable: use generic search and sort routines")
Reviewed-by: Ard Biesheuvel <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Tony Luck <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The x86 exception table sorting was changed in this recent commit:
29934b0fb8 ("x86/extable: use generic search and sort routines")
... to use the arch independent code in lib/extable.c. However, the
patch was mangled somehow on its way into the kernel from the last
version posted at:
https://lkml.org/lkml/2016/1/27/232
The committed version kind of attempted to incorporate the changes of
contemporary commit done in the x86 tree:
548acf1923 ("x86/mm: Expand the exception table logic to allow new handling options")
... as in _completely_ _ignoring_ the x86 specific 'handler' member of
struct exception_table_entry. This effectively broke the sorting as
entries will only be partly swapped now.
Fortunately, the x86 Kconfig selects BUILDTIME_EXTABLE_SORT, so the
exception table doesn't need to be sorted at runtime. However, in case
that ever changes, we better not break the exception table sorting just
because of that.
Fix this by providing a swap_ex_entry_fixup() macro that takes care of
the 'handler' member.
Signed-off-by: Mathias Krause <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Tony Luck <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
If /proc/<PID>/environ gets read before the envp[] array is fully set up
in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
read more bytes than are actually written, as env_start will already be
set but env_end will still be zero, making the range calculation
underflow, allowing to read beyond the end of what has been written.
Fix this as it is done for /proc/<PID>/cmdline by testing env_end for
zero. It is, apparently, intentionally set last in create_*_tables().
This bug was found by the PaX size_overflow plugin that detected the
arithmetic underflow of 'this_len = env_end - (env_start + src)' when
env_end is still zero.
The expected consequence is that userland trying to access
/proc/<PID>/environ of a not yet fully set up process may get
inconsistent data as we're in the middle of copying in the environment
variables.
Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461
Signed-off-by: Mathias Krause <[email protected]>
Cc: Emese Revfy <[email protected]>
Cc: Pax Team <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Mateusz Guzik <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: Cyrill Gorcunov <[email protected]>
Cc: Jarod Wilson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Because we miss to wipe the remainder of i->addr[] in packet_mc_add(),
pdiag_put_mclist() leaks uninitialized heap bytes via the
PACKET_DIAG_MCLIST netlink attribute.
Fix this by explicitly memset(0)ing the remaining bytes in i->addr[].
Fixes: eea68e2f1a ("packet: Report socket mclist info via diag module")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Pavel Emelyanov <[email protected]>
Acked-by: Pavel Emelyanov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Instead of re-creating the array on the stack each time
is_cmos_rtc_device() gets called, make the array 'static const'.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Commit 1266963170 ("PCI: Prevent out of bounds access in numa_node
override") missed that the user-provided node could also be negative.
Handle this case as well to avoid out-of-bounds accesses to the
node_states[] array. However, allow the special value -1, i.e.
NUMA_NO_NODE, to be able to set the 'no specific node' configuration.
Fixes: 1266963170 ("PCI: Prevent out of bounds access in numa_node override")
Fixes: 63692df103 ("PCI: Allow numa_node override via sysfs")
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Sasha Levin <[email protected]>
CC: Prarit Bhargava <[email protected]>
CC: [email protected] # v3.19+
The following statement of ABI/testing/dev-kmsg is not quite right:
It is not possible to inject messages from userspace with the
facility number LOG_KERN (0), to make sure that the origin of the
messages can always be reliably determined.
Userland actually can inject messages with a facility of 0 by abusing the
fact that the facility is stored in a u8 data type. By using a facility
which is a multiple of 256 the assignment of msg->facility in log_store()
implicitly truncates it to 0, i.e. LOG_KERN, allowing users of /dev/kmsg
to spoof kernel messages as shown below:
The following call...
# printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg
...leads to the following log entry (dmesg -x | tail -n 1):
user :emerg : [ 66.137758] Kernel panic - not syncing: beer empty
However, this call...
# printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg
...leads to the slightly different log entry (note the kernel facility):
kern :emerg : [ 74.177343] Kernel panic - not syncing: beer empty
Fix that by limiting the user provided facility to 8 bit right from the
beginning and catch the truncation early.
Fixes: 7ff9554bb5 ("printk: convert byte-buffer to variable-length...")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Alex Elder <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Kay Sievers <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
cpu_chain lost its __cpuinitdata annotation long ago in commit
5c113fbeed ("fix cpu_chain section mismatch..."). This and the global
__cpuinit annotation drop in v3.11 vanished the need to mark all users,
including transitive ones, with the __ref annotation. Just get rid of it
to not wrongly hide section mismatches.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
In commit 0db0628d90 ("kernel: delete __cpuinit usage from all core
kernel files") cpu_up() lost its __cpuinit annotation, vanishing the
need for cpu_subsys_online() to have a __ref annotation. Just drop it
to be able to catch real section mismatches in the future.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The sk_classid member is only required when CONFIG_CGROUP_NET_CLASSID is
enabled. #ifdefify it to reduce the size of struct sock on 32 bit
systems, at least.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The processor_handler structure does not reference any __init / __exit
code or data. Therefore the __refdata annotation is not needed. It used
to be prior to commit fe7bf106eb ("acpi: delete __cpuinit usage from
all acpi files") due to the __cpuinit annotation of acpi_processor_add().
But with that commit in place that requirement has gone.
The same is true for the acpi_cpu_notifier notifier block.
acpi_cpu_soft_notify() used to be marked __cpuinit but lost its
annotation in the above mentioned commit as well. Therefore the __refdata
annotation isn't needed there either.
Just drop the unneded __refdata annotations to be able to catch future
section mismatches.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The __ref / __refdata annotations used to be needed because of
referencing functions / variables annotated __cpuinit /
__cpuinitdata.
But those annotations vanished during the development of v3.11.
Therefore most of the __ref / __refdata annotations are not needed
anymore. As they may hide legitimate sections mismatches, we
better get rid of them.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
ACPI device ID arrays normally don't need to be written to as they're
only ever read. The common usage -- embedding pointers to acpi_device_id
arrays in other data structures -- reference them as 'const', e.g. as in
struct acpi_driver / acpi_scan_handler / device_driver. The matchers are
taking const pointers, too. So it's only natural, to propose using const
arrays. Change the documentation accordingly.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Make the button ACPI device ID array static const. Safes us a little bit
of code.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
There is no need to have processor_power_dmi_table[] writeable, constify
it.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Constify the acpi_hed_ids[] ACPI device IDs array -- no need to have it
writeable.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The device descriptors are never written to -- even pointed to as
'const' from struct lpss_private_data. Make them r/o for real.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The bat_dmi_table[] DMI table is referenced from the __init function
acpi_battery_init_async() only. It and its referenced functions can
therefore be marked __initconst to free up ~1kB of runtime memory after
initialization is done.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Make the acpi_battery_units() function take a const argument and return
a const char*, too. Also make it static. It probably doesn't matter, as
gcc will be clever enough to optimize and inline the code even without
these hints. However, we also get rid of a #ifdef block by moving the
function closer to its usage location, so it's at least a small gain in
code readability.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The offset tables are only read, not modified. Make them const.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
There is no need to have ac_dmi_table[] writeable, constify it.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Make the video ACPI device ID array static and constify the DMI system
IDs array. Saves us a little bit of code.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Constify the ACPI device ID array and the register map, no need to have
them writable at runtime. Also drop the unneeded RT5670_INIT_REG_LEN
define.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Constify the ACPI device ID array and the register map, no need to have
them writable at runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Constify the ACPI device ID array and the register map, no need to have
them writable at runtime. Also drop the unneeded RT5640_INIT_REG_LEN
define.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Mark the module init / exit functions with __init / __exit accodingly.
This allows making the intel_powerclamp_ids[] array __initconst, too, as
it only gets referenced from powerclamp_probe(). This is safe as
file2alias doesn't care about the section, but the symbol name for the
MODULE_DEVICE_TABLE alias.
Cc: Arjan van de Ven <[email protected]>
Cc: Jacob Pan <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Jacob Pan <[email protected]>
Acked-by: Jacob Pan <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
The CPU ids are only tested in intel_idle_probe() which is itself an
__init function. For the MODULE_DEVICE_TABLE() file2alias doesn't care
about the section, just about the symbol name. So it's safe to mark
the cpu id array as __initconst so its memory can be released after
initialization is done.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The RAPL ids are only tested in rapl_init() which is itself an __init
function. For the MODULE_DEVICE_TABLE() file2alias doesn't care about
the section, just about the symbol name. Therefore it's safe to mark the
rapl_ids[] array as __initconst so its memory can be released after
initialization is done.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Jacob Pan <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
This module implements variations of "des3_ede" only. Drop the bogus
module aliases for "des".
Cc: Jussi Kivilinna <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
This module provides implementations for "des3_ede", too. Announce those
via an appropriate crypto module alias so it can be used in favour to
the generic C implementation.
Cc: David S. Miller <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: David S. Miller <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Commit 5d26a105b5 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.
Even though commit 5d26a105b5 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.
Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.
Fixes: 5d26a105b5 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
We can mark the DMI system id table as __initconst by using a helper
variable that'll tell us if we need to unregister the reboot notifier in
atyfb_exit() instead of matching the DMI system id again.
This frees up ~680 bytes of runtime memory, the DMI table occupies.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
The "by8" counter mode optimization is broken for 128 bit keys with
input data longer than 128 bytes. It uses the wrong key material for
en- and decryption.
The key registers xkey0, xkey4, xkey8 and xkey12 need to be preserved
in case we're handling more than 128 bytes of input data -- they won't
get reloaded after the initial load. They must therefore be (a) loaded
on the first iteration and (b) be preserved for the latter ones. The
implementation for 128 bit keys does not comply with (a) nor (b).
Fix this by bringing the implementation back to its original source
and correctly load the key registers and preserve their values by
*not* re-using the registers for other purposes.
Kudos to James for reporting the issue and providing a test case
showing the discrepancies.
Reported-by: James Yonan <[email protected]>
Cc: Chandramouli Narayanan <[email protected]>
Cc: <[email protected]> # v3.18
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
pptp_getname() only partially initializes the stack variable sa,
particularly only fills the pptp part of the sa_addr union. The code
thereby discloses 16 bytes of kernel stack memory via getsockname().
Fix this by memset(0)'ing the union before.
Cc: Dmitry Kozlov <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
In commit 3891a04aaf ("x86-64, espfix: Don't leak bits 31:16 of %esp
returning..") the "ESPFix Area" was added to the page table dump special
sections. That area, though, has a limited amount of entries printed.
The EFI runtime services are, unfortunately, located in-between the
espfix area and the high kernel memory mapping. Due to the enforced
limitation for the espfix area, the EFI mappings won't be printed in the
page table dump.
To make the ESP runtime service mappings visible again, provide them a
dedicated entry.
Signed-off-by: Mathias Krause <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
There is no need to keep the module loaded when it serves no function in
case the EFI runtime services are disabled. Return an error in this case
so loading the module will fail.
Also supply a module_exit function to allow unloading the module.
Last, but not least, set the owner of the file_system_type struct.
Cc: Jeremy Kerr <[email protected]>
Cc: Matthew Garrett <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
If userland creates a timer without specifying a sigevent info, we'll
create one ourself, using a stack local variable. Particularly will we
use the timer ID as sival_int. But as sigev_value is a union containing
a pointer and an int, that assignment will only partially initialize
sigev_value on systems where the size of a pointer is bigger than the
size of an int. On such systems we'll copy the uninitialized stack bytes
from the timer_create() call to userland when the timer actually fires
and we're going to deliver the signal.
Initialize sigev_value with 0 to plug the stack info leak.
Found in the PaX patch, written by the PaX Team.
Fixes: 5a9fa73072 ("posix-timers: kill ->it_sigev_signo and...")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Brad Spengler <[email protected]>
Cc: PaX Team <[email protected]>
Cc: <[email protected]> # v2.6.28+
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
The 32 bit and 64 bit implementations differ in their __init annotations
for some functions referenced from the common EFI code. Namely, the 32
bit variant is missing some of the __init annotations the 64 bit variant
has.
To solve the colliding annotations, mark the corresponding functions in
efi_32.c as initialization code, too -- as it is such.
Actually, quite a few more functions are only used during initialization
and therefore can be marked __init. They are therefore annotated, too.
Also add the __init annotation to the prototypes in the efi.h header so
users of those functions will see it's meant as initialization code
only.
This patch also fixes the "prelog" typo. ("prologue" / "epilogue" might
be more appropriate but this is C code after all, not an opera! :D)
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
Commit 3f4a7836e3 ("x86/efi: Rip out phys_efi_get_time()") left
set_virtual_address_map as the only runtime service needed with a
phys mapping but missed to update the preceding comment. Fix that.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
This variable was accidentally exported, even though it's only used in
this compilation unit and only during initialization.
Remove the bogus export, make the variable static instead and mark it
as __initdata.
Fixes: 200001eb14 ("x86 boot: only pick up additional EFI memmap...")
Cc: Paul Jackson <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
Complement commit 62fa6e69a4 ("x86/efi: Delete most of the efi_call*
macros") and delete the stub macros for the !CONFIG_EFI case, too. In
fact, there are no EFI calls in this case so we don't need a dummy for
efi_call() even.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
The defines for xkey3, xkey6 and xkey9 are not used in the code. They're
probably left overs from merging the three source files for 128, 192 and
256 bit AES. They can safely be removed.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The "by8" CTR AVX implementation fails to propperly handle counter
overflows. That was the reason it got disabled in commit 7da4b29d49
("crypto: aesni - disable "by8" AVX CTR optimization").
Fix the overflow handling by incrementing the counter block as a double
quad word, i.e. a 128 bit, and testing for overflows afterwards. We need
to use VPTEST to do so as VPADD* does not set the flags itself and
silently drops the carry bit.
As this change adds branches to the hot path, minor performance
regressions might be a side effect. But, OTOH, we now have a conforming
implementation -- the preferable goal.
A tcrypt test on a SandyBridge system (i7-2620M) showed almost identical
numbers for the old and this version with differences within the noise
range. A dm-crypt test with the fixed version gave even slightly better
results for this version. So the performance impact might not be as big
as expected.
Tested-by: Romain Francoise <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The "by8" implementation introduced in commit 22cddcc7df ("crypto: aes
- AES CTR x86_64 "by8" AVX optimization") is failing crypto tests as it
handles counter block overflows differently. It only accounts the right
most 32 bit as a counter -- not the whole block as all other
implementations do. This makes it fail the cryptomgr test #4 that
specifically tests this corner case.
As we're quite late in the release cycle, just disable the "by8" variant
for now.
Reported-by: Romain Francoise <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Cc: Chandramouli Narayanan <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
The pci_find_bios() function is only ever called from initialization code,
therefore can be marked as such, too. This, in turn, allows marking other
functions called only in this context as well.
The bios32_indirect variable can be marked as __initdata as it is only
referenced from __init functions now.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
The constants in pci_mmcfg_nvidia_mcp55() need to be marked as __initconst
or they will remain in memory after init memory was released.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
According to include/linux/init.h, the __init annotation should be added
immediately before the function name. However, for quite a few functions
in mmconfig-shared.c this is not the case. It's either before the return
type or even in the middle of it. Beside gcc still getting it right, we
should change them to comply to the rules of include/linux/init.h.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
The DMI tables are only used in __init code, thereby can be marked as
initialization data, too. The same is true for the callback functions
referenced from the DMI tables.
This moves ~9.6 kB of code and r/o data to the init sections, marking the
memory for release after initialization.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
This is a follow-up patch to commit 49458e8308 ("ideapad-laptop:
Constify DMI table and other r/o variables") to do what its commit
message says. The actual commit differs from the patch posted at
https://www.mail-archive.com/[email protected]/msg05340.html
significantly, probably due to a bad merge conflict resolution. Fix up
the mess and constify the DMI table for real and fix the bogus
double-const of ideapad_rfk_data[].
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Mathias Krause <[email protected]>
Cc: Matthew Garrett <[email protected]>
Cc: Ike Panhc <[email protected]>
Signed-off-by: Darren Hart <[email protected]>
The DMI table does not need to be written to, make it r/o.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
The __init annotations for the DMI callback functions are wrong as this
code can be called even after the module has been initialized, e.g. like
this:
# echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove
# modprobe i915
# echo 1 > /sys/bus/pci/rescan
The first command will remove the PCI device from the kernel's device
list so the second command won't see it right away. But as it registers
a PCI driver it'll see it on the third command. If the system happens to
match one of the DMI table entries we'll try to call a function in long
released memory and generate an Oops, at best.
Fix this by removing the bogus annotation.
Modpost should have caught that one but it ignores section reference
mismatches from the .rodata section. :/
Fixes: 25e341cfc3 ("drm/i915: quirk away broken OpRegion VBT")
Fixes: 8ca4013d70 ("CHROMIUM: i915: Add DMI override to skip CRT...")
Fixes: 425d244c86 ("drm/i915: ignore LVDS on intel graphics systems...")
Signed-off-by: Mathias Krause <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Duncan Laurie <[email protected]>
Cc: Jarod Wilson <[email protected]>
Cc: Rusty Russell <[email protected]> # Can modpost be fixed?
Cc: [email protected]
Signed-off-by: Jani Nikula <[email protected]>
Avoid the variable length array (vla), just use PATH_MAX instead.
This not only makes this code clang friedly, it also leads to a
code size reduction:
text data bss dec hex filename
51765 2224 12416 66405 10365 scripts/mod/modpost.old
51677 2224 12416 66317 1030d scripts/mod/modpost.new
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Internally used symbols of modpost don't need to be externally visible;
make them static. Also constify the string arrays so they resist in the
r/o section instead of being runtime writable.
Those changes lead to a small size reduction as can be seen below:
text data bss dec hex filename
51381 2640 12416 66437 10385 scripts/mod/modpost.old
51765 2224 12416 66405 10365 scripts/mod/modpost.new
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Constify the rfkill_blacklist[] DMI table, the ideapad_rfk_data[] table
and the ideapad_attribute_group attribute group. There's no need to have
them writeable during runtime.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Ike Panhc <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
These variables don't need to be visible outside of this compilation
unit, make them static.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Mark volume_alsa_control_vol and volume_alsa_control_mute as __initdata,
as snd_ctl_new1() will copy the relevant parts, so there is no need to
keep the master copies around after initialization.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Henrique de Moraes Holschuh <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The DMI table is only ever used during initialization. Mark it as
__initconst so its memory can be released afterwards -- roughly 1.5 kB.
In turn, the callback functions can be marked with __init, too.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Jonathan Woithe <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
These functions are only called from other initialization routines, so
can be marked __init, too.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Constify the lis3lv02d_device_ids[] ACPI and the lis3lv02d_dmi_ids[] DMI
tables. There's no need to have them writeable during runtime.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Eric Piel <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The DMI table is already marked as __initconst, so can be the callback
functions as they're only used in that context.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Robert Gerlach <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
The dell_quirks[] DMI table is only ever used during initialization.
Mark it as __initconst so its memory can be released afterwards --
roughly 5.7 kB. In turn, the callback function can be marked with
__init, too.
Also the touchpad_led_init() function can be marked __init as it's only
referenced from dell_init() -- an __init function.
Signed-off-by: Mathias Krause <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Mathias Krause