On Feb 7, 2008 12:25 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> and while I'm at it a lot of the non-DFS additions to cifs aren't quite
> up to standards for kernel code either, lots of useless braces, wierd
> coding style and ifdef mania.
Reducing "ifdef mania" would help (there are about
On Wed, Feb 06, 2008 at 04:08:58PM +0200, Rabeeh Khoury wrote:
> > >
> > > Exporting an XFS volume with kernel NFSD when real-time subvolume is
> > > enabled hangs the kernel.
> > >
> > > I'm using vanilla LK 2.6.22.7; first I create the XFS volume with
> two
> > > partitions of 20GB each with exte
On Feb 7, 2008 12:25 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 06, 2008 at 07:43:01AM -0600, Steve French wrote:
> > I only remember missing a loop unwinding on exit style comment of
> > yours that was not addressed in what got integrated. I will go back
> > through your notes
On Sun, Jan 20, 2008 at 09:58:59AM -0500, Oleg Drokin wrote:
> Hello!
>
> On Jan 18, 2008, at 6:07 PM, J. Bruce Fields wrote:
>
>> On Thu, Nov 29, 2007 at 02:41:57PM -0800, Marc Eshel wrote:
>>> The problem seems to be with the fact that the client and server are
>>> on
>>> the same machine. This
On Wed, Feb 06, 2008 at 07:43:01AM -0600, Steve French wrote:
> I only remember missing a loop unwinding on exit style comment of
> yours that was not addressed in what got integrated. I will go back
> through your notes again to see if I missed one.
- there's still all that CONFIG_CIFS_DFS_UPCA
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > > > think that would make a lot of sense anyway.
> > > >
> > > > Would it be as simple as tagging the inodes with capability sets? One
> > > > set for writing, or one eac
> On Tue, Feb 05, 2008 at 10:36:23PM +0100, Miklos Szeredi wrote:
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Add the following:
> >
> > /proc/sys/fs/types/${FS_TYPE}/usermount_safe
> >
>
>
> There is /proc/fs// already. Since it is file system specific
> shouldn't it go there ?
T
On Tue, Feb 05, 2008 at 10:36:23PM +0100, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add the following:
>
> /proc/sys/fs/types/${FS_TYPE}/usermount_safe
>
There is /proc/fs// already. Since it is file system specific
shouldn't it go there ?
-aneesh
-
To unsubscrib
On Thu 07-02-08 16:02:57, Rasmus Rohde wrote:
>
> > > Before posting the last and hopefully final patch I'd like to know what
> > > Jan says about open coding the lookup for ..
> > > It will mean a lot of code duplication and I think it makes good sense
> > > for udf_find_entry to be able to handl
> > Before posting the last and hopefully final patch I'd like to know what
> > Jan says about open coding the lookup for ..
> > It will mean a lot of code duplication and I think it makes good sense
> > for udf_find_entry to be able to handle ..
> Yes, I think opencoding it would really lead to
On Thu 07-02-08 08:06:37, Rasmus Rohde wrote:
> Ok - I have checked get_parent and it works as expected.
> I used the "Neil Brown"-test mentioned elsewhere in this thread and
> added a few printk's to make sure we actually got the code covered.
>
> > There's still a few trivial warnings from scrip
> > > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > > think that would make a lot of sense anyway.
> > >
> > > Would it be as simple as tagging the inodes with capability sets? One
> > > set for writing, or one each for reading and writing?
> >
> > Yes, or something
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > think that would make a lot of sense anyway.
> >
> > Would it be as simple as tagging the inodes with capability sets? One
> > set for writing, or one each for reading and wr
Chuck Lever <[EMAIL PROTECTED]> wrote:
> > @@ -95,12 +100,25 @@ struct nfs_server {
> > unsigned intacdirmin;
> > unsigned intacdirmax;
> > unsigned intnamelen;
> > + unsigned intoptions;/* extra options enabled by
> > mount */
> > Maybe sysctls just need to check capabilities, instead of uids. I
> > think that would make a lot of sense anyway.
>
> Would it be as simple as tagging the inodes with capability sets? One
> set for writing, or one each for reading and writing?
Yes, or something even simpler, like mapping t
15 matches
Mail list logo
