ve include/uapi/ at all, so add that
subdir and put one Kbuild file into it (since git does not track
empty subdirs).
Signed-off-by: Randy Dunlap
Cc: Masahiro Yamada
Cc: Michal Marek
Cc: linux-kbu...@vger.kernel.org
Cc: Jeff Dike
Cc: Richard Weinberger
Cc: Anton Ivanov
Cc: linux...@lists.inf
goal is to collect the initial
feedback, to discuss the interfaces, and maybe to get some advice on
implementation..
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Anton Ivanov
Cc: Christian Brauner
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Cc: Ingo Molnar
Cc: Jeff Dike
Cc: Mike Rapopo
Cc: Alexei Starovoitov
Cc: kbuild-...@lists.01.org
Cc: Jeff Dike
Cc: Richard Weinberger
Cc: Anton Ivanov
Cc: linux...@lists.infradead.org
Cc: Johannes Berg
Cc: Johannes Berg
---
My UML on i386 build environment is br0ken so this is not tested other
than to see that the .o files are built
behavior - the bug shows up on 4.x up to at least 5.4. I do not see it
on 5.10.
Brgds,
Timo
On 21.02.2021 16:53, Anton Ivanov wrote:
Client side. This seems to be an entirely client side issue.
A variety of kernels on the clients starting from 4.9 and up to 5.10
using 4.19 servers. I have
On 21/02/2021 14:37, Bruce Fields wrote:
On Sun, Feb 21, 2021 at 11:38:51AM +, Anton Ivanov wrote:
On 21/02/2021 09:13, Salvatore Bonaccorso wrote:
On Sat, Feb 20, 2021 at 08:16:26PM +, Chuck Lever wrote:
Confirming you are varying client-side kernels. Should the Linux
NFS client
On 21/02/2021 09:13, Salvatore Bonaccorso wrote:
Hi,
On Sat, Feb 20, 2021 at 08:16:26PM +, Chuck Lever wrote:
On Feb 20, 2021, at 3:13 PM, Anton Ivanov
wrote:
On 20/02/2021 20:04, Salvatore Bonaccorso wrote:
Hi,
On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote:
Hi list
On 20/02/2021 20:04, Salvatore Bonaccorso wrote:
Hi,
On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote:
Hi list,
NFS caching appears broken in 4.19.37.
The more cores/threads the easier to reproduce. Tested with identical
results on Ryzen 1600 and 1600X.
1. Mount an openwrt build
nto /dev/random.
+ own drivers. It registers itself as a rng-core driver thus providing
+ a device which is usually called /dev/hwrng. This hardware random
+ number generator does feed into the kernel's random number generator
+ entropy pool.
+
+ If unsure, say Y.
Acked-by: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
nit(>tx_poll, vector_tx_poll, (unsigned long)vp);
+ tasklet_setup(>tx_poll, vector_tx_poll);
INIT_WORK(>reset_tx, vector_reset_tx);
timer_setup(>tl, vector_timer_expire, 0);
Acked-By: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Compa
Thanks.
Acked-By: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
;pdev.dev))
goto flash_fail;
- vp->bpf->filter = kmemdup(fw->data, fw->size, GFP_KERNEL);
+ vp->bpf->filter = kmemdup(fw->data, fw->size, GFP_ATOMIC);
if (!vp->bpf->filter)
goto free_buffer;
Acked-By: Anton Ivanov
--
On 14/07/2020 11:23, Ignat Korchagin wrote:
On Tue, Jul 14, 2020 at 9:40 AM Anton Ivanov
wrote:
On 04/07/2020 09:52, Ignat Korchagin wrote:
musl toolchain and headers are a bit more strict. These fixes enable building
UML with musl as well as seem not to break on glibc.
Signed-off
On 04/07/2020 09:52, Ignat Korchagin wrote:
musl toolchain and headers are a bit more strict. These fixes enable building
UML with musl as well as seem not to break on glibc.
Signed-off-by: Ignat Korchagin
---
arch/um/drivers/daemon_user.c | 1 +
arch/um/drivers/pcap_user.c | 12
On 07/07/2020 21:32, Alexander A. Klimov wrote:
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
en_file(filename, of_read(OPENFLAGS()), 0);
if (ffd < 0) {
printk(KERN_ERR "Error %d opening bpf file", -errno);
Acked-By: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
Hi list,
NFS caching appears broken in 4.19.37.
The more cores/threads the easier to reproduce. Tested with identical
results on Ryzen 1600 and 1600X.
1. Mount an openwrt build tree over NFS v4
2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in
a loop
3. Result after
On 11/05/2019 13:39, Steven Rostedt wrote:
From: "Steven Rostedt (VMware)"
User Mode Linux does not have access to the ip or sp fields of the
pt_regs, and accessing them causes UML to fail to build. Hide the
int3_emulate_jmp() and int3_emulate_call() instructions from UML, as it
doesn't
On 10/05/2019 17:20, Bartosz Golaszewski wrote:
pt., 10 maj 2019 o 11:16 Bartosz Golaszewski napisał(a):
śr., 8 maj 2019 o 09:13 Richard Weinberger napisał(a):
- Ursprüngliche Mail -
Can you please check?
This patch is already queued in -next. So we need to decide whether to
-by: Bartosz Golaszewski
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
Just noticed that this triggers the following errors while bootup:
Trying to reregister IRQ 11 FD 8 TYPE 0 ID (null)
write_sigio_irq : um_request_irq failed, err = -16
Trying to reregister IRQ 11 FD 8 TYPE 0 ID
CONFIG_3_LEVEL_PGTABLES
pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long address)
{
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
*error_out = "Didn't parse major number";
- goto out1;
+ return err;
}
mutex_lock(_lock);
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
--
Anton R. Ivanov
https://www.kot-begemot.co.uk/
On 03/04/2019 09:39, Bartosz Golaszewski wrote:
śr., 3 kwi 2019 o 10:39 Bartosz Golaszewski napisał(a):
From: Bartosz Golaszewski
I've previously sent these patches separately. I still don't see them
in next and I don't know what the policy is for picking up uml patches
but I thought I'd
q_type, handle_edge_irq);
/* Initialize EPOLL Loop */
os_setup_epoll();
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
On 14/03/2019 13:33, Bartosz Golaszewski wrote:
śr., 13 mar 2019 o 10:45 Anton Ivanov
napisał(a):
On 12/03/2019 13:30, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
While the affected code is run in user-mode, the build still warns
about it. Convert all uses of VLA to dynamic
,
+ pte_t *pteptr, pte_t pteval)
+{
+ set_pte(pteptr, pteval);
+}
#define __HAVE_ARCH_PTE_SAME
static inline int pte_same(pte_t pte_a, pte_t pte_b)
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England
On 12/03/2019 13:30, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
While the affected code is run in user-mode, the build still warns
about it. Convert all uses of VLA to dynamic allocations.
Signed-off-by: Bartosz Golaszewski
---
arch/um/os-Linux/umid.c | 36
)(unsigned long addr, int len, void *arg), void *arg)
{
- jmp_buf buf;
struct page *page;
pte_t *pte;
int n;
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https
-#include
#include "vector_user.h"
#define ID_GRE 0
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
--
Anton R. Ivanov
Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/
On 18/01/2019 19:42, Richard Weinberger wrote:
Am Freitag, 18. Januar 2019, 20:23:07 CET schrieb Anton Ivanov:
On 18/01/2019 14:58, Sabyasachi Gupta wrote:
Remove sys/socket.h and sys/uio.h which are included more than once
Signed-off-by: Sabyasachi Gupta
---
arch/um/drivers
On 18/01/2019 14:58, Sabyasachi Gupta wrote:
Remove sys/socket.h and sys/uio.h which are included more than once
Signed-off-by: Sabyasachi Gupta
---
arch/um/drivers/vector_user.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/um/drivers/vector_user.c
3d8cdbdb4e66..41eefbcdc86f 100644
--- a/arch/um/drivers/vector_user.c
+++ b/arch/um/drivers/vector_user.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
Acked-by: Anton Ivanov
--
Anton R. Ivanov
Cambridge Greys Limited, England and Wales company
= kmalloc_array(max_size, sizeof(void *),
+ GFP_KERNEL);
if (result->skbuff_vector == NULL)
goto out_skb_fail;
Acked-by: Anton Ivanov
--
Anton R. Ivanov
Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/
On 12/11/18 2:41 PM, Steven Rostedt wrote:
On Tue, 11 Dec 2018 15:09:26 +0100
Petr Mladek wrote:
We have liburcu already, which is good. The main sticking points are:
- printk has started adding a lot of %pX enhancements which printf
obviously doesn't know about.
I wonder how big
On 30/11/2018 03:14, Luis Chamberlain wrote:
On Wed, Nov 28, 2018 at 11:36:18AM -0800, Brendan Higgins wrote:
+#define module_test(module) \
+ static int module_kunit_init##module(void) \
+ { \
+ return kunit_run_tests(); \
+ } \
+
On 30/11/2018 03:14, Luis Chamberlain wrote:
On Wed, Nov 28, 2018 at 11:36:18AM -0800, Brendan Higgins wrote:
+#define module_test(module) \
+ static int module_kunit_init##module(void) \
+ { \
+ return kunit_run_tests(); \
+ } \
+
On 03/08/18 07:39, YueHaibing wrote:
kfree(NULL) is safe,so this removes NULL check before freeing the mem
Signed-off-by: YueHaibing
---
arch/um/drivers/vector_kern.c | 15 +--
arch/um/drivers/vector_user.c | 6 ++
arch/um/kernel/irq.c | 3 +--
3 files changed,
On 03/08/18 07:39, YueHaibing wrote:
kfree(NULL) is safe,so this removes NULL check before freeing the mem
Signed-off-by: YueHaibing
---
arch/um/drivers/vector_kern.c | 15 +--
arch/um/drivers/vector_user.c | 6 ++
arch/um/kernel/irq.c | 3 +--
3 files changed,
uding some of mine).
The joys of having a broken list :(
Whoever posted it, if you are reading it, please re-post again so we can
have a look.
In the meantime we are as you said - x86 only.
A.
On 04/24/18 09:32, Richard Weinberger wrote:
On Fri, Apr 20, 2018 at 6:06 PM, Anton Ivanov
<ant
uding some of mine).
The joys of having a broken list :(
Whoever posted it, if you are reading it, please re-post again so we can
have a look.
In the meantime we are as you said - x86 only.
A.
On 04/24/18 09:32, Richard Weinberger wrote:
On Fri, Apr 20, 2018 at 6:06 PM, Anton Ivanov
wrote:
On 04/20/18 15:38, Eric W. Biederman wrote:
Today user mode linux only works on x86 and x86_64 and this allows
simplifications of relay_signal.
I believe someone recently fixed the ARM port. I have not had the time
to try the fixes though.
I have added the new list we are migrating to the
On 04/20/18 15:38, Eric W. Biederman wrote:
Today user mode linux only works on x86 and x86_64 and this allows
simplifications of relay_signal.
I believe someone recently fixed the ARM port. I have not had the time
to try the fixes though.
I have added the new list we are migrating to the
Thanks, well noted.
It still does not fix it completely though.
Re-reading the code it will leak a fd if the malloc for result fails.
That return result; there should be inside the conditional falling back
to cleanup if the alloc fails.
A.
On 03/11/18 15:16, SF Markus Elfring wrote:
Thanks, well noted.
It still does not fix it completely though.
Re-reading the code it will leak a fd if the malloc for result fails.
That return result; there should be inside the conditional falling back
to cleanup if the alloc fails.
A.
On 03/11/18 15:16, SF Markus Elfring wrote:
Hi Wei,
I just double-checked.
This issue has been fixed in a patch submitted by Dan Carpenter on 09th
Dec 2017 which I acknowledged on 11th Dec 2017 and which should be in
Richard's queue to be applied.
It should at some point show up in Linux-next.
Best Regards and once again, thanks for
Hi Wei,
I just double-checked.
This issue has been fixed in a patch submitted by Dan Carpenter on 09th
Dec 2017 which I acknowledged on 11th Dec 2017 and which should be in
Richard's queue to be applied.
It should at some point show up in Linux-next.
Best Regards and once again, thanks for
On 03/12/17 21:54, Richard Weinberger wrote:
> Christoph,
>
> Am Mittwoch, 29. November 2017, 22:46:51 CET schrieb Christoph Hellwig:
>> On Sun, Nov 26, 2017 at 02:10:53PM +0100, Richard Weinberger wrote:
>>> MAX_SG is 64, used for blk_queue_max_segments(). This comes from
>>> a0044bdf60c2 ("uml:
On 03/12/17 21:54, Richard Weinberger wrote:
> Christoph,
>
> Am Mittwoch, 29. November 2017, 22:46:51 CET schrieb Christoph Hellwig:
>> On Sun, Nov 26, 2017 at 02:10:53PM +0100, Richard Weinberger wrote:
>>> MAX_SG is 64, used for blk_queue_max_segments(). This comes from
>>> a0044bdf60c2 ("uml:
On 26/11/17 13:56, Richard Weinberger wrote:
> Anton,
>
> please don't crop the CC list.
Apologies, I wanted to keep the discussion UML side until we have come
up with something.
Will not do it again.
>
> Am Sonntag, 26. November 2017, 14:41:12 CET schrieb Anton Ivanov:
>&
On 26/11/17 13:56, Richard Weinberger wrote:
> Anton,
>
> please don't crop the CC list.
Apologies, I wanted to keep the discussion UML side until we have come
up with something.
Will not do it again.
>
> Am Sonntag, 26. November 2017, 14:41:12 CET schrieb Anton Ivanov:
>&
How about tackling some real problems and performance issues instead?
There are a few of those in the network, interrupt and memory
subsystems. Take your pick.
A.
On 19/01/17 17:13, SF Markus Elfring wrote:
please don't send drive-by patches.
Would you dare to take another look at the
How about tackling some real problems and performance issues instead?
There are a few of those in the network, interrupt and memory
subsystems. Take your pick.
A.
On 19/01/17 17:13, SF Markus Elfring wrote:
please don't send drive-by patches.
Would you dare to take another look at the
On 19/10/14 15:59, Thomas Meyer wrote:
> Am Dienstag, den 14.10.2014, 08:31 +0100 schrieb Anton Ivanov:
>> I see a very similar stall on writeout to ubd with my patches (easy) and
>> without (difficult - takes running an IO soak for a few days).
>>
>> It stalls (us
On 19/10/14 15:59, Thomas Meyer wrote:
Am Dienstag, den 14.10.2014, 08:31 +0100 schrieb Anton Ivanov:
I see a very similar stall on writeout to ubd with my patches (easy) and
without (difficult - takes running an IO soak for a few days).
It stalls (usually) when trying to flush the journal
53 matches
Mail list logo
