Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Message-ID: <f3b30b70563c68b56451e3eb7a3e22ce4c142651.camel@codeconstruct.com.au>
Subject: Re: [PATCH 05/10] ipmi: kcs_bmc: Define client actions in terms of
 kcs_bmc_client
From:   Andrew Jeffery <andrew@codeconstruct.com.au>
To:     Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc:     minyard@acm.org, openipmi-developer@lists.sourceforge.net,
        linux-kernel@vger.kernel.org, aladyshev22@gmail.com,
        jk@codeconstruct.com.au
Date:   Tue, 07 Nov 2023 17:02:37 +1030
In-Reply-To: <20231103151651.000045ae@Huawei.com>
References: <20231103061522.1268637-1-andrew@codeconstruct.com.au>
         <20231103061522.1268637-6-andrew@codeconstruct.com.au>
         <20231103151651.000045ae@Huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2023-11-03 at 15:16 +0000, Jonathan Cameron wrote:
> On Fri,  3 Nov 2023 16:45:17 +1030
> Andrew Jeffery <andrew@codeconstruct.com.au> wrote:
>=20
> > Operations such as reading and writing from hardware and updating the
> > events of interest are operations in which the client is interested, bu=
t
> > are applied to the device. Strengthen the concept of the client in the
> > subsystem and clean up some call-sites by translating between the clien=
t
> > and device types in the core of the KCS subsystem.
> >=20
> > Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
> > ---
> >  drivers/char/ipmi/kcs_bmc.c           | 67 ++++++++++++++++++---------
> >  drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 50 ++++++++++----------
> >  drivers/char/ipmi/kcs_bmc_client.h    | 15 +++---
> >  drivers/char/ipmi/kcs_bmc_serio.c     | 10 ++--
> >  4 files changed, 81 insertions(+), 61 deletions(-)
> >=20
> > diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
> > index 5a3f199241d2..d70e503041bd 100644
> > --- a/drivers/char/ipmi/kcs_bmc.c
> > +++ b/drivers/char/ipmi/kcs_bmc.c
> > @@ -22,33 +22,53 @@ static LIST_HEAD(kcs_bmc_drivers);
> > =20
> >  /* Consumer data access */
> > =20
> > -u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc)
> > +static void kcs_bmc_client_validate(struct kcs_bmc_client *client)
> >  {
> > -	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
> > +	WARN_ONCE(client !=3D READ_ONCE(client->dev->client), "KCS client con=
fusion detected");
>=20
> Is this intended as runtime validation or to catch bugs?
> If just catch bugs then fair enough.

Ah, I think I missed replying here.

So for "runtime validation" I assume you mean "things userspace might
do that are not valid - the error condition should be detected and
punted back to userspace", vs "catch bugs" meaning "the implementation
in the kernel failed to uphold an invariant and now there are
Problems".

If that sounds accurate, then it's the latter: The WARN_ONCE() is
asserting "don't operate on a client that doesn't own the device". It
isn't an error that can be punted back for handling in userspace as it
should not be possible for the kernel to get into this state to begin
with. If we reach this state it's an error in the programming of the
kernel module that's a client of the KCS subsystem.

>=20
> With that question answered based on my somewhat vague understanding of t=
he kcs subsystem.
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Thanks,

Andrew