* Re: [igt-dev] [PATCH i-g-t 1/1] tools/generate_cb_buffer: Add script to assemble CB kernel
From: Petri Latvala @ 2020-02-20 10:10 UTC (permalink / raw)
To: Abodunrin, Akeem G
Cc: Luck, Tony, Aran, Omer, Nikula, Jani, Wilson, Chris P,
Stewart, David C, igt-dev@lists.freedesktop.org,
Pathi, Pragyansri, Bloomfield, Jon, Vetter, Daniel,
Kuoppala, Mika
In-Reply-To: <CFEEE81102D91947B9CC368106979EBAC8A1549D@ORSMSX102.amr.corp.intel.com>
On Thu, Feb 20, 2020 at 03:06:09AM +0200, Abodunrin, Akeem G wrote:
> > > +export ASSEMBLY_SOURCE=./tools/assembly_source
> > > +
> > > +function get_help {
> > > + echo "Usage: asm_eu_kernel.sh [options]"
> > > + echo "Remember to run this as root"
> >
> > I can't spot why this would need root.
> Since we are generating new file, and writing to it - the script definitely needs root access... otherwise commands like this " prefix_header $i915_filename "Media CB Kernel for gen7.5 devices"" fails
That's no reason to need root. That's just a reason to need write
access to the directory where you're creating the files.
As you require the script to be run in IGT source root and writing to
$cwd, you need write access to IGT source root. Which shouldn't be
root-owned.
> >
> >
> > > + echo " "
> > > + echo "Please make sure your MESA tool is compiled, and run this script
> > from igt home directory"
> >
> > Mesa written as "Mesa" and IGT written as "IGT". And it's "source root
> > directory", not "home directory".
> >
> > Does the assembler require specific build options for Mesa? Note them here.
>
> Yes, it does - but the options are hardcoded in this script - so, mentioning them in the help function is irrelevant...
I'm asking about the Mesa _build_ options. This script doesn't build
Mesa, it just uses it.
From a quick check that would be -Dtools=intel that is required.
--
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH] hw/char/pl011: Output characters using best-effort mode
From: Peter Maydell @ 2020-02-20 10:10 UTC (permalink / raw)
To: Marc Zyngier; +Cc: qemu-arm, Gavin Shan, QEMU Developers, Shan Gavin
In-Reply-To: <f3c8adba729d050ba2144cc9c834fe82@kernel.org>
On Thu, 20 Feb 2020 at 09:10, Marc Zyngier <maz@kernel.org> wrote:
>
> On 2020-02-20 06:01, Gavin Shan wrote:
> > This fixes the issue by using newly added API
> > qemu_chr_fe_try_write_all(),
> > which provides another type of service (best-effort). It's different
> > from
> > qemu_chr_fe_write_all() as the data will be dropped if the backend has
> > been running into so-called broken state or 50 attempts of
> > transmissions.
> > The broken state is cleared if the data is transmitted at once.
>
> I don't think dropping the serial port output is an acceptable outcome.
Agreed. The correct fix for this is the one cryptically described
in the XXX comment this patch deletes:
- /* XXX this blocks entire thread. Rewrite to use
- * qemu_chr_fe_write and background I/O callbacks */
The idea is that essentially we end up emulating the real
hardware's transmit FIFO:
* as data arrives from the guest we put it in the FIFO
* we try to send the data with qemu_chr_fe_write(), which does
not block
* if qemu_chr_fe_write() tells us it did not send all the data,
we use qemu_chr_fe_add_watch() to set up an I/O callback
which will get called when the output chardev has drained
enough that we can try again
* we make sure all the guest visible registers and mechanisms
for tracking tx fifo level (status bits, interrupts, etc) are
correctly wired up
Then we don't lose data or block QEMU if the guest sends
faster than the chardev backend can handle, assuming the
guest is well-behaved -- just as with a real hardware slow
serial port, the guest will fill the tx fifo and then either poll
or wait for an interrupt telling it that the fifo has drained
before it tries to send more data.
There is an example of this in hw/char/cadence_uart.c
(and an example of how it works for a UART with no tx
fifo in hw/char-cmsdk-apb-uart.c, which is basically the
same except the 'fifo' is just one byte.)
You will also find an awful lot of XXX comments like the
above one in various UART models in hw/char, because
converting an old-style simple blocking UART implementation
to a non-blocking one is a bit fiddly and needs knowledge
of the specifics of the UART behaviour.
The other approach here would be that we could add
options to relevant chardev backends so the user
could say "if you couldn't connect to the tcp server I
specified, throw away data rather than waiting", where
we don't have suitable options already. If the user specifically
tells us they're ok to throw away the serial data, then it's
fine to throw away the serial data :-)
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH 4/4] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver
From: Xu Zaibo @ 2020-02-20 10:10 UTC (permalink / raw)
To: John Garry, herbert, davem
Cc: qianweili, tanghui20, forest.zhouchang, linuxarm, zhangwei375,
shenyang39, yekai13, linux-crypto
In-Reply-To: <011d8794-b4ab-a5ad-b765-e6e2c09991aa@huawei.com>
Hi,
On 2020/2/20 17:50, John Garry wrote:
> On 20/02/2020 09:04, Zaibo Xu wrote:
>> From: liulongfang <liulongfang@huawei.com>
>>
>> In the scenario of SMMU translation, the SEC performance of short
>> messages
>> (<512Bytes) cannot meet our expectations. To avoid this, we reserve the
>> plat buffer (PBUF) memory for small packets when creating TFM.
>>
>
> I haven't gone through the code here, but why not use this method also
> for non-translated? What are the pros and cons?
Because non-translated has no performance or throughput problems.
cheers,
Zaibo
.
>
> The commit message is very light on details.
>
> Thanks
> john
>
> .
>
^ permalink raw reply
* spi_flash_read issue
From: dvo @ 2020-02-20 10:10 UTC (permalink / raw)
To: u-boot
Hello,
I encounter an issue with spi_flash_read function. I'd copy uboot from SPI
Flash to DDRAM. If I use the function once. It works OK. If I use the
function is more than 1 time, then it doesn't work properly.
Here is the procedure of what I did:
uboot version: U-Boot 2019.07-00013-g6107815c9c
uboot size: 244288 Bytes
case 1:
- Copy uboot to 0x81000000 -> Jump to uboot at 0x81000000 OK
case 2:
- Copy uboot to 0x81000000
- Copy uboot to 0x83000000
-> Jump to uboot at 0x83000000 NOK. Only able to load some parts of uboot
and then hang.
I hexdump and do memory comparison between 0x81000000 and 0x83000000. The
memory is different from i=78078.
Do I need to do something in between 2 copies to solve the issue?
Has anyone experienced this issue?
Thanks for any help or suggestion.
Dan
--
Sent from: http://u-boot.10912.n7.nabble.com/
^ permalink raw reply
* [MODERATED] Re: [PATCH 1/2] more sampling fun 1
From: Andrew Cooper @ 2020-02-20 10:10 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220100745.GA30404@zn.tnic>
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
On 20/02/2020 10:07, speck for Borislav Petkov wrote:
> On Thu, Feb 06, 2020 at 02:11:02PM -0800, speck for mark gross wrote:
>> From: mark gross <mgross@linux.intel.com>
>> Subject: [PATCH 1/2] Add capability to specify a range of steppings in the
>>
>> Intel has produced processors with the same CPUID family+model. Code
>> may need to check the stepping when programming model specific behavior.
>>
>> Add an API to allow easy specification of stepping or range of steppings
>> with a 16 bit bitmask.
>>
>> Update cpu_vuln_whitelist using this new API.
>>
>> I implemented this in the way I did to avoid modifying x86_cpu_id as
>> that structure is an exported ABI and any change would impact user mode
>> code using the structure.
>>
>> Signed-off-by: mark gross <mgross@linux.intel.com>
>> Reviewed-by: tony luck <tony.luck@intel.com>
>> ---
>> arch/x86/include/asm/cpu_device_id.h | 12 ++++++++++++
>> arch/x86/kernel/cpu/common.c | 28 ++++++++++++++--------------
>> arch/x86/kernel/cpu/match.c | 26 ++++++++++++++++++++++++++
>> 3 files changed, 52 insertions(+), 14 deletions(-)
> Why isn't this sent to lkml like a normal patch?
>
Because it is under embargo until May 12th.
~Andrew
^ permalink raw reply
* Re: [PATCH v3 1/2] driver core: Rework logic in __driver_deferred_probe_check_state to allow EPROBE_DEFER to be returned for longer
From: Andy Shevchenko @ 2020-02-20 10:09 UTC (permalink / raw)
To: Saravana Kannan
Cc: John Stultz, lkml, Rob Herring, Bjorn Andersson, Mark Brown,
Greg Kroah-Hartman, Kevin Hilman, Brown, Len, Liam Girdwood,
Linux PM, Pavel Machek, Rafael J. Wysocki, Todd Kjos, Ulf Hansson,
kernel-team
In-Reply-To: <20200220052739.87057-1-saravanak@google.com>
On Thu, Feb 20, 2020 at 7:29 AM Saravana Kannan <saravanak@google.com> wrote:
> On Tue, Feb 18, 2020 at 4:07 PM John Stultz wrote:
> > Due to commit e01afc3250255 ("PM / Domains: Stop deferring probe
> > at the end of initcall"), along with commit 25b4e70dcce9
> > ("driver core: allow stopping deferred probe after init") after
> > late_initcall, drivers will stop getting EPROBE_DEFER, and
> > instead see an error causing the driver to fail to load.
>
> Both of those patches were the best solution at that point in time. But
> the kernel has changed a lot since then. Power domain and IOMMU drivers
> can work as modules now. We have of_devlink and sync_state().
>
> So, while a delay might have been the ideal solution back then, I think
> we need to work towards removing arbitrary timeouts instead of making
> the timeout mechanism more elaborate.
>
> I think driver_deferred_probe_check_state() logic should boiled down
> to something like:
...
> Once we add of_devlink support for power-domains, you won't even hit the
> genpd error path if you have of_devlink enabled. I believe in the case
> you are testing DB 845c, of_devlink is enabled?
>
> If of_devlink is enabled, the devices depending on the unprobed power
> domains would be deferred without even calling the driver's probe()
> function.
>
> Adding power-domain support to of_devlink is a 2 line change. I'll send
> it out soon.
...
Pardon me for not knowing the OF and devlink stuff in particular, but
have you had a chance to test your changes on some (rather complex)
ACPI enabled platforms?
Would it have any complications there?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 6/8] powerpc/papr_scm: Add support for handling PAPR DSM commands
From: Vaibhav Jain @ 2020-02-20 9:58 UTC (permalink / raw)
To: linuxppc-dev
Cc: Vaibhav Jain, Michael Ellerman, Oliver O'Halloran,
Alastair D'Silva, Aneesh Kumar K . V
In-Reply-To: <20200220095805.197229-1-vaibhav@linux.ibm.com>
Implement support for handling PAPR DSM commands in papr_scm
module. We advertise support for ND_CMD_CALL for the dimm command mask
and implement necessary scaffolding in the module to handle ND_CMD_CALL
ioctl and DSM commands that we receive.
The layout of the DSM commands as we expect from libnvdimm/libndctl is
defined in 'struct nd_pkg_papr_scm' which contains a 'struct
nd_cmd_pkg' as header. This header is used to communicate the DSM
command via 'nd_pkg_papr_scm->nd_command' and size of payload that
need to be sent/received for servicing the DSM.
The PAPR DSM commands are assigned indexes started from 0x10000 to
prevent them from overlapping ND_CMD_* values and also makes handling
dimm commands in papr_scm_ndctl() easier via a simplified switch-case
block. For this a new function cmd_to_func() is implemented that reads
the args to papr_scm_ndctl() , performs sanity tests on them and
converts them to PAPR DSM commands which can then be handled via the
switch-case block.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
Change-log:
* Added a 'reserved' field in 'struct nd_pkg_papr_scm' to ensure
'payload' falls on a 8-Byte aligned boundary.
---
arch/powerpc/platforms/pseries/papr_scm.c | 87 +++++++++++++++++++++--
1 file changed, 80 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index 28143a681aa2..d5eea2f38fa6 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -15,13 +15,15 @@
#include <asm/plpar_wrappers.h>
#include <asm/papr_scm.h>
+#include <asm/papr_scm_dsm.h>
#define BIND_ANY_ADDR (~0ul)
#define PAPR_SCM_DIMM_CMD_MASK \
((1ul << ND_CMD_GET_CONFIG_SIZE) | \
(1ul << ND_CMD_GET_CONFIG_DATA) | \
- (1ul << ND_CMD_SET_CONFIG_DATA))
+ (1ul << ND_CMD_SET_CONFIG_DATA) | \
+ (1ul << ND_CMD_CALL))
struct papr_scm_priv {
struct platform_device *pdev;
@@ -330,19 +332,82 @@ static int papr_scm_meta_set(struct papr_scm_priv *p,
return 0;
}
+/*
+ * Validate the input to dimm-control function and return papr_scm specific
+ * commands. This does sanity validation to ND_CMD_CALL sub-command packages.
+ */
+static int cmd_to_func(struct nvdimm *nvdimm, unsigned int cmd, void *buf,
+ unsigned int buf_len)
+{
+ unsigned long cmd_mask = PAPR_SCM_DIMM_CMD_MASK;
+ struct nd_papr_scm_cmd_pkg *pkg = nd_to_papr_cmd_pkg(buf);
+
+ /* Only dimm-specific calls are supported atm */
+ if (!nvdimm)
+ return -EINVAL;
+
+ if (!test_bit(cmd, &cmd_mask)) {
+ pr_debug("%s: Unsupported cmd=%u\n", __func__, cmd);
+ return -EINVAL;
+ } else if (cmd != ND_CMD_CALL) {
+ return cmd;
+ }
+
+ /* cmd == ND_CMD_CALL so verify the envelop package */
+
+ if (!buf || buf_len < sizeof(struct nd_papr_scm_cmd_pkg)) {
+ pr_debug("%s: Invalid pkg size=%u\n", __func__, buf_len);
+ return -EINVAL;
+ }
+
+ if (pkg->hdr.nd_family != NVDIMM_FAMILY_PAPR_SCM) {
+ pr_debug("%s: Invalid pkg family=0x%llx\n", __func__,
+ pkg->hdr.nd_family);
+ return -EINVAL;
+
+ }
+
+ if (pkg->hdr.nd_command <= DSM_PAPR_SCM_MIN ||
+ pkg->hdr.nd_command >= DSM_PAPR_SCM_MAX) {
+
+ /* for unknown subcommands return ND_CMD_CALL */
+ pr_debug("%s: Unknown sub-command=0x%llx\n", __func__,
+ pkg->hdr.nd_command);
+ return ND_CMD_CALL;
+ }
+
+ /* We except a payload with all DSM commands */
+ if (papr_scm_pcmd_to_payload(pkg) == NULL) {
+ pr_debug("%s: Empty patload for sub-command=0x%llx\n", __func__,
+ pkg->hdr.nd_command);
+ return -EINVAL;
+ }
+
+ /* Return the DSM_PAPR_SCM_* command */
+ return pkg->hdr.nd_command;
+}
+
int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
unsigned int cmd, void *buf, unsigned int buf_len, int *cmd_rc)
{
struct nd_cmd_get_config_size *get_size_hdr;
struct papr_scm_priv *p;
+ struct nd_papr_scm_cmd_pkg *call_pkg = NULL;
+ int cmd_in, rc;
- /* Only dimm-specific calls are supported atm */
- if (!nvdimm)
- return -EINVAL;
+ /* Use a local variable in case cmd_rc pointer is NULL */
+ if (cmd_rc == NULL)
+ cmd_rc = &rc;
+
+ cmd_in = cmd_to_func(nvdimm, cmd, buf, buf_len);
+ if (cmd_in < 0) {
+ pr_debug("%s: Invalid cmd=%u. Err=%d\n", __func__, cmd, cmd_in);
+ return cmd_in;
+ }
p = nvdimm_provider_data(nvdimm);
- switch (cmd) {
+ switch (cmd_in) {
case ND_CMD_GET_CONFIG_SIZE:
get_size_hdr = buf;
@@ -360,13 +425,21 @@ int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
*cmd_rc = papr_scm_meta_set(p, buf);
break;
+ case ND_CMD_CALL:
+ /* This happens if subcommand package sanity fails */
+ call_pkg = nd_to_papr_cmd_pkg(buf);
+ call_pkg->cmd_status = -ENOENT;
+ *cmd_rc = 0;
+ break;
+
default:
- return -EINVAL;
+ dev_dbg(&p->pdev->dev, "Unknown command = %d\n", cmd_in);
+ *cmd_rc = -EINVAL;
}
dev_dbg(&p->pdev->dev, "returned with cmd_rc = %d\n", *cmd_rc);
- return 0;
+ return *cmd_rc;
}
static inline int papr_scm_node(int node)
--
2.24.1
^ permalink raw reply related
* [LTP] [PATCH V2 05/10] syscalls/fsconfig: New tests
From: Li Wang @ 2020-02-20 10:09 UTC (permalink / raw)
To: ltp
In-Reply-To: <20200220055024.fgh2uxje6yanrshh@vireshk-i7>
On Thu, Feb 20, 2020 at 1:50 PM Viresh Kumar <viresh.kumar@linaro.org>
wrote:
> On 20-02-20, 13:41, Li Wang wrote:
> > > + TEST(fsconfig(fd, FSCONFIG_SET_PATH, "foo", tst_device->dev,
> > > AT_FDCWD));
> > > + if (TST_RET == -1) {
> > > + if (TST_ERR == EOPNOTSUPP) {
> > > + tst_res(TINFO, "fsconfig(): FSCONFIG_SET_PATH
> not
> > > supported");
>
> On my ARM setup, I always hit this path for few of the syscalls :(
>
> > > + } else {
> > > + tst_res(TFAIL | TERRNO, "fsconfig() failed");
> > >
> >
> > The test reports an EINVAL error when testing fsconfig() with
> > 'FSCONFIG_SET_PATH' on XFS. I'm now trying to look close to this issue.
> >
> > kernel: 5.6.0-rc2+ x86_64
> >
> > tst_test.c:1278: INFO: Testing on xfs
> > tst_mkfs.c:90: INFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
> > tst_test.c:1217: INFO: Timeout per run is 0h 05m 00s
> > fsconfig01.c:46: FAIL: fsconfig() failed: EINVAL (22)
>
> Both "foo" and tst_device->dev may be wrong here unfortunately. Same
> for few other commands like: _PATH, _PATH_EMPTY, _FD..
>
If the parameter '_key' is replaced by 'ro' or 'rw', then the test always
gets passed, the same behavior occurred in fspick01 too.
I'm not sure if the usage is correct for fsconfig(), it'd be great if FS
guys could give advice.
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200220/d12ad1c0/attachment.htm>
^ permalink raw reply
* Re: [PATCH] sched/fair: add !se->on_rq check before dequeue entity
From: chenqiwu @ 2020-02-20 10:09 UTC (permalink / raw)
To: Vincent Guittot
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel, chenqiwu
In-Reply-To: <CAKfTPtDzb9XD5wrMhcvGn+dz27nh58taDrdp36YHKNusp739Og@mail.gmail.com>
On Thu, Feb 20, 2020 at 10:38:02AM +0100, Vincent Guittot wrote:
> On Thu, 20 Feb 2020 at 08:29, <qiwuchen55@gmail.com> wrote:
> >
> > From: chenqiwu <chenqiwu@xiaomi.com>
> >
> > We igonre checking for !se->on_rq condition before dequeue one
> > entity from cfs rq. It must be required in case the entity has
> > been dequeued.
>
> Do you have a use case that triggers this situation ?
>
> This is the only way to reach this situation seems to be dequeuing a
> task on a throttled cfs_rq
>
Sorry, I have no use case triggers this situation. It's just found by
reading code.
I agree the situation you mentioned above may have a racy with
dequeue_task_fair() in the following code path:
__schedule
pick_next_task_fair
put_prev_entity
check_cfs_rq_runtime
throttle_cfs_rq
dequeue_entity
So this check is worth to be added for dequeue_task_fair().
^ permalink raw reply
* [PATCH 4/8] UAPI: ndctl: Introduce NVDIMM_FAMILY_PAPR_SCM as a new NVDIMM DSM family
From: Vaibhav Jain @ 2020-02-20 9:58 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Alastair D'Silva, Aneesh Kumar K . V, Oliver O'Halloran,
Vishal Verma, Vaibhav Jain, Michael Ellerman, Dan Williams
In-Reply-To: <20200220095805.197229-1-vaibhav@linux.ibm.com>
Add PAPR-scm family of DSM command-set to the white list of NVDIMM
command sets.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
include/uapi/linux/ndctl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/ndctl.h b/include/uapi/linux/ndctl.h
index de5d90212409..99fb60600ef8 100644
--- a/include/uapi/linux/ndctl.h
+++ b/include/uapi/linux/ndctl.h
@@ -244,6 +244,7 @@ struct nd_cmd_pkg {
#define NVDIMM_FAMILY_HPE2 2
#define NVDIMM_FAMILY_MSFT 3
#define NVDIMM_FAMILY_HYPERV 4
+#define NVDIMM_FAMILY_PAPR_SCM 5
#define ND_IOCTL_CALL _IOWR(ND_IOCTL, ND_CMD_CALL,\
struct nd_cmd_pkg)
--
2.24.1
^ permalink raw reply related
* [PATCH v2 1/2] RDMA/rw: fix error flow during RDMA context initialization
From: Max Gurtovoy @ 2020-02-20 10:08 UTC (permalink / raw)
To: jgg, leon, linux-rdma; +Cc: israelr, logang, Max Gurtovoy
In case the SGL was mapped for P2P DMA operation, we must unmap it using
pci_p2pdma_unmap_sg.
Fixes: 7f73eac3a713 ("PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg()")
Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
---
drivers/infiniband/core/rw.c | 32 +++++++++++++++++++++-----------
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/core/rw.c b/drivers/infiniband/core/rw.c
index 4fad732f9b3c..69513b484507 100644
--- a/drivers/infiniband/core/rw.c
+++ b/drivers/infiniband/core/rw.c
@@ -273,6 +273,24 @@ static int rdma_rw_init_single_wr(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
return 1;
}
+static void rdma_rw_unmap_sg(struct ib_device *dev, struct scatterlist *sg,
+ u32 sg_cnt, enum dma_data_direction dir)
+{
+ if (is_pci_p2pdma_page(sg_page(sg)))
+ pci_p2pdma_unmap_sg(dev->dma_device, sg, sg_cnt, dir);
+ else
+ ib_dma_unmap_sg(dev, sg, sg_cnt, dir);
+}
+
+static int rdma_rw_map_sg(struct ib_device *dev, struct scatterlist *sg,
+ u32 sg_cnt, enum dma_data_direction dir)
+{
+ if (is_pci_p2pdma_page(sg_page(sg)))
+ return pci_p2pdma_map_sg(dev->dma_device, sg, sg_cnt, dir);
+ else
+ return ib_dma_map_sg(dev, sg, sg_cnt, dir);
+}
+
/**
* rdma_rw_ctx_init - initialize a RDMA READ/WRITE context
* @ctx: context to initialize
@@ -295,11 +313,7 @@ int rdma_rw_ctx_init(struct rdma_rw_ctx *ctx, struct ib_qp *qp, u8 port_num,
struct ib_device *dev = qp->pd->device;
int ret;
- if (is_pci_p2pdma_page(sg_page(sg)))
- ret = pci_p2pdma_map_sg(dev->dma_device, sg, sg_cnt, dir);
- else
- ret = ib_dma_map_sg(dev, sg, sg_cnt, dir);
-
+ ret = rdma_rw_map_sg(dev, sg, sg_cnt, dir);
if (!ret)
return -ENOMEM;
sg_cnt = ret;
@@ -338,7 +352,7 @@ int rdma_rw_ctx_init(struct rdma_rw_ctx *ctx, struct ib_qp *qp, u8 port_num,
return ret;
out_unmap_sg:
- ib_dma_unmap_sg(dev, sg, sg_cnt, dir);
+ rdma_rw_unmap_sg(dev, sg, sg_cnt, dir);
return ret;
}
EXPORT_SYMBOL(rdma_rw_ctx_init);
@@ -588,11 +602,7 @@ void rdma_rw_ctx_destroy(struct rdma_rw_ctx *ctx, struct ib_qp *qp, u8 port_num,
break;
}
- if (is_pci_p2pdma_page(sg_page(sg)))
- pci_p2pdma_unmap_sg(qp->pd->device->dma_device, sg,
- sg_cnt, dir);
- else
- ib_dma_unmap_sg(qp->pd->device, sg, sg_cnt, dir);
+ rdma_rw_unmap_sg(qp->pd->device, sg, sg_cnt, dir);
}
EXPORT_SYMBOL(rdma_rw_ctx_destroy);
--
2.20.1
^ permalink raw reply related
* [PATCH v2 2/2] RDMA/rw: map P2P memory correctly for signature operations
From: Max Gurtovoy @ 2020-02-20 10:08 UTC (permalink / raw)
To: jgg, leon, linux-rdma; +Cc: israelr, logang, Max Gurtovoy
In-Reply-To: <20200220100819.41860-1-maxg@mellanox.com>
Since RDMA rw API support operations with P2P memory sg list, make sure
to map/unmap the scatter list for signature operation correctly.
Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
---
drivers/infiniband/core/rw.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/rw.c b/drivers/infiniband/core/rw.c
index 69513b484507..6eba8453f206 100644
--- a/drivers/infiniband/core/rw.c
+++ b/drivers/infiniband/core/rw.c
@@ -392,13 +392,13 @@ int rdma_rw_ctx_signature_init(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
return -EINVAL;
}
- ret = ib_dma_map_sg(dev, sg, sg_cnt, dir);
+ ret = rdma_rw_map_sg(dev, sg, sg_cnt, dir);
if (!ret)
return -ENOMEM;
sg_cnt = ret;
if (prot_sg_cnt) {
- ret = ib_dma_map_sg(dev, prot_sg, prot_sg_cnt, dir);
+ ret = rdma_rw_map_sg(dev, prot_sg, prot_sg_cnt, dir);
if (!ret) {
ret = -ENOMEM;
goto out_unmap_sg;
@@ -467,9 +467,9 @@ int rdma_rw_ctx_signature_init(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
kfree(ctx->reg);
out_unmap_prot_sg:
if (prot_sg_cnt)
- ib_dma_unmap_sg(dev, prot_sg, prot_sg_cnt, dir);
+ rdma_rw_unmap_sg(dev, prot_sg, prot_sg_cnt, dir);
out_unmap_sg:
- ib_dma_unmap_sg(dev, sg, sg_cnt, dir);
+ rdma_rw_unmap_sg(dev, sg, sg_cnt, dir);
return ret;
}
EXPORT_SYMBOL(rdma_rw_ctx_signature_init);
@@ -629,9 +629,9 @@ void rdma_rw_ctx_destroy_signature(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
ib_mr_pool_put(qp, &qp->sig_mrs, ctx->reg->mr);
kfree(ctx->reg);
- ib_dma_unmap_sg(qp->pd->device, sg, sg_cnt, dir);
if (prot_sg_cnt)
- ib_dma_unmap_sg(qp->pd->device, prot_sg, prot_sg_cnt, dir);
+ rdma_rw_unmap_sg(qp->pd->device, prot_sg, prot_sg_cnt, dir);
+ rdma_rw_unmap_sg(qp->pd->device, sg, sg_cnt, dir);
}
EXPORT_SYMBOL(rdma_rw_ctx_destroy_signature);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 04/17] s390x: protvirt: Add diag308 subcodes 8 - 10
From: Cornelia Huck @ 2020-02-20 10:07 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200214151636.8764-5-frankja@linux.ibm.com>
On Fri, 14 Feb 2020 10:16:23 -0500
Janosch Frank <frankja@linux.ibm.com> wrote:
> For diag308 subcodes 8 - 10 we have a new ipib of type 5. The ipib
> holds the address and length of the secure execution header, as well
> as a list of guest components.
>
> Each component is a block of memory, for example kernel or initrd,
> which needs to be decrypted by the Ultravisor in order to run a
> protected VM. The secure execution header instructs the Ultravisor on
> how to handle the protected VM and its components.
>
> Subcodes 8 and 9 are similiar to 5 and 6 and subcode 10 will finally
> start the protected guest.
>
> Subcodes 8-10 are not valid in protected mode, we have to do a subcode
> 3 and then the 8 and 10 combination for a protected reboot.
>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ---
> hw/s390x/ipl.c | 48 ++++++++++++++++++++++++++++++++++++++++++---
> hw/s390x/ipl.h | 31 +++++++++++++++++++++++++++++
> target/s390x/diag.c | 27 ++++++++++++++++++++++---
> 3 files changed, 100 insertions(+), 6 deletions(-)
(...)
> void s390_ipl_update_diag308(IplParameterBlock *iplb)
> {
> S390IPLState *ipl = get_ipl_device();
>
> - ipl->iplb = *iplb;
> - ipl->iplb_valid = true;
> + if (iplb->pbt == 5) {
Magic value; maybe introduce a #define or at least a comment?
> + ipl->iplb_pbt5 = *iplb;
> + ipl->iplb_valid_pbt5 = true;
> + } else {
> + ipl->iplb = *iplb;
> + ipl->iplb_valid = true;
> + }
> ipl->netboot = is_virtio_net_device(iplb);
> }
> @@ -133,6 +154,7 @@ struct S390IPLState {
> /*< private >*/
> DeviceState parent_obj;
> IplParameterBlock iplb;
> + IplParameterBlock iplb_pbt5;
Add /* for protected virtualization */ ?
Or, if this is not used for anything else, call it iplb_pv?
> QemuIplParameters qipl;
> uint64_t start_addr;
> uint64_t compat_start_addr;
(...)
> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
> index b5aec06d6b..4ba6033609 100644
> --- a/target/s390x/diag.c
> +++ b/target/s390x/diag.c
> @@ -52,6 +52,8 @@ int handle_diag_288(CPUS390XState *env, uint64_t r1, uint64_t r3)
> #define DIAG_308_RC_OK 0x0001
> #define DIAG_308_RC_NO_CONF 0x0102
> #define DIAG_308_RC_INVALID 0x0402
> +#define DIAG_308_RC_NO_PV_CONF 0x0a02
> +#define DIAG_308_RC_INV_FOR_PV 0x0b02
DIAG_308_RC_INVAL_FOR_PV ?
>
> #define DIAG308_RESET_MOD_CLR 0
> #define DIAG308_RESET_LOAD_NORM 1
(...)
> @@ -128,17 +135,31 @@ out:
> g_free(iplb);
> return;
> case DIAG308_STORE:
> + case DIAG308_PV_STORE:
> if (diag308_parm_check(env, r1, addr, ra, true)) {
> return;
> }
> - iplb = s390_ipl_get_iplb();
> + if (subcode == DIAG308_PV_STORE) {
> + iplb = s390_ipl_get_iplb_secure();
> + } else {
> + iplb = s390_ipl_get_iplb();
> + }
iplb = (subcode == DIAG308_PV_STORE) ?
s390_ipl_get_iplb_secure() : s390_ipl_get_iplb();
Matter of taste, I guess.
> if (iplb) {
> cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
> env->regs[r1 + 1] = DIAG_308_RC_OK;
> } else {
> env->regs[r1 + 1] = DIAG_308_RC_NO_CONF;
> }
> - return;
> + break;
> + case DIAG308_PV_START:
> + iplb = s390_ipl_get_iplb_secure();
> + if (!iplb || !iplb_valid_pv(iplb)) {
> + env->regs[r1 + 1] = DIAG_308_RC_NO_PV_CONF;
> + return;
> + }
> +
> + s390_ipl_reset_request(cs, S390_RESET_PV);
> + break;
> default:
> s390_program_interrupt(env, PGM_SPECIFICATION, ra);
> break;
^ permalink raw reply
* Re: [PATCH v3] binfmt_misc: pass binfmt_misc flags to the interpreter
From: Laurent Vivier @ 2020-02-20 10:07 UTC (permalink / raw)
To: linux-kernel
Cc: linux-fsdevel, YunQiang Su, YunQiang Su, Alexander Viro,
James Bottomley
In-Reply-To: <d2993cd1-f671-380c-5887-52c987b84cd0@vivier.eu>
I'd like to have this in the kernel to be able to use it in QEMU (next
QEMU release is 28/04, freeze 17/03).
Thanks,
Laurent
Le 14/02/2020 à 13:29, Laurent Vivier a écrit :
> Hi,
>
> any comment?
>
> I think I've addressed comments on v2.
>
> Thanks,
> Laurent
>
> Le 28/01/2020 à 14:25, Laurent Vivier a écrit :
>> It can be useful to the interpreter to know which flags are in use.
>>
>> For instance, knowing if the preserve-argv[0] is in use would
>> allow to skip the pathname argument.
>>
>> This patch uses an unused auxiliary vector, AT_FLAGS, to add a
>> flag to inform interpreter if the preserve-argv[0] is enabled.
>>
>> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
>> ---
>>
>> Notes:
>> This can be tested with QEMU from my branch:
>>
>> https://github.com/vivier/qemu/commits/binfmt-argv0
>>
>> With something like:
>>
>> # cp ..../qemu-ppc /chroot/powerpc/jessie
>>
>> # qemu-binfmt-conf.sh --qemu-path / --systemd ppc --credential yes \
>> --persistent no --preserve-argv0 yes
>> # systemctl restart systemd-binfmt.service
>> # cat /proc/sys/fs/binfmt_misc/qemu-ppc
>> enabled
>> interpreter //qemu-ppc
>> flags: POC
>> offset 0
>> magic 7f454c4601020100000000000000000000020014
>> mask ffffffffffffff00fffffffffffffffffffeffff
>> # chroot /chroot/powerpc/jessie sh -c 'echo $0'
>> sh
>>
>> # qemu-binfmt-conf.sh --qemu-path / --systemd ppc --credential yes \
>> --persistent no --preserve-argv0 no
>> # systemctl restart systemd-binfmt.service
>> # cat /proc/sys/fs/binfmt_misc/qemu-ppc
>> enabled
>> interpreter //qemu-ppc
>> flags: OC
>> offset 0
>> magic 7f454c4601020100000000000000000000020014
>> mask ffffffffffffff00fffffffffffffffffffeffff
>> # chroot /chroot/powerpc/jessie sh -c 'echo $0'
>> /bin/sh
>>
>> v3: mix my patch with one from YunQiang Su and my comments on it
>> introduce a new flag in the uabi for the AT_FLAGS
>> v2: only pass special flags (remove Magic and Enabled flags)
>>
>> fs/binfmt_elf.c | 5 ++++-
>> fs/binfmt_elf_fdpic.c | 5 ++++-
>> fs/binfmt_misc.c | 4 +++-
>> include/linux/binfmts.h | 4 ++++
>> include/uapi/linux/binfmts.h | 4 ++++
>> 5 files changed, 19 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
>> index ecd8d2698515..ff918042ceed 100644
>> --- a/fs/binfmt_elf.c
>> +++ b/fs/binfmt_elf.c
>> @@ -176,6 +176,7 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
>> unsigned char k_rand_bytes[16];
>> int items;
>> elf_addr_t *elf_info;
>> + elf_addr_t flags = 0;
>> int ei_index = 0;
>> const struct cred *cred = current_cred();
>> struct vm_area_struct *vma;
>> @@ -250,7 +251,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
>> NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr));
>> NEW_AUX_ENT(AT_PHNUM, exec->e_phnum);
>> NEW_AUX_ENT(AT_BASE, interp_load_addr);
>> - NEW_AUX_ENT(AT_FLAGS, 0);
>> + if (bprm->interp_flags & BINPRM_FLAGS_PRESERVE_ARGV0)
>> + flags |= AT_FLAGS_PRESERVE_ARGV0;
>> + NEW_AUX_ENT(AT_FLAGS, flags);
>> NEW_AUX_ENT(AT_ENTRY, exec->e_entry);
>> NEW_AUX_ENT(AT_UID, from_kuid_munged(cred->user_ns, cred->uid));
>> NEW_AUX_ENT(AT_EUID, from_kuid_munged(cred->user_ns, cred->euid));
>> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
>> index 240f66663543..abb90d82aa58 100644
>> --- a/fs/binfmt_elf_fdpic.c
>> +++ b/fs/binfmt_elf_fdpic.c
>> @@ -507,6 +507,7 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
>> char __user *u_platform, *u_base_platform, *p;
>> int loop;
>> int nr; /* reset for each csp adjustment */
>> + unsigned long flags = 0;
>>
>> #ifdef CONFIG_MMU
>> /* In some cases (e.g. Hyper-Threading), we want to avoid L1 evictions
>> @@ -647,7 +648,9 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
>> NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr));
>> NEW_AUX_ENT(AT_PHNUM, exec_params->hdr.e_phnum);
>> NEW_AUX_ENT(AT_BASE, interp_params->elfhdr_addr);
>> - NEW_AUX_ENT(AT_FLAGS, 0);
>> + if (bprm->interp_flags & BINPRM_FLAGS_PRESERVE_ARGV0)
>> + flags |= AT_FLAGS_PRESERVE_ARGV0;
>> + NEW_AUX_ENT(AT_FLAGS, flags);
>> NEW_AUX_ENT(AT_ENTRY, exec_params->entry_addr);
>> NEW_AUX_ENT(AT_UID, (elf_addr_t) from_kuid_munged(cred->user_ns, cred->uid));
>> NEW_AUX_ENT(AT_EUID, (elf_addr_t) from_kuid_munged(cred->user_ns, cred->euid));
>> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
>> index cdb45829354d..b9acdd26a654 100644
>> --- a/fs/binfmt_misc.c
>> +++ b/fs/binfmt_misc.c
>> @@ -154,7 +154,9 @@ static int load_misc_binary(struct linux_binprm *bprm)
>> if (bprm->interp_flags & BINPRM_FLAGS_PATH_INACCESSIBLE)
>> goto ret;
>>
>> - if (!(fmt->flags & MISC_FMT_PRESERVE_ARGV0)) {
>> + if (fmt->flags & MISC_FMT_PRESERVE_ARGV0) {
>> + bprm->interp_flags |= BINPRM_FLAGS_PRESERVE_ARGV0;
>> + } else {
>> retval = remove_arg_zero(bprm);
>> if (retval)
>> goto ret;
>> diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
>> index b40fc633f3be..265b80d5fd6f 100644
>> --- a/include/linux/binfmts.h
>> +++ b/include/linux/binfmts.h
>> @@ -78,6 +78,10 @@ struct linux_binprm {
>> #define BINPRM_FLAGS_PATH_INACCESSIBLE_BIT 2
>> #define BINPRM_FLAGS_PATH_INACCESSIBLE (1 << BINPRM_FLAGS_PATH_INACCESSIBLE_BIT)
>>
>> +/* if preserve the argv0 for the interpreter */
>> +#define BINPRM_FLAGS_PRESERVE_ARGV0_BIT 3
>> +#define BINPRM_FLAGS_PRESERVE_ARGV0 (1 << BINPRM_FLAGS_PRESERVE_ARGV0_BIT)
>> +
>> /* Function parameter for binfmt->coredump */
>> struct coredump_params {
>> const kernel_siginfo_t *siginfo;
>> diff --git a/include/uapi/linux/binfmts.h b/include/uapi/linux/binfmts.h
>> index 689025d9c185..a70747416130 100644
>> --- a/include/uapi/linux/binfmts.h
>> +++ b/include/uapi/linux/binfmts.h
>> @@ -18,4 +18,8 @@ struct pt_regs;
>> /* sizeof(linux_binprm->buf) */
>> #define BINPRM_BUF_SIZE 256
>>
>> +/* if preserve the argv0 for the interpreter */
>> +#define AT_FLAGS_PRESERVE_ARGV0_BIT 0
>> +#define AT_FLAGS_PRESERVE_ARGV0 (1 << AT_FLAGS_PRESERVE_ARGV0_BIT)
>> +
>> #endif /* _UAPI_LINUX_BINFMTS_H */
>>
>
^ permalink raw reply
* [MODERATED] Re: [PATCH 1/2] more sampling fun 1
From: Borislav Petkov @ 2020-02-20 10:07 UTC (permalink / raw)
To: speck
On Thu, Feb 06, 2020 at 02:11:02PM -0800, speck for mark gross wrote:
> From: mark gross <mgross@linux.intel.com>
> Subject: [PATCH 1/2] Add capability to specify a range of steppings in the
>
> Intel has produced processors with the same CPUID family+model. Code
> may need to check the stepping when programming model specific behavior.
>
> Add an API to allow easy specification of stepping or range of steppings
> with a 16 bit bitmask.
>
> Update cpu_vuln_whitelist using this new API.
>
> I implemented this in the way I did to avoid modifying x86_cpu_id as
> that structure is an exported ABI and any change would impact user mode
> code using the structure.
>
> Signed-off-by: mark gross <mgross@linux.intel.com>
> Reviewed-by: tony luck <tony.luck@intel.com>
> ---
> arch/x86/include/asm/cpu_device_id.h | 12 ++++++++++++
> arch/x86/kernel/cpu/common.c | 28 ++++++++++++++--------------
> arch/x86/kernel/cpu/match.c | 26 ++++++++++++++++++++++++++
> 3 files changed, 52 insertions(+), 14 deletions(-)
Why isn't this sent to lkml like a normal patch?
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
--
^ permalink raw reply
* Re: [PATCH][master-next] webkitgtk: add PACKAGECONFIG gobject-introspection
From: Alexander Kanavin @ 2020-02-20 10:08 UTC (permalink / raw)
To: Andreas Müller; +Cc: OE-core
In-Reply-To: <20200220002849.9126-1-schnitzeltony@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]
You need to at the same time drop the introspection enablement logic from
EXTRA_OECMAKE I think?
This line:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb?h=master-next#n70
And for consistency, it would be good to do the same for gtk-doc.
Alex
${@bb.utils.contains('GI_DATA_ENABLED', 'True',
'-DENABLE_INTROSPECTION=ON', '-DENABLE_INTROSPECTION=OFF', d)} \
${@bb.utils.contains('GI_DATA_ENABLED', 'True',
'-DENABLE_INTROSPECTION=ON', '-DENABLE_INTROSPECTION=OFF', d)} \
On Thu, 20 Feb 2020 at 01:29, Andreas Müller <schnitzeltony@gmail.com>
wrote:
> Enable if 'gobject-introspection-data' is in DISTRO_FEATURES. This is what
> gobject-introspection.bbclass does automatically for projects build with
> autotools and meson.
>
> It was checked: there are webkitgtk and libdnf inheriting
> gobject-introspection
> and cmake. Since libdnf cannot configure gir, webkitgtk seems the only
> project
> requiring gir-auto-enabling. So handle at recipe / no common magic at
> gobject-introspection.bbclass required.
>
> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> ---
>
> This patch applies on top of master-next/Alex's patches sent
>
> meta/recipes-sato/webkit/webkitgtk_2.26.4.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> index 585723772e..d5085620d2 100644
> --- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> +++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> @@ -39,6 +39,7 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt
> libxt libidn libgcrypt \
> "
>
> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11',
> d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES',
> 'gobject-introspection-data', 'gobject-introspection', '' ,d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'webgl opengl', '' ,d)} \
> enchant \
> libsecret \
> @@ -46,6 +47,7 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES',
> 'wayland x11', d)} \
>
> PACKAGECONFIG[wayland] =
> "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe
> wpebackend-fdo wayland-native"
> PACKAGECONFIG[x11] =
> "-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/libx11"
> +PACKAGECONFIG[gobject-introspection] =
> "-DENABLE_INTROSPECTION=ON,-DENABLE_INTROSPECTION=OFF"
> PACKAGECONFIG[geoclue] =
> "-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
> PACKAGECONFIG[enchant] =
> "-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
> PACKAGECONFIG[gtk2] =
> "-DENABLE_PLUGIN_PROCESS_GTK2=ON,-DENABLE_PLUGIN_PROCESS_GTK2=OFF,gtk+"
> --
> 2.21.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 4872 bytes --]
^ permalink raw reply
* Re: [Xen-devel] [PATCH 2/3] tools/xentop: Remove dead code
From: Wei Liu @ 2020-02-20 0:56 UTC (permalink / raw)
To: Sander Eikelenboom; +Cc: xen-devel, Ian Jackson, Wei Liu
In-Reply-To: <20200220005123.wtas2zrii4zgf3rz@debian>
On Thu, Feb 20, 2020 at 12:51:23AM +0000, Wei Liu wrote:
> On Wed, Feb 19, 2020 at 09:31:31PM +0100, Sander Eikelenboom wrote:
> > Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
> > ---
>
> I will add the following commit message:
>
> The variable freealbe_mb was never really used. Delete it and the code
> associated with it.
Actually, use the following:
The freeable_mb variable was made to always be zero when purging tmem
from tools. We can in fact just delete it and the code associated with
it.
Fixes: c588c002cc1 ("tools: remove tmem code and commands")
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v4] iommu/vt-d: consider real PCI device when checking if mapping is needed
From: Daniel Drake @ 2020-02-20 10:06 UTC (permalink / raw)
To: baolu.lu; +Cc: bhelgaas, linux, iommu, dwmw2, jonathan.derrick
In-Reply-To: <CAD8Lp47Bhv_58-Z+a+JFS9rTZW58_rWvE8N+XVtX7mmB-Tj55A@mail.gmail.com>
> On Wed, Feb 19, 2020 at 11:40 AM Lu Baolu <baolu.lu@linux.intel.com> wrote:
> > With respect, this is problematical. The parent and all subdevices share
> > a single translation entry. The DMA mask should be consistent.
> >
> > Otherwise, for example, subdevice A has 64-bit DMA capability and uses
> > an identity domain for DMA translation. While subdevice B has 32-bit DMA
> > capability and is forced to switch to DMA domain. Subdevice A will be
> > impacted without any notification.
Looking closer, this problematic codepath may already be happening for VMD,
under intel_iommu_add_device(). Consider this function running for a VMD
subdevice, we hit:
domain = iommu_get_domain_for_dev(dev);
I can't quite grasp the code flow here, but domain->type now always seems
to return the domain type of the real DMA device, which seems like pretty
reasonable behaviour.
if (domain->type == IOMMU_DOMAIN_DMA) {
and as detailed in previous mails, the real VMD device seems to be in a DMA
domain by default, so we continue.
if (device_def_domain_type(dev) == IOMMU_DOMAIN_IDENTITY) {
Now we checked the default domain type of the subdevice. This seems rather
likely to return IDENTITY because that's effectively the default type...
ret = iommu_request_dm_for_dev(dev);
if (ret) {
dmar_remove_one_dev_info(dev);
dmar_domain->flags |= DOMAIN_FLAG_LOSE_CHILDREN;
domain_add_dev_info(si_domain, dev);
dev_info(dev,
"Device uses a private identity domain.\n");
}
}
and now we're doing the bad stuff that Lu pointed out: we only have one
mapping shared for all the subdevices, so if we end up changing it for one
subdevice, we're likely to be breaking another.
In this case iommu_request_dm_for_dev() returns -EBUSY without doing anything
and the following private identity code fortunately seems to have no
consequential effects - the real DMA device continues to operate in the DMA
domain, and all subdevice DMA requests go through the DMA mapping codepath.
That's probably why VMD appears to be working fine anyway, but this seems
fragile.
The following changes enforce that the real DMA device is in the DMA domain,
and avoid the intel_iommu_add_device() codepaths that would try to change
it to a different domain type. Let me know if I'm on the right lines...
---
drivers/iommu/intel-iommu.c | 16 ++++++++++++++++
drivers/pci/controller/intel-nvme-remap.c | 6 ++++++
2 files changed, 22 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 9644a5b3e0ae..8872b8d1780d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2911,6 +2911,9 @@ static int device_def_domain_type(struct device *dev)
if (dev_is_pci(dev)) {
struct pci_dev *pdev = to_pci_dev(dev);
+ if (pci_real_dma_dev(pdev) != pdev)
+ return IOMMU_DOMAIN_DMA;
+
if (device_is_rmrr_locked(dev))
return IOMMU_DOMAIN_DMA;
@@ -5580,6 +5583,7 @@ static bool intel_iommu_capable(enum iommu_cap cap)
static int intel_iommu_add_device(struct device *dev)
{
+ struct device *real_dev = dev;
struct dmar_domain *dmar_domain;
struct iommu_domain *domain;
struct intel_iommu *iommu;
@@ -5591,6 +5595,17 @@ static int intel_iommu_add_device(struct device *dev)
if (!iommu)
return -ENODEV;
+ if (dev_is_pci(dev))
+ real_dev = &pci_real_dma_dev(to_pci_dev(dev))->dev;
+
+ if (real_dev != dev) {
+ domain = iommu_get_domain_for_dev(real_dev);
+ if (domain->type != IOMMU_DOMAIN_DMA) {
+ dev_err(dev, "Real DMA device not in DMA domain; can't handle DMA\n");
+ return -ENODEV;
+ }
+ }
+
iommu_device_link(&iommu->iommu, dev);
if (translation_pre_enabled(iommu))
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related
* Re: [PATCH 2/2] MAINTAINERS: Set MIPS status to Odd Fixes
From: Zhou Yanjie @ 2020-02-20 10:06 UTC (permalink / raw)
To: Jiaxun Yang, Huacai Chen, open list:MIPS
Cc: Paul Burton, LKML, ysu, Paul Cercueil
In-Reply-To: <17061a9f690.e5cbd01f5685.8497926865164942268@flygoat.com>
Hi,
I think Huacai Chen and Paul Cercueil are also two potential candidates
for the maintainer.
Both of them have been active for many years and have contributed a lot
of code to MIPS.
Thanks and best regards!
On 2020年02月20日 16:14, Jiaxun Yang wrote:
>
> 于 2020年2月20日 GMT+08:00 下午2:44:03, Huacai Chen <chenhuacai@gmail.com> 写到:
>> Hi, all,
>>
>> I suggest Jiaxun Yang to be the new Linux/MIPS maintainer because of
>> the following reasons:
>>
>> 1. He is familiar with Linux kernel & MIPS architecture.
>> 2. He is active and has already contributed many patches.
>> 3. He is not an employee of any corporation, so people can expect him
>> to be neutral.
>> 4. He is young and has enough free time to follow the mainstream
>> development closely.
>> 5. His English is good and is willing to maintain a good level of
>> communication with other contributors.
>>
>> Jiaxun, what's your opinion?
> Resend as MIPS List rejected the previous mail.
>
> Thanks for your recommendation.
>
> It's my pleasure to take this duty if I'm eligible.
>
> I have experience in MIPS chips and have already involved in some review processes.
> i.e.loongson, Ingenic/MediaTek & etc.
>
> As what Huacai has said, I'm a pure contributor from community,
> which means I will able to be neutral to MIPS family members.
>
> [Also added Yunqiang Su to Cc list as he is the
> only current MIPS company employee I know.]
>
> Thanks.
>> Regards,
>> Huacai Chen
^ permalink raw reply
* [PATCH 3/8] powerpc/papr_scm: Fetch dimm performance stats from PHYP
From: Vaibhav Jain @ 2020-02-20 9:58 UTC (permalink / raw)
To: linuxppc-dev
Cc: Vaibhav Jain, Michael Ellerman, Oliver O'Halloran,
Alastair D'Silva, Aneesh Kumar K . V
In-Reply-To: <20200220095805.197229-1-vaibhav@linux.ibm.com>
Implement support for fetching dimm performance metrics via
H_SCM_PERFORMANCE_HEALTH hcall as documented in Ref[1]. The hcall
returns a structure as described in Ref[1] and defined as newly
introduced 'struct papr_scm_perf_stats'. The struct has a header
followed by key-value pairs of performance attributes. The 'key' part
is a 8-byte char array naming the attribute encoded as a __be64
integer. This makes the output buffer format for the hcall self
describing and can be easily interpreted.
This patch implements functionality to fetch these performance stats
and reporting them via a nvdimm sysfs attribute named
'papr_perf_stats'.
A new function drc_pmem_query_stats() is implemented that issues hcall
H_SCM_PERFORMANCE_HEALTH ,requesting PHYP to store performance stats
in pre-allocated 'struct papr_scm_perf_stats' buffer. During nvdimm
initialization in papr_scm_nvdimm_init() this function is called with
an empty buffer to know the max buffer size needed for issuing the
H_SCM_PERFORMANCE_HEALTH hcall. The buffer size retrieved is stored in
newly introduced 'struct papc_scm_priv.len_stat_buffer' for later
retrival.
[1]: commit 58b278f568f0 ("powerpc: Provide initial documentation for
PAPR hcalls")
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
arch/powerpc/platforms/pseries/papr_scm.c | 107 ++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index aaf2e4ab1f75..28143a681aa2 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -47,6 +47,9 @@ struct papr_scm_priv {
/* Health information for the dimm */
__be64 health_bitmap;
__be64 health_bitmap_valid;
+
+ /* length of the stat buffer as expected by phyp */
+ size_t len_stat_buffer;
};
static int drc_pmem_bind(struct papr_scm_priv *p)
@@ -152,6 +155,50 @@ static int drc_pmem_query_n_bind(struct papr_scm_priv *p)
return drc_pmem_bind(p);
}
+static int drc_pmem_query_stats(struct papr_scm_priv *p,
+ struct papr_scm_perf_stats *stats,
+ size_t size, uint64_t *out)
+{
+ unsigned long ret[PLPAR_HCALL_BUFSIZE];
+ int64_t rc;
+
+ /* In case of no out buffer ignore the size */
+ if (!stats)
+ size = 0;
+
+ /*
+ * Do the HCALL asking PHYP for info and if R4 was requested
+ * return its value in 'out' variable.
+ */
+ rc = plpar_hcall(H_SCM_PERFORMANCE_STATS, ret, p->drc_index,
+ __pa(stats), size);
+ if (out)
+ *out = be64_to_cpu(ret[0]);
+
+ switch (rc) {
+ case H_SUCCESS:
+ /* Handle the case where size of stat buffer was requested */
+ if (size != 0)
+ dev_dbg(&p->pdev->dev,
+ "Performance stats returned %d stats\n",
+ be32_to_cpu(stats->num_statistics));
+ else
+ dev_dbg(&p->pdev->dev,
+ "Performance stats size %lld\n",
+ be64_to_cpu(ret[0]));
+ return 0;
+ case H_PARTIAL:
+ dev_err(&p->pdev->dev,
+ "Unknown performance stats, Err:0x%016llX\n",
+ be64_to_cpu(ret[0]));
+ return -ENOENT;
+ default:
+ dev_err(&p->pdev->dev,
+ "Failed to query performance stats, Err:%lld\n", rc);
+ return -ENXIO;
+ }
+}
+
static int drc_pmem_query_health(struct papr_scm_priv *p)
{
unsigned long ret[PLPAR_HCALL_BUFSIZE];
@@ -341,6 +388,53 @@ static inline int papr_scm_node(int node)
return min_node;
}
+static ssize_t papr_perf_stats_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct nvdimm *dimm = to_nvdimm(dev);
+ struct papr_scm_priv *p = nvdimm_provider_data(dimm);
+ struct papr_scm_perf_stats *retbuffer;
+ struct papr_scm_perf_stat *stat;
+ uint64_t statid, val;
+ int rc, i;
+
+ if (!p->len_stat_buffer)
+ return -ENOENT;
+
+ /* Return buffer for phyp where stats are written */
+ retbuffer = kzalloc(p->len_stat_buffer, GFP_KERNEL);
+ if (!retbuffer)
+ return -ENOMEM;
+
+ /* Setup the buffer */
+ memcpy(retbuffer->eye_catcher, PAPR_SCM_PERF_STATS_EYECATCHER,
+ sizeof(retbuffer->eye_catcher));
+ retbuffer->stats_version = cpu_to_be32(0x1);
+ retbuffer->num_statistics = 0;
+
+ rc = drc_pmem_query_stats(p, retbuffer, p->len_stat_buffer, NULL);
+ if (rc)
+ goto out;
+
+ /*
+ * Go through the returned output buffer and print stats and values.
+ * Since statistic_id is essentially a char string of 8 bytes encoded
+ * as a __be64, simply use the string format specifier to print it.
+ */
+ for (i = 0, stat = retbuffer->scm_statistics;
+ i < be32_to_cpu(retbuffer->num_statistics); ++i, ++stat) {
+ statid = be64_to_cpu(stat->statistic_id);
+ val = be64_to_cpu(stat->statistic_value);
+ rc += sprintf(buf + rc, "%.8s => 0x%016llX\n",
+ (char *) &(statid), val);
+ }
+out:
+ kfree(retbuffer);
+ return rc;
+
+}
+DEVICE_ATTR_RO(papr_perf_stats);
+
static ssize_t papr_flags_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -390,6 +484,7 @@ DEVICE_ATTR_RO(papr_flags);
/* papr_scm specific dimm attributes */
static struct attribute *papr_scm_nd_attributes[] = {
&dev_attr_papr_flags.attr,
+ &dev_attr_papr_perf_stats.attr,
NULL,
};
@@ -409,6 +504,7 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
struct nd_region_desc ndr_desc;
unsigned long dimm_flags;
int target_nid, online_nid;
+ uint64_t stat_size;
p->bus_desc.ndctl = papr_scm_ndctl;
p->bus_desc.module = THIS_MODULE;
@@ -470,6 +566,17 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
dev_info(dev, "Region registered with target node %d and online node %d",
target_nid, online_nid);
+ /* Try retriving the stat buffer and see if its supported */
+ if (!drc_pmem_query_stats(p, NULL, 0, &stat_size)) {
+ p->len_stat_buffer = (size_t)stat_size;
+ dev_dbg(&p->pdev->dev, "Max dimm perf stats size %ld bytes\n",
+ p->len_stat_buffer);
+ } else {
+ p->len_stat_buffer = 0;
+ dev_dbg(&p->pdev->dev, "Unable to retrieve performace stats\n");
+ dev_info(&p->pdev->dev, "Limited dimm info available\n");
+ }
+
return 0;
err: nvdimm_bus_unregister(p->bus);
--
2.24.1
^ permalink raw reply related
* [PULL] drm-misc-fixes
From: Maarten Lankhorst @ 2020-02-20 10:06 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter
Cc: dim-tools, dri-devel, Rodrigo Vivi, Sean Paul, intel-gfx
I see I missed some commits in the actual tag, but I fixed this below.
drm-misc-fixes-2020-02-20:
drm-misc-fixes for v5.6-rc3:
- Fix dt binding for sunxi.
- Allow only 1 rotation argument, and allow 0 rotation in video cmdline.
- Small compiler warning fix for panfrost.
- Fix when using performance counters in panfrost when using per fd address space.
- Fix tc358767 poll timeouts.
- Fix ti-tfp410 error message.
The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:
Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-02-20
for you to fetch changes up to dde2bb2da01e96c17f0a44b4a3cf72a30e66e3ef:
drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context (2020-02-12 14:27:29 -0600)
----------------------------------------------------------------
drm-misc-fixes for v5.6-rc3:
- Fix dt binding for sunxi.
- Allow only 1 rotation argument, and allow 0 rotation in video cmdline.
- Small compiler warning fix for panfrost.
- Fix when using performance counters in panfrost when using per fd address space.
----------------------------------------------------------------
Boris Brezillon (1):
drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context
Geert Uytterhoeven (1):
drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error message
Maarten Lankhorst (1):
Merge v5.6-rc1 into drm-misc-fixes
Maxime Ripard (1):
dt-bindings: display: sunxi: Fix compatible
Stephan Gerhold (2):
drm/modes: Make sure to parse valid rotation value from cmdline
drm/modes: Allow DRM_MODE_ROTATE_0 when applying video mode parameters
Tomi Valkeinen (1):
drm/bridge: tc358767: fix poll timeouts
YueHaibing (1):
drm/panfrost: Remove set but not used variable 'bo'
.../bindings/display/allwinner,sun4i-a10-tcon.yaml | 6 +++++-
drivers/gpu/drm/bridge/tc358767.c | 8 ++++----
drivers/gpu/drm/bridge/ti-tfp410.c | 3 ++-
drivers/gpu/drm/drm_client_modeset.c | 3 ++-
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
drivers/gpu/drm/drm_modes.c | 7 +++++++
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
drivers/gpu/drm/panfrost/panfrost_gem.h | 6 ++++++
drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 3 +++
drivers/gpu/drm/panfrost/panfrost_job.c | 13 +++++++------
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 ++++++-
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 11 ++++-------
drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_cmdline_parser.c | 15 +++++++++++++--
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 -
15 files changed, 63 insertions(+), 25 deletions(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Intel-gfx] [PULL] drm-misc-fixes
From: Maarten Lankhorst @ 2020-02-20 10:06 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter; +Cc: dim-tools, dri-devel, Maxime Ripard, intel-gfx
I see I missed some commits in the actual tag, but I fixed this below.
drm-misc-fixes-2020-02-20:
drm-misc-fixes for v5.6-rc3:
- Fix dt binding for sunxi.
- Allow only 1 rotation argument, and allow 0 rotation in video cmdline.
- Small compiler warning fix for panfrost.
- Fix when using performance counters in panfrost when using per fd address space.
- Fix tc358767 poll timeouts.
- Fix ti-tfp410 error message.
The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:
Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-02-20
for you to fetch changes up to dde2bb2da01e96c17f0a44b4a3cf72a30e66e3ef:
drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context (2020-02-12 14:27:29 -0600)
----------------------------------------------------------------
drm-misc-fixes for v5.6-rc3:
- Fix dt binding for sunxi.
- Allow only 1 rotation argument, and allow 0 rotation in video cmdline.
- Small compiler warning fix for panfrost.
- Fix when using performance counters in panfrost when using per fd address space.
----------------------------------------------------------------
Boris Brezillon (1):
drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context
Geert Uytterhoeven (1):
drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error message
Maarten Lankhorst (1):
Merge v5.6-rc1 into drm-misc-fixes
Maxime Ripard (1):
dt-bindings: display: sunxi: Fix compatible
Stephan Gerhold (2):
drm/modes: Make sure to parse valid rotation value from cmdline
drm/modes: Allow DRM_MODE_ROTATE_0 when applying video mode parameters
Tomi Valkeinen (1):
drm/bridge: tc358767: fix poll timeouts
YueHaibing (1):
drm/panfrost: Remove set but not used variable 'bo'
.../bindings/display/allwinner,sun4i-a10-tcon.yaml | 6 +++++-
drivers/gpu/drm/bridge/tc358767.c | 8 ++++----
drivers/gpu/drm/bridge/ti-tfp410.c | 3 ++-
drivers/gpu/drm/drm_client_modeset.c | 3 ++-
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
drivers/gpu/drm/drm_modes.c | 7 +++++++
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
drivers/gpu/drm/panfrost/panfrost_gem.h | 6 ++++++
drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 3 +++
drivers/gpu/drm/panfrost/panfrost_job.c | 13 +++++++------
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 ++++++-
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 11 ++++-------
drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_cmdline_parser.c | 15 +++++++++++++--
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 -
15 files changed, 63 insertions(+), 25 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [Ocfs2-devel] [QUESTION] An NULL pointer dereference problem which was caused when dereference journal head
From: Jan Kara @ 2020-02-20 10:06 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <94931222-b185-2a8c-2819-7d3d47b369a9@huawei.com>
On Thu 20-02-20 16:48:56, wangyan wrote:
> Hi all,
>
> I met an null pointer dereference problem, the running environment:
> kernel version: 4.19
> A cluster with two nodes, 5 luns mounted on two nodes, and do some
> file operations like dd/fallocate/truncate/rm on every lun with storage
> network disconnection.
>
> The fallocate operation on dm-23-45 caused an null pointer dereference.
>
> The information of NULL pointer dereference as follows:
> [577992.878282] JBD2: Error -5 detected when updating journal superblock for dm-23-45.
> [577992.878290] Aborting journal on device dm-23-45.
> ...
> [577992.890778] JBD2: Error -5 detected when updating journal superblock for dm-24-46.
> [577992.890908] __journal_remove_journal_head: freeing b_committed_data
> [577992.890916] (fallocate,88392,52):ocfs2_extend_trans:474 ERROR: status = -30
> [577992.890918] __journal_remove_journal_head: freeing b_committed_data
> [577992.890920] (fallocate,88392,52):ocfs2_rotate_tree_right:2500 ERROR: status = -30
> [577992.890922] __journal_remove_journal_head: freeing b_committed_data
> [577992.890924] (fallocate,88392,52):ocfs2_do_insert_extent:4382 ERROR: status = -30
> [577992.890928] (fallocate,88392,52):ocfs2_insert_extent:4842 ERROR: status = -30
> [577992.890928] __journal_remove_journal_head: freeing b_committed_data
> [577992.890930] (fallocate,88392,52):ocfs2_add_clusters_in_btree:4947 ERROR: status = -30
> [577992.890933] __journal_remove_journal_head: freeing b_committed_data
> [577992.890939] __journal_remove_journal_head: freeing b_committed_data
> [577992.890949] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
> [577992.890950] Mem abort info:
> [577992.890951] ESR = 0x96000004
> [577992.890952] Exception class = DABT (current EL), IL = 32 bits
> [577992.890952] SET = 0, FnV = 0
> [577992.890953] EA = 0, S1PTW = 0
> [577992.890954] Data abort info:
> [577992.890955] ISV = 0, ISS = 0x00000004
> [577992.890956] CM = 0, WnR = 0
> [577992.890958] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f8da07a9
> [577992.890960] [0000000000000020] pgd=0000000000000000
> [577992.890964] Internal error: Oops: 96000004 [#1] SMP
> [577992.890965] Process fallocate (pid: 88392, stack limit = 0x00000000013db2fd)
> [577992.890968] CPU: 52 PID: 88392 Comm: fallocate Kdump: loaded Tainted: G W OE 4.19.36 #1
> [577992.890969] Hardware name: Huawei TaiShan 2280 V2/BC82AMDD, BIOS 0.98 08/25/2019
> [577992.890971] pstate: 60400009 (nZCv daif +PAN -UAO)
> [577992.891054] pc : _ocfs2_free_suballoc_bits+0x63c/0x968 [ocfs2]
> [577992.891082] lr : _ocfs2_free_suballoc_bits+0x618/0x968 [ocfs2]
> [577992.891084] sp : ffff0000c8e2b810
> [577992.891085] x29: ffff0000c8e2b820 x28: 0000000000000000
> [577992.891087] x27: 00000000000006f3 x26: ffffa07957b02e70
> [577992.891089] x25: ffff807c59d50000 x24: 00000000000006f2
> [577992.891091] x23: 0000000000000001 x22: ffff807bd39abc30
> [577992.891093] x21: ffff0000811d9000 x20: ffffa07535d6a000
> [577992.891097] x19: ffff000001681638 x18: ffffffffffffffff
> [577992.891098] x17: 0000000000000000 x16: ffff000080a03df0
> [577992.891100] x15: ffff0000811d9708 x14: 203d207375746174
> [577992.891101] x13: 73203a524f525245 x12: 20373439343a6565
> [577992.891103] x11: 0000000000000038 x10: 0101010101010101
> [577992.891106] x9 : ffffa07c68a85d70 x8 : 7f7f7f7f7f7f7f7f
> [577992.891109] x7 : 0000000000000000 x6 : 0000000000000080
> [577992.891110] x5 : 0000000000000000 x4 : 0000000000000002
> [577992.891112] x3 : ffff000001713390 x2 : 2ff90f88b1c22f00
> [577992.891114] x1 : ffff807bd39abc30 x0 : 0000000000000000
> [577992.891116] Call trace:
> [577992.891139] _ocfs2_free_suballoc_bits+0x63c/0x968 [ocfs2]
> [577992.891162] _ocfs2_free_clusters+0x100/0x290 [ocfs2]
> [577992.891185] ocfs2_free_clusters+0x50/0x68 [ocfs2]
> [577992.891206] ocfs2_add_clusters_in_btree+0x198/0x5e0 [ocfs2]
> [577992.891227] ocfs2_add_inode_data+0x94/0xc8 [ocfs2]
> [577992.891248] ocfs2_extend_allocation+0x1bc/0x7a8 [ocfs2]
> [577992.891269] ocfs2_allocate_extents+0x14c/0x338 [ocfs2]
> [577992.891290] __ocfs2_change_file_space+0x3f8/0x610 [ocfs2]
> [577992.891309] ocfs2_fallocate+0xe4/0x128 [ocfs2]
> [577992.891316] vfs_fallocate+0x11c/0x250
> [577992.891317] ksys_fallocate+0x54/0x88
> [577992.891319] __arm64_sys_fallocate+0x28/0x38
> [577992.891323] el0_svc_common+0x78/0x130
> [577992.891325] el0_svc_handler+0x38/0x78
> [577992.891327] el0_svc+0x8/0xc
>
> My analysis process as follows:
> ocfs2_fallocate
> __ocfs2_change_file_space
> ocfs2_allocate_extents
> ocfs2_extend_allocation
> ocfs2_add_inode_data
> ocfs2_add_clusters_in_btree
> ocfs2_insert_extent
> ocfs2_do_insert_extent
> ocfs2_rotate_tree_right
> ocfs2_extend_rotate_transaction
> ocfs2_extend_trans
> jbd2_journal_restart
> jbd2__journal_restart
> /* handle->h_transaction is NULL,
> * is_handle_aborted(handle) is true
> */
> handle->h_transaction = NULL;
> start_this_handle
> return -EROFS;
> ocfs2_free_clusters
> _ocfs2_free_clusters
> _ocfs2_free_suballoc_bits
> ocfs2_block_group_clear_bits
> ocfs2_journal_access_gd
> __ocfs2_journal_access
> jbd2_journal_get_undo_access
> /* I think jbd2_write_access_granted() will
> * return true, because do_get_write_access()
> * will return -EROFS.
> */
> if (jbd2_write_access_granted(...)) return 0;
> do_get_write_access
> /* handle->h_transaction is NULL, it will
> * return -EROFS here, so do_get_write_access()
> * was not called.
> */
> if (is_handle_aborted(handle)) return -EROFS;
> /* bh2jh(group_bh) is NULL, caused NULL
> pointer dereference */
> undo_bg = (struct ocfs2_group_desc *)
> bh2jh(group_bh)->b_committed_data;
>
> I found the log "__journal_remove_journal_head: freeing b_committed_data"
> before causing NULL pointer dereference which will be printed when remove
> journal head.
>
> So, I think bh2jh(group_bh) is removed after ocfs2_journal_access_gd() and
> before call "bh2jh(group_bh)->b_committed_data", I don't know if this
> condition will happen and if the analysis result is right?
Thanks for the analysis! Yes, what you write seems to be possible because
if handle->h_transaction == NULL, then jbd2_write_access_granted() does not
really guarantee that journal_head will stay around, not even speaking of
its b_committed_data.
I think a proper fix is to move is_handle_aborted() check from
do_get_write_access() into jbd2_journal_get_undo_access() and
jbd2_journal_get_write_access() before the call to
jbd2_write_access_granted().
Will you send a patch to fix this or should I do it?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [Xen-devel] [PATCH 1/3] tools/xentop: Fix calculation of used memory.
From: Wei Liu @ 2020-02-20 0:54 UTC (permalink / raw)
To: Sander Eikelenboom; +Cc: xen-devel, Ian Jackson, Wei Liu
In-Reply-To: <20200220004816.qydrhtyedkko4rc7@debian>
On Thu, Feb 20, 2020 at 12:48:16AM +0000, Wei Liu wrote:
> The code looks correct to me, but I would like to add the following
> commit message to this change.
>
> Used memory should be calculated by subtracting free memory from total
> memory.
Fixes: c588c002cc1 ("tools: remove tmem code and commands")
>
>
> On Wed, Feb 19, 2020 at 09:31:30PM +0100, Sander Eikelenboom wrote:
> > Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
> > ---
> > tools/xenstat/xentop/xentop.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c
> > index af11ebfbf7..13b612f26d 100644
> > --- a/tools/xenstat/xentop/xentop.c
> > +++ b/tools/xenstat/xentop/xentop.c
> > @@ -969,7 +969,7 @@ void do_summary(void)
> > "%u crashed, %u dying, %u shutdown \n",
> > num_domains, run, block, pause, crash, dying, shutdown);
> >
> > - used = xenstat_node_tot_mem(cur_node);
> > + used = xenstat_node_tot_mem(cur_node)-xenstat_node_free_mem(cur_node);
>
> Also, I will add spaces around "-".
>
> Acked-by: Wei Liu <wl@xen.org>
>
> > freeable_mb = 0;
> >
> > /* Dump node memory and cpu information */
> > --
> > 2.20.1
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2 2/8] blk-mq: Keep set->nr_hw_queues and set->map[].nr_queues in sync
From: Ming Lei @ 2020-02-20 10:05 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jens Axboe, linux-block, Christoph Hellwig, Christoph Hellwig,
Hannes Reinecke, Johannes Thumshirn, syzbot+d44e1b26ce5c3e77458d
In-Reply-To: <20200220024441.11558-3-bvanassche@acm.org>
On Wed, Feb 19, 2020 at 06:44:35PM -0800, Bart Van Assche wrote:
> blk_mq_map_queues() and multiple .map_queues() implementations expect that
> set->map[HCTX_TYPE_DEFAULT].nr_queues is set to the number of hardware
Only single queue mapping expects set->map[HCTX_TYPE_DEFAULT].nr_queues
to be set->nr_hw_queues. For multiple mapping, set->nr_hw_queues should
be sum of each mapping's nr_queue.
Thanks,
Ming
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.