Bug 238971 - patch(1) modifies the wrong file
Summary: patch(1) modifies the wrong file
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-03 19:12 UTC by Eric van Gyzen
Modified: 2019-07-14 01:03 UTC (History)
3 users (show)

See Also:


Attachments
patch that adds a new Makefile (7.06 KB, patch)
2019-07-03 19:12 UTC, Eric van Gyzen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric van Gyzen freebsd_committer 2019-07-03 19:12:47 UTC
Created attachment 205503 [details]
patch that adds a new Makefile

I'm running 12.0-STABLE r348455.  I used patch(1) to apply the attached patch file to a head tree at r349671.  The patch adds a new Makefile under a new directory under tools/, but patch(1) applied the change to the top-level Makefile.  It also added the new .c file to the top-level directory, although that should have gone in the new directory.

Here is the patch output:

$ patch < ~/0001-Save-the-last-callout-function-executed-on-each-CPU.patch 
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From ee77139c3ce21bac8665411c9d5e7c945afcf981 Mon Sep 17 00:00:00 2001
|From: Eric van Gyzen <eric@vangyzen.net>
|Date: Fri, 28 Jun 2019 05:16:27 -0500
|Subject: [PATCH 1/2] Save the last callout function executed on each CPU
|
|Save the last callout function pointer (and its argument) executed
|on each CPU for inspection by a debugger.  Add a ddb `show callout_last`
|command to show these pointers.  Add a kernel module that I used
|for testing that command.
|
|Relocate `ce_migration_cpu` to reduce padding and therefore preserve
|the size of `struct callout_cpu` (320 bytes on amd64) despite the
|added members.
|
|This should help diagnose reference-after-free bugs where the
|callout's mutex has already been freed when `softclock_call_cc`
|tries to unlock it.
|
|You might hope that the pointer would still be available, but it
|isn't.  The argument to that function is on the stack (because
|`softclock_call_cc` uses it later), and that might be enough in
|some cases, but even then, it's very laborious.  A pointer to the
|callout is saved right before these newly added fields, but that
|callout might have been freed.  We still have the pointer to its
|associated mutex, and the name within might be enough, but it might
|also have been freed.
|---
| sys/kern/kern_timeout.c                | 39 +++++++++++-
| tools/test/callout_free/Makefile       |  4 ++
| tools/test/callout_free/callout_free.c | 87 ++++++++++++++++++++++++++
| 3 files changed, 129 insertions(+), 1 deletion(-)
| create mode 100644 tools/test/callout_free/Makefile
| create mode 100644 tools/test/callout_free/callout_free.c
|
|diff --git a/sys/kern/kern_timeout.c b/sys/kern/kern_timeout.c
|index 81b4a14ecf08..73f3904d1837 100644
|--- a/sys/kern/kern_timeout.c
|+++ b/sys/kern/kern_timeout.c
--------------------------
Patching file sys/kern/kern_timeout.c using Plan A...
Hunk #1 succeeded at 65.
Hunk #2 succeeded at 144.
Hunk #3 succeeded at 180.
Hunk #4 succeeded at 691.
Hunk #5 succeeded at 1677.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/tools/test/callout_free/Makefile b/tools/test/callout_free/Makefile
|new file mode 100644
|index 000000000000..6421c072c5b9
|--- /dev/null
|+++ b/tools/test/callout_free/Makefile
--------------------------
Patching file Makefile using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/tools/test/callout_free/callout_free.c b/tools/test/callout_free/callout_free.c
|new file mode 100644
|index 000000000000..4556687e06f6
|--- /dev/null
|+++ b/tools/test/callout_free/callout_free.c
--------------------------
(Creating file callout_free.c...)
Patching file callout_free.c using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.
Hmm...  Ignoring the trailing garbage.
done

$ svn st
M       Makefile
?       Makefile.orig
?       callout_free.c
?       callout_free.c.orig
M       sys/kern/kern_timeout.c
?       sys/kern/kern_timeout.c.orig

$ svn diff Makefile
Index: Makefile
===================================================================
--- Makefile	(revision 349673)
+++ Makefile	(working copy)
@@ -1,3 +1,7 @@
+KMOD=	callout_free
+SRCS=	callout_free.c
+
+.include <bsd.kmod.mk>
 #
 # $FreeBSD$
 #
Comment 1 Eric van Gyzen freebsd_committer 2019-07-03 19:15:47 UTC
When I created the directory and tried again, patch(1) did the right thing.
Comment 2 Andriy Gapon freebsd_committer 2019-07-04 13:06:48 UTC
What happens if you use -p0 option to patch in the original scenario?