Re: [PATCH] Add supplementary UIDs, and getusers/setusers system calls

[Josh Triplett]

On Sat, Nov 15, 2014 at 11:08:31PM -0800, Josh Triplett wrote:
>  asmlinkage long sys_setgroups(int gidsetsize, gid_t __user *grouplist);
> +asmlinkage long sys_setusers(int uidsetsize, uid_t __user *grouplist);

Obvious typo here: s/grouplist/userlist/.  Will fix in a v2, but I'll
wait for other feedback on v1 first.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH manpages] Document supplementary user IDs

[Josh Triplett]

Add new manpages for getusers(2) and setusers(2).  Discuss supplementary
UIDs in credentials(7).  Update manpages for seteuid(2), setfsuid(2),
setresuid(2), setreuid(2), and setuid(2).

Signed-off-by: Josh Triplett 
---
 man2/getusers.2| 177 +
 man2/seteuid.2 |  10 ++-
 man2/setfsuid.2|   4 +-
 man2/setresuid.2   |   8 ++-
 man2/setreuid.2|  12 +++-
 man2/setuid.2  |   7 ++-
 man2/setusers.2|   1 +
 man7/credentials.7 |  21 ++-
 8 files changed, 229 insertions(+), 11 deletions(-)
 create mode 100644 man2/getusers.2
 create mode 100644 man2/setusers.2

diff --git a/man2/getusers.2 b/man2/getusers.2
new file mode 100644
index 000..e5dd371
--- /dev/null
+++ b/man2/getusers.2
@@ -0,0 +1,177 @@
+.\" Copyright 2014 Josh Triplett 
+.\" Based on getgroups.2:
+.\" Copyright 1993 Rickard E. Faith (fa...@cs.unc.edu)
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date.  The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein.  The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.\" Modified Thu Oct 31 12:04:29 1996 by Eric S. Raymond 
+.\" Modified, 27 May 2004, Michael Kerrisk 
+.\" Added notes on capability requirements
+.\" 2008-05-03, mtk, expanded and rewrote parts of DESCRIPTION and RETURN
+.\" VALUE, made style of page more consistent with man-pages style.
+.\"
+.TH GETUSERS 2 2014-10-20 "Linux" "Linux Programmer's Manual"
+.SH NAME
+getusers, setusers \- get/set list of supplementary user IDs
+.SH SYNOPSIS
+.B #include 
+.br
+.B #include 
+.sp
+.BI "int getusers(int " size ", uid_t *" list );
+.sp
+.BI "int setusers(int " size ", const uid_t *" list );
+.sp
+.in -4n
+Feature Test Macro Requirements for glibc (see
+.BR feature_test_macros (7)):
+.in
+.sp
+.BR getusers (),
+.BR setusers ():
+_GNU_SOURCE
+.SH DESCRIPTION
+.PP
+.BR getusers ()
+returns the supplementary user IDs of the calling process in
+.IR list .
+The argument
+.I size
+should be set to the maximum number of items that can be stored in the
+buffer pointed to by
+.IR list .
+If the calling process has more than
+.I size
+supplementary user IDs,
+.BR getusers ()
+returns an error.
+The returned list may or may not include the real, effective, saved, or 
filesystem user ID of the calling process.
+
+If
+.I size
+is zero,
+.I list
+is not modified, but the total number of supplementary user IDs for the
+process is returned.
+This allows the caller to determine the size of a dynamically allocated
+.I list
+to be used in a further call to
+.BR getusers ().
+.PP
+.BR setusers ()
+sets the supplementary user IDs for the calling process.
+The
+.I size
+argument specifies the number of supplementary user IDs
+in the buffer pointed to by
+.IR list .
+
+Any process may drop user IDs from its supplementary list; however, adding user
+IDs not already present in the supplementary list or in the real, effective, or
+saved user ID requires the
+.B CAP_SETUID
+capability.
+.SH RETURN VALUE
+On success,
+.BR getusers ()
+returns the number of supplementary user IDs.
+On error, \-1 is returned, and
+.I errno
+is set appropriately.
+
+On success,
+.BR setusers ()
+returns 0.
+On error, \-1 is returned, and
+.I errno
+is set appropriately.
+.SH ERRORS
+.TP
+.B EFAULT
+.I list
+has an invalid address.
+.PP
+.BR getusers ()
+can additionally fail with the following error:
+.TP
+.B EINVAL
+.I size
+is less than the number of supplementary user IDs, but is not zero.
+.PP
+.BR setusers ()
+can additionally fail with the following errors:
+.TP
+.B EINVAL
+.I size
+is greater than
+.B NUSERS_MAX
+(65536).
+.TP
+.B ENOMEM
+Out of memory.
+.TP
+.B EPERM
+.I list
+contains user IDs not present in the current supplemental user IDs list,
+and not equal to the real, effective, or saved user ID, and the calling
+process does not have
+.BR CAP_SETUID .
+.SH CONFORMING TO
+.BR getusers (),
+.BR setusers (),
+and supplementary user IDs in general are Linux-specific and should not
+be used in programs intended to be portable.
+.SH NOTES
+A process can 

[PATCH] Add supplementary UIDs, and getusers/setusers system calls

[Josh Triplett]

Analogous to the supplementary GID list, the supplementary UID list
provides a set of additional user credentials that a process can act as.
A process with CAP_SETUID can set its UID list arbitrarily; a process
without CAP_SETUID can only reduce its UID list.

This allows each user to have a set of UIDs that they can then use to
further sandbox individual child processes without first escalating to
root to change UIDs.  For instance, a PAM module could give each user a
block of UIDs to work with.

Tested via the following test program:

#include 
#include 
#include 
#include 

static int getusers(int count, uid_t *uids)
{
return syscall(322, count, uids);
}

static int setusers(int count, const uid_t *uids)
{
return syscall(323, count, uids);
}

static void show_users(void)
{
uid_t uids[65536];
int i, count = getusers(65536, uids);
if (count < 0)
err(1, "getusers");
printf("UIDs:");
for (i = 0; i < count; i++)
printf(" %u", (unsigned)uids[i]);
printf("\n");
}

int main(void)
{
uid_t list1[] = { 1, 2, 3, 4, 5 };
uid_t list2[] = { 1, 2, 3, 4 };
uid_t list3[] = { 2, 3, 4 };
show_users();
if (setusers(5, list1) < 0)
err(1, "setusers 1");
show_users();
if (setresgid(1, 1, 1) < 0)
err(1, "setresgid");
if (setresuid(1, 1, 1) < 0)
err(1, "setresuid");
if (setusers(4, list2) < 0)
err(1, "setusers 2");
show_users();
if (setusers(3, list3) < 0)
err(1, "setusers 3");
show_users();
if (setusers(4, list2) < 0)
err(1, "setusers 4");
show_users();
if (setresuid(2, 2, 2) < 0)
err(1, "setresuid 2");
if (setusers(5, list1) < 0)
err(1, "setusers 5");
show_users();

return 0;
}

In this test, all but the last call to setusers succeeds; the last call
fails with EPERM because the unprivileged process attempts to add UID 5
to the supplementary UID list, which it does not currently have.

Signed-off-by: Josh Triplett 
---
 arch/x86/syscalls/syscall_32.tbl  |   2 +
 arch/x86/syscalls/syscall_64.tbl  |   2 +
 include/linux/cred.h  |  66 +++
 include/linux/syscalls.h  |   2 +
 include/uapi/asm-generic/unistd.h |   6 +-
 include/uapi/linux/limits.h   |   1 +
 init/Kconfig  |   9 ++
 kernel/cred.c |   4 +
 kernel/groups.c   | 173 ++
 kernel/sys.c  |  21 +++--
 kernel/sys_ni.c   |   2 +
 11 files changed, 280 insertions(+), 8 deletions(-)

diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index 9fe1b5d..55717d7 100644
--- a/arch/x86/syscalls/syscall_32.tbl
+++ b/arch/x86/syscalls/syscall_32.tbl
@@ -364,3 +364,5 @@
 355i386getrandom   sys_getrandom
 356i386memfd_createsys_memfd_create
 357i386bpf sys_bpf
+358i386getuserssys_getusers
+359i386setuserssys_setusers
diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index 281150b..5572e67 100644
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@ -328,6 +328,8 @@
 319common  memfd_createsys_memfd_create
 320common  kexec_file_load sys_kexec_file_load
 321common  bpf sys_bpf
+322common  getuserssys_getusers
+323common  setuserssys_setusers
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/include/linux/cred.h b/include/linux/cred.h
index b2d0820..31169fe 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -76,6 +76,8 @@ extern int groups_search(const struct group_info *, kgid_t);
 extern int in_group_p(kgid_t);
 extern int in_egroup_p(kgid_t);
 
+struct user_info;
+
 /*
  * The security context of a task
  *
@@ -135,6 +137,12 @@ struct cred {
struct user_struct *user;   /* real user ID subscription */
struct user_namespace *user_ns; /* user_ns the caps and keyrings are 
relative to. */
struct group_info *group_info;  /* supplementary groups for euid/fsgid 
*/
+#ifdef CONFIG_SUPPLEMENTARY_UIDS
+   struct user_info *user_info;/* supplementary users */
+#define INIT_USER_INFO .user_info = _users,
+#else
+#define INIT_USER_INFO
+#endif
struct rcu_head rcu;/* RCU deletion hook */
 };
 
@@ -381,4 +389,62 @@ do {   \
*(_fsgid) = __cred->fsgid;  \
 } while(0)
 
+#ifdef CONFIG_SUPPLEMENTARY_UIDS
+struct user_info {
+   atomic_tusage;
+   int nusers;
+   int nblocks;
+   kuid_t  small_block[NGROUPS_SMALL];
+   kuid_t  *blocks[0];
+};
+
+#define USER_AT(ui, i) GROUP_AT(ui, i)
+extern struct user_info init_users;
+void users_free(struct 

Re: linux-next: Tree for Nov 14

[Guenter Roeck]

On 11/15/2014 08:20 PM, Jiang Liu wrote:


On 2014/11/16 11:22, Guenter Roeck wrote:

On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
 Could you please help to provide the config file and
error messages?


Config file:
 
https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig

Hi Guenter,
Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
 def_bool y
 depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
 select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?


I took the configuration file I had for the SMP case (located in the same
directory in the git repository), disabled SMP, and ran "make savedefconfig".
"old" is relative in this context; I don't usually create new configuration
files for each new kernel release, so, yes, you could say that the file
I used is "old".

CONFIG_X86_LOCAL_APIC is enabled. Keep in mind this is a configuration file
created with "make savedefconfig", so default settings are not included.
Correct, CONFIG_X86_IO_APIC is not enabled, but that is not really surprising
since its dependencies are not met as far as I can see.

Overall, I am not sure I understand what you are trying to say. X86_IO_APIC
depends on X86_64 (not set) or SMP (not set) or X86_32_NON_STANDARD (not set)
or X86_UP_IOAPIC (not set because it depends on X86_UP_APIC which depends on
!PCI_MSI).

Does that mean that I'll have to disable PCI_MSI to get x86 uniprocessor
support to work after your patch ?

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: frequent lockups in 3.18rc4

[Linus Torvalds]

On Sat, Nov 15, 2014 at 5:40 PM, Dave Jones  wrote:
>  >
>  > I'll try that next, and check in on it tomorrow.
>
> No luck. Died even faster this time.

Yeah, and your other lockups haven't even been TLB related. Not that
they look like anything else *either*.

I have no ideas left. I'd go for a bisection - rather than try random
things, at least bisection will get us a smaller set of suspects if
you can go through a few cycles of it. Even if you decide that you
want to run for most of a day before you are convinced it's all good,
a couple of days should get you a handful of bisection points (that's
assuming you hit a couple of bad ones too that turn bad in a shorter
while). And 4 or five bisections should get us from 11k commits down
to the ~600 commit range. That would be a huge improvement.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Josh Triplett]

On Sat, Nov 15, 2014 at 09:08:07PM -0600, Eric W. Biederman wrote:
> Josh Triplett  writes:
> > On November 15, 2014 6:05:11 PM PST, Theodore Ts'o  wrote:
> >>On Sat, Nov 15, 2014 at 12:20:42PM -0800, Josh Triplett wrote:
> >>> > However, sudoers seems to allow negative group matches.  So maybe
> >>> > allowing this only with no_new_privs already set would make sense.
> >>> 
> >>> Sigh, bad sudo.  Sure, restricting this to no_new_privs only seems
> >>fine.
> >>> I'll do that in v2, and document that in the manpage.
> >>
> >>I've also seen use cases (generally back in the bad old days of big
> >>timesharing VAX 750's :-) where the system admin might assign someone
> >>to the "games-abusers" group, and then set /usr/games to mode 705
> >>root:games-abusers --- presumably because it's easier to add a few
> >>people to the deny list rather than having to add all of the EECS
> >>department to the games group minus the abusers.
> >>
> >>So arbitrarily anyone to drop groups from their supplemental group
> >>list will result in a change from both existing practice and legacy
> >>Unix systems, and it could potentially lead to a security exposure.
> >
> > As Andy pointed out, you can already do that with a user namespace,
> 
> That may be a bug with the user namespace permission check.  Perhaps we
> shouldn't allow dropping groups that aren't mapped in the user
> namespace.

Changing that would break containers for users on many common Linux
distributions, which put users in various supplementary groups by
default.

I do actually have another patch planned, to allow users to set up gid
maps for groups they currently have permission for, not just for their
primary group.  But even with that change, breaking the ability for
container-root to use setgroups to drop all its supplementary groups
seems very wrong, and seems highly likely to break real-world software
running in containers.

> To add to the discussion there are also sg and newgroup, though I don't
> think they touch supplementary groups.

Both sg and newgrp do prove a different point, though: an unprivileged
user should be able to change their gid to one of their supplementary
groups.  That's another patch I planned to submit after this one:
allow setgid/setresgid/etc to a supplementary group ID.

> > for any case not involving a setuid or setgid (or otherwise
> > privilege-gaining) program.  And requiring no_new_privs handles that.
> 
> Frankly adding a no_new_privs check to allow something/anything scares
> me.  That converts no_new_privs from something simple and easy to
> understand to something much more complicated.

no_new_privs already exists in large part to support such use cases,
such as setting seccomp filters, which would be dangerous for
privilege-escalating programs to inherit.

> > Given the combination of those two things, do you still see any
> > problematic cases?
> 
> Josh I think it is time to stop and make certain you understand how
> unix groups work in the large.
>
> It seems to me that either supplementary groups can be dropped or
> supplementary groups can not be dropped.  If they can be dropped we
> shouldn't need complicated checks to allow them to be dropped in some
> circumstances but not others.
> 
> Unix groups are an old interface and they have been used in a lot of
> ways over the years.  We need to be careful any change we make is good
> and truly backwards compatible and that we do our darndest not to
> introduce security holes.

Seeking the decades-old precedents and corner cases that might
contradict the most obvious semantics is a large part of what I'm
looking for out of this thread.

However, I don't necessarily think that we must permit unprivileged
setgroups in *all* cases if we permit it in *any*; it may well make
sense to reduce the surface area of the change by limiting the
circumstances in which you can do this.  Whether it does end up making
sense to do so depends on the outcome of this discussion.

I added the no_new_privs check at Andy's suggestion, since the use case
I had in mind will work just fine with that restriction.  I'm also open
to just allowing setgroups in all cases, if that semantic seems
preferable, or to adding some separate check specific to this case if
that really seems necessary.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Josh Triplett]

On Sat, Nov 15, 2014 at 10:40:06PM -0500, Theodore Ts'o wrote:
> On Sat, Nov 15, 2014 at 06:35:05PM -0800, Josh Triplett wrote:
> > >So arbitrarily anyone to drop groups from their supplemental group
> > >list will result in a change from both existing practice and legacy
> > >Unix systems, and it could potentially lead to a security exposure.
> > 
> > As Andy pointed out, you can already do that with a user namespace,
> > for any case not involving a setuid or setgid (or otherwise
> > privilege-gaining) program.  And requiring no_new_privs handles
> > that.
> 
> Well, it's no worse than what we can do already with the user
> namespace, yes.  I'm still worried it's going to come as a surprise
> for some configurations because it's a change from what was allowed
> historically.  Then again, pretty much all of the tripwire and rootkit
> scanners won't notice a "setuid" program that uses capabilities
> instead of the traditional setuid bit, and most sysadmins won't think
> to check for an executable with a forced capability mask, so this
> isn't exactly a new problem

We certainly have introduced orthogonal APIs in various areas before,
such that applications written prior to those APIs may interact
interestingly with them; we don't allow *breaking* those applications,
or introducing security holes, but the existence of applications
designed to block one particular way to do something doesn't
*automatically* rule out the possibility of adding another way to do it.
It does require some careful thought, though.

When we introduced seccomp filters for syscalls, we tied them to
no_new_privs to prevent any possible security holes caused by selective
syscall denial/filtration.

In this case, I'm indifferent about whether unprivileged setgroups works
without no_new_privs; if people are comfortable with that, fine, and if
people would prefer no_new_privs (or for that matter a sysctl, a
compile-time option, or any other means of making the behavior
optional), I can do that too.  The security model of "having a group
gives you less privilege than not having it" seems crazy, but
nonetheless I can see a couple of easy ways that we can avoid breaking
that pattern, no_new_privs being one of them.  I'd like to make sure
that nobody sees any other real-world corner case that unprivileged
setgroups would break.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Anup Patel]

On Thu, Nov 13, 2014 at 1:15 PM, Ankit Jindal  wrote:
> This patch adds device tree binding documentation for
> X-Gene QMTM UIO driver.
>
> Signed-off-by: Ankit Jindal 
> Signed-off-by: Tushar Jagad 
> ---
>  .../devicetree/bindings/uio/uio_xgene_qmtm.txt |   51 
> 
>  1 file changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
>
> diff --git a/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt 
> b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
> new file mode 100644
> index 000..ed85bc6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
> @@ -0,0 +1,51 @@
> +APM X-Gene QMTM nodes
> +
> +The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
> +and Traffic manager). It is a device for managing hardware queues.
> +It also implements QoS among hardware queues hence term "traffic"
> +manager is present in its name.
> +
> +Required properties:
> +- compatible: Should be "apm,xgene-qmtm"
> +- reg: Address and length of the register set for the device. It contains the
> +  information of registers in the same order as described by reg-names.
> +- reg-names: Should contain the register set names
> +  - "csr": QMTM control and status register address space.
> +  - "fabric": QMTM memory mapped access to queue states.
> +- qpool-memory: Points to the phandle of the node defining memory location 
> for
> +creating QMTM queues. This must point to the reserved-memory node
> +(as-per reserved memory bindings). It is expected that size and
> +location of qpool memory will be configurable via bootloader.
> +- clocks: Reference to the clock entry.
> +- num-queues: Number of queues under this QMTM device.
> +- devid: QMTM identification number for the system having multiple QMTM 
> devices.
> +This is used to form a unique id (a tuple of queue number and
> +device id) for the queues belonging to this device.
> +
> +Example:
> +   qmtm1_uio_qpool: qmtm1_uio_qpool {
> +   reg = <0x0 0x0 0x0 0x0>
> +   };
> +
> +   qmtm1clk: qmtmclk@1f20c000 {
> +   compatible = "apm,xgene-device-clock";
> +   clock-output-names = "qmtm1clk";
> +   status = "ok";
> +   };
> +
> +   qmtm1_uio: qmtm_uio@1f20 {
> +   compatible = "apm,xgene-qmtm";
> +   status = "disabled";
> +   reg = <0x0 0x1f20 0x0 0x1>,
> + <0x0 0x1b00 0x0 0x40>;
> +   reg-names = "csr", "fabric";
> +   qpool = <_uio_qpool>;

Small typo, this should be qpool-memory = <...>;

> +   clocks = < 0>;
> +   num-queues = <0x400>;
> +   devid = <1>;
> +   };
> +
> +   /* Board-specific peripheral configurations */
> +   _uio {
> +   status = "ok";
> +   };
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

[Jiang Liu]

On 2014/11/16 11:22, Guenter Roeck wrote:
> On 11/15/2014 06:33 PM, Jiang Liu wrote:
>> Hi Guenter,
>> Could you please help to provide the config file and
>> error messages?
> 
> Config file:
> 
> https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig
Hi Guenter,
Thanks for help. According to the above configuration file:
CONFIG_PCI_MSI is enabled, but CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC are both disabled. But the Kconfig for X86_LOCAL_APIC
is defined as:
config X86_LOCAL_APIC
def_bool y
depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC
|| PCI_MSI
select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

That means CONFIG_X86_LOCAL_APIC should be enabled if CONFIG_PCI_MSI is
enabled. So how did you generate the qemu_x86_pc_nosmp_defconfig? Are
you using an old configuration file?
Thanks!
Gerry

> 
> 
> Error log:
> 
> http://server.roeck-us.net:8010/builders/qemu-x86-next/builds/44/steps/qemubuildcommand/logs/stdio
> 
> 
> You can find the root file system used for the test as well as the test
> script at
> https://github.com/groeck/linux-build-test/tree/master/rootfs/x86
> 
> There isn't really an error message, though - the boot stalls until the
> controlling daemon
> kills the qemu session.
> 
> Guenter
> 
>> Thanks!
>> Gerry
>>
>> On 2014/11/16 5:19, Guenter Roeck wrote:
>>> On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
 Hi all,

 Changes since 20141113:

 New tree: overlayfs

 The idle tree gained a conflict against Linus' tree.

 The scsi tree gained a conflict against the usb tree.

 Non-merge commits (relative to Linus' tree): 6264
   6509 files changed, 209171 insertions(+), 167101 deletions(-)

>>>
>>> I bisected the x86-nosmp qemu runtime failure I have seen for
>>> the last few days. Here is the result:
>>>
>>> bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
>>> commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
>>> Author: Jiang Liu 
>>> Date:   Mon Oct 27 16:12:06 2014 +0800
>>>
>>>  x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
>>>
>>> Detailed log:
>>>
>>> git bisect start 'HEAD' 'v3.18-rc4'
>>> # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge
>>> remote-tracking branch 'sound-asoc/for-next'
>>> git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
>>> # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge
>>> remote-tracking branch 'usb-serial/usb-next'
>>> git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
>>> # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge
>>> remote-tracking branch 'kvm/linux-next'
>>> git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
>>> # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge
>>> remote-tracking branch 'audit/next'
>>> git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
>>> # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch
>>> 'x86/vdso'
>>> git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
>>> # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch
>>> 'sched/urgent'
>>> git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
>>> # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch
>>> 'x86/boot'
>>> git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
>>> # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect
>>> __clear_irq_vector() with vector_lock
>>> git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
>>> # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use
>>> helpers to access irq_cfg data structure associated with IRQ
>>> git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
>>> # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT
>>> IRQ related code from io_apic.c into htirq.c
>>> git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
>>> # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI
>>> and HT_IRQ indepenent of X86_IO_APIC
>>> git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
>>> # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ
>>> initialization routines from io_apic.c into vector.c
>>> git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
>>> # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86,
>>> irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
>>>
>>> I'll be happy to provide the configuration if needed.
>>>
>>> Guenter
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To 

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Theodore Ts'o]

On Sat, Nov 15, 2014 at 06:35:05PM -0800, Josh Triplett wrote:
> >So arbitrarily anyone to drop groups from their supplemental group
> >list will result in a change from both existing practice and legacy
> >Unix systems, and it could potentially lead to a security exposure.
> 
> As Andy pointed out, you can already do that with a user namespace,
> for any case not involving a setuid or setgid (or otherwise
> privilege-gaining) program.  And requiring no_new_privs handles
> that.

Well, it's no worse than what we can do already with the user
namespace, yes.  I'm still worried it's going to come as a surprise
for some configurations because it's a change from what was allowed
historically.  Then again, pretty much all of the tripwire and rootkit
scanners won't notice a "setuid" program that uses capabilities
instead of the traditional setuid bit, and most sysadmins won't think
to check for an executable with a forced capability mask, so this
isn't exactly a new problem

- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

[Guenter Roeck]

On 11/15/2014 06:33 PM, Jiang Liu wrote:

Hi Guenter,
Could you please help to provide the config file and
error messages?


Config file:

https://github.com/groeck/linux-build-test/blob/master/rootfs/x86/qemu_x86_pc_nosmp_defconfig

Error log:

http://server.roeck-us.net:8010/builders/qemu-x86-next/builds/44/steps/qemubuildcommand/logs/stdio

You can find the root file system used for the test as well as the test script 
at
https://github.com/groeck/linux-build-test/tree/master/rootfs/x86

There isn't really an error message, though - the boot stalls until the 
controlling daemon
kills the qemu session.

Guenter


Thanks!
Gerry

On 2014/11/16 5:19, Guenter Roeck wrote:

On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:

Hi all,

Changes since 20141113:

New tree: overlayfs

The idle tree gained a conflict against Linus' tree.

The scsi tree gained a conflict against the usb tree.

Non-merge commits (relative to Linus' tree): 6264
  6509 files changed, 209171 insertions(+), 167101 deletions(-)



I bisected the x86-nosmp qemu runtime failure I have seen for
the last few days. Here is the result:

bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
Author: Jiang Liu 
Date:   Mon Oct 27 16:12:06 2014 +0800

 x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

Detailed log:

git bisect start 'HEAD' 'v3.18-rc4'
# good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking branch 
'sound-asoc/for-next'
git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
# bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking branch 
'usb-serial/usb-next'
git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
# bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking branch 
'kvm/linux-next'
git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
# good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking branch 
'audit/next'
git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
# bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
# good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
# bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
# good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
__clear_irq_vector() with vector_lock
git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
# bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
access irq_cfg data structure associated with IRQ
git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
# good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
related code from io_apic.c into htirq.c
git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
# bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and HT_IRQ 
indepenent of X86_IO_APIC
git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
# good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
initialization routines from io_apic.c into vector.c
git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
# first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
MSI and HT_IRQ indepenent of X86_IO_APIC

I'll be happy to provide the configuration if needed.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Eric W. Biederman]

Josh Triplett  writes:

> On November 15, 2014 6:05:11 PM PST, Theodore Ts'o  wrote:
>>On Sat, Nov 15, 2014 at 12:20:42PM -0800, Josh Triplett wrote:
>>> > However, sudoers seems to allow negative group matches.  So maybe
>>> > allowing this only with no_new_privs already set would make sense.
>>> 
>>> Sigh, bad sudo.  Sure, restricting this to no_new_privs only seems
>>fine.
>>> I'll do that in v2, and document that in the manpage.
>>
>>I've also seen use cases (generally back in the bad old days of big
>>timesharing VAX 750's :-) where the system admin might assign someone
>>to the "games-abusers" group, and then set /usr/games to mode 705
>>root:games-abusers --- presumably because it's easier to add a few
>>people to the deny list rather than having to add all of the EECS
>>department to the games group minus the abusers.
>>
>>So arbitrarily anyone to drop groups from their supplemental group
>>list will result in a change from both existing practice and legacy
>>Unix systems, and it could potentially lead to a security exposure.
>
> As Andy pointed out, you can already do that with a user namespace,

That may be a bug with the user namespace permission check.  Perhaps we
shouldn't allow dropping groups that aren't mapped in the user
namespace.

To add to the discussion there are also sg and newgroup, though I don't
think they touch supplementary groups.

> for any case not involving a setuid or setgid (or otherwise
> privilege-gaining) program.  And requiring no_new_privs handles that.

Frankly adding a no_new_privs check to allow something/anything scares
me.  That converts no_new_privs from something simple and easy to
understand to something much more complicated.

> Given the combination of those two things, do you still see any
> problematic cases?

Josh I think it is time to stop and make certain you understand how
unix groups work in the large.

It seems to me that either supplementary groups can be dropped or
supplementary groups can not be dropped.  If they can be dropped we
shouldn't need complicated checks to allow them to be dropped in some
circumstances but not others.

Unix groups are an old interface and they have been used in a lot of
ways over the years.  We need to be careful any change we make is good
and truly backwards compatible and that we do our darndest not to
introduce security holes.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 10/10] crypto: AF_ALG: document the user space interface

[Stephan Mueller]

The extension of the user space interface documentation covers all
aspects of the patchset, including:

* AEAD cipher interface

* RNG cipher interface

* getsockopt interface

Signed-off-by: Stephan Mueller 
---
 Documentation/crypto/crypto-API-userspace.txt | 95 ++-
 1 file changed, 93 insertions(+), 2 deletions(-)

diff --git a/Documentation/crypto/crypto-API-userspace.txt 
b/Documentation/crypto/crypto-API-userspace.txt
index ac619cd..5090b05 100644
--- a/Documentation/crypto/crypto-API-userspace.txt
+++ b/Documentation/crypto/crypto-API-userspace.txt
@@ -30,8 +30,9 @@ ciphers are accessible:
 
* Symmetric ciphers
 
-Note, AEAD ciphers are currently not supported via the symmetric cipher
-interface.
+   * AEAD ciphers
+
+   * Random number generators
 
 The interface is provided via Netlink using the type AF_ALG. In addition, the
 setsockopt option type is SOL_ALG. In case the user space header files do not
@@ -85,6 +86,7 @@ If a consumer on the other hand wants to maintain the 
plaintext and the
 ciphertext in different memory locations, all a consumer needs to do is to
 provide different memory pointers for the encryption and decryption operation.
 
+
 Message digest API
 ==
 
@@ -169,6 +171,69 @@ as large as to hold all blocks of the encrypted or 
decrypted data. If the output
 data size is smaller, only as many blocks are returned that fit into that
 output buffer size.
 
+
+AEAD cipher API
+===
+
+The operation is identical to the symmetric cipher API. However, an AEAD
+cipher requires additional information, such as the authentication tag and
+the associated data. This data is to be supplied in addition to the normal
+symmetric cipher data like key and IV discussed for the symmetric ciphers.
+
+During initialization, the struct sockaddr data structure must be filled as
+follows:
+
+struct sockaddr_alg sa = {
+   .salg_family = AF_ALG,
+   .salg_type = "aead", /* this selects the AEAD cipher */
+   .salg_name = "gcm(aes)" /* this is the cipher name */
+};
+
+The discussion about the sendmsg given for the symmetric cipher applies for
+the AEAD interface as well. In addition to the plaintext / ciphertext data and
+the IV, the following data must be supplied with the cmsghdr data structure:
+
+   * The AEAD authentication tag size is set with the flag
+ ALG_SET_AEAD_AUTHSIZE. The integer value of the authentication tag
+ size must be provided in the data field of the cmsghdr structure.
+
+   * The AEAD associated data is set with the flag ALG_SET_AEAD_ASSOC.
+ The data is set the same way as for the IV by supplying the associated
+ data in the data field of the cmsghdr structure.
+
+The authentication tag itself, however, is handled in a different way to comply
+with the specifics of the kernel crypto API and to avoid copying the
+authentication tag around in memory. The authentication tag is added to the
+memory that immediately follows the ciphertext.
+
+   * When performing an encryption operation, the resulting ciphertext
+ buffer will hold the tag as follows: ciphertext || tag.  The consumer
+ must ensure that the ciphertext buffer is large enough to hold the
+ ciphertext together with the tag of the size set by the consumer using
+ the ALG_SET_AEAD_AUTHSIZE cmsghdr flag as discussed above.
+
+   * When performing a decryption operation, the initial ciphertext buffer
+ must hold the tag as follows: ciphertext || tag. The resulting
+ plaintext has the same size as the ciphertext.
+
+Note: Authentication errors during decryption are marked with a failing
+read/recv system call whose errno is set to EBADMSG.
+
+
+Random number generator API
+===
+
+Compared to the symmetric ciphers, the random number generator API is simple:
+it only supports the system calls of read/recv.
+
+The consumer must observe the returned size of the read/recv system calls and
+potentially make subsequent calls if the returned length of random numbers is
+smaller than the expected length.
+
+When initializing a random number generator instance, the AF_ALG interface
+handler ensures that it is appropriately seeded.
+
+
 Setsockopt interface
 
 
@@ -190,6 +255,32 @@ optname:
 
- the hash cipher type (keyed message digests)
 
+
+Getsockopt interface
+
+
+To allow consumers to obtain information about the allocated cipher, the
+following getsockopt calls with the optval set to the listed flags are 
provided.
+
+The getsockopt system call must be invoked with the file descriptor of the open
+cipher (i.e. the file descriptor returned by the accept system call).
+
+   * ALG_GET_BLOCKSIZE -- Return the block size of the cipher in the
+ optlen field of getsockopt. This call is only applicable to
+ symmetric and AEAD ciphers.
+
+   * 

[PATCH v2 08/10] crypto: AF_ALG: enable RNG interface compilation

[Stephan Mueller]

Enable compilation of the RNG AF_ALG support and provide a Kconfig
option to compile the RNG AF_ALG support.

Signed-off-by: Stephan Mueller 
---
 crypto/Kconfig  | 9 +
 crypto/Makefile | 1 +
 2 files changed, 10 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 87bbc9c..e127323 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1505,6 +1505,15 @@ config CRYPTO_USER_API_SKCIPHER
  This option enables the user-spaces interface for symmetric
  key cipher algorithms.
 
+config CRYPTO_USER_API_RNG
+   tristate "User-space interface for random number generator algorithms"
+   depends on NET
+   select CRYPTO_RNG
+   select CRYPTO_USER_API
+   help
+ This option enables the user-spaces interface for random
+ number generator algorithms.
+
 config CRYPTO_HASH_INFO
bool
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 1445b91..ba19465 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
 obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
 obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
 obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
+obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
 
 #
 # generic algorithms and the async_tx api
-- 
2.1.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [mempolicy] remove unnecessary is_valid_nodemask()

[Zhihui Zhang]

When nodes is true, nsc->mask2 has already been filtered by nsc->mask1, which 
has
already factored in node_states[N_MEMORY].

Signed-off-by: Zhihui Zhang 
---
 mm/mempolicy.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index e58725a..f22c559 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -162,12 +162,6 @@ static const struct mempolicy_operations {
enum mpol_rebind_step step);
 } mpol_ops[MPOL_MAX];
 
-/* Check that the nodemask contains at least one populated zone */
-static int is_valid_nodemask(const nodemask_t *nodemask)
-{
-   return nodes_intersects(*nodemask, node_states[N_MEMORY]);
-}
-
 static inline int mpol_store_user_nodemask(const struct mempolicy *pol)
 {
return pol->flags & MPOL_MODE_FLAGS;
@@ -202,7 +196,7 @@ static int mpol_new_preferred(struct mempolicy *pol, const 
nodemask_t *nodes)
 
 static int mpol_new_bind(struct mempolicy *pol, const nodemask_t *nodes)
 {
-   if (!is_valid_nodemask(nodes))
+   if (nodes_empty(*nodes))
return -EINVAL;
pol->v.nodes = *nodes;
return 0;
@@ -234,7 +228,7 @@ static int mpol_set_nodemask(struct mempolicy *pol,
nodes = NULL;   /* explicit local allocation */
else {
if (pol->flags & MPOL_F_RELATIVE_NODES)
-   mpol_relative_nodemask(>mask2, nodes,>mask1);
+   mpol_relative_nodemask(>mask2, nodes, >mask1);
else
nodes_and(nsc->mask2, *nodes, nsc->mask1);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 00/10] crypto: AF_ALG: add AEAD and RNG support

[Stephan Mueller]

Hi,

This patch set adds AEAD and RNG support to the AF_ALG interface
exported by the kernel crypto API. By extending AF_ALG with AEAD and RNG
support, all cipher types the kernel crypto API allows access to are
now accessible from userspace.

The RNG support is stand-alone.

The AEAD implementation is added to algif_skcipher.c to prevent
re-implementation of the memory moving logic.

The extension for the AEAD support can be summarized with the following
types of changes:

* select the correct crypto API functions (either the ablkcipher
  or the aead functions)

* apply the additional data needed for AEAD at the right time
  (associated data, authentication tag) -- this includes the addition
  of user space interfaces to allow setting this data.

* add the calculation for the memory size needed for encryption and
  decryption.

In addition, the patch set adds a getsockopt implementation to skcipher to
allow user space to inquire about properties of the ciphers (IV size,
block size, authentication data size). This extension would be needed for a
generic user space usage of these ciphers.

The new AEAD and RNG interfaces are fully tested with the test application
provided at [1]. That test application exercises all newly added user space
interfaces.

The patch set was tested on x86_64 and i386.

[1] http://www.chronox.de/libkcapi.html

Changes v2:
* rebase to current cryptodev-2.6 tree
* use memzero_explicit to zeroize AEAD associated data
* use sizeof for determining length of AEAD associated data
* update algif_rng.c covering all suggestions from Daniel Borkmann
  
* addition of patch 9: add digestsize interface for hashes
* addition of patch to update documentation covering the userspace interface
* change numbers of getsockopt options: separate them from sendmsg interface
  definitions

Stephan Mueller (10):
  crypto: AF_ALG: add user space interface for AEAD
  crypto: AF_ALG: user space interface for cipher info
  crypto: AF_ALG: extend data structuers for AEAD
  crypto: AF_ALG: crypto API calls to inline functions
  crypto: AF_ALG: add AEAD support
  crypto: AF_ALG: make setkey optional
  crypto: AF_ALG: add random number generator support
  crypto: AF_ALG: enable RNG interface compilation
  crypto: AF_ALG: user space interface for hash info
  crypto: AF_ALG: document the user space interface

 Documentation/crypto/crypto-API-userspace.txt |  95 ++-
 crypto/Kconfig|   9 +
 crypto/Makefile   |   1 +
 crypto/af_alg.c   |  20 ++
 crypto/algif_hash.c   |  35 ++-
 crypto/algif_rng.c| 186 ++
 crypto/algif_skcipher.c   | 352 +++---
 include/crypto/if_alg.h   |   2 +
 include/uapi/linux/if_alg.h   |  15 ++
 9 files changed, 683 insertions(+), 32 deletions(-)
 create mode 100644 crypto/algif_rng.c

-- 
2.1.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 01/10] crypto: AF_ALG: add user space interface for AEAD

[Stephan Mueller]

AEAD requires the following data in addition to normal symmetric
ciphers:

* Associated authentication data of arbitrary length

* Authentication tag for decryption

* Length of authentication tag for encryption

The authentication tag data is communicated as part of the actual
ciphertext as mandated by the kernel crypto API. Therefore we only need
to provide a user space interface for the associated authentication data
as well as for the authentication tag length.

This patch adds both as a setsockopt interface that is identical to the
AF_ALG interface for setting an IV and for selecting the cipher
operation type (encrypt or decrypt).

Signed-off-by: Stephan Mueller 
---
 crypto/af_alg.c | 17 +
 include/crypto/if_alg.h |  2 ++
 include/uapi/linux/if_alg.h |  7 +++
 3 files changed, 26 insertions(+)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 6a3ad80..635140b 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -421,6 +421,23 @@ int af_alg_cmsg_send(struct msghdr *msg, struct 
af_alg_control *con)
con->op = *(u32 *)CMSG_DATA(cmsg);
break;
 
+
+   case ALG_SET_AEAD_AUTHSIZE:
+   if (cmsg->cmsg_len < CMSG_LEN(sizeof(u32)))
+   return -EINVAL;
+   con->aead_authsize = *(u32 *)CMSG_DATA(cmsg);
+   break;
+
+   case ALG_SET_AEAD_ASSOC:
+   if (cmsg->cmsg_len < CMSG_LEN(sizeof(*con->aead_assoc)))
+   return -EINVAL;
+   con->aead_assoc = (void *)CMSG_DATA(cmsg);
+   if (cmsg->cmsg_len <
+   CMSG_LEN(con->aead_assoc->aead_assoclen +
+sizeof(*con->aead_assoc)))
+   return -EINVAL;
+   break;
+
default:
return -EINVAL;
}
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index d61c111..c741483 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -41,7 +41,9 @@ struct af_alg_completion {
 
 struct af_alg_control {
struct af_alg_iv *iv;
+   struct af_alg_aead_assoc *aead_assoc;
int op;
+   unsigned int aead_authsize;
 };
 
 struct af_alg_type {
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index 0f9acce..64e7008 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -28,10 +28,17 @@ struct af_alg_iv {
__u8iv[0];
 };
 
+struct af_alg_aead_assoc {
+   __u32   aead_assoclen;
+   __u8aead_assoc[0];
+};
+
 /* Socket options */
 #define ALG_SET_KEY1
 #define ALG_SET_IV 2
 #define ALG_SET_OP 3
+#define ALG_SET_AEAD_ASSOC 4
+#define ALG_SET_AEAD_AUTHSIZE  5
 
 /* Operations */
 #define ALG_OP_DECRYPT 0
-- 
2.1.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 03/10] crypto: AF_ALG: extend data structuers for AEAD

[Stephan Mueller]

The data structure holding the state of an ongoing symmetric cipher
operation is extended by the data variables needed for AEAD.

The request data structures are encapsulated by a union as the symmetric
cipher implementation is either exclusively used for "normal" symmetric
ciphers or for AEAD ciphers.

The define MAX_AEAD_ASSOCLEN restricts the size of the associated
authentication data. The kernel must allocate memory for this data to be
stored for the cipher operation. To prevent an excessive use of memory,
it is limited to 128 bytes, which is considered to be a sensible size.

Signed-off-by: Stephan Mueller 
---
 crypto/algif_skcipher.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 2f5d663..483ff97 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -46,7 +46,15 @@ struct skcipher_ctx {
bool merge;
bool enc;
 
-   struct ablkcipher_request req;
+   bool aead;
+   void *aead_assoc;
+   /* define arbitrary maximum length of associated data */
+   #define MAX_AEAD_ASSOCLEN 128
+   struct scatterlist sg_aead_assoc;
+   union {
+   struct ablkcipher_request ablkcipher_req;
+   struct aead_request aead_req;
+   } u;
 };
 
 #define MAX_SGL_ENTS ((4096 - sizeof(struct skcipher_sg_list)) / \
-- 
2.1.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 07/10] crypto: AF_ALG: add random number generator support

[Stephan Mueller]

This patch adds the random number generator support for AF_ALG.

A random number generator's purpose is to generate data without
requiring the caller to provide any data. Therefore, the AF_ALG
interface handler for RNGs only implements a callback handler for
recvmsg.

The following parameters provided with a recvmsg are processed by the
RNG callback handler:

* sock - to resolve the RNG context data structure accessing the
  RNG instance private to the socket

* len - this parameter allows userspace callers to specify how
  many random bytes the RNG shall produce and return. As the
  kernel context for the RNG allocates a buffer of 128 bytes to
  store random numbers before copying them to userspace, the len
  parameter is checked that it is not larger than 128. If a
  caller wants more random numbers, a new request for recvmsg
  shall be made.

The size of 128 bytes is chose because of the following considerations:

* to increase the memory footprint of the kernel too much (note,
  that would be 128 bytes per open socket)

* 128 is divisible by any typical cryptographic block size an
  RNG may have

* A request for random numbers typically only shall supply small
  amount of data like for keys or IVs that should only require
  one invocation of the recvmsg function.

Note, during instantiation of the RNG, the code checks whether the RNG
implementation requires seeding. If so, the RNG is seeded with output
from get_random_bytes.

A fully working example using all aspects of the RNG interface is
provided at http://www.chronox.de/libkcapi.html

Signed-off-by: Stephan Mueller 
---
 crypto/algif_rng.c | 186 +
 1 file changed, 186 insertions(+)
 create mode 100644 crypto/algif_rng.c

diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
new file mode 100644
index 000..fc25869
--- /dev/null
+++ b/crypto/algif_rng.c
@@ -0,0 +1,186 @@
+/*
+ * algif_rng: User-space interface for random number generators
+ *
+ * This file provides the user-space API for random number generators.
+ *
+ * Copyright (C) 2014, Stephan Mueller 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, and the entire permission notice in its entirety,
+ *including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ *products derived from this software without specific prior
+ *written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL2
+ * are required INSTEAD OF the above restrictions.  (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Stephan Mueller ");
+MODULE_DESCRIPTION("User-space interface for random number generators");
+
+struct rng_ctx {
+#define MAXSIZE 128
+   u8 result[MAXSIZE];
+   unsigned int len;
+   struct crypto_rng *drng;
+};
+
+static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
+  struct msghdr *msg, size_t len, int flags)
+{
+   struct sock *sk = sock->sk;
+   struct alg_sock *ask = alg_sk(sk);
+   struct rng_ctx *ctx = ask->private;
+   int err = -EFAULT;
+
+   if (len == 0)
+   return 0;
+   if (len > MAXSIZE)
+   len = MAXSIZE;
+
+   lock_sock(sk);
+   len = crypto_rng_get_bytes(ctx->drng, ctx->result, len);
+   if (len < 0)
+   goto unlock;
+
+   err = memcpy_toiovec(msg->msg_iov, 

[PATCH v2 05/10] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

This patch adds the AEAD support for AF_ALG.

The AEAD implementation uses the entire memory handling and
infrastructure of the existing skcipher implementation.

To use AEAD, the user space consumer has to use the salg_type named
"aead". The AEAD extension only uses the bind callback as the key
differentiator. The previously added functions that select whether to
use AEAD or ablkcipher crypto API functions depend on the TFM type
allocated during the bind() call.

The addition of AEAD brings a bit of overhead to calculate the size of
the ciphertext, because the AEAD implementation of the kernel crypto API
makes implied assumption on the location of the authentication tag. When
performing an encryption, the tag will be added to the created
ciphertext (note, the tag is placed adjacent to the ciphertext). For
decryption, the caller must hand in the ciphertext with the tag appended
to the ciphertext. Therefore, the selection of the used memory
needs to add/subtract the tag size from the source/destination buffers
depending on the encryption type. The code is provided with comments
explainint when and how that operation is performed.

Note: The AF_ALG interface does not support zero length plaintext or
zero length ciphertext. Such zero length input data may be used if one
wants to access the hash implementation of an AEAD directly (e.g. the
GHASH of GCM or CMAC for CCM). However, this is a use case that is not
of interest. GHASH or CMAC is directly available via the hash AF_ALG
interface and we therefore do not need to take precautions for this
use case.

A fully working example using all aspects of AEAD is provided at
http://www.chronox.de/libkcapi.html

Signed-off-by: Stephan Mueller 
---
 crypto/algif_skcipher.c | 155 
 1 file changed, 145 insertions(+), 10 deletions(-)

diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index d0e31ab..4bb7556 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -49,7 +49,7 @@ struct skcipher_ctx {
bool aead;
void *aead_assoc;
/* define arbitrary maximum length of associated data */
-   #define MAX_AEAD_ASSOCLEN 128
+#define MAX_AEAD_ASSOCLEN 128
struct scatterlist sg_aead_assoc;
union {
struct ablkcipher_request ablkcipher_req;
@@ -387,6 +387,17 @@ static int skcipher_sendmsg(struct kiocb *unused, struct 
socket *sock,
 
if (con.iv && con.iv->ivlen != ivsize)
return -EINVAL;
+
+   /*
+* AEAD associated data is limited to a sensible size
+* Size limit is set to some arbitrary length to avoid
+* user space eating up memory
+*/
+   if (ctx->aead &&
+   (con.aead_assoc->aead_assoclen > MAX_AEAD_ASSOCLEN ||
+!con.aead_assoc->aead_assoclen ||
+!con.aead_assoc || !con.aead_authsize))
+   return -EINVAL;
}
 
err = -EINVAL;
@@ -399,6 +410,25 @@ static int skcipher_sendmsg(struct kiocb *unused, struct 
socket *sock,
ctx->enc = enc;
if (con.iv)
memcpy(ctx->iv, con.iv->iv, ivsize);
+   /* AEAD authentication data handling */
+   if (ctx->aead) {
+   if (con.aead_authsize)
+   err = crypto_aead_setauthsize(
+   crypto_aead_reqtfm(>u.aead_req),
+  con.aead_authsize);
+   if (err)
+   goto unlock;
+   /* set associated data */
+   memcpy(ctx->aead_assoc,
+  con.aead_assoc->aead_assoc,
+  con.aead_assoc->aead_assoclen);
+   sg_init_one(>sg_aead_assoc,
+   ctx->aead_assoc,
+   con.aead_assoc->aead_assoclen);
+   aead_request_set_assoc(>u.aead_req,
+  >sg_aead_assoc,
+  con.aead_assoc->aead_assoclen);
+   }
}
 
while (size) {
@@ -547,10 +577,41 @@ static int skcipher_recvmsg(struct kiocb *unused, struct 
socket *sock,
int err = -EAGAIN;
int used;
long copied = 0;
+   unsigned int aead_authsize_enc = 0;
+   unsigned int aead_authsize_dec = 0;
 
lock_sock(sk);
+   /*
+   * AEAD memory structure: For encryption, the tag is appended to the
+   * ciphertext which implies that the memory allocated for the ciphertext
+   * must be increased by the tag length. For decryption, the tag
+   * is expected to be concatenated to the ciphertext. The plaintext
+   * therefore has a memory size of the ciphertext minus the 

[PATCH v2 02/10] crypto: AF_ALG: user space interface for cipher info

[Stephan Mueller]

The AF_ALG interface allows normal cipher (hash, encrypt, decrypt).
However, it does not allow user space to obtain the following generic
information about the currently active cipher:

* block size of the cipher

* IV size of the cipher

* for AEAD, the maximum authentication tag size

The patch adds a getsockopt interface for the symmetric ciphers to
answer such information requests from user space.

The kernel crypto API function calls are used to obtain the real data.
As all data are simple integer values, the getsockopt handler function
uses put_user() to return the integer value to user space in the
*optval parameter of getsockopt.

Signed-off-by: Stephan Mueller 
---
 crypto/algif_skcipher.c | 46 -
 include/uapi/linux/if_alg.h |  7 +++
 2 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 85e3bdb..2f5d663 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -522,6 +522,50 @@ static unsigned int skcipher_poll(struct file *file, 
struct socket *sock,
return mask;
 }
 
+static int skcipher_getsockopt(struct socket *sock, int level, int optname,
+  char __user *optval, int __user *optlen)
+{
+   struct sock *sk = sock->sk;
+   struct alg_sock *ask = alg_sk(sk);
+   struct skcipher_ctx *ctx = ask->private;
+   const struct af_alg_type *type;
+   int len = 0;
+   int err = -EOPNOTSUPP;
+
+   lock_sock(sk);
+   type = ask->type;
+
+   if (level != SOL_ALG || !type)
+   goto unlock;
+
+   switch (optname) {
+   case ALG_GET_BLOCKSIZE:
+   len = skcipher_crypto_blocksize(ctx);
+   err = 0;
+   break;
+   case ALG_GET_IVSIZE:
+   len = skcipher_crypto_ivsize_ctx(ctx);
+   err = 0;
+   break;
+   case ALG_GET_AEAD_AUTHSIZE:
+   if (ctx->aead) {
+   len = crypto_aead_authsize(crypto_aead_reqtfm(
+  >u.aead_req));
+   err = 0;
+   }
+   break;
+   default:
+   break;
+   }
+
+unlock:
+   release_sock(sk);
+   if (err >= 0)
+   err = put_user(len, optlen);
+
+   return err;
+}
+
 static struct proto_ops algif_skcipher_ops = {
.family =   PF_ALG,
 
@@ -531,7 +575,6 @@ static struct proto_ops algif_skcipher_ops = {
.ioctl  =   sock_no_ioctl,
.listen =   sock_no_listen,
.shutdown   =   sock_no_shutdown,
-   .getsockopt =   sock_no_getsockopt,
.mmap   =   sock_no_mmap,
.bind   =   sock_no_bind,
.accept =   sock_no_accept,
@@ -542,6 +585,7 @@ static struct proto_ops algif_skcipher_ops = {
.sendpage   =   skcipher_sendpage,
.recvmsg=   skcipher_recvmsg,
.poll   =   skcipher_poll,
+   .getsockopt =   skcipher_getsockopt,
 };
 
 static void *skcipher_bind(const char *name, u32 type, u32 mask)
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index 64e7008..b8fb714 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -40,8 +40,15 @@ struct af_alg_aead_assoc {
 #define ALG_SET_AEAD_ASSOC 4
 #define ALG_SET_AEAD_AUTHSIZE  5
 
+/* getsockopt options */
+#define ALG_GET_BLOCKSIZE  1
+#define ALG_GET_IVSIZE 2
+#define ALG_GET_AEAD_AUTHSIZE  3
+
 /* Operations */
 #define ALG_OP_DECRYPT 0
 #define ALG_OP_ENCRYPT 1
 
+
+
 #endif /* _LINUX_IF_ALG_H */
-- 
2.1.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 04/10] crypto: AF_ALG: crypto API calls to inline functions

[Stephan Mueller]

To avoid excessive branches and cluttering the code, all kernel crypto
API calls are extracted into separate inline functions. These functions
invoke either the ablkcipher or the aead crypto API function calls, as
necessary.

Signed-off-by: Stephan Mueller 
---
 crypto/algif_skcipher.c | 143 ++--
 1 file changed, 125 insertions(+), 18 deletions(-)

diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 483ff97..d0e31ab 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -247,14 +247,121 @@ static void skcipher_data_wakeup(struct sock *sk)
rcu_read_unlock();
 }
 
+static inline bool skcipher_is_aead(struct crypto_tfm *tfm)
+{
+   return ((crypto_tfm_alg_type(tfm) & CRYPTO_ALG_TYPE_MASK) ==
+   CRYPTO_ALG_TYPE_AEAD);
+}
+
+static inline unsigned int skcipher_crypto_ivsize(void *private)
+{
+   if (skcipher_is_aead(private))
+   return crypto_aead_ivsize(private);
+   else
+   return crypto_ablkcipher_ivsize(private);
+}
+
+static inline unsigned int skcipher_crypto_ivsize_ctx(struct skcipher_ctx *ctx)
+{
+   if (ctx->aead)
+   return crypto_aead_ivsize(crypto_aead_reqtfm(>u.aead_req));
+   else
+   return crypto_ablkcipher_ivsize(
+   crypto_ablkcipher_reqtfm(>u.ablkcipher_req));
+}
+
+static inline unsigned int skcipher_crypto_blocksize(struct skcipher_ctx *ctx)
+{
+   if (ctx->aead)
+   return crypto_aead_blocksize(
+   crypto_aead_reqtfm(>u.aead_req));
+   else
+   return crypto_ablkcipher_blocksize(
+   crypto_ablkcipher_reqtfm(>u.ablkcipher_req));
+}
+
+static inline unsigned int skcipher_crypto_reqsize(void *private)
+{
+   if (skcipher_is_aead(private))
+   return crypto_aead_reqsize(private);
+   else
+   return crypto_ablkcipher_reqsize(private);
+}
+
+static inline unsigned int skcipher_crypto_setkey(void *private, const u8 *key,
+ unsigned int keylen)
+{
+   if (skcipher_is_aead(private))
+   return crypto_aead_setkey(private, key, keylen);
+   else
+   return crypto_ablkcipher_setkey(private, key, keylen);
+}
+
+static inline void skcipher_crypto_free(void *private)
+{
+   if (skcipher_is_aead(private))
+   crypto_free_aead(private);
+   else
+   crypto_free_ablkcipher(private);
+}
+
+static inline void skcipher_request_set_tfm(struct skcipher_ctx *ctx, void 
*tfm)
+{
+   if (ctx->aead)
+   aead_request_set_tfm(>u.aead_req, tfm);
+   else
+   ablkcipher_request_set_tfm(>u.ablkcipher_req, tfm);
+}
+
+static inline int skcipher_crypto_encrypt(struct skcipher_ctx *ctx)
+{
+   if (ctx->aead)
+   return crypto_aead_encrypt(>u.aead_req);
+   else
+   return crypto_ablkcipher_encrypt(>u.ablkcipher_req);
+}
+
+static inline int skcipher_crypto_decrypt(struct skcipher_ctx *ctx)
+{
+   if (ctx->aead)
+   return crypto_aead_decrypt(>u.aead_req);
+   else
+   return crypto_ablkcipher_decrypt(>u.ablkcipher_req);
+}
+
+static inline void skcipher_crypto_set_crypt(struct skcipher_ctx *ctx,
+struct scatterlist *src,
+struct scatterlist *dst,
+unsigned int cryptlen, u8 *iv)
+{
+   if (ctx->aead)
+   return aead_request_set_crypt(>u.aead_req, src, dst,
+ cryptlen, iv);
+   else
+   return ablkcipher_request_set_crypt(>u.ablkcipher_req, src,
+   dst, cryptlen, iv);
+}
+
+static inline void skcipher_request_set_callback(struct skcipher_ctx *ctx,
+u32 flags,
+crypto_completion_t complete,
+void *data)
+{
+   if (ctx->aead)
+   aead_request_set_callback(>u.aead_req, flags, complete,
+ data);
+   else
+   ablkcipher_request_set_callback(>u.ablkcipher_req, flags,
+   complete, data);
+}
+
 static int skcipher_sendmsg(struct kiocb *unused, struct socket *sock,
struct msghdr *msg, size_t size)
 {
struct sock *sk = sock->sk;
struct alg_sock *ask = alg_sk(sk);
struct skcipher_ctx *ctx = ask->private;
-   struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(>req);
-   unsigned ivsize = crypto_ablkcipher_ivsize(tfm);
+   unsigned ivsize = skcipher_crypto_ivsize_ctx(ctx);
struct skcipher_sg_list *sgl;
struct af_alg_control con = {};
long 

[PATCH v2 06/10] crypto: AF_ALG: make setkey optional

[Stephan Mueller]

The current AF_ALG implementation requires that a userspace interface
implementation must provide a callback for setkey. Such a call is not
appliable to random number generators.

To prepare AF_ALG for the addition of a random number generator user
space interface, this function callback invocation is made optional.

Signed-off-by: Stephan Mueller 
---
 crypto/af_alg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 635140b..47a199c 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -177,6 +177,9 @@ static int alg_setkey(struct sock *sk, char __user *ukey,
u8 *key;
int err;
 
+   if (!type->setkey)
+   return -EOPNOTSUPP;
+
key = sock_kmalloc(sk, keylen, GFP_KERNEL);
if (!key)
return -ENOMEM;
-- 
2.1.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel:signal.c Fix coding style errors and warnings.

[Al Viro]

On Fri, Nov 14, 2014 at 05:56:55PM +0200, Ionut Alexa wrote:
> Fix various coding style errors and warnings as:
> - space before tabs
> - exiting a function from different points (else after return
>   ..)

How the hell is that goto any better than plain return?  Because some
moronic script^W^Wholy oracle says so?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 09/10] crypto: AF_ALG: user space interface for hash info

[Stephan Mueller]

The AF_ALG interface allows normal cipher (hash, encrypt, decrypt).
However, it does not allow user space to obtain the following generic
information about the currently active hash:

* digestsize

The patch adds a getsockopt interface for the hash ciphers to
answer such information requests from user space.

The kernel crypto API function calls are used to obtain the real data.
As all data are simple integer values, the getsockopt handler function
uses put_user() to return the integer value to user space in the
*optval parameter of getsockopt.

A fully working example using the digestsize interface is provided at
http://www.chronox.de/libkcapi.html

Signed-off-by: Stephan Mueller 
---
 crypto/algif_hash.c | 35 ++-
 include/uapi/linux/if_alg.h |  1 +
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index f75db4c..68ae34c 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -216,6 +216,39 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags)
return err;
 }
 
+static int hash_getsockopt(struct socket *sock, int level, int optname,
+  char __user *optval, int __user *optlen)
+{
+   struct sock *sk = sock->sk;
+   struct alg_sock *ask = alg_sk(sk);
+   struct hash_ctx *ctx = ask->private;
+   const struct af_alg_type *type;
+   int len = 0;
+   int err = -EOPNOTSUPP;
+
+   lock_sock(sk);
+   type = ask->type;
+
+   if (level != SOL_ALG || !type)
+   goto unlock;
+
+   switch (optname) {
+   case ALG_GET_DIGESTSIZE:
+   len = crypto_ahash_digestsize(crypto_ahash_reqtfm(>req));
+   err = 0;
+   break;
+   default:
+   break;
+   }
+
+unlock:
+   release_sock(sk);
+   if (err >= 0)
+   err = put_user(len, optlen);
+
+   return err;
+}
+
 static struct proto_ops algif_hash_ops = {
.family =   PF_ALG,
 
@@ -225,7 +258,6 @@ static struct proto_ops algif_hash_ops = {
.ioctl  =   sock_no_ioctl,
.listen =   sock_no_listen,
.shutdown   =   sock_no_shutdown,
-   .getsockopt =   sock_no_getsockopt,
.mmap   =   sock_no_mmap,
.bind   =   sock_no_bind,
.setsockopt =   sock_no_setsockopt,
@@ -236,6 +268,7 @@ static struct proto_ops algif_hash_ops = {
.sendpage   =   hash_sendpage,
.recvmsg=   hash_recvmsg,
.accept =   hash_accept,
+   .getsockopt =   hash_getsockopt,
 };
 
 static void *hash_bind(const char *name, u32 type, u32 mask)
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index b8fb714..3759d3c 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -44,6 +44,7 @@ struct af_alg_aead_assoc {
 #define ALG_GET_BLOCKSIZE  1
 #define ALG_GET_IVSIZE 2
 #define ALG_GET_AEAD_AUTHSIZE  3
+#define ALG_GET_DIGESTSIZE 4
 
 /* Operations */
 #define ALG_OP_DECRYPT 0
-- 
2.1.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Josh Triplett]

On November 15, 2014 6:05:11 PM PST, Theodore Ts'o  wrote:
>On Sat, Nov 15, 2014 at 12:20:42PM -0800, Josh Triplett wrote:
>> > However, sudoers seems to allow negative group matches.  So maybe
>> > allowing this only with no_new_privs already set would make sense.
>> 
>> Sigh, bad sudo.  Sure, restricting this to no_new_privs only seems
>fine.
>> I'll do that in v2, and document that in the manpage.
>
>I've also seen use cases (generally back in the bad old days of big
>timesharing VAX 750's :-) where the system admin might assign someone
>to the "games-abusers" group, and then set /usr/games to mode 705
>root:games-abusers --- presumably because it's easier to add a few
>people to the deny list rather than having to add all of the EECS
>department to the games group minus the abusers.
>
>So arbitrarily anyone to drop groups from their supplemental group
>list will result in a change from both existing practice and legacy
>Unix systems, and it could potentially lead to a security exposure.

As Andy pointed out, you can already do that with a user namespace, for any 
case not involving a setuid or setgid (or otherwise privilege-gaining) program. 
 And requiring no_new_privs handles that.

Given the combination of those two things, do you still see any problematic 
cases?

- Josh Triplett

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

[Jiang Liu]

Hi Guenter,
Could you please help to provide the config file and
error messages?
Thanks!
Gerry

On 2014/11/16 5:19, Guenter Roeck wrote:
> On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20141113:
>>
>> New tree: overlayfs
>>
>> The idle tree gained a conflict against Linus' tree.
>>
>> The scsi tree gained a conflict against the usb tree.
>>
>> Non-merge commits (relative to Linus' tree): 6264
>>  6509 files changed, 209171 insertions(+), 167101 deletions(-)
>>
> 
> I bisected the x86-nosmp qemu runtime failure I have seen for
> the last few days. Here is the result:
> 
> bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
> commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
> Author: Jiang Liu 
> Date:   Mon Oct 27 16:12:06 2014 +0800
> 
> x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC
> 
> Detailed log:
> 
> git bisect start 'HEAD' 'v3.18-rc4'
> # good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking 
> branch 'sound-asoc/for-next'
> git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
> # bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking 
> branch 'usb-serial/usb-next'
> git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
> # bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking 
> branch 'kvm/linux-next'
> git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
> # good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking 
> branch 'audit/next'
> git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
> # bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
> git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
> # good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
> git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
> # bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
> git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
> # good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
> __clear_irq_vector() with vector_lock
> git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
> # bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
> access irq_cfg data structure associated with IRQ
> git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
> # good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
> related code from io_apic.c into htirq.c
> git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
> # bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and 
> HT_IRQ indepenent of X86_IO_APIC
> git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
> # good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
> initialization routines from io_apic.c into vector.c
> git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
> # first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
> MSI and HT_IRQ indepenent of X86_IO_APIC
> 
> I'll be happy to provide the configuration if needed.
> 
> Guenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: samsung: Fix serial config dependencies for exynos7

[Abhilash Kesavan]

Hello Greg,

On Tue, Nov 11, 2014 at 7:55 PM, Abhilash Kesavan
 wrote:
> Hi Greg,
>
> On Tue, Sep 30, 2014 at 8:02 PM, Abhilash Kesavan
>  wrote:
>> Hi Tomasz,
>>
>> On Tue, Sep 30, 2014 at 4:08 AM, Tomasz Figa  wrote:
>>> Hi Abhilash,
>>>
>>> The patch itself seems fine, but I wonder if those config options aren't
>>> really just leftovers from the past and couldn't be completely removed.
>>>
>>> On 29.09.2014 07:16, Abhilash Kesavan wrote:
 From: Pankaj Dubey 

 Exynos7 has a similar serial controller to that present in older Samsung
 SoCs. To re-use the existing serial driver on Exynos7 we need to have
 SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
 possible because these symbols are dependent on PLAT_SAMSUNG which is
 not present for the ARMv8 based exynos7.

 Change the dependency of these symbols from PLAT_SAMSUNG to the serial
 driver thus making it available on exynos7. As the existing platform
 specific code making use of these symbols is related to uart driver this
 change in dependency should not cause any issues.

 Signed-off-by: Pankaj Dubey 
 Signed-off-by: Naveen Krishna Chatradhi 
 Signed-off-by: Abhilash Kesavan 
 Cc: Greg Kroah-Hartman 
 ---
 Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig
 with and without the serial driver enabled.

  drivers/tty/serial/Kconfig |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
 index 81f6ee7..e6c0bcb 100644
 --- a/drivers/tty/serial/Kconfig
 +++ b/drivers/tty/serial/Kconfig
 @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG

  config SERIAL_SAMSUNG_UARTS_4
   bool
 - depends on PLAT_SAMSUNG
 + depends on SERIAL_SAMSUNG
   default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
 CPU_S3C2442)
   help
 Internal node for the common case of 4 Samsung compatible UARTs
>>>
>>> The only place where this symbol is used is below.
>>>

  config SERIAL_SAMSUNG_UARTS
   int
 - depends on PLAT_SAMSUNG
 + depends on SERIAL_SAMSUNG
   default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
   default 3
   help

>>>
>>> With this symbol the situation isn't that easy, but still should be
>>> manageable.
>>>
>>> Looking at the serial-samsung driver, all occurrences of
>>> CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
>>> defined number equal to the maximum value - in this case 4.
>>>
>>> There are also two places in arch/arm where this symbol is used:
>>>
>>> 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
>>> ports which need suspend/resume handling. Since on s3c64xx the number is
>>> always 4, it can be simply defined locally as a constant.
>>>
>>> 2) In arch/arm/plat-samsung/init.c it is used to determine size of a
>>> static array of UART ports and to check whether the UART driver is
>>> enabled. In former case I believe it should be safe to hardcode it to 4
>>> as well, in latter CONFIG_SERIAL_SAMSUNG can be used.
>>
>> I will post patches removing these two symbols.
>
> I posted a couple of patches handling Tomasz' comments but Kukjin
> prefers the approach in this patch (Discussion here:
> http://www.spinics.net/lists/linux-samsung-soc/msg38742.html).
> Can you please review the patch.

This is a gentle reminder. The patch is required for serial enablement
on the new exynos7 SoC, kindly take a look.

Thanks,
Abhilash
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Theodore Ts'o]

On Sat, Nov 15, 2014 at 12:20:42PM -0800, Josh Triplett wrote:
> > However, sudoers seems to allow negative group matches.  So maybe
> > allowing this only with no_new_privs already set would make sense.
> 
> Sigh, bad sudo.  Sure, restricting this to no_new_privs only seems fine.
> I'll do that in v2, and document that in the manpage.

I've also seen use cases (generally back in the bad old days of big
timesharing VAX 750's :-) where the system admin might assign someone
to the "games-abusers" group, and then set /usr/games to mode 705
root:games-abusers --- presumably because it's easier to add a few
people to the deny list rather than having to add all of the EECS
department to the games group minus the abusers.

So arbitrarily anyone to drop groups from their supplemental group
list will result in a change from both existing practice and legacy
Unix systems, and it could potentially lead to a security exposure.

Cheers,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH] cpuidle: Use a lighter barrier in snooze_loop()

[Pranith Kumar]

Using smp_mb() here so that the bit clear is not reordered is an overkill.

It is more appropriate to use smp_mb__after_atomic() which ensures that the
bit clear is not reordered.

Signed-off-by: Pranith Kumar 
---
 drivers/cpuidle/cpuidle-powernv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index 7d3a349..b0bfcbe 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -48,7 +48,8 @@ static int snooze_loop(struct cpuidle_device *dev,
HMT_medium();
ppc64_runlatch_on();
clear_thread_flag(TIF_POLLING_NRFLAG);
-   smp_mb();
+   /* ensure bit clear is not reordered */
+   smp_mb__after_atomic();
return index;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: frequent lockups in 3.18rc4

[Dave Jones]

On Sat, Nov 15, 2014 at 04:34:05PM -0500, Dave Jones wrote:
 > On Fri, Nov 14, 2014 at 02:01:27PM -0800, Linus Torvalds wrote:
 > 
 >  > But since you say "several times a day", just for fun, can you test
 >  > the follow-up patch to that one-liner fix that Will Deacon posted
 >  > today (Subject: "[PATCH] mmu_gather: move minimal range calculations
 >  > into generic code"). That does some further cleanup in this area.
 > 
 > A few hours ago it hit the NMI watchdog again with that patch applied.
 > Incomplete trace, but it looks different based on what did make it over.
 > Different RIP at least.
 > 
 > [65155.054155] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
 > [trinity-c127:12559]
 > [65155.054573] irq event stamp: 296752
 > [65155.054589] hardirqs last  enabled at (296751): [] 
 > _raw_spin_unlock_irqrestore+0x5d/0x80
 > [65155.054625] hardirqs last disabled at (296752): [] 
 > apic_timer_interrupt+0x6a/0x80
 > [65155.054657] softirqs last  enabled at (296188): [] 
 > bdi_queue_work+0x83/0x270
 > [65155.054688] softirqs last disabled at (296184): [] 
 > bdi_queue_work+0x60/0x270
 > [65155.054721] CPU: 1 PID: 12559 Comm: trinity-c127 Not tainted 3.18.0-rc4+ 
 > #84 [loadavg: 209.68 187.90 185.33 34/431 17515]
 > [65155.054795] task: 88023f664680 ti: 8801649f task.ti: 
 > 8801649f
 > [65155.054820] RIP: 0010:[]  [] 
 > _raw_spin_unlock_irqrestore+0x5f/0x80
 > [65155.054852] RSP: 0018:8801649f3be8  EFLAGS: 0292
 > [65155.054872] RAX: 88023f664680 RBX: 0007 RCX: 
 > 0007
 > [65155.054895] RDX: 29e0 RSI: 88023f664ea0 RDI: 
 > 88023f664680
 > [65155.054919] RBP: 8801649f3bf8 R08:  R09: 
 > 
 > [65155.055956] R10:  R11:  R12: 
 > 
 > [65155.056985] R13: 8801649f3b58 R14: 9d3e7d0e R15: 
 > 03e0
 > [65155.058037] FS:  7f0dc957c700() GS:88024420() 
 > knlGS:
 > [65155.059083] CS:  0010 DS:  ES:  CR0: 80050033
 > [65155.060121] CR2: 7f0dc958e000 CR3: 00022f31e000 CR4: 
 > 001407e0
 > [65155.061152] DR0: 7f54162bc000 DR1: 7feb92c3d000 DR2: 
 > 
 > [65155.062180] DR3:  DR6: fffe0ff0 DR7: 
 > 0600
 > [65155.063202] Stack:
 > 
 > And that's all she wrote.
 > 
 >  > If Will's patch doesn't make a difference, what about reverting that
 >  > ce9ec37bddb6? Although it really *is* a "obvious bugfix", and I really
 >  > don't see why any of this would be noticeable on x86 (it triggered
 >  > issues on ARM64, but that was because ARM64 cared much more about the
 >  > exact range).
 > 
 > I'll try that next, and check in on it tomorrow.

No luck. Died even faster this time.

[  772.459481] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! 
[modprobe:31400]
[  772.459858] irq event stamp: 3362
[  772.459872] hardirqs last  enabled at (3361): [] 
context_tracking_user_enter+0x9c/0x2c0
[  772.459907] hardirqs last disabled at (3362): [] 
apic_timer_interrupt+0x6a/0x80
[  772.459937] softirqs last  enabled at (0): [] 
copy_process.part.26+0x635/0x1d80
[  772.459968] softirqs last disabled at (0): [<  (null)>]   
(null)
[  772.459996] CPU: 3 PID: 31400 Comm: modprobe Not tainted 3.18.0-rc4+ #85 
[loadavg: 207.70 163.33 92.64 11/433 31547]
[  772.460086] task: 88022f0b2f00 ti: 88019a944000 task.ti: 
88019a944000
[  772.460110] RIP: 0010:[]  [] 
context_tracking_user_enter+0x9e/0x2c0
[  772.460142] RSP: 0018:88019a947f00  EFLAGS: 0282
[  772.460161] RAX: 88022f0b2f00 RBX:  RCX: 
[  772.460184] RDX: 0001 RSI: 0001 RDI: 88022f0b2f00
[  772.460207] RBP: 88019a947f10 R08:  R09: 
[  772.460229] R10:  R11:  R12: 88019a947e90
[  772.460252] R13: 940f6d04 R14: 88019a947ec0 R15: 8802447cd640
[  772.460294] FS:  7f3b71ee4700() GS:88024460() 
knlGS:
[  772.460362] CS:  0010 DS:  ES:  CR0: 80050033
[  772.460391] CR2: 7fffdad5af58 CR3: 00011608e000 CR4: 001407e0
[  772.460424] DR0:  DR1:  DR2: 
[  772.460447] DR3:  DR6: fffe0ff0 DR7: 0400
[  772.460470] Stack:
[  772.460480]  88019a947f58 006233a8 88019a947f40 
9401429d
[  772.460512]  006233a8 0041d68a 006233a8 

[  772.460543]  006233a0 94874fa4 1008feff 
000507d93d73a434
[  772.460574] Call Trace:
[  772.461576]  [] syscall_trace_leave+0xad/0x2e0
[  772.462572]  [] int_check_syscall_exit_work+0x34/0x3d
[  772.463575] Code: f8 1c 00 84 c0 75 46 48 c7 c7 51 53 cd 94 e8 aa 23 24 00 
65 c7 04 25 f4 f8 1c 00 01 00 00 00 f6 c7 02 74 19 e8 84 43 f3 ff 53 

Re: SystemD fanboi Erich Schubert claims others have done no contributions to opensource software. (information within)

[Theodore Ts'o]

On Fri, Nov 14, 2014 at 03:24:24PM +0100, Cecil Westerhof wrote:
> Op Friday 14 Nov 2014 07:54 CET schreef George Malone:
> 
> > I expect this post to be censored, it is par for the course for
> > people like you.
> 
> Could you stop flaming? I have seen this at least ten times. This does
> beg the question: could the problem be with you?

Quite possibly, but

 +---+ .:\:\:/:/:.
 |   PLEASE DO NOT   |:.:\:\:/:/:.:   
 |  FEED THE TROLLS  |   :=.' -   - '.=:  
 |   |   '=(\ 9   9 /)='
 |   Thank you,  |  (  (_)  ) 
 |   Management  |  /`-vvv-'\ 
 +---+ / \
 |  |@@@  / /|,|\ \   
 |  |@@@ /_//  /^\  \\_\  
   @x@@x@|  | |/ WW(  (   )  )WW
   \/|  |\|   __\,,\ /,,/__
\||/ |  | |  (__Y__)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v8 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> On Friday 14 November 2014 15:11:58 Marek Szyprowski wrote:
> >
> > I assume that after all comments from previous versions, no more changes
> > are needed
> > to this patchset and I would really like to have it queued to v3.19.
> >
> > Arnd, Olof: could you take this patchset thought arm-soc tree? It already
> > contains all dependencies.
> >
> > Kukjin: could you ack this patchset?
> 
> I'd rather see this merged through Russell's tree, as most of the patches
> are for core code, and only three are for the platform.
> 
> For the exynos patches:
> 
> Acked-by: Arnd Bergmann 
> 
I'm also fine on this series for the exynos stuff:

Acked-by: Kukjin Kim 

And agree with Arnd's suggestion to handle in rmk tree.
(I think seems this has no dependency with samsung tree)

Thanks,
Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S

[Aaro Koskinen]

Hi,

On Fri, Oct 24, 2014 at 11:54:32AM +0100, Daniel Thompson wrote:
> + config DEBUG_OMAP1UART1
> + bool "Kernel low-level debugging via OMAP1 UART1"
> + depends on ARCH_OMAP1
> + select DEBUG_UART_8250
> + help
> +   Say Y here if you want kernel low-level debugging support
> +   on OMAP1 based platforms (expect OMAP730) on the UART1.
[...]
> +   on OMAP1 based platforms (expect OMAP730) on the UART2.
[...]
> +   on OMAP1 based platforms (expect OMAP730) on the UART3.
^^

Spelling again wrong. I think it was already corrected in v11?

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 02/22] irqchip: brcmstb-l2: fix error handling of irq_of_parse_and_map

[Kevin Cernekee]

From: Dmitry Torokhov 

Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.

Signed-off-by: Dmitry Torokhov 
Acked-by: Florian Fainelli 
Tested-by: Kevin Cernekee 
---
 drivers/irqchip/irq-brcmstb-l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index 4aa653a..313c2c6 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -139,9 +139,9 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
writel(0x, data->base + CPU_CLEAR);
 
data->parent_irq = irq_of_parse_and_map(np, 0);
-   if (data->parent_irq < 0) {
+   if (!data->parent_irq) {
pr_err("failed to find parent interrupt\n");
-   ret = data->parent_irq;
+   ret = -EINVAL;
goto out_unmap;
}
 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 05/22] irqchip: bcm7120-l2: Change DT binding to allow non-contiguous IRQEN/IRQSTAT

[Kevin Cernekee]

To date, all supported controllers have had the IRQEN register at offset
0x00 and the IRQSTAT register at 0x04.  So in DT we would typically see
something like:

reg = <0xf0406800 0x8>;

We still want to support this format, but we also need to support cases
where IRQEN and IRQSTAT aren't adjacent.  So, we will amend the driver to
accept an alternate format that looks like this:

reg = <0xf0406800 0x4 0xf0406804 0x4>;

i.e. if the first resource_size() == 4, assume that the first resource
points to IRQEN and that the next resource points to IRQSTAT.  If the
first resource_size() == 8, retain the current behavior.

Signed-off-by: Kevin Cernekee 
---
 .../interrupt-controller/brcm,bcm7120-l2-intc.txt  |  5 +-
 drivers/irqchip/irq-bcm7120-l2.c   | 76 +-
 2 files changed, 63 insertions(+), 18 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
index bae1f21..e3b0cba 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
@@ -55,7 +55,10 @@ Required properties:
 - compatible: should be "brcm,bcm7120-l2-intc"
 - reg: specifies the base physical address and size of the registers;
   multiple pairs may be specified, with the first pair handling IRQ offsets
-  0..31 and the second pair handling 32..63
+  0..31 and the second pair handling 32..63. A register pair may be
+  specified as either , where IRQEN lives at base+0x00 and
+  IRQSTAT lives at base+0x04, or , where the
+  address of each register is listed independently.
 - interrupt-controller: identifies the node as an interrupt controller
 - #interrupt-cells: specifies the number of cells needed to encode an interrupt
   source, should be 1.
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index e8441ee..576a92b 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,12 +31,8 @@
 
 #include "irqchip.h"
 
-/* Register offset in the L2 interrupt controller */
-#define IRQEN  0x00
-#define IRQSTAT0x04
-
 #define MAX_WORDS  4
-#define MAX_MAPPINGS   MAX_WORDS
+#define MAX_MAPPINGS   (MAX_WORDS * 2)
 #define IRQS_PER_WORD  32
 
 struct bcm7120_l2_intc_data {
@@ -128,6 +126,61 @@ static int bcm7120_l2_intc_init_one(struct device_node *dn,
return 0;
 }
 
+static int __init bcm7120_l2_intc_map_regs(struct device_node *dn,
+  struct bcm7120_l2_intc_data *data)
+{
+   unsigned int idx, n_regs = 0, gc_idx = 0;
+   void __iomem *en_reg = NULL, *stat_reg = NULL;
+
+   for (idx = 0; n_regs < MAX_WORDS * 2; idx++) {
+   struct resource res;
+   resource_size_t sz;
+   void __iomem *map_base;
+
+   if (of_address_to_resource(dn, idx, ))
+   break;
+   sz = resource_size();
+   map_base = data->map_base[idx] = ioremap(res.start, sz);
+   if (!map_base)
+   return -EINVAL;
+
+   if (n_regs % 2 == 0) {
+   /* Accept either enable + status, or just enable:
+* reg = <0x1024 0x8>;
+* reg = <0x1024 0x4 0x102c 0x4>;
+*/
+   en_reg = map_base;
+   if (sz == 8) {
+   stat_reg = map_base + 0x04;
+   n_regs += 2;
+   } else if (sz == 4) {
+   n_regs += 1;
+   continue;
+   } else {
+   return -EINVAL;
+   }
+   } else {
+   /* If the last register was enable, we're looking
+* for its corresponding status register
+*/
+   if (sz == 4) {
+   stat_reg = map_base;
+   n_regs += 1;
+   } else {
+   return -EINVAL;
+   }
+   }
+
+   data->pair_base[gc_idx] = min(en_reg, stat_reg);
+   data->en_offset[gc_idx] = en_reg - data->pair_base[gc_idx];
+   data->stat_offset[gc_idx] = stat_reg - data->pair_base[gc_idx];
+   gc_idx++;
+   }
+
+   data->n_words = gc_idx;
+   return gc_idx ? 0 : -ENOENT;
+}
+
 int __init bcm7120_l2_intc_of_init(struct device_node *dn,
 

[PATCH V2 06/22] irqchip: Add new driver for BCM7038-style level 1 interrupt controllers

[Kevin Cernekee]

This is the main peripheral IRQ controller on the BCM7xxx MIPS chips;
it has the following characteristics:

 - 64 to 160+ level IRQs
 - Atomic set/clear registers
 - Reasonably predictable register layout (N status words, then N
   mask status words, then N mask set words, then N mask clear words)
 - SMP affinity supported on most systems
 - Typically connected to MIPS IRQ 2,3,2,3 on CPUs 0,1,2,3

This driver registers one IRQ domain and one IRQ chip to cover all
instances of the block.  Up to 4 instances of the block may appear, as
it supports 4-way IRQ affinity on BCM7435.

The same block exists on the ARM BCM7xxx chips, but typically the ARM GIC
is used instead.  So this driver is primarily intended for MIPS STB chips.

Signed-off-by: Kevin Cernekee 
---
 .../interrupt-controller/brcm,bcm7038-l1-intc.txt  |  52 
 drivers/irqchip/Kconfig|   5 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-bcm7038-l1.c   | 335 +
 4 files changed, 393 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
 create mode 100644 drivers/irqchip/irq-bcm7038-l1.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
new file mode 100644
index 000..cc217b2
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
@@ -0,0 +1,52 @@
+Broadcom BCM7038-style Level 1 interrupt controller
+
+This block is a first level interrupt controller that is typically connected
+directly to one of the HW INT lines on each CPU.  Every BCM7xxx set-top chip
+since BCM7038 has contained this hardware.
+
+Key elements of the hardware design include:
+
+- 64, 96, 128, or 160 incoming level IRQ lines
+
+- Most onchip peripherals are wired directly to an L1 input
+
+- A separate instance of the register set for each CPU, allowing individual
+  peripheral IRQs to be routed to any CPU
+
+- Atomic mask/unmask operations
+
+- No polarity/level/edge settings
+
+- No FIFO or priority encoder logic; software is expected to read all
+  2-5 status words to determine which IRQs are pending
+
+Required properties:
+
+- compatible: should be "brcm,bcm7038-l1-intc"
+- reg: specifies the base physical address and size of the registers;
+  the number of supported IRQs is inferred from the size argument
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+  source, should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller(s)
+  this one is cascaded from
+- interrupts: specifies the interrupt line(s) in the interrupt-parent 
controller
+  node; valid values depend on the type of parent interrupt controller
+
+If multiple reg ranges and interrupt-parent entries are present on an SMP
+system, the driver will allow IRQ SMP affinity to be set up through the
+/proc/irq/ interface.  In the simplest possible configuration, only one
+reg range and one interrupt-parent is needed.
+
+Example:
+
+periph_intc: periph_intc@1041a400 {
+compatible = "brcm,bcm7038-l1-intc";
+reg = <0x1041a400 0x30 0x1041a600 0x30>;
+
+interrupt-controller;
+#interrupt-cells = <1>;
+
+interrupt-parent = <_intc>;
+interrupts = <2>, <3>;
+};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index afdc1f3..84070c9 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -48,6 +48,11 @@ config ATMEL_AIC5_IRQ
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
 
+config BCM7038_L1_IRQ
+   bool
+   select GENERIC_IRQ_CHIP
+   select IRQ_DOMAIN
+
 config BCM7120_L2_IRQ
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index f0909d0..fca4af9 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_TB10X_IRQC)  += irq-tb10x.o
 obj-$(CONFIG_XTENSA)   += irq-xtensa-pic.o
 obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
 obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_BCM7038_L1_IRQ)   += irq-bcm7038-l1.o
 obj-$(CONFIG_BCM7120_L2_IRQ)   += irq-bcm7120-l2.o
 obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o
 obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
diff --git a/drivers/irqchip/irq-bcm7038-l1.c b/drivers/irqchip/irq-bcm7038-l1.c
new file mode 100644
index 000..d3b8c8b
--- /dev/null
+++ b/drivers/irqchip/irq-bcm7038-l1.c
@@ -0,0 +1,335 @@
+/*
+ * Broadcom BCM7038 style Level 1 interrupt controller driver
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ * Author: Kevin Cernekee
+ *
+ * This program is free software; you can redistribute it and/or modify

[PATCH V2 07/22] MIPS: BMIPS: Fix ".previous without corresponding .section" warnings

[Kevin Cernekee]

Commit 078a55fc824c1 ("Delete __cpuinit/__CPUINIT usage from MIPS code")
removed our __CPUINIT directives, so now the ".previous" directives
are superfluous.  Remove them.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/bmips_vec.S | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/mips/kernel/bmips_vec.S b/arch/mips/kernel/bmips_vec.S
index 290c23b..8649507 100644
--- a/arch/mips/kernel/bmips_vec.S
+++ b/arch/mips/kernel/bmips_vec.S
@@ -208,7 +208,6 @@ bmips_reset_nmi_vec_end:
 END(bmips_reset_nmi_vec)
 
.setpop
-   .previous
 
 /***
  * CPU1 warm restart vector (used for second and subsequent boots).
@@ -281,5 +280,3 @@ LEAF(bmips_enable_xks01)
jr  ra
 
 END(bmips_enable_xks01)
-
-   .previous
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 10/22] MIPS: BMIPS: Allow BMIPS3300 to utilize SMP ebase relocation code

[Kevin Cernekee]

From: Jon Fraser 

BMIPS3300 processors do not have the hardware to support SMP, but with a
small tweak, the SMP ebase relocation code allows BMIPS3300-based
platforms to reuse the S2/S3 power management code from BMIPS4380-based
chips.  Normally this is as simple as adding one line to prom_init():

board_ebase_setup = _ebase_setup;

Signed-off-by: Jon Fraser 
Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 8383fa4..887c3ea 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -541,6 +541,7 @@ void bmips_ebase_setup(void)
_smp_int_vec, 0x80);
__sync();
return;
+   case CPU_BMIPS3300:
case CPU_BMIPS4380:
/*
 * 0x8000_: reset/NMI (initially in kseg1)
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 08/22] MIPS: BMIPS: Align secondary boot sequence with latest firmware releases

[Kevin Cernekee]

On some older BMIPS5200 (dual core / quad thread) platforms, the
PROM code set up CPU2/CPU3 so they would be started through an NMI
instead of through the ACTION register.  But this was incompatible with
some power management features that were later added, so the scheme was
changed so that Linux is fully responsible for booting CPU2/CPU3.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 06bb5ed..4e56911 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -213,17 +213,7 @@ static void bmips_boot_secondary(int cpu, struct 
task_struct *idle)
set_c0_brcm_cmt_ctrl(0x01);
break;
case CPU_BMIPS5000:
-   if (cpu & 0x01)
-   write_c0_brcm_action(ACTION_BOOT_THREAD(cpu));
-   else {
-   /*
-* core N thread 0 was already booted; just
-* pulse the NMI line
-*/
-   bmips_write_zscm_reg(0x210, 0xc000);
-   udelay(10);
-   bmips_write_zscm_reg(0x210, 0x00);
-   }
+   write_c0_brcm_action(ACTION_BOOT_THREAD(cpu));
break;
}
cpumask_set_cpu(cpu, _booted_mask);
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 14/22] MIPS: BMIPS: Fix L1_CACHE_SHIFT when BMIPS5000 is selected

[Kevin Cernekee]

BMIPS platforms can select multiple CPUs, in which case we'll need to
use the greatest common denominator (= 1 << 7 = 128 bytes, for the
BMIPS5000 L2).

Signed-off-by: Kevin Cernekee 
---
 arch/mips/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 3d56928..c0130ec 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1473,6 +1473,7 @@ config CPU_BMIPS
select WEAK_ORDERING
select CPU_SUPPORTS_HIGHMEM
select CPU_HAS_PREFETCH
+   select MIPS_L1_CACHE_SHIFT_7
help
  Support for BMIPS32/3300/4350/4380 and BMIPS5000 processors.
 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 18/22] MIPS: Create a helper function for DT setup

[Kevin Cernekee]

A couple of platforms register two buses and call of_platform_populate().
Move this into a common function to reduce duplication.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/include/asm/prom.h |  1 +
 arch/mips/kernel/prom.c  | 18 ++
 arch/mips/lantiq/prom.c  | 11 +--
 arch/mips/ralink/of.c| 14 ++
 4 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/mips/include/asm/prom.h b/arch/mips/include/asm/prom.h
index a9494c0..eaa2627 100644
--- a/arch/mips/include/asm/prom.h
+++ b/arch/mips/include/asm/prom.h
@@ -22,6 +22,7 @@ extern void device_tree_init(void);
 struct boot_param_header;
 
 extern void __dt_setup_arch(void *bph);
+extern int __dt_register_buses(const char *bus0, const char *bus1);
 
 #define dt_setup_arch(sym) \
 ({ \
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 5d39bb8..452d435 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -54,4 +55,21 @@ void __init __dt_setup_arch(void *bph)
 
mips_set_machine_name(of_flat_dt_get_machine_name());
 }
+
+int __init __dt_register_buses(const char *bus0, const char *bus1)
+{
+   static struct of_device_id of_ids[3];
+
+   if (!of_have_populated_dt())
+   panic("device tree not present");
+
+   strlcpy(of_ids[0].compatible, bus0, sizeof(of_ids[0].compatible));
+   strlcpy(of_ids[1].compatible, bus1, sizeof(of_ids[1].compatible));
+
+   if (of_platform_populate(NULL, of_ids, NULL, NULL))
+   panic("failed to populate DT");
+
+   return 0;
+}
+
 #endif
diff --git a/arch/mips/lantiq/prom.c b/arch/mips/lantiq/prom.c
index 7447d32..758970e 100644
--- a/arch/mips/lantiq/prom.c
+++ b/arch/mips/lantiq/prom.c
@@ -97,16 +97,7 @@ void __init prom_init(void)
 
 int __init plat_of_setup(void)
 {
-   static struct of_device_id of_ids[3];
-
-   if (!of_have_populated_dt())
-   panic("device tree not present");
-
-   strlcpy(of_ids[0].compatible, soc_info.compatible,
-   sizeof(of_ids[0].compatible));
-   strncpy(of_ids[1].compatible, "simple-bus",
-   sizeof(of_ids[1].compatible));
-   return of_platform_populate(NULL, of_ids, NULL, NULL);
+   return __dt_register_buses(soc_info.compatible, "simple-bus");
 }
 
 arch_initcall(plat_of_setup);
diff --git a/arch/mips/ralink/of.c b/arch/mips/ralink/of.c
index 7c4598c..f68115f 100644
--- a/arch/mips/ralink/of.c
+++ b/arch/mips/ralink/of.c
@@ -74,19 +74,9 @@ void __init plat_mem_setup(void)
 
 static int __init plat_of_setup(void)
 {
-   static struct of_device_id of_ids[3];
-   int len = sizeof(of_ids[0].compatible);
+   __dt_register_buses(soc_info.compatible, "palmbus");
 
-   if (!of_have_populated_dt())
-   panic("device tree not present");
-
-   strlcpy(of_ids[0].compatible, soc_info.compatible, len);
-   strlcpy(of_ids[1].compatible, "palmbus", len);
-
-   if (of_platform_populate(NULL, of_ids, NULL, NULL))
-   panic("failed to populate DT");
-
-   /* make sure ithat the reset controller is setup early */
+   /* make sure that the reset controller is setup early */
ralink_rst_init();
 
return 0;
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 11/22] MIPS: BMIPS: Mask off timer IRQs when hot-unplugging a CPU

[Kevin Cernekee]

From: Jon Fraser 

CPU interrupts need to be disabled on a cpu being taken down.
When a cpu is hot-plugged out of the system the following sequence occurs.

On the CPU where the hotplug sequence was initiated:
cpu_down
_cpu_down {
__cpu_notify(CPU_DOWN_PREPARE
__stop_machine(take_cpu_down
wait for cpu to run disable code.
__cpu_die
}

On the CPU  being disabled:
take_cpu_down
__cpu_disable {
mp_ops->cpu_disable
bmips_cpu_disable
clear_c0_status(IE_IRQ5) (added)
cpu_notify(CPU_DYING...
}

Before the cpu_notifier is called with CPU_DYING, all interrupts on the
dying cpu must be disabled.  This guarantees that before tick_notify is
called with the CPU_DYING event and sets the clock device pointer to
NULL, there can not be any more clock interrupts.

When this wasn't done, an unfortunately-timed timer interrupt sometimes
caused hangs immediately prior to system suspend:

Debug PM is not enabled. To enable partial suspend, rebuild kernel with 
CONFIG_PM_DEBUG
Pass 1 out of 1,PM: Syncing filesystems ... mode=none, tp1=done.
1, flags=5, cycle_tp=, sleep=
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: suspend of devices complete after 54.199 msecs
PM: late suspend of devices complete after 0.172 msecs
Disabling non-boot CPUs ...
SMP: CPU1 is offline
INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 0, t=62537 
jiffies)
Call Trace:
[<804baa78>] dump_stack+0x8/0x34
[<8008a2d8>] __rcu_pending+0x4b8/0x55c
[<8008adf4>] rcu_check_callbacks+0x78/0x180
[<80037830>] update_process_times+0x40/0x6c
[<80072fe4>] tick_sched_timer+0x74/0xe4
[<80050180>] __run_hrtimer.clone.30+0x64/0x140
[<80051150>] hrtimer_interrupt+0x19c/0x4bc
[<8000cdb8>] c0_compare_interrupt+0x50/0x88
[<80081b18>] handle_irq_event_percpu+0x5c/0x2f4
[<80086490>] handle_percpu_irq+0x8c/0xc0
[<800811b4>] generic_handle_irq+0x34/0x54
[<800067dc>] do_IRQ+0x18/0x2c
[<8000375c>] plat_irq_dispatch+0xd0/0x128
[<80004a04>] ret_from_irq+0x0/0x4
[<80004c40>] r4k_wait+0x20/0x40
[<80006b6c>] cpu_idle+0x98/0xf0
[<805d3988>] start_kernel+0x424/0x440

Signed-off-by: Jon Fraser 
Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 887c3ea..f7b1bee 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -375,6 +375,7 @@ static int bmips_cpu_disable(void)
 
set_cpu_online(cpu, false);
cpu_clear(cpu, cpu_callin_map);
+   clear_c0_status(IE_IRQ5);
 
local_flush_tlb_all();
local_flush_icache_range(0, ~0);
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 13/22] MIPS: Allow MIPS_CPU_SCACHE to be used with different line sizes

[Kevin Cernekee]

CONFIG_MIPS_CPU_SCACHE determines whether to build sc-mips.c.  However,
it is currently hardwired to use an L1_SHIFT of 6 (64 bytes).  Move the
L1_SHIFT selection into the CPU or SoC section so that other SoCs can
select different values.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 92033b7..3d56928 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -326,6 +326,7 @@ config MIPS_MALTA
select I8259
select MIPS_BONITO64
select MIPS_CPU_SCACHE
+   select MIPS_L1_CACHE_SHIFT_6
select PCI_GT64XXX_PCI0
select MIPS_MSC
select SWAP_IO_SPACE
@@ -1909,7 +1910,6 @@ config IP22_CPU_SCACHE
 config MIPS_CPU_SCACHE
bool
select BOARD_SCACHE
-   select MIPS_L1_CACHE_SHIFT_6
 
 config R5000_CPU_SCACHE
bool
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 15/22] MIPS: BMIPS: Let each platform customize the CPU1 IRQ mask

[Kevin Cernekee]

On some chips like bcm3384, "other stuff" gets wired up to CPU1's IE_IRQ1
input, generating spurious IRQs.  In this case we want the platform code
to be able to mask it off.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/include/asm/bmips.h | 1 +
 arch/mips/kernel/smp-bmips.c  | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/bmips.h b/arch/mips/include/asm/bmips.h
index cbacceb..30939b0 100644
--- a/arch/mips/include/asm/bmips.h
+++ b/arch/mips/include/asm/bmips.h
@@ -84,6 +84,7 @@ extern char bmips_smp_int_vec_end;
 extern int bmips_smp_enabled;
 extern int bmips_cpu_offset;
 extern cpumask_t bmips_booted_mask;
+extern unsigned long bmips_tp1_irqs;
 
 extern void bmips_ebase_setup(void);
 extern asmlinkage void plat_wired_tlb_setup(void);
diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 162391d..b8bd934 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -43,6 +43,7 @@ static int __maybe_unused max_cpus = 1;
 int bmips_smp_enabled = 1;
 int bmips_cpu_offset;
 cpumask_t bmips_booted_mask;
+unsigned long bmips_tp1_irqs = IE_IRQ1;
 
 #define RESET_FROM_KSEG0   0x80080800
 #define RESET_FROM_KSEG1   0xa0080800
@@ -257,7 +258,7 @@ static void bmips_smp_finish(void)
write_c0_compare(read_c0_count() + mips_hpt_frequency / HZ);
 
irq_enable_hazard();
-   set_c0_status(IE_SW0 | IE_SW1 | IE_IRQ1 | IE_IRQ5 | ST0_IE);
+   set_c0_status(IE_SW0 | IE_SW1 | bmips_tp1_irqs | IE_IRQ5 | ST0_IE);
irq_enable_hazard();
 }
 
@@ -387,7 +388,8 @@ void __ref play_dead(void)
 * IRQ handlers; this clears ST0_IE and returns immediately.
 */
clear_c0_cause(CAUSEF_IV | C_SW0 | C_SW1);
-   change_c0_status(IE_IRQ5 | IE_IRQ1 | IE_SW0 | IE_SW1 | ST0_IE | ST0_BEV,
+   change_c0_status(
+   IE_IRQ5 | bmips_tp1_irqs | IE_SW0 | IE_SW1 | ST0_IE | ST0_BEV,
IE_SW0 | IE_SW1 | ST0_IE | ST0_BEV);
irq_disable_hazard();
 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 22/22] MIPS: Add multiplatform BMIPS target

[Kevin Cernekee]

bmips_be_defconfig supports Linux running on the following CM and DSL
SoCs:

 - BCM3384 (BMIPS5000) cable modem application processor, BE, SMP
 - BCM3384 (BMIPS4355) cable modem "spare CPU"*, BE
 - BCM6328 (BMIPS4355) ADSL chip, BE
 - BCM6368 (BMIPS4350) ADSL chip, BE, SMP

*experimental; most configurations will require changing CONFIG_PHYSICAL_START

bmips_stb_defconfig supports Linux running on the (nominally LE) STB
chipsets:

 - BCM7125 (BMIPS4380) set-top box chip, LE, SMP
 - BCM7346 (BMIPS5000) set-top box chip, LE, SMP
 - BCM7360 (BMIPS3300) set-top box chip, LE
 - BCM7420 (BMIPS5000) set-top box chip, LE, SMP
 - BCM7425 (BMIPS5000) set-top box chip, LE, SMP

serial8250 and bcm63xx_uart do not currently coexist.  If/when this is
fixed, it will be also possible to boot the BE image on any supported STB
board configured for BE.  For now, each defconfig can only pick one UART
driver, and the BE defconfig enables bcm63xx_uart.

On these MIPS systems, endianness cannot be reconfigured at runtime.  On
STB it is sometimes offered as a board jumper or 0-ohm resistor, and
sometimes hardwired to LE only.  The CM and DSL systems always run BE.

Device Tree is used to configure the following items:

 - UART, USB, GENET peripherals
 - IRQ controllers
 - Early console base address (bcm63xx_uart only)
 - SMP or UP mode
 - MIPS counter frequency
 - Memory size / regions
 - DMA remappings
 - Kernel command line

The DT-enabled bootloader and build instructions for 3384 are posted at
https://github.com/Broadcom/aeolus .  The other chips use legacy non-DT
bootloaders, and so the kernel employs autodetection heuristics to select
a builtin DTB.

Signed-off-by: Kevin Cernekee 
---
 .../devicetree/bindings/mips/brcm/bmips.txt|   8 +
 .../devicetree/bindings/mips/brcm/soc.txt  |  21 ++
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  37 +++
 arch/mips/bmips/Makefile   |   1 +
 arch/mips/bmips/Platform   |   7 +
 arch/mips/bmips/dma.c  | 109 +
 arch/mips/bmips/irq.c  |  38 
 arch/mips/bmips/setup.c| 249 +
 arch/mips/boot/dts/Makefile|   9 +
 arch/mips/boot/dts/bcm3384_common.dtsi |  44 
 arch/mips/boot/dts/bcm3384_viper.dtsi  |  63 ++
 arch/mips/boot/dts/bcm3384_zephyr.dtsi |  82 +++
 arch/mips/boot/dts/bcm6328.dtsi|  63 ++
 arch/mips/boot/dts/bcm6368.dtsi|  89 
 arch/mips/boot/dts/bcm7125.dtsi|  99 
 arch/mips/boot/dts/bcm7346.dtsi| 174 ++
 arch/mips/boot/dts/bcm7360.dtsi| 121 ++
 arch/mips/boot/dts/bcm7420.dtsi| 142 
 arch/mips/boot/dts/bcm7425.dtsi| 174 ++
 arch/mips/boot/dts/bcm93384wvg.dts |  25 +++
 arch/mips/boot/dts/bcm93384wvg_viper.dts   |  25 +++
 arch/mips/boot/dts/bcm96368mvwg.dts|  31 +++
 arch/mips/boot/dts/bcm97125cbmb.dts|  31 +++
 arch/mips/boot/dts/bcm97346dbsmb.dts   |  58 +
 arch/mips/boot/dts/bcm97360svmb.dts|  34 +++
 arch/mips/boot/dts/bcm97420c.dts   |  44 
 arch/mips/boot/dts/bcm97425svmb.dts|  59 +
 arch/mips/boot/dts/bcm9ejtagprb.dts|  22 ++
 arch/mips/configs/bmips_be_defconfig   |  83 +++
 arch/mips/configs/bmips_stb_defconfig  |  83 +++
 arch/mips/include/asm/mach-bmips/dma-coherence.h   |  45 
 arch/mips/include/asm/mach-bmips/spaces.h  |  17 ++
 arch/mips/include/asm/mach-bmips/war.h |  24 ++
 34 files changed, 2112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/bmips.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/soc.txt
 create mode 100644 arch/mips/bmips/Makefile
 create mode 100644 arch/mips/bmips/Platform
 create mode 100644 arch/mips/bmips/dma.c
 create mode 100644 arch/mips/bmips/irq.c
 create mode 100644 arch/mips/bmips/setup.c
 create mode 100644 arch/mips/boot/dts/bcm3384_common.dtsi
 create mode 100644 arch/mips/boot/dts/bcm3384_viper.dtsi
 create mode 100644 arch/mips/boot/dts/bcm3384_zephyr.dtsi
 create mode 100644 arch/mips/boot/dts/bcm6328.dtsi
 create mode 100644 arch/mips/boot/dts/bcm6368.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7125.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7346.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7360.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7420.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7425.dtsi
 create mode 100644 arch/mips/boot/dts/bcm93384wvg.dts
 create mode 100644 arch/mips/boot/dts/bcm93384wvg_viper.dts
 create mode 100644 

[PATCH V2 21/22] MAINTAINERS: Add entry for BMIPS multiplatform kernel

[Kevin Cernekee]

Add myself as a maintainer for the new BMIPS target.

Signed-off-by: Kevin Cernekee 
---
 MAINTAINERS | 12 
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6ab20b4..e96b4ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2108,6 +2108,18 @@ S:   Maintained
 F: arch/arm/mach-bcm/*brcmstb*
 F: arch/arm/boot/dts/bcm7*.dts*
 
+BROADCOM BMIPS MIPS ARCHITECTURE
+M: Kevin Cernekee 
+M: Florian Fainelli 
+L: linux-m...@linux-mips.org
+S: Maintained
+F: arch/mips/bmips/*
+F: arch/mips/include/asm/mach-bmips/*
+F: arch/mips/kernel/*bmips*
+F: arch/mips/boot/dts/bcm*.dts*
+F: drivers/irqchip/irq-bcm7*
+F: drivers/irqchip/irq-brcmstb*
+
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
 M: Prashant Sreedharan 
 M: Michael Chan 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 16/22] MIPS: BMIPS: Add special cache handling in c-r4k.c

[Kevin Cernekee]

BMIPS435x and BMIPS438x have a single shared L1 D$ and load/store unit,
so it isn't necessary to raise IPIs to keep both CPUs coherent.

BMIPS5000 has VIPT L1 caches that handle aliases in hardware, and its I$
fills from D$.  But a special sequence with 2 SYNCs and 32 NOPs is needed
to ensure coherency.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/mm/c-r4k.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index fbcd867..dd261df 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -917,6 +917,18 @@ static inline void alias_74k_erratum(struct cpuinfo_mips 
*c)
}
 }
 
+static void b5k_instruction_hazard(void)
+{
+   __sync();
+   __sync();
+   __asm__ __volatile__(
+   "   nop; nop; nop; nop; nop; nop; nop; nop\n"
+   "   nop; nop; nop; nop; nop; nop; nop; nop\n"
+   "   nop; nop; nop; nop; nop; nop; nop; nop\n"
+   "   nop; nop; nop; nop; nop; nop; nop; nop\n"
+   : : : "memory");
+}
+
 static char *way_string[] = { NULL, "direct mapped", "2-way",
"3-way", "4-way", "5-way", "6-way", "7-way", "8-way"
 };
@@ -1683,6 +1695,37 @@ void r4k_cache_init(void)
 
coherency_setup();
board_cache_error_setup = r4k_cache_error_setup;
+
+   /*
+* Per-CPU overrides
+*/
+   switch (current_cpu_type()) {
+   case CPU_BMIPS4350:
+   case CPU_BMIPS4380:
+   /* No IPI is needed because all CPUs share the same D$ */
+   flush_data_cache_page = r4k_blast_dcache_page;
+   break;
+   case CPU_BMIPS5000:
+   /* We lose our superpowers if L2 is disabled */
+   if (c->scache.flags & MIPS_CACHE_NOT_PRESENT)
+   break;
+
+   /* I$ fills from D$ just by emptying the write buffers */
+   flush_cache_page = (void *)b5k_instruction_hazard;
+   flush_cache_range = (void *)b5k_instruction_hazard;
+   flush_cache_sigtramp = (void *)b5k_instruction_hazard;
+   local_flush_data_cache_page = (void *)b5k_instruction_hazard;
+   flush_data_cache_page = (void *)b5k_instruction_hazard;
+   flush_icache_range = (void *)b5k_instruction_hazard;
+   local_flush_icache_range = (void *)b5k_instruction_hazard;
+
+   /* Cache aliases are handled in hardware; allow HIGHMEM */
+   current_cpu_data.dcache.flags &= ~MIPS_CACHE_ALIASES;
+
+   /* Optimization: an L2 flush implicitly flushes the L1 */
+   current_cpu_data.options |= MIPS_CPU_INCLUSIVE_CACHES;
+   break;
+   }
 }
 
 static int r4k_cache_pm_notifier(struct notifier_block *self, unsigned long 
cmd,
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 20/22] MAINTAINERS: Add entry for bcm63xx/bcm33xx UDC gadget driver

[Kevin Cernekee]

This hardware shows up on the newly-supported BCM3384 cable chip, as well
as several old BCM63xx DSL chips.

Signed-off-by: Kevin Cernekee 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e5e8a55..6ab20b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2094,6 +2094,12 @@ S:   Maintained
 F: arch/arm/mach-bcm/bcm63xx.c
 F: arch/arm/include/debug/bcm63xx.S
 
+BROADCOM BCM63XX/BCM33XX UDC DRIVER
+M: Kevin Cernekee 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/usb/gadget/udc/bcm63xx_udc.*
+
 BROADCOM BCM7XXX ARM ARCHITECTURE
 M: Marc Carino 
 M: Brian Norris 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 01/22] irqchip: Update docs regarding irq_domain_add_tree()

[Kevin Cernekee]

Several drivers now use this API, including the ARM GIC driver, so remove
the outdated comment.

Signed-off-by: Kevin Cernekee 
---
 Documentation/IRQ-domain.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
index 8a8b82c..0ccd7b7 100644
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@@ -95,8 +95,7 @@ since it doesn't need to allocate a table as large as the 
largest
 hwirq number.  The disadvantage is that hwirq to IRQ number lookup is
 dependent on how many entries are in the table.
 
-Very few drivers should need this mapping.  At the moment, powerpc
-iseries is the only user.
+Very few drivers should need this mapping.
 
  No Map ===-
 irq_domain_add_nomap()
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 19/22] Documentation: DT: Add "mti" vendor prefix

[Kevin Cernekee]

We have a bunch of platforms using "mti,cpu-interrupt-controller" but
the "mti" prefix isn't documented.  Fix this.

Signed-off-by: Kevin Cernekee 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d..b2114de 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -96,6 +96,7 @@ mitsubishiMitsubishi Electric Corporation
 mosaixtech Mosaix Technologies, Inc.
 moxa   Moxa
 mplMPL AG
+mtiImagination Technologies Ltd. (formerly MIPS Technologies Inc.)
 mundoreaderMundo Reader S.L.
 murata Murata Manufacturing Co., Ltd.
 mxicy  Macronix International Co., Ltd.
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 17/22] MIPS: BMIPS: Add PRId for BMIPS5200 (Whirlwind)

[Kevin Cernekee]

This is a dual core (quad thread) BMIPS5000.  It needs a little extra
code to boot the second core (CPU2/CPU3), but for now we can treat it the
same as a single core BMIPS5000.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/include/asm/cpu.h  | 1 +
 arch/mips/kernel/cpu-probe.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index dfdc77e..de9ca43 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -142,6 +142,7 @@
 #define PRID_IMP_BMIPS3300_BUG 0x
 #define PRID_IMP_BMIPS43XX 0xa000
 #define PRID_IMP_BMIPS5000 0x5a00
+#define PRID_IMP_BMIPS5200 0x5b00
 
 #define PRID_REV_BMIPS4380_LO  0x0040
 #define PRID_REV_BMIPS4380_HI  0x006f
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 94c4a0c..5477d91 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1024,6 +1024,7 @@ static inline void cpu_probe_broadcom(struct cpuinfo_mips 
*c, unsigned int cpu)
break;
}
case PRID_IMP_BMIPS5000:
+   case PRID_IMP_BMIPS5200:
c->cputype = CPU_BMIPS5000;
__cpu_name[cpu] = "Broadcom BMIPS5000";
set_elf_platform(cpu, "bmips5000");
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 12/22] MIPS: BMIPS: Explicitly configure reset vectors prior to secondary boot

[Kevin Cernekee]

The secondary CPU's reset vector needs to be set to KSEG1 for a cold
boot (release from reset), or KSEG0 for a warm restart.  On a cold boot
KSEG0 may be unavailable (BMIPS4380), and on a warm restart KSEG1 may
be unavailable (XKS01 mode on 4380 or 5000).

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 29 -
 1 file changed, 8 insertions(+), 21 deletions(-)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index f7b1bee..162391d 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -47,6 +47,8 @@ cpumask_t bmips_booted_mask;
 #define RESET_FROM_KSEG0   0x80080800
 #define RESET_FROM_KSEG1   0xa0080800
 
+static void bmips_set_reset_vec(int cpu, u32 val);
+
 #ifdef CONFIG_SMP
 
 /* initial $sp, $gp - used by arch/mips/kernel/bmips_vec.S */
@@ -198,6 +200,9 @@ static void bmips_boot_secondary(int cpu, struct 
task_struct *idle)
pr_info("SMP: Booting CPU%d...\n", cpu);
 
if (cpumask_test_cpu(cpu, _booted_mask)) {
+   /* kseg1 might not exist if this CPU enabled XKS01 */
+   bmips_set_reset_vec(cpu, RESET_FROM_KSEG0);
+
switch (current_cpu_type()) {
case CPU_BMIPS4350:
case CPU_BMIPS4380:
@@ -207,8 +212,9 @@ static void bmips_boot_secondary(int cpu, struct 
task_struct *idle)
bmips5000_send_ipi_single(cpu, 0);
break;
}
-   }
-   else {
+   } else {
+   bmips_set_reset_vec(cpu, RESET_FROM_KSEG1);
+
switch (current_cpu_type()) {
case CPU_BMIPS4350:
case CPU_BMIPS4380:
@@ -229,31 +235,12 @@ static void bmips_boot_secondary(int cpu, struct 
task_struct *idle)
  */
 static void bmips_init_secondary(void)
 {
-   /* move NMI vector to kseg0, in case XKS01 is enabled */
-
-   void __iomem *cbr;
-   unsigned long old_vec;
-   unsigned long relo_vector;
-   int boot_cpu;
-
switch (current_cpu_type()) {
case CPU_BMIPS4350:
case CPU_BMIPS4380:
-   cbr = BMIPS_GET_CBR();
-
-   boot_cpu = !!(read_c0_brcm_cmt_local() & (1 << 31));
-   relo_vector = boot_cpu ? BMIPS_RELO_VECTOR_CONTROL_0 :
- BMIPS_RELO_VECTOR_CONTROL_1;
-
-   old_vec = __raw_readl(cbr + relo_vector);
-   __raw_writel(old_vec & ~0x2000, cbr + relo_vector);
-
clear_c0_cause(smp_processor_id() ? C_SW1 : C_SW0);
break;
case CPU_BMIPS5000:
-   write_c0_brcm_bootvec(read_c0_brcm_bootvec() &
-   (smp_processor_id() & 0x01 ? ~0x2000 : ~0x2000));
-
write_c0_brcm_action(ACTION_CLR_IPI(smp_processor_id(), 0));
break;
}
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 03/22] irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map

[Kevin Cernekee]

From: Dmitry Torokhov 

Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.

Signed-off-by: Dmitry Torokhov 
Acked-by: Florian Fainelli 
Tested-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index e7c6155..8eec8e1 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -102,9 +102,9 @@ static int bcm7120_l2_intc_init_one(struct device_node *dn,
unsigned int idx;
 
parent_irq = irq_of_parse_and_map(dn, irq);
-   if (parent_irq < 0) {
+   if (!parent_irq) {
pr_err("failed to map interrupt %d\n", irq);
-   return parent_irq;
+   return -EINVAL;
}
 
/* For multiple parent IRQs with multiple words, this looks like:
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 04/22] irqchip: bcm7120-l2: Refactor driver for arbitrary IRQEN/IRQSTAT offsets

[Kevin Cernekee]

Currently the driver assumes that REG_BASE+0x00 is the IRQ enable mask,
and REG_BASE+0x04 is the IRQ status mask.  This is true on BCM3384 and
BCM7xxx, but it is not true for some of the controllers found on BCM63xx
chips.  So we will change a couple of key assumptions:

 - Don't assume that both the IRQEN and IRQSTAT registers will be
   covered by a single ioremap() operation.

 - Don't assume any particular ordering (IRQSTAT might show up before
   IRQEN on some chips).

 - For an L2 controller with >=64 IRQs, don't assume that every
   IRQEN/IRQSTAT pair will use the same register spacing.

This patch changes the "plumbing" but doesn't yet provide a way for users
to instantiate a controller with arbitrary IRQEN/IRQSTAT offsets.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 41 +++-
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 8eec8e1..e8441ee 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -34,11 +34,15 @@
 #define IRQSTAT0x04
 
 #define MAX_WORDS  4
+#define MAX_MAPPINGS   MAX_WORDS
 #define IRQS_PER_WORD  32
 
 struct bcm7120_l2_intc_data {
unsigned int n_words;
-   void __iomem *base[MAX_WORDS];
+   void __iomem *map_base[MAX_MAPPINGS];
+   void __iomem *pair_base[MAX_WORDS];
+   int en_offset[MAX_WORDS];
+   int stat_offset[MAX_WORDS];
struct irq_domain *domain;
bool can_wake;
u32 irq_fwd_mask[MAX_WORDS];
@@ -61,7 +65,8 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
int hwirq;
 
irq_gc_lock(gc);
-   pending = irq_reg_readl(gc, IRQSTAT) & gc->mask_cache;
+   pending = irq_reg_readl(gc, b->stat_offset[idx]) &
+   gc->mask_cache;
irq_gc_unlock(gc);
 
for_each_set_bit(hwirq, , IRQS_PER_WORD) {
@@ -76,21 +81,24 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
 static void bcm7120_l2_intc_suspend(struct irq_data *d)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct bcm7120_l2_intc_data *b = gc->private;
 
irq_gc_lock(gc);
if (b->can_wake)
-   irq_reg_writel(gc, gc->mask_cache | gc->wake_active, IRQEN);
+   irq_reg_writel(gc, gc->mask_cache | gc->wake_active,
+  ct->regs.mask);
irq_gc_unlock(gc);
 }
 
 static void bcm7120_l2_intc_resume(struct irq_data *d)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
 
/* Restore the saved mask */
irq_gc_lock(gc);
-   irq_reg_writel(gc, gc->mask_cache, IRQEN);
+   irq_reg_writel(gc, gc->mask_cache, ct->regs.mask);
irq_gc_unlock(gc);
 }
 
@@ -137,9 +145,14 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
return -ENOMEM;
 
for (idx = 0; idx < MAX_WORDS; idx++) {
-   data->base[idx] = of_iomap(dn, idx);
-   if (!data->base[idx])
+   data->map_base[idx] = of_iomap(dn, idx);
+   if (!data->map_base[idx])
break;
+
+   data->pair_base[idx] = data->map_base[idx];
+   data->en_offset[idx] = IRQEN;
+   data->stat_offset[idx] = IRQSTAT;
+
data->n_words = idx + 1;
}
if (!data->n_words) {
@@ -157,7 +170,8 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
if (ret == 0 || ret == -EINVAL) {
for (idx = 0; idx < data->n_words; idx++)
__raw_writel(data->irq_fwd_mask[idx],
-data->base[idx] + IRQEN);
+data->pair_base[idx] +
+data->en_offset[idx]);
} else {
/* property exists but has the wrong number of words */
pr_err("invalid int-fwd-mask property\n");
@@ -215,11 +229,12 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
gc = irq_get_domain_generic_chip(data->domain, irq);
 
gc->unused = 0x & ~data->irq_map_mask[idx];
-   gc->reg_base = data->base[idx];
gc->private = data;
ct = gc->chip_types;
 
-   ct->regs.mask = IRQEN;
+   gc->reg_base = data->pair_base[idx];
+   ct->regs.mask = data->en_offset[idx];
+
ct->chip.irq_mask = irq_gc_mask_clr_bit;
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_ack = irq_gc_noop;
@@ -237,16 +252,16 @@ int __init bcm7120_l2_intc_of_init(struct 

[PATCH V2 09/22] MIPS: BMIPS: Introduce helper function to change the reset vector

[Kevin Cernekee]

This will need to be called from a few different places, and the logic
is starting to get a bit hairy (with the need for IPIs, CPU bug
workarounds, and hazards).

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/smp-bmips.c | 65 +++-
 1 file changed, 58 insertions(+), 7 deletions(-)

diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index 4e56911..8383fa4 100644
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int __maybe_unused max_cpus = 1;
 
@@ -43,6 +44,9 @@ int bmips_smp_enabled = 1;
 int bmips_cpu_offset;
 cpumask_t bmips_booted_mask;
 
+#define RESET_FROM_KSEG0   0x80080800
+#define RESET_FROM_KSEG1   0xa0080800
+
 #ifdef CONFIG_SMP
 
 /* initial $sp, $gp - used by arch/mips/kernel/bmips_vec.S */
@@ -463,10 +467,61 @@ static inline void bmips_nmi_handler_setup(void)
_smp_int_vec_end);
 }
 
+struct reset_vec_info {
+   int cpu;
+   u32 val;
+};
+
+static void bmips_set_reset_vec_remote(void *vinfo)
+{
+   struct reset_vec_info *info = vinfo;
+   int shift = info->cpu & 0x01 ? 16 : 0;
+   u32 mask = ~(0x << shift), val = info->val >> 16;
+
+   preempt_disable();
+   if (smp_processor_id() > 0) {
+   smp_call_function_single(0, _set_reset_vec_remote,
+info, 1);
+   } else {
+   if (info->cpu & 0x02) {
+   /* BMIPS5200 "should" use mask/shift, but it's buggy */
+   bmips_write_zscm_reg(0xa0, (val << 16) | val);
+   bmips_read_zscm_reg(0xa0);
+   } else {
+   write_c0_brcm_bootvec((read_c0_brcm_bootvec() & mask) |
+ (val << shift));
+   }
+   }
+   preempt_enable();
+}
+
+static void bmips_set_reset_vec(int cpu, u32 val)
+{
+   struct reset_vec_info info;
+
+   if (current_cpu_type() == CPU_BMIPS5000) {
+   /* this needs to run from CPU0 (which is always online) */
+   info.cpu = cpu;
+   info.val = val;
+   bmips_set_reset_vec_remote();
+   } else {
+   void __iomem *cbr = BMIPS_GET_CBR();
+
+   if (cpu == 0)
+   __raw_writel(val, cbr + BMIPS_RELO_VECTOR_CONTROL_0);
+   else {
+   if (current_cpu_type() != CPU_BMIPS4380)
+   return;
+   __raw_writel(val, cbr + BMIPS_RELO_VECTOR_CONTROL_1);
+   }
+   }
+   __sync();
+   back_to_back_c0_hazard();
+}
+
 void bmips_ebase_setup(void)
 {
unsigned long new_ebase = ebase;
-   void __iomem __maybe_unused *cbr;
 
BUG_ON(ebase != CKSEG0);
 
@@ -492,9 +547,7 @@ void bmips_ebase_setup(void)
 * 0x8000_0400: normal vectors
 */
new_ebase = 0x8400;
-   cbr = BMIPS_GET_CBR();
-   __raw_writel(0x80080800, cbr + BMIPS_RELO_VECTOR_CONTROL_0);
-   __raw_writel(0xa0080800, cbr + BMIPS_RELO_VECTOR_CONTROL_1);
+   bmips_set_reset_vec(0, RESET_FROM_KSEG0);
break;
case CPU_BMIPS5000:
/*
@@ -502,10 +555,8 @@ void bmips_ebase_setup(void)
 * 0x8000_1000: normal vectors
 */
new_ebase = 0x80001000;
-   write_c0_brcm_bootvec(0xa0088008);
+   bmips_set_reset_vec(0, RESET_FROM_KSEG0);
write_c0_ebase(new_ebase);
-   if (max_cpus > 2)
-   bmips_write_zscm_reg(0xa0, 0xa008a008);
break;
default:
return;
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 00/22] Multiplatform BMIPS kernel

[Kevin Cernekee]

This patch series implements a multiplatform target that runs on a
variety of different Broadcom chipsets based on the BMIPS CPUs.  It
evolved out of the "BMIPS updates and BCM3384 platform support"
RFC posted earlier.

V1->V2:

 - Add several more DTS files so the same kernel can boot on multiple
   chips: BCM6328, BCM6368, BCM7125, BCM7346, BCM7360, BCM7420, BCM7425,
   and as a very special bonus, the BCM3384 Viper CPU.

 - Add irq-bcm7038-l1.c to support the BCM7xxx chipsets.

 - Rename target from "bcm3384" to "bmips".

 - Change L1_CACHE_SHIFT fix so it works correctly when multiple BMIPS
   CPU types are selected.

 - Drop dependency on rejected EARLYCON_FORCE changes.

 - Delete most of my new irq.c, in favor of using the refactored
   irq-bcm7120-l2.c.

 - Add flush for BMIPS3300/BMIPS43xx readahead caches, to avoid
   non-coherency after DMA_FROM_DEVICE operations.

 - Utilize the new MIPS IRQ APIs from mips-for-linux-next.

 - Tweak docs/copyrights/maintainership.


This series is based on 3.18-rc4, plus:

http://patchwork.linux-mips.org/bundle/cernekee/bmips-multi-v2-deps/?state=*
http://marc.info/?l=linux-usb=141305106215886=2 (all 3/3)

These are all queued for tty-next / irqchip-next / usb-next.  Notably,
the proposed serial/pxa/ttyBCM coexistence changes are not required at
this time.


A couple of sample boot logs are posted here:

https://gist.github.com/cernekee/e53a6ff05292c3a78a94


checkpatch status:

The checkpatch warnings fall into two categories:

 - Undocumented DT bindings.  These SoCs use mostly-standard-looking
   peripherals (OHCI/EHCI controllers, ethernet PHYs), but it may be
   necessary to add extra code in the future to compensate for
   hardware quirks.  So the compatible string in the DTS file lists
   both the generic device name (documented) and a more specific
   identifier for the hardware present on the chip (undocumented).

 - extern declarations for the __dtb_* symbols.


Known issues:

If the lockdep checks are enabled, I see a weird IRQ state mismatch
returning from e.g. sys_execve().  CP0 STATUS shows IE disabled, but
current->hardirqs_enabled == 1.  Not sure if this is a problem with
my new code or something more general.  It only shows up on
SMP && !PREEMPT builds.

Booting a HIGHMEM MIPS kernel on a system with cache aliases may fail
if the system has >256MB of memory.  AFAICT this is a general problem
with the fallback logic in arch/mips/mm/init.c.

Many of the BCM63xx bootloaders impose severe restrictions on the kernel
size.  This tends to cause a lot of trouble booting images that include
an initramfs (because we're still missing MTD support).  One workaround
is to set CONFIG_PHYSICAL_START to a higher value, like 0x8100_.


Future work:

Many BCM7xxx boards can be freely switched between big endian and little
endian modes, with the latter being the default.  It would be nice if we
could use identical DTS files for both configurations, since the LE/BE
setting mostly doesn't affect how the peripherals work.  But currently a
few assumptions are hardcoded in there ("big-endian" USB register
properties and a hack to get the 16550 register addresses correct).  I
submitted a patch to the DT/serial lists which adds a "native-endian"
property; if this is accepted and utilized by the drivers in question, it
will go a long way toward solving this problem.

Lots of peripherals are still missing, especially flash and bcm63xx_enet.
The lack of a reboot handler is annoying; syscon-reboot probably won't work
on STB (because it requires two writes).  Some peripherals, like USB on
certain boards, need more work (possibly PHY drivers) and were left
disabled.

There are ways to retrieve other information from the legacy non-DT
bootloaders, but they're pretty hacky.  The flash configuration is among
the worst of the bunch, because these chips can have up to 4 different
flash controllers, more than one can be active at a time, and the
bootloader just passes "hints" rather than explicit partition maps.  For
specific boards it is sometimes OK to hardcode the map into the DTS file,
although most of the supported boards are user-reconfigurable and the
flash layouts may change from one bootloader version to the next.

There is currently no way to distinguish between different bcm63xx
board types (i.e. we can only identify the SoC, not the board).  There
is a way to distinguish different bcm7xxx board types, although in
practice the data source is somewhat unreliable and doesn't always convey
all of the information needed to distinguish boards with different
capabilities.

The kernel makes a few assumptions about how the bootloader has set up
Broadcom-specific registers for e.g. USB.  If/when power management
features are added, these registers will revert to their default settings
on resume, and somehow need to be set up again by Linux.

irq-bcm7120-l2.c is getting a little bloated and I'm not entirely happy
with the latest round of changes.  In particular it would be 

re: bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load

[devzero]

forwarding to lkml, as no response on netdev list so far.
 
maybe someone has a clue how to properly fix this timing issue.  the remaining 
question is about how to correctly replace readl() with inl() to make it 
compile cleanly or how eeprom_delay() is being done correctly.  inl() seems to 
be slower to complete which seems to make the driver work, but it seems it 
needs an I/O port as param but not an memory-adress. 

sorry, i`m not good at programming, but now as the problem is "basically" fixed 
there are just some tiny bits missing for a proper fix. i´m unsure if 
typecasting ee_addr is the right thing to do (i think it`s not) and if a patch 
with such typecast would have any chance for being accepted.


hi,
as i`m doing a little project with this older devices, i have come across this 
issue again and had some fun to dig deeper into it.

it`s a little bit academic, as i can do ifconfig eth0 hw ether. as a 
workaround, but it sucks to hack that into startup scripts and i also have seen 
udev not playing nicely with it.

apparently the problem is being caused by a timing issue in the natsemi driver.

i added some debug printk`s in natsemi.c -> eeprom_read() after each occurrence 
of eeprom_delay(ee_addr); , and the problem went away. 

there is a hint about timing sensitivity in the code:

/* Delay between EEPROM clock transitions.
   No extra delay is needed with 33Mhz PCI, but future 66Mhz access may need
   a delay.  Note that pre-2.0.34 kernels had a cache-alignment bug that
   made udelay() unreliable.
   The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is
   deprecated.
*/

looking at the source of natsemi-diag.c made me wonder why that utility is 
using 

#define eeprom_delay(ee_addr)   inl(ee_addr)

instead of 

#define eeprom_delay(ee_addr)   readl(ee_addr)

and apparently, that also fixes the problem (but gives a compile warning):

drivers/net/ethernet/natsemi/natsemi.c: In function âeeprom_readâ:
drivers/net/ethernet/natsemi/natsemi.c:1019:3: warning: passing argument 1 of 
âinlâ makes integer from pointer without a cast [enabled by default]
In file included from include/linux/io.h:22:0,
 from include/linux/pci.h:54,
 from drivers/net/ethernet/natsemi/natsemi.c:38:


looking at a more recent version of natsemi-diag.c ,  i even found this one:

ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c

/* Delay between EEPROM clock transitions.
   This flushes the write buffer to prevent quick double-writes.
*/
#define eeprom_delay(ee_addr)   inl(ee_addr); inl(ee_addr)

The question is how to make a proper fix, as i don`t know what to pass to inl() 
, as it seems it should not get an mmapped adress but an i/o port instead !?

"The  in*() functions return data read from the specified I/O port"

"The read*() functions read data from device memory previously mapped by 
map_memory()"

regards
roland

ps: CC driver maintainer from Kernel Maintainers file.



Roland Kletzing | 17 Dec 13:38 2012
bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load

Hello,
i recently played with my older evo t20/wyse 3235le thin clients and flashed
a linux kernel into those, apparently there seems an issue with the natsemi
driver.

after driver load (natsemi.ko) eth0 has no valid mac adress, dmesg and
ifconfig shows just zero`s: 00:00:00:00:00:00.

despite that , the nic is working fine for me (in this test setup i set the
mac manually: ifconfig eth0 hw ether de:ad:be:ef:be:ef )

apparently, the driver fails to read the proper mac from the eeprom, as
"natsemi-diag -ee" (from nictools-pci in debian squeeze) shows, that there
is a valid "Ethernet MAC Station Address" stored inside the eeprom. (see
below)

looks like a driver bug !?
does anybody have a clue what`s going wrong here?

regards
roland

#lspci

00:00.0 Host bridge: Cyrix Corporation PCI Master
00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815
(MacPhyter) Ethernet Controller
00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30)
00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua]
00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua]
00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev
06)

#dmesg |egrep "natsemi|eth"
natsemi dp8381x driver, version 2.1, Sept 11, 2006
natsemi :00:0f.0: setting latency timer to 64
natsemi eth0: NatSemi DP8381[56] at 0x401 (:00:0f.0),
00:00:00:00:00:00, IRQ 10, port TP.
eth0: DSPCFG accepted after 0 usec.
eth0: link up.
eth0: Setting full-duplex based on negotiated link capability.

#natsemi-diag -aa
natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker  scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a NatSemi DP83815 adapter at 0xf800.
 Natsemi 83815 series with station address 

Re: [PATCH v2 00/33] thermal: exynos: convert the driver to use per-SoC type operations

[Eduardo Valentin]

Hello Bartlomiej,


On Thu, Nov 13, 2014 at 04:00:55PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patch series replaces the hardware registers abstractions in
> the Exynos thermal driver by the usage of per-SoC type operations.

Good! I think the driver is a bit confusing because it has two ways of
checking features: soc based and feature flag based. Thus, removing one
is a good step.

> Such solution provides simpler, easier to understand code and

Well, that is arguable. IMO, the feature based solution is naturally
easier to understand as while reading the code, you think about the
feature not about chip / IP/ SoC versions. Besides, having soc based
approach spreads many if's in your code base.

Anyways, so far no one working in the Exynos code base has nacked your
proposal. Apart from that, the issue I had with it, as I mentioned, was
the fact that it currently has two ways of representing / checking
features. That is for sure the major issue.

> allows removal of ~250 LOCs (~11% of the whole source code) from
> the driver.  Some other driver improvements are now also possible
> thanks to these changes but are scheduled at later time (like
> consolidating code for clearing IRQs using INTCLEAR register).
> 

I am not sure I get your point here. I understand you are basing new
changes in the code on top of this series, but I don't see how this
refactoring could enable other feature implementions.


> The patchset should not cause any functionality changes.  This
> means that unless there are some bugs in the patches itself there
> should be no behavior changes for the driver (this also includes
> lack of changes in the way hardware is accessed by the driver).
> 
> All testing was done on (Exynos4412 SoC based) ODROID U3 board
> (some additional patches are needed to make the Exynos thermal
> driver work on this hardware).

Is it possible to spread testing here? I would like to have coverage for
all supported chip versions. The reasoning is because the driver
supports more than Exynos4412, and the amount of changes are
considerably big.

One thing I can do is to start testing in linux-next on this code. Thus,
I can merge it in my -next branch (which includes my -linus and -fixes
branches). But so far, it would not be queued.

My proposal is that these changes will be sent only for the 3.19 merge
window though. For 3.18 -rc's I believe it is too late. However,
to get it into 3.19, I request you to provide the testing in all
supported chips, as I mentioned. Do you think it is doable before Linus
opens 3.19 merge window?


> 
> Depends on:
> - 'next' branch of linux-soc-thermal.git kernel tree from Eduardo
> 

Thanks for attending my request.

> Changes since v1 (https://lkml.org/lkml/2014/9/18/305):
> - rebased on top of the current linux-soc-thermal kernel
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
> 
> 
> Bartlomiej Zolnierkiewicz (33):
>   thermal: exynos: remove needless triminfo_data abstraction
>   thermal: exynos: remove needless tmu_status abstraction
>   thermal: exynos: remove needless threshold_temp abstraction
>   thermal: exynos: remove needless triminfo_ctrl abstraction
>   thermal: exynos: remove needless test_mux_addr_shift abstraction
>   thermal: exynos: remove needless therm_trip_[mode,mask]_shift
> abstractions
>   thermal: exynos: remove needless therm_trip_en_shift abstraction
>   thermal: exynos: remove needless emul_temp_shift abstraction
>   thermal: exynos: remove needless emul_time_shift abstraction
>   thermal: exynos: replace tmu_irqstatus check by Exynos5440 one
>   thermal: exynos: replace tmu_pmin check by Exynos5440 one
>   thermal: exynos: simplify HW_TRIP level setting
>   thermal: exynos: replace threshold_falling check by Exynos SoC type
> one
>   thermal: exynos: remove TMU_SUPPORT_READY_STATUS flag
>   thermal: exynos: remove TMU_SUPPORT_TRIM_RELOAD flag
>   thermal: exynos: add sanitize_temp_error() helper
>   thermal: exynos: add get_th_reg() helper
>   thermal: exynos: add ->tmu_initialize method
>   thermal: exynos: add get_con_reg() helper
>   thermal: exynos: add ->tmu_control method
>   thermal: exynos: add ->tmu_read method
>   thermal: exynos: add get_emul_con_reg() helper
>   thermal: exynos: add ->tmu_set_emulation method
>   thermal: exynos: add ->tmu_clear_irqs method
>   thermal: exynos: remove TMU_SUPPORT_FALLING_TRIP flag
>   thermal: exynos: remove TMU_SUPPORT_EMUL_TIME flag
>   thermal: exynos: remove TMU_SUPPORT_EMULATION flag
>   thermal: exynos: remove TMU_SUPPORT_ADDRESS_MULTIPLE flag
>   thermal: exynos: remove TMU_SUPPORT_MULTI_INST flag
>   thermal: exynos: remove test_mux pdata field
>   thermal: exynos: remove SoC type ifdefs
>   thermal: exynos: remove __EXYNOS5420_TMU_DATA macro
>   thermal: exynos: remove exynos_tmu_data.h include
> 
>  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
>  drivers/thermal/samsung/exynos_tmu.c| 692 
> 

[PATCHv3 1/2] groups: Factor out a function to set a pre-sorted group list

[Josh Triplett]

This way, functions that already need to sort the group list need not do
so twice.

The new set_groups_sorted is intentionally not exported.

Signed-off-by: Josh Triplett 
---
v2, v3: No changes to patch 1/2.
 kernel/groups.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/kernel/groups.c b/kernel/groups.c
index 451698f..f0667e7 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -154,16 +154,26 @@ int groups_search(const struct group_info *group_info, 
kgid_t grp)
 }
 
 /**
+ * set_groups_sorted - Change a group subscription in a set of credentials
+ * @new: The newly prepared set of credentials to alter
+ * @group_info: The group list to install; must be sorted
+ */
+static void set_groups_sorted(struct cred *new, struct group_info *group_info)
+{
+   put_group_info(new->group_info);
+   get_group_info(group_info);
+   new->group_info = group_info;
+}
+
+/**
  * set_groups - Change a group subscription in a set of credentials
  * @new: The newly prepared set of credentials to alter
  * @group_info: The group list to install
  */
 void set_groups(struct cred *new, struct group_info *group_info)
 {
-   put_group_info(new->group_info);
groups_sort(group_info);
-   get_group_info(group_info);
-   new->group_info = group_info;
+   set_groups_sorted(new, group_info);
 }
 
 EXPORT_SYMBOL(set_groups);
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] getgroups.2: Document unprivileged setgroups calls

[Josh Triplett]

Signed-off-by: Josh Triplett 
---
v3: Document use of gid/egid/sgid.
v2: Document requirement for no_new_privs.

(If this doesn't end up going into 3.18, the version number in the patch will
need updating.)

 man2/getgroups.2 | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/man2/getgroups.2 b/man2/getgroups.2
index 373c204..e2b834e 100644
--- a/man2/getgroups.2
+++ b/man2/getgroups.2
@@ -81,9 +81,16 @@ to be used in a further call to
 .PP
 .BR setgroups ()
 sets the supplementary group IDs for the calling process.
-Appropriate privileges (Linux: the
+A process with the
 .B CAP_SETGID
-capability) are required.
+capability may change its supplementary group IDs arbitrarily.
+As of Linux 3.18, any process that has enabled PR_SET_NO_NEW_PRIVS (see
+.BR prctl (2))
+may drop supplementary groups, or add any of the current real UID, the current
+effective UID, or the current saved set-user-ID; adding any other group ID
+requires the
+.B CAP_SETGID
+capability.
 The
 .I size
 argument specifies the number of supplementary group IDs
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Josh Triplett]

Currently, unprivileged processes (without CAP_SETGID) cannot call
setgroups at all.  In particular, processes with a set of supplementary
groups cannot further drop permissions without obtaining elevated
permissions first.

Allow unprivileged processes to call setgroups with a subset of their
current groups; only require CAP_SETGID to add a group the process does
not currently have (either as a supplementary group, or as its gid,
egid, or sgid).

Since some privileged programs (such as sudo) allow tests for
non-membership in a group, require no_new_privs to drop group
privileges.

The kernel already maintains the list of supplementary group IDs in
sorted order, and setgroups already needs to sort the new list, so this
just requires a linear comparison of the two sorted lists.

This moves the CAP_SETGID test from setgroups into set_current_groups.

Tested via the following test program:

void run_id(void)
{
pid_t p = fork();
switch (p) {
case -1:
err(1, "fork");
case 0:
execl("/usr/bin/id", "id", NULL);
err(1, "exec");
default:
if (waitpid(p, NULL, 0) < 0)
err(1, "waitpid");
}
}

int main(void)
{
gid_t list1[] = { 1, 2, 3, 4, 5 };
gid_t list2[] = { 2, 3, 4 };
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 1");
run_id();
if (setresgid(1, 1, 1) < 0)
err(1, "setresgid");
if (setresuid(1, 1, 1) < 0)
err(1, "setresuid");
run_id();
if (setgroups(3, list2) < 0)
err(1, "setgroups 2");
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 3");
run_id();

return 0;
}

Without this patch, the test program gets EPERM from the second
setgroups call, after dropping root privileges.  With this patch, the
test program successfully drops groups 1 and 5, but then gets EPERM from
the third setgroups call, since that call attempts to add groups the
process does not currently have.

Signed-off-by: Josh Triplett 
---
v3: Allow gid, egid, or sgid.
v2: Require no_new_privs.

 kernel/groups.c | 42 +++---
 kernel/uid16.c  |  2 --
 2 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/kernel/groups.c b/kernel/groups.c
index f0667e7..5114155 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -153,6 +153,37 @@ int groups_search(const struct group_info *group_info, 
kgid_t grp)
return 0;
 }
 
+/* Return true if the group_info is a subset of the group_info of the specified
+ * credentials.  Also allow the first group_info to contain the gid, egid, or
+ * sgid of the credentials.
+ */
+static bool group_subset(const struct group_info *g1,
+const struct cred *cred2)
+{
+   const struct group_info *g2 = cred2->group_info;
+   unsigned int i, j;
+
+   for (i = 0, j = 0; i < g1->ngroups; i++) {
+   kgid_t gid1 = GROUP_AT(g1, i);
+   kgid_t gid2;
+   for (; j < g2->ngroups; j++) {
+   gid2 = GROUP_AT(g2, j);
+   if (gid_lte(gid1, gid2))
+   break;
+   }
+   if (j >= g2->ngroups || !gid_eq(gid1, gid2)) {
+   if (!gid_eq(gid1, cred2->gid)
+   && !gid_eq(gid1, cred2->egid)
+   && !gid_eq(gid1, cred2->sgid))
+   return false;
+   } else {
+   j++;
+   }
+   }
+
+   return true;
+}
+
 /**
  * set_groups_sorted - Change a group subscription in a set of credentials
  * @new: The newly prepared set of credentials to alter
@@ -189,11 +220,18 @@ int set_current_groups(struct group_info *group_info)
 {
struct cred *new;
 
+   groups_sort(group_info);
new = prepare_creds();
if (!new)
return -ENOMEM;
+   if (!(ns_capable(current_user_ns(), CAP_SETGID)
+ || (task_no_new_privs(current)
+ && group_subset(group_info, new {
+   abort_creds(new);
+   return -EPERM;
+   }
 
-   set_groups(new, group_info);
+   set_groups_sorted(new, group_info);
return commit_creds(new);
 }
 
@@ -233,8 +271,6 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user *, 
grouplist)
struct group_info *group_info;
int retval;
 
-   if (!ns_capable(current_user_ns(), CAP_SETGID))
-   return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
 
diff --git a/kernel/uid16.c b/kernel/uid16.c
index 602e5bb..b27e167 100644
--- a/kernel/uid16.c
+++ b/kernel/uid16.c
@@ -176,8 +176,6 @@ SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t 
__user *, grouplist)
struct group_info *group_info;
int retval;
 
-   if (!ns_capable(current_user_ns(), CAP_SETGID))
-   return -EPERM;
if 

Re: [PATCH] clk: rockchip: fix clock select order for usbphy480m_src

[Heiko Stübner]

Am Donnerstag, 13. November 2014, 16:11:49 schrieb Kever Yang:
> According to rk3288 trm, the mux selector locate at bit[12:11]
> of CRU_CLKSEL13_CON shows:
> 2'b00: select HOST0 USB pll clock (clk_otgphy1)
> 2'b01: select HOST1 USB pll clock (clk_otgphy2)
> 2'b10: select OTG USB pll clock   (clk_otgphy0)
> 
> The clock map is in Fig. 3-4 CRU Clock Architecture Diagram 3
> - clk_otgphy0 -> USB PHY OTG
> - clk_otgphy1 -> USB PHY host0
> - clk_otgphy2 -> USB PHY host1
> 
> Signed-off-by: Kever Yang 

applied this to my clk branch for 3.19


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/8] x86, microcode, intel: guard against misaligned microcode data

[Henrique de Moraes Holschuh]

On Thu, 13 Nov 2014, Borislav Petkov wrote:
> On Wed, Nov 12, 2014 at 10:18:47PM -0200, Henrique de Moraes Holschuh wrote:
> > The detail is that: since most Intel microcodes are bigger than the kmalloc
> > cache, most of the time kmalloc will return page-aligned addresses, which
> > don't need any alignment.
> 
> Yeah, you keep saying that. Do you have an actual proof too?

I believe so, from documention gathered through google... but I could be
wrong about this.

And since I have learned my lesson, I took your comment to mean "look
deeper".  I took the time to both try to understand somewhat the mm/ code
AND write a kernel module to do empiric testing before I wrote this reply,
instead of trusting the documentation.

And it turns out I failed at proving myself wrong, either because I am not
wrong, or by sheer unluckyness.


Important detail: intel microcodes have 1KiB size granularity, are never
smaller than 2048 bytes, and so far the largest ones are close to 64KiB.


For SLUB:

kmalloc() will do kmalloc_large() for anything > 8192 bytes and that should
return page-aligned data since it calls alloc_kmem_pages()/alloc_pages().

For 2048 bytes to 8192 bytes, we will get memory from one of the following
slabs: kmalloc-2048, kmalloc-4096 or kmalloc-8192.

As far as I could understand (and here I could easily be wrong as the mm/
slab cache code is not trivial to grok), those are going to be object-size
aligned, because the allocation size will be rounded up to the slab's object
size (i.e. 2048/4096/8192 bytes).  The objects are allocated from the start
of the slab (which is page-aligned), back-to-back.

Thus SLUB would always return 16-byte aligned memory for the size range of
Intel microcode.  In fact, it will return 2048-byte aligned memory in the
worst case (2048-byte microcode).

Empiric testing in x86-64 resulted in data compatible with the above
reasoning.


For SLAB:

SLAB is nasty to grok with a first look due to the whole complexity re. its
queues and cpu caches, and I don't think I understood the code properly.

intel microcode sized allocations end up in slabs with large objects that
are all of the same 2^n size (i.e. 2048 bytes, 4096 bytes, etc).  I could
not grok the code enough to assert what real alignment I could expect for
2KiB to 64KiB objects.

Empiric testing in x86-64 SLAB, done by allocating 63 objects of the same
size in a row, for all possible microcode sizes, did not result in a single
kmalloc() that was not sufficiently aligned, and in fact all of them were
object-size aligned, even for the smallest microcodes (2048 bytes).  I even
tried it with CONFIG_DEBUG_SLAB turned on and off to see if it changed
anything (it didn't).

So, while I didn't understand the code enough to prove that we'd mostly get
good microcode alignment out of SLAB, I couldn't get it to return pointers
that would require extra alignment either.  The worst case was 2048-byte
alignment, for microcodes with 2048 bytes.


For SLOB:

SLOB will call the page allocator for anything bigger than 4095 bytes, so
all microcodes from 4096 bytes and above will be page-aligned.

Only 2048-byte and 3072-byte microcode wouldn't go directly to the page
allocator.  This is microcode for ancient processors: Pentium M and earlier,
and the first NetBurst processors.

I didn't bother to test, but from the code, I expect that 2048-byte and
3072-byte sized microcode would *not* be aligned to 16 bytes.  However, we
have very few users of these ancient processors left.  Calling kmalloc(s);
kfree(); kmalloc(s+15); for these rare processors doesn't look like too much
of an issue IMHO.

SLOB was the only allocator that could result in microcode that needs
further alignment in my testing, and only for the small microcode (2KiB and
3KiB) of ancient processors.

> Because if this turns out wrong, we'll end up doing two allocations
> instead of one, which is dumb. My suggestion was to do one allocation
> only.

See above.  As far as I could verify, we wouldn't be doing two allocations
in the common cases.

I really don't like the idea of increasing the allocation order by one for
4KiB, 8KiB, 16KiB, 32KiB and 64KiB microcodes just to alocate 15 bytes of
extra padding that, at least as far as I could check, seem to be most often
not needed.

Note that I did not do any empiric testing on 32 bits.

> > Your version also needs to keep the original pointer around for kfree, which
> > is going to be annoying.
> > 
> > My version has the drawback that it requires the use of INTEL_UCODE_PTR(p)
> 
> Yeah, just drop that macro - use simply PTR_ALIGN and
> INTEL_MICROCODE_MINALIGN.

I will do that.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info 

Re: [PATCH] clk: rockchip: fix clk_usbphy480m_gate bit location in register

[Heiko Stübner]

Am Donnerstag, 13. November 2014, 15:19:21 schrieb Kever Yang:
> According to rk3288 trm, the clk_usbphy480m_gate is locate at
> bit 14 of CRU_CLKGATE5_CON register.
> 
> Signed-off-by: Kever Yang 

applied this to my clk branch.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] parisc architecture patches for v3.18

[Helge Deller]

Hi Linus,

please pull some patches for the parisc architecture for kernel 3.18 from 
  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
parisc-3.18-2

Changes include:
- wire up the bpf syscall
- Remove CONFIG_64BIT usage from some userspace-exported header files
- Use compat functions for msgctl, shmat, shmctl and semtimedop syscalls 

Thanks,
Helge


Helge Deller (4):
  parisc: Wire up bpf syscall
  parisc: Use BUILD_BUG() instead of undefined functions
  parisc: Use compat layer for msgctl, shmat, shmctl and semtimedop syscalls
  parisc: Avoid using CONFIG_64BIT in userspace exported headers

 arch/parisc/include/asm/uaccess.h  | 19 +++-
 arch/parisc/include/uapi/asm/bitsperlong.h |  8 +--
 arch/parisc/include/uapi/asm/msgbuf.h  |  8 ---
 arch/parisc/include/uapi/asm/sembuf.h  |  6 +++--
 arch/parisc/include/uapi/asm/shmbuf.h  | 35 +-
 arch/parisc/include/uapi/asm/signal.h  |  2 +-
 arch/parisc/include/uapi/asm/unistd.h  |  3 ++-
 arch/parisc/kernel/syscall_table.S |  9 
 8 files changed, 41 insertions(+), 49 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: frequent lockups in 3.18rc4

[Dave Jones]

On Fri, Nov 14, 2014 at 02:01:27PM -0800, Linus Torvalds wrote:

 > But since you say "several times a day", just for fun, can you test
 > the follow-up patch to that one-liner fix that Will Deacon posted
 > today (Subject: "[PATCH] mmu_gather: move minimal range calculations
 > into generic code"). That does some further cleanup in this area.

A few hours ago it hit the NMI watchdog again with that patch applied.
Incomplete trace, but it looks different based on what did make it over.
Different RIP at least.

[65155.054155] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[trinity-c127:12559]
[65155.054573] irq event stamp: 296752
[65155.054589] hardirqs last  enabled at (296751): [] 
_raw_spin_unlock_irqrestore+0x5d/0x80
[65155.054625] hardirqs last disabled at (296752): [] 
apic_timer_interrupt+0x6a/0x80
[65155.054657] softirqs last  enabled at (296188): [] 
bdi_queue_work+0x83/0x270
[65155.054688] softirqs last disabled at (296184): [] 
bdi_queue_work+0x60/0x270
[65155.054721] CPU: 1 PID: 12559 Comm: trinity-c127 Not tainted 3.18.0-rc4+ #84 
[loadavg: 209.68 187.90 185.33 34/431 17515]
[65155.054795] task: 88023f664680 ti: 8801649f task.ti: 
8801649f
[65155.054820] RIP: 0010:[]  [] 
_raw_spin_unlock_irqrestore+0x5f/0x80
[65155.054852] RSP: 0018:8801649f3be8  EFLAGS: 0292
[65155.054872] RAX: 88023f664680 RBX: 0007 RCX: 0007
[65155.054895] RDX: 29e0 RSI: 88023f664ea0 RDI: 88023f664680
[65155.054919] RBP: 8801649f3bf8 R08:  R09: 
[65155.055956] R10:  R11:  R12: 
[65155.056985] R13: 8801649f3b58 R14: 9d3e7d0e R15: 03e0
[65155.058037] FS:  7f0dc957c700() GS:88024420() 
knlGS:
[65155.059083] CS:  0010 DS:  ES:  CR0: 80050033
[65155.060121] CR2: 7f0dc958e000 CR3: 00022f31e000 CR4: 001407e0
[65155.061152] DR0: 7f54162bc000 DR1: 7feb92c3d000 DR2: 
[65155.062180] DR3:  DR6: fffe0ff0 DR7: 0600
[65155.063202] Stack:

And that's all she wrote.

 > If Will's patch doesn't make a difference, what about reverting that
 > ce9ec37bddb6? Although it really *is* a "obvious bugfix", and I really
 > don't see why any of this would be noticeable on x86 (it triggered
 > issues on ARM64, but that was because ARM64 cared much more about the
 > exact range).

I'll try that next, and check in on it tomorrow.

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: media: bcm2048: fix coding style error

[Konrad Zapalowicz]

On 11/15, Pavel Machek wrote:
> On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote:
> > On 11/15, Christian Resell wrote:
> > > Simple style fix (checkpatch.pl: "space prohibited before that ','").
> > > For the eudyptula challenge (http://eudyptula-challenge.org/).
> > 
> > Nice, however we do not need the information about the 'eudyptula
> > challenge' in the commit message.
> > 
> > If you want to include extra information please do it after the '---'
> > line (just below the signed-off). You will find more details in the
> > SubmittingPatches (chapter 15) of the kernel documentation.
> 
> Greg is staging tree maintainer... And if single extra space is all
> you can fix in the driver, perhaps it is not worth the patch?

I think that every contribution, as long as it acctually fixes
something, is worth the patch. The beauty of the open source community
is that we do when we have time as much as we are able to do - totally
no stress.

You, Pavel, are more experienced however those who are not have to learn
somehow and one of the options is to start with something very simple.
Sometimes the 'simple' means oneliner however as long as it compiles, is
inline with the coding standard and in general is an improvement then it
is good.

Regards,
Konrad
 
>   Pavel
> 
> > Thanks,
> > Konrad
> >  
> > > Signed-off-by: Christian F. Resell 
> > > ---
> > > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
> > > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > index 2bba370..bdc6854 100644
> > > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct 
> > > i2c_client *client)
> > >   *   bcm2048_i2c_driver - i2c driver interface
> > >   */
> > >  static const struct i2c_device_id bcm2048_id[] = {
> > > - { "bcm2048" , 0 },
> > > + { "bcm2048", 0 },
> > >   { },
> > >  };
> > >  MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> > > ___
> > > devel mailing list
> > > de...@linuxdriverproject.org
> > > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [V2 PATCH 01/10] added media agnostic (MA) USB HCD driver

[Alan Stern]

On Fri, 14 Nov 2014, Sean O. Stalley wrote:

> To summarize the spec:
> MA USB groups a host & connected devices into MA service sets (MSS).
> The architectural limit is 254 MA devices per MSS.
> 
> If the host needs to connect more devices than that, It can start a
> new MSS and connect to 254 more MA devices.
> 
> 
> 
> Is supporting up to 254 devices on one machine sufficient?

It's probably more than enough.

> Would it make sense (and does the usb stack support) having 254 root
> ports on one host controller? If so, we could make our host
> controller instance have 254 ports. I'm guessing the hub driver may have
> a problem with this (especially for superspeed).

The USB stack is likely to have problems if there are more than 31 
ports on any hub.

> If that doesn't make sense (or isn't supported), we can have 1 host
> controller instance per MA device. Would that be preferred?

It doesn't make much difference.  Whatever you think will be easier to 
support.  You might check and see how usbip does it.

> > Also, I noticed that your patch adds a new bus type for these MA host 
> > controllers.  It really seems like overkill to have a whole new bus 
> > type if there's only going to be one device on it.
> 
> The bus was added when we were quickly trying to replace the platform
> device code. It's probably not the right thing to do.
> 
> I'm still not sure why we can't make our hcd a platform device,
> especially since dummy_hcd & the usbip's hcd are both platform devices.

A platform device is the right way to go.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: media: bcm2048: fix coding style error

[Greg KH]

On Sat, Nov 15, 2014 at 09:59:34PM +0100, Pavel Machek wrote:
> On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote:
> > On 11/15, Christian Resell wrote:
> > > Simple style fix (checkpatch.pl: "space prohibited before that ','").
> > > For the eudyptula challenge (http://eudyptula-challenge.org/).
> > 
> > Nice, however we do not need the information about the 'eudyptula
> > challenge' in the commit message.
> > 
> > If you want to include extra information please do it after the '---'
> > line (just below the signed-off). You will find more details in the
> > SubmittingPatches (chapter 15) of the kernel documentation.
> 
> Greg is staging tree maintainer... And if single extra space is all
> you can fix in the driver, perhaps it is not worth the patch?

I am not the maintainer of drivers/staging/media/ please look at
MAINTAINERS before you make statements like that.

And yes, one space fixes is just fine, that's why the code is in
staging.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] ipc/mqueue.c: Drag unneeded code out of locks

[Davidlohr Bueso]

On Sat, 2014-11-15 at 04:44 +, Steven Stewart-Gallus wrote:
> > What's the benefit here? Seems very risky at very little gain.
> >
> > The juice ain't worth the squeeze. NAK
> 
> Hello,
> 
> It is fair to argue that these changes are too tiny to be very
> meaningful for performance but the other goal of this patch was also
> to make the code look cleaner and easier for me and other people to
> understand. I hope that is a reasonable desire.

I don't see how on earth you consider your patch makes things easier to
understand. For instance, adding local variables from structures passed
to a function does *not* make things more clearer:

+   bool too_many_open_files;
+   long msgqueue_lim;
+   unsigned long u_bytes;
+
+   msgqueue_lim = rlimit(RLIMIT_MSGQUEUE);
+
+   spin_lock(_lock);
+
+   u_bytes = u->mq_bytes;
+   too_many_open_files = u_bytes + mq_bytes < u_bytes ||
+   u_bytes + mq_bytes > msgqueue_lim;
+   if (!too_many_open_files)

Plus you add context specific regions within the function (code around
{ }), ugly and something we've been removing!

In fact it makes it *harder* to read: Now you have to keep in mind where
each variable came from, ie: u_bytes.

> It is not fair to argue that these changes are risky. 

Oh no? Andrew already found issues with the patch. But you claim there
is no risk. But hey, not getting the patch right the first time is fine,
except that the patch (i) has no tangible effects on performance, (ii)
as a cleanup, it does not make it any easier to read, (iii) can
potentially introduce bugs (yes, extra risk in subtleties when changing
critical regions and goto statements... we have had similar regressions
in ipc in the past).

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 14

[Guenter Roeck]

On Fri, Nov 14, 2014 at 07:27:38PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20141113:
> 
> New tree: overlayfs
> 
> The idle tree gained a conflict against Linus' tree.
> 
> The scsi tree gained a conflict against the usb tree.
> 
> Non-merge commits (relative to Linus' tree): 6264
>  6509 files changed, 209171 insertions(+), 167101 deletions(-)
> 

I bisected the x86-nosmp qemu runtime failure I have seen for
the last few days. Here is the result:

bb46613f7099f70bc68c1c684cfa22d6863cd8eb is the first bad commit
commit bb46613f7099f70bc68c1c684cfa22d6863cd8eb
Author: Jiang Liu 
Date:   Mon Oct 27 16:12:06 2014 +0800

x86, irq: Make MSI and HT_IRQ indepenent of X86_IO_APIC

Detailed log:

git bisect start 'HEAD' 'v3.18-rc4'
# good: [97bf3e2baed8f45432933bf15535061fb5acda44] Merge remote-tracking branch 
'sound-asoc/for-next'
git bisect good 97bf3e2baed8f45432933bf15535061fb5acda44
# bad: [d23dcf93e7ad8004ef80726717f700316e53f44d] Merge remote-tracking branch 
'usb-serial/usb-next'
git bisect bad d23dcf93e7ad8004ef80726717f700316e53f44d
# bad: [cff78d32f4c15b7b2cb173c8e6097c513f406da0] Merge remote-tracking branch 
'kvm/linux-next'
git bisect bad cff78d32f4c15b7b2cb173c8e6097c513f406da0
# good: [09dc3f20206821e06b1b281b1ae4451777f707c4] Merge remote-tracking branch 
'audit/next'
git bisect good 09dc3f20206821e06b1b281b1ae4451777f707c4
# bad: [caf0fea9e728916a92c508988fd2ae84a08c280b] Merge branch 'x86/vdso'
git bisect bad caf0fea9e728916a92c508988fd2ae84a08c280b
# good: [9aa5f98820067b00456c42347fc0ff48d2d2474f] Merge branch 'sched/urgent'
git bisect good 9aa5f98820067b00456c42347fc0ff48d2d2474f
# bad: [46fe562d914fde0a43ee339a0fcfd4af829cb8f7] Merge branch 'x86/boot'
git bisect bad 46fe562d914fde0a43ee339a0fcfd4af829cb8f7
# good: [b26ea43d0bb1539ce047206a57c7fd8d636e7f22] x86, irq: Protect 
__clear_irq_vector() with vector_lock
git bisect good b26ea43d0bb1539ce047206a57c7fd8d636e7f22
# bad: [e1d8f79a27a41493c8f1ad0bde440048e17f9494] iommu/amd: Use helpers to 
access irq_cfg data structure associated with IRQ
git bisect bad e1d8f79a27a41493c8f1ad0bde440048e17f9494
# good: [051825cab15c8180f2f0dbc3a9de5a3db7476065] x86, irq: Move HT IRQ 
related code from io_apic.c into htirq.c
git bisect good 051825cab15c8180f2f0dbc3a9de5a3db7476065
# bad: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make MSI and HT_IRQ 
indepenent of X86_IO_APIC
git bisect bad bb46613f7099f70bc68c1c684cfa22d6863cd8eb
# good: [b09198f7b59101e52bcf238ed3b7bfc64de055ef] x86, irq: Move IRQ 
initialization routines from io_apic.c into vector.c
git bisect good b09198f7b59101e52bcf238ed3b7bfc64de055ef
# first bad commit: [bb46613f7099f70bc68c1c684cfa22d6863cd8eb] x86, irq: Make 
MSI and HT_IRQ indepenent of X86_IO_APIC

I'll be happy to provide the configuration if needed.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] r8169: Use load_acquire() and store_release() to reduce memory barrier overhead

[Francois Romieu]

Alexander Duyck  :
> On 11/13/2014 01:30 PM, Francois Romieu wrote:
> > Alexander Duyck  :
> > [...]
> >> In addition the r8169 uses a rmb() however I believe it is placed 
> >> incorrectly
> >> as I assume it supposed to be ordering descriptor reads after the check for
> >> ownership.
> > Not exactly. It's a barrier against compiler optimization from 2004.
> > It should not matter.
> 
> Okay.  Do you recall the kind of problem it was you were seeing ?

Mildly, I had to grep the local archives.

The relevant code used to be included in the irq handler at that time
(napi support for this driver took place in may 2004). One did not want
a runaway loop in the Tx reaper.

Compiler optimization was suggested by Manfred Spraul in the thread below:
http://marc.info/?l=linux-kernel=108096868119004

> The origin of the rmb() for the Intel drivers was a PowerPC issue in
> which it was fetching the length of a buffer before it checked the DD
> bit (equivalent of DescOwn).  I'm wondering if the issue you were seeing
> was something similar where it had reordered reads in the descriptor to
> cause that type of result.

The problem was only reported on Intel 32 bit + slackware + gcc 3.2.3.

Adam Nielsen - Cc: added - did not return for this bug.

-- 
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Josh Triplett]

Currently, unprivileged processes (without CAP_SETGID) cannot call
setgroups at all.  In particular, processes with a set of supplementary
groups cannot further drop permissions without obtaining elevated
permissions first.

Allow unprivileged processes to call setgroups with a subset of their
current groups; only require CAP_SETGID to add a group the process does
not currently have.

Since some privileged programs (such as sudo) allow tests for
non-membership in a group, require no_new_privs to drop group
privileges.

The kernel already maintains the list of supplementary group IDs in
sorted order, and setgroups already needs to sort the new list, so this
just requires a linear comparison of the two sorted lists.

This moves the CAP_SETGID test from setgroups into set_current_groups.

Tested via the following test program:

void run_id(void)
{
pid_t p = fork();
switch (p) {
case -1:
err(1, "fork");
case 0:
execl("/usr/bin/id", "id", NULL);
err(1, "exec");
default:
if (waitpid(p, NULL, 0) < 0)
err(1, "waitpid");
}
}

int main(void)
{
gid_t list1[] = { 1, 2, 3, 4, 5 };
gid_t list2[] = { 2, 3, 4 };
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 1");
run_id();
if (setresgid(1, 1, 1) < 0)
err(1, "setresgid");
if (setresuid(1, 1, 1) < 0)
err(1, "setresuid");
run_id();
if (setgroups(3, list2) < 0)
err(1, "setgroups 2");
run_id();
if (setgroups(5, list1) < 0)
err(1, "setgroups 3");
run_id();

return 0;
}

Without this patch, the test program gets EPERM from the second
setgroups call, after dropping root privileges.  With this patch, the
test program successfully drops groups 1 and 5, but then gets EPERM from
the third setgroups call, since that call attempts to add groups the
process does not currently have.

Signed-off-by: Josh Triplett 
---
v2: Require no_new_privs.

 kernel/groups.c | 34 +++---
 kernel/uid16.c  |  2 --
 2 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/kernel/groups.c b/kernel/groups.c
index f0667e7..f7fb8dd 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -153,6 +153,29 @@ int groups_search(const struct group_info *group_info, 
kgid_t grp)
return 0;
 }
 
+/* Compare two sorted group lists; return true if the first is a subset of the
+ * second.
+ */
+static bool is_subset(const struct group_info *g1, const struct group_info *g2)
+{
+   unsigned int i, j;
+
+   for (i = 0, j = 0; i < g1->ngroups; i++) {
+   kgid_t gid1 = GROUP_AT(g1, i);
+   kgid_t gid2;
+   for (; j < g2->ngroups; j++) {
+   gid2 = GROUP_AT(g2, j);
+   if (gid_lte(gid1, gid2))
+   break;
+   }
+   if (j >= g2->ngroups || !gid_eq(gid1, gid2))
+   return false;
+   j++;
+   }
+
+   return true;
+}
+
 /**
  * set_groups_sorted - Change a group subscription in a set of credentials
  * @new: The newly prepared set of credentials to alter
@@ -189,11 +212,18 @@ int set_current_groups(struct group_info *group_info)
 {
struct cred *new;
 
+   groups_sort(group_info);
new = prepare_creds();
if (!new)
return -ENOMEM;
+   if (!(ns_capable(current_user_ns(), CAP_SETGID)
+ || (task_no_new_privs(current)
+ && is_subset(group_info, new->group_info {
+   abort_creds(new);
+   return -EPERM;
+   }
 
-   set_groups(new, group_info);
+   set_groups_sorted(new, group_info);
return commit_creds(new);
 }
 
@@ -233,8 +263,6 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user *, 
grouplist)
struct group_info *group_info;
int retval;
 
-   if (!ns_capable(current_user_ns(), CAP_SETGID))
-   return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
 
diff --git a/kernel/uid16.c b/kernel/uid16.c
index 602e5bb..b27e167 100644
--- a/kernel/uid16.c
+++ b/kernel/uid16.c
@@ -176,8 +176,6 @@ SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t 
__user *, grouplist)
struct group_info *group_info;
int retval;
 
-   if (!ns_capable(current_user_ns(), CAP_SETGID))
-   return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
 
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 manpages] getgroups.2: Document unprivileged setgroups calls

[Josh Triplett]

Signed-off-by: Josh Triplett 
---
v2: Document requirement for no_new_privs.

(If this doesn't end up going into 3.18, the version number in the patch will
need updating.)

 man2/getgroups.2 | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/man2/getgroups.2 b/man2/getgroups.2
index 373c204..3f3d330 100644
--- a/man2/getgroups.2
+++ b/man2/getgroups.2
@@ -81,9 +81,11 @@ to be used in a further call to
 .PP
 .BR setgroups ()
 sets the supplementary group IDs for the calling process.
-Appropriate privileges (Linux: the
+As of Linux 3.18, any process that has enabled PR_SET_NO_NEW_PRIVS may drop
+supplementary groups, but may not add new groups. Adding groups, or making any
+change at all without no_new_privs enabled, requires the
 .B CAP_SETGID
-capability) are required.
+capability.
 The
 .I size
 argument specifies the number of supplementary group IDs
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 1/2] groups: Factor out a function to set a pre-sorted group list

[Josh Triplett]

This way, functions that already need to sort the group list need not do
so twice.

The new set_groups_sorted is intentionally not exported.

Signed-off-by: Josh Triplett 
---
 kernel/groups.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/kernel/groups.c b/kernel/groups.c
index 451698f..f0667e7 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -154,16 +154,26 @@ int groups_search(const struct group_info *group_info, 
kgid_t grp)
 }
 
 /**
+ * set_groups_sorted - Change a group subscription in a set of credentials
+ * @new: The newly prepared set of credentials to alter
+ * @group_info: The group list to install; must be sorted
+ */
+static void set_groups_sorted(struct cred *new, struct group_info *group_info)
+{
+   put_group_info(new->group_info);
+   get_group_info(group_info);
+   new->group_info = group_info;
+}
+
+/**
  * set_groups - Change a group subscription in a set of credentials
  * @new: The newly prepared set of credentials to alter
  * @group_info: The group list to install
  */
 void set_groups(struct cred *new, struct group_info *group_info)
 {
-   put_group_info(new->group_info);
groups_sort(group_info);
-   get_group_info(group_info);
-   new->group_info = group_info;
+   set_groups_sorted(new, group_info);
 }
 
 EXPORT_SYMBOL(set_groups);
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: media: bcm2048: fix coding style error

[Pavel Machek]

On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote:
> On 11/15, Christian Resell wrote:
> > Simple style fix (checkpatch.pl: "space prohibited before that ','").
> > For the eudyptula challenge (http://eudyptula-challenge.org/).
> 
> Nice, however we do not need the information about the 'eudyptula
> challenge' in the commit message.
> 
> If you want to include extra information please do it after the '---'
> line (just below the signed-off). You will find more details in the
> SubmittingPatches (chapter 15) of the kernel documentation.

Greg is staging tree maintainer... And if single extra space is all
you can fix in the driver, perhaps it is not worth the patch?

Pavel

> Thanks,
> Konrad
>  
> > Signed-off-by: Christian F. Resell 
> > ---
> > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
> > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > index 2bba370..bdc6854 100644
> > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct 
> > i2c_client *client)
> >   * bcm2048_i2c_driver - i2c driver interface
> >   */
> >  static const struct i2c_device_id bcm2048_id[] = {
> > -   { "bcm2048" , 0 },
> > +   { "bcm2048", 0 },
> > { },
> >  };
> >  MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> > ___
> > devel mailing list
> > de...@linuxdriverproject.org
> > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled

[Pavel Machek]

On Fri 2014-11-14 23:41:15, Rafael J. Wysocki wrote:
> On Friday, November 14, 2014 09:36:17 AM Kevin Hilman wrote:
> > Geert Uytterhoeven  writes:
> > 
> > > Hi Kevin,
> > >
> > > On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman  wrote:
> > >> It makes little sense to use generic power domains without runtime PM.
> > >
> > > Does it?
> > > It still powers down the PM domains on system suspend (at least on my
> > > boards ;-)
> > 
> > Sure, but your devices are also using runtime PM, so I'm not sure how
> > does that change my statement above?
> 
> Questions here are (1) how many users will actually want to disable PM_RUNTIME
> for systems using genpd (my sort of educated guess is "none") and

Well. Developers sometimes want to disable power management so that
they don't have to debug it just now... disabling PM_RUNTIME is a way
to do that.

OTOH making code more complex to make new board bring-up easier may
not be good idea..
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NFC: st21nfcb: fix error handling of irq_of_parse_and_map

[Christophe RICARD]

Hi Dmitry,

Thank you for your feedback.
A patch got already pushed earlier this month:
https://lists.01.org/pipermail/linux-nfc/2014-November/003126.html

The i2c-core is already running the i2c_of_parse_and_map function when
registering the slave device when using dts. This step got removed for
this reason. 

However, i will take into account your second point in order to report
devm_gpio_request_one instead of -ENODEV in a future patchset.

Best Regards
Christophe

On Fri, 14 Nov 2014 14:35:27 -0800
Dmitry Torokhov  wrote:

> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
> 
> Also report error returned by devm_gpio_request_one instead of
> clobbering it with -ENODEV.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
> 
> Not tested, found by casual code inspection.
> 
>  drivers/nfc/st21nfcb/i2c.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/nfc/st21nfcb/i2c.c b/drivers/nfc/st21nfcb/i2c.c
> index c5d2427..abe73ec 100644
> --- a/drivers/nfc/st21nfcb/i2c.c
> +++ b/drivers/nfc/st21nfcb/i2c.c
> @@ -258,19 +258,18 @@ static int
> st21nfcb_nci_i2c_of_request_resources(struct i2c_client *client)
> GPIOF_OUT_INIT_HIGH, "clf_reset"); if (r) {
>   nfc_err(>dev, "Failed to request reset
> pin\n");
> - return -ENODEV;
> + return r;
>   }
>   phy->gpio_reset = gpio;
>  
>   /* IRQ */
> - r = irq_of_parse_and_map(pp, 0);
> - if (r < 0) {
> - nfc_err(>dev, "Unable to get irq, error:
> %d\n", r);
> - return r;
> + client->irq = irq_of_parse_and_map(pp, 0);
> + if (!client->irq) {
> + nfc_err(>dev, "Unable to get irq\n");
> + return -EINVAL;
>   }
>  
>   phy->irq_polarity = irq_get_trigger_type(r);
> - client->irq = r;
>  
>   return 0;
>  }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NFC: st21nfca: fix error handling of irq_of_parse_and_map

[Christophe RICARD]

Hi Dmitry,

Thank you for your feedback.
A patch got already pushed earlier this month:
https://lists.01.org/pipermail/linux-nfc/2014-November/003123.html

The i2c-core is already running the i2c_of_parse_and_map function when
registering the slave device when using dts. This step got removed for
this reason. 

However, i will take into account your second point in order to report
devm_gpio_request_one instead of -ENODEV in a future patchset.

Best Regards
Christophe 

On Fri, 14 Nov 2014 14:32:24 -0800
Dmitry Torokhov  wrote:

> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
> 
> Also report error returned by devm_gpio_request_one instead of
> clobbering it with -ENODEV.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/nfc/st21nfca/i2c.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
> index 0ea756b..6d6d282 100644
> --- a/drivers/nfc/st21nfca/i2c.c
> +++ b/drivers/nfc/st21nfca/i2c.c
> @@ -531,20 +531,19 @@ static int
> st21nfca_hci_i2c_of_request_resources(struct i2c_client *client)
> "clf_enable"); if (r) {
>   nfc_err(>dev, "Failed to request enable
> pin\n");
> - return -ENODEV;
> + return r;
>   }
>  
>   phy->gpio_ena = gpio;
>  
>   /* IRQ */
> - r = irq_of_parse_and_map(pp, 0);
> - if (r < 0) {
> - nfc_err(>dev, "Unable to get irq, error:
> %d\n", r);
> - return r;
> + client->irq = irq_of_parse_and_map(pp, 0);
> + if (!client->irq) {
> + nfc_err(>dev, "Unable to get irq\n");
> + return -EINVAL;
>   }
>  
>   phy->irq_polarity = irq_get_trigger_type(r);
> - client->irq = r;
>  
>   return 0;
>  }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] lib/mpi: Deletion of unnecessary checks before the function call "mpi_free_limb_space"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Nov 2014 21:33:26 +0100

The mpi_free_limb_space() function tests whether its argument is NULL and
then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 lib/mpi/mpi-pow.c  | 15 +--
 lib/mpi/mpih-mul.c | 21 +++--
 2 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/lib/mpi/mpi-pow.c b/lib/mpi/mpi-pow.c
index 5464c87..c28882f 100644
--- a/lib/mpi/mpi-pow.c
+++ b/lib/mpi/mpi-pow.c
@@ -308,16 +308,11 @@ leave:
 enomem:
if (assign_rp)
mpi_assign_limb_space(res, rp, size);
-   if (mp_marker)
-   mpi_free_limb_space(mp_marker);
-   if (bp_marker)
-   mpi_free_limb_space(bp_marker);
-   if (ep_marker)
-   mpi_free_limb_space(ep_marker);
-   if (xp_marker)
-   mpi_free_limb_space(xp_marker);
-   if (tspace)
-   mpi_free_limb_space(tspace);
+   mpi_free_limb_space(mp_marker);
+   mpi_free_limb_space(bp_marker);
+   mpi_free_limb_space(ep_marker);
+   mpi_free_limb_space(xp_marker);
+   mpi_free_limb_space(tspace);
return rc;
 }
 EXPORT_SYMBOL_GPL(mpi_powm);
diff --git a/lib/mpi/mpih-mul.c b/lib/mpi/mpih-mul.c
index 7c84171..ff021cc 100644
--- a/lib/mpi/mpih-mul.c
+++ b/lib/mpi/mpih-mul.c
@@ -339,8 +339,7 @@ mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
mpi_limb_t cy;
 
if (!ctx->tspace || ctx->tspace_size < vsize) {
-   if (ctx->tspace)
-   mpi_free_limb_space(ctx->tspace);
+   mpi_free_limb_space(ctx->tspace);
ctx->tspace = mpi_alloc_limb_space(2 * vsize);
if (!ctx->tspace)
return -ENOMEM;
@@ -354,12 +353,10 @@ mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,
usize -= vsize;
if (usize >= vsize) {
if (!ctx->tp || ctx->tp_size < vsize) {
-   if (ctx->tp)
-   mpi_free_limb_space(ctx->tp);
+   mpi_free_limb_space(ctx->tp);
ctx->tp = mpi_alloc_limb_space(2 * vsize);
if (!ctx->tp) {
-   if (ctx->tspace)
-   mpi_free_limb_space(ctx->tspace);
+   mpi_free_limb_space(ctx->tspace);
ctx->tspace = NULL;
return -ENOMEM;
}
@@ -407,16 +404,12 @@ void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx 
*ctx)
 {
struct karatsuba_ctx *ctx2;
 
-   if (ctx->tp)
-   mpi_free_limb_space(ctx->tp);
-   if (ctx->tspace)
-   mpi_free_limb_space(ctx->tspace);
+   mpi_free_limb_space(ctx->tp);
+   mpi_free_limb_space(ctx->tspace);
for (ctx = ctx->next; ctx; ctx = ctx2) {
ctx2 = ctx->next;
-   if (ctx->tp)
-   mpi_free_limb_space(ctx->tp);
-   if (ctx->tspace)
-   mpi_free_limb_space(ctx->tspace);
+   mpi_free_limb_space(ctx->tp);
+   mpi_free_limb_space(ctx->tspace);
kfree(ctx);
}
 }
-- 
2.1.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: rockchip: enable PWM on Radxa Rock

[Heiko Stübner]

Am Freitag, 14. November 2014, 16:32:25 schrieb Julien CHAUVEAU:
> This enables user space access to the 3 PWM available on the Radxa Rock
> headers.
> 
> Signed-off-by: Julien CHAUVEAU 

added to my v3.19-armsoc/dts branch

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Josh Triplett]

On Sat, Nov 15, 2014 at 12:06:20PM -0800, Andy Lutomirski wrote:
> On Sat, Nov 15, 2014 at 11:29 AM, Josh Triplett  wrote:
> > On Sat, Nov 15, 2014 at 09:37:27AM -0600, Eric W. Biederman wrote:
> >> Josh Triplett  writes:
> >>
> >> > Currently, unprivileged processes (without CAP_SETGID) cannot call
> >> > setgroups at all.  In particular, processes with a set of supplementary
> >> > groups cannot further drop permissions without obtaining elevated
> >> > permissions first.
> >> >
> >> > Allow unprivileged processes to call setgroups with a subset of their
> >> > current groups; only require CAP_SETGID to add a group the process does
> >> > not currently have.
> >>
> >> A couple of questions.
> >> - Is there precedence in other unix flavors for this?
> >
> > I found a few references to now-nonexistent pages at MIT about a system
> > with this property, but other than that no.
> >
> > I've also found more than a few references to people wanting this
> > functionality.
> >
> >> - What motiviates this change?
> >
> > I have a series of patches planned to add more ways to drop elevated
> > privileges without requiring a transition through root to do so.  That
> > would improve the ability for unprivileged users to run programs
> > sandboxed with even *less* privileges.  (Among other things, that would
> > also allow programs running with no_new_privs to further *reduce* their
> > privileges, which they can't currently do in this case.)
> >
> >> - Have you looked to see if anything might for bug compatibilty
> >>   require applications not to be able to drop supplementary groups?
> >
> > I haven't found any such case; that doesn't mean such a case does not
> > exist.  Feedback welcome.
> >
> > The only case I can think of (and I don't know of any examples of such a
> > system): some kind of quota system that limits the members of a group to
> > a certain amount of storage, but places no such limit on non-members.
> >
> > However, the idea of *holding* a credential (a supplementary group ID)
> > giving *less* privileges, and *dropping* a credential giving *more*
> > privileges, would completely invert normal security models.  (The sane
> > way to design such a system would be to have a privileged group for
> > "users who can exceed the quota".)
> 
> Agreed.  And, if you want to bypass quotas by dropping a supplementary
> group, you already can by unsharing your user namespace.

Good point!  Given that a process can run with a new user namespace and
no other namespaces, and then drop all its other privileges that way,
the ability to drop privileges without using a user namespace seems
completely harmless, with one exception that you noted:

> However, sudoers seems to allow negative group matches.  So maybe
> allowing this only with no_new_privs already set would make sense.

Sigh, bad sudo.  Sure, restricting this to no_new_privs only seems fine.
I'll do that in v2, and document that in the manpage.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] fs-fat: Less function calls in fat_fill_super() after error detection

[Julia Lawall]

On Sat, 15 Nov 2014, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Sat, 15 Nov 2014 20:55:23 +0100
> 
> The iput() function was called in an inefficient way by the implementation
> of the fat_fill_super() function in case of an allocation failure.
> The corresponding source code was improved by deletion of two unnecessary
> null pointer checks and a few adjustments for jump labels.
> 
> Signed-off-by: Markus Elfring 
> ---
>  fs/fat/inode.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/fat/inode.c b/fs/fat/inode.c
> index 756aead..138ab9a 100644
> --- a/fs/fat/inode.c
> +++ b/fs/fat/inode.c
> @@ -1716,20 +1716,20 @@ int fat_fill_super(struct super_block *sb, void 
> *data, int silent, int isvfat,
>  
>   fsinfo_inode = new_inode(sb);
>   if (!fsinfo_inode)
> - goto out_fail;
> + goto fsinfo_inode_failure;
>   fsinfo_inode->i_ino = MSDOS_FSINFO_INO;
>   sbi->fsinfo_inode = fsinfo_inode;
>   insert_inode_hash(fsinfo_inode);
>  
>   root_inode = new_inode(sb);
>   if (!root_inode)
> - goto out_fail;
> + goto other_failure;

Other_failure is not such a good name.  The one above is better.

julia

>   root_inode->i_ino = MSDOS_ROOT_INO;
>   root_inode->i_version = 1;
>   error = fat_read_root(root_inode);
>   if (error < 0) {
>   iput(root_inode);
> - goto out_fail;
> + goto other_failure;
>   }
>   error = -ENOMEM;
>   insert_inode_hash(root_inode);
> @@ -1737,7 +1737,7 @@ int fat_fill_super(struct super_block *sb, void *data, 
> int silent, int isvfat,
>   sb->s_root = d_make_root(root_inode);
>   if (!sb->s_root) {
>   fat_msg(sb, KERN_ERR, "get root inode failed");
> - goto out_fail;
> + goto other_failure;
>   }
>  
>   if (sbi->options.discard) {
> @@ -1756,11 +1756,13 @@ out_invalid:
>   if (!silent)
>   fat_msg(sb, KERN_INFO, "Can't find a valid FAT filesystem");
>  
> +other_failure:
> + iput(fsinfo_inode);
> +
> +fsinfo_inode_failure:
> + iput(fat_inode);
> +
>  out_fail:
> - if (fsinfo_inode)
> - iput(fsinfo_inode);
> - if (fat_inode)
> - iput(fat_inode);
>   unload_nls(sbi->nls_io);
>   unload_nls(sbi->nls_disk);
>   if (sbi->options.iocharset != fat_default_iocharset)
> -- 
> 2.1.3
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: media: bcm2048: fix coding style error

[Konrad Zapalowicz]

On 11/15, Christian Resell wrote:
> Simple style fix (checkpatch.pl: "space prohibited before that ','").
> For the eudyptula challenge (http://eudyptula-challenge.org/).

Nice, however we do not need the information about the 'eudyptula
challenge' in the commit message.

If you want to include extra information please do it after the '---'
line (just below the signed-off). You will find more details in the
SubmittingPatches (chapter 15) of the kernel documentation.

Thanks,
Konrad
 
> Signed-off-by: Christian F. Resell 
> ---
> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
> b/drivers/staging/media/bcm2048/radio-bcm2048.c
> index 2bba370..bdc6854 100644
> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> @@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct 
> i2c_client *client)
>   *   bcm2048_i2c_driver - i2c driver interface
>   */
>  static const struct i2c_device_id bcm2048_id[] = {
> - { "bcm2048" , 0 },
> + { "bcm2048", 0 },
>   { },
>  };
>  MODULE_DEVICE_TABLE(i2c, bcm2048_id);
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Andy Lutomirski]

On Sat, Nov 15, 2014 at 11:29 AM, Josh Triplett  wrote:
> On Sat, Nov 15, 2014 at 09:37:27AM -0600, Eric W. Biederman wrote:
>> Josh Triplett  writes:
>>
>> > Currently, unprivileged processes (without CAP_SETGID) cannot call
>> > setgroups at all.  In particular, processes with a set of supplementary
>> > groups cannot further drop permissions without obtaining elevated
>> > permissions first.
>> >
>> > Allow unprivileged processes to call setgroups with a subset of their
>> > current groups; only require CAP_SETGID to add a group the process does
>> > not currently have.
>>
>> A couple of questions.
>> - Is there precedence in other unix flavors for this?
>
> I found a few references to now-nonexistent pages at MIT about a system
> with this property, but other than that no.
>
> I've also found more than a few references to people wanting this
> functionality.
>
>> - What motiviates this change?
>
> I have a series of patches planned to add more ways to drop elevated
> privileges without requiring a transition through root to do so.  That
> would improve the ability for unprivileged users to run programs
> sandboxed with even *less* privileges.  (Among other things, that would
> also allow programs running with no_new_privs to further *reduce* their
> privileges, which they can't currently do in this case.)
>
>> - Have you looked to see if anything might for bug compatibilty
>>   require applications not to be able to drop supplementary groups?
>
> I haven't found any such case; that doesn't mean such a case does not
> exist.  Feedback welcome.
>
> The only case I can think of (and I don't know of any examples of such a
> system): some kind of quota system that limits the members of a group to
> a certain amount of storage, but places no such limit on non-members.
>
> However, the idea of *holding* a credential (a supplementary group ID)
> giving *less* privileges, and *dropping* a credential giving *more*
> privileges, would completely invert normal security models.  (The sane
> way to design such a system would be to have a privileged group for
> "users who can exceed the quota".)

Agreed.  And, if you want to bypass quotas by dropping a supplementary
group, you already can by unsharing your user namespace.

However, sudoers seems to allow negative group matches.  So maybe
allowing this only with no_new_privs already set would make sense.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] fs-fat: Less function calls in fat_fill_super() after error detection

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Nov 2014 20:55:23 +0100

The iput() function was called in an inefficient way by the implementation
of the fat_fill_super() function in case of an allocation failure.
The corresponding source code was improved by deletion of two unnecessary
null pointer checks and a few adjustments for jump labels.

Signed-off-by: Markus Elfring 
---
 fs/fat/inode.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 756aead..138ab9a 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -1716,20 +1716,20 @@ int fat_fill_super(struct super_block *sb, void *data, 
int silent, int isvfat,
 
fsinfo_inode = new_inode(sb);
if (!fsinfo_inode)
-   goto out_fail;
+   goto fsinfo_inode_failure;
fsinfo_inode->i_ino = MSDOS_FSINFO_INO;
sbi->fsinfo_inode = fsinfo_inode;
insert_inode_hash(fsinfo_inode);
 
root_inode = new_inode(sb);
if (!root_inode)
-   goto out_fail;
+   goto other_failure;
root_inode->i_ino = MSDOS_ROOT_INO;
root_inode->i_version = 1;
error = fat_read_root(root_inode);
if (error < 0) {
iput(root_inode);
-   goto out_fail;
+   goto other_failure;
}
error = -ENOMEM;
insert_inode_hash(root_inode);
@@ -1737,7 +1737,7 @@ int fat_fill_super(struct super_block *sb, void *data, 
int silent, int isvfat,
sb->s_root = d_make_root(root_inode);
if (!sb->s_root) {
fat_msg(sb, KERN_ERR, "get root inode failed");
-   goto out_fail;
+   goto other_failure;
}
 
if (sbi->options.discard) {
@@ -1756,11 +1756,13 @@ out_invalid:
if (!silent)
fat_msg(sb, KERN_INFO, "Can't find a valid FAT filesystem");
 
+other_failure:
+   iput(fsinfo_inode);
+
+fsinfo_inode_failure:
+   iput(fat_inode);
+
 out_fail:
-   if (fsinfo_inode)
-   iput(fsinfo_inode);
-   if (fat_inode)
-   iput(fat_inode);
unload_nls(sbi->nls_io);
unload_nls(sbi->nls_disk);
if (sbi->options.iocharset != fat_default_iocharset)
-- 
2.1.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] mfd: t7l66xb: prepare/unprepare clocks

[Dmitry Eremin-Solenikov]

Change clk_enable/disable() calls to clk_prepare_enable() and
clk_disable_unrepapre().

Signed-off-by: Dmitry Eremin-Solenikov 
---
 drivers/mfd/t7l66xb.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/t7l66xb.c b/drivers/mfd/t7l66xb.c
index 9e04a74..439d905 100644
--- a/drivers/mfd/t7l66xb.c
+++ b/drivers/mfd/t7l66xb.c
@@ -87,7 +87,7 @@ static int t7l66xb_mmc_enable(struct platform_device *mmc)
unsigned long flags;
u8 dev_ctl;
 
-   clk_enable(t7l66xb->clk32k);
+   clk_prepare_enable(t7l66xb->clk32k);
 
spin_lock_irqsave(>lock, flags);
 
@@ -118,7 +118,7 @@ static int t7l66xb_mmc_disable(struct platform_device *mmc)
 
spin_unlock_irqrestore(>lock, flags);
 
-   clk_disable(t7l66xb->clk32k);
+   clk_disable_unprepare(t7l66xb->clk32k);
 
return 0;
 }
@@ -285,7 +285,7 @@ static int t7l66xb_suspend(struct platform_device *dev, 
pm_message_t state)
 
if (pdata && pdata->suspend)
pdata->suspend(dev);
-   clk_disable(t7l66xb->clk48m);
+   clk_disable_unprepare(t7l66xb->clk48m);
 
return 0;
 }
@@ -295,7 +295,7 @@ static int t7l66xb_resume(struct platform_device *dev)
struct t7l66xb *t7l66xb = platform_get_drvdata(dev);
struct t7l66xb_platform_data *pdata = dev_get_platdata(>dev);
 
-   clk_enable(t7l66xb->clk48m);
+   clk_prepare_enable(t7l66xb->clk48m);
if (pdata && pdata->resume)
pdata->resume(dev);
 
@@ -369,7 +369,7 @@ static int t7l66xb_probe(struct platform_device *dev)
goto err_ioremap;
}
 
-   clk_enable(t7l66xb->clk48m);
+   clk_prepare_enable(t7l66xb->clk48m);
 
if (pdata && pdata->enable)
pdata->enable(dev);
@@ -414,9 +414,9 @@ static int t7l66xb_remove(struct platform_device *dev)
int ret;
 
ret = pdata->disable(dev);
-   clk_disable(t7l66xb->clk48m);
+   clk_disable_unprepare(t7l66xb->clk48m);
clk_put(t7l66xb->clk48m);
-   clk_disable(t7l66xb->clk32k);
+   clk_disable_unprepare(t7l66xb->clk32k);
clk_put(t7l66xb->clk32k);
t7l66xb_detach_irq(dev);
iounmap(t7l66xb->scr);
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] mfd: tc6387xb: prepare/unprepare clocks

[Dmitry Eremin-Solenikov]

Change clk_enable/disable() calls to clk_prepare_enable() and
clk_disable_unrepapre().

Signed-off-by: Dmitry Eremin-Solenikov 
---
 drivers/mfd/tc6387xb.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/tc6387xb.c b/drivers/mfd/tc6387xb.c
index e71f880..85fab37 100644
--- a/drivers/mfd/tc6387xb.c
+++ b/drivers/mfd/tc6387xb.c
@@ -52,7 +52,7 @@ static int tc6387xb_suspend(struct platform_device *dev, 
pm_message_t state)
 
if (pdata && pdata->suspend)
pdata->suspend(dev);
-   clk_disable(tc6387xb->clk32k);
+   clk_disable_unprepare(tc6387xb->clk32k);
 
return 0;
 }
@@ -62,7 +62,7 @@ static int tc6387xb_resume(struct platform_device *dev)
struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
struct tc6387xb_platform_data *pdata = dev_get_platdata(>dev);
 
-   clk_enable(tc6387xb->clk32k);
+   clk_prepare_enable(tc6387xb->clk32k);
if (pdata && pdata->resume)
pdata->resume(dev);
 
@@ -100,7 +100,7 @@ static int tc6387xb_mmc_enable(struct platform_device *mmc)
struct platform_device *dev  = to_platform_device(mmc->dev.parent);
struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
 
-   clk_enable(tc6387xb->clk32k);
+   clk_prepare_enable(tc6387xb->clk32k);
 
tmio_core_mmc_enable(tc6387xb->scr + 0x200, 0,
tc6387xb_mmc_resources[0].start & 0xfffe);
@@ -113,7 +113,7 @@ static int tc6387xb_mmc_disable(struct platform_device *mmc)
struct platform_device *dev  = to_platform_device(mmc->dev.parent);
struct tc6387xb *tc6387xb = platform_get_drvdata(dev);
 
-   clk_disable(tc6387xb->clk32k);
+   clk_disable_unprepare(tc6387xb->clk32k);
 
return 0;
 }
@@ -214,7 +214,7 @@ static int tc6387xb_remove(struct platform_device *dev)
mfd_remove_devices(>dev);
iounmap(tc6387xb->scr);
release_resource(>rscr);
-   clk_disable(tc6387xb->clk32k);
+   clk_disable_unprepare(tc6387xb->clk32k);
clk_put(tc6387xb->clk32k);
kfree(tc6387xb);
 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Cocci] [PATCH 1/1] ntfs: Deletion of unnecessary checks before the function call "iput"

[Julia Lawall]

On Sat, 15 Nov 2014, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Sat, 15 Nov 2014 19:35:05 +0100
> 
> The iput() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  fs/ntfs/super.c | 21 +++--
>  1 file changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
> index 6c3296e..8f22a47 100644
> --- a/fs/ntfs/super.c
> +++ b/fs/ntfs/super.c
> @@ -2204,17 +2204,12 @@ get_ctx_vol_failed:
>   return true;
>  #ifdef NTFS_RW
>  iput_usnjrnl_err_out:

I don't have time to look at the code now, but since there is an exit 
label here, have you checked whether you could improve the gotos in these 
cases?

julia

> - if (vol->usnjrnl_j_ino)
> - iput(vol->usnjrnl_j_ino);
> - if (vol->usnjrnl_max_ino)
> - iput(vol->usnjrnl_max_ino);
> - if (vol->usnjrnl_ino)
> - iput(vol->usnjrnl_ino);
> + iput(vol->usnjrnl_j_ino);
> + iput(vol->usnjrnl_max_ino);
> + iput(vol->usnjrnl_ino);
>  iput_quota_err_out:
> - if (vol->quota_q_ino)
> - iput(vol->quota_q_ino);
> - if (vol->quota_ino)
> - iput(vol->quota_ino);
> + iput(vol->quota_q_ino);
> + iput(vol->quota_ino);
>   iput(vol->extend_ino);
>  #endif /* NTFS_RW */
>  iput_sec_err_out:
> @@ -2223,8 +2218,7 @@ iput_root_err_out:
>   iput(vol->root_ino);
>  iput_logfile_err_out:
>  #ifdef NTFS_RW
> - if (vol->logfile_ino)
> - iput(vol->logfile_ino);
> + iput(vol->logfile_ino);
>  iput_vol_err_out:
>  #endif /* NTFS_RW */
>   iput(vol->vol_ino);
> @@ -2254,8 +2248,7 @@ iput_mftbmp_err_out:
>   iput(vol->mftbmp_ino);
>  iput_mirr_err_out:
>  #ifdef NTFS_RW
> - if (vol->mftmirr_ino)
> - iput(vol->mftmirr_ino);
> + iput(vol->mftmirr_ino);
>  #endif /* NTFS_RW */
>   return false;
>  }
> -- 
> 2.1.3
> 
> 
> ___
> Cocci mailing list
> co...@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: media: bcm2048: fix coding style error

[Christian Resell]

Simple style fix (checkpatch.pl: "space prohibited before that ','").
For the eudyptula challenge (http://eudyptula-challenge.org/).

Signed-off-by: Christian F. Resell 
---
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 2bba370..bdc6854 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2707,7 +2707,7 @@ static int __exit bcm2048_i2c_driver_remove(struct 
i2c_client *client)
  * bcm2048_i2c_driver - i2c driver interface
  */
 static const struct i2c_device_id bcm2048_id[] = {
-   { "bcm2048" , 0 },
+   { "bcm2048", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(i2c, bcm2048_id);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map

[Kevin Cernekee]

On Fri, Nov 14, 2014 at 2:16 PM, Dmitry Torokhov  wrote:
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
>
> Signed-off-by: Dmitry Torokhov 
> ---
>
> Not tested, found by casual code inspection.
>
>  drivers/irqchip/irq-bcm7120-l2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-bcm7120-l2.c 
> b/drivers/irqchip/irq-bcm7120-l2.c
> index e7c6155..8eec8e1 100644
> --- a/drivers/irqchip/irq-bcm7120-l2.c
> +++ b/drivers/irqchip/irq-bcm7120-l2.c
> @@ -102,9 +102,9 @@ static int bcm7120_l2_intc_init_one(struct device_node 
> *dn,
> unsigned int idx;
>
> parent_irq = irq_of_parse_and_map(dn, irq);
> -   if (parent_irq < 0) {
> +   if (!parent_irq) {
> pr_err("failed to map interrupt %d\n", irq);
> -   return parent_irq;
> +   return -EINVAL;
> }
>
> /* For multiple parent IRQs with multiple words, this looks like:

Hi Dmitry,

Thanks for the review.  For this patch and for your irq-brcmstb-l2.c
patch, I'll add:

Tested-by: Kevin Cernekee 

The same bug also showed up in my new irq-bcm7038-l1.c driver; it will
be fixed in the initial submission.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irqchip: brcmstb-l2: fix error handling of irq_of_parse_and_map

[Florian Fainelli]

2014-11-14 14:16 GMT-08:00 Dmitry Torokhov :
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
>
> Signed-off-by: Dmitry Torokhov 

Acked-by: Florian Fainelli 


> ---
>
> Not tested, found by casual code inspection.
>
>  drivers/irqchip/irq-brcmstb-l2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-brcmstb-l2.c 
> b/drivers/irqchip/irq-brcmstb-l2.c
> index 4aa653a..313c2c6 100644
> --- a/drivers/irqchip/irq-brcmstb-l2.c
> +++ b/drivers/irqchip/irq-brcmstb-l2.c
> @@ -139,9 +139,9 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
> writel(0x, data->base + CPU_CLEAR);
>
> data->parent_irq = irq_of_parse_and_map(np, 0);
> -   if (data->parent_irq < 0) {
> +   if (!data->parent_irq) {
> pr_err("failed to find parent interrupt\n");
> -   ret = data->parent_irq;
> +   ret = -EINVAL;
> goto out_unmap;
> }
>
> --
> 2.1.0.rc2.206.gedb03e5
>
>
> --
> Dmitry



-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map

[Florian Fainelli]

2014-11-14 14:16 GMT-08:00 Dmitry Torokhov :
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
>
> Signed-off-by: Dmitry Torokhov 

Acked-by: Florian Fainelli 

> ---
>
> Not tested, found by casual code inspection.
>
>  drivers/irqchip/irq-bcm7120-l2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-bcm7120-l2.c 
> b/drivers/irqchip/irq-bcm7120-l2.c
> index e7c6155..8eec8e1 100644
> --- a/drivers/irqchip/irq-bcm7120-l2.c
> +++ b/drivers/irqchip/irq-bcm7120-l2.c
> @@ -102,9 +102,9 @@ static int bcm7120_l2_intc_init_one(struct device_node 
> *dn,
> unsigned int idx;
>
> parent_irq = irq_of_parse_and_map(dn, irq);
> -   if (parent_irq < 0) {
> +   if (!parent_irq) {
> pr_err("failed to map interrupt %d\n", irq);
> -   return parent_irq;
> +   return -EINVAL;
> }
>
> /* For multiple parent IRQs with multiple words, this looks like:
> --
> 2.1.0.rc2.206.gedb03e5
>
>
> --
> Dmitry



-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] groups: Allow unprivileged processes to use setgroups to drop groups

[Josh Triplett]

On Sat, Nov 15, 2014 at 09:37:27AM -0600, Eric W. Biederman wrote:
> Josh Triplett  writes:
> 
> > Currently, unprivileged processes (without CAP_SETGID) cannot call
> > setgroups at all.  In particular, processes with a set of supplementary
> > groups cannot further drop permissions without obtaining elevated
> > permissions first.
> >
> > Allow unprivileged processes to call setgroups with a subset of their
> > current groups; only require CAP_SETGID to add a group the process does
> > not currently have.
> 
> A couple of questions.
> - Is there precedence in other unix flavors for this?

I found a few references to now-nonexistent pages at MIT about a system
with this property, but other than that no.

I've also found more than a few references to people wanting this
functionality.

> - What motiviates this change?

I have a series of patches planned to add more ways to drop elevated
privileges without requiring a transition through root to do so.  That
would improve the ability for unprivileged users to run programs
sandboxed with even *less* privileges.  (Among other things, that would
also allow programs running with no_new_privs to further *reduce* their
privileges, which they can't currently do in this case.)

> - Have you looked to see if anything might for bug compatibilty
>   require applications not to be able to drop supplementary groups?

I haven't found any such case; that doesn't mean such a case does not
exist.  Feedback welcome.

The only case I can think of (and I don't know of any examples of such a
system): some kind of quota system that limits the members of a group to
a certain amount of storage, but places no such limit on non-members.

However, the idea of *holding* a credential (a supplementary group ID)
giving *less* privileges, and *dropping* a credential giving *more*
privileges, would completely invert normal security models.  (The sane
way to design such a system would be to have a privileged group for
"users who can exceed the quota".)

If it turns out that a real case exists that people care about, I could
easily make this configurable, either at compile time or via a sysctl.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler

[Richard Cochran]

On Fri, Nov 14, 2014 at 10:37:27AM +0530, Vignesh R wrote:
> From: Brad Griffis 
> 
> TSC interrupt handler had udelay to avoid reporting of false pen-up
> interrupt to user space. This patch implements workaround suggesting in
> Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay
> and touchscreen lag. This also improves performance of touchscreen and
> eliminates sudden jump of cursor at touch release.

I back ported this series onto v3.15.1 in order to try this out on a
custom, beaglebone-like board. With this series, the touch is really
broken. (I had fixed the pen up problem in a totally different way for
a customer, and so I wanted to try out your solution.)

I will try to port the board code to a more recent kernel to try your
series again. With which kernel version did you test your patches?

And which board?

Thanks,
Richard


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Request for help: what did I do wrong with idtentry?

[Andy Lutomirski]

On Sat, Nov 15, 2014 at 10:28 AM, Andi Kleen  wrote:
>> I'm not
>> completely thrilled with what it does to double_fault, though.  If we
>> somehow get a double fault caused by an interrupt hitting userspace
>> with a bad kernel_stack, then we'll end up page faulting in the
>> double_fault prologue.  I'm not convinced that this is worth worrying
>> about.  It would be easy enough to fix, though, even if it would
>> further uglify the code.
>
> If you're "cleaning up" good and working code the functionality should
> be the same as before. The old code handled this situation fine.
> So your new code should handle this too.

First, this failure mode should be almost impossible.  We'd really
have to screw up to have the kernel stack point to a bad address.
(This isn't the stack *pointer* being bad -- it's the value in the
TSS.)

If this happens, the existing code will die (no recovery possible
unlike with normal OOPSes).  The new code will log a kernel-mode page
fault on the DF stack (as shown on the stack trace, assuming that
logic works), complain some more in do_exit, and make some sort of
effort to recover, which might even work.

In other words, I'd be happy to "fix" it, but I'm not entirely
convinced that this change should count as a regression in the first
place.

If we go for the fix-it approach, we could add a fixup in sync_regs
and probe the kernel_stack or we could add a paranoid=2 mode for
double_fault.

>
> In general yes handling all the corner cases makes code ugly.
> That is how the existing code got how it became.

Most of those corner cases are at least in code paths that are
supposed to work.  This particular corner case is in a handler that's
just trying to print something useful rather than silently rebooting,
and it should still work well enough to print something useful.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] ntfs: Deletion of unnecessary checks before the function call "iput"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Nov 2014 19:35:05 +0100

The iput() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 fs/ntfs/super.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
index 6c3296e..8f22a47 100644
--- a/fs/ntfs/super.c
+++ b/fs/ntfs/super.c
@@ -2204,17 +2204,12 @@ get_ctx_vol_failed:
return true;
 #ifdef NTFS_RW
 iput_usnjrnl_err_out:
-   if (vol->usnjrnl_j_ino)
-   iput(vol->usnjrnl_j_ino);
-   if (vol->usnjrnl_max_ino)
-   iput(vol->usnjrnl_max_ino);
-   if (vol->usnjrnl_ino)
-   iput(vol->usnjrnl_ino);
+   iput(vol->usnjrnl_j_ino);
+   iput(vol->usnjrnl_max_ino);
+   iput(vol->usnjrnl_ino);
 iput_quota_err_out:
-   if (vol->quota_q_ino)
-   iput(vol->quota_q_ino);
-   if (vol->quota_ino)
-   iput(vol->quota_ino);
+   iput(vol->quota_q_ino);
+   iput(vol->quota_ino);
iput(vol->extend_ino);
 #endif /* NTFS_RW */
 iput_sec_err_out:
@@ -2223,8 +2218,7 @@ iput_root_err_out:
iput(vol->root_ino);
 iput_logfile_err_out:
 #ifdef NTFS_RW
-   if (vol->logfile_ino)
-   iput(vol->logfile_ino);
+   iput(vol->logfile_ino);
 iput_vol_err_out:
 #endif /* NTFS_RW */
iput(vol->vol_ino);
@@ -2254,8 +2248,7 @@ iput_mftbmp_err_out:
iput(vol->mftbmp_ino);
 iput_mirr_err_out:
 #ifdef NTFS_RW
-   if (vol->mftmirr_ino)
-   iput(vol->mftmirr_ino);
+   iput(vol->mftmirr_ino);
 #endif /* NTFS_RW */
return false;
 }
-- 
2.1.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Request for help: what did I do wrong with idtentry?

[Andi Kleen]

> I'm not
> completely thrilled with what it does to double_fault, though.  If we
> somehow get a double fault caused by an interrupt hitting userspace
> with a bad kernel_stack, then we'll end up page faulting in the
> double_fault prologue.  I'm not convinced that this is worth worrying
> about.  It would be easy enough to fix, though, even if it would
> further uglify the code.

If you're "cleaning up" good and working code the functionality should
be the same as before. The old code handled this situation fine. 
So your new code should handle this too.

In general yes handling all the corner cases makes code ugly.
That is how the existing code got how it became.

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] fs-ext4: Deletion of an unnecessary check before the function call "iput"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Nov 2014 19:04:06 +0100

The iput() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 fs/ext4/mballoc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 8b0f9ef..e1a2521 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2712,8 +2712,7 @@ int ext4_mb_release(struct super_block *sb)
}
kfree(sbi->s_mb_offsets);
kfree(sbi->s_mb_maxs);
-   if (sbi->s_buddy_cache)
-   iput(sbi->s_buddy_cache);
+   iput(sbi->s_buddy_cache);
if (sbi->s_mb_stats) {
ext4_msg(sb, KERN_INFO,
   "mballoc: %u blocks %u reqs (%u success)",
-- 
2.1.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/