On Fri, Apr 05, 2019 at 06:26:27PM +0200, 'Luis Ressel' wrote:
> On Fri, Apr 05, 2019 at 04:16:14PM +, David Laight wrote:
>
> > In which case you should be looking at a way of removing -Wundef
> > not removing -Werror.
>
> No, my whole point is that this
On Fri, Apr 05, 2019 at 11:15:41AM -0500, Josh Poimboeuf wrote:
> I consider that a good thing, because I *want* the build to be broken
> when somebody uses a bad version of libelf. A patch to produce a more
> useful error message (e.g., "bad version of libelf") would be welcome of
> course.
Do t
On Fri, Apr 05, 2019 at 04:16:14PM +, David Laight wrote:
> In which case you should be looking at a way of removing -Wundef
> not removing -Werror.
No, my whole point is that this blacklisting approach doesn't work
outside a controlled dev environment, because different
compilers/compiler ve
On Fri, Apr 05, 2019 at 09:39:26AM -0500, Josh Poimboeuf wrote:
> Hm, I would actually argue the reverse. Warnings are generally bad and
> -Werror is useful for ensuring that we don't have any. For warnings
> that don't provide value, we just disable those individual warnings.
Sure, during deve
On Fri, Apr 05, 2019 at 07:39:09AM -0500, Josh Poimboeuf wrote:
> What version of libelf are you using? AFAIK, the non-elfutils version
> of libelf is buggy and has been unmaintained for 10 years.
I'm using libelf 0.8.13, which is indeed 10y old, abandoned and rather
suboptimal (elfutils OTOH is
Fixes: 056d28d135bc ("objtool: Query pkg-config for libelf location")
Signed-off-by: Luis Ressel
Cc: sta...@vger.kernel.org
---
tools/objtool/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 53f8be0f4a1f.
/crtsavres.o on ppc32 (and ppc64 if binutils is too
old).
A similar problem applies to "make clean" -- it is supposed to retain
all files which are neccessary for module building, but the global
"find . -name '*.o' -delete" it performs drops crtsavres.o.
--
Regards,
Lui
kernel sources, I doubt there are
many users of it, anyway.
Regards,
Luis Ressel
For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf.
net/unix/af_unix.c). This is a tad obscure, but libpcap uses it.
Signed-off-by: Luis Ressel
Acked-by: Stephen Smalley
---
security/selinux/hooks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/selinux/hooks.c b/security
For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf.
net/unix/af_unix.c). This is a tad obscure, but libpcap uses it.
---
security/selinux/hooks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 819fd6858b49..1a331fba4a3c 100644
---
mount_pseudo() is called, as
that function doesn't take a 'flags' argument.
Hence, the first part of the above permission check fails. (The second
part also fails under some cicumstances due to a SELinux quirk, and
therefore the initalization of my graphics driver doesn't succee
The autogenerated module signing key shouldn't be world-readable.
Signed-off-by: Luis Ressel
---
certs/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/certs/Makefile b/certs/Makefile
index 28ac694..7f1f082 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -49,6 +49,8 @@
I forgot to CC this mailing list.
Begin forwarded message:
Date: Sat, 2 Jan 2016 16:13:50 +0100
From: Luis Ressel
To: keyri...@vger.kernel.org
Cc: keyri...@linux-nfs.org, David Howells , David
Woodhouse Subject: [PATCH] Restrict read access
to private module signing key
The autogenerated
13 matches
Mail list logo
