[PATCH v3 10/10] Documentation: arm64: Document PMU counters access from userspace

From: Raphael Gault Add a documentation file to describe the access to the pmu hardware counters from userspace Signed-off-by: Raphael Gault Signed-off-by: Rob Herring --- v2: - Update links to test examples Changes from Raphael's v4: - Convert to rSt - Update chained event status -

[PATCH v3 09/10] perf: arm64: Add test for userspace counter access on heterogeneous systems

Userspace counter access only works on heterogeneous systems with some restrictions. The userspace process must be pinned to a homogeneous subset of CPUs and must open the corresponding PMU for those CPUs. This commit adds a test implementing these requirements. Signed-off-by: Rob Herring ---

Re: [External] Re: [PATCH] mm: memcontrol: Add the missing numa stat of anon and file for cgroup v2

On Fri, Sep 11, 2020 at 11:51:42AM +0800, Muchun Song wrote: > On Fri, Sep 11, 2020 at 12:02 AM Shakeel Butt wrote: > > > > On Thu, Sep 10, 2020 at 1:46 AM Muchun Song > > wrote: > > > > > > In the cgroup v1, we have a numa_stat interface. This is useful for > > > providing visibility into the

[PATCH v9 4/7] iommu/uapi: Use named union for user data

IOMMU UAPI data size is filled by the user space which must be validated by the kernel. To ensure backward compatibility, user data can only be extended by either re-purpose padding bytes or extend the variable sized union at the end. No size change is allowed before the union. Therefore, the

[PATCH v9 3/7] iommu/uapi: Introduce enum type for PASID data format

There can be multiple vendor-specific PASID data formats used in UAPI structures. This patch adds enum type with a last entry which makes range checking much easier. Suggested-by: Alex Williamson Reviewed-by: Eric Auger Signed-off-by: Jacob Pan --- include/uapi/linux/iommu.h | 8 ++-- 1

[PATCH v9 2/7] iommu/uapi: Add argsz for user filled data

As IOMMU UAPI gets extended, user data size may increase. To support backward compatibiliy, this patch introduces a size field to each UAPI data structures. It is *always* the responsibility for the user to fill in the correct size. Padding fields are adjusted to ensure 8 byte alignment. Specific

[PATCH v9 0/7] IOMMU user API enhancement

IOMMU user API header was introduced to support nested DMA translation and related fault handling. The current UAPI data structures consist of three areas that cover the interactions between host kernel and guest: - fault handling - cache invalidation - bind guest page tables, i.e. guest PASID

[PATCH v9 6/7] iommu/uapi: Handle data and argsz filled by users

IOMMU user APIs are responsible for processing user data. This patch changes the interface such that user pointers can be passed into IOMMU code directly. Separate kernel APIs without user pointers are introduced for in-kernel users of the UAPI functionality. IOMMU UAPI data has a user filled

[PATCH v9 5/7] iommu/uapi: Rename uapi functions

User APIs such as iommu_sva_unbind_gpasid() may also be used by the kernel. Since we introduced user pointer to the UAPI functions, in-kernel callers cannot share the same APIs. In-kernel callers are also trusted, there is no need to validate the data. We plan to have two flavors of the same API

[PATCH v9 1/7] docs: IOMMU user API

IOMMU UAPI is newly introduced to support communications between guest virtual IOMMU and host IOMMU. There has been lots of discussions on how it should work with VFIO UAPI and userspace in general. This document is intended to clarify the UAPI design and usage. The mechanics of how future

[PATCH v9 7/7] iommu/vt-d: Check UAPI data processed by IOMMU core

IOMMU generic layer already does sanity checks on UAPI data for version match and argsz range based on generic information. This patch adjusts the following data checking responsibilities: - removes the redundant version check from VT-d driver - removes the check for vendor specific data size -

slab-out-of-bounds in iov_iter_revert()

Super easy to reproduce on today's mainline by just fuzzing for a few minutes on virtiofs (if it ever matters). Any thoughts? [ 511.089112] BUG: KASAN: slab-out-of-bounds in iov_iter_revert+0xd8/0x3c0 iov_iter_revert at lib/iov_iter.c:1135 (inlined by) iov_iter_revert at lib/iov_iter.c:1080 [

Re: [IB/srpt] c804af2c1d: last_state.test.blktests.exit_code.143

On 2020-09-08 19:01, Bart Van Assche wrote: > The above patch didn't compile, but the patch below does and makes the hang > disappear. So feel free to add the following to the patch below: > > Tested-by: Bart Van Assche > > diff --git a/drivers/infiniband/core/device.c >

[PATCH net-next] octeontx2-af: Constify npc_kpu_profile_{action,cam}

These are never modified, so constify them to allow the compiler to place them in read-only memory. This moves about 25kB to read-only memory as seen by the output of the size command. Before: textdata bss dec hex filename 296203 654641248 362915 589a3

Re: first bad commit: [5795eb443060148796beeba106e4366d7f1458a6] scsi: sd_zbc: emulate ZONE_APPEND commands

On Fri, Sep 11, 2020 at 09:53:12PM +0200, Borislav Petkov wrote: > Now, looking at that patch: > > 5795eb443060 ("scsi: sd_zbc: emulate ZONE_APPEND commands") > > yeah, that doesn't revert cleanly. But it talks about zoned-something > devices and that rings a bell because you guys broke my

[tip:x86/cpu] BUILD SUCCESS 33b4711df4c1b3aec7c267c60fc24abccfadd40c

386 randconfig-a004-20200911 i386 randconfig-a006-20200911 i386 randconfig-a001-20200911 i386 randconfig-a003-20200911 i386 randconfig-a002-20200911 i386 randconfig-a005-20200911 x86_64 randconfig-a

Re: [PATCH 5.8 00/16] 5.8.9-rc1 review

On 9/11/20 6:47 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.8.9 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made

[tip:ras/core] BUILD SUCCESS e2def7d49d0812ea40a224161b2001b2e815dce2

powerpc allnoconfig i386 randconfig-a004-20200911 i386 randconfig-a006-20200911 i386 randconfig-a001-20200911 i386 randconfig-a003-20200911 i386 randconfig-a002-20200911 i386

Re: [PATCH 5.4 0/8] 5.4.65-rc1 review

On 9/11/20 6:54 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.4.65 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made

[GIT PULL] libnvdimm fix for v5.9-rc5

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git tags/libnvdimm-fix-v5.9-rc5 ...to receive another fix for detection of DAX support for block devices. The previous fix in this area (merged in -rc3) was incomplete, and this should finally address all the

Re: first bad commit: [5795eb443060148796beeba106e4366d7f1458a6] scsi: sd_zbc: emulate ZONE_APPEND commands

On 9/11/20 3:17 PM, Borislav Petkov wrote: > On Fri, Sep 11, 2020 at 09:53:12PM +0200, Borislav Petkov wrote: >> Now, looking at that patch: >> >> 5795eb443060 ("scsi: sd_zbc: emulate ZONE_APPEND commands") >> >> yeah, that doesn't revert cleanly. But it talks about zoned-something >> devices

Re: [PATCH 4.19 0/8] 4.19.145-rc1 review

On 9/11/20 6:54 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.19.145 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made

[PATCH v2 0/4] mtd: spi-nor: OTP support

This patchset implements the MTD OTP functions to allow access to the SPI OTP data. Specific support is added for the Adesto, Macronix and Winbond flash chips. In the past there was already an attempt by Rahul Bedarkar to add this, but there was no response. These patches are slightly based on

[PATCH v2 4/4] mtd: spi-nor: implement OTP support for Winbond and similar flashes

Use the new OTP ops to implement OTP access on Winbond flashes. Most Winbond flashes provides up to four different OTP areas ("Security Registers"). Newer flashes uses the first OTP area for SFDP data. Thus, for these flashes only the last three areas are handled and the first one is left

[PATCH v2 2/4] mtd: spi-nor: add OTP support

Implement the MTD callbacks for the OTP methods for the SPI NOR subsystem. Usually, the OTP area of a SPI flash can be accessed like the normal memory, eg by offset addressing; except that you either have to use special read/write commands (Winbond) or you have to enter (and exit) a specific OTP

[PATCH v2 3/4] mtd: spi-nor: implement OTP support for Macronix and similar flashes

Use the new OTP ops to implement OTP access on Macronix flashes. The Macronix flashes provides one OTP area which is either programmed with an electrical serial number and locked by the factory or is empty and can be locked by the user. To keep things simple and because most devices will have

[PATCH v2 1/4] mtd: spi-nor: cleanup common code

Introduce a spi_nor_simple_cmd() function which executes a SPI command with no additional argument bits. This function is then used to simplify many other functions. Signed-off-by: Michael Walle --- drivers/mtd/spi-nor/core.c | 295 +++-- 1 file changed, 84

Re: first bad commit: [5795eb443060148796beeba106e4366d7f1458a6] scsi: sd_zbc: emulate ZONE_APPEND commands

On 12/09/2020 00:22, Randy Dunlap wrote: > On 9/11/20 3:17 PM, Borislav Petkov wrote: >> On Fri, Sep 11, 2020 at 09:53:12PM +0200, Borislav Petkov wrote: >>> Now, looking at that patch: >>> >>> 5795eb443060 ("scsi: sd_zbc: emulate ZONE_APPEND commands") >>> >>> yeah, that doesn't revert cleanly.

Re: [PATCH 4.14 00/12] 4.14.198-rc1 review

On 9/11/20 6:46 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.198 release. There are 12 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 00/71] 4.9.236-rc1 review

On 9/11/20 6:45 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.236 release. There are 71 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made

[RESEND PATCH] bluetooth: Set ext scan response only when it exists

Only set extended scan response only when it exists. Otherwise, clear the scan response data. Per the core spec v5.2, Vol 4, Part E, 7.8.55 If the advertising set is non-scannable and the Host uses this command other than to discard existing data, the Controller shall return the error code

[RESEND PATCH] Bluetooth: Only mark socket zapped after unlocking

Since l2cap_sock_teardown_cb doesn't acquire the channel lock before setting the socket as zapped, it could potentially race with l2cap_sock_release which frees the socket. Thus, wait until the cleanup is complete before marking the socket as zapped. This race was reproduced on a JBL GO speaker

Re: [PATCH v2 2/5] perf record: Prevent override of attr->sample_period for libpfm4 events

On Fri, Sep 4, 2020 at 11:51 AM Arnaldo Carvalho de Melo wrote: > > Em Fri, Sep 04, 2020 at 03:50:13PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Fri, Sep 04, 2020 at 03:48:03PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Fri, Sep 04, 2020 at 09:22:10AM -0700, Ian Rogers escreveu: >

Re: [PATCH 4.4 00/62] 4.4.236-rc1 review

On 9/11/20 6:45 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.236 release. There are 62 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made

Re: first bad commit: [5795eb443060148796beeba106e4366d7f1458a6] scsi: sd_zbc: emulate ZONE_APPEND commands

On 9/11/20 3:26 PM, Johannes Thumshirn wrote: > On 12/09/2020 00:22, Randy Dunlap wrote: >> On 9/11/20 3:17 PM, Borislav Petkov wrote: >>> On Fri, Sep 11, 2020 at 09:53:12PM +0200, Borislav Petkov wrote: Now, looking at that patch: 5795eb443060 ("scsi: sd_zbc: emulate ZONE_APPEND

Re: [PATCH] mm: memcg/slab: fix racy access to page->mem_cgroup in mem_cgroup_from_obj()

On Fri, Sep 11, 2020 at 2:34 PM Roman Gushchin wrote: > [snip] > > > > Also have you taken a look at [1]? I am still trying to figure out how > > that is possible. > > > > [1] https://lore.kernel.org/lkml/20200901075321.GL4299@shao2-debian/ > > Hm, yeah, it's complicated. At the very first glance

[PATCH v2 block/for-next] blk-iocost: fix divide-by-zero in transfer_surpluses()

Conceptually, root_iocg->hweight_donating must be less than WEIGHT_ONE but all hweight calculations round up and thus it may end up >= WEIGHT_ONE triggering divide-by-zero and other issues. Bound the value to avoid surprises. Signed-off-by: Tejun Heo Fixes: e08d02aa5fc9 ("blk-iocost: implement

Re: [PATCH] mm: memcg/slab: fix racy access to page->mem_cgroup in mem_cgroup_from_obj()

On Thu, Sep 10, 2020 at 3:43 PM Roman Gushchin wrote: > > Forgot to cc stable@, an updated version is below. > > Thanks! > > -- > > From fe61af45ae570b143ca783ba4d013a0a2b923a15 Mon Sep 17 00:00:00 2001 > From: Roman Gushchin > Date: Wed, 9 Sep 2020 12:19:37 -0700 > Subject: [PATCH] mm:

Re: [PATCH v2 block/for-next] blk-iocost: fix divide-by-zero in transfer_surpluses()

On 9/11/20 4:40 PM, Tejun Heo wrote: > Conceptually, root_iocg->hweight_donating must be less than WEIGHT_ONE but > all hweight calculations round up and thus it may end up >= WEIGHT_ONE > triggering divide-by-zero and other issues. Bound the value to avoid > surprises. > > Signed-off-by: Tejun

Re: [v2,2/3] PCI: mediatek: Add new generation controller support

On Thu, Sep 10, 2020 at 11:45:35AM +0800, Jianjun Wang wrote: > MediaTek's PCIe host controller has three generation HWs, the new > generation HW is an individual bridge, it supoorts Gen3 speed and > up to 256 MSI interrupt numbers for multi-function devices. > > Add support for new Gen3

Re: [PATCH v2 block/for-next] blk-iocost: fix divide-by-zero in transfer_surpluses()

On Fri, Sep 11, 2020 at 04:43:18PM -0600, Jens Axboe wrote: > On 9/11/20 4:40 PM, Tejun Heo wrote: > > Conceptually, root_iocg->hweight_donating must be less than WEIGHT_ONE but > > all hweight calculations round up and thus it may end up >= WEIGHT_ONE > > triggering divide-by-zero and other

Re: [v2,1/3] dt-bindings: PCI: mediatek: Add YAML schema

On Thu, Sep 10, 2020 at 11:45:34AM +0800, Jianjun Wang wrote: > Add YAML schemas documentation for Gen3 PCIe controller on > MediaTek SoCs. > > Signed-off-by: Jianjun Wang > Acked-by: Ryder Lee > --- > .../bindings/pci/mediatek-pcie-gen3.yaml | 130 ++ > 1 file changed,

Re: [PATCH] platform/x86: Add Driver to set up lid GPEs on MS Surface device

On 9/12/20 12:10 AM, mark gross wrote: Surface devices are tablets with detachable keyboards. they don't really have a "lid" as the tablet is the "lid". The Surface Laptop series doesn't have a detachable keyboard, yet still requires this. Arguably, the Surface Books are also more laptop than

Re: [BUG RT] dump-capture kernel not executed for panic in interrupt context

Joerg Vehlow writes: > Hi, > > here is the new version of the patch based on Peters suggestion > It looks like it works fine. I added the BUG_ON to __crash_kexec, because it > is > a precondition, that panic_cpu is set correctly, otherwise the whole locking > logic fails. > > The mutex_trylock

Re: [PATCH v2 1/4] dt bindings: remoteproc: Add bindings for MT8183 APU

On Thu, 10 Sep 2020 15:01:45 +0200, Alexandre Bailon wrote: > This adds dt bindings for the APU present in the MT8183. > > Signed-off-by: Alexandre Bailon > --- > .../bindings/remoteproc/mtk,apu.yaml | 107 ++ > 1 file changed, 107 insertions(+) > create mode 100644

Re: [PATCH v2 1/4] dt bindings: remoteproc: Add bindings for MT8183 APU

On Thu, 10 Sep 2020 15:01:45 +0200, Alexandre Bailon wrote: > This adds dt bindings for the APU present in the MT8183. > > Signed-off-by: Alexandre Bailon > --- > .../bindings/remoteproc/mtk,apu.yaml | 107 ++ > 1 file changed, 107 insertions(+) > create mode 100644

Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro

On Thu, Jul 16, 2020 at 02:49:35PM +0200, Linus Walleij wrote: > Hi Syed, > > sorry for taking so long. I was on vacation and a bit snowed > under by work. > > On Sat, Jun 27, 2020 at 10:10 AM Syed Nayyar Waris > wrote: > > > Since this patchset primarily affects GPIO drivers, would you like

Re: [PATCH 2/2] media: dt-bindings: media: i2c: Add bindings for ADDI9036

On Thu, 10 Sep 2020 19:24:07 +0300, Bogdan Togorean wrote: > Add YAML device tree bindings for Analog Devices Inc. ADDI9036 CCD TOF > front-end. > > Signed-off-by: Bogdan Togorean > --- > .../bindings/media/i2c/adi,addi9036.yaml | 72 +++ > 1 file changed, 72 insertions(+)

Re: [RESEND][PATCH v6] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)

I'm not a maintainer, but I reviewed this earlier, so I guess it's only appropriate: Reviewed-by: Konrad Dybcio Looking forward to future patches for this device! :D Konrad

Re: [PATCH v3 2/2] dm-crypt: collect data and submit to DM to measure

Thanks for taking a look at this patch Milan. Appreciate it. Sorry for responding late. I was on vacation last week. My responses below. On 2020-08-31 3:54 a.m., Milan Broz wrote: On 28/08/2020 22:27, Tushar Sugandhi wrote: Currently, dm-crypt does not take advantage of IMA measuring

Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack

On Wed, 2020-09-09 at 16:29 -0700, Dave Hansen wrote: > On 9/9/20 4:25 PM, Yu, Yu-cheng wrote: > > On 9/9/2020 4:11 PM, Dave Hansen wrote: > > > On 9/9/20 4:07 PM, Yu, Yu-cheng wrote: > > > > What if a writable mapping is passed to madvise(MADV_SHSTK)? Should > > > > that be rejected? > > > > >

Re: [PATCH 01/12] dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains controller

On Thu, Sep 10, 2020 at 07:28:15PM +0200, Enric Balletbo i Serra wrote: > The System Control Processor System (SCPSYS) has several power management > related tasks in the system. Add the bindings to define the power > domains for the SCPSYS power controller. > > Co-developed-by: Matthias Brugger

Re: [RFC PATCH v1 1/1] sched/fair: select idle cpu from idle cpumask in sched domain

On 2020/9/12 0:28, Qais Yousef wrote: > On 09/10/20 13:42, Aubrey Li wrote: >> Added idle cpumask to track idle cpus in sched domain. When a CPU >> enters idle, its corresponding bit in the idle cpumask will be set, >> and when the CPU exits idle, its bit will be cleared. >> >> When a task wakes

Re: first bad commit: [5795eb443060148796beeba106e4366d7f1458a6] scsi: sd_zbc: emulate ZONE_APPEND commands

On Sat, Sep 12, 2020 at 12:17:59AM +0200, Borislav Petkov wrote: > Enabling it, fixes the issue. Btw, I just hit the below warn with 5.8, while booting with the above config option enabled. Looks familiar and I didn't trigger it with 5.9-rc4+ so you guys either fixed it or something changed

Re: [PATCH] ide/macide: Convert Mac IDE driver to platform driver

On Fri, 11 Sep 2020, Geert Uytterhoeven wrote: > > Sorry, I completely missed that the Baboon case registers a > "pata_platform" device instead of a "macide" device. Hence please > ignore my comments related to that. Sorry for the noise. > No problem. That misunderstanding got me thinking

Yet another ethernet PHY LED control proposal

Hello, I have been thinking about another way to implement ABI for HW control of ethernet PHY connected LEDs. This proposal is inspired by the fact that for some time there is a movement in the kernel to do transparent HW offloading of things (DSA is an example of that). So currently we have

Re: [PATCH v3 04/10] PCI/RCEC: Add pcie_walk_rcec() to walk associated RCiEPs

On 4 Sep 2020, at 19:23, Bjorn Helgaas wrote: On Fri, Sep 04, 2020 at 10:18:30PM +, Kelley, Sean V wrote: Hi Bjorn, Quick question below... On Wed, 2020-09-02 at 14:55 -0700, Sean V Kelley wrote: Hi Bjorn, On Wed, 2020-09-02 at 14:00 -0500, Bjorn Helgaas wrote: On Wed, Aug 12, 2020 at

Re: [RFC PATCH v1 1/1] sched/fair: select idle cpu from idle cpumask in sched domain

On 2020/9/12 7:04, Li, Aubrey wrote: > On 2020/9/12 0:28, Qais Yousef wrote: >> On 09/10/20 13:42, Aubrey Li wrote: >>> Added idle cpumask to track idle cpus in sched domain. When a CPU >>> enters idle, its corresponding bit in the idle cpumask will be set, >>> and when the CPU exits idle, its bit

Re: [PATCH net-next] net/socket.c: Remove an unused header file

On Fri, Sep 11, 2020 at 2:41 PM David Miller wrote: > > From: Xie He > Date: Thu, 10 Sep 2020 23:07:20 -0700 > > > This header file is not actually used in this file. Let's remove it. > > How did you test this assertion? As Jakub showed, the > dlci_ioctl_set() function needs to be declared

Re.Dear Friend

-- Hello, How are you once again. I have been having difficulty reaching you. I have an important business transaction to discuss with you. There are funds available and ready for investment which we will need your assistance to invest. Do get back to me as soon as you can for more

Re: [PATCH net-next] net/packet: Fix a comment about hard_header_len and add a warning for it

On Fri, Sep 11, 2020 at 7:32 AM Willem de Bruijn wrote: > > From a quick scan, a few device types that might trigger this > > net/atm/clip.c > drivers/net/wan/hdlc_fr.c > drivers/net/appletalk/ipddp.c > drivers/net/ppp/ppp_generic.c > drivers/net/net_failover.c I have recently fixed this problem

Re: [PATCH net-next] drivers/net/wan/x25_asy: Remove an unused flag "SLF_OUTWAIT"

On Fri, Sep 11, 2020 at 2:44 PM David Miller wrote: > > From: Xie He > Date: Thu, 10 Sep 2020 23:35:03 -0700 > > > The "SLF_OUTWAIT" flag defined in x25_asy.h is not actually used. > > It is only cleared at one place in x25_asy.c but is never read or set. > > So we can remove it. > > > >

Re: slab-out-of-bounds in iov_iter_revert()

On Fri, Sep 11, 2020 at 05:59:04PM -0400, Qian Cai wrote: > Super easy to reproduce on today's mainline by just fuzzing for a few minutes > on virtiofs (if it ever matters). Any thoughts? Usually happens when ->direct_IO() fucks up and reports the wrong amount of data written/read. We had

Re: [PATCH v2] zram: add restriction on dynamic zram device creation

Hi Yi, On Fri, Sep 04, 2020 at 04:52:10PM +0800, Yi Wang wrote: > From: zhanglin > > Add max_num_devices to limit dynamic zram device creation to prevent > potential OOM > > Signed-off-by: zhanglin > Signed-off-by: Yi Wang > --- > v1->v2: > change hard-coded initial max_num_devices into

[ANNOUNCE] 4.14.197-rt95

Hello RT-list! I'm pleased to announce the 4.14.197-rt95 stable release. In addition to the merge of the .196 and .197 stable release tags, this release contains three RT specific fixes: eba893980303 net: xfrm: fix compress vs decompress serialization 23d7ce6a6ca9 Bluetooth: Acquire

Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)

On Thu, 10 Sep 2020, Kees Cook wrote: > [kees: re-sending this series on behalf of John Wood > also visible at https://github.com/johwood/linux fbfam] > > From: John Wood Why are you resending this? The author of the code needs to be able to send and receive emails directly as part of

Re: [REGRESSION] x86/entry: Tracer no longer has opportunity to change the syscall number at entry via orig_ax

On Wed, Sep 09, 2020 at 11:53:42PM +1000, Michael Ellerman wrote: > I can observe the difference between v5.8 and mainline, using the > raw_syscall trace event and running the seccomp_bpf selftest which turns > a getpid (39) into a getppid (110). > > With v5.8 we see getppid on entry and exit: >

Re: [PATCH net-next] octeontx2-af: Constify npc_kpu_profile_{action,cam}

From: Rikard Falkeborn Date: Sat, 12 Sep 2020 00:00:15 +0200 > These are never modified, so constify them to allow the compiler to > place them in read-only memory. This moves about 25kB to read-only > memory as seen by the output of the size command. > > Before: >textdata bss

Re: [RFC PATCH v8 0/3] Add support for AT_INTERPRETED (was O_MAYEXEC)

On Wed, 9 Sep 2020, Al Viro wrote: > On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote: > > > > On 08/09/2020 20:50, Al Viro wrote: > > > On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote: > > >> Hi, > > >> > > >> This height patch series rework the previous O_MAYEXEC

[GIT PULL] seccomp fixes for v5.9-rc5

Hi Linus, Please pull these seccomp fixes for v5.9-rc5. This fixes a rare race condition in seccomp when using TSYNC and USER_NOTIF together where a memory allocation would not get freed (found by syzkaller, fixed by Tycho). Additionally updates Tycho's MAINTAINERS and .mailmap entries for his

[PATCH] RISC-V: Consider sparse memory while removing unusable memory

Currently, any usable memory area beyond page_offset is removed by adding the memory sizes from each memblock. That may not work for sparse memory as memory regions can be very far apart resulting incorrect removal of some usable memory. Just use the start of the first memory block and the end of

Re: [PATCH net v1] hinic: fix rewaking txq after netif_tx_disable

From: Luo bin Date: Thu, 10 Sep 2020 22:04:40 +0800 > When calling hinic_close in hinic_set_channels, all queues are > stopped after netif_tx_disable, but some queue may be rewaken in > free_tx_poll by mistake while drv is handling tx irq. If one queue > is rewaken core may call hinic_xmit_frame

[ANNOUNCE] 4.9.235-rt153

Hello RT-list! I'm pleased to announce the 4.9.235-rt153 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.9-rt Head SHA1: 0e7258df4e13bd29c182837d9b642b2ad7868847 Or to build 4.9.235-rt153

Re: [PATCH net] net: ipa: fix u32_replace_bits by u32p_xxx version

From: Vadym Kochan Date: Thu, 10 Sep 2020 18:41:52 +0300 > Looks like u32p_replace_bits() should be used instead of > u32_replace_bits() which does not modifies the value but returns the > modified version. > > Fixes: 2b9feef2b6c2 ("soc: qcom: ipa: filter and routing tables") > Signed-off-by:

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

On Thu, 10 Sep 2020, Matthew Wilcox wrote: > On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: > > There is also the use case of noexec mounts and file permissions. From > > user space point of view, it doesn't matter which kernel component is in > > charge of defining the policy.

Re: [PATCH net-next v3 0/9] net: ethernet: ti: ale: add static configuration

From: Grygorii Strashko Date: Thu, 10 Sep 2020 23:27:58 +0300 > As existing, as newly introduced CPSW ALE versions have differences in > supported features and ALE table formats. Especially it's actual for the > recent AM65x/J721E/J7200 and future AM64x SoCs, which supports more > features

Re: [PATCH] net: ethernet: ti: cpsw_new: fix suspend/resume

From: Grygorii Strashko Date: Thu, 10 Sep 2020 23:52:29 +0300 > Add missed suspend/resume callbacks to properly restore networking after > suspend/resume cycle. > > Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based > driver part 1 - dual-emac") > Signed-off-by: Grygorii

Re: [PATCH v3 net-next] net: phy: mchp: Add support for LAN8814 QUAD PHY

From: Divya Koppera Date: Fri, 11 Sep 2020 18:48:44 +0530 > LAN8814 is a low-power, quad-port triple-speed (10BASE-T/100BASETX/1000BASE-T) > Ethernet physical layer transceiver (PHY). It supports transmission and > reception of data on standard CAT-5, as well as CAT-5e and CAT-6, unshielded >

Re: [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"

From: Geert Uytterhoeven Date: Fri, 11 Sep 2020 08:32:55 +0200 > Hi David, > > On Thu, Sep 10, 2020 at 9:20 PM David Miller wrote: >> From: Geert Uytterhoeven >> Date: Tue, 1 Sep 2020 17:02:37 +0200 >> >> > This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c. >> > >> > Inami-san

Re: [PATCH] drm: xlnx: remove defined but not used 'scaling_factors_666'

On Fri, Sep 11, 2020 at 09:27:08AM -0700, Hyun Kwon wrote: > Hi Daniel, > > On Fri, Sep 11, 2020 at 01:15:19AM -0700, Daniel Vetter wrote: > > On Thu, Sep 10, 2020 at 11:14:18AM -0700, Hyun Kwon wrote: > > > Hi Jason, > > > > > > On Thu, Sep 10, 2020 at 07:06:30AM -0700, Jason Yan wrote: > > > >

[PATCH net-next v2 2/7] net: ipa: replace ipa->suspend_ref with a flag bit

For suspend/resume, we currently take an extra clock reference to prevent the IPA clock from being shut down until a power management suspend request arrives. An atomic field in the IPA structure is used to indicate whether this reference has been taken. Instead, introduce a new flags bitmap in

[PATCH net-next v2 1/7] net: ipa: use refcount_t for IPA clock reference count

Take advantage of the checking provided by refcount_t, rather than using a plain atomic to represent the IPA clock reference count. Note that we need to *set* the value to 1 in ipa_clock_get() rather than incrementing it from 0 (because doing that is considered an error for a refcount_t).

[PATCH net-next v2 3/7] net: ipa: verify reference flag values

We take a single IPA clock reference to keep the clock running until we get a system suspend operation, and maintain a flag indicating whether that reference has been taken. When a suspend request arrives, we drop that reference and clear the flag. In most places we simply set or clear the

[PATCH net-next v2 7/7] net: ipa: do not enable GSI interrupt for wakeup

We now trigger a system resume when we receive an IPA SUSPEND interrupt. We should *not* wake up on GSI interrupts. Signed-off-by: Alex Elder --- drivers/net/ipa/gsi.c | 17 - drivers/net/ipa/gsi.h | 1 - 2 files changed, 4 insertions(+), 14 deletions(-) diff --git

[PATCH net-next v2 5/7] net: ipa: use device_init_wakeup()

The call to wakeup_source_register() in ipa_probe() does not do what it was intended to do. Call device_init_wakeup() in ipa_setup() instead, to set the IPA device as wakeup-capable and to initially enable wakeup capability. When we receive a SUSPEND interrupt, call pm_wakeup_dev_event() with a

[PATCH net-next v2 0/7] net: ipa: wake up system on RX available

This series arranges for the IPA driver to wake up a suspended system if the IPA hardware has a packet to deliver to the AP. Version 2 replaces the first patch from version 1 with three patches, in response to David Miller's feedback. Specifically: - The first patch now replaces an atomic_t

[PATCH net-next v2 4/7] net: ipa: manage endpoints separate from clock

Currently, when (before) the last IPA clock reference is dropped, all endpoints are suspended. And whenever the first IPA clock reference is taken, all endpoints are resumed (or started). In most cases there's no need to start endpoints when the clock starts. So move the calls to

[PATCH net-next v2 6/7] net: ipa: enable wakeup on IPA interrupt

Now that we handle wakeup interrupts properly, arrange for the IPA interrupt to be treated as a wakeup interrupt. Signed-off-by: Alex Elder --- drivers/net/ipa/ipa_interrupt.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/ipa/ipa_interrupt.c

kernel panic: stack is corrupted in get_kernel_gp_address

Hello, syzbot found the following issue on: HEAD commit:f4d51dff Linux 5.9-rc4 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14aa2d3e90 kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9 dashboard link:

Re: [PATCH v3 04/10] PCI/RCEC: Add pcie_walk_rcec() to walk associated RCiEPs

On Fri, Sep 11, 2020 at 04:16:03PM -0700, Sean V Kelley wrote: > On 4 Sep 2020, at 19:23, Bjorn Helgaas wrote: > > On Fri, Sep 04, 2020 at 10:18:30PM +, Kelley, Sean V wrote: > > > Hi Bjorn, > > > > > > Quick question below... > > > > > > On Wed, 2020-09-02 at 14:55 -0700, Sean V Kelley

Re: [PATCH v2 1/1] Input: atmel_mxt_ts - implement I2C retries

Hi Andy Thanks for your comment On 2020/09/06 3:02, Andy Shevchenko wrote: On Thursday, September 3, 2020, Jiada Wang > wrote: From: Nick Dyer mailto:nick.d...@itdev.co.uk>> Some maXTouch chips (eg mXT1386) will not respond on the first I2C

[PATCH] core/entry: Report syscall correctly for trace and audit

On v5.8 when doing seccomp syscall rewrites (e.g. getpid into getppid as seen in the seccomp selftests), trace (and audit) correctly see the rewritten syscall on entry and exit: seccomp_bpf-1307 [000] 22974.874393: sys_enter: NR 110 (... seccomp_bpf-1307 [000] .N..

[no subject]

-- I, Mikhail Fridman have selected you specifically as one of my beneficiaries for my Charitable Donation of $5 Million Dollars, Check the link below for confirmation: https://www.rt.com/business/343781-mikhail-fridman-will-charity/ I await your earliest response for further directives.

[PATCH v4 1/1] Input: atmel_mxt_ts - implement I2C retries

From: Nick Dyer Some maXTouch chips (eg mXT1386) will not respond on the first I2C request when they are in a sleep state. It must be retried after a delay for the chip to wake up. Signed-off-by: Nick Dyer [gdavis: Forward port and fix conflicts.] Signed-off-by: George G. Davis [jiada: return

Re: [PATCH] i2c: do not acpi/of match device in i2c_device_probe()

On (20/08/26 23:49), Sergey Senozhatsky wrote: > i2c, apparently, can match the same device twice - the first > time in ->match bus hook (i2c_device_match()), and the second > one in ->probe (i2c_device_probe()) bus hook. > > To make things more complicated, the second matching does not > do

[RFC/RFT PATCH v2 0/5] Unify NUMA implementation between ARM64 & RISC-V

This series attempts to move the ARM64 numa implementation to common code so that RISC-V can leverage that as well instead of reimplementing it again. RISC-V specific bits are based on initial work done by Greentime Hu [1] but modified to reuse the common implementation to avoid duplication. [1]

[RFC/RFT PATCH v2 2/5] arm64, numa: Change the numa init function name to be generic

As we are using generic numa implementation code, modify the init function name to indicate that generic implementation. Signed-off-by: Atish Patra --- arch/arm64/kernel/acpi_numa.c | 13 - arch/arm64/mm/init.c | 4 ++-- drivers/base/arch_numa.c | 29

[RFC/RFT PATCH v2 5/5] riscv: Add numa support for riscv64 platform

Use the generic numa implementation to add NUMA support for RISC-V. This is based on Greentime's patch[1] but modified to use generic NUMA implementation and few more fixes. [1] https://lkml.org/lkml/2020/1/10/233 Co-developed-by: Greentime Hu Signed-off-by: Greentime Hu Signed-off-by: Atish

[RFC/RFT PATCH v2 1/5] numa: Move numa implementation to common code

ARM64 numa implementation is generic enough that RISC-V can reuse that implementation with very minor cosmetic changes. This will help both ARM64 and RISC-V in terms of maintanace and feature improvement Move the numa implementation code to common directory so that both ISAs can reuse this. This

Re: inconsistent lock state in sco_conn_del

syzbot has found a reproducer for the following issue on: HEAD commit:e8878ab8 Merge tag 'spi-fix-v5.9-rc4' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1213075990 kernel config:

  1   2   3   4   5   6   7   8   9   10   >