Re: [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap
On Thu, Oct 22, 2020 at 1:20 AM Jason Gunthorpe wrote: > > On Wed, Oct 21, 2020 at 09:24:08PM +0200, Daniel Vetter wrote: > > On Wed, Oct 21, 2020 at 6:37 PM Jason Gunthorpe wrote: > > > > > > On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wrote: > > > > > > > The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to > > > > split that. So ideally ->mmap would never set up any ptes. > > > > > > /dev/mem makes pgoff == pfn so it doesn't get changed by remap. > > > > > > pgoff doesn't get touched for MAP_SHARED either, so there are other > > > users that could work like this - eg anyone mmaping IO memory is > > > probably OK. > > > > I was more generally thinking for io_remap_pfn_users because of the > > mkwrite use-case we might have in fbdev emulation in drm. > > You have a use case for MAP_PRIVATE and io_remap_pfn_range()?? Uh no :-) But for ioremaps and keep track of which pages userspace has touched. Problem is that there's many displays where you need to explicitly upload the data, and in drm we have ioctl calls for that. fbdev mmap assumes this just magically happens. So you need to keep track of write faults, launch a delayed worker which first re-protects all ptes and then uploads the dirty pages. And ideally we wouldn't have to implement this everywhere just for fbdev, but could wrap it around an existing mmap implementation by just intercepting mkwrite. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2] firmware: gsmi: Drop the use of dma_pool_* API functions
On Thu, 22 Oct 2020 at 06:38, Furquan Shaikh wrote:
>
> GSMI driver uses dma_pool_* API functions for buffer allocation
> because it requires that the SMI buffers are allocated within 32-bit
> physical address space. However, this does not work well with IOMMU
> since there is no real device and hence no domain associated with the
> device.
>
> Since this is not a real device, it does not require any device
> address(IOVA) for the buffer allocations. The only requirement is to
> ensure that the physical address allocated to the buffer is within
> 32-bit physical address space. This is because the buffers have
> nothing to do with DMA at all. It is required for communication with
> firmware executing in SMI mode which has access only to the bottom
> 4GiB of memory. Hence, this change switches to using a SLAB cache
> created with SLAB_CACHE_DMA32 that guarantees that the allocation
> happens from the DMA32 memory zone. All calls to dma_pool_* are
> replaced with kmem_cache_*.
>
> In addition to that, all the code for managing the dma_pool for GSMI
> platform device is dropped.
>
> Signed-off-by: Furquan Shaikh
> ---
> Changelog since v1:
> - Switched to using SLAB cache with SLAB_CACHE_DMA32.
> - Added comment to code and commit message explaining the reason for
> using DMA32 memory zone.
>
> drivers/firmware/google/gsmi.c | 38 +++---
> 1 file changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
> index 7d9367b22010..092d8cb209a3 100644
> --- a/drivers/firmware/google/gsmi.c
> +++ b/drivers/firmware/google/gsmi.c
> @@ -17,7 +17,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -85,7 +84,6 @@
> struct gsmi_buf {
> u8 *start; /* start of buffer */
> size_t length; /* length of buffer */
> - dma_addr_t handle; /* dma allocation handle */
> u32 address;/* physical address of buffer */
> };
>
> @@ -97,7 +95,7 @@ static struct gsmi_device {
> spinlock_t lock;/* serialize access to SMIs */
> u16 smi_cmd;/* SMI command port */
> int handshake_type; /* firmware handler interlock type */
> - struct dma_pool *dma_pool; /* DMA buffer pool */
> + struct kmem_cache *mem_pool;/* kmem cache for gsmi_buf
> allocations */
> } gsmi_dev;
>
> /* Packed structures for communicating with the firmware */
> @@ -157,14 +155,20 @@ static struct gsmi_buf *gsmi_buf_alloc(void)
> }
>
> /* allocate buffer in 32bit address space */
> - smibuf->start = dma_pool_alloc(gsmi_dev.dma_pool, GFP_KERNEL,
> - &smibuf->handle);
> + smibuf->start = kmem_cache_alloc(gsmi_dev.mem_pool, GFP_KERNEL);
> if (!smibuf->start) {
> printk(KERN_ERR "gsmi: failed to allocate name buffer\n");
> kfree(smibuf);
> return NULL;
> }
>
> + if ((u64)virt_to_phys(smibuf->start) >> 32) {
> + printk(KERN_ERR "gsmi: allocation not within 32-bit physical
> address space\n");
> + kfree(smibuf->start);
> + kfree(smibuf);
> + return NULL;
> + }
> +
Please drop this check - on x86, DMA32 guarantees that the buffer is
in 32-bit address space.
With the check dropped:
Reviewed-by: Ard Biesheuvel
> /* fill in the buffer handle */
> smibuf->length = GSMI_BUF_SIZE;
> smibuf->address = (u32)virt_to_phys(smibuf->start);
> @@ -176,8 +180,7 @@ static void gsmi_buf_free(struct gsmi_buf *smibuf)
> {
> if (smibuf) {
> if (smibuf->start)
> - dma_pool_free(gsmi_dev.dma_pool, smibuf->start,
> - smibuf->handle);
> + kmem_cache_free(gsmi_dev.mem_pool, smibuf->start);
> kfree(smibuf);
> }
> }
> @@ -914,9 +917,20 @@ static __init int gsmi_init(void)
> spin_lock_init(&gsmi_dev.lock);
>
> ret = -ENOMEM;
> - gsmi_dev.dma_pool = dma_pool_create("gsmi", &gsmi_dev.pdev->dev,
> -GSMI_BUF_SIZE, GSMI_BUF_ALIGN,
> 0);
> - if (!gsmi_dev.dma_pool)
> +
> + /*
> +* SLAB cache is created using SLAB_CACHE_DMA32 to ensure that the
> +* allocations for gsmi_buf come from the DMA32 memory zone. These
> +* buffers have nothing to do with DMA. They are required for
> +* communication with firmware executing in SMI mode which can only
> +* access the bottom 4GiB of physical memory. Since DMA32 memory zone
> +* guarantees allocation under the 4GiB boundary, this driver creates
> +* a SLAB cache with SLAB_CACHE_DMA32 flag.
> +*/
> + gsmi_dev.mem_pool = kmem_cache_create("gsmi",
Re: [PATCH] PM / s2idle: Export s2idle_set_ops
On Thu, Oct 22, 2020 at 02:17:48PM +0800, Claude Yen wrote:
> As suspend_set_ops is exported in commit a5e4fd8783a2
> ("PM / Suspend: Export suspend_set_ops, suspend_valid_only_mem"),
> exporting s2idle_set_ops to make kernel module setup s2idle ops too.
>
> In this way, kernel module can hook platform suspend
> functions regardless of Suspend-to-Ram(S2R) or
> Suspend-to-Idle(S2I)
>
If this is for arm64 platform, then NACK. You must use PSCI and it will
set the ops and it can't be module.
--
Regards,
Sudeep
Re: [PATCH v3] mm: memcg/slab: Stop reparented obj_cgroups from charging root
Hello,
Michal Koutný writes:
> Hi.
>
> On Tue, Oct 20, 2020 at 06:52:08AM +0100, Richard Palethorpe
> wrote:
>> I don't think that is relevant as we get the memcg from objcg->memcg
>> which is set during reparenting. I suppose however, we can determine if
>> the objcg was reparented by inspecting memcg->objcg.
> +1
>
>> If we just check use_hierarchy then objects directly charged to the
>> memcg where use_hierarchy=0 will not be uncharged. However, maybe it is
>> better to check if it was reparented and if use_hierarchy=0.
> I think (I had to make a table) the yielded condition would be:
>
> if ((memcg->use_hierarchy && reparented) || (!mem_cgroup_is_root(memcg) &&
> !reparented))
This looks correct, but I don't think we need to check for reparenting
after all. We have the following unique scenarious:
use_hierarchy=1, memcg=?, reparented=?:
Because use_hierarchy=1 any descendants will have charged the current
memcg, including root, so we can simply uncharge regardless of the memcg
or objcg.
use_hierarchy=0, memcg!=root, reparented=?:
When use_hierarchy=0, objcgs are *only* reparented to root, so if we are
not root the objcg must belong to us.
use_hierarchy=0, memcg=root, reparented=?:
We must have been reparented because root is not initialised with an
objcg, but use_hierarchy=0 so we can not uncharge.
So I believe that the following is sufficient.
if (memcg->use_hierarchy || !mem_cgroup_is_root(memcg))
>__memcg_kmem_uncharge(memcg, nr_pages);
>
> (I admit it's not very readable.)
>
>
> Michal
For the record, I did create the following patch which checks for
reparenting, but it appears to be unecessary.
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 6877c765b8d0..0285f760f003 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -257,6 +257,14 @@ struct cgroup_subsys_state *vmpressure_to_css(struct
vmpressure *vmpr)
#ifdef CONFIG_MEMCG_KMEM
extern spinlock_t css_set_lock;
+/* Assumes objcg originated from a descendant of memcg or is memcg's */
+static bool obj_cgroup_did_charge(const struct obj_cgroup *objcg,
+ const struct mem_cgroup *memcg)
+{
+ return memcg->use_hierarchy ||
+ rcu_access_pointer(memcg->objcg) == objcg;
+}
+
static void obj_cgroup_release(struct percpu_ref *ref)
{
struct obj_cgroup *objcg = container_of(ref, struct obj_cgroup, refcnt);
@@ -291,7 +299,7 @@ static void obj_cgroup_release(struct percpu_ref *ref)
spin_lock_irqsave(&css_set_lock, flags);
memcg = obj_cgroup_memcg(objcg);
- if (nr_pages)
+ if (nr_pages && obj_cgroup_did_charge(objcg, memcg))
__memcg_kmem_uncharge(memcg, nr_pages);
list_del(&objcg->list);
mem_cgroup_put(memcg);
@@ -3100,6 +3108,7 @@ static bool consume_obj_stock(struct obj_cgroup *objcg,
unsigned int nr_bytes)
static void drain_obj_stock(struct memcg_stock_pcp *stock)
{
struct obj_cgroup *old = stock->cached_objcg;
+ struct mem_cgroup *memcg;
if (!old)
return;
@@ -3110,7 +3119,9 @@ static void drain_obj_stock(struct memcg_stock_pcp *stock)
if (nr_pages) {
rcu_read_lock();
- __memcg_kmem_uncharge(obj_cgroup_memcg(old), nr_pages);
+ memcg = obj_cgroup_memcg(old);
+ if (obj_cgroup_did_charge(old, memcg))
+ __memcg_kmem_uncharge(memcg, nr_pages);
rcu_read_unlock();
}
--
Thank you,
Richard.
Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error
On Thu, 22 Oct 2020 at 05:30, Kees Cook wrote:
>
> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > 22.10.2020 02:40, Kees Cook пишет:
> > > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> > >> The vfp_kmode_exception() function now is unreachable using relative
> > >> branching in THUMB2 kernel configuration, resulting in a "relocation
> > >> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
> > >> linker error. Let's use long jump in order to fix the issue.
> > >
> > > Eek. Is this with gcc or clang?
> >
> > GCC 9.3.0
> >
> > >> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
> > >
> > > Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing sections") ?
> > > That commit may have implicitly moved the location of .vfp11_veneer,
> > > though I thought I had chosen the correct position.
> >
> > I re-checked that the fixes tag is correct.
> >
> > >> Signed-off-by: Dmitry Osipenko
> > >> ---
> > >> arch/arm/vfp/vfphw.S | 3 ++-
> > >> 1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > >> index 4fcff9f59947..6e2b29f0c48d 100644
> > >> --- a/arch/arm/vfp/vfphw.S
> > >> +++ b/arch/arm/vfp/vfphw.S
> > >> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > >>ldr r3, [sp, #S_PSR]@ Neither lazy restore nor FP
> > >> exceptions
> > >>and r3, r3, #MODE_MASK @ are supported in kernel mode
> > >>teq r3, #USR_MODE
> > >> - bne vfp_kmode_exception @ Returns through lr
> > >> + ldr r1, =vfp_kmode_exception
> > >> + bxner1 @ Returns through lr
> > >>
> > >>VFPFMRX r1, FPEXC @ Is the VFP enabled?
> > >>DBGSTR1 "fpexc %08x", r1
> > >
> > > This seems like a workaround though? I suspect the vfp11_veneer needs
> > > moving?
> > >
> >
> > I don't know where it needs to be moved. Please feel free to make a
> > patch if you have a better idea, I'll be glad to test it.
>
> I might have just been distracted by the common "vfp" prefix. It's
> possible that the text section shuffling just ended up being very large,
> so probably this patch is right then!
>
I already sent a fix for this issue:
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
Re: [PATCH] sched/fair: check for idle core
On Wed, Oct 21, 2020 at 08:11:59PM +0200, Rafael J. Wysocki wrote: > > @@ -144,6 +145,7 @@ config CPU_FREQ_GOV_USERSPACE > > > > config CPU_FREQ_GOV_ONDEMAND > > tristate "'ondemand' cpufreq policy governor" > > + depends on !SMP > > But I don't think that we can do this and the one below. Well, but we need to do something to force people onto schedutil, otherwise we'll get more crap like this thread. Can we take the choice away? Only let Kconfig select which governors are available and then set the default ourselves? I mean, the end goal being to not have selectable governors at all, this seems like a good step anyway. --- diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 2c7171e0b001..3a9f54b382c0 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -34,77 +34,6 @@ config CPU_FREQ_STAT If in doubt, say N. -choice - prompt "Default CPUFreq governor" - default CPU_FREQ_DEFAULT_GOV_USERSPACE if ARM_SA1100_CPUFREQ || ARM_SA1110_CPUFREQ - default CPU_FREQ_DEFAULT_GOV_SCHEDUTIL if ARM64 || ARM - default CPU_FREQ_DEFAULT_GOV_SCHEDUTIL if X86_INTEL_PSTATE && SMP - default CPU_FREQ_DEFAULT_GOV_PERFORMANCE - help - This option sets which CPUFreq governor shall be loaded at - startup. If in doubt, use the default setting. - -config CPU_FREQ_DEFAULT_GOV_PERFORMANCE - bool "performance" - select CPU_FREQ_GOV_PERFORMANCE - help - Use the CPUFreq governor 'performance' as default. This sets - the frequency statically to the highest frequency supported by - the CPU. - -config CPU_FREQ_DEFAULT_GOV_POWERSAVE - bool "powersave" - select CPU_FREQ_GOV_POWERSAVE - help - Use the CPUFreq governor 'powersave' as default. This sets - the frequency statically to the lowest frequency supported by - the CPU. - -config CPU_FREQ_DEFAULT_GOV_USERSPACE - bool "userspace" - select CPU_FREQ_GOV_USERSPACE - help - Use the CPUFreq governor 'userspace' as default. This allows - you to set the CPU frequency manually or when a userspace - program shall be able to set the CPU dynamically without having - to enable the userspace governor manually. - -config CPU_FREQ_DEFAULT_GOV_ONDEMAND - bool "ondemand" - select CPU_FREQ_GOV_ONDEMAND - select CPU_FREQ_GOV_PERFORMANCE - help - Use the CPUFreq governor 'ondemand' as default. This allows - you to get a full dynamic frequency capable system by simply - loading your cpufreq low-level hardware driver. - Be aware that not all cpufreq drivers support the ondemand - governor. If unsure have a look at the help section of the - driver. Fallback governor will be the performance governor. - -config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE - bool "conservative" - select CPU_FREQ_GOV_CONSERVATIVE - select CPU_FREQ_GOV_PERFORMANCE - help - Use the CPUFreq governor 'conservative' as default. This allows - you to get a full dynamic frequency capable system by simply - loading your cpufreq low-level hardware driver. - Be aware that not all cpufreq drivers support the conservative - governor. If unsure have a look at the help section of the - driver. Fallback governor will be the performance governor. - -config CPU_FREQ_DEFAULT_GOV_SCHEDUTIL - bool "schedutil" - depends on SMP - select CPU_FREQ_GOV_SCHEDUTIL - select CPU_FREQ_GOV_PERFORMANCE - help - Use the 'schedutil' CPUFreq governor by default. If unsure, - have a look at the help section of that governor. The fallback - governor will be 'performance'. - -endchoice - config CPU_FREQ_GOV_PERFORMANCE tristate "'performance' governor" help @@ -145,6 +74,7 @@ config CPU_FREQ_GOV_USERSPACE config CPU_FREQ_GOV_ONDEMAND tristate "'ondemand' cpufreq policy governor" select CPU_FREQ_GOV_COMMON + select CPU_FREQ_GOV_PERFORMANCE help 'ondemand' - This driver adds a dynamic cpufreq policy governor. The governor does a periodic polling and @@ -164,6 +94,7 @@ config CPU_FREQ_GOV_CONSERVATIVE tristate "'conservative' cpufreq governor" depends on CPU_FREQ select CPU_FREQ_GOV_COMMON + select CPU_FREQ_GOV_PERFORMANCE help 'conservative' - this driver is rather similar to the 'ondemand' governor both in its source code and its purpose, the difference is @@ -188,6 +119,7 @@ config CPU_FREQ_GOV_SCHEDUTIL bool "'schedutil' cpufreq policy governor" depends on CPU_FREQ && SMP select CPU_FREQ_GOV_ATTR_SET + select CPU_FREQ_GOV_PERFORMANCE select IRQ_WORK help This governor makes decisions based on the utilization data provided diff --git a/drivers/cpufreq/cpufreq.c b/d
Re: [PATCH] HID: logitech-hidpp: Add PID for MX Anywhere 2
On Wed, Oct 21, 2020 at 06:56:12AM -0700, Harry Cutts wrote:
> It seems that the PID 0x4072 was missing from the list Logitech gave me
> for this mouse, as I found one with it in the wild (with which I tested
> this patch).
>
> Fixes: 4435ff2f09a2 ("HID: logitech: Enable high-resolution scrolling on
> Logitech mice")
> Signed-off-by: Harry Cutts
Acked-by: Peter Hutterer
we have the same PID for this device in libratbag so there must be some
truth to it ;)
Cheers,
Peter
> ---
>
> drivers/hid/hid-logitech-hidpp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index b8b53dc95e86b..730036650f7df 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -3947,6 +3947,7 @@ static const struct hid_device_id hidpp_devices[] = {
> LDJ_DEVICE(0x405e), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> { /* Mouse Logitech MX Anywhere 2 */
> LDJ_DEVICE(0x404a), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + { LDJ_DEVICE(0x4072), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> { LDJ_DEVICE(0xb013), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> { LDJ_DEVICE(0xb018), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> { LDJ_DEVICE(0xb01f), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> --
> 2.29.0.rc1.297.gfa9743e501-goog
>
BUG: unable to handle kernel paging request in bpf_trace_run3
Hello,
syzbot found the following issue on:
HEAD commit:9ff9b0d3 Merge tag 'net-next-5.10' of git://git.kernel.org..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=140e3e7850
kernel config: https://syzkaller.appspot.com/x/.config?x=d13c3fa80bc4bcc1
dashboard link: https://syzkaller.appspot.com/bug?extid=83aa762ef23b6f0d1991
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1411390790
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=130d331050
The issue was bisected to:
commit 9df1c28bb75217b244257152ab7d788bb2a386d0
Author: Matt Mullins
Date: Fri Apr 26 18:49:47 2019 +
bpf: add writable context for raw tracepoints
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=159e3e7850
final oops: https://syzkaller.appspot.com/x/report.txt?x=179e3e7850
console output: https://syzkaller.appspot.com/x/log.txt?x=139e3e7850
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+83aa762ef23b6f0d1...@syzkaller.appspotmail.com
Fixes: 9df1c28bb752 ("bpf: add writable context for raw tracepoints")
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
BUG: unable to handle page fault for address: c9e84030
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD aa67
P4D aa67
PUD aa1ee067
PMD a9074067
PTE 0
Oops: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 6879 Comm: syz-executor875 Not tainted 5.9.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:bpf_dispatcher_nop_func include/linux/bpf.h:644 [inline]
RIP: 0010:__bpf_trace_run kernel/trace/bpf_trace.c:2045 [inline]
RIP: 0010:bpf_trace_run3+0x145/0x3f0 kernel/trace/bpf_trace.c:2083
Code: f7 ff 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80
3c 02 00 0f 85 9f 02 00 00 48 8d 73 38 48 8d 7c 24 28 53 30 e8 c3 00 f7 ff
e8 fe 32 c3 06 31 ff 89 c3 89 c6 e8 13 fd
RSP: 0018:c90005457838 EFLAGS: 00010082
RAX: RBX: c9e84000 RCX: 817e37b0
RDX: RSI: c9e84038 RDI: c90005457860
RBP: 192000a8af08 R08: R09: 8d7149a7
R10: R11: R12: 0001
R13: 888092df4440 R14: 0001 R15: 8880a8f2e300
FS: 01666880() GS:8880ae40() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: c9e84030 CR3: 9d9ab000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
__bpf_trace_sched_switch+0xdc/0x120 include/trace/events/sched.h:138
__traceiter_sched_switch+0x64/0xb0 include/trace/events/sched.h:138
trace_sched_switch include/trace/events/sched.h:138 [inline]
__schedule+0x1197/0x2200 kernel/sched/core.c:4520
preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:4682
preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:40
vprintk_emit+0x2d7/0x6e0 kernel/printk/printk.c:2029
vprintk_func+0x8d/0x1e0 kernel/printk/printk_safe.c:393
printk+0xba/0xed kernel/printk/printk.c:2076
fail_dump lib/fault-inject.c:45 [inline]
should_fail+0x472/0x5a0 lib/fault-inject.c:146
should_failslab+0x5/0x10 mm/slab_common.c:1194
slab_pre_alloc_hook.constprop.0+0xf4/0x200 mm/slab.h:512
slab_alloc mm/slab.c:3300 [inline]
__do_kmalloc mm/slab.c:3655 [inline]
__kmalloc+0x6f/0x360 mm/slab.c:3666
kmalloc include/linux/slab.h:559 [inline]
allocate_probes kernel/tracepoint.c:58 [inline]
func_remove kernel/tracepoint.c:210 [inline]
tracepoint_remove_func kernel/tracepoint.c:297 [inline]
tracepoint_probe_unregister+0x1cf/0x890 kernel/tracepoint.c:382
bpf_raw_tp_link_release+0x51/0xa0 kernel/bpf/syscall.c:2734
bpf_link_free+0xe6/0x1b0 kernel/bpf/syscall.c:2327
bpf_link_put+0x15e/0x1b0 kernel/bpf/syscall.c:2353
bpf_link_release+0x33/0x40 kernel/bpf/syscall.c:2361
__fput+0x285/0x920 fs/file_table.c:281
task_work_run+0xdd/0x190 kernel/task_work.c:141
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_user_mode_loop kernel/entry/common.c:165 [inline]
exit_to_user_mode_prepare+0x20e/0x230 kernel/entry/common.c:192
syscall_exit_to_user_mode+0x7a/0x2c0 kernel/entry/common.c:267
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441509
Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
8b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffd2b2c6888 EFLAGS: 0246 ORIG_RAX: 0003
RAX: RBX: RCX: 00441509
RDX: fffd RSI: 0001 RDI: 0004
RBP: 7ffd2b2c68a0 R08: 0001 R09:
R10:
Re: [PATCH v2] usb: typec: Expose Product Type VDOs via sysfs
Thanks for reviewing the patch, Greg.
On Wed, Oct 21, 2020 at 11:56 PM Greg KH wrote:
>
> On Wed, Oct 21, 2020 at 11:15:54PM -0700, Prashant Malani wrote:
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-typec
> > b/Documentation/ABI/testing/sysfs-class-typec
> > index b834671522d6..16440a236b66 100644
> > --- a/Documentation/ABI/testing/sysfs-class-typec
> > +++ b/Documentation/ABI/testing/sysfs-class-typec
> > @@ -170,6 +170,14 @@ Description:
> > will show 0 until Discover Identity command result becomes
> > available. The value can be polled.
> >
> > +What:
> > /sys/class/typec/-partner/identity/product_type_vdo
> > +Date:October 2020
> > +Contact: Prashant Malani
> > +Description:
> > + Product Type VDOs part of Discover Identity command result. 3
> > values
> > + are displayed (for the 3 possible Product Type VDOs), one per
> > line.
>
> sysfs is "one value per file", not "one value per line". This is not
> ok.
I see. Would listing these out as three separate vdos (i.e vdo0, vdo1,
vdo2) be better?
>
> > + The values will show 0s until Discover Identity command
> > result becomes
> > + available. The values can be polled.
>
> It can be polled? Did you try that? I don't see the logic for that in
> your patch.
To be honest, no. I followed the pattern used by the other identity
VDOs (cert_stat, id_header and product),
and re-used their description assuming it to be accurate.
>
>
> >
> > USB Type-C cable devices (eg. /sys/class/typec/port0-cable/)
> >
> > @@ -230,6 +238,15 @@ Description:
> > will show 0 until Discover Identity command result becomes
> > available. The value can be polled.
> >
> > +What:
> > /sys/class/typec/-cable/identity/product_type_vdo
> > +Date:October 2020
> > +Contact: Prashant Malani
> > +Description:
> > + Product Type VDOs part of Discover Identity command result. 3
> > values
> > + are displayed (for the 3 possible Product Type VDOs), one per
> > line.
> > + The values will show 0s until Discover Identity command
> > result becomes
> > + available. The values can be polled.
>
> Why are you describing the same value in two different locations?
Both cable and partner can have Discover Identity VDOs and they are
listed separately in sysfs.
The other VDOs (id_header, cert_stat and product) have separate
descriptions for cable and partner too.
Perhaps there is a case for consolidating the listings here (factor
out the ones which are common to cable and partner).
>
> > +
> >
> > USB Type-C port alternate mode devices.
> >
> > diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> > index 35eec707cb51..37fa4501e75f 100644
> > --- a/drivers/usb/typec/class.c
> > +++ b/drivers/usb/typec/class.c
> > @@ -122,10 +122,20 @@ static ssize_t product_show(struct device *dev,
> > struct device_attribute *attr,
> > }
> > static DEVICE_ATTR_RO(product);
> >
> > +static ssize_t product_type_vdo_show(struct device *dev, struct
> > device_attribute *attr,
> > + char *buf)
> > +{
> > + struct usb_pd_identity *id = get_pd_identity(dev);
> > +
> > + return sprintf(buf, "0x%08x\n0x%08x\n0x%08x\n", id->vdo[0],
> > id->vdo[1], id->vdo[2]);
>
> Note, for future sysfs stuff, always use sysfs_emit().
>
> But again, this is not allowed as you have multiple values per a single
> file.
Noted. I will keep that in mind for future versions.
Best regards,
>
> thanks,
>
> greg k-h
[PATCH v3] firmware: gsmi: Drop the use of dma_pool_* API functions
GSMI driver uses dma_pool_* API functions for buffer allocation
because it requires that the SMI buffers are allocated within 32-bit
physical address space. However, this does not work well with IOMMU
since there is no real device and hence no domain associated with the
device.
Since this is not a real device, it does not require any device
address(IOVA) for the buffer allocations. The only requirement is to
ensure that the physical address allocated to the buffer is within
32-bit physical address space. This is because the buffers have
nothing to do with DMA at all. It is required for communication with
firmware executing in SMI mode which has access only to the bottom
4GiB of memory. Hence, this change switches to using a SLAB cache
created with SLAB_CACHE_DMA32 that guarantees that the allocation
happens from the DMA32 memory zone. All calls to dma_pool_* are
replaced with kmem_cache_*.
In addition to that, all the code for managing the dma_pool for GSMI
platform device is dropped.
Signed-off-by: Furquan Shaikh
Reviewed-by: Ard Biesheuvel
---
Changelog since v2:
- Dropped the check to ensure allocation done by kmem_cache_alloc is
below the 4GiB boundary since DMA32 memory zone guarantees that.
- Added Reviewed-by based on response from Ard.
Changelog since v1:
- Switched to using SLAB cache with SLAB_CACHE_DMA32.
- Added comment to code and commit message explaining the reason for
using DMA32 memory zone.
drivers/firmware/google/gsmi.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 7d9367b22010..3d77f26c1e8c 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -85,7 +84,6 @@
struct gsmi_buf {
u8 *start; /* start of buffer */
size_t length; /* length of buffer */
- dma_addr_t handle; /* dma allocation handle */
u32 address;/* physical address of buffer */
};
@@ -97,7 +95,7 @@ static struct gsmi_device {
spinlock_t lock;/* serialize access to SMIs */
u16 smi_cmd;/* SMI command port */
int handshake_type; /* firmware handler interlock type */
- struct dma_pool *dma_pool; /* DMA buffer pool */
+ struct kmem_cache *mem_pool;/* kmem cache for gsmi_buf allocations
*/
} gsmi_dev;
/* Packed structures for communicating with the firmware */
@@ -157,8 +155,7 @@ static struct gsmi_buf *gsmi_buf_alloc(void)
}
/* allocate buffer in 32bit address space */
- smibuf->start = dma_pool_alloc(gsmi_dev.dma_pool, GFP_KERNEL,
- &smibuf->handle);
+ smibuf->start = kmem_cache_alloc(gsmi_dev.mem_pool, GFP_KERNEL);
if (!smibuf->start) {
printk(KERN_ERR "gsmi: failed to allocate name buffer\n");
kfree(smibuf);
@@ -176,8 +173,7 @@ static void gsmi_buf_free(struct gsmi_buf *smibuf)
{
if (smibuf) {
if (smibuf->start)
- dma_pool_free(gsmi_dev.dma_pool, smibuf->start,
- smibuf->handle);
+ kmem_cache_free(gsmi_dev.mem_pool, smibuf->start);
kfree(smibuf);
}
}
@@ -914,9 +910,20 @@ static __init int gsmi_init(void)
spin_lock_init(&gsmi_dev.lock);
ret = -ENOMEM;
- gsmi_dev.dma_pool = dma_pool_create("gsmi", &gsmi_dev.pdev->dev,
-GSMI_BUF_SIZE, GSMI_BUF_ALIGN, 0);
- if (!gsmi_dev.dma_pool)
+
+ /*
+* SLAB cache is created using SLAB_CACHE_DMA32 to ensure that the
+* allocations for gsmi_buf come from the DMA32 memory zone. These
+* buffers have nothing to do with DMA. They are required for
+* communication with firmware executing in SMI mode which can only
+* access the bottom 4GiB of physical memory. Since DMA32 memory zone
+* guarantees allocation under the 4GiB boundary, this driver creates
+* a SLAB cache with SLAB_CACHE_DMA32 flag.
+*/
+ gsmi_dev.mem_pool = kmem_cache_create("gsmi", GSMI_BUF_SIZE,
+ GSMI_BUF_ALIGN,
+ SLAB_CACHE_DMA32, NULL);
+ if (!gsmi_dev.mem_pool)
goto out_err;
/*
@@ -1032,7 +1039,7 @@ static __init int gsmi_init(void)
gsmi_buf_free(gsmi_dev.param_buf);
gsmi_buf_free(gsmi_dev.data_buf);
gsmi_buf_free(gsmi_dev.name_buf);
- dma_pool_destroy(gsmi_dev.dma_pool);
+ kmem_cache_destroy(gsmi_dev.mem_pool);
platform_device_unregister(gsmi_dev.pdev);
pr_info("gsmi: failed to load: %d\n", ret);
#ifdef CONFIG_PM
@@ -1057,7 +106
Re: [PATCH v3 3/5] net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver
On 21.10.2020 23:49, Łukasz Stelmach wrote: > ASIX AX88796[1] is a versatile ethernet adapter chip, that can be > connected to a CPU with a 8/16-bit bus or with an SPI. This driver > supports SPI connection. > > The driver has been ported from the vendor kernel for ARTIK5[2] > boards. Several changes were made to adapt it to the current kernel > which include: > > + updated DT configuration, > + clock configuration moved to DT, > + new timer, ethtool and gpio APIs, > + dev_* instead of pr_* and custom printk() wrappers, > + removed awkward vendor power managemtn. > > [1] > https://www.asix.com.tw/products.php?op=pItemdetail&PItemID=104;65;86&PLine=65 > [2] > https://git.tizen.org/cgit/profile/common/platform/kernel/linux-3.10-artik/ > > The other ax88796 driver is for NE2000 compatible AX88796L chip. These > chips are not compatible. Hence, two separate drivers are required. > > Signed-off-by: Łukasz Stelmach coś zaszalałeś, jak dobry koreański kod - push bez kompilacji ;) drivers/net/ethernet/asix/ax88796c_main.c:758:13: error: static declaration of ‘ax88796c_set_csums’ follows non-static declaration static void ax88796c_set_csums(struct ax88796c_device *ax_local) ^ In file included from drivers/net/ethernet/asix/ax88796c_main.c:12:0: drivers/net/ethernet/asix/ax88796c_ioctl.h:24:6: note: previous declaration of ‘ax88796c_set_csums’ was here void ax88796c_set_csums(struct ax88796c_device *ax_local); ^ scripts/Makefile.build:283: recipe for target 'drivers/net/ethernet/asix/ax88796c_main.o' failed make[4]: *** [drivers/net/ethernet/asix/ax88796c_main.o] Error 1 scripts/Makefile.build:500: recipe for target 'drivers/net/ethernet/asix' failed make[3]: *** [drivers/net/ethernet/asix] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/net/ethernet' failed make[2]: *** [drivers/net/ethernet] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/net' failed make[1]: *** [drivers/net] Error 2 > ... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
Le 22/10/2020 à 05:23, Finn Thain a écrit : > On Wed, 21 Oct 2020, Laurent Vivier wrote: > >> Le 21/10/2020 à 01:43, Finn Thain a écrit : >> >>> Laurent, can we avoid the irq == 0 warning splat like this? >>> >>> diff --git a/drivers/tty/serial/pmac_zilog.c >>> b/drivers/tty/serial/pmac_zilog.c >>> index 96e7aa479961..7db600cd8cc7 100644 >>> --- a/drivers/tty/serial/pmac_zilog.c >>> +++ b/drivers/tty/serial/pmac_zilog.c >>> @@ -1701,8 +1701,10 @@ static int __init pmz_init_port(struct >>> uart_pmac_port *uap) >>> int irq; >>> >>> r_ports = platform_get_resource(uap->pdev, IORESOURCE_MEM, 0); >>> + if (!r_ports) >>> + return -ENODEV; >>> irq = platform_get_irq(uap->pdev, 0); >>> - if (!r_ports || irq <= 0) >>> + if (irq <= 0) >>> return -ENODEV; >>> >>> uap->port.mapbase = r_ports->start; >>> >> >> No, this doesn't fix the problem. >> > > Then I had better stop guessing and start up Aranym... > > The patch below seems to fix the problem for me. Does it work on your > system(s)? It works like a charm. Thank you, Laurent
Re: [PATCH v2] usb: typec: Expose Product Type VDOs via sysfs
On Thu, Oct 22, 2020 at 12:13:54AM -0700, Prashant Malani wrote: > Thanks for reviewing the patch, Greg. > > On Wed, Oct 21, 2020 at 11:56 PM Greg KH wrote: > > > > On Wed, Oct 21, 2020 at 11:15:54PM -0700, Prashant Malani wrote: > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-typec > > > b/Documentation/ABI/testing/sysfs-class-typec > > > index b834671522d6..16440a236b66 100644 > > > --- a/Documentation/ABI/testing/sysfs-class-typec > > > +++ b/Documentation/ABI/testing/sysfs-class-typec > > > @@ -170,6 +170,14 @@ Description: > > > will show 0 until Discover Identity command result becomes > > > available. The value can be polled. > > > > > > +What: > > > /sys/class/typec/-partner/identity/product_type_vdo > > > +Date:October 2020 > > > +Contact: Prashant Malani > > > +Description: > > > + Product Type VDOs part of Discover Identity command result. > > > 3 values > > > + are displayed (for the 3 possible Product Type VDOs), one > > > per line. > > > > sysfs is "one value per file", not "one value per line". This is not > > ok. > > I see. Would listing these out as three separate vdos (i.e vdo0, vdo1, > vdo2) be better? Given that your current implementation is not acceptable, something has to change :) thanks, greg k-h
Re: [PATCH v2 05/15] perf session: introduce decompressor into trace reader object
On 22.10.2020 7:36, Namhyung Kim wrote: > On Thu, Oct 22, 2020 at 1:00 AM Alexey Budankov > wrote: >> >> >> Introduce decompressor to trace reader object so that decompression >> could be executed on per trace file basis separately for every >> trace file located in trace directory. > > I'm slightly uncomfortable with the word 'trace' here as it's > used for other cases like perf trace and ftrace. Maybe we can > change it to 'profile' and/or 'data file'? Let's use "data file" and "data directory" terms then. Thanks, Alexei
Re: [PATCH] ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead of selecting it
Hi Ted,
On Thu, Oct 22, 2020 at 5:43 AM Theodore Y. Ts'o wrote:
> On Wed, Oct 21, 2020 at 04:07:15PM -0700, Randy Dunlap wrote:
> > > I'm don't particularly care how this gets achieved, but please think
> > > about how to make it easy for a kernel developer to run a specific set
> > > of subsystem unit tests. (In fact, being able to do something like
> > > "kunit.py run fs/ext4 fs/jbd2" or maybe "kunit.py run fs/..." would be
> > > *great*. No need to fuss with hand editing the .kunitconfig file at
> > > all would be **wonderful**.
> >
> > I understand the wish for ease of use, but this is still the tail
> > wagging the dog.
> >
> > The primary documentation for 'select' is
> > Documentation/kbuild/kconfig-language.rst, which says:
> >
> > Note:
> > select should be used with care. select will force
> > a symbol to a value without visiting the dependencies.
> > By abusing select you are able to select a symbol FOO even
> > if FOO depends on BAR that is not set.
> > In general use select only for non-visible symbols
> > (no prompts anywhere) and for symbols with no dependencies.
> > That will limit the usefulness but on the other hand avoid
> > the illegal configurations all over.
> >
>
> Well, the KUNIT configs are kinda of a special case, since normally
Please read "Why my CONFIG symbol is (not) special?"...
> they don't have a lot of huge number of dependencies, since unit tests
They still depend on the feature under test, which may not be enabled.
> in general are not integration tests. So ideally, dependencies will
> mostly be replaced with mocking functions. And if there are *real*
> dependencies that the Kunit Unit tests need, they can be explicitly
> pulled in with selects.
While I'm a strong supporter of testing, this select is what I object
to, as it forces the enablement of features that were not enabled in
your kernel in the first place.
> That being said, as I said, I'm not picky about *how* this gets
> achieved. But ease of use is a key part of making people more likely
> to run the unit tests. So another way of solving the problem might be
> to put some kind of automated dependency solver into kunit.py, or some
> way of manually adding the necessary dependencies in some kind of
> Kunitconfig file that are in directories where their are Unit tests,
> or maybe some kind of extenstion to the Kconfig file. My main
> requirement is that the only thing that should be necessary for
> enabling the ext4 Kunit tests should be adding a single line to the
> .kunitconfig file. It's not fair to make the human developer manually
> have to figure out the dependency chains.
If you want to test e.g. EXT4, sure you know you should enable EXT4?
If you don't enable feature FOO in your kernel. why would you be
interested in testing feature FOO? Unless you want to test everything,
and you might as well run an allmodconfig kernel.
> As far as I'm concerned, ease of use is important enough to justfy
> special casing and/or bending the rules as far as "select" is concered
> for Kunit-related CONFIG items. But if someone else want to suggest a
> better approach, I'm all ears.
Providing .config snippets containing both the CONFIG_FOO_KUNIT_TESTS
and CONFIG_FOO symbols set (and other dependencies, if needed) could
provide this, and would also be useful in documenting CONFIG_FOO has a
corresponding tests.
As kunit can be modular, and most tests can be modular too, I can build
all tests relevant for my system as modules. Hence they are available
when the need to run them ever arises, while there is no further impact
on my system. This use case also seems to be supported by
CONFIG_KUNIT_ALL_TESTS:
config KUNIT_ALL_TESTS
tristate "All KUnit tests with satisfied dependencies"
help
Enables all KUnit tests, if they can be enabled.
However, this no longer works if this suddenly starts enabling random
features in my kernel, which was the case for EXT4_KUNIT_TESTS
and MPTCP_KUNIT_TESTS (enables MPTCP, and IPV6!).
While ext4 is ubiquitous (I did have it enabled ;-) and may be
considered common on all systems (it is not: e.g. embedded systems with
JFFS do not need EXT4 enabled), this is surely not the case for other
features with tests, and won't be the case for all features that will
receive kunit tests in the future.
Thanks for your understanding!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH v2 3/3] ARM: dts: add ehci uhci enable in evb dts
> -Original Message- > From: Andrew Jeffery > Sent: Thursday, October 22, 2020 7:45 AM > To: Ryan Chen ; Sergei Shtylyov > ; Joel Stanley ; > linux-arm-ker...@lists.infradead.org; linux-asp...@lists.ozlabs.org; > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; BMC-SW > ; Alan Stern > Subject: Re: [PATCH v2 3/3] ARM: dts: add ehci uhci enable in evb dts > > Hi Ryan, > > On Mon, 12 Oct 2020, at 11:13, Ryan Chen wrote: > > Hello Segei, > > > > > -Original Message- > > > From: Sergei Shtylyov > > > Sent: Friday, October 9, 2020 4:23 PM > > > To: Ryan Chen ; Joel Stanley > > > ; Andrew Jeffery ; > > > linux-arm-ker...@lists.infradead.org; > > > linux-asp...@lists.ozlabs.org; linux-kernel@vger.kernel.org; > > > linux-...@vger.kernel.org; BMC-SW ; Alan > > > Stern > > > Subject: Re: [PATCH v2 3/3] ARM: dts: add ehci uhci enable in evb > > > dts > > > > > > HEllo! > > > > > > On 09.10.2020 5:49, Ryan Chen wrote: > > > > > > > Add EHCI UHCI enable build in aspeed-ast2600-evb.dts > > > > > > Enable ECHI/UHCI for the Aspeed AST2600 EVB, perhaps? > > > > > > > Yes, it is enable for AST2600 EVB. > > I think Sergei was suggesting you change the wording of the commit message. > Thanks, will resend the patch with modification.
Re: [PATCH 4/5] RISC-V: Protect .init.text & .init.data
On Thu, Oct 22, 2020 at 10:33 AM Anup Patel wrote:
>
> On Thu, Oct 22, 2020 at 7:01 AM Atish Patra wrote:
> >
> > On Fri, Oct 16, 2020 at 11:24 AM Atish Patra wrote:
> > >
> > > On Tue, Oct 13, 2020 at 10:24 PM Atish Patra
> > > wrote:
> > > >
> > > > On Tue, Oct 13, 2020 at 6:21 PM Jim Wilson wrote:
> > > > >
> > > > > On Tue, Oct 13, 2020 at 3:25 PM Atish Patra
> > > > > wrote:
> > > > > > This happens only when copy_from_user is called from function that
> > > > > > is
> > > > > > annotated with __init.
> > > > > > Adding Kito & Jim for their input
> > > > > >
> > > > > > @kito, @Jim: Please let me know if I should create a issue in
> > > > > > riscv-gnu-toolchain repo or somewhere else.
> > > > >
> > > > > I can't do anything useful without a testcase that I can use to
> > > > > reproduce the problem. The interactions here are complex, so pointing
> > > > > at lines of code or kernel config options doesn't give me any useful
> > > > > info.
> > > > >
> > > > > Relaxation can convert calls to a jal. I don't know of any open bugs
> > > > > in this area that can generate relocation errors. if it is a
> > > > > relaxation error then turning off relaxation should work around the
> > > > > problem as you suggested.
> > > > >
> > > > > A kernel build problem is serious. I think this is worth a bug
> > > > > report. FSF binutils or riscv-gnu-toolchain is fine.
> > > > >
> > > >
> > > > I have created an issue with detailed descriptions and reproduction
> > > > steps.
> > > > Please let me know if you need anything else.
> > > >
> > >
> > > It may be a toolchain issue. Here is the ongoing discussion in case
> > > anybody else is interested.
> > >
> > > https://github.com/riscv/riscv-gnu-toolchain/issues/738
> > >
> > > > > Jim
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Atish
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Atish
> >
> > Thanks to Jim, we know the cause now. Jim has provided an excellent
> > analysis of the issue in the github issue report.
> > https://github.com/riscv/riscv-gnu-toolchain/issues/738
> >
> > To summarize, the linker relaxation code is not aware of the
> > alignments between sections.
> > That's why it relaxes the calls from .text to .init.text and converts
> > a auipc+jalr pair to jal even if the address can't be fit +/- 1MB.
> >
> > There are few ways we can solve this problem.
> >
> > 1. As per Jim's suggestion, linker relaxation code is aware of the
> > section alignments. We can mark .init.text as a 2MB aligned section.
> >For calls within a section, section's alignment will be used in the
> > calculation. For calls across sections, e.g. from .init.text to .text,
> > the maximum
> >section alignment of every section will be used. Thus, all
> > relaxation within .init.text and between any sections will be
> > impacted.
> >Thus, it avoids the error but results in the following increase in
> > size of various sections.
> > section change in size (in bytes)
> > .head.text +4
> > .text +40
> > .init.text.+6530
> > .exit.text+84
> >
> > The only significant increase is .init.text but it is freed after
> > boot. Thus, I don't see any significant performance degradation due to
> > that.
> >
> > Here is the diff
> > --- a/arch/riscv/kernel/vmlinux.lds.S
> > +++ b/arch/riscv/kernel/vmlinux.lds.S
> > @@ -51,7 +51,13 @@ SECTIONS
> > . = ALIGN(SECTION_ALIGN);
> > __init_begin = .;
> > __init_text_begin = .;
> > - INIT_TEXT_SECTION(PAGE_SIZE)
> > + . = ALIGN(PAGE_SIZE); \
> > + .init.text : AT(ADDR(.init.text) - LOAD_OFFSET)
> > ALIGN(SECTION_ALIGN) { \
> > + _sinittext = .; \
> > + INIT_TEXT \
> > + _einittext = .; \
> > + }
> > +
> > . = ALIGN(8);
> > __soc_early_init_table : {
> > __soc_early_init_table_start = .;
> >
> > 2. We will continue to keep head.txt & .init.text together before
> > .text. However, we will map the pages that contain head & init.text at
> > page
> > granularity so that .head.text and init.text can have different
> > permissions. I have not measured the performance impact of this but it
> > won't
> > too bad given that the combined size of sections .head.txt &
> > .init.text is 200K. So we are talking about page level permission only
> > for
> > ~50 pages during boot.
> >
> > 3. Keep head.text in a separate 2MB aligned section. .init.text will
> > follow .head.text in its own section as well. This increases the
> > kernel
> > size by 2MB for MMU kernels. For nommu case, it will only increase
> > by 64 bytes due to smaller section alignment for nommu kernels.
> >
> > Both solutions 1 & 2 come at minimal performance on boot time while
> > solution 3 comes at in
Re: [PATCH v2] usb: typec: Expose Product Type VDOs via sysfs
Hi Greg, On Thu, Oct 22, 2020 at 12:17 AM Greg KH wrote: > > > > > +What: > > > > /sys/class/typec/-partner/identity/product_type_vdo > > > > +Date:October 2020 > > > > +Contact: Prashant Malani > > > > +Description: > > > > + Product Type VDOs part of Discover Identity command > > > > result. 3 values > > > > + are displayed (for the 3 possible Product Type VDOs), one > > > > per line. > > > > > > sysfs is "one value per file", not "one value per line". This is not > > > ok. > > > > I see. Would listing these out as three separate vdos (i.e vdo0, vdo1, > > vdo2) be better? > > Given that your current implementation is not acceptable, something has > to change :) Got it. I'd like to see if Heikki has any suggestions on naming these entries better. Thanks again and best regards, -Prashant > > thanks, > > greg k-h
[PATCH] arm64: dts: imx8m: use generic name for tmu
From: Peng Fan
Per devicetree specification, generic names are recommended
to be used, such as temperature-sensor.
Signed-off-by: Peng Fan
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index b83f400def8b..327f1d44ced9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -404,7 +404,7 @@ gpio5: gpio@3024 {
gpio-ranges = <&iomuxc 0 119 30>;
};
- tmu: tmu@3026 {
+ tmu: temperature-sensor@3026 {
compatible = "fsl,imx8mm-tmu";
reg = <0x3026 0x1>;
clocks = <&clk IMX8MM_CLK_TMU_ROOT>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 746faf1cf2fb..994fcb021b8f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -311,7 +311,7 @@ gpio5: gpio@3024 {
gpio-ranges = <&iomuxc 0 119 30>;
};
- tmu: tmu@3026 {
+ tmu: temperature-sensor@3026 {
compatible = "fsl,imx8mn-tmu", "fsl,imx8mm-tmu";
reg = <0x3026 0x1>;
clocks = <&clk IMX8MN_CLK_TMU_ROOT>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 6038f66aefc1..2a16016b1cf4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -288,7 +288,7 @@ gpio5: gpio@3024 {
gpio-ranges = <&iomuxc 0 114 30>;
};
- tmu: tmu@3026 {
+ tmu: temperature-sensor@3026 {
compatible = "fsl,imx8mp-tmu";
reg = <0x3026 0x1>;
clocks = <&clk IMX8MP_CLK_TSENSOR_ROOT>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 5e0e7d0f1bc4..ab57839a3de1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -420,7 +420,7 @@ gpio5: gpio@3024 {
gpio-ranges = <&iomuxc 0 119 30>;
};
- tmu: tmu@3026 {
+ tmu: temperature-sensor@3026 {
compatible = "fsl,imx8mq-tmu";
reg = <0x3026 0x1>;
interrupts = ;
--
2.28.0
Re: [PATCH v6 22/25] x86/asm: annotate indirect jumps
On Wed, Oct 21, 2020 at 04:27:47PM -0500, Josh Poimboeuf wrote: > On Wed, Oct 21, 2020 at 11:32:13AM +0200, Peter Zijlstra wrote: > > On Wed, Oct 21, 2020 at 10:56:06AM +0200, Peter Zijlstra wrote: > > > > > I do not see these in particular, although I do see a lot of: > > > > > > "sibling call from callable instruction with modified stack frame" > > > > defconfig-build/vmlinux.o: warning: objtool: msr_write()+0x10a: sibling > > call from callable instruction with modified stack frame > > defconfig-build/vmlinux.o: warning: objtool: msr_write()+0x99: (branch) > > defconfig-build/vmlinux.o: warning: objtool: msr_write()+0x3e: (branch) > > defconfig-build/vmlinux.o: warning: objtool: msr_write()+0x0: <=== (sym) > > > > $ nm defconfig-build/vmlinux.o | grep msr_write > > 00043250 t msr_write > > 004289c0 T msr_write > > 3056 t msr_write.cold > > > > Below 'fixes' it. So this is also caused by duplicate symbols. > > There's a new linker flag for renaming duplicates: > > https://sourceware.org/bugzilla/show_bug.cgi?id=26391 > > But I guess that doesn't help us now. Well, depends a bit if clang can do it; we only need this for LTO builds for now. > I don't have access to GCC 10 at the moment so I can't recreate it. > Does this fix it? Doesn't seem to do the trick :/ I'll try and have a poke later.
sound/soc/intel/catpt/dsp.c:359:9: sparse: sparse: restricted pci_power_t degrades to integer
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f804b3159482eedbb4250b1e9248c308fb63b805
commit: 6cbfa11d2694b8a1e46d6834fb9705d5589e3ef1 ASoC: Intel: Select catpt and
deprecate haswell
date: 3 weeks ago
config: i386-randconfig-s002-20201022 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6cbfa11d2694b8a1e46d6834fb9705d5589e3ef1
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 6cbfa11d2694b8a1e46d6834fb9705d5589e3ef1
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> sound/soc/intel/catpt/dsp.c:359:9: sparse: sparse: restricted pci_power_t
>> degrades to integer
sound/soc/intel/catpt/dsp.c:372:9: sparse: sparse: restricted pci_power_t
degrades to integer
sound/soc/intel/catpt/dsp.c:423:9: sparse: sparse: restricted pci_power_t
degrades to integer
sound/soc/intel/catpt/dsp.c:447:9: sparse: sparse: restricted pci_power_t
degrades to integer
vim +359 sound/soc/intel/catpt/dsp.c
ba202a7bc3da05 Cezary Rojewski 2020-09-29 343
ba202a7bc3da05 Cezary Rojewski 2020-09-29 344 int lpt_dsp_power_down(struct
catpt_dev *cdev)
ba202a7bc3da05 Cezary Rojewski 2020-09-29 345 {
ba202a7bc3da05 Cezary Rojewski 2020-09-29 346 catpt_dsp_reset(cdev,
true);
ba202a7bc3da05 Cezary Rojewski 2020-09-29 347
ba202a7bc3da05 Cezary Rojewski 2020-09-29 348 /* set 24Mhz clock for
both SSPs */
ba202a7bc3da05 Cezary Rojewski 2020-09-29 349
catpt_updatel_shim(cdev, CS1, CATPT_CS_SBCS(0) | CATPT_CS_SBCS(1),
ba202a7bc3da05 Cezary Rojewski 2020-09-29 350
CATPT_CS_SBCS(0) | CATPT_CS_SBCS(1));
ba202a7bc3da05 Cezary Rojewski 2020-09-29 351
catpt_dsp_select_lpclock(cdev, true, false);
ba202a7bc3da05 Cezary Rojewski 2020-09-29 352
ba202a7bc3da05 Cezary Rojewski 2020-09-29 353 /* DRAM power gating
all */
ba202a7bc3da05 Cezary Rojewski 2020-09-29 354
catpt_dsp_set_srampge(cdev, &cdev->dram, cdev->spec->dram_mask,
ba202a7bc3da05 Cezary Rojewski 2020-09-29 355
cdev->spec->dram_mask);
ba202a7bc3da05 Cezary Rojewski 2020-09-29 356
catpt_dsp_set_srampge(cdev, &cdev->iram, cdev->spec->iram_mask,
ba202a7bc3da05 Cezary Rojewski 2020-09-29 357
cdev->spec->iram_mask);
ba202a7bc3da05 Cezary Rojewski 2020-09-29 358
ba202a7bc3da05 Cezary Rojewski 2020-09-29 @359 catpt_updatel_pci(cdev,
PMCS, PCI_PM_CTRL_STATE_MASK, PCI_D3hot);
ba202a7bc3da05 Cezary Rojewski 2020-09-29 360 /* give hw time to drop
off */
ba202a7bc3da05 Cezary Rojewski 2020-09-29 361 udelay(50);
ba202a7bc3da05 Cezary Rojewski 2020-09-29 362
ba202a7bc3da05 Cezary Rojewski 2020-09-29 363 return 0;
ba202a7bc3da05 Cezary Rojewski 2020-09-29 364 }
ba202a7bc3da05 Cezary Rojewski 2020-09-29 365
:: The code at line 359 was first introduced by commit
:: ba202a7bc3da05ca4548c7247f9be769b4e8c9fa ASoC: Intel: catpt: Define DSP
operations
:: TO: Cezary Rojewski
:: CC: Mark Brown
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
Hi Finn,
On Thu, Oct 22, 2020 at 5:23 AM Finn Thain wrote:
> The patch below seems to fix the problem for me. Does it work on your
> system(s)?
Thanks for your patch!
> --- a/arch/m68k/mac/config.c
> +++ b/arch/m68k/mac/config.c
> @@ -776,16 +776,12 @@ static struct resource scc_b_rsrcs[] = {
> struct platform_device scc_a_pdev = {
> .name = "scc",
> .id = 0,
> - .num_resources = ARRAY_SIZE(scc_a_rsrcs),
> - .resource = scc_a_rsrcs,
> };
> EXPORT_SYMBOL(scc_a_pdev);
>
> struct platform_device scc_b_pdev = {
> .name = "scc",
> .id = 1,
> - .num_resources = ARRAY_SIZE(scc_b_rsrcs),
> - .resource = scc_b_rsrcs,
> };
> EXPORT_SYMBOL(scc_b_pdev);
>
> @@ -812,10 +808,15 @@ static void __init mac_identify(void)
>
> /* Set up serial port resources for the console initcall. */
>
> - scc_a_rsrcs[0].start = (resource_size_t) mac_bi_data.sccbase + 2;
> - scc_a_rsrcs[0].end = scc_a_rsrcs[0].start;
> - scc_b_rsrcs[0].start = (resource_size_t) mac_bi_data.sccbase;
> - scc_b_rsrcs[0].end = scc_b_rsrcs[0].start;
> + scc_a_rsrcs[0].start = (resource_size_t)mac_bi_data.sccbase + 2;
> + scc_a_rsrcs[0].end = scc_a_rsrcs[0].start;
> + scc_a_pdev.num_resources = ARRAY_SIZE(scc_a_rsrcs);
> + scc_a_pdev.resource = scc_a_rsrcs;
> +
> + scc_b_rsrcs[0].start = (resource_size_t)mac_bi_data.sccbase;
> + scc_b_rsrcs[0].end = scc_b_rsrcs[0].start;
> + scc_b_pdev.num_resources = ARRAY_SIZE(scc_b_rsrcs);
> + scc_b_pdev.resource = scc_b_rsrcs;
I can't say I'm a fan of this...
>
> switch (macintosh_config->scc_type) {
> case MAC_SCC_PSC:
> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
> index 96e7aa479961..95abdb305d67 100644
> --- a/drivers/tty/serial/pmac_zilog.c
> +++ b/drivers/tty/serial/pmac_zilog.c
> @@ -1697,18 +1697,17 @@ extern struct platform_device scc_a_pdev, scc_b_pdev;
The real issue is this "extern struct platform_device scc_a_pdev, scc_b_pdev",
circumventing the driver framework.
Can we get rid of that?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote: > Hi, > > There is a problem with glibc+systemd on BTI enabled systems. Systemd > has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny > PROT_EXEC changes. Glibc enables BTI only on segments which are marked as > being BTI compatible by calling mprotect PROT_EXEC|PROT_BTI. That call is > caught by the seccomp filter, resulting in service failures. > > So, at the moment one has to pick either denying PROT_EXEC changes, or BTI. > This is obviously not desirable. > > Various changes have been suggested, replacing the mprotect with mmap calls > having PROT_BTI set on the original mapping, re-mmapping the segments, > implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set, > and various modification to seccomp to allow particular mprotect cases to > bypass the filters. In each case there seems to be an undesirable attribute > to the solution. > > So, whats the best solution? Did you see Topi's comments on the systemd issue? https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 I think I agree with this: it's a bit weird to alter the bits after the fact. Can't glibc set up everything right from the begining? That would keep both concepts working. Lennart -- Lennart Poettering, Berlin
[PATCH net RFC] net: Clear IFF_TX_SKB_SHARING for all Ethernet devices using skb_padto
The ether_setup function adds the IFF_TX_SKB_SHARING flag to the
device. This flag indicates that it is safe to transmit shared skbs to
the device.
However, this is not true for many Ethernet devices. Many Ethernet
drivers would call skb_pad or skb_padto on the transmission path,
which modify the skb. So it would not be safe to transmit shared skbs to
these devices.
I grepped "skb_padto" under "drivers/net/ethernet", and attempted to fix
all drivers that show up, by clearing the IFF_TX_SKB_SHARING flag for
them.
This patch only tries to fix drivers under "drivers/net/ethernet" that
use "skb_padto". There are other drivers in the kernel also need to be
fixed. It's hard for me to cover all because they are too many.
Another simpler solution is to simply remove IFF_TX_SKB_SHARING from
ether_setup. That would solve all problems and may also make the code
cleaner. So I'm not sure this patch is the best solution. This is why
I'm sending this as a RFC.
For any source file that calls "skb_padto", I searched "alloc_etherdev"
in it. Once found, I added the flag clearing code after it.
Some files that call "skb_padto" don't have "alloc_etherdev" in it,
because the dev is allocated in other files in the same directory.
These files include:
1. drivers/net/ethernet/natsemi/sonic.c:
skb_padto called in sonic_send_packet.
sonic_send_packet is used in xtsonic.c, macsonic.c, jazzsonic.c.
2. drivers/net/ethernet/arc/emac_main.c:
skb_padto called in arc_emac_tx.
arc_emac_tx is used as arc_emac_netdev_ops.ndo_start_xmit.
arc_emac_netdev_ops is used in arc_emac_probe.
arc_emac_probe is used in emac_rockchip.c and emac_arc.c.
Also, the following file is skipped because I couldn't find the
corresponding dev allocation code.
drivers/net/ethernet/i825xx/lib82596.c:
skb_padto called in i596_start_xmit.
i596_start_xmit is used as i596_netdev_ops.ndo_start_xmit.
i596_netdev_ops is used in i82596_probe.
i82596_probe is used nowhere in this file,
and because it is a static function, it cannot be used anywhere else.
Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing
IFF_TX_SKB_SHARING cleared")
Cc: Neil Horman
Cc: Jakub Kicinski
Cc: David S. Miller
Signed-off-by: Xie He
---
drivers/net/ethernet/adaptec/starfire.c | 2 ++
drivers/net/ethernet/amd/a2065.c | 2 ++
drivers/net/ethernet/amd/ariadne.c| 2 ++
drivers/net/ethernet/amd/atarilance.c | 3 +++
drivers/net/ethernet/amd/declance.c | 2 ++
drivers/net/ethernet/amd/lance.c | 5 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 2 ++
drivers/net/ethernet/arc/emac_arc.c | 3 +++
drivers/net/ethernet/arc/emac_rockchip.c | 3 +++
drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 3 +++
drivers/net/ethernet/i825xx/82596.c | 2 ++
drivers/net/ethernet/i825xx/ether1.c | 2 ++
drivers/net/ethernet/intel/igc/igc_main.c | 2 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 ++
drivers/net/ethernet/marvell/skge.c | 2 ++
drivers/net/ethernet/natsemi/jazzsonic.c | 2 ++
drivers/net/ethernet/natsemi/macsonic.c | 2 ++
drivers/net/ethernet/natsemi/xtsonic.c| 2 ++
drivers/net/ethernet/packetengines/yellowfin.c| 2 ++
drivers/net/ethernet/seeq/ether3.c| 2 ++
drivers/net/ethernet/seeq/sgiseeq.c | 2 ++
drivers/net/ethernet/sis/sis190.c | 2 ++
drivers/net/ethernet/smsc/epic100.c | 2 ++
drivers/net/ethernet/smsc/smc9194.c | 2 ++
drivers/net/ethernet/sun/cassini.c| 3 +++
drivers/net/ethernet/ti/cpmac.c | 2 ++
drivers/net/ethernet/ti/cpsw.c| 4
drivers/net/ethernet/ti/cpsw_new.c| 2 ++
drivers/net/ethernet/ti/davinci_emac.c| 2 ++
drivers/net/ethernet/ti/netcp_core.c | 2 ++
drivers/net/ethernet/ti/tlan.c| 3 +++
drivers/net/ethernet/via/via-rhine.c | 3 +++
drivers/net/ethernet/via/via-velocity.c | 2 ++
drivers/net/ethernet/xircom/xirc2ps_cs.c | 3 +++
34 files changed, 81 insertions(+)
diff --git a/drivers/net/ethernet/adaptec/starfire.c
b/drivers/net/ethernet/adaptec/starfire.c
index 555299737b51..66c2a29d736f 100644
--- a/drivers/net/ethernet/adaptec/starfire.c
+++ b/drivers/net/ethernet/adaptec/starfire.c
@@ -655,16 +655,18 @@ static int starfire_init_one(struct pci_dev *pdev,
dev_err(d, "no PCI MEM resources, aborting\n");
return -ENODEV;
}
dev = alloc_etherdev(sizeof(*np));
if (!dev)
return -ENOMEM;
+ dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+
SET_NETDEV_DEV(dev, &pdev->dev);
irq = pdev->irq;
if (pci_request_regions (pdev, DRV_NAME)) {
dev_err(d, "cannot reserve PCI resources, aborting\n");
Re: [PATCH 1/1] video: fbdev: fix divide error in fbcon_switch
Hi
On 22.10.20 01:57, saeed.mirzamohamm...@oracle.com wrote:
> From: Saeed Mirzamohammadi
>
> This patch fixes the issue due to:
>
> [ 89.572883] divide_error: [#1] SMP KASAN PTI
> [ 89.572897] CPU: 3 PID: 16083 Comm: repro Not tainted
> 5.9.0-rc7.20200930.rc1.allarch-19-g3e32d0d.syzk #5
> [ 89.572902] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 0.5.1 01/01/2011
> [ 89.572934] RIP: 0010:cirrusfb_check_var+0x84/0x1260
>
> The error happens when the pixels value is calculated before performing the
> sanity checks on bits_per_pixel.
> A bits_per_pixel set to zero causes divide by zero error.
>
> This patch moves the calculation after the sanity check.
>
> Signed-off-by: Saeed Mirzamohammadi
> Tested-by: Saeed Mirzamohammadi
Looks good, thanks a lot. I'll add the patch to drm-misc-next
Reviewed-by: Thomas Zimemrmann
Best regards
Thomas
> ---
> drivers/video/fbdev/cirrusfb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c
> index 15a9ee7cd734..a7749101b094 100644
> --- a/drivers/video/fbdev/cirrusfb.c
> +++ b/drivers/video/fbdev/cirrusfb.c
> @@ -531,7 +531,7 @@ static int cirrusfb_check_var(struct fb_var_screeninfo
> *var,
> {
> int yres;
> /* memory size in pixels */
> - unsigned pixels = info->screen_size * 8 / var->bits_per_pixel;
> + unsigned int pixels;
> struct cirrusfb_info *cinfo = info->par;
>
> switch (var->bits_per_pixel) {
> @@ -573,6 +573,7 @@ static int cirrusfb_check_var(struct fb_var_screeninfo
> *var,
> return -EINVAL;
> }
>
> + pixels = info->screen_size * 8 / var->bits_per_pixel;
> if (var->xres_virtual < var->xres)
> var->xres_virtual = var->xres;
> /* use highest possible virtual resolution */
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Re: [RFC] Have insn decoder functions return success/failure
On Wed, 21 Oct 2020 18:45:58 +0200
Borislav Petkov wrote:
> On Wed, Oct 21, 2020 at 11:26:13PM +0900, Masami Hiramatsu wrote:
> > Hmm, I meant someone might think it can be used for filtering the
> > instruction something like,
> >
> > insn_init(insn, buf, buflen, 1);
> > ret = insn_get_length(insn);
> > if (!ret) {
> > /* OK, this is safe */
> > patch_text(buf, trampoline);
> > }
> >
> > No, we need another validator for such usage.
>
> Well, I think calling insn_get_length() should give you only the
> *length* of the insn and nothing else - I mean that is what the function
> is called. And I believe current use is wrong.
>
> Examples:
>
> arch/x86/kernel/kprobes/core.c:
> insn_get_length(&insn);
>
> /*
> * Another debugging subsystem might insert this breakpoint.
> * In that case, we can't recover it.
> */
> if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
>
> So this has called get_length but it is far from clear that after that
> call, the opcode bytes in insn.opcode.bytes are there.
No, insn_get_length() implies it decodes whole of the instruction.
(yeah, we need an alias of that, something like insn_get_complete())
>
> What that should do instead IMO is this:
>
> insn_get_opcode(&insn);
>
No, you've cut the last lines of that loop.
/*
* Another debugging subsystem might insert this breakpoint.
* In that case, we can't recover it.
*/
if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
return 0;
addr += insn.length;
}
I need insn.length too. Of course we can split it into 2 calls. But
as I said, since the insn_get_length() implies it decodes all other
parts, I just called it once.
> and *then* the return value can tell you whether the opcode bytes were
> parsed properly or not. See what I mean?
I agreed to check the return value of insn_get_length() at that point
only for checking whether the instruction parsing was failed or not.
>
> That's even documented that way:
>
> /**
> * insn_get_opcode - collect opcode(s)
> * @insn: &struct insn containing instruction
> *
> * Populates @insn->opcode, updates @insn->next_byte to point past the
> * opcode byte(s), and set @insn->attr (except for groups).
>
>
> Similarly here:
>
> static enum es_result vc_decode_insn(struct es_em_ctxt *ctxt)
>
> ...
>
> insn_get_length(&ctxt->insn);
>
> ret = ctxt->insn.immediate.got ? ES_OK : ES_DECODE_FAILED;
>
> that thing wants to decode the insn but it is looking whether it parsed
> an *immediate*?!
Hm, it is better to call insn_get_immediate() if it doesn't use length later.
>
> I'm not saying this is necessarily wrong - just the naming nomenclature
> and the API should be properly defined when you call a function of the
> insn decoder, what you are guaranteed to get and what a caller can
> assume after that. And then the proper functions be called.
Would you mean we'd better have something like insn_get_until_immediate() ?
Since the x86 instruction is CISC, we can not decode intermediate
parts. The APIs follows that. If you are confused, I'm sorry about that.
>
> In the kprobes/core.c example above, it does a little further:
>
> ddr += insn.length;
>
> which, IMO, it should be either preceeded by a call to insn_get_length()
> - yes, this time we want the insn length or, the code should call a
> decoding function which gives you *both* length* and opcode bytes.
> insn_decode_insn() or whatever. And *that* should be documented in that
> function's kernel-doc section. And so on...
Actually, there is a historical reason too. INT3 check was added afterwards.
At first, I just calculated the instruction length in the loop...
Thank you,
>
> Does that make more sense?
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
--
Masami Hiramatsu
Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support
Hi Richard,
On Thursday, 22 October 2020, 04:42:01 CEST, Richard Cochran wrote:
> I'm just catching up with this.
>
> Really. Truly. Please -- Include the maintainer on CC for such patches!
sorry for missing you on the recipients list. I blindly trusted the output of
get_maintainer.pl.
I recently sent two other patches which may also be of interest for you. They
related to handling of SO_TIMESTAMPING on 32 bit platforms with newer C
libraries:
https://patchwork.ozlabs.org/project/netdev/patch/20201012093542.15504-1-cegg...@arri.de/
https://patchwork.ozlabs.org/project/netdev/patch/20201012093542.15504-2-cegg...@arri.de/
> On Thu, Oct 22, 2020 at 02:39:35AM +0300, Vladimir Oltean wrote:
> > On Mon, Oct 19, 2020 at 07:24:33PM +0200, Christian Eggers wrote:
> > > The PTP hardware performs internal detection of PTP frames (likely
> > > similar as ptp_classify_raw() and ptp_parse_header()). As these filters
> > > cannot be disabled, the current delay mode (E2E/P2P) and the clock mode
> > > (master/slave) must be configured via sysfs attributes.
>
> This is a complete no-go. NAK.
I didn't design the hardware nor do I have access to adequate documentation.
I will try to figure out what functionality is concretely affected by these
two settings.
If I am correct, the KSZ hardware consists of two main building blocks:
1. A TC on the switch path.
2. An OC on the DSA host port.
>From the data sheet, page 109, chapter 5.1.6.11
("Global PTP Message Config 1 Register"), bit 2:
> *Selection of P2P or E2E*
> 1 = Peer-to-peer (P2P) transparent clock mode
> 0 = End-to-end (E2E) transparent clock mode
So this "tcmode" sysfs entry controls the behavior of the switch' transparent
clock. Is this related in any way to the PTP API?
For the master/slave setting, the data sheet writes the following:
*Selection of Master or Slave*
1 = Host port is PTP master ordinary clock
0 = Host port is PTP slave ordinary clock
So this is really related to the OC and so to the PTP API. Setting this
manually would interfere with the BMCA. I'll check whether delay measurement
and clock synchronization can also work for all conditions (E2E/P2P,
master/slave) without altering this value. Otherwise we might consider
the KSZ as a "Slave Only Clock (SO)".
Christian
Re: [PATCH -next] treewide: Remove stringification from __alias macro definition
On Wed, Oct 21, 2020 at 11:58:25AM -0700, Joe Perches wrote: > Like the __section macro, the __alias macro uses > macro # stringification to create quotes around > the section name used in the __attribute__. > > Remove the stringification and add quotes or a > stringification to the uses instead. There's a complete lack of rationale for this change.
Re: [PATCH 1/1] video: fbdev: fix divide error in fbcon_switch
Hi
On 22.10.20 01:57, saeed.mirzamohamm...@oracle.com wrote:
> From: Saeed Mirzamohammadi
>
> This patch fixes the issue due to:
>
> [ 89.572883] divide_error: [#1] SMP KASAN PTI
> [ 89.572897] CPU: 3 PID: 16083 Comm: repro Not tainted
> 5.9.0-rc7.20200930.rc1.allarch-19-g3e32d0d.syzk #5
> [ 89.572902] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 0.5.1 01/01/2011
> [ 89.572934] RIP: 0010:cirrusfb_check_var+0x84/0x1260
BTW, if you run qemu with cirrus, there's also a DRM driver named
cirrus.ko. Might be a better choice than the old fbdev driver. If you
just care about qemu, but not the actual graphics device, take a look at
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
Anyway, thanks for your patch.
Best regards
Thomas
>
> The error happens when the pixels value is calculated before performing the
> sanity checks on bits_per_pixel.
> A bits_per_pixel set to zero causes divide by zero error.
>
> This patch moves the calculation after the sanity check.
>
> Signed-off-by: Saeed Mirzamohammadi
> Tested-by: Saeed Mirzamohammadi
> ---
> drivers/video/fbdev/cirrusfb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c
> index 15a9ee7cd734..a7749101b094 100644
> --- a/drivers/video/fbdev/cirrusfb.c
> +++ b/drivers/video/fbdev/cirrusfb.c
> @@ -531,7 +531,7 @@ static int cirrusfb_check_var(struct fb_var_screeninfo
> *var,
> {
> int yres;
> /* memory size in pixels */
> - unsigned pixels = info->screen_size * 8 / var->bits_per_pixel;
> + unsigned int pixels;
> struct cirrusfb_info *cinfo = info->par;
>
> switch (var->bits_per_pixel) {
> @@ -573,6 +573,7 @@ static int cirrusfb_check_var(struct fb_var_screeninfo
> *var,
> return -EINVAL;
> }
>
> + pixels = info->screen_size * 8 / var->bits_per_pixel;
> if (var->xres_virtual < var->xres)
> var->xres_virtual = var->xres;
> /* use highest possible virtual resolution */
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
[PATCH v3 1/3] dt-bindings: vendor-prefixes: Add an entry for Van der Laan b.v.
Add "vdl" entry for Van der Laan b.v.: https://www.teamvdl.nl/ Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 801cc267349d..a570f96348a7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1120,6 +1120,8 @@ patternProperties: description: Vamrs Ltd. "^variscite,.*": description: Variscite Ltd. + "^vdl,.*": +description: Van der Laan b.v. "^via,.*": description: VIA Technologies, Inc. "^videostrong,.*": -- 2.28.0
[PATCH v3 0/3] mainline LANMCU board
changes v3: - rename led-debug to led-0 - rename bcrmf to wifi changes v2: - add phy-handle - rename node to touchscreen@38 - reorder reg and status properties Oleksij Rempel (3): dt-bindings: vendor-prefixes: Add an entry for Van der Laan b.v. dt-bindings: arm: fsl: add Van der Laan LANMCU board ARM: dts: add Van der Laan LANMCU board .../devicetree/bindings/arm/fsl.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/imx6dl-lanmcu.dts | 469 ++ 4 files changed, 473 insertions(+) create mode 100644 arch/arm/boot/dts/imx6dl-lanmcu.dts -- 2.28.0
[PATCH v3 3/3] ARM: dts: add Van der Laan LANMCU board
Van der Laan LANMCU is a module for the food storage rooms to control
proper gas composition.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-lanmcu.dts | 469
2 files changed, 470 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-lanmcu.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2289a28c0ff6..dc2543a7b7e9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -447,6 +447,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-icore.dtb \
imx6dl-icore-mipi.dtb \
imx6dl-icore-rqs.dtb \
+ imx6dl-lanmcu.dtb \
imx6dl-mamoj.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-lanmcu.dts
b/arch/arm/boot/dts/imx6dl-lanmcu.dts
new file mode 100644
index ..bda2c7a304ba
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-lanmcu.dts
@@ -0,0 +1,469 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2019 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Van der Laan LANMCU";
+ compatible = "vdl,lanmcu", "fsl,imx6dl";
+
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ clock_ksz8081: clock-ksz8081 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 500 0>;
+ brightness-levels = <0 1000>;
+ num-interpolated-steps = <20>;
+ default-brightness-level = <19>;
+ };
+
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-0 = <&pinctrl_ipu1_disp>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0bdh6";
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+
+ reg_otg_vbus: regulator-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "otg-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ usdhc2_wifi_pwrseq: usdhc2-wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_npd>;
+ reset-gpios = <&gpio6 10 GPIO_ACTIVE_LOW>;
+ };
+
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ status = "okay";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can2>;
+ status = "okay";
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ clocks = <&clks IMX6QDL_CLK_ENET>,
+<&clks IMX6QDL_CLK_ENET>,
+<&clock_ksz8081>;
+ clock-names = "ipg", "ahb", "ptp";
+ phy-handle = <&rgmii_phy>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ8081RNA PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&gpio5 23 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <300>;
+ };
+ };
+};
+
+&gpio1 {
+ gpio
[PATCH v3 2/3] dt-bindings: arm: fsl: add Van der Laan LANMCU board
Add Van der Laan LANMCU iMX6dl based board Signed-off-by: Oleksij Rempel Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 74aaf68b7d06..589df0669ccd 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -190,6 +190,7 @@ properties: - toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1 - toradex,colibri_imx6dl-eval-v3 # Colibri iMX6 Module on Colibri Evaluation Board V3 - toradex,colibri_imx6dl-v1_1-eval-v3 # Colibri iMX6 Module V1.1 on Colibri Evaluation Board V3 + - vdl,lanmcu# Van der Laan LANMCU board - ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board - ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board - ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board -- 2.28.0
Re: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible
On Wed, 2020-10-21 at 08:18 +, David Laight wrote: > From: Benjamin Herrenschmidt > > Sent: 21 October 2020 01:00 > > > > On Wed, 2020-10-21 at 08:36 +1030, Joel Stanley wrote: > > > We must ensure the tx descriptor updates are visible before updating > > > the tx pointer. > > > > > > This resolves the tx hangs observed on the 2600 when running iperf: > > > > To clarify the comment here. This doesn't ensure they are visible to > > the hardware but to other CPUs. This is the ordering vs start_xmit and > > tx_complete. > > You need two barriers. > 1) after making the data buffers available before transferring > the descriptor ownership to the device. > 2) after transferring the ownership before 'kicking' the mac engine. > > The first is needed because the mac engine can poll the descriptors > at any time (eg on completing the previous transmit). > This stops it transmitting garbage. > > The second makes sure it finds the descriptor you've just set. > This stops delays before sending the packet. > (But it will get sent later.) The above is unrelated to this patch. This isn't about fixing any device <-> CPU ordering or interaction but purely about ensuring proper ordering between start_xmit and tx packet cleanup. IE. We are looking at two different issues with this driver. > For (2) dma_wmb() is the documented barrier. > > I'm not sure which barrier you need for (1). > smp_wmb() would be right if the reader were another cpu, > but it is (at most) a compile barrier on UP kernels. > So you need something stronger than smp_wmb(). There should already be sufficient barriers for that in the driver (except for the HW bug mentioned earlier). > On a TSO system (which yours probably is) a compile barrier > is probably sufficient, but if memory writes can get re-ordered > it needs to be a stronger barrier - but not necessarily as strong > as dma_wmb(). > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales)
Re: GCC section alignment, and GCC-4.9 being a weird one
On Wed, Oct 21, 2020 at 10:42:01AM -0700, Nick Desaulniers wrote:
> On Wed, Oct 21, 2020 at 6:45 AM Peter Zijlstra wrote:
> >
> > Ah, thanks!
> >
> > In that case something like the below ought to make it good.
> >
> > I'll go feed it to the robots, see if anything falls over.
> >
> > ---
> > kernel/sched/deadline.c | 4 +++-
> > kernel/sched/fair.c | 4 +++-
> > kernel/sched/idle.c | 4 +++-
> > kernel/sched/rt.c| 4 +++-
> > kernel/sched/sched.h | 3 +--
> > kernel/sched/stop_task.c | 3 ++-
> > 6 files changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 6d93f4518734..f4855203143d 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -2504,7 +2504,9 @@ static void prio_changed_dl(struct rq *rq, struct
> > task_struct *p,
> > }
> >
> > const struct sched_class dl_sched_class
> > - __attribute__((section("__dl_sched_class"))) = {
> > + __attribute__((section("__dl_sched_class")))
> > + __attribute__((aligned(__alignof__(struct sched_class = {
>
> If you used some of the macros from
> include/linux/compiler_attributes.h like __section and __aligned, I
> would prefer it. Please consider spelling out __attribute__(()) an
> antipattern.
Feh, and then suffer more patches because someone doesn't like how
__section uses # :/
Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates
On Wed, Oct 21, 2020 at 09:55:57AM +0200, Niklas Schnelle wrote:
> Hi Daniel,
>
> friendly ping. I haven't seen a new version of this patch series,
> as I said I think your change for s390/pci is generally useful so
> I'm curious, are you planning on sending a new version soon?
> If you want you can also just sent this patch with the last few
> nitpicks (primarily the mail address) fixed and I'll happily apply.
(I think this was stuck somewhere in moderation, only showed up just now)
I was waiting for the testing result for the habana driver from Oded, but
I guess Oded was waiting for v3. Hence the delay.
Cheers, Daniel
>
> Best regards,
> Niklas Schnelle
>
> On 10/12/20 4:19 PM, Daniel Vetter wrote:
> > On Mon, Oct 12, 2020 at 04:03:28PM +0200, Niklas Schnelle wrote:
> ... snip
> >>> Cc: Jason Gunthorpe
> >>> Cc: Dan Williams
> >>> Cc: Kees Cook
> >>> Cc: Andrew Morton
> >>> Cc: John Hubbard
> >>> Cc: Jérôme Glisse
> >>> Cc: Jan Kara
> >>> Cc: Dan Williams
> >>
> >> The above Cc: line for Dan Williams is a duplicate
> >>
> >>> Cc: linux...@kvack.org
> >>> Cc: linux-arm-ker...@lists.infradead.org
> >>> Cc: linux-samsung-...@vger.kernel.org
> >>> Cc: linux-me...@vger.kernel.org
> >>> Cc: Niklas Schnelle
> >>> Cc: Gerald Schaefer
> >>> Cc: linux-s...@vger.kernel.org
> >>> --
> >>> v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL
> >>> like before (Gerard)
> >>
> >> I think the above should go before the CC/Signed-off/Reviewev block.
> >
> > This is a per-subsystem bikeshed :-) drivers/gpu definitely wants it
> > above, but most core subsystems want it below. I'll move it.
> >
> >>> ---
> >>> arch/s390/pci/pci_mmio.c | 98 +++-
> >>> 1 file changed, 57 insertions(+), 41 deletions(-)
> >>>
> >>> diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
> >>> index 401cf670a243..1a6adbc68ee8 100644
> >>> --- a/arch/s390/pci/pci_mmio.c
> >>> +++ b/arch/s390/pci/pci_mmio.c
> >>> @@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem
> >>> *dst,
> >>> return rc;
> >>> }
> >>>
> >>> -static long get_pfn(unsigned long user_addr, unsigned long access,
> >>> - unsigned long *pfn)
> >>> -{
> >>> - struct vm_area_struct *vma;
> >>> - long ret;
> >>> -
> >>> - mmap_read_lock(current->mm);
> >>> - ret = -EINVAL;
> >>> - vma = find_vma(current->mm, user_addr);
> >>> - if (!vma)
> >>> - goto out;
> >>> - ret = -EACCES;
> >>> - if (!(vma->vm_flags & access))
> >>> - goto out;
> >>> - ret = follow_pfn(vma, user_addr, pfn);
> >>> -out:
> >>> - mmap_read_unlock(current->mm);
> >>> - return ret;
> >>> -}
> >>> -
> >>> SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
> >>> const void __user *, user_buffer, size_t, length)
> >>> {
> >>> u8 local_buf[64];
> >>> void __iomem *io_addr;
> >>> void *buf;
> >>> - unsigned long pfn;
> >>> + struct vm_area_struct *vma;
> >>> + pte_t *ptep;
> >>> + spinlock_t *ptl;
> >>
> >> With checkpatch.pl --strict the above yields a complained
> >> "CHECK: spinlock_t definition without comment" but I think
> >> that's really okay since your commit description is very clear.
> >> Same oin line 277.
> >
> > I think this is a falls positive, checkpatch doesn't realize that
> > SYSCALL_DEFINE3 is a function, not a structure. And in a structure I'd
> > have added the kerneldoc or comment.
> >
> > I'll fix up all the nits you've found for the next round. Thanks for
> > taking a look.
> > -Daniel
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 0/2] kunit: tool: Respect '.kunitconfig' in '--build_dir'
From: SeongJae Park This patchset makes kunit tool to respect '.kunitconfig' under the '--build_dir'. Revision History >From v1 (https://lore.kernel.org/linux-kselftest/20201012102621.32226-2-sjp...@amazon.com/) - Rebase on master branch of linus' tree (Not a clean rebase) - Add 'Reviewed-by: Brendan Higgins ' in second patch SeongJae Park (2): kunit: tool: Respect '.kunitconfig' in 'build_dir' kunit: tool: Mark 'kunittest_config' as constant again tools/testing/kunit/kunit.py| 28 +++- tools/testing/kunit/kunit_kernel.py | 6 +++--- 2 files changed, 18 insertions(+), 16 deletions(-) -- 2.17.1
Re: [PATCH v4 00/32] Make charlcd device independent
On Fri, Oct 16, 2020 at 05:59:04AM +0200, Miguel Ojeda wrote: > On Fri, Oct 16, 2020 at 4:33 AM Miguel Ojeda > wrote: > > > > Picking these for linux-next (including Rob's Reviewed-by). I have > > spotted a few typos that I corrected -- I will note them by email. > > Hmm, I think we should do another round instead, since I found what > looks to be an unintended revert of a previous commit in patch 24. > Lars, can you please take a look? I will work on this soon. > Also, please take the chance to apply my comments given we have a new > round (and Rob's Reviewed-by too). Yes, of course. > By the way, I think you could simplify by squashing the "implement > hd44780_*" commits together (i.e. from 15 to 22 except 20), and the > two cleanups together too (i.e. 20 and 23). I know we asked you to > split things up before, but those two sets are quite similar > (including in their commit message) and easy to understand all > together. No problem. I will do this as well. Regards, Lars
[PATCH v2 2/2] kunit: tool: Mark 'kunittest_config' as constant again
From: SeongJae Park
'kunit_kernel.kunittest_config' was constant at first, and therefore it
used UPPER_SNAKE_CASE naming convention that usually means it is
constant in Python world. But, commit e3212513a8f0 ("kunit: Create
default config in '--build_dir'") made it modifiable to fix a use case
of the tool and thus the naming also changed to lower_snake_case.
However, this resulted in a confusion. As a result, some successing
changes made the tool unittest fail, and a fix[1] of it again incurred
the '--build_dir' use case failure.
As the previous commit fixed the '--build_dir' use case without
modifying the variable again, this commit marks the variable as constant
again with UPPER_SNAKE_CASE, to reduce future confusions.
[1] Commit d43c7fb05765 ("kunit: tool: fix improper treatment of file location")
Signed-off-by: SeongJae Park
Reviewed-by: Brendan Higgins
---
tools/testing/kunit/kunit.py| 6 +++---
tools/testing/kunit/kunit_kernel.py | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index 8bee2a5fee27..26046875adb2 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -45,7 +45,7 @@ class KunitStatus(Enum):
TEST_FAILURE = auto()
def create_default_kunitconfig(build_dir=''):
- kunitconfig = os.path.join(build_dir, kunit_kernel.kunitconfig_path)
+ kunitconfig = os.path.join(build_dir, kunit_kernel.KUNITCONFIG_PATH)
if not os.path.exists(kunitconfig):
shutil.copyfile('arch/um/configs/kunit_defconfig', kunitconfig)
@@ -259,7 +259,7 @@ def main(argv, linux=None):
os.chdir(get_kernel_root_path())
kunitconfig_path = os.path.join(cli_args.build_dir,
- kunit_kernel.kunitconfig_path)
+ kunit_kernel.KUNITCONFIG_PATH)
if cli_args.subcommand == 'run':
if not os.path.exists(cli_args.build_dir):
os.mkdir(cli_args.build_dir)
@@ -285,7 +285,7 @@ def main(argv, linux=None):
not os.path.exists(cli_args.build_dir)):
os.mkdir(cli_args.build_dir)
- if not os.path.exists(kunit_kernel.kunitconfig_path):
+ if not os.path.exists(kunitconfig_path):
create_default_kunitconfig(cli_args.build_dir)
if not linux:
diff --git a/tools/testing/kunit/kunit_kernel.py
b/tools/testing/kunit/kunit_kernel.py
index 7dd4268665a8..f4bc9568bbce 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -18,7 +18,7 @@ import kunit_config
import kunit_parser
KCONFIG_PATH = '.config'
-kunitconfig_path = '.kunitconfig'
+KUNITCONFIG_PATH = '.kunitconfig'
BROKEN_ALLCONFIG_PATH = 'tools/testing/kunit/configs/broken_on_uml.config'
class ConfigError(Exception):
@@ -111,7 +111,7 @@ class LinuxSourceTree(object):
def __init__(self, build_dir):
self._kconfig = kunit_config.Kconfig()
- self._kconfig.read_from_file(os.path.join(build_dir,
kunitconfig_path))
+ self._kconfig.read_from_file(os.path.join(build_dir,
KUNITCONFIG_PATH))
self._ops = LinuxSourceTreeOperations()
signal.signal(signal.SIGINT, self.signal_handler)
--
2.17.1
[PATCH v2 1/2] kunit: tool: Respect '.kunitconfig' in 'build_dir'
From: SeongJae Park
Commit d43c7fb05765 ("kunit: tool: fix improper treatment of file
location") removed 'kunit_kernel.kunitconfig_path' modification for the
'--build_dir' argument. As a result, running kunit with '--build_dir'
failed with below error message:
Traceback (most recent call last):
File "./tools/testing/kunit/kunit.py", line 325, in
main(sys.argv[1:])
File "./tools/testing/kunit/kunit.py", line 245, in main
linux = kunit_kernel.LinuxSourceTree()
File "/home/sjpark/linux/tools/testing/kunit/kunit_kernel.py", line 109,
in __init__
self._kconfig.read_from_file(kunitconfig_path)
File "/home/sjpark/linux/tools/testing/kunit/kunit_config.py", line 88,
in read_from_file
with open(path, 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: '.kunitconfig'
The error removed after commit 82206a0c06cc ("kunit: tool: handle when
.kunit exists but .kunitconfig does not"). However, it was not the
intention of the commit. It hides the error by ignoring the
'.kunitconfig' in the '--build_dir'.
This commit makes the tool to respect '.kunitconfig' in '--build_dir'
again, while respecting the constantness of
'kunit_kernel.kunitconfig_path', as modifying the variable makes the
'kunit_tool_test.py' fails
Fixes: d43c7fb05765 ("kunit: tool: fix improper treatment of file location")
Signed-off-by: SeongJae Park
---
tools/testing/kunit/kunit.py| 26 ++
tools/testing/kunit/kunit_kernel.py | 4 ++--
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index ebf5f5763dee..8bee2a5fee27 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -44,10 +44,10 @@ class KunitStatus(Enum):
BUILD_FAILURE = auto()
TEST_FAILURE = auto()
-def create_default_kunitconfig():
- if not os.path.exists(kunit_kernel.kunitconfig_path):
- shutil.copyfile('arch/um/configs/kunit_defconfig',
- kunit_kernel.kunitconfig_path)
+def create_default_kunitconfig(build_dir=''):
+ kunitconfig = os.path.join(build_dir, kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunitconfig):
+ shutil.copyfile('arch/um/configs/kunit_defconfig', kunitconfig)
def get_kernel_root_path():
parts = sys.argv[0] if not __file__ else __file__
@@ -61,7 +61,7 @@ def config_tests(linux: kunit_kernel.LinuxSourceTree,
kunit_parser.print_with_timestamp('Configuring KUnit Kernel ...')
config_start = time.time()
- create_default_kunitconfig()
+ create_default_kunitconfig(request.build_dir)
success = linux.build_reconfig(request.build_dir, request.make_options)
config_end = time.time()
if not success:
@@ -258,15 +258,17 @@ def main(argv, linux=None):
if get_kernel_root_path():
os.chdir(get_kernel_root_path())
+ kunitconfig_path = os.path.join(cli_args.build_dir,
+ kunit_kernel.kunitconfig_path)
if cli_args.subcommand == 'run':
if not os.path.exists(cli_args.build_dir):
os.mkdir(cli_args.build_dir)
- if not os.path.exists(kunit_kernel.kunitconfig_path):
- create_default_kunitconfig()
+ if not os.path.exists(kunitconfig_path):
+ create_default_kunitconfig(cli_args.build_dir)
if not linux:
- linux = kunit_kernel.LinuxSourceTree()
+ linux = kunit_kernel.LinuxSourceTree(cli_args.build_dir)
request = KunitRequest(cli_args.raw_output,
cli_args.timeout,
@@ -284,10 +286,10 @@ def main(argv, linux=None):
os.mkdir(cli_args.build_dir)
if not os.path.exists(kunit_kernel.kunitconfig_path):
- create_default_kunitconfig()
+ create_default_kunitconfig(cli_args.build_dir)
if not linux:
- linux = kunit_kernel.LinuxSourceTree()
+ linux = kunit_kernel.LinuxSourceTree(cli_args.build_dir)
request = KunitConfigRequest(cli_args.build_dir,
cli_args.make_options)
@@ -299,7 +301,7 @@ def main(argv, linux=None):
sys.exit(1)
elif cli_args.subcommand == 'build':
if not linux:
- linux = kunit_kernel.LinuxSourceTree()
+ linux = kunit_kernel.LinuxSourceTree(cli_args.build_dir)
request = KunitBuildRequest(cli_args.jobs,
cli_args.build_dir,
@@ -313,7 +315,7 @@ def main(argv, linux=None):
sys.exit(1)
elif cli_args.subcommand == 'exec':
if not linux:
-
Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue
On Wed, 2020-10-21 at 14:11 +0200, Arnd Bergmann wrote: > (replying to my own mail from a different address to deal with the > regular one being blacklisted somewhere, sorry for any duplicates) > > On Wed, Oct 21, 2020 at 9:16 AM Arnd Bergmann wrote: > > > > On Wed, Oct 21, 2020 at 12:10 AM Benjamin Herrenschmidt > > wrote: > > > On Tue, 2020-10-20 at 21:49 +0200, Arnd Bergmann wrote: > > > > On Tue, Oct 20, 2020 at 11:37 AM Dylan Hung > > > > wrote: > > > > > > +1 @first is system memory from dma_alloc_coherent(), right? > > > > > > > > > > > > You shouldn't have to do this. Is coherent DMA memory broken on your > > > > > > platform? > > > > > > > > > > It is about the arbitration on the DRAM controller. There are two > > > > > queues in the dram controller, one is for the CPU access and the > > > > > other is for the HW engines. > > > > > When CPU issues a store command, the dram controller just > > > > > acknowledges cpu's request and pushes the request into the queue. > > > > > Then CPU triggers the HW MAC engine, the HW engine starts to fetch > > > > > the DMA memory. > > > > > But since the cpu's request may still stay in the queue, the HW > > > > > engine may fetch the wrong data. > > > > > > Actually, I take back what I said earlier, the above seems to imply > > > this is more generic. > > > > > > Dylan, please confirm, does this affect *all* DMA capable devices ? If > > > yes, then it's a really really bad design bug in your chips > > > unfortunately and the proper fix is indeed to make dma_wmb() do a dummy > > > read of some sort (what address though ? would any dummy non-cachable > > > page do ?) to force the data out as *all* drivers will potentially be > > > affected. > > > > > > I was under the impression that it was a specific timing issue in the > > > vhub and ethernet parts, but if it's more generic then it needs to be > > > fixed globally. > > > > We have CONFIG_ARM_HEAVY_MB for SoCs with similar problems, > > it turns mb() and wmb() into a platform specific function call, though it > > doesn't do that for dma_wmb() and smp_wmb(), which should not > > be affected if the problem is only missing serialization between DMA > > and CPU writes. Right. I got mixed up by David mention of dma_wmb, it's not the issue here, it's indeed the ordering of writes to "coherent" memory vs iowrite. > > > > If either of the two is the case, then the READ_ONCE() would just > > > > introduce a long delay before the iowrite32() that makes it more likely > > > > that the data is there, but the inconsistent state would still be > > > > observable > > > > by the device if it is still working on previous frames. > > > > > > I think it just get stuck until we try another packet, ie, it doesn't > > > see the new descriptor valid bit. But Dylan can elaborate. > > > > Ok, that would point to an insufficient barrier in iowrite32() as well, > > not in dma_wmb(). Correct. > > At the moment, the only chips that need the heavy barrier are > > omap4 and mstar_v7, and early l2 cache controllers (not the one > > on Cortex-A7) have another synchronization callback that IIRC > > is used for streaming mappings. .../... > > Obviously, adding one of these for ast2600 would slow down every > > mb() and writel() a lot, but if it is a chip-wide problem rather than > > one isolated to the network device, it would be the correct solution, > > provided that a correct code sequence can be found. I'm surprised that problem doesn't already exist on the ast2400 and 2500 and I thus worry about the performance impact of such a workaround applied generally to every MMIO writes But we did kill mmiowb so ... ;-) Cheers, Ben.
Re: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible
On Wed, 2020-10-21 at 14:40 +0200, Arnd Bergmann wrote: > On Wed, Oct 21, 2020 at 12:39 PM Joel Stanley wrote: > > > > > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c > > b/drivers/net/ethernet/faraday/ftgmac100.c > > index 331d4bdd4a67..15cdfeb135b0 100644 > > --- a/drivers/net/ethernet/faraday/ftgmac100.c > > +++ b/drivers/net/ethernet/faraday/ftgmac100.c > > @@ -653,6 +653,11 @@ static bool ftgmac100_tx_complete_packet(struct > > ftgmac100 *priv) > > ftgmac100_free_tx_packet(priv, pointer, skb, txdes, ctl_stat); > > txdes->txdes0 = cpu_to_le32(ctl_stat & priv->txdes0_edotr_mask); > > > > + /* Ensure the descriptor config is visible before setting the tx > > +* pointer. > > +*/ > > + smp_wmb(); > > + > > priv->tx_clean_pointer = ftgmac100_next_tx_pointer(priv, pointer); > > > > return true; > > @@ -806,6 +811,11 @@ static netdev_tx_t ftgmac100_hard_start_xmit(struct > > sk_buff *skb, > > dma_wmb(); > > first->txdes0 = cpu_to_le32(f_ctl_stat); > > > > + /* Ensure the descriptor config is visible before setting the tx > > +* pointer. > > +*/ > > + smp_wmb(); > > + > > Shouldn't these be paired with smp_rmb() on the reader side? (Not near the code right now) I *think* the reader already has them where it matters but I might have overlooked something when I quickly checked the other day. Cheers, Ben.
[PATCH 5/5] Documentation: add xen.fifo_events kernel parameter description
The kernel boot parameter xen.fifo_events isn't listed in Documentation/admin-guide/kernel-parameters.txt. Add it. Signed-off-by: Juergen Gross --- Documentation/admin-guide/kernel-parameters.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 02d4adbf98d2..526d65d8573a 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5978,6 +5978,13 @@ After which time (jiffies) the event handling loop should start to delay EOI handling. Default is 2. + xen.fifo_events=[XEN] + Boolean parameter to disable using fifo event handling + even if available. Normally fifo event handling is + preferred over the 2-level event handling, as it is + fairer and the number of possible event channels is + much higher. Default is on (use fifo events). + nopv= [X86,XEN,KVM,HYPER_V,VMWARE] Disables the PV optimizations forcing the guest to run as generic guest with no PV drivers. Currently support -- 2.26.2
[PATCH 2/5] xen/events: make struct irq_info private to events_base.c
The struct irq_info of Xen's event handling is used only for two
evtchn_ops functions outside of events_base.c. Those two functions
can easily be switched to avoid that usage.
This allows to make struct irq_info and its related access functions
private to events_base.c.
Signed-off-by: Juergen Gross
---
drivers/xen/events/events_2l.c | 7 +--
drivers/xen/events/events_base.c | 63 ++---
drivers/xen/events/events_fifo.c | 6 +--
drivers/xen/events/events_internal.h | 70
4 files changed, 73 insertions(+), 73 deletions(-)
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index fe5ad0e89cd8..da87f3a1e351 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -47,10 +47,11 @@ static unsigned evtchn_2l_max_channels(void)
return EVTCHN_2L_NR_CHANNELS;
}
-static void evtchn_2l_bind_to_cpu(struct irq_info *info, unsigned cpu)
+static void evtchn_2l_bind_to_cpu(evtchn_port_t evtchn, unsigned int cpu,
+ unsigned int old_cpu)
{
- clear_bit(info->evtchn, BM(per_cpu(cpu_evtchn_mask, info->cpu)));
- set_bit(info->evtchn, BM(per_cpu(cpu_evtchn_mask, cpu)));
+ clear_bit(evtchn, BM(per_cpu(cpu_evtchn_mask, old_cpu)));
+ set_bit(evtchn, BM(per_cpu(cpu_evtchn_mask, cpu)));
}
static void evtchn_2l_clear_pending(evtchn_port_t port)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 436682db41c5..1c25580c7691 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -70,6 +70,57 @@
#undef MODULE_PARAM_PREFIX
#define MODULE_PARAM_PREFIX "xen."
+/* Interrupt types. */
+enum xen_irq_type {
+ IRQT_UNBOUND = 0,
+ IRQT_PIRQ,
+ IRQT_VIRQ,
+ IRQT_IPI,
+ IRQT_EVTCHN
+};
+
+/*
+ * Packed IRQ information:
+ * type - enum xen_irq_type
+ * event channel - irq->event channel mapping
+ * cpu - cpu this event channel is bound to
+ * index - type-specific information:
+ *PIRQ - vector, with MSB being "needs EIO", or physical IRQ of the HVM
+ * guest, or GSI (real passthrough IRQ) of the device.
+ *VIRQ - virq number
+ *IPI - IPI vector
+ *EVTCHN -
+ */
+struct irq_info {
+ struct list_head list;
+ struct list_head eoi_list;
+ short refcnt;
+ short spurious_cnt;
+ enum xen_irq_type type; /* type */
+ unsigned irq;
+ evtchn_port_t evtchn; /* event channel */
+ unsigned short cpu; /* cpu bound */
+ unsigned short eoi_cpu; /* EOI must happen on this cpu-1 */
+ unsigned int irq_epoch; /* If eoi_cpu valid: irq_epoch of event */
+ u64 eoi_time; /* Time in jiffies when to EOI. */
+
+ union {
+ unsigned short virq;
+ enum ipi_vector ipi;
+ struct {
+ unsigned short pirq;
+ unsigned short gsi;
+ unsigned char vector;
+ unsigned char flags;
+ uint16_t domid;
+ } pirq;
+ } u;
+};
+
+#define PIRQ_NEEDS_EOI (1 << 0)
+#define PIRQ_SHAREABLE (1 << 1)
+#define PIRQ_MSI_GROUP (1 << 2)
+
static uint __read_mostly event_loop_timeout = 2;
module_param(event_loop_timeout, uint, 0644);
@@ -110,7 +161,7 @@ static DEFINE_PER_CPU(int [NR_VIRQS], virq_to_irq) = {[0
... NR_VIRQS-1] = -1};
/* IRQ <-> IPI mapping */
static DEFINE_PER_CPU(int [XEN_NR_IPIS], ipi_to_irq) = {[0 ... XEN_NR_IPIS-1]
= -1};
-int **evtchn_to_irq;
+static int **evtchn_to_irq;
#ifdef CONFIG_X86
static unsigned long *pirq_eoi_map;
#endif
@@ -190,7 +241,7 @@ int get_evtchn_to_irq(evtchn_port_t evtchn)
}
/* Get info for IRQ */
-struct irq_info *info_for_irq(unsigned irq)
+static struct irq_info *info_for_irq(unsigned irq)
{
if (irq < nr_legacy_irqs())
return legacy_info_ptrs[irq];
@@ -228,7 +279,7 @@ static int xen_irq_info_common_setup(struct irq_info *info,
irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
- return xen_evtchn_port_setup(info);
+ return xen_evtchn_port_setup(evtchn);
}
static int xen_irq_info_evtchn_setup(unsigned irq,
@@ -351,7 +402,7 @@ static enum xen_irq_type type_from_irq(unsigned irq)
return info_for_irq(irq)->type;
}
-unsigned cpu_from_irq(unsigned irq)
+static unsigned cpu_from_irq(unsigned irq)
{
return info_for_irq(irq)->cpu;
}
@@ -391,7 +442,7 @@ static void bind_evtchn_to_cpu(evtchn_port_t evtchn,
unsigned int cpu)
#ifdef CONFIG_SMP
cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(cpu));
#endif
- xen_evtchn_port_bind_to_cpu(info, cpu);
+ xen_evtchn_port_bind_to_cpu(evtchn, cpu, info->cpu);
info->cpu = cpu;
}
@@ -745,7 +796,7 @@ static unsigned int __startup_pirq(unsigned int irq)
info->evtchn = evtchn;
bind_evtchn_to_cpu(evtchn, 0);
- rc = xen_evt
[PATCH 0/5] xen: event handling cleanup
Do some cleanups in Xen event handling code. Juergen Gross (5): xen: remove no longer used functions xen/events: make struct irq_info private to events_base.c xen/events: only register debug interrupt for 2-level events xen/events: unmask a fifo event channel only if it was masked Documentation: add xen.fifo_events kernel parameter description .../admin-guide/kernel-parameters.txt | 7 ++ arch/x86/xen/smp.c| 19 ++-- arch/x86/xen/xen-ops.h| 2 + drivers/xen/events/events_2l.c| 7 +- drivers/xen/events/events_base.c | 90 +-- drivers/xen/events/events_fifo.c | 9 +- drivers/xen/events/events_internal.h | 70 ++- include/xen/events.h | 8 -- 8 files changed, 100 insertions(+), 112 deletions(-) -- 2.26.2
[PATCH 4/5] xen/events: unmask a fifo event channel only if it was masked
Unmasking an event channel with fifo events channels being used can
require a hypercall to be made, so try to avoid that by checking
whether the event channel was really masked.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
drivers/xen/events/events_fifo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 243e7b6d7b96..f60c5a9ec833 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -236,6 +236,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
w = *word;
+ if (!(w & (1 << EVTCHN_FIFO_MASKED)))
+ return true;
+
do {
if (w & (1 << EVTCHN_FIFO_PENDING))
return false;
--
2.26.2
[PATCH 3/5] xen/events: only register debug interrupt for 2-level events
xen_debug_interrupt() is specific to 2-level event handling. So don't
register it with fifo event handling being active.
Signed-off-by: Juergen Gross
---
arch/x86/xen/smp.c | 19 +++
arch/x86/xen/xen-ops.h | 2 ++
drivers/xen/events/events_base.c | 6 --
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2097fa0ebdb5..b544e511b3c2 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -88,14 +88,17 @@ int xen_smp_intr_init(unsigned int cpu)
per_cpu(xen_callfunc_irq, cpu).irq = rc;
per_cpu(xen_callfunc_irq, cpu).name = callfunc_name;
- debug_name = kasprintf(GFP_KERNEL, "debug%d", cpu);
- rc = bind_virq_to_irqhandler(VIRQ_DEBUG, cpu, xen_debug_interrupt,
-IRQF_PERCPU | IRQF_NOBALANCING,
-debug_name, NULL);
- if (rc < 0)
- goto fail;
- per_cpu(xen_debug_irq, cpu).irq = rc;
- per_cpu(xen_debug_irq, cpu).name = debug_name;
+ if (!fifo_events) {
+ debug_name = kasprintf(GFP_KERNEL, "debug%d", cpu);
+ rc = bind_virq_to_irqhandler(VIRQ_DEBUG, cpu,
+xen_debug_interrupt,
+IRQF_PERCPU | IRQF_NOBALANCING,
+debug_name, NULL);
+ if (rc < 0)
+ goto fail;
+ per_cpu(xen_debug_irq, cpu).irq = rc;
+ per_cpu(xen_debug_irq, cpu).name = debug_name;
+ }
callfunc_name = kasprintf(GFP_KERNEL, "callfuncsingle%d", cpu);
rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_SINGLE_VECTOR,
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 45d556f71858..e444c78b6e2b 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -29,6 +29,8 @@ extern struct start_info *xen_start_info;
extern struct shared_info xen_dummy_shared_info;
extern struct shared_info *HYPERVISOR_shared_info;
+extern bool fifo_events;
+
void xen_setup_mfn_list_list(void);
void xen_build_mfn_list_list(void);
void xen_setup_machphys_mapping(void);
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 1c25580c7691..bb18cce4db06 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2050,7 +2050,7 @@ void xen_setup_callback_vector(void) {}
static inline void xen_alloc_callback_vector(void) {}
#endif
-static bool fifo_events = true;
+bool fifo_events = true;
module_param(fifo_events, bool, 0);
static int xen_evtchn_cpu_prepare(unsigned int cpu)
@@ -2082,8 +2082,10 @@ void __init xen_init_IRQ(void)
if (fifo_events)
ret = xen_evtchn_fifo_init();
- if (ret < 0)
+ if (ret < 0) {
xen_evtchn_2l_init();
+ fifo_events = false;
+ }
xen_cpu_init_eoi(smp_processor_id());
--
2.26.2
[PATCH 1/5] xen: remove no longer used functions
With the switch to the lateeoi model for interdomain event channels
some functions are no longer in use. Remove them.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
drivers/xen/events/events_base.c | 21 -
include/xen/events.h | 8
2 files changed, 29 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index cc317739e786..436682db41c5 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1145,14 +1145,6 @@ static int bind_interdomain_evtchn_to_irq_chip(unsigned
int remote_domain,
chip);
}
-int bind_interdomain_evtchn_to_irq(unsigned int remote_domain,
- evtchn_port_t remote_port)
-{
- return bind_interdomain_evtchn_to_irq_chip(remote_domain, remote_port,
- &xen_dynamic_chip);
-}
-EXPORT_SYMBOL_GPL(bind_interdomain_evtchn_to_irq);
-
int bind_interdomain_evtchn_to_irq_lateeoi(unsigned int remote_domain,
evtchn_port_t remote_port)
{
@@ -1320,19 +1312,6 @@ static int bind_interdomain_evtchn_to_irqhandler_chip(
return irq;
}
-int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain,
- evtchn_port_t remote_port,
- irq_handler_t handler,
- unsigned long irqflags,
- const char *devname,
- void *dev_id)
-{
- return bind_interdomain_evtchn_to_irqhandler_chip(remote_domain,
- remote_port, handler, irqflags, devname,
- dev_id, &xen_dynamic_chip);
-}
-EXPORT_SYMBOL_GPL(bind_interdomain_evtchn_to_irqhandler);
-
int bind_interdomain_evtchn_to_irqhandler_lateeoi(unsigned int remote_domain,
evtchn_port_t remote_port,
irq_handler_t handler,
diff --git a/include/xen/events.h b/include/xen/events.h
index 3b8155c2ea03..8ec418e30c7f 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -35,16 +35,8 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi,
unsigned long irqflags,
const char *devname,
void *dev_id);
-int bind_interdomain_evtchn_to_irq(unsigned int remote_domain,
- evtchn_port_t remote_port);
int bind_interdomain_evtchn_to_irq_lateeoi(unsigned int remote_domain,
evtchn_port_t remote_port);
-int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain,
- evtchn_port_t remote_port,
- irq_handler_t handler,
- unsigned long irqflags,
- const char *devname,
- void *dev_id);
int bind_interdomain_evtchn_to_irqhandler_lateeoi(unsigned int remote_domain,
evtchn_port_t remote_port,
irq_handler_t handler,
--
2.26.2
Re: [PATCH] hugetlb_cgroup: fix reservation accounting
On 10/21/20 10:44 PM, Mike Kravetz wrote:
Michal Privoznik was using "free page reporting" in QEMU/virtio-balloon
with hugetlbfs and hit the warning below. QEMU with free page hinting
uses fallocate(FALLOC_FL_PUNCH_HOLE) to discard pages that are reported
as free by a VM. The reporting granularity is in pageblock granularity.
So when the guest reports 2M chunks, we fallocate(FALLOC_FL_PUNCH_HOLE)
one huge page in QEMU.
[ 315.251417] [ cut here ]
[ 315.251424] WARNING: CPU: 7 PID: 6636 at mm/page_counter.c:57
page_counter_uncharge+0x4b/0x50
[ 315.251425] Modules linked in: ...
[ 315.251466] CPU: 7 PID: 6636 Comm: qemu-system-x86 Not tainted 5.9.0 #137
[ 315.251467] Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS PRO/X570
AORUS PRO, BIOS F21 07/31/2020
[ 315.251469] RIP: 0010:page_counter_uncharge+0x4b/0x50
...
[ 315.251479] Call Trace:
[ 315.251485] hugetlb_cgroup_uncharge_file_region+0x4b/0x80
[ 315.251487] region_del+0x1d3/0x300
[ 315.251489] hugetlb_unreserve_pages+0x39/0xb0
[ 315.251492] remove_inode_hugepages+0x1a8/0x3d0
[ 315.251495] ? tlb_finish_mmu+0x7a/0x1d0
[ 315.251497] hugetlbfs_fallocate+0x3c4/0x5c0
[ 315.251519] ? kvm_arch_vcpu_ioctl_run+0x614/0x1700 [kvm]
[ 315.251522] ? file_has_perm+0xa2/0xb0
[ 315.251524] ? inode_security+0xc/0x60
[ 315.251525] ? selinux_file_permission+0x4e/0x120
[ 315.251527] vfs_fallocate+0x146/0x290
[ 315.251529] __x64_sys_fallocate+0x3e/0x70
[ 315.251531] do_syscall_64+0x33/0x40
[ 315.251533] entry_SYSCALL_64_after_hwframe+0x44/0xa9
...
[ 315.251542] ---[ end trace 4c88c62ccb1349c9 ]---
Investigation of the issue uncovered bugs in hugetlb cgroup reservation
accounting. This patch addresses the found issues.
Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings")
Cc:
Reported-by: Michal Privoznik
Co-developed-by: David Hildenbrand
Signed-off-by: David Hildenbrand
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
I just tested this and can confirm it fixes the problem:
Tested-by: Michal Privoznik
Thank you!
Michal
[PATCH v2 1/2] net: phy: adin: disable diag clock & disable standby mode in config_aneg
When the PHY powers up, the diagnostics clock isn't enabled (bit 2 in
register PHY_CTRL_1 (0x0012)).
Also, the PHY is not in standby mode, so bit 13 in PHY_CTRL_3 (0x0017) is
always set at power up.
The standby mode and the diagnostics clock are both meant to be for the
cable diagnostics feature of the PHY (in phylib this would be equivalent to
the cable-test support), and for the frame-generator feature of the PHY.
In standby mode, the PHY doesn't negotiate links or manage links.
To use the cable diagnostics/test (or frame-generator), the PHY must be
first set in standby mode, so that the link operation doesn't interfere.
Then, the diagnostics clock must be enabled.
For the cable-test feature, when the operation finishes, the PHY goes into
PHY_UP state, and the config_aneg hook is called.
For the ADIN PHY, we need to make sure that during autonegotiation
configuration/setup the PHY is removed from standby mode and the
diagnostics clock is disabled, so that normal operation is resumed.
This change does that by moving the set of the ADIN1300_LINKING_EN bit (2)
in the config_aneg (to disable standby mode).
Previously, this was set in the downshift setup, because the downshift
retry value and the ADIN1300_LINKING_EN are in the same register.
And the ADIN1300_DIAG_CLK_EN bit (13) is cleared, to disable the
diagnostics clock.
Signed-off-by: Alexandru Ardelean
---
Changelog v1 -> v2:
* updated title; updated description to better describe the diagnostics
clock & standby mode, and what they mean for the PHY
drivers/net/phy/adin.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 5bc3926c52f0..619d36685b5d 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -23,6 +23,7 @@
#define ADIN1300_PHY_CTRL1 0x0012
#define ADIN1300_AUTO_MDI_EN BIT(10)
#define ADIN1300_MAN_MDIX_EN BIT(9)
+#define ADIN1300_DIAG_CLK_EN BIT(2)
#define ADIN1300_RX_ERR_CNT0x0014
@@ -326,10 +327,9 @@ static int adin_set_downshift(struct phy_device *phydev,
u8 cnt)
return -E2BIG;
val = FIELD_PREP(ADIN1300_DOWNSPEED_RETRIES_MSK, cnt);
- val |= ADIN1300_LINKING_EN;
rc = phy_modify(phydev, ADIN1300_PHY_CTRL3,
- ADIN1300_LINKING_EN | ADIN1300_DOWNSPEED_RETRIES_MSK,
+ ADIN1300_DOWNSPEED_RETRIES_MSK,
val);
if (rc < 0)
return rc;
@@ -560,6 +560,14 @@ static int adin_config_aneg(struct phy_device *phydev)
{
int ret;
+ ret = phy_clear_bits(phydev, ADIN1300_PHY_CTRL1, ADIN1300_DIAG_CLK_EN);
+ if (ret < 0)
+ return ret;
+
+ ret = phy_set_bits(phydev, ADIN1300_PHY_CTRL3, ADIN1300_LINKING_EN);
+ if (ret < 0)
+ return ret;
+
ret = adin_config_mdix(phydev);
if (ret)
return ret;
--
2.25.1
Re: [PATCH net RFC] net: Clear IFF_TX_SKB_SHARING for all Ethernet devices using skb_padto
Sorry. I spotted some errors in this patch. Some drivers use "ndev" as the variable name but I mistakenly used "dev". It was very hard for me to attempt fixing. There are too many drivers that need to be fixed. Fixing them is very time-consuming and may also be error-prone. So I think it may be better to just remove IFF_TX_SKB_SHARING from ether_setup. Drivers that support this feature should add this flag by themselves. This also makes our code cleaner.
[PATCH v2 2/2] net: phy: adin: implement cable-test support
The ADIN1300/ADIN1200 support cable diagnostics using TDR.
The cable fault detection is automatically run on all four pairs looking at
all combinations of pair faults by first putting the PHY in standby (clear
the LINK_EN bit, PHY_CTRL_3 register, Address 0x0017) and then enabling the
diagnostic clock (set the DIAG_CLK_EN bit, PHY_CTRL_1 register, Address
0x0012).
Cable diagnostics can then be run (set the CDIAG_RUN bit in the
CDIAG_RUN register, Address 0xBA1B). The results are reported for each pair
in the cable diagnostics results registers, CDIAG_DTLD_RSLTS_0,
CDIAG_DTLD_RSLTS_1, CDIAG_DTLD_RSLTS_2, and CDIAG_DTLD_RSLTS_3, Address
0xBA1D to Address 0xBA20).
The distance to the first fault for each pair is reported in the cable
fault distance registers, CDIAG_FLT_DIST_0, CDIAG_FLT_DIST_1,
CDIAG_FLT_DIST_2, and CDIAG_FLT_DIST_3, Address 0xBA21 to Address 0xBA24).
This change implements support for this using phylib's cable-test support.
Signed-off-by: Alexandru Ardelean
---
drivers/net/phy/adin.c | 138 +
1 file changed, 138 insertions(+)
diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 619d36685b5d..3e66f97c7611 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -70,6 +71,31 @@
#define ADIN1300_CLOCK_STOP_REG0x9400
#define ADIN1300_LPI_WAKE_ERR_CNT_REG 0xa000
+#define ADIN1300_CDIAG_RUN 0xba1b
+#define ADIN1300_CDIAG_RUN_ENBIT(0)
+
+/*
+ * The XSIM3/2/1 and XSHRT3/2/1 are actually relative.
+ * For CDIAG_DTLD_RSLTS(0) it's ADIN1300_CDIAG_RSLT_XSIM3/2/1
+ * For CDIAG_DTLD_RSLTS(1) it's ADIN1300_CDIAG_RSLT_XSIM3/2/0
+ * For CDIAG_DTLD_RSLTS(2) it's ADIN1300_CDIAG_RSLT_XSIM3/1/0
+ * For CDIAG_DTLD_RSLTS(3) it's ADIN1300_CDIAG_RSLT_XSIM2/1/0
+ */
+#define ADIN1300_CDIAG_DTLD_RSLTS(x) (0xba1d + (x))
+#define ADIN1300_CDIAG_RSLT_BUSY BIT(10)
+#define ADIN1300_CDIAG_RSLT_XSIM3BIT(9)
+#define ADIN1300_CDIAG_RSLT_XSIM2BIT(8)
+#define ADIN1300_CDIAG_RSLT_XSIM1BIT(7)
+#define ADIN1300_CDIAG_RSLT_SIM BIT(6)
+#define ADIN1300_CDIAG_RSLT_XSHRT3 BIT(5)
+#define ADIN1300_CDIAG_RSLT_XSHRT2 BIT(4)
+#define ADIN1300_CDIAG_RSLT_XSHRT1 BIT(3)
+#define ADIN1300_CDIAG_RSLT_SHRT BIT(2)
+#define ADIN1300_CDIAG_RSLT_OPEN BIT(1)
+#define ADIN1300_CDIAG_RSLT_GOOD BIT(0)
+
+#define ADIN1300_CDIAG_FLT_DIST(x) (0xba21 + (x))
+
#define ADIN1300_GE_SOFT_RESET_REG 0xff0c
#define ADIN1300_GE_SOFT_RESET BIT(0)
@@ -741,10 +767,117 @@ static int adin_probe(struct phy_device *phydev)
return 0;
}
+static int adin_cable_test_start(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_clear_bits(phydev, ADIN1300_PHY_CTRL3, ADIN1300_LINKING_EN);
+ if (ret < 0)
+ return ret;
+
+ ret = phy_clear_bits(phydev, ADIN1300_PHY_CTRL1, ADIN1300_DIAG_CLK_EN);
+ if (ret < 0)
+ return ret;
+
+ /* wait a bit for the clock to stabilize */
+ msleep(50);
+
+ return phy_set_bits_mmd(phydev, MDIO_MMD_VEND1, ADIN1300_CDIAG_RUN,
+ ADIN1300_CDIAG_RUN_EN);
+}
+
+static int adin_cable_test_report_trans(int result)
+{
+ int mask;
+
+ if (result & ADIN1300_CDIAG_RSLT_GOOD)
+ return ETHTOOL_A_CABLE_RESULT_CODE_OK;
+ if (result & ADIN1300_CDIAG_RSLT_OPEN)
+ return ETHTOOL_A_CABLE_RESULT_CODE_OPEN;
+
+ /* short with other pairs */
+ mask = ADIN1300_CDIAG_RSLT_XSHRT3 |
+ ADIN1300_CDIAG_RSLT_XSHRT2 |
+ ADIN1300_CDIAG_RSLT_XSHRT1;
+ if (result & mask)
+ return ETHTOOL_A_CABLE_RESULT_CODE_CROSS_SHORT;
+
+ if (result & ADIN1300_CDIAG_RSLT_SHRT)
+ return ETHTOOL_A_CABLE_RESULT_CODE_SAME_SHORT;
+
+ return ETHTOOL_A_CABLE_RESULT_CODE_UNSPEC;
+}
+
+static int adin_cable_test_report_pair(struct phy_device *phydev,
+ unsigned int pair)
+{
+ int fault_rslt;
+ int ret;
+
+ ret = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+ ADIN1300_CDIAG_DTLD_RSLTS(pair));
+ if (ret < 0)
+ return ret;
+
+ fault_rslt = adin_cable_test_report_trans(ret);
+
+ ret = ethnl_cable_test_result(phydev, pair, fault_rslt);
+ if (ret < 0)
+ return ret;
+
+ ret = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+ ADIN1300_CDIAG_FLT_DIST(pair));
+ if (ret < 0)
+ return ret;
+
+ switch (fault_rslt) {
+ case ETHTOOL_A_CABLE_RESULT_CODE_OPEN:
+ case ETHTOOL_A_CABLE_RESULT_CODE_SAME_SHORT:
+ case ETHTOOL_A_CABLE_RESULT_CODE_CROSS_SHORT:
+
Re: [PATCH v4 2/2] spmi: mediatek: Add support for MT6873/8192
On Sat, Oct 17, 2020 at 12:11 AM Hsin-Hsiung Wang
wrote:
>
> add spmi support for MT6873/8192.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/spmi/Kconfig | 9 +
> drivers/spmi/Makefile| 1 +
> drivers/spmi/spmi-mtk-pmif.c | 490 +++
> 3 files changed, 500 insertions(+)
> create mode 100644 drivers/spmi/spmi-mtk-pmif.c
>
> diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
> index a53bad541f1a..418848840999 100644
> --- a/drivers/spmi/Kconfig
> +++ b/drivers/spmi/Kconfig
> @@ -25,4 +25,13 @@ config SPMI_MSM_PMIC_ARB
> This is required for communicating with Qualcomm PMICs and
> other devices that have the SPMI interface.
>
> +config SPMI_MTK_PMIF
> + tristate "Mediatek SPMI Controller (PMIC Arbiter)"
> + help
> + If you say yes to this option, support will be included for the
> + built-in SPMI PMIC Arbiter interface on Mediatek family
> + processors.
> +
> + This is required for communicating with Mediatek PMICs and
> + other devices that have the SPMI interface.
> endif
> diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
> index 55a94cadeffe..91f303b96925 100644
> --- a/drivers/spmi/Makefile
> +++ b/drivers/spmi/Makefile
> @@ -5,3 +5,4 @@
> obj-$(CONFIG_SPMI) += spmi.o
>
> obj-$(CONFIG_SPMI_MSM_PMIC_ARB)+= spmi-pmic-arb.o
> +obj-$(CONFIG_SPMI_MTK_PMIF)+= spmi-mtk-pmif.o
> \ No newline at end of file
> diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
> new file mode 100644
> index ..1b8b628fc9b6
> --- /dev/null
> +++ b/drivers/spmi/spmi-mtk-pmif.c
> @@ -0,0 +1,490 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SWINF_IDLE 0x00
> +#define SWINF_WFVLDCLR 0x06
> +
> +#define GET_SWINF(x) (((x) >> 1) & 0x7)
> +
> +#define PMIF_CMD_REG_0 0
> +#define PMIF_CMD_REG 1
> +#define PMIF_CMD_EXT_REG 2
> +#define PMIF_CMD_EXT_REG_LONG 3
> +
> +#define PMIF_DELAY_US 10
> +#define PMIF_TIMEOUT(10 * 1000)
> +
> +#define PMIF_CHAN_OFFSET 0x5
> +
> +#define SPMI_OP_ST_BUSY 1
> +
> +struct ch_reg {
> + u32 ch_sta;
> + u32 wdata;
> + u32 rdata;
> + u32 ch_send;
> + u32 ch_rdy;
> +};
> +
> +struct pmif {
> + void __iomem*base;
> + const u32 *regs;
> + void __iomem*spmimst_base;
> + const u32 *spmimst_regs;
> + u32 soc_chan;
> + int grpid;
> + raw_spinlock_t lock;
> + struct clk *pmif_sys_ck;
> + struct clk *pmif_tmr_ck;
> + struct clk *spmimst_clk_mux;
> + struct ch_reg chan;
Nit: use tab to align.
> +};
> +
> +enum pmif_regs {
> + PMIF_INIT_DONE,
> + PMIF_INF_EN,
> + PMIF_ARB_EN,
> + PMIF_CMDISSUE_EN,
> + PMIF_TIMER_CTRL,
> + PMIF_SPI_MODE_CTRL,
> + PMIF_IRQ_EVENT_EN_0,
> + PMIF_IRQ_FLAG_0,
> + PMIF_IRQ_CLR_0,
> + PMIF_IRQ_EVENT_EN_1,
> + PMIF_IRQ_FLAG_1,
> + PMIF_IRQ_CLR_1,
> + PMIF_IRQ_EVENT_EN_2,
> + PMIF_IRQ_FLAG_2,
> + PMIF_IRQ_CLR_2,
> + PMIF_IRQ_EVENT_EN_3,
> + PMIF_IRQ_FLAG_3,
> + PMIF_IRQ_CLR_3,
> + PMIF_IRQ_EVENT_EN_4,
> + PMIF_IRQ_FLAG_4,
> + PMIF_IRQ_CLR_4,
> + PMIF_WDT_EVENT_EN_0,
> + PMIF_WDT_FLAG_0,
> + PMIF_WDT_EVENT_EN_1,
> + PMIF_WDT_FLAG_1,
> + PMIF_SWINF_0_STA,
> + PMIF_SWINF_0_WDATA_31_0,
> + PMIF_SWINF_0_RDATA_31_0,
> + PMIF_SWINF_0_ACC,
> + PMIF_SWINF_0_VLD_CLR,
> + PMIF_SWINF_1_STA,
> + PMIF_SWINF_1_WDATA_31_0,
> + PMIF_SWINF_1_RDATA_31_0,
> + PMIF_SWINF_1_ACC,
> + PMIF_SWINF_1_VLD_CLR,
> + PMIF_SWINF_2_STA,
> + PMIF_SWINF_2_WDATA_31_0,
> + PMIF_SWINF_2_RDATA_31_0,
> + PMIF_SWINF_2_ACC,
> + PMIF_SWINF_2_VLD_CLR,
> + PMIF_SWINF_3_STA,
> + PMIF_SWINF_3_WDATA_31_0,
> + PMIF_SWINF_3_RDATA_31_0,
> + PMIF_SWINF_3_ACC,
> + PMIF_SWINF_3_VLD_CLR,
> +};
> +
> +static const u32 mt6873_regs[] = {
> + [PMIF_INIT_DONE] = 0x,
> + [PMIF_INF_EN] = 0x0024,
> + [PMIF_ARB_EN] = 0x0150,
> + [PMIF_CMDISSUE_EN] =0x03B4,
> + [PMIF_TIMER_CTRL] = 0x03E0,
> + [PMIF_SPI_MODE_CTRL] = 0x0400,
> + [PMIF_IRQ_EVENT_EN_0] = 0x0418,
> + [PMIF_IRQ_FLAG_0] = 0x0420,
> + [PMIF_IRQ_CLR_0] = 0x0424,
> + [PMIF_IRQ_EVENT_EN_1] = 0x0428,
> + [PMIF_IRQ_FLAG_1] = 0x0430,
> + [PMIF_IRQ_CLR_1] = 0x0434,
> + [PMIF_IRQ_EVENT_EN_2] = 0x0438,
> + [PMIF_IRQ_FLAG_2] = 0x0440,
> + [PMIF_IRQ_CLR_2] = 0x0444,
> + [PMIF_IRQ_EVENT_EN_3] = 0x0448,
> + [PMIF_IRQ_FLAG_3] = 0x0450,
> + [PMIF_IRQ_CLR_3] =
[PATCH] nvmem: imx-ocotp: add support for the unaliged word count
From: Peng Fan
When offset is not 4 bytes aligned, directly shift righty by 2 bits
will cause reading out wrong data. Since imx ocotp only supports
4 bytes reading once, we need handle offset is not 4 bytes aligned
and enlarge the bytes to 4 bytes aligned. After reading finished,
copy the needed data from buffer to caller and free buffer.
Signed-off-by: Peng Fan
---
drivers/nvmem/imx-ocotp.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index 7a1ebd6fd08b..08f41328cc71 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -4,6 +4,8 @@
*
* Copyright (c) 2015 Pengutronix, Philipp Zabel
*
+ * Copyright 2019 NXP
+ *
* Based on the barebox ocotp driver,
* Copyright (c) 2010 Baruch Siach ,
* Orex Computed Radiography
@@ -158,22 +160,30 @@ static int imx_ocotp_read(void *context, unsigned int
offset,
{
struct ocotp_priv *priv = context;
unsigned int count;
- u32 *buf = val;
+ u8 *buf, *p;
int i, ret;
- u32 index;
+ u32 index, num_bytes;
index = offset >> 2;
- count = bytes >> 2;
+ num_bytes = round_up((offset % 4) + bytes, 4);
+ count = num_bytes >> 2;
if (count > (priv->params->nregs - index))
count = priv->params->nregs - index;
+ p = kzalloc(num_bytes, GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
mutex_lock(&ocotp_mutex);
+ buf = p;
+
ret = clk_prepare_enable(priv->clk);
if (ret < 0) {
mutex_unlock(&ocotp_mutex);
dev_err(priv->dev, "failed to prepare/enable ocotp clk\n");
+ kfree(p);
return ret;
}
@@ -184,7 +194,7 @@ static int imx_ocotp_read(void *context, unsigned int
offset,
}
for (i = index; i < (index + count); i++) {
- *buf++ = readl(priv->base + IMX_OCOTP_OFFSET_B0W0 +
+ *(u32 *)buf = readl(priv->base + IMX_OCOTP_OFFSET_B0W0 +
i * IMX_OCOTP_OFFSET_PER_WORD);
/* 47.3.1.2
@@ -193,13 +203,21 @@ static int imx_ocotp_read(void *context, unsigned int
offset,
* software before any new write, read or reload access can be
* issued
*/
- if (*(buf - 1) == IMX_OCOTP_READ_LOCKED_VAL)
+ if (*((u32 *)buf) == IMX_OCOTP_READ_LOCKED_VAL)
imx_ocotp_clr_err_if_set(priv);
+
+ buf += 4;
}
+ index = offset % 4;
+ memcpy(val, &p[index], bytes);
+
read_end:
clk_disable_unprepare(priv->clk);
mutex_unlock(&ocotp_mutex);
+
+ kfree(p);
+
return ret;
}
@@ -447,7 +465,7 @@ static struct nvmem_config imx_ocotp_nvmem_config = {
.name = "imx-ocotp",
.read_only = false,
.word_size = 4,
- .stride = 4,
+ .stride = 1,
.reg_read = imx_ocotp_read,
.reg_write = imx_ocotp_write,
};
--
2.28.0
Re: [PATCH v2 03/15] perf data: open data directory in read access mode
On 22.10.2020 7:31, Namhyung Kim wrote:
> On Thu, Oct 22, 2020 at 12:58 AM Alexey Budankov
> wrote:
>>
>>
>> Open files located at trace data directory in case read access
>> mode is requested. File are opened and its fds assigned to
>> perf_data dir files especially for loading data directories
>> content in perf report mode.
>>
>> Signed-off-by: Alexey Budankov
>> ---
>> tools/perf/util/data.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
>> index c47aa34fdc0a..6ad61ac6ba67 100644
>> --- a/tools/perf/util/data.c
>> +++ b/tools/perf/util/data.c
>> @@ -321,6 +321,10 @@ static int open_dir(struct perf_data *data)
>> return -1;
>>
>> ret = open_file(data);
>> + if (!ret && perf_data__is_dir(data)) {
>
> I think this __is_dir() check is unnecessary since it's checked
> from the caller side already.
Corrected in v3. Thanks!
Alexei
[PATCH v3 2/2] dt-bindings: can: flexcan: convert fsl,*flexcan bindings to yaml
In order to automate the verification of DT nodes convert
fsl-flexcan.txt to fsl,flexcan.yaml
Signed-off-by: Oleksij Rempel
Link: https://lore.kernel.org/r/20201016073315.16232-3-o.rem...@pengutronix.de
Signed-off-by: Marc Kleine-Budde
---
.../bindings/net/can/fsl,flexcan.yaml | 135 ++
.../bindings/net/can/fsl-flexcan.txt | 57
2 files changed, 135 insertions(+), 57 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
new file mode 100644
index ..43df15ba8fa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/fsl,flexcan.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title:
+ Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
+
+maintainers:
+ - Marc Kleine-Budde
+
+allOf:
+ - $ref: can-controller.yaml#
+
+properties:
+ compatible:
+oneOf:
+ - enum:
+ - fsl,imx8qm-flexcan
+ - fsl,imx8mp-flexcan
+ - fsl,imx6q-flexcan
+ - fsl,imx53-flexcan
+ - fsl,imx35-flexcan
+ - fsl,imx28-flexcan
+ - fsl,imx25-flexcan
+ - fsl,p1010-flexcan
+ - fsl,vf610-flexcan
+ - fsl,ls1021ar2-flexcan
+ - fsl,lx2160ar1-flexcan
+ - items:
+ - enum:
+ - fsl,imx7d-flexcan
+ - fsl,imx6ul-flexcan
+ - fsl,imx6sx-flexcan
+ - const: fsl,imx6q-flexcan
+ - items:
+ - enum:
+ - fsl,ls1028ar1-flexcan
+ - const: fsl,lx2160ar1-flexcan
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 2
+
+ clock-names:
+items:
+ - const: ipg
+ - const: per
+
+ clock-frequency:
+description: |
+ The oscillator frequency driving the flexcan device, filled in by the
+ boot loader. This property should only be used the used operating system
+ doesn't support the clocks and clock-names property.
+
+ xceiver-supply:
+description: Regulator that powers the CAN transceiver.
+
+ big-endian:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+ This means the registers of FlexCAN controller are big endian. This is
+ optional property.i.e. if this property is not present in device tree
+ node then controller is assumed to be little endian. If this property is
+ present then controller is assumed to be big endian.
+
+ fsl,stop-mode:
+description: |
+ Register bits of stop mode control.
+
+ The format should be as follows:
+
+ gpr is the phandle to general purpose register node.
+ req_gpr is the gpr register offset of CAN stop request.
+ req_bit is the bit offset of CAN stop request.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ - description: The 'gpr' is the phandle to general purpose register node.
+ - description: The 'req_gpr' is the gpr register offset of CAN stop
request.
+maximum: 0xff
+ - description: The 'req_bit' is the bit offset of CAN stop request.
+maximum: 0x1f
+
+ fsl,clk-source:
+description: |
+ Select the clock source to the CAN Protocol Engine (PE). It's SoC
+ implementation dependent. Refer to RM for detailed definition. If this
+ property is not set in device tree node then driver selects clock source
1
+ by default.
+ 0: clock source 0 (oscillator clock)
+ 1: clock source 1 (peripheral clock)
+$ref: /schemas/types.yaml#/definitions/uint32
+default: 1
+minimum: 0
+maximum: 1
+
+ wakeup-source:
+$ref: /schemas/types.yaml#/definitions/flag
+description:
+ Enable CAN remote wakeup.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+can@1c000 {
+compatible = "fsl,p1010-flexcan";
+reg = <0x1c000 0x1000>;
+interrupts = <48 0x2>;
+interrupt-parent = <&mpic>;
+clock-frequency = <2>;
+fsl,clk-source = <0>;
+};
+ - |
+#include
+
+can@209 {
+compatible = "fsl,imx6q-flexcan";
+reg = <0x0209 0x4000>;
+interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
+clocks = <&clks 1>, <&clks 2>;
+clock-names = "ipg", "per";
+fsl,stop-mode = <&gpr 0x34 28>;
+};
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
deleted file mode 100644
index e10b6eb955e1..
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ /d
[PATCH v3 0/2] convert flexcan to the yaml
changes v3: - can-controller.yaml: add "additionalProperties: true" - fsl,flexcan.yaml: remove maxItems and not needed type definition changes v2: - add can-controller.yaml for common patterns - use phandle-array instead of uint32-array - Drop the outer 'items' in fsl,stop-mode - use can@ instead of flexcan@ Oleksij Rempel (2): dt-bindings: can: add can-controller.yaml dt-bindings: can: flexcan: convert fsl,*flexcan bindings to yaml .../bindings/net/can/can-controller.yaml | 18 +++ .../bindings/net/can/fsl,flexcan.yaml | 135 ++ .../bindings/net/can/fsl-flexcan.txt | 57 3 files changed, 153 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/can/can-controller.yaml create mode 100644 Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt -- 2.28.0
[PATCH v3 1/2] dt-bindings: can: add can-controller.yaml
For now we have only node name as common rule for all CAN controllers Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20201016073315.16232-2-o.rem...@pengutronix.de Signed-off-by: Marc Kleine-Budde --- .../bindings/net/can/can-controller.yaml | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/can/can-controller.yaml diff --git a/Documentation/devicetree/bindings/net/can/can-controller.yaml b/Documentation/devicetree/bindings/net/can/can-controller.yaml new file mode 100644 index ..9cf2ae097156 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/can-controller.yaml @@ -0,0 +1,18 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/can-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CAN Controller Generic Binding + +maintainers: + - Marc Kleine-Budde + +properties: + $nodename: +pattern: "^can(@.*)?$" + +additionalProperties: true + +... -- 2.28.0
[PATCH v3] spi: spi-sun6i: implement DMA-based transfer mode
From: Alexander Kochetkov
DMA-based transfer will be enabled if data length is larger than FIFO size
(64 bytes for A64). This greatly reduce number of interrupts for
transferring data.
For smaller data size PIO mode will be used. In PIO mode whole buffer will
be loaded into FIFO.
If driver failed to request DMA channels then it fallback for PIO mode.
Tested on SOPINE (https://www.pine64.org/sopine/)
Signed-off-by: Alexander Kochetkov
---
Changes in v3:
- Remove use_dma from struct sun6i_spi
Changes in v2:
- Fix 'checkpatch.pl --strict' warnings
- Optimezed DMA transfers. Fix burst size and address width for
DMA transfers. The code works for me an I did some tests with different
values and conditions. Empirically found that trigger level used for
PIO mode also can be used for DMA mode (TRM for A64 lacks that
description)
- Handling inside sun6i_spi_handler() leaved as is, it explicity states that
sun6i_spi_drain_fifo() is not used in DMA mode. Yes, if we call
sun6i_spi_drain_fifo() after DMA transfer, it will not drain anything
becase DMA already drain FIFO.
I can remove condition if it's better without it.
drivers/spi/spi-sun6i.c | 194
1 file changed, 176 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 19238e1b76b4..5336c5e32694 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
@@ -52,10 +53,12 @@
#define SUN6I_FIFO_CTL_REG 0x18
#define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_MASK 0xff
+#define SUN6I_FIFO_CTL_RF_DRQ_EN BIT(8)
#define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS 0
#define SUN6I_FIFO_CTL_RF_RST BIT(15)
#define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_MASK 0xff
#define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS 16
+#define SUN6I_FIFO_CTL_TF_DRQ_EN BIT(24)
#define SUN6I_FIFO_CTL_TF_RST BIT(31)
#define SUN6I_FIFO_STA_REG 0x1c
@@ -83,6 +86,8 @@
struct sun6i_spi {
struct spi_master *master;
void __iomem*base_addr;
+ dma_addr_t dma_addr_rx;
+ dma_addr_t dma_addr_tx;
struct clk *hclk;
struct clk *mclk;
struct reset_control*rstc;
@@ -182,6 +187,68 @@ static size_t sun6i_spi_max_transfer_size(struct
spi_device *spi)
return SUN6I_MAX_XFER_SIZE - 1;
}
+static int sun6i_spi_prepare_dma(struct sun6i_spi *sspi,
+struct spi_transfer *tfr)
+{
+ struct dma_async_tx_descriptor *rxdesc, *txdesc;
+ struct spi_master *master = sspi->master;
+
+ rxdesc = NULL;
+ if (tfr->rx_buf) {
+ struct dma_slave_config rxconf = {
+ .direction = DMA_DEV_TO_MEM,
+ .src_addr = sspi->dma_addr_rx,
+ .src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .src_maxburst = 8,
+ };
+
+ dmaengine_slave_config(master->dma_rx, &rxconf);
+
+ rxdesc = dmaengine_prep_slave_sg(master->dma_rx,
+tfr->rx_sg.sgl,
+tfr->rx_sg.nents,
+DMA_DEV_TO_MEM,
+DMA_PREP_INTERRUPT);
+ if (!rxdesc)
+ return -EINVAL;
+ }
+
+ txdesc = NULL;
+ if (tfr->tx_buf) {
+ struct dma_slave_config txconf = {
+ .direction = DMA_MEM_TO_DEV,
+ .dst_addr = sspi->dma_addr_tx,
+ .dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .dst_maxburst = 8,
+ };
+
+ dmaengine_slave_config(master->dma_tx, &txconf);
+
+ txdesc = dmaengine_prep_slave_sg(master->dma_tx,
+tfr->tx_sg.sgl,
+tfr->tx_sg.nents,
+DMA_MEM_TO_DEV,
+DMA_PREP_INTERRUPT);
+ if (!txdesc) {
+ if (rxdesc)
+ dmaengine_terminate_sync(master->dma_rx);
+ return -EINVAL;
+ }
+ }
+
+ if (tfr->rx_buf) {
+ dmaengine_submit(rxdesc);
+ dma_async_issue_pending(master->dma_rx);
+ }
+
+ if (tfr->tx_buf) {
+ dmaengine_submit(txdesc);
+ dma_async_issue_pending(master->dma_tx);
+ }
+
+ return 0;
+}
+
static int sun6i_spi_transfer_one(struct spi_master *master,
struct spi_device *spi,
struct spi_transfer *tfr)
Re: [PATCH 3/5] xen/events: only register debug interrupt for 2-level events
On 22.10.2020 09:42, Juergen Gross wrote:
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -2050,7 +2050,7 @@ void xen_setup_callback_vector(void) {}
> static inline void xen_alloc_callback_vector(void) {}
> #endif
>
> -static bool fifo_events = true;
> +bool fifo_events = true;
When making this non-static, perhaps better to also prefix it with
xen_?
Jan
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
* Lennart Poettering: > On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote: > >> Hi, >> >> There is a problem with glibc+systemd on BTI enabled systems. Systemd >> has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny >> PROT_EXEC changes. Glibc enables BTI only on segments which are marked as >> being BTI compatible by calling mprotect PROT_EXEC|PROT_BTI. That call is >> caught by the seccomp filter, resulting in service failures. >> >> So, at the moment one has to pick either denying PROT_EXEC changes, or BTI. >> This is obviously not desirable. >> >> Various changes have been suggested, replacing the mprotect with mmap calls >> having PROT_BTI set on the original mapping, re-mmapping the segments, >> implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set, >> and various modification to seccomp to allow particular mprotect cases to >> bypass the filters. In each case there seems to be an undesirable attribute >> to the solution. >> >> So, whats the best solution? > > Did you see Topi's comments on the systemd issue? > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 > > I think I agree with this: it's a bit weird to alter the bits after > the fact. Can't glibc set up everything right from the begining? That > would keep both concepts working. The dynamic loader has to process the LOAD segments to get to the ELF note that says to enable BTI. Maybe we could do a first pass and load only the segments that cover notes. But that requires lots of changes to generic code in the loader. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Re: [PATCH v2] usb: dwc3: Trigger a GCTL soft reset when switching modes in DRD
Hi, John Stultz writes: > From: Yu Chen > > With the current dwc3 code on the HiKey960 we often see the > COREIDLE flag get stuck off in __dwc3_gadget_start(), which > seems to prevent the reset irq and causes the USB gadget to > fail to initialize. > > We had seen occasional initialization failures with older > kernels but with recent 5.x era kernels it seemed to be becoming > much more common, so I dug back through some older trees and > realized I dropped this quirk from Yu Chen during upstreaming > as I couldn't provide a proper rational for it and it didn't > seem to be necessary. I now realize I was wrong. This keeps coming back every few years. It has never been necessary so far. Why is it necessary now? The only thing we need to do is verify which registers are shadowed between host and peripheral roles and cache only those registers. A full soft reset will take a while and is likely to create other issues. -- balbi signature.asc Description: PGP signature
Re: [PATCH 4/5] xen/events: unmask a fifo event channel only if it was masked
On 22.10.2020 09:42, Juergen Gross wrote:
> --- a/drivers/xen/events/events_fifo.c
> +++ b/drivers/xen/events/events_fifo.c
> @@ -236,6 +236,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
>
> w = *word;
>
> + if (!(w & (1 << EVTCHN_FIFO_MASKED)))
> + return true;
Maybe better move this ...
> do {
> if (w & (1 << EVTCHN_FIFO_PENDING))
> return false;
>
... into the loop, above this check?
Jan
Re: [PATCH v2] usb: dwc3: Trigger a GCTL soft reset when switching modes in DRD
Hi,
Thinh Nguyen writes:
> John Stultz wrote:
>> static void __dwc3_set_mode(struct work_struct *work)
>> {
>> struct dwc3 *dwc = work_to_dwc(work);
>> unsigned long flags;
>> +int hw_mode;
>> int ret;
>> u32 reg;
>>
>> @@ -154,6 +168,11 @@ static void __dwc3_set_mode(struct work_struct *work)
>> break;
>> }
>>
>> +/* Execute a GCTL Core Soft Reset when switch mode in DRD*/
>> +hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
>> +if (hw_mode == DWC3_GHWPARAMS0_MODE_DRD)
>> +dwc3_gctl_core_soft_reset(dwc);
>> +
>
> I think this should be done inside the spin_lock.
>
>> spin_lock_irqsave(&dwc->lock, flags);
>>
>> dwc3_set_prtcap(dwc, dwc->desired_dr_role);
>
> The DRD mode change sequence should be like this if we want to switch
> from host -> device according to the programming guide (for all DRD IPs):
> 1. Reset controller with GCTL.CoreSoftReset
> 2. Set GCTL.PrtCapDir(device)
> 3. Soft reset with DCTL.CSftRst
> 4. Then follow up with the initializing registers sequence
>
> However, from code review, with this patch, it follows this sequence:
> a. Soft reset with DCTL.CSftRst on driver probe
> b. Reset controller with GCTL.CoreSoftReset
> c. Set GCTL.PrtCapDir(device)
> d. < missing DCTL.CSftRst >
> e. Then follow up with initializing registers sequence
>
> It may work, but it doesn't follow the programming guide.
>
> For device -> host, it should be fine because the xHCI driver will do
> USBCMD.HCRST during initialization.
The only reason why this is needed is because SNPS saves some die area
by mapping some host and peripheral register to the same physical area
in the die. I still think a full soft reset is unnecessary as we have
been running this driver without that soft reset for several years now.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v8 -tip 02/26] sched: Introduce sched_class::pick_task()
On 2020/10/20 9:43, Joel Fernandes (Google) wrote:
> From: Peter Zijlstra
>
> Because sched_class::pick_next_task() also implies
> sched_class::set_next_task() (and possibly put_prev_task() and
> newidle_balance) it is not state invariant. This makes it unsuitable
> for remote task selection.
>
> Tested-by: Julien Desfossez
> Signed-off-by: Peter Zijlstra (Intel)
> Signed-off-by: Vineeth Remanan Pillai
> Signed-off-by: Julien Desfossez
> Signed-off-by: Joel Fernandes (Google)
> ---
> kernel/sched/deadline.c | 16 ++--
> kernel/sched/fair.c | 32 +++-
> kernel/sched/idle.c | 8
> kernel/sched/rt.c| 14 --
> kernel/sched/sched.h | 3 +++
> kernel/sched/stop_task.c | 13 +++--
> 6 files changed, 79 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 814ec49502b1..0271a7848ab3 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1848,7 +1848,7 @@ static struct sched_dl_entity
> *pick_next_dl_entity(struct rq *rq,
> return rb_entry(left, struct sched_dl_entity, rb_node);
> }
>
> -static struct task_struct *pick_next_task_dl(struct rq *rq)
> +static struct task_struct *pick_task_dl(struct rq *rq)
> {
> struct sched_dl_entity *dl_se;
> struct dl_rq *dl_rq = &rq->dl;
> @@ -1860,7 +1860,18 @@ static struct task_struct *pick_next_task_dl(struct rq
> *rq)
> dl_se = pick_next_dl_entity(rq, dl_rq);
> BUG_ON(!dl_se);
> p = dl_task_of(dl_se);
> - set_next_task_dl(rq, p, true);
> +
> + return p;
> +}
> +
> +static struct task_struct *pick_next_task_dl(struct rq *rq)
> +{
> + struct task_struct *p;
> +
> + p = pick_task_dl(rq);
> + if (p)
> + set_next_task_dl(rq, p, true);
> +
> return p;
> }
>
> @@ -2517,6 +2528,7 @@ const struct sched_class dl_sched_class
>
> #ifdef CONFIG_SMP
> .balance= balance_dl,
> + .pick_task = pick_task_dl,
> .select_task_rq = select_task_rq_dl,
> .migrate_task_rq= migrate_task_rq_dl,
> .set_cpus_allowed = set_cpus_allowed_dl,
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index dbd9368a959d..bd6aed63f5e3 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4450,7 +4450,7 @@ pick_next_entity(struct cfs_rq *cfs_rq, struct
> sched_entity *curr)
>* Avoid running the skip buddy, if running something else can
>* be done without getting too unfair.
>*/
> - if (cfs_rq->skip == se) {
> + if (cfs_rq->skip && cfs_rq->skip == se) {
> struct sched_entity *second;
>
> if (se == curr) {
> @@ -6976,6 +6976,35 @@ static void check_preempt_wakeup(struct rq *rq, struct
> task_struct *p, int wake_
> set_last_buddy(se);
> }
>
> +#ifdef CONFIG_SMP
> +static struct task_struct *pick_task_fair(struct rq *rq)
> +{
> + struct cfs_rq *cfs_rq = &rq->cfs;
> + struct sched_entity *se;
> +
> + if (!cfs_rq->nr_running)
> + return NULL;
> +
> + do {
> + struct sched_entity *curr = cfs_rq->curr;
> +
> + se = pick_next_entity(cfs_rq, NULL);
> +
> + if (curr) {
> + if (se && curr->on_rq)
> + update_curr(cfs_rq);
> +
> + if (!se || entity_before(curr, se))
> + se = curr;
> + }
> +
> + cfs_rq = group_cfs_rq(se);
> + } while (cfs_rq);
> +
> + return task_of(se);
> +}
> +#endif
One of my machines hangs when I run uperf with only one message:
[ 719.034962] BUG: kernel NULL pointer dereference, address: 0050
Then I replicated the problem on my another machine(no serial console),
here is the stack by manual copy.
Call Trace:
pick_next_entity+0xb0/0x160
pick_task_fair+0x4b/0x90
__schedule+0x59b/0x12f0
schedule_idle+0x1e/0x40
do_idle+0x193/0x2d0
cpu_startup_entry+0x19/0x20
start_secondary+0x110/0x150
secondary_startup_64_no_verify+0xa6/0xab
> +
> struct task_struct *
> pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags
> *rf)
> {
> @@ -11173,6 +11202,7 @@ const struct sched_class fair_sched_class
>
> #ifdef CONFIG_SMP
> .balance= balance_fair,
> + .pick_task = pick_task_fair,
> .select_task_rq = select_task_rq_fair,
> .migrate_task_rq= migrate_task_rq_fair,
>
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index 8ce6e80352cf..ce7552c6bc65 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -405,6 +405,13 @@ static void set_next_task_idle(struct rq *rq, struct
> task_struct *next, bool fir
> schedstat_inc(rq->sched_goidle);
> }
>
> +#ifdef CONFIG_SMP
> +static struct task_struct *pick_task_idle(struct rq *rq)
> +{
> + return rq->idle;
> +}
>
Re: [PATCH V3 1/4] misc: vop: change the way of allocating vring and device page
Hi Sherry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on soc/for-next linus/master v5.9 next-20201022]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sherry-Sun/Change-vring-space-from-nomal-memory-to-dma-coherent-memory/20201022-131008
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
f3277cbfba763cd2826396521b9296de67cf1bbc
config: i386-randconfig-s002-20201022 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-dirty
#
https://github.com/0day-ci/linux/commit/6851e84ec2f16ab12b04b2a5bf61b05465d450e6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Sherry-Sun/Change-vring-space-from-nomal-memory-to-dma-coherent-memory/20201022-131008
git checkout 6851e84ec2f16ab12b04b2a5bf61b05465d450e6
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/misc/mic/vop/vop_vringh.c:1052:29: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned long @@ got
>> restricted __le64 [usertype] address @@
>> drivers/misc/mic/vop/vop_vringh.c:1052:29: sparse: expected unsigned long
>> drivers/misc/mic/vop/vop_vringh.c:1052:29: sparse: got restricted __le64
>> [usertype] address
vim +1052 drivers/misc/mic/vop/vop_vringh.c
1024
1025 static inline int
1026 vop_query_offset(struct vop_vdev *vdev, unsigned long offset,
1027 unsigned long *size, unsigned long *pa)
1028 {
1029 struct vop_device *vpdev = vdev->vpdev;
1030 struct mic_vqconfig *vqconfig = mic_vq_config(vdev->dd);
1031 unsigned long start = MIC_DP_SIZE;
1032 int i;
1033
1034 /*
1035 * MMAP interface is as follows:
1036 * offset region
1037 * 0x0 virtio device_page
1038 * 0x1000 first vring
1039 * 0x1000 + size of 1st vring second vring
1040 *
1041 */
1042 if (!offset) {
1043 *pa = virt_to_phys(vpdev->hw_ops->get_dp(vpdev));
1044 *size = MIC_DP_SIZE;
1045 return 0;
1046 }
1047
1048 for (i = 0; i < vdev->dd->num_vq; i++) {
1049 struct vop_vringh *vvr = &vdev->vvr[i];
1050
1051 if (offset == start) {
> 1052 *pa = vqconfig[i].address;
1053 *size = vvr->vring.len;
1054 return 0;
1055 }
1056 start += vvr->vring.len;
1057 }
1058 return -1;
1059 }
1060
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] perf/x86/intel: make anythread filter support conditional
On Wed, Oct 21, 2020 at 02:16:12PM -0700, Stephane Eranian wrote:
> Starting with Arch Perfmon v5, the anythread filter on generic counters may be
> deprecated. The current kernel was exporting the any filter without checking.
> On Icelake, it means you could do cpu/event=0x3c,any/ even though the filter
> does not exist. This patch corrects the problem by relying on the CPUID 0xa
> leaf
> function to determine if anythread is supported or not as described in the
> Intel SDM Vol3b 18.2.5.1 AnyThread Deprecation section.
>
> Signed-off-by: Stephane Eranian
> ---
> arch/x86/events/intel/core.c | 20
> arch/x86/events/perf_event.h | 1 +
> arch/x86/include/asm/perf_event.h | 4 +++-
> arch/x86/kvm/cpuid.c | 4 +++-
> 4 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index f1926e9f2143..65bf649048a6 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -4220,6 +4220,16 @@ static struct attribute *intel_arch3_formats_attr[] = {
> NULL,
> };
>
> +static struct attribute *intel_arch5_formats_attr[] = {
> + &format_attr_event.attr,
> + &format_attr_umask.attr,
> + &format_attr_edge.attr,
> + &format_attr_pc.attr,
> + &format_attr_inv.attr,
> + &format_attr_cmask.attr,
> + NULL,
> +};
Instead of adding yet another (which is an exact duplicate of the
existing intel_arch_formats_attr BTW), can't we clean this up and use
is_visible() as 'demanded' by GregKH and done by Jiri here:
3d5672735b23 ("perf/x86: Add is_visible attribute_group callback for base
events")
b7c9b3927337 ("perf/x86/intel: Use ->is_visible callback for default group")
baa0c83363c7 ("perf/x86: Use the new pmu::update_attrs attribute group")
And only have "any" visible for v3,v4
Re: [PATCH 1/2] coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf()
On 2020-10-21 15:38, Suzuki Poulose wrote: On 10/21/20 8:29 AM, Sai Prakash Ranjan wrote: On 2020-10-20 21:40, Sai Prakash Ranjan wrote: On 2020-10-14 21:29, Sai Prakash Ranjan wrote: On 2020-10-14 18:46, Suzuki K Poulose wrote: On 10/14/2020 10:36 AM, Sai Prakash Ranjan wrote: On 2020-10-13 22:05, Suzuki K Poulose wrote: On 10/07/2020 02:00 PM, Sai Prakash Ranjan wrote: There was a report of NULL pointer dereference in ETF enable path for perf CS mode with PID monitoring. It is almost 100% reproducible when the process to monitor is something very active such as chrome and with ETF as the sink and not ETR. Currently in a bid to find the pid, the owner is dereferenced via task_pid_nr() call in tmc_enable_etf_sink_perf() and with owner being NULL, we get a NULL pointer dereference. Looking at the ETR and other places in the kernel, ETF and the ETB are the only places trying to dereference the task(owner) in tmc_enable_etf_sink_perf() which is also called from the sched_in path as in the call trace. Owner(task) is NULL even in the case of ETR in tmc_enable_etr_sink_perf(), but since we cache the PID in alloc_buffer() callback and it is done as part of etm_setup_aux() when allocating buffer for ETR sink, we never dereference this NULL pointer and we are safe. So lets do the The patch is necessary to fix some of the issues. But I feel it is not complete. Why is it safe earlier and not later ? I believe we are simply reducing the chances of hitting the issue, by doing this earlier than later. I would say we better fix all instances to make sure that the event->owner is valid. (e.g, I can see that the for kernel events event->owner == -1 ?) struct task_struct *tsk = READ_ONCE(event->owner); if (!tsk || is_kernel_event(event)) /* skip ? */ Looking at it some more, is_kernel_event() is not exposed outside events core and probably for good reason. Why do we need to check for this and not just tsk? Because the event->owner could be : = NULL = -1UL // kernel event = valid. Yes I understood that part, but here we were trying to fix the NULL pointer dereference right and hence the question as to why we need to check for kernel events? I am no expert in perf but I don't see anywhere in the kernel checking for is_kernel_event(), so I am a bit skeptical if exporting that is actually right or not. I have stress tested with the original patch many times now, i.e., without a check for event->owner and is_kernel_event() and didn't observe any crash. Plus on ETR where this was already done, no crashes were reported till date and with ETF, the issue was quickly reproducible, so I am fairly confident that this doesn't just delay the original issue but actually fixes it. I will run an overnight test again to confirm this. I ran the overnight test which collected aroung 4G data(see below), with the following small change to see if the two cases (event->owner=NULL and is_kernel_event()) are triggered with suggested changes and it didn't trigger at all. Do we still need those additional checks? Yes. Please see perf_event_create_kernel_event(), which is an exported function allowing any kernel code (including modules) to use the PMU (just like the userspace perf tool would do). Just because your use case doesn't trigger this (because you don't run something that can trigger this) doesn't mean this can't be triggered. Thanks for that pointer, I will add them in the next version. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 0/5] xen: event handling cleanup
On 22.10.2020 09:42, Juergen Gross wrote: > Do some cleanups in Xen event handling code. > > Juergen Gross (5): > xen: remove no longer used functions > xen/events: make struct irq_info private to events_base.c > xen/events: only register debug interrupt for 2-level events > xen/events: unmask a fifo event channel only if it was masked > Documentation: add xen.fifo_events kernel parameter description With the two remarks to individual patches suitably taken care of one way or another Reviewed-by: Jan Beulich Jan
[PATCH v2 1/3] mmc: core: Initial support for SD express card/host
From: Ulf Hansson
In the SD specification v7.10 the SD express card has been added. This new
type of removable SD card, can be managed via a PCIe/NVMe based interface,
while also allowing backwards compatibility towards the legacy SD
interface.
To keep the backwards compatibility, it's required to start the
initialization through the legacy SD interface. If it turns out that the
mmc host and the SD card, both supports the PCIe/NVMe interface, then a
switch should be allowed.
Therefore, let's introduce some basic support for this type of SD cards to
the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it supports this
interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is supported, as to inform
the core about it.
To deal with the switch to the PCIe/NVMe interface, the mmc host is
required to implement a new host ops, ->init_sd_express(). Based on the
initial communication between the host and the card, host->ios.timing is
set to either MMC_TIMING_SD_EXP or MMC_TIMING_SD_EXP_1_2V, depending on if
1.2V is supported or not. In this way, the mmc host can check these values
in its ->init_sd_express() ops, to know how to proceed with the handover.
Note that, to manage card insert/removal, the mmc core sticks with using
the ->get_cd() callback, which means it's the host's responsibility to make
sure it provides valid data, even if the card may be managed by PCIe/NVMe
at the moment. As long as the card seems to be present, the mmc core keeps
the card powered on.
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: Christoph Hellwig
Cc: Rui Feng
Signed-off-by: Ulf Hansson
Reviewed-by: Greg Kroah-Hartman
---
drivers/mmc/core/core.c | 15 ++--
drivers/mmc/core/host.h | 6 +
drivers/mmc/core/sd_ops.c | 49 +--
drivers/mmc/core/sd_ops.h | 1 +
include/linux/mmc/host.h | 7 ++
5 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 8ccae6452b9c..6673c0f33cc7 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2137,8 +2137,12 @@ static int mmc_rescan_try_freq(struct mmc_host *host,
unsigned freq)
mmc_go_idle(host);
- if (!(host->caps2 & MMC_CAP2_NO_SD))
- mmc_send_if_cond(host, host->ocr_avail);
+ if (!(host->caps2 & MMC_CAP2_NO_SD)) {
+ if (mmc_send_if_cond_pcie(host, host->ocr_avail))
+ goto out;
+ if (mmc_card_sd_express(host))
+ return 0;
+ }
/* Order's important: probe SDIO, then SD, then MMC */
if (!(host->caps2 & MMC_CAP2_NO_SDIO))
@@ -2153,6 +2157,7 @@ static int mmc_rescan_try_freq(struct mmc_host *host,
unsigned freq)
if (!mmc_attach_mmc(host))
return 0;
+out:
mmc_power_off(host);
return -EIO;
}
@@ -2280,6 +2285,12 @@ void mmc_rescan(struct work_struct *work)
goto out;
}
+ /* If an SD express card is present, then leave it as is. */
+ if (mmc_card_sd_express(host)) {
+ mmc_release_host(host);
+ goto out;
+ }
+
for (i = 0; i < ARRAY_SIZE(freqs); i++) {
unsigned int freq = freqs[i];
if (freq > host->f_max) {
diff --git a/drivers/mmc/core/host.h b/drivers/mmc/core/host.h
index 5e3b9534ffb2..ba407617ed23 100644
--- a/drivers/mmc/core/host.h
+++ b/drivers/mmc/core/host.h
@@ -77,5 +77,11 @@ static inline bool mmc_card_hs400es(struct mmc_card *card)
return card->host->ios.enhanced_strobe;
}
+static inline bool mmc_card_sd_express(struct mmc_host *host)
+{
+ return host->ios.timing == MMC_TIMING_SD_EXP ||
+ host->ios.timing == MMC_TIMING_SD_EXP_1_2V;
+}
+
#endif
diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd_ops.c
index 22bf528294b9..d61ff811218c 100644
--- a/drivers/mmc/core/sd_ops.c
+++ b/drivers/mmc/core/sd_ops.c
@@ -158,7 +158,8 @@ int mmc_send_app_op_cond(struct mmc_host *host, u32 ocr,
u32 *rocr)
return err;
}
-int mmc_send_if_cond(struct mmc_host *host, u32 ocr)
+static int __mmc_send_if_cond(struct mmc_host *host, u32 ocr, u8 pcie_bits,
+ u32 *resp)
{
struct mmc_command cmd = {};
int err;
@@ -171,7 +172,7 @@ int mmc_send_if_cond(struct mmc_host *host, u32 ocr)
* SD 1.0 cards.
*/
cmd.opcode = SD_SEND_IF_COND;
- cmd.arg = ((ocr & 0xFF8000) != 0) << 8 | test_pattern;
+ cmd.arg = ((ocr & 0xFF8000) != 0) << 8 | pcie_bits << 8 | test_pattern;
cmd.flags = MMC_RSP_SPI_R7 | MMC_RSP_R7 | MMC_CMD_BCR;
err = mmc_wait_for_cmd(host, &cmd, 0);
@@ -186,6 +187,50 @@ int mmc_send_if_cond(struct mmc_host *host, u32 ocr)
if (result_pattern != test_pattern)
return -EIO;
+ if (resp)
+ *resp = cmd.resp[0];
+
+ return 0;
+}
+
+int mmc_send_if_cond(struct mmc_host *host, u32 oc
[PATCH v2 2/3] misc: rtsx: Add SD Express mode support for RTS5261
From: Rui Feng
RTS5261 support SD mode and PCIe/NVMe mode. The workflow is as follows.
1.RTS5261 work in SD mode and set MMC_CAPS2_SD_EXP flag.
2.If card is plugged in, Host send CMD8 to ask card's PCIe availability.
3.If the card has PCIe availability and WP is not set, init_sd_express() will
be invoked,
RTS5261 switch to PCIe/NVMe mode.
4.Mmc driver handover it to NVMe driver.
5.If card is unplugged, RTS5261 will switch to SD mode.
Signed-off-by: Rui Feng
---
v2:remove duplicate define
---
drivers/misc/cardreader/rts5261.c | 4
drivers/misc/cardreader/rts5261.h | 23 ---
drivers/misc/cardreader/rtsx_pcr.c | 5 +
include/linux/rtsx_pci.h | 23 +++
4 files changed, 32 insertions(+), 23 deletions(-)
diff --git a/drivers/misc/cardreader/rts5261.c
b/drivers/misc/cardreader/rts5261.c
index 471961487ff8..536c90d4fd76 100644
--- a/drivers/misc/cardreader/rts5261.c
+++ b/drivers/misc/cardreader/rts5261.c
@@ -738,8 +738,12 @@ void rts5261_init_params(struct rtsx_pcr *pcr)
{
struct rtsx_cr_option *option = &pcr->option;
struct rtsx_hw_param *hw_param = &pcr->hw_param;
+ u8 val;
pcr->extra_caps = EXTRA_CAPS_SD_SDR50 | EXTRA_CAPS_SD_SDR104;
+ rtsx_pci_read_register(pcr, RTS5261_FW_STATUS, &val);
+ if (!(val & RTS5261_EXPRESS_LINK_FAIL_MASK))
+ pcr->extra_caps |= EXTRA_CAPS_SD_EXPRESS;
pcr->num_slots = 1;
pcr->ops = &rts5261_pcr_ops;
diff --git a/drivers/misc/cardreader/rts5261.h
b/drivers/misc/cardreader/rts5261.h
index ebfdd236a553..8d80f0d5d5d6 100644
--- a/drivers/misc/cardreader/rts5261.h
+++ b/drivers/misc/cardreader/rts5261.h
@@ -65,23 +65,6 @@
#define RTS5261_FW_EXPRESS_TEST_MASK (0x01<<0)
#define RTS5261_FW_EA_MODE_MASK(0x01<<5)
-/* FW config register */
-#define RTS5261_FW_CFG00xFF54
-#define RTS5261_FW_ENTER_EXPRESS (0x01<<0)
-
-#define RTS5261_FW_CFG10xFF55
-#define RTS5261_SYS_CLK_SEL_MCU_CLK(0x01<<7)
-#define RTS5261_CRC_CLK_SEL_MCU_CLK(0x01<<6)
-#define RTS5261_FAKE_MCU_CLOCK_GATING (0x01<<5)
-/*MCU_bus_mode_sel: 0=real 8051 1=fake mcu*/
-#define RTS5261_MCU_BUS_SEL_MASK (0x01<<4)
-/*MCU_clock_sel:VerA 00=aux16M 01=aux400K 1x=REFCLK100M*/
-/*MCU_clock_sel:VerB 00=aux400K 01=aux16M 10=REFCLK100M*/
-#define RTS5261_MCU_CLOCK_SEL_MASK (0x03<<2)
-#define RTS5261_MCU_CLOCK_SEL_16M (0x01<<2)
-#define RTS5261_MCU_CLOCK_GATING (0x01<<1)
-#define RTS5261_DRIVER_ENABLE_FW (0x01<<0)
-
/* FW status register */
#define RTS5261_FW_STATUS 0xFF56
#define RTS5261_EXPRESS_LINK_FAIL_MASK (0x01<<7)
@@ -121,12 +104,6 @@
#define RTS5261_DV3318_19 (0x04<<4)
#define RTS5261_DV3318_33 (0x07<<4)
-#define RTS5261_LDO1_CFG0 0xFF72
-#define RTS5261_LDO1_OCP_THD_MASK (0x07<<5)
-#define RTS5261_LDO1_OCP_EN(0x01<<4)
-#define RTS5261_LDO1_OCP_LMT_THD_MASK (0x03<<2)
-#define RTS5261_LDO1_OCP_LMT_EN(0x01<<1)
-
/* CRD6603-433 190319 request changed */
#define RTS5261_LDO1_OCP_THD_740 (0x00<<5)
#define RTS5261_LDO1_OCP_THD_800 (0x01<<5)
diff --git a/drivers/misc/cardreader/rtsx_pcr.c
b/drivers/misc/cardreader/rtsx_pcr.c
index 37ccc67f4914..6e5c16b4b7d1 100644
--- a/drivers/misc/cardreader/rtsx_pcr.c
+++ b/drivers/misc/cardreader/rtsx_pcr.c
@@ -990,6 +990,11 @@ static irqreturn_t rtsx_pci_isr(int irq, void *dev_id)
} else {
pcr->card_removed |= SD_EXIST;
pcr->card_inserted &= ~SD_EXIST;
+ if (PCI_PID(pcr) == PID_5261) {
+ rtsx_pci_write_register(pcr, RTS5261_FW_STATUS,
+ RTS5261_EXPRESS_LINK_FAIL_MASK, 0);
+ pcr->extra_caps |= EXTRA_CAPS_SD_EXPRESS;
+ }
}
pcr->dma_error_count = 0;
}
diff --git a/include/linux/rtsx_pci.h b/include/linux/rtsx_pci.h
index 745f5e73f99a..b47959f48ccd 100644
--- a/include/linux/rtsx_pci.h
+++ b/include/linux/rtsx_pci.h
@@ -658,6 +658,19 @@
#define PM_WAKE_EN 0x01
#define PM_CTRL4 0xFF47
+#define RTS5261_FW_CFG00xFF54
+#define RTS5261_FW_ENTER_EXPRESS (0x01 << 0)
+
+#define RTS5261_FW_CFG10xFF55
+#define RTS5261_SYS_CLK_SEL_MCU_CLK (0x01 << 7)
+#define RTS5261_CRC_CLK_SEL_MCU_CLK (0x01 << 6)
+#define RTS5261_FAKE_MCU_CLOCK_GATING(0x01 << 5)
+#define RTS5261_MCU_BUS_SEL_MASK (0x01 << 4)
+#define RTS5261_MCU_CLOCK_SEL_MASK (0x03 << 2)
+#define RTS5261_MCU_CLOCK_SEL_16M(0x01 << 2)
+#define RTS5261_MCU_CLOCK_GATING (0x01 << 1)
+#define RTS5261_DRIVER_ENABLE_FW (0x01 << 0)
+
#define REG_CFG_OOBS_OFF_TIMER 0xFEA6
#define REG_CFG_OOBS_ON_TIMER 0xFEA7
#define REG_CFG_VCM_ON
Re: [RFC] Have insn decoder functions return success/failure
On Wed, Oct 21, 2020 at 06:45:58PM +0200, Borislav Petkov wrote:
> On Wed, Oct 21, 2020 at 11:26:13PM +0900, Masami Hiramatsu wrote:
> > Hmm, I meant someone might think it can be used for filtering the
> > instruction something like,
> >
> > insn_init(insn, buf, buflen, 1);
> > ret = insn_get_length(insn);
> > if (!ret) {
> > /* OK, this is safe */
> > patch_text(buf, trampoline);
> > }
> >
> > No, we need another validator for such usage.
>
> Well, I think calling insn_get_length() should give you only the
> *length* of the insn and nothing else - I mean that is what the function
> is called. And I believe current use is wrong.
>
> Examples:
>
> arch/x86/kernel/kprobes/core.c:
> insn_get_length(&insn);
>
> /*
> * Another debugging subsystem might insert this breakpoint.
> * In that case, we can't recover it.
> */
> if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
>
> So this has called get_length but it is far from clear that after that
> call, the opcode bytes in insn.opcode.bytes are there.
Given the trainwreck called x86-instruction-encoding, it's impossible to
not have decoded the opcode and still know the length. Therefore, if you
know the length, you also have the opcode. Hm?
[PATCH v2 3/3] mmc: rtsx: Add SD Express mode support for RTS5261
From: Rui Feng
RTS5261 support SD mode and PCIe/NVMe mode. The workflow is as follows.
1.RTS5261 work in SD mode and set MMC_CAPS2_SD_EXP flag.
2.If card is plugged in, Host send CMD8 to ask card's PCIe availability.
3.If the card has PCIe availability and WP is not set, init_sd_express() will
be invoked,
RTS5261 switch to PCIe/NVMe mode.
4.Mmc driver handover it to NVMe driver.
5.If card is unplugged, RTS5261 will switch to SD mode.
Signed-off-by: Rui Feng
---
v2:
1.re-enable mmc caps in sd_power_on()
2.don't check write protect bit in init_sd_express()
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 52 +++
1 file changed, 52 insertions(+)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 2763a376b054..a6c89f739035 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -895,7 +895,9 @@ static int sd_set_bus_width(struct realtek_pci_sdmmc *host,
static int sd_power_on(struct realtek_pci_sdmmc *host)
{
struct rtsx_pcr *pcr = host->pcr;
+ struct mmc_host *mmc = host->mmc;
int err;
+ u32 val;
if (host->power_state == SDMMC_POWER_ON)
return 0;
@@ -922,6 +924,16 @@ static int sd_power_on(struct realtek_pci_sdmmc *host)
if (err < 0)
return err;
+ if (PCI_PID(pcr) == PID_5261) {
+ if (pcr->extra_caps & EXTRA_CAPS_SD_EXPRESS)
+ mmc->caps2 |= MMC_CAP2_SD_EXP | MMC_CAP2_SD_EXP_1_2V;
+ val = rtsx_pci_readl(pcr, RTSX_BIPR);
+ if (val & SD_WRITE_PROTECT) {
+ pcr->extra_caps &= ~EXTRA_CAPS_SD_EXPRESS;
+ mmc->caps2 &= ~(MMC_CAP2_SD_EXP | MMC_CAP2_SD_EXP_1_2V);
+ }
+ }
+
host->power_state = SDMMC_POWER_ON;
return 0;
}
@@ -1308,6 +1320,43 @@ static int sdmmc_execute_tuning(struct mmc_host *mmc,
u32 opcode)
return err;
}
+static int sdmmc_init_sd_express(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+ u32 relink_time;
+ struct realtek_pci_sdmmc *host = mmc_priv(mmc);
+ struct rtsx_pcr *pcr = host->pcr;
+
+ /* Set relink_time for changing to PCIe card */
+ relink_time = 0x8FFF;
+
+ rtsx_pci_write_register(pcr, 0xFF01, 0xFF, relink_time);
+ rtsx_pci_write_register(pcr, 0xFF02, 0xFF, relink_time >> 8);
+ rtsx_pci_write_register(pcr, 0xFF03, 0x01, relink_time >> 16);
+
+ rtsx_pci_write_register(pcr, PETXCFG, 0x80, 0x80);
+ rtsx_pci_write_register(pcr, LDO_VCC_CFG0,
+ RTS5261_LDO1_OCP_THD_MASK,
+ pcr->option.sd_800mA_ocp_thd);
+
+ if (pcr->ops->disable_auto_blink)
+ pcr->ops->disable_auto_blink(pcr);
+
+ /* For PCIe/NVMe mode can't enter delink issue */
+ pcr->hw_param.interrupt_en &= ~(SD_INT_EN);
+ rtsx_pci_writel(pcr, RTSX_BIER, pcr->hw_param.interrupt_en);
+
+ rtsx_pci_write_register(pcr, RTS5260_AUTOLOAD_CFG4,
+ RTS5261_AUX_CLK_16M_EN, RTS5261_AUX_CLK_16M_EN);
+ rtsx_pci_write_register(pcr, RTS5261_FW_CFG0,
+ RTS5261_FW_ENTER_EXPRESS, RTS5261_FW_ENTER_EXPRESS);
+ rtsx_pci_write_register(pcr, RTS5261_FW_CFG1,
+ RTS5261_MCU_BUS_SEL_MASK | RTS5261_MCU_CLOCK_SEL_MASK
+ | RTS5261_MCU_CLOCK_GATING | RTS5261_DRIVER_ENABLE_FW,
+ RTS5261_MCU_CLOCK_SEL_16M | RTS5261_MCU_CLOCK_GATING
+ | RTS5261_DRIVER_ENABLE_FW);
+ return 0;
+}
+
static const struct mmc_host_ops realtek_pci_sdmmc_ops = {
.pre_req = sdmmc_pre_req,
.post_req = sdmmc_post_req,
@@ -1317,6 +1366,7 @@ static const struct mmc_host_ops realtek_pci_sdmmc_ops = {
.get_cd = sdmmc_get_cd,
.start_signal_voltage_switch = sdmmc_switch_voltage,
.execute_tuning = sdmmc_execute_tuning,
+ .init_sd_express = sdmmc_init_sd_express,
};
static void init_extra_caps(struct realtek_pci_sdmmc *host)
@@ -1338,6 +1388,8 @@ static void init_extra_caps(struct realtek_pci_sdmmc
*host)
mmc->caps |= MMC_CAP_8_BIT_DATA;
if (pcr->extra_caps & EXTRA_CAPS_NO_MMC)
mmc->caps2 |= MMC_CAP2_NO_MMC;
+ if (pcr->extra_caps & EXTRA_CAPS_SD_EXPRESS)
+ mmc->caps2 |= MMC_CAP2_SD_EXP | MMC_CAP2_SD_EXP_1_2V;
}
static void realtek_init_host(struct realtek_pci_sdmmc *host)
--
2.17.1
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
The 10/22/2020 09:18, Lennart Poettering wrote: > On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote: > > > Hi, > > > > There is a problem with glibc+systemd on BTI enabled systems. Systemd > > has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny > > PROT_EXEC changes. Glibc enables BTI only on segments which are marked as > > being BTI compatible by calling mprotect PROT_EXEC|PROT_BTI. That call is > > caught by the seccomp filter, resulting in service failures. > > > > So, at the moment one has to pick either denying PROT_EXEC changes, or BTI. > > This is obviously not desirable. > > > > Various changes have been suggested, replacing the mprotect with mmap calls > > having PROT_BTI set on the original mapping, re-mmapping the segments, > > implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set, > > and various modification to seccomp to allow particular mprotect cases to > > bypass the filters. In each case there seems to be an undesirable attribute > > to the solution. > > > > So, whats the best solution? > > Did you see Topi's comments on the systemd issue? > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 > > I think I agree with this: it's a bit weird to alter the bits after > the fact. Can't glibc set up everything right from the begining? That > would keep both concepts working. that's hard to do and does not work for the main exe currently (which is mmaped by the kernel). (it's hard to do because to know that the elf module requires bti the PT_GNU_PROPERTY notes have to be accessed that are often in the executable load segment, so either you mmap that or have to read that, but the latter has a lot more failure modes, so if i have to get the mmap flags right i'd do a mmap and then re-mmap if the flags were not right)
[PATCH net RFC v2] net: Clear IFF_TX_SKB_SHARING for all Ethernet devices using skb_padto
The ether_setup function adds the IFF_TX_SKB_SHARING flag to the
device. This flag indicates that it is safe to transmit shared skbs to
the device.
However, this is not true for many Ethernet devices. Many Ethernet
drivers would call skb_pad or skb_padto on the transmission path,
which modify the skb. So it would not be safe to transmit shared skbs to
these devices.
I grepped "skb_padto" under "drivers/net/ethernet", and attempted to fix
all drivers that show up, by clearing the IFF_TX_SKB_SHARING flag for
them.
This patch only tries to fix drivers under "drivers/net/ethernet" that
use "skb_padto". There are other drivers in the kernel also need to be
fixed. It's hard for me to cover all because they are too many.
Another simpler solution is to simply remove IFF_TX_SKB_SHARING from
ether_setup. That would solve all problems and may also make the code
cleaner. So I'm not sure this patch is the best solution. This is why
I'm sending this as a RFC.
For any source file that calls "skb_padto", I searched "alloc_etherdev"
in it. Once found, I added the flag clearing code after it.
Some files that call "skb_padto" don't have "alloc_etherdev" in it,
because the dev is allocated in other files in the same directory.
These files include:
1. drivers/net/ethernet/natsemi/sonic.c:
skb_padto called in sonic_send_packet.
sonic_send_packet is used in xtsonic.c, macsonic.c, jazzsonic.c.
2. drivers/net/ethernet/arc/emac_main.c:
skb_padto called in arc_emac_tx.
arc_emac_tx is used as arc_emac_netdev_ops.ndo_start_xmit.
arc_emac_netdev_ops is used in arc_emac_probe.
arc_emac_probe is used in emac_rockchip.c and emac_arc.c.
Also, the following file is skipped because I couldn't find the
corresponding dev allocation code.
drivers/net/ethernet/i825xx/lib82596.c:
skb_padto called in i596_start_xmit.
i596_start_xmit is used as i596_netdev_ops.ndo_start_xmit.
i596_netdev_ops is used in i82596_probe.
i82596_probe is used nowhere in this file,
and because it is a static function, it cannot be used anywhere else.
Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing
IFF_TX_SKB_SHARING cleared")
Cc: Neil Horman
Cc: Jakub Kicinski
Cc: David S. Miller
Signed-off-by: Xie He
---
drivers/net/ethernet/adaptec/starfire.c | 2 ++
drivers/net/ethernet/amd/a2065.c | 2 ++
drivers/net/ethernet/amd/ariadne.c| 2 ++
drivers/net/ethernet/amd/atarilance.c | 3 +++
drivers/net/ethernet/amd/declance.c | 2 ++
drivers/net/ethernet/amd/lance.c | 5 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 2 ++
drivers/net/ethernet/arc/emac_arc.c | 3 +++
drivers/net/ethernet/arc/emac_rockchip.c | 3 +++
drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 3 +++
drivers/net/ethernet/i825xx/82596.c | 2 ++
drivers/net/ethernet/i825xx/ether1.c | 2 ++
drivers/net/ethernet/intel/igc/igc_main.c | 2 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 ++
drivers/net/ethernet/marvell/skge.c | 2 ++
drivers/net/ethernet/natsemi/jazzsonic.c | 2 ++
drivers/net/ethernet/natsemi/macsonic.c | 2 ++
drivers/net/ethernet/natsemi/xtsonic.c| 2 ++
drivers/net/ethernet/packetengines/yellowfin.c| 2 ++
drivers/net/ethernet/seeq/ether3.c| 2 ++
drivers/net/ethernet/seeq/sgiseeq.c | 2 ++
drivers/net/ethernet/sis/sis190.c | 2 ++
drivers/net/ethernet/smsc/epic100.c | 2 ++
drivers/net/ethernet/smsc/smc9194.c | 2 ++
drivers/net/ethernet/sun/cassini.c| 3 +++
drivers/net/ethernet/ti/cpmac.c | 2 ++
drivers/net/ethernet/ti/cpsw.c| 4
drivers/net/ethernet/ti/cpsw_new.c| 2 ++
drivers/net/ethernet/ti/davinci_emac.c| 2 ++
drivers/net/ethernet/ti/netcp_core.c | 2 ++
drivers/net/ethernet/ti/tlan.c| 3 +++
drivers/net/ethernet/via/via-rhine.c | 3 +++
drivers/net/ethernet/via/via-velocity.c | 2 ++
drivers/net/ethernet/xircom/xirc2ps_cs.c | 3 +++
34 files changed, 81 insertions(+)
diff --git a/drivers/net/ethernet/adaptec/starfire.c
b/drivers/net/ethernet/adaptec/starfire.c
index 555299737b51..66c2a29d736f 100644
--- a/drivers/net/ethernet/adaptec/starfire.c
+++ b/drivers/net/ethernet/adaptec/starfire.c
@@ -655,16 +655,18 @@ static int starfire_init_one(struct pci_dev *pdev,
dev_err(d, "no PCI MEM resources, aborting\n");
return -ENODEV;
}
dev = alloc_etherdev(sizeof(*np));
if (!dev)
return -ENOMEM;
+ dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+
SET_NETDEV_DEV(dev, &pdev->dev);
irq = pdev->irq;
if (pci_request_regions (pdev, DRV_NAME)) {
dev_err(d, "cannot reserve PCI resources, aborting\n");
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On 20-10-20, 07:13, Rob Clark wrote: > On Tue, Oct 20, 2020 at 4:24 AM Viresh Kumar wrote: > > > > On 20-10-20, 12:56, Daniel Vetter wrote: > > > Yeah that's bad practice. Generally you shouldn't need to hold locks > > > in setup/teardown code, since there's no other thread which can > > > possible hold a reference to anything your touching anymore. Ofc > > > excluding quickly grabbing/dropping a lock to insert/remove objects > > > into lists and stuff. > > > > > > The other reason is that especially with anything related to sysfs or > > > debugfs, the locking dependencies you're pulling in are enormous: vfs > > > locks pull in mm locks (due to mmap) and at that point there's pretty > > > much nothing left you're allowed to hold while acquiring such a lock. > > > For simple drivers this is no issue, but for fancy drivers (like gpu > > > drivers) which need to interact with core mm) this means your > > > subsystem is a major pain to use. > > > > > > Usually the correct fix is to only hold your subsystem locks in > > > setup/teardown when absolutely required, and fix any data > > > inconsistency issues by reordering your setup/teardown code: When you > > > register as the last step and unregister as the first step, there's no > > > need for any additional locking. And hence no need to call debugfs > > > functions while holding your subsystem locks. > > > > > > The catch phrase I use for this is "don't solve object lifetime issues > > > with locking". Instead use refcounting and careful ordering in > > > setup/teardown code. > > > > This is exactly what I have done in the OPP core, the locks were taken > > only when really necessary, though as we have seen now I have missed > > that at a single place and that should be fixed as well. Will do that, > > thanks. > > I do have an easy enough way to repro the issue, so if you have a > patch I can certainly test it. Does this fix it for you ? There is one more place still left where we are taking the opp_table_lock while adding stuff to debugfs and that's not that straight forward to fix. But I didn't see that path in your circular dependency trace, so who knows :) diff --git a/drivers/opp/core.c b/drivers/opp/core.c index 2483e765318a..4cc0fb716381 100644 --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -1181,6 +1181,10 @@ static void _opp_table_kref_release(struct kref *kref) struct opp_device *opp_dev, *temp; int i; + /* Drop the lock as soon as we can */ + list_del(&opp_table->node); + mutex_unlock(&opp_table_lock); + _of_clear_opp_table(opp_table); /* Release clk */ @@ -1208,10 +1212,7 @@ static void _opp_table_kref_release(struct kref *kref) mutex_destroy(&opp_table->genpd_virt_dev_lock); mutex_destroy(&opp_table->lock); - list_del(&opp_table->node); kfree(opp_table); - - mutex_unlock(&opp_table_lock); } void dev_pm_opp_put_opp_table(struct opp_table *opp_table) -- viresh
Re: [PATCH] mm,thp,shmem: limit shmem THP alloc gfp_mask
On Wed 21-10-20 23:48:46, Rik van Riel wrote: > The allocation flags of anonymous transparent huge pages can be controlled > through the files in /sys/kernel/mm/transparent_hugepage/defrag, which can > help the system from getting bogged down in the page reclaim and compaction > code when many THPs are getting allocated simultaneously. > > However, the gfp_mask for shmem THP allocations were not limited by those > configuration settings, and some workloads ended up with all CPUs stuck > on the LRU lock in the page reclaim code, trying to allocate dozens of > THPs simultaneously. > > This patch applies the same configurated limitation of THPs to shmem > hugepage allocations, to prevent that from happening. > > This way a THP defrag setting of "never" or "defer+madvise" will result > in quick allocation failures without direct reclaim when no 2MB free > pages are available. I remmeber I wanted to unify this in the past as well. The patch got reverted in the end. It was a long story and I do not have time to read through lengthy discussions again. I do remember though that there were some objections pointing out that shmem has its own behavior which is controlled by the mount option - at least for the explicitly mounted shmems. I might misremember. [...] > diff --git a/mm/shmem.c b/mm/shmem.c > index 537c137698f8..d1290eb508e5 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -1545,8 +1545,11 @@ static struct page *shmem_alloc_hugepage(gfp_t gfp, > return NULL; > > shmem_pseudo_vma_init(&pvma, info, hindex); > - page = alloc_pages_vma(gfp | __GFP_COMP | __GFP_NORETRY | __GFP_NOWARN, > - HPAGE_PMD_ORDER, &pvma, 0, numa_node_id(), true); > + /* Limit the gfp mask according to THP configuration. */ > + gfp |= __GFP_COMP | __GFP_NORETRY | __GFP_NOWARN; What is the reason for these when alloc_hugepage_direct_gfpmask provides the full mask? > + gfp &= alloc_hugepage_direct_gfpmask(&pvma); > + page = alloc_pages_vma(gfp, HPAGE_PMD_ORDER, &pvma, 0, numa_node_id(), > +true); > shmem_pseudo_vma_destroy(&pvma); > if (page) > prep_transhuge_page(page); > > -- > All rights reversed. -- Michal Hocko SUSE Labs
drivers/scsi/fnic/vnic_dev.c:332:32: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f804b3159482eedbb4250b1e9248c308fb63b805
commit: 8f28ca6bd8211214faf717677bbffe375c2a6072 iomap: constify ioreadX()
iomem argument (as in generic implementation)
date: 10 weeks ago
config: x86_64-randconfig-s031-20201022 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f28ca6bd8211214faf717677bbffe375c2a6072
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 8f28ca6bd8211214faf717677bbffe375c2a6072
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/scsi/fnic/vnic_dev.c:332:32: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const [noderef]
>> __iomem * @@ got unsigned int * @@
>> drivers/scsi/fnic/vnic_dev.c:332:32: sparse: expected void const
>> [noderef] __iomem *
drivers/scsi/fnic/vnic_dev.c:332:32: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const [noderef]
__iomem * @@ got unsigned int * @@
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: expected void const
[noderef] __iomem *
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void [noderef] __iomem *
@@ got unsigned int * @@
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: expected void [noderef]
__iomem *
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected struct vnic_wq_ctrl
*wq_ctrl @@ got struct vnic_wq_ctrl [noderef] __iomem *ctrl @@
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: expected struct
vnic_wq_ctrl *wq_ctrl
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: got struct vnic_wq_ctrl
[noderef] __iomem *ctrl
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected void *p @@ got void
[noderef] __iomem * @@
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: expected void *p
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: got void [noderef] __iomem *
vim +332 drivers/scsi/fnic/vnic_dev.c
5df6d737dd4b0fe Abhijeet Joglekar 2009-04-17 318
363f4d937501ba4 Jason Yan 2020-04-15 319 static int
vnic_dev_cmd2(struct vnic_dev *vdev, enum vnic_devcmd_cmd cmd,
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 320 int wait)
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 321 {
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 322 struct
devcmd2_controller *dc2c = vdev->devcmd2;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 323 struct devcmd2_result
*result;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 324 u8 color;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 325 unsigned int i;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 326 int delay;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 327 int err;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 328 u32 fetch_index;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 329 u32 posted;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 330 u32 new_posted;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 331
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 @332 posted =
ioread32(&dc2c->wq_ctrl->posted_index);
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 333 fetch_index =
ioread32(&dc2c->wq_ctrl->fetch_index);
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 334
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 335 if (posted ==
0x || fetch_index == 0x) {
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 336 /* Hardware
surprise removal: return error */
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 337 pr_err("%s:
devcmd2 invalid posted or fetch index on cmd %d\n",
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 338
pci_name(vdev->pdev), _CMD_N(cmd));
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 339 pr_err("%s:
fetch index: %u, posted index: %u\n",
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 340
pci_name(vdev->pdev)
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On 22.10.2020 10.54, Florian Weimer wrote: * Lennart Poettering: On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote: Hi, There is a problem with glibc+systemd on BTI enabled systems. Systemd has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny PROT_EXEC changes. Glibc enables BTI only on segments which are marked as being BTI compatible by calling mprotect PROT_EXEC|PROT_BTI. That call is caught by the seccomp filter, resulting in service failures. So, at the moment one has to pick either denying PROT_EXEC changes, or BTI. This is obviously not desirable. Various changes have been suggested, replacing the mprotect with mmap calls having PROT_BTI set on the original mapping, re-mmapping the segments, implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set, and various modification to seccomp to allow particular mprotect cases to bypass the filters. In each case there seems to be an undesirable attribute to the solution. So, whats the best solution? Did you see Topi's comments on the systemd issue? https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 I think I agree with this: it's a bit weird to alter the bits after the fact. Can't glibc set up everything right from the begining? That would keep both concepts working. The dynamic loader has to process the LOAD segments to get to the ELF note that says to enable BTI. Maybe we could do a first pass and load only the segments that cover notes. But that requires lots of changes to generic code in the loader. What if the loader always enabled BTI for PROT_EXEC pages, but then when discovering that this was a mistake, mprotect() the pages without BTI? Then both BTI and MDWX would work and the penalty of not getting MDWX would fall to non-BTI programs. What's the expected proportion of BTI enabled code vs. disabled in the future, is it perhaps expected that a distro would enable the flag globally so eventually only a few legacy programs might be unprotected? -Topi
Re: Adding ABI to htmldocs - Was: Re: [PATCH 2/2] w1: w1_therm: Add support for GXCAS GX20MH01 device.
Em Wed, 21 Oct 2020 18:58:19 +0200 Greg Kroah-Hartman escreveu: > On Wed, Oct 21, 2020 at 06:28:43PM +0200, Mauro Carvalho Chehab wrote: > > Hi greg, > > > > Em Wed, 7 Oct 2020 13:59:34 +0200 > > Mauro Carvalho Chehab escreveu: > > > > > Em Wed, 7 Oct 2020 13:43:59 +0200 > > > Greg Kroah-Hartman escreveu: > > > > > > > On Wed, Oct 07, 2020 at 01:05:49PM +0200, Mauro Carvalho Chehab wrote: > > > > > Em Wed, 7 Oct 2020 11:06:19 +0200 > > > > > Greg Kroah-Hartman escreveu: > > > > > > > > > > > On Wed, Oct 07, 2020 at 10:57:02AM +0200, Mauro Carvalho Chehab > > > > > > wrote: > > > > > > > Em Wed, 7 Oct 2020 10:32:27 +0300 > > > > > > > Ivan Zaentsev escreveu: > > > > > > > > > > > > > > > Tuesday, October 6, 2020, 4:19:15 PM, Mauro Carvalho Chehab > > > > > > > > wrote: > > > > > > > > > > > > > > > > >> diff --git a/Documentation/w1/slaves/w1_therm.rst > > > > > > > > >> b/Documentation/w1/slaves/w1_therm.rst > > > > > > > > >> index f1148181f53e..00376501a5ef 100644 > > > > > > > > >> --- a/Documentation/w1/slaves/w1_therm.rst > > > > > > > > >> +++ b/Documentation/w1/slaves/w1_therm.rst > > > > > > > > > > > > > > > > >> > > > > > > > > >> @@ -130,4 +131,12 @@ conversion and temperature reads 85.00 > > > > > > > > >> (powerup value) or 127.94 (insufficient > > > > > > > > >> power), the driver returns a conversion error. Bit mask > > > > > > > > >> ``2`` enables poll for > > > > > > > > >> conversion completion (normal power only) by generating > > > > > > > > >> read cycles on the bus > > > > > > > > >> after conversion starts. In parasite power mode this > > > > > > > > >> feature is not available. > > > > > > > > >> -Feature bit masks may be combined (OR). > > > > > > > > >> +Feature bit masks may be combined (OR). See accompanying > > > > > > > > >> sysfs documentation: > > > > > > > > >> +:ref:`Documentation/w1/slaves/w1_therm.rst ` > > > > > > > > >> + > > > > > > > > > > > > > > > > > As warned by Sphinx, this cross-reference is broken: > > > > > > > > > > > > > > > > > .../Documentation/w1/slaves/w1_therm.rst:125: WARNING: > > > > > > > > > undefined label: w1_therm (if the link has no caption the > > > > > > > > > label must precede a section header) > > > > > > > > > > > > > > > > Would this be ok? > > > > > > > > > > > > > > Yeah, sure! > > > > > > > > > > > > > > > > > > > > > > > "More details in > > > > > > > > Documentation/ABI/testing/sysfs-driver-w1_therm" > > > > > > > > > > > > > > > > > Not sure what you wanted to point here. > > > > > > > > > > > > > > > > A link to a driver's sysfs interface, but sysfs docs are text > > > > > > > > files and seem to not be included in Sphynx Docs. > > > > > > > > > > > > > > I sent upstream sometime ago a patch series adding ABI to Sphinx, > > > > > > > but I > > > > > > > was not merged, not sure why: > > > > > > > > > > > > > > > > > > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=abi_patches_v5.6 > > > > > > > > > > > > > > > > > > > I think the raft of different patches floating around at the time > > > > > > made > > > > > > me totally confused as to what was, and was not, the latest > > > > > > versions. > > > > > > > > > > Yeah, there were lots of patches floating around that time. > > > > > > > > > > I also recall that someone (Jeni?) asked if the best wouldn't be to > > > > > just convert the ABI files to ReST directly. > > > > > > > > > > > I'll be glad to look at them again, if you want to rebase after > > > > > > 5.10-rc1 > > > > > > is out and resend them, as I think this should be showing up in the > > > > > > documentation. > > > > > > > > > > Surely. I'll rebase them after 5.10-rc1 and re-submit. > > > > > > > > > > What strategy do you prefer? Keep the files with the same format as > > > > > today (allowing them to optionally have ReST markups) or to convert > > > > > them to .rst directly? > > > > > > > > > > In the latter case, the best would be to apply it as early as possible > > > > > after 5.10-rc1, as it may cause conflicts with other patches being > > > > > submitted for 5.11. > > > > > > > > The existing format if at all possible, doing wholesale changes is a > > > > mess and wouldn't be recommended. > > > > > > Yeah, merging it would indeed be a mess. At long term, though, it could > > > be easier to maintain. > > > > > > > I think you already fixed up the entries that had problems being parsed > > > > in the past, if not, we can resolve those as well. > > > > > > Yes. The series start with fixes. I suspect several of them > > > (if not all) were already merged, but if anything is missing, I can fix > > > at the upcoming rebased series. > > > > Rebasing the patch series was easier than what I expected: > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=abi_patches_v6 > > > > Yet, while fixing
RE: [PATCH v2 6/6] crypto: lib/sha - Combine round constants and message schedule
From: Eric Biggers
> Sent: 22 October 2020 05:35
>
> On Tue, Oct 20, 2020 at 04:39:57PM -0400, Arvind Sankar wrote:
> > Putting the round constants and the message schedule arrays together in
> > one structure saves one register, which can be a significant benefit on
> > register-constrained architectures. On x86-32 (tested on Broadwell
> > Xeon), this gives a 10% performance benefit.
> >
> > Signed-off-by: Arvind Sankar
> > Suggested-by: David Laight
> > ---
> > lib/crypto/sha256.c | 49 ++---
> > 1 file changed, 28 insertions(+), 21 deletions(-)
> >
> > diff --git a/lib/crypto/sha256.c b/lib/crypto/sha256.c
> > index 3a8802d5f747..985cd0560d79 100644
> > --- a/lib/crypto/sha256.c
> > +++ b/lib/crypto/sha256.c
> > @@ -29,6 +29,11 @@ static const u32 SHA256_K[] = {
> > 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb,
> > 0xbef9a3f7, 0xc67178f2,
> > };
> >
> > +struct KW {
> > + u32 K[64];
> > + u32 W[64];
> > +};
>
> Note that this doubles the stack usage from 256 to 512 bytes. That's pretty
> large for kernel code, especially when compiler options can increase the stack
> usage well beyond the "expected" value.
>
> So unless this gives a big performance improvement on architectures other than
> 32-bit x86 (which people don't really care about these days), we probably
> shouldn't do this.
IIRC the gain came from an odd side effect - which can probably
be got (for some compiler versions) by other means.
> FWIW, it's possible to reduce the length of 'W' to 16 words by computing the
> next W value just before each round 16-63,
I was looking at that.
You'd need to do the first 16 rounds then rounds 17-63 in a second
loop to avoid the conditional.
The problem is that it needs too many registers.
You'd need registers for 16 W values, the 8 a-h and a few spare.
...
Looking closely each round is like:
t1 = h + e1(e) + Ch(e, f, g) + 0x428a2f98 + W[0];
t2 = e0(a) + Maj(a, b, c);
h = t1 + t2; // Not used for a few rounds
d += t1; // Needed next round
So only needs 4 of the state variables (e, f, g, h).
The next round uses d, e, f and g.
So with extreme care d and h can use the same register.
Although I'm not sure how you'd get the compiler to do it.
Possibly making state[] volatile (or using READ/WRITE_ONCE).
So the last two lines become:
state[7] = t1 + t2;
d = state[3] + t1;
That might stop the x86 (32bit) spilling registers.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
[PATCH v8 0/4] userspace MHI client interface driver
This patch series adds support for UCI driver. UCI driver enables userspace clients to communicate to external MHI devices like modem and WLAN. UCI driver probe creates standard character device file nodes for userspace clients to perform open, read, write, poll and release file operations. These file operations call MHI core layer APIs to perform data transfer using MHI bus to communicate with MHI device. Patch is tested using arm64 based platform. V8: - Fixed kernel test robot compilation error by changing %lu to %zu for size_t. - Replaced uci with UCI in Kconfig, commit text, and comments in driver code. - Fixed minor style related comments. V7: - Decoupled uci device and uci channel objects. uci device is associated with device file node. uci channel is associated with MHI channels. uci device refers to uci channel to perform MHI channel operations for device file operations like read() and write(). uci device increments its reference count for every open(). uci device calls mhi_uci_dev_start_chan() to start the MHI channel. uci channel object is tracking number of times MHI channel is referred. This allows to keep the MHI channel in start state until last release() is called. After that uci channel reference count goes to 0 and uci channel clean up is performed which stops the MHI channel. After the last call to release() if driver is removed uci reference count becomes 0 and uci object is cleaned up. - Use separate uci channel read and write lock to fine grain locking between reader and writer. - Use uci device lock to synchronize open, release and driver remove. - Optimize for downlink only or uplink only UCI device. V6: - Moved uci.c to mhi directory. - Updated Kconfig to add module information. - Updated Makefile to rename uci object file name as mhi_uci - Removed kref for open count V5: - Removed mhi_uci_drv structure. - Used idr instead of creating global list of uci devices. - Used kref instead of local ref counting for uci device and open count. - Removed unlikely macro. V4: - Fix locking to protect proper struct members. - Updated documentation describing uci client driver use cases. - Fixed uci ref counting in mhi_uci_open for error case. - Addressed style related review comments. V3: Added documentation for MHI UCI driver. V2: Added mutex lock to prevent multiple readers to access same mhi buffer which can result into use after free. Hemant Kumar (4): bus: mhi: core: Add helper API to return number of free TREs bus: mhi: core: Move MHI_MAX_MTU to external header file docs: Add documentation for userspace client interface bus: mhi: Add userspace client interface driver Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 83 + drivers/bus/mhi/Kconfig | 13 + drivers/bus/mhi/Makefile| 4 + drivers/bus/mhi/core/internal.h | 1 - drivers/bus/mhi/core/main.c | 12 + drivers/bus/mhi/uci.c | 657 include/linux/mhi.h | 12 + 8 files changed, 782 insertions(+), 1 deletion(-) create mode 100644 Documentation/mhi/uci.rst create mode 100644 drivers/bus/mhi/uci.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v8 2/4] bus: mhi: core: Move MHI_MAX_MTU to external header file
Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/internal.h | 1 -
include/linux/mhi.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 7989269..4abf0cf 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -453,7 +453,6 @@ enum mhi_pm_state {
#define CMD_EL_PER_RING128
#define PRIMARY_CMD_RING 0
#define MHI_DEV_WAKE_DB127
-#define MHI_MAX_MTU0x
#define MHI_RANDOM_U32_NONZERO(bmsk) (prandom_u32_max(bmsk) + 1)
enum mhi_er_type {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 7829b1d..6e1122c 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -15,6 +15,9 @@
#include
#include
+/* MHI client drivers to set this upper bound for tx buffer */
+#define MHI_MAX_MTU 0x
+
#define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
struct mhi_chan;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v8 1/4] bus: mhi: core: Add helper API to return number of free TREs
Introduce mhi_get_free_desc_count() API to return number
of TREs available to queue buffer. MHI clients can use this
API to know before hand if ring is full without calling queue
API.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/main.c | 12
include/linux/mhi.h | 9 +
2 files changed, 21 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 2cff5dd..3950792 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -258,6 +258,18 @@ int mhi_destroy_device(struct device *dev, void *data)
return 0;
}
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir)
+{
+ struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+ struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ?
+ mhi_dev->ul_chan : mhi_dev->dl_chan;
+ struct mhi_ring *tre_ring = &mhi_chan->tre_ring;
+
+ return get_nr_avail_ring_elements(mhi_cntrl, tre_ring);
+}
+EXPORT_SYMBOL_GPL(mhi_get_free_desc_count);
+
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason)
{
struct mhi_driver *mhi_drv;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index d4841e5..7829b1d 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -597,6 +597,15 @@ void mhi_set_mhi_state(struct mhi_controller *mhi_cntrl,
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason);
/**
+ * mhi_get_free_desc_count - Get transfer ring length
+ * Get # of TD available to queue buffers
+ * @mhi_dev: Device associated with the channels
+ * @dir: Direction of the channel
+ */
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir);
+
+/**
* mhi_prepare_for_power_up - Do pre-initialization before power up.
*This is optional, call this before power up if
*the controller does not want bus framework to
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v8 4/4] bus: mhi: Add userspace client interface driver
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format
/dev/mhi__
Currently it supports LOOPBACK channel.
Signed-off-by: Hemant Kumar
---
drivers/bus/mhi/Kconfig | 13 +
drivers/bus/mhi/Makefile | 4 +
drivers/bus/mhi/uci.c| 657 +++
3 files changed, 674 insertions(+)
create mode 100644 drivers/bus/mhi/uci.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index e841c10..476cc55 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -20,3 +20,16 @@ config MHI_BUS_DEBUG
Enable debugfs support for use with the MHI transport. Allows
reading and/or modifying some values within the MHI controller
for debug and test purposes.
+
+config MHI_UCI
+ tristate "MHI UCI"
+ depends on MHI_BUS
+ help
+ MHI based Userspace Client Interface (UCI) driver is used for
+ transferring raw data between host and device using standard file
+ operations from userspace. Open, read, write, and close operations
+ are supported by this driver. Please check mhi_uci_match_table for
+ all supported channels that are exposed to userspace.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 19e6443..80feefb 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -1,2 +1,6 @@
# core layer
obj-y += core/
+
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 000..472bd63
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,657 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_MINORS 128
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_lock: spin lock
+ * @pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+ struct uci_dev *udev;
+ wait_queue_head_t ul_wq;
+
+ /* ul channel lock to synchronize multiple writes */
+ struct mutex write_lock;
+
+ wait_queue_head_t dl_wq;
+
+ /* dl channel lock to synchronize multiple reads */
+ struct mutex read_lock;
+
+ /*
+* protects pending and cur_buf members in bh context, channel release,
+* read and poll
+*/
+ spinlock_t dl_lock;
+
+ struct list_head pending;
+ struct uci_buf *cur_buf;
+ size_t dl_size;
+ struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - UCI buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the UCI buffer
+ */
+struct uci_buf {
+ void *data;
+ size_t len;
+ struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI UCI device
+ * @minor: UCI device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: UCI uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: Flag to track the state of the UCI device
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+ unsigned int minor;
+ struct mhi_device *mhi_dev;
+ struct uci_chan *uchan;
+ size_t mtu;
+ bool enabled;
+
+ /* synchronize open, release and driver remove */
+ struct mutex lock;
+ struct kref ref_count;
+};
+
+static void mhi_uci_dev_chan_release(struct kref *ref)
+{
+ struct uci_buf *buf_itr, *tmp;
+ struct uci_chan *uchan =
+ container_of(ref, struct uci_chan, ref_count);
+
+ if (uchan->udev->enabled)
+ mhi_unprepare_from_transfer(uchan->udev->mhi_dev);
+
+ spin_lock_bh(&uchan->dl_lock);
+ list_for_each_en
[PATCH v8 3/4] docs: Add documentation for userspace client interface
MHI userspace client driver is creating device file node for user application to perform file operations. File operations are handled by MHI core driver. Currently Loopback MHI channel is supported by this driver. Signed-off-by: Hemant Kumar --- Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 83 + 2 files changed, 84 insertions(+) create mode 100644 Documentation/mhi/uci.rst diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst index 1d8dec3..c75a371 100644 --- a/Documentation/mhi/index.rst +++ b/Documentation/mhi/index.rst @@ -9,6 +9,7 @@ MHI mhi topology + uci .. only:: subproject and html diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst new file mode 100644 index 000..fe901c4 --- /dev/null +++ b/Documentation/mhi/uci.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +Userspace Client Interface (UCI) += + +UCI driver enables userspace clients to communicate to external MHI devices +like modem and WLAN. UCI driver probe creates standard character device file +nodes for userspace clients to perform open, read, write, poll and release file +operations. + +Operations +== + +open + + +Instantiates UCI channel object and starts MHI channels to move it to running +state. Inbound buffers are queued to downlink channel transfer ring. Every +subsequent open() increments UCI device reference count as well as UCI channel +reference count. + +read + + +When data transfer is completed on downlink channel, TRE buffer is copied to +pending list. Reader is unblocked and data is copied to userspace buffer. TRE +buffer is queued back to downlink channel transfer ring. + +write +- + +Write buffer is queued to uplink channel transfer ring if ring is not full. Upon +uplink transfer completion buffer is freed. + +poll + + +Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by +userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer +ring is not empty. Returns EPOLLERR when UCI driver is removed. MHI channels +move to disabled state upon driver remove. + +release +--- + +Decrements UCI device reference count and UCI channel reference count upon last +release(). UCI channel clean up is performed. MHI channel moves to disabled +state and inbound buffers are freed. + +Usage += + +Device file node is created with format:- + +/dev/mhi__ + +controller_name is the name of underlying bus used to transfer data. mhi_device +name is the name of the MHI channel being used by MHI client in userspace to +send or receive data using MHI protocol. + +There is a separate character device file node created for each channel +specified in mhi device id table. MHI channels are statically defined by MHI +specification. The list of supported channels is in the channel list variable +of mhi_device_id table in UCI driver. + +LOOPBACK Channel + + +Userspace MHI client using LOOPBACK channel opens device file node. As part of +open operation TREs to transfer ring of LOOPBACK channel 1 gets queued and channel +doorbell is rung. When userspace MHI client performs write operation on device node, +data buffer gets queued as a TRE to transfer ring of LOOPBACK channel 0. MHI Core +driver rings the channel doorbell for MHI device to move data over underlying bus. +When userspace MHI client driver performs read operation, same data gets looped back +to MHI host using LOOPBACK channel 1. LOOPBACK channel is used to verify data path +and data integrity between MHI Host and MHI device. + +Other Use Cases +--- + +Getting MHI device specific diagnostics information to userspace MHI diag client +using DIAG channel 4 (Host to device) and 5 (Device to Host). -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
* Topi Miettinen: >> The dynamic loader has to process the LOAD segments to get to the ELF >> note that says to enable BTI. Maybe we could do a first pass and >> load only the segments that cover notes. But that requires lots of >> changes to generic code in the loader. > > What if the loader always enabled BTI for PROT_EXEC pages, but then > when discovering that this was a mistake, mprotect() the pages without > BTI? Is that architecturally supported? How costly is the mprotect change if the pages have not been faulted in yet? > Then both BTI and MDWX would work and the penalty of not getting > MDWX would fall to non-BTI programs. What's the expected proportion of > BTI enabled code vs. disabled in the future, is it perhaps expected > that a distro would enable the flag globally so eventually only a few > legacy programs might be unprotected? Eventually, I expect that mainstream distributions build everything for BTI, so yes, the PROT_BTI removal would only be needed for legacy programs. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
RE: [PATCH v5 0/5] Add r8a77965 DRIF support
Hi Laurent, > From: Laurent Pinchart > Sent: 21 October 2020 22:43 > Subject: Re: [PATCH v5 0/5] Add r8a77965 DRIF support > > Hi Fabrizio, > > On Wed, Oct 21, 2020 at 02:53:27PM +0100, Fabrizio Castro wrote: > > Dear All, > > > > this series is to add DRIF support for the r8a77965 > > (a.k.a. R-Car M3-N). Version 5 fixes a warning reported > > by 'make dt_binding_check', as reported by Rob. > > Patch 1/5 to 4/5 taken in my tree, I'll send a pull request to > linux-media when the merge window closes. I expect Geert to handle 5/5. Great, thank you. Fab > > > Fabrizio Castro (5): > > MAINTAINERS: Update MAINTAINERS for Renesas DRIF driver > > media: dt-bindings: media: renesas,drif: Convert to json-schema > > media: dt-bindings: media: renesas,drif: Add r8a77990 support > > media: dt-bindings: media: renesas,drif: Add r8a77965 support > > arm64: dts: r8a77965: Add DRIF support > > > > .../bindings/media/renesas,drif.txt | 177 --- > > .../bindings/media/renesas,drif.yaml | 279 ++ > > MAINTAINERS | 4 +- > > arch/arm64/boot/dts/renesas/r8a77965.dtsi | 120 > > 4 files changed, 401 insertions(+), 179 deletions(-) > > delete mode 100644 > Documentation/devicetree/bindings/media/renesas,drif.txt > > create mode 100644 > Documentation/devicetree/bindings/media/renesas,drif.yaml > > -- > Regards, > > Laurent Pinchart
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: > On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: > > On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: > > > From: David Laight > > > > > > This lets the compiler inline it into import_iovec() generating > > > much better code. > > > > > > Signed-off-by: David Laight > > > Signed-off-by: Christoph Hellwig > > > --- > > > fs/read_write.c | 179 > > > lib/iov_iter.c | 176 +++ > > > 2 files changed, 176 insertions(+), 179 deletions(-) > > > > Strangely, this commit causes a regression in Linus's tree right now. > > > > I can't really figure out what the regression is, only that this commit > > triggers a "large Android system binary" from working properly. There's > > no kernel log messages anywhere, and I don't have any way to strace the > > thing in the testing framework, so any hints that people can provide > > would be most appreciated. > > It's a pure move - modulo changed line breaks in the argument lists > the functions involved are identical before and after that (just checked > that directly, by checking out the trees before and after, extracting two > functions in question from fs/read_write.c and lib/iov_iter.c (before and > after, resp.) and checking the diff between those. > > How certain is your bisection? The bisection is very reproducable. But, this looks now to be a compiler bug. I'm using the latest version of clang and if I put "noinline" at the front of the function, everything works. Nick, any ideas here as to who I should report this to? I'll work on a fixup patch for the Android kernel tree to see if I can work around it there, but others will hit this in Linus's tree sooner or later... thanks, greg k-h
Re: [PATCH 3/5] xen/events: only register debug interrupt for 2-level events
On 22.10.20 09:54, Jan Beulich wrote:
On 22.10.2020 09:42, Juergen Gross wrote:
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2050,7 +2050,7 @@ void xen_setup_callback_vector(void) {}
static inline void xen_alloc_callback_vector(void) {}
#endif
-static bool fifo_events = true;
+bool fifo_events = true;
When making this non-static, perhaps better to also prefix it with
xen_?
Fine with me.
Juergen
Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs
On Wed, Oct 21 2020 at 17:02, Jakub Kicinski wrote: > On Wed, 21 Oct 2020 22:25:48 +0200 Thomas Gleixner wrote: >> The right answer to this is to utilize managed interrupts and have >> according logic in your network driver to handle CPU hotplug. When a CPU >> goes down, then the queue which is associated to that CPU is quiesced >> and the interrupt core shuts down the relevant interrupt instead of >> moving it to an online CPU (which causes the whole vector exhaustion >> problem on x86). When the CPU comes online again, then the interrupt is >> reenabled in the core and the driver reactivates the queue. > > I think Mellanox folks made some forays into managed irqs, but I don't > remember/can't find the details now. > > For networking the locality / queue per core does not always work, > since the incoming traffic is usually spread based on a hash. Many That makes it problematic and is fundamentally different from block I/O. > applications perform better when network processing is done on a small > subset of CPUs, and application doesn't get interrupted every 100us. > So we do need extra user control here. Ok. > We have a bit of a uAPI problem since people had grown to depend on > IRQ == queue == NAPI to configure their systems. "The right way" out > would be a proper API which allows associating queues with CPUs rather > than IRQs, then we can use managed IRQs and solve many other problems. > > Such new API has been in the works / discussions for a while now. If there is anything which needs to be done/extended on the irq side please let me know. Thanks tglx
Re: [PATCH 4/5] xen/events: unmask a fifo event channel only if it was masked
On 22.10.20 09:55, Jan Beulich wrote:
On 22.10.2020 09:42, Juergen Gross wrote:
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -236,6 +236,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
w = *word;
+ if (!(w & (1 << EVTCHN_FIFO_MASKED)))
+ return true;
Maybe better move this ...
do {
if (w & (1 << EVTCHN_FIFO_PENDING))
return false;
... into the loop, above this check?
Yes, that should be better.
Juergen
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote: > On 22.10.2020 10.54, Florian Weimer wrote: > > * Lennart Poettering: > > > Did you see Topi's comments on the systemd issue? > > > > > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 > > > > > > I think I agree with this: it's a bit weird to alter the bits after > > > the fact. Can't glibc set up everything right from the begining? That > > > would keep both concepts working. > > > > The dynamic loader has to process the LOAD segments to get to the ELF > > note that says to enable BTI. Maybe we could do a first pass and load > > only the segments that cover notes. But that requires lots of changes > > to generic code in the loader. > > What if the loader always enabled BTI for PROT_EXEC pages, but then when > discovering that this was a mistake, mprotect() the pages without BTI? Then > both BTI and MDWX would work and the penalty of not getting MDWX would fall > to non-BTI programs. What's the expected proportion of BTI enabled code vs. > disabled in the future, is it perhaps expected that a distro would enable > the flag globally so eventually only a few legacy programs might be > unprotected? i thought mprotect(PROT_EXEC) would get filtered with or without bti, is that not the case? then i guess we can do the protection that way around, but then i don't see why the filter cannot treat PROT_EXEC|PROT_BTI the same as PROT_EXEC.
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On Do, 22.10.20 09:05, Szabolcs Nagy (szabolcs.n...@arm.com) wrote: > > > Various changes have been suggested, replacing the mprotect with mmap > > > calls > > > having PROT_BTI set on the original mapping, re-mmapping the segments, > > > implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set, > > > and various modification to seccomp to allow particular mprotect cases to > > > bypass the filters. In each case there seems to be an undesirable > > > attribute > > > to the solution. > > > > > > So, whats the best solution? > > > > Did you see Topi's comments on the systemd issue? > > > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 > > > > I think I agree with this: it's a bit weird to alter the bits after > > the fact. Can't glibc set up everything right from the begining? That > > would keep both concepts working. > > that's hard to do and does not work for the main exe currently > (which is mmaped by the kernel). > > (it's hard to do because to know that the elf module requires > bti the PT_GNU_PROPERTY notes have to be accessed that are > often in the executable load segment, so either you mmap that > or have to read that, but the latter has a lot more failure > modes, so if i have to get the mmap flags right i'd do a mmap > and then re-mmap if the flags were not right) Only other option I then see is to neuter one of the two mechanisms. We could certainly turn off MDWE on arm in systemd, if people want that. Or make it a build-time choice, so that distros make the choice: build everything with BTI xor suppport MDWE. (Might make sense for glibc to gracefully fallback to non-BTI mode if the mprotect() fails though, to make sure BTI-built binaries work everywhere.) I figure your interest in ARM system security is bigger than mine. I am totally fine to turn off MDWE on ARM if that's what the Linux ARM folks want. I ave no horse in the race. Just let me know. [An acceptable compromise might be to allow mprotect(PROT_EXEC|PROT_BTI) if MDWE is on, but prohibit mprotect(PROT_EXEC) without PROT_BTI. Then at least you get one of the two protections, but not both. I mean, MDWE is not perfect anyway on non-x86-64 already: on 32bit i386 MDWE protection is not complete, due to ipc() syscall multiplexing being unmatchable with seccomp. I personally am happy as long as it works fully on x86-64] Lennart -- Lennart Poettering, Berlin
Re: [PATCH 2/2] thermal: cpufreq_cooling: Reuse effective_cpu_util()
Hi Peter, Since Lukasz asked me to hold on to this stuff so he can propose something in its place, I stayed away from discussing this patchset for sometime. But now that he agrees [1] that we may take this forward and he can work on top of it as and when he can, I am looking to find the way out to get this stuff merged in some form. On 16-07-20, 13:56, Peter Zijlstra wrote: > So there's a number of things... let me recap a bunch of things that > got mentioned on IRC earlier this week and then continue from there.. > > So IPA* (or any other thermal governor) needs energy estimates for the > various managed devices, cpufreq_cooling, being the driver for the CPU > device, needs to provide that and in return receives feedback on how > much energy it is allowed to consume, cpufreq_cooling then dynamically > enables/disables OPP states. > > There are actually two methods the thermal governor will use: > get_real_power() and get_requested_power(). > > The first isn't used anywhere in mainline, but could be implemented on > hardware that has energy counters (like say x86 RAPL). > > The second attempts to guesstimate power, and is the subject of this > patch. > > Currently cpufreq_cooling appears to estimate the CPU energy usage by > calculating the percentage of idle time using the per-cpu cpustat stuff, > which is pretty horrific. > > This patch then attempts to improve upon that by using the scheduler's > cpu_util(ENERGY_UTIL) estimate, which is also used to select OPP state > and improves upon avg idle. This should be a big improvement as higher > frequency consumes more energy Exactly and that's the motivation behind this change. > , but should we not also consider that: > > E = C V^2 f > > The EAS energy model has tables for the OPPs that contain this, but in > this case we seem to be assuming a linear enery/frequency curve, which > is just not the case. > > I suppose we could do something like **: > > 100 * util^3 / max^3 > > which assumes V~f. > > Another point is that cpu_util() vs turbo is a bit iffy, and to that, > things like x86-APERF/MPERF and ARM-AMU got mentioned. Those might also > have the benefit of giving you values that match your own sampling > interval (100ms), where the sched stuff is PELT (64,32.. based). I believe the above stuff is more around additional improvements that we can do over this change, and probably Lukasz was looking to do that. > So what I've been thinking is that cpufreq drivers ought to be able to > supply this method, and only when they lack, can the cpufreq-governor > (schedutil) install a fallback. One of the issues I see with this is that schedutil may not be available in all configurations and it is still absolutely fine to using the suggested helper to get the energy numbers in such cases, so we shouldn't really make it scheutil dependent. > And then cpufreq-cooling can use > whatever is provided (through the cpufreq interfaces). > > That way, we: > > 1) don't have to export anything Yeah, I understand that the exports are annoying and specially this line :) +#include "../../kernel/sched/sched.h" But this is the best I could think of then as we don't want to export them for anyone else to use sched specific stuff. And there was other core kernel stuff that was already doing it :) > 2) get arch drivers to provide something 'better' > > > Does that sounds like something sensible? -- viresh [1] http://lore.kernel.org/lkml/d2a75b18-1eae-f396-4dc5-af41b539e...@arm.com
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On 22.10.20 10:26, Greg KH wrote: > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: From: David Laight This lets the compiler inline it into import_iovec() generating much better code. Signed-off-by: David Laight Signed-off-by: Christoph Hellwig --- fs/read_write.c | 179 lib/iov_iter.c | 176 +++ 2 files changed, 176 insertions(+), 179 deletions(-) >>> >>> Strangely, this commit causes a regression in Linus's tree right now. >>> >>> I can't really figure out what the regression is, only that this commit >>> triggers a "large Android system binary" from working properly. There's >>> no kernel log messages anywhere, and I don't have any way to strace the >>> thing in the testing framework, so any hints that people can provide >>> would be most appreciated. >> >> It's a pure move - modulo changed line breaks in the argument lists >> the functions involved are identical before and after that (just checked >> that directly, by checking out the trees before and after, extracting two >> functions in question from fs/read_write.c and lib/iov_iter.c (before and >> after, resp.) and checking the diff between those. >> >> How certain is your bisection? > > The bisection is very reproducable. > > But, this looks now to be a compiler bug. I'm using the latest version > of clang and if I put "noinline" at the front of the function, > everything works. Well, the compiler can do more invasive optimizations when inlining. If you have buggy code that relies on some unspecified behavior, inlining can change the behavior ... but going over that code, there isn't too much action going on. At least nothing screamed at me. -- Thanks, David / dhildenb
[PATCH] selftests/powerpc/eeh: disable kselftest timeout setting for eeh-basic
The eeh-basic test got its own 60 seconds timeout (defined in commit 414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable device. And we have discovered that the number of breakable devices varies on different hardware. The device recovery time ranges from 0 to 35 seconds. In our test pool it will take about 30 seconds to run on a Power8 system that with 5 breakable devices, 60 seconds to run on a Power9 system that with 4 breakable devices. Thus it's better to disable the default 45 seconds timeout setting in the kselftest framework to give it a chance to finish. And let the test to take care of the timeout control. Signed-off-by: Po-Hsu Lin --- tools/testing/selftests/powerpc/eeh/Makefile | 2 +- tools/testing/selftests/powerpc/eeh/settings | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/powerpc/eeh/settings diff --git a/tools/testing/selftests/powerpc/eeh/Makefile b/tools/testing/selftests/powerpc/eeh/Makefile index b397bab..ae963eb 100644 --- a/tools/testing/selftests/powerpc/eeh/Makefile +++ b/tools/testing/selftests/powerpc/eeh/Makefile @@ -3,7 +3,7 @@ noarg: $(MAKE) -C ../ TEST_PROGS := eeh-basic.sh -TEST_FILES := eeh-functions.sh +TEST_FILES := eeh-functions.sh settings top_srcdir = ../../../../.. include ../../lib.mk diff --git a/tools/testing/selftests/powerpc/eeh/settings b/tools/testing/selftests/powerpc/eeh/settings new file mode 100644 index 000..e7b9417 --- /dev/null +++ b/tools/testing/selftests/powerpc/eeh/settings @@ -0,0 +1 @@ +timeout=0 -- 2.7.4
Re: [PATCH v2 1/2] cifs: convert to add_to_page_cache()
you can add my reviewed-by if you would like
On Thu, Oct 22, 2020 at 1:48 AM Kent Overstreet
wrote:
>
> This is just open coding add_to_page_cache(), and the next patch will
> delete add_to_page_cache_locked().
>
> Signed-off-by: Kent Overstreet
> ---
> fs/cifs/file.c | 20
> 1 file changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index be46fab4c9..b3ee790532 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -4296,20 +4296,11 @@ readpages_get_pages(struct address_space *mapping,
> struct list_head *page_list,
>
> page = lru_to_page(page_list);
>
> - /*
> -* Lock the page and put it in the cache. Since no one else
> -* should have access to this page, we're safe to simply set
> -* PG_locked without checking it first.
> -*/
> - __SetPageLocked(page);
> - rc = add_to_page_cache_locked(page, mapping,
> - page->index, gfp);
> + rc = add_to_page_cache(page, mapping, page->index, gfp);
>
> /* give up if we can't stick it in the cache */
> - if (rc) {
> - __ClearPageLocked(page);
> + if (rc)
> return rc;
> - }
>
> /* move first page to the tmplist */
> *offset = (loff_t)page->index << PAGE_SHIFT;
> @@ -4328,12 +4319,9 @@ readpages_get_pages(struct address_space *mapping,
> struct list_head *page_list,
> if (*bytes + PAGE_SIZE > rsize)
> break;
>
> - __SetPageLocked(page);
> - rc = add_to_page_cache_locked(page, mapping, page->index,
> gfp);
> - if (rc) {
> - __ClearPageLocked(page);
> + rc = add_to_page_cache(page, mapping, page->index, gfp);
> + if (rc)
> break;
> - }
> list_move_tail(&page->lru, tmplist);
> (*bytes) += PAGE_SIZE;
> expected_index++;
> --
> 2.28.0
>
--
Thanks,
Steve
Re: [PATCH v4 0/3] time namespace aware system boot time
On Mon, Oct 19, 2020 at 09:52:54PM +0200, Michael Weiß wrote: > Time namespaces make it possible to virtualize time inside of > containers, e.g., it is feasible to reset the uptime of a container > to zero by setting the time namespace offset for boottime to the > negated current value of the CLOCK_BOOTTIME. > > However, the boot time stamp provided by getboottime64() does not > take care of time namespaces. The resulting boot time stamp 'btime' > provided by /proc/stat does not show a plausible time stamp inside > the time namespace of a container. > > We address this by shifting the value returned by getboottime64() > by subtracting the boottime offset of the time namespace. > (A selftest to check the expected /proc/stat 'btime' inside the > namespace is provided.) > > Further, to avoid to show processes as time travelers inside of the > time namespace the boottime offset then needs to be added to the > start_boottime provided by the task_struct. > > v4 Changes: > Avoid type conversions back and forth between timespec64 and ktime_t > in 'proc/stat.c' as suggested by Andrei. > Introduced timens_sub_boottime() in 'time_namespace.h' to provide > better coder readability/consistency. > Reviewed-by: Andrei Vagin Thanks, Andrei
Re: [PATCH 0/3] warn and suppress irqflood
On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote: > I hit a irqflood bug on powerpc platform, and two years ago, on a x86 > platform. > When the bug happens, the kernel is totally occupies by irq. Currently, there > may be nothing or just soft lockup warning showed in console. It is better > to warn users with irq flood info. > > In the kdump case, the kernel can move on by suppressing the irq flood. You're curing the symptom not the cause and the cure is just magic and can't work reliably. Where is that irq flood originated from and why is none of the mechanisms we have in place to shut it up working? Thanks, tglx
