From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-security-module@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de, Subodh Nijsure <snijsure@grid-net.com>
Subject: Re: [PATCH RFC 4/5] UBIFS: Add security.* XATTR support for the UBIFS
Date: Fri, 22 Feb 2013 09:10:37 +0200 [thread overview]
Message-ID: <1361517037.2734.145.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <1360750998-15191-5-git-send-email-mkl@pengutronix.de>
OK, the lockdep warnings clearly tell the reason:
CPU0 CPU1
---- ----
lock(&ui->ui_mutex);
lock(&sb->s_type->i_mutex_key#10);
lock(&ui->ui_mutex);
lock(&sb->s_type->i_mutex_key#10);
And then there are 2 tracebacks which are useful and show that you
unnecessarily initialize the inode security contenxt whil holding the
parent inode lock. I think you do not need to hold that lock. Move the
initialization out of the protected section.
See below my suggestions.
On Wed, 2013-02-13 at 11:23 +0100, Marc Kleine-Budde wrote:
> @@ -280,6 +280,10 @@ static int ubifs_create(struct inode *dir, struct dentry *dentry, umode_t mode,
> err = ubifs_jnl_update(c, dir, &dentry->d_name, inode, 0, 0);
> if (err)
> goto out_cancel;
> +
> + err = ubifs_init_security(dir, inode, &dentry->d_name);
> + if (err)
> + goto out_cancel;
> mutex_unlock(&dir_ui->ui_mutex);
Can you move ubifs_init_security() up to before
'mutex_lock(&dir_ui->ui_mutex)'
> @@ -742,6 +746,10 @@ static int ubifs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode)
...
> + err = ubifs_init_security(dir, inode, &dentry->d_name);
> + if (err)
> + goto out_cancel;
> mutex_unlock(&dir_ui->ui_mutex);
Ditto.
> @@ -818,6 +826,10 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry,
...
> + err = ubifs_init_security(dir, inode, &dentry->d_name);
> + if (err)
> + goto out_cancel;
> mutex_unlock(&dir_ui->ui_mutex);
Ditto.
> @@ -894,6 +906,10 @@ static int ubifs_symlink(struct inode *dir, struct dentry *dentry,
...
> + err = ubifs_init_security(dir, inode, &dentry->d_name);
> + if (err)
> + goto out_cancel;
> mutex_unlock(&dir_ui->ui_mutex);
Ditto.
> +int ubifs_init_security(struct inode *dentry, struct inode *inode,
> + const struct qstr *qstr)
> +{
> + int err;
> +
> + mutex_lock(&inode->i_mutex);
> + err = security_inode_init_security(inode, dentry, qstr,
> + &ubifs_initxattrs, 0);
> + mutex_unlock(&inode->i_mutex);
I did not verify, but I doubt that you need i_mutex here, because you
only call this function when you create an inode, before it becomes
visible to VFS. Please, double-check this.
Thanks!
--
Best Regards,
Artem Bityutskiy
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-mtd@lists.infradead.org, kernel@pengutronix.de,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Subodh Nijsure <snijsure@grid-net.com>
Subject: Re: [PATCH RFC 4/5] UBIFS: Add security.* XATTR support for the UBIFS
Date: Fri, 22 Feb 2013 09:10:37 +0200 [thread overview]
Message-ID: <1361517037.2734.145.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <1360750998-15191-5-git-send-email-mkl@pengutronix.de>
OK, the lockdep warnings clearly tell the reason:
CPU0 CPU1
---- ----
lock(&ui->ui_mutex);
lock(&sb->s_type->i_mutex_key#10);
lock(&ui->ui_mutex);
lock(&sb->s_type->i_mutex_key#10);
And then there are 2 tracebacks which are useful and show that you
unnecessarily initialize the inode security contenxt whil holding the
parent inode lock. I think you do not need to hold that lock. Move the
initialization out of the protected section.
See below my suggestions.
On Wed, 2013-02-13 at 11:23 +0100, Marc Kleine-Budde wrote:
> @@ -280,6 +280,10 @@ static int ubifs_create(struct inode *dir, struct dentry *dentry, umode_t mode,
> err = ubifs_jnl_update(c, dir, &dentry->d_name, inode, 0, 0);
> if (err)
> goto out_cancel;
> +
> + err = ubifs_init_security(dir, inode, &dentry->d_name);
> + if (err)
> + goto out_cancel;
> mutex_unlock(&dir_ui->ui_mutex);
Can you move ubifs_init_security() up to before
'mutex_lock(&dir_ui->ui_mutex)'
> @@ -742,6 +746,10 @@ static int ubifs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode)
...
> + err = ubifs_init_security(dir, inode, &dentry->d_name);
> + if (err)
> + goto out_cancel;
> mutex_unlock(&dir_ui->ui_mutex);
Ditto.
> @@ -818,6 +826,10 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry,
...
> + err = ubifs_init_security(dir, inode, &dentry->d_name);
> + if (err)
> + goto out_cancel;
> mutex_unlock(&dir_ui->ui_mutex);
Ditto.
> @@ -894,6 +906,10 @@ static int ubifs_symlink(struct inode *dir, struct dentry *dentry,
...
> + err = ubifs_init_security(dir, inode, &dentry->d_name);
> + if (err)
> + goto out_cancel;
> mutex_unlock(&dir_ui->ui_mutex);
Ditto.
> +int ubifs_init_security(struct inode *dentry, struct inode *inode,
> + const struct qstr *qstr)
> +{
> + int err;
> +
> + mutex_lock(&inode->i_mutex);
> + err = security_inode_init_security(inode, dentry, qstr,
> + &ubifs_initxattrs, 0);
> + mutex_unlock(&inode->i_mutex);
I did not verify, but I doubt that you need i_mutex here, because you
only call this function when you create an inode, before it becomes
visible to VFS. Please, double-check this.
Thanks!
--
Best Regards,
Artem Bityutskiy
next prev parent reply other threads:[~2013-02-22 7:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 10:23 [RFC PATCH 0/5] UBIFS: improve xattr and add support for security.* XATTR Marc Kleine-Budde
2013-02-13 10:23 ` Marc Kleine-Budde
2013-02-13 10:23 ` [PATCH RFC 1/5] UBIFS: xattr: protect ui_size and data_len by ui_mutex Marc Kleine-Budde
2013-02-13 10:23 ` Marc Kleine-Budde
2013-02-14 7:23 ` Artem Bityutskiy
2013-02-14 7:23 ` Artem Bityutskiy
2013-02-14 11:57 ` Marc Kleine-Budde
2013-02-14 11:57 ` Marc Kleine-Budde
2013-02-13 10:23 ` [PATCH RFC 2/5] UBIFS: fix couple bugs in UBIFS extended attribute length calculation Marc Kleine-Budde
2013-02-13 10:23 ` Marc Kleine-Budde
2013-02-13 10:23 ` [PATCH RFC 3/5] UBIFS: Add xattr support for symlinks Marc Kleine-Budde
2013-02-13 10:23 ` Marc Kleine-Budde
2013-02-13 10:23 ` [PATCH RFC 4/5] UBIFS: Add security.* XATTR support for the UBIFS Marc Kleine-Budde
2013-02-13 10:23 ` Marc Kleine-Budde
2013-02-14 7:28 ` Artem Bityutskiy
2013-02-14 7:28 ` Artem Bityutskiy
2013-02-14 12:05 ` Marc Kleine-Budde
2013-02-14 12:05 ` Marc Kleine-Budde
2013-02-22 7:10 ` Artem Bityutskiy [this message]
2013-02-22 7:10 ` Artem Bityutskiy
2013-02-13 10:23 ` [PATCH RFC 5/5] UBIFS: add ubifs_err() to print error reason Marc Kleine-Budde
2013-02-13 10:23 ` Marc Kleine-Budde
2013-02-14 7:29 ` Artem Bityutskiy
2013-02-14 7:29 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1361517037.2734.145.camel@sauron.fi.intel.com \
--to=artem.bityutskiy@linux.intel.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=snijsure@grid-net.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.