RE: [PATCH v4 08/17] iommufd: Always setup MSI and anforce cc on kernel-managed domains
> From: Nicolin Chen > Sent: Monday, October 23, 2023 8:18 AM > > On Sat, Oct 21, 2023 at 01:38:04PM -0300, Jason Gunthorpe wrote: > > On Fri, Oct 20, 2023 at 11:59:13AM -0700, Nicolin Chen wrote: > > > On Fri, Oct 20, 2023 at 10:55:01AM -0300, Jason Gunthorpe wrote: > > > > On Fri, Oct 20, 2023 at 02:43:58AM +, Tian, Kevin wrote: > > > > > > > > > But the user shouldn't assume such explicit consistency since it's not > > > > > defined in our uAPI. All we defined is that the attaching may > > > > > fail due to incompatibility for whatever reason then the user can > > > > > always try creating a new hwpt for the to-be-attached device. From > > > > > this regard I don't see providing consistency of result is > > > > > necessary. > > > > > > > > Anyhow, OK, lets add a comment summarizing your points and remove > the > > > > cc upgrade at attach time (sorry Nicolin/Yi!) > > > > > > Ack. I will send a small removal series. I assume it should CC > > > stable tree also? > > > > No, it seems more like tidying that fixing a functional issue, do I > > misunderstand? > > Hmm. Maybe the misunderstanding is mine -- Kevin was asking if > it was already a bug and you answered yes: > https://lore.kernel.org/linux-iommu/20231016115736.gp3...@nvidia.com/ > currently intel-iommu driver already rejects 1) enforcing CC on a domain which is already attached to non-CC device and 2) attaching a non-CC device to a domain which has enforce_cc. so there is no explorable bug to fix in stable tree. Just logically intel-iommu driver doesn't support enforcing Cc on a domain which is capable of enforce-cc and already has valid mappings. Then it should add proper check to prevent it from being attempted by future usages.
Re: [PATCH v4 08/17] iommufd: Always setup MSI and anforce cc on kernel-managed domains
On Sat, Oct 21, 2023 at 01:38:04PM -0300, Jason Gunthorpe wrote: > On Fri, Oct 20, 2023 at 11:59:13AM -0700, Nicolin Chen wrote: > > On Fri, Oct 20, 2023 at 10:55:01AM -0300, Jason Gunthorpe wrote: > > > On Fri, Oct 20, 2023 at 02:43:58AM +, Tian, Kevin wrote: > > > > > > > What we want to prevent is attaching a non-CC device to a CC domain > > > > or upgrade a non-CC domain to CC since in both case the non-CC > > > > device will be broken due to incompatible page table format. > > > > > > [..] > > > > > > > Who cares about such consistency? sure the result is different due to > > > > order: > > > > > > > > 1) creating hwpt for dev1 (non-CC) then later attaching hwpt to > > > > dev2 (CC) will succeed; > > > > > > > > 2) creating hwpt for dev2 (CC) then later attaching hwpt to > > > > dev1 (non-CC) will fail then the user should create a new hwpt > > > > for dev1; > > > > > > AH... So really what the Intel driver wants is not upgrade to CC but > > > *downgrade* from CC. > > > > > > non-CC is the type that is universally applicable, so if we come > > > across a non-CC capable device the proper/optimal thing is to degrade > > > the HWPT and re-use it, not allocate a new HWPT. > > > > > > So the whole thing is upside down. > > > > > > As changing the IOPTEs in flight seems hard, and I don't want to see > > > the Intel driver get slowed down to accomodate this, I think you are > > > right to say this should be a creation time property only. > > > > > > I still think userspace should be able to select it so it can minimize > > > the number of HWPTs required. > > > > > > > But the user shouldn't assume such explicit consistency since it's not > > > > defined in our uAPI. All we defined is that the attaching may > > > > fail due to incompatibility for whatever reason then the user can > > > > always try creating a new hwpt for the to-be-attached device. From > > > > this regard I don't see providing consistency of result is > > > > necessary. > > > > > > Anyhow, OK, lets add a comment summarizing your points and remove the > > > cc upgrade at attach time (sorry Nicolin/Yi!) > > > > Ack. I will send a small removal series. I assume it should CC > > stable tree also? > > No, it seems more like tidying that fixing a functional issue, do I > misunderstand? Hmm. Maybe the misunderstanding is mine -- Kevin was asking if it was already a bug and you answered yes: https://lore.kernel.org/linux-iommu/20231016115736.gp3...@nvidia.com/ If this shouldn't be a bug fix, I could just merge them into a single tidying patch and add the comments you suggested below. > > And where should we add this comment? Kdoc of > > the alloc uAPI? > > Maybe right in front of the only enforce_cc op callback? OK. How about this? Might be a bit verbose though: /* * enforce_cache_coherenc must be determined during the HWPT allocation. * Note that a HWPT (non-CC) created for a device (non-CC) can be later * reused by another device (either non-CC or CC). However, A HWPT (CC) * created for a device (CC) cannot be reused by another device (non-CC) * but only devices (CC). Instead user space in this case would need to * allocate a separate HWPT (non-CC). */ Thanks Nic
[PATCH 2/2] mm/damon/sysfs-test: add a unit test for damon_sysfs_set_targets()
damon_sysfs_set_targets() had a bug that can result in unexpected memory
usage and monitoring overhead increase. The bug has fixed by a previous
commit. Add a unit test for avoiding a similar bug of future.
Signed-off-by: SeongJae Park
---
mm/damon/Kconfig | 12 ++
mm/damon/sysfs-test.h | 86 +++
mm/damon/sysfs.c | 2 +
3 files changed, 100 insertions(+)
create mode 100644 mm/damon/sysfs-test.h
diff --git a/mm/damon/Kconfig b/mm/damon/Kconfig
index 436c6b4cb5ec..29f43fbc2eff 100644
--- a/mm/damon/Kconfig
+++ b/mm/damon/Kconfig
@@ -59,6 +59,18 @@ config DAMON_SYSFS
This builds the sysfs interface for DAMON. The user space can use
the interface for arbitrary data access monitoring.
+config DAMON_SYSFS_KUNIT_TEST
+ bool "Test for damon debugfs interface" if !KUNIT_ALL_TESTS
+ depends on DAMON_SYSFS && KUNIT=y
+ default KUNIT_ALL_TESTS
+ help
+ This builds the DAMON sysfs interface Kunit test suite.
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation.
+
+ If unsure, say N.
+
config DAMON_DBGFS
bool "DAMON debugfs interface (DEPRECATED!)"
depends on DAMON_VADDR && DAMON_PADDR && DEBUG_FS
diff --git a/mm/damon/sysfs-test.h b/mm/damon/sysfs-test.h
new file mode 100644
index ..73bdce2452c1
--- /dev/null
+++ b/mm/damon/sysfs-test.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Data Access Monitor Unit Tests
+ *
+ * Author: SeongJae Park
+ */
+
+#ifdef CONFIG_DAMON_SYSFS_KUNIT_TEST
+
+#ifndef _DAMON_SYSFS_TEST_H
+#define _DAMON_SYSFS_TEST_H
+
+#include
+
+static unsigned int nr_damon_targets(struct damon_ctx *ctx)
+{
+ struct damon_target *t;
+ unsigned int nr_targets = 0;
+
+ damon_for_each_target(t, ctx)
+ nr_targets++;
+
+ return nr_targets;
+}
+
+static int __damon_sysfs_test_get_any_pid(int min, int max)
+{
+ struct pid *pid;
+ int i;
+
+ for (i = min; i <= max; i++) {
+ pid = find_get_pid(i);
+ if (pid) {
+ put_pid(pid);
+ return i;
+ }
+ }
+ return -1;
+}
+
+static void damon_sysfs_test_set_targets(struct kunit *test)
+{
+ struct damon_sysfs_targets *sysfs_targets;
+ struct damon_sysfs_target *sysfs_target;
+ struct damon_ctx *ctx;
+
+ sysfs_targets = damon_sysfs_targets_alloc();
+ sysfs_targets->nr = 1;
+ sysfs_targets->targets_arr = kmalloc_array(1,
+ sizeof(*sysfs_targets->targets_arr), GFP_KERNEL);
+
+ sysfs_target = damon_sysfs_target_alloc();
+ sysfs_target->pid = __damon_sysfs_test_get_any_pid(12, 100);
+ sysfs_target->regions = damon_sysfs_regions_alloc();
+ sysfs_targets->targets_arr[0] = sysfs_target;
+
+ ctx = damon_new_ctx();
+
+ damon_sysfs_set_targets(ctx, sysfs_targets);
+ KUNIT_EXPECT_EQ(test, 1u, nr_damon_targets(ctx));
+
+ sysfs_target->pid = __damon_sysfs_test_get_any_pid(
+ sysfs_target->pid + 1, 200);
+ damon_sysfs_set_targets(ctx, sysfs_targets);
+ KUNIT_EXPECT_EQ(test, 1u, nr_damon_targets(ctx));
+
+ damon_destroy_ctx(ctx);
+ kfree(sysfs_targets->targets_arr);
+ kfree(sysfs_targets);
+ kfree(sysfs_target);
+}
+
+static struct kunit_case damon_sysfs_test_cases[] = {
+ KUNIT_CASE(damon_sysfs_test_set_targets),
+ {},
+};
+
+static struct kunit_suite damon_sysfs_test_suite = {
+ .name = "damon-sysfs",
+ .test_cases = damon_sysfs_test_cases,
+};
+kunit_test_suite(damon_sysfs_test_suite);
+
+#endif /* _DAMON_SYSFS_TEST_H */
+
+#endif /* CONFIG_DAMON_SYSFS_KUNIT_TEST */
diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index 5268e8503722..d13e353bee52 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -1804,3 +1804,5 @@ static int __init damon_sysfs_init(void)
return err;
}
subsys_initcall(damon_sysfs_init);
+
+#include "sysfs-test.h"
--
2.34.1
[PATCH 0/2] mm/damon/sysfs: fix unexpected targets adding bug
The sysfs code for online targets updating can result in adding more than expected monigoring targets to the context. It can result in unexpected amount of memory consumption and monitoring overhead. This patchset fixes the issue (patch 1), and add a kunit test for avoiding similar bug of future (patch 2). SeongJae Park (2): mm/damon/sysfs: remove requested targets when online-commit inputs mm/damon/sysfs-test: add a unit test for damon_sysfs_set_targets() mm/damon/Kconfig | 12 ++ mm/damon/sysfs-test.h | 86 +++ mm/damon/sysfs.c | 52 ++ 3 files changed, 109 insertions(+), 41 deletions(-) create mode 100644 mm/damon/sysfs-test.h base-commit: 9a969da6ffb9609f5fa8d0b7fdc6859c37a10335 -- 2.34.1
Re: [PATCH] selftests:net change ifconfig with ip command
On 10/22/23 5:31 AM, Swarup Laxman Kotiaklapudi wrote:
> diff --git a/tools/testing/selftests/net/route_localnet.sh
> b/tools/testing/selftests/net/route_localnet.sh
> index 116bfeab72fa..3ab9beb4462c 100755
> --- a/tools/testing/selftests/net/route_localnet.sh
> +++ b/tools/testing/selftests/net/route_localnet.sh
> @@ -18,8 +18,10 @@ setup() {
> ip route del 127.0.0.0/8 dev lo table local
> ip netns exec "${PEER_NS}" ip route del 127.0.0.0/8 dev lo table local
>
> -ifconfig veth0 127.25.3.4/24 up
> -ip netns exec "${PEER_NS}" ifconfig veth1 127.25.3.14/24 up
> +ip a add 127.25.3.4/24 dev veth0
ip addr add ...
> +ip link set dev veth0 up
> +ip netns exec "${PEER_NS}" ip a add 127.25.3.14/24 dev veth1
ip addr add ...
> +ip netns exec "${PEER_NS}" ip link set dev veth1 up
>
> ip route flush cache
> ip netns exec "${PEER_NS}" ip route flush cache
Re: [PATCH v3 2/3] userfaultfd: UFFDIO_MOVE uABI
On Thu, Oct 19, 2023 at 02:24:06PM -0700, Suren Baghdasaryan wrote:
> On Thu, Oct 12, 2023 at 3:00 PM Peter Xu wrote:
> >
> > On Sun, Oct 08, 2023 at 11:42:27PM -0700, Suren Baghdasaryan wrote:
> > > From: Andrea Arcangeli
> > >
> > > Implement the uABI of UFFDIO_MOVE ioctl.
> > > UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application
> > > needs pages to be allocated [1]. However, with UFFDIO_MOVE, if pages are
> > > available (in userspace) for recycling, as is usually the case in heap
> > > compaction algorithms, then we can avoid the page allocation and memcpy
> > > (done by UFFDIO_COPY). Also, since the pages are recycled in the
> > > userspace, we avoid the need to release (via madvise) the pages back to
> > > the kernel [2].
> > > We see over 40% reduction (on a Google pixel 6 device) in the compacting
> > > thread’s completion time by using UFFDIO_MOVE vs. UFFDIO_COPY. This was
> > > measured using a benchmark that emulates a heap compaction implementation
> > > using userfaultfd (to allow concurrent accesses by application threads).
> > > More details of the usecase are explained in [2].
> > > Furthermore, UFFDIO_MOVE enables moving swapped-out pages without
> > > touching them within the same vma. Today, it can only be done by mremap,
> > > however it forces splitting the vma.
> > >
> > > [1]
> > > https://lore.kernel.org/all/1425575884-2574-1-git-send-email-aarca...@redhat.com/
> > > [2]
> > > https://lore.kernel.org/linux-mm/ca+eeso4uo84ssnbharh4hvlnhauq5nzknkxqxrcyjninvjp...@mail.gmail.com/
> > >
> > > Update for the ioctl_userfaultfd(2) manpage:
> > >
> > >UFFDIO_MOVE
> > >(Since Linux xxx) Move a continuous memory chunk into the
> > >userfault registered range and optionally wake up the blocked
> > >thread. The source and destination addresses and the number of
> > >bytes to move are specified by the src, dst, and len fields of
> > >the uffdio_move structure pointed to by argp:
> > >
> > >struct uffdio_move {
> > >__u64 dst;/* Destination of move */
> > >__u64 src;/* Source of move */
> > >__u64 len;/* Number of bytes to move */
> > >__u64 mode; /* Flags controlling behavior of move */
> > >__s64 move; /* Number of bytes moved, or negated error */
> > >};
> > >
> > >The following value may be bitwise ORed in mode to change the
> > >behavior of the UFFDIO_MOVE operation:
> > >
> > >UFFDIO_MOVE_MODE_DONTWAKE
> > > Do not wake up the thread that waits for page-fault
> > > resolution
> > >
> > >UFFDIO_MOVE_MODE_ALLOW_SRC_HOLES
> > > Allow holes in the source virtual range that is being moved.
> > > When not specified, the holes will result in ENOENT error.
> > > When specified, the holes will be accounted as successfully
> > > moved memory. This is mostly useful to move hugepage aligned
> > > virtual regions without knowing if there are transparent
> > > hugepages in the regions or not, but preventing the risk of
> > > having to split the hugepage during the operation.
> > >
> > >The move field is used by the kernel to return the number of
> > >bytes that was actually moved, or an error (a negated errno-
> > >style value). If the value returned in move doesn't match the
> > >value that was specified in len, the operation fails with the
> > >error EAGAIN. The move field is output-only; it is not read by
> > >the UFFDIO_MOVE operation.
> > >
> > >The operation may fail for various reasons. Usually, remapping of
> > >pages that are not exclusive to the given process fail; once KSM
> > >might deduplicate pages or fork() COW-shares pages during fork()
> > >with child processes, they are no longer exclusive. Further, the
> > >kernel might only perform lightweight checks for detecting whether
> > >the pages are exclusive, and return -EBUSY in case that check
> > > fails.
> > >To make the operation more likely to succeed, KSM should be
> > >disabled, fork() should be avoided or MADV_DONTFORK should be
> > >configured for the source VMA before fork().
> > >
> > >This ioctl(2) operation returns 0 on success. In this case, the
> > >entire area was moved. On error, -1 is returned and errno is
> > >set to indicate the error. Possible errors include:
> > >
> > >EAGAIN The number of bytes moved (i.e., the value returned in
> > > the move field) does not equal the value that was
> > > specified in the len field.
> > >
> > >EINVAL Either dst or len was not a multiple of the system page
> > > size, or the range specified by src and len or dst and len
> > >
Re: [PATCH v3 2/3] userfaultfd: UFFDIO_MOVE uABI
On Fri, Oct 20, 2023 at 07:16:19PM +0200, David Hildenbrand wrote: > These are rather the vibes I'm getting from Peter. "Why rename it, could > confuse people because the original patches are old", "Why exclude it if it > has been included in the original patches". Not the kind of reasoning I can > relate to when it comes to upstreaming some patches. You can't blame anyone if you misunderstood and biased the question. The first question is definitely valid, even until now. You guys still prefer to rename it, which I'm totally fine with. The 2nd question is wrong from your interpretation. That's not my point, at least not starting from a few replies already. What I was asking for is why such page movement between mm is dangerous. I don't think I get solid answers even until now. Noticing "memcg is missing" is not an argument for "cross-mm is dangerous", it's a review comment. Suren can address that. You'll propose a new feature that may tag an mm is not an argument either, if it's not merged yet. We can also address that depending on what it is, also on which lands earlier. It'll be good to discuss these details even in a single-mm support. Anyone would like to add that can already refer to discussion in this thread. I hope I'm clear. -- Peter Xu
[PATCH] selftests:net change ifconfig with ip command
Change ifconfig with ip command,
on a system where ifconfig is
not used this script will not
work correcly.
Test result with this patchset:
sudo make TARGETS="net" kselftest
TAP version 13
1..1
timeout set to 1500
selftests: net: route_localnet.sh
run arp_announce test
net.ipv4.conf.veth0.route_localnet = 1
net.ipv4.conf.veth1.route_localnet = 1
net.ipv4.conf.veth0.arp_announce = 2
net.ipv4.conf.veth1.arp_announce = 2
PING 127.25.3.14 (127.25.3.14) from 127.25.3.4 veth0: 56(84)
bytes of data.
64 bytes from 127.25.3.14: icmp_seq=1 ttl=64 time=0.038 ms
64 bytes from 127.25.3.14: icmp_seq=2 ttl=64 time=0.068 ms
64 bytes from 127.25.3.14: icmp_seq=3 ttl=64 time=0.068 ms
64 bytes from 127.25.3.14: icmp_seq=4 ttl=64 time=0.068 ms
64 bytes from 127.25.3.14: icmp_seq=5 ttl=64 time=0.068 ms
--- 127.25.3.14 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4073ms
rtt min/avg/max/mdev = 0.038/0.062/0.068/0.012 ms
ok
run arp_ignore test
net.ipv4.conf.veth0.route_localnet = 1
net.ipv4.conf.veth1.route_localnet = 1
net.ipv4.conf.veth0.arp_ignore = 3
net.ipv4.conf.veth1.arp_ignore = 3
PING 127.25.3.14 (127.25.3.14) from 127.25.3.4 veth0: 56(84)
bytes of data.
64 bytes from 127.25.3.14: icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from 127.25.3.14: icmp_seq=2 ttl=64 time=0.065 ms
64 bytes from 127.25.3.14: icmp_seq=3 ttl=64 time=0.066 ms
64 bytes from 127.25.3.14: icmp_seq=4 ttl=64 time=0.065 ms
64 bytes from 127.25.3.14: icmp_seq=5 ttl=64 time=0.065 ms
--- 127.25.3.14 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4092ms
rtt min/avg/max/mdev = 0.032/0.058/0.066/0.013 ms
ok
ok 1 selftests: net: route_localnet.sh
...
Signed-off-by: Swarup Laxman Kotiaklapudi
---
tools/testing/selftests/net/route_localnet.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/net/route_localnet.sh
b/tools/testing/selftests/net/route_localnet.sh
index 116bfeab72fa..3ab9beb4462c 100755
--- a/tools/testing/selftests/net/route_localnet.sh
+++ b/tools/testing/selftests/net/route_localnet.sh
@@ -18,8 +18,10 @@ setup() {
ip route del 127.0.0.0/8 dev lo table local
ip netns exec "${PEER_NS}" ip route del 127.0.0.0/8 dev lo table local
-ifconfig veth0 127.25.3.4/24 up
-ip netns exec "${PEER_NS}" ifconfig veth1 127.25.3.14/24 up
+ip a add 127.25.3.4/24 dev veth0
+ip link set dev veth0 up
+ip netns exec "${PEER_NS}" ip a add 127.25.3.14/24 dev veth1
+ip netns exec "${PEER_NS}" ip link set dev veth1 up
ip route flush cache
ip netns exec "${PEER_NS}" ip route flush cache
--
2.34.1
Re: [PATCH 5/5] selftests/nolibc: generate config automatically
On Tue, Oct 10, 2023 at 02:34:00PM +0200, Thomas Weißschuh wrote: > This new target generates a .config if none exists yet. > > Also drop the defconfig target with its hidden call to 'mrproper' which > is fairly invasive. > If users want to overwrite their kernel existing kernel configuration > they can do so easily from the toplevel directory. Hmmm I'm not sure about that one, I pretty much remember seeing failing arm64 builds when mrproper and prepare were missing. I would argue that someone starting "make defconfig" does expect the config to be dropped, hence mrproper to be called as well. What specific issue did you face with it ? Maybe we can restrict it to only a few cases ? Willy
Re: [PATCH 4/5] selftests/nolibc: support out-of-tree builds
On Tue, Oct 10, 2023 at 02:33:59PM +0200, Thomas Weißschuh wrote: > Out of tree builds are much more convenient when building for multiple > architectures or configurations in parallel. > > Only absolute O= parameters are supported as Makefile.include will > always resolve relative paths in relation to $(srctree) instead of the > current directory. > > Add a call to "make outputmakefile" to verify that the sourcetree is > clean. At first this worried me, I thought you meant clean in the git meaning, but it's clean as in "make clean" from what I'm seeing. Yeah that sounds reasonable. > This is based on Zhangjins out-of-tree patch. > It extends that work for get_init_cpio support and also drops relative > O= specifications explicitly. Yeah I remember these discussions about these shortcomings, that's pretty reasonable. > Link: > https://lore.kernel.org/lkml/06d96bd81fe812a9718098a383678ad3beba98b1.1691215074.git.fal...@tinylab.org/ > Signed-off-by: Thomas Weißschuh (...) I think you should add a Suggested-by at least since Zhangjin attempted that work quite a few times already and allowed to make progress in that direction (maybe even co-developed, I'm not sure). Acked-by: Willy Tarreau Willy
Re: [PATCH 3/5] selftests/nolibc: anchor paths in $(srcdir) if possible
On Tue, Oct 10, 2023 at 02:33:58PM +0200, Thomas Weißschuh wrote: > It is easier to recognize paths from their well-known location in the > source tree than having to resolve the relative path in ones head. > > Signed-off-by: Thomas Weißschuh > --- > tools/testing/selftests/nolibc/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/testing/selftests/nolibc/Makefile > b/tools/testing/selftests/nolibc/Makefile > index 258293639572..598d53c5cb7b 100644 > --- a/tools/testing/selftests/nolibc/Makefile > +++ b/tools/testing/selftests/nolibc/Makefile > @@ -167,7 +167,7 @@ sysroot: sysroot/$(ARCH)/include > sysroot/$(ARCH)/include: > $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot > $(QUIET_MKDIR)mkdir -p sysroot > - $(Q)$(MAKE) -C ../../../include/nolibc ARCH=$(ARCH) > OUTPUT=$(CURDIR)/sysroot/ headers_standalone > + $(Q)$(MAKE) -C $(srctree)/tools/include/nolibc ARCH=$(ARCH) > OUTPUT=$(CURDIR)/sysroot/ headers_standalone > $(Q)mv sysroot/sysroot sysroot/$(ARCH) > > ifneq ($(NOLIBC_SYSROOT),0) > @@ -177,7 +177,7 @@ nolibc-test: nolibc-test.c sysroot/$(ARCH)/include > else > nolibc-test: nolibc-test.c > $(QUIET_CC)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ \ > - -nostdlib -static -include ../../../include/nolibc/nolibc.h $< -lgcc > + -nostdlib -static -include $(srctree)/tools/include/nolibc/nolibc.h > $< -lgcc > endif Agreed, this comes from the early days where we didn't have srctree, that's better this way. Acked-by: Willy Tarreau Willy
