* Re: [PATCH 2/6] module: add support for symbol namespaces.
From: Martijn Coenen @ 2018-07-24 7:44 UTC (permalink / raw)
To: Jessica Yu
Cc: LKML, Masahiro Yamada, Michal Marek, Geert Uytterhoeven,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
the arch/x86 maintainers, Alan Stern, Greg Kroah-Hartman,
Oliver Neukum, Arnd Bergmann, Stephen Boyd, Philippe Ombredanne,
Kate Stewart, Sam Ravnborg, linux-kbuild, linux-m68k, USB list,
USB Storage list, linux-scsi, Linux-Arch, Martijn Coenen,
Sandeep Patil, Iliyan Malchev, Joel Fernandes
In-Reply-To: <20180723111251.x2cam6bcuglr4hhz@linux-8ccs>
On Mon, Jul 23, 2018 at 1:12 PM, Jessica Yu <jeyu@kernel.org> wrote:
> IMO I don't think we should bend over backwards to accommodate
> out-of-tree modules - modifying the module loader to recognize even
> more special sections to accommodate these OOT modules would be where
> we'd draw the line I think.
I agree with you, I really don't like making the module loader more
complex (which is why I didn't opt to create separate sections in the
first place), and in the end this change will in some ways benefit
out-of-tree drivers too, even though it will be a bit painful now.
> I think going forward I would prefer to have export namespaces to be a
> normal and regular part of kernel API (as in, we shouldn't require a
> new option for it), and that the warnings for 1-2 cycles are courteous
> enough - but anyone with stronger opinions about this should speak up.
That aligns with how I think about this; if we want this to be a
standard thing in the kernel, we should at some point enforce it,
because it's pretty easy to ignore the warning. The good thing is that
it's not a big on/off switch, but subsystem maintainers can just
introduce namespaces when it makes sense.
Thanks,
Martijn
>
> Thanks,
>
> Jessica
^ permalink raw reply
* Re: [PATCH] drm/i915: Pull unpin map into vma release
From: Michał Winiarski @ 2018-07-24 8:48 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20180721125037.20127-1-chris@chris-wilson.co.uk>
On Sat, Jul 21, 2018 at 01:50:37PM +0100, Chris Wilson wrote:
> A reasonably common operation is to pin the map of the vma alongside the
> vma itself for the lifetime of the vma, and so release both pin at the
> same time as destroying the vma. It is common enough to pull into the
> release function, making that central function more attractive to a
> couple of other callsites.
>
> The continual ulterior motive is to sweep over errors on module load
> aborting...
>
> Testcase: igt/drv_module_reload/basic-reload-inject
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
-Michał
> ---
> drivers/gpu/drm/i915/i915_perf.c | 10 ++++------
> drivers/gpu/drm/i915/i915_vma.c | 5 ++++-
> drivers/gpu/drm/i915/i915_vma.h | 3 ++-
> drivers/gpu/drm/i915/intel_engine_cs.c | 18 +++---------------
> drivers/gpu/drm/i915/intel_guc.c | 5 ++---
> drivers/gpu/drm/i915/intel_guc_ads.c | 2 +-
> drivers/gpu/drm/i915/intel_guc_ct.c | 7 ++-----
> drivers/gpu/drm/i915/intel_guc_log.c | 2 +-
> drivers/gpu/drm/i915/intel_guc_submission.c | 10 ++++------
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> 10 files changed, 24 insertions(+), 40 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/2] examples/ipsec-secgw: fix portmask option parsing
From: De Lara Guarch, Pablo @ 2018-07-24 8:48 UTC (permalink / raw)
To: Akhil Goyal, Ananyev, Konstantin, dev@dpdk.org; +Cc: Nicolau, Radu
In-Reply-To: <f82a1e15-559e-d0f0-b6e8-cc327d49e46e@nxp.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Akhil Goyal
> Sent: Thursday, July 5, 2018 10:03 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org
> Cc: Nicolau, Radu <radu.nicolau@intel.com>
> Subject: Re: [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: fix portmask option
> parsing
>
> Hi Konstantin,
>
> On 6/22/2018 5:21 PM, Ananyev, Konstantin wrote:
>
> >
> >> -----Original Message-----
> >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> >> Sent: Friday, June 22, 2018 11:41 AM
> >> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org
> >> Cc: Nicolau, Radu <radu.nicolau@intel.com>
> >> Subject: Re: [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: fix
> >> portmask option parsing
> >>
> >>
> >>
> >> On 6/22/2018 3:40 PM, Ananyev, Konstantin wrote:
> >>>> -----Original Message-----
> >>>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> >>>> Sent: Friday, June 22, 2018 11:01 AM
> >>>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> >>>> dev@dpdk.org
> >>>> Cc: Nicolau, Radu <radu.nicolau@intel.com>
> >>>> Subject: Re: [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: fix
> >>>> portmask option parsing
> >>>>
> >>>> Hi Konstantin,
> >>>>
> >>>> On 6/21/2018 8:32 PM, Ananyev, Konstantin wrote:
> >>>>
> >>>>> Hi Akhil,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> >>>>>> Sent: Thursday, June 21, 2018 2:49 PM
> >>>>>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> >>>>>> dev@dpdk.org
> >>>>>> Cc: Nicolau, Radu <radu.nicolau@intel.com>
> >>>>>> Subject: Re: [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: fix
> >>>>>> portmask option parsing
> >>>>>>
> >>>>>> Hi Konstantin,
> >>>>>>
> >>>>>> On 6/5/2018 7:46 PM, Konstantin Ananyev wrote:
> >>>>>>> parse_portmask() returns both portmask value and possible error
> >>>>>>> code as 32-bit integer. That causes some confusion for callers.
> >>>>>>> Split error code and portmask value into two distinct variables.
> >>>>>>> Also allows to run the app with unprotected_port_mask == 0.
> >>>>>> This would also allow cryptodev_mask == 0 to work well which should
> not be the case.
> >>>>>>
> >>>>>>> Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample
> >>>>>>> application")
> >>>>>>>
> >>>>>>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >>>>>>> ---
> >>>>>>> examples/ipsec-secgw/ipsec-secgw.c | 29 +++++++++++++++---------
> -----
> >>>>>>> 1 file changed, 15 insertions(+), 14 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> >>>>>>> b/examples/ipsec-secgw/ipsec-secgw.c
> >>>>>>> index fafb41161..5d7071657 100644
> >>>>>>> --- a/examples/ipsec-secgw/ipsec-secgw.c
> >>>>>>> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> >>>>>>> @@ -972,20 +972,19 @@ print_usage(const char *prgname)
> >>>>>>> }
> >>>>>>>
> >>>>>>> static int32_t
> >>>>>>> -parse_portmask(const char *portmask)
> >>>>>>> +parse_portmask(const char *portmask, uint32_t *pmv)
> >>>>>>> {
> >>>>>>> - char *end = NULL;
> >>>>>>> + char *end;
> >>>>>>> unsigned long pm;
> >>>>>>>
> >>>>>>> /* parse hexadecimal string */
> >>>>>>> + errno = 0;
> >>>>>>> pm = strtoul(portmask, &end, 16);
> >>>>>>> - if ((portmask[0] == '\0') || (end == NULL) || (*end != '\0'))
> >>>>>>> + if (errno != 0 || *end != '\0' || pm > UINT32_MAX)
> >>>>>>> return -1;
> >>>>>>>
> >>>>>>> - if ((pm == 0) && errno)
> >>>>>>> - return -1;
> >>>>>>> -
> >>>>>>> - return pm;
> >>>>>>> + *pmv = pm;
> >>>>>>> + return 0;
> >>>>>>> }
> >>>>>>>
> >>>>>>> static int32_t
> >>>>>>> @@ -1063,6 +1062,7 @@ parse_args(int32_t argc, char **argv)
> >>>>>>> int32_t opt, ret;
> >>>>>>> char **argvopt;
> >>>>>>> int32_t option_index;
> >>>>>>> + uint32_t v;
> >>>>>>> char *prgname = argv[0];
> >>>>>>> int32_t f_present = 0;
> >>>>>>>
> >>>>>>> @@ -1073,8 +1073,8 @@ parse_args(int32_t argc, char **argv)
> >>>>>>>
> >>>>>>> switch (opt) {
> >>>>>>> case 'p':
> >>>>>>> - enabled_port_mask = parse_portmask(optarg);
> >>>>>>> - if (enabled_port_mask == 0) {
> >>>>>>> + ret = parse_portmask(optarg,
> &enabled_port_mask);
> >>>>>>> + if (ret < 0 || enabled_port_mask == 0) {
> >>>>>>> printf("invalid portmask\n");
> >>>>>>> print_usage(prgname);
> >>>>>>> return -1;
> >>>>>>> @@ -1085,8 +1085,8 @@ parse_args(int32_t argc, char **argv)
> >>>>>>> promiscuous_on = 1;
> >>>>>>> break;
> >>>>>>> case 'u':
> >>>>>>> - unprotected_port_mask =
> parse_portmask(optarg);
> >>>>>>> - if (unprotected_port_mask == 0) {
> >>>>>>> + ret = parse_portmask(optarg,
> &unprotected_port_mask);
> >>>>>>> + if (ret < 0) {
> >>>>>>> printf("invalid unprotected
> portmask\n");
> >>>>>>> print_usage(prgname);
> >>>>>>> return -1;
> >>>>>>> @@ -1147,15 +1147,16 @@ parse_args(int32_t argc, char **argv)
> >>>>>>> single_sa_idx);
> >>>>>>> break;
> >>>>>>> case CMD_LINE_OPT_CRYPTODEV_MASK_NUM:
> >>>>>>> - ret = parse_portmask(optarg);
> >>>>>>> + ret = parse_portmask(optarg, &v);
> >>>>>> I think there is no need for v, enabled_cryptodev_mask can be used
> instead.
> >>>>> Right now - it can't as enabled_cryptodevmask is uint64_t.
> >>>>> To do what you suggesting we have either downgrade
> >>>>> enabled_cryptodevmask 32-bits, or upgrade enabled_port_mask to 64-bit
> and change parse_portmask() to accept 64-bit parameter.
> >>>> I am ok with any of the case.
> >>>>
> >>>>>>> if (ret == -1) {
> >>>>>> enabled_cryptodev_mask should not be 0 and should be checked here.
> >>>>> Could you explain a bit more why enabled_cryptodevmask==0 is not
> allowed?
> >>>> By default, the value of enabled_cryptodevmask is UINT64_MAX, which
> >>>> means all crypto devices are enabled, and if it is marked as 0,
> >>>> then all get disabled which is not correct as we need atleast 1 crypto
> device in ipsec application.
> >>> Might be user would like to run app with inline ipsec only, or have
> >>> app to work in bypass mode only (no encrypt/decrypt) at all.
> >>> Why that should be considered as a problem?
> >>> Konstantin
> >> Agreed with your point. But in case of inline ipsec, user may not be initializing
> the crypto device either.
> >>
> >> So the cryptodev_mask option would be redundant in that case and it may
> not give that parameter.
> > It is still not clear to me why you'd like to prohibit cryptodev_mask==0?
> > Would anything will be broken?
> > Konstantin
>
> Sorry for delayed response. I missed this one somehow.
>
> Nothing is broken, but it looks very redundant in case of inline modes, and it is
> not a valid value in case of other modes.
Any further comments?
Thanks,
Pablo
>
> >
> >> -Akhil
> >>
> >>>> So if the user doesn't
> >>>> want to give the cryptodev_mask then he may skip that parameter,
> >>>> but if it is giving, then it cannot be 0.
> >>>>
> >>>>> Konstantin
> >>>>>
> >>>>>
> >>>> -Akhil
> >
^ permalink raw reply
* [Qemu-devel] [PATCH 2/2] iotests: Don't lock /dev/null in 226
From: Fam Zheng @ 2018-07-24 8:47 UTC (permalink / raw)
To: qemu-devel; +Cc: jsnow, Kevin Wolf, Max Reitz, qemu-block, eblake
In-Reply-To: <20180724084739.580-1-famz@redhat.com>
On my system (Fedora 28), this script reports a 'failed to get
"consistent read" lock' error. Following docs/devel/testing.rst, it's
better to add locking=off here.
Signed-off-by: Fam Zheng <famz@redhat.com>
---
tests/qemu-iotests/226 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/226 b/tests/qemu-iotests/226
index 211ea9888a..8ec3e612dd 100755
--- a/tests/qemu-iotests/226
+++ b/tests/qemu-iotests/226
@@ -56,10 +56,10 @@ for PROTO in "file" "host_device" "host_cdrom"; do
echo
echo "== Testing RO =="
$QEMU_IO -c "open -r -o driver=$PROTO,filename=$TEST_IMG" 2>&1 | _filter_testdir | _filter_imgfmt
- $QEMU_IO -c "open -r -o driver=$PROTO,filename=/dev/null" 2>&1 | _filter_imgfmt
+ $QEMU_IO -c "open -r -o driver=$PROTO,filename=/dev/null,locking=off" 2>&1 | _filter_imgfmt
echo "== Testing RW =="
$QEMU_IO -c "open -o driver=$PROTO,filename=$TEST_IMG" 2>&1 | _filter_testdir | _filter_imgfmt
- $QEMU_IO -c "open -o driver=$PROTO,filename=/dev/null" 2>&1 | _filter_imgfmt
+ $QEMU_IO -c "open -o driver=$PROTO,filename=/dev/null,locking=off" 2>&1 | _filter_imgfmt
done
# success, all done
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 1/2] docs: Describe using images in writing iotests
From: Fam Zheng @ 2018-07-24 8:47 UTC (permalink / raw)
To: qemu-devel; +Cc: jsnow, Kevin Wolf, Max Reitz, qemu-block, eblake
In-Reply-To: <20180724084739.580-1-famz@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
---
docs/devel/testing.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 5e19cd50da..8e1fa3a66e 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -255,6 +255,17 @@ comparable library support for invoking and interacting with QEMU programs. If
you opt for Python, it is strongly recommended to write Python 3 compatible
code.
+Both Python and Bash frameworks in iotests provide helpers to manage test
+images. They can be used to create and clean up images under the test
+directory. If no I/O or any protocol specific feature is needed, it is often
+more convenient to use the pseudo block driver, ``null-co://``, as the test
+image, which doesn't require image creation or cleaning up. Avoid system-wide
+devices or files whenever possible, such as ``/dev/null`` or ``/dev/zero``.
+Otherwise, image locking implications have to be considered. For example,
+another application on the host may have locked the file, possibly leading to a
+test failure. If using such devices are explicitly desired, consider adding
+``locking=off`` option to disable image locking.
+
Docker based tests
==================
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 0/2] iotests: Fix 226 on _my_ system
From: Fam Zheng @ 2018-07-24 8:47 UTC (permalink / raw)
To: qemu-devel; +Cc: jsnow, Kevin Wolf, Max Reitz, qemu-block, eblake
Something has locked /dev/null on my system (I still don't know what to do with
the annoying incapability of lslocks, or more precisely /proc/locks, on
inspecting OFD lock information), and as a result 226 cannot pass due to the
unexpected image locking error.
Fix the test case by disabling locking, and add a doc text about using test
images.
Fam Zheng (2):
docs: Describe using images in writing iotests
iotests: Don't lock /dev/null in 226
docs/devel/testing.rst | 11 +++++++++++
tests/qemu-iotests/226 | 4 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH] net/p9/trans_fd.c: fix double list_del()
From: jiangyiwen @ 2018-07-24 8:46 UTC (permalink / raw)
To: Tomas Bortoli; +Cc: asmadeus, davem, v9fs-developer, linux-kernel, syzkaller
In-Reply-To: <20180723121902.20201-1-tomasbortoli@gmail.com>
On 2018/7/23 20:19, Tomas Bortoli wrote:
> A double list_del(&req->req_list) is possible in p9_fd_cancel() as
> shown by Syzbot. To prevent it we have to ensure that we have the
> client->lock when deleting the list. Furthermore, we have to update
> the status of the request before releasing the lock, to prevent the
> race.
>
> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
> Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
> ---
> net/9p/trans_fd.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> index a64b01c56e30..370c6c69a05c 100644
> --- a/net/9p/trans_fd.c
> +++ b/net/9p/trans_fd.c
> @@ -199,15 +199,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)
> static void p9_conn_cancel(struct p9_conn *m, int err)
> {
> struct p9_req_t *req, *rtmp;
> - unsigned long flags;
> LIST_HEAD(cancel_list);
>
> p9_debug(P9_DEBUG_ERROR, "mux %p err %d\n", m, err);
>
> - spin_lock_irqsave(&m->client->lock, flags);
> + spin_lock(&m->client->lock);
>
> if (m->err) {
> - spin_unlock_irqrestore(&m->client->lock, flags);
> + spin_unlock(&m->client->lock);
> return;
> }
>
> @@ -219,7 +218,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
> list_for_each_entry_safe(req, rtmp, &m->unsent_req_list, req_list) {
> list_move(&req->req_list, &cancel_list);
> }
> - spin_unlock_irqrestore(&m->client->lock, flags);
>
> list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
> p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
> @@ -228,6 +226,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
> req->t_err = err;
> p9_client_cb(m->client, req, REQ_STATUS_ERROR);
> }
> + spin_unlock(&m->client->lock);
If you want to expand the ranges of client->lock, the cancel_list will not
be necessary, you can optimize this code.
In addition, we delete some person because too many recipients are limited.
Thanks,
Yiwen.
> }
>
> static __poll_t
> @@ -370,12 +369,12 @@ static void p9_read_work(struct work_struct *work)
> if (m->req->status != REQ_STATUS_ERROR)
> status = REQ_STATUS_RCVD;
> list_del(&m->req->req_list);
> - spin_unlock(&m->client->lock);
> p9_client_cb(m->client, m->req, status);
> m->rc.sdata = NULL;
> m->rc.offset = 0;
> m->rc.capacity = 0;
> m->req = NULL;
> + spin_unlock(&m->client->lock);
> }
>
> end_clear:
>
^ permalink raw reply
* [U-Boot] [PATCH] sunxi: enable SATA on Banana Pi M2 Berry
From: Maxime Ripard @ 2018-07-24 8:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180723222219.20202-1-gmbnomis@gmail.com>
On Tue, Jul 24, 2018 at 12:22:19AM +0200, Simon Baatz wrote:
> Banana Pi M2 Ultra and M2 Berry are very similar boards. SATA can be
> enabled exactly the same as for M2 Ultra introduced in
> commit daa8b75a5527 ("sunxi: enable SATA on Banana Pi M2 Ultra").
>
> Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180724/735a8a15/attachment.sig>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] qstring: Fix integer overflow
From: Markus Armbruster @ 2018-07-24 8:46 UTC (permalink / raw)
To: Markus Armbruster
Cc: liujunjie (A), wangxin (U), Gonglei (Arei), Huangweidong (C),
qemu-devel@nongnu.org
In-Reply-To: <87r2jt40g1.fsf@dusky.pond.sub.org>
Markus Armbruster <armbru@redhat.com> writes:
> "liujunjie (A)" <liujunjie23@huawei.com> writes:
>
>> The stack backtrace is as follows:
>> (gdb) bt
>> #0 0x00007f1dc3c7b091 in _g_log_abort () from /usr/lib64/libglib-2.0.so.0
>> #1 0x00007f1dc3c7c0bd in g_log_default_handler () from /usr/lib64/libglib-2.0.so.0
>> #2 0x00007f1dc3c7c341 in g_logv () from /usr/lib64/libglib-2.0.so.0
>> #3 0x00007f1dc3c7c5cf in g_log () from /usr/lib64/libglib-2.0.so.0
>> #4 0x00007f1dc3c7ac4c in g_malloc () from /usr/lib64/libglib-2.0.so.0
>> #5 0x00000000008300b7 in qstring_from_substr (
>> str=0x7f13a2e67010 "00000000777b8000: 0000000003083000 ----A--U-\r\n00000000777b9000: 0000000005984000 ----A--U-\r\n00000000777ba000: 0000000005985000 ----A--U-\r\n00000000777bb000: 0000000003086000 ----A--U-\r\n00000000777bc000"..., start=start@entry=0, end=<optimized out>) at qobject/qstring.c:51
>> #6 0x0000000000830113 in qstring_from_str (str=<optimized out>) at qobject/qstring.c:66
>> #7 0x000000000082be98 in qobject_output_type_str (v=<optimized out>, name=0x89703b "unused", obj=0x7ffff0135f98, errp=<optimized out>)
>> at qapi/qobject_output_visitor.c:172
>> #8 0x0000000000829d2c in visit_type_str (v=v@entry=0x4d9d940, name=name@entry=0x89703b "unused", obj=obj@entry=0x7ffff0135f98, errp=errp@entry=0x7ffff0135fa8)
>> at qapi/qapi_visit_core.c:291
>> #9 0x0000000000576135 in qmp_marshal_output_str (
>> ret_in=0x7f13a2e67010 "00000000777b8000: 0000000003083000 ----A--U-\r\n00000000777b9000: 0000000005984000 ----A--U-\r\n00000000777ba000: 0000000005985000 ----A--U-\r\n00000000777bb000: 0000000003086000 ----A--U-\r\n00000000777bc000"..., ret_out=ret_out@entry=0x7ffff0136068, errp=errp@entry=0x7ffff0135fe8) at qmp-marshal.c:2022
>> #10 0x00000000005762cb in qmp_marshal_human_monitor_command (args=<optimized out>, ret=0x7ffff0136068, errp=0x7ffff0136060) at qmp-marshal.c:2059
>> #11 0x000000000082c897 in do_qmp_dispatch (request=request@entry=0x1fcda50, errp=errp@entry=0x7ffff01360b8) at qapi/qmp_dispatch.c:114
>> #12 0x000000000082caeb in qmp_dispatch (request=request@entry=0x1fcda50) at qapi/qmp_dispatch.c:141
>> #13 0x000000000045e0d2 in handle_qmp_command (parser=<optimized out>, tokens=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3907
> [...]
>
> The code is trying to marshall the return value of
> qmp_human_monitor_command(). It's @ret_in in qmp_marshal_output_str()
> (frame#9, abbreviated by GDB), and @str in qstring_from_substr()
> (frame#5). Also @str in qstring_from_str() (frame#6), but GDB can't see
> it there. Sadly, GDB can't see shows qstring_from_substr()'s @end,
> either. However, you previously examined qstring->length there:
>
>>> > (gdb) p/x qstring->length
>>> > $7 = 0xffffffffb0fd64bc
>>> > (gdb) p end
>>> > $8 = <optimized out>
>
> We know
>
> qstring->length = end - start + 1;
>
> If GDB shows the true value (always in doubt for optimized code), then
> @end must be qstring->length - 1, because @start is zero. But that's
> not plausible at all! It's almost 16 exabyte.
>
> I suspect GDB is lying to you. Please show us the complete string, like
> this:
>
> (gdb) set print elements unlimited
> (gdb) print str
Actually, I'm interested only in the true length of @str, and the print
is just a simple way to find it. No need to post the output of print if
it's inconveniently long.
^ permalink raw reply
* [U-Boot] [UBOOT PATCH] gpio: zynq: Used platdata structure for storing static data instead of priv
From: Michal Simek @ 2018-07-24 8:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ02o89Jj5ic1gtocgNnDPfFhYn9_qfRR6j-1+++Z1+QWQ@mail.gmail.com>
On 24.7.2018 01:48, Simon Glass wrote:
> On 20 July 2018 at 03:06, Vipul Kumar <vipul.kumar@xilinx.com> wrote:
>> This patch used platdata structure instead of priv for storing static
>> information read from DT.
>>
>> Signed-off-by: Vipul Kumar <vipul.kumar@xilinx.com>
>> ---
>> drivers/gpio/zynq_gpio.c | 67 ++++++++++++++++++++++++------------------------
>> 1 file changed, 34 insertions(+), 33 deletions(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
Applied.
M
^ permalink raw reply
* Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps
From: David Hildenbrand @ 2018-07-24 8:46 UTC (permalink / raw)
To: Michal Hocko
Cc: Vlastimil Babka, linux-mm, linux-kernel, Andrew Morton,
Baoquan He, Dave Young, Greg Kroah-Hartman, Hari Bathini,
Huang Ying, Kirill A. Shutemov, Marc-André Lureau,
Matthew Wilcox, Miles Chen, Pavel Tatashin, Petr Tesarik
In-Reply-To: <20180724072536.GB28386@dhcp22.suse.cz>
On 24.07.2018 09:25, Michal Hocko wrote:
> On Mon 23-07-18 19:20:43, David Hildenbrand wrote:
>> On 23.07.2018 14:30, Michal Hocko wrote:
>>> On Mon 23-07-18 13:45:18, Vlastimil Babka wrote:
>>>> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
>>>>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
>>>>> So reserved pages might be access by dump tools although nobody except
>>>>> the owner should touch them.
>>>>
>>>> Are you sure about that? Or maybe I understand wrong. Maybe it changed
>>>> recently, but IIRC pages that are backing memmap (struct pages) are also
>>>> PG_reserved. And you definitely do want those in the dump.
>>>
>>> You are right. reserve_bootmem_region will make all early bootmem
>>> allocations (including those backing memmaps) PageReserved. I have asked
>>> several times but I haven't seen a satisfactory answer yet. Why do we
>>> even care for kdump about those. If they are reserved the nobody should
>>> really look at those specific struct pages and manipulate them. Kdump
>>> tools are using a kernel interface to read the content. If the specific
>>> content is backed by a non-existing memory then they should simply not
>>> return anything.
>>>
>>
>> "new kernel" provides an interface to read memory from "old kernel".
>>
>> The new kernel has no idea about
>> - which memory was added/online in the old kernel
>> - where struct pages of the old kernel are and what their content is
>> - which memory is save to touch and which not
>>
>> Dump tools figure all that out by interpreting the VMCORE. They e.g.
>> identify "struct pages" and see if they should be dumped. The "new
>> kernel" only allows to read that memory. It cannot hinder to crash the
>> system (e.g. if a dump tool would try to read a hwpoison page).
>>
>> So how should the "new kernel" know if a page can be touched or not?
>
> I am sorry I am not familiar with kdump much. But from what I remember
> it reads from /proc/vmcore and implementation of this interface should
> simply return EINVAL or alike when you try to dump inaccessible memory
> range.
I assume the main problem with this approach is that we would always
have to fallback to reading old memory from vmcore page by page. e.g.
makedumpfile will always try to read bigger bunches. I also assume the
reason HWPOISON is handled in dump tools instead of in the kernel using
the mechanism you describe is the case.
One way to avoid this would be to silently "read zero". Although not
nice, it avoids having to touch dump tools.
E.g. fs/proc/vmcore.c:read_from_oldmem() has a hook called
"pfn_is_ram()". This is the hook for XEN I mentioned previously.
-> register_oldmem_pfn_is_ram()
However this callback right now assumes that there is a "global
hypervisor implemented way of checking whether a page is accessible". We
don't want anything like that in KVM.
I could imagine extending this register mechanism in a way that
- we can have multiple callbacks
- we can return something like "Yes" / "No" / "Don't know"
So we could have multiple devices (controlling a memory area) register
there and when called, they could see if they are responsible for that
area and query the hypervisor (e.g. using virtio).
Might be complicated but the last resort.
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH 5/5] dax/super: Do not request a pointer kaddr when not required
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: axboe, linux-s390, chengnt, linux-fsdevel, heiko.carstens,
linux-kernel, willy, bart.vanassche, viro, gregkh, schwidefsky,
jack
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
Some functions within driver/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run in
the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
drivers/dax/super.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 2b2332b..fad68d2 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -88,7 +88,6 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize)
struct dax_device *dax_dev;
pgoff_t pgoff;
int err, id;
- void *kaddr;
pfn_t pfn;
long len;
@@ -113,7 +112,7 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize)
}
id = dax_read_lock();
- len = dax_direct_access(dax_dev, pgoff, 1, &kaddr, &pfn);
+ len = dax_direct_access(dax_dev, pgoff, 1, NULL, &pfn);
dax_read_unlock(id);
put_dax(dax_dev);
--
1.8.3.1
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply related
* [PATCH 4/5] filesystem-dax: Do not request a pointer kaddr when not required
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: axboe, linux-s390, chengnt, linux-fsdevel, heiko.carstens,
linux-kernel, willy, bart.vanassche, viro, gregkh, schwidefsky,
jack
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
Some functions within fs/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run
in the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
fs/dax.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index aaec72de..abdb9e2 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -870,7 +870,6 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
{
const sector_t sector = dax_iomap_sector(iomap, pos);
pgoff_t pgoff;
- void *kaddr;
int id, rc;
long length;
@@ -879,7 +878,7 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
return rc;
id = dax_read_lock();
length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
- &kaddr, pfnp);
+ NULL, pfnp);
if (length < 0) {
rc = length;
goto out;
--
1.8.3.1
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply related
* [PATCH v3] mmc: sunxi: remove output of virtual base address
From: Maxime Ripard @ 2018-07-24 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723153431.8669-1-andre.przywara@arm.com>
On Mon, Jul 23, 2018 at 04:34:31PM +0100, Andre Przywara wrote:
> Recent Linux versions refuse to print actual virtual kernel addresses,
> to not give a hint about the location of the kernel in a randomized virtual
> address space. This affects the output of the sunxi MMC controller
> driver, which now produces the rather uninformative line:
>
> [ 1.482660] sunxi-mmc 1c0f000.mmc: base:0x(____ptrval____) irq:8
>
> Since the virtual base address is not really interesting in the first
> place, let's just drop this value. The same applies to Linux' notion of
> the interrupt number, which is independent from the GIC SPI number.
> We have the physical address as part of the DT node name, which is way
> more useful for debugging purposes.
> To keep a success message in the driver, we make this purpose explicit
> with the word "initialized", plus print some information that is not too
> obvious and that we learned while probing the device:
> the maximum request size and whether it uses the new timing mode.
> So the output turns into:
> [ 1.750626] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
> [ 1.786699] sunxi-mmc 1c11000.mmc: initialized, max. request size: 2048 KB
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180724/b8580186/attachment.sig>
^ permalink raw reply
* Re: [PATCH v3] mmc: sunxi: remove output of virtual base address
From: Maxime Ripard @ 2018-07-24 8:46 UTC (permalink / raw)
To: Andre Przywara
Cc: Ulf Hansson, Chen-Yu Tsai, Robin Murphy,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180723153431.8669-1-andre.przywara-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
On Mon, Jul 23, 2018 at 04:34:31PM +0100, Andre Przywara wrote:
> Recent Linux versions refuse to print actual virtual kernel addresses,
> to not give a hint about the location of the kernel in a randomized virtual
> address space. This affects the output of the sunxi MMC controller
> driver, which now produces the rather uninformative line:
>
> [ 1.482660] sunxi-mmc 1c0f000.mmc: base:0x(____ptrval____) irq:8
>
> Since the virtual base address is not really interesting in the first
> place, let's just drop this value. The same applies to Linux' notion of
> the interrupt number, which is independent from the GIC SPI number.
> We have the physical address as part of the DT node name, which is way
> more useful for debugging purposes.
> To keep a success message in the driver, we make this purpose explicit
> with the word "initialized", plus print some information that is not too
> obvious and that we learned while probing the device:
> the maximum request size and whether it uses the new timing mode.
> So the output turns into:
> [ 1.750626] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
> [ 1.786699] sunxi-mmc 1c11000.mmc: initialized, max. request size: 2048 KB
>
> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 3/5] s390, dcssblk: Allow a NULL-kaddr to ->direct_access()
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: axboe, linux-s390, chengnt, linux-fsdevel, heiko.carstens,
linux-kernel, willy, bart.vanassche, viro, gregkh, schwidefsky,
jack
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
dcssblk_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
drivers/s390/block/dcssblk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
index 0a312e4..9c13dc5 100644
--- a/drivers/s390/block/dcssblk.c
+++ b/drivers/s390/block/dcssblk.c
@@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
unsigned long dev_sz;
dev_sz = dev_info->end - dev_info->start + 1;
- *kaddr = (void *) dev_info->start + offset;
+ if (kaddr)
+ *kaddr = (void *) dev_info->start + offset;
*pfn = __pfn_to_pfn_t(PFN_DOWN(dev_info->start + offset),
PFN_DEV|PFN_SPECIAL);
--
1.8.3.1
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply related
* Re: [PATCH] ACPI / LPSS: Avoid PM quirks on suspend and resume from S3
From: Kai Heng Feng @ 2018-07-24 8:46 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: ACPI Devel Maling List, Ulf Hansson, P HeLiOn,
Linux Kernel Mailing List, Andy Shevchenko, Mika Westerberg,
Linux PM
In-Reply-To: <1568228.RgPNub1osy@aspire.rjw.lan>
Hi Rafael,
> On Jun 13, 2018, at 7:17 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> It is reported that commit a192aa923b66a (ACPI / LPSS: Consolidate
> runtime PM and system sleep handling) introduced a system suspend
> regression on some machines, but the only functional change made by
> it was to cause the PM quirks in the LPSS to also be used during
> system suspend and resume. While that should always work for
> suspend-to-idle, it turns out to be problematic for S3
> (suspend-to-RAM).
>
> To address that issue restore the previous S3 suspend and resume
> behavior of the LPSS to avoid applying PM quirks then.
The users reported that this patch does fix the S3 issue, but the S4 still
fails.
Please refer to [1] for more for user's testing result.
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950/comments/60
Kai-Heng
>
> Fixes: a192aa923b66a (ACPI / LPSS: Consolidate runtime PM and system
> sleep handling)
> Link: https://bugs.launchpad.net/bugs/1774950
> Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/acpi_lpss.c | 18 +++++++++++-------
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/acpi/acpi_lpss.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/acpi_lpss.c
> +++ linux-pm/drivers/acpi/acpi_lpss.c
> @@ -22,6 +22,7 @@
> #include <linux/pm_domain.h>
> #include <linux/pm_runtime.h>
> #include <linux/pwm.h>
> +#include <linux/suspend.h>
> #include <linux/delay.h>
>
> #include "internal.h"
> @@ -940,9 +941,10 @@ static void lpss_iosf_exit_d3_state(void
> mutex_unlock(&lpss_iosf_mutex);
> }
>
> -static int acpi_lpss_suspend(struct device *dev, bool wakeup)
> +static int acpi_lpss_suspend(struct device *dev, bool runtime)
> {
> struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> + bool wakeup = runtime || device_may_wakeup(dev);
> int ret;
>
> if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
> @@ -955,13 +957,14 @@ static int acpi_lpss_suspend(struct devi
> * wrong status for devices being about to be powered off. See
> * lpss_iosf_enter_d3_state() for further information.
> */
> - if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
> + if ((runtime || !pm_suspend_via_firmware()) &&
> + lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
> lpss_iosf_enter_d3_state();
>
> return ret;
> }
>
> -static int acpi_lpss_resume(struct device *dev)
> +static int acpi_lpss_resume(struct device *dev, bool runtime)
> {
> struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> int ret;
> @@ -970,7 +973,8 @@ static int acpi_lpss_resume(struct devic
> * This call is kept first to be in symmetry with
> * acpi_lpss_runtime_suspend() one.
> */
> - if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
> + if ((runtime || !pm_resume_via_firmware()) &&
> + lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
> lpss_iosf_exit_d3_state();
>
> ret = acpi_dev_resume(dev);
> @@ -994,12 +998,12 @@ static int acpi_lpss_suspend_late(struct
> return 0;
>
> ret = pm_generic_suspend_late(dev);
> - return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
> + return ret ? ret : acpi_lpss_suspend(dev, false);
> }
>
> static int acpi_lpss_resume_early(struct device *dev)
> {
> - int ret = acpi_lpss_resume(dev);
> + int ret = acpi_lpss_resume(dev, false);
>
> return ret ? ret : pm_generic_resume_early(dev);
> }
> @@ -1014,7 +1018,7 @@ static int acpi_lpss_runtime_suspend(str
>
> static int acpi_lpss_runtime_resume(struct device *dev)
> {
> - int ret = acpi_lpss_resume(dev);
> + int ret = acpi_lpss_resume(dev, true);
>
> return ret ? ret : pm_generic_runtime_resume(dev);
> }
^ permalink raw reply
* [PATCH 2/5] tools/testing/nvdimm: Allow a NULL-kaddr to ->direct_access()
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: axboe, linux-s390, chengnt, linux-fsdevel, heiko.carstens,
linux-kernel, willy, bart.vanassche, viro, gregkh, schwidefsky,
jack
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
The mock / test version of pmem_direct_access() needs to check the
validity of second rank pointer kaddr for NULL assignment. If kaddr
equals to NULL, it doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
tools/testing/nvdimm/pmem-dax.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/nvdimm/pmem-dax.c b/tools/testing/nvdimm/pmem-dax.c
index b53596a..c3ba159 100644
--- a/tools/testing/nvdimm/pmem-dax.c
+++ b/tools/testing/nvdimm/pmem-dax.c
@@ -31,7 +31,8 @@ long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
if (get_nfit_res(pmem->phys_addr + offset)) {
struct page *page;
- *kaddr = pmem->virt_addr + offset;
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
page = vmalloc_to_page(pmem->virt_addr + offset);
*pfn = page_to_pfn_t(page);
pr_debug_ratelimited("%s: pmem: %p pgoff: %#lx pfn: %#lx\n",
@@ -40,7 +41,8 @@ long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
return 1;
}
- *kaddr = pmem->virt_addr + offset;
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
*pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
/*
--
1.8.3.1
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply related
* [PATCH 1/5] libnvdimm, pmem: Allow a NULL-kaddr to ->direct_access()
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: axboe, linux-s390, chengnt, linux-fsdevel, heiko.carstens,
linux-kernel, willy, bart.vanassche, viro, gregkh, schwidefsky,
jack
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
pmem_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
drivers/nvdimm/pmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 9d71492..b1d121a 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -232,7 +232,9 @@ __weak long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
if (unlikely(is_bad_pmem(&pmem->bb, PFN_PHYS(pgoff) / 512,
PFN_PHYS(nr_pages))))
return -EIO;
- *kaddr = pmem->virt_addr + offset;
+
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
*pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
/*
--
1.8.3.1
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply related
* [PATCH 0/5] Do not request a pointer kaddr when not required
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: axboe, linux-s390, chengnt, linux-fsdevel, heiko.carstens,
linux-kernel, willy, bart.vanassche, viro, gregkh, schwidefsky,
jack
From: Huaisheng Ye <yehs1@lenovo.com>
Some functions within fs/dax and dax/super don't need to get kaddr from
direct_access. Assigning NULL to kaddr to ->direct_access() is more
straightforward and simple than offering a useless local pointer.
So all direct_access() need to check the validity of second rank pointer
kaddr for NULL assignment. If kaddr equals to NULL, it doesn't need to
calculate its value.
* This series are supplement to [PATCH v2 00/14]mm: Asynchronous +
multithreaded memmap init for ZONE_DEVICE. [1]
[1]: https://lkml.org/lkml/2018/7/16/828
Huaisheng Ye (5):
libnvdimm, pmem: Allow a NULL-kaddr to ->direct_access()
tools/testing/nvdimm: Allow a NULL-kaddr to ->direct_access()
s390, dcssblk: Allow a NULL-kaddr to ->direct_access()
filesystem-dax: Do not request a pointer kaddr when not required
dax/super: Do not request a pointer kaddr when not required
drivers/dax/super.c | 3 +--
drivers/nvdimm/pmem.c | 4 +++-
drivers/s390/block/dcssblk.c | 3 ++-
fs/dax.c | 3 +--
tools/testing/nvdimm/pmem-dax.c | 6 ++++--
5 files changed, 11 insertions(+), 8 deletions(-)
--
1.8.3.1
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* [PATCH 5/5] dax/super: Do not request a pointer kaddr when not required
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: ross.zwisler, willy, vishal.l.verma, dave.jiang, schwidefsky,
heiko.carstens, viro, martin.petersen, axboe, gregkh,
bart.vanassche, jack, linux-kernel, linux-s390, linux-fsdevel,
chengnt, Huaisheng Ye
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
Some functions within driver/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run in
the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
drivers/dax/super.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 2b2332b..fad68d2 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -88,7 +88,6 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize)
struct dax_device *dax_dev;
pgoff_t pgoff;
int err, id;
- void *kaddr;
pfn_t pfn;
long len;
@@ -113,7 +112,7 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize)
}
id = dax_read_lock();
- len = dax_direct_access(dax_dev, pgoff, 1, &kaddr, &pfn);
+ len = dax_direct_access(dax_dev, pgoff, 1, NULL, &pfn);
dax_read_unlock(id);
put_dax(dax_dev);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 4/5] filesystem-dax: Do not request a pointer kaddr when not required
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: ross.zwisler, willy, vishal.l.verma, dave.jiang, schwidefsky,
heiko.carstens, viro, martin.petersen, axboe, gregkh,
bart.vanassche, jack, linux-kernel, linux-s390, linux-fsdevel,
chengnt, Huaisheng Ye
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
Some functions within fs/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run
in the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
fs/dax.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index aaec72de..abdb9e2 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -870,7 +870,6 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
{
const sector_t sector = dax_iomap_sector(iomap, pos);
pgoff_t pgoff;
- void *kaddr;
int id, rc;
long length;
@@ -879,7 +878,7 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
return rc;
id = dax_read_lock();
length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
- &kaddr, pfnp);
+ NULL, pfnp);
if (length < 0) {
rc = length;
goto out;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3/5] s390, dcssblk: Allow a NULL-kaddr to ->direct_access()
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: ross.zwisler, willy, vishal.l.verma, dave.jiang, schwidefsky,
heiko.carstens, viro, martin.petersen, axboe, gregkh,
bart.vanassche, jack, linux-kernel, linux-s390, linux-fsdevel,
chengnt, Huaisheng Ye
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
dcssblk_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
drivers/s390/block/dcssblk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
index 0a312e4..9c13dc5 100644
--- a/drivers/s390/block/dcssblk.c
+++ b/drivers/s390/block/dcssblk.c
@@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
unsigned long dev_sz;
dev_sz = dev_info->end - dev_info->start + 1;
- *kaddr = (void *) dev_info->start + offset;
+ if (kaddr)
+ *kaddr = (void *) dev_info->start + offset;
*pfn = __pfn_to_pfn_t(PFN_DOWN(dev_info->start + offset),
PFN_DEV|PFN_SPECIAL);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/5] tools/testing/nvdimm: Allow a NULL-kaddr to ->direct_access()
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: ross.zwisler, willy, vishal.l.verma, dave.jiang, schwidefsky,
heiko.carstens, viro, martin.petersen, axboe, gregkh,
bart.vanassche, jack, linux-kernel, linux-s390, linux-fsdevel,
chengnt, Huaisheng Ye
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
The mock / test version of pmem_direct_access() needs to check the
validity of second rank pointer kaddr for NULL assignment. If kaddr
equals to NULL, it doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
tools/testing/nvdimm/pmem-dax.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/nvdimm/pmem-dax.c b/tools/testing/nvdimm/pmem-dax.c
index b53596a..c3ba159 100644
--- a/tools/testing/nvdimm/pmem-dax.c
+++ b/tools/testing/nvdimm/pmem-dax.c
@@ -31,7 +31,8 @@ long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
if (get_nfit_res(pmem->phys_addr + offset)) {
struct page *page;
- *kaddr = pmem->virt_addr + offset;
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
page = vmalloc_to_page(pmem->virt_addr + offset);
*pfn = page_to_pfn_t(page);
pr_debug_ratelimited("%s: pmem: %p pgoff: %#lx pfn: %#lx\n",
@@ -40,7 +41,8 @@ long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
return 1;
}
- *kaddr = pmem->virt_addr + offset;
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
*pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
/*
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/5] libnvdimm, pmem: Allow a NULL-kaddr to ->direct_access()
From: Huaisheng Ye @ 2018-07-24 8:45 UTC (permalink / raw)
To: linux-nvdimm, dan.j.williams
Cc: ross.zwisler, willy, vishal.l.verma, dave.jiang, schwidefsky,
heiko.carstens, viro, martin.petersen, axboe, gregkh,
bart.vanassche, jack, linux-kernel, linux-s390, linux-fsdevel,
chengnt, Huaisheng Ye
In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com>
From: Huaisheng Ye <yehs1@lenovo.com>
pmem_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
---
drivers/nvdimm/pmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 9d71492..b1d121a 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -232,7 +232,9 @@ __weak long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
if (unlikely(is_bad_pmem(&pmem->bb, PFN_PHYS(pgoff) / 512,
PFN_PHYS(nr_pages))))
return -EIO;
- *kaddr = pmem->virt_addr + offset;
+
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
*pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
/*
--
1.8.3.1
^ permalink raw reply related
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.