linux-kernel - Re: [PATCH] cifs: Add information about noserverino

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101209070952.24793c23@barsoom.rdu.redhat.com>
Date:	Thu, 9 Dec 2010 07:09:52 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Suresh Jayaraman <sjayaraman@...e.de>
Cc:	Bernhard Walle <bernhard@...lle.de>, sfrench@...ba.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cifs: Add information about noserverino

On Thu, 09 Dec 2010 17:10:28 +0530
Suresh Jayaraman <sjayaraman@...e.de> wrote:

> On 12/06/2010 09:08 PM, Jeff Layton wrote:
> > On Mon, 06 Dec 2010 16:35:06 +0100
> > Bernhard Walle <bernhard@...lle.de> wrote:
> > 
> >>
> >> Zitat von Jeff Layton <jlayton@...hat.com>:
> >>
> >>>
> >>> I'm still not sure I like this patch however. It potentially means a
> >>> lot of printk spam since these things have no ratelimiting. It also
> >>> doesn't tell me anything about which server might be giving me grief.
> >>>
> >>> Maybe this should be turned into a cFYI?
> >>
> >> Well, if I see it in the kernel log, it doesn't matter if it's info or
> >> something else.
> >>
> >>> The bottom line though is that running 32-bit applications that were
> >>> built without -D_FILE_OFFSET_BITS=64 on a 64-bit kernel is a very bad
> >>> idea. It would be nice to be able to alert users that things aren't
> >>> working the way they expect, but I'm not sure this is the right place
> >>> to do that.
> >>
> >> Well, but there *are* such application (in my case it was Softmaker Office
> >> which is a proprietary word processor) and it's quite nice if you know
> >> how you can workaround it when you encounter such a problem. That's all.
> >>
> > 
> > Sure...but this problem is not limited to CIFS. Many modern filesystems
> > use 64-bit inodes. Running this application on XFS or NFS for instance
> > is likely to give you the same trouble. You just hit it on CIFS because
> > the server happened to give you a very large inode number.
> > 
> > If we're going to add printk's for this situation, it probably ought to
> > be in a more generic place.
> > 
> 
> By generic place, did you mean at the VFS level? I think at VFS level,
> there is little information about the Server or underlying fs and this
> information doesn't seem too critical that VFS should warn/care much about.
> 
> May be sticking to a cFYI along with Server detail is a good idea?
> 
My poing was mainly that there's nothing special about CIFS in this
regard, other than the fact that servers regularly send us inodes that
are larger than 2^32. Why should we do this for cifs but not for nfs,
xfs, ext4, etc?

The filldir function gets a dentry as an argument, so it could
reasonably generate a printk for this. I'm also not keen on
the printk recommending noserverino for this. That has its own
drawbacks.

A cFYI for this sort of thing seems reasonable however.

-- 
Jeff Layton <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/