On Fri, Jan 10, 2014 at 12:14:34PM -0600, Ben Myers wrote:
> > What's really needed there to make XFS behave more similar to everyone
> > else is a way for the filesystem to say: "I can't actually free this
> > inode right now, but I'll come back to you later".
>
> This test might read something l
Christoph,
On Fri, Jan 10, 2014 at 01:31:48AM -0800, Christoph Hellwig wrote:
> On Fri, Jan 10, 2014 at 12:06:42AM +, Al Viro wrote:
> > Check what XFS is doing ;-/ That's where those call_rcu() have come from.
> > Sure, we can separate the simple "just do call_rcu(...->free_inode)" case
> >
On Fri, Jan 10, 2014 at 12:06:42AM +, Al Viro wrote:
> Check what XFS is doing ;-/ That's where those call_rcu() have come from.
> Sure, we can separate the simple "just do call_rcu(...->free_inode)" case
> and hit it whenever full ->free_inode is there and ->destroy_inode isn't.
> Not too pre
On Fri, 10 Jan 2014, Linus Torvalds wrote:
> > There's an extra source of headache, BTW - what about the "LSM stacking"
> > crowd and their plans?
>
> LSM stacking is a pipedream right now anyway, isn't it? It's been
> talked about for years and years, I've never seen a patch-set that is
> even
On Thu, Jan 09, 2014 at 06:59:07PM -0500, Steven Rostedt wrote:
> On Thu, 9 Jan 2014 15:45:37 -0800
> "Paul E. McKenney" wrote:
>
> > > static void inode_free_security(struct inode *inode)
> > > {
> > > struct inode_security_struct *isec = inode->i_security;
> > > @@ -244,8 +252,7 @@ static v
On Fri, Jan 10, 2014 at 8:06 AM, Al Viro wrote:
>
> Sure, we can separate the simple "just do call_rcu(...->free_inode)" case
> and hit it whenever full ->free_inode is there and ->destroy_inode isn't.
> Not too pretty, but removal of tons of boilerplate might be worth doing
> that anyway.
Yeah.
On Fri, Jan 10, 2014 at 12:06:42AM +, Al Viro wrote:
> and hit it whenever full ->free_inode is there and ->destroy_inode isn't.
Grr... "whenever ->free_inode is there and full ->destroy_inode isn't".
Apologies for sloppy editing...
--
To unsubscribe from this list: send the line "unsubscribe
On Fri, Jan 10, 2014 at 07:53:41AM +0800, Linus Torvalds wrote:
> On Fri, Jan 10, 2014 at 7:37 AM, Eric Paris wrote:
> >
> > but at least from an SELinux PoV, I think it's quick and easy, but wrong
> > for maintainability...
>
> Yeah, it's a hack, and it's wrong, and we should figure out how to d
On Thu, 9 Jan 2014 15:45:37 -0800
"Paul E. McKenney" wrote:
> > static void inode_free_security(struct inode *inode)
> > {
> > struct inode_security_struct *isec = inode->i_security;
> > @@ -244,8 +252,7 @@ static void inode_free_security(struct i
> > list_del_init(&isec->list);
On Fri, Jan 10, 2014 at 7:37 AM, Eric Paris wrote:
>
> but at least from an SELinux PoV, I think it's quick and easy, but wrong
> for maintainability...
Yeah, it's a hack, and it's wrong, and we should figure out how to do
it right. Likely we should just tie the lifetime of the i_security
member
On Thu, 09 Jan 2014 18:37:06 -0500
Eric Paris wrote:
> > Oh wait, you said not to clear the member. Thus, the patch would look
> > like this:
> >
> > Signed-off-by: Steven Rostedt
>
> SMACK also needs this change somehow in smack_inode_free_security()
>
> but at least from an SELinux PoV, I
On Thu, Jan 09, 2014 at 06:27:56PM -0500, Steven Rostedt wrote:
> On Thu, 9 Jan 2014 18:25:23 -0500
> Steven Rostedt wrote:
>
> > On Fri, 10 Jan 2014 06:41:03 +0800
> > Linus Torvalds wrote:
> >
> > > I think the sane short term fix is to make the kfree() of the i_security
> > > member be a rcu
On Thu, 2014-01-09 at 18:27 -0500, Steven Rostedt wrote:
> On Thu, 9 Jan 2014 18:25:23 -0500
> Steven Rostedt wrote:
>
> > On Fri, 10 Jan 2014 06:41:03 +0800
> > Linus Torvalds wrote:
> >
> > > I think the sane short term fix is to make the kfree() of the i_security
> > > member be a rcu free,
On Thu, 9 Jan 2014 18:25:23 -0500
Steven Rostedt wrote:
> On Fri, 10 Jan 2014 06:41:03 +0800
> Linus Torvalds wrote:
>
> > I think the sane short term fix is to make the kfree() of the i_security
> > member be a rcu free, and not clear the member.
>
> You mean my first patch?
>
> https://lkml
On Fri, 10 Jan 2014 06:41:03 +0800
Linus Torvalds wrote:
> I think the sane short term fix is to make the kfree() of the i_security
> member be a rcu free, and not clear the member.
You mean my first patch?
https://lkml.org/lkml/2014/1/9/349
-- Steve
>
> Not pretty, but should did this case.
On Fri, Jan 10, 2014 at 06:41:03AM +0800, Linus Torvalds wrote:
> I think the sane short term fix is to make the kfree() of the i_security
> member be a rcu free, and not clear the member.
Interesting use case. ;-)
Thanx, Paul
> Not pretty
On Thu, Jan 09, 2014 at 04:50:12PM -0500, Steven Rostedt wrote:
> > We'd then have to get rid of all the call_rcu() invocations in individual
> > filesystems' destroy_inode methods, but that doesn't sound like a bad
> > thing to me.
Check what e.g. XFS is doing...
> Which is another reason that
On Thu, 9 Jan 2014 14:42:39 -0700
Matthew Wilcox wrote:
> On Thu, Jan 09, 2014 at 04:27:31PM -0500, Steven Rostedt wrote:
> > Note, the crash came from stressing the deletion and reading of debugfs
> > files. I was not able to recreate this via normal files. But I'm not
> > sure they are safe. It
On Thu, Jan 09, 2014 at 04:27:31PM -0500, Steven Rostedt wrote:
> Note, the crash came from stressing the deletion and reading of debugfs
> files. I was not able to recreate this via normal files. But I'm not
> sure they are safe. It may just be that the race window is much harder
> to hit.
But "n
While running stress tests on adding and deleting ftrace instances I
hit this bug:
BUG: unable to handle kernel NULL pointer dereference at 0020
IP: [] selinux_inode_permission+0x85/0x160
PGD 63681067 PUD 7ddbe067 PMD 0
Oops: [#1] PREEMPT
CPU: 0 PID: 5634 Comm: ftrace-test-mki
20 matches
Mail list logo
