On Wed, Apr 17, 2024 at 10:16:26AM +0200, Greg KH wrote:
> > at the scripts used by stable developers - and maybe at the ML server - to
> > catch different variations won't hurt, as it sounds likely that people will
> > end messing up with a big name like "do-not-apply-to-stable", typing
> >
Hi Thomas,
On Sun, Sep 10, 2023 at 09:29:01PM +0200, Thomas Weißschuh wrote:
> Newer versions of glibc annotate the poll() function with
> __attribute__(access) which triggers a compiler warning inside the
> testcase poll_fault.
> Avoid this by using a plain NULL which is enough for the testcase.
On Tue, Apr 20, 2021 at 07:56:18AM +0200, Greg Kroah-Hartman wrote:
> I would LOVE it if some "executives" would see the above presentations,
> because then they would maybe actually fund developers to fix bugs and
> maintain the kernel code, instead of only allowing them to add new
> features.
>
Hi Nick,
On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote:
> I don't think the introduction of Rust made Firefox _more_ insecure.
> https://wiki.mozilla.org/Oxidation#Within_Firefox
Browsers are human interfaces and do not fundamentally require low
level access to
On Sun, Apr 18, 2021 at 07:25:08PM +0200, Fawad Lateef wrote:
> I tried booting the userspace compiled with gcc-9.1 and kernel
> compiled with gcc-5.5. But seems like the kernel 3.4.111 is not
> compatible with user-space compiled with gcc-9.1.
> During boot getting error: "FATAL: kernel too old."
On Sat, Apr 17, 2021 at 10:26:30PM -0400, Matt Corallo wrote:
> Sure, there are better ways to handle the reassembly cache overflowing, but
> that is pretty unrelated to the fact that waiting 30 full seconds for a
> fragment to come in doesn't really make sense in today's networks (the 30
> second
On Sat, Apr 17, 2021 at 04:24:43PM +0200, Peter Zijlstra wrote:
> On Sat, Apr 17, 2021 at 01:46:23PM +0200, Willy Tarreau wrote:
> > For me the old trick of casting one side as long long still works:
> >
> > unsigned long long mul3264(unsigned int a, unsigned int b)
>
On Sat, Apr 17, 2021 at 02:53:10PM +0100, Wedson Almeida Filho wrote:
> > > Note that this is
> > > another area where Rust offers advantages: read-only guards (in C, if you
> > > take a
> > > read lock, nothing prevents you from making changes to fields you should
> > > only be
> > > allowed to
On Sat, Apr 17, 2021 at 01:17:21PM +0200, Peter Zijlstra wrote:
> Well, I think the rules actually make sense, at the point in the syntax
> tree where + happens, we have 'unsigned char' and 'int', so at that
> point we promote to 'int'. Subsequently 'int' gets shifted and bad
> things happen.
On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote:
> How about at least allow the existing queue to finish? Currently a tiny new
> fragment would potentially invalid all previous fragments by letting them
> timeout without allowing the fragments to come in to finish the assembly.
Because
On Sat, Apr 17, 2021 at 06:44:40AM +0200, Eric Dumazet wrote:
> On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
> >
> > [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
>
> I think this has been discussed already. There is no strategy that
> makes IP reassembly units immune to DDOS
On Sat, Apr 17, 2021 at 01:46:35AM +0200, Miguel Ojeda wrote:
> On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote:
> >
> > But my point remains that the point of extreme care is at the interface
> > with the rest of the kernel because there is a change of semantics
&g
On Fri, Apr 16, 2021 at 11:39:00PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 10:58 PM Willy Tarreau wrote:
> >
> > No, two:
> > - ok in %rax (seems like it's "!ok" technically speaking since it
> > returns 1 on !ok and 0 on ok
On Fri, Apr 16, 2021 at 03:34:50PM -0500, Connor Kuehl wrote:
> On 4/16/21 3:22 PM, Willy Tarreau wrote:
> > So it simply does the equivalent of:
> >
> > #define EINVAL -1234
> >
> > struct result {
> > int status;
> > int error;
> &
On Fri, Apr 16, 2021 at 08:57:07PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 8:10 PM Al Viro wrote:
> >
> > How well would ? operator fit that pattern? _If_ it's just a syntax sugar
> > along the lines of "if argument matches Err(_), return Err(_)", the types
> > shouldn't be an
Hi Miguel,
On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
> And by having the compiler enforce this safe-unsafe split, you can
> review safe code without having to constantly worry about UB; and be
> extra alert when dealing with `unsafe` blocks.
I do appreciate this safe/unsafe
On Fri, Apr 16, 2021 at 04:33:51PM +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 04:19:07PM +0200, Peter Zijlstra wrote:
> > Does this also not prohibit constructs where modification must be done
> > while holding two locks, but reading can be done while holding either
> > lock?
>
On Fri, Apr 16, 2021 at 10:16:05AM +0200, Michal Kubecek wrote:
> And I don't see how the two languages might coexist peacefully without
> rust toolchain being necessary for building any kernel useful in
> practice and anyone seriously involved in kernel development having to
> be proficient in
erity: ("Unused value")
> Signed-off-by: Colin Ian King
Indeed you're right.
Acked-by: Willy Tarreau
Willy
On Thu, Apr 15, 2021 at 06:43:43AM +0200, Borislav Petkov wrote:
> On Wed, Apr 14, 2021 at 05:57:22PM -0400, Len Brown wrote:
> > I'm pretty sure that the "it isn't my use case of interest, so it
> > doesn't matter" line of reasoning has long been established as -EINVAL
> > ;-)
>
> I have only a
On Wed, Apr 14, 2021 at 11:58:04AM +0200, Borislav Petkov wrote:
> On Tue, Apr 13, 2021 at 03:51:50PM -0400, Len Brown wrote:
> > AMX does the type of matrix multiplication that AI algorithms use. In
> > the unlikely event that you or one of the libraries you call are doing
> > the same, then you
On Mon, Apr 12, 2021 at 07:46:06PM -0400, Len Brown wrote:
> On Mon, Apr 12, 2021 at 11:21 AM Andy Lutomirski wrote:
>
> > AMX: Multiplying a 4x4 matrix probably looks *great* in a
> > microbenchmark. Do it once and you permanently allocate 8kB (is that
> > even a constant? can it grow in
On Mon, Mar 29, 2021 at 11:51:38AM +0200, Gustavo Pimentel wrote:
> Signed-off-by: Gustavo Pimentel
Please make an effort, this is in no way an acceptable commit description
for a patch. The subject is already extremely vague "FIX driver" with no
context at all, and there is no description of
On Sun, Mar 28, 2021 at 11:14:05PM +0300, Andy Shevchenko wrote:
> On Sunday, March 28, 2021, Willy Tarreau wrote:
>
> > Hi Thomas,
> >
> > On Sun, Mar 28, 2021 at 03:07:24AM +0200, Thomas Gleixner wrote:
> > > On Sun, Mar 28 2021 at 00:25, Willy Tarreau wrote:
&
On Sun, Mar 28, 2021 at 03:30:29PM +0200, Willy Tarreau wrote:
> On Sun, Mar 28, 2021 at 02:37:55PM +0200, Mateusz Jonczyk wrote:
> > W dniu 28.03.2021 o 00:25, Willy Tarreau pisze:
> > > FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
> > >
On Sun, Mar 28, 2021 at 02:37:55PM +0200, Mateusz Jonczyk wrote:
> W dniu 28.03.2021 o 00:25, Willy Tarreau pisze:
> > FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
> > 32-bit. I had already tried in the past but wanted to give it a try
> > again in
Hi Thomas,
On Sun, Mar 28, 2021 at 03:07:24AM +0200, Thomas Gleixner wrote:
> On Sun, Mar 28 2021 at 00:25, Willy Tarreau wrote:
> > On Sat, Mar 27, 2021 at 10:13:22PM +0100, Mateusz Jonczyk wrote:
> > FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
> >
Hi,
On Sat, Mar 27, 2021 at 10:13:22PM +0100, Mateusz Jonczyk wrote:
> W dniu 27.03.2021 o 21:32, Mateusz Jonczyk pisze:
> > Hello,
> >
> > There are some netbooks with Intel Atom processors that have 64-bit
> > support disabled by BIOS. Theoretically, the processor supports 64-bit
> > operation,
On Mon, Mar 22, 2021 at 05:34:48PM +0100, Arnd Bergmann wrote:
> On Mon, Mar 22, 2021 at 5:26 PM Willy Tarreau wrote:
> > On Mon, Mar 22, 2021 at 05:18:23PM +0100, Arnd Bergmann wrote:
> > > and a lot mostly harmless code like
> > >
> > > #ifdef
On Mon, Mar 22, 2021 at 05:18:23PM +0100, Arnd Bergmann wrote:
> I agree that this instance of the warning is particularly stupid, but the
> I'd like to leave the warning option there and eventually enable it by
> default because it tends to find other more interesting cases, and this
> one is
On Mon, Mar 22, 2021 at 03:47:35PM +, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 12:44:34PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > Building with 'make W=1' shows a harmless warning for pscsi:
> >
> > drivers/target/target_core_pscsi.c: In function
On Sat, Feb 27, 2021 at 02:58:18PM -0800, Randy Dunlap wrote:
> On 2/27/21 2:44 PM, Bhaskar Chowdhury wrote:
> >
> > s/occured/occurred/
> >
> > Signed-off-by: Bhaskar Chowdhury
>
> Acked-by: Randy Dunlap
Oops, seems like I missed this one, now queued, thanks to you both!
Willy
On Fri, Mar 19, 2021 at 12:04:47PM +0800, Sieng Piaw Liew wrote:
> Remove this trivial bit of inefficiency from the rx receive loop,
> results in increase of a few Mbps in iperf3. Tested on Intel Core2
> platform.
>
> Signed-off-by: Sieng Piaw Liew
> ---
>
On Fri, Mar 12, 2021 at 11:48:11AM +0900, Masahiro Yamada wrote:
> Hi.
>
> I think I am missing something, but
> is there any particular reason to
> use a different bit size between
> a syscall and its userspace wrapper?
>
>
>
> For example, for the unshare syscall,
>
> unshare(2) says the
Hi,
On Tue, Mar 09, 2021 at 08:55:10AM +, claudiu.bez...@microchip.com wrote:
> Hi Andreas,
>
> On 08.03.2021 21:30, Andreas Schwab wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > One of the changes to the macb driver
Hello,
On Fri, Mar 05, 2021 at 06:38:08PM +, Justin Mitchell wrote:
> Issue:
> Intermittent occurrence of failure to program new boards from CM.
No idea what "CM" is here, but that's not relevant here anyway.
> Primary partition mounted OK
> Loading file 'dtb/at91sam9g25ek.dtb' to addr
On Sat, Feb 20, 2021 at 05:05:14PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Feb 20, 2021 at 01:29:21PM +, Jari Ruusu wrote:
> > On Friday, February 19, 2021 5:23 PM, Jari Ruusu
> > wrote:
> > > My contribution here is trying to point you guys to right direction.
> >
> > I have been able
On Thu, Feb 18, 2021 at 12:16:50PM -0800, Scott Branden wrote:
> On 2021-02-18 10:36 a.m., Greg Kroah-Hartman wrote:
> > On Thu, Feb 18, 2021 at 07:20:50PM +0100, Willy Tarreau wrote:
> >> On Thu, Feb 18, 2021 at 06:53:56PM +0100, Greg Kroah-Hartman wrote:
> >>> On T
On Thu, Feb 18, 2021 at 06:53:56PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 18, 2021 at 09:21:13AM -0800, Florian Fainelli wrote:
> > As a company, we are most likely shooting ourselves in the foot by not
> > having a point of coordination with the Linux Foundation and key people
> > like
Hi Florian!
On Thu, Feb 18, 2021 at 09:42:00AM -0800, Florian Fainelli wrote:
> > Other difficulty with the LTS version is the frequency it is updated. We
> > would not
> > pickup the changes that frequently to test. A quarterly, bi-annually, or
> > when a critical fix
> > is identified would
On Thu, Feb 18, 2021 at 04:15:11PM +0200, Jari Ruusu wrote:
> Willy Tarreau wrote:
> > The only set of fixes that can be trusted are the "official" stable
> > kernels, because they are the only ones that are approved by the patches
> > authors themselves. Adding more
On Thu, Feb 18, 2021 at 08:43:48AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote:
> > Other difficulty with the LTS version is the frequency it is updated.
What a stange statement! So basically if fixes come in quickly so that
customers are not
Hi Paul,
On Fri, Feb 12, 2021 at 07:07:05AM -0800, Paul E. McKenney wrote:
> Thank you, Ingo! In the future, I will group nolibc with RCU. But there
> has to be something other than RCU that needs it. I will take a look. ;-)
All my kernels boot using a "preinit" that is built with nolibc and
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 79f220e56dc85739aa5462fa8a1abd4a44f002e0
Gitweb:
https://git.kernel.org/tip/79f220e56dc85739aa5462fa8a1abd4a44f002e0
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:24 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: c0c7c103756fee25aadfd5c36f7b86e318f9abb4
Gitweb:
https://git.kernel.org/tip/c0c7c103756fee25aadfd5c36f7b86e318f9abb4
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:25 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 70ca7aea50a27f03aa7e4cc6ee68940d13cbcd17
Gitweb:
https://git.kernel.org/tip/70ca7aea50a27f03aa7e4cc6ee68940d13cbcd17
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:28 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 35635d7fa689492ca9edb1d949f1805f074ecf1a
Gitweb:
https://git.kernel.org/tip/35635d7fa689492ca9edb1d949f1805f074ecf1a
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:30 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: f65d7117785cb8ab04f1af55909807c7eb9ed30b
Gitweb:
https://git.kernel.org/tip/f65d7117785cb8ab04f1af55909807c7eb9ed30b
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:29 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: c261145abd2461f921ac44ad70c28778dda710f4
Gitweb:
https://git.kernel.org/tip/c261145abd2461f921ac44ad70c28778dda710f4
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:23 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: be60ca41fbaa93bc8f92b24e34d8cc62af41300d
Gitweb:
https://git.kernel.org/tip/be60ca41fbaa93bc8f92b24e34d8cc62af41300d
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:26 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 5b1c827ca3b349801e2faff4185118cfa74f94c6
Gitweb:
https://git.kernel.org/tip/5b1c827ca3b349801e2faff4185118cfa74f94c6
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:27 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 3c6ce7a5363723a05bfe3ee03a8d4a9b66841ae4
Gitweb:
https://git.kernel.org/tip/3c6ce7a5363723a05bfe3ee03a8d4a9b66841ae4
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:20:31 +01:00
Committer
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 26cec81415b1b2a2e8e36ef0b24cf5f26467aa61
Gitweb:
https://git.kernel.org/tip/26cec81415b1b2a2e8e36ef0b24cf5f26467aa61
Author:Willy Tarreau
AuthorDate:Thu, 21 Jan 2021 08:48:08 +01:00
Committer
Hello,
On Sun, Feb 07, 2021 at 10:46:04AM +0100, Marcin Raszka wrote:
> ---
> drivers/gpu/drm/radeon/radeon_benchmark.c | 5 ++--
> drivers/gpu/drm/radeon/radeon_connectors.c | 30 ++
> drivers/gpu/drm/radeon/radeon_drv.c| 5
>
On Sat, Feb 06, 2021 at 02:19:57PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> > On Sat, Feb 06, 2021 at 02:00:27PM +0100, Greg Kroah-Hartman wrote:
> > > I think Sasha's patch here:
> > > https://lore.kernel.org
On Sat, Feb 06, 2021 at 02:11:13PM +0100, Willy Tarreau wrote:
> Something like this looks more robust to me, it will use SUBLEVEL for
> values 0 to 255 and 255 for any larger value:
>
> - expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
> + expr $(VERSIO
On Sat, Feb 06, 2021 at 02:00:27PM +0100, Greg Kroah-Hartman wrote:
> I think Sasha's patch here:
> https://lore.kernel.org/r/20210205174702.1904681-1-sas...@kernel.org
> is looking like the solution.
It might cause trouble to those forcing SUBLEVEL to a given version such
as .0 to avoid
On Tue, Feb 02, 2021 at 10:20:48PM +0100, Borislav Petkov wrote:
> It would be good to start forward-porting and integrating some of the
> fixes and even extend tcc to handle some of the gnuisms we're using in
> the kernel so that we can build the kernel with it too.
I agree. And the team is
On Tue, Feb 02, 2021 at 09:19:20PM +0100, Borislav Petkov wrote:
> On Tue, Feb 02, 2021 at 11:11:32AM -0800, Amy Parker wrote:
> > On Tue, Feb 2, 2021 at 8:26 AM Amy Parker wrote:
> > > > It compiles extremely fast, implements some subsets of gcc (a few
> > > > attributes for example), but is far
Hi Amy,
On Mon, Feb 01, 2021 at 03:31:49PM -0800, Amy Parker wrote:
> Hello! My name's Amy. I'm really impressed by the work done to make
> Clang (and the LLVM toolchain overall) able to compile the kernel.
> Figured I might as well donate my monkey hours to helping make it run
> on other
Hi Greg,
On Tue, Jan 26, 2021 at 07:51:18PM +0100, Greg Kroah-Hartman wrote:
> > > Ok, seriously, this happens every year, and every year we go through the
> > > same thing, it's not like this is somehow new, right?
> > No, but why do we need to keep playing the same game every year now.
>
>
On Thu, Jan 21, 2021 at 11:54:32AM -0800, Paul E. McKenney wrote:
> > > It would be great if this could be applied soon so that it's possible to
> > > use the rcutorture scripts without applying local hacks.
> >
> > Makes sense. I was wondering, should we mark them for stable ? I don't
> > know
On Thu, Jan 21, 2021 at 11:11:17AM +, Mark Rutland wrote:
> So FWIW:
>
> Tested-by: Mark Rutland [arm64]
Perfect, thanks! Paul, may I let you copy-paste the tested-by yourself ?
If you prefer I'm fine with resending a series to you, I just don't want
to needlessly spam you :-)
> It would
On Thu, Jan 21, 2021 at 11:05:48AM +, Valentin Schneider wrote:
> This lets me run the following invocation without a hitch:
>
> tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 10
> --configs "4*SRCU-P" --trust-make
>
> where before I would get some errors building the
I placed -lgcc poorly in the build options, resulting in possible build
failures that are typically encountered on ARM when uidiv is required;
-lgcc must be placed after the source files.
Signed-off-by: Willy Tarreau
---
Sorry for this last one, I figured after my last documentation fix
00b1b0d9b2a4]
Reported-by: Mark Rutland
Link: https://lore.kernel.org/lkml/20210119153147.GA5083@paulmck-ThinkPad-P72
Cc: "Paul E. McKenney"
Cc: valentin.schnei...@arm.com
Signed-off-by: Willy Tarreau
---
tools/include/nolibc/nolibc.h | 8
1 file changed, 8 deletions(-)
diff --g
getpgrp() is not implemented on arm64, getpgid(0) must be used
instead.
[This is nolibc's upstream commit 2379f25073f9]
Signed-off-by: Willy Tarreau
---
tools/include/nolibc/nolibc.h | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/tools/include/nolibc
/
Signed-off-by: Willy Tarreau
---
tools/include/nolibc/nolibc.h | 52 ++-
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc/nolibc.h
index 475d956ed1d6..618acad6c932 100644
--- a/tools/include/nolibc
]
Signed-off-by: Willy Tarreau
---
tools/include/nolibc/nolibc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc/nolibc.h
index 618acad6c932..8b7a9830dd22 100644
--- a/tools/include/nolibc/nolibc.h
+++ b/tools/include/nolibc
Some architectures like arm64 do not implement poll() and have to
use ppoll() instead.
[This is nolibc's upstream commit 800f75c13ede]
Signed-off-by: Willy Tarreau
---
tools/include/nolibc/nolibc.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/include/nolibc/nolibc.h b
Some archs such as arm64 do not have fork() and have to use clone()
instead so let's make fork() always use clone() when available. This
requires to include signal.h to get the definition of SIGCHLD.
[This is nolibc's upstream commit d2dc42fd6149]
Signed-off-by: Willy Tarreau
---
tools/include
A recent boot failure on 5.4-rc3 on arm64 revealed that sys_dup2()
is not available and that only sys_dup3() is implemented, thus let's
detect this and fall back to sys_dup3() when available.
[This is nolibc's upstream commit fd5272ec2c66]
Signed-off-by: Willy Tarreau
---
tools/include/nolibc
dup() was mistakenly forgotten while sys_dup() was defined.
[This is nolibc's upstream commit 47cc42a79c92]
Signed-off-by: Willy Tarreau
---
tools/include/nolibc/nolibc.h | 12
1 file changed, 12 insertions(+)
diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc
uest, as I can do that as well.
Thanks!
Willy
Willy Tarreau (9):
tools/nolibc: the definition dup() was missing
tools/nolibc: make dup2() rely on dup3() when available
tools/nolibc: make getpgrp() fall back to getpgid(0)
tools/nolibc: implement fork() based on clone()
tools/nolibc: imple
These ones conflict with linux/time.h when building, so better take
them from there directly.
[This is nolibc's upstream commit dc45f5426b0c]
Signed-off-by: Willy Tarreau
---
tools/include/nolibc/nolibc.h | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git
On Wed, Jan 20, 2021 at 07:38:38PM -0800, Linus Torvalds wrote:
> On Wed, Jan 20, 2021 at 5:45 PM Al Viro wrote:
> >
> > splice() triggers an error for seekable destination with O_APPEND and
> > with NULL off_out.
>
> Ok, that's just broken.
>
> > Same for splice() to socket with
> >
On Wed, Jan 20, 2021 at 04:02:23PM +0100, Willy Tarreau wrote:
> > ... and getting rid of the ARCH_WANT_* definitions (which are never
> > legitimate for userspace to set). That way, there's no risk that we
> > accidentally use a bogus syscall number in future. Where the kernel
On Wed, Jan 20, 2021 at 02:54:47PM +, Mark Rutland wrote:
> On Wed, Jan 20, 2021 at 03:25:00PM +0100, Willy Tarreau wrote:
> > On Wed, Jan 20, 2021 at 01:45:11PM +, Mark Rutland wrote:
> > > > Ah that's very interesting indeed because actually these ones should
>
Hi Mark,
On Wed, Jan 20, 2021 at 12:07:25PM +, Mark Rutland wrote:
> On Tue, Jan 19, 2021 at 06:43:58PM +0100, Willy Tarreau wrote:
> > On Tue, Jan 19, 2021 at 06:16:37PM +0100, Willy Tarreau wrote:
> > Given that you used a native compiler we can't suspect an issue with a
On Wed, Jan 20, 2021 at 01:45:11PM +, Mark Rutland wrote:
> > Ah that's very interesting indeed because actually these ones should
> > only be used when __NR_dup3 or __NR_clone are not defined. Thus I wanted
> > to check the definitions that were reported in your error output but
> > actually
On Tue, Jan 19, 2021 at 06:16:37PM +0100, Willy Tarreau wrote:
> > | ${CROSS_COMPILE}gcc -fno-asynchronous-unwind-tables -fno-ident \
> > | -nostdlib -include ../../../../include/nolibc/nolibc.h \
> > | -lgcc -s -static -Os -o init init.c
>
> OK I'll retry
Hi Mark,
On Tue, Jan 19, 2021 at 05:02:38PM +, Mark Rutland wrote:
> > I can't spot from the report above the original C file that was attempted
> > to be built, it makes me think we tried to compile directly the .h file.
>
> That was the inline snippet in
>
Hi Paul,
On Tue, Jan 19, 2021 at 07:31:47AM -0800, Paul E. McKenney wrote:
> Hello, Willy,
>
> Some people are having trouble running rcutorture on ARMv8. They
> get things like this from the nolibc build of initrd:
>
> https://paste.debian.net/1181762/
>
> The nolibc.h file says this:
>
>
On Sat, Jan 09, 2021 at 10:52:53PM +0100, Arnd Bergmann wrote:
(... i486 ...)
> As with the other older platforms, the main question to ask is:
> Are there users that are better off running a future LTS kernel on this
> hardware than the v5.10.y version or something older?
I think this is the
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
> indications that 486 have no users either on recent kernels.
> There is still the Vortex86 family of SoCs, and the oldest of those were
> 486SX-class, but all the
Hi,
On Tue, Dec 15, 2020 at 11:05:28PM +0800, kernel test robot wrote:
> Hi Willy,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 148842c98a24e508aecb929718818fbf4c2a6ff3
> commit:
On Thu, Dec 03, 2020 at 10:46:25AM -0800, Yury Norov wrote:
> Yun, could you please stop top-posting and excessive trimming in the thread?
And re-configure the mail agent to make the "Subject" field appear and
fill it.
Willy
On Wed, Nov 11, 2020 at 03:36:04PM +0100, Christian Hesse wrote:
> Greg Kroah-Hartman on Tue, 2020/11/10 21:56:
> > I'm announcing the release of the 5.9.8 kernel.
>
> This is not yet linked on kernel.org - same goes for lts version 5.4.77.
> I guess this is not by intention, no?
Strange, both
h replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Fixes: f227e3ec3b5c ("random
h replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Fixes: f227e3ec3b5c ("random
h replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Fixes: f227e3ec3b5c ("random
h replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Fixes: f227e3ec3b5c ("random
h replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Fixes: f227e3ec3b5c ("random
h replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Fixes: f227e3ec3b5c ("random
On Mon, Nov 09, 2020 at 08:54:13AM +0200, Amit Klein wrote:
> Unfortunately, I'm just a security researcher, not a kernel developer...
>
> Does that mean you don't plan to back-port the patch?
I could possibly have a look, but quite frankly I'm not convinced that we
need to backport this at all.
On Thu, Nov 05, 2020 at 10:21:27AM +0100, Linus Walleij wrote:
> If your SoC is only used by OpenWrt (like ixp4xx) then it is fine
> to just use bool because that distribution is always built with an
> image for a specific hardware, whereas distributions are generic.
Speaking for myself (since I
Hi Greg,
On Tue, Oct 27, 2020 at 02:54:49PM +0100, Greg Kroah-Hartman wrote:
> From: George Spelvin
>
> [ Upstream commit c51f8f88d705e06bd696d7510aff22b33eb8e638 ]
>
> Non-cryptographic PRNGs may have great statistical properties, but
> are usually trivially predictable to someone who knows
: Eric Dumazet
Cc: "Jason A. Donenfeld"
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Signed-off-by: Willy Tarreau
---
lib/random32.c | 56 +++
fix.
Whether to reinstate a weaker PRNG for uses which can tolerate it
is an open question.
Commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity") was an earlier attempt at a solution. This patch replaces
it.
Reported-by: Amit Klein
Cc: Willy Tarreau
Cc: ty...@mit.edu
Cc: Florian Westphal
Cc: Marc Plumb
Tested-by: Sedat Dilek
Signed-off-by: Willy Tarreau
---
include/linux/prandom.h | 19 +++
kernel/time/timer.c | 2 ++
lib/random32.c | 5 +
net/core/dev.c | 4
4 files changed, 30 insertions(+)
1 - 100 of 7649 matches
Mail list logo
