[RESEND PATCH 0/4] um: build and irq fixes

[RESEND PATCH 0/4] um: build and irq fixes

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

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(-)

-- 
2.21.0

[RESEND PATCH 1/4] um: remove unused variable

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The buf variable is unused. Remove it.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
---
 arch/um/kernel/skas/uaccess.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/um/kernel/skas/uaccess.c b/arch/um/kernel/skas/uaccess.c
index 7f06fdbc7ee1..bd3cb694322c 100644
--- a/arch/um/kernel/skas/uaccess.c
+++ b/arch/um/kernel/skas/uaccess.c
@@ -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;
-- 
2.21.0

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

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

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 <bgolaszewski@baylibre.com>
---
 arch/um/os-Linux/umid.c | 36 +++++++++++++++++++++++++++---------
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/arch/um/os-Linux/umid.c b/arch/um/os-Linux/umid.c
index 998fbb445458..e261656fe9d7 100644
--- a/arch/um/os-Linux/umid.c
+++ b/arch/um/os-Linux/umid.c
@@ -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);
-- 
2.21.0

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

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

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 <bgolaszewski@baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
---
 arch/um/include/asm/pgtable.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/um/include/asm/pgtable.h b/arch/um/include/asm/pgtable.h
index 9c04562310b3..b377df76cc28 100644
--- a/arch/um/include/asm/pgtable.h
+++ b/arch/um/include/asm/pgtable.h
@@ -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)
-- 
2.21.0

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

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

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 <bgolaszewski@baylibre.com>
Reviewed-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
---
 arch/um/kernel/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index f4874b7ec503..598d7b3d9355 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
@@ -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();
-- 
2.21.0

Re: [RESEND PATCH 0/4] um: build and irq fixes

[Richard Weinberger]

Am Donnerstag, 11. April 2019, 11:49:40 CEST schrieb Bartosz Golaszewski:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> Resending again - this time with tags collected.

Queued for next merge window.

Thanks,
//richard

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

[Richard Weinberger]

On Thu, Apr 11, 2019 at 11:50 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> 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 <bgolaszewski@baylibre.com>
> Reviewed-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
> Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>

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.

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

[Anton Ivanov]

On 07/05/2019 22:26, Richard Weinberger wrote:
> On Thu, Apr 11, 2019 at 11:50 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> 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 <bgolaszewski@baylibre.com>
>> Reviewed-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
>> Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
> 
> 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.
> 
I am looking at it. It passed tests in my case (I did the usual round).

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

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

[Richard Weinberger]

----- Ursprüngliche Mail -----
>> 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

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

[Bartosz Golaszewski]

śr., 8 maj 2019 o 09:13 Richard Weinberger <richard@nod.at> napisał(a):
>
> ----- Ursprüngliche Mail -----
> >> 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.

Bart

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

[Bartosz Golaszewski]

pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> śr., 8 maj 2019 o 09:13 Richard Weinberger <richard@nod.at> napisał(a):
> >
> > ----- Ursprüngliche Mail -----
> > >> 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.
>
> 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

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

[Anton Ivanov]

On 10/05/2019 17:20, Bartosz Golaszewski wrote:
> pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>> śr., 8 maj 2019 o 09:13 Richard Weinberger <richard@nod.at> napisał(a):
>>> ----- Ursprüngliche Mail -----
>>>>> 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.
>>
>> 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,

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

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

[Bartosz Golaszewski]

pt., 10 maj 2019 o 18:22 Anton Ivanov
<anton.ivanov@cambridgegreys.com> napisał(a):
>
>
> On 10/05/2019 17:20, Bartosz Golaszewski wrote:
> > pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
> >> śr., 8 maj 2019 o 09:13 Richard Weinberger <richard@nod.at> napisał(a):
> >>> ----- Ursprüngliche Mail -----
> >>>>> 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.
> >>
> >> 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

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

[Dana Johnson]

On 5/11/19 5:48 AM, Bartosz Golaszewski wrote:
> pt., 10 maj 2019 o 18:22 Anton Ivanov
> <anton.ivanov@cambridgegreys.com> napisał(a):
>>
>>
>> On 10/05/2019 17:20, Bartosz Golaszewski wrote:
>>> pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>>>> śr., 8 maj 2019 o 09:13 Richard Weinberger <richard@nod.at> napisał(a):
>>>>> ----- Ursprüngliche Mail -----
>>>>>>> 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.
>>>>
>>>> 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
> 
 
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:


diff --git a/arch/um/include/asm/irq.h b/arch/um/include/asm/irq.h
index 49ed3e35b35a..ce7a78c3bcf2 100644
--- a/arch/um/include/asm/irq.h
+++ b/arch/um/include/asm/irq.h
@@ -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
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

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

[Anton Ivanov]

On 31/05/2019 11:30, Dana Johnson wrote:
> On 5/11/19 5:48 AM, Bartosz Golaszewski wrote:
>> pt., 10 maj 2019 o 18:22 Anton Ivanov
>> <anton.ivanov@cambridgegreys.com> napisał(a):
>>>
>>>
>>> On 10/05/2019 17:20, Bartosz Golaszewski wrote:
>>>> pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>>>>> śr., 8 maj 2019 o 09:13 Richard Weinberger <richard@nod.at> napisał(a):
>>>>>> ----- Ursprüngliche Mail -----
>>>>>>>> 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.
>>>>>
>>>>> 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
>>
>   
> 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:
> 
> 
> diff --git a/arch/um/include/asm/irq.h b/arch/um/include/asm/irq.h
> index 49ed3e35b35a..ce7a78c3bcf2 100644
> --- a/arch/um/include/asm/irq.h
> +++ b/arch/um/include/asm/irq.h
> @@ -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.

>   #else
> 
> Dana
> 
> _______________________________________________
> linux-um mailing list
> linux-um@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 

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

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

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

[Dana Johnson]

On 6/2/19 11:54 PM, Anton Ivanov wrote:
> 
> 
> On 31/05/2019 11:30, Dana Johnson wrote:
>> On 5/11/19 5:48 AM, Bartosz Golaszewski wrote:
>>> pt., 10 maj 2019 o 18:22 Anton Ivanov
>>> <anton.ivanov@cambridgegreys.com> napisał(a):
>>>>
>>>>
>>>> On 10/05/2019 17:20, Bartosz Golaszewski wrote:
>>>>> pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>>>>>> śr., 8 maj 2019 o 09:13 Richard Weinberger <richard@nod.at> napisał(a):
>>>>>>> ----- Ursprüngliche Mail -----
>>>>>>>>> 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.
>>>>>>
>>>>>> 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
>>>
>>   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:
>>
>>
>> diff --git a/arch/um/include/asm/irq.h b/arch/um/include/asm/irq.h
>> index 49ed3e35b35a..ce7a78c3bcf2 100644
>> --- a/arch/um/include/asm/irq.h
>> +++ b/arch/um/include/asm/irq.h
>> @@ -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.
> 
>>   #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
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

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

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

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 <bgolaszewski@baylibre.com>
---
 arch/um/kernel/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index f4874b7ec503..598d7b3d9355 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
@@ -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();
-- 
2.21.0