Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Nathan Lynch <nathanl@linux.ibm.com>
To:     Michal =?utf-8?Q?Such=C3=A1nek?= <msuchanek@suse.de>
Cc:     Laurent Dufour <ldufour@linux.ibm.com>,
        Tyrel Datwyler <tyreld@linux.ibm.com>,
        linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
        Michal Hocko <mhocko@suse.com>, Lee@kitsune.suse.cz,
        Chun-Yi <jlee@suse.com>
Subject: Re: [PATCH] powerpc/pseries: add lparctl driver for
 platform-specific functions
In-Reply-To: <20220913163343.GA28810@kitsune.suse.cz>
References: <20220730000458.130938-1-nathanl@linux.ibm.com>
 <0ead0cd1-f6f6-ecf0-65d9-f3d9366e258c@linux.ibm.com>
 <87k07dl1f6.fsf@linux.ibm.com> <20220913091302.GY28810@kitsune.suse.cz>
 <87v8prtgcj.fsf@linux.ibm.com> <20220913163343.GA28810@kitsune.suse.cz>
Date:   Tue, 13 Sep 2022 12:02:42 -0500
Message-ID: <87sfkvtdfx.fsf@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Michal Such=C3=A1nek <msuchanek@suse.de> writes:
> On Tue, Sep 13, 2022 at 10:59:56AM -0500, Nathan Lynch wrote:
>> Michal Such=C3=A1nek <msuchanek@suse.de> writes:
>>=20
>> > On Fri, Aug 12, 2022 at 02:14:21PM -0500, Nathan Lynch wrote:
>> >> Laurent Dufour <ldufour@linux.ibm.com> writes:
>> >> > Le 30/07/2022 =C3=A0 02:04, Nathan Lynch a =C3=A9crit=C2=A0:
>> >> >> +static long lparctl_get_sysparm(struct lparctl_get_system_paramet=
er __user *argp)
>> >> >> +{
>> >> >> +	struct lparctl_get_system_parameter *gsp;
>> >> >> +	long ret;
>> >> >> +	int fwrc;
>> >> >> +
>> >> >> +	/*
>> >> >> +	 * Special case to allow user space to probe the command.
>> >> >> +	 */
>> >> >> +	if (argp =3D=3D NULL)
>> >> >> +		return 0;
>> >> >> +
>> >> >> +	gsp =3D memdup_user(argp, sizeof(*gsp));
>> >> >> +	if (IS_ERR(gsp)) {
>> >> >> +		ret =3D PTR_ERR(gsp);
>> >> >> +		goto err_return;
>> >> >> +	}
>> >> >> +
>> >> >> +	ret =3D -EINVAL;
>> >> >> +	if (gsp->rtas_status !=3D 0)
>> >> >> +		goto err_free;
>> >> >> +
>> >> >> +	do {
>> >> >> +		static_assert(sizeof(gsp->data) <=3D sizeof(rtas_data_buf));
>> >> >> +
>> >> >> +		spin_lock(&rtas_data_buf_lock);
>> >> >> +		memset(rtas_data_buf, 0, sizeof(rtas_data_buf));
>> >> >> +		memcpy(rtas_data_buf, gsp->data, sizeof(gsp->data));
>> >> >> +		fwrc =3D rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
>> >> >> +				 NULL, gsp->token, __pa(rtas_data_buf),
>> >> >> +				 sizeof(gsp->data));
>> >> >> +		if (fwrc =3D=3D 0)
>> >> >> +			memcpy(gsp->data, rtas_data_buf, sizeof(gsp->data));
>> >> >
>> >> > May be the amount of data copied out to the user space could be
>> >> > gsp->length. This would prevent copying 4K bytes all the time.
>> >> >
>> >> > In a more general way, the size of the RTAS buffer is quite big, an=
d I'm
>> >> > wondering if all the data need to be copied back and forth to the k=
ernel.
>> >> >
>> >> > Unless there are a high frequency of calls this doesn't make sense,=
 and
>> >> > keeping the code simple might be the best way. Otherwise limiting t=
he bytes
>> >> > copied could help a bit.
>> >>=20
>> >> This is not intended to be a high-bandwidth interface and I don't thi=
nk
>> >> there's much of a performance concern here, so I'd rather just keep t=
he
>> >> copy sizes involved constant.
>> >
>> > But that's absolutely horrible!
>>=20
>> ?
>>=20
>> > The user wants the VPD data, all of it. And you only give one page with
>> > this interface.
>>=20
>> The code here is for system parameters, which have a known maximum size,
>> unlike VPD. There's no code for VPD retrieval in this patch.
>
> But we do need to support the calls that return multiple pages of data.
>
> If the new driver supports only the simple calls it's a failure.

Michal, will you please moderate your tone? I think you can communicate
your concerns without calling my work "absolutely horrible" or a
"failure". Thanks.

Anyway, of course I intend to support the more complex calls, but
supporting the simple calls actually unbreaks a lot of stuff.

>> But I'm happy to constructively discuss how a VPD ioctl interface should
>> work.
>>=20
>> > Worse, the call is not reentrant so you need to lock against other use=
rs
>> > calling the call while the current caller is retrieving the inidividual
>> > pagaes.
>> >
>> > You could do that per process, but then processes with userspace
>> > threading would want the data as well so you would have to save the
>> > arguments of the last call, and compare to arguments of any subsequent
>> > call to determine if you can let it pass or block.
>> >
>> > And when you do all that there will be a process that retrieves a coup=
le
>> > of pages and goes out for lunch or loses interest completely, blocking
>> > out everyone from accessing the interface at all.
>>=20
>> Right, the ibm,get-vpd RTAS function is tricky to expose to user space.
>>=20
>> It needs to be called repeatedly until all data has been returned, 4KB
>> at a time.
>>=20
>> Only one ibm,get-vpd sequence can be in progress at any time. If an
>> ibm,get-vpd sequence is begun while another sequence is already
>> outstanding, the first one is invalidated -- I would guess -1 or some
>> other error is returned on its next call.
>>=20
>> So a new system-call level interface for VPD retrieval probably should
>> not expose the repeating sequence-based nature of the RTAS function to
>> user space, to prevent concurrent clients from interfering with each
>> other. That implies that the kernel should buffer the VPD results
>> internally; at least that's the only idea I've had so far. Open to
>> other suggestions.
>
> It can save the data to an user-supplied buffer until all data is
> transferred or the buffer space runs out.

Yes, of course, thanks. Assuming user space can discover the appropriate
buffer size, which should be possible.