On Fri, May 22, 2015 at 5:13 PM, Sage Weil wrote:
> Hi Linus,
>
> Please pull the following fixes from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git
Nothing there.
Did you perhaps mean the "for-linus" branch?
Please fix whatever script it is you use that generates bad
On Wed, Dec 17, 2014 at 6:25 PM, Yan, Zheng wrote:
> my commit "ceph: add inline data to pagecache" incidentally adds
> fs/ceph/super.j.rej. please remove it from your branch. sorry for
> the inconvenience
I wish I hadn't pulled it so quickly, and could have fixed it up as
part of the merge co
On Tue, Feb 4, 2014 at 3:33 AM, Steven Whitehouse wrote:
>
> The other question that I have relating to that side of things, is why
> security_inode_permission() is called from __inode_permission() rather
> than from generic_permission() ? Maybe there is a good reason, but I
> can't immediately se
On Mon, Feb 3, 2014 at 2:40 PM, Al Viro wrote:
>
> Umm... Point, but that actually means that we get an extra pitfall for
> filesystem writers here. foo_permission() passes dentry (now that it
> has one) to foo_wank_a_lot(), with the latter using dentry->d_inode at
> some point...
I agree.
The
On Mon, Feb 3, 2014 at 1:59 PM, Al Viro wrote:
> On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
>
>> - err = vfs_mkdir(path.dentry->d_inode, dentry, mode);
>> + err = vfs_mkdir(path.dentry, dentry, mode);
>
> Pointless - path.dentry == dentry-&
On Mon, Feb 3, 2014 at 1:39 PM, Al Viro wrote:
>
> If we really have hardlinks, the result of permission check would better
> be a function of inode itself - as in, "if it gives different results
> for two pathnames reachable for the same user, we have a bug".
No. You're wrong.
EVEN ON A UNIX FI
On Mon, Feb 3, 2014 at 1:31 PM, Al Viro wrote:
>
> Yes, and...? CIFS also doesn't have hardlinks, so _there_ d_find_alias()
> is just fine.
Hmm? I'm pretty sure cifs can actually have hardlinks.
Linus
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the b
On Mon, Feb 3, 2014 at 1:19 PM, Al Viro wrote:
>
> Please, don't do that. Half of that is pointless (e.g. what you are
> doing with vfs_rmdir() - if anything, we could get rid of the first
> argument completely, it's always victim->d_parent->d_inode and we are
> holding enough locks for that to b
On Wed, Jan 29, 2014 at 11:54 PM, Christoph Hellwig wrote:
>
> For ->set_acl that's fairly easily doable and I actually had a version
> doing that to be able to convert 9p. But for ->get_acl the path walking
> caller didn't seem easily feasible. ->get_acl actually is an invention
> of yours, so
On Wed, Jan 29, 2014 at 8:37 AM, Ilya Dryomov wrote:
> From: Sage Weil
>
> The merge of 7221fe4c2 raced with upstream changes in the generic POSIX
> ACL code (2aeccbe95). Update Ceph to use the new helpers as well by
> dropping the now-generic functions and setting the set_acl inode op.
>
> Sign
On Tue, Jan 28, 2014 at 1:10 PM, Dave Jones wrote:
>
> This breaks the build for me.
It is my merge (Christoph's ACL changes came in today through the VFS
tree from Al).
I was doing the merges today on my laptop (I had jury duty yesterday
and today), and so I didn't do the allmodconfig build I w
On Mon, Aug 20, 2012 at 2:04 AM, Mel Gorman wrote:
>
> Can the following patch be tested please? It is reported to fix an fio
> regression that may be similar to what you are experiencing but has not
> been picked up yet.
Andrew, is this in your queue, or should I take this directly, or
what? It
On Fri, Jun 8, 2012 at 4:37 PM, Andrew Morton wrote:
>
> So how about open-coding the rcu_barrier() in btrfs and gfs2 for the
> non-inode caches (which is the appropriate place), and hand the inode
> cache over to the vfs for treatment (which is the appropriate place).
The thing is, none of the i
On Fri, Jun 8, 2012 at 3:23 PM, Al Viro wrote:
>
> Note that module unload is *not* a hot path - not on any even remotely sane
> use.
Actually, I think we've had distributions that basically did a "load
pretty much everything, and let God sort it out" approach to modules.
I know some people *have
On Fri, Jun 8, 2012 at 3:00 PM, Kirill A. Shutemov
wrote:
>
> IIUC, moving rcu_barrier() up should help, but I can't say that I fully
> understand SLAB_DESTROY_BY_RCU semantics.
.. hmm. I think you may be right. Even if we do move it up, we
probably shouldn't use it.
We don't even want SLAB_DEST
On Fri, Dec 10, 2010 at 10:05 AM, Trond Myklebust
wrote:
> Resending pull request after appending Chuck's fix for the nfs_umount() panic.
[ .. and other people have other similar pull requests - acpi, ceph,
cifs, xfs etc ]
Right now I'm traveling without access to my laptop to actually do
pulls.
16 matches
Mail list logo
