From: Vaibhav Jain <vaibhav(a)linux.ibm.com>
On Power-8 the AFU attr prefault_mode tried to improve storage fault
performance by prefaulting process segments. However Power-9 radix
mode doesn't have Storage-Segments and prefaulting Pages is too fine
grained.
So this patch updates prefault_mode_store() to not allow any other
value apart from CXL_PREFAULT_NONE when radix mode is enabled.
Cc: <stable(a)vger.kernel.org>
Fixes: f24be42aab37 ("cxl: Add psl9 specific code")
Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com>
---
Documentation/ABI/testing/sysfs-class-cxl | 4 +++-
drivers/misc/cxl/sysfs.c | 16 ++++++++++++----
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
index 640f65e79ef1..267920a1874b 100644
--- a/Documentation/ABI/testing/sysfs-class-cxl
+++ b/Documentation/ABI/testing/sysfs-class-cxl
@@ -69,7 +69,9 @@ Date: September 2014
Contact: linuxppc-dev(a)lists.ozlabs.org
Description: read/write
Set the mode for prefaulting in segments into the segment table
- when performing the START_WORK ioctl. Possible values:
+ when performing the START_WORK ioctl. Only applicable when
+ running under hashed page table mmu.
+ Possible values:
none: No prefaulting (default)
work_element_descriptor: Treat the work element
descriptor as an effective address and
diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
index 4b5a4c5d3c01..629e2e156412 100644
--- a/drivers/misc/cxl/sysfs.c
+++ b/drivers/misc/cxl/sysfs.c
@@ -353,12 +353,20 @@ static ssize_t prefault_mode_store(struct device *device,
struct cxl_afu *afu = to_cxl_afu(device);
enum prefault_modes mode = -1;
- if (!strncmp(buf, "work_element_descriptor", 23))
- mode = CXL_PREFAULT_WED;
- if (!strncmp(buf, "all", 3))
- mode = CXL_PREFAULT_ALL;
if (!strncmp(buf, "none", 4))
mode = CXL_PREFAULT_NONE;
+ else {
+ if (!radix_enabled()) {
+
+ /* only allowed when not in radix mode */
+ if (!strncmp(buf, "work_element_descriptor", 23))
+ mode = CXL_PREFAULT_WED;
+ if (!strncmp(buf, "all", 3))
+ mode = CXL_PREFAULT_ALL;
+ } else {
+ dev_err(device, "Cannot prefault with radix enabled\n");
+ }
+ }
if (mode == -1)
return -EINVAL;
--
2.17.0
Oops sorry, I failed to write the subject. It should been something like the subject of this e-mail.
> -----Original Message-----
> From: stable-owner(a)vger.kernel.org [mailto:stable-owner@vger.kernel.org] On
> Behalf Of Daniel Sangorrin
> Sent: Friday, May 18, 2018 9:59 AM
> To: stable(a)vger.kernel.org
> Cc: mtk.manpages(a)gmail.com; viro(a)zeniv.linux.org.uk
> Subject:
>
> Hello Greg,
>
> After running LTP with Fuego on the LTS kernel 4.4.y, there were
> a few test cases failing that I thought needed some investigation.
>
> I reviewed the first one (fcntl35 and fcntl35_64) so far. According to the
> comments on LTP's fcntl35.c file (by Xiao Yang <yangx.jy(a)cn.fujitsu.com>)
> the bug tested by this test case was fixed by:
> pipe: cap initial pipe capacity according to pipe-max-size
> commit 086e774a57fba4695f14383c0818994c0b31da7c
> Author: Michael Kerrisk (man-pages) <mtk.manpages(a)gmail.com>
> Date: Tue Oct 11 13:53:43 2016 -0700
>
> I backported that patch (see next e-mail), tested again and confirmed that
> the patch fixed the bug (or at least the error message in LTP's test).
>
> Before:
> fcntl35.c:98: FAIL: an unprivileged user init the capacity of a pipe to 65536
> unexpectedly, expected 4096
> After:
> fcntl35.c:101: PASS: an unprivileged user init the capacity of a pipe to 4096
> successfully
>
> Thanks,
> Daniel Sangorrin
>
Hello Greg,
After running LTP with Fuego on the LTS kernel 4.4.y, there were
a few test cases failing that I thought needed some investigation.
I reviewed the first one (fcntl35 and fcntl35_64) so far. According to the
comments on LTP's fcntl35.c file (by Xiao Yang <yangx.jy(a)cn.fujitsu.com>)
the bug tested by this test case was fixed by:
pipe: cap initial pipe capacity according to pipe-max-size
commit 086e774a57fba4695f14383c0818994c0b31da7c
Author: Michael Kerrisk (man-pages) <mtk.manpages(a)gmail.com>
Date: Tue Oct 11 13:53:43 2016 -0700
I backported that patch (see next e-mail), tested again and confirmed that
the patch fixed the bug (or at least the error message in LTP's test).
Before:
fcntl35.c:98: FAIL: an unprivileged user init the capacity of a pipe to 65536 unexpectedly, expected 4096
After:
fcntl35.c:101: PASS: an unprivileged user init the capacity of a pipe to 4096 successfully
Thanks,
Daniel Sangorrin
When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
but Dom Heap is increased by the same size. Tracing raidconfig we found
that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
to apply memory. If the memory allocated by Dom0 is not in the DMA area,
it will exchange memory with Xen to meet the requiment. Later drivers
call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
the check condition (dev_addr + size - 1 <= dma_mask) is always false,
it prevents calling xen_destroy_contiguous_region() to return the memory
to the Xen DMA heap.
This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin <joe.jin(a)oracle.com>
Tested-by: John Sobecki <john.sobecki(a)oracle.com>
Reviewed-by: Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: stable(a)vger.kernel.org
---
drivers/xen/swiotlb-xen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index e1c60899fdbc..a6f9ba85dc4b 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -351,7 +351,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
* physical address */
phys = xen_bus_to_phys(dev_addr);
- if (((dev_addr + size - 1 > dma_mask)) ||
+ if (((dev_addr + size - 1 <= dma_mask)) ||
range_straddles_page_boundary(phys, size))
xen_destroy_contiguous_region(phys, order);
--
2.14.3 (Apple Git-98)
When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
but Dom Heap is increased by the same size. Tracing raidconfig we found
that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
to apply memory. If the memory allocated by Dom0 is not in the DMA area,
it will exchange memory with Xen to meet the requiment. Later drivers
call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
the check condition (dev_addr + size - 1 <= dma_mask) is always false,
it prevents calling xen_destroy_contiguous_region() to return the memory
to the Xen DMA heap.
This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin <joe.jin(a)oracle.com>
Tested-by: John Sobecki <john.sobecki(a)oracle.com>
Reviewed-by: Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: stable(a)vger.kernel.org
---
drivers/xen/swiotlb-xen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index e1c60899fdbc..a6f9ba85dc4b 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -351,7 +351,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
* physical address */
phys = xen_bus_to_phys(dev_addr);
- if (((dev_addr + size - 1 > dma_mask)) ||
+ if (((dev_addr + size - 1 <= dma_mask)) ||
range_straddles_page_boundary(phys, size))
xen_destroy_contiguous_region(phys, order);
--
2.14.3 (Apple Git-98)
v4.4.y:
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_add_dual_emac_def_ale_entries':
drivers/net/ethernet/ti/cpsw.c:1112:23: error: 'cpsw' undeclared
Guenter
On Thu, 2017-10-19 at 16:21 -0400, Josef Bacik wrote:
> + blk_mq_start_request(req);
> if (unlikely(nsock->pending && nsock->pending != req)) {
> blk_mq_requeue_request(req, true);
> ret = 0;
(replying to an e-mail from seven months ago)
Hello Josef,
Are you aware that the nbd driver is one of the very few block drivers that
calls blk_mq_requeue_request() after a request has been started? I think that
can lead to the block layer core to undesired behavior, e.g. that the timeout
handler fires concurrently with a request being reinstered. Can you or a
colleague have a look at this? I would like to add the following code to the
block layer core and I think that the nbd driver would trigger this warning:
void blk_mq_requeue_request(struct request *rq, bool kick_requeue_list)
{
+ WARN_ON_ONCE(old_state != MQ_RQ_COMPLETE);
+
__blk_mq_requeue_request(rq);
Thanks,
Bart.