On Mon, 2009-01-05 at 17:13 -0800, Matt Helsley wrote:
> plain text document attachment (move-rpc-client-nodename-cache.patch)
> Currently RPC needs to know the nodename (often the same as the hostname)
> which
> should be used for UNIX-style authentication and file-lock tracking. Because
> hostna
On Tue, 2009-01-06 at 14:02 -0600, Serge E. Hallyn wrote:
> Quoting Matt Helsley (matth...@us.ibm.com):
> > We can often specify the UTS namespace to use when starting an RPC client.
> > However sometimes no UTS namespace is available (specifically during system
> > shutdown as the last NFS mount i
On Tue, 2009-01-06 at 15:58 -0600, Serge E. Hallyn wrote:
> So should we use patch 2/4, plus (as someone - was it you? - suggested)
> using a DEFAULT instead of init_utsname()->nodename when
> current->utsname() == NULL?
No. I'm don't think that 2/4 is correct either. Basically, 2/4 is saying
tha
On Tue, 2009-01-06 at 15:04 -0800, Eric W. Biederman wrote:
> That implies to me you want to capture the value at mount time, and to
> pass it in to the rpc_call creation, and only at very specific well
> defined points where we interact with user space should we examine
> current->utsname(). At w
On Tue, 2009-01-06 at 18:32 -0500, J. Bruce Fields wrote:
> On Tue, Jan 06, 2009 at 06:15:34PM -0500, Trond Myklebust wrote:
> > On Tue, 2009-01-06 at 15:04 -0800, Eric W. Biederman wrote:
> > > That implies to me you want to capture the value at mount time, and to
> > >
On Tue, 2009-01-06 at 15:18 -0800, Matt Helsley wrote:
> Yes, I was aware that the inode might be dirtied by another container. I
> was thinking that, at least in the case of NFS, it makes sense to report
> the node name of the container that did the original mount. Of course
> this doesn't address
On Tue, 2009-01-06 at 16:08 -0800, Matt Helsley wrote:
> IMHO This seems more incorrect than trying to use a more proximal
namespace.
You have yet to explain why.
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-f
On Tue, 2009-01-06 at 16:08 -0800, Matt Helsley wrote:
> IMHO This seems more incorrect than trying to use a more proximal
> namespace.
You have yet to explain why.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.neta
On Tue, 2009-01-06 at 19:26 -0500, J. Bruce Fields wrote:
> On Tue, Jan 06, 2009 at 07:20:07PM -0500, Trond Myklebust wrote:
> > As for the NFSv4 clientid, I can't see how you would ever want to use
> > anything other than the init->utsname(), since the requirement is onl
lished
from a workqueue process), and so the source IP address will always be
that of the init namespace.
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
___
Containers mailing list
contain...@lists
resend it as a reply here. OK?
Sorry if you saw the request twice. My mail server at uio.no appears to
be on the blink, so I switched to the netapp account...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
_
On Tue, 2009-01-06 at 18:35 -0500, Trond Myklebust wrote:
> So how does tracking it in a shared structure like the rpc_client help?
> If you consider it to be part of the cred, then it needs to be tracked
> in the cred...
OK. If people really want to track this, then you could add a ref
On Tue, 2009-01-06 at 16:43 -0800, Matt Helsley wrote:
> On Tue, 2009-01-06 at 19:20 -0500, Trond Myklebust wrote:
> > On Tue, 2009-01-06 at 16:08 -0800, Matt Helsley wrote:
> > > IMHO This seems more incorrect than trying to use a more proximal
> > > namespace.
>
tion:
>
> http://ols.fedoraproject.org/OLS/Reprints-2008/mirkin-reprint.pdf
>
> then moving the NFS state strikes me as not the greatest of their
> troubles.
ROTFL...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
__
neral
> principle of not leaking information to a domain that the user wouldn't
> expect it to.
Then RPC would fail. Thanks to the limitations imposed by selinux &
friends, all RPC sockets have to be owned by the init process.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
tr
On Tue, 2009-05-12 at 14:51 -0700, Matt Helsley wrote:
> Sun RPC currently opens sockets from the initial network namespace making it
> impossible to restrict which NFS servers a container may interact with.
>
> For example, the NFS server at 10.0.0.3 reachable from the initial namespace
> will al
On Tue, 2009-05-12 at 17:04 -0700, Eric W. Biederman wrote:
> Trond Myklebust writes:
>
> > Finally, what happens if someone decides to set up a private socket
> > namespace, using CLONE_NEWNET, without also using CLONE_NEWNS to create
> > a private mount namespace? Wo
On Wed, 2007-04-18 at 11:11 +0200, Miklos Szeredi wrote:
> > > I've tried to make this unprivileged mount thing as simple as
> > > possible, and no simpler. If we can make it even simpler, all the
> > > better.
> >
> > We are certainly much more complex then the code in plan9 (just
> > read throu
On Wed, 2007-04-18 at 16:03 +0200, Miklos Szeredi wrote:
> > Don't forget that almost all mount flags are per-superblock. How are you
> > planning on dealing with the case that one user mounts a filesystem
> > read-only, while another is trying to mount the same one read-write?
>
> Yeah, I forgot,
On Wed, 2007-04-18 at 16:01 +0100, Christoph Hellwig wrote:
> I suspect the right answer here is to make nfs mount handling smarter.
> The way mounting works the filesystem is allowed to choose whether it
> can re-used a superblock or needs a new one. In the NFS case we probably
> want to allow mu
On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> Start the reclaimer thread using kthread_run instead
> of a combination of kernel_thread and daemonize.
> The small amount of signal handling code is also removed
> as it makes no sense an
On Thu, 2007-04-19 at 01:59 -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> To start the nfsv4-delegreturn thread this patch uses
> kthread_run instead of a combination of kernel_thread
> and daemonize.
>
> In addition allow_signal(SIGKILL) is removed from
> the
On Thu, 2007-04-19 at 01:59 -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> Cc: Neil Brown <[EMAIL PROTECTED]>
> Cc: Trond Myklebust <[EMAIL PROTECTED]>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
On Thu, 2007-04-19 at 13:20 -0600, Eric W. Biederman wrote:
> Trond Myklebust <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
> >> From: Eric W. Biederman <[EMAIL PROTECTED]>
> >>
> >> Start the r
On Thu, 2007-04-19 at 14:40 -0700, Andrew Morton wrote:
> Using signals to communicate with kernel threads is fairly unpleasant, IMO.
> We have much simpler, faster and more idiomatic ways of communicating
> between threads in-kernel and there are better ways in which userspace can
> communicate wi
On Fri, 2007-05-18 at 14:04 +0400, Pavel Emelianov wrote:
> This includes /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes
> entries.
>
> Both need to show the header and use the list_head.
>
> Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
Acked-by: Trond Myk
On Wed, 2007-08-29 at 14:52 +0100, Christoph Hellwig wrote:
> On Wed, Aug 29, 2007 at 05:36:24PM +0400, Pavel Emelyanov wrote:
> > Pid namespaces make it dangerous to use pid and tgid values
> > when run in some namespace. The struct pid itself is going
> > to be the only way for working with task
On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
> When the process is blocked on mandatory lock and someone changes
> the inode's permissions, so that the lock is no longer mandatory,
> nobody wakes up the blocked process, but probably should.
Please explain in more detail why we need t
On Mon, 2007-09-17 at 18:16 +0400, Pavel Emelyanov wrote:
> Trond Myklebust wrote:
> > On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
> >> When the process is blocked on mandatory lock and someone changes
> >> the inode's permissions, so that
Trond
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> Cc: Trond Myklebust <[EMAIL PROTECTED]>
>
> ---
>
> fs/nfs/file.c |3 +--
> 1 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
> index 73ddd2e.
On Tue, 2007-09-18 at 10:20 +0400, Pavel Emelyanov wrote:
> Trond Myklebust wrote:
> > On Mon, 2007-09-17 at 11:57 +0400, Pavel Emelyanov wrote:
> >> The __mandatory_lock(inode) macro makes the same check, but
> >> makes the code more readable.
> >
> > Cou
On Tue, 2007-09-18 at 11:19 -0400, J. Bruce Fields wrote:
> Maybe this should be documented, e.g. in fcntl(2). I'm not sure exactly
> what we'd say--we probably don't want to commit to the current behavior.
> Maybe something like "behavior is undefined when setting or clearing
> mandatory locking
On Tue, 2007-09-18 at 12:52 -0400, J. Bruce Fields wrote:
> On Tue, Sep 18, 2007 at 12:14:55PM -0400, Trond Myklebust wrote:
> > Note also that strictly speaking, we're not even compliant with the
> > System V behaviour on read() and write(). See:
> >
> >
On Wed, 2007-09-19 at 14:07 -0400, J. Bruce Fields wrote:
> On Tue, Sep 18, 2007 at 10:36:32AM +0400, Pavel Emelyanov wrote:
> > J. Bruce Fields wrote:
> > > I would also prefer a locking scheme that didn't rely on the BKL. That
> > > said, except for this race:
> >
> > I would as well :) But I d
On Fri, 2007-09-21 at 13:13 +0400, Vitaliy Gusev wrote:
> Hello.
>
> Tested kernels: 2.6.18, 2.6.22, 2.6.23-rc2
>
> Steps to reproduce: Suppose that we have mounted some directory from nfs v3
> server with default options. Also we have the two directories in this
> mountpoint and each director
On Tue, 2010-03-02 at 14:48 +0100, Peter Zijlstra wrote:
> unsigned long reclaimable_pages(cgroup)
> {
> if (mem_cgroup_has_dirty_limit(cgroup))
> return mem_cgroup_page_stat(MEMCG_NR_RECLAIM_PAGES);
>
> return global_page_state(NR_FILE_DIRTY) +
> global_page_state(NR_NFS_UNSTABLE);
>
_clnt4 = NULL;
> + }
> + shutdown = !rpcb_users;
> + spin_unlock(&rpcb_clnt_lock);
> +
> + if (shutdown) {
> + /*
> + * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
> + */
> + if (clnt4)
On Tue, 2011-10-25 at 16:41 +0400, Stanislav Kinsbursky wrote:
> 25.10.2011 15:16, Trond Myklebust пишет:
> > On Tue, 2011-10-25 at 14:16 +0300, Stanislav Kinsbursky wrote:
> >> v6:
> >> 1) added write memory barrier to rpcb_set_local to make sure, that rpcbind
>
to happen? When inserting
> >> > > kernel modules or when user issues
> >> > mount command?
> >> > >
> >> >
> >> > When user issues mount command.
> >> > Kernel mounts of PipeFS has been removed with all these patch sets
On Tue, 2011-11-29 at 23:30 +0800, Peng Tao wrote:
> On Tue, Nov 29, 2011 at 11:18 PM, Trond Myklebust
> wrote:
> > On Tue, 2011-11-29 at 23:10 +0800, Peng Tao wrote:
> >> On Tue, Nov 29, 2011 at 9:35 PM, Myklebust, Trond
> >> wrote:
> >> >> -
On Tue, 2011-11-29 at 11:42 -0500, J. Bruce Fields wrote:
> On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
> > I mean that I'm perfectly entitled to do
> >
> > 'modprobe -r blocklayoutdriver'
> >
> > and when I do that, then
>d_inode)->pipe, &msg) < 0) {
Needs a rebase: the above doesn't apply...
> remove_wait_queue(&bl_wq, &wq);
> goto out;
> }
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
, S_IFIFO | mode, i_fop, private);
> - if (err) {
> - kfree(pipe);
> + if (err)
> return err;
> - }
> rpci = RPC_I(dentry->d_inode);
> rpci->private = private;
> rpci->pipe = pipe;
> - rpci->pipe->fl
; namespace context.
>
> Signed-off-by: Stanislav Kinsbursky
This doesn't seem to integrate with any of your patch series, and
conflicts with everything that touches netns.h, for instance...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
fs/nfs/nfs.ko] undefined!
ERROR: "nfs_idmap_quit" [fs/nfs/nfs.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2
if CONFIG_NFS_V4 is not defined.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@n
|1
> fs/nfs/netns.h |1
> include/linux/sunrpc/rpc_pipe_fs.h |2
> net/sunrpc/rpc_pipe.c | 21 -----
> 8 files changed, 137 insertions(+), 57 deletions(-)
These patches need rebasi
On Fri, 2011-12-30 at 17:55 -0500, Trond Myklebust wrote:
> On Tue, 2011-11-29 at 13:10 +0300, Stanislav Kinsbursky wrote:
> > This patch set was created in context of clone of git
> > branch: git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git.
> > tag: v3.1
> >
&g
On Tue, 2012-01-10 at 16:58 +0400, Stanislav Kinsbursky wrote:
> 06.01.2012 00:58, Trond Myklebust пишет:
> > The second problem that was highlighted was the fact that as they stand
> > today, these patchsets do not allow for bisection. When we hit the Oops,
> > I had Brya
t some testing to make sure that we don't
hit it again...
> BTW, it looks like that in last 2 days I've sent all updates to the issues
> you
> pointed out. If not, please, ping me once more.
I'm in the process of reviewing it right now.
Cheers
Trond
--
Trond
lock);
> if (ret)
> goto out_remove;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Trond Mykleb
On Wed, 2012-01-11 at 13:33 -0500, Trond Myklebust wrote:
> On Tue, 2012-01-10 at 17:04 +0400, Stanislav Kinsbursky wrote:
> > This is a cleanup patch. We don't need this reference anymore, because
> > blocklayout pipes dentries now creates and destroys in per-net operat
removed
The patches look good, and I've applied them for now in my 'devel'
branch so we can test them, but I'd like to get an Ack/Nack from Bruce
before committing to merging them.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netap
; Maybe they are in your repo, Bruce?
>
> Everything that I had from you is in -rc1 now.
>
> --b.
I can carry these patches if you like. They don't seem to conflict with
anything already in my repository.
--
Trond Myklebust
Linux NFS client maintai
PL(svc_sock_update_bufs);
I'm assuming that Bruce will prefer to carry this, since it is
completely orthogonal to the net namespace patchsets.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
54 matches
Mail list logo
