From: "Jürgen Groß" <jgross@suse.com>
To: Julien Grall <julien@xen.org>, Simon Leiner <simon@leiner.me>,
xen-devel@lists.xenproject.org, sstabellini@kernel.org
Subject: Re: [PATCH 2/2] arm/xen: Add misuse warning to virt_to_gfn
Date: Thu, 27 Aug 2020 10:35:04 +0200 [thread overview]
Message-ID: <18229211-c7b5-21bc-f3a9-4a9a1974094e@suse.com> (raw)
In-Reply-To: <3a1cad1b-3d78-e5b0-0f68-70c245dbcc1a@xen.org>
On 27.08.20 10:24, Julien Grall wrote:
>
>
> On 27/08/2020 06:21, Jürgen Groß wrote:
>> On 26.08.20 20:37, Julien Grall wrote:
>> "Usually" is a bit gross here. The only generic call site I could find
>> is xenbus_grant_ring(). All other instances (I counted 22) are not
>> generic at all.
>>
>>> will only catch one instance and it means we would have to fix the
>>> first instance and then re-run to catch the others.
>>>
>>> So I think we want to switch to WARN_ON() here.
>>
>> No, please don't. In case there would be a frequent path the result
>> would be a basically unusable system due to massive console clobbering.
>
> Right, but if that's really happenning then you have a much bigger
> problem on your platform because the address returned will be invalid.
>
> So I still don't see the advantage of WARN_ON_ONCE() here.
Depends of the (potential) source of the warnings. I think we can agree
that e.g. a problem in the pv network stack is rather improbable, as it
would have been detected long ago.
If, however, the problem is being introduced by one of the rather new
pv-drivers (like sound, pvcalls, 9pfs) it is perfectly fine to assume
the overall system is still functional even without those drivers
working correctly. Having a message storm from those sources is still
quite undesirable IMO and doesn't really help.
Juergen
next prev parent reply other threads:[~2020-08-27 8:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Aw: [Linux] [ARM] Granting memory obtained from the DMA API>
2020-08-25 9:31 ` [PATCH 1/2] xen/xenbus: Fix granting of vmalloc'd memory Simon Leiner
2020-08-25 9:31 ` [PATCH 2/2] arm/xen: Add misuse warning to virt_to_gfn Simon Leiner
2020-08-25 12:16 ` Jan Beulich
2020-08-25 23:48 ` Stefano Stabellini
2020-08-26 6:20 ` Jan Beulich
2020-08-26 7:50 ` Simon Leiner
2020-08-26 7:59 ` Jürgen Groß
2020-08-26 8:14 ` Simon Leiner
2020-08-26 8:27 ` Jürgen Groß
2020-08-26 8:30 ` Simon Leiner
2020-08-25 23:58 ` Stefano Stabellini
2020-08-26 18:37 ` Julien Grall
2020-08-27 5:21 ` Jürgen Groß
2020-08-27 8:24 ` Julien Grall
2020-08-27 8:35 ` Jürgen Groß [this message]
2020-08-27 16:04 ` Stefano Stabellini
2020-08-25 23:55 ` [PATCH 1/2] xen/xenbus: Fix granting of vmalloc'd memory Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18229211-c7b5-21bc-f3a9-4a9a1974094e@suse.com \
--to=jgross@suse.com \
--cc=julien@xen.org \
--cc=simon@leiner.me \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).