From: Andrew Morton <akpm@linux-foundation.org>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>,
Randy Dunlap <rdunlap@infradead.org>,
David Rientjes <rientjes@google.com>,
James Morris <jmorris@namei.org>, axboe <axboe@kernel.dk>,
Dmitry Kasatkin <dmitry.kasatkin@intel.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
linux-next <linux-next@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] block: fix part_pack_uuid() build error
Date: Mon, 25 Feb 2013 15:18:27 -0800 [thread overview]
Message-ID: <20130225151827.36ecb447.akpm@linux-foundation.org> (raw)
In-Reply-To: <20130225151638.bd40807c.akpm@linux-foundation.org>
On Mon, 25 Feb 2013 15:16:38 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sun, 24 Feb 2013 10:15:44 -0500
> Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>
> > Fix a build error when CONFIG_BLOCK is not enabled, by defining
> > a wrapper called blk_part_pack_uuid(). The wrapper returns
> > -EINVAL, when CONFIG_BLOCK is not defined.
> >
> > security/integrity/ima/ima_policy.c:538:4: error: implicit declaration
> > of function 'part_pack_uuid' [-Werror=implicit-function-declaration]
> >
> > ...
> >
> > diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> > index b27535a..399433a 100644
> > --- a/security/integrity/ima/ima_policy.c
> > +++ b/security/integrity/ima/ima_policy.c
> > ima_log_string(ab, "fsuuid", args[0].from);
> >
> > if (memchr_inv(entry->fsuuid, 0x00,
> > - sizeof(entry->fsuuid))) {
> > + sizeof(entry->fsuuid))) {
> > result = -EINVAL;
> > break;
> > }
> >
> > - part_pack_uuid(args[0].from, entry->fsuuid);
> > - entry->flags |= IMA_FSUUID;
> > - result = 0;
> > + result = blk_part_pack_uuid(args[0].from,
> > + entry->fsuuid);
> > + if (!result)
> > + entry->flags |= IMA_FSUUID;
>
> This will cause ima_parse_rule() to newly return -EINVAL if the fsuuid=
> option is used when CONFIG_BLOCK=n.
>
> This functional change was not changelogged, forcing me to ask: was it
> deliberate or was it accidental?
>
> And it is a non-back-compatible change, introducing some potential to
> break existing userspace code. Is the risk considered acceptable? If
> so, why?
ah, I see that the fsuuid stuff is new in 3.9, so there are no issues.
prev parent reply other threads:[~2013-02-25 23:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-24 15:15 [PATCH] block: fix part_pack_uuid() build error Mimi Zohar
2013-02-24 18:29 ` David Rientjes
2013-02-24 20:28 ` Randy Dunlap
2013-02-25 2:59 ` James Morris
2013-02-25 23:16 ` Andrew Morton
2013-02-25 23:18 ` Andrew Morton [this message]
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=20130225151827.36ecb447.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=dmitry.kasatkin@intel.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=zohar@linux.vnet.ibm.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.