November 2020 - Linux-stable-mirror

[git:media_tree/master] media: sunxi-cir: ensure IR is handled when it is continuous

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: sunxi-cir: ensure IR is handled when it is continuous Author: Sean Young <sean(a)mess.org> Date: Mon Nov 9 23:16:52 2020 +0100 If a user holds a button down on a remote, then no ir idle interrupt will be generated until the user releases the button, depending on how quickly the remote repeats. No IR is processed until that point, which means that holding down a button may not do anything. This also resolves an issue on a Cubieboard 1 where the IR receiver is picking up ambient infrared as IR and spews out endless "rc rc0: IR event FIFO is full!" messages unless you choose to live in the dark. Cc: stable(a)vger.kernel.org Tested-by: Hans Verkuil <hverkuil(a)xs4all.nl> Acked-by: Maxime Ripard <mripard(a)kernel.org> Reported-by: Hans Verkuil <hverkuil(a)xs4all.nl> Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/rc/sunxi-cir.c | 2 ++ 1 file changed, 2 insertions(+) --- diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c index ddee6ee37bab..4afc5895bee7 100644 --- a/drivers/media/rc/sunxi-cir.c +++ b/drivers/media/rc/sunxi-cir.c @@ -137,6 +137,8 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id) } else if (status & REG_RXSTA_RPE) { ir_raw_event_set_idle(ir->rc, true); ir_raw_event_handle(ir->rc); + } else { + ir_raw_event_handle(ir->rc); } spin_unlock(&ir->ir_lock);

4 years

1
0
0 0

Re: [PATCH v3] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status

by Coiby Xu

On Wed, Nov 25, 2020 at 12:39:02PM +0000, Barnabás Pőcze wrote: >2020. november 25., szerda 11:57 keltezéssel, Coiby Xu írta: > >> On Mon, Nov 23, 2020 at 04:32:40PM +0000, Barnabás Pőcze wrote: >> >> [...] >> >> >> >> +static int get_gpio_pin_state(struct irq_desc *irq_desc) >> >> >> >> +{ >> >> >> >> + struct gpio_chip *gc = irq_data_get_irq_chip_data(&irq_desc->irq_data); >> >> >> >> + >> >> >> >> + return gc->get(gc, irq_desc->irq_data.hwirq); >> >> >> >> +} >> >> >> [...] >> >> >> >> + ssize_t status = get_gpio_pin_state(irq_desc); >> >> >> > >> >> >> >`get_gpio_pin_state()` returns an `int`, so I am not sure why `ssize_t` is used here. >> >> >> > >> >> >> >> >> >> I used `ssize_t` because I found gpiolib-sysfs.c uses `ssize_t` >> >> >> >> >> >> // drivers/gpio/gpiolib-sysfs.c >> >> >> static ssize_t value_show(struct device *dev, >> >> >> struct device_attribute *attr, char *buf) >> >> >> { >> >> >> struct gpiod_data *data = dev_get_drvdata(dev); >> >> >> struct gpio_desc *desc = data->desc; >> >> >> ssize_t status; >> >> >> >> >> >> mutex_lock(&data->mutex); >> >> >> >> >> >> status = gpiod_get_value_cansleep(desc); >> >> >> ... >> >> >> return status; >> >> >> } >> >> >> >> >> >> According to the book Advanced Programming in the UNIX Environment by >> >> >> W. Richard Stevens, >> >> >> With the 1990 POSIX.1 standard, the primitive system data type >> >> >> ssize_t was introduced to provide the signed return value... >> >> >> >> >> >> So ssize_t is fairly common, for example, the read and write syscall >> >> >> return a value of type ssize_t. But I haven't found out why ssize_t is >> >> >> better int. >> >> >> > >> >> > >> >> >Sorry if I wasn't clear, what prompted me to ask that question is the following: >> >> >`gc->get()` returns `int`, `get_gpio_pin_state()` returns `int`, yet you still >> >> >save the return value of `get_gpio_pin_state()` into a variable with type >> >> >`ssize_t` for no apparent reason. In the example you cited, `ssize_t` is used >> >> >because the show() callback of a sysfs attribute must return `ssize_t`, but here, >> >> >`interrupt_line_active()` returns `bool`, so I don't see any advantage over a >> >> >plain `int`. Anyways, I believe either one is fine, I just found it odd. >> >> > >> >> I don't understand why "the show() callback of a sysfs attribute >> >> must return `ssize_t`" instead of int. Do you think the rationale >> >> behind it is the same for this case? If yes, using "ssize_t" for >> >> status could be justified. >> >> [...] >> > >> >Because it was decided that way, `ssize_t` is a better choice for that purpose >> >than plain `int`. You can see it in include/linux/device.h, that both the >> >show() and store() methods must return `ssize_t`. >> > >> >> Could you explain why `ssize_t` is a better choice? AFAIU, ssize_t >> is used because we can return negative value to indicate an error. > >ssize_t: "Signed integer type used for a count of bytes or an error indication."[1] > >And POSIX mandates that the return type of read() and write() be `ssize_t`, >so it makes sense to keep a similar interface in the kernel since show() and store() >are called as a direct result of the user using the read() and write() system >calls, respectively. > > >> If >> we use ssize_t here, it's a reminder that reading a GPIO pin's status >> could fail. And ssize_t reminds us it's a operation similar to read >> or write. So ssize_t is better than int here. And maybe it's the same >> reason why "it was decided that way". >> [...] > >I believe it's more appropriate to use ssize_t when it's about a "count of elements", >but the GPIO pin state is a single boolean value (or an error indication), which >is returned as an `int`. Since it's returned as an `int` - I'm arguing that - >there is no reason to use `ssize_t` here. Anyways, both `ssize_t` and `int` work fine >in this case. > So value_show in gpiolib-sysfs.c is a kind of being forced to use ssize_t. I'll use int instead to avoid confusion in v4. Thank you for the explanation! > >[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#t… > > >Regards, >Barnabás Pőcze -- Best regards, Coiby

4 years

1
0
0 0

FAILED: patch "[PATCH] leds: lm3697: Fix out-of-bound access" failed to apply to 5.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 98d278ca00bd8f62c8bc98bd9e65372d16eb6956 Mon Sep 17 00:00:00 2001 From: Gabriel David <ultracoolguy(a)tutanota.com> Date: Fri, 2 Oct 2020 18:27:00 -0400 Subject: [PATCH] leds: lm3697: Fix out-of-bound access If both LED banks aren't used in device tree, an out-of-bounds condition in lm3697_init occurs because of the for loop assuming that all the banks are used. Fix it by adding a variable that contains the number of used banks. Signed-off-by: Gabriel David <ultracoolguy(a)tutanota.com> [removed extra rename, minor tweaks] Signed-off-by: Pavel Machek <pavel(a)ucw.cz> Cc: stable(a)kernel.org diff --git a/drivers/leds/leds-lm3697.c b/drivers/leds/leds-lm3697.c index 64c0794801e6..7d216cdb91a8 100644 --- a/drivers/leds/leds-lm3697.c +++ b/drivers/leds/leds-lm3697.c @@ -78,6 +78,7 @@ struct lm3697 { struct mutex lock; int bank_cfg; + int num_banks; struct lm3697_led leds[]; }; @@ -180,7 +181,7 @@ static int lm3697_init(struct lm3697 *priv) if (ret) dev_err(dev, "Cannot write OUTPUT config\n"); - for (i = 0; i < LM3697_MAX_CONTROL_BANKS; i++) { + for (i = 0; i < priv->num_banks; i++) { led = &priv->leds[i]; ret = ti_lmu_common_set_ramp(&led->lmu_data); if (ret) @@ -301,8 +302,8 @@ static int lm3697_probe(struct i2c_client *client, int ret; count = device_get_child_node_count(dev); - if (!count) { - dev_err(dev, "LEDs are not defined in device tree!"); + if (!count || count > LM3697_MAX_CONTROL_BANKS) { + dev_err(dev, "Strange device tree!"); return -ENODEV; } @@ -315,6 +316,7 @@ static int lm3697_probe(struct i2c_client *client, led->client = client; led->dev = dev; + led->num_banks = count; led->regmap = devm_regmap_init_i2c(client, &lm3697_regmap_config); if (IS_ERR(led->regmap)) { ret = PTR_ERR(led->regmap);

4 years

4
3
0 0

[PATCH 5/5] memory: renesas-rpc-if: Fix a reference leak in rpcif_probe()

by Lad Prabhakar

Release the node reference by calling of_node_put(flash) in the probe. Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver") Reported-by: Pavel Machek <pavel(a)denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Cc: stable(a)vger.kernel.org --- drivers/memory/renesas-rpc-if.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/memory/renesas-rpc-if.c b/drivers/memory/renesas-rpc-if.c index f5cbc762fda7..99633986ffda 100644 --- a/drivers/memory/renesas-rpc-if.c +++ b/drivers/memory/renesas-rpc-if.c @@ -548,9 +548,11 @@ static int rpcif_probe(struct platform_device *pdev) } else if (of_device_is_compatible(flash, "cfi-flash")) { name = "rpc-if-hyperflash"; } else { + of_node_put(flash); dev_warn(&pdev->dev, "unknown flash type\n"); return -ENODEV; } + of_node_put(flash); vdev = platform_device_alloc(name, pdev->id); if (!vdev) -- 2.17.1

4 years

2
1
0 0

FAILED: patch "[PATCH] mm/userfaultfd: do not access vma->vm_mm after calling" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bfe8cc1db02ab243c62780f17fc57f65bde0afe1 Mon Sep 17 00:00:00 2001 From: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Date: Sat, 21 Nov 2020 22:17:15 -0800 Subject: [PATCH] mm/userfaultfd: do not access vma->vm_mm after calling handle_userfault() Alexander reported a syzkaller / KASAN finding on s390, see below for complete output. In do_huge_pmd_anonymous_page(), the pre-allocated pagetable will be freed in some cases. In the case of userfaultfd_missing(), this will happen after calling handle_userfault(), which might have released the mmap_lock. Therefore, the following pte_free(vma->vm_mm, pgtable) will access an unstable vma->vm_mm, which could have been freed or re-used already. For all architectures other than s390 this will go w/o any negative impact, because pte_free() simply frees the page and ignores the passed-in mm. The implementation for SPARC32 would also access mm->page_table_lock for pte_free(), but there is no THP support in SPARC32, so the buggy code path will not be used there. For s390, the mm->context.pgtable_list is being used to maintain the 2K pagetable fragments, and operating on an already freed or even re-used mm could result in various more or less subtle bugs due to list / pagetable corruption. Fix this by calling pte_free() before handle_userfault(), similar to how it is already done in __do_huge_pmd_anonymous_page() for the WRITE / non-huge_zero_page case. Commit 6b251fc96cf2c ("userfaultfd: call handle_userfault() for userfaultfd_missing() faults") actually introduced both, the do_huge_pmd_anonymous_page() and also __do_huge_pmd_anonymous_page() changes wrt to calling handle_userfault(), but only in the latter case it put the pte_free() before calling handle_userfault(). BUG: KASAN: use-after-free in do_huge_pmd_anonymous_page+0xcda/0xd90 mm/huge_memory.c:744 Read of size 8 at addr 00000000962d6988 by task syz-executor.0/9334 CPU: 1 PID: 9334 Comm: syz-executor.0 Not tainted 5.10.0-rc1-syzkaller-07083-g4c9720875573 #0 Hardware name: IBM 3906 M04 701 (KVM/Linux) Call Trace: do_huge_pmd_anonymous_page+0xcda/0xd90 mm/huge_memory.c:744 create_huge_pmd mm/memory.c:4256 [inline] __handle_mm_fault+0xe6e/0x1068 mm/memory.c:4480 handle_mm_fault+0x288/0x748 mm/memory.c:4607 do_exception+0x394/0xae0 arch/s390/mm/fault.c:479 do_dat_exception+0x34/0x80 arch/s390/mm/fault.c:567 pgm_check_handler+0x1da/0x22c arch/s390/kernel/entry.S:706 copy_from_user_mvcos arch/s390/lib/uaccess.c:111 [inline] raw_copy_from_user+0x3a/0x88 arch/s390/lib/uaccess.c:174 _copy_from_user+0x48/0xa8 lib/usercopy.c:16 copy_from_user include/linux/uaccess.h:192 [inline] __do_sys_sigaltstack kernel/signal.c:4064 [inline] __s390x_sys_sigaltstack+0xc8/0x240 kernel/signal.c:4060 system_call+0xe0/0x28c arch/s390/kernel/entry.S:415 Allocated by task 9334: slab_alloc_node mm/slub.c:2891 [inline] slab_alloc mm/slub.c:2899 [inline] kmem_cache_alloc+0x118/0x348 mm/slub.c:2904 vm_area_dup+0x9c/0x2b8 kernel/fork.c:356 __split_vma+0xba/0x560 mm/mmap.c:2742 split_vma+0xca/0x108 mm/mmap.c:2800 mlock_fixup+0x4ae/0x600 mm/mlock.c:550 apply_vma_lock_flags+0x2c6/0x398 mm/mlock.c:619 do_mlock+0x1aa/0x718 mm/mlock.c:711 __do_sys_mlock2 mm/mlock.c:738 [inline] __s390x_sys_mlock2+0x86/0xa8 mm/mlock.c:728 system_call+0xe0/0x28c arch/s390/kernel/entry.S:415 Freed by task 9333: slab_free mm/slub.c:3142 [inline] kmem_cache_free+0x7c/0x4b8 mm/slub.c:3158 __vma_adjust+0x7b2/0x2508 mm/mmap.c:960 vma_merge+0x87e/0xce0 mm/mmap.c:1209 userfaultfd_release+0x412/0x6b8 fs/userfaultfd.c:868 __fput+0x22c/0x7a8 fs/file_table.c:281 task_work_run+0x200/0x320 kernel/task_work.c:151 tracehook_notify_resume include/linux/tracehook.h:188 [inline] do_notify_resume+0x100/0x148 arch/s390/kernel/signal.c:538 system_call+0xe6/0x28c arch/s390/kernel/entry.S:416 The buggy address belongs to the object at 00000000962d6948 which belongs to the cache vm_area_struct of size 200 The buggy address is located 64 bytes inside of 200-byte region [00000000962d6948, 00000000962d6a10) The buggy address belongs to the page: page:00000000313a09fe refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x962d6 flags: 0x3ffff00000000200(slab) raw: 3ffff00000000200 000040000257e080 0000000c0000000c 000000008020ba00 raw: 0000000000000000 000f001e00000000 ffffffff00000001 0000000096959501 page dumped because: kasan: bad access detected page->mem_cgroup:0000000096959501 Memory state around the buggy address: 00000000962d6880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000962d6900: 00 fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb >00000000962d6980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 00000000962d6a00: fb fb fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00000000962d6a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Fixes: 6b251fc96cf2c ("userfaultfd: call handle_userfault() for userfaultfd_missing() faults") Reported-by: Alexander Egorenkov <egorenar(a)linux.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> [4.3+] Link: https://lkml.kernel.org/r/20201110190329.11920-1-gerald.schaefer@linux.ibm.… Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 9474dbc150ed..ec2bb93f7431 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -710,7 +710,6 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf) transparent_hugepage_use_zero_page()) { pgtable_t pgtable; struct page *zero_page; - bool set; vm_fault_t ret; pgtable = pte_alloc_one(vma->vm_mm); if (unlikely(!pgtable)) @@ -723,25 +722,25 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf) } vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd); ret = 0; - set = false; if (pmd_none(*vmf->pmd)) { ret = check_stable_address_space(vma->vm_mm); if (ret) { spin_unlock(vmf->ptl); + pte_free(vma->vm_mm, pgtable); } else if (userfaultfd_missing(vma)) { spin_unlock(vmf->ptl); + pte_free(vma->vm_mm, pgtable); ret = handle_userfault(vmf, VM_UFFD_MISSING); VM_BUG_ON(ret & VM_FAULT_FALLBACK); } else { set_huge_zero_page(pgtable, vma->vm_mm, vma, haddr, vmf->pmd, zero_page); spin_unlock(vmf->ptl); - set = true; } - } else + } else { spin_unlock(vmf->ptl); - if (!set) pte_free(vma->vm_mm, pgtable); + } return ret; } gfp = alloc_hugepage_direct_gfpmask(vma);

4 years

3
2
0 0

perf: Apply e9a6882f267a to v4.9 stable (fix for null-pointer dereference)

by Alexander Dahl

Hei hei, please apply e9a6882f267a8105461066e3ea6b4b6b9be1b807 ("perf event: Check ref_reloc_sym before using it") to the v4.9 stable tree and maybe to later LTS trees (v4.14, v4.19) as well. That change is in mainline since v5.4-rc1 and it's a fix for a possible null pointer dereference in the tool 'perf', so it is a fix for a user space tool coming with the kernel tree actually. I am directly affeted by this, calling 'perf record' on an at91 based device (armv5te, sam9g20 soc) running PREEMPT RT kernel 4.9.220-rt143 results in a segfault here. I debugged this with gdb and tracked it down to the exact pointer being NULL, which is checked now in that above mentioned changeset. I could cleanly apply that changeset to my local tree and the segfault is not triggered anymore, I can use perf on that platform now. I only tested this on the above mentioned v4.9 based kernel version. Thanks & Greets Alex

4 years

2
1
0 0

Re: [PATCH v3] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status

by Coiby Xu

On Mon, Nov 23, 2020 at 04:32:40PM +0000, Barnabás Pőcze wrote: >> [...] >> >> >> +static int get_gpio_pin_state(struct irq_desc *irq_desc) >> >> >> +{ >> >> >> + struct gpio_chip *gc = irq_data_get_irq_chip_data(&irq_desc->irq_data); >> >> >> + >> >> >> + return gc->get(gc, irq_desc->irq_data.hwirq); >> >> >> +} >> >> [...] >> >> >> + ssize_t status = get_gpio_pin_state(irq_desc); >> >> > >> >> >`get_gpio_pin_state()` returns an `int`, so I am not sure why `ssize_t` is used here. >> >> > >> >> >> >> I used `ssize_t` because I found gpiolib-sysfs.c uses `ssize_t` >> >> >> >> // drivers/gpio/gpiolib-sysfs.c >> >> static ssize_t value_show(struct device *dev, >> >> struct device_attribute *attr, char *buf) >> >> { >> >> struct gpiod_data *data = dev_get_drvdata(dev); >> >> struct gpio_desc *desc = data->desc; >> >> ssize_t status; >> >> >> >> mutex_lock(&data->mutex); >> >> >> >> status = gpiod_get_value_cansleep(desc); >> >> ... >> >> return status; >> >> } >> >> >> >> According to the book Advanced Programming in the UNIX Environment by >> >> W. Richard Stevens, >> >> With the 1990 POSIX.1 standard, the primitive system data type >> >> ssize_t was introduced to provide the signed return value... >> >> >> >> So ssize_t is fairly common, for example, the read and write syscall >> >> return a value of type ssize_t. But I haven't found out why ssize_t is >> >> better int. >> >> > >> > >> >Sorry if I wasn't clear, what prompted me to ask that question is the following: >> >`gc->get()` returns `int`, `get_gpio_pin_state()` returns `int`, yet you still >> >save the return value of `get_gpio_pin_state()` into a variable with type >> >`ssize_t` for no apparent reason. In the example you cited, `ssize_t` is used >> >because the show() callback of a sysfs attribute must return `ssize_t`, but here, >> >`interrupt_line_active()` returns `bool`, so I don't see any advantage over a >> >plain `int`. Anyways, I believe either one is fine, I just found it odd. >> > >> I don't understand why "the show() callback of a sysfs attribute >> must return `ssize_t`" instead of int. Do you think the rationale >> behind it is the same for this case? If yes, using "ssize_t" for >> status could be justified. >> [...] > >Because it was decided that way, `ssize_t` is a better choice for that purpose >than plain `int`. You can see it in include/linux/device.h, that both the >show() and store() methods must return `ssize_t`. > Could you explain why `ssize_t` is a better choice? AFAIU, ssize_t is used because we can return negative value to indicate an error. If we use ssize_t here, it's a reminder that reading a GPIO pin's status could fail. And ssize_t reminds us it's a operation similar to read or write. So ssize_t is better than int here. And maybe it's the same reason why "it was decided that way". >What I'm arguing here, is that there is no reason to use `ssize_t` in this case. >Because `get_gpio_pin_state()` returns `int`. So when you do >``` >ssize_t status = get_gpio_pin_state(...); >``` >then the return value of `get_gpio_pin_state()` (which is an `int`), will be >converted to an `ssize_t`, and saved into `status`. I'm arguing that that is >unnecessary and a plain `int` would work perfectly well in this case. Anyways, >both work fine, I just found the unnecessary use of `ssize_t` here odd. > > >Regards, >Barnabás Pőcze -- Best regards, Coiby

4 years

1
0
0 0

[PATCH] dma-buf/dma-resv: Respect num_fences when initializing the shared fence list.

by Maarten Lankhorst

We hardcode the maximum number of shared fences to 4, instead of respecting num_fences. Use a minimum of 4, but more if num_fences is higher. This seems to have been an oversight when first implementing the api. Fixes: 04a5faa8cbe5 ("reservation: update api and add some helpers") Cc: <stable(a)vger.kernel.org> # v3.17+ Reported-by: Niranjana Vishwanathapura <niranjana.vishwanathapura(a)intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> --- drivers/dma-buf/dma-resv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index bb5a42b10c29..6ddbeb5dfbf6 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -200,7 +200,7 @@ int dma_resv_reserve_shared(struct dma_resv *obj, unsigned int num_fences) max = max(old->shared_count + num_fences, old->shared_max * 2); } else { - max = 4; + max = max(4ul, roundup_pow_of_two(num_fences)); } new = dma_resv_list_alloc(max); base-commit: d08ea807a6466f311fe921872bc18cfc384ae281 prerequisite-patch-id: 67ededd6181f1f0d00b98376bcacefb776ebfd1b prerequisite-patch-id: 36ea30085b8b6095303642e82a6d9c2373d331c2 prerequisite-patch-id: 453c3fe559333daea47bc5d24171b32ae8483c2d prerequisite-patch-id: 3792e6478845da3a19dda5fdca5d094d3847c6e3 prerequisite-patch-id: 7d4e280d1197ead2e3f90d10d0c38c4685bedd86 prerequisite-patch-id: 6db8468aba0d92cd5d67af028caebe4146b9f02e prerequisite-patch-id: 6550921ad75aaa9ddd30db6a75878d06c13ab6bb prerequisite-patch-id: 35cfae6d6d6c30453026284fc2b25733f005f950 prerequisite-patch-id: 3bf03aa3ed1532d6c67fa47cec3ba34418ea5a79 prerequisite-patch-id: 580e28da7a0e724c293eb5b36a35be0964554885 prerequisite-patch-id: 61932497d71dc764e040deea7a58286dca51a6e0 prerequisite-patch-id: b3f6ac925fd9f3517e63b0595ce138fdd0196db2 prerequisite-patch-id: 609d83e906e26c4d9c0fb5ba29f66eec0234d11b prerequisite-patch-id: 88264df437b404b00bba07edb7761762c52daa9d prerequisite-patch-id: 2d3d4efeb0e32423938d546a683513ee8077143e prerequisite-patch-id: 675d46b64f98322e8ab90b947598d030f1133120 prerequisite-patch-id: fbd3c4bf0ea604f9ab30aa21f28fb26b953f8889 prerequisite-patch-id: d51e789c6ddc37cb65b6e49aaf567ba2a6168841 prerequisite-patch-id: 1e05b33595d37f01087a82f11344b0e3cca2580a prerequisite-patch-id: 64151f1e9a5ae900c09322ef2bade0e1dad06568 prerequisite-patch-id: af71a3e75f28e0ee92721491b27f260500567d92 prerequisite-patch-id: 30c6b42d4bd39703a865ee9ebce41d986a803ce4 prerequisite-patch-id: 15a26c36a233ee3f738faa4a666b4f9c8749494d prerequisite-patch-id: 9733d60910fb3e14ba5caa2eecc97a8c50592d7d prerequisite-patch-id: b7b484c19e966041b39b7e3f089e9fb407c0b641 prerequisite-patch-id: dd2adee5d7c941363193ad4033f419ca8f535b69 prerequisite-patch-id: 89142874b57f3120e4dcdefd7e40168766fc7f52 prerequisite-patch-id: df6983cc3366963afb6e4229cddd5b1a42406e3c prerequisite-patch-id: 7d90d37f7e7545c5710ebdbd3db9967c1d1b5b4d prerequisite-patch-id: 07041f82bdb5a5f886dd13a0a6a27b66d06d17c2 prerequisite-patch-id: 6086254edae9372a2a2a79521a9713c8d30e695c prerequisite-patch-id: 6ad40b13b98391ed21da873bdf88c04f23ecb6fb prerequisite-patch-id: 9fbbbc72209b81bc26573427ec70246eb2d04af1 prerequisite-patch-id: 5cc8743cf655d791faca7934683dd0d758151321 prerequisite-patch-id: 5bd8d06716d6cbae7a9fd904ff8713f3a5d0c8a0 prerequisite-patch-id: 2271226e9ac9ab8d8d93c7c3b2384c3c7bd84b87 prerequisite-patch-id: 19497288dc06ceb627a6eab0c75754a945eb1d71 prerequisite-patch-id: 85867a867694055295ce127a7ce1e9818d76801f prerequisite-patch-id: 1b1d6aa8f4b96f82548917135d7747ed6e250fc7 prerequisite-patch-id: 39838eac42ec51ce7fb0951d4da3c64c801d71cf prerequisite-patch-id: 846be3c76fbbca1890b3874e1fdb2af846d8f3e2 prerequisite-patch-id: 35af5ef849b3b4e207d9d9385580768c75c0827b prerequisite-patch-id: b6aa080addba2ac4c851f41a01b72004e14fe7ca prerequisite-patch-id: c4ba87ce6d1e48bddafb896f3c3d1fe514bf3b5c prerequisite-patch-id: f8e4fec905fb4d6e000df3f17717f7b47d22ae27 prerequisite-patch-id: 8c0f82cdfb3c0995cdff96f9c6fc2971faf60a1e prerequisite-patch-id: b89d16d373447225b2821d784b21331fb62e7a7c prerequisite-patch-id: 1486fef342202199cb746fcf1601621ef07a02c4 prerequisite-patch-id: efad6151fb2cedb2cbe18d3873aa8a9b1ec4ee4f prerequisite-patch-id: 7993a9682b498599a2fca2b7bc9c871c4bc3a374 prerequisite-patch-id: a4c31ca38e3009e9e0f15ec5531f0fa09d4929b8 prerequisite-patch-id: 3e3b4dccd7abc5c1de05d70aa397221d0a6e9c91 prerequisite-patch-id: 421ba703353af51b801fa948d862e6102b52ea9f prerequisite-patch-id: c2ad0f1f0b00408b0068c2f8b235910fe19ce430 prerequisite-patch-id: 13a554c8d1b77415d2bf11ff260a8f932902f11c prerequisite-patch-id: b00e4016272f55195941fedf49de1cb8f0b68dc4 prerequisite-patch-id: f89b24990377441eaf3f45d9b822ff699874af59 prerequisite-patch-id: 97d90df0f9d0499e5d3b4fd5ce37f3bb964c2370 prerequisite-patch-id: 45989d03b7508141fff2b99bee1ed9296841c3dd prerequisite-patch-id: 77549a6ae8ce281254b876b05727983bb9b7560a prerequisite-patch-id: 2ceee10179ceeef045bd54f0d0afa57b3e45a18a prerequisite-patch-id: 28d94479e5cb8294668a6e8f26c1f3abc548fc11 prerequisite-patch-id: c25cb8c4efc803a3103098a043cce9d3db362050 -- 2.29.2.222.g5d2a92d10f8

4 years

2
2
0 0

[PATCH 1/5] memory: renesas-rpc-if: Return correct value to the caller of rpcif_manual_xfer()

by Lad Prabhakar

In the error path of rpcif_manual_xfer() the value of ret is overwritten by value returned by reset_control_reset() function and thus returning incorrect value to the caller. This patch makes sure the correct value is returned to the caller of rpcif_manual_xfer() by dropping the overwrite of ret in error path. Also now we ignore the value returned by reset_control_reset() in the error path and instead print a error message when it fails. Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver") Reported-by: Pavel Machek <pavel(a)denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Cc: stable(a)vger.kernel.org --- drivers/memory/renesas-rpc-if.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/memory/renesas-rpc-if.c b/drivers/memory/renesas-rpc-if.c index f2a33a1af836..69f2e2b4cd50 100644 --- a/drivers/memory/renesas-rpc-if.c +++ b/drivers/memory/renesas-rpc-if.c @@ -508,7 +508,8 @@ int rpcif_manual_xfer(struct rpcif *rpc) return ret; err_out: - ret = reset_control_reset(rpc->rstc); + if (reset_control_reset(rpc->rstc)) + dev_err(rpc->dev, "Failed to reset HW\n"); rpcif_hw_init(rpc, rpc->bus_size == 2); goto exit; } -- 2.17.1

4 years

2
1
0 0

Re: [PATCH] efivarfs: revert "fix memory leak in efivarfs_create()"

by Oleksandr Natalenko

Hello. On 25.11.2020 08:53, Ard Biesheuvel wrote: > The memory leak addressed by commit fe5186cf12e3 is a false positive: > all allocations are recorded in a linked list, and freed when the > filesystem is unmounted. This leads to double frees, and as reported > by David, leads to crashes if SLUB is configured to self destruct when > double frees occur. > > So drop the redundant kfree() again, and instead, mark the offending > pointer variable so the allocation is ignored by kmemleak. > > Cc: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi(a)gmail.com> Should also have: Cc: <stable(a)vger.kernel.org> # v5.9 > Fixes: fe5186cf12e3 ("efivarfs: fix memory leak in efivarfs_create()") > Reported-by: David Laight <David.Laight(a)aculab.com> > Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> > --- > fs/efivarfs/inode.c | 1 + > fs/efivarfs/super.c | 1 - > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/efivarfs/inode.c b/fs/efivarfs/inode.c > index 96c0c86f3fff..38324427a2b3 100644 > --- a/fs/efivarfs/inode.c > +++ b/fs/efivarfs/inode.c > @@ -103,6 +103,7 @@ static int efivarfs_create(struct inode *dir, > struct dentry *dentry, > var->var.VariableName[i] = '\0'; > > inode->i_private = var; > + kmemleak_ignore(var); > > err = efivar_entry_add(var, &efivarfs_list); > if (err) > diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c > index f943fd0b0699..15880a68faad 100644 > --- a/fs/efivarfs/super.c > +++ b/fs/efivarfs/super.c > @@ -21,7 +21,6 @@ LIST_HEAD(efivarfs_list); > static void efivarfs_evict_inode(struct inode *inode) > { > clear_inode(inode); > - kfree(inode->i_private); > } > > static const struct super_operations efivarfs_ops = { -- Oleksandr Natalenko (post-factum)

4 years

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2020