redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity
Fork of alistair23 Linux kernel for reMarkable from https://github.com/alistair23/linux
979,613 Commits
15 Branches
0 Tags
3.4 GiB
C 97.7%
Assembly 1.4%
Makefile 0.3%
Shell 0.2%
Python 0.1%
Other 0.1%
 
 
 
 
 
 
Go to file
Linus Torvalds d652d5f1ee drm/edid: fix objtool warning in drm_cvt_modes() 
Commit 991fcb77f4 ("drm/edid: Fix uninitialized variable in
drm_cvt_modes()") just replaced one warning with another.

The original warning about a possibly uninitialized variable was due to
the compiler not being smart enough to see that the case statement
actually enumerated all possible cases.  And the initial fix was just to
add a "default" case that had a single "unreachable()", just to tell the
compiler that that situation cannot happen.

However, that doesn't actually fix the fundamental reason for the
problem: the compiler still doesn't see that the existing case
statements enumerate all possibilities, so the compiler will still
generate code to jump to that unreachable case statement.  It just won't
complain about an uninitialized variable any more.

So now the compiler generates code to our inline asm marker that we told
it would not fall through, and end end result is basically random.  We
have created a bridge to nowhere.

And then, depending on the random details of just exactly what the
compiler ends up doing, 'objtool' might end up complaining about the
conditional branches (for conditions that cannot happen, and that thus
will never be taken - but if the compiler was not smart enough to figure
that out, we can't expect objtool to do so) going off in the weeds.

So depending on how the compiler has laid out the result, you might see
something like this:

    drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls through to next function drm_mode_detailed.isra.0()

and now you have a truly inscrutable warning that makes no sense at all
unless you start looking at whatever random code the compiler happened
to generate for our bare "unreachable()" statement.

IOW, don't use "unreachable()" unless you have an _active_ operation
that generates code that actually makes it obvious that something is not
reachable (ie an UD instruction or similar).

Solve the "compiler isn't smart enough" problem by just marking one of
the cases as "default", so that even when the compiler doesn't otherwise
see that we've enumerated all cases, the compiler will feel happy and
safe about there always being a valid case that initializes the 'width'
variable.

This also generates better code, since now the compiler doesn't generate
comparisons for five different possibilities (the four real ones and the
one that can't happen), but just for the three real ones and "the rest"
(which is that last one).

A smart enough compiler that sees that we cover all the cases won't care.

Cc: Lyude Paul <lyude@redhat.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 		2020-12-17 09:27:57 -08:00
Documentation ARM: SoC drivers for v5.11 2020-12-16 16:38:41 -08:00
LICENSES LICENSES: Add the CC-BY-4.0 license 2020-12-08 10:33:27 -07:00
arch ARM: SoC updates for OMAP GenPD 2020-12-16 16:53:54 -08:00
block SCSI misc on 20201216 2020-12-16 13:34:31 -08:00
certs .gitignore: add SPDX License Identifier 2020-03-25 11:50:48 +01:00
crypto crypto: aegis128 - avoid spurious references crypto_aegis128_update_simd 2020-12-04 18:16:53 +11:00
drivers drm/edid: fix objtool warning in drm_cvt_modes() 2020-12-17 09:27:57 -08:00
fs for-5.11/block-2020-12-14 2020-12-16 12:57:51 -08:00
include ARM: SoC updates for OMAP GenPD 2020-12-16 16:53:54 -08:00
init for-5.11/block-2020-12-14 2020-12-16 12:57:51 -08:00
ipc Merge branch 'akpm' (patches from Andrew) 2020-12-15 12:53:37 -08:00
kernel ARM: SoC drivers for v5.11 2020-12-16 16:38:41 -08:00
lib for-5.11/block-2020-12-14 2020-12-16 12:57:51 -08:00
mm memblock: debug enhancements 2020-12-16 14:44:53 -08:00
net RDMA 5.11 pull request 2020-12-16 13:42:26 -08:00
samples ARM: SoC drivers for v5.11 2020-12-16 16:38:41 -08:00
scripts gcc-plugins updates for v5.11-rc1 2020-12-16 11:17:27 -08:00
security Smack updates for Linux 5.11. One minor code clean-up and a 2020-12-16 11:11:58 -08:00
sound ACPI updates for 5.11-rc1 2020-12-15 16:39:06 -08:00
tools RDMA 5.11 pull request 2020-12-16 13:42:26 -08:00
usr Merge branch 'work.fdpic' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs 2020-08-07 13:29:39 -07:00
virt kvm: x86/mmu: Support dirty logging for the TDP MMU 2020-10-23 03:42:13 -04:00
.clang-format RDMA 5.10 pull request 2020-10-17 11:18:18 -07:00
.cocciconfig
…
.get_maintainer.ignore Opt out of scripts/get_maintainer.pl 2019-05-16 10:53:40 -07:00
.gitattributes .gitattributes: use 'dts' diff driver for dts files 2019-12-04 19:44:11 -08:00
.gitignore .gitignore: docs: ignore sphinx_*/ directories 2020-09-10 10:44:31 -06:00
.mailmap RDMA 5.11 pull request 2020-12-16 13:42:26 -08:00
COPYING COPYING: state that all contributions really are covered by this file 2020-02-10 13:32:20 -08:00
CREDITS Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net 2020-12-11 22:29:38 -08:00
Kbuild kbuild: rename hostprogs-y/always to hostprogs/always-y 2020-02-04 01:53:07 +09:00
Kconfig kbuild: ensure full rebuild when the compiler is updated 2020-05-12 13:28:33 +09:00
MAINTAINERS ARM: SoC drivers for v5.11 2020-12-16 16:38:41 -08:00
Makefile Linux 5.10 2020-12-13 14:41:30 -08:00
README Drop all 00-INDEX files from Documentation/ 2018-09-09 15:08:58 -06:00

README 

Linux kernel
============

There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.  The formatted documentation can also be read online at:

    https://www.kernel.org/doc/html/latest/

There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.

Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.