From: Greg KH <gregkh@linuxfoundation.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>,
wsa@kernel.org, jie.deng@intel.com,
virtualization@lists.linux-foundation.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@axis.com
Subject: Re: [PATCH 1/2] i2c: virtio: disable timeout handling
Date: Tue, 19 Oct 2021 13:16:46 +0200 [thread overview]
Message-ID: <YW6pHkXOPvtidtwS@kroah.com> (raw)
In-Reply-To: <20211019094203.3kjzch7ipbdv7peg@vireshk-i7>
On Tue, Oct 19, 2021 at 03:12:03PM +0530, Viresh Kumar wrote:
> On 19-10-21, 11:36, Greg KH wrote:
> > What is the "other side" here? Is it something that you trust or not?
>
> Other side can be a remote processor (for remoteproc over virtio or
> something similar), or traditionally it can be host OS or host
> firmware providing virtualisation to a Guest running Linux (this
> driver). Or something else..
>
> I would incline towards "we trust the other side" here.
That's in contradition with what other people seem to think the virtio
drivers are for, see this crazy thread for details about that:
https://lore.kernel.org/all/20211009003711.1390019-1-sathyanarayanan.kuppuswamy@linux.intel.com/
You can "trust" the hardware, but also handle things when hardware is
broken, which is most often the case in the real world.
So why is having a timeout a problem here? If you have an overloaded
system, you want things to time out so that you can start to recover.
> > Usually we trust the hardware, but if you do not trust the hardware,
> > then yes, you need to have a timeout here.
>
> The other side is the software that has access to the _Real_ hardware,
> and so we should trust it. So we can have a actually have a completion
> without timeout here, interesting.
And if that hardware stops working? Timeouts are good to have, why not
just bump it up a bit if you are running into it in a real-world
situation?
thanks,
greg k-h
next prev parent reply other threads:[~2021-10-19 11:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-19 7:46 [PATCH 0/2] virtio-i2c: Fix buffer handling Vincent Whitchurch
2021-10-19 7:46 ` [PATCH 1/2] i2c: virtio: disable timeout handling Vincent Whitchurch
2021-10-19 8:09 ` Viresh Kumar
2021-10-19 9:36 ` Greg KH
2021-10-19 9:42 ` Viresh Kumar
2021-10-19 11:15 ` Wolfram Sang
2021-10-19 14:14 ` Viresh Kumar
2021-10-19 11:16 ` Greg KH [this message]
2021-10-19 14:37 ` Viresh Kumar
2021-10-19 18:14 ` Wolfram Sang
2021-10-20 4:20 ` Jie Deng
2021-10-20 5:36 ` Greg KH
2021-10-20 6:35 ` Jie Deng
2021-10-20 6:41 ` Viresh Kumar
2021-10-20 7:04 ` Jie Deng
2021-10-20 10:55 ` Vincent Whitchurch
2021-10-20 11:03 ` Viresh Kumar
2021-10-21 3:30 ` Jie Deng
2021-10-29 12:24 ` Vincent Whitchurch
2021-11-01 5:23 ` Jie Deng
2021-11-03 6:18 ` Chen, Conghui
2021-11-03 6:37 ` Viresh Kumar
2021-11-03 14:42 ` Vincent Whitchurch
2021-11-09 4:52 ` Viresh Kumar
2021-10-20 3:36 ` Jie Deng
2021-10-19 7:46 ` [PATCH 2/2] i2c: virtio: fix completion handling Vincent Whitchurch
2021-10-19 8:22 ` Viresh Kumar
2021-10-20 8:54 ` Jie Deng
2021-10-20 9:17 ` Viresh Kumar
2021-10-20 10:38 ` Vincent Whitchurch
2021-10-20 10:47 ` Viresh Kumar
2021-10-29 11:54 ` Vincent Whitchurch
2021-10-21 5:55 ` Jie Deng
2021-10-21 5:58 ` Viresh Kumar
2021-11-02 4:32 ` Viresh Kumar
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=YW6pHkXOPvtidtwS@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jie.deng@intel.com \
--cc=kernel@axis.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vincent.whitchurch@axis.com \
--cc=viresh.kumar@linaro.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wsa@kernel.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).