All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier@cisco.com>
To: Hoang-Nam Nguyen <HNGUYEN@de.ibm.com>
Cc: Christoph Raisch <raisch@de.ibm.com>,
	general@lists.openfabrics.org,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Roland Dreier <rolandd@cisco.com>,
	Sean Hefty <sean.hefty@intel.com>,
	Pavel Emelyanov <xemul@openvz.org>
Subject: Re: [PATCH 1/3] Infiniband: make ehca_pd use struct pid pointer rather than pid_t
Date: Tue, 18 Mar 2008 11:27:00 -0700	[thread overview]
Message-ID: <adazlsvopl7.fsf@cisco.com> (raw)
In-Reply-To: <OF4F7C6111.9AA26F4F-ONC1257410.00599780-C1257410.005E3475@de.ibm.com> (Hoang-Nam Nguyen's message of "Tue, 18 Mar 2008 18:09:22 +0100")

 > Right, above checking is based on a very simple policy "creator of a
 > resource is also the owner in term of releasing it" and will not cover
 > other customized patterns. We had a case - believe on sles9, in which
 > a child process manipulated/released resources from parent one, and
 > it was not easy to find the bug.

Hmm, I can see how that might be ugly.  On the other hand it doesn't
seem like the unix way for a process not to be able to do something
with a file if it has a valid fd.

 > Wrt/ your actual question: we can remove the tgid stuff from ehca kernel
 > code. When do you expect me to send a patch at latest?

I don't think it's super-urgent.  If you can't do it, say, by the end
of this week, then I'll apply Pavel's patch so we don't block his
progress on namespace stuff.  But I would still like to get a patch to
move this out of ehca at some point, so please don't drop it.

If you guys think there is value in having the checks, then please
send a patch to add the ownership stuff to the uverbs core and we can
argue about it then.

Thanks,
  Roland


      reply	other threads:[~2008-03-19 21:03 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
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 [this message]

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=adazlsvopl7.fsf@cisco.com \
    --to=rdreier@cisco.com \
    --cc=HNGUYEN@de.ibm.com \
    --cc=general@lists.openfabrics.org \
    --cc=hal.rosenstock@gmail.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 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.