Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by Mimi Zohar
On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> > >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
> > >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> > >>>Stefan Berger <stefanb(a)linux.vnet.ibm.com> writes:
> > >>>
> > >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
> > >>>>
> > >>>>>My big question right now is can you implement Ted's suggested
> > >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
> > >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
> > >>>>
> > >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
> > >>>>
> > >>>The latter.
> > >>That case would prevent a container user from overriding the xattr
> > >>on the host. Is that what we want? For limiting the number of xattrs
> > >Not really. If the file is owned by a uid mapped into the container,
> > >then the container root can chown the file which will clear the file
> > >capability, after which he can set a new one. If the file is not
> > >owned by a uid mapped into the container, then container root could
> > >not set a filecap anyway.
> >
> > Let's say I installed a container where all files are signed and
> > thus have security.ima. Now for some reason I want to re-sign some
> > or all files inside that container. How would I do that ? Would I
> > need to get rid of security.ima first, possibly by copying each
> > file, deleting the original file, and renaming the copied file to
> > the original name, or should I just be able to write out a new
> > signature, thus creating security.ima@uid=1000 besides the
> > security.ima ?
> >
> > Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
If I'm understanding the discussion correctly, this isn't an issue for
layered copy on write filesystems, as each fs layer could have it's
own set of xattrs. The underlying and layered xattrs should be able
to co-exist. Use the layered xattr if it exists, but fall back to
using the underlying xattr if it doesn't.
The concern is with a shared filesystems. In that case, for IMA it
would make sense to support a native and a namespace xattr. If due to
xattr space limitations we have to limit the number of xattrs, then we
should limit it to two - a native and a namespace version, with a
"uid=" tag - first namespace gets permission to write the namespace
xattr. Again, like in the layered case, if the namespace xattr
doesn't exist, fall back to using the native xattr.
This allows most files to use the underlying xattrs, but allows a few
files to be re-signed inside the namespace, as needed. For the
layered filesystem case, this would allow mutable file hashes to be
written. (Unclear as to how shared filesystems would work in this
case.)
Mimi
4 years, 10 months
Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by Stefan Berger
On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb(a)linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr
>> on the host. Is that what we want? For limiting the number of xattrs
> Not really. If the file is owned by a uid mapped into the container,
> then the container root can chown the file which will clear the file
> capability, after which he can set a new one. If the file is not
> owned by a uid mapped into the container, then container root could
> not set a filecap anyway.
Let's say I installed a container where all files are signed and thus
have security.ima. Now for some reason I want to re-sign some or all
files inside that container. How would I do that ? Would I need to get
rid of security.ima first, possibly by copying each file, deleting the
original file, and renaming the copied file to the original name, or
should I just be able to write out a new signature, thus creating
security.ima@uid=1000 besides the security.ima ?
Stefan
4 years, 10 months
Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by Eric W. Biederman
"Serge E. Hallyn" <serge(a)hallyn.com> writes:
> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
>> >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):
>> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>> >>>Stefan Berger <stefanb(a)linux.vnet.ibm.com> writes:
>> >>>
>> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>> >>>>
>> >>>>>My big question right now is can you implement Ted's suggested
>> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?
>> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>> >>>>
>> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>> >>>>
>> >>>The latter.
>> >>That case would prevent a container user from overriding the xattr
>> >>on the host. Is that what we want? For limiting the number of xattrs
>> >Not really. If the file is owned by a uid mapped into the container,
>> >then the container root can chown the file which will clear the file
>> >capability, after which he can set a new one. If the file is not
>> >owned by a uid mapped into the container, then container root could
>> >not set a filecap anyway.
>>
>> Let's say I installed a container where all files are signed and
>> thus have security.ima. Now for some reason I want to re-sign some
>> or all files inside that container. How would I do that ? Would I
>> need to get rid of security.ima first, possibly by copying each
>> file, deleting the original file, and renaming the copied file to
>> the original name, or should I just be able to write out a new
>> signature, thus creating security.ima@uid=1000 besides the
>> security.ima ?
>>
>> Stefan
>
> Hi Mimi,
>
> what do you think makes most sense for IMA?
I am going to give my two cents since I have been thinking about this.
First I think this entire scheme plays hobs with the security.evm
attribute as security.evm needs to know the names of the xattrs to
protect.
I forget which attributes has a hash and what has a message
athentication code.
If there is an attribute with a simple file hash I think it only make
sense for the kernel to touch it, and I don't see any sense in having
multiples.
If there is an attribute with a message authentication code (roughly a
signed hash) it makes sense to have that to be tied to the kernel key
ring that controlls the keys. (Which probably means a per user
namespace thing at some point). But again pretty untouchable otherwise.
Which brings us to the semantic question of would it be nice to have
stacked IMA/EVM on the same file.
I really don't think we do. I think allowing multiple keys for
different part of trusting files is easy enough that we should have no
need to fight over which keys do which.
Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use
case I can think of for distributing a distribution image with ima/evm
xattrs will need to use asymmetric keys aka public/private keypairs so
that the originator of the content does not give away their private
keys.
Given that usefully we are talking about content that should be
connected to keys in one way or another I don't believe it even makes
sense at this point to attempt to use uids for dealing with ima and
evm content.
Further looking Serge's previous patch is 300 lines of code Setfan's
patch that provides the possibility of code resuse is 500 lines of code.
Increasingly it is looking to me that code reuse rather than concept
reuse is a false economy. The code does not get smaller. The semantic
differences make it problematic. Possibly to the problematic to the
point where significant pieces may not be reused. The format breaks
assumptions for other parts of the code like security.evm. The format
by multiple names instead of a single attribute requires more disk
access so is less efficient.
In short I am seeing more code that runs slower and is harder to
maintain. Please point out where I am wrong.
Eric
4 years, 10 months
Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by Eric W. Biederman
"Serge E. Hallyn" <serge(a)hallyn.com> writes:
> Quoting Eric W. Biederman (ebiederm(a)xmission.com):
>> Stefan Berger <stefanb(a)linux.vnet.ibm.com> writes:
>>
>> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
>> >> Theodore Ts'o <tytso(a)mit.edu> writes:
>> >>
>> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>> >>>> The concise summary:
>> >>>>
>> >>>> Today we have the xattr security.capable that holds a set of
>> >>>> capabilities that an application gains when executed. AKA setuid root exec
>> >>>> without actually being setuid root.
>> >>>>
>> >>>> User namespaces have the concept of capabilities that are not global but
>> >>>> are limited to their user namespace. We do not currently have
>> >>>> filesystem support for this concept.
>> >>> So correct me if I am wrong; in general, there will only be one
>> >>> variant of the form:
>> >>>
>> >>> security.foo@uid=15000
>> >>>
>> >>> It's not like there will be:
>> >>>
>> >>> security.foo@uid=1000
>> >>> security.foo@uid=2000
>> >>>
>> >>> Except.... if you have an Distribution root directory which is shared
>> >>> by many containers, you would need to put the xattrs in the overlay
>> >>> inodes. Worse, each time you launch a new container, with a new
>> >>> subuid allocation, you will have to iterate over all files with
>> >>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> >>> So that's actually a bit of a disaster.
>> >>>
>> >>> So for distribution overlays, you will need to do things a different
>> >>> way, which is to map the distro subdirectory so you know that the
>> >>> capability with the global uid 0 should be used for the container
>> >>> "root" uid, right?
>> >>>
>> >>> So this hack of using security.foo@uid=1000 is *only* useful when the
>> >>> subcontainer root wants to create the privileged executable. You
>> >>> still have to do things the other way.
>> >>>
>> >>> So can we make perhaps the assertion that *either*:
>> >>>
>> >>> security.foo
>> >>>
>> >>> exists, *or*
>> >>>
>> >>> security.foo@uid=BAR
>> >>>
>> >>> exists, but never both? And there BAR is exclusive to only one
>> >>> instances?
>> >>>
>> >>> Otherwise, I suspect that the architecture is going to turn around and
>> >>> bite us in the *ss eventually, because someone will want to do
>> >>> something crazy and the solution will not be scalable.
>> >> Yep. That is what it looks like from here.
>> >>
>> >> Which is why I asked the question about scalability of the xattr
>> >> implementations. It looks like trying to accomodate the general
>> >> case just gets us in trouble, and sets unrealistic expectations.
>> >>
>> >> Which strongly suggests that Serge's previous version that
>> >> just reved the format of security.capable so that a uid field could
>> >> be added is likely to be the better approach.
>> >>
>> >> I want to see what Serge and Stefan have to say but the case looks
>> >> pretty clear cut at the moment.
>
> I'm fine with that. Now, we'll be doing the enforcement at xattr
> write time, meaning someone *can* come up with an fs image with >1
> such xattrs. Which is *fine*, I believe, it won't break anything
> security-wise, and our goal is only to stop users from thinking it
> is legitimate two write multiple such xattrs, so that they don't later
> bug the fs folks like Ted saying "hey why can't I write 1000 of these,
> I think that's a bug."
>
> So at xattr write time,
>
> 1. if there is already an xattr, and it is either the global
> non-namespaced xattr, or it has kuid=X where X is the kuid
> mapped to root in a parent of the container, then we refuse
> the write
> 2. if there is already an xattr, and it is for a kuid=X where
> X is mapped into the container, then we overwrite the existing
> xattr.
>
> At read/use time, we use the rules we have now.
>
> Does that seem reasonable?
That sounds like it would keep us to one xattr of any given type so yes.
It occurs to me while I am writing this that this is also important
for ima/evm. There is an xattr that has a hash of all of the other
security relevant xattrs. Without a limit on the number of xattrs
calculating that security xattr could become time prohibitive.
Eric
4 years, 10 months
Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by James Morris
On Wed, 12 Jul 2017, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm(a)xmission.com):
> > Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes:
> > > Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com>
> > > Signed-off-by: Serge Hallyn <serge(a)hallyn.com>
> > > Reviewed-by: Serge Hallyn <serge(a)hallyn.com>
> >
> > It doesn't look like this is coming through Serge so I don't see how
> > the Signed-off-by tag is legtimate.
>
> This is mostly explained by the fact that there have been a *lot* of
> changes, many of them discussed in private emails.
Please try and keep technical discussions public or at least document them
when reposting the patches.
--
James Morris
<jmorris(a)namei.org>
4 years, 10 months
Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by Stefan Berger
On 07/11/2017 11:45 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb(a)linux.vnet.ibm.com):
>> +/*
>> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user namespaces
>> + * or determine needed size for attribute list
>> + * in case size == 0
>> + *
>> + * In a user namespace we do not present all extended attributes to the
>> + * user. We filter out those that are in the list of userns supported xattr.
>> + * Besides that we filter out those with @uid=<uid> when there is no mapping
>> + * for that uid in the current user namespace.
>> + *
>> + * @list: list of 0-byte separated xattr names
>> + * @size: the size of the list; may be 0 to determine needed list size
>> + * @list_maxlen: allocated buffer size of list
>> + */
>> +static ssize_t
>> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
>> +{
>> + char *nlist = NULL;
>> + size_t s_off, len, nlen;
>> + ssize_t d_off;
>> + char *name, *newname;
>> +
>> + if (!list || size < 0 || current_user_ns() == &init_user_ns)
>> + return size;
>> +
>> + if (size) {
>> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
>> + if (!nlist)
>> + return -ENOMEM;
>> + }
>> +
>> + s_off = d_off = 0;
>> + while (s_off < size || size == 0) {
>> + name = &list[s_off];
>> +
>> + len = strlen(name);
>> + if (!len)
>> + break;
>> +
>> + if (xattr_is_userns_supported(name, false) >= 0)
>> + newname = name;
>> + else {
>> + newname = xattr_rewrite_userns_xattr(name);
> Why are you doing this here? If we get here it means that
> xattr_is_userns_supported() returned < 0, meaning name is
> not userns-supported. So xattr_rewrite_userns_xattr() will
> just return name. Am I missing something?
xattr_is_userns_support(name, false) does a _full string match_ rather
than a prefix match and will only return >= 0 for security.capability.
This case handles the hosts's security.capability which 'shines
through' for read and needs to be listed. Only in this case we set
newname=name.
In the else branch we handle security.capability@uid=1000 and rewrite
that to security.capability for root mapping to uid=1000.
>
>> + if (IS_ERR(newname)) {
>> + d_off = PTR_ERR(newname);
>> + goto out_free;
>> + }
>> + }
>> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {
> Now here, if name was recalculated to @newname, and @newname is
> found in the nlist, that should raise an error right? Something
> fishy is going on?
If security.capability is set on a file but the container doesn't have
security.capability@uid=1000, we still need to list the former here.
However, we end up with duplicates if security.capability is there and
security.capability@uid=1000 is also there and root is mapped to
uid=1000. Both would be shown as security.capability inside the
container. In this case we need to filter.
I think the code is correct. More problematic is a memory leak in the
error case. Will fix that.
>
>> + nlen = strlen(newname);
>> +
>> + if (nlist) {
>> + if (nlen + 1 > list_maxlen)
> d_off needs to be set to -ERANGE here.
Fixed.
>
>> + break;
>> + strcpy(&nlist[d_off], newname);
>> + }
>> +
>> + d_off += nlen + 1;
>> + if (newname != name)
>> + kfree(newname);
>> + }
>> + s_off += len + 1;
>> + }
>> + if (nlist)
>> + memcpy(list, nlist, d_off);
>> +out_free:
>> + kfree(nlist);
>> +
>> + return d_off;
>> +}
4 years, 10 months
[x86/time] f61a8e12b5: ACPI_Error:Table[DMAR]is_not_invalidated_during_early_boot_stage(#/tbxface-#)
by kernel test robot
FYI, we noticed the following commit:
commit: f61a8e12b5972879f8decfe059e54c813dc4416b ("x86/time: Initialize interrupt mode behind timer init")
url: https://github.com/0day-ci/linux/commits/Dou-Liyang/Unify-the-interrupt-d...
in testcase: will-it-scale
with following parameters:
nr_task: 50%
mode: process
test: writeseek3
cpufreq_governor: performance
test-description: Will It Scale takes a testcase and runs it from 1 through to n parallel copies to see if the testcase will scale. It builds both a process and threads based test in order to see any differences between the two.
test-url: https://github.com/antonblanchard/will-it-scale
on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 64G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+-------------------------------------------------------------------------------+------------+------------+
| | d021c73124 | f61a8e12b5 |
+-------------------------------------------------------------------------------+------------+------------+
| boot_successes | 0 | 6 |
| boot_failures | 2 | 4 |
| invoked_oom-killer:gfp_mask=0x | 2 | |
| Mem-Info | 2 | |
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 2 | |
| ACPI_Error:Table[DMAR]is_not_invalidated_during_early_boot_stage(#/tbxface-#) | 0 | 4 |
| WARNING:at_mm/early_ioremap.c:#check_early_ioremap_leak | 0 | 4 |
+-------------------------------------------------------------------------------+------------+------------+
kern :info : [ 0.005000] tsc: Fast TSC calibration using PIT
kern :info : [ 0.006000] tsc: Detected 2194.957 MHz processor
kern :info : [ 0.007000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4389.91 BogoMIPS (lpj=2194957)
kern :info : [ 0.008002] pid_max: default: 90112 minimum: 704
kern :info : [ 0.009034] ACPI: Core revision 20170303
kern :err : [ 0.010002] ACPI Error: Table [DMAR] is not invalidated during early boot stage (20170303/tbxface-193)
kern :info : [ 0.125364] ACPI: 4 ACPI AML tables successfully acquired and loaded
kern :info : [ 0.126116] Security Framework initialized
kern :info : [ 0.127003] SELinux: Initializing.
kern :debug : [ 0.128012] SELinux: Starting in permissive mode
kern :info : [ 0.131850] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Kernel Test Robot
4 years, 10 months
Re: [LKP] [PATCH v2] xattr: Enable security.capability in user namespaces
by Stefan Berger
On 07/11/2017 01:12 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (Stefan Bergerstefanb(a)linux.vnet.ibm.com):
>> er.kernel.org>
>> X-Mailing-List: linux-kernel(a)vger.kernel.org
>> Content-Length: 19839
>> Lines: 700
>> X-UID: 24770
>> Status: RO
>>
>> From: Stefan Berger <stefanb(a)linux.vnet.ibm.com>
>>
>> This patch enables security.capability in user namespaces but also
>> takes a more general approach to enabling extended attributes in user
>> namespaces.
>>
>> The following rules describe the approach using security.foo as a
>> 'user namespace enabled' extended attribute:
>>
>> Reading of extended attributes:
>>
>> 1a) Reading security.foo from a user namespace will read
>> security.foo@uid=<uid> of the parent user namespace instead with uid
>> being the mapping of root in that parent user namespace. An
>> exception is if root is mapped to uid 0 on the host, and in this case
>> we will read security.foo directly.
>> --> reading security.foo will read security.foo@uid=1000 for uid
>> mapping of root to 1000.
>>
>> 1b) If security.foo@uid=<uid> is not available, the security.foo of the
>> parent namespace is tried to be read. This procedure is repeated up to
>> the init user namespace. This step only applies for reading of extended
>> attributes and provides the same behavior as older system where the
>> host's extended attributes applied to user namespaces.
>>
>> 2) All security.foo@uid=<uid> with valid uid mapping in the user namespace
>> can be read. The uid within the user namespace will be mapped to the
>> corresponding uid on the host and that uid will be used in the name of
>> the extended attribute.
>> -> reading security.foo@uid=1 will read security.foo@uid=1001 for uid
>> mapping of root to 1000, size of at least 2.
>>
>> All security.foo@uid=<uid> can be read (by root) on the host with values
>> of <uid> also being subject to checking for valid mappings.
>>
>> 3) No other security.foo* can be read.
>>
>> The same rules for reading apply to writing and removing of user
>> namespace enabled extended attributes.
>>
>> When listing extended attributes of a file, only those are presented
>> to the user namespace that have a valid mapping. Besides that, names
>> of the extended attributes are adjusted to represent the mapping.
>> This means that if root is mapped to uid 1000 on the host, the
>> security.foo@uid=1000 will be listed as security.foo in the user
>> namespace, security.foo@uid=1001 becomes security.foo@uid=1 and so on.
>>
>> Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com>
>> Signed-off-by: Serge Hallyn <serge(a)hallyn.com>
>> Reviewed-by: Serge Hallyn <serge(a)hallyn.com>
>> ---
>> fs/xattr.c | 509 +++++++++++++++++++++++++++++++++++++++++++++--
>> security/commoncap.c | 36 +++-
>> security/selinux/hooks.c | 9 +-
>> 3 files changed, 523 insertions(+), 31 deletions(-)
>>
>> diff --git a/fs/xattr.c b/fs/xattr.c
>> index 464c94b..eacad9e 100644
>> --- a/fs/xattr.c
>> +++ b/fs/xattr.c
>> @@ -133,20 +133,440 @@ xattr_permission(struct inode *inode, const char *name, int mask)
>> return inode_permission(inode, mask);
>> }
>>
>> +/*
>> + * A list of extended attributes that are supported in user namespaces
>> + */
>> +static const char *const userns_xattrs[] = {
>> + XATTR_NAME_CAPS,
>> + NULL
>> +};
>> +
>> +/*
>> + * xattrs_is_userns_supported - Check whether an xattr is supported in userns
>> + *
>> + * @name: full name of the extended attribute
>> + * @prefix: do a prefix match (true) or a full match (false)
>> + *
>> + * This function returns < 0 if not supported, an index into userns_xattrs[]
>> + * otherwise.
>> + */
>> +static int
>> +xattr_is_userns_supported(const char *name, int prefix)
>> +{
>> + int i;
>> +
>> + if (!name)
>> + return -1;
>> +
>> + for (i = 0; userns_xattrs[i]; i++) {
>> + if (prefix) {
>> + if (!strncmp(userns_xattrs[i], name,
>> + strlen(userns_xattrs[i])))
>> + return i;
> I think you here need to also check that the next char is either
> '\0' or '.' (or maybe '@')
I have the checks for '@' and '\0' done by the caller. With the current
support of only security.capability I don't think we need to check for '.'.
>
>> + } else {
>> + if (!strcmp(userns_xattrs[i], name))
>> + return i;
>> + }
>> + }
>> + return -1;
>> +}
>> +
>> +/*
>> + * xattr_write_uid - print a string in the format of "%s@uid=%u", which
>> + * includes a prefix string
>> + *
>> + * @uid: the uid
>> + * @prefix: prefix string; may be NULL
>> + *
>> + * This function returns a buffer with the string, or a NULL pointer in
>> + * case of out-of-memory error.
>> + */
>> +static char *
>> +xattr_write_uid(uid_t uid, const char *prefix)
>> +{
>> + size_t buflen;
>> + char *buffer;
>> +
>> + buflen = sizeof("@uid=") - 1 + sizeof("4294967295") - 1 + 1;
>> + if (prefix)
>> + buflen += strlen(prefix);
>> +
>> + buffer = kmalloc(buflen, GFP_KERNEL);
>> + if (!buffer)
>> + return NULL;
>> +
>> + if (uid == 0)
>> + *buffer = 0;
> Do you need to print out the prefix here?
Right. Fixed.
>
>> + else
>> + sprintf(buffer, "%s@uid=%u",
>> + (prefix) ? prefix : "",
>> + uid);
>> +
>> + return buffer;
>> +}
Thanks.
Stefan
4 years, 10 months
Request to add kernel tree
by Joe Lawrence
I'd like to add my github kernel tree to the 0-day testing.
It's located at https://github.com/joe-lawrence/linux
Do branches need to have any prefix/suffix/etc identification, or will
all new branches pushed to this repo be considered for testing?
Also, is it possible to enable notifications on successful test-runs
(ie, not just failures)?
Thanks!
-- Joe
4 years, 10 months
[lkp-robot] [EDAC] 5729ee3edf: kmsg.EDAC_sbridge:Failed_to_register_device_with_error
by kernel test robot
FYI, we noticed the following commit:
commit: 5729ee3edf50e4627ab216a170a4748a2d62dd12 ("EDAC: Remove EDAC_MM_EDAC")
https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git edac-for-4.12-stub
in testcase: unixbench
with following parameters:
runtime: 300s
nr_task: 1
test: pipe
cpufreq_governor: performance
test-description: UnixBench is the original BYTE UNIX benchmark suite aims to test performance of Unix-like system.
test-url: https://github.com/kdlucas/byte-unixbench
on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 64G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
kern :err : [ 32.919091] EDAC sbridge: Couldn't find mci handler
kern :err : [ 32.919092] EDAC sbridge: Couldn't find mci handler
kern :err : [ 32.919095] EDAC sbridge: Failed to register device with error -22.
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Xiaolong
4 years, 10 months
