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(-)
--
2.21.0
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(-)
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
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(-)
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
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(-)
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
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(-)
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
Am Donnerstag, 11. April 2019, 11:49:40 CEST schrieb Bartosz Golaszewski:
> From: Bartosz Golaszewski <[email protected]>
>
> Resending again - this time with tags collected.
Queued for next merge window.
Thanks,
//richard
On Thu, Apr 11, 2019 at 11:50 AM Bartosz Golaszewski <[email protected]> wrote:
>
> 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]>
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.
On 07/05/2019 22:26, Richard Weinberger wrote:
> On Thu, Apr 11, 2019 at 11:50 AM Bartosz Golaszewski <[email protected]> wrote:
>>
>> 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]>
>
> 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/
----- 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
śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> 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
pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):
>
> śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> 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
On 10/05/2019 17:20, Bartosz Golaszewski wrote:
> pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):
>> śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> 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/
pt., 10 maj 2019 o 18:22 Anton Ivanov
<[email protected]> napisał(a):
>
>
> On 10/05/2019 17:20, Bartosz Golaszewski wrote:
> > pt., 10 maj 2019 o 11:16 Bartosz Golaszewski <[email protected]> napisał(a):
> >> śr., 8 maj 2019 o 09:13 Richard Weinberger <[email protected]> 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