* Regression: SUnreclaim leak: snd_ctl_ioctl?
[not found] <1710953751.8yx03664pf.none.ref@localhost>
@ 2024-03-20 17:01 98% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2024-03-20 17:01 UTC (permalink / raw)
To: linux-kernel, linux-sound
Hi all,
In the last few days of running torvalds master kernel, I found that
SUnreclaim memory seems to increase indefinitely. slabinfo -r kmalloc-2k
says:
Slabcache: kmalloc-2k Aliases: 0 Order : 3 Objects: 1272941
Sizes (bytes) Slabs Debug Memory
------------------------------------------------------------------------
Object : 2048 Total : 264991 Sanity Checks : On Total: 8683225088
SlabObj: 6144 Full : 264972 Redzoning : On Used : 2606983168
SlabSiz: 32768 Partial: 19 Poisoning : On Loss : 6076241920
Loss : 4096 CpuSlab: 0 Tracking : On Lalig: 5213966336
Align : 2048 Objects: 5 Tracing : Off Lpadd: 542701568
kmalloc-2k has no kmem_cache operations
kmalloc-2k: Kernel object allocation
-----------------------------------------------------------------------
1272283 snd_ctl_ioctl+0x45f/0x6d0 waste=1048361192/824 age=6141/183854/366927 pid=687-33984 cpus=0-1,3-8,10
memdup_user+0x21/0x70
snd_ctl_ioctl+0x45f/0x6d0
__x64_sys_ioctl+0x85/0xa0
do_syscall_64+0x3d/0xf0
entry_SYSCALL_64_after_hwframe+0x46/0x4e
189 acpi_add_single_object+0x38/0x710 waste=119448/632 age=368130/368134/368138 pid=1 cpus=0
[ ... ]
kmalloc-2k: Kernel object freeing
------------------------------------------------------------------------
633587 <not-available> age=4295305473 pid=0 cpus=0
382872 rcu_core+0x284/0x540 age=4513/194630/361523 pid=0-21201 cpus=0-11
rcu_core+0x284/0x540
__do_softirq+0xad/0x1de
247690 amdgpu_dm_atomic_commit_tail+0x1721/0x3740 age=6157/199198/366963 pid=163-19507 cpus=0-11
amdgpu_dm_atomic_commit_tail+0x1721/0x3740
commit_tail+0x8a/0x120
process_one_work+0x12b/0x250
worker_thread+0x2d9/0x3f0
kthread+0xac/0xe0
ret_from_fork+0x28/0x40
ret_from_fork_asm+0x11/0x20
2794 __sk_destruct+0x17a/0x1b0 age=994/147194/368001 pid=0-19414 cpus=0-11
[ ... ]
So, if I understand correctly, some memory copied from userspace for
snd_ctl_ioctl is not freed correctly. The PIDs were pipewire,
wireplumber, and pipewire-pulse, so I restarted those but it didn't
resolve the issue.
Let me know what other information is needed.
Thanks,
Alex.
^ permalink raw reply [relevance 98%]
* Don't fill the kernel log with memfd_create messages
[not found] <1693408388.rwssx8r1h9.none.ref@localhost>
@ 2023-08-30 15:52 93% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2023-08-30 15:52 UTC (permalink / raw)
To: Christian Brauner, Aleksa Sarai
Cc: Andrew Morton, Shuah Khan, Jeff Xu, Kees Cook, Daniel Verkamp,
Dominique Martinet, stable, linux-api, linux-kernel, linux-mm,
linux-kselftest
Hi all,
Recently "memfd: improve userspace warnings for missing exec-related
flags" was merged. On my system, this is a regression, not an
improvement, because the entire 256k kernel log buffer (default on x86)
is filled with these warnings and "__do_sys_memfd_create: 122 callbacks
suppressed". I haven't investigated too closely, but the most likely
cause is Wayland libraries.
This is too serious of a consequence for using an old API, especially
considering how recently the flags were added. The vast majority of
software has not had time to add the flags: glibc does not define the
macros until 2.38 which was released less than one month ago, man-pages
does not document the flags, and according to Debian Code Search, only
systemd, stress-ng, and strace actually pass either of these flags.
Furthermore, since old kernels reject unknown flags, it's not just a
matter of defining and passing the flag; every program needs to
add logic to handle EINVAL and try again.
Some other way needs to be found to encourage userspace to add the
flags; otherwise, this message will be patched out because the kernel
log becomes unusable after running unupdated programs, which will still
exist even after upstreams are fixed. In particular, AppImages,
flatpaks, snaps, and similar app bundles contain vendored Wayland
libraries which can be difficult or impossible to update.
Thanks,
Alex.
^ permalink raw reply [relevance 93%]
* [PATCH] x86/Kconfig: Allow X86_X32_ABI with llvm-objcopy in some cases
[not found] <20220701210437.579322-1-alex_y_xu.ref@yahoo.ca>
@ 2022-07-01 21:04 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2022-07-01 21:04 UTC (permalink / raw)
To: Nathan Chancellor, Peter Zijlstra, x86, llvm
Cc: Andy Lutomirski, H. Peter Anvin, Nick Desaulniers,
Masahiro Yamada, linux-kernel, Alex Xu (Hello71)
According to the comment and commit message, there are issues compiling
with IBT and/or compressed debug sections. Therefore, the condition
should be restricted to when those are enabled.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index be0b95e51df6..e5af1088420e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2847,7 +2847,7 @@ config X86_X32_ABI
# compressed debug sections to x86_x32 properly:
# https://github.com/ClangBuiltLinux/linux/issues/514
# https://github.com/ClangBuiltLinux/linux/issues/1141
- depends on $(success,$(OBJCOPY) --version | head -n1 | grep -qv llvm)
+ depends on !X86_KERNEL_IBT || !DEBUG_INFO_COMPRESSED || $(success,$(OBJCOPY) --version | head -n1 | grep -qv llvm)
help
Include code to run binaries for the x32 native 32-bit ABI
for 64-bit processors. An x32 process gets access to the
--
2.36.1
^ permalink raw reply related [relevance 99%]
* Re: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in amdgpu after suspend)
@ 2022-06-28 19:28 96% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2022-06-28 19:28 UTC (permalink / raw)
To: paulmck
Cc: alexander.deucher, amd-gfx, Arve Hjønnevåg,
Christian Brauner, christian.koenig, Greg Kroah-Hartman,
Hridya Valsaraju, Jason A. Donenfeld, Joel Fernandes,
linux-kernel, Martijn Coenen, rcu, Suren Baghdasaryan, Todd Kjos,
Theodore Ts'o, uladzislau.rezki, urezki, wireguard,
Xinhui.Pan
Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
> All you need to do to get the previous behavior is to add something like
> this to your defconfig file:
>
> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
>
> Any reason why this will not work for you?
As far as I know, I do not require any particular RCU debugging features
intended for developers; as an individual user and distro maintainer, I
would like to select the option corresponding to "emit errors for
unexpected conditions which should be reported upstream", not "emit
debugging information for development purposes".
Therefore, I think 0 is a suitable setting for me and most ordinary
(not tightly controlled) distributions. My concern is that other users
and distro maintainers will also have confusion about what value to set
and whether the warnings are important, since the help text does not say
anything about Android, and "make oldconfig" does not indicate that the
default value is different for Android.
My suggestion is that the default be set to 0, and if a non-zero value
is appropriate for Android, that should be communicated to the Android
developers, not made conditional on CONFIG_ANDROID.
Thanks,
Alex.
^ permalink raw reply [relevance 96%]
* CONFIG_ANDROID (was: rcu_sched detected expedited stalls in amdgpu after suspend)
[not found] ` <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
@ 2022-06-28 15:02 88% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2022-06-28 15:02 UTC (permalink / raw)
To: paulmck, rcu, urezki, uladzislau.rezki, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Hridya Valsaraju,
Suren Baghdasaryan, linux-kernel, Jason A. Donenfeld, wireguard,
Theodore Ts'o
Cc: alexander.deucher, christian.koenig, Xinhui.Pan, amd-gfx
Excerpts from Paul E. McKenney's message of June 28, 2022 12:12 am:
> On Mon, Jun 27, 2022 at 09:50:53PM -0400, Alex Xu (Hello71) wrote:
>> Ah, I see. I have selected the default value for
>> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT, but that is 20 if ANDROID. I am not
>> using Android; I'm not sure there exist Android devices with AMD GPUs.
>> However, I have set CONFIG_ANDROID=y in order to use
>> ANDROID_BINDER_IPC=m for emulation.
>>
>> In general, I think CONFIG_ANDROID is not a reliable method for
>> detecting if the kernel is for an Android device; for example, Fedora
>> sets CONFIG_ANDROID, but (AFAIK) its kernel is not intended for use with
>> Android userspace.
>>
>> On the other hand, it's not clear to me why the value 20 should be for
>> Android only anyways. If, as you say in
>> https://lore.kernel.org/lkml/20220216195508.GM4285@paulmck-ThinkPad-P17-Gen-1/,
>> it is related to the size of the system, perhaps some other heuristic
>> would be more appropriate.
>
> It is related to the fact that quite a few Android guys want these
> 20-millisecond short-timeout expedited RCU CPU stall warnings, but no one
> else does. Not yet anyway.
>
> And let's face it, the intent and purpose of CONFIG_ANDROID=y is extremely
> straightforward and unmistakeable. So perhaps people not running Android
> devices but wanting a little bit of the Android functionality should do
> something other than setting CONFIG_ANDROID=y in their .config files. Me,
> I am surprised that it took this long for something like this to bite you.
>
> But just out of curiosity, what would you suggest instead?
Both Debian and Fedora set CONFIG_ANDROID, specifically for binder. If
major distro vendors are consistently making this "mistake", then
perhaps the problem is elsewhere.
In my own opinion, assuming that binderfs means Android vendor is not a
good assumption. The ANDROID help says:
> Enable support for various drivers needed on the Android platform
It doesn't say "Enable only if building an Android device", or "Enable
only if you are Google". Isn't the traditional Linux philosophy a
collection of pieces to be assembled, without gratuitous hidden
dependencies? For example, [0] removes the unnecessary Android
dependency, it doesn't block the whole thing with "depends on ANDROID".
It seems to me that the proper way to set some configuration for Android
kernels is or should be to ask the Android kernel config maintainers,
not to set it based on an upstream kernel option. There is, after all,
no CONFIG_FEDORA or CONFIG_UBUNTU or CONFIG_HANNAH_MONTANA.
WireGuard and random also use CONFIG_ANDROID in a similar "proxy" way as
rcu, there to see if suspends are "frequent". This seems dubious for the
same reasons.
I wonder if it might be time to retire CONFIG_ANDROID: the only
remaining driver covered is binder, which originates from Android but
is no longer used exclusively on Android systems. Like ufs-qcom, binder
is no longer used exclusively on Android devices; it is also used for
Android device emulators, which might be used on Android-like mobile
devices, or might not.
My understanding is that both Android and upstream kernel developers
intend to add no more Android-specific drivers, so binder should be the
only one covered for the foreseeable future.
> For that matter, why the private reply?
Mail client issues, not intentional. Lists re-added, plus Android,
WireGuard, and random.
Thanks,
Alex.
[0] https://lore.kernel.org/all/20220321151853.24138-1-krzk@kernel.org/
^ permalink raw reply [relevance 88%]
* Re: [PATCH] mm/smaps_rollup: return empty file for kthreads instead of ESRCH
@ 2022-04-14 15:24 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2022-04-14 15:24 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Matthew Wilcox, Andrew Morton, Daniel Colascione, linux-api,
linux-fsdevel, linux-kernel, linux-mm, Vlastimil Babka
Excerpts from Alexey Dobriyan's message of April 14, 2022 2:55 am:
> Returning ESRCH is better so that programs don't waste time reading and
> closing empty files and instantiating useless inodes.
Yes, except ESRCH is not returned for open, it is returned for read.
> Of course it is different if this patch was sent as response to a regression.
I'm not sure I would classify it as a regression; I don't have an
existing program which broke, it is a new program which happens to use
some functionality which worked with a previous kernel. It is
theoretically possible that some program exists that currently uses
4.14, and will break if upgraded to 4.19+, but it is also possible that
some program exists that currently uses 4.19+ and will break if this
patch is applied.
Cheers,
Alex.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] mm/smaps_rollup: return empty file for kthreads instead of ESRCH
@ 2022-04-13 22:25 90% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2022-04-13 22:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Alexey Dobriyan, Daniel Colascione, linux-api, linux-fsdevel,
linux-kernel, linux-mm, Vlastimil Babka
Excerpts from Andrew Morton's message of April 13, 2022 5:27 pm:
> On Wed, 13 Apr 2022 17:13:57 -0400 "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca> wrote:
>
>> This restores the behavior prior to 258f669e7e88 ("mm:
>> /proc/pid/smaps_rollup: convert to single value seq_file"), making it
>> once again consistent with maps and smaps, and allowing patterns like
>> awk '$1=="Anonymous:"{x+=$2}END{print x}' /proc/*/smaps_rollup to work.
>> Searching all Debian packages for "smaps_rollup" did not find any
>> programs which would be affected by this change.
>
> Thanks.
>
> 258f669e7e88 was 4 years ago, so I guess a -stable backport isn't
> really needed.
>
> However, we need to be concerned about causing new regressions, and I
> don't think you've presented enough information for this to be determined.
>
> So please provide us with a full description of how the smaps_rollup
> output will be altered by this patch. Quoting example output would be
> helpful.
>
>
Current behavior (4.19+):
$ cat /proc/2/smaps; echo $?
0
$ cat /proc/2/smaps_rollup; echo $?
cat: /proc/2/smaps_rollup: No such process
1
$ strace -yP /proc/2/smaps_rollup cat /proc/2/smaps_rollup
openat(AT_FDCWD</>, "/proc/2/smaps_rollup", O_RDONLY) = 3</proc/2/smaps_rollup>
newfstatat(3</proc/2/smaps_rollup>, "", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_EMPTY_PATH) = 0
fadvise64(3</proc/2/smaps_rollup>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
read(3</proc/2/smaps_rollup>, 0x7fa475f5d000, 131072) = -1 ESRCH (No such process)
cat: /proc/2/smaps_rollup: No such process
close(3</proc/2/smaps_rollup>) = 0
+++ exited with 1 +++
Pre-4.19 and post-patch behavior:
$ cat /proc/2/smaps; echo $?
0
$ cat /proc/2/smaps_rollup; echo $?
0
$ strace -yP /proc/2/smaps_rollup cat /proc/2/smaps_rollup
openat(AT_FDCWD</>, "/proc/2/smaps_rollup", O_RDONLY) = 3</proc/2/smaps_rollup>
newfstatat(3</proc/2/smaps_rollup>, "", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_EMPTY_PATH) = 0
fadvise64(3</proc/2/smaps_rollup>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
read(3</proc/2/smaps_rollup>, "", 131072) = 0
close(3</proc/2/smaps_rollup>) = 0
+++ exited with 0 +++
I agree that this type of change must be done carefully to avoid
introducing inadvertent regressions. However, I think this particular
change is highly unlikely to introduce regressions for the following
reasons:
1. I cannot think of a plausible case which would be affected. The only
case I can possibly imagine is a program checking whether a process
is a kernel thread, but this seems like a particularly silly method.
Moreover, the method is already broken on kernels before 4.14
(because smaps_rollup does not exist) and before 4.19 (because
smaps_rollup worked like smaps). A plausible method would be opening
/proc/x/(s)maps and checking that it is empty, which some programs
actually do.
2. Research on Debian Code Search did not find any apparent cases. I also
searched GitHub Code Search but found too many irrelevant results with
no useful way to filter them out.
3. As mentioned previously, this was already the behavior between 4.14
and 4.18 (inclusive).
Cheers,
Alex.
^ permalink raw reply [relevance 90%]
* [PATCH] mm/smaps_rollup: return empty file for kthreads instead of ESRCH
[not found] <20220413211357.26938-1-alex_y_xu.ref@yahoo.ca>
@ 2022-04-13 21:13 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2022-04-13 21:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Vlastimil Babka, Daniel Colascione, linux-mm, linux-kernel,
linux-fsdevel, Alexey Dobriyan, linux-api, Alex Xu (Hello71)
This restores the behavior prior to 258f669e7e88 ("mm:
/proc/pid/smaps_rollup: convert to single value seq_file"), making it
once again consistent with maps and smaps, and allowing patterns like
awk '$1=="Anonymous:"{x+=$2}END{print x}' /proc/*/smaps_rollup to work.
Searching all Debian packages for "smaps_rollup" did not find any
programs which would be affected by this change.
Fixes: 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value seq_file")
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
fs/proc/task_mmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index f46060eb91b5..d7de4584a271 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -883,10 +883,8 @@ static int show_smaps_rollup(struct seq_file *m, void *v)
return -ESRCH;
mm = priv->mm;
- if (!mm || !mmget_not_zero(mm)) {
- ret = -ESRCH;
+ if (!mm || !mmget_not_zero(mm))
goto out_put_task;
- }
memset(&mss, 0, sizeof(mss));
--
2.35.2
^ permalink raw reply related [relevance 99%]
* Re: "dma-mapping: remove CONFIG_DMA_REMAP" causes AMD SME boot fail
@ 2022-03-30 19:17 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2022-03-30 19:17 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: iommu, linux-kernel, regressions
Excerpts from Christoph Hellwig's message of March 30, 2022 2:01 pm:
> Can you try this patch, which is a bit of a hack?
>
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 50d209939c66c..61997c2ee0a17 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -28,7 +28,8 @@ bool force_dma_unencrypted(struct device *dev)
> * device does not support DMA to addresses that include the
> * encryption mask.
> */
> - if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
> + if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) &&
> + !get_dma_ops(dev)) {
> u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
> u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
> dev->bus_dma_limit);
>
This seems to work for me.
Cheers,
Alex.
^ permalink raw reply [relevance 99%]
* "dma-mapping: remove CONFIG_DMA_REMAP" causes AMD SME boot fail
[not found] <1648659326.eabkokyuym.none.ref@localhost>
@ 2022-03-30 17:51 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2022-03-30 17:51 UTC (permalink / raw)
To: Christoph Hellwig, regressions; +Cc: linux-kernel, iommu
Hi,
After a recent kernel update, booting one of my machines causes it to
hang on a black screen. Pressing Lock keys on the USB keyboard does not
turn on the indicators, and the machine does not appear on the Ethernet
network. I don't have a serial port on this machine. I didn't try
netconsole, but I suspect it won't work.
Setting mem_encrypt=0 seems to resolve the issue. Reverting f5ff79fddf0e
("dma-mapping: remove CONFIG_DMA_REMAP") also appears to resolve the
issue.
The machine in question has an AMD Ryzen 5 1600 and ASRock B450 Pro4.
Cheers,
Alex.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] random: allow writes to /dev/urandom to influence fast init
@ 2022-03-24 19:03 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2022-03-24 19:03 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Jann Horn, Linux Crypto Mailing List, Dominik Brodowski, LKML,
Guenter Roeck, Linus Torvalds, Theodore Ts'o
Excerpts from Jason A. Donenfeld's message of March 24, 2022 1:20 pm:
> Hi Alex,
>
> On Thu, Mar 24, 2022 at 10:29 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
>> The issue, in systemd developers' opinion, is that counting seed file
>> towards entropy initialization potentially causes repeated RNG output if
>> a system is cloned without resetting the seed file. This is discussed at
>> length in https://github.com/systemd/systemd/pull/4513. A few years ago,
>> I wrote most of a program to check machine ID, disk ID, DMI ID, and some
>> other things in order to avoid this issue. Since then, systemd decided
>> to store the random seed in EFI variables, I assume on the basis that
>> machine cloning typically does not clone the EFI variables? In my
>> opinion, since the same argument applies to machine ID, ssh keys, and
>> any other persistent cryptographic (or even non-cryptographic) material,
>> this falls outside the scope of random seeding and into a general
>> machine cloning "sysprep"-like utility.
>
> systemd's seed utility will credit a seed file if the seed file was
> generated properly (e.g. after the RNG was initialized). For that they
> use the user.random-seed-creditable xattr, which is a reasonable way of
> deciding. If that attribute is present, it's credited; if it's not, it's
> not. Here's their source:
>
> /* If we got this random seed data from getrandom() the data is suitable for crediting
> * entropy later on. Let's keep that in mind by setting an extended attribute. on the file */
> if (getrandom_worked)
> if (fsetxattr(seed_fd, "user.random-seed-creditable", "1", 1, 0) < 0)
> log_full_errno(ERRNO_IS_NOT_SUPPORTED(errno) ? LOG_DEBUG : LOG_WARNING, errno,
> "Failed to mark seed file as creditable, ignoring: %m");
>
> Since my seedrng.c is designed for more minimal systems (running
> buildroot or openrc or whatever), which might not have xattrs available,
> it distinguishes just based on the filename:
>
> if (new_seed_creditable && rename(NON_CREDITABLE_SEED, CREDITABLE_SEED) < 0) {
> fprintf(stderr, "ERROR: Unable to make new seed creditable: %s\n", strerror(errno));
> program_ret |= 1 << 6;
> }
>
> It's no surprise that these are very similar; I've read systemd's
> seeding logic and contributed a fix to it.
>
> By the way, if you think something is different or wrong or whatever in
> seedrng.c, please feel free to send me a patch for it. It already
> received its first contribution this morning (from the buildroot
> maintainer). Hopefully the code will reach a good settling point soon,
> and then various projects that want it can just copy and paste it
> verbatim into their environment, and tweak idiomatic things as needed.
>
> Jason
>
Right, but I'm saying that even if the seed file is good when you wrote
it, it becomes bad if you copy it to multiple machines (e.g. by VM
cloning). For various reasons, I think this is outside the scope of the
random seed services to handle, but I think it's good to keep in mind.
Cheers,
Alex.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] random: allow writes to /dev/urandom to influence fast init
@ 2022-03-24 16:28 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2022-03-24 16:28 UTC (permalink / raw)
To: Jann Horn, Jason A. Donenfeld, Dominik Brodowski, Guenter Roeck,
Linus Torvalds, Theodore Ts'o
Cc: Linux Crypto Mailing List, LKML
Excerpts from Jason A. Donenfeld's message of March 23, 2022 11:18 pm:
> Hi all,
>
> [...]
>
> In light of that conclusion, I'm going to work with every userspace
> downstream I can find to help them fix their file-based seeding, if it
> has bugs. I've started talking with the buildroot folks, and then I'll
> speak with the OpenRC people (being a Gentoo dev, that should be easy
> going). Systemd does the right thing already.
>
> I wrote a little utility for potential inclusion in
> busybox/util-linux/whatever when it matures beyond its current age of
> being half hour old:
> - https://git.zx2c4.com/seedrng/about/
> - https://git.zx2c4.com/seedrng/tree/seedrng.c
> So I'll see what the buildroot people think of this and take it from there.
>
> The plus side of doing all this is that, if the efforts pan out, it
> means there'll actually be proper seeding on devices that don't
> currently do that, which then might lead to a better ecosystem and
> less boot time blocking and all that jazz.
>
> Jason
>
The issue, in systemd developers' opinion, is that counting seed file
towards entropy initialization potentially causes repeated RNG output if
a system is cloned without resetting the seed file. This is discussed at
length in https://github.com/systemd/systemd/pull/4513. A few years ago,
I wrote most of a program to check machine ID, disk ID, DMI ID, and some
other things in order to avoid this issue. Since then, systemd decided
to store the random seed in EFI variables, I assume on the basis that
machine cloning typically does not clone the EFI variables? In my
opinion, since the same argument applies to machine ID, ssh keys, and
any other persistent cryptographic (or even non-cryptographic) material,
this falls outside the scope of random seeding and into a general
machine cloning "sysprep"-like utility.
Cheers,
Alex.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] random: allow writes to /dev/urandom to influence fast init
@ 2022-03-23 4:30 90% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2022-03-23 4:30 UTC (permalink / raw)
To: Jason A. Donenfeld, linux-crypto, linux-kernel
Cc: Jann Horn, Dominik Brodowski, Guenter Roeck, Linus Torvalds,
Theodore Ts'o
I searched for users of RNDADDTOENTCNT using
(?s:ioctl.{1,500}RNDADDTOENTCNT) on Debian Code Search and
"/(?s)ioctl.{1,40},\s*RNDADDTOENTCNT/ -path:incfs_test.c" on GitHub Code
Search (beta).
Several programs use it for testing purposes, without writing any
entropy to /dev/random or /dev/urandom, including rauc, wireguard, and
openSUSE kdump. Several programs use it as intended, after writing
entropy to /dev/random or /dev/urandom. Of the latter group,
- kata-containers is a lightweight VM implementation. Its guest-side
agent offers a gRPC endpoint which will write the provided data to
/dev/random, then call RNDADDTOENTCNT with the length of the data,
then call RNDRESEEDRNG. As far as I can tell, this endpoint is
made available to users on the host, but is not used by
kata-containers itself.
- aws-nitro-enclaves-sdk-c is an SDK for building lightweight VMs to be
used with AWS Nitro Enclaves. kmstool-enclave is a sample application
provided, which writes "up to 256 bytes" (from where?) to /dev/random,
then calls RNDADDTOENTCNT, then repeats the process until it reaches
1024 bytes.
- sandy-harris/maxwell is a "jitter entropy" daemon, similar to haveged.
It writes 4 bytes of "generated entropy" to /dev/random, then calls
RNDADDTOENTCNT, then repeats.
- guix is, among other things, a "GNU/"Linux distribution. The provided
base services write the seed file to /dev/urandom, then call
RNDADDTOENTCNT, then write 512 bytes from /dev/hwrng to /dev/urandom,
then call RNDADDTOENTCNT, then "immediately" read 512 bytes from
/dev/urandom and write it to the seed file. On shutdown, 512 bytes are
read from /dev/urandom and written to the seed file.
I was unable to locate any other public non-archived usages of
RNDADDTOENTCNT on Debian or GitHub Code Search.
I don't have any particular expertise with the random subsystem or
conclusions to make from this data, but I hope this helps inform the
discussion.
Cheers,
Alex.
^ permalink raw reply [relevance 90%]
* Re: [PATCH -next] blk-mq: Fix wrong wakeup batch configuration which will cause hang
@ 2022-01-27 14:17 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2022-01-27 14:17 UTC (permalink / raw)
To: andriy.shevchenko, axboe, Laibin Qiu; +Cc: linux-block, linux-kernel
Excerpts from Laibin Qiu's message of January 27, 2022 5:00 am:
> Commit 180dccb0dba4f ("blk-mq: fix tag_get wait task can't be
> awakened") will recalculating wake_batch when inc or dec active_queues
> to avoid wake_batch is > hctx_max_depth. At the same time, in order to
> not affect performance as much as possible, the minimum wakeup batch is
> set to 4. But when the QD is small (such as QD=1), if inc or dec
> active_queues will increase wakeup batch, which will lead to hang.
>
> Fix this problem with the following strategies:
> QD : >= 32 | < 32
> ---------------------------------
> wakeup batch: 8~4 | 3~1
>
> Fixes: 180dccb0dba4f ("blk-mq: fix tag_get wait task can't be awakened")
> Link: https://lore.kernel.org/linux-block/78cafe94-a787-e006-8851-69906f0c2128@huawei.com/T/#t
> Reported-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
> Signed-off-by: Laibin Qiu <qiulaibin@huawei.com>
> ---
> lib/sbitmap.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/sbitmap.c b/lib/sbitmap.c
> index 6220fa67fb7e..09d293c30fd2 100644
> --- a/lib/sbitmap.c
> +++ b/lib/sbitmap.c
> @@ -488,9 +488,13 @@ void sbitmap_queue_recalculate_wake_batch(struct sbitmap_queue *sbq,
> unsigned int users)
> {
> unsigned int wake_batch;
> + unsigned int min_batch;
> + unsigned int depth = (sbq->sb.depth + users - 1) / users;
>
> - wake_batch = clamp_val((sbq->sb.depth + users - 1) /
> - users, 4, SBQ_WAKE_BATCH);
> + min_batch = sbq->sb.depth >= (4 * SBQ_WAIT_QUEUES) ? 4 : 1;
> +
> + wake_batch = clamp_val(depth / SBQ_WAIT_QUEUES,
> + min_batch, SBQ_WAKE_BATCH);
> __sbitmap_queue_update_wake_batch(sbq, wake_batch);
> }
> EXPORT_SYMBOL_GPL(sbitmap_queue_recalculate_wake_batch);
> --
> 2.22.0
>
>
Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
^ permalink raw reply [relevance 99%]
* Re: "blk-mq: fix tag_get wait task can't be awakened" causes hangs
@ 2022-01-25 15:15 98% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2022-01-25 15:15 UTC (permalink / raw)
To: Andy Shevchenko, axboe, linux-block, QiuLaibin
Cc: akpm, bvanassche, hare, john.garry, linux-kernel,
martin.petersen, ming.lei, Daniel Palmer
Excerpts from QiuLaibin's message of January 24, 2022 11:08 pm:
> Hi Alex
>
> 1、Please help to import this structure:
>
> blk_mq_tags <= request_queue->blk_mq_hw_ctx->blk_mq_tags
I don't understand what you mean.
> If there is no kernel dump, help to see the value of
>
> cat /sys/block/sda/mq/0/nr_tags
> __ <= Change it to the problem device
The affected device returns 1. My understanding is that mq does not work
with legacy non-UAS devices.
> And how many block devices in total by lsblk.
My device topology roughly looks like:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 [snip] 0 disk
├─sda1 8:1 0 [snip] 0 part
├─sda2 8:2 0 [snip] 0 part
└─sda3 8:3 0 [snip] 0 part
sdb 8:16 0 [snip] 0 disk
├─sdb1 8:17 0 [snip] 0 part
├─sdb2 8:18 0 [snip] 0 part
├─sdb3 8:19 0 [snip] 0 part
└─sdb4 8:20 0 [snip] 0 part
sdc 8:32 1 [snip] 0 disk
├─sdc1 8:33 1 [snip] 0 part
└─sdc2 8:34 1 [snip] 0 part
nvme0n1 259:0 0 [snip] 0 disk
├─nvme0n1p1 259:1 0 [snip] 0 part
└─nvme0n1p2 259:2 0 [snip] 0 part
└─root 254:0 0 [snip] 0 crypt /
> 2、Please describe in detail how to reproduce the issue,
1. Plug in the device.
2. Execute Show Blocked Tasks. udev is stuck.
> And what type of USB device?
It is a cheap unbranded USB flash drive.
> 3、Please help to try the attachment patch and see if it can be reproduced.
From a quick test, it appears to resolve the issue.
> Thanks.
Cheers,
Alex.
^ permalink raw reply [relevance 98%]
* "blk-mq: fix tag_get wait task can't be awakened" causes hangs
[not found] <1643040870.3bwvk3sis4.none.ref@localhost>
@ 2022-01-24 16:24 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2022-01-24 16:24 UTC (permalink / raw)
To: Laibin Qiu, axboe, Andy Shevchenko, linux-block
Cc: john.garry, ming.lei, martin.petersen, hare, akpm, bvanassche,
linux-kernel
Hi,
Recently on torvalds master, I/O on USB flash drives started hanging
here:
task:systemd-udevd state:D stack: 0 pid: 374 ppid: 347 flags:0x00004000
Call Trace:
<TASK>
? __schedule+0x319/0x4a0
? schedule+0x77/0xa0
? io_schedule+0x43/0x60
? blk_mq_get_tag+0x175/0x2b0
? mempool_alloc+0x33/0x170
? init_wait_entry+0x30/0x30
? __blk_mq_alloc_requests+0x1b4/0x220
? blk_mq_submit_bio+0x213/0x490
? submit_bio_noacct+0x22c/0x270
? xa_load+0x48/0x80
? mpage_readahead+0x114/0x130
? blkdev_fallocate+0x170/0x170
? read_pages+0x48/0x1d0
? page_cache_ra_unbounded+0xee/0x1f0
? force_page_cache_ra+0x68/0xc0
? filemap_read+0x18c/0x9a0
? blkdev_read_iter+0x4e/0x120
? vfs_read+0x265/0x2d0
? ksys_read+0x50/0xa0
? do_syscall_64+0x62/0x90
? do_user_addr_fault+0x271/0x3c0
? asm_exc_page_fault+0x8/0x30
? exc_page_fault+0x58/0x80
? entry_SYSCALL_64_after_hwframe+0x44/0xae
</TASK>
mount(8) hangs with a similar backtrace, making the device effectively
unusable. It does not seem to affect NVMe or SATA attached drives. The
affected drive does not support UAS. I don't currently have UAS drives
to test with. The default I/O scheduler is set to noop.
I found that reverting 180dccb0dba4 ("blk-mq: fix tag_get wait
task can't be awakened") appears to resolve the issue.
Let me know what other information is needed.
Cheers,
Alex.
^ permalink raw reply [relevance 99%]
* very low IOPS due to "block: reduce kblockd_mod_delayed_work_on() CPU consumption"
[not found] <1639853092.524jxfaem2.none.ref@localhost>
@ 2021-12-18 18:57 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-12-18 18:57 UTC (permalink / raw)
To: Jens Axboe, linux-block, Dexuan Cui, ming.lei, hch, Long Li,
Michael Kelley (LINUX),
linux-kernel
Hi,
I recently noticed that between 6441998e2e and 9eaa88c703, I/O became
much slower on my machine using ext4 on dm-crypt on NVMe with bfq
scheduler. Checking iostat during heavy usage (find / -xdev and fstrim
-v /), maximum IOPS had fallen from ~10000 to ~100. Reverting cb2ac2912a
("block: reduce kblockd_mod_delayed_work_on() CPU consumption") resolves
the issue.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* [PATCH v2 2/2] kbuild: pass --stream-size --no-content-size to zstd
2021-11-24 15:31 80% ` [PATCH v2 1/2] kbuild: use perl instead of shell to get file size Alex Xu (Hello71)
@ 2021-11-24 15:31 90% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-11-24 15:31 UTC (permalink / raw)
To: Michael Forney, Masahiro Yamada, Michal Marek, Nick Desaulniers,
Nick Terrell, Ingo Molnar, Sedat Dilek, Kees Cook, linux-kernel,
linux-kbuild
Cc: Alex Xu (Hello71)
Otherwise, it allocates 2 GB of memory at once. Even though the majority
of this memory is never touched, the default heuristic overcommit
refuses this request if less than 2 GB of RAM+swap is currently
available. This results in "zstd: error 11 : Allocation error : not
enough memory" and the kernel failing to build.
When the size is specified, zstd will reduce the memory request
appropriately. For typical kernel sizes of ~32 MB, the largest mmap
request will be reduced to 512 MB, which will succeed on all but the
smallest devices.
For inputs around this size, --stream-size --no-content-size may
slightly decrease the compressed size, or slightly increase it:
https://github.com/facebook/zstd/issues/2848.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
scripts/Makefile.lib | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index ca901814986a..c98a82ca38e6 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -466,12 +466,20 @@ quiet_cmd_xzmisc = XZMISC $@
# single pass, so zstd doesn't need to allocate a window buffer. When streaming
# decompression is used, like initramfs decompression, zstd22 should likely not
# be used because it would require zstd to allocate a 128 MB buffer.
+#
+# --stream-size to reduce zstd memory usage (otherwise zstd -22 --ultra
+# allocates, but does not use, 2 GB) and potentially improve compression.
+#
+# --no-content-size to save three bytes which we do not use (we use size_append).
+
+# zstd --stream-size is only supported since 1.4.4
+zstd_stream_size = $(shell $(ZSTD) -1c --stream-size=0 --no-content-size </dev/null >/dev/null 2>&1 && printf '%s' '--stream-size=$(total_size) --no-content-size')
quiet_cmd_zstd = ZSTD $@
- cmd_zstd = { cat $(real-prereqs) | $(ZSTD) -19; $(size_append); } > $@
+ cmd_zstd = { cat $(real-prereqs) | $(ZSTD) $(zstd_stream_size) -19; $(size_append); } > $@
quiet_cmd_zstd22 = ZSTD22 $@
- cmd_zstd22 = { cat $(real-prereqs) | $(ZSTD) -22 --ultra; $(size_append); } > $@
+ cmd_zstd22 = { cat $(real-prereqs) | $(ZSTD) $(zstd_stream_size) -22 --ultra; $(size_append); } > $@
# ASM offsets
# ---------------------------------------------------------------------------
--
2.34.0
^ permalink raw reply related [relevance 90%]
* [PATCH v2 1/2] kbuild: use perl instead of shell to get file size
[not found] <20211124153105.155739-1-alex_y_xu.ref@yahoo.ca>
@ 2021-11-24 15:31 80% ` Alex Xu (Hello71)
2021-11-24 15:31 90% ` [PATCH v2 2/2] kbuild: pass --stream-size --no-content-size to zstd Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2021-11-24 15:31 UTC (permalink / raw)
To: Michael Forney, Masahiro Yamada, Michal Marek, Nick Desaulniers,
Nick Terrell, Ingo Molnar, Sedat Dilek, Kees Cook, linux-kernel,
linux-kbuild
Cc: Alex Xu (Hello71)
This makes it easier to get the size of multiple files. Perl is already
a requirement for all builds to do header checks, so this is not an
additional dependency.
---
arch/arm/boot/deflate_xip_data.sh | 2 +-
arch/powerpc/boot/wrapper | 2 +-
scripts/Makefile.lib | 9 ++-------
scripts/file-size.pl | 8 ++++++++
scripts/file-size.sh | 4 ----
scripts/link-vmlinux.sh | 4 ++--
6 files changed, 14 insertions(+), 15 deletions(-)
create mode 100755 scripts/file-size.pl
delete mode 100755 scripts/file-size.sh
diff --git a/arch/arm/boot/deflate_xip_data.sh b/arch/arm/boot/deflate_xip_data.sh
index 304495c3c2c5..14cfa2babb93 100755
--- a/arch/arm/boot/deflate_xip_data.sh
+++ b/arch/arm/boot/deflate_xip_data.sh
@@ -43,7 +43,7 @@ data_start=$(($__data_loc - $base_offset))
data_end=$(($_edata_loc - $base_offset))
# Make sure data occupies the last part of the file.
-file_end=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" "$XIPIMAGE")
+file_end=$(${PERL} "${srctree}/scripts/file-size.pl" "$XIPIMAGE")
if [ "$file_end" != "$data_end" ]; then
printf "end of xipImage doesn't match with _edata_loc (%#x vs %#x)\n" \
$(($file_end + $base_offset)) $_edata_loc 1>&2
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 9184eda780fd..9f9ee8613432 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -380,7 +380,7 @@ vmz="$tmpdir/`basename \"$kernel\"`.$ext"
# Calculate the vmlinux.strip size
${CROSS}objcopy $objflags "$kernel" "$vmz.$$"
-strip_size=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" "$vmz.$$")
+strip_size=$(${PERL} "${srctree}/scripts/file-size.pl" "$vmz.$$")
if [ -z "$cacheit" -o ! -f "$vmz$compression" -o "$vmz$compression" -ot "$kernel" ]; then
# recompress the image if we need to
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index d1f865b8c0cb..ca901814986a 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -379,13 +379,8 @@ dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
# Bzip2 and LZMA do not include size in file... so we have to fake that;
# append the size as a 32-bit littleendian number as gzip does.
-size_append = printf $(shell \
-dec_size=0; \
-for F in $(real-prereqs); do \
- fsize=$$($(CONFIG_SHELL) $(srctree)/scripts/file-size.sh $$F); \
- dec_size=$$(expr $$dec_size + $$fsize); \
-done; \
-printf "%08x\n" $$dec_size | \
+total_size = $(shell $(PERL) $(srctree)/scripts/file-size.pl $(real-prereqs))
+size_append = printf $(shell printf "%08x\n" $(total_size) | \
sed 's/\(..\)/\1 /g' | { \
read ch0 ch1 ch2 ch3; \
for ch in $$ch3 $$ch2 $$ch1 $$ch0; do \
diff --git a/scripts/file-size.pl b/scripts/file-size.pl
new file mode 100755
index 000000000000..170bb6d048fa
--- /dev/null
+++ b/scripts/file-size.pl
@@ -0,0 +1,8 @@
+#!/usr/bin/perl -w
+# SPDX-License-Identifier: GPL-2.0
+my $total = 0;
+foreach (@ARGV) {
+ @stat = stat $_ or die "$_: $!";
+ $total += $stat[7];
+}
+print "$total\n";
diff --git a/scripts/file-size.sh b/scripts/file-size.sh
deleted file mode 100755
index 7eb7423416b5..000000000000
--- a/scripts/file-size.sh
+++ /dev/null
@@ -1,4 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0
-set -- $(ls -dn "$1")
-printf '%s\n' "$5"
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 5cdd9bc5c385..c3fa38bd18ab 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -384,8 +384,8 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then
kallsyms_step 2
# step 3
- size1=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" ${kallsymso_prev})
- size2=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" ${kallsymso})
+ size1=$(${PERL} "${srctree}/scripts/file-size.pl" ${kallsymso_prev})
+ size2=$(${PERL} "${srctree}/scripts/file-size.pl" ${kallsymso})
if [ $size1 -ne $size2 ] || [ -n "${KALLSYMS_EXTRA_PASS}" ]; then
kallsyms_step 3
--
2.34.0
^ permalink raw reply related [relevance 80%]
* [PATCH 2/2] kbuild: pass --stream-size --no-content-size to zstd
2021-11-20 16:53 80% ` [PATCH 1/2] kbuild: use perl instead of shell to get file size Alex Xu (Hello71)
@ 2021-11-20 16:53 94% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-11-20 16:53 UTC (permalink / raw)
To: Michael Forney, Masahiro Yamada, Michal Marek, Nick Desaulniers,
Nick Terrell, Ingo Molnar, Sedat Dilek, Kees Cook, linux-kernel,
linux-kbuild
Cc: Alex Xu (Hello71)
Otherwise, it allocates 2 GB of memory at once. Even though the majority
of this memory is never touched, the default heuristic overcommit
refuses this request if less than 2 GB of RAM+swap is currently
available. This results in "zstd: error 11 : Allocation error : not
enough memory" and the kernel failing to build.
When the size is specified, zstd will reduce the memory request
appropriately. For typical kernel sizes of ~32 MB, the largest mmap
request will be reduced to 512 MB, which will succeed on all but the
smallest devices.
For inputs around this size, --stream-size --no-content-size may
slightly decrease the compressed size, or slightly increase it:
https://github.com/facebook/zstd/issues/2848.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
scripts/Makefile.lib | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index ca901814986a..13d756fbcdc7 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -468,10 +468,10 @@ quiet_cmd_xzmisc = XZMISC $@
# be used because it would require zstd to allocate a 128 MB buffer.
quiet_cmd_zstd = ZSTD $@
- cmd_zstd = { cat $(real-prereqs) | $(ZSTD) -19; $(size_append); } > $@
+ cmd_zstd = { cat $(real-prereqs) | $(ZSTD) --stream-size=$(total_size) --no-content-size -19; $(size_append); } > $@
quiet_cmd_zstd22 = ZSTD22 $@
- cmd_zstd22 = { cat $(real-prereqs) | $(ZSTD) -22 --ultra; $(size_append); } > $@
+ cmd_zstd22 = { cat $(real-prereqs) | $(ZSTD) --stream-size=$(total_size) --no-content-size -22 --ultra; $(size_append); } > $@
# ASM offsets
# ---------------------------------------------------------------------------
--
2.34.0
^ permalink raw reply related [relevance 94%]
* [PATCH 1/2] kbuild: use perl instead of shell to get file size
[not found] <20211120165349.99908-1-alex_y_xu.ref@yahoo.ca>
@ 2021-11-20 16:53 80% ` Alex Xu (Hello71)
2021-11-20 16:53 94% ` [PATCH 2/2] kbuild: pass --stream-size --no-content-size to zstd Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2021-11-20 16:53 UTC (permalink / raw)
To: Michael Forney, Masahiro Yamada, Michal Marek, Nick Desaulniers,
Nick Terrell, Ingo Molnar, Sedat Dilek, Kees Cook, linux-kernel,
linux-kbuild
Cc: Alex Xu (Hello71)
This makes it easier to get the size of multiple files. Perl is already
a requirement for all builds to do header checks, so this is not an
additional dependency.
---
arch/arm/boot/deflate_xip_data.sh | 2 +-
arch/powerpc/boot/wrapper | 2 +-
scripts/Makefile.lib | 9 ++-------
scripts/file-size.pl | 8 ++++++++
scripts/file-size.sh | 4 ----
scripts/link-vmlinux.sh | 4 ++--
6 files changed, 14 insertions(+), 15 deletions(-)
create mode 100755 scripts/file-size.pl
delete mode 100755 scripts/file-size.sh
diff --git a/arch/arm/boot/deflate_xip_data.sh b/arch/arm/boot/deflate_xip_data.sh
index 304495c3c2c5..14cfa2babb93 100755
--- a/arch/arm/boot/deflate_xip_data.sh
+++ b/arch/arm/boot/deflate_xip_data.sh
@@ -43,7 +43,7 @@ data_start=$(($__data_loc - $base_offset))
data_end=$(($_edata_loc - $base_offset))
# Make sure data occupies the last part of the file.
-file_end=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" "$XIPIMAGE")
+file_end=$(${PERL} "${srctree}/scripts/file-size.pl" "$XIPIMAGE")
if [ "$file_end" != "$data_end" ]; then
printf "end of xipImage doesn't match with _edata_loc (%#x vs %#x)\n" \
$(($file_end + $base_offset)) $_edata_loc 1>&2
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 9184eda780fd..9f9ee8613432 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -380,7 +380,7 @@ vmz="$tmpdir/`basename \"$kernel\"`.$ext"
# Calculate the vmlinux.strip size
${CROSS}objcopy $objflags "$kernel" "$vmz.$$"
-strip_size=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" "$vmz.$$")
+strip_size=$(${PERL} "${srctree}/scripts/file-size.pl" "$vmz.$$")
if [ -z "$cacheit" -o ! -f "$vmz$compression" -o "$vmz$compression" -ot "$kernel" ]; then
# recompress the image if we need to
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index d1f865b8c0cb..ca901814986a 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -379,13 +379,8 @@ dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
# Bzip2 and LZMA do not include size in file... so we have to fake that;
# append the size as a 32-bit littleendian number as gzip does.
-size_append = printf $(shell \
-dec_size=0; \
-for F in $(real-prereqs); do \
- fsize=$$($(CONFIG_SHELL) $(srctree)/scripts/file-size.sh $$F); \
- dec_size=$$(expr $$dec_size + $$fsize); \
-done; \
-printf "%08x\n" $$dec_size | \
+total_size = $(shell $(PERL) $(srctree)/scripts/file-size.pl $(real-prereqs))
+size_append = printf $(shell printf "%08x\n" $(total_size) | \
sed 's/\(..\)/\1 /g' | { \
read ch0 ch1 ch2 ch3; \
for ch in $$ch3 $$ch2 $$ch1 $$ch0; do \
diff --git a/scripts/file-size.pl b/scripts/file-size.pl
new file mode 100755
index 000000000000..170bb6d048fa
--- /dev/null
+++ b/scripts/file-size.pl
@@ -0,0 +1,8 @@
+#!/usr/bin/perl -w
+# SPDX-License-Identifier: GPL-2.0
+my $total = 0;
+foreach (@ARGV) {
+ @stat = stat $_ or die "$_: $!";
+ $total += $stat[7];
+}
+print "$total\n";
diff --git a/scripts/file-size.sh b/scripts/file-size.sh
deleted file mode 100755
index 7eb7423416b5..000000000000
--- a/scripts/file-size.sh
+++ /dev/null
@@ -1,4 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0
-set -- $(ls -dn "$1")
-printf '%s\n' "$5"
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 5cdd9bc5c385..c3fa38bd18ab 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -384,8 +384,8 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then
kallsyms_step 2
# step 3
- size1=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" ${kallsymso_prev})
- size2=$(${CONFIG_SHELL} "${srctree}/scripts/file-size.sh" ${kallsymso})
+ size1=$(${PERL} "${srctree}/scripts/file-size.pl" ${kallsymso_prev})
+ size2=$(${PERL} "${srctree}/scripts/file-size.pl" ${kallsymso})
if [ $size1 -ne $size2 ] || [ -n "${KALLSYMS_EXTRA_PASS}" ]; then
kallsyms_step 3
--
2.34.0
^ permalink raw reply related [relevance 80%]
* No HDA sound output with AMD IOMMU on master
[not found] <1636040759.fnw68jgcw1.none.ref@localhost>
@ 2021-11-04 16:01 86% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-11-04 16:01 UTC (permalink / raw)
To: Takashi Iwai, Linux Kernel Mailing List
Hi,
At some point between 86f925fded03 and 5f4e450cd96b, the built-in sound
card on my ASRock B450 Pro4 has stopped working for me. All controls are
unchanged (no new or removed controls, all outputs are unmuted), but
when I try to play sound, I hear a click from the output powering up but
no sound otherwise. While attempting to play sound, the following lines
are output to the kernel log:
[ 15.081961] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac00000 flags=0x0000]
[ 15.081982] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac00040 flags=0x0000]
[ 15.082253] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac00080 flags=0x0000]
[ 15.082581] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac000c0 flags=0x0000]
[ 15.082914] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac00100 flags=0x0000]
[ 15.083247] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac00140 flags=0x0000]
[ 15.083580] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac00180 flags=0x0000]
[ 15.083914] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac001c0 flags=0x0000]
[ 15.084246] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac00200 flags=0x0000]
[ 15.084579] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x14ac00240 flags=0x0000]
[ 749.373925] amd_iommu_report_page_fault: 5917 callbacks suppressed
[ 749.373933] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f2000000 flags=0x0000]
[ 749.373952] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f2000040 flags=0x0000]
[ 749.374248] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f2000080 flags=0x0000]
[ 749.374574] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f20000c0 flags=0x0000]
[ 749.374907] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f2000100 flags=0x0000]
[ 749.375240] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f2000140 flags=0x0000]
[ 749.375572] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f2000180 flags=0x0000]
[ 749.375904] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f20001c0 flags=0x0000]
[ 749.376238] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f2000200 flags=0x0000]
[ 749.376570] snd_hda_intel 0000:0b:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0016 address=0x1f2000240 flags=0x0000]
Note that I first attempted to play audio around 15 seconds in, then
tried again about 730 seconds later.
Adding mem_encrypt=off to the kernel command line does not fix the
issue, but adding mem_encrypt=off amd_iommu=off to the kernel command
line does fix it. I am not using any other IOMMU-related parameters such
as iommu=pt.
I have not yet tested it, but it seems reasonable that this issue is
probably related to the recently pulled "ALSA: memalloc" series of
changes.
Let me know what further information or testing is required. I can do a
full bisection but it is somewhat time-consuming due to the manual
nature of the tests.
Thanks,
Alex.
^ permalink raw reply [relevance 86%]
* [PATCH v3] drm/plane-helper: fix uninitialized variable reference
[not found] <20211007063706.305984-1-alex_y_xu.ref@yahoo.ca>
@ 2021-10-07 6:37 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-10-07 6:37 UTC (permalink / raw)
To: dri-devel, Daniel Vetter
Cc: ville.syrjala, linux-kernel, Simon Ser, Alex Xu (Hello71)
drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_update':
drivers/gpu/drm/drm_plane_helper.c:113:32: error: 'visible' is used uninitialized [-Werror=uninitialized]
113 | struct drm_plane_state plane_state = {
| ^~~~~~~~~~~
drivers/gpu/drm/drm_plane_helper.c:178:14: note: 'visible' was declared here
178 | bool visible;
| ^~~~~~~
cc1: all warnings being treated as errors
visible is an output, not an input. in practice this use might turn out
OK but it's still UB.
Fixes: df86af9133 ("drm/plane-helper: Add drm_plane_helper_check_state()")
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
drivers/gpu/drm/drm_plane_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c
index 5b2d0ca03705..838b32b70bce 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -123,7 +123,6 @@ static int drm_plane_helper_check_update(struct drm_plane *plane,
.crtc_w = drm_rect_width(dst),
.crtc_h = drm_rect_height(dst),
.rotation = rotation,
- .visible = *visible,
};
struct drm_crtc_state crtc_state = {
.crtc = crtc,
--
2.33.0
^ permalink raw reply related [relevance 99%]
* [PATCH v2] drm/plane-helper: fix uninitialized variable reference
@ 2021-09-09 1:32 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-09-09 1:32 UTC (permalink / raw)
To: dri-devel; +Cc: ville.syrjala, linux-kernel, Alex Xu (Hello71)
drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_update':
drivers/gpu/drm/drm_plane_helper.c:113:32: error: 'visible' is used uninitialized [-Werror=uninitialized]
113 | struct drm_plane_state plane_state = {
| ^~~~~~~~~~~
drivers/gpu/drm/drm_plane_helper.c:178:14: note: 'visible' was declared here
178 | bool visible;
| ^~~~~~~
cc1: all warnings being treated as errors
visible is an output, not an input. in practice this use might turn out
OK but it's still UB.
Fixes: df86af9133 ("drm/plane-helper: Add drm_plane_helper_check_state()")
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
drivers/gpu/drm/drm_plane_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c
index 5b2d0ca03705..838b32b70bce 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -123,7 +123,6 @@ static int drm_plane_helper_check_update(struct drm_plane *plane,
.crtc_w = drm_rect_width(dst),
.crtc_h = drm_rect_height(dst),
.rotation = rotation,
- .visible = *visible,
};
struct drm_crtc_state crtc_state = {
.crtc = crtc,
--
2.33.0
^ permalink raw reply related [relevance 99%]
* [PATCH] drm/plane-helper: fix uninitialized variable reference
[not found] <20210907140836.323149-1-alex_y_xu.ref@yahoo.ca>
@ 2021-09-07 14:08 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-09-07 14:08 UTC (permalink / raw)
To: dri-devel; +Cc: ville.syrjala, linux-kernel, Alex Xu (Hello71)
drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_update':
drivers/gpu/drm/drm_plane_helper.c:113:32: error: 'visible' is used uninitialized [-Werror=uninitialized]
113 | struct drm_plane_state plane_state = {
| ^~~~~~~~~~~
drivers/gpu/drm/drm_plane_helper.c:178:14: note: 'visible' was declared here
178 | bool visible;
| ^~~~~~~
cc1: all warnings being treated as errors
visible is an output, not an input. in practice this use might turn out
OK but it's still UB.
Fixes: df86af9133 ("drm/plane-helper: Add drm_plane_helper_check_state()")
---
drivers/gpu/drm/drm_plane_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c
index 5b2d0ca03705..838b32b70bce 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -123,7 +123,6 @@ static int drm_plane_helper_check_update(struct drm_plane *plane,
.crtc_w = drm_rect_width(dst),
.crtc_h = drm_rect_height(dst),
.rotation = rotation,
- .visible = *visible,
};
struct drm_crtc_state crtc_state = {
.crtc = crtc,
--
2.33.0
^ permalink raw reply related [relevance 99%]
* [PATCH] pipe: increase minimum default pipe size to 2 pages
[not found] <20210805144047.13518-1-alex_y_xu.ref@yahoo.ca>
@ 2021-08-05 14:40 88% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-08-05 14:40 UTC (permalink / raw)
To: torvalds
Cc: linux-fsdevel, linux-api, linux-kernel, dhowells, linux, gregkh,
peterz, nicolas.dichtel, raven, christian, Alex Xu (Hello71),
stable
This program always prints 4096 and hangs before the patch, and always
prints 8192 and exits successfully after:
int main() {
int pipefd[2];
for (int i = 0; i < 1025; i++)
if (pipe(pipefd) == -1)
return 1;
size_t bufsz = fcntl(pipefd[1], F_GETPIPE_SZ);
printf("%zd\n", bufsz);
char *buf = calloc(bufsz, 1);
write(pipefd[1], buf, bufsz);
read(pipefd[0], buf, bufsz-1);
write(pipefd[1], buf, 1);
}
Note that you may need to increase your RLIMIT_NOFILE before running the
program.
Fixes: 759c01142a ("pipe: limit the per-user amount of pages allocated in pipes")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/lkml/1628086770.5rn8p04n6j.none@localhost/
Link: https://lore.kernel.org/lkml/1628127094.lxxn016tj7.none@localhost/
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
fs/pipe.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/fs/pipe.c b/fs/pipe.c
index 9ef4231cce61..8e6ef62aeb1c 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -31,6 +31,21 @@
#include "internal.h"
+/*
+ * New pipe buffers will be restricted to this size while the user is exceeding
+ * their pipe buffer quota. The general pipe use case needs at least two
+ * buffers: one for data yet to be read, and one for new data. If this is less
+ * than two, then a write to a non-empty pipe may block even if the pipe is not
+ * full. This can occur with GNU make jobserver or similar uses of pipes as
+ * semaphores: multiple processes may be waiting to write tokens back to the
+ * pipe before reading tokens: https://lore.kernel.org/lkml/1628086770.5rn8p04n6j.none@localhost/.
+ *
+ * Users can reduce their pipe buffers with F_SETPIPE_SZ below this at their
+ * own risk, namely: pipe writes to non-full pipes may block until the pipe is
+ * emptied.
+ */
+#define PIPE_MIN_DEF_BUFFERS 2
+
/*
* The max size that a non-root user is allowed to grow the pipe. Can
* be set by root in /proc/sys/fs/pipe-max-size
@@ -781,8 +796,8 @@ struct pipe_inode_info *alloc_pipe_info(void)
user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
if (too_many_pipe_buffers_soft(user_bufs) && pipe_is_unprivileged_user()) {
- user_bufs = account_pipe_buffers(user, pipe_bufs, 1);
- pipe_bufs = 1;
+ user_bufs = account_pipe_buffers(user, pipe_bufs, PIPE_MIN_DEF_BUFFERS);
+ pipe_bufs = PIPE_MIN_DEF_BUFFERS;
}
if (too_many_pipe_buffers_hard(user_bufs) && pipe_is_unprivileged_user())
--
2.32.0
^ permalink raw reply related [relevance 88%]
* [PATCH] pipe: increase minimum default pipe size to 2 pages
[not found] ` <20210805000435.10833-1-alex_y_xu@yahoo.ca>
@ 2021-08-05 1:33 91% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-08-05 1:33 UTC (permalink / raw)
To: linux-kernel
Before this patch, the following program prints 4096 and hangs.
Afterwards, it prints 8192 and exits successfully. Note that you may
need to increase your RLIMIT_NOFILE before running the program.
int main() {
int pipefd[2];
for (int i = 0; i < 1025; i++)
if (pipe(pipefd) == -1)
return 1;
size_t bufsz = fcntl(pipefd[1], F_GETPIPE_SZ);
printf("%zd\n", bufsz);
char *buf = calloc(bufsz, 1);
write(pipefd[1], buf, bufsz);
read(pipefd[0], buf, bufsz-1);
write(pipefd[1], buf, 1);
}
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
See discussion at https://lore.kernel.org/lkml/1628086770.5rn8p04n6j.none@localhost/.
Patch resend to linux-kernel@vger.kernel.org (typoed email last time).
Sorry if this messes up your mail clients.
fs/pipe.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/fs/pipe.c b/fs/pipe.c
index 9ef4231cce61..8e6ef62aeb1c 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -31,6 +31,21 @@
#include "internal.h"
+/*
+ * New pipe buffers will be restricted to this size while the user is exceeding
+ * their pipe buffer quota. The general pipe use case needs at least two
+ * buffers: one for data yet to be read, and one for new data. If this is less
+ * than two, then a write to a non-empty pipe may block even if the pipe is not
+ * full. This can occur with GNU make jobserver or similar uses of pipes as
+ * semaphores: multiple processes may be waiting to write tokens back to the
+ * pipe before reading tokens: https://lore.kernel.org/lkml/1628086770.5rn8p04n6j.none@localhost/.
+ *
+ * Users can reduce their pipe buffers with F_SETPIPE_SZ below this at their
+ * own risk, namely: pipe writes to non-full pipes may block until the pipe is
+ * emptied.
+ */
+#define PIPE_MIN_DEF_BUFFERS 2
+
/*
* The max size that a non-root user is allowed to grow the pipe. Can
* be set by root in /proc/sys/fs/pipe-max-size
@@ -781,8 +796,8 @@ struct pipe_inode_info *alloc_pipe_info(void)
user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
if (too_many_pipe_buffers_soft(user_bufs) && pipe_is_unprivileged_user()) {
- user_bufs = account_pipe_buffers(user, pipe_bufs, 1);
- pipe_bufs = 1;
+ user_bufs = account_pipe_buffers(user, pipe_bufs, PIPE_MIN_DEF_BUFFERS);
+ pipe_bufs = PIPE_MIN_DEF_BUFFERS;
}
if (too_many_pipe_buffers_hard(user_bufs) && pipe_is_unprivileged_user())
--
2.32.0
^ permalink raw reply related [relevance 91%]
* Re: [REGRESSION?] Simultaneous writes to a reader-less, non-full pipe can hang
@ 2021-08-04 19:48 88% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-08-04 19:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: acrichton, Christian Brauner, David Howells, Greg Kroah-Hartman,
keyrings, Linux API, linux-block, linux-fsdevel,
Linux Kernel Mailing List, Rasmus Villemoes, LSM List, linux-usb,
Nicolas Dichtel, Peter Zijlstra, Ian Kent
Excerpts from Linus Torvalds's message of August 4, 2021 12:31 pm:
> Your program is buggy.
>
> On Wed, Aug 4, 2021 at 8:37 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
>>
>> pipe(pipefd);
>> printf("init buffer: %d\n", fcntl(pipefd[1], F_GETPIPE_SZ));
>> printf("new buffer: %d\n", fcntl(pipefd[1], F_SETPIPE_SZ, 0));
>
> Yeah, what did you expect this to do? You said you want a minimal
> buffer, you get a really small buffer.
>
> Then you try to write multiple messages to the pipe that you just said
> should have a minimum size.
>
> Don't do that then.
>
>> /proc/x/stack shows that the remaining thread is hanging at pipe.c:560.
>> It looks like not only there needs to be space in the pipe, but also
>> slots.
>
> Correct. The fullness of a pipe is not about whether it has the
> possibility of merging more bytes into an existing not-full slot, but
> about whether it has empty slots left.
>
> Part of that is simply the POSIX pipe guarantees - a write of size
> PIPE_BUF or less is guaranteed to be atomic, so it mustn't be split
> among buffers.
>
> So a pipe must not be "writable" unless it has space for at least that
> much (think select/poll, which don't know the size of the write).
>
> The fact that we might be able to reuse a partially filled buffer for
> smaller writes is simply not relevant to that issue.
>
> And yes, we could have different measures of "could write" for
> different writes, but we just don't have or want that complexity.
>
> Please don't mess with F_SETPIPE_SZ unless you have a really good
> reason to do so, and actually understand what you are doing.
>
> Doing a F_SETPIPE_SZ, 0 basically means "I want the mimimum pipe size
> possible". And that one accepts exactly one write at a time.
>
> Of course, the exact semantics are much more complicated than that
> "exactly one write". The pipe write code will optimistically merge
> writes into a previous buffer, which means that depending on the
> pattern of your writes, the exact number of bytes you can write will
> be very different.
>
> But that "merge writes into a previous buffer" only appends to the
> buffer - not _reuse_ it - so when each buffer is one page in size,
> what happens is that you can merge up to 4096 bytes worth of writes,
> but then after that the pipe write will want a new buffer - even if
> the old buffer is now empty because of old reads.
>
> That's why your test program won't block immediately: both writers
> will actually start out happily doing writes into that one buffer that
> is allocated, but at some point that buffer ends, and it wants to
> allocate a new buffer.
>
> But you told it not to allocate more buffers, and the old buffer is
> never completely empty because your readers never read _everythign_,
> so it will hang, waiting for you to empty the one minimal buffer it
> allocated. And that will never happen.
>
> There's a very real reason why we do *not* by default say "pipes can
> only ever use only one buffer".
>
> I don't think this is a regression, but if you have an actual
> application - not a test program - that does crazy things like this
> and used to work (I'm not sure it has ever worked, though), we can
> look into making it work again.
>
> That said, I suspect the way to make it work is to just say "the
> minimum pipe size is two slots" rather than change the "we want at
> least one empty slot". Exactly because of that whole "look, we must
> not consider a pipe that doesn't have a slot writable".
>
> Because clearly people don't understand how subtle F_SETPIPE_SZ is.
> It's not really a "byte count", even though that is how it's
> expressed.
>
> Linus
>
I agree that if this only affects programs which intentionally adjust
the pipe buffer size, then it is not a huge issue. The problem,
admittedly buried very close to the bottom of my email, is that the
kernel will silently provide one-page pipe buffers if the user has
exceeded 16384 (by default) pipe buffer pages allocated. Try this
slightly more complicated program:
#define _GNU_SOURCE
#include <fcntl.h>
#include <pthread.h>
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
static int pipefd[2];
void *thread_start(void *arg) {
char buf[1];
int i;
for (i = 0; i < 1000000; i++) {
read(pipefd[0], buf, sizeof(buf));
if (write(pipefd[1], buf, sizeof(buf)) == -1)
break;
}
printf("done %d\n", i);
return NULL;
}
int main() {
signal(SIGPIPE, SIG_IGN);
// pretend there are a very large number of make processes running
for (int i = 0; i < 1025; i++)
{
pipe(pipefd);
write(pipefd[1], "aa", 2);
}
printf("%d %d\n", pipefd[0], pipefd[1]);
printf("init buffer: %d\n", fcntl(pipefd[1], F_GETPIPE_SZ));
//printf("new buffer: %d\n", fcntl(pipefd[1], F_SETPIPE_SZ, 0));
pthread_t thread1, thread2;
pthread_create(&thread1, NULL, thread_start, NULL);
pthread_create(&thread2, NULL, thread_start, NULL);
sleep(3);
close(pipefd[0]);
close(pipefd[1]);
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);
}
You may need to raise your RLIMIT_NOFILE before running the program.
With default settings (fs.pipe-user-pages-soft = 16384) the init buffer
will be 4096, no mangling required. I think this could be probably be
solved if the kernel instead reduced over-quota pipes to two pages
instead of one page. If someone wants to set a one-page pipe buffer,
then they can suffer the consequences, but the kernel shouldn't silently
hand people that footgun.
Regards,
Alex.
^ permalink raw reply [relevance 88%]
* [REGRESSION?] Simultaneous writes to a reader-less, non-full pipe can hang
[not found] <1628086770.5rn8p04n6j.none.ref@localhost>
@ 2021-08-04 15:37 71% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2021-08-04 15:37 UTC (permalink / raw)
To: linux-kernel, dhowells, acrichton
Cc: torvalds, Rasmus Villemoes, Greg Kroah-Hartman, Peter Zijlstra,
nicolas.dichtel, raven, Christian Brauner, keyrings, linux-usb,
linux-block, linux-security-module, linux-fsdevel, linux-api
Hi,
An issue "Jobserver hangs due to full pipe" was recently reported
against Cargo, the Rust package manager. This was diagnosed as an issue
with pipe writes hanging in certain circumstances.
Specifically, if two or more threads simultaneously write to a pipe, it
is possible for all the writers to hang despite there being significant
space available in the pipe.
I have translated the Rust example to C with some small adjustments:
#define _GNU_SOURCE
#include <fcntl.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
static int pipefd[2];
void *thread_start(void *arg) {
char buf[1];
for (int i = 0; i < 1000000; i++) {
read(pipefd[0], buf, sizeof(buf));
write(pipefd[1], buf, sizeof(buf));
}
puts("done");
return NULL;
}
int main() {
pipe(pipefd);
printf("init buffer: %d\n", fcntl(pipefd[1], F_GETPIPE_SZ));
printf("new buffer: %d\n", fcntl(pipefd[1], F_SETPIPE_SZ, 0));
write(pipefd[1], "aa", 2);
pthread_t thread1, thread2;
pthread_create(&thread1, NULL, thread_start, NULL);
pthread_create(&thread2, NULL, thread_start, NULL);
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);
}
The expected behavior of this program is to print:
init buffer: 65536
new buffer: 4096
done
done
and then exit.
On Linux 5.14-rc4, compiling this program and running it will print the
following about half the time:
init buffer: 65536
new buffer: 4096
done
and then hang. This is unexpected behavior, since the pipe is at most
two bytes full at any given time.
/proc/x/stack shows that the remaining thread is hanging at pipe.c:560.
It looks like not only there needs to be space in the pipe, but also
slots. At pipe.c:1306, a one-page pipe has only one slot. this led me to
test nthreads=2, which also hangs. Checking blame of the pipe_write
comment, it was added in a194dfe, which says, among other things:
> We just abandon the preallocated slot if we get a copy error. Future
> writes may continue it and a future read will eventually recycle it.
This matches the observed behavior: in this case, there are no readers
on the pipe, so the abandoned slot is lost.
In my opinion (as expressed on the issue), the pipe is being misused
here. As explained in the pipe(7) manual page:
> Applications should not rely on a particular capacity: an application
> should be designed so that a reading process consumes data as soon as
> it is available, so that a writing process does not remain blocked.
Despite the misuse, I am reporting this for the following reasons:
1. I am reasonably confident that this is a regression in the kernel,
which has a standard of making reasonable efforts to maintain
backwards compatibility even with broken programs.
2. Even if this is not a regression, it seems like this situation could
be handled somewhat more gracefully. In this case, we are not writing
4095 bytes and then expecting a one-byte write to succeed; the pipe
is actually almost entirely empty.
3. Pipe sizes dynamically shrink in Linux, so despite the fact that this
case is unlikely to occur with two or more slots available, even a
program which does not explicitly allocate a one-page pipe buffer may
wind up with one if the user has 1024 or more pipes already open.
This significantly exacerbates the next point:
4. GNU make's jobserver uses pipes in a similar manner. By my reading of
the paper, it is theoretically possible for an N simultaneous writes
to occur without any readers, where N is the maximum concurrent jobs
permitted.
Consider the following example with make -j2: two compile jobs are to
be performed: one at the top level, and one in a sub-directory. The
top-level make invokes one make and one cc, costing two tokens. The
sub-make invokes one cc with its free token. The pipe is now empty.
Now, suppose the two compilers return at exactly the same time. Both
copies of make will attempt to simultaneously write a token to the
pipe. This does not yet trigger deadlock: at least one write will
always succeed on an empty pipe. Suppose the sub-make's write goes
through. It then exits. The top-level make, however, is still blocked
on its original write, since it was not successfully merged with the
other write. The build is now deadlocked.
I think this does not happen only by a coincidental design decision:
when the sub-make exits, the top-level make receives a SIGCHLD. GNU
make registers a SA_RESTART handler for SIGCHLD, so the write will be
interrupted and restarted. This is only a coincidence, however: the
program does not actually expect writing to the control pipe to ever
block; it could just as well de-register the signal handler while
performing the write and still be fully correct.
Regards,
Alex.
^ permalink raw reply [relevance 71%]
* Re: regression: data corruption with ext4 on LUKS on nvme with torvalds master
@ 2021-05-09 14:47 97% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-05-09 14:47 UTC (permalink / raw)
To: Jens Axboe, bgoncalv, bvanassche, dm-crypt, hch, jaegeuk,
linux-block, linux-ext4, linux-kernel, linux-nvme, ming.lei,
Changheun Lee, yi.zhang
Excerpts from Jens Axboe's message of May 8, 2021 11:51 pm:
> On 5/8/21 8:29 PM, Alex Xu (Hello71) wrote:
>> Excerpts from Alex Xu (Hello71)'s message of May 8, 2021 1:54 pm:
>>> Hi all,
>>>
>>> Using torvalds master, I recently encountered data corruption on my ext4
>>> volume on LUKS on NVMe. Specifically, during heavy writes, the system
>>> partially hangs; SysRq-W shows that processes are blocked in the kernel
>>> on I/O. After forcibly rebooting, chunks of files are replaced with
>>> other, unrelated data. I'm not sure exactly what the data is; some of it
>>> is unknown binary data, but in at least one case, a list of file paths
>>> was inserted into a file, indicating that the data is misdirected after
>>> encryption.
>>>
>>> This issue appears to affect files receiving writes in the temporal
>>> vicinity of the hang, but affects both new and old data: for example, my
>>> shell history file was corrupted up to many months before.
>>>
>>> The drive reports no SMART issues.
>>>
>>> I believe this is a regression in the kernel related to something merged
>>> in the last few days, as it consistently occurs with my most recent
>>> kernel versions, but disappears when reverting to an older kernel.
>>>
>>> I haven't investigated further, such as by bisecting. I hope this is
>>> sufficient information to give someone a lead on the issue, and if it is
>>> a bug, nail it down before anybody else loses data.
>>>
>>> Regards,
>>> Alex.
>>>
>>
>> I found the following test to reproduce a hang, which I guess may be the
>> cause:
>>
>> host$ cd /tmp
>> host$ truncate -s 10G drive
>> host$ qemu-system-x86_64 -drive format=raw,file=drive,if=none,id=drive -device nvme,drive=drive,serial=1 [... more VM setup options]
>> guest$ cryptsetup luksFormat /dev/nvme0n1
>> [accept warning, use any password]
>> guest$ cryptsetup open /dev/nvme0n1
>> [enter password]
>> guest$ mkfs.ext4 /dev/mapper/test
>> [normal output...]
>> Creating journal (16384 blocks): [hangs forever]
>>
>> I bisected this issue to:
>>
>> cd2c7545ae1beac3b6aae033c7f31193b3255946 is the first bad commit
>> commit cd2c7545ae1beac3b6aae033c7f31193b3255946
>> Author: Changheun Lee <nanich.lee@samsung.com>
>> Date: Mon May 3 18:52:03 2021 +0900
>>
>> bio: limit bio max size
>>
>> I didn't try reverting this commit or further reducing the test case.
>> Let me know if you need my kernel config or other information.
>
> If you have time, please do test with that reverted. I'd be anxious to
> get this revert queued up for 5.13-rc1.
>
> --
> Jens Axboe
>
>
I tested reverting it on top of b741596468b010af2846b75f5e75a842ce344a6e
("Merge tag 'riscv-for-linus-5.13-mw1' of
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux"), causing it
to no longer hang. I didn't check if this fixes the data corruption, but
I assume so.
I also tested a 1 GB image (works either way), and a virtio-blk
interface (works either way)
The Show Blocked State from the VM (without revert):
sysrq: Show Blocked State
task:kworker/u2:0 state:D stack: 0 pid: 7 ppid: 2 flags:0x00004000
Workqueue: kcryptd/252:0 kcryptd_crypt
Call Trace:
__schedule+0x1a2/0x4f0
schedule+0x63/0xe0
schedule_timeout+0x6a/0xd0
? lock_timer_base+0x80/0x80
io_schedule_timeout+0x4c/0x70
mempool_alloc+0xfc/0x130
? __wake_up_common_lock+0x90/0x90
kcryptd_crypt+0x291/0x4e0
process_one_work+0x1b1/0x300
worker_thread+0x48/0x3d0
? process_one_work+0x300/0x300
kthread+0x129/0x150
? __kthread_create_worker+0x100/0x100
ret_from_fork+0x22/0x30
task:mkfs.ext4 state:D stack: 0 pid: 979 ppid: 964 flags:0x00004000
Call Trace:
__schedule+0x1a2/0x4f0
? __schedule+0x1aa/0x4f0
schedule+0x63/0xe0
schedule_timeout+0x99/0xd0
io_schedule_timeout+0x4c/0x70
wait_for_completion_io+0x74/0xc0
submit_bio_wait+0x46/0x60
blkdev_issue_zeroout+0x118/0x1f0
blkdev_fallocate+0x125/0x180
vfs_fallocate+0x126/0x2e0
__x64_sys_fallocate+0x37/0x60
do_syscall_64+0x61/0x80
? do_syscall_64+0x6e/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Regards,
Alex.
^ permalink raw reply [relevance 97%]
* Re: regression: data corruption with ext4 on LUKS on nvme with torvalds master
2021-05-08 17:54 97% ` regression: data corruption with ext4 on LUKS on nvme with torvalds master Alex Xu (Hello71)
@ 2021-05-09 2:29 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2021-05-09 2:29 UTC (permalink / raw)
To: linux-kernel, linux-ext4, dm-crypt, linux-nvme, linux-block,
Jens Axboe, Changheun Lee, bvanassche, yi.zhang, ming.lei,
bgoncalv, hch, jaegeuk
Excerpts from Alex Xu (Hello71)'s message of May 8, 2021 1:54 pm:
> Hi all,
>
> Using torvalds master, I recently encountered data corruption on my ext4
> volume on LUKS on NVMe. Specifically, during heavy writes, the system
> partially hangs; SysRq-W shows that processes are blocked in the kernel
> on I/O. After forcibly rebooting, chunks of files are replaced with
> other, unrelated data. I'm not sure exactly what the data is; some of it
> is unknown binary data, but in at least one case, a list of file paths
> was inserted into a file, indicating that the data is misdirected after
> encryption.
>
> This issue appears to affect files receiving writes in the temporal
> vicinity of the hang, but affects both new and old data: for example, my
> shell history file was corrupted up to many months before.
>
> The drive reports no SMART issues.
>
> I believe this is a regression in the kernel related to something merged
> in the last few days, as it consistently occurs with my most recent
> kernel versions, but disappears when reverting to an older kernel.
>
> I haven't investigated further, such as by bisecting. I hope this is
> sufficient information to give someone a lead on the issue, and if it is
> a bug, nail it down before anybody else loses data.
>
> Regards,
> Alex.
>
I found the following test to reproduce a hang, which I guess may be the
cause:
host$ cd /tmp
host$ truncate -s 10G drive
host$ qemu-system-x86_64 -drive format=raw,file=drive,if=none,id=drive -device nvme,drive=drive,serial=1 [... more VM setup options]
guest$ cryptsetup luksFormat /dev/nvme0n1
[accept warning, use any password]
guest$ cryptsetup open /dev/nvme0n1
[enter password]
guest$ mkfs.ext4 /dev/mapper/test
[normal output...]
Creating journal (16384 blocks): [hangs forever]
I bisected this issue to:
cd2c7545ae1beac3b6aae033c7f31193b3255946 is the first bad commit
commit cd2c7545ae1beac3b6aae033c7f31193b3255946
Author: Changheun Lee <nanich.lee@samsung.com>
Date: Mon May 3 18:52:03 2021 +0900
bio: limit bio max size
I didn't try reverting this commit or further reducing the test case.
Let me know if you need my kernel config or other information.
Regards,
Alex.
^ permalink raw reply [relevance 99%]
* regression: data corruption with ext4 on LUKS on nvme with torvalds master
[not found] <1620493841.bxdq8r5haw.none.ref@localhost>
@ 2021-05-08 17:54 97% ` Alex Xu (Hello71)
2021-05-09 2:29 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2021-05-08 17:54 UTC (permalink / raw)
To: linux-kernel, linux-ext4, dm-crypt, linux-nvme, linux-block
Hi all,
Using torvalds master, I recently encountered data corruption on my ext4
volume on LUKS on NVMe. Specifically, during heavy writes, the system
partially hangs; SysRq-W shows that processes are blocked in the kernel
on I/O. After forcibly rebooting, chunks of files are replaced with
other, unrelated data. I'm not sure exactly what the data is; some of it
is unknown binary data, but in at least one case, a list of file paths
was inserted into a file, indicating that the data is misdirected after
encryption.
This issue appears to affect files receiving writes in the temporal
vicinity of the hang, but affects both new and old data: for example, my
shell history file was corrupted up to many months before.
The drive reports no SMART issues.
I believe this is a regression in the kernel related to something merged
in the last few days, as it consistently occurs with my most recent
kernel versions, but disappears when reverting to an older kernel.
I haven't investigated further, such as by bisecting. I hope this is
sufficient information to give someone a lead on the issue, and if it is
a bug, nail it down before anybody else loses data.
Regards,
Alex.
^ permalink raw reply [relevance 97%]
* Re: 5.12-rc1 regression: freezing iou-mgr/wrk failed
@ 2021-03-02 22:13 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-03-02 22:13 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block, linux-kernel
I tried 29be7fc03d ("io_uring: ensure that threads freeze on suspend")
and it seems to work OK. The system suspends fine and no errors are
printed to the kernel log.
I am using Gentoo on the machine in question.
I didn't test the other patches you supplied. Let me know if there's
anything you would like me to test.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* 5.12-rc1 regression: freezing iou-mgr/wrk failed
[not found] <1614646241.av51lk2de4.none.ref@localhost>
@ 2021-03-02 0:57 96% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2021-03-02 0:57 UTC (permalink / raw)
To: linux-kernel, linux-block, Jens Axboe
Hi,
On Linux 5.12-rc1, I am unable to suspend to RAM. The system freezes for
about 40 seconds and then continues operation. The following messages
are printed to the kernel log:
[ 240.650300] PM: suspend entry (deep)
[ 240.650748] Filesystems sync: 0.000 seconds
[ 240.725605] Freezing user space processes ...
[ 260.739483] Freezing of tasks failed after 20.013 seconds (3 tasks refusing to freeze, wq_busy=0):
[ 260.739497] task:iou-mgr-446 state:S stack: 0 pid: 516 ppid: 439 flags:0x00004224
[ 260.739504] Call Trace:
[ 260.739507] ? sysvec_apic_timer_interrupt+0xb/0x81
[ 260.739515] ? pick_next_task_fair+0x197/0x1cde
[ 260.739519] ? sysvec_reschedule_ipi+0x2f/0x6a
[ 260.739522] ? asm_sysvec_reschedule_ipi+0x12/0x20
[ 260.739525] ? __schedule+0x57/0x6d6
[ 260.739529] ? del_timer_sync+0xb9/0x115
[ 260.739533] ? schedule+0x63/0xd5
[ 260.739536] ? schedule_timeout+0x219/0x356
[ 260.739540] ? __next_timer_interrupt+0xf1/0xf1
[ 260.739544] ? io_wq_manager+0x73/0xb1
[ 260.739549] ? io_wq_create+0x262/0x262
[ 260.739553] ? ret_from_fork+0x22/0x30
[ 260.739557] task:iou-mgr-517 state:S stack: 0 pid: 522 ppid: 439 flags:0x00004224
[ 260.739561] Call Trace:
[ 260.739563] ? sysvec_apic_timer_interrupt+0xb/0x81
[ 260.739566] ? pick_next_task_fair+0x16f/0x1cde
[ 260.739569] ? sysvec_apic_timer_interrupt+0xb/0x81
[ 260.739571] ? asm_sysvec_apic_timer_interrupt+0x12/0x20
[ 260.739574] ? __schedule+0x5b7/0x6d6
[ 260.739578] ? del_timer_sync+0x70/0x115
[ 260.739581] ? schedule_timeout+0x211/0x356
[ 260.739585] ? __next_timer_interrupt+0xf1/0xf1
[ 260.739588] ? io_wq_check_workers+0x15/0x11f
[ 260.739592] ? io_wq_manager+0x69/0xb1
[ 260.739596] ? io_wq_create+0x262/0x262
[ 260.739600] ? ret_from_fork+0x22/0x30
[ 260.739603] task:iou-wrk-517 state:S stack: 0 pid: 523 ppid: 439 flags:0x00004224
[ 260.739607] Call Trace:
[ 260.739609] ? __schedule+0x5b7/0x6d6
[ 260.739614] ? schedule+0x63/0xd5
[ 260.739617] ? schedule_timeout+0x219/0x356
[ 260.739621] ? __next_timer_interrupt+0xf1/0xf1
[ 260.739624] ? task_thread.isra.0+0x148/0x3af
[ 260.739628] ? task_thread_unbound+0xa/0xa
[ 260.739632] ? task_thread_bound+0x7/0x7
[ 260.739636] ? ret_from_fork+0x22/0x30
[ 260.739647] OOM killer enabled.
[ 260.739648] Restarting tasks ... done.
[ 260.740077] PM: suspend exit
and then a set of similar messages except with s2idle instead of deep.
Reverting 5695e51619 ("Merge tag 'io_uring-worker.v3-2021-02-25' of
git://git.kernel.dk/linux-block") appears to resolve the issue. I have
not yet bisected further. Let me know which troubleshooting steps I
should perform next.
Thanks,
Alex.
^ permalink raw reply [relevance 96%]
* Re: [PATCH] proc_sysctl: clamp sizes using table->maxlen
@ 2021-02-27 14:41 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-02-27 14:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Alexey Dobriyan, Kees Cook, linux-fsdevel, linux-kernel,
Luis Chamberlain, Andrey Ignatov, Al Viro, Iurii Zaikin
Excerpts from Christoph Hellwig's message of February 16, 2021 3:47 am:
> How do these maxlen = 0 entries even survive the sysctl_check_table
> check?
maxlen!=0 is only checked for "default" handlers, e.g. proc_dostring,
proc_dointvec. it is not checked for non-default handlers, because some
of them use fixed lengths.
my patch is not correct though because some drivers neither set proper
maxlen nor use memcpy themselves; instead, they construct a ctl_table on
the stack and call proc_*.
> Please split this into one patch each each subsystem that sets maxlen
> to 0 and the actual change to proc_sysctl.c.
I will do this with a new patch version once I figure out a way to
comprehensively fix all the drivers setting bogus values for maxlen
(sometimes maxlen=0 is valid if only blank writes are permitted, and
some drivers set random values which have no relation to the actual read
size).
Thank you for the review.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] proc_sysctl: clamp sizes using table->maxlen
2021-02-15 14:53 71% ` [PATCH] proc_sysctl: clamp sizes using table->maxlen Alex Xu (Hello71)
@ 2021-02-16 0:49 99% ` Alex Xu (Hello71)
1 sibling, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-02-16 0:49 UTC (permalink / raw)
To: linux-kernel, Luis Chamberlain, Kees Cook, Christoph Hellwig,
Andrey Ignatov, Al Viro, Iurii Zaikin, Alexey Dobriyan,
linux-fsdevel
Excerpts from Alex Xu (Hello71)'s message of February 15, 2021 9:53 am:
> This issue was discussed at [0] and following, and the solution was to
> clamp the size at KMALLOC_MAX_LEN. However, KMALLOC_MAX_LEN is a maximum
> allocation, and may be difficult to allocate in low memory conditions.
>
> Since maxlen is already exposed, we can allocate approximately the right
> amount directly, fixing up those drivers which set a bogus maxlen. These
> drivers were located based on those which had copy_x_user replaced in
> 32927393dc1c, on the basis that other drivers either use builtin proc_*
> handlers, or do not access the data pointer. The latter is OK because
> maxlen only needs to be an upper limit.
>
> [0] https://lore.kernel.org/lkml/1fc7ce08-26a7-59ff-e580-4e6c22554752@oracle.com/
>
> Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
> Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Yeah, no, this doesn't work. A bunch of functions call proc_* but don't
set maxlen, and it's annoying to check this statically. Also causes
weird failures elsewhere. May need to think of a better solution here
(kvzalloc?).
^ permalink raw reply [relevance 99%]
* [PATCH] proc_sysctl: clamp sizes using table->maxlen
[not found] <20210215145305.283064-1-alex_y_xu.ref@yahoo.ca>
@ 2021-02-15 14:53 71% ` Alex Xu (Hello71)
2021-02-16 0:49 99% ` Alex Xu (Hello71)
0 siblings, 2 replies; 89+ results
From: Alex Xu (Hello71) @ 2021-02-15 14:53 UTC (permalink / raw)
To: linux-kernel, Luis Chamberlain, Kees Cook, Christoph Hellwig,
Andrey Ignatov, Al Viro, Iurii Zaikin, Alexey Dobriyan,
linux-fsdevel
Cc: Alex Xu (Hello71)
This issue was discussed at [0] and following, and the solution was to
clamp the size at KMALLOC_MAX_LEN. However, KMALLOC_MAX_LEN is a maximum
allocation, and may be difficult to allocate in low memory conditions.
Since maxlen is already exposed, we can allocate approximately the right
amount directly, fixing up those drivers which set a bogus maxlen. These
drivers were located based on those which had copy_x_user replaced in
32927393dc1c, on the basis that other drivers either use builtin proc_*
handlers, or do not access the data pointer. The latter is OK because
maxlen only needs to be an upper limit.
[0] https://lore.kernel.org/lkml/1fc7ce08-26a7-59ff-e580-4e6c22554752@oracle.com/
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
drivers/parport/procfs.c | 20 ++++++++++----------
fs/proc/proc_sysctl.c | 13 ++++++++-----
include/linux/sysctl.h | 2 +-
net/core/sysctl_net_core.c | 1 +
net/decnet/sysctl_net_decnet.c | 4 ++--
net/sunrpc/xprtrdma/svc_rdma.c | 18 +++++++++---------
6 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/drivers/parport/procfs.c b/drivers/parport/procfs.c
index d740eba3c099..a2eeae73f9fa 100644
--- a/drivers/parport/procfs.c
+++ b/drivers/parport/procfs.c
@@ -280,28 +280,28 @@ static const struct parport_sysctl_table parport_sysctl_template = {
{
.procname = "base-addr",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 20,
.mode = 0444,
.proc_handler = do_hardware_base_addr
},
{
.procname = "irq",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 20,
.mode = 0444,
.proc_handler = do_hardware_irq
},
{
.procname = "dma",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 20,
.mode = 0444,
.proc_handler = do_hardware_dma
},
{
.procname = "modes",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 40,
.mode = 0444,
.proc_handler = do_hardware_modes
},
@@ -310,35 +310,35 @@ static const struct parport_sysctl_table parport_sysctl_template = {
{
.procname = "autoprobe",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
{
.procname = "autoprobe0",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
{
.procname = "autoprobe1",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
{
.procname = "autoprobe2",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
{
.procname = "autoprobe3",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
@@ -349,7 +349,7 @@ static const struct parport_sysctl_table parport_sysctl_template = {
{
.procname = "active",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_active_device
},
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index d2018f70d1fa..4a54d3cc174b 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -547,7 +547,7 @@ static ssize_t proc_sys_call_handler(struct kiocb *iocb, struct iov_iter *iter,
struct inode *inode = file_inode(iocb->ki_filp);
struct ctl_table_header *head = grab_header(inode);
struct ctl_table *table = PROC_I(inode)->sysctl_entry;
- size_t count = iov_iter_count(iter);
+ size_t count = min(table->maxlen, iov_iter_count(iter));
char *kbuf;
ssize_t error;
@@ -567,10 +567,6 @@ static ssize_t proc_sys_call_handler(struct kiocb *iocb, struct iov_iter *iter,
if (!table->proc_handler)
goto out;
- /* don't even try if the size is too large */
- error = -ENOMEM;
- if (count >= KMALLOC_MAX_SIZE)
- goto out;
kbuf = kzalloc(count + 1, GFP_KERNEL);
if (!kbuf)
goto out;
@@ -1138,6 +1134,13 @@ static int sysctl_check_table(const char *path, struct ctl_table *table)
if ((table->mode & (S_IRUGO|S_IWUGO)) != table->mode)
err |= sysctl_err(path, table, "bogus .mode 0%o",
table->mode);
+
+ if (table->maxlen >= KMALLOC_MAX_SIZE)
+ err |= sysctl_err(path, table, "maxlen %ld too big",
+ table->maxlen);
+
+ if ((table->mode & S_IRUGO) && !table->maxlen)
+ err |= sysctl_err(path, table, "cannot read maxlen=0");
}
return err;
}
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 51298a4f4623..78a1d36767f9 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -112,7 +112,7 @@ static inline void *proc_sys_poll_event(struct ctl_table_poll *poll)
struct ctl_table {
const char *procname; /* Text ID for /proc/sys, or zero */
void *data;
- int maxlen;
+ size_t maxlen;
umode_t mode;
struct ctl_table *child; /* Deprecated */
proc_handler *proc_handler; /* Callback for text formatting */
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index d86d8d11cfe4..c51a2e7e0dfb 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -470,6 +470,7 @@ static struct ctl_table net_core_table[] = {
#ifdef CONFIG_NET_FLOW_LIMIT
{
.procname = "flow_limit_cpu_bitmap",
+ .maxlen = 128,
.mode = 0644,
.proc_handler = flow_limit_cpu_sysctl
},
diff --git a/net/decnet/sysctl_net_decnet.c b/net/decnet/sysctl_net_decnet.c
index 67b5ab2657b7..2ca2ac42c40c 100644
--- a/net/decnet/sysctl_net_decnet.c
+++ b/net/decnet/sysctl_net_decnet.c
@@ -239,14 +239,14 @@ static int dn_def_dev_handler(struct ctl_table *table, int write,
static struct ctl_table dn_table[] = {
{
.procname = "node_address",
- .maxlen = 7,
+ .maxlen = DN_ASCBUF_LEN,
.mode = 0644,
.proc_handler = dn_node_address_handler,
},
{
.procname = "node_name",
.data = node_name,
- .maxlen = 7,
+ .maxlen = sizeof(node_name),
.mode = 0644,
.proc_handler = proc_dostring,
},
diff --git a/net/sunrpc/xprtrdma/svc_rdma.c b/net/sunrpc/xprtrdma/svc_rdma.c
index 526da5d4710b..f326ba6825f2 100644
--- a/net/sunrpc/xprtrdma/svc_rdma.c
+++ b/net/sunrpc/xprtrdma/svc_rdma.c
@@ -143,63 +143,63 @@ static struct ctl_table svcrdma_parm_table[] = {
{
.procname = "rdma_stat_read",
.data = &rdma_stat_read,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
{
.procname = "rdma_stat_recv",
.data = &rdma_stat_recv,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
{
.procname = "rdma_stat_write",
.data = &rdma_stat_write,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
{
.procname = "rdma_stat_sq_starve",
.data = &rdma_stat_sq_starve,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
{
.procname = "rdma_stat_rq_starve",
.data = &rdma_stat_rq_starve,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
{
.procname = "rdma_stat_rq_poll",
.data = &rdma_stat_rq_poll,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
{
.procname = "rdma_stat_rq_prod",
.data = &rdma_stat_rq_prod,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
{
.procname = "rdma_stat_sq_poll",
.data = &rdma_stat_sq_poll,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
{
.procname = "rdma_stat_sq_prod",
.data = &rdma_stat_sq_prod,
- .maxlen = sizeof(atomic_t),
+ .maxlen = 32,
.mode = 0644,
.proc_handler = read_reset_stat,
},
--
2.30.1
^ permalink raw reply related [relevance 71%]
* Re: [RFC PATCH] treewide: remove bzip2 compression support
2020-12-15 19:03 17% ` [RFC PATCH] treewide: remove bzip2 compression support Alex Xu (Hello71)
@ 2020-12-15 23:39 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-12-15 23:39 UTC (permalink / raw)
To: linux-kernel, linux-kbuild, linux-arm-kernel, linux-aspeed,
linux-mips, openrisc, linux-parisc, linuxppc-dev, linux-riscv,
linux-s390, linux-sh, linux-xtensa
Excerpts from Alex Xu (Hello71)'s message of December 15, 2020 2:03 pm:
> bzip2 is either slower or larger than every other supported algorithm,
> according to benchmarks at [0]. It is far slower to decompress than any
> other algorithm, and still larger than lzma, xz, and zstd.
>
> [0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/
>
> Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Upon further research, I found that bzip2 removal was already
implemented as part of zstd addition, but were apparently abandoned in
an effort to get zstd in. I will check those patches and try sending
those instead. Thanks to all reviewers for comments on this patch.
^ permalink raw reply [relevance 99%]
* [RFC PATCH] treewide: remove bzip2 compression support
[not found] <20201215190315.8681-1-alex_y_xu.ref@yahoo.ca>
@ 2020-12-15 19:03 17% ` Alex Xu (Hello71)
2020-12-15 23:39 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-12-15 19:03 UTC (permalink / raw)
To: linux-kernel, linux-kbuild, linux-arm-kernel, linux-aspeed,
linux-mips, openrisc, linux-parisc, linuxppc-dev, linux-riscv,
linux-s390, linux-sh, linux-xtensa
Cc: torvalds, Alex Xu (Hello71)
bzip2 is either slower or larger than every other supported algorithm,
according to benchmarks at [0]. It is far slower to decompress than any
other algorithm, and still larger than lzma, xz, and zstd.
[0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
Documentation/x86/boot.rst | 8 +-
arch/arm/configs/aspeed_g4_defconfig | 1 -
arch/arm/configs/aspeed_g5_defconfig | 1 -
arch/arm/configs/ezx_defconfig | 1 -
arch/arm/configs/imote2_defconfig | 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/vf610m4_defconfig | 1 -
arch/arm64/boot/Makefile | 5 +-
arch/mips/Kconfig | 1 -
arch/mips/Makefile | 3 -
arch/mips/boot/Makefile | 14 -
arch/mips/boot/compressed/Makefile | 1 -
arch/mips/boot/compressed/decompress.c | 4 -
arch/mips/configs/ath25_defconfig | 1 -
arch/mips/configs/pistachio_defconfig | 1 -
arch/openrisc/configs/simple_smp_defconfig | 1 -
arch/parisc/Kconfig | 1 -
arch/parisc/boot/compressed/Makefile | 5 +-
arch/parisc/boot/compressed/misc.c | 4 -
arch/powerpc/configs/skiroot_defconfig | 1 -
arch/riscv/boot/Makefile | 3 -
arch/riscv/configs/nommu_k210_defconfig | 1 -
arch/riscv/configs/nommu_virt_defconfig | 1 -
arch/s390/Kconfig | 1 -
arch/s390/boot/compressed/Makefile | 5 +-
arch/s390/boot/compressed/decompressor.c | 8 -
arch/sh/Kconfig | 1 -
arch/sh/Makefile | 3 +-
arch/sh/boot/Makefile | 11 +-
arch/sh/boot/compressed/Makefile | 5 +-
arch/sh/boot/compressed/misc.c | 8 -
arch/sh/configs/sdk7786_defconfig | 1 -
arch/x86/Kconfig | 1 -
arch/x86/boot/compressed/Makefile | 9 +-
arch/x86/boot/compressed/misc.c | 4 -
arch/x86/include/asm/boot.h | 4 +-
arch/xtensa/configs/cadence_csp_defconfig | 1 -
arch/xtensa/configs/nommu_kc705_defconfig | 1 -
include/linux/decompress/bunzip2.h | 11 -
init/Kconfig | 22 +-
init/do_mounts_rd.c | 1 -
kernel/configs/tiny.config | 1 -
lib/Kconfig | 3 -
lib/Makefile | 1 -
lib/decompress.c | 5 -
lib/decompress_bunzip2.c | 756 ---------------------
scripts/Makefile.lib | 8 +-
scripts/Makefile.package | 1 -
scripts/package/buildtar | 2 +-
usr/Kconfig | 26 +-
usr/Makefile | 3 +-
51 files changed, 22 insertions(+), 942 deletions(-)
delete mode 100644 include/linux/decompress/bunzip2.h
delete mode 100644 lib/decompress_bunzip2.c
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index abb9fc164657..741eebc10140 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -781,10 +781,10 @@ Protocol: 2.08+
The payload may be compressed. The format of both the compressed and
uncompressed data should be determined using the standard magic
numbers. The currently supported compression formats are gzip
- (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
- (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number
- 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is
- currently always ELF (magic number 7F 45 4C 46).
+ (magic numbers 1F 8B or 1F 9E), LZMA (magic number 5D 00), XZ (magic
+ number FD 37), LZ4 (magic number 02 21) and ZSTD (magic number 28 B5).
+ Formerly supported was bzip2 (magic number 42 5A). The uncompressed
+ payload is currently always ELF (magic number 7F 45 4C 46).
============ ==============
Field name: payload_length
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index 58d293b63581..f2f5dcd0e59c 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_UID16 is not set
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index 047975eccefb..5d045b2902d6 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_UID16 is not set
diff --git a/arch/arm/configs/ezx_defconfig b/arch/arm/configs/ezx_defconfig
index 81665b7abf83..422592786e01 100644
--- a/arch/arm/configs/ezx_defconfig
+++ b/arch/arm/configs/ezx_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_EXPERT=y
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arm/configs/imote2_defconfig b/arch/arm/configs/imote2_defconfig
index ae15a2a33802..04e23ec01af6 100644
--- a/arch/arm/configs/imote2_defconfig
+++ b/arch/arm/configs/imote2_defconfig
@@ -3,7 +3,6 @@ CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_EXPERT=y
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arm/configs/lpc18xx_defconfig b/arch/arm/configs/lpc18xx_defconfig
index be882ea0eee4..12e69dfa18dc 100644
--- a/arch/arm/configs/lpc18xx_defconfig
+++ b/arch/arm/configs/lpc18xx_defconfig
@@ -1,7 +1,6 @@
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/arm/configs/vf610m4_defconfig b/arch/arm/configs/vf610m4_defconfig
index a89f035c3b01..02c7acc7cd09 100644
--- a/arch/arm/configs/vf610m4_defconfig
+++ b/arch/arm/configs/vf610m4_defconfig
@@ -1,6 +1,5 @@
CONFIG_NAMESPACES=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZ4 is not set
diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index cd3414898d10..d3207561c078 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -16,14 +16,11 @@
OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
-targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo
+targets := Image Image.gz Image.lz4 Image.lzma Image.lzo
$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
-$(obj)/Image.bz2: $(obj)/Image FORCE
- $(call if_changed,bzip2)
-
$(obj)/Image.gz: $(obj)/Image FORCE
$(call if_changed,gzip)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 6b762bebff33..d25d900294bb 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1880,7 +1880,6 @@ endif # CPU_LOONGSON2F
config SYS_SUPPORTS_ZBOOT
bool
select HAVE_KERNEL_GZIP
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 0d0f29d662c9..2dd53daf6fbb 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -328,14 +328,12 @@ boot-y += vmlinux.srec
ifeq ($(shell expr $(load-y) \< 0xffffffff80000000 2> /dev/null), 0)
boot-y += uImage
boot-y += uImage.bin
-boot-y += uImage.bz2
boot-y += uImage.gz
boot-y += uImage.lzma
boot-y += uImage.lzo
endif
boot-y += vmlinux.itb
boot-y += vmlinux.gz.itb
-boot-y += vmlinux.bz2.itb
boot-y += vmlinux.lzma.itb
boot-y += vmlinux.lzo.itb
@@ -429,7 +427,6 @@ define archhelp
echo ' vmlinuz.srec - SREC zboot image'
echo ' uImage - U-Boot image'
echo ' uImage.bin - U-Boot image (uncompressed)'
- echo ' uImage.bz2 - U-Boot image (bz2)'
echo ' uImage.gz - U-Boot image (gzip)'
echo ' uImage.lzma - U-Boot image (lzma)'
echo ' uImage.lzo - U-Boot image (lzo)'
diff --git a/arch/mips/boot/Makefile b/arch/mips/boot/Makefile
index a3da2c5d63c2..78f70e3576cd 100644
--- a/arch/mips/boot/Makefile
+++ b/arch/mips/boot/Makefile
@@ -24,7 +24,6 @@ strip-flags := $(addprefix --remove-section=,$(drop-sections))
hostprogs := elf2ecoff
suffix-y := bin
-suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_GZIP) := gz
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_LZO) := lzo
@@ -54,14 +53,10 @@ UIMAGE_ENTRYADDR = $(VMLINUX_ENTRY_ADDRESS)
# Compressed vmlinux images
#
-extra-y += vmlinux.bin.bz2
extra-y += vmlinux.bin.gz
extra-y += vmlinux.bin.lzma
extra-y += vmlinux.bin.lzo
-$(obj)/vmlinux.bin.bz2: $(obj)/vmlinux.bin FORCE
- $(call if_changed,bzip2)
-
$(obj)/vmlinux.bin.gz: $(obj)/vmlinux.bin FORCE
$(call if_changed,gzip)
@@ -77,7 +72,6 @@ $(obj)/vmlinux.bin.lzo: $(obj)/vmlinux.bin FORCE
targets += uImage
targets += uImage.bin
-targets += uImage.bz2
targets += uImage.gz
targets += uImage.lzma
targets += uImage.lzo
@@ -85,9 +79,6 @@ targets += uImage.lzo
$(obj)/uImage.bin: $(obj)/vmlinux.bin FORCE
$(call if_changed,uimage,none)
-$(obj)/uImage.bz2: $(obj)/vmlinux.bin.bz2 FORCE
- $(call if_changed,uimage,bzip2)
-
$(obj)/uImage.gz: $(obj)/vmlinux.bin.gz FORCE
$(call if_changed,uimage,gzip)
@@ -122,7 +113,6 @@ $(obj)/vmlinux.its.S: $(addprefix $(srctree)/arch/mips/$(PLATFORM)/,$(ITS_INPUTS
targets += vmlinux.its
targets += vmlinux.gz.its
-targets += vmlinux.bz2.its
targets += vmlinux.lzma.its
targets += vmlinux.lzo.its
@@ -142,9 +132,6 @@ $(obj)/vmlinux.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
$(obj)/vmlinux.gz.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
$(call if_changed,cpp_its_S,gzip,vmlinux.bin.gz)
-$(obj)/vmlinux.bz2.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
- $(call if_changed,cpp_its_S,bzip2,vmlinux.bin.bz2)
-
$(obj)/vmlinux.lzma.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
$(call if_changed,cpp_its_S,lzma,vmlinux.bin.lzma)
@@ -153,7 +140,6 @@ $(obj)/vmlinux.lzo.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
targets += vmlinux.itb
targets += vmlinux.gz.itb
-targets += vmlinux.bz2.itb
targets += vmlinux.lzma.itb
targets += vmlinux.lzo.itb
diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile
index d66511825fe1..8fbd72b466e6 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -70,7 +70,6 @@ $(obj)/vmlinux.bin: $(KBUILD_IMAGE) FORCE
$(call if_changed,objcopy)
tool_$(CONFIG_KERNEL_GZIP) = gzip
-tool_$(CONFIG_KERNEL_BZIP2) = bzip2
tool_$(CONFIG_KERNEL_LZ4) = lz4
tool_$(CONFIG_KERNEL_LZMA) = lzma
tool_$(CONFIG_KERNEL_LZO) = lzo
diff --git a/arch/mips/boot/compressed/decompress.c b/arch/mips/boot/compressed/decompress.c
index c61c641674e6..ac7ccab2bb52 100644
--- a/arch/mips/boot/compressed/decompress.c
+++ b/arch/mips/boot/compressed/decompress.c
@@ -52,10 +52,6 @@ void error(char *x)
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZ4
#include "../../../../lib/decompress_unlz4.c"
#endif
diff --git a/arch/mips/configs/ath25_defconfig b/arch/mips/configs/ath25_defconfig
index 7143441f5476..1e12d3018c15 100644
--- a/arch/mips/configs/ath25_defconfig
+++ b/arch/mips/configs/ath25_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYSVIPC=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
diff --git a/arch/mips/configs/pistachio_defconfig b/arch/mips/configs/pistachio_defconfig
index b9adf15ebbec..ad31439400c6 100644
--- a/arch/mips/configs/pistachio_defconfig
+++ b/arch/mips/configs/pistachio_defconfig
@@ -14,7 +14,6 @@ CONFIG_CGROUP_FREEZER=y
CONFIG_NAMESPACES=y
CONFIG_USER_NS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
diff --git a/arch/openrisc/configs/simple_smp_defconfig b/arch/openrisc/configs/simple_smp_defconfig
index ff49d868e040..74a5fe83aa17 100644
--- a/arch/openrisc/configs/simple_smp_defconfig
+++ b/arch/openrisc/configs/simple_smp_defconfig
@@ -3,7 +3,6 @@ CONFIG_NO_HZ=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index b234e8154cbd..4eee43c1e7d9 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -22,7 +22,6 @@ config PARISC
select BUILDTIME_TABLE_SORT
select HAVE_PCI
select HAVE_PERF_EVENTS
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
diff --git a/arch/parisc/boot/compressed/Makefile b/arch/parisc/boot/compressed/Makefile
index dff453687530..2c9403ebb96a 100644
--- a/arch/parisc/boot/compressed/Makefile
+++ b/arch/parisc/boot/compressed/Makefile
@@ -9,7 +9,7 @@ KCOV_INSTRUMENT := n
GCOV_PROFILE := n
UBSAN_SANITIZE := n
-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2
+targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz
targets += vmlinux.bin.xz vmlinux.bin.lzma vmlinux.bin.lzo vmlinux.bin.lz4
targets += misc.o piggy.o sizes.h head.o real2.o firmware.o
targets += real2.S firmware.c
@@ -64,7 +64,6 @@ $(obj)/vmlinux.bin: vmlinux FORCE
vmlinux.bin.all-y := $(obj)/vmlinux.bin
suffix-$(CONFIG_KERNEL_GZIP) := gz
-suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZ4) := lz4
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_LZO) := lzo
@@ -72,8 +71,6 @@ suffix-$(CONFIG_KERNEL_XZ) := xz
$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y)
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y)
- $(call if_changed,bzip2)
$(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y)
$(call if_changed,lz4)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y)
diff --git a/arch/parisc/boot/compressed/misc.c b/arch/parisc/boot/compressed/misc.c
index 2d395998f524..247a0b138cb1 100644
--- a/arch/parisc/boot/compressed/misc.c
+++ b/arch/parisc/boot/compressed/misc.c
@@ -42,10 +42,6 @@ static unsigned long free_mem_end_ptr;
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZ4
#include "../../../../lib/decompress_unlz4.c"
#endif
diff --git a/arch/powerpc/configs/skiroot_defconfig b/arch/powerpc/configs/skiroot_defconfig
index b806a5d3a695..28139c0294e9 100644
--- a/arch/powerpc/configs/skiroot_defconfig
+++ b/arch/powerpc/configs/skiroot_defconfig
@@ -11,7 +11,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
diff --git a/arch/riscv/boot/Makefile b/arch/riscv/boot/Makefile
index c59fca695f9d..944ea5165225 100644
--- a/arch/riscv/boot/Makefile
+++ b/arch/riscv/boot/Makefile
@@ -31,9 +31,6 @@ $(obj)/loader.o: $(src)/loader.S $(obj)/Image
$(obj)/loader: $(obj)/loader.o $(obj)/Image $(obj)/loader.lds FORCE
$(Q)$(LD) -T $(obj)/loader.lds -o $@ $(obj)/loader.o
-$(obj)/Image.bz2: $(obj)/Image FORCE
- $(call if_changed,bzip2)
-
$(obj)/Image.lz4: $(obj)/Image FORCE
$(call if_changed,lz4)
diff --git a/arch/riscv/configs/nommu_k210_defconfig b/arch/riscv/configs/nommu_k210_defconfig
index cd1df62b13c7..a71b615fa1b1 100644
--- a/arch/riscv/configs/nommu_k210_defconfig
+++ b/arch/riscv/configs/nommu_k210_defconfig
@@ -3,7 +3,6 @@ CONFIG_LOG_BUF_SHIFT=15
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_FORCE=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/riscv/configs/nommu_virt_defconfig b/arch/riscv/configs/nommu_virt_defconfig
index e046a0babde4..fb72b5d6c0ec 100644
--- a/arch/riscv/configs/nommu_virt_defconfig
+++ b/arch/riscv/configs/nommu_virt_defconfig
@@ -2,7 +2,6 @@
CONFIG_LOG_BUF_SHIFT=16
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index a60cc523d810..4bdfe1d64836 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -153,7 +153,6 @@ config S390
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GCC_PLUGINS
select HAVE_GENERIC_VDSO
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
diff --git a/arch/s390/boot/compressed/Makefile b/arch/s390/boot/compressed/Makefile
index de18dab518bb..db11dc6264aa 100644
--- a/arch/s390/boot/compressed/Makefile
+++ b/arch/s390/boot/compressed/Makefile
@@ -12,7 +12,7 @@ KASAN_SANITIZE := n
obj-y := $(if $(CONFIG_KERNEL_UNCOMPRESSED),,decompressor.o) info.o
obj-all := $(obj-y) piggy.o syms.o
-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2
+targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz
targets += vmlinux.bin.xz vmlinux.bin.lzma vmlinux.bin.lzo vmlinux.bin.lz4
targets += info.bin syms.bin vmlinux.syms $(obj-all)
@@ -58,7 +58,6 @@ $(obj)/vmlinux.bin: vmlinux FORCE
vmlinux.bin.all-y := $(obj)/vmlinux.bin
suffix-$(CONFIG_KERNEL_GZIP) := .gz
-suffix-$(CONFIG_KERNEL_BZIP2) := .bz2
suffix-$(CONFIG_KERNEL_LZ4) := .lz4
suffix-$(CONFIG_KERNEL_LZMA) := .lzma
suffix-$(CONFIG_KERNEL_LZO) := .lzo
@@ -66,8 +65,6 @@ suffix-$(CONFIG_KERNEL_XZ) := .xz
$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
- $(call if_changed,bzip2)
$(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lz4)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
diff --git a/arch/s390/boot/compressed/decompressor.c b/arch/s390/boot/compressed/decompressor.c
index 3061b11c4d27..87395950cc69 100644
--- a/arch/s390/boot/compressed/decompressor.c
+++ b/arch/s390/boot/compressed/decompressor.c
@@ -28,11 +28,7 @@ extern char _end[];
extern unsigned char _compressed_start[];
extern unsigned char _compressed_end[];
-#ifdef CONFIG_HAVE_KERNEL_BZIP2
-#define BOOT_HEAP_SIZE 0x400000
-#else
#define BOOT_HEAP_SIZE 0x10000
-#endif
static unsigned long free_mem_ptr = (unsigned long) _end;
static unsigned long free_mem_end_ptr = (unsigned long) _end + BOOT_HEAP_SIZE;
@@ -41,10 +37,6 @@ static unsigned long free_mem_end_ptr = (unsigned long) _end + BOOT_HEAP_SIZE;
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZ4
#include "../../../../lib/decompress_unlz4.c"
#endif
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 159da4ed578f..df4113457afd 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -42,7 +42,6 @@ config SUPERH
select HAVE_HW_BREAKPOINT
select HAVE_IDE if HAS_IOPORT_MAP
select HAVE_IOREMAP_PROT if MMU && !X2TLB
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index 2faebfd72eca..6fdaa8d2d835 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -189,7 +189,7 @@ endif
libs-y := arch/sh/lib/ $(libs-y)
-BOOT_TARGETS = uImage uImage.bz2 uImage.gz uImage.lzma uImage.xz uImage.lzo \
+BOOT_TARGETS = uImage uImage.gz uImage.lzma uImage.xz uImage.lzo \
uImage.srec uImage.bin zImage vmlinux.bin vmlinux.srec \
romImage
PHONY += $(BOOT_TARGETS)
@@ -220,7 +220,6 @@ define archhelp
@echo ' uImage.srec - Create an S-record for U-Boot'
@echo ' uImage.bin - Kernel-only image for U-Boot (bin)'
@echo '* uImage.gz - Kernel-only image for U-Boot (gzip)'
- @echo ' uImage.bz2 - Kernel-only image for U-Boot (bzip2)'
@echo ' uImage.lzma - Kernel-only image for U-Boot (lzma)'
@echo ' uImage.xz - Kernel-only image for U-Boot (xz)'
@echo ' uImage.lzo - Kernel-only image for U-Boot (lzo)'
diff --git a/arch/sh/boot/Makefile b/arch/sh/boot/Makefile
index 58592dfa5cb6..8f742b8285a5 100644
--- a/arch/sh/boot/Makefile
+++ b/arch/sh/boot/Makefile
@@ -21,14 +21,13 @@ CONFIG_PHYSICAL_START ?= $(CONFIG_MEMORY_START)
suffix-y := bin
suffix-$(CONFIG_KERNEL_GZIP) := gz
-suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_XZ) := xz
suffix-$(CONFIG_KERNEL_LZO) := lzo
targets := zImage vmlinux.srec romImage uImage uImage.srec uImage.gz \
- uImage.bz2 uImage.lzma uImage.xz uImage.lzo uImage.bin
-extra-y += vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \
+ uImage.lzma uImage.xz uImage.lzo uImage.bin
+extra-y += vmlinux.bin vmlinux.bin.gz vmlinux.bin.lzma \
vmlinux.bin.xz vmlinux.bin.lzo
subdir- := compressed romimage
@@ -68,9 +67,6 @@ $(obj)/vmlinux.bin: vmlinux FORCE
$(obj)/vmlinux.bin.gz: $(obj)/vmlinux.bin FORCE
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(obj)/vmlinux.bin FORCE
- $(call if_changed,bzip2)
-
$(obj)/vmlinux.bin.lzma: $(obj)/vmlinux.bin FORCE
$(call if_changed,lzma)
@@ -80,9 +76,6 @@ $(obj)/vmlinux.bin.xz: $(obj)/vmlinux.bin FORCE
$(obj)/vmlinux.bin.lzo: $(obj)/vmlinux.bin FORCE
$(call if_changed,lzo)
-$(obj)/uImage.bz2: $(obj)/vmlinux.bin.bz2
- $(call if_changed,uimage,bzip2)
-
$(obj)/uImage.gz: $(obj)/vmlinux.bin.gz
$(call if_changed,uimage,gzip)
diff --git a/arch/sh/boot/compressed/Makefile b/arch/sh/boot/compressed/Makefile
index 589d2d8a573d..641b16826383 100644
--- a/arch/sh/boot/compressed/Makefile
+++ b/arch/sh/boot/compressed/Makefile
@@ -6,8 +6,7 @@
#
targets := vmlinux vmlinux.bin vmlinux.bin.gz \
- vmlinux.bin.bz2 vmlinux.bin.lzma \
- vmlinux.bin.xz vmlinux.bin.lzo \
+ vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo \
head_32.o misc.o piggy.o
OBJECTS = $(obj)/head_32.o $(obj)/misc.o $(obj)/cache.o
@@ -57,8 +56,6 @@ vmlinux.bin.all-y := $(obj)/vmlinux.bin
$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
- $(call if_changed,bzip2)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lzma)
$(obj)/vmlinux.bin.xz: $(vmlinux.bin.all-y) FORCE
diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c
index a03b6680a9d9..bf0d4446f7a6 100644
--- a/arch/sh/boot/compressed/misc.c
+++ b/arch/sh/boot/compressed/misc.c
@@ -44,20 +44,12 @@ extern int _end;
static unsigned long free_mem_ptr;
static unsigned long free_mem_end_ptr;
-#ifdef CONFIG_HAVE_KERNEL_BZIP2
-#define HEAP_SIZE 0x400000
-#else
#define HEAP_SIZE 0x10000
-#endif
#ifdef CONFIG_KERNEL_GZIP
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZMA
#include "../../../../lib/decompress_unlzma.c"
#endif
diff --git a/arch/sh/configs/sdk7786_defconfig b/arch/sh/configs/sdk7786_defconfig
index 61bec46ebd66..486e8762cc44 100644
--- a/arch/sh/configs/sdk7786_defconfig
+++ b/arch/sh/configs/sdk7786_defconfig
@@ -29,7 +29,6 @@ CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_LZO=y
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eeb87fce9c6f..177a84c2f822 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -186,7 +186,6 @@ config X86
select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_IRQ_TIME_ACCOUNTING
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 40b8fd375d52..868c61b6d692 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -7,13 +7,13 @@
# vmlinuz is:
# decompression code (*.o)
# asm globals (piggy.S), including:
-# vmlinux.bin.(gz|bz2|lzma|...)
+# vmlinux.bin.(gz|lzma|...)
#
# vmlinux.bin is:
# vmlinux stripped of debugging and comments
# vmlinux.bin.all is:
# vmlinux.bin + vmlinux.relocs
-# vmlinux.bin.(gz|bz2|lzma|...) is:
+# vmlinux.bin.(gz|lzma|...) is:
# (see scripts/Makefile.lib size_append)
# compressed vmlinux.bin.all + u32 size of vmlinux.bin.all
@@ -25,7 +25,7 @@ OBJECT_FILES_NON_STANDARD := y
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
-targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \
+targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.lzma \
vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4 vmlinux.bin.zst
KBUILD_CFLAGS := -m$(BITS) -O2
@@ -120,8 +120,6 @@ vmlinux.bin.all-$(CONFIG_X86_NEED_RELOCS) += $(obj)/vmlinux.relocs
$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
- $(call if_changed,bzip2)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lzma)
$(obj)/vmlinux.bin.xz: $(vmlinux.bin.all-y) FORCE
@@ -134,7 +132,6 @@ $(obj)/vmlinux.bin.zst: $(vmlinux.bin.all-y) FORCE
$(call if_changed,zstd22)
suffix-$(CONFIG_KERNEL_GZIP) := gz
-suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_XZ) := xz
suffix-$(CONFIG_KERNEL_LZO) := lzo
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 267e7f93050e..b8ef48b240cd 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -55,10 +55,6 @@ static int lines, cols;
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZMA
#include "../../../../lib/decompress_unlzma.c"
#endif
diff --git a/arch/x86/include/asm/boot.h b/arch/x86/include/asm/boot.h
index 9191280d9ea3..460243445b13 100644
--- a/arch/x86/include/asm/boot.h
+++ b/arch/x86/include/asm/boot.h
@@ -24,9 +24,7 @@
# error "Invalid value for CONFIG_PHYSICAL_ALIGN"
#endif
-#if defined(CONFIG_KERNEL_BZIP2)
-# define BOOT_HEAP_SIZE 0x400000
-#elif defined(CONFIG_KERNEL_ZSTD)
+#if defined(CONFIG_KERNEL_ZSTD)
/*
* Zstd needs to allocate the ZSTD_DCtx in order to decompress the kernel.
* The ZSTD_DCtx is ~160KB, so set the heap size to 192KB because it is a
diff --git a/arch/xtensa/configs/cadence_csp_defconfig b/arch/xtensa/configs/cadence_csp_defconfig
index fc240737b14d..fb069d8a7c83 100644
--- a/arch/xtensa/configs/cadence_csp_defconfig
+++ b/arch/xtensa/configs/cadence_csp_defconfig
@@ -15,7 +15,6 @@ CONFIG_SCHED_AUTOGROUP=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="$$KERNEL_INITRAMFS_SOURCE"
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/xtensa/configs/nommu_kc705_defconfig b/arch/xtensa/configs/nommu_kc705_defconfig
index 88b2e222d4bf..b78b404f4f8f 100644
--- a/arch/xtensa/configs/nommu_kc705_defconfig
+++ b/arch/xtensa/configs/nommu_kc705_defconfig
@@ -15,7 +15,6 @@ CONFIG_NAMESPACES=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/include/linux/decompress/bunzip2.h b/include/linux/decompress/bunzip2.h
deleted file mode 100644
index 5860163942a4..000000000000
--- a/include/linux/decompress/bunzip2.h
+++ /dev/null
@@ -1,11 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef DECOMPRESS_BUNZIP2_H
-#define DECOMPRESS_BUNZIP2_H
-
-int bunzip2(unsigned char *inbuf, long len,
- long (*fill)(void*, unsigned long),
- long (*flush)(void*, unsigned long),
- unsigned char *output,
- long *pos,
- void(*error)(char *x));
-#endif
diff --git a/init/Kconfig b/init/Kconfig
index b77c60f8b963..fdb50763ec50 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -180,9 +180,6 @@ config BUILD_SALT
config HAVE_KERNEL_GZIP
bool
-config HAVE_KERNEL_BZIP2
- bool
-
config HAVE_KERNEL_LZMA
bool
@@ -204,7 +201,7 @@ config HAVE_KERNEL_UNCOMPRESSED
choice
prompt "Kernel compression mode"
default KERNEL_GZIP
- depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4 || HAVE_KERNEL_ZSTD || HAVE_KERNEL_UNCOMPRESSED
+ depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_LZMA || HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4 || HAVE_KERNEL_ZSTD || HAVE_KERNEL_UNCOMPRESSED
help
The linux kernel is a kind of self-extracting executable.
Several compression algorithms are available, which differ
@@ -212,11 +209,6 @@ choice
Compression speed is only relevant when building a kernel.
Decompression speed is relevant at each boot.
- If you have any problems with bzip2 or lzma compressed
- kernels, mail me (Alain Knaff) <alain@knaff.lu>. (An older
- version of this functionality (bzip2 only), for 2.4, was
- supplied by Christian Ludwig)
-
High compression options are mostly useful for users, who
are low on disk space (embedded systems), but for whom ram
size matters less.
@@ -230,22 +222,12 @@ config KERNEL_GZIP
The old and tried gzip compression. It provides a good balance
between compression ratio and decompression speed.
-config KERNEL_BZIP2
- bool "Bzip2"
- depends on HAVE_KERNEL_BZIP2
- help
- Its compression ratio and speed is intermediate.
- Decompression speed is slowest among the choices. The kernel
- size is about 10% smaller with bzip2, in comparison to gzip.
- Bzip2 uses a large amount of memory. For modern kernels you
- will need at least 8MB RAM or more for booting.
-
config KERNEL_LZMA
bool "LZMA"
depends on HAVE_KERNEL_LZMA
help
This compression algorithm's ratio is best. Decompression speed
- is between gzip and bzip2. Compression is slowest.
+ is similar to XZ. Compression is slowest.
The kernel size is about 33% smaller with LZMA in comparison to gzip.
config KERNEL_XZ
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index ac021ae6e6fa..5b7114743c9a 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -48,7 +48,6 @@ static int __init crd_load(decompress_fn deco);
* cramfs
* squashfs
* gzip
- * bzip2
* lzma
* xz
* lzo
diff --git a/kernel/configs/tiny.config b/kernel/configs/tiny.config
index 8a44b93da0f3..2ca3fb830ca7 100644
--- a/kernel/configs/tiny.config
+++ b/kernel/configs/tiny.config
@@ -1,7 +1,6 @@
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_KERNEL_GZIP is not set
-# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
diff --git a/lib/Kconfig b/lib/Kconfig
index b46a9fd122c8..1d33e5e70f0e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -324,9 +324,6 @@ config DECOMPRESS_GZIP
select ZLIB_INFLATE
tristate
-config DECOMPRESS_BZIP2
- tristate
-
config DECOMPRESS_LZMA
tristate
diff --git a/lib/Makefile b/lib/Makefile
index d415fc7067c5..c50f3f0111c2 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -193,7 +193,6 @@ obj-$(CONFIG_XZ_DEC) += xz/
obj-$(CONFIG_RAID6_PQ) += raid6/
lib-$(CONFIG_DECOMPRESS_GZIP) += decompress_inflate.o
-lib-$(CONFIG_DECOMPRESS_BZIP2) += decompress_bunzip2.o
lib-$(CONFIG_DECOMPRESS_LZMA) += decompress_unlzma.o
lib-$(CONFIG_DECOMPRESS_XZ) += decompress_unxz.o
lib-$(CONFIG_DECOMPRESS_LZO) += decompress_unlzo.o
diff --git a/lib/decompress.c b/lib/decompress.c
index ab3fc90ffc64..7e272d7fd27a 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -7,7 +7,6 @@
#include <linux/decompress/generic.h>
-#include <linux/decompress/bunzip2.h>
#include <linux/decompress/unlzma.h>
#include <linux/decompress/unxz.h>
#include <linux/decompress/inflate.h>
@@ -23,9 +22,6 @@
#ifndef CONFIG_DECOMPRESS_GZIP
# define gunzip NULL
#endif
-#ifndef CONFIG_DECOMPRESS_BZIP2
-# define bunzip2 NULL
-#endif
#ifndef CONFIG_DECOMPRESS_LZMA
# define unlzma NULL
#endif
@@ -51,7 +47,6 @@ struct compress_format {
static const struct compress_format compressed_formats[] __initconst = {
{ {0x1f, 0x8b}, "gzip", gunzip },
{ {0x1f, 0x9e}, "gzip", gunzip },
- { {0x42, 0x5a}, "bzip2", bunzip2 },
{ {0x5d, 0x00}, "lzma", unlzma },
{ {0xfd, 0x37}, "xz", unxz },
{ {0x89, 0x4c}, "lzo", unlzo },
diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
deleted file mode 100644
index c72c865032fa..000000000000
--- a/lib/decompress_bunzip2.c
+++ /dev/null
@@ -1,756 +0,0 @@
-/* Small bzip2 deflate implementation, by Rob Landley (rob@landley.net).
-
- Based on bzip2 decompression code by Julian R Seward (jseward@acm.org),
- which also acknowledges contributions by Mike Burrows, David Wheeler,
- Peter Fenwick, Alistair Moffat, Radford Neal, Ian H. Witten,
- Robert Sedgewick, and Jon L. Bentley.
-
- This code is licensed under the LGPLv2:
- LGPL (http://www.gnu.org/copyleft/lgpl.html
-*/
-
-/*
- Size and speed optimizations by Manuel Novoa III (mjn3@codepoet.org).
-
- More efficient reading of Huffman codes, a streamlined read_bunzip()
- function, and various other tweaks. In (limited) tests, approximately
- 20% faster than bzcat on x86 and about 10% faster on arm.
-
- Note that about 2/3 of the time is spent in read_unzip() reversing
- the Burrows-Wheeler transformation. Much of that time is delay
- resulting from cache misses.
-
- I would ask that anyone benefiting from this work, especially those
- using it in commercial products, consider making a donation to my local
- non-profit hospice organization in the name of the woman I loved, who
- passed away Feb. 12, 2003.
-
- In memory of Toni W. Hagan
-
- Hospice of Acadiana, Inc.
- 2600 Johnston St., Suite 200
- Lafayette, LA 70503-3240
-
- Phone (337) 232-1234 or 1-800-738-2226
- Fax (337) 232-1297
-
- https://www.hospiceacadiana.com/
-
- Manuel
- */
-
-/*
- Made it fit for running in Linux Kernel by Alain Knaff (alain@knaff.lu)
-*/
-
-
-#ifdef STATIC
-#define PREBOOT
-#else
-#include <linux/decompress/bunzip2.h>
-#endif /* STATIC */
-
-#include <linux/decompress/mm.h>
-#include <linux/crc32poly.h>
-
-#ifndef INT_MAX
-#define INT_MAX 0x7fffffff
-#endif
-
-/* Constants for Huffman coding */
-#define MAX_GROUPS 6
-#define GROUP_SIZE 50 /* 64 would have been more efficient */
-#define MAX_HUFCODE_BITS 20 /* Longest Huffman code allowed */
-#define MAX_SYMBOLS 258 /* 256 literals + RUNA + RUNB */
-#define SYMBOL_RUNA 0
-#define SYMBOL_RUNB 1
-
-/* Status return values */
-#define RETVAL_OK 0
-#define RETVAL_LAST_BLOCK (-1)
-#define RETVAL_NOT_BZIP_DATA (-2)
-#define RETVAL_UNEXPECTED_INPUT_EOF (-3)
-#define RETVAL_UNEXPECTED_OUTPUT_EOF (-4)
-#define RETVAL_DATA_ERROR (-5)
-#define RETVAL_OUT_OF_MEMORY (-6)
-#define RETVAL_OBSOLETE_INPUT (-7)
-
-/* Other housekeeping constants */
-#define BZIP2_IOBUF_SIZE 4096
-
-/* This is what we know about each Huffman coding group */
-struct group_data {
- /* We have an extra slot at the end of limit[] for a sentinal value. */
- int limit[MAX_HUFCODE_BITS+1];
- int base[MAX_HUFCODE_BITS];
- int permute[MAX_SYMBOLS];
- int minLen, maxLen;
-};
-
-/* Structure holding all the housekeeping data, including IO buffers and
- memory that persists between calls to bunzip */
-struct bunzip_data {
- /* State for interrupting output loop */
- int writeCopies, writePos, writeRunCountdown, writeCount, writeCurrent;
- /* I/O tracking data (file handles, buffers, positions, etc.) */
- long (*fill)(void*, unsigned long);
- long inbufCount, inbufPos /*, outbufPos*/;
- unsigned char *inbuf /*,*outbuf*/;
- unsigned int inbufBitCount, inbufBits;
- /* The CRC values stored in the block header and calculated from the
- data */
- unsigned int crc32Table[256], headerCRC, totalCRC, writeCRC;
- /* Intermediate buffer and its size (in bytes) */
- unsigned int *dbuf, dbufSize;
- /* These things are a bit too big to go on the stack */
- unsigned char selectors[32768]; /* nSelectors = 15 bits */
- struct group_data groups[MAX_GROUPS]; /* Huffman coding tables */
- int io_error; /* non-zero if we have IO error */
- int byteCount[256];
- unsigned char symToByte[256], mtfSymbol[256];
-};
-
-
-/* Return the next nnn bits of input. All reads from the compressed input
- are done through this function. All reads are big endian */
-static unsigned int INIT get_bits(struct bunzip_data *bd, char bits_wanted)
-{
- unsigned int bits = 0;
-
- /* If we need to get more data from the byte buffer, do so.
- (Loop getting one byte at a time to enforce endianness and avoid
- unaligned access.) */
- while (bd->inbufBitCount < bits_wanted) {
- /* If we need to read more data from file into byte buffer, do
- so */
- if (bd->inbufPos == bd->inbufCount) {
- if (bd->io_error)
- return 0;
- bd->inbufCount = bd->fill(bd->inbuf, BZIP2_IOBUF_SIZE);
- if (bd->inbufCount <= 0) {
- bd->io_error = RETVAL_UNEXPECTED_INPUT_EOF;
- return 0;
- }
- bd->inbufPos = 0;
- }
- /* Avoid 32-bit overflow (dump bit buffer to top of output) */
- if (bd->inbufBitCount >= 24) {
- bits = bd->inbufBits&((1 << bd->inbufBitCount)-1);
- bits_wanted -= bd->inbufBitCount;
- bits <<= bits_wanted;
- bd->inbufBitCount = 0;
- }
- /* Grab next 8 bits of input from buffer. */
- bd->inbufBits = (bd->inbufBits << 8)|bd->inbuf[bd->inbufPos++];
- bd->inbufBitCount += 8;
- }
- /* Calculate result */
- bd->inbufBitCount -= bits_wanted;
- bits |= (bd->inbufBits >> bd->inbufBitCount)&((1 << bits_wanted)-1);
-
- return bits;
-}
-
-/* Unpacks the next block and sets up for the inverse burrows-wheeler step. */
-
-static int INIT get_next_block(struct bunzip_data *bd)
-{
- struct group_data *hufGroup = NULL;
- int *base = NULL;
- int *limit = NULL;
- int dbufCount, nextSym, dbufSize, groupCount, selector,
- i, j, k, t, runPos, symCount, symTotal, nSelectors, *byteCount;
- unsigned char uc, *symToByte, *mtfSymbol, *selectors;
- unsigned int *dbuf, origPtr;
-
- dbuf = bd->dbuf;
- dbufSize = bd->dbufSize;
- selectors = bd->selectors;
- byteCount = bd->byteCount;
- symToByte = bd->symToByte;
- mtfSymbol = bd->mtfSymbol;
-
- /* Read in header signature and CRC, then validate signature.
- (last block signature means CRC is for whole file, return now) */
- i = get_bits(bd, 24);
- j = get_bits(bd, 24);
- bd->headerCRC = get_bits(bd, 32);
- if ((i == 0x177245) && (j == 0x385090))
- return RETVAL_LAST_BLOCK;
- if ((i != 0x314159) || (j != 0x265359))
- return RETVAL_NOT_BZIP_DATA;
- /* We can add support for blockRandomised if anybody complains.
- There was some code for this in busybox 1.0.0-pre3, but nobody ever
- noticed that it didn't actually work. */
- if (get_bits(bd, 1))
- return RETVAL_OBSOLETE_INPUT;
- origPtr = get_bits(bd, 24);
- if (origPtr >= dbufSize)
- return RETVAL_DATA_ERROR;
- /* mapping table: if some byte values are never used (encoding things
- like ascii text), the compression code removes the gaps to have fewer
- symbols to deal with, and writes a sparse bitfield indicating which
- values were present. We make a translation table to convert the
- symbols back to the corresponding bytes. */
- t = get_bits(bd, 16);
- symTotal = 0;
- for (i = 0; i < 16; i++) {
- if (t&(1 << (15-i))) {
- k = get_bits(bd, 16);
- for (j = 0; j < 16; j++)
- if (k&(1 << (15-j)))
- symToByte[symTotal++] = (16*i)+j;
- }
- }
- /* How many different Huffman coding groups does this block use? */
- groupCount = get_bits(bd, 3);
- if (groupCount < 2 || groupCount > MAX_GROUPS)
- return RETVAL_DATA_ERROR;
- /* nSelectors: Every GROUP_SIZE many symbols we select a new
- Huffman coding group. Read in the group selector list,
- which is stored as MTF encoded bit runs. (MTF = Move To
- Front, as each value is used it's moved to the start of the
- list.) */
- nSelectors = get_bits(bd, 15);
- if (!nSelectors)
- return RETVAL_DATA_ERROR;
- for (i = 0; i < groupCount; i++)
- mtfSymbol[i] = i;
- for (i = 0; i < nSelectors; i++) {
- /* Get next value */
- for (j = 0; get_bits(bd, 1); j++)
- if (j >= groupCount)
- return RETVAL_DATA_ERROR;
- /* Decode MTF to get the next selector */
- uc = mtfSymbol[j];
- for (; j; j--)
- mtfSymbol[j] = mtfSymbol[j-1];
- mtfSymbol[0] = selectors[i] = uc;
- }
- /* Read the Huffman coding tables for each group, which code
- for symTotal literal symbols, plus two run symbols (RUNA,
- RUNB) */
- symCount = symTotal+2;
- for (j = 0; j < groupCount; j++) {
- unsigned char length[MAX_SYMBOLS], temp[MAX_HUFCODE_BITS+1];
- int minLen, maxLen, pp;
- /* Read Huffman code lengths for each symbol. They're
- stored in a way similar to mtf; record a starting
- value for the first symbol, and an offset from the
- previous value for everys symbol after that.
- (Subtracting 1 before the loop and then adding it
- back at the end is an optimization that makes the
- test inside the loop simpler: symbol length 0
- becomes negative, so an unsigned inequality catches
- it.) */
- t = get_bits(bd, 5)-1;
- for (i = 0; i < symCount; i++) {
- for (;;) {
- if (((unsigned)t) > (MAX_HUFCODE_BITS-1))
- return RETVAL_DATA_ERROR;
-
- /* If first bit is 0, stop. Else
- second bit indicates whether to
- increment or decrement the value.
- Optimization: grab 2 bits and unget
- the second if the first was 0. */
-
- k = get_bits(bd, 2);
- if (k < 2) {
- bd->inbufBitCount++;
- break;
- }
- /* Add one if second bit 1, else
- * subtract 1. Avoids if/else */
- t += (((k+1)&2)-1);
- }
- /* Correct for the initial -1, to get the
- * final symbol length */
- length[i] = t+1;
- }
- /* Find largest and smallest lengths in this group */
- minLen = maxLen = length[0];
-
- for (i = 1; i < symCount; i++) {
- if (length[i] > maxLen)
- maxLen = length[i];
- else if (length[i] < minLen)
- minLen = length[i];
- }
-
- /* Calculate permute[], base[], and limit[] tables from
- * length[].
- *
- * permute[] is the lookup table for converting
- * Huffman coded symbols into decoded symbols. base[]
- * is the amount to subtract from the value of a
- * Huffman symbol of a given length when using
- * permute[].
- *
- * limit[] indicates the largest numerical value a
- * symbol with a given number of bits can have. This
- * is how the Huffman codes can vary in length: each
- * code with a value > limit[length] needs another
- * bit.
- */
- hufGroup = bd->groups+j;
- hufGroup->minLen = minLen;
- hufGroup->maxLen = maxLen;
- /* Note that minLen can't be smaller than 1, so we
- adjust the base and limit array pointers so we're
- not always wasting the first entry. We do this
- again when using them (during symbol decoding).*/
- base = hufGroup->base-1;
- limit = hufGroup->limit-1;
- /* Calculate permute[]. Concurrently, initialize
- * temp[] and limit[]. */
- pp = 0;
- for (i = minLen; i <= maxLen; i++) {
- temp[i] = limit[i] = 0;
- for (t = 0; t < symCount; t++)
- if (length[t] == i)
- hufGroup->permute[pp++] = t;
- }
- /* Count symbols coded for at each bit length */
- for (i = 0; i < symCount; i++)
- temp[length[i]]++;
- /* Calculate limit[] (the largest symbol-coding value
- *at each bit length, which is (previous limit <<
- *1)+symbols at this level), and base[] (number of
- *symbols to ignore at each bit length, which is limit
- *minus the cumulative count of symbols coded for
- *already). */
- pp = t = 0;
- for (i = minLen; i < maxLen; i++) {
- pp += temp[i];
- /* We read the largest possible symbol size
- and then unget bits after determining how
- many we need, and those extra bits could be
- set to anything. (They're noise from
- future symbols.) At each level we're
- really only interested in the first few
- bits, so here we set all the trailing
- to-be-ignored bits to 1 so they don't
- affect the value > limit[length]
- comparison. */
- limit[i] = (pp << (maxLen - i)) - 1;
- pp <<= 1;
- base[i+1] = pp-(t += temp[i]);
- }
- limit[maxLen+1] = INT_MAX; /* Sentinal value for
- * reading next sym. */
- limit[maxLen] = pp+temp[maxLen]-1;
- base[minLen] = 0;
- }
- /* We've finished reading and digesting the block header. Now
- read this block's Huffman coded symbols from the file and
- undo the Huffman coding and run length encoding, saving the
- result into dbuf[dbufCount++] = uc */
-
- /* Initialize symbol occurrence counters and symbol Move To
- * Front table */
- for (i = 0; i < 256; i++) {
- byteCount[i] = 0;
- mtfSymbol[i] = (unsigned char)i;
- }
- /* Loop through compressed symbols. */
- runPos = dbufCount = symCount = selector = 0;
- for (;;) {
- /* Determine which Huffman coding group to use. */
- if (!(symCount--)) {
- symCount = GROUP_SIZE-1;
- if (selector >= nSelectors)
- return RETVAL_DATA_ERROR;
- hufGroup = bd->groups+selectors[selector++];
- base = hufGroup->base-1;
- limit = hufGroup->limit-1;
- }
- /* Read next Huffman-coded symbol. */
- /* Note: It is far cheaper to read maxLen bits and
- back up than it is to read minLen bits and then an
- additional bit at a time, testing as we go.
- Because there is a trailing last block (with file
- CRC), there is no danger of the overread causing an
- unexpected EOF for a valid compressed file. As a
- further optimization, we do the read inline
- (falling back to a call to get_bits if the buffer
- runs dry). The following (up to got_huff_bits:) is
- equivalent to j = get_bits(bd, hufGroup->maxLen);
- */
- while (bd->inbufBitCount < hufGroup->maxLen) {
- if (bd->inbufPos == bd->inbufCount) {
- j = get_bits(bd, hufGroup->maxLen);
- goto got_huff_bits;
- }
- bd->inbufBits =
- (bd->inbufBits << 8)|bd->inbuf[bd->inbufPos++];
- bd->inbufBitCount += 8;
- };
- bd->inbufBitCount -= hufGroup->maxLen;
- j = (bd->inbufBits >> bd->inbufBitCount)&
- ((1 << hufGroup->maxLen)-1);
-got_huff_bits:
- /* Figure how many bits are in next symbol and
- * unget extras */
- i = hufGroup->minLen;
- while (j > limit[i])
- ++i;
- bd->inbufBitCount += (hufGroup->maxLen - i);
- /* Huffman decode value to get nextSym (with bounds checking) */
- if ((i > hufGroup->maxLen)
- || (((unsigned)(j = (j>>(hufGroup->maxLen-i))-base[i]))
- >= MAX_SYMBOLS))
- return RETVAL_DATA_ERROR;
- nextSym = hufGroup->permute[j];
- /* We have now decoded the symbol, which indicates
- either a new literal byte, or a repeated run of the
- most recent literal byte. First, check if nextSym
- indicates a repeated run, and if so loop collecting
- how many times to repeat the last literal. */
- if (((unsigned)nextSym) <= SYMBOL_RUNB) { /* RUNA or RUNB */
- /* If this is the start of a new run, zero out
- * counter */
- if (!runPos) {
- runPos = 1;
- t = 0;
- }
- /* Neat trick that saves 1 symbol: instead of
- or-ing 0 or 1 at each bit position, add 1
- or 2 instead. For example, 1011 is 1 << 0
- + 1 << 1 + 2 << 2. 1010 is 2 << 0 + 2 << 1
- + 1 << 2. You can make any bit pattern
- that way using 1 less symbol than the basic
- or 0/1 method (except all bits 0, which
- would use no symbols, but a run of length 0
- doesn't mean anything in this context).
- Thus space is saved. */
- t += (runPos << nextSym);
- /* +runPos if RUNA; +2*runPos if RUNB */
-
- runPos <<= 1;
- continue;
- }
- /* When we hit the first non-run symbol after a run,
- we now know how many times to repeat the last
- literal, so append that many copies to our buffer
- of decoded symbols (dbuf) now. (The last literal
- used is the one at the head of the mtfSymbol
- array.) */
- if (runPos) {
- runPos = 0;
- if (dbufCount+t >= dbufSize)
- return RETVAL_DATA_ERROR;
-
- uc = symToByte[mtfSymbol[0]];
- byteCount[uc] += t;
- while (t--)
- dbuf[dbufCount++] = uc;
- }
- /* Is this the terminating symbol? */
- if (nextSym > symTotal)
- break;
- /* At this point, nextSym indicates a new literal
- character. Subtract one to get the position in the
- MTF array at which this literal is currently to be
- found. (Note that the result can't be -1 or 0,
- because 0 and 1 are RUNA and RUNB. But another
- instance of the first symbol in the mtf array,
- position 0, would have been handled as part of a
- run above. Therefore 1 unused mtf position minus 2
- non-literal nextSym values equals -1.) */
- if (dbufCount >= dbufSize)
- return RETVAL_DATA_ERROR;
- i = nextSym - 1;
- uc = mtfSymbol[i];
- /* Adjust the MTF array. Since we typically expect to
- *move only a small number of symbols, and are bound
- *by 256 in any case, using memmove here would
- *typically be bigger and slower due to function call
- *overhead and other assorted setup costs. */
- do {
- mtfSymbol[i] = mtfSymbol[i-1];
- } while (--i);
- mtfSymbol[0] = uc;
- uc = symToByte[uc];
- /* We have our literal byte. Save it into dbuf. */
- byteCount[uc]++;
- dbuf[dbufCount++] = (unsigned int)uc;
- }
- /* At this point, we've read all the Huffman-coded symbols
- (and repeated runs) for this block from the input stream,
- and decoded them into the intermediate buffer. There are
- dbufCount many decoded bytes in dbuf[]. Now undo the
- Burrows-Wheeler transform on dbuf. See
- http://dogma.net/markn/articles/bwt/bwt.htm
- */
- /* Turn byteCount into cumulative occurrence counts of 0 to n-1. */
- j = 0;
- for (i = 0; i < 256; i++) {
- k = j+byteCount[i];
- byteCount[i] = j;
- j = k;
- }
- /* Figure out what order dbuf would be in if we sorted it. */
- for (i = 0; i < dbufCount; i++) {
- uc = (unsigned char)(dbuf[i] & 0xff);
- dbuf[byteCount[uc]] |= (i << 8);
- byteCount[uc]++;
- }
- /* Decode first byte by hand to initialize "previous" byte.
- Note that it doesn't get output, and if the first three
- characters are identical it doesn't qualify as a run (hence
- writeRunCountdown = 5). */
- if (dbufCount) {
- if (origPtr >= dbufCount)
- return RETVAL_DATA_ERROR;
- bd->writePos = dbuf[origPtr];
- bd->writeCurrent = (unsigned char)(bd->writePos&0xff);
- bd->writePos >>= 8;
- bd->writeRunCountdown = 5;
- }
- bd->writeCount = dbufCount;
-
- return RETVAL_OK;
-}
-
-/* Undo burrows-wheeler transform on intermediate buffer to produce output.
- If start_bunzip was initialized with out_fd =-1, then up to len bytes of
- data are written to outbuf. Return value is number of bytes written or
- error (all errors are negative numbers). If out_fd!=-1, outbuf and len
- are ignored, data is written to out_fd and return is RETVAL_OK or error.
-*/
-
-static int INIT read_bunzip(struct bunzip_data *bd, char *outbuf, int len)
-{
- const unsigned int *dbuf;
- int pos, xcurrent, previous, gotcount;
-
- /* If last read was short due to end of file, return last block now */
- if (bd->writeCount < 0)
- return bd->writeCount;
-
- gotcount = 0;
- dbuf = bd->dbuf;
- pos = bd->writePos;
- xcurrent = bd->writeCurrent;
-
- /* We will always have pending decoded data to write into the output
- buffer unless this is the very first call (in which case we haven't
- Huffman-decoded a block into the intermediate buffer yet). */
-
- if (bd->writeCopies) {
- /* Inside the loop, writeCopies means extra copies (beyond 1) */
- --bd->writeCopies;
- /* Loop outputting bytes */
- for (;;) {
- /* If the output buffer is full, snapshot
- * state and return */
- if (gotcount >= len) {
- bd->writePos = pos;
- bd->writeCurrent = xcurrent;
- bd->writeCopies++;
- return len;
- }
- /* Write next byte into output buffer, updating CRC */
- outbuf[gotcount++] = xcurrent;
- bd->writeCRC = (((bd->writeCRC) << 8)
- ^bd->crc32Table[((bd->writeCRC) >> 24)
- ^xcurrent]);
- /* Loop now if we're outputting multiple
- * copies of this byte */
- if (bd->writeCopies) {
- --bd->writeCopies;
- continue;
- }
-decode_next_byte:
- if (!bd->writeCount--)
- break;
- /* Follow sequence vector to undo
- * Burrows-Wheeler transform */
- previous = xcurrent;
- pos = dbuf[pos];
- xcurrent = pos&0xff;
- pos >>= 8;
- /* After 3 consecutive copies of the same
- byte, the 4th is a repeat count. We count
- down from 4 instead *of counting up because
- testing for non-zero is faster */
- if (--bd->writeRunCountdown) {
- if (xcurrent != previous)
- bd->writeRunCountdown = 4;
- } else {
- /* We have a repeated run, this byte
- * indicates the count */
- bd->writeCopies = xcurrent;
- xcurrent = previous;
- bd->writeRunCountdown = 5;
- /* Sometimes there are just 3 bytes
- * (run length 0) */
- if (!bd->writeCopies)
- goto decode_next_byte;
- /* Subtract the 1 copy we'd output
- * anyway to get extras */
- --bd->writeCopies;
- }
- }
- /* Decompression of this block completed successfully */
- bd->writeCRC = ~bd->writeCRC;
- bd->totalCRC = ((bd->totalCRC << 1) |
- (bd->totalCRC >> 31)) ^ bd->writeCRC;
- /* If this block had a CRC error, force file level CRC error. */
- if (bd->writeCRC != bd->headerCRC) {
- bd->totalCRC = bd->headerCRC+1;
- return RETVAL_LAST_BLOCK;
- }
- }
-
- /* Refill the intermediate buffer by Huffman-decoding next
- * block of input */
- /* (previous is just a convenient unused temp variable here) */
- previous = get_next_block(bd);
- if (previous) {
- bd->writeCount = previous;
- return (previous != RETVAL_LAST_BLOCK) ? previous : gotcount;
- }
- bd->writeCRC = 0xffffffffUL;
- pos = bd->writePos;
- xcurrent = bd->writeCurrent;
- goto decode_next_byte;
-}
-
-static long INIT nofill(void *buf, unsigned long len)
-{
- return -1;
-}
-
-/* Allocate the structure, read file header. If in_fd ==-1, inbuf must contain
- a complete bunzip file (len bytes long). If in_fd!=-1, inbuf and len are
- ignored, and data is read from file handle into temporary buffer. */
-static int INIT start_bunzip(struct bunzip_data **bdp, void *inbuf, long len,
- long (*fill)(void*, unsigned long))
-{
- struct bunzip_data *bd;
- unsigned int i, j, c;
- const unsigned int BZh0 =
- (((unsigned int)'B') << 24)+(((unsigned int)'Z') << 16)
- +(((unsigned int)'h') << 8)+(unsigned int)'0';
-
- /* Figure out how much data to allocate */
- i = sizeof(struct bunzip_data);
-
- /* Allocate bunzip_data. Most fields initialize to zero. */
- bd = *bdp = malloc(i);
- if (!bd)
- return RETVAL_OUT_OF_MEMORY;
- memset(bd, 0, sizeof(struct bunzip_data));
- /* Setup input buffer */
- bd->inbuf = inbuf;
- bd->inbufCount = len;
- if (fill != NULL)
- bd->fill = fill;
- else
- bd->fill = nofill;
-
- /* Init the CRC32 table (big endian) */
- for (i = 0; i < 256; i++) {
- c = i << 24;
- for (j = 8; j; j--)
- c = c&0x80000000 ? (c << 1)^(CRC32_POLY_BE) : (c << 1);
- bd->crc32Table[i] = c;
- }
-
- /* Ensure that file starts with "BZh['1'-'9']." */
- i = get_bits(bd, 32);
- if (((unsigned int)(i-BZh0-1)) >= 9)
- return RETVAL_NOT_BZIP_DATA;
-
- /* Fourth byte (ascii '1'-'9'), indicates block size in units of 100k of
- uncompressed data. Allocate intermediate buffer for block. */
- bd->dbufSize = 100000*(i-BZh0);
-
- bd->dbuf = large_malloc(bd->dbufSize * sizeof(int));
- if (!bd->dbuf)
- return RETVAL_OUT_OF_MEMORY;
- return RETVAL_OK;
-}
-
-/* Example usage: decompress src_fd to dst_fd. (Stops at end of bzip2 data,
- not end of file.) */
-STATIC int INIT bunzip2(unsigned char *buf, long len,
- long (*fill)(void*, unsigned long),
- long (*flush)(void*, unsigned long),
- unsigned char *outbuf,
- long *pos,
- void(*error)(char *x))
-{
- struct bunzip_data *bd;
- int i = -1;
- unsigned char *inbuf;
-
- if (flush)
- outbuf = malloc(BZIP2_IOBUF_SIZE);
-
- if (!outbuf) {
- error("Could not allocate output buffer");
- return RETVAL_OUT_OF_MEMORY;
- }
- if (buf)
- inbuf = buf;
- else
- inbuf = malloc(BZIP2_IOBUF_SIZE);
- if (!inbuf) {
- error("Could not allocate input buffer");
- i = RETVAL_OUT_OF_MEMORY;
- goto exit_0;
- }
- i = start_bunzip(&bd, inbuf, len, fill);
- if (!i) {
- for (;;) {
- i = read_bunzip(bd, outbuf, BZIP2_IOBUF_SIZE);
- if (i <= 0)
- break;
- if (!flush)
- outbuf += i;
- else
- if (i != flush(outbuf, i)) {
- i = RETVAL_UNEXPECTED_OUTPUT_EOF;
- break;
- }
- }
- }
- /* Check CRC and release memory */
- if (i == RETVAL_LAST_BLOCK) {
- if (bd->headerCRC != bd->totalCRC)
- error("Data integrity error when decompressing.");
- else
- i = RETVAL_OK;
- } else if (i == RETVAL_UNEXPECTED_OUTPUT_EOF) {
- error("Compressed file ends unexpectedly");
- }
- if (!bd)
- goto exit_1;
- if (bd->dbuf)
- large_free(bd->dbuf);
- if (pos)
- *pos = bd->inbufPos;
- free(bd);
-exit_1:
- if (!buf)
- free(inbuf);
-exit_0:
- if (flush)
- free(outbuf);
- return i;
-}
-
-#ifdef PREBOOT
-STATIC int INIT __decompress(unsigned char *buf, long len,
- long (*fill)(void*, unsigned long),
- long (*flush)(void*, unsigned long),
- unsigned char *outbuf, long olen,
- long *pos,
- void (*error)(char *x))
-{
- return bunzip2(buf, len - 4, fill, flush, outbuf, pos, error);
-}
-#endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 94133708889d..f05111c59a3b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -343,10 +343,7 @@ $(obj)/%.dt.yaml: $(src)/%.dts $(DTC) $(DT_TMP_SCHEMA) FORCE
dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
-# Bzip2
-# ---------------------------------------------------------------------------
-
-# Bzip2 and LZMA do not include size in file... so we have to fake that;
+# LZMA does not include size in file... so we have to fake that;
# append the size as a 32-bit littleendian number as gzip does.
size_append = printf $(shell \
dec_size=0; \
@@ -363,9 +360,6 @@ printf "%08x\n" $$dec_size | \
} \
)
-quiet_cmd_bzip2 = BZIP2 $@
- cmd_bzip2 = { cat $(real-prereqs) | $(KBZIP2) -9; $(size_append); } > $@
-
# Lzma
# ---------------------------------------------------------------------------
diff --git a/scripts/Makefile.package b/scripts/Makefile.package
index f952fb64789d..2c4a9dbc7e6e 100644
--- a/scripts/Makefile.package
+++ b/scripts/Makefile.package
@@ -127,7 +127,6 @@ util/PERF-VERSION-GEN $(CURDIR)/$(perf-tar)/); \
tar rf $(perf-tar).tar $(perf-tar)/HEAD $(perf-tar)/PERF-VERSION-FILE; \
rm -r $(perf-tar); \
$(if $(findstring tar-src,$@),, \
-$(if $(findstring bz2,$@),$(KBZIP2), \
$(if $(findstring gz,$@),$(KGZIP), \
$(if $(findstring xz,$@),$(XZ), \
$(error unknown target $@)))) \
diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index 936198a90477..91bcb50579c7 100755
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -118,7 +118,7 @@ case "${ARCH}" in
fi
;;
arm64)
- for i in Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo ; do
+ for i in Image.gz Image.lz4 Image.lzma Image.lzo ; do
if [ -f "${objtree}/arch/arm64/boot/${i}" ] ; then
cp -v -- "${objtree}/arch/arm64/boot/${i}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
break
diff --git a/usr/Kconfig b/usr/Kconfig
index 2599bc21c1b2..ba5ecb054df5 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -60,14 +60,6 @@ config RD_GZIP
Support loading of a gzip encoded initial ramdisk or cpio buffer.
If unsure, say Y.
-config RD_BZIP2
- bool "Support initial ramdisk/ramfs compressed using bzip2"
- default y
- select DECOMPRESS_BZIP2
- help
- Support loading of a bzip2 encoded initial ramdisk or cpio buffer
- If unsure, say N.
-
config RD_LZMA
bool "Support initial ramdisk/ramfs compressed using LZMA"
default y
@@ -143,19 +135,6 @@ config INITRAMFS_COMPRESSION_GZIP
supported by your build system as the gzip tool is present by default
on most distros.
-config INITRAMFS_COMPRESSION_BZIP2
- bool "Bzip2"
- depends on RD_BZIP2
- help
- It's compression ratio and speed is intermediate. Decompression speed
- is slowest among the choices. The initramfs size is about 10% smaller
- with bzip2, in comparison to gzip. Bzip2 uses a large amount of
- memory. For modern kernels you will need at least 8MB RAM or more for
- booting.
-
- If you choose this, keep in mind that you need to have the bzip2 tool
- available to be able to compress the initram.
-
config INITRAMFS_COMPRESSION_LZMA
bool "LZMA"
depends on RD_LZMA
@@ -175,9 +154,8 @@ config INITRAMFS_COMPRESSION_XZ
help
XZ uses the LZMA2 algorithm and has a large dictionary which may cause
problems on memory constrained systems. The initramfs size is about
- 30% smaller with XZ in comparison to gzip. Decompression speed is
- better than that of bzip2 but worse than gzip and LZO. Compression is
- slow.
+ 30% smaller with XZ in comparison to gzip. Compression and
+ decompression are slowest.
If you choose this, keep in mind that you may need to install the xz
tool to be able to compress the initram.
diff --git a/usr/Makefile b/usr/Makefile
index b1a81a40eab1..367bc5d4c759 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -3,14 +3,13 @@
# kbuild file for usr/ - including initramfs image
#
-# cmd_bzip2, cmd_lzma, cmd_lzo, cmd_lz4 from scripts/Makefile.lib appends the
+# cmd_lzma, cmd_lzo, cmd_lz4 from scripts/Makefile.lib appends the
# size at the end of the compressed file, which unfortunately does not work
# with unpack_to_rootfs(). Make size_append no-op.
override size_append := :
compress-y := shipped
compress-$(CONFIG_INITRAMFS_COMPRESSION_GZIP) := gzip
-compress-$(CONFIG_INITRAMFS_COMPRESSION_BZIP2) := bzip2
compress-$(CONFIG_INITRAMFS_COMPRESSION_LZMA) := lzma
compress-$(CONFIG_INITRAMFS_COMPRESSION_XZ) := xzmisc
compress-$(CONFIG_INITRAMFS_COMPRESSION_LZO) := lzo
--
2.29.2
^ permalink raw reply related [relevance 17%]
* [PATCH 2/3] init: remove special-case for mtd/ubi
2020-12-07 18:48 99% ` [PATCH 1/3] init: fall back on mounting raw root Alex Xu (Hello71)
@ 2020-12-07 18:48 99% ` Alex Xu (Hello71)
2020-12-07 18:48 99% ` [PATCH 3/3] init: remove root_device_name Alex Xu (Hello71)
1 sibling, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-12-07 18:48 UTC (permalink / raw)
To: Alex Xu (Hello71),
Dominik Brodowski, Song Liu, Theodore Ts'o, Jens Axboe,
linux-kernel
This should be handled by the fallback after trying to resolve it.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
init/do_mounts.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 8aa38ec0bfec..a2a273b9866f 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -603,11 +603,6 @@ void __init prepare_namespace(void)
if (saved_root_name[0]) {
root_device_name = saved_root_name;
- if (!strncmp(root_device_name, "mtd", 3) ||
- !strncmp(root_device_name, "ubi", 3)) {
- mount_block_root(root_device_name, root_mountflags);
- goto out;
- }
ROOT_DEV = name_to_dev_t(root_device_name);
if (strncmp(root_device_name, "/dev/", 5) == 0)
root_device_name += 5;
--
2.29.2
^ permalink raw reply related [relevance 99%]
* [PATCH 3/3] init: remove root_device_name
2020-12-07 18:48 99% ` [PATCH 1/3] init: fall back on mounting raw root Alex Xu (Hello71)
2020-12-07 18:48 99% ` [PATCH 2/3] init: remove special-case for mtd/ubi Alex Xu (Hello71)
@ 2020-12-07 18:48 99% ` Alex Xu (Hello71)
1 sibling, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-12-07 18:48 UTC (permalink / raw)
To: Alex Xu (Hello71),
Dominik Brodowski, Song Liu, Theodore Ts'o, Jens Axboe,
linux-kernel
root_device_name has gone through many iterations, but is now solely
used for removing a /dev/ prefix off root= parameter. It's time for it
to be removed.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
init/do_mounts.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index a2a273b9866f..544614279281 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -29,7 +29,6 @@
#include "do_mounts.h"
int root_mountflags = MS_RDONLY | MS_SILENT;
-static char * __initdata root_device_name;
static char __initdata saved_root_name[64];
static int root_wait;
@@ -449,7 +448,7 @@ void __init mount_block_root(char *name, int flags)
* and give them a list of the available devices
*/
printk("VFS: Cannot open root device \"%s\" or %s: error %d\n",
- root_device_name, b, err);
+ saved_root_name, b, err);
printk("Please append a correct \"root=\" boot option; here are the available partitions:\n");
printk_all_partitions();
@@ -602,10 +601,7 @@ void __init prepare_namespace(void)
md_run_setup();
if (saved_root_name[0]) {
- root_device_name = saved_root_name;
- ROOT_DEV = name_to_dev_t(root_device_name);
- if (strncmp(root_device_name, "/dev/", 5) == 0)
- root_device_name += 5;
+ ROOT_DEV = name_to_dev_t(saved_root_name);
}
if (initrd_load())
--
2.29.2
^ permalink raw reply related [relevance 99%]
* [PATCH 1/3] init: fall back on mounting raw root
[not found] <20201207184835.63538-1-alex_y_xu.ref@yahoo.ca>
@ 2020-12-07 18:48 99% ` Alex Xu (Hello71)
2020-12-07 18:48 99% ` [PATCH 2/3] init: remove special-case for mtd/ubi Alex Xu (Hello71)
2020-12-07 18:48 99% ` [PATCH 3/3] init: remove root_device_name Alex Xu (Hello71)
0 siblings, 2 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-12-07 18:48 UTC (permalink / raw)
To: Alex Xu (Hello71),
Dominik Brodowski, Song Liu, Theodore Ts'o, Jens Axboe,
linux-kernel
9p/virtio, virtiofs, and others can be mounted with no block device or
userspace helpers.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
init/do_mounts.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index b5f9604d0c98..8aa38ec0bfec 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -568,7 +568,7 @@ void __init mount_root(void)
}
#endif
#ifdef CONFIG_BLOCK
- {
+ if (ROOT_DEV != 0) {
int err = create_dev("/dev/root", ROOT_DEV);
if (err < 0)
@@ -576,6 +576,7 @@ void __init mount_root(void)
mount_block_root("/dev/root", root_mountflags);
}
#endif
+ mount_block_root(saved_root_name, root_mountflags);
}
/*
--
2.29.2
^ permalink raw reply related [relevance 99%]
* [RFC PATCH] treewide: remove bzip2 compression support
[not found] <20201117223253.65920-1-alex_y_xu.ref@yahoo.ca>
@ 2020-11-17 22:32 17% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-11-17 22:32 UTC (permalink / raw)
To: linux-kernel, linux-kbuild, linux-arm-kernel, linux-aspeed,
linux-mips, openrisc, linux-parisc, linuxppc-dev, linux-riscv,
linux-s390, linux-sh, linux-xtensa
Cc: torvalds, Alex Xu (Hello71)
bzip2 is either slower or larger than every other supported algorithm,
according to benchmarks at [0]. It is far slower to decompress than any
other algorithm, and still larger than lzma, xz, and zstd.
[0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
Documentation/x86/boot.rst | 8 +-
arch/arm/configs/aspeed_g4_defconfig | 1 -
arch/arm/configs/aspeed_g5_defconfig | 1 -
arch/arm/configs/ezx_defconfig | 1 -
arch/arm/configs/imote2_defconfig | 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/vf610m4_defconfig | 1 -
arch/arm64/boot/Makefile | 5 +-
arch/mips/Kconfig | 1 -
arch/mips/Makefile | 3 -
arch/mips/boot/Makefile | 14 -
arch/mips/boot/compressed/Makefile | 1 -
arch/mips/boot/compressed/decompress.c | 4 -
arch/mips/configs/ath25_defconfig | 1 -
arch/mips/configs/pistachio_defconfig | 1 -
arch/openrisc/configs/simple_smp_defconfig | 1 -
arch/parisc/Kconfig | 1 -
arch/parisc/boot/compressed/Makefile | 5 +-
arch/parisc/boot/compressed/misc.c | 4 -
arch/powerpc/configs/skiroot_defconfig | 1 -
arch/riscv/boot/Makefile | 3 -
arch/riscv/configs/nommu_k210_defconfig | 1 -
arch/riscv/configs/nommu_virt_defconfig | 1 -
arch/s390/Kconfig | 1 -
arch/s390/boot/compressed/Makefile | 5 +-
arch/s390/boot/compressed/decompressor.c | 8 -
arch/sh/Kconfig | 1 -
arch/sh/Makefile | 3 +-
arch/sh/boot/Makefile | 11 +-
arch/sh/boot/compressed/Makefile | 5 +-
arch/sh/boot/compressed/misc.c | 8 -
arch/sh/configs/sdk7786_defconfig | 1 -
arch/x86/Kconfig | 1 -
arch/x86/boot/compressed/Makefile | 9 +-
arch/x86/boot/compressed/misc.c | 4 -
arch/x86/include/asm/boot.h | 4 +-
arch/xtensa/configs/cadence_csp_defconfig | 1 -
arch/xtensa/configs/nommu_kc705_defconfig | 1 -
include/linux/decompress/bunzip2.h | 11 -
init/Kconfig | 22 +-
init/do_mounts_rd.c | 1 -
kernel/configs/tiny.config | 1 -
lib/Kconfig | 3 -
lib/Makefile | 1 -
lib/decompress.c | 5 -
lib/decompress_bunzip2.c | 756 ---------------------
scripts/Makefile.lib | 8 +-
scripts/Makefile.package | 1 -
scripts/package/buildtar | 2 +-
usr/Kconfig | 26 +-
usr/Makefile | 3 +-
51 files changed, 22 insertions(+), 942 deletions(-)
delete mode 100644 include/linux/decompress/bunzip2.h
delete mode 100644 lib/decompress_bunzip2.c
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index abb9fc164657..b74d14caabe6 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -781,10 +781,10 @@ Protocol: 2.08+
The payload may be compressed. The format of both the compressed and
uncompressed data should be determined using the standard magic
numbers. The currently supported compression formats are gzip
- (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
- (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number
- 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is
- currently always ELF (magic number 7F 45 4C 46).
+ (magic numbers 1F 8B or 1F 9E), LZMA (magic number 5D 00), XZ (magic
+ number FD 37), LZ4 (magic number 02 21) and ZSTD (magic number 28
+ B5). The uncompressed payload is currently always ELF (magic number
+ 7F 45 4C 46).
============ ==============
Field name: payload_length
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index 58d293b63581..f2f5dcd0e59c 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_UID16 is not set
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index 047975eccefb..5d045b2902d6 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_UID16 is not set
diff --git a/arch/arm/configs/ezx_defconfig b/arch/arm/configs/ezx_defconfig
index 81665b7abf83..422592786e01 100644
--- a/arch/arm/configs/ezx_defconfig
+++ b/arch/arm/configs/ezx_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_EXPERT=y
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arm/configs/imote2_defconfig b/arch/arm/configs/imote2_defconfig
index ae15a2a33802..04e23ec01af6 100644
--- a/arch/arm/configs/imote2_defconfig
+++ b/arch/arm/configs/imote2_defconfig
@@ -3,7 +3,6 @@ CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_EXPERT=y
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arm/configs/lpc18xx_defconfig b/arch/arm/configs/lpc18xx_defconfig
index be882ea0eee4..12e69dfa18dc 100644
--- a/arch/arm/configs/lpc18xx_defconfig
+++ b/arch/arm/configs/lpc18xx_defconfig
@@ -1,7 +1,6 @@
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/arm/configs/vf610m4_defconfig b/arch/arm/configs/vf610m4_defconfig
index a89f035c3b01..02c7acc7cd09 100644
--- a/arch/arm/configs/vf610m4_defconfig
+++ b/arch/arm/configs/vf610m4_defconfig
@@ -1,6 +1,5 @@
CONFIG_NAMESPACES=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZ4 is not set
diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index cd3414898d10..d3207561c078 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -16,14 +16,11 @@
OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
-targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo
+targets := Image Image.gz Image.lz4 Image.lzma Image.lzo
$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
-$(obj)/Image.bz2: $(obj)/Image FORCE
- $(call if_changed,bzip2)
-
$(obj)/Image.gz: $(obj)/Image FORCE
$(call if_changed,gzip)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2000bb2b0220..50992a3b6130 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1880,7 +1880,6 @@ endif # CPU_LOONGSON2F
config SYS_SUPPORTS_ZBOOT
bool
select HAVE_KERNEL_GZIP
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 0d0f29d662c9..2dd53daf6fbb 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -328,14 +328,12 @@ boot-y += vmlinux.srec
ifeq ($(shell expr $(load-y) \< 0xffffffff80000000 2> /dev/null), 0)
boot-y += uImage
boot-y += uImage.bin
-boot-y += uImage.bz2
boot-y += uImage.gz
boot-y += uImage.lzma
boot-y += uImage.lzo
endif
boot-y += vmlinux.itb
boot-y += vmlinux.gz.itb
-boot-y += vmlinux.bz2.itb
boot-y += vmlinux.lzma.itb
boot-y += vmlinux.lzo.itb
@@ -429,7 +427,6 @@ define archhelp
echo ' vmlinuz.srec - SREC zboot image'
echo ' uImage - U-Boot image'
echo ' uImage.bin - U-Boot image (uncompressed)'
- echo ' uImage.bz2 - U-Boot image (bz2)'
echo ' uImage.gz - U-Boot image (gzip)'
echo ' uImage.lzma - U-Boot image (lzma)'
echo ' uImage.lzo - U-Boot image (lzo)'
diff --git a/arch/mips/boot/Makefile b/arch/mips/boot/Makefile
index a3da2c5d63c2..78f70e3576cd 100644
--- a/arch/mips/boot/Makefile
+++ b/arch/mips/boot/Makefile
@@ -24,7 +24,6 @@ strip-flags := $(addprefix --remove-section=,$(drop-sections))
hostprogs := elf2ecoff
suffix-y := bin
-suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_GZIP) := gz
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_LZO) := lzo
@@ -54,14 +53,10 @@ UIMAGE_ENTRYADDR = $(VMLINUX_ENTRY_ADDRESS)
# Compressed vmlinux images
#
-extra-y += vmlinux.bin.bz2
extra-y += vmlinux.bin.gz
extra-y += vmlinux.bin.lzma
extra-y += vmlinux.bin.lzo
-$(obj)/vmlinux.bin.bz2: $(obj)/vmlinux.bin FORCE
- $(call if_changed,bzip2)
-
$(obj)/vmlinux.bin.gz: $(obj)/vmlinux.bin FORCE
$(call if_changed,gzip)
@@ -77,7 +72,6 @@ $(obj)/vmlinux.bin.lzo: $(obj)/vmlinux.bin FORCE
targets += uImage
targets += uImage.bin
-targets += uImage.bz2
targets += uImage.gz
targets += uImage.lzma
targets += uImage.lzo
@@ -85,9 +79,6 @@ targets += uImage.lzo
$(obj)/uImage.bin: $(obj)/vmlinux.bin FORCE
$(call if_changed,uimage,none)
-$(obj)/uImage.bz2: $(obj)/vmlinux.bin.bz2 FORCE
- $(call if_changed,uimage,bzip2)
-
$(obj)/uImage.gz: $(obj)/vmlinux.bin.gz FORCE
$(call if_changed,uimage,gzip)
@@ -122,7 +113,6 @@ $(obj)/vmlinux.its.S: $(addprefix $(srctree)/arch/mips/$(PLATFORM)/,$(ITS_INPUTS
targets += vmlinux.its
targets += vmlinux.gz.its
-targets += vmlinux.bz2.its
targets += vmlinux.lzma.its
targets += vmlinux.lzo.its
@@ -142,9 +132,6 @@ $(obj)/vmlinux.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
$(obj)/vmlinux.gz.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
$(call if_changed,cpp_its_S,gzip,vmlinux.bin.gz)
-$(obj)/vmlinux.bz2.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
- $(call if_changed,cpp_its_S,bzip2,vmlinux.bin.bz2)
-
$(obj)/vmlinux.lzma.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
$(call if_changed,cpp_its_S,lzma,vmlinux.bin.lzma)
@@ -153,7 +140,6 @@ $(obj)/vmlinux.lzo.its: $(obj)/vmlinux.its.S $(VMLINUX) FORCE
targets += vmlinux.itb
targets += vmlinux.gz.itb
-targets += vmlinux.bz2.itb
targets += vmlinux.lzma.itb
targets += vmlinux.lzo.itb
diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile
index d66511825fe1..8fbd72b466e6 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -70,7 +70,6 @@ $(obj)/vmlinux.bin: $(KBUILD_IMAGE) FORCE
$(call if_changed,objcopy)
tool_$(CONFIG_KERNEL_GZIP) = gzip
-tool_$(CONFIG_KERNEL_BZIP2) = bzip2
tool_$(CONFIG_KERNEL_LZ4) = lz4
tool_$(CONFIG_KERNEL_LZMA) = lzma
tool_$(CONFIG_KERNEL_LZO) = lzo
diff --git a/arch/mips/boot/compressed/decompress.c b/arch/mips/boot/compressed/decompress.c
index c61c641674e6..ac7ccab2bb52 100644
--- a/arch/mips/boot/compressed/decompress.c
+++ b/arch/mips/boot/compressed/decompress.c
@@ -52,10 +52,6 @@ void error(char *x)
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZ4
#include "../../../../lib/decompress_unlz4.c"
#endif
diff --git a/arch/mips/configs/ath25_defconfig b/arch/mips/configs/ath25_defconfig
index 7143441f5476..1e12d3018c15 100644
--- a/arch/mips/configs/ath25_defconfig
+++ b/arch/mips/configs/ath25_defconfig
@@ -4,7 +4,6 @@ CONFIG_SYSVIPC=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
diff --git a/arch/mips/configs/pistachio_defconfig b/arch/mips/configs/pistachio_defconfig
index b9adf15ebbec..ad31439400c6 100644
--- a/arch/mips/configs/pistachio_defconfig
+++ b/arch/mips/configs/pistachio_defconfig
@@ -14,7 +14,6 @@ CONFIG_CGROUP_FREEZER=y
CONFIG_NAMESPACES=y
CONFIG_USER_NS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
diff --git a/arch/openrisc/configs/simple_smp_defconfig b/arch/openrisc/configs/simple_smp_defconfig
index ff49d868e040..74a5fe83aa17 100644
--- a/arch/openrisc/configs/simple_smp_defconfig
+++ b/arch/openrisc/configs/simple_smp_defconfig
@@ -3,7 +3,6 @@ CONFIG_NO_HZ=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index b234e8154cbd..4eee43c1e7d9 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -22,7 +22,6 @@ config PARISC
select BUILDTIME_TABLE_SORT
select HAVE_PCI
select HAVE_PERF_EVENTS
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
diff --git a/arch/parisc/boot/compressed/Makefile b/arch/parisc/boot/compressed/Makefile
index dff453687530..2c9403ebb96a 100644
--- a/arch/parisc/boot/compressed/Makefile
+++ b/arch/parisc/boot/compressed/Makefile
@@ -9,7 +9,7 @@ KCOV_INSTRUMENT := n
GCOV_PROFILE := n
UBSAN_SANITIZE := n
-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2
+targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz
targets += vmlinux.bin.xz vmlinux.bin.lzma vmlinux.bin.lzo vmlinux.bin.lz4
targets += misc.o piggy.o sizes.h head.o real2.o firmware.o
targets += real2.S firmware.c
@@ -64,7 +64,6 @@ $(obj)/vmlinux.bin: vmlinux FORCE
vmlinux.bin.all-y := $(obj)/vmlinux.bin
suffix-$(CONFIG_KERNEL_GZIP) := gz
-suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZ4) := lz4
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_LZO) := lzo
@@ -72,8 +71,6 @@ suffix-$(CONFIG_KERNEL_XZ) := xz
$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y)
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y)
- $(call if_changed,bzip2)
$(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y)
$(call if_changed,lz4)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y)
diff --git a/arch/parisc/boot/compressed/misc.c b/arch/parisc/boot/compressed/misc.c
index 2d395998f524..247a0b138cb1 100644
--- a/arch/parisc/boot/compressed/misc.c
+++ b/arch/parisc/boot/compressed/misc.c
@@ -42,10 +42,6 @@ static unsigned long free_mem_end_ptr;
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZ4
#include "../../../../lib/decompress_unlz4.c"
#endif
diff --git a/arch/powerpc/configs/skiroot_defconfig b/arch/powerpc/configs/skiroot_defconfig
index b806a5d3a695..28139c0294e9 100644
--- a/arch/powerpc/configs/skiroot_defconfig
+++ b/arch/powerpc/configs/skiroot_defconfig
@@ -11,7 +11,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_BLK_DEV_INITRD=y
# CONFIG_RD_GZIP is not set
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
diff --git a/arch/riscv/boot/Makefile b/arch/riscv/boot/Makefile
index c59fca695f9d..944ea5165225 100644
--- a/arch/riscv/boot/Makefile
+++ b/arch/riscv/boot/Makefile
@@ -31,9 +31,6 @@ $(obj)/loader.o: $(src)/loader.S $(obj)/Image
$(obj)/loader: $(obj)/loader.o $(obj)/Image $(obj)/loader.lds FORCE
$(Q)$(LD) -T $(obj)/loader.lds -o $@ $(obj)/loader.o
-$(obj)/Image.bz2: $(obj)/Image FORCE
- $(call if_changed,bzip2)
-
$(obj)/Image.lz4: $(obj)/Image FORCE
$(call if_changed,lz4)
diff --git a/arch/riscv/configs/nommu_k210_defconfig b/arch/riscv/configs/nommu_k210_defconfig
index cd1df62b13c7..a71b615fa1b1 100644
--- a/arch/riscv/configs/nommu_k210_defconfig
+++ b/arch/riscv/configs/nommu_k210_defconfig
@@ -3,7 +3,6 @@ CONFIG_LOG_BUF_SHIFT=15
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_FORCE=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/riscv/configs/nommu_virt_defconfig b/arch/riscv/configs/nommu_virt_defconfig
index e046a0babde4..fb72b5d6c0ec 100644
--- a/arch/riscv/configs/nommu_virt_defconfig
+++ b/arch/riscv/configs/nommu_virt_defconfig
@@ -2,7 +2,6 @@
CONFIG_LOG_BUF_SHIFT=16
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 4a2a12be04c9..acdd13a78d96 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -154,7 +154,6 @@ config S390
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GCC_PLUGINS
select HAVE_GENERIC_VDSO
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
diff --git a/arch/s390/boot/compressed/Makefile b/arch/s390/boot/compressed/Makefile
index b235ed95a3d8..18574433c43f 100644
--- a/arch/s390/boot/compressed/Makefile
+++ b/arch/s390/boot/compressed/Makefile
@@ -11,7 +11,7 @@ UBSAN_SANITIZE := n
KASAN_SANITIZE := n
obj-y := $(if $(CONFIG_KERNEL_UNCOMPRESSED),,decompressor.o) piggy.o info.o
-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2
+targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz
targets += vmlinux.bin.xz vmlinux.bin.lzma vmlinux.bin.lzo vmlinux.bin.lz4
targets += info.bin $(obj-y)
@@ -40,7 +40,6 @@ $(obj)/vmlinux.bin: vmlinux FORCE
vmlinux.bin.all-y := $(obj)/vmlinux.bin
suffix-$(CONFIG_KERNEL_GZIP) := .gz
-suffix-$(CONFIG_KERNEL_BZIP2) := .bz2
suffix-$(CONFIG_KERNEL_LZ4) := .lz4
suffix-$(CONFIG_KERNEL_LZMA) := .lzma
suffix-$(CONFIG_KERNEL_LZO) := .lzo
@@ -48,8 +47,6 @@ suffix-$(CONFIG_KERNEL_XZ) := .xz
$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
- $(call if_changed,bzip2)
$(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lz4)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
diff --git a/arch/s390/boot/compressed/decompressor.c b/arch/s390/boot/compressed/decompressor.c
index 3061b11c4d27..87395950cc69 100644
--- a/arch/s390/boot/compressed/decompressor.c
+++ b/arch/s390/boot/compressed/decompressor.c
@@ -28,11 +28,7 @@ extern char _end[];
extern unsigned char _compressed_start[];
extern unsigned char _compressed_end[];
-#ifdef CONFIG_HAVE_KERNEL_BZIP2
-#define BOOT_HEAP_SIZE 0x400000
-#else
#define BOOT_HEAP_SIZE 0x10000
-#endif
static unsigned long free_mem_ptr = (unsigned long) _end;
static unsigned long free_mem_end_ptr = (unsigned long) _end + BOOT_HEAP_SIZE;
@@ -41,10 +37,6 @@ static unsigned long free_mem_end_ptr = (unsigned long) _end + BOOT_HEAP_SIZE;
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZ4
#include "../../../../lib/decompress_unlz4.c"
#endif
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 159da4ed578f..df4113457afd 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -42,7 +42,6 @@ config SUPERH
select HAVE_HW_BREAKPOINT
select HAVE_IDE if HAS_IOPORT_MAP
select HAVE_IOREMAP_PROT if MMU && !X2TLB
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index 2faebfd72eca..6fdaa8d2d835 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -189,7 +189,7 @@ endif
libs-y := arch/sh/lib/ $(libs-y)
-BOOT_TARGETS = uImage uImage.bz2 uImage.gz uImage.lzma uImage.xz uImage.lzo \
+BOOT_TARGETS = uImage uImage.gz uImage.lzma uImage.xz uImage.lzo \
uImage.srec uImage.bin zImage vmlinux.bin vmlinux.srec \
romImage
PHONY += $(BOOT_TARGETS)
@@ -220,7 +220,6 @@ define archhelp
@echo ' uImage.srec - Create an S-record for U-Boot'
@echo ' uImage.bin - Kernel-only image for U-Boot (bin)'
@echo '* uImage.gz - Kernel-only image for U-Boot (gzip)'
- @echo ' uImage.bz2 - Kernel-only image for U-Boot (bzip2)'
@echo ' uImage.lzma - Kernel-only image for U-Boot (lzma)'
@echo ' uImage.xz - Kernel-only image for U-Boot (xz)'
@echo ' uImage.lzo - Kernel-only image for U-Boot (lzo)'
diff --git a/arch/sh/boot/Makefile b/arch/sh/boot/Makefile
index 58592dfa5cb6..8f742b8285a5 100644
--- a/arch/sh/boot/Makefile
+++ b/arch/sh/boot/Makefile
@@ -21,14 +21,13 @@ CONFIG_PHYSICAL_START ?= $(CONFIG_MEMORY_START)
suffix-y := bin
suffix-$(CONFIG_KERNEL_GZIP) := gz
-suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_XZ) := xz
suffix-$(CONFIG_KERNEL_LZO) := lzo
targets := zImage vmlinux.srec romImage uImage uImage.srec uImage.gz \
- uImage.bz2 uImage.lzma uImage.xz uImage.lzo uImage.bin
-extra-y += vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \
+ uImage.lzma uImage.xz uImage.lzo uImage.bin
+extra-y += vmlinux.bin vmlinux.bin.gz vmlinux.bin.lzma \
vmlinux.bin.xz vmlinux.bin.lzo
subdir- := compressed romimage
@@ -68,9 +67,6 @@ $(obj)/vmlinux.bin: vmlinux FORCE
$(obj)/vmlinux.bin.gz: $(obj)/vmlinux.bin FORCE
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(obj)/vmlinux.bin FORCE
- $(call if_changed,bzip2)
-
$(obj)/vmlinux.bin.lzma: $(obj)/vmlinux.bin FORCE
$(call if_changed,lzma)
@@ -80,9 +76,6 @@ $(obj)/vmlinux.bin.xz: $(obj)/vmlinux.bin FORCE
$(obj)/vmlinux.bin.lzo: $(obj)/vmlinux.bin FORCE
$(call if_changed,lzo)
-$(obj)/uImage.bz2: $(obj)/vmlinux.bin.bz2
- $(call if_changed,uimage,bzip2)
-
$(obj)/uImage.gz: $(obj)/vmlinux.bin.gz
$(call if_changed,uimage,gzip)
diff --git a/arch/sh/boot/compressed/Makefile b/arch/sh/boot/compressed/Makefile
index 589d2d8a573d..641b16826383 100644
--- a/arch/sh/boot/compressed/Makefile
+++ b/arch/sh/boot/compressed/Makefile
@@ -6,8 +6,7 @@
#
targets := vmlinux vmlinux.bin vmlinux.bin.gz \
- vmlinux.bin.bz2 vmlinux.bin.lzma \
- vmlinux.bin.xz vmlinux.bin.lzo \
+ vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo \
head_32.o misc.o piggy.o
OBJECTS = $(obj)/head_32.o $(obj)/misc.o $(obj)/cache.o
@@ -57,8 +56,6 @@ vmlinux.bin.all-y := $(obj)/vmlinux.bin
$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
- $(call if_changed,bzip2)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lzma)
$(obj)/vmlinux.bin.xz: $(vmlinux.bin.all-y) FORCE
diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c
index a03b6680a9d9..bf0d4446f7a6 100644
--- a/arch/sh/boot/compressed/misc.c
+++ b/arch/sh/boot/compressed/misc.c
@@ -44,20 +44,12 @@ extern int _end;
static unsigned long free_mem_ptr;
static unsigned long free_mem_end_ptr;
-#ifdef CONFIG_HAVE_KERNEL_BZIP2
-#define HEAP_SIZE 0x400000
-#else
#define HEAP_SIZE 0x10000
-#endif
#ifdef CONFIG_KERNEL_GZIP
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZMA
#include "../../../../lib/decompress_unlzma.c"
#endif
diff --git a/arch/sh/configs/sdk7786_defconfig b/arch/sh/configs/sdk7786_defconfig
index 61bec46ebd66..486e8762cc44 100644
--- a/arch/sh/configs/sdk7786_defconfig
+++ b/arch/sh/configs/sdk7786_defconfig
@@ -29,7 +29,6 @@ CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_LZO=y
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f6946b81f74a..66d75b86ed01 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -182,7 +182,6 @@ config X86
select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_IRQ_TIME_ACCOUNTING
- select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index ee249088cbfe..fb2ebc11c3e8 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -7,13 +7,13 @@
# vmlinuz is:
# decompression code (*.o)
# asm globals (piggy.S), including:
-# vmlinux.bin.(gz|bz2|lzma|...)
+# vmlinux.bin.(gz|lzma|...)
#
# vmlinux.bin is:
# vmlinux stripped of debugging and comments
# vmlinux.bin.all is:
# vmlinux.bin + vmlinux.relocs
-# vmlinux.bin.(gz|bz2|lzma|...) is:
+# vmlinux.bin.(gz|lzma|...) is:
# (see scripts/Makefile.lib size_append)
# compressed vmlinux.bin.all + u32 size of vmlinux.bin.all
@@ -25,7 +25,7 @@ OBJECT_FILES_NON_STANDARD := y
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
-targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \
+targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.lzma \
vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4 vmlinux.bin.zst
KBUILD_CFLAGS := -m$(BITS) -O2
@@ -118,8 +118,6 @@ vmlinux.bin.all-$(CONFIG_X86_NEED_RELOCS) += $(obj)/vmlinux.relocs
$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,gzip)
-$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
- $(call if_changed,bzip2)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lzma)
$(obj)/vmlinux.bin.xz: $(vmlinux.bin.all-y) FORCE
@@ -132,7 +130,6 @@ $(obj)/vmlinux.bin.zst: $(vmlinux.bin.all-y) FORCE
$(call if_changed,zstd22)
suffix-$(CONFIG_KERNEL_GZIP) := gz
-suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZMA) := lzma
suffix-$(CONFIG_KERNEL_XZ) := xz
suffix-$(CONFIG_KERNEL_LZO) := lzo
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 267e7f93050e..b8ef48b240cd 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -55,10 +55,6 @@ static int lines, cols;
#include "../../../../lib/decompress_inflate.c"
#endif
-#ifdef CONFIG_KERNEL_BZIP2
-#include "../../../../lib/decompress_bunzip2.c"
-#endif
-
#ifdef CONFIG_KERNEL_LZMA
#include "../../../../lib/decompress_unlzma.c"
#endif
diff --git a/arch/x86/include/asm/boot.h b/arch/x86/include/asm/boot.h
index 9191280d9ea3..460243445b13 100644
--- a/arch/x86/include/asm/boot.h
+++ b/arch/x86/include/asm/boot.h
@@ -24,9 +24,7 @@
# error "Invalid value for CONFIG_PHYSICAL_ALIGN"
#endif
-#if defined(CONFIG_KERNEL_BZIP2)
-# define BOOT_HEAP_SIZE 0x400000
-#elif defined(CONFIG_KERNEL_ZSTD)
+#if defined(CONFIG_KERNEL_ZSTD)
/*
* Zstd needs to allocate the ZSTD_DCtx in order to decompress the kernel.
* The ZSTD_DCtx is ~160KB, so set the heap size to 192KB because it is a
diff --git a/arch/xtensa/configs/cadence_csp_defconfig b/arch/xtensa/configs/cadence_csp_defconfig
index fc240737b14d..fb069d8a7c83 100644
--- a/arch/xtensa/configs/cadence_csp_defconfig
+++ b/arch/xtensa/configs/cadence_csp_defconfig
@@ -15,7 +15,6 @@ CONFIG_SCHED_AUTOGROUP=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="$$KERNEL_INITRAMFS_SOURCE"
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/arch/xtensa/configs/nommu_kc705_defconfig b/arch/xtensa/configs/nommu_kc705_defconfig
index 88b2e222d4bf..b78b404f4f8f 100644
--- a/arch/xtensa/configs/nommu_kc705_defconfig
+++ b/arch/xtensa/configs/nommu_kc705_defconfig
@@ -15,7 +15,6 @@ CONFIG_NAMESPACES=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
diff --git a/include/linux/decompress/bunzip2.h b/include/linux/decompress/bunzip2.h
deleted file mode 100644
index 5860163942a4..000000000000
--- a/include/linux/decompress/bunzip2.h
+++ /dev/null
@@ -1,11 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef DECOMPRESS_BUNZIP2_H
-#define DECOMPRESS_BUNZIP2_H
-
-int bunzip2(unsigned char *inbuf, long len,
- long (*fill)(void*, unsigned long),
- long (*flush)(void*, unsigned long),
- unsigned char *output,
- long *pos,
- void(*error)(char *x));
-#endif
diff --git a/init/Kconfig b/init/Kconfig
index c9446911cf41..30be16a7ec21 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -176,9 +176,6 @@ config BUILD_SALT
config HAVE_KERNEL_GZIP
bool
-config HAVE_KERNEL_BZIP2
- bool
-
config HAVE_KERNEL_LZMA
bool
@@ -200,7 +197,7 @@ config HAVE_KERNEL_UNCOMPRESSED
choice
prompt "Kernel compression mode"
default KERNEL_GZIP
- depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4 || HAVE_KERNEL_ZSTD || HAVE_KERNEL_UNCOMPRESSED
+ depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_LZMA || HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4 || HAVE_KERNEL_ZSTD || HAVE_KERNEL_UNCOMPRESSED
help
The linux kernel is a kind of self-extracting executable.
Several compression algorithms are available, which differ
@@ -208,11 +205,6 @@ choice
Compression speed is only relevant when building a kernel.
Decompression speed is relevant at each boot.
- If you have any problems with bzip2 or lzma compressed
- kernels, mail me (Alain Knaff) <alain@knaff.lu>. (An older
- version of this functionality (bzip2 only), for 2.4, was
- supplied by Christian Ludwig)
-
High compression options are mostly useful for users, who
are low on disk space (embedded systems), but for whom ram
size matters less.
@@ -226,22 +218,12 @@ config KERNEL_GZIP
The old and tried gzip compression. It provides a good balance
between compression ratio and decompression speed.
-config KERNEL_BZIP2
- bool "Bzip2"
- depends on HAVE_KERNEL_BZIP2
- help
- Its compression ratio and speed is intermediate.
- Decompression speed is slowest among the choices. The kernel
- size is about 10% smaller with bzip2, in comparison to gzip.
- Bzip2 uses a large amount of memory. For modern kernels you
- will need at least 8MB RAM or more for booting.
-
config KERNEL_LZMA
bool "LZMA"
depends on HAVE_KERNEL_LZMA
help
This compression algorithm's ratio is best. Decompression speed
- is between gzip and bzip2. Compression is slowest.
+ is similar to XZ. Compression is slowest.
The kernel size is about 33% smaller with LZMA in comparison to gzip.
config KERNEL_XZ
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index ac021ae6e6fa..5b7114743c9a 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -48,7 +48,6 @@ static int __init crd_load(decompress_fn deco);
* cramfs
* squashfs
* gzip
- * bzip2
* lzma
* xz
* lzo
diff --git a/kernel/configs/tiny.config b/kernel/configs/tiny.config
index 8a44b93da0f3..2ca3fb830ca7 100644
--- a/kernel/configs/tiny.config
+++ b/kernel/configs/tiny.config
@@ -1,7 +1,6 @@
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_KERNEL_GZIP is not set
-# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
diff --git a/lib/Kconfig b/lib/Kconfig
index b46a9fd122c8..1d33e5e70f0e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -324,9 +324,6 @@ config DECOMPRESS_GZIP
select ZLIB_INFLATE
tristate
-config DECOMPRESS_BZIP2
- tristate
-
config DECOMPRESS_LZMA
tristate
diff --git a/lib/Makefile b/lib/Makefile
index ce45af50983a..0e0f3390c16b 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -192,7 +192,6 @@ obj-$(CONFIG_XZ_DEC) += xz/
obj-$(CONFIG_RAID6_PQ) += raid6/
lib-$(CONFIG_DECOMPRESS_GZIP) += decompress_inflate.o
-lib-$(CONFIG_DECOMPRESS_BZIP2) += decompress_bunzip2.o
lib-$(CONFIG_DECOMPRESS_LZMA) += decompress_unlzma.o
lib-$(CONFIG_DECOMPRESS_XZ) += decompress_unxz.o
lib-$(CONFIG_DECOMPRESS_LZO) += decompress_unlzo.o
diff --git a/lib/decompress.c b/lib/decompress.c
index ab3fc90ffc64..7e272d7fd27a 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -7,7 +7,6 @@
#include <linux/decompress/generic.h>
-#include <linux/decompress/bunzip2.h>
#include <linux/decompress/unlzma.h>
#include <linux/decompress/unxz.h>
#include <linux/decompress/inflate.h>
@@ -23,9 +22,6 @@
#ifndef CONFIG_DECOMPRESS_GZIP
# define gunzip NULL
#endif
-#ifndef CONFIG_DECOMPRESS_BZIP2
-# define bunzip2 NULL
-#endif
#ifndef CONFIG_DECOMPRESS_LZMA
# define unlzma NULL
#endif
@@ -51,7 +47,6 @@ struct compress_format {
static const struct compress_format compressed_formats[] __initconst = {
{ {0x1f, 0x8b}, "gzip", gunzip },
{ {0x1f, 0x9e}, "gzip", gunzip },
- { {0x42, 0x5a}, "bzip2", bunzip2 },
{ {0x5d, 0x00}, "lzma", unlzma },
{ {0xfd, 0x37}, "xz", unxz },
{ {0x89, 0x4c}, "lzo", unlzo },
diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
deleted file mode 100644
index c72c865032fa..000000000000
--- a/lib/decompress_bunzip2.c
+++ /dev/null
@@ -1,756 +0,0 @@
-/* Small bzip2 deflate implementation, by Rob Landley (rob@landley.net).
-
- Based on bzip2 decompression code by Julian R Seward (jseward@acm.org),
- which also acknowledges contributions by Mike Burrows, David Wheeler,
- Peter Fenwick, Alistair Moffat, Radford Neal, Ian H. Witten,
- Robert Sedgewick, and Jon L. Bentley.
-
- This code is licensed under the LGPLv2:
- LGPL (http://www.gnu.org/copyleft/lgpl.html
-*/
-
-/*
- Size and speed optimizations by Manuel Novoa III (mjn3@codepoet.org).
-
- More efficient reading of Huffman codes, a streamlined read_bunzip()
- function, and various other tweaks. In (limited) tests, approximately
- 20% faster than bzcat on x86 and about 10% faster on arm.
-
- Note that about 2/3 of the time is spent in read_unzip() reversing
- the Burrows-Wheeler transformation. Much of that time is delay
- resulting from cache misses.
-
- I would ask that anyone benefiting from this work, especially those
- using it in commercial products, consider making a donation to my local
- non-profit hospice organization in the name of the woman I loved, who
- passed away Feb. 12, 2003.
-
- In memory of Toni W. Hagan
-
- Hospice of Acadiana, Inc.
- 2600 Johnston St., Suite 200
- Lafayette, LA 70503-3240
-
- Phone (337) 232-1234 or 1-800-738-2226
- Fax (337) 232-1297
-
- https://www.hospiceacadiana.com/
-
- Manuel
- */
-
-/*
- Made it fit for running in Linux Kernel by Alain Knaff (alain@knaff.lu)
-*/
-
-
-#ifdef STATIC
-#define PREBOOT
-#else
-#include <linux/decompress/bunzip2.h>
-#endif /* STATIC */
-
-#include <linux/decompress/mm.h>
-#include <linux/crc32poly.h>
-
-#ifndef INT_MAX
-#define INT_MAX 0x7fffffff
-#endif
-
-/* Constants for Huffman coding */
-#define MAX_GROUPS 6
-#define GROUP_SIZE 50 /* 64 would have been more efficient */
-#define MAX_HUFCODE_BITS 20 /* Longest Huffman code allowed */
-#define MAX_SYMBOLS 258 /* 256 literals + RUNA + RUNB */
-#define SYMBOL_RUNA 0
-#define SYMBOL_RUNB 1
-
-/* Status return values */
-#define RETVAL_OK 0
-#define RETVAL_LAST_BLOCK (-1)
-#define RETVAL_NOT_BZIP_DATA (-2)
-#define RETVAL_UNEXPECTED_INPUT_EOF (-3)
-#define RETVAL_UNEXPECTED_OUTPUT_EOF (-4)
-#define RETVAL_DATA_ERROR (-5)
-#define RETVAL_OUT_OF_MEMORY (-6)
-#define RETVAL_OBSOLETE_INPUT (-7)
-
-/* Other housekeeping constants */
-#define BZIP2_IOBUF_SIZE 4096
-
-/* This is what we know about each Huffman coding group */
-struct group_data {
- /* We have an extra slot at the end of limit[] for a sentinal value. */
- int limit[MAX_HUFCODE_BITS+1];
- int base[MAX_HUFCODE_BITS];
- int permute[MAX_SYMBOLS];
- int minLen, maxLen;
-};
-
-/* Structure holding all the housekeeping data, including IO buffers and
- memory that persists between calls to bunzip */
-struct bunzip_data {
- /* State for interrupting output loop */
- int writeCopies, writePos, writeRunCountdown, writeCount, writeCurrent;
- /* I/O tracking data (file handles, buffers, positions, etc.) */
- long (*fill)(void*, unsigned long);
- long inbufCount, inbufPos /*, outbufPos*/;
- unsigned char *inbuf /*,*outbuf*/;
- unsigned int inbufBitCount, inbufBits;
- /* The CRC values stored in the block header and calculated from the
- data */
- unsigned int crc32Table[256], headerCRC, totalCRC, writeCRC;
- /* Intermediate buffer and its size (in bytes) */
- unsigned int *dbuf, dbufSize;
- /* These things are a bit too big to go on the stack */
- unsigned char selectors[32768]; /* nSelectors = 15 bits */
- struct group_data groups[MAX_GROUPS]; /* Huffman coding tables */
- int io_error; /* non-zero if we have IO error */
- int byteCount[256];
- unsigned char symToByte[256], mtfSymbol[256];
-};
-
-
-/* Return the next nnn bits of input. All reads from the compressed input
- are done through this function. All reads are big endian */
-static unsigned int INIT get_bits(struct bunzip_data *bd, char bits_wanted)
-{
- unsigned int bits = 0;
-
- /* If we need to get more data from the byte buffer, do so.
- (Loop getting one byte at a time to enforce endianness and avoid
- unaligned access.) */
- while (bd->inbufBitCount < bits_wanted) {
- /* If we need to read more data from file into byte buffer, do
- so */
- if (bd->inbufPos == bd->inbufCount) {
- if (bd->io_error)
- return 0;
- bd->inbufCount = bd->fill(bd->inbuf, BZIP2_IOBUF_SIZE);
- if (bd->inbufCount <= 0) {
- bd->io_error = RETVAL_UNEXPECTED_INPUT_EOF;
- return 0;
- }
- bd->inbufPos = 0;
- }
- /* Avoid 32-bit overflow (dump bit buffer to top of output) */
- if (bd->inbufBitCount >= 24) {
- bits = bd->inbufBits&((1 << bd->inbufBitCount)-1);
- bits_wanted -= bd->inbufBitCount;
- bits <<= bits_wanted;
- bd->inbufBitCount = 0;
- }
- /* Grab next 8 bits of input from buffer. */
- bd->inbufBits = (bd->inbufBits << 8)|bd->inbuf[bd->inbufPos++];
- bd->inbufBitCount += 8;
- }
- /* Calculate result */
- bd->inbufBitCount -= bits_wanted;
- bits |= (bd->inbufBits >> bd->inbufBitCount)&((1 << bits_wanted)-1);
-
- return bits;
-}
-
-/* Unpacks the next block and sets up for the inverse burrows-wheeler step. */
-
-static int INIT get_next_block(struct bunzip_data *bd)
-{
- struct group_data *hufGroup = NULL;
- int *base = NULL;
- int *limit = NULL;
- int dbufCount, nextSym, dbufSize, groupCount, selector,
- i, j, k, t, runPos, symCount, symTotal, nSelectors, *byteCount;
- unsigned char uc, *symToByte, *mtfSymbol, *selectors;
- unsigned int *dbuf, origPtr;
-
- dbuf = bd->dbuf;
- dbufSize = bd->dbufSize;
- selectors = bd->selectors;
- byteCount = bd->byteCount;
- symToByte = bd->symToByte;
- mtfSymbol = bd->mtfSymbol;
-
- /* Read in header signature and CRC, then validate signature.
- (last block signature means CRC is for whole file, return now) */
- i = get_bits(bd, 24);
- j = get_bits(bd, 24);
- bd->headerCRC = get_bits(bd, 32);
- if ((i == 0x177245) && (j == 0x385090))
- return RETVAL_LAST_BLOCK;
- if ((i != 0x314159) || (j != 0x265359))
- return RETVAL_NOT_BZIP_DATA;
- /* We can add support for blockRandomised if anybody complains.
- There was some code for this in busybox 1.0.0-pre3, but nobody ever
- noticed that it didn't actually work. */
- if (get_bits(bd, 1))
- return RETVAL_OBSOLETE_INPUT;
- origPtr = get_bits(bd, 24);
- if (origPtr >= dbufSize)
- return RETVAL_DATA_ERROR;
- /* mapping table: if some byte values are never used (encoding things
- like ascii text), the compression code removes the gaps to have fewer
- symbols to deal with, and writes a sparse bitfield indicating which
- values were present. We make a translation table to convert the
- symbols back to the corresponding bytes. */
- t = get_bits(bd, 16);
- symTotal = 0;
- for (i = 0; i < 16; i++) {
- if (t&(1 << (15-i))) {
- k = get_bits(bd, 16);
- for (j = 0; j < 16; j++)
- if (k&(1 << (15-j)))
- symToByte[symTotal++] = (16*i)+j;
- }
- }
- /* How many different Huffman coding groups does this block use? */
- groupCount = get_bits(bd, 3);
- if (groupCount < 2 || groupCount > MAX_GROUPS)
- return RETVAL_DATA_ERROR;
- /* nSelectors: Every GROUP_SIZE many symbols we select a new
- Huffman coding group. Read in the group selector list,
- which is stored as MTF encoded bit runs. (MTF = Move To
- Front, as each value is used it's moved to the start of the
- list.) */
- nSelectors = get_bits(bd, 15);
- if (!nSelectors)
- return RETVAL_DATA_ERROR;
- for (i = 0; i < groupCount; i++)
- mtfSymbol[i] = i;
- for (i = 0; i < nSelectors; i++) {
- /* Get next value */
- for (j = 0; get_bits(bd, 1); j++)
- if (j >= groupCount)
- return RETVAL_DATA_ERROR;
- /* Decode MTF to get the next selector */
- uc = mtfSymbol[j];
- for (; j; j--)
- mtfSymbol[j] = mtfSymbol[j-1];
- mtfSymbol[0] = selectors[i] = uc;
- }
- /* Read the Huffman coding tables for each group, which code
- for symTotal literal symbols, plus two run symbols (RUNA,
- RUNB) */
- symCount = symTotal+2;
- for (j = 0; j < groupCount; j++) {
- unsigned char length[MAX_SYMBOLS], temp[MAX_HUFCODE_BITS+1];
- int minLen, maxLen, pp;
- /* Read Huffman code lengths for each symbol. They're
- stored in a way similar to mtf; record a starting
- value for the first symbol, and an offset from the
- previous value for everys symbol after that.
- (Subtracting 1 before the loop and then adding it
- back at the end is an optimization that makes the
- test inside the loop simpler: symbol length 0
- becomes negative, so an unsigned inequality catches
- it.) */
- t = get_bits(bd, 5)-1;
- for (i = 0; i < symCount; i++) {
- for (;;) {
- if (((unsigned)t) > (MAX_HUFCODE_BITS-1))
- return RETVAL_DATA_ERROR;
-
- /* If first bit is 0, stop. Else
- second bit indicates whether to
- increment or decrement the value.
- Optimization: grab 2 bits and unget
- the second if the first was 0. */
-
- k = get_bits(bd, 2);
- if (k < 2) {
- bd->inbufBitCount++;
- break;
- }
- /* Add one if second bit 1, else
- * subtract 1. Avoids if/else */
- t += (((k+1)&2)-1);
- }
- /* Correct for the initial -1, to get the
- * final symbol length */
- length[i] = t+1;
- }
- /* Find largest and smallest lengths in this group */
- minLen = maxLen = length[0];
-
- for (i = 1; i < symCount; i++) {
- if (length[i] > maxLen)
- maxLen = length[i];
- else if (length[i] < minLen)
- minLen = length[i];
- }
-
- /* Calculate permute[], base[], and limit[] tables from
- * length[].
- *
- * permute[] is the lookup table for converting
- * Huffman coded symbols into decoded symbols. base[]
- * is the amount to subtract from the value of a
- * Huffman symbol of a given length when using
- * permute[].
- *
- * limit[] indicates the largest numerical value a
- * symbol with a given number of bits can have. This
- * is how the Huffman codes can vary in length: each
- * code with a value > limit[length] needs another
- * bit.
- */
- hufGroup = bd->groups+j;
- hufGroup->minLen = minLen;
- hufGroup->maxLen = maxLen;
- /* Note that minLen can't be smaller than 1, so we
- adjust the base and limit array pointers so we're
- not always wasting the first entry. We do this
- again when using them (during symbol decoding).*/
- base = hufGroup->base-1;
- limit = hufGroup->limit-1;
- /* Calculate permute[]. Concurrently, initialize
- * temp[] and limit[]. */
- pp = 0;
- for (i = minLen; i <= maxLen; i++) {
- temp[i] = limit[i] = 0;
- for (t = 0; t < symCount; t++)
- if (length[t] == i)
- hufGroup->permute[pp++] = t;
- }
- /* Count symbols coded for at each bit length */
- for (i = 0; i < symCount; i++)
- temp[length[i]]++;
- /* Calculate limit[] (the largest symbol-coding value
- *at each bit length, which is (previous limit <<
- *1)+symbols at this level), and base[] (number of
- *symbols to ignore at each bit length, which is limit
- *minus the cumulative count of symbols coded for
- *already). */
- pp = t = 0;
- for (i = minLen; i < maxLen; i++) {
- pp += temp[i];
- /* We read the largest possible symbol size
- and then unget bits after determining how
- many we need, and those extra bits could be
- set to anything. (They're noise from
- future symbols.) At each level we're
- really only interested in the first few
- bits, so here we set all the trailing
- to-be-ignored bits to 1 so they don't
- affect the value > limit[length]
- comparison. */
- limit[i] = (pp << (maxLen - i)) - 1;
- pp <<= 1;
- base[i+1] = pp-(t += temp[i]);
- }
- limit[maxLen+1] = INT_MAX; /* Sentinal value for
- * reading next sym. */
- limit[maxLen] = pp+temp[maxLen]-1;
- base[minLen] = 0;
- }
- /* We've finished reading and digesting the block header. Now
- read this block's Huffman coded symbols from the file and
- undo the Huffman coding and run length encoding, saving the
- result into dbuf[dbufCount++] = uc */
-
- /* Initialize symbol occurrence counters and symbol Move To
- * Front table */
- for (i = 0; i < 256; i++) {
- byteCount[i] = 0;
- mtfSymbol[i] = (unsigned char)i;
- }
- /* Loop through compressed symbols. */
- runPos = dbufCount = symCount = selector = 0;
- for (;;) {
- /* Determine which Huffman coding group to use. */
- if (!(symCount--)) {
- symCount = GROUP_SIZE-1;
- if (selector >= nSelectors)
- return RETVAL_DATA_ERROR;
- hufGroup = bd->groups+selectors[selector++];
- base = hufGroup->base-1;
- limit = hufGroup->limit-1;
- }
- /* Read next Huffman-coded symbol. */
- /* Note: It is far cheaper to read maxLen bits and
- back up than it is to read minLen bits and then an
- additional bit at a time, testing as we go.
- Because there is a trailing last block (with file
- CRC), there is no danger of the overread causing an
- unexpected EOF for a valid compressed file. As a
- further optimization, we do the read inline
- (falling back to a call to get_bits if the buffer
- runs dry). The following (up to got_huff_bits:) is
- equivalent to j = get_bits(bd, hufGroup->maxLen);
- */
- while (bd->inbufBitCount < hufGroup->maxLen) {
- if (bd->inbufPos == bd->inbufCount) {
- j = get_bits(bd, hufGroup->maxLen);
- goto got_huff_bits;
- }
- bd->inbufBits =
- (bd->inbufBits << 8)|bd->inbuf[bd->inbufPos++];
- bd->inbufBitCount += 8;
- };
- bd->inbufBitCount -= hufGroup->maxLen;
- j = (bd->inbufBits >> bd->inbufBitCount)&
- ((1 << hufGroup->maxLen)-1);
-got_huff_bits:
- /* Figure how many bits are in next symbol and
- * unget extras */
- i = hufGroup->minLen;
- while (j > limit[i])
- ++i;
- bd->inbufBitCount += (hufGroup->maxLen - i);
- /* Huffman decode value to get nextSym (with bounds checking) */
- if ((i > hufGroup->maxLen)
- || (((unsigned)(j = (j>>(hufGroup->maxLen-i))-base[i]))
- >= MAX_SYMBOLS))
- return RETVAL_DATA_ERROR;
- nextSym = hufGroup->permute[j];
- /* We have now decoded the symbol, which indicates
- either a new literal byte, or a repeated run of the
- most recent literal byte. First, check if nextSym
- indicates a repeated run, and if so loop collecting
- how many times to repeat the last literal. */
- if (((unsigned)nextSym) <= SYMBOL_RUNB) { /* RUNA or RUNB */
- /* If this is the start of a new run, zero out
- * counter */
- if (!runPos) {
- runPos = 1;
- t = 0;
- }
- /* Neat trick that saves 1 symbol: instead of
- or-ing 0 or 1 at each bit position, add 1
- or 2 instead. For example, 1011 is 1 << 0
- + 1 << 1 + 2 << 2. 1010 is 2 << 0 + 2 << 1
- + 1 << 2. You can make any bit pattern
- that way using 1 less symbol than the basic
- or 0/1 method (except all bits 0, which
- would use no symbols, but a run of length 0
- doesn't mean anything in this context).
- Thus space is saved. */
- t += (runPos << nextSym);
- /* +runPos if RUNA; +2*runPos if RUNB */
-
- runPos <<= 1;
- continue;
- }
- /* When we hit the first non-run symbol after a run,
- we now know how many times to repeat the last
- literal, so append that many copies to our buffer
- of decoded symbols (dbuf) now. (The last literal
- used is the one at the head of the mtfSymbol
- array.) */
- if (runPos) {
- runPos = 0;
- if (dbufCount+t >= dbufSize)
- return RETVAL_DATA_ERROR;
-
- uc = symToByte[mtfSymbol[0]];
- byteCount[uc] += t;
- while (t--)
- dbuf[dbufCount++] = uc;
- }
- /* Is this the terminating symbol? */
- if (nextSym > symTotal)
- break;
- /* At this point, nextSym indicates a new literal
- character. Subtract one to get the position in the
- MTF array at which this literal is currently to be
- found. (Note that the result can't be -1 or 0,
- because 0 and 1 are RUNA and RUNB. But another
- instance of the first symbol in the mtf array,
- position 0, would have been handled as part of a
- run above. Therefore 1 unused mtf position minus 2
- non-literal nextSym values equals -1.) */
- if (dbufCount >= dbufSize)
- return RETVAL_DATA_ERROR;
- i = nextSym - 1;
- uc = mtfSymbol[i];
- /* Adjust the MTF array. Since we typically expect to
- *move only a small number of symbols, and are bound
- *by 256 in any case, using memmove here would
- *typically be bigger and slower due to function call
- *overhead and other assorted setup costs. */
- do {
- mtfSymbol[i] = mtfSymbol[i-1];
- } while (--i);
- mtfSymbol[0] = uc;
- uc = symToByte[uc];
- /* We have our literal byte. Save it into dbuf. */
- byteCount[uc]++;
- dbuf[dbufCount++] = (unsigned int)uc;
- }
- /* At this point, we've read all the Huffman-coded symbols
- (and repeated runs) for this block from the input stream,
- and decoded them into the intermediate buffer. There are
- dbufCount many decoded bytes in dbuf[]. Now undo the
- Burrows-Wheeler transform on dbuf. See
- http://dogma.net/markn/articles/bwt/bwt.htm
- */
- /* Turn byteCount into cumulative occurrence counts of 0 to n-1. */
- j = 0;
- for (i = 0; i < 256; i++) {
- k = j+byteCount[i];
- byteCount[i] = j;
- j = k;
- }
- /* Figure out what order dbuf would be in if we sorted it. */
- for (i = 0; i < dbufCount; i++) {
- uc = (unsigned char)(dbuf[i] & 0xff);
- dbuf[byteCount[uc]] |= (i << 8);
- byteCount[uc]++;
- }
- /* Decode first byte by hand to initialize "previous" byte.
- Note that it doesn't get output, and if the first three
- characters are identical it doesn't qualify as a run (hence
- writeRunCountdown = 5). */
- if (dbufCount) {
- if (origPtr >= dbufCount)
- return RETVAL_DATA_ERROR;
- bd->writePos = dbuf[origPtr];
- bd->writeCurrent = (unsigned char)(bd->writePos&0xff);
- bd->writePos >>= 8;
- bd->writeRunCountdown = 5;
- }
- bd->writeCount = dbufCount;
-
- return RETVAL_OK;
-}
-
-/* Undo burrows-wheeler transform on intermediate buffer to produce output.
- If start_bunzip was initialized with out_fd =-1, then up to len bytes of
- data are written to outbuf. Return value is number of bytes written or
- error (all errors are negative numbers). If out_fd!=-1, outbuf and len
- are ignored, data is written to out_fd and return is RETVAL_OK or error.
-*/
-
-static int INIT read_bunzip(struct bunzip_data *bd, char *outbuf, int len)
-{
- const unsigned int *dbuf;
- int pos, xcurrent, previous, gotcount;
-
- /* If last read was short due to end of file, return last block now */
- if (bd->writeCount < 0)
- return bd->writeCount;
-
- gotcount = 0;
- dbuf = bd->dbuf;
- pos = bd->writePos;
- xcurrent = bd->writeCurrent;
-
- /* We will always have pending decoded data to write into the output
- buffer unless this is the very first call (in which case we haven't
- Huffman-decoded a block into the intermediate buffer yet). */
-
- if (bd->writeCopies) {
- /* Inside the loop, writeCopies means extra copies (beyond 1) */
- --bd->writeCopies;
- /* Loop outputting bytes */
- for (;;) {
- /* If the output buffer is full, snapshot
- * state and return */
- if (gotcount >= len) {
- bd->writePos = pos;
- bd->writeCurrent = xcurrent;
- bd->writeCopies++;
- return len;
- }
- /* Write next byte into output buffer, updating CRC */
- outbuf[gotcount++] = xcurrent;
- bd->writeCRC = (((bd->writeCRC) << 8)
- ^bd->crc32Table[((bd->writeCRC) >> 24)
- ^xcurrent]);
- /* Loop now if we're outputting multiple
- * copies of this byte */
- if (bd->writeCopies) {
- --bd->writeCopies;
- continue;
- }
-decode_next_byte:
- if (!bd->writeCount--)
- break;
- /* Follow sequence vector to undo
- * Burrows-Wheeler transform */
- previous = xcurrent;
- pos = dbuf[pos];
- xcurrent = pos&0xff;
- pos >>= 8;
- /* After 3 consecutive copies of the same
- byte, the 4th is a repeat count. We count
- down from 4 instead *of counting up because
- testing for non-zero is faster */
- if (--bd->writeRunCountdown) {
- if (xcurrent != previous)
- bd->writeRunCountdown = 4;
- } else {
- /* We have a repeated run, this byte
- * indicates the count */
- bd->writeCopies = xcurrent;
- xcurrent = previous;
- bd->writeRunCountdown = 5;
- /* Sometimes there are just 3 bytes
- * (run length 0) */
- if (!bd->writeCopies)
- goto decode_next_byte;
- /* Subtract the 1 copy we'd output
- * anyway to get extras */
- --bd->writeCopies;
- }
- }
- /* Decompression of this block completed successfully */
- bd->writeCRC = ~bd->writeCRC;
- bd->totalCRC = ((bd->totalCRC << 1) |
- (bd->totalCRC >> 31)) ^ bd->writeCRC;
- /* If this block had a CRC error, force file level CRC error. */
- if (bd->writeCRC != bd->headerCRC) {
- bd->totalCRC = bd->headerCRC+1;
- return RETVAL_LAST_BLOCK;
- }
- }
-
- /* Refill the intermediate buffer by Huffman-decoding next
- * block of input */
- /* (previous is just a convenient unused temp variable here) */
- previous = get_next_block(bd);
- if (previous) {
- bd->writeCount = previous;
- return (previous != RETVAL_LAST_BLOCK) ? previous : gotcount;
- }
- bd->writeCRC = 0xffffffffUL;
- pos = bd->writePos;
- xcurrent = bd->writeCurrent;
- goto decode_next_byte;
-}
-
-static long INIT nofill(void *buf, unsigned long len)
-{
- return -1;
-}
-
-/* Allocate the structure, read file header. If in_fd ==-1, inbuf must contain
- a complete bunzip file (len bytes long). If in_fd!=-1, inbuf and len are
- ignored, and data is read from file handle into temporary buffer. */
-static int INIT start_bunzip(struct bunzip_data **bdp, void *inbuf, long len,
- long (*fill)(void*, unsigned long))
-{
- struct bunzip_data *bd;
- unsigned int i, j, c;
- const unsigned int BZh0 =
- (((unsigned int)'B') << 24)+(((unsigned int)'Z') << 16)
- +(((unsigned int)'h') << 8)+(unsigned int)'0';
-
- /* Figure out how much data to allocate */
- i = sizeof(struct bunzip_data);
-
- /* Allocate bunzip_data. Most fields initialize to zero. */
- bd = *bdp = malloc(i);
- if (!bd)
- return RETVAL_OUT_OF_MEMORY;
- memset(bd, 0, sizeof(struct bunzip_data));
- /* Setup input buffer */
- bd->inbuf = inbuf;
- bd->inbufCount = len;
- if (fill != NULL)
- bd->fill = fill;
- else
- bd->fill = nofill;
-
- /* Init the CRC32 table (big endian) */
- for (i = 0; i < 256; i++) {
- c = i << 24;
- for (j = 8; j; j--)
- c = c&0x80000000 ? (c << 1)^(CRC32_POLY_BE) : (c << 1);
- bd->crc32Table[i] = c;
- }
-
- /* Ensure that file starts with "BZh['1'-'9']." */
- i = get_bits(bd, 32);
- if (((unsigned int)(i-BZh0-1)) >= 9)
- return RETVAL_NOT_BZIP_DATA;
-
- /* Fourth byte (ascii '1'-'9'), indicates block size in units of 100k of
- uncompressed data. Allocate intermediate buffer for block. */
- bd->dbufSize = 100000*(i-BZh0);
-
- bd->dbuf = large_malloc(bd->dbufSize * sizeof(int));
- if (!bd->dbuf)
- return RETVAL_OUT_OF_MEMORY;
- return RETVAL_OK;
-}
-
-/* Example usage: decompress src_fd to dst_fd. (Stops at end of bzip2 data,
- not end of file.) */
-STATIC int INIT bunzip2(unsigned char *buf, long len,
- long (*fill)(void*, unsigned long),
- long (*flush)(void*, unsigned long),
- unsigned char *outbuf,
- long *pos,
- void(*error)(char *x))
-{
- struct bunzip_data *bd;
- int i = -1;
- unsigned char *inbuf;
-
- if (flush)
- outbuf = malloc(BZIP2_IOBUF_SIZE);
-
- if (!outbuf) {
- error("Could not allocate output buffer");
- return RETVAL_OUT_OF_MEMORY;
- }
- if (buf)
- inbuf = buf;
- else
- inbuf = malloc(BZIP2_IOBUF_SIZE);
- if (!inbuf) {
- error("Could not allocate input buffer");
- i = RETVAL_OUT_OF_MEMORY;
- goto exit_0;
- }
- i = start_bunzip(&bd, inbuf, len, fill);
- if (!i) {
- for (;;) {
- i = read_bunzip(bd, outbuf, BZIP2_IOBUF_SIZE);
- if (i <= 0)
- break;
- if (!flush)
- outbuf += i;
- else
- if (i != flush(outbuf, i)) {
- i = RETVAL_UNEXPECTED_OUTPUT_EOF;
- break;
- }
- }
- }
- /* Check CRC and release memory */
- if (i == RETVAL_LAST_BLOCK) {
- if (bd->headerCRC != bd->totalCRC)
- error("Data integrity error when decompressing.");
- else
- i = RETVAL_OK;
- } else if (i == RETVAL_UNEXPECTED_OUTPUT_EOF) {
- error("Compressed file ends unexpectedly");
- }
- if (!bd)
- goto exit_1;
- if (bd->dbuf)
- large_free(bd->dbuf);
- if (pos)
- *pos = bd->inbufPos;
- free(bd);
-exit_1:
- if (!buf)
- free(inbuf);
-exit_0:
- if (flush)
- free(outbuf);
- return i;
-}
-
-#ifdef PREBOOT
-STATIC int INIT __decompress(unsigned char *buf, long len,
- long (*fill)(void*, unsigned long),
- long (*flush)(void*, unsigned long),
- unsigned char *outbuf, long olen,
- long *pos,
- void (*error)(char *x))
-{
- return bunzip2(buf, len - 4, fill, flush, outbuf, pos, error);
-}
-#endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 94133708889d..f05111c59a3b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -343,10 +343,7 @@ $(obj)/%.dt.yaml: $(src)/%.dts $(DTC) $(DT_TMP_SCHEMA) FORCE
dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
-# Bzip2
-# ---------------------------------------------------------------------------
-
-# Bzip2 and LZMA do not include size in file... so we have to fake that;
+# LZMA does not include size in file... so we have to fake that;
# append the size as a 32-bit littleendian number as gzip does.
size_append = printf $(shell \
dec_size=0; \
@@ -363,9 +360,6 @@ printf "%08x\n" $$dec_size | \
} \
)
-quiet_cmd_bzip2 = BZIP2 $@
- cmd_bzip2 = { cat $(real-prereqs) | $(KBZIP2) -9; $(size_append); } > $@
-
# Lzma
# ---------------------------------------------------------------------------
diff --git a/scripts/Makefile.package b/scripts/Makefile.package
index f952fb64789d..2c4a9dbc7e6e 100644
--- a/scripts/Makefile.package
+++ b/scripts/Makefile.package
@@ -127,7 +127,6 @@ util/PERF-VERSION-GEN $(CURDIR)/$(perf-tar)/); \
tar rf $(perf-tar).tar $(perf-tar)/HEAD $(perf-tar)/PERF-VERSION-FILE; \
rm -r $(perf-tar); \
$(if $(findstring tar-src,$@),, \
-$(if $(findstring bz2,$@),$(KBZIP2), \
$(if $(findstring gz,$@),$(KGZIP), \
$(if $(findstring xz,$@),$(XZ), \
$(error unknown target $@)))) \
diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index 936198a90477..91bcb50579c7 100755
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -118,7 +118,7 @@ case "${ARCH}" in
fi
;;
arm64)
- for i in Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo ; do
+ for i in Image.gz Image.lz4 Image.lzma Image.lzo ; do
if [ -f "${objtree}/arch/arm64/boot/${i}" ] ; then
cp -v -- "${objtree}/arch/arm64/boot/${i}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
break
diff --git a/usr/Kconfig b/usr/Kconfig
index 2599bc21c1b2..ba5ecb054df5 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -60,14 +60,6 @@ config RD_GZIP
Support loading of a gzip encoded initial ramdisk or cpio buffer.
If unsure, say Y.
-config RD_BZIP2
- bool "Support initial ramdisk/ramfs compressed using bzip2"
- default y
- select DECOMPRESS_BZIP2
- help
- Support loading of a bzip2 encoded initial ramdisk or cpio buffer
- If unsure, say N.
-
config RD_LZMA
bool "Support initial ramdisk/ramfs compressed using LZMA"
default y
@@ -143,19 +135,6 @@ config INITRAMFS_COMPRESSION_GZIP
supported by your build system as the gzip tool is present by default
on most distros.
-config INITRAMFS_COMPRESSION_BZIP2
- bool "Bzip2"
- depends on RD_BZIP2
- help
- It's compression ratio and speed is intermediate. Decompression speed
- is slowest among the choices. The initramfs size is about 10% smaller
- with bzip2, in comparison to gzip. Bzip2 uses a large amount of
- memory. For modern kernels you will need at least 8MB RAM or more for
- booting.
-
- If you choose this, keep in mind that you need to have the bzip2 tool
- available to be able to compress the initram.
-
config INITRAMFS_COMPRESSION_LZMA
bool "LZMA"
depends on RD_LZMA
@@ -175,9 +154,8 @@ config INITRAMFS_COMPRESSION_XZ
help
XZ uses the LZMA2 algorithm and has a large dictionary which may cause
problems on memory constrained systems. The initramfs size is about
- 30% smaller with XZ in comparison to gzip. Decompression speed is
- better than that of bzip2 but worse than gzip and LZO. Compression is
- slow.
+ 30% smaller with XZ in comparison to gzip. Compression and
+ decompression are slowest.
If you choose this, keep in mind that you may need to install the xz
tool to be able to compress the initram.
diff --git a/usr/Makefile b/usr/Makefile
index b1a81a40eab1..367bc5d4c759 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -3,14 +3,13 @@
# kbuild file for usr/ - including initramfs image
#
-# cmd_bzip2, cmd_lzma, cmd_lzo, cmd_lz4 from scripts/Makefile.lib appends the
+# cmd_lzma, cmd_lzo, cmd_lz4 from scripts/Makefile.lib appends the
# size at the end of the compressed file, which unfortunately does not work
# with unpack_to_rootfs(). Make size_append no-op.
override size_append := :
compress-y := shipped
compress-$(CONFIG_INITRAMFS_COMPRESSION_GZIP) := gzip
-compress-$(CONFIG_INITRAMFS_COMPRESSION_BZIP2) := bzip2
compress-$(CONFIG_INITRAMFS_COMPRESSION_LZMA) := lzma
compress-$(CONFIG_INITRAMFS_COMPRESSION_XZ) := xzmisc
compress-$(CONFIG_INITRAMFS_COMPRESSION_LZO) := lzo
--
2.29.2
^ permalink raw reply related [relevance 17%]
* RE: amdgpu crashes on OOM
@ 2020-10-26 14:50 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-10-26 14:50 UTC (permalink / raw)
To: Deucher, Alexander, amd-gfx, Wentland, Harry, Michel Dänzer,
Kazlauskas, Nicholas, Li, Sun peng (Leo)
Cc: linux-kernel
Excerpts from Deucher, Alexander's message of October 26, 2020 10:34 am:
> It was using kvzalloc, but was accidently dropped when that code was refactored. I just sent a patch to fix it.
Ah, that explains why I wasn't seeing it before. I was only looking at
changes in amdgpu_dm_atomic_commit_tail, not dc_create_state.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* amdgpu crashes on OOM
[not found] <1603684905.h43s1t0y05.none.ref@localhost>
@ 2020-10-26 4:29 93% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-10-26 4:29 UTC (permalink / raw)
To: Nicholas Kazlauskas, alexander.deucher, Harry Wentland, Leo Li, amd-gfx
Cc: linux-kernel
Hi,
I frequently encounter OOM on my system, mostly due to my own fault.
Recently, I noticed that not only does a swap storm happen and OOM
killer gets invoked, but the graphics output freezes permanently.
Checking the kernel messages, I see:
kworker/u24:4: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null)
CPU: 6 PID: 279469 Comm: kworker/u24:4 Tainted: G W 5.9.0-14732-g20b1adb60cf6 #2
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIOS P4.20 06/18/2020
Workqueue: events_unbound commit_work
Call Trace:
? dump_stack+0x57/0x6a
? warn_alloc.cold+0x69/0xcd
? __alloc_pages_direct_compact+0xfb/0x116
? __alloc_pages_slowpath.constprop.0+0x9c2/0xc14
? __alloc_pages_nodemask+0x143/0x167
? kmalloc_order+0x24/0x64
? dc_create_state+0x1a/0x4d
? amdgpu_dm_atomic_commit_tail+0x1b19/0x227d
followed by:
WARNING: CPU: 6 PID: 279469 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7511 amdgpu_dm_atomic_commit_tail+0x217c/0x227d
followed by:
BUG: unable to handle page fault for address: 0000000000012480
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
[ ... ]
RIP: 0010:dc_resource_state_copy_construct+0x10/0x455
[ ... ]
Call Trace:
? amdgpu_dm_atomic_commit_tail+0x2193/0x227
This area of code is quite odd:
dc_state_temp = dc_create_state(dm->dc);
ASSERT(dc_state_temp);
dc_state = dc_state_temp;
dc_resource_state_copy_construct_current(dm->dc, dc_state);
This ASSERT macro is misleading: unless CONFIG_DEBUG_KERNEL_DC is set,
it is actually WARN_ON_ONCE(!(expr)). Therefore, this code fails to
allocate memory (causing a warning to be printed), prints another
warning that it failed, then proceeds to immediately dereference it,
crashing the thread (and the kernel if panic_on_oops is set).
While I am not by any means a graphics or kernel expert, it seems to me
like there should be a better solution than crashing. If nothing else,
the OOM killer should be invoked and the operation retried. We may lose
some frames or see some corruption, but that's far better than totally
breaking.
Thanks,
Alex.
^ permalink raw reply [relevance 93%]
* Re: wine fails to start with seccomp updates for v5.9-rc1
@ 2020-08-07 17:51 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-08-07 17:51 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo, Linus Torvalds
Cc: Christian Brauner, Aleksa Sarai, Christoph Hellwig, Kees Cook,
Linux Kernel Mailing List, Matt Denton, Chris Palmer,
Robert Sesek, Sargun Dhillon, Shuah Khan, Tycho Andersen,
Will Drewry, Will Deacon, Yonghong Song
Excerpts from Thadeu Lima de Souza Cascardo's message of August 7, 2020 1:36 pm:
> On Fri, Aug 07, 2020 at 08:48:46AM -0700, Linus Torvalds wrote:
>> On Fri, Aug 7, 2020 at 8:19 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
>> >
>> > On Linus' master, wine fails to start with the following error:
>> >
>> > wine client error:0: write: Bad file descriptor
>> >
>> > This issue is not present on 5.8. It appears to be caused by failure to
>> > write to a pipe FD received via SCM_RIGHTS. Therefore, I tried reverting
>> > 9ecc6ea491f0, which resolved the issue.
>>
>> Would you mind trying to bisect exactly where it happens?
>>
>
> This report [1] seemed related and pointed out at c0029de50982 ("net/scm:
> Regularize compat handling of scm_detach_fds()"). The use of CMSG_USER_DATA
> instead of CMSG_COMPAT_DATA seems fishy.
>
> Alex, can you try applying the patch below?
>
> Cascardo.
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216156.html
>
>> I don't think any of the commits in that pull are supposed to change
>> semantics, and while reverting the whole merge shows that yes, that's
>> what brought in the problems, it would be good to pinpoint just which
>> change breaks so that we can fix just that thing.
>>
>> Kees, ideas?
>>
>> Linus
>
> ---
> diff --git a/net/compat.c b/net/compat.c
> index 703acb51c698..95ce707a30a3 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -294,7 +294,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct scm_cookie *scm)
> (struct compat_cmsghdr __user *)msg->msg_control;
> unsigned int o_flags = (msg->msg_flags & MSG_CMSG_CLOEXEC) ? O_CLOEXEC : 0;
> int fdmax = min_t(int, scm_max_fds_compat(msg), scm->fp->count);
> - int __user *cmsg_data = CMSG_USER_DATA(cm);
> + int __user *cmsg_data = CMSG_COMPAT_DATA(cm);
> int err = 0, i;
>
> for (i = 0; i < fdmax; i++) {
>
Yes, this seems to work.
Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Thanks!
^ permalink raw reply [relevance 99%]
* wine fails to start with seccomp updates for v5.9-rc1
[not found] <1596812929.lz7fuo8r2w.none.ref@localhost>
@ 2020-08-07 15:19 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-08-07 15:19 UTC (permalink / raw)
To: Kees Cook
Cc: Linus Torvalds, linux-kernel, Aleksa Sarai, Chris Palmer,
Christian Brauner, Christoph Hellwig, Matt Denton, Robert Sesek,
Thadeu Lima de Souza Cascardo, Sargun Dhillon, Shuah Khan,
Tycho Andersen, Will Deacon, Will Drewry, Yonghong Song
Hi,
On Linus' master, wine fails to start with the following error:
wine client error:0: write: Bad file descriptor
This issue is not present on 5.8. It appears to be caused by failure to
write to a pipe FD received via SCM_RIGHTS. Therefore, I tried reverting
9ecc6ea491f0, which resolved the issue.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* Re: Kernel compression benchmarks
@ 2020-07-01 17:32 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-07-01 17:32 UTC (permalink / raw)
To: Gao Xiang
Cc: Chris Mason, gregkh, Kees Cook, Kernel Team, Adam Borowski,
linux-kbuild, linux-kernel, mingo, Nick Terrell, Norbert Lange,
Petr Malat, Patrick Williams, Patrick Williams, rmikey,
Sedat Dilek, Nick Terrell, x86
Excerpts from Gao Xiang's message of July 1, 2020 11:50 am:
> Anyway, I think LZMA (xz) is still useful and which is more
> friendly to fixed-sized output compression than Zstd yet (But
> yeah, I'm not familar with all ZSTD internals. I will dig
> into that if I've more extra time).
Yes, I agree. If you look at the graphs, LZMA2 (xz/7zip) still produces
smaller results, even compared to zstd maximum settings, so definitely
LZMA2 should be kept, at least for now. I am only suggesting removing
LZMA, since it has no benefits over xz and zstd combination (bigger than
xz, slower than zstd).
>> - modern compressors (xz, lz4, zstd) decompress about as fast for each
>> compression level, only requiring more memory
>
> lz4 has fixed sliding window (dictionary, 64k), so it won't
> require more memory among different compression level when
> decompressing.
Yes, this is true. I tried to simplify among all compressors, but I
think I simplified too much. Thanks for clarifying.
Cheers,
Alex.
^ permalink raw reply [relevance 99%]
* Kernel compression benchmarks
[not found] <1588791882.08g1378g67.none.ref@localhost>
@ 2020-07-01 14:35 77% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-07-01 14:35 UTC (permalink / raw)
To: linux-kernel, Nick Terrell, Nick Terrell, Norbert Lange
Cc: Chris Mason, linux-kbuild, x86, gregkh, Petr Malat, Kees Cook,
Kernel Team, Adam Borowski, Patrick Williams, rmikey, mingo,
Patrick Williams, Sedat Dilek
[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]
Hi all,
ZSTD compression patches have been sent in a number of times over the
past few years. Every time, someone asks for benchmarks. Every time,
someone is concerned about compression time. Sometimes, someone provides
benchmarks.
But, as far as I can tell, nobody considered the compression parameters,
which have a significant impact on compression time and ratio.
So, I did some benchmarks myself, including all the compression levels
for each compressor.
Results:
The results are attached as SVG graphs and CSV data.
Summary:
- compression level, predictably, has a huge impact on compression time.
- compression level has virtually no impact on decompression time for
lz4, zstd, and some effect on others. interestingly, xz decompresses
slightly faster at higher compression levels (perhaps cache-related).
- gzip compresses slightly faster than zstd at medium compression levels.
- bzip2 sucks: slow compression, very slow decompression, poor ratio.
- lzma decompresses slightly faster than xz, but is also slightly larger.
- xz is smallest but with very slow compression and decompression.
- lz4 decompresses fastest.
- zstd is a good balanced default.
- 7z is much faster than xz, even with wine overhead.
Files:
For the kernel, I did "make allmodconfig; sed -i -e '/=m$/d' .config"
with a 5.6 kernel and gcc 9.3.0 on x86_64, then concatenated vmlinux.bin
and vmlinux.relocs. For the initramfs, I used the Arch Linux fallback
initramfs with default hooks.
Versions:
gzip 1.10
bzip2, a block-sorting file compressor. Version 1.0.8, 13-Jul-2019.
xz (XZ Utils) 5.2.5
*** LZ4 command line interface 64-bits v1.9.2, by Yann Collet ***
lzop 1.04
LZO library 2.10
*** zstd command line interface 64-bits v1.4.4, by Yann Collet ***
7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21
Notes:
I used the userspace versions of the decompressors, not the kernel
version. This is particularly relevant for xz, as the kernel xzminidec
is significantly slower than xz.
pigz is faster than gzip, but I used gzip as a common baseline.
7-Zip was run through wine with a persistent wineserver.
I ran the benchmark on a Ryzen 1600, with turbo boost turned off. Each
test was run only once, on the basis that any noise wouldn't disrupt the
overall curve, and also I don't want to spend hours waiting for the
results.
The current compression level defaults are:
- gzip -9
- bzip2 -9
- lzma -9
- xz --check=crc32 --x86 --lzma2=,dict=32MiB # except on ppc
- lzop -9
- lz4 -l -1
My conclusions:
- zstd is an improvement on almost all metrics.
- bzip2 and lzma should be removed post-haste.
- lzo should be removed once zstd is merged.
- compression level is important to consider for compression speed: the
default lz4 -1 compresses very fast but has a very poor compression
ratio. zstd -19 compresses barely better than zstd -18, but takes
significantly longer to compress.
- compression level should be configurable: lz4 -1 is useful, but so is
lz4 -9. zstd -1 is useful, but so is zstd -19. zstd -1 is useful for
developers who want kernel builds as fast as possible, zstd -19 for
everybody else.
- gzip is by far not the fastest compressor (even excluding cat)
- modern compressors (xz, lz4, zstd) decompress about as fast for each
compression level, only requiring more memory
- 7-Zip is much faster than xz, needs more research
- 7-Zip BCJ2 is slightly better than xz/BCJ. probably better filters for
all archs would be a good area of research, as apparently BCJ/BCJ2 are
intended only for 32-bit x86.
Thanks,
Alex.
[-- Attachment #2: kernel-compression-benchmarks.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 56733 bytes --]
^ permalink raw reply [relevance 77%]
* Re: AMD IOMMU + SME + amdgpu regression
@ 2020-06-22 15:30 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-06-22 15:30 UTC (permalink / raw)
To: Joerg Roedel
Cc: Andy Gross, Lu Baolu, Bjorn Andersson, Daniel Drake,
David Woodhouse, Gerald Schaefer, Christoph Hellwig,
Heiko Stuebner, Jean-Philippe Brucker, jonathan.derrick,
Jonathan Hunter, Joerg Roedel, Kukjin Kim, Krzysztof Kozlowski,
linux-arm-msm, linux-kernel, linux-mediatek, linux-rockchip,
linux-s390, linux-samsung-soc, linux-tegra, Matthias Brugger,
Marek Szyprowski, David Rientjes, Rob Clark, Robin Murphy,
Thierry Reding, virtualization, Will Deacon
Excerpts from Joerg Roedel's message of June 22, 2020 6:02 am:
> Hi Alex,
>
> On Thu, Jun 11, 2020 at 07:05:21PM -0400, Alex Xu (Hello71) wrote:
>> I am using an ASRock B450 Pro4 with Ryzen 1600 and ASUS RX 480. I don't
>> understand this code at all, but let me know what I can do to
>> troubleshoot.
>
> Does it boot without SME enabled?
>
>
> Regards,
>
> Joerg
>
Yes, it works with SME off with dbed452a078 ("dma-pool: decouple
DMA_REMAP from DMA_COHERENT_POOL") applied.
^ permalink raw reply [relevance 99%]
* Re: next-0519 on thinkpad x60: sound related? window manager crash
@ 2020-06-14 12:07 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-06-14 12:07 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, bp, hch, Christoph Hellwig, hpa, linux-kernel, mingo,
Pavel Machek, perex, rientjes, tglx, tiwai, x86
Excerpts from Takashi Iwai's message of June 14, 2020 5:54 am:
> On Sat, 13 Jun 2020 18:25:22 +0200,
> Alex Xu (Hello71) wrote:
>>
>> Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
>> > Thanks, so something still missing in the mmap handling, I guess.
>> >
>> > I've worked on two different branches for potential fixes of your
>> > problems. Could you test topic/dma-fix and topic/dma-fix2 branches?
>> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
>> > Just pull one of them onto Linus' git HEAD.
>> >
>> > I guess we'll go with David's new patch, but still it's interesting
>> > whether my changes do anything good actually.
>> >
>> >
>> > Takashi
>> >
>>
>> On torvalds 623f6dc593, topic/dma-fix causes sound to be output as
>> alternating half-second bursts of noise and a few seconds of silence.
>> topic/dma-fix2 appears to work properly.
>
> OK, thanks for the feedback! Just to make sure, you're using
> PulseAudio, right?
> If so, it was still something wrong about mmap, and the secondary
> method (the fallback to the continuous page) looks like a safer
> approach in the end.
>
> I suppose that David's fix will be merged sooner or later. Meanwhile
> I'll work on the change in the sound driver side to make things a bit
> more robust. They don't conflict and both good applicable.
>
>
> thanks,
>
> Takashi
>
Ah, no, I think that wasn't clear. I use ALSA directly with mostly
default configuration, except an asym sets separate default playback and
record devices.
asound.conf:
defaults.pcm.card 1
defaults.ctl.card 1
pcm.!default {
type asym
playback.pcm
{
type plug
slave.pcm "dmix"
}
capture.pcm
{
type plug
slave.pcm {
type dsnoop
ipc_key 6793
slave.pcm "hw:U0x46d0x81d"
}
}
}
I think I wasn't able to set defaults.pcm.dmix.card and
defaults.pcm.dsnoop.card for some reason, not sure why. I can try that,
but I don't think it will affect this mmap issue.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* Re: next-0519 on thinkpad x60: sound related? window manager crash
@ 2020-06-13 16:25 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-06-13 16:25 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, bp, hch, Christoph Hellwig, hpa, linux-kernel, mingo,
Pavel Machek, perex, rientjes, tglx, tiwai, x86
Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
> Thanks, so something still missing in the mmap handling, I guess.
>
> I've worked on two different branches for potential fixes of your
> problems. Could you test topic/dma-fix and topic/dma-fix2 branches?
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> Just pull one of them onto Linus' git HEAD.
>
> I guess we'll go with David's new patch, but still it's interesting
> whether my changes do anything good actually.
>
>
> Takashi
>
On torvalds 623f6dc593, topic/dma-fix causes sound to be output as
alternating half-second bursts of noise and a few seconds of silence.
topic/dma-fix2 appears to work properly.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* AMD IOMMU + SME + amdgpu regression
[not found] <1591915710.rakbpzst8h.none.ref@localhost>
@ 2020-06-11 23:05 89% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-06-11 23:05 UTC (permalink / raw)
To: Joerg Roedel, linux-kernel, David Rientjes, Christoph Hellwig
Cc: Will Deacon, Robin Murphy, Marek Szyprowski, Kukjin Kim,
Krzysztof Kozlowski, David Woodhouse, Lu Baolu, Andy Gross,
Bjorn Andersson, Matthias Brugger, Rob Clark, Heiko Stuebner,
Gerald Schaefer, Thierry Reding, Jonathan Hunter,
Jean-Philippe Brucker, Daniel Drake, jonathan.derrick,
linux-samsung-soc, linux-arm-msm, linux-mediatek, linux-rockchip,
linux-s390, linux-tegra, virtualization, Joerg Roedel
Hi,
amdgpu + IOMMU + SME is now working for me on 5.7, yay! But, it is
broken on torvalds master, boo. On boot, depending on which exact commit
I test, it either hangs immediately (with built-in driver, before
starting initramfs), displays some errors then hangs, or spams the
screen with many amdgpu errors.
I bisected the black screen hang to:
commit dce8d6964ebdb333383bacf5e7ab8c27df151218
Author: Joerg Roedel <jroedel@suse.de>
Date: Wed Apr 29 15:36:53 2020 +0200
iommu/amd: Convert to probe/release_device() call-backs
Convert the AMD IOMMU Driver to use the probe_device() and
release_device() call-backs of iommu_ops, so that the iommu core code
does the group and sysfs setup.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20200429133712.31431-16-joro@8bytes.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Testing torvalds master (623f6dc593) with the containing merge
(98bdc74b36) plus the DMA mapping merge (4e94d08734) reverted allows
amdgpu + IOMMU + SME to once again work.
I think that nobody is really working on amdgpu + SME, but it would be a
shame if it was supported and then incidentally broken by a small
change.
I am using an ASRock B450 Pro4 with Ryzen 1600 and ASUS RX 480. I don't
understand this code at all, but let me know what I can do to
troubleshoot.
Thanks,
Alex.
^ permalink raw reply [relevance 89%]
* Re: next-0519 on thinkpad x60: sound related? window manager crash
[not found] ` <<s5hr1uogtna.wl-tiwai@suse.de>
@ 2020-06-11 14:51 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-06-11 14:51 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, bp, hch, Christoph Hellwig, hpa, linux-kernel, mingo,
Pavel Machek, perex, rientjes, tglx, tiwai, x86
Excerpts from Takashi Iwai's message of June 9, 2020 11:12 am:
> On Tue, 09 Jun 2020 13:47:33 +0200,
> Christoph Hellwig wrote:
>>
>> Alex, can you try this patch?
>
> Also could you check whether just papering over the memset() call
> alone avoids the crash like below? For PulseAudio and dmix/dsnoop,
> it's the only code path that accesses the vmapped buffer, I believe.
>
> If this works more or less, I'll cook a more comprehensive fix.
>
>
> thanks,
>
> Takashi
>
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -754,9 +754,11 @@ static int snd_pcm_hw_params(struct snd_pcm_substream *substream,
> while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size)
> runtime->boundary *= 2;
>
> +#if 0
> /* clear the buffer for avoiding possible kernel info leaks */
> if (runtime->dma_area && !substream->ops->copy_user)
> memset(runtime->dma_area, 0, runtime->dma_bytes);
> +#endif
>
> snd_pcm_timer_resolution_change(substream);
> snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
>
Sorry, this patch doesn't work for me with SME off using abfbb29297c2.
David's newest submitted patch works for me, which I already replied to
separately.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* Re: [patch for-5.8] dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL
@ 2020-06-11 14:49 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-06-11 14:49 UTC (permalink / raw)
To: Christoph Hellwig, David Rientjes
Cc: alsa-devel, bp, hch, hpa, linux-kernel, mingo, Pavel Machek,
perex, tglx, tiwai, x86
Excerpts from David Rientjes's message of June 11, 2020 3:25 am:
> DMA_REMAP is an unnecessary requirement for AMD SEV, which requires
> DMA_COHERENT_POOL, so avoid selecting it when it is otherwise unnecessary.
>
> The only other requirement for DMA coherent pools is DMA_DIRECT_REMAP, so
> ensure that properly selects the config option when needed.
>
> Fixes: 82fef0ad811f ("x86/mm: unencrypted non-blocking DMA allocations use
> coherent pools")
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
> kernel/dma/Kconfig | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
Works for me with SME on or off with af7b480103, and with SME off in
abfbb29297. There is some regression with amdgpu and SME between those
two points, I need to check that out too. I haven't tested either before
or after with SEV (which I'm not even sure my system supports).
Regardless, this is a definite improvement.
Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* Re: next-0519 on thinkpad x60: sound related? window manager crash
@ 2020-06-11 14:51 99% ` Alex Xu (Hello71)
1 sibling, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-06-11 14:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: alsa-devel, bp, hch, hpa, linux-kernel, mingo, Pavel Machek,
perex, rientjes, tglx, tiwai, x86
Excerpts from Christoph Hellwig's message of June 9, 2020 7:47 am:
> Alex, can you try this patch?
>
> diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> index d4554f376160a9..10b06e575a7fc5 100644
> --- a/sound/core/Kconfig
> +++ b/sound/core/Kconfig
> @@ -192,6 +192,6 @@ config SND_VMASTER
>
> config SND_DMA_SGBUF
> def_bool y
> - depends on X86
> + depends on BROKEN
>
> source "sound/core/seq/Kconfig"
>
Sorry, this patch doesn't work for me with SME off using abfbb29297c2.
David's newest submitted patch works for me, which I already replied to
separately.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* Re: next-0519 on thinkpad x60: sound related? window manager crash
@ 2020-06-08 13:53 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-06-08 13:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: alsa-devel, bp, hch, hpa, linux-kernel, mingo, Pavel Machek,
perex, rientjes, tglx, tiwai, x86
Excerpts from Christoph Hellwig's message of June 8, 2020 2:19 am:
> Can you do a listing using gdb where this happens?
>
> gdb vmlinux
>
> l *(snd_pcm_hw_params+0x3f3)
>
> ?
>
(gdb) l *(snd_pcm_hw_params+0x3f3)
0xffffffff817efc85 is in snd_pcm_hw_params (.../linux/sound/core/pcm_native.c:749).
744 while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size)
745 runtime->boundary *= 2;
746
747 /* clear the buffer for avoiding possible kernel info leaks */
748 if (runtime->dma_area && !substream->ops->copy_user)
749 memset(runtime->dma_area, 0, runtime->dma_bytes);
750
751 snd_pcm_timer_resolution_change(substream);
752 snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
753
^ permalink raw reply [relevance 99%]
* Re: 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was Re: next-0519 on thinkpad x60: sound related? window manager crash
@ 2020-06-08 2:13 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-06-08 2:13 UTC (permalink / raw)
To: David Rientjes
Cc: alsa-devel, bp, hch, hch, hpa, linux-kernel, mingo, Pavel Machek,
perex, tglx, tiwai, x86
Excerpts from David Rientjes's message of June 7, 2020 8:57 pm:
> Thanks for trying it out, Alex. Would you mind sending your .config and
> command line? I assume either mem_encrypt=on or
> CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is enabled.
>
> Could you also give this a try?
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -99,10 +99,11 @@ static inline bool dma_should_alloc_from_pool(struct device *dev, gfp_t gfp,
> static inline bool dma_should_free_from_pool(struct device *dev,
> unsigned long attrs)
> {
> - if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
> + if (!IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
> + return false;
> + if (force_dma_unencrypted(dev))
> return true;
> - if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> - !force_dma_unencrypted(dev))
> + if (attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> return false;
> if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP))
> return true;
>
This patch doesn't work for me either. It has since occurred to me that
while I do have CONFIG_AMD_MEM_ENCYRPT=y, I have
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=n, because it was broken with
amdgpu (unfortunately a downgrade from radeon in this respect). Tried it
again just now and it looks like it's now able to enable KMS, but all it
displays is serious-looking errors.
Sorry for not mentioning that earlier. I'll send you my .config and
command line off-list.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* Re: 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was Re: next-0519 on thinkpad x60: sound related? window manager crash
@ 2020-06-07 22:53 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-06-07 22:53 UTC (permalink / raw)
To: David Rientjes
Cc: alsa-devel, bp, hch, hch, hpa, linux-kernel, mingo, perex, tglx,
tiwai, x86, Pavel Machek
Excerpts from David Rientjes's message of June 7, 2020 3:41 pm:
> On Sun, 7 Jun 2020, Pavel Machek wrote:
>
>> > I have a similar issue, caused between aaa2faab4ed8 and b170290c2836.
>> >
>> > [ 20.263098] BUG: unable to handle page fault for address: ffffb2b582cc2000
>> > [ 20.263104] #PF: supervisor write access in kernel mode
>> > [ 20.263105] #PF: error_code(0x000b) - reserved bit violation
>> > [ 20.263107] PGD 3fd03b067 P4D 3fd03b067 PUD 3fd03c067 PMD 3f8822067 PTE 8000273942ab2163
>> > [ 20.263113] Oops: 000b [#1] PREEMPT SMP
>> > [ 20.263117] CPU: 3 PID: 691 Comm: mpv Not tainted 5.7.0-11262-gb170290c2836 #1
>> > [ 20.263119] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIOS P4.10 03/05/2020
>> > [ 20.263125] RIP: 0010:__memset+0x24/0x30
>> > [ 20.263128] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
>> > [ 20.263131] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216
>> > [ 20.263133] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000
>> > [ 20.263134] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000
>> > [ 20.263136] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000
>> > [ 20.263137] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000
>> > [ 20.263139] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0
>> > [ 20.263141] FS: 00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000
>> > [ 20.263143] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > [ 20.263144] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0
>> > [ 20.263146] Call Trace:
>> > [ 20.263151] ? snd_pcm_hw_params+0x3f3/0x47a
>> > [ 20.263154] ? snd_pcm_common_ioctl+0xf2/0xf73
>> > [ 20.263158] ? snd_pcm_ioctl+0x1e/0x29
>> > [ 20.263161] ? ksys_ioctl+0x77/0x91
>> > [ 20.263163] ? __x64_sys_ioctl+0x11/0x14
>> > [ 20.263166] ? do_syscall_64+0x3d/0xf5
>> > [ 20.263170] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> > [ 20.263173] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev snd_usb_audio videobuf2_common snd_hwdep snd_usbmidi_lib input_leds snd_rawmidi led_class
>> > [ 20.263182] CR2: ffffb2b582cc2000
>> > [ 20.263184] ---[ end trace c6b47a774b91f0a0 ]---
>> > [ 20.263187] RIP: 0010:__memset+0x24/0x30
>> > [ 20.263190] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
>> > [ 20.263192] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216
>> > [ 20.263193] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000
>> > [ 20.263195] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000
>> > [ 20.263196] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000
>> > [ 20.263197] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000
>> > [ 20.263199] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0
>> > [ 20.263201] FS: 00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000
>> > [ 20.263202] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > [ 20.263204] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0
>> >
>> > I bisected this to 82fef0ad811f "x86/mm: unencrypted non-blocking DMA
>> > allocations use coherent pools". Reverting 1ee18de92927 resolves the
>> > issue.
>> >
>> > Looks like Thinkpad X60 doesn't have VT-d, but could still be DMA
>> > related.
>>
>> Note that newer -next releases seem to behave okay for me. The commit
>> pointed out by siection is really simple:
>>
>> AFAIK you could verify it is responsible by turning off
>> CONFIG_AMD_MEM_ENCRYPT on latest kernel...
>>
>> Best regards,
>> Pavel
>>
>> index 1d6104ea8af0..2bf2222819d3 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1520,6 +1520,7 @@ config X86_CPA_STATISTICS
>> config AMD_MEM_ENCRYPT
>> bool "AMD Secure Memory Encryption (SME) support"
>> depends on X86_64 && CPU_SUP_AMD
>> + select DMA_COHERENT_POOL
>> select DYNAMIC_PHYSICAL_MASK
>> select ARCH_USE_MEMREMAP_PROT
>> select ARCH_HAS_FORCE_DMA_UNENCRYPTED
>
> Thanks for the report!
>
> Besides CONFIG_AMD_MEM_ENCRYPT, do you have CONFIG_DMA_DIRECT_REMAP
> enabled? If so, it may be caused by the virtual address passed to the
> set_memory_{decrypted,encrypted}() functions.
>
> And I assume you are enabling SME by using mem_encrypt=on on the kernel
> command line or CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is enabled.
>
> We likely need an atomic pool for devices that support DMA to addresses in
> sme_me_mask as well. I can test this tomorrow, but wanted to get it out
> early to see if it helps?
This patch doesn't seem to help. I have the same problem (kernel page
fault, __memset, snd_pcm_hw_params...).
I don't have CONFIG_DMA_DIRECT_REMAP enabled, and AFAICT it doesn't seem
to be selectable currently on x86, unless there are some patches
floating around for that.
^ permalink raw reply [relevance 99%]
* Re: next-0519 on thinkpad x60: sound related? window manager crash
@ 2020-06-07 15:58 88% ` Alex Xu (Hello71)
0 siblings, 2 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-06-07 15:58 UTC (permalink / raw)
To: alsa-devel, bp, hpa, linux-kernel, mingo, Pavel Machek, perex,
tglx, tiwai, x86, rientjes, hch, hch
I have a similar issue, caused between aaa2faab4ed8 and b170290c2836.
[ 20.263098] BUG: unable to handle page fault for address: ffffb2b582cc2000
[ 20.263104] #PF: supervisor write access in kernel mode
[ 20.263105] #PF: error_code(0x000b) - reserved bit violation
[ 20.263107] PGD 3fd03b067 P4D 3fd03b067 PUD 3fd03c067 PMD 3f8822067 PTE 8000273942ab2163
[ 20.263113] Oops: 000b [#1] PREEMPT SMP
[ 20.263117] CPU: 3 PID: 691 Comm: mpv Not tainted 5.7.0-11262-gb170290c2836 #1
[ 20.263119] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIOS P4.10 03/05/2020
[ 20.263125] RIP: 0010:__memset+0x24/0x30
[ 20.263128] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
[ 20.263131] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216
[ 20.263133] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000
[ 20.263134] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000
[ 20.263136] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000
[ 20.263137] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000
[ 20.263139] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0
[ 20.263141] FS: 00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000
[ 20.263143] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 20.263144] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0
[ 20.263146] Call Trace:
[ 20.263151] ? snd_pcm_hw_params+0x3f3/0x47a
[ 20.263154] ? snd_pcm_common_ioctl+0xf2/0xf73
[ 20.263158] ? snd_pcm_ioctl+0x1e/0x29
[ 20.263161] ? ksys_ioctl+0x77/0x91
[ 20.263163] ? __x64_sys_ioctl+0x11/0x14
[ 20.263166] ? do_syscall_64+0x3d/0xf5
[ 20.263170] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 20.263173] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev snd_usb_audio videobuf2_common snd_hwdep snd_usbmidi_lib input_leds snd_rawmidi led_class
[ 20.263182] CR2: ffffb2b582cc2000
[ 20.263184] ---[ end trace c6b47a774b91f0a0 ]---
[ 20.263187] RIP: 0010:__memset+0x24/0x30
[ 20.263190] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
[ 20.263192] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216
[ 20.263193] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000
[ 20.263195] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000
[ 20.263196] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000
[ 20.263197] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000
[ 20.263199] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0
[ 20.263201] FS: 00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000
[ 20.263202] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 20.263204] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0
I bisected this to 82fef0ad811f "x86/mm: unencrypted non-blocking DMA
allocations use coherent pools". Reverting 1ee18de92927 resolves the
issue.
Looks like Thinkpad X60 doesn't have VT-d, but could still be DMA
related.
^ permalink raw reply [relevance 88%]
* Unrecoverable AER error when resuming from RAM (hda regression in 5.7-rc2)
[not found] <1587494585.7pihgq0z3i.none.ref@localhost>
@ 2020-04-21 19:08 92% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-04-21 19:08 UTC (permalink / raw)
To: alsa-devel, Takashi Iwai; +Cc: Roy Spliet, linux-kernel, linux-pci
With 5.7-rc2, after resuming from suspend to RAM, I get:
[ 55.679382] pcieport 0000:00:03.1: AER: Multiple Uncorrected (Non-Fatal) error received: 0000:00:00.0
[ 55.679405] pcieport 0000:00:03.1: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
[ 55.679410] pcieport 0000:00:03.1: AER: device [1022:1453] error status/mask=00100000/04400000
[ 55.679414] pcieport 0000:00:03.1: AER: [20] UnsupReq (First)
[ 55.679417] pcieport 0000:00:03.1: AER: TLP Header: 40000004 0a0000ff fffc0e80 00000000
[ 55.679423] amdgpu 0000:0a:00.0: AER: can't recover (no error_detected callback)
[ 55.679425] snd_hda_intel 0000:0a:00.1: AER: can't recover (no error_detected callback)
[ 55.679455] pcieport 0000:00:03.1: AER: device recovery failed
Then the display freezes and the system basically falls apart (can't
even sudo reboot -f, need to use magic sysrq).
I bisected this to "ALSA: hda: Skip controller resume if not needed".
Setting snd_hda_intel.power_save=0 resolves the issue.
I am using an ASRock B450 Pro4 with Realtek HDA codec:
[ 1.009400] snd_hda_intel 0000:0a:00.1: enabling device (0000 -> 0002)
[ 1.009425] snd_hda_intel 0000:0a:00.1: Force to non-snoop mode
[ 1.009653] snd_hda_intel 0000:0c:00.3: enabling device (0000 -> 0002)
[ 1.021452] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x7, too many assigned pins
[ 1.021461] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x9, too many assigned pins
[ 1.021471] snd_hda_codec_generic hdaudioC0D0: ignore pin 0xb, too many assigned pins
[ 1.021480] snd_hda_codec_generic hdaudioC0D0: ignore pin 0xd, too many assigned pins
[ 1.021482] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line
[ 1.021482] snd_hda_codec_generic hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 1.021483] snd_hda_codec_generic hdaudioC0D0: hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 1.021484] snd_hda_codec_generic hdaudioC0D0: mono: mono_out=0x0
[ 1.021484] snd_hda_codec_generic hdaudioC0D0: dig-out=0x3/0x5
[ 1.021485] snd_hda_codec_generic hdaudioC0D0: inputs:
[ 1.046053] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC892: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[ 1.046054] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 1.046055] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[ 1.046055] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0
[ 1.046056] snd_hda_codec_realtek hdaudioC1D0: inputs:
[ 1.046057] snd_hda_codec_realtek hdaudioC1D0: Front Mic=0x19
[ 1.046058] snd_hda_codec_realtek hdaudioC1D0: Rear Mic=0x18
[ 1.046058] snd_hda_codec_realtek hdaudioC1D0: Line=0x1a
I also have an ASUS RX 480 graphics card with HDMI audio output.
^ permalink raw reply [relevance 92%]
* Re: Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
@ 2020-04-07 15:36 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-04-07 15:36 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-mm, Thomas Hellström (VMware)
Cc: Andrew Morton, Christian König, Dan Williams,
Jérôme Glisse, Kirill A. Shutemov,
linux-graphics-maintainer, Michal Hocko, pv-drivers,
Ralph Campbell, Roland Scheidegger, Matthew Wilcox (Oracle)
Excerpts from Thomas Hellström (VMware)'s message of April 7, 2020 7:26 am:
> On 4/7/20 2:38 AM, Alex Xu (Hello71) wrote:
>> Excerpts from Thomas Hellström (VMware)'s message of April 6, 2020 5:04 pm:
>>> Hi,
>>>
>>> On 4/6/20 9:51 PM, Alex Xu (Hello71) wrote:
>>>> Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad
>>>> rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to
>>>> start filling dmesg, and then closing programs causes more BUGs and
>>>> hangs, and then everything grinds to a halt (can't start more programs,
>>>> can't even reboot through systemd).
>>>>
>>>> Using master and reverting that branch up to that point fixes the
>>>> problem.
>>>>
>>>> I'm using a Ryzen 1600 and AMD Radeon RX 480 on an ASRock B450 Pro4
>>>> board with IOMMU enabled.
>>> If you could try the attached patch, that'd be great!
>>>
>>> Thanks,
>>>
>>> Thomas
>>>
>> Yeah, that works too. Kernel config sent off-list.
>>
>> Regards,
>> Alex.
>
> Thanks. Do you want me to add your
>
> Reported-by: and Tested-by: To this patch?
>
> /Thomas
>
>
Sure. Shouldn't we fix it properly though?
^ permalink raw reply [relevance 99%]
* Re: Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
@ 2020-04-07 0:38 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-04-07 0:38 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-mm, Thomas Hellström (VMware)
Cc: Andrew Morton, Christian König, Dan Williams,
Jérôme Glisse, Kirill A. Shutemov,
linux-graphics-maintainer, Michal Hocko, pv-drivers,
Ralph Campbell, Roland Scheidegger, Matthew Wilcox (Oracle)
Excerpts from Thomas Hellström (VMware)'s message of April 6, 2020 5:04 pm:
> Hi,
>
> On 4/6/20 9:51 PM, Alex Xu (Hello71) wrote:
>> Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad
>> rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to
>> start filling dmesg, and then closing programs causes more BUGs and
>> hangs, and then everything grinds to a halt (can't start more programs,
>> can't even reboot through systemd).
>>
>> Using master and reverting that branch up to that point fixes the
>> problem.
>>
>> I'm using a Ryzen 1600 and AMD Radeon RX 480 on an ASRock B450 Pro4
>> board with IOMMU enabled.
>
> If you could try the attached patch, that'd be great!
>
> Thanks,
>
> Thomas
>
Yeah, that works too. Kernel config sent off-list.
Regards,
Alex.
^ permalink raw reply [relevance 99%]
* Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
[not found] <1586138158.v5u7myprlp.none.ref@localhost>
@ 2020-04-06 19:51 99% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-04-06 19:51 UTC (permalink / raw)
To: linux-mm, dri-devel, linux-kernel, thomas_os
Cc: pv-drivers, linux-graphics-maintainer, Andrew Morton,
Michal Hocko, Matthew Wilcox (Oracle),
Kirill A. Shutemov, Ralph Campbell, Jérôme Glisse,
Christian König, Dan Williams, Roland Scheidegger
Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad
rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to
start filling dmesg, and then closing programs causes more BUGs and
hangs, and then everything grinds to a halt (can't start more programs,
can't even reboot through systemd).
Using master and reverting that branch up to that point fixes the
problem.
I'm using a Ryzen 1600 and AMD Radeon RX 480 on an ASRock B450 Pro4
board with IOMMU enabled.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS
@ 2020-02-22 14:24 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2020-02-22 14:24 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Russell King, linux-kbuild, linux-kernel, masahiroy, michal.lkml
Excerpts from Nathan Chancellor's message of February 22, 2020 3:01 am:
> I used hyperfine [1] to run a quick benchmark with a freshly built
> GCC 9.2.0 for x86 and aarch64 and here are the results:
>
> In both cases it seems like performance regresses (by 1% but still) but
> maybe it is my machine, even though this benchmark was done on a
> different machine than the one from my commit back in 2018.
>
> I am not sure I would write off these results, since I did the benchmark
> 25 times on each one back to back, eliminating most of the variance that
> you described.
>
> [1]: https://github.com/sharkdp/hyperfine
>
> Cheers,
> Nathan
>
What kernel version are you running? Do you have the 5.6 pipe reworks?
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS
@ 2020-02-22 4:01 82% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-02-22 4:01 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Russell King, linux-kbuild, linux-kernel, masahiroy, michal.lkml
Excerpts from Nathan Chancellor's message of February 21, 2020 9:16 pm:
> Hi Alex,
>
> On Fri, Feb 21, 2020 at 07:38:20PM -0500, Alex Xu (Hello71) wrote:
>> -pipe reduces unnecessary disk wear for systems where /tmp is not a
>> tmpfs, slightly increases compilation speed, and avoids leaving behind
>> files when gcc crashes.
>>
>> According to the gcc manual, "this fails to work on some systems where
>> the assembler is unable to read from a pipe; but the GNU assembler has
>> no trouble". We already require GNU ld on all platforms, so this is not
>> an additional dependency. LLVM as also supports pipes.
>>
>> -pipe has always been used for most architectures, this change
>> standardizes it globally. Most notably, arm, arm64, riscv, and x86 are
>> affected.
>>
>> Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
>
> Do you have any numbers to show this is actually beneficial from a
> compilation time perspective? I ask because I saw an improvement in
> compilation time when removing -pipe from x86's KBUILD_CFLAGS in
> commit 437e88ab8f9e ("x86/build: Remove -pipe from KBUILD_CFLAGS").
>
> For what it's worth, clang ignores -pipe so this does not actually
> matter for its integrated assembler.
>
> That type of change could have been a fluke but I guarantee people
> will care more about any change in compilation time than any of the
> other things that you mention so it might be wise to check on major
> architectures to make sure that it doesn't hurt.
>
> Cheers,
> Nathan
>
Sorry, I should've checked the performance first. I have now run:
cd /tmp/linux # previously: make O=/tmp/linux
export MAKEFLAGS=12 # Ryzen 1600, 6 cores, 12 threads
make allnoconfig
for i in {1..10}; do
make clean >/dev/null
time make XPIPE=-pipe >/dev/null
make clean >/dev/null
time make >/dev/null
done
after patching -pipe to $(XPIPE) in Makefile.
Results (without ld warnings):
make > /dev/null 130.54s user 10.41s system 969% cpu 14.537 total
make XPIPE=-pipe > /dev/null 129.83s user 9.95s system 977% cpu 14.296 total
make > /dev/null 129.73s user 10.28s system 966% cpu 14.493 total
make XPIPE=-pipe > /dev/null 130.04s user 10.63s system 986% cpu 14.252 total
make > /dev/null 129.53s user 10.28s system 972% cpu 14.379 total
make XPIPE=-pipe > /dev/null 130.29s user 10.17s system 983% cpu 14.288 total
make > /dev/null 130.19s user 10.52s system 968% cpu 14.530 total
make XPIPE=-pipe > /dev/null 129.90s user 10.47s system 978% cpu 14.343 total
make > /dev/null 129.50s user 10.81s system 959% cpu 14.620 total
make XPIPE=-pipe > /dev/null 130.37s user 10.60s system 975% cpu 14.446 total
make > /dev/null 129.63s user 10.18s system 972% cpu 14.374 total
make XPIPE=-pipe > /dev/null 131.29s user 9.92s system 1016% cpu 13.899 total
make > /dev/null 129.96s user 10.39s system 961% cpu 14.596 total
make XPIPE=-pipe > /dev/null 131.63s user 10.16s system 1011% cpu 14.015 total
make > /dev/null 129.33s user 10.54s system 970% cpu 14.405 total
make XPIPE=-pipe > /dev/null 129.70s user 10.40s system 976% cpu 14.349 total
make > /dev/null 129.53s user 10.25s system 964% cpu 14.494 total
make XPIPE=-pipe > /dev/null 130.38s user 10.62s system 973% cpu 14.479 total
make > /dev/null 130.73s user 10.08s system 957% cpu 14.704 total
make XPIPE=-pipe > /dev/null 130.43s user 10.62s system 985% cpu 14.309 total
make > /dev/null 130.54s user 10.41s system 969% cpu 14.537 total
There is a fair bit of variance, probably due to cpufreq, schedutil, CPU
temperature, CPU scheduler, motherboard power delivery, etc. But, I
think it can be clearly seen that -pipe is, on average, about 0.1 to 0.2
seconds faster.
I also tried "make defconfig":
make > /dev/null 1238.26s user 102.39s system 1095% cpu 2:02.33 total
make XPIPE=-pipe > /dev/null 1231.33s user 102.52s system 1081% cpu 2:03.29 total
make > /dev/null 1232.92s user 102.07s system 1096% cpu 2:01.71 total
make XPIPE=-pipe > /dev/null 1239.59s user 102.30s system 1096% cpu 2:02.39 total
make > /dev/null 1229.81s user 101.72s system 1093% cpu 2:01.74 total
make XPIPE=-pipe > /dev/null 1234.64s user 101.30s system 1098% cpu 2:01.64 total
make > /dev/null 1228.50s user 104.39s system 1093% cpu 2:01.91 total
make XPIPE=-pipe > /dev/null 1238.78s user 102.57s system 1099% cpu 2:01.99 total
make > /dev/null 1238.26s user 102.39s system 1095% cpu 2:02.33 total
I stopped after this because I needed to use the machine for other
tasks. The results are less clear, but I think there's not a big
difference one way or another, at least on my machine.
CPU: Ryzen 1600, overclocked to ~3.8 GHz
RAM: Corsair Vengeance, overclocked to ~3300 MHz, forgot timings
Motherboard: ASRock B450 Pro4
I would speculate that the recent pipe changes have caused a change in
the relative speed compared to 2018. I am using 5.6.0-rc2 with -O3
-march=native patches.
Regards,
Alex.
^ permalink raw reply [relevance 82%]
* [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS
[not found] <20200222003820.220854-1-alex_y_xu.ref@yahoo.ca>
@ 2020-02-22 0:38 62% ` Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2020-02-22 0:38 UTC (permalink / raw)
To: linux-kbuild, michal.lkml, masahiroy
Cc: linux-kernel, Russell King, Alex Xu (Hello71)
-pipe reduces unnecessary disk wear for systems where /tmp is not a
tmpfs, slightly increases compilation speed, and avoids leaving behind
files when gcc crashes.
According to the gcc manual, "this fails to work on some systems where
the assembler is unable to read from a pipe; but the GNU assembler has
no trouble". We already require GNU ld on all platforms, so this is not
an additional dependency. LLVM as also supports pipes.
-pipe has always been used for most architectures, this change
standardizes it globally. Most notably, arm, arm64, riscv, and x86 are
affected.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
Makefile | 2 +-
arch/alpha/Makefile | 2 +-
arch/arc/Makefile | 2 +-
arch/arm/Makefile | 1 -
arch/csky/Makefile | 1 -
arch/ia64/Makefile | 2 +-
arch/m68k/Makefile | 2 +-
arch/mips/Makefile | 2 +-
arch/nios2/Makefile | 2 +-
arch/openrisc/Makefile | 2 +-
arch/parisc/Makefile | 2 +-
arch/powerpc/Makefile | 2 +-
arch/s390/Makefile | 2 +-
arch/sh/Makefile | 2 +-
arch/sparc/Makefile | 4 ++--
arch/xtensa/Makefile | 2 +-
16 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/Makefile b/Makefile
index aab38cb02b24..782c12267151 100644
--- a/Makefile
+++ b/Makefile
@@ -459,7 +459,7 @@ KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
-Werror=implicit-function-declaration -Werror=implicit-int \
-Wno-format-security \
- -std=gnu89
+ -std=gnu89 -pipe
KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
index 12dee59b011c..b40a9be72d9b 100644
--- a/arch/alpha/Makefile
+++ b/arch/alpha/Makefile
@@ -12,7 +12,7 @@ NM := $(NM) -B
LDFLAGS_vmlinux := -static -N #-relax
CHECKFLAGS += -D__alpha__
-cflags-y := -pipe -mno-fp-regs -ffixed-8
+cflags-y := -mno-fp-regs -ffixed-8
cflags-y += $(call cc-option, -fno-jump-tables)
cpuflags-$(CONFIG_ALPHA_EV4) := -mcpu=ev4
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 20e9ab6cc521..b6a2f553771c 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -9,7 +9,7 @@ ifeq ($(CROSS_COMPILE),)
CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- arceb-linux-)
endif
-cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__
+cflags-y += -fno-common -fno-builtin -mmedium-calls -D__linux__
cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7
cflags-$(CONFIG_ISA_ARCV2) += -mcpu=hs38
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index db857d07114f..7711467e0797 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -21,7 +21,6 @@ KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
endif
GZFLAGS :=-9
-#KBUILD_CFLAGS +=-pipe
# Never generate .eh_frame
KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
diff --git a/arch/csky/Makefile b/arch/csky/Makefile
index fb1bbbd91954..3ba8d936122c 100644
--- a/arch/csky/Makefile
+++ b/arch/csky/Makefile
@@ -42,7 +42,6 @@ KBUILD_CFLAGS += -msoft-float -mdiv
KBUILD_CFLAGS += -fno-tree-vectorize
endif
-KBUILD_CFLAGS += -pipe
ifeq ($(CSKYABI),abiv2)
KBUILD_CFLAGS += -mno-stack-size
endif
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index 32240000dc0c..554dc20873d8 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -24,7 +24,7 @@ KBUILD_LDS_MODULE += $(srctree)/arch/ia64/module.lds
KBUILD_AFLAGS_KERNEL := -mconstant-gp
EXTRA :=
-cflags-y := -pipe $(EXTRA) -ffixed-r13 -mfixed-range=f12-f15,f32-f127 \
+cflags-y := $(EXTRA) -ffixed-r13 -mfixed-range=f12-f15,f32-f127 \
-falign-functions=32 -frename-registers -fno-optimize-sibling-calls
KBUILD_CFLAGS_KERNEL := -mconstant-gp
diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index 5d9288384096..99a226bbd06c 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -60,7 +60,7 @@ cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200)
KBUILD_AFLAGS += $(cpuflags-y)
KBUILD_CFLAGS += $(cpuflags-y)
-KBUILD_CFLAGS += -pipe -ffreestanding
+KBUILD_CFLAGS += -ffreestanding
ifdef CONFIG_MMU
# without -fno-strength-reduce the 53c7xx.c driver fails ;-(
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index e1c44aed8156..05eb77328a13 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -95,7 +95,7 @@ all-$(CONFIG_SYS_SUPPORTS_ZBOOT)+= vmlinuz
# machines may also. Since BFD is incredibly buggy with respect to
# crossformat linking we rely on the elf2ecoff tool for format conversion.
#
-cflags-y += -G 0 -mno-abicalls -fno-pic -pipe
+cflags-y += -G 0 -mno-abicalls -fno-pic
cflags-y += -msoft-float
LDFLAGS_vmlinux += -G 0 -static -n -nostdlib
KBUILD_AFLAGS_MODULE += -mlong-calls
diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
index 52c03e60b114..3205cb5fd143 100644
--- a/arch/nios2/Makefile
+++ b/arch/nios2/Makefile
@@ -24,7 +24,7 @@ LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-n
KBUILD_AFLAGS += -march=r$(CONFIG_NIOS2_ARCH_REVISION)
-KBUILD_CFLAGS += -pipe -D__linux__ -D__ELF__
+KBUILD_CFLAGS += -D__linux__ -D__ELF__
KBUILD_CFLAGS += -march=r$(CONFIG_NIOS2_ARCH_REVISION)
KBUILD_CFLAGS += $(if $(CONFIG_NIOS2_HW_MUL_SUPPORT),-mhw-mul,-mno-hw-mul)
KBUILD_CFLAGS += $(if $(CONFIG_NIOS2_HW_MULX_SUPPORT),-mhw-mulx,-mno-hw-mulx)
diff --git a/arch/openrisc/Makefile b/arch/openrisc/Makefile
index bf10141c7426..86075fc673d9 100644
--- a/arch/openrisc/Makefile
+++ b/arch/openrisc/Makefile
@@ -22,7 +22,7 @@ KBUILD_DEFCONFIG := or1ksim_defconfig
OBJCOPYFLAGS := -O binary -R .note -R .comment -S
LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
-KBUILD_CFLAGS += -pipe -ffixed-r10 -D__linux__
+KBUILD_CFLAGS += -ffixed-r10 -D__linux__
ifeq ($(CONFIG_OPENRISC_HAVE_INST_MUL),y)
KBUILD_CFLAGS += $(call cc-option,-mhard-mul)
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index dca8f2de8cf5..88bee828400d 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -64,7 +64,7 @@ endif
OBJCOPY_FLAGS =-O binary -R .note -R .comment -S
-cflags-y := -pipe
+cflags-y :=
# These flags should be implied by an hppa-linux configuration, but they
# are not in gcc 3.2.
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f35730548e42..0550b976157c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -215,7 +215,7 @@ asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
KBUILD_CPPFLAGS += -I $(srctree)/arch/$(ARCH) $(asinstr)
KBUILD_AFLAGS += $(AFLAGS-y)
KBUILD_CFLAGS += $(call cc-option,-msoft-float)
-KBUILD_CFLAGS += -pipe $(CFLAGS-y)
+KBUILD_CFLAGS += $(CFLAGS-y)
CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(BITS) -D__powerpc__ -D__powerpc$(BITS)__
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index e0e3a465bbfd..3ca3e3a29864 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -118,7 +118,7 @@ endif
cfi := $(call as-instr,.cfi_startproc\n.cfi_val_offset 15$(comma)-160\n.cfi_endproc,-DCONFIG_AS_CFI_VAL_OFFSET=1)
KBUILD_CFLAGS += -mbackchain -msoft-float $(cflags-y)
-KBUILD_CFLAGS += -pipe -Wno-sign-compare
+KBUILD_CFLAGS += -Wno-sign-compare
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables $(cfi)
KBUILD_AFLAGS += $(aflags-y) $(cfi)
export KBUILD_AFLAGS_DECOMPRESSOR
diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index b4a86f27e048..2e224b2a436b 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -194,7 +194,7 @@ drivers-$(CONFIG_OPROFILE) += arch/sh/oprofile/
cflags-y += $(foreach d, $(cpuincdir-y), -I $(srctree)/arch/sh/include/$(d)) \
$(foreach d, $(machdir-y), -I $(srctree)/arch/sh/include/$(d))
-KBUILD_CFLAGS += -pipe $(cflags-y)
+KBUILD_CFLAGS += $(cflags-y)
KBUILD_CPPFLAGS += $(cflags-y)
KBUILD_AFLAGS += $(cflags-y)
diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
index 4a0919581697..ad30e7e668e0 100644
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@ -29,7 +29,7 @@ UTS_MACHINE := sparc
# versions of gcc. Some gcc versions won't pass -Av8 to binutils when you
# give -mcpu=v8. This silently worked with older bintutils versions but
# does not any more.
-KBUILD_CFLAGS += -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
+KBUILD_CFLAGS += -m32 -mcpu=v8 -mno-fpu -fcall-used-g5 -fcall-used-g7
KBUILD_CFLAGS += -Wa,-Av8
KBUILD_AFLAGS += -m32 -Wa,-Av8
@@ -44,7 +44,7 @@ KBUILD_LDFLAGS := -m elf64_sparc
export BITS := 64
UTS_MACHINE := sparc64
-KBUILD_CFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
+KBUILD_CFLAGS += -m64 -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
KBUILD_CFLAGS += -Wa,--undeclared-regs
KBUILD_CFLAGS += $(call cc-option,-mtune=ultrasparc3)
diff --git a/arch/xtensa/Makefile b/arch/xtensa/Makefile
index 67a7d151d1e7..fdaa588c504c 100644
--- a/arch/xtensa/Makefile
+++ b/arch/xtensa/Makefile
@@ -42,7 +42,7 @@ export PLATFORM
# temporarily until string.h is fixed
KBUILD_CFLAGS += -ffreestanding -D__linux__
-KBUILD_CFLAGS += -pipe -mlongcalls -mtext-section-literals
+KBUILD_CFLAGS += -mlongcalls -mtext-section-literals
KBUILD_CFLAGS += $(call cc-option,-mforce-no-pic,)
KBUILD_CFLAGS += $(call cc-option,-mno-serialize-volatile,)
--
2.25.1
^ permalink raw reply related [relevance 62%]
* [PATCH] random: print a message when waiting for random
@ 2019-07-24 22:33 95% Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2019-07-24 22:33 UTC (permalink / raw)
To: linux-kernel, tytso; +Cc: arnd, gregkh, Alex Xu (Hello71)
- many programs now use getrandom on startup, including for cases which
may not be security-sensitive (e.g. hash tables)
- boot times are faster than ever with the widespread use of high-speed
SSD storage
- no major distributions currently use RNDADDENTROPY ioctl when
restoring the random seed, including systemd and OpenRC. systemd may
add this functionality soon
(https://github.com/systemd/systemd/pull/13137) but it seems to have
some special requirements (systemd-boot) and/or require special
opt-in.
- despite the availability of virtio-rng, many hosts do not offer it,
and many/most distributions do not configure rngd by default
in combination, many programs (e.g. sshd, gdm) now block on startup,
sometimes for many minutes. in the kernel, we can't fix this easily, but
we should at least notify users why their program is stuck.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
drivers/char/random.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5d5ea4ce1442..e4490c6c9c84 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -511,6 +511,8 @@ static struct ratelimit_state unseeded_warning =
RATELIMIT_STATE_INIT("warn_unseeded_randomness", HZ, 3);
static struct ratelimit_state urandom_warning =
RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
+static struct ratelimit_state wait_for_random_warning =
+ RATELIMIT_STATE_INIT("warn_wait_for_random", HZ, 3);
static int ratelimit_disable __read_mostly;
@@ -1745,6 +1747,9 @@ int wait_for_random_bytes(void)
{
if (likely(crng_ready()))
return 0;
+ if (__ratelimit(&wait_for_random_warning))
+ pr_info("random: %s: waiting for randomness\n",
+ current->comm);
return wait_event_interruptible(crng_init_wait, crng_ready());
}
EXPORT_SYMBOL(wait_for_random_bytes);
@@ -1901,6 +1906,7 @@ int __init rand_initialize(void)
if (ratelimit_disable) {
urandom_warning.interval = 0;
unseeded_warning.interval = 0;
+ wait_for_random_warning.interval = 0;
}
return 0;
}
--
2.22.0
^ permalink raw reply related [relevance 95%]
* Re: [PATCH] crypto: ux500 - fix license comment syntax error
@ 2019-06-01 19:41 99% ` Alex Xu
0 siblings, 0 replies; 89+ results
From: Alex Xu @ 2019-06-01 19:41 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, linux-crypto, tglx, allison, alexios.zavras,
swinslow, rfontana, linux-spdx, torvalds
Quoting Greg KH (2019-06-01 16:29:07)
> On Sat, Jun 01, 2019 at 10:49:43AM -0400, Alex Xu (Hello71) wrote:
> > Causes error: drivers/crypto/ux500/cryp/Makefile:5: *** missing
> > separator. Stop.
> >
> > Fixes: af873fcecef5 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 194")
> > Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
> > ---
> > drivers/crypto/ux500/cryp/Makefile | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Also, how did 0-day not catch this? Is this an odd configuration that
> it can not build?
I had to run "make clean" to get the error.
^ permalink raw reply [relevance 99%]
* [PATCH] crypto: ux500 - fix license comment syntax error
@ 2019-06-01 14:49 99% Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2019-06-01 14:49 UTC (permalink / raw)
To: linux-kernel, linux-crypto, tglx
Cc: allison, alexios.zavras, swinslow, rfontana, gregkh, linux-spdx,
torvalds, Alex Xu (Hello71)
Causes error: drivers/crypto/ux500/cryp/Makefile:5: *** missing
separator. Stop.
Fixes: af873fcecef5 ("treewide: Replace GPLv2 boilerplate/reference with
SPDX - rule 194")
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
drivers/crypto/ux500/cryp/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ux500/cryp/Makefile b/drivers/crypto/ux500/cryp/Makefile
index a90b50597e5c..3e67531f484c 100644
--- a/drivers/crypto/ux500/cryp/Makefile
+++ b/drivers/crypto/ux500/cryp/Makefile
@@ -2,7 +2,7 @@
#/*
# * Copyright (C) ST-Ericsson SA 2010
# * Author: shujuan.chen@stericsson.com for ST-Ericsson.
- */
+# */
ccflags-$(CONFIG_CRYPTO_DEV_UX500_DEBUG) += -DDEBUG
--
2.21.0
^ permalink raw reply related [relevance 99%]
* [PATCH] treewide: fix awk regexp over-escaping
@ 2019-05-18 19:53 81% Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2019-05-18 19:53 UTC (permalink / raw)
To: linux-kernel
Cc: x86, jpoimboe, peterz, hpa, masami.hiramatsu.pt, ben-linux,
adrian.hunter, Alex Xu (Hello71)
Fix "warning: regexp escape sequence is not a known regexp operator" on
gawk 5.0.0.
Results found by:
- grepping '\\[^\[\\^$.|?*+()a-z]' on *.awk
- grepping 'awk.*\\[^\[\\^$.|?*+()a-z]'
- running awk --lint -f </dev/null >/dev/null on *.awk
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
Documentation/arm/Samsung/clksrc-change-registers.awk | 2 +-
arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
lib/raid6/unroll.awk | 2 +-
tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
tools/perf/arch/x86/tests/gen-insn-x86-dat.awk | 2 +-
tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk | 4 ++--
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/arm/Samsung/clksrc-change-registers.awk b/Documentation/arm/Samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..d853f750c861 100755
--- a/Documentation/arm/Samsung/clksrc-change-registers.awk
+++ b/Documentation/arm/Samsung/clksrc-change-registers.awk
@@ -67,7 +67,7 @@ BEGIN {
# to replace and create an associative array of values
while (getline line < ARGV[1] > 0) {
- if (line ~ /\#define.*_MASK/ &&
+ if (line ~ /#define.*_MASK/ &&
!(line ~ /USB_SIG_MASK/)) {
splitdefine(line, fields)
name = fields[0]
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk b/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+ lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/lib/raid6/unroll.awk b/lib/raid6/unroll.awk
index c6aa03631df8..0809805a7e23 100644
--- a/lib/raid6/unroll.awk
+++ b/lib/raid6/unroll.awk
@@ -13,7 +13,7 @@ BEGIN {
for (i = 0; i < rep; ++i) {
tmp = $0
gsub(/\$\$/, i, tmp)
- gsub(/\$\#/, n, tmp)
+ gsub(/\$#/, n, tmp)
gsub(/\$\*/, "$", tmp)
print tmp
}
diff --git a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+ lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
index a21454835cd4..27585d032ee6 100644
--- a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
+++ b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
@@ -31,7 +31,7 @@ BEGIN {
going = 0
}
-/^\s*[0-9a-fA-F]+\:/ {
+/^\s*[0-9a-fA-F]+:/ {
if (going) {
colon_pos = index($0, ":")
useful_line = substr($0, colon_pos + 1)
diff --git a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
index ddd5c4c21129..606ccd154392 100644
--- a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
+++ b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+ lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
--
2.21.0
^ permalink raw reply related [relevance 81%]
* Re: [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries
@ 2019-05-18 18:59 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2019-05-18 18:59 UTC (permalink / raw)
To: linux-ext4, Linux List Kernel Mailing, Mikhail Gavrilov
Excerpts from Mikhail Gavrilov's message of May 18, 2019 7:07 am:
> On Sat, 18 May 2019 at 11:44, Mikhail Gavrilov
> <mikhail.v.gavrilov@gmail.com> wrote:
>> [28616.429757] EXT4-fs error (device nvme0n1p2): ext4_find_extent:908:
>> inode #8: comm jbd2/nvme0n1p2-: pblk 23101439 bad header/extent:
>> invalid extent entries - magic f30a, entries 8, max 340(340), depth
>> 0(0)
I had a similar problem today:
EXT4-fs error (device dm-0): ext4_find_extent:908: inode #8: comm jbd2/dm-0-8: pblk 117997567 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0)
I am using dm-crypt on SATA disk.
^ permalink raw reply [relevance 99%]
* [REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e)
@ 2019-05-13 1:20 86% Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2019-05-13 1:20 UTC (permalink / raw)
To: linux-kernel, tj, guro; +Cc: oleg, kernel-team
Hi,
I was trying to use strace recently and found that it exhibited some
strange behavior. I produced this minimal test case:
#include <unistd.h>
int main() {
write(1, "a", 1);
return 0;
}
which, when run using "gcc test.c && strace ./a.out" produces this
strace output:
[ pre-main omitted ]
write(1, "a", 1) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
write(1, "a", 1) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
[ repeats forever ]
The correct result is of course:
[ pre-main omitted ]
write(1, "a", 1) = 1
exit_group(0) = ?
+++ exited with 0 +++
Strangely, this only occurs when outputting to a tty-like output.
Running "strace ./a.out" from a native Linux x86 console or a terminal
emulator causes the abnormal behavior. However, the following commands
work correctly:
- strace ./a.out >/dev/null
- strace ./a.out >/tmp/a # /tmp is a standard tmpfs
- strace ./a.out >&- # causes -1 EBADF (Bad file descriptor)
"strace -o /tmp/a ./a.out" hangs and produces the above (infinite)
output to /tmp/a.
I bisected this to 76f969e, "cgroup: cgroup v2 freezer". I reverted the
entire patchset (reverting only that one caused a conflict), which
resolved the issue. I skimmed the patch and came up with this
workaround, which also resolves the issue. I am not at all clear on the
technical workings of the patchset, but it seems to me like a process's
frozen status is supposed to be "suspended" when a frozen process is
ptraced, and "unsuspended" when ptracing ends. Therefore, it seems
suspicious to always "enter frozen" whether or not the cgroup is
actually frozen. It seems like the code should instead check if the
cgroup is actually frozen, and if so, restore the frozen status.
I am using systemd but not any other cgroup features. I tried in an
initramfs environment (no systemd, /init -> shell script) and reproduced
the failing test case.
Please CC me on replies.
Thanks,
Alex.
---
kernel/signal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 62f9aea4a15a..47145d9d89ca 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2110,7 +2110,7 @@ static void ptrace_stop(int exit_code, int why, int clear_code, kernel_siginfo_t
preempt_disable();
read_unlock(&tasklist_lock);
preempt_enable_no_resched();
- cgroup_enter_frozen();
+ //cgroup_enter_frozen();
freezable_schedule();
} else {
/*
@@ -2289,7 +2289,7 @@ static bool do_signal_stop(int signr)
}
/* Now we don't run again until woken by SIGCONT or SIGKILL */
- cgroup_enter_frozen();
+ //cgroup_enter_frozen();
freezable_schedule();
return true;
} else {
--
2.21.0
^ permalink raw reply related [relevance 86%]
* [PATCH] treewide: fix awk regexp over-escaping
@ 2019-04-30 2:17 81% Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2019-04-30 2:17 UTC (permalink / raw)
To: linux-kernel
Cc: x86, jpoimboe, peterz, hpa, masami.hiramatsu.pt, ben-linux,
adrian.hunter, Alex Xu (Hello71)
Fix "warning: regexp escape sequence is not a known regexp operator" on
gawk 5.0.0.
Results found by:
- grepping '\\[^\[\\^$.|?*+()a-z]' on *.awk
- grepping 'awk.*\\[^\[\\^$.|?*+()a-z]'
- running awk --lint -f </dev/null >/dev/null on *.awk
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
Documentation/arm/Samsung/clksrc-change-registers.awk | 2 +-
arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
lib/raid6/unroll.awk | 2 +-
tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
tools/perf/arch/x86/tests/gen-insn-x86-dat.awk | 2 +-
tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk | 4 ++--
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/arm/Samsung/clksrc-change-registers.awk b/Documentation/arm/Samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..d853f750c861 100755
--- a/Documentation/arm/Samsung/clksrc-change-registers.awk
+++ b/Documentation/arm/Samsung/clksrc-change-registers.awk
@@ -67,7 +67,7 @@ BEGIN {
# to replace and create an associative array of values
while (getline line < ARGV[1] > 0) {
- if (line ~ /\#define.*_MASK/ &&
+ if (line ~ /#define.*_MASK/ &&
!(line ~ /USB_SIG_MASK/)) {
splitdefine(line, fields)
name = fields[0]
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk b/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+ lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/lib/raid6/unroll.awk b/lib/raid6/unroll.awk
index c6aa03631df8..0809805a7e23 100644
--- a/lib/raid6/unroll.awk
+++ b/lib/raid6/unroll.awk
@@ -13,7 +13,7 @@ BEGIN {
for (i = 0; i < rep; ++i) {
tmp = $0
gsub(/\$\$/, i, tmp)
- gsub(/\$\#/, n, tmp)
+ gsub(/\$#/, n, tmp)
gsub(/\$\*/, "$", tmp)
print tmp
}
diff --git a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+ lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
index a21454835cd4..27585d032ee6 100644
--- a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
+++ b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
@@ -31,7 +31,7 @@ BEGIN {
going = 0
}
-/^\s*[0-9a-fA-F]+\:/ {
+/^\s*[0-9a-fA-F]+:/ {
if (going) {
colon_pos = index($0, ":")
useful_line = substr($0, colon_pos + 1)
diff --git a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
index ddd5c4c21129..606ccd154392 100644
--- a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
+++ b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+ lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
--
2.21.0
^ permalink raw reply related [relevance 81%]
* Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
@ 2019-03-31 16:15 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2019-03-31 16:15 UTC (permalink / raw)
To: Vineeth Pillai
Cc: Andrew Morton, Hugh Dickins, Kelley Nielsen, linux-kernel,
linux-mm, Rik van Riel, Huang Ying
Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm:
> On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
>>
>> I get this BUG in 5.1-rc1 sometimes when powering off the machine. I
>> suspect my setup erroneously executes two swapoff+cryptsetup close
>> operations simultaneously, so a race condition is triggered.
>>
>> I am using a single swap on a plain dm-crypt device on a MBR partition
>> on a SATA drive.
>>
>> I think the problem is probably related to
>> b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people.
>>
> Could you please provide more information on this - stack trace, dmesg etc?
> Is it easily reproducible? If yes, please detail the steps so that I
> can try it inhouse.
>
> Thanks,
> Vineeth
>
Some info from the BUG entry (I didn't bother to type it all,
low-quality image available upon request):
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
#PF error: [normal kernel read fault]
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 0 Comm: swapoff Not tainted 5.1.0-rc1+ #2
RIP: 0010:shmem_recalc_inode+0x41/0x90
Call Trace:
? shmem_undo_range
? rb_erase_cached
? set_next_entity
? __inode_wait_for_writeback
? shmem_truncate_range
? shmem_evict_inode
? evict
? shmem_unuse
? try_to_unuse
? swapcache_free_entries
? _cond_resched
? __se_sys_swapoff
? do_syscall_64
? entry_SYSCALL_64_after_hwframe
As I said, it only occurs occasionally on shutdown. I think it is a safe
guess that it can only occur when the swap is not empty, but possibly
other conditions are necessary, so I will test further.
^ permalink raw reply [relevance 99%]
* shmem_recalc_inode: unable to handle kernel NULL pointer dereference
@ 2019-03-24 15:30 99% Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2019-03-24 15:30 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Vineeth Remanan Pillai, Kelley Nielsen, Huang Ying, Hugh Dickins,
Rik van Riel, Andrew Morton
I get this BUG in 5.1-rc1 sometimes when powering off the machine. I
suspect my setup erroneously executes two swapoff+cryptsetup close
operations simultaneously, so a race condition is triggered.
I am using a single swap on a plain dm-crypt device on a MBR partition
on a SATA drive.
I think the problem is probably related to
b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* Re: r8169 only works in promisc mode
2019-03-09 2:16 99% r8169 only works in promisc mode Alex Xu (Hello71)
@ 2019-03-23 1:26 93% ` Alex Xu
1 sibling, 0 replies; 89+ results
From: Alex Xu @ 2019-03-23 1:26 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: gnomes
I have done some more investigation, some of which I posted on the
Bugzilla bug.
I believe the promisc issue is due to the MAC address receive filter
being silently reset to the invalid burned-in address. I used wireshark
and determined that the outgoing MAC address after suspend is the
overridden value. Re-setting the overridden value with "ip link set eth0
address" appears to have no effect. Setting it to a different overridden
value works normally and resolves the packet loss issue. Removing the
module and re-inserting it also resolves the issue.
I also attempted to determine why the MAC address on boot is
8e:00:00:00:8e:8e. As far as I can tell, this value is burned into the
flash somewhere. I tried turning off the machine, unplugging the power,
pressing the power button several times, then plugging it back in and
immediately booting into Windows; the incorrect MAC address was shown.
This reminded me that I am experiencing another firmware-related issue,
namely that it appears that the machine is only able to reach S1 or
possibly S2 sleep mode, even when specifying S3, and even in Windows. I
think there may be some flash bitrot, but clearing the firmware
settings, by all of: in the interface, removing the battery, and setting
the jumper; had no effect. I also tried reinstalling the BIOS using the
vendor-provided Windows updater, which also had no effect.
In conclusion: I think my firmware is broken (even moreso than regular
PC firmware), but I believe there is in fact some bug with r8169 on
"RTL8211B" in 5.0-rc1.
I can try bisecting if someone more competent than me believes that
would be helpful.
Thanks,
Alex.
^ permalink raw reply [relevance 93%]
* Re: r8169 only works in promisc mode
@ 2019-03-09 16:53 99% ` Alex Xu
0 siblings, 0 replies; 89+ results
From: Alex Xu @ 2019-03-09 16:53 UTC (permalink / raw)
To: Heiner Kallweit, linux-kernel, netdev
Quoting Heiner Kallweit (2019-03-09 09:33:40)
> On 09.03.2019 03:16, Alex Xu (Hello71) wrote:
> > After suspending, my r8169 (not actually 8169, just that driver) only
> > receives packets when in promiscuous mode. I have tried disabling all
> > offload features except highdma [fixed], and it doesn't fix the issue.
> >
> > I am using torvalds/linux, compiled about two days ago (not sure which
> > commit). I think this happened after a recent upgrade (some time in the
> > past week). Given the long testing cycle, I don't really want to bisect;
> > I am hoping someone has some idea of where the issue could be.
> >
> The provided information isn't enough to say anything. Please create a
> bug ticket in bugzilla. Needed information:
> - Last working and first failing kernel version (as reported by uname -a)
> - Is 5.0 ok?
> - Full dmesg log
> - lspci -vv output for the network card
> - If the issue happens only after resume from suspend, diff of the
> chip registers (ethtool -d) before and after suspend.
> - Does removing / reloading the r8169 module fix the issue?
>
> > Please CC me on replies.
> >
> > Thanks,
> > Alex.
> >
> Heiner
I filed bug 202851 with some of the requested information.
Alex.
^ permalink raw reply [relevance 99%]
* r8169 only works in promisc mode
@ 2019-03-09 2:16 99% Alex Xu (Hello71)
2019-03-23 1:26 93% ` Alex Xu
0 siblings, 2 replies; 89+ results
From: Alex Xu (Hello71) @ 2019-03-09 2:16 UTC (permalink / raw)
To: netdev, linux-kernel
After suspending, my r8169 (not actually 8169, just that driver) only
receives packets when in promiscuous mode. I have tried disabling all
offload features except highdma [fixed], and it doesn't fix the issue.
I am using torvalds/linux, compiled about two days ago (not sure which
commit). I think this happened after a recent upgrade (some time in the
past week). Given the long testing cycle, I don't really want to bisect;
I am hoping someone has some idea of where the issue could be.
Please CC me on replies.
Thanks,
Alex.
^ permalink raw reply [relevance 99%]
* Re: [PATCH net v2] r8169: always autoneg on resume
@ 2018-10-01 3:31 99% ` Alex Xu
0 siblings, 0 replies; 89+ results
From: Alex Xu @ 2018-10-01 3:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: Daan Wendelen, netdev, hkallweit1, nic_swsd, davem, linux-kernel
Quoting Andrew Lunn (2018-10-01 02:39:47)
> I keep reading the patch wrong, so here is the end state:
>
> /* It was reported that several chips end up with 10MBit/Half on a
> * 1GBit link after resuming from S3. For whatever reason the PHY on
> * these chips doesn't properly start a renegotiation when soft-reset.
> * Explicitly requesting a renegotiation fixes this.
> */
>
> I would also say 'don't'. For me the subject is 'PHY on these chips',
> which is plural.
>
> However:
>
> For whatever reason the PHY, on these chips, doesn't properly start a
> renegotiation when soft-reset.
>
> Now just 'the PHY' is the subject, so singular.
>
> But i'm just a native speaker who never actually learnt the rules of
> grammar, it just sounds right or wrong, and i have no idea why.
No. Ending in a plural noun doesn't make a noun phrase plural.
Example 1: The boy with the books is walking.
Example 2: The women on the roof are waving.
In these cases, "with" and "on" introduce prepositional phrases
which are subordinate to the noun phrase. The subjects are "boy" and
"women" respectively; the books are not walking, and the roof is not
waving.
In fact, this can be clearly seen by drawing a parse tree, which should
hopefully be a familiar tool to all programmers.
Furthermore, the addition of commas in these cases is not correct (hey,
another example!); the phrases are essential, so commas may not be used.
Regardless, this is highly off-topic, so I think further replies can go
off-list.
^ permalink raw reply [relevance 99%]
* Re: [PATCH net v2] r8169: always autoneg on resume
@ 2018-09-30 22:30 99% ` Alex Xu
0 siblings, 1 reply; 89+ results
From: Alex Xu @ 2018-09-30 22:30 UTC (permalink / raw)
To: Daan Wendelen; +Cc: netdev, hkallweit1, nic_swsd, davem, linux-kernel
Quoting Daan Wendelen (2018-09-30 22:17:51)
> Hi Alex,
>
> I randomly opened your patch even though I have absolutely no idea what this patch is about, but I
> found a mistake in one of the comments:
>
> On Sun, Sep 30, 2018 at 11:06:39AM -0400, Alex Xu (Hello71) wrote:
> > This affects at least versions 25 and 33, so assume all cards are broken
> ...
> > * 1GBit link after resuming from S3. For whatever reason the PHY on
> > - * this chip doesn't properly start a renegotiation when soft-reset.
> > + * these chips doesn't properly start a renegotiation when soft-reset.
> ~~~~~~~
> I believe it should be "these chips don't"
>
> With kind regards,
> Daan
The grammar is correct as is. The subject of the sentence is "the PHY",
which is singular. However, I think it should be "the PHYs" instead,
assuming that they are different.
^ permalink raw reply [relevance 99%]
* [PATCH net v2] r8169: always autoneg on resume
@ 2018-09-30 15:06 99% Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2018-09-30 15:06 UTC (permalink / raw)
To: netdev; +Cc: hkallweit1, nic_swsd, davem, linux-kernel
This affects at least versions 25 and 33, so assume all cards are broken
and just renegotiate by default.
Fixes: 10bc6a6042c9 ("r8169: fix autoneg issue on resume with RTL8168E")
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
drivers/net/ethernet/realtek/r8169.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index ab30aaeac6d3..db2f347c1463 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4072,13 +4072,12 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
genphy_soft_reset(dev->phydev);
- /* It was reported that chip version 33 ends up with 10MBit/Half on a
+ /* It was reported that several chips end up with 10MBit/Half on a
* 1GBit link after resuming from S3. For whatever reason the PHY on
- * this chip doesn't properly start a renegotiation when soft-reset.
+ * these chips doesn't properly start a renegotiation when soft-reset.
* Explicitly requesting a renegotiation fixes this.
*/
- if (tp->mac_version == RTL_GIGA_MAC_VER_33 &&
- dev->phydev->autoneg == AUTONEG_ENABLE)
+ if (dev->phydev->autoneg == AUTONEG_ENABLE)
phy_restart_aneg(dev->phydev);
}
--
2.19.0
^ permalink raw reply related [relevance 99%]
* [PATCH net] r8169: always autoneg on resume
@ 2018-09-30 1:18 99% Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2018-09-30 1:18 UTC (permalink / raw)
To: linux-netdev; +Cc: hkallweit1, nic_swsd, davem, linux-kernel
This affects at least versions 25 and 33, so assume all cards are broken
and just renegotiate by default.
Fixes: a2965f12fde6 ("r8169: remove rtl8169_set_speed_xmii")
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
drivers/net/ethernet/realtek/r8169.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index ab30aaeac6d3..db2f347c1463 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4072,13 +4072,12 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
genphy_soft_reset(dev->phydev);
- /* It was reported that chip version 33 ends up with 10MBit/Half on a
+ /* It was reported that several chips end up with 10MBit/Half on a
* 1GBit link after resuming from S3. For whatever reason the PHY on
- * this chip doesn't properly start a renegotiation when soft-reset.
+ * these chips doesn't properly start a renegotiation when soft-reset.
* Explicitly requesting a renegotiation fixes this.
*/
- if (tp->mac_version == RTL_GIGA_MAC_VER_33 &&
- dev->phydev->autoneg == AUTONEG_ENABLE)
+ if (dev->phydev->autoneg == AUTONEG_ENABLE)
phy_restart_aneg(dev->phydev);
}
--
2.19.0
^ permalink raw reply related [relevance 99%]
* [PATCH v2] mm: fix z3fold warnings on CONFIG_SMP=n
2018-09-27 21:12 99% ` Alex Xu
@ 2018-09-27 21:15 99% ` Alex Xu (Hello71)
0 siblings, 0 replies; 89+ results
From: Alex Xu (Hello71) @ 2018-09-27 21:15 UTC (permalink / raw)
To: Dan Streetman, linux-mm; +Cc: linux-kernel
Spinlocks are always lockable on UP systems, even if they were just
locked.
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
mm/z3fold.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d181..2e8d268ac 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -277,7 +277,7 @@ static void release_z3fold_page_locked(struct kref *ref)
{
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
refcount);
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
__release_z3fold_page(zhdr, true);
}
@@ -289,7 +289,7 @@ static void release_z3fold_page_locked_list(struct kref *ref)
list_del_init(&zhdr->buddy);
spin_unlock(&zhdr->pool->lock);
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
__release_z3fold_page(zhdr, true);
}
@@ -403,7 +403,7 @@ static void do_compact_page(struct z3fold_header *zhdr, bool locked)
page = virt_to_page(zhdr);
if (locked)
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
else
z3fold_page_lock(zhdr);
if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) {
--
2.19.0
^ permalink raw reply related [relevance 99%]
* Re: [PATCH] mm: fix z3fold warnings on CONFIG_SMP=n
@ 2018-09-27 21:12 99% ` Alex Xu
2018-09-27 21:15 99% ` [PATCH v2] " Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu @ 2018-09-27 21:12 UTC (permalink / raw)
To: Dan Streetman; +Cc: Linux-MM, linux-kernel
Quoting Dan Streetman (2018-09-27 20:41:21)
> On Thu, Sep 27, 2018 at 4:27 PM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
> >
> > Spinlocks are always lockable on UP systems, even if they were just
> > locked.
>
> i think it would be much better to just use either
> assert_spin_locked() or just spin_is_locked(), instead of an #ifdef.
>
I wrote a longer response and then learned about the WARN_ON_SMP macro,
so I'll just use that instead.
Original response below:
I thought about using assert_spin_locked, but I wanted to keep the
existing behavior, and it seems to make sense to try to lock the page if
we forgot to lock it earlier? Maybe not though; I don't understand this
code completely. I did write a version of z3fold_page_ensure_locked with
"if (assert_spin_locked(...))" but not only did that look even worse, it
doesn't even work, because assert_spin_locked is a statement on UP
systems, not an expression. It might be worth adding a
ensure_spin_locked function that does that though...
spin_is_locked currently still always returns 0 "on CONFIG_SMP=n builds
with CONFIG_DEBUG_SPINLOCK=n", so that would just return us to the same
problem of checking CONFIG_SMP.
^ permalink raw reply [relevance 99%]
* [PATCH] mm: fix z3fold warnings on CONFIG_SMP=n
@ 2018-09-27 20:27 99% Alex Xu (Hello71)
0 siblings, 1 reply; 89+ results
From: Alex Xu (Hello71) @ 2018-09-27 20:27 UTC (permalink / raw)
To: linux-mm, linux-kernel; +Cc: ddstreet
Spinlocks are always lockable on UP systems, even if they were just
locked.
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
---
mm/z3fold.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d181..4e6ad2de4 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -202,6 +202,13 @@ static inline void z3fold_page_lock(struct z3fold_header *zhdr)
spin_lock(&zhdr->page_lock);
}
+static inline void z3fold_page_ensure_locked(struct z3fold_header *zhdr)
+{
+#ifdef CONFIG_SMP
+ WARN_ON(z3fold_page_trylock(zhdr));
+#endif
+}
+
/* Try to lock a z3fold page */
static inline int z3fold_page_trylock(struct z3fold_header *zhdr)
{
@@ -277,7 +284,7 @@ static void release_z3fold_page_locked(struct kref *ref)
{
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
refcount);
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
__release_z3fold_page(zhdr, true);
}
@@ -289,7 +296,7 @@ static void release_z3fold_page_locked_list(struct kref *ref)
list_del_init(&zhdr->buddy);
spin_unlock(&zhdr->pool->lock);
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
__release_z3fold_page(zhdr, true);
}
@@ -403,7 +410,7 @@ static void do_compact_page(struct z3fold_header *zhdr, bool locked)
page = virt_to_page(zhdr);
if (locked)
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
else
z3fold_page_lock(zhdr);
if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) {
--
2.19.0
^ permalink raw reply related [relevance 99%]
* Re: bfq/ext4 disk IO hangs forever on resume
@ 2017-08-18 20:29 99% ` Alex Xu
0 siblings, 0 replies; 89+ results
From: Alex Xu @ 2017-08-18 20:29 UTC (permalink / raw)
To: Ming Lei, Jens Axboe
Cc: Linux Kernel Mailing List, open list:EXT4 FILE SYSTEM
On Tue, 25 Jul 2017 20:18:07 +0800
Ming Lei <tom.leiming@gmail.com> wrote as excerpted:
> On Mon, Jun 26, 2017 at 11:07 AM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
> > Hi,
> >
> > I get hangs when resuming when using bfq-mq with ext4 on 4.12-rc6+
> > (currently a4fd8b3accf43d407472e34403d4b0a4df5c0e71).
>
> Please test the following patch to see if it can help your issue:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-linus&id=765e40b675a9566459ddcb8358ad16f3b8344bbe
>
I tried 4.13-rc3+ (including that commit) and still have (seemingly)
the same issue.
^ permalink raw reply [relevance 99%]
* bfq/ext4 disk IO hangs forever on resume
@ 2017-06-26 3:07 88% Alex Xu
0 siblings, 1 reply; 89+ results
From: Alex Xu @ 2017-06-26 3:07 UTC (permalink / raw)
To: linux-kernel, linux-ext4
Hi,
I get hangs when resuming when using bfq-mq with ext4 on 4.12-rc6+
(currently a4fd8b3accf43d407472e34403d4b0a4df5c0e71).
Steps to reproduce:
1. boot computer
2. systemctl suspend
3. wait few seconds
4. press power button
5. type "ls" into console or SSH or do anything that does disk IO
Expected results:
Command is executed.
Actual results:
Command hangs.
lockdep has no comments, but sysrq-d shows that i_mutex_dir_key and
jbd2_handle are held by multiple processes, leading me to suspect that
ext4 is at least partially involved. [0]
sysrq-w lists many blocked processes [1]
This happens consistently, every time I resume the system from
suspend-to-RAM using this configuration. Switching to noop IO scheduler
makes it stop happening. I haven't tried switching filesystems yet.
I can do more debugging (enable KASAN or whatever), but usually when I
bother doing that I find someone has already sent a patch for the issue.
Please CC me on replies.
Cheers,
Alex.
[0]
4 locks held by systemd/384:
#0: (sb_writers#3){.+.+.+}, at: [<ffffffff811b0e5f>] mnt_want_write+0x1f/0x50
#1: (&type->i_mutex_dir_key/1){+.+.+.}, at: [<ffffffff8119b7ce>] do_rmdir+0x15e/0x1e0
#2: (&type->i_mutex_dir_key){++++++}, at: [<ffffffff81195ee0>] vfs_rmdir+0x50/0x130
#3: (jbd2_handle){++++..}, at: [<ffffffff8124f17f>] start_this_handle+0xff/0x430
4 locks held by syncthing/279:
#0: (&f->f_pos_lock){+.+.+.}, at: [<ffffffff811ade1e>] __fdget_pos+0x3e/0x50
#1: (sb_writers#3){.+.+.+}, at: [<ffffffff8118b04c>] vfs_write+0x17c/0x1d0
#2: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81217977>] ext4_file_write_iter+0x57/0x350
#3: (jbd2_handle){++++..}, at: [<ffffffff8124f17f>] start_this_handle+0xff/0x430
2 locks held by zsh/238:
#0: (&tty->ldisc_sem){++++.+}, at: [<ffffffff816fbeaf>] ldsem_down_read+0x1f/0x30
#1: (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8134fbb0>] n_tty_read+0xb0/0x8b0
2 locks held by sddm-greeter/267:
#0: (sb_writers#3){.+.+.+}, at: [<ffffffff811b0e5f>] mnt_want_write+0x1f/0x50
#1: (&type->i_mutex_dir_key){++++++}, at: [<ffffffff8119a698>] path_openat+0x2d8/0xa10
2 locks held by kworker/u16:28/330:
#0: ("events_unbound"){.+.+.+}, at: [<ffffffff810a1ef3>] process_one_work+0x1c3/0x420
#1: ((&entry->work)){+.+.+.}, at: [<ffffffff810a1ef3>] process_one_work+0x1c3/0x420
1 lock held by zsh/382:
#0: (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff81192570>] prepare_bprm_creds+0x30/0x70
[1]
task PC stack pid father
systemd D 0 384 0 0x00000000
Call Trace:
__schedule+0x295/0x7c0
? bit_wait+0x50/0x50
? bit_wait+0x50/0x50
schedule+0x31/0x80
io_schedule+0x11/0x40
bit_wait_io+0xc/0x50
__wait_on_bit+0x53/0x80
? bit_wait+0x50/0x50
out_of_line_wait_on_bit+0x6e/0x80
? autoremove_wake_function+0x30/0x30
do_get_write_access+0x20b/0x420
jbd2_journal_get_write_access+0x2c/0x60
__ext4_journal_get_write_access+0x55/0xa0
ext4_delete_entry+0x8c/0x140
? __ext4_journal_start_sb+0x4e/0xa0
ext4_rmdir+0x114/0x250
vfs_rmdir+0x6e/0x130
do_rmdir+0x1a3/0x1e0
SyS_unlinkat+0x1d/0x30
entry_SYSCALL_64_fastpath+0x18/0xad
jbd2/sda1-8 D 0 81 2 0x00000000
Call Trace:
__schedule+0x295/0x7c0
? bit_wait+0x50/0x50
schedule+0x31/0x80
io_schedule+0x11/0x40
bit_wait_io+0xc/0x50
__wait_on_bit+0x53/0x80
? bit_wait+0x50/0x50
out_of_line_wait_on_bit+0x6e/0x80
? autoremove_wake_function+0x30/0x30
__wait_on_buffer+0x2d/0x30
jbd2_journal_commit_transaction+0xe6a/0x1700
kjournald2+0xc8/0x270
? kjournald2+0xc8/0x270
? wake_atomic_t_function+0x50/0x50
kthread+0xfe/0x130
? commit_timeout+0x10/0x10
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x27/0x40
[ more processes follow, some different tracebacks ]
^ permalink raw reply [relevance 88%]
* Re: kernel BUG at mm/huge_memory.c:1798!
@ 2012-12-27 16:08 85% ` Alex Xu
0 siblings, 0 replies; 89+ results
From: Alex Xu @ 2012-12-27 16:08 UTC (permalink / raw)
To: Hillf Danton
Cc: Zhouping Liu, linux-mm, linux-kernel, Ingo Molnar,
Johannes Weiner, mgorman, hughd, Andrea Arcangeli
On 25/12/12 07:05 AM, Hillf Danton wrote:
> On Tue, Dec 25, 2012 at 12:38 PM, Zhouping Liu <zliu@redhat.com> wrote:
>> Hello all,
>>
>> I found the below kernel bug using latest mainline(637704cbc95),
>> my hardware has 2 numa nodes, and it's easy to reproduce the issue
>> using LTP test case: "# ./mmap10 -a -s -c 200":
>
> Can you test with 5a505085f0 and 4fc3f1d66b1 reverted?
>
> Hillf
>
(for people from mailing lists, please cc me when replying)
Same thing?
mapcount 0 page_mapcount 1
------------[ cut here ]------------
kernel BUG at mm/huge_memory.c:1798!
invalid opcode: 0000 [#1] SMP
Modules linked in: usb_storage wacom
CPU 3
Pid: 1287, comm: thunderbird Not tainted 3.8.0-rc1+ #5 HP-Pavilion
AU992AA-ABL e9262f/Indio
RIP: 0010:[<ffffffff810c12c0>] [<ffffffff810c12c0>] 0xffffffff810c12c0
RSP: 0018:ffff880216887c58 EFLAGS: 00010297
RAX: 0000000000000001 RBX: ffffea00065d0000 RCX: 0000000000000038
RDX: 000000000000002c RSI: 0000000000000046 RDI: ffffffff818e9e34
RBP: ffff880216887cd8 R08: 000000000000000a R09: 0000000000000000
R10: 0000000000000272 R11: 0000000000000271 R12: ffff880203fbad10
R13: 00007f1160e00000 R14: 0000000000000000 R15: ffffea00065d0000
FS: 00007f1180fca740(0000) GS:ffff88022fd80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fca86e18000 CR3: 00000002168e3000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process thunderbird (pid: 1287, threadinfo ffff880216886000, task
ffff8802259c4380)
Stack:
ffff880216887c68 ffffffff8145f284 ffff880216887cb8 ffff8801f9c24ac0
00000000065d0000 ffff8801f9c24af0 0000000000000000 ffff880216887cf8
0000000000000000 00000007f1160e00 0000000000000000 ffffea00065d0000
Call Trace:
[<ffffffff8145f284>] ? 0xffffffff8145f284
[<ffffffff810c2310>] 0xffffffff810c2310
[<ffffffff810a69ea>] 0xffffffff810a69ea
[<ffffffff8106bbd8>] ? 0xffffffff8106bbd8
[<ffffffff810a7710>] 0xffffffff810a7710
[<ffffffff810a4a1d>] 0xffffffff810a4a1d
[<ffffffff8106e062>] ? 0xffffffff8106e062
[<ffffffff810adf84>] ? 0xffffffff810adf84
[<ffffffff81460952>] 0xffffffff81460952
Code: 6d 81 31 c0 8b 75 c4 83 c2 01 e8 c4 94 39 00 e9 83 fb ff ff 0f 0b
0f 0b 0f 0b f3 90 48 8b 03 a9 00 00 80 00 75 f4 e9 b6 fb ff ff <0f> 0b
0f 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 49 89 d1 48
RIP [<ffffffff810c12c0>] 0xffffffff810c12c0
RSP <ffff880216887c58>
---[ end trace 0d442da0022ecdd1 ]---
I don't have KALLSYMS, so after running through ksymoops:
>>RIP; ffffffff810c12c0 <split_huge_page+600/610> <=====
>>RBX; ffffea00065d0000 <phys_startup_64+ffffea00055d0000/ffffffff80000000>
>>RDI; ffffffff818e9e34 <logbuf_lock+0/4>
>>RBP; ffff880216887cd8 <phys_startup_64+ffff880215887cd8/ffffffff80000000>
>>R12; ffff880203fbad10 <phys_startup_64+ffff880202fbad10/ffffffff80000000>
>>R13; 00007f1160e00000 <phys_startup_64+7f115fe00000/ffffffff80000000>
>>R15; ffffea00065d0000 <phys_startup_64+ffffea00055d0000/ffffffff80000000>
Trace; ffffffff8145f284 <schedule+24/70>
Trace; ffffffff810c2310 <__split_huge_page_pmd+b0/1b0>
Trace; ffffffff810a69ea <unmap_single_vma+25a/700>
Trace; ffffffff8106bbd8 <futex_wake+108/130>
Trace; ffffffff810a7710 <zap_page_range+90/d0>
Trace; ffffffff810a4a1d <sys_madvise+25d/690>
Trace; ffffffff8106e062 <sys_futex+142/1a0>
Trace; ffffffff810adf84 <vm_munmap+54/70>
Trace; ffffffff81460952 <system_call_fastpath+16/1b>
Code; ffffffff810c1295 <split_huge_page+5d5/610>
0000000000000000 <_RIP>:
Code; ffffffff810c1295 <split_huge_page+5d5/610>
0: 6d insl (%dx),%es:(%rdi)
Code; ffffffff810c1296 <split_huge_page+5d6/610>
1: 81 31 c0 8b 75 c4 xorl $0xc4758bc0,(%rcx)
Code; ffffffff810c129c <split_huge_page+5dc/610>
7: 83 c2 01 add $0x1,%edx
Code; ffffffff810c129f <split_huge_page+5df/610>
a: e8 c4 94 39 00 callq 3994d3 <_RIP+0x3994d3>
Code; ffffffff810c12a4 <split_huge_page+5e4/610>
f: e9 83 fb ff ff jmpq fffffffffffffb97
<_RIP+0xfffffffffffffb97>
Code; ffffffff810c12a9 <split_huge_page+5e9/610>
14: 0f 0b ud2
Code; ffffffff810c12ab <split_huge_page+5eb/610>
16: 0f 0b ud2
Code; ffffffff810c12ad <split_huge_page+5ed/610>
18: 0f 0b ud2
Code; ffffffff810c12af <split_huge_page+5ef/610>
1a: f3 90 pause
Code; ffffffff810c12b1 <split_huge_page+5f1/610>
1c: 48 8b 03 mov (%rbx),%rax
Code; ffffffff810c12b4 <split_huge_page+5f4/610>
1f: a9 00 00 80 00 test $0x800000,%eax
Code; ffffffff810c12b9 <split_huge_page+5f9/610>
24: 75 f4 jne 1a <_RIP+0x1a>
Code; ffffffff810c12bb <split_huge_page+5fb/610>
26: e9 b6 fb ff ff jmpq fffffffffffffbe1
<_RIP+0xfffffffffffffbe1>
Code; ffffffff810c12c0 <split_huge_page+600/610> <=====
2b: 0f 0b ud2 <=====
Code; ffffffff810c12c2 <split_huge_page+602/610>
2d: 0f 0b ud2
Code; ffffffff810c12c4 <split_huge_page+604/610>
2f: 66 66 66 2e 0f 1f 84 data32 data32 nopw %cs:0x0(%rax,%rax,1)
Code; ffffffff810c12cb <split_huge_page+60b/610>
36: 00 00 00 00 00
Code; ffffffff810c12d0 <do_huge_pmd_wp_page+0/840>
3b: 55 push %rbp
Code; ffffffff810c12d1 <do_huge_pmd_wp_page+1/840>
3c: 49 89 d1 mov %rdx,%r9
Code; ffffffff810c12d4 <do_huge_pmd_wp_page+4/840>
3f: 48 rex.W
^ permalink raw reply [relevance 85%]
Results 1-89 of 89 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <1621091901.34838094.1356409676820.JavaMail.root@redhat.com>
2012-12-25 4:38 ` kernel BUG at mm/huge_memory.c:1798! Zhouping Liu
2012-12-25 12:05 ` Hillf Danton
2012-12-27 16:08 85% ` Alex Xu
2017-06-26 3:07 88% bfq/ext4 disk IO hangs forever on resume Alex Xu
2017-07-25 12:18 ` Ming Lei
2017-08-18 20:29 99% ` Alex Xu
2018-09-27 20:27 99% [PATCH] mm: fix z3fold warnings on CONFIG_SMP=n Alex Xu (Hello71)
2018-09-27 20:41 ` Dan Streetman
2018-09-27 21:12 99% ` Alex Xu
2018-09-27 21:15 99% ` [PATCH v2] " Alex Xu (Hello71)
2018-09-30 1:18 99% [PATCH net] r8169: always autoneg on resume Alex Xu (Hello71)
2018-09-30 15:06 99% [PATCH net v2] " Alex Xu (Hello71)
2018-09-30 22:17 ` Daan Wendelen
2018-09-30 22:30 99% ` Alex Xu
2018-10-01 2:39 ` Andrew Lunn
2018-10-01 3:31 99% ` Alex Xu
2019-03-09 2:16 99% r8169 only works in promisc mode Alex Xu (Hello71)
2019-03-09 9:33 ` Heiner Kallweit
2019-03-09 16:53 99% ` Alex Xu
2019-03-23 1:26 93% ` Alex Xu
2019-03-24 15:30 99% shmem_recalc_inode: unable to handle kernel NULL pointer dereference Alex Xu (Hello71)
2019-03-25 22:08 ` Vineeth Pillai
2019-03-31 16:15 99% ` Alex Xu (Hello71)
2019-04-30 2:17 81% [PATCH] treewide: fix awk regexp over-escaping Alex Xu (Hello71)
2019-05-13 1:20 86% [REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e) Alex Xu (Hello71)
2019-05-18 6:44 [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries Mikhail Gavrilov
2019-05-18 11:07 ` Mikhail Gavrilov
2019-05-18 18:59 99% ` Alex Xu (Hello71)
2019-05-18 19:53 81% [PATCH] treewide: fix awk regexp over-escaping Alex Xu (Hello71)
2019-06-01 14:49 99% [PATCH] crypto: ux500 - fix license comment syntax error Alex Xu (Hello71)
2019-06-01 16:29 ` Greg KH
2019-06-01 19:41 99% ` Alex Xu
2019-07-24 22:33 95% [PATCH] random: print a message when waiting for random Alex Xu (Hello71)
[not found] <20200222003820.220854-1-alex_y_xu.ref@yahoo.ca>
2020-02-22 0:38 62% ` [PATCH] kbuild: move -pipe to global KBUILD_CFLAGS Alex Xu (Hello71)
2020-02-22 2:16 ` Nathan Chancellor
2020-02-22 4:01 82% ` Alex Xu (Hello71)
2020-02-22 8:01 ` Nathan Chancellor
2020-02-22 14:24 99% ` Alex Xu (Hello71)
[not found] <1586138158.v5u7myprlp.none.ref@localhost>
2020-04-06 19:51 99% ` Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults Alex Xu (Hello71)
2020-04-06 21:04 ` Thomas Hellström (VMware)
2020-04-07 0:38 99% ` Alex Xu (Hello71)
2020-04-07 11:26 ` Thomas Hellström (VMware)
2020-04-07 15:36 99% ` Alex Xu (Hello71)
[not found] <1587494585.7pihgq0z3i.none.ref@localhost>
2020-04-21 19:08 92% ` Unrecoverable AER error when resuming from RAM (hda regression in 5.7-rc2) Alex Xu (Hello71)
2020-05-20 11:11 next-0519 on thinkpad x60: sound related? window manager crash Pavel Machek
2020-06-07 15:58 88% ` Alex Xu (Hello71)
2020-06-07 16:38 ` 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was " Pavel Machek
2020-06-07 19:41 ` David Rientjes
2020-06-07 22:53 99% ` Alex Xu (Hello71)
2020-06-08 0:57 ` David Rientjes
2020-06-08 2:13 99% ` Alex Xu (Hello71)
2020-06-08 6:19 ` Christoph Hellwig
2020-06-08 13:53 99% ` Alex Xu (Hello71)
2020-06-09 11:47 ` Christoph Hellwig
2020-06-09 15:12 ` Takashi Iwai
[not found] ` <<s5hr1uogtna.wl-tiwai@suse.de>
2020-06-11 14:51 99% ` Alex Xu (Hello71)
2020-06-11 17:11 ` Takashi Iwai
2020-06-13 16:25 99% ` Alex Xu (Hello71)
2020-06-14 9:54 ` Takashi Iwai
2020-06-14 12:07 99% ` Alex Xu (Hello71)
2020-06-11 14:51 99% ` Alex Xu (Hello71)
2020-06-11 7:25 [patch for-5.8] dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL David Rientjes
2020-06-11 14:49 99% ` Alex Xu (Hello71)
[not found] <1591915710.rakbpzst8h.none.ref@localhost>
2020-06-11 23:05 89% ` AMD IOMMU + SME + amdgpu regression Alex Xu (Hello71)
2020-06-22 10:02 ` Joerg Roedel
2020-06-22 15:30 99% ` Alex Xu (Hello71)
[not found] <1588791882.08g1378g67.none.ref@localhost>
2020-07-01 14:35 77% ` Kernel compression benchmarks Alex Xu (Hello71)
[not found] <20200701153028.GA30962.ref@hsiangkao-HP-ZHAN-66-Pro-G1>
2020-07-01 15:50 ` Gao Xiang
2020-07-01 17:32 99% ` Alex Xu (Hello71)
[not found] <1596812929.lz7fuo8r2w.none.ref@localhost>
2020-08-07 15:19 99% ` wine fails to start with seccomp updates for v5.9-rc1 Alex Xu (Hello71)
2020-08-07 15:48 ` Linus Torvalds
2020-08-07 17:36 ` Thadeu Lima de Souza Cascardo
2020-08-07 17:51 99% ` Alex Xu (Hello71)
[not found] <1603684905.h43s1t0y05.none.ref@localhost>
2020-10-26 4:29 93% ` amdgpu crashes on OOM Alex Xu (Hello71)
2020-10-26 11:03 ` Michel Dänzer
2020-10-26 14:34 ` Deucher, Alexander
2020-10-26 14:50 99% ` Alex Xu (Hello71)
[not found] <20201117223253.65920-1-alex_y_xu.ref@yahoo.ca>
2020-11-17 22:32 17% ` [RFC PATCH] treewide: remove bzip2 compression support Alex Xu (Hello71)
[not found] <20201207184835.63538-1-alex_y_xu.ref@yahoo.ca>
2020-12-07 18:48 99% ` [PATCH 1/3] init: fall back on mounting raw root Alex Xu (Hello71)
2020-12-07 18:48 99% ` [PATCH 2/3] init: remove special-case for mtd/ubi Alex Xu (Hello71)
2020-12-07 18:48 99% ` [PATCH 3/3] init: remove root_device_name Alex Xu (Hello71)
[not found] <20201215190315.8681-1-alex_y_xu.ref@yahoo.ca>
2020-12-15 19:03 17% ` [RFC PATCH] treewide: remove bzip2 compression support Alex Xu (Hello71)
2020-12-15 23:39 99% ` Alex Xu (Hello71)
[not found] <20210215145305.283064-1-alex_y_xu.ref@yahoo.ca>
2021-02-15 14:53 71% ` [PATCH] proc_sysctl: clamp sizes using table->maxlen Alex Xu (Hello71)
2021-02-16 0:49 99% ` Alex Xu (Hello71)
2021-02-16 8:47 ` Christoph Hellwig
2021-02-27 14:41 99% ` Alex Xu (Hello71)
[not found] <1614646241.av51lk2de4.none.ref@localhost>
2021-03-02 0:57 96% ` 5.12-rc1 regression: freezing iou-mgr/wrk failed Alex Xu (Hello71)
2021-03-02 1:11 ` Jens Axboe
2021-03-02 1:25 ` Jens Axboe
2021-03-02 1:35 ` Jens Axboe
2021-03-02 22:13 99% ` Alex Xu (Hello71)
[not found] <1620493841.bxdq8r5haw.none.ref@localhost>
2021-05-08 17:54 97% ` regression: data corruption with ext4 on LUKS on nvme with torvalds master Alex Xu (Hello71)
2021-05-09 2:29 99% ` Alex Xu (Hello71)
2021-05-09 3:51 ` Jens Axboe
2021-05-09 14:47 97% ` Alex Xu (Hello71)
[not found] <1628086770.5rn8p04n6j.none.ref@localhost>
2021-08-04 15:37 71% ` [REGRESSION?] Simultaneous writes to a reader-less, non-full pipe can hang Alex Xu (Hello71)
2021-08-04 16:31 ` Linus Torvalds
2021-08-04 19:48 88% ` Alex Xu (Hello71)
[not found] <20210805000435.10833-1-alex_y_xu.ref@yahoo.ca>
[not found] ` <20210805000435.10833-1-alex_y_xu@yahoo.ca>
2021-08-05 1:33 91% ` [PATCH] pipe: increase minimum default pipe size to 2 pages Alex Xu (Hello71)
[not found] <20210805144047.13518-1-alex_y_xu.ref@yahoo.ca>
2021-08-05 14:40 88% ` Alex Xu (Hello71)
[not found] <20210907140836.323149-1-alex_y_xu.ref@yahoo.ca>
2021-09-07 14:08 99% ` [PATCH] drm/plane-helper: fix uninitialized variable reference Alex Xu (Hello71)
2021-09-08 18:34 Daniel Vetter
2021-09-09 1:32 99% ` [PATCH v2] " Alex Xu (Hello71)
[not found] <20211007063706.305984-1-alex_y_xu.ref@yahoo.ca>
2021-10-07 6:37 99% ` [PATCH v3] " Alex Xu (Hello71)
[not found] <1636040759.fnw68jgcw1.none.ref@localhost>
2021-11-04 16:01 86% ` No HDA sound output with AMD IOMMU on master Alex Xu (Hello71)
[not found] <20211120165349.99908-1-alex_y_xu.ref@yahoo.ca>
2021-11-20 16:53 80% ` [PATCH 1/2] kbuild: use perl instead of shell to get file size Alex Xu (Hello71)
2021-11-20 16:53 94% ` [PATCH 2/2] kbuild: pass --stream-size --no-content-size to zstd Alex Xu (Hello71)
[not found] <20211124153105.155739-1-alex_y_xu.ref@yahoo.ca>
2021-11-24 15:31 80% ` [PATCH v2 1/2] kbuild: use perl instead of shell to get file size Alex Xu (Hello71)
2021-11-24 15:31 90% ` [PATCH v2 2/2] kbuild: pass --stream-size --no-content-size to zstd Alex Xu (Hello71)
[not found] <1639853092.524jxfaem2.none.ref@localhost>
2021-12-18 18:57 99% ` very low IOPS due to "block: reduce kblockd_mod_delayed_work_on() CPU consumption" Alex Xu (Hello71)
[not found] <1643040870.3bwvk3sis4.none.ref@localhost>
2022-01-24 16:24 99% ` "blk-mq: fix tag_get wait task can't be awakened" causes hangs Alex Xu (Hello71)
2022-01-25 4:08 ` QiuLaibin
2022-01-25 15:15 98% ` Alex Xu (Hello71)
2022-01-27 10:00 [PATCH -next] blk-mq: Fix wrong wakeup batch configuration which will cause hang Laibin Qiu
2022-01-27 14:17 99% ` Alex Xu (Hello71)
2022-03-22 19:14 [PATCH] random: allow writes to /dev/urandom to influence fast init Jason A. Donenfeld
2022-03-23 4:30 90% ` Alex Xu (Hello71)
2022-03-23 4:47 ` Jason A. Donenfeld
2022-03-24 3:18 ` Jason A. Donenfeld
2022-03-24 16:28 99% ` Alex Xu (Hello71)
2022-03-24 17:20 ` Jason A. Donenfeld
2022-03-24 19:03 99% ` Alex Xu (Hello71)
[not found] <1648659326.eabkokyuym.none.ref@localhost>
2022-03-30 17:51 99% ` "dma-mapping: remove CONFIG_DMA_REMAP" causes AMD SME boot fail Alex Xu (Hello71)
2022-03-30 18:01 ` Christoph Hellwig
2022-03-30 19:17 99% ` Alex Xu (Hello71)
[not found] <20220413211357.26938-1-alex_y_xu.ref@yahoo.ca>
2022-04-13 21:13 99% ` [PATCH] mm/smaps_rollup: return empty file for kthreads instead of ESRCH Alex Xu (Hello71)
2022-04-13 21:27 ` Andrew Morton
2022-04-13 22:25 90% ` Alex Xu (Hello71)
2022-04-13 23:06 ` Andrew Morton
2022-04-14 3:23 ` Matthew Wilcox
2022-04-14 6:55 ` Alexey Dobriyan
2022-04-14 15:24 99% ` Alex Xu (Hello71)
[not found] <1656357116.rhe0mufk6a.none.ref@localhost>
[not found] ` <1656357116.rhe0mufk6a.none@localhost>
[not found] ` <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
[not found] ` <1656379893.q9yb069erk.none@localhost>
[not found] ` <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
2022-06-28 15:02 88% ` CONFIG_ANDROID (was: rcu_sched detected expedited stalls in amdgpu after suspend) Alex Xu (Hello71)
2022-06-28 18:54 ` Paul E. McKenney
2022-06-28 19:28 96% ` Alex Xu (Hello71)
[not found] <20220701210437.579322-1-alex_y_xu.ref@yahoo.ca>
2022-07-01 21:04 99% ` [PATCH] x86/Kconfig: Allow X86_X32_ABI with llvm-objcopy in some cases Alex Xu (Hello71)
[not found] <1693408388.rwssx8r1h9.none.ref@localhost>
2023-08-30 15:52 93% ` Don't fill the kernel log with memfd_create messages Alex Xu (Hello71)
[not found] <1710953751.8yx03664pf.none.ref@localhost>
2024-03-20 17:01 98% ` Regression: SUnreclaim leak: snd_ctl_ioctl? Alex Xu (Hello71)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).