Re: dm bufio: fix shrinker scans when (nr_to_scan < retain_target)

This was already included as of v4.15-rc4 via commit fbc7c07ec2 ("dm bufio: fix shrinker scans when (nr_to_scan < retain_target)") I even cc'd you on the relevant pull request that I sent to Linus, see: https://www.redhat.com/archives/dm-devel/2017-December/msg00119.html Mike On Thu, Jan 04

Re: dm bufio: fix shrinker scans when (nr_to_scan < retain_target)

This was already included as of v4.15-rc4 via commit fbc7c07ec2 ("dm bufio: fix shrinker scans when (nr_to_scan < retain_target)") I even cc'd you on the relevant pull request that I sent to Linus, see: https://www.redhat.com/archives/dm-devel/2017-December/msg00119.html Mike On Thu, Jan 04

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

Hi! > >> > What remains to be seen is if there are other patterns that affect > >> > different processors. > >> > > >> > In the longer term the compiler itself needs to know what is and isn't > >> > safe (ie you need to be able to write things like > >> > > >> > void foo(tainted __user int *x) >

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

Hi! > >> > What remains to be seen is if there are other patterns that affect > >> > different processors. > >> > > >> > In the longer term the compiler itself needs to know what is and isn't > >> > safe (ie you need to be able to write things like > >> > > >> > void foo(tainted __user int *x) >

Re: [PATCH v4 6/7] ARM: davinci: convert to common clock framework

On Thu, Jan 4, 2018 at 11:50 AM, David Lechner wrote: > > > On 1/4/18 6:39 AM, Sekhar Nori wrote: >> >> On Monday 01 January 2018 05:09 AM, David Lechner wrote: >>> >>> This converts all of arch/arm/mach-davinci to the common clock framework. >>> The clock drivers from

Re: [PATCH v4 6/7] ARM: davinci: convert to common clock framework

On Thu, Jan 4, 2018 at 11:50 AM, David Lechner wrote: > > > On 1/4/18 6:39 AM, Sekhar Nori wrote: >> >> On Monday 01 January 2018 05:09 AM, David Lechner wrote: >>> >>> This converts all of arch/arm/mach-davinci to the common clock framework. >>> The clock drivers from clock.c and psc.c have been

Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

On Thu, Jan 04, 2018 at 12:01:31PM -0700, Logan Gunthorpe wrote: > > @@ -269,18 +270,24 @@ static int rdma_rw_init_single_wr(struct rdma_rw_ctx > *ctx, struct ib_qp *qp, > * @remote_addr:remote address to read/write (relative to @rkey) > * @rkey:remote key to operate on > * @dir:

Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

On Thu, Jan 04, 2018 at 12:01:31PM -0700, Logan Gunthorpe wrote: > > @@ -269,18 +270,24 @@ static int rdma_rw_init_single_wr(struct rdma_rw_ctx > *ctx, struct ib_qp *qp, > * @remote_addr:remote address to read/write (relative to @rkey) > * @rkey:remote key to operate on > * @dir:

Re: [PATCH 12/12] watchdog: sp5100_tco: Add support for recent FCH versions

On Thu, Jan 04, 2018 at 01:01:22PM +0100, Boszormenyi Zoltan wrote: > 2017-12-24 22:04 keltezéssel, Guenter Roeck írta: > >Starting with Family 16h Models 30h-3Fh and Family 15h Models 60h-6Fh, > >watchdog address space decoding has changed. The cutover point is already > >identified in the

Re: [PATCH 12/12] watchdog: sp5100_tco: Add support for recent FCH versions

On Thu, Jan 04, 2018 at 01:01:22PM +0100, Boszormenyi Zoltan wrote: > 2017-12-24 22:04 keltezéssel, Guenter Roeck írta: > >Starting with Family 16h Models 30h-3Fh and Family 15h Models 60h-6Fh, > >watchdog address space decoding has changed. The cutover point is already > >identified in the

Re: [PATCH v5 03/20] firmware: arm_scmi: add basic driver infrastructure for SCMI

Hi Sudeep, thank you for working on this. On Tue, Jan 2, 2018 at 2:42 PM, Sudeep Holla wrote: [...] > diff --git a/drivers/firmware/arm_scmi/driver.c > b/drivers/firmware/arm_scmi/driver.c > new file mode 100644 > index ..58d8f88893e6 > --- /dev/null > +++

Re: [PATCH v5 03/20] firmware: arm_scmi: add basic driver infrastructure for SCMI

Hi Sudeep, thank you for working on this. On Tue, Jan 2, 2018 at 2:42 PM, Sudeep Holla wrote: [...] > diff --git a/drivers/firmware/arm_scmi/driver.c > b/drivers/firmware/arm_scmi/driver.c > new file mode 100644 > index ..58d8f88893e6 > --- /dev/null > +++

Re: [PATCH 0/7] IBRS patch series

On Thu, 2018-01-04 at 11:00 -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen > wrote: > > > > > > Speculation on Skylake and later requires these patches ("dynamic > > IBRS") > > be used instead of retpoline[1]. > Can somebody explain this

Re: [PATCH 0/7] IBRS patch series

On Thu, 2018-01-04 at 11:00 -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen > wrote: > > > > > > Speculation on Skylake and later requires these patches ("dynamic > > IBRS") > > be used instead of retpoline[1]. > Can somebody explain this part? > > I was assuming that

[PATCH v10 8/8] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Signed-off-by: Logan Gunthorpe Cc: Jon Mason --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 30

[PATCH v10 8/8] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Signed-off-by: Logan Gunthorpe Cc: Jon Mason --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 30 +- 1 file changed, 1 insertion(+),

[PATCH v10 1/8] drm/tilcdc: ensure nonatomic iowrite64 is not used

Add a check to ensure iowrite64 is only used if it is atomic. It was decided in [1] that the tilcdc driver should not be using an atomic operation (so it was left out of this patchset). However, it turns out that through the drm code, a nonatomic header is actually included:

[PATCH v10 1/8] drm/tilcdc: ensure nonatomic iowrite64 is not used

Add a check to ensure iowrite64 is only used if it is atomic. It was decided in [1] that the tilcdc driver should not be using an atomic operation (so it was left out of this patchset). However, it turns out that through the drm code, a nonatomic header is actually included:

[PATCH v10 4/8] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v10 4/8] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v10 3/8] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

[PATCH v10 3/8] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

[PATCH v10 5/8] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v10 5/8] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v10 2/8] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-by:

[PATCH v10 2/8] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-by: Michael Ellerman

[PATCH v10 6/8] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang

[PATCH v10 7/8] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

[PATCH v10 6/8] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang Acked-by: Allen Hubbe Acked-by: Jon Mason # Please enter the

[PATCH v10 7/8] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

[PATCH v10 0/8] Add io{read|write}64 to io-64-atomic headers

This is v10 of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their

[PATCH v10 0/8] Add io{read|write}64 to io-64-atomic headers

This is v10 of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their

Re: LKML admins (syzbot emails are not delivered)

04.01.2018, 18:31, "David Miller" : > From: Ozgur > Date: Thu, 04 Jan 2018 12:56:56 +0300 Dvyukov, I think you will set a bot sensitive and syzbot send e-mail that it doesn't disturb list members :) David is sometimes nervous. Ozgur >>  autoanswer is

Re: LKML admins (syzbot emails are not delivered)

04.01.2018, 18:31, "David Miller" : > From: Ozgur > Date: Thu, 04 Jan 2018 12:56:56 +0300 Dvyukov, I think you will set a bot sensitive and syzbot send e-mail that it doesn't disturb list members :) David is sometimes nervous. Ozgur >>  autoanswer is just automated reply address that the

Re: [PATCH 7/7] x86/microcode: Recheck IBRS features on microcode reload

On 01/04/2018 10:50 AM, Borislav Petkov wrote: > On Thu, Jan 04, 2018 at 07:34:30PM +0100, Andrea Arcangeli wrote: >> void spec_ctrl_rescan_cpuid(void) >> { >> int cpu; >> >> if (use_ibp_disable) >> return; >> mutex_lock(_ctrl_mutex); >> if

Re: [PATCH 7/7] x86/microcode: Recheck IBRS features on microcode reload

On 01/04/2018 10:50 AM, Borislav Petkov wrote: > On Thu, Jan 04, 2018 at 07:34:30PM +0100, Andrea Arcangeli wrote: >> void spec_ctrl_rescan_cpuid(void) >> { >> int cpu; >> >> if (use_ibp_disable) >> return; >> mutex_lock(_ctrl_mutex); >> if

Re: [PATCH 0/7] IBRS patch series

On 01/04/2018 11:05 AM, Justin Forbes wrote: > On Thu, Jan 4, 2018 at 11:56 AM, Tim Chen wrote: >> This patch series enables the basic detection and usage of x86 indirect >> branch speculation feature. It enables the indirect branch restricted >> speculation (IBRS) on

Re: [PATCH v7 2/6] perf record: Get the first sample time and last sample time

Em Fri, Dec 08, 2017 at 09:13:42PM +0800, Jin Yao escreveu: > In the default 'perf record' configuration, all samples are processed, > to create the HEADER_BUILD_ID table. So it's very easy to get the > first/last samples and save the time to perf file header via the > function

Re: [PATCH 0/7] IBRS patch series

On 01/04/2018 11:05 AM, Justin Forbes wrote: > On Thu, Jan 4, 2018 at 11:56 AM, Tim Chen wrote: >> This patch series enables the basic detection and usage of x86 indirect >> branch speculation feature. It enables the indirect branch restricted >> speculation (IBRS) on kernel entry and disables

Re: [PATCH v7 2/6] perf record: Get the first sample time and last sample time

Em Fri, Dec 08, 2017 at 09:13:42PM +0800, Jin Yao escreveu: > In the default 'perf record' configuration, all samples are processed, > to create the HEADER_BUILD_ID table. So it's very easy to get the > first/last samples and save the time to perf file header via the > function

Re: [PATCH][next] usbip: vhci: fix spelling mistake: "synchronuously" -> "synchronously"

On 01/03/2018 02:18 AM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_dbg debug message. > > Signed-off-by: Colin Ian King > --- > drivers/usb/usbip/vhci_rx.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH][next] usbip: vhci: fix spelling mistake: "synchronuously" -> "synchronously"

On 01/03/2018 02:18 AM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_dbg debug message. > > Signed-off-by: Colin Ian King > --- > drivers/usb/usbip/vhci_rx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH v1 01/15] ASoC: fsl_ssi: Clean up set_dai_tdm_slot()

On Mon, Jan 01, 2018 at 07:39:52PM +0100, Maciej S. Szmigiero wrote: > > /* The slot number should be >= 2 if using Network mode or I2S mode */ > > - regmap_read(regs, REG_SSI_SCR, ); > > - val &= SSI_SCR_I2S_MODE_MASK | SSI_SCR_NET; > > - if (val && slots < 2) { > > + if

Re: [PATCH 07/12] nvme-pci: clean up CMB initialization

On 04/01/18 12:01 PM, Logan Gunthorpe wrote: From: Christoph Hellwig Refactor the call to nvme_map_cmb, and change the conditions for probing for the CMB. First remove the version check as NVMe TPs always apply to earlier versions of the spec as well. Second check for the

Re: [PATCH 08/12] nvme-pci: clean up SMBSZ bit definitions

On 04/01/18 12:01 PM, Logan Gunthorpe wrote: From: Christoph Hellwig Define the bit positions instead of macros using the magic values, and move the expanded helpers to calculate the size and size unit into the implementation C file. Signed-off-by: Christoph Hellwig

Re: [PATCH v1 01/15] ASoC: fsl_ssi: Clean up set_dai_tdm_slot()

On Mon, Jan 01, 2018 at 07:39:52PM +0100, Maciej S. Szmigiero wrote: > > /* The slot number should be >= 2 if using Network mode or I2S mode */ > > - regmap_read(regs, REG_SSI_SCR, ); > > - val &= SSI_SCR_I2S_MODE_MASK | SSI_SCR_NET; > > - if (val && slots < 2) { > > + if

Re: [PATCH 07/12] nvme-pci: clean up CMB initialization

On 04/01/18 12:01 PM, Logan Gunthorpe wrote: From: Christoph Hellwig Refactor the call to nvme_map_cmb, and change the conditions for probing for the CMB. First remove the version check as NVMe TPs always apply to earlier versions of the spec as well. Second check for the whole CMBSZ

Re: [PATCH 08/12] nvme-pci: clean up SMBSZ bit definitions

On 04/01/18 12:01 PM, Logan Gunthorpe wrote: From: Christoph Hellwig Define the bit positions instead of macros using the magic values, and move the expanded helpers to calculate the size and size unit into the implementation C file. Signed-off-by: Christoph Hellwig Oops, I forgot:

Re: [PATCH v1 11/15] ASoC: fsl_ssi: Setup AC97 in dai_probe()

On Mon, Jan 01, 2018 at 04:17:20PM +0100, Maciej S. Szmigiero wrote: > > AC97 configures some registers earlier to start a communication > > with CODECs, so this patch moves those register settings to the > > dai_probe() as well, along with other register configurations. > This patch breaks

Re: [PATCH v1 11/15] ASoC: fsl_ssi: Setup AC97 in dai_probe()

On Mon, Jan 01, 2018 at 04:17:20PM +0100, Maciej S. Szmigiero wrote: > > AC97 configures some registers earlier to start a communication > > with CODECs, so this patch moves those register settings to the > > dai_probe() as well, along with other register configurations. > This patch breaks

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On Thu, Jan 04, 2018 at 10:59:35AM -0800, Dave Hansen wrote: > On 01/04/2018 10:52 AM, Borislav Petkov wrote: > >> Paranoid people want "IBRS always" aka "ibrs 2". > > > > So why not "IBRS always" or off? No need for the "IBRS only in the > > kernel" setting. > > IBRS=1 slows execution down. If

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On Thu, Jan 04, 2018 at 10:59:35AM -0800, Dave Hansen wrote: > On 01/04/2018 10:52 AM, Borislav Petkov wrote: > >> Paranoid people want "IBRS always" aka "ibrs 2". > > > > So why not "IBRS always" or off? No need for the "IBRS only in the > > kernel" setting. > > IBRS=1 slows execution down. If

[PATCH 12/12] nvmet: Optionally use PCI P2P memory

We create a configfs attribute in each nvme-fabrics target port to enable p2p memory use. When enabled, the port will only then use the p2p memory if a p2p memory device can be found which is behind the same switch as the RDMA port and all the block devices in use. If the user enabled it an no

[PATCH 12/12] nvmet: Optionally use PCI P2P memory

We create a configfs attribute in each nvme-fabrics target port to enable p2p memory use. When enabled, the port will only then use the p2p memory if a p2p memory device can be found which is behind the same switch as the RDMA port and all the block devices in use. If the user enabled it an no

[PATCH 08/12] nvme-pci: clean up SMBSZ bit definitions

From: Christoph Hellwig Define the bit positions instead of macros using the magic values, and move the expanded helpers to calculate the size and size unit into the implementation C file. Signed-off-by: Christoph Hellwig --- drivers/nvme/host/pci.c | 23

[PATCH 08/12] nvme-pci: clean up SMBSZ bit definitions

From: Christoph Hellwig Define the bit positions instead of macros using the magic values, and move the expanded helpers to calculate the size and size unit into the implementation C file. Signed-off-by: Christoph Hellwig --- drivers/nvme/host/pci.c | 23 +--

[PATCH 03/12] pci-p2p: Add PCI p2pmem dma mappings to adjust the bus offset

The DMA address used when mapping PCI P2P memory must be the PCI bus address. Thus, introduce pci_p2pmem_[un]map_sg() to map the correct addresses when using P2P memory. For this, we assume that an SGL passed to these functions contain all p2p memory or no p2p memory. Signed-off-by: Logan

[PATCH 03/12] pci-p2p: Add PCI p2pmem dma mappings to adjust the bus offset

The DMA address used when mapping PCI P2P memory must be the PCI bus address. Thus, introduce pci_p2pmem_[un]map_sg() to map the correct addresses when using P2P memory. For this, we assume that an SGL passed to these functions contain all p2p memory or no p2p memory. Signed-off-by: Logan

[PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

Register the CMB buffer as p2pmem and use the appropriate allocation functions to create and destroy the IO SQ. If the CMB supports WDS and RDS, publish it for use as p2p memory by other devices. Signed-off-by: Logan Gunthorpe --- drivers/nvme/host/pci.c | 74

[PATCH 05/12] block: Introduce PCI P2P flags for request and request queue

QUEUE_FLAG_PCI_P2P is introduced meaning a driver's request queue supports targeting P2P memory. REQ_PCI_P2P is introduced to indicate a particular bio request is directed to/from PCI P2P memory. A request with this flag is not accepted unless the corresponding queues have the QUEUE_FLAG_PCI_P2P

[PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

Register the CMB buffer as p2pmem and use the appropriate allocation functions to create and destroy the IO SQ. If the CMB supports WDS and RDS, publish it for use as p2p memory by other devices. Signed-off-by: Logan Gunthorpe --- drivers/nvme/host/pci.c | 74

[PATCH 05/12] block: Introduce PCI P2P flags for request and request queue

QUEUE_FLAG_PCI_P2P is introduced meaning a driver's request queue supports targeting P2P memory. REQ_PCI_P2P is introduced to indicate a particular bio request is directed to/from PCI P2P memory. A request with this flag is not accepted unless the corresponding queues have the QUEUE_FLAG_PCI_P2P

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 11:56 AM, Tim Chen wrote: > This patch series enables the basic detection and usage of x86 indirect > branch speculation feature. It enables the indirect branch restricted > speculation (IBRS) on kernel entry and disables it on exit. > It

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 11:56 AM, Tim Chen wrote: > This patch series enables the basic detection and usage of x86 indirect > branch speculation feature. It enables the indirect branch restricted > speculation (IBRS) on kernel entry and disables it on exit. > It enumerates the indirect branch

[PATCH 10/12] nvme-pci: Add support for P2P memory in requests

For P2P requests we must use the pci_p2pmem_[un]map_sg() functions instead of the dma_map_sg functions. With that, we can then indicate PCI_P2P support in the request queue. For this, we create an NVME_F_PCI_P2P flag which tells the core to set QUEUE_FLAG_PCI_P2P in the request queue.

[PATCH 10/12] nvme-pci: Add support for P2P memory in requests

For P2P requests we must use the pci_p2pmem_[un]map_sg() functions instead of the dma_map_sg functions. With that, we can then indicate PCI_P2P support in the request queue. For this, we create an NVME_F_PCI_P2P flag which tells the core to set QUEUE_FLAG_PCI_P2P in the request queue.

[PATCH 02/12] pci-p2p: Add sysfs group to display p2pmem stats

Attributes display the total amount of P2P memory, the ammount available and whether it is published or not. Signed-off-by: Logan Gunthorpe --- Documentation/ABI/testing/sysfs-bus-pci | 25 drivers/pci/p2p.c | 51

[PATCH 02/12] pci-p2p: Add sysfs group to display p2pmem stats

Attributes display the total amount of P2P memory, the ammount available and whether it is published or not. Signed-off-by: Logan Gunthorpe --- Documentation/ABI/testing/sysfs-bus-pci | 25 drivers/pci/p2p.c | 51 + 2 files

Re: [PATCH] dm bufio: fix shrinker scans when (nr_to_scan < retain_target)

Dear kernel maintainers. I know it was close to holiday season when I send this patch last month, so delay was expected. Could you please take a look at it and provide your feedback? Thanks! On Wed, Dec 6, 2017 at 9:27 AM, Suren Baghdasaryan wrote: > When system is under

Re: [PATCH] dm bufio: fix shrinker scans when (nr_to_scan < retain_target)

Dear kernel maintainers. I know it was close to holiday season when I send this patch last month, so delay was expected. Could you please take a look at it and provide your feedback? Thanks! On Wed, Dec 6, 2017 at 9:27 AM, Suren Baghdasaryan wrote: > When system is under memory pressure it is

[PATCH 11/12] nvme-pci: Add a quirk for a pseudo CMB

Introduce a quirk to use CMB-like memory on older devices that have an exposed BAR but do not advertise support for using CMBLOC and CMBSIZE. We'd like to use some of these older cards to test P2P memory. Signed-off-by: Logan Gunthorpe --- drivers/nvme/host/nvme.h | 7

[PATCH 11/12] nvme-pci: Add a quirk for a pseudo CMB

Introduce a quirk to use CMB-like memory on older devices that have an exposed BAR but do not advertise support for using CMBLOC and CMBSIZE. We'd like to use some of these older cards to test P2P memory. Signed-off-by: Logan Gunthorpe --- drivers/nvme/host/nvme.h | 7 +++

Re: [PATCH v5 03/12] dt-bindings: display: sun4i-drm: Add LVDS properties

Hi, On Sat, Dec 30, 2017 at 12:45:19PM +0100, Jernej Škrabec wrote: > Hi Maxime, > > Dne četrtek, 21. december 2017 ob 12:02:29 CET je Maxime Ripard napisal(a): > > Some clocks and resets supposed to drive the LVDS logic in the display > > engine have been overlooked when the driver was first

Re: [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry

On 04/01/18 18:40, Lorenzo Pieralisi wrote: > [+Marc] > > On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zh...@mediatek.com wrote: >> From: Honghui Zhang >> >> There maybe a same IRQ reentry scenario after IRQ received in current >> IRQ handle flow: >> EP

Re: [PATCH v5 03/12] dt-bindings: display: sun4i-drm: Add LVDS properties

Hi, On Sat, Dec 30, 2017 at 12:45:19PM +0100, Jernej Škrabec wrote: > Hi Maxime, > > Dne četrtek, 21. december 2017 ob 12:02:29 CET je Maxime Ripard napisal(a): > > Some clocks and resets supposed to drive the LVDS logic in the display > > engine have been overlooked when the driver was first

Re: [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry

On 04/01/18 18:40, Lorenzo Pieralisi wrote: > [+Marc] > > On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zh...@mediatek.com wrote: >> From: Honghui Zhang >> >> There maybe a same IRQ reentry scenario after IRQ received in current >> IRQ handle flow: >> EP device PCIe host

[PATCH 01/12] pci-p2p: Support peer to peer memory

Some PCI devices may have memory mapped in a BAR space that's intended for use in Peer-to-Peer transactions. In order to enable such transactions the memory must be registered with ZONE_DEVICE pages so it can be used by DMA interfaces in existing drivers. A kernel interface is provided so that

[PATCH 01/12] pci-p2p: Support peer to peer memory

Some PCI devices may have memory mapped in a BAR space that's intended for use in Peer-to-Peer transactions. In order to enable such transactions the memory must be registered with ZONE_DEVICE pages so it can be used by DMA interfaces in existing drivers. A kernel interface is provided so that

[PATCH 04/12] pci-p2p: Clear ACS P2P flags for all client devices

When the ACS P2P flags are set in the downstream port of the switch, any P2P TLPs will be sent back to the root complex. The whole point of the P2P work is to have TLPs avoid the RC seeing it may not support P2P transactions or, at best, it will perform poorly. So we clear these flags for all

[PATCH 04/12] pci-p2p: Clear ACS P2P flags for all client devices

When the ACS P2P flags are set in the downstream port of the switch, any P2P TLPs will be sent back to the root complex. The whole point of the P2P work is to have TLPs avoid the RC seeing it may not support P2P transactions or, at best, it will perform poorly. So we clear these flags for all

[PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

In order to use PCI P2P memory pci_p2pmem_[un]map_sg() functions must be called to map the correct DMA address. To do this, we add a flags variable and the RDMA_RW_CTX_FLAG_PCI_P2P flag. When the flag is specified use the appropriate map function. Signed-off-by: Logan Gunthorpe

[PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

In order to use PCI P2P memory pci_p2pmem_[un]map_sg() functions must be called to map the correct DMA address. To do this, we add a flags variable and the RDMA_RW_CTX_FLAG_PCI_P2P flag. When the flag is specified use the appropriate map function. Signed-off-by: Logan Gunthorpe ---

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/04/2018 10:34 AM, Andrea Arcangeli wrote: > On Thu, Jan 04, 2018 at 09:56:47AM -0800, Tim Chen wrote: >> There are 2 ways to control IBRS >> >> 1. At boot time >> noibrs kernel boot parameter will disable IBRS usage >> >> Otherwise if the above parameters are not specified, the system >>

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/04/2018 10:34 AM, Andrea Arcangeli wrote: > On Thu, Jan 04, 2018 at 09:56:47AM -0800, Tim Chen wrote: >> There are 2 ways to control IBRS >> >> 1. At boot time >> noibrs kernel boot parameter will disable IBRS usage >> >> Otherwise if the above parameters are not specified, the system >>

Re: [PATCH net] net: stmmac: enable EEE in MII, GMII or RGMII only

From: Jerome Brunet Date: Wed, 3 Jan 2018 16:46:29 +0100 > Note in the databook - Section 4.4 - EEE : > " The EEE feature is not supported when the MAC is configured to use the > TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC > supports multiple PHY

Re: [PATCH net] net: stmmac: enable EEE in MII, GMII or RGMII only

From: Jerome Brunet Date: Wed, 3 Jan 2018 16:46:29 +0100 > Note in the databook - Section 4.4 - EEE : > " The EEE feature is not supported when the MAC is configured to use the > TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC > supports multiple PHY interfaces, you should

[PATCH 07/12] nvme-pci: clean up CMB initialization

From: Christoph Hellwig Refactor the call to nvme_map_cmb, and change the conditions for probing for the CMB. First remove the version check as NVMe TPs always apply to earlier versions of the spec as well. Second check for the whole CMBSZ register for support of the CMB feature

[PATCH 07/12] nvme-pci: clean up CMB initialization

From: Christoph Hellwig Refactor the call to nvme_map_cmb, and change the conditions for probing for the CMB. First remove the version check as NVMe TPs always apply to earlier versions of the spec as well. Second check for the whole CMBSZ register for support of the CMB feature instead of

[PATCH 00/11] Copy Offload in NVMe Fabrics with P2P PCI Memory

Hello, This is a continuation of our work to enable using Peer-to-Peer PCI memory in NVMe fabrics targets. Many thanks go to Christoph Hellwig who provided valuable feedback to get these patches to where they are today. The concept here is to use memory that's exposed on a PCI BAR as data

[PATCH 00/11] Copy Offload in NVMe Fabrics with P2P PCI Memory

Hello, This is a continuation of our work to enable using Peer-to-Peer PCI memory in NVMe fabrics targets. Many thanks go to Christoph Hellwig who provided valuable feedback to get these patches to where they are today. The concept here is to use memory that's exposed on a PCI BAR as data

Re: WARNING in ion_ioctl

On 01/04/2018 06:13 AM, Dmitry Vyukov wrote: On Thu, Jan 4, 2018 at 3:06 PM, Greg KH wrote: On Thu, Jan 04, 2018 at 05:57:01AM -0800, syzbot wrote: Hello, syzkaller hit the following crash on 71ee203389f7cb1c1927eab22b95baa01405791c

Re: WARNING in ion_ioctl

On 01/04/2018 06:13 AM, Dmitry Vyukov wrote: On Thu, Jan 4, 2018 at 3:06 PM, Greg KH wrote: On Thu, Jan 04, 2018 at 05:57:01AM -0800, syzbot wrote: Hello, syzkaller hit the following crash on 71ee203389f7cb1c1927eab22b95baa01405791c

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen wrote: > > Speculation on Skylake and later requires these patches ("dynamic IBRS") > be used instead of retpoline[1]. Can somebody explain this part? I was assuming that retpoline would work around this issue on all uarchs.

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen wrote: > > Speculation on Skylake and later requires these patches ("dynamic IBRS") > be used instead of retpoline[1]. Can somebody explain this part? I was assuming that retpoline would work around this issue on all uarchs. This seems to say "retpoline

unify the interface of the proportional-share policy in blkio/io

Hi Tejun, Jens, all, the shares of storage resources are controlled through weights in the proportional-share policy of the blkio/io controllers of the cgroups subsystem. But, on blk-mq, this control doesn't work for any legacy application, service or tool. In a similar vein, in most of the

unify the interface of the proportional-share policy in blkio/io

Hi Tejun, Jens, all, the shares of storage resources are controlled through weights in the proportional-share policy of the blkio/io controllers of the cgroups subsystem. But, on blk-mq, this control doesn't work for any legacy application, service or tool. In a similar vein, in most of the

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/04/2018 10:52 AM, Borislav Petkov wrote: >> Paranoid people want "IBRS always" aka "ibrs 2". > > So why not "IBRS always" or off? No need for the "IBRS only in the > kernel" setting. IBRS=1 slows execution down. If it's on all the time, you pay a performance cost in userspace. The

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On 01/04/2018 10:52 AM, Borislav Petkov wrote: >> Paranoid people want "IBRS always" aka "ibrs 2". > > So why not "IBRS always" or off? No need for the "IBRS only in the > kernel" setting. IBRS=1 slows execution down. If it's on all the time, you pay a performance cost in userspace. The

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On Thu, Jan 04, 2018 at 07:52:19PM +0100, Borislav Petkov wrote: > So why not "IBRS always" or off? No need for the "IBRS only in the > kernel" setting. Because it's slower (or much slower depending on how much stuff the microcode has to disable in the CPU to provide IBSR) and you only need that

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On Thu, Jan 04, 2018 at 07:52:19PM +0100, Borislav Petkov wrote: > So why not "IBRS always" or off? No need for the "IBRS only in the > kernel" setting. Because it's slower (or much slower depending on how much stuff the microcode has to disable in the CPU to provide IBSR) and you only need that

<    3   4   5   6   7   8   9   10   11   12   >