From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH] block: fix part_pack_uuid() build error Date: Mon, 25 Feb 2013 15:16:38 -0800 Message-ID: <20130225151638.bd40807c.akpm@linux-foundation.org> References: <1361718944.2908.49.camel@falcor1.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from mail.linuxfoundation.org ([140.211.169.12]:55911 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754148Ab3BYXQk (ORCPT ); Mon, 25 Feb 2013 18:16:40 -0500 In-Reply-To: <1361718944.2908.49.camel@falcor1.watson.ibm.com> Sender: linux-next-owner@vger.kernel.org List-ID: To: Mimi Zohar Cc: Randy Dunlap , David Rientjes , James Morris , axboe , Dmitry Kasatkin , linux-security-module , linux-next , linux-kernel On Sun, 24 Feb 2013 10:15:44 -0500 Mimi Zohar 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?