From: Roland Dreier <rdreier@cisco.com>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: Roland Dreier <rolandd@cisco.com>,
Sean Hefty <sean.hefty@intel.com>,
Hal Rosenstock <hal.rosenstock@gmail.com>,
general@lists.openfabrics.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hoang-Nam Nguyen <hnguyen@de.ibm.com>,
Christoph Raisch <raisch@de.ibm.com>
Subject: Re: [PATCH 1/3] Infiniband: make ehca_pd use struct pid pointer rather than pid_t
Date: Mon, 17 Mar 2008 13:56:14 -0700 [thread overview]
Message-ID: <adatzj5f4sx.fsf@cisco.com> (raw)
In-Reply-To: <47DE683E.3050005@openvz.org> (Pavel Emelyanov's message of "Mon, 17 Mar 2008 15:46:54 +0300")
> The task_struct->tgid field is about to become deprecated, due to
> pid namespaces make tasks have many pids, not one. The infiniband
> driver is one of the code, that still uses it in some places.
Looks fine in terms of the changes it makes, but actually it seems
that the ehca use of this is completely bogus and the ownership
checking should be removed.
The core ib_uverbs module has checks that make sure that objects can
only be accessed through the file that they were created through; of
course there are tricky ways a file can be passed from one process to
another, but I don't think we want to disallow userspace processes
from trying to do interesting stuff as long as it doesn't hurt anything.
In other words-- ehca shouldn't be looking at tgids or anything like
that at all. If there are missing checks then they should be in the
core userspace verbs stuff; but I think what we have is actually OK.
ehca guys, what do you think?
- R.
next prev parent reply other threads:[~2008-03-17 20:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-17 12:46 [PATCH 1/3] Infiniband: make ehca_pd use struct pid pointer rather than pid_t Pavel Emelyanov
2008-03-17 20:56 ` Roland Dreier [this message]
2008-03-18 15:52 ` Hoang-Nam Nguyen
2008-03-18 16:10 ` Roland Dreier
2008-03-18 17:09 ` Hoang-Nam Nguyen
2008-03-18 18:27 ` Roland Dreier
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=adatzj5f4sx.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=general@lists.openfabrics.org \
--cc=hal.rosenstock@gmail.com \
--cc=hnguyen@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=raisch@de.ibm.com \
--cc=rolandd@cisco.com \
--cc=sean.hefty@intel.com \
--cc=xemul@openvz.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox