From: Ben Widawsky <ben.widawsky@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-cxl@vger.kernel.org,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH] cxl/mem: Fixes to IOCTL interface
Date: Sat, 20 Feb 2021 19:47:03 -0800 [thread overview]
Message-ID: <20210221034703.ncetonon7iseqd72@intel.com> (raw)
In-Reply-To: <CAPcyv4gfoe=QGuKV19ay51D-cqzRqTMLpD-p5whnJbYkKoGtBA@mail.gmail.com>
On 21-02-20 18:38:36, Dan Williams wrote:
> On Sat, Feb 20, 2021 at 1:57 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
> >
> > When submitting a command for userspace, input and output payload bounce
> > buffers are allocated. For a given command, both input and output
> > buffers may exist and so when allocation of the input buffer fails, the
> > output buffer must be freed. As far as I can tell, userspace can't
> > easily exploit the leak to OOM a machine unless the machine was already
> > near OOM state.
> >
> > This bug was introduced in v5 of the patch and did not exist in prior
> > revisions.
> >
>
> Thanks for the quick turnaround, but I think that speed introduced
> some issues...
>
> > While here, adjust the variable 'j' found in patch review by Konrad.
>
> Please split this pure cleanup to its own patch. The subject says
> "Fixes", but it's only the one fix.
>
This was intentional. I pinged you internally to just drop it if you don't like
to combine these kind of things. It didn't feel worthwhile to introduce a new
patch to change the 'j'. I agree with Konrad that 'j' is not the best variable
name to use. Konrad, maybe you'd like to send a fixup for that one?
I will drop this hunk.
> >
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> Since the commit is upstream add a "Fixes" line:
>
> Fixes: 583fa5e71cae ('cxl/mem: Add basic IOCTL interface")
>
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com> (v2)
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> Jonathan and I didn't pre-review this.
My bad on this. It was a mistake that I pulled the info from the original patch
I was fixing.
WARNING: multiple messages have this Message-ID (diff)
From: Ben Widawsky <ben.widawsky@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-cxl@vger.kernel.org,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Alison Schofield <alison.schofield@intel.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH] cxl/mem: Fixes to IOCTL interface
Date: Sat, 20 Feb 2021 19:47:03 -0800 [thread overview]
Message-ID: <20210221034703.ncetonon7iseqd72@intel.com> (raw)
In-Reply-To: <CAPcyv4gfoe=QGuKV19ay51D-cqzRqTMLpD-p5whnJbYkKoGtBA@mail.gmail.com>
On 21-02-20 18:38:36, Dan Williams wrote:
> On Sat, Feb 20, 2021 at 1:57 PM Ben Widawsky <ben.widawsky@intel.com> wrote:
> >
> > When submitting a command for userspace, input and output payload bounce
> > buffers are allocated. For a given command, both input and output
> > buffers may exist and so when allocation of the input buffer fails, the
> > output buffer must be freed. As far as I can tell, userspace can't
> > easily exploit the leak to OOM a machine unless the machine was already
> > near OOM state.
> >
> > This bug was introduced in v5 of the patch and did not exist in prior
> > revisions.
> >
>
> Thanks for the quick turnaround, but I think that speed introduced
> some issues...
>
> > While here, adjust the variable 'j' found in patch review by Konrad.
>
> Please split this pure cleanup to its own patch. The subject says
> "Fixes", but it's only the one fix.
>
This was intentional. I pinged you internally to just drop it if you don't like
to combine these kind of things. It didn't feel worthwhile to introduce a new
patch to change the 'j'. I agree with Konrad that 'j' is not the best variable
name to use. Konrad, maybe you'd like to send a fixup for that one?
I will drop this hunk.
> >
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> Since the commit is upstream add a "Fixes" line:
>
> Fixes: 583fa5e71cae ('cxl/mem: Add basic IOCTL interface")
>
> > Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com> (v2)
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> Jonathan and I didn't pre-review this.
My bad on this. It was a mistake that I pulled the info from the original patch
I was fixing.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
next prev parent reply other threads:[~2021-02-21 3:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-20 21:56 [PATCH] cxl/mem: Fixes to IOCTL interface Ben Widawsky
2021-02-20 21:56 ` Ben Widawsky
2021-02-21 2:38 ` Dan Williams
2021-02-21 2:38 ` Dan Williams
2021-02-21 3:47 ` Ben Widawsky [this message]
2021-02-21 3:47 ` Ben Widawsky
2021-02-22 16:12 ` Dan Williams
2021-02-22 16:12 ` Dan Williams
2021-02-22 17:19 ` Konrad Rzeszutek Wilk
2021-02-22 17:19 ` Konrad Rzeszutek Wilk
2021-02-21 3:58 ` [PATCH v2] cxl/mem: Fix potential memory leak Ben Widawsky
2021-02-21 3:58 ` Ben Widawsky
2021-02-22 16:28 ` Jonathan Cameron
2021-02-22 16:28 ` Jonathan Cameron
2021-02-22 17:09 ` Konrad Rzeszutek Wilk
2021-02-22 17:09 ` Konrad Rzeszutek Wilk
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=20210221034703.ncetonon7iseqd72@intel.com \
--to=ben.widawsky@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=ira.weiny@intel.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vishal.l.verma@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.