mirrors/linux-stable
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git synced 2024-09-12 13:55:32 +00:00
Code Issues Releases Wiki Activity
No description
731671 commits 104 branches 5093 tags 5.6 GiB
C 97.6%
Assembly 1%
Shell 0.5%
Python 0.3%
Makefile 0.3%
Find a file
Linus Torvalds 64f42625d8 gpiolib: acpi: use correct format characters 
[ Upstream commit 213d266ebf ]

When compiling with -Wformat, clang emits the following warning:

  gpiolib-acpi.c:393:4: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat]
                        pin);
                        ^~~

So warning that '%hhX' is paired with an 'int' is all just completely
mindless and wrong. Sadly, I can see a different bogus warning reason
why people would want to use '%02hhX'.

Again, the *sane* thing from a human perspective is to use '%02X. But
if the compiler doesn't do any range analysis at all, it could decide
that "Oh, that print format could need up to 8 bytes of space in the
result". Using '%02hhX' would cut that down to two.

And since we use

        char ev_name[5];

and currently use "_%c%02hhX" as the format string, even a compiler
that doesn't notice that "pin <= 255" test that guards this all will
go "OK, that's at most 4 bytes and the final NUL termination, so it's
fine".

While a compiler - like gcc - that only sees that the original source
of the 'pin' value is a 'unsigned short' array, and then doesn't take
the "pin <= 255" into account, will warn like this:

  gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
  gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=]
       sprintf(ev_name, "_%c%02X",
                            ^~~~
  gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535]

because gcc isn't being very good at that argument range analysis either.

In other words, the original use of 'hhx' was bogus to begin with, and
due to *another* compiler warning being bad, and we had that bad code
being written back in 2016 to work around _that_ compiler warning
(commit e40a3ae1f7: "gpio: acpi: work around false-positive
-Wstring-overflow warning").

Sadly, two different bad compiler warnings together does not make for
one good one.

It just makes for even more pain.

End result: I think the simplest and cleanest option is simply the
proposed change which undoes that '%hhX' change for gcc, and replaces
it with just using a slightly bigger stack allocation. It's not like
a 5-byte allocation is in any way likely to have saved any actual stack,
since all the other variables in that function are 'int' or bigger.

False-positive compiler warnings really do make people write worse
code, and that's a problem. But on a scale of bad code, I feel that
extending the buffer trivially is better than adding a pointless cast
that literally makes no sense.

At least in this case the end result isn't unreadable or buggy. We've
had several cases of bad compiler warnings that caused changes that
were actually horrendously wrong.

Fixes: e40a3ae1f7 ("gpio: acpi: work around false-positive -Wstring-overflow warning")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-20 09:08:31 +02:00
arch arm64: module: remove (NOLOAD) from linker script 2022-04-20 09:08:30 +02:00
block block: bio-integrity: Advance seed correctly for larger interval sizes 2022-02-08 18:16:28 +01:00
certs certs: Trigger creation of RSA module signing key if it's not an RSA key 2021-09-22 11:45:19 +02:00
crypto crypto: authenc - Fix sleep in atomic context in decrypt_tail 2022-04-20 09:08:12 +02:00
Documentation Documentation: update stable tree link 2022-04-20 09:08:09 +02:00
drivers gpiolib: acpi: use correct format characters 2022-04-20 09:08:31 +02:00
firmware Fix built-in early-load Intel microcode alignment 2020-01-23 08:20:30 +01:00
fs btrfs: fix qgroup reserve overflow the qgroup limit 2022-04-20 09:08:30 +02:00
include xfrm: policy: match with both mark and mask on user interfaces 2022-04-20 09:08:31 +02:00
init init/main.c: return 1 from handled __setup() functions 2022-04-20 09:08:28 +02:00
ipc ipc: WARN if trying to remove ipc object which is absent 2021-12-08 08:46:53 +01:00
kernel cgroup: Use open-time cgroup namespace for process migration perm checks 2022-04-20 09:08:30 +02:00
lib lib/test: use after free in register_test_dev_kmod() 2022-04-20 09:08:21 +02:00
mm mm: don't skip swap entry even if zap_details specified 2022-04-20 09:08:30 +02:00
net xfrm: policy: match with both mark and mask on user interfaces 2022-04-20 09:08:31 +02:00
samples samples/kretprobes: Fix return value if register_kretprobe() failed 2021-11-26 11:40:31 +01:00
scripts Makefile.extrawarn: Move -Wunaligned-access to W=1 2022-02-23 11:57:32 +01:00
security Fix incorrect type in assignment of ipv6 port for audit 2022-04-20 09:08:21 +02:00
sound ASoC: topology: Allow TLV control to be either read or write 2022-04-20 09:08:25 +02:00
tools tools build: Use $(shell ) instead of `` to get embedded libperl's ccopts 2022-04-20 09:08:30 +02:00
usr initramfs: restore default compression behavior 2020-04-13 10:34:19 +02:00
virt KVM: Prevent module exit until all VMs are freed 2022-04-20 09:08:24 +02:00
.cocciconfig
.get_maintainer.ignore
.gitattributes
.gitignore
.mailmap
COPYING
CREDITS
Kbuild
Kconfig
MAINTAINERS MAINTAINERS: Update drm/i915 bug filing URL 2020-02-28 16:36:12 +01:00
Makefile Linux 4.14.275 2022-04-02 12:41:10 +02:00
README

README 

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

This file was moved to Documentation/admin-guide/README.rst

Please notice that there are several guides for kernel developers and users.
These guides can be rendered in a number of formats, like HTML and PDF.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.

There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
See Documentation/00-INDEX for a list of what is contained in each file.

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.