thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/rapidquilt/apply/common.rs:539:61
Closed this issue · 8 comments
I'm trying to backport e32e5723256a drm/vc4: hdmi: Fix HPD GPIO detection
to the SLE15-SP4 branch which gives the following error when running rapidquilt. sequence-patch.sh without rapidquilt works as expected.
$ RUST_BACKTRACE=full ./scripts/sequence-patch.sh --rapid
SCRATCH_AREA not defined (defaulting to "tmp")
Creating tree in /home/patrik/suse/kernel/internal/kernel-source/tmp/linux-5.14-SLE15-SP4-git-fixes-2022-04-13
Cleaning up from previous run
Linking from /home/patrik/suse/kernel/internal/kernel-source/tmp/linux-5.14.orig
Applying 10173 patches using 32 threads...
Saving modified files...
Saving rejects to "drivers/gpu/drm/vc4/vc4_hdmi.c.rej"
Saving quilt backup files (last 100)...
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/rapidquilt/apply/common.rs:539:61
stack backtrace:
0: 0x5565a7e08b82 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7b351b19edc68675
1: 0x5565a7d9e70c - core::fmt::write::hda66aa43d7efd443
2: 0x5565a7dfcfe1 - std::io::Write::write_fmt::h3aebb987a9dbdcf6
3: 0x5565a7e04352 - std::panicking::default_hook::{{closure}}::h7e02fcec43867ea3
4: 0x5565a7e04dae - std::panicking::rust_panic_with_hook::h88a969557601b593
5: 0x5565a7e08ec6 - std::panicking::begin_panic_handler::{{closure}}::ha092887707fea9e8
6: 0x5565a7e08e66 - std::sys_common::backtrace::__rust_end_short_backtrace::h79f139e7bde27ff0
7: 0x5565a7e046a2 - rust_begin_unwind
8: 0x5565a7d7cd60 - core::panicking::panic_fmt::h0b501d90f307324b
9: 0x5565a7d7cd2c - core::panicking::panic::h39d8ed301699854e
10: 0x5565a7dd5eec - rapidquilt::apply::common::rollback_and_save_backup_files::h4121476355d20a79
11: 0x5565a7de6408 - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h8070cbe433daac02
12: 0x5565a7de8b37 - <rayon_core::job::HeapJob<BODY> as rayon_core::job::Job>::execute::h0a782b56199700b7
13: 0x5565a7d81ca2 - rayon_core::registry::WorkerThread::wait_until_cold::h4429617872cf317c
14: 0x5565a7dee059 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd6848c64c0c75636
15: 0x5565a7dee899 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hf41721fdb5e34723
16: 0x5565a7dfdb25 - std::sys::unix::thread::Thread::new::thread_start::hc697227d937b5e35
17: 0x7f93dae862ba - start_thread
18: 0x7f93daf10460 - __GI___clone3
19: 0x0 - <unknown>
[ Tree: /home/patrik/suse/kernel/internal/kernel-source/tmp/linux-5.14-SLE15-SP4-git-fixes-2022-04-13 ]
Hi Patrik, can you also attach the exact patch file and series.conf that triggers this bug?
Alternatively, push into a suitable named user branch (e.g. users/pjakobsson/SLE15-SP4/quilt-panic-20).
Affected branch pushed to users/pjakobsson/SLE15-SP4/quilt-panic-20
This is really odd because from this point I tried backporting the following patches:
82cb88af12d2 drm/vc4: hdmi: Use a mutex to prevent concurrent framework access
633be8c3c0c5 drm/vc4: hdmi: Prevent access to crtc->state outside of KMS
49c55f7b035b drm/i915/hdmi: Turn DP++ TMDS output buffers back on in encoder->shutdown()
2ee5ef9c934a drm/i915/fb: Fix rounding error in subsampled plane size calculation
244a36e50da0 drm/vc4: kms: Wait for the commit before increasing our clock rate
8aadeb8ad874 drm/vmwgfx: Remove the dedicated memory accounting
0215466a8585 drm/amd/display: Set exit_optimized_pwr_state for DCN31
d210919dbdc8 drm/tegra: Add back arm_iommu_detach_device()
3db817fce43e drm/amd/display: Send s0i2_rdy in stream_count == 0 optimization
c856f16c33e6 drm/amd/display: Set optimize_pwr_state for DCN31
They all fail to apply and rapidquilt spits out the same error. So I skip backporting those patches and suddenly it starts working again when I reach:
ffb378fb3069 drm/amdkfd: remove unused function
This patch also fails to apply but rapidquilt shows the normal output for the failed hunks.
I can at least reproduce the failure on my system. That's a good start.
All right. Rapidquilt fails as tries to rollback arch/x86/mm/mem_encrypt.c which was removed by patches.suse/x86-sev-rename-mem_encrypt-c-to-mem_encrypt_amd-c. Since the new filename is different from old filename, rapidquilt assumes that the file was renamed and it must also write a quilt backup file for the new file, but this new file is /dev/null, for which we do not have any backup, of course.
I'm trying to understand the various file names involved (old_filename, new_filename, target_filename and final_filename).
The FilePatch::old_filename and FilePatch::new_filename contain the filenames as they appear in the patch file. The PatchStatus::target_filename and PatchStatus::final_filename record what actually happened when applied the patch: target_filename is the file on which the patch was actually applied and final_filename is the filename after it (will be different from target_filename if it was a rename).
The code in rollback_and_save_backup_files assumes that the patch is renaming if the new_filename is present, which is weird. Maybe it should check the FilePatch::is_rename instead. But I don't really remember what the logic for creating quilt backup files should be.
Thank you, Michal, this is helpful. AFAICS rapidquilt now always saves both the old and the new filename. If they are identical, the file gets written twice (verified by passing -vv on the command line). I propose to change this behaviour:
- Always save the old filename.
- Save the new filename if and only if
applied_patch.file_patch.is_rename()is true. I have already checked that it is false for deleted and newly created files.
As I was preparing a test case, I can see what's wrong with the series. The patch that removes arch/x86/mm/mem_encrypt.c starts with the following header:
--- a/arch/x86/mm/mem_encrypt.c
+++ b/dev/null
@@ -1,507 +0,0 @@
NB the new file is not /dev/null, but b/dev/null. Why should the new name make any difference if a file is deleted?
Hm, I see, the file is not deleted by patch. It's merely truncated to zero bytes. Well, yes, that's a difference, indeed.