um: build and irq fixes

PATCH RESEND In review Bartosz Golaszewski 5 participants 16 messages Apr 11, 2019 – Jun 3, 2019 User-mode Linux (UML)

lore

Share & tools

lore

Bartosz Golaszewski

author

2019-04-11 09:49 UTC #0 lore raw

cover um: build and irq fixes

From: Bartosz Golaszewski <[email protected]>

Resending again - this time with tags collected.

===

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 resend them rebased together on top of v5.1-rc4.

Bartosz Golaszewski (4):
um: remove unused variable
um: remove uses of variable length arrays
um: define set_pte_at() as a static inline function, not a macro
um: irq: don't set the chip for all irqs

 arch/um/include/asm/pgtable.h |  7 ++++++-
 arch/um/kernel/irq.c          |  2 +-
 arch/um/kernel/skas/uaccess.c |  1 -
 arch/um/os-Linux/umid.c       | 36 ++++++++++++++++++++++++++---------
 4 files changed, 34 insertions(+), 12 deletions(-)

Signature · 1 line

2.21.0

Bartosz Golaszewski

author

2019-04-11 09:49 UTC #1 lore raw

PATCH RESEND 1/4 um: remove unused variable

From: Bartosz Golaszewski <[email protected]>

The buf variable is unused. Remove it.

Signed-off-by Bartosz Golaszewski <[email protected]>

Reviewed-by Anton Ivanov <[email protected]>

Acked-by Anton Ivanov <[email protected]>

---
 arch/um/kernel/skas/uaccess.c | 1 -
 1 file changed, 1 deletion(-)

arch/um/kernel/skas/uaccess.c +0 -1

index 7f06fdbc7ee1..bd3cb694322c 100644
@@ -59,7 +59,6 @@ static pte_t *maybe_map(unsigned long virt, int is_write)
 static int do_op_one_page(unsigned long addr, int len, int is_write,
 		 int (*op)(unsigned long addr, int len, void *arg), void *arg)
 {
-	jmp_buf buf;
 	struct page *page;
 	pte_t *pte;
 	int n;

Signature · 1 line

2.21.0

Bartosz Golaszewski

author

2019-04-11 09:49 UTC #2 lore raw

PATCH RESEND 2/4 um: remove uses of variable length arrays

In reply to Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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 <[email protected]>

---
 arch/um/os-Linux/umid.c | 36 +++++++++++++++++++++++++++---------
 1 file changed, 27 insertions(+), 9 deletions(-)

arch/um/os-Linux/umid.c +27 -9

index 998fbb445458..e261656fe9d7 100644
@@ -135,12 +135,18 @@ static int remove_files_and_dir(char *dir)
  */
 static inline int is_umdir_used(char *dir)
 {
-	char file[strlen(uml_dir) + UMID_LEN + sizeof("/pid\0")];
-	char pid[sizeof("nnnnn\0")], *end;
+	char pid[sizeof("nnnnn\0")], *end, *file;
 	int dead, fd, p, n, err;
+	size_t filelen;
 
-	n = snprintf(file, sizeof(file), "%s/pid", dir);
-	if (n >= sizeof(file)) {
+	err = asprintf(&file, "%s/pid", dir);
+	if (err < 0)
+		return 0;
+
+	filelen = strlen(file);
+
+	n = snprintf(file, filelen, "%s/pid", dir);
+	if (n >= filelen) {
 		printk(UM_KERN_ERR "is_umdir_used - pid filename too long\n");
 		err = -E2BIG;
 		goto out;

@@ -185,6 +191,7 @@ static inline int is_umdir_used(char *dir)
 out_close:
 	close(fd);
 out:
+	free(file);
 	return 0;
 }

@@ -210,18 +217,21 @@ static int umdir_take_if_dead(char *dir)
 
 static void __init create_pid_file(void)
 {
-	char file[strlen(uml_dir) + UMID_LEN + sizeof("/pid\0")];
-	char pid[sizeof("nnnnn\0")];
+	char pid[sizeof("nnnnn\0")], *file;
 	int fd, n;
 
-	if (umid_file_name("pid", file, sizeof(file)))
+	file = malloc(strlen(uml_dir) + UMID_LEN + sizeof("/pid\0"));
+	if (!file)
 		return;
 
+	if (umid_file_name("pid", file, sizeof(file)))
+		goto out;
+
 	fd = open(file, O_RDWR | O_CREAT | O_EXCL, 0644);
 	if (fd < 0) {
 		printk(UM_KERN_ERR "Open of machine pid file \"%s\" failed: "
 		       "%s\n", file, strerror(errno));
-		return;
+		goto out;
 	}
 
 	snprintf(pid, sizeof(pid), "%d\n", getpid());

@@ -231,6 +241,8 @@ static void __init create_pid_file(void)
 		       errno);
 
 	close(fd);
+out:
+	free(file);
 }
 
 int __init set_umid(char *name)

@@ -385,13 +397,19 @@ __uml_setup("uml_dir=", set_uml_dir,
 
 static void remove_umid_dir(void)
 {
-	char dir[strlen(uml_dir) + UMID_LEN + 1], err;
+	char *dir, err;
+
+	dir = malloc(strlen(uml_dir) + UMID_LEN + 1);
+	if (!dir)
+		return;
 
 	sprintf(dir, "%s%s", uml_dir, umid);
 	err = remove_files_and_dir(dir);
 	if (err)
 		os_warn("%s - remove_files_and_dir failed with err = %d\n",
 			__func__, err);
+
+	free(dir);
 }
 
 __uml_exitcall(remove_umid_dir);

Signature · 1 line

2.21.0

Bartosz Golaszewski

author

2019-04-11 09:49 UTC #3 lore raw

PATCH RESEND 3/4 um: define set_pte_at() as a static inline function, not a macro

In reply to Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

When defined as macro, the mm argument is unused and subsequently the variable passed as mm is considered unused by the compiler. This fixes a build warning.

Signed-off-by Bartosz Golaszewski <[email protected]>

Reviewed-by Geert Uytterhoeven <[email protected]>

Reviewed-by Anton Ivanov <[email protected]>

Acked-by Anton Ivanov <[email protected]>

---
 arch/um/include/asm/pgtable.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/um/include/asm/pgtable.h +6 -1

index 9c04562310b3..b377df76cc28 100644
@@ -263,7 +263,12 @@ static inline void set_pte(pte_t *pteptr, pte_t pteval)
 	*pteptr = pte_mknewpage(*pteptr);
 	if(pte_present(*pteptr)) *pteptr = pte_mknewprot(*pteptr);
 }
-#define set_pte_at(mm,addr,ptep,pteval) set_pte(ptep,pteval)
+
+static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
+			      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)

Signature · 1 line

2.21.0

Bartosz Golaszewski

author

2019-04-11 09:49 UTC #4 lore raw

PATCH RESEND 4/4 um: irq: don't set the chip for all irqs

In reply to Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

Setting a chip for an interrupt marks it as allocated. Since UM doesn't support dynamic interrupt numbers (yet), it means we cannot simply increase NR_IRQS and then use the free irqs between LAST_IRQ and NR_IRQS with gpio-mockup or iio testing drivers as irq_alloc_descs() will fail after not being able to neither find an unallocated range of interrupts nor expand the range.

Only call irq_set_chip_and_handler() for irqs until LAST_IRQ.

Signed-off-by Bartosz Golaszewski <[email protected]>

Reviewed-by Anton Ivanov <[email protected]>

Acked-by Anton Ivanov <[email protected]>

---
 arch/um/kernel/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/um/kernel/irq.c +1 -1

index f4874b7ec503..598d7b3d9355 100644
@@ -479,7 +479,7 @@ void __init init_IRQ(void)
 	irq_set_chip_and_handler(TIMER_IRQ, &SIGVTALRM_irq_type, handle_edge_irq);
 
 
-	for (i = 1; i < NR_IRQS; i++)
+	for (i = 1; i < LAST_IRQ; i++)
 		irq_set_chip_and_handler(i, &normal_irq_type, handle_edge_irq);
 	/* Initialize EPOLL Loop */
 	os_setup_epoll();

Signature · 1 line

2.21.0

Richard Weinberger

2019-05-07 21:26 UTC #5 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

Quoted 10 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>
Setting a chip for an interrupt marks it as allocated. Since UM doesn't support dynamic interrupt numbers (yet), it means we cannot simply increase NR_IRQS and then use the free irqs between LAST_IRQ and NR_IRQS with gpio-mockup or iio testing drivers as irq_alloc_descs() will fail after not being able to neither find an unallocated range of interrupts nor expand the range.

Quoted 5 lines

Only call irq_set_chip_and_handler() for irqs until LAST_IRQ.
Signed-off-by Bartosz Golaszewski <[email protected]>
Reviewed-by Anton Ivanov <[email protected]>
Acked-by Anton Ivanov <[email protected]>

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 (null)
write_sigio_irq : um_request_irq failed, err = -16
VFS: Mounted root (hostfs filesystem) readonly on

Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.

Anton Ivanov

maintainer

2019-05-08 07:09 UTC #6 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

Quoted 24 lines · Richard Weinberger

Quoted 10 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
Setting a chip for an interrupt marks it as allocated. Since UM doesn't support dynamic interrupt numbers (yet), it means we cannot simply increase NR_IRQS and then use the free irqs between LAST_IRQ and NR_IRQS with gpio-mockup or iio testing drivers as irq_alloc_descs() will fail after not being able to neither find an unallocated range of interrupts nor expand the range.
Quoted 5 lines
Only call irq_set_chip_and_handler() for irqs until LAST_IRQ.
Signed-off-by Bartosz Golaszewski <[email protected]>
Reviewed-by Anton Ivanov <[email protected]>
Acked-by Anton Ivanov <[email protected]>
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 (null)
write_sigio_irq : um_request_irq failed, err = -16
VFS: Mounted root (hostfs filesystem) readonly on

Quoted 4 lines

Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.

I am looking at it. It passed tests in my case (I did the usual round).

Signature · 3 lines

Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Richard Weinberger

maintainer

2019-05-08 07:13 UTC #7 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

----- Ursprüngliche Mail -----

Quoted 5 lines

Quoted 4 lines
Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.
I am looking at it. It passed tests in my case (I did the usual round).

It works here too. That's why I never noticed.
Yesterday I noticed just because I looked for something else in the kernel logs.

Thanks,
//richard

Bartosz Golaszewski

author

2019-05-10 09:16 UTC #8 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> napisał(a):

Quoted 6 lines

----- Ursprüngliche Mail -----
Quoted 4 lines
Quoted 4 lines
Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.

Quoted 7 lines

Quoted 1 line
I am looking at it. It passed tests in my case (I did the usual round).
It works here too. That's why I never noticed.
Yesterday I noticed just because I looked for something else in the kernel logs.
Thanks,
//richard

Hi,

sorry for the late reply - I just came back from vacation.

I see it here too, I'll check if I can find the culprit and fix it today.

Bart

Bartosz Golaszewski

author

2019-05-10 16:20 UTC #9 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):

Quoted 16 lines

śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> napisał(a):
Quoted 6 lines
----- Ursprüngliche Mail -----
Quoted 4 lines
Quoted 4 lines
Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.
Quoted 7 lines
Quoted 1 line
I am looking at it. It passed tests in my case (I did the usual round).
It works here too. That's why I never noticed.
Yesterday I noticed just because I looked for something else in the kernel logs.
Thanks,
//richard

Quoted 7 lines

Hi,
sorry for the late reply - I just came back from vacation.
I see it here too, I'll check if I can find the culprit and fix it today.
Bart

Hi Richard, Anton,

I'm not sure yet what this is caused by. It doesn't seem to break anything for me but since it's a new error message I guess it's best to revert this patch (others are good) and revisit it for v5.3.

Bart

Anton Ivanov

maintainer

2019-05-10 16:22 UTC #10 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

Quoted 17 lines · Bartosz Golaszewski

pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):
Quoted 16 lines
śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> napisał(a):
Quoted 11 lines
----- Ursprüngliche Mail -----
Quoted 5 lines
Quoted 4 lines
Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.
I am looking at it. It passed tests in my case (I did the usual round).
It works here too. That's why I never noticed.
Yesterday I noticed just because I looked for something else in the kernel logs.
Thanks,
//richard
Hi,
sorry for the late reply - I just came back from vacation.

Quoted 8 lines

Quoted 3 lines
I see it here too, I'll check if I can find the culprit and fix it today.
Bart
Hi Richard, Anton,
I'm not sure yet what this is caused by. It doesn't seem to break anything for me but since it's a new error message I guess it's best to revert this patch (others are good) and revisit it for v5.3.

Can you send me your command line and .config so I can try to reproduce it.

Brgds,

Quoted 3 lines

Bart

Signature · 3 lines

Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Bartosz Golaszewski

author

2019-05-11 12:48 UTC #11 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

pt., 10 maj 2019 o 18:22 Anton Ivanov
<[email protected]> napisał(a):

Quoted 22 lines · Bartosz Golaszewski

Quoted 19 lines
pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):
Quoted 18 lines
śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> napisał(a):
Quoted 11 lines
----- Ursprüngliche Mail -----
Quoted 5 lines
Quoted 4 lines
Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.
I am looking at it. It passed tests in my case (I did the usual round).
It works here too. That's why I never noticed.
Yesterday I noticed just because I looked for something else in the kernel logs.
Thanks,
//richard
Hi,
sorry for the late reply - I just came back from vacation.
I see it here too, I'll check if I can find the culprit and fix it today.

Quoted 9 lines

Quoted 6 lines
Quoted 1 line
Bart
Hi Richard, Anton,
I'm not sure yet what this is caused by. It doesn't seem to break anything for me but since it's a new error message I guess it's best to revert this patch (others are good) and revisit it for v5.3.
Can you send me your command line and .config so I can try to reproduce it.

Sure,

the command line is:

./linux rootfstype=hostfs rootflags=<path to a regular buildroot rootfs> rw mem=48M

The config is the regular x86_64_defconfig from arch/um.

Bart

Dana Johnson

2019-05-31 10:30 UTC #12 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

Quoted 36 lines · Bartosz Golaszewski

pt., 10 maj 2019 o 18:22 Anton Ivanov
<[email protected]> napisał(a):
Quoted 22 lines · Bartosz Golaszewski
Quoted 19 lines
pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):
Quoted 18 lines
śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> napisał(a):
Quoted 11 lines
----- Ursprüngliche Mail -----
Quoted 5 lines
Quoted 4 lines
Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.
I am looking at it. It passed tests in my case (I did the usual round).
It works here too. That's why I never noticed.
Yesterday I noticed just because I looked for something else in the kernel logs.
Thanks,
//richard
Hi,
sorry for the late reply - I just came back from vacation.
I see it here too, I'll check if I can find the culprit and fix it today.
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Bart
Hi Richard, Anton,
I'm not sure yet what this is caused by. It doesn't seem to break anything for me but since it's a new error message I guess it's best to revert this patch (others are good) and revisit it for v5.3.
Can you send me your command line and .config so I can try to reproduce it.
Sure,

Quoted 9 lines

the command line is:
./linux rootfstype=hostfs rootflags=<path to a regular buildroot rootfs> rw mem=48M
The config is the regular x86_64_defconfig from arch/um.
Bart

I hit this compiling 5.2.0-rc2-00024-gbec7550cca10

I can trigger:

Trying to reregister IRQ 11 FD 9 TYPE 0 ID (____ptrval____) write_sigio_irq : um_request_irq failed, err = -16

during boot when:

# CONFIG_UML_NET_VECTOR is not set

Looking at the code there seems to be a one off error
in the LAST_IRQ calculation when CONFIG_UML_NET_VECTOR is enabled. In that case the patch should be reverted and the following applied:

arch/um/include/asm/irq.h +1 -1

index 49ed3e35b35a..ce7a78c3bcf2 100644
@@ -23,7 +23,7 @@
 #define VECTOR_BASE_IRQ                15
 #define VECTOR_IRQ_SPACE       8
 
-#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ)
+#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ - 1)
 
 #else

Dana

_______________________________________________
linux-um mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-um

Anton Ivanov

maintainer

2019-06-03 07:31 UTC #13 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

Quoted 68 lines · Dana Johnson

Quoted 36 lines · Bartosz Golaszewski
pt., 10 maj 2019 o 18:22 Anton Ivanov
<[email protected]> napisał(a):
Quoted 22 lines · Bartosz Golaszewski
Quoted 19 lines
pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):
Quoted 18 lines
śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> napisał(a):
Quoted 11 lines
----- Ursprüngliche Mail -----
Quoted 5 lines
Quoted 4 lines
Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.
I am looking at it. It passed tests in my case (I did the usual round).
It works here too. That's why I never noticed.
Yesterday I noticed just because I looked for something else in the kernel logs.
Thanks,
//richard
Hi,
sorry for the late reply - I just came back from vacation.
I see it here too, I'll check if I can find the culprit and fix it today.
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Bart
Hi Richard, Anton,
I'm not sure yet what this is caused by. It doesn't seem to break anything for me but since it's a new error message I guess it's best to revert this patch (others are good) and revisit it for v5.3.
Can you send me your command line and .config so I can try to reproduce it.
Sure,
Quoted 9 lines
the command line is:
./linux rootfstype=hostfs rootflags=<path to a regular buildroot rootfs> rw mem=48M
The config is the regular x86_64_defconfig from arch/um.
Bart
I hit this compiling 5.2.0-rc2-00024-gbec7550cca10
I can trigger:
Trying to reregister IRQ 11 FD 9 TYPE 0 ID (____ptrval____) write_sigio_irq : um_request_irq failed, err = -16
during boot when:
# CONFIG_UML_NET_VECTOR is not set
Looking at the code there seems to be a one off error
in the LAST_IRQ calculation when CONFIG_UML_NET_VECTOR is enabled. In that case the patch should be reverted and the following applied:
arch/um/include/asm/irq.h +0 -0
index 49ed3e35b35a..ce7a78c3bcf2 100644

arch/um/include/asm/irq.h line 27

Quoted 6 lines

arch/um/include/asm/irq.h +1 -1

@@ -23,7 +23,7 @@
  #define VECTOR_BASE_IRQ                15
  #define VECTOR_IRQ_SPACE       8
 
-#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ)
+#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ - 1)

That does not work. Vector IRQs are allocated modulo VECTOR_IRQ_SPACE. Line 1219 and 1234 in vector_kern.c.

irq_rr = (irq_rr + 1) % VECTOR_IRQ_SPACE;

#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ - 1) will definitely give off-by-one if vector network drivers are enabled.

IRQ 11 is sigio, this is something else.

Can I have your .config please so I can try to reproduce it.

Quoted 9 lines

arch/um/include/asm/irq.h +0 -0
  #else
 
Dana
_______________________________________________
linux-um mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-um

Signature · 8 lines

Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

_______________________________________________
linux-um mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-um

Dana Johnson

2019-06-03 19:32 UTC #14 lore raw

Re: [RESEND PATCH 4/4] um: irq: don't set the chip for all irqs

Quoted 79 lines · Anton Ivanov

Quoted 67 lines · Dana Johnson
Quoted 36 lines · Bartosz Golaszewski
pt., 10 maj 2019 o 18:22 Anton Ivanov
<[email protected]> napisał(a):
Quoted 22 lines · Bartosz Golaszewski
Quoted 19 lines
pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):
Quoted 18 lines
śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> napisał(a):
Quoted 11 lines
----- Ursprüngliche Mail -----
Quoted 5 lines
Quoted 4 lines
Can you please check?
This patch is already queued in -next. So we need to decide whether to revert or fix it now.
I am looking at it. It passed tests in my case (I did the usual round).
It works here too. That's why I never noticed.
Yesterday I noticed just because I looked for something else in the kernel logs.
Thanks,
//richard
Hi,
sorry for the late reply - I just came back from vacation.
I see it here too, I'll check if I can find the culprit and fix it today.
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Bart
Hi Richard, Anton,
I'm not sure yet what this is caused by. It doesn't seem to break anything for me but since it's a new error message I guess it's best to revert this patch (others are good) and revisit it for v5.3.
Can you send me your command line and .config so I can try to reproduce it.
Sure,
Quoted 9 lines
the command line is:
./linux rootfstype=hostfs rootflags=<path to a regular buildroot rootfs> rw mem=48M
The config is the regular x86_64_defconfig from arch/um.
Bart
I hit this compiling 5.2.0-rc2-00024-gbec7550cca10
I can trigger:
Trying to reregister IRQ 11 FD 9 TYPE 0 ID (____ptrval____) write_sigio_irq : um_request_irq failed, err = -16
during boot when:
# CONFIG_UML_NET_VECTOR is not set
Looking at the code there seems to be a one off error
in the LAST_IRQ calculation when CONFIG_UML_NET_VECTOR is enabled. In that case the patch should be reverted and the following applied:
arch/um/include/asm/irq.h +0 -0
index 49ed3e35b35a..ce7a78c3bcf2 100644
arch/um/include/asm/irq.h line 27
Quoted 6 lines
arch/um/include/asm/irq.h +1 -1
@@ -23,7 +23,7 @@
   #define VECTOR_BASE_IRQ                15
   #define VECTOR_IRQ_SPACE       8
 
-#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ)
+#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ - 1)
 
That does not work. Vector IRQs are allocated modulo VECTOR_IRQ_SPACE. Line 1219 and 1234 in vector_kern.c.

Quoted 13 lines

irq_rr = (irq_rr + 1) % VECTOR_IRQ_SPACE;
#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ - 1) will definitely give off-by-one if vector network drivers are enabled.
IRQ 11 is sigio, this is something else.
Can I have your .config please so I can try to reproduce it.
Quoted 4 lines
arch/um/include/asm/irq.h +0 -0
   #else
 
Dana

Yes exactly irq_rr takes on the values: 0..(VECTOR_IRQ_SPACE - 1). The maximum value of irq_rr is (VECTOR_IRQ_SPACE - 1) So LAST_IRQ is:

#define LAST_IRQ (VECTOR_BASE_IRQ + (VECTOR_IRQ_SPACE - 1))

Before the patch we benignly initialized an extra interrupt using

#define LAST_IRQ (VECTOR_IRQ_SPACE + VECTOR_BASE_IRQ)

After the patch everything is still good for vector because of the benign claim of an extra interrupt, but

When:

# CONFIG_UML_NET_VECTOR is not set

changing in kernel/irq.c from:

       for (i = 1; i < NR_IRQS; i++)
to:
       for (i = 1; i < LAST_IRQ; i++)

We stop one short in initalizing with leads to the burble.

So keeping the patch we need to use '<=" not '<'

The test needs to be:

       for (i = 1; i <= LAST_IRQ; i++)

and LAST_IRQ:

#define LAST_IRQ (VECTOR_BASE_IRQ + (VECTOR_IRQ_SPACE - 1))

Dana

_______________________________________________
linux-um mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-um

Richard Weinberger

maintainer

2019-04-14 07:57 UTC #15 lore raw

In reply to Bartosz Golaszewski

Am Donnerstag, 11. April 2019, 11:49:40 CEST schrieb Bartosz Golaszewski:

Quoted 3 lines

From: Bartosz Golaszewski <[email protected]>
Resending again - this time with tags collected.

Queued for next merge window.

Thanks,
//richard