netdev - Re: [PATCH v5 13/16] IB/pvrdma: Add the main driver module for PVRDMA

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] [day] [month] [year] [list]

Date:   Tue, 27 Sep 2016 11:50:44 -0700
From:   Adit Ranadive <aditr@...are.com>
To:     David Laight <David.Laight@...LAB.COM>,
        Yuval Shaia <yuval.shaia@...cle.com>
CC:     "dledford@...hat.com" <dledford@...hat.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "pv-drivers@...are.com" <pv-drivers@...are.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "jhansen@...are.com" <jhansen@...are.com>,
        "asarwade@...are.com" <asarwade@...are.com>,
        "georgezhang@...are.com" <georgezhang@...are.com>,
        "bryantan@...are.com" <bryantan@...are.com>
Subject: Re: [PATCH v5 13/16] IB/pvrdma: Add the main driver module for PVRDMA

On Tue, Sep 27, 2016 at 09:21:27AM +0000, David Laight wrote:
> From: Adit Ranadive
> > Sent: 26 September 2016 19:15
> > On Mon, Sep 26, 2016 at 00:27:40AM -0700, Yuval Shaia wrote:
> > > On Sat, Sep 24, 2016 at 04:21:37PM -0700, Adit Ranadive wrote:
> > > > +
> > > > +	/* Currently, the driver only supports RoCE mode. */
> > > > +	if (dev->dsr->caps.mode != PVRDMA_DEVICE_MODE_ROCE) {
> > > > +		dev_err(&pdev->dev, "unsupported transport %d\n",
> > > > +			dev->dsr->caps.mode);
> > > > +		ret = -EINVAL;
> > >
> > > This is some fatal error with the device, not that something wrong with the
> > > function's argument.
> > > Suggesting to replace with -EFAULT.
> > >
> > 
> > Thanks, will fix this one and the others here.
> 
> Won't EFAULT generate SIGSEGV ?

Since this is called at module load time, wouldn't the module load fail with
this error rather than generate a SIGSEGV?

I'm slightly unclear about what would if it is compiled into the kernel though
I think it should fail with the error.

The only other error value to return here that could make sense is EIO.