linux-kernel - Re: [PATCH 1/4] drivers: hv: dxgkrnl: core code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Aug 2020 16:29:59 -0700
From:   Iouri Tarassov <iourit@...ux.microsoft.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Sasha Levin <sashal@...nel.org>
Cc:     kys@...rosoft.com, haiyangz@...rosoft.com, sthemmin@...rosoft.com,
        wei.liu@...nel.org, iourit@...rosoft.com,
        linux-kernel@...r.kernel.org, linux-hyperv@...r.kernel.org
Subject: Re: [PATCH 1/4] drivers: hv: dxgkrnl: core code

On 8/14/2020 5:55 AM, Greg KH wrote:
> On Fri, Aug 14, 2020 at 08:38:53AM -0400, Sasha Levin wrote:
> > Add support for a Hyper-V based vGPU implementation that exposes the
> > DirectX API to Linux userspace.
> > 
> > Signed-off-by: Sasha Levin <sashal@...nel.org>
>
> Better, but what is this mess:
>
> > +#define ISERROR(ret)					(ret < 0)

The VM bus messages return the NTSTATUS error code from the host. 
NTSTATUS is integer and the positive values indicate success.
The success error code needs to be returned by IOCTLs to the DxCore 
applications. The ISERROR() macro is used in places where the NTSTATUS 
success code could be returned from a function. "if (ret)" cannot be 
used. I will add a comment to the macro in the next patch.

>
> ?
>
> > +#define EINTERNALERROR					EINVAL
This macro will be removed in the next patch
> And that?
>
> > +
> > +#define DXGKRNL_ASSERT(exp)
> > +#define UNUSED(x) (void)(x)
The UNUSED macro will be removed.
The DXGKRNL_ASSERT() macro will be changed to generate a memory dump and 
BUG_ON when DXGDEBUG is enabled. It is used to catch internal errors in 
the debug code. There will be no bugcheck in the released driver.
>
> Ick, no, please.
>
> > +#undef pr_fmt
>
> In a .h file?
>
> > +#define pr_fmt(fmt)	"dxgk:err: " fmt
> > +#define pr_fmt1(fmt)	"dxgk: " fmt
> > +#define pr_fmt2(fmt)	"dxgk:    " fmt
This will be fixed in the next patch set.
> Why?
>
> > +
> > +#define DXGKDEBUG 1
> > +/* #define USEPRINTK 1 */
> > +
> > +#ifndef DXGKDEBUG
> > +#define TRACE_DEBUG(...)
> > +#define TRACE_DEFINE(...)
> > +#define TRACE_FUNC_ENTER(...)
> > +#define TRACE_FUNC_EXIT(...)
>
> No, please do not to custom "trace" printk messages, that is what ftrace
> is for, no individual driver should ever need to do that.
>
> Just use the normal dev_*() calls for error messages and the like, do
> not try to come up with a custom tracing framework for one tiny
> individual driver.  If every driver in kernel did that, we would have a
> nightmare...
I understand the concern. This will be fixed later when we learn and 
pick the final tracing technology for the driver. The current 
implementation allows the hardware vendors to quickly identify issues 
without learning about ftrace. They just need to enable the WSL debug 
console and mount debugfs.
> thanks,
>
> greg k-h
>
Thank you for your time and good comments.
Iouri