Re: [RESEND PATCH nouveau 2/3] volt: allow non-bios voltage scaling

[Alexandre Courbot]

On Fri, Nov 28, 2014 at 8:12 PM, Vince Hsu  wrote:
> Signed-off-by: Vince Hsu 

Make sure you always write a short summary for your patches, even if
the title sounds sufficient.

At the very least this patch makes the code easier to read, so:

Acked-by: Alexandre Courbot 
--
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] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c

[Rafał Miłecki]

On 29 November 2014 at 04:32, nick  wrote:
> I don't have hardware for this driver on me, so I didn't test it. However 
> this seems to
> be correct from my reading of the code around this function and other locking 
> related
> to this driver.

So do you say it's not executed in an atomic?

>From *early* look it seems b43_update_templates is called from
b43_op_beacon_set_tim and b43_op_bss_info_changed, both or them are
mac80211 callbacks. That also should be safe, however I didn't check
if it may conflict with some in-kernel code (still, assuming it's not
atomic code, which I don't know!).
--
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] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c

[Michael Büsch]

On Fri, 28 Nov 2014 22:32:30 -0500
nick  wrote:

> I don't have hardware for this driver on me, so I didn't test it. However 
> this seems to 
> be correct from my reading of the code around this function and other locking 
> related
> to this driver.

From the current docs:

>  * @set_tim: Set TIM bit. mac80211 calls this function when a TIM bit
>  *  must be set or cleared for a given STA. Must be atomic.

So it is not allowed to lock a mutex here.

-- 
Michael


pgpVMwrlc7t6G.pgp
Description: OpenPGP digital signature

Re: [PATCH] drivers:net:wireless: Add mutex locking for function, b43_op_beacon_set_time in main.c

[Rafał Miłecki]

On 29 November 2014 at 09:56, Michael Büsch  wrote:
> On Fri, 28 Nov 2014 22:32:30 -0500
> nick  wrote:
>
>> I don't have hardware for this driver on me, so I didn't test it. However 
>> this seems to
>> be correct from my reading of the code around this function and other 
>> locking related
>> to this driver.
>
> From the current docs:
>
>>  * @set_tim: Set TIM bit. mac80211 calls this function when a TIM bit
>>  *  must be set or cleared for a given STA. Must be atomic.
>
> So it is not allowed to lock a mutex here.

Nicholas please be more careful with your patches. It seems your patch
is wrong, you didn't check the docs and you didn't even say in the
first place that it wasn't tested. You could at least submit with with
RFT tag or sth.

-- 
Rafał
--
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] urandom: handle signals immediately

[Heinrich Schuchardt]

Without the patch device /dev/urandom only considers signals when a
rescheduling of the thread is requested. This may imply that
signals will not be handled for time intervals in excess of 30s.

With the patch signals are handled in every round copying 10 bytes if more
than 256 bytes have been collected. This 256 byte limit ensures the
guarantee given by system call getrandom().

With the patch rescheduling may occur even when reading less than 257 bytes.
This restores the logic before the introduction of the getrandom() system
call. getrandom() provides no guarantee concerning rescheduling.

An example code for testing is provided in
https://lkml.org/lkml/2014/11/22/41

Signed-off-by: Heinrich Schuchardt 
---
 drivers/char/random.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 04645c0..75e96c1 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1189,21 +1189,20 @@ static ssize_t extract_entropy_user(struct 
entropy_store *r, void __user *buf,
 {
ssize_t ret = 0, i;
__u8 tmp[EXTRACT_SIZE];
-   int large_request = (nbytes > 256);
 
trace_extract_entropy_user(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_);
xfer_secondary_pool(r, nbytes);
nbytes = account(r, nbytes, 0, 0);
 
while (nbytes) {
-   if (large_request && need_resched()) {
-   if (signal_pending(current)) {
-   if (ret == 0)
-   ret = -ERESTARTSYS;
-   break;
-   }
+   /*
+* getrandom must not be interrupted by a signal while
+* reading up to 256 bytes.
+*/
+   if (signal_pending(current) && ret > 256)
+   break;
+   if (need_resched())
schedule();
-   }
 
extract_buf(r, tmp);
i = min_t(int, nbytes, EXTRACT_SIZE);
-- 
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: [BUG] linux-next: 20141127 boot hang

[Jeremiah Mahler]

all,

On Fri, Nov 28, 2014 at 03:32:50PM -0800, Jeremiah Mahler wrote:
> On Thu, Nov 27, 2014 at 03:16:19PM -0800, Jeremiah Mahler wrote:
> > 
> > I just tried the latest linux-next 20141127 (commit 3bcf494d225fd19) and
> > it hangs very early in the boot sequence, after decompressing the kernel
> > and after fsck (see attached screen shot).  I have tried it with two
> > different machines and they both have the same problem.  It worked with
> > version 20141126.
> > 
> []
> 
> My bisect results so far indicate that the bug was introduced by this
> merge commit.
> 
>   commit 0305904a7416ced1358c5ff575e58135453bfc1d
>   Merge: 38a4751 2ef5864
>   Author: Stephen Rothwell 
>   Date:   Thu Nov 27 14:53:44 2014 +1100
>   
>   Merge remote-tracking branch 'block/for-next'
>   
>   Conflicts:
>   fs/fs-writeback.c
> 
[]

Something is definitely broken at this merge commit.  I haven't
quite figured out how to bisect the patches inside the merge commit.
Any suggestions are welcome.

-- 
- Jeremiah Mahler
--
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 v2] adjtimex.2: add explanation about ADJ_TAI action

[Michael Kerrisk (man-pages)]

Hello Laurent,

Thanks for working on this. I have one question; see below.

On 11/29/2014 12:02 AM, Laurent Georget wrote:
> Le 28/11/2014 22:00, Richard Cochran a écrit :
>> On Fri, Nov 28, 2014 at 02:40:44PM +0100, Laurent Georget wrote:
>>> @@ -101,7 +99,19 @@ combination of zero or more of the following bits:
>>>  Ordinary users are restricted to a zero value for
>>>  .IR modes .
>>>  Only the superuser may set any parameters.
>>> +.PP
>>> +Support for TAI (Atomic International Time, for a complete explanation
>>> about
>>> +what it is and what is the difference between TAI and UTC, see
>>> +.UR http://www.bipm.org/en/bipm/tai/tai.html
>>> +.I BIPM
>>> +.UE )
>>> +has been added in version 2.6.29. For any clock, the TAI offset may
>>
>> Not for "any clock", just for CLOCK_REALTIME.
> 
> Considering that this is the only one representing the "human" time and
> supporting an adjtime action, indeed, it's not relevant for anything
> else than the realtime clock.
> 
>>
>>> +be calculated by adding a value to the UTC offset which is updated when a
>>> +leap second is added or deleted.
>>>  .br
>>> +All the offsets in the timex structure are expressed between the value
>>> of the
>>> +clock and the corresponding value (e.g. TAI offset is the difference
>>> between
>>> +the clock and the TAI, not between TAI and another value such as UTC).
>>
>> The TAI offset is just (TAI - UTC). That's all.
>>
> 
> Yes, my mistake, I misunderstood the part about timekeeping
> (__timekeeping_set_tai_offset() in kernel/time/timekeeping.c, line 815)
> which does store the offset in several formats (monotonic -> TAI and UTC
> -> TAI). But this is not directly related to the timex value. Aniway
> this is not very relevant in the man page.
> 
> Thank you for your comments. Below is a new version of the patch. Less
> unrelevant chit-chat, more useful information (hopefully).
> 
> 
> diff --git a/man2/adjtimex.2 b/man2/adjtimex.2
> index 20a2f0b..871e607 100644
> --- a/man2/adjtimex.2
> +++ b/man2/adjtimex.2
> @@ -26,9 +26,6 @@
>  .\" Modified 2004-05-27 by Michael Kerrisk 
>  .\" Modified 2014-11-28 by Laurent Georget 
>  .\"
> -.\" FIXME Document ADJ_TAI (added in Linux 2.6.26)
> -.\"  commit 153b5d054ac2d98ea0d86504884326b6777f683d
> -.\"
>  .\" FIXME Document ADJ_MICRO and ADJ_NANO (added in Linux 2.6.26)
>  .\"  commit eea83d896e318bda54be2d2770d2c5d6668d11db
>  .\"  Author: Roman Zippel 
> @@ -74,6 +71,17 @@ struct timex {
>  (read-only) */
>  struct timeval time; /* current time (read-only) */
>  long tick;   /* usecs between clock ticks */

What is the following piece about? Did you mean to include it in this patch?

> +
> +long ppsfreq;/* pps frequency (scaled ppm) (read-only) */
> +long jitter; /* pps jitter (usec) (read-only) */
> +int shift;   /* interval duration (sec) (read-only) */
> +long stabil; /* pps stability (scaled ppm) (read-only) */
> +long jitcnt; /* jitter limit exceeded (read-only) */
> +long calcnt; /* calibration intervals (read-only) */
> +long errcnt; /* calibration errors (read-only) */
> +long stbcnt; /* stability limit exceeded (read-only) */
> +
> +int tai; /* TAI offset (s) (read-only) */
>  };

Thanks,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 v2] adjtimex.2: add explanation about ADJ_TAI action

[Richard Cochran]

On Sat, Nov 29, 2014 at 12:02:33AM +0100, Laurent Georget wrote:
> 
> Thank you for your comments. Below is a new version of the patch. Less
> unrelevant chit-chat, more useful information (hopefully).

Looks better to me.

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: [tracecompass-dev] Support for Perf CTF traces now in master (was Re: FW: [RFC 0/5] perf tools: Add perf data CTF conversion)

[Jerome CORRENOZ]

Hi Alexandre,

Catching with this thread of email: could you please share some links to 
documentation/screenshot about perf support with trace compass ?

Regards,
  Jerome

-Original Message-
From: tracecompass-dev-boun...@eclipse.org 
[mailto:tracecompass-dev-boun...@eclipse.org] On Behalf Of Alexandre Montplaisir
Sent: Thursday, November 27, 2014 5:28 AM
To: Sebastian Andrzej Siewior
Cc: Jeremie Galarneau; linux-kernel@vger.kernel.org; Arnaldo Carvalho de Melo; 
Tom Zanussi; Mathieu Desnoyers; David Ahern; Dominique Toupin; Trace Compass 
Developer Discussions; Jiri Olsa; andr...@linutronix.de
Subject: Re: [tracecompass-dev] Support for Perf CTF traces now in master (was 
Re: FW: [RFC 0/5] perf tools: Add perf data CTF conversion)

On 2014-11-26 12:37 PM, Sebastian Andrzej Siewior wrote:
> * Alexandre Montplaisir | 2014-11-12 17:14:45 [-0500]:
>
>> Just a quick note, this branch is now merged to master. So anyone who 
>> pulls the code from the master branch at 
>> git://git.eclipse.org/gitroot/tracecompass/org.eclipse.tracecompass.g
>> it should be able to load perf-CTF traces in the viewer. The trace 
>> type is now called "Common Trace Format -> Linux Kernel Trace" and 
>> should support both LTTng kernel and perf traces in CTF format 
>> (although auto-detection should work in most cases).
> Thank you for all the work.
> Let me try to reply to the emails at once here:
> - I added to the environment metadata the following (comparing to the
>last version):
> domain => kernel
> tracer_name => perf
>
>There is no tracer_major + minor. Instead I added
>version => perf's version
>On my system I have:
>   release = "3.16.0-4-amd64";
>   version = "3.18.rc3.g91405a";
>
>Because I run Debian's v3.16 and recorded the trace with perf from the
>kernel 3.18.rc3.
>There is no version of perf doing the convert of perf.data => ctf.
>Any objections, rename of the version member?
>
> - Mathieu decided that it makes no sense to add the kernel version to
>each event we trace. Instead each event should have its own version
>with a major/minor member. Once the event is changed the "ABI"
>version should be adjusted. I second this since it makes sense.
>Therefore there are no changes that were made to the converter.
>
> - Alexandre (you) noticed that there are syscall names in the events
>recorded via "sys_enter and sys_exit". This is true, but there is a
>hint. There is an event for instance:
>
> [03:37:07.579969498] (+?.?) raw_syscalls:sys_enter: { cpu_id = 
> 2 }, { perf_ip = 0x81020EBC, perf_tid = 30004, perf_pid = 
> 30004, perf_id = 382, perf_period = 1, common_type = 76, common_flags 
> = 0, common_preempt_count = 0, common_pid = 30004, id = 16, args = [ 
> [0] = 0xE, [1] = 0x2400, [2] = 0x0, [3] = 0x0, [4] = 0xA20F00, [5] = 
> 0xA1FDA0 ] }

Oh ok, so this "id" field is really the system call ID then. Good to know, 
thanks!

>
>By the end you notice id=16 and args. args are the Arguments passed
>to syscall and id is the syscall number. Together with machine =
>x86_64 you know which architecture you need to lookup the number 16.
>The numbers are from unistd.h (and may be different between architectures,
>even between i386 & x86_64). strace has for instance the following [0] 
> table.
>
> { 3,TD, sys_read,   "read"  },  /* 0 */
> …
> { 3,TD, sys_ioctl,  "ioctl" },  /* 16 */
> …
>
> So 16 is ioctl. strace has those tables for a bunch of architectures 
> so it might be helpful to suck them in. I know no other way to ease 
> things here.

Indeed. Well this information could be part of the trace metadata too, but I 
guess that wouldn't be very practical.
We'll just need to add a way for each supported tracer to advertize how it gets 
its system call names.

>
> [0] https://github.com/bnoordhuis/strace/blob/master/linux/x86_64/syscallent.h
>
> The same thing is true for softirq_entry events for instance. This event
> will give you you only vec=9 and you need to lookup that 9 => RCU. That
> one is easy however:
>
>   const char * const softirq_to_name[NR_SOFTIRQS] = {
>   "HI", "TIMER", "NET_TX", "NET_RX", "BLOCK", "BLOCK_IOPOLL",
>   "TASKLET", "SCHED", "HRTIMER", "RCU"
>   };
>
> this has been taken from kernel/softirq.c.

Oh, that's right, we never got around to getting/showing the actual 
names of the soft IRQs. Thanks for reminding us. ;)

>> This was based on the most recent file format I was aware of, we will
>> update it accordingly if required.
>>
>> Testing welcome!
> I pushed the perf changes I mentioned to
>
>git://git.breakpoint.cc/bigeasy/linux.git ctf_convert_7
>
> It is now based on Arnaldo's perf/core. If everything goes well from
> the compass side and nobody complains here in any way, the next step
> would be to present the patches on the mailing list and compass as a
> user.
>
> I took you tree and added the patch below. I uploaded the followi

Out-of-bounds write in driver_override_show

[Dmitry Vyukov]

Hello,

I am working on Kernel AddressSanitizer, a fast memory error detector
for kernel:
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

Here is an error report that I got while running trinity:

BUG: AddressSanitizer: out of bounds access in vsnprintf+0xd0/0x890 at
addr 880057483261
Write of size 1 by task trinity-c54/4461
=
BUG kmalloc-4096 (Tainted: GW ): kasan error
-
INFO: Allocated in seq_open+0x5a/0xe0 age=1571449 cpu=0 pid=28869
__slab_alloc+0x4c4/0x4e0
__kmalloc+0x18b/0x1b0
seq_buf_alloc+0x16/0x40
traverse+0x243/0x350
seq_read+0x434/0x6b0
kernfs_fop_read+0x176/0x1f0
vfs_read+0xd7/0x240
SyS_read+0x57/0xc0
system_call_fastpath+0x12/0x17
INFO: Slab 0xea00015d2000 objects=7 used=7 fp=0x  (null)
flags=0x1004080
INFO: Object 0x880057482260 @offset=8800 fp=0x

CPU: 0 PID: 4461 Comm: trinity-c54 Tainted: GB   W  3.18.0-rc1+ #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 81fbdaac 88008e3ab8c8 81c85c3f 1130
 88011b003200 88008e3ab8f8 811ee018 88011b003200
 ea00015d2000 880057482260 8800d748225f 88008e3ab928
Call Trace:
 [] __asan_store1+0x75/0xb0 mm/kasan/kasan.c:417
 [] vsnprintf+0xd0/0x890 lib/vsprintf.c:1860
 [] sprintf+0x40/0x50 lib/vsprintf.c:1989
 [] driver_override_show+0x31/0x40 drivers/base/platform.c:755
 [] dev_attr_show+0x39/0x80 drivers/base/core.c:120
 [] sysfs_kf_seq_show+0x152/0x230 fs/sysfs/file.c:63
 [] kernfs_seq_show+0x76/0x90 fs/kernfs/file.c:168
 [] traverse+0x185/0x350 fs/seq_file.c:120
 [] seq_read+0x434/0x6b0 fs/seq_file.c:191
[] kernfs_fop_read+0x176/0x1f0 fs/kernfs/file.c:244
 [] do_loop_readv_writev+0x71/0xa0 fs/read_write.c:708
 [] do_readv_writev+0x350/0x360 fs/read_write.c:842
 [] vfs_readv+0x4b/0x70 fs/read_write.c:867
 [< inlined>] SyS_preadv+0xca/0xf0 SYSC_preadv fs/read_write.c:945
 [] SyS_preadv+0xca/0xf0 fs/read_write.c:931
 [] system_call_fastpath+0x12/0x17
arch/x86/kernel/entry_64.S:422
Memory state around the buggy address:
 880057482f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880057483000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880057483080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880057483100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880057483180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>880057483200: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
   ^
 880057483280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 880057483300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 880057483380: fc fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880057483400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880057483480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
dev_attr_show: driver_override_show+0x0/0x40 returned bad count
fill_read_buffer: dev_attr_show+0x0/0x80 returned bad count


My source is on revision f114040e3ea6e07372334ade75d1ee0775c355e1.

I've looked at source code and it seems that driver_override_store
does not do length sanitization, so driver_override_show smashes
subsequent memory blocks in sprinf (with user-provided data?).
--
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] tty: serial: serial-omap: depend on !8250_omap

[Sebastian Andrzej Siewior]

* Sebastian Andrzej Siewior | 2014-11-26 23:01:46 [+0100]:

>Technically speaking this is not required. If both are enabled then the
>Maikefile order says that 8250 one wins, the second is never probed.
>
>If we choose to enable 8250_omap via defconfig then one might get supprised
>that his console isn't working anymore since nothing says use ttySx
>instead ttyOx.
>This patch _tries_ to bring this to the users' attention by not showing
>the serial-omap driver once the 8250 one is enabled. So the user might
>choose to use the help text which says that this driver (8250_omap)
>uses ttySx instead ttyOx.
>
>Signed-off-by: Sebastian Andrzej Siewior 
>---
>This is my attempt to warn the defconfig user of the defconfig change
>(which did not yet happen). Any suggestions?

This is was Uwe Kleine-König suggested off-list:

|Currently there are two drivers for the serial device. Until the new one
|matured enough to drop the old one, let them conflict each other. They
|both handle the same devices, but only one can be responsible for a
|single device. There is no technical need, but having two drivers in the
|same kernel might result in surprises.

I personally don't mind having two drivers enabled since the makefile
order is always the same. My main concern is the ttyOx -> ttySx switch
after the newer driver is enabled by default via defconfig (and the user
does not know it). "make oldconfig" is covered by "default n".
Uwe's has a point about "matured enough to drop the old one". It isn't
mentioned anywhere that the newer driver supports also DMA. Is this
something we want to add to the help text?
Could someone that will probably be dealling with possible fallout comment
on this? This patch shouldn't go in without an ACK.

Sebastian
--
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] irq updates for 3.18

[Thomas Gleixner]

Linus,

please pull the latest irq-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
irq-urgent-for-linus

Three fixlets from the ARM SoC camp:
 - Correct irqdomain initialization for atmel-aic
 - Correct error handling for device tree parsing in bcm controllers

Thanks,

tglx

-->
Boris Brezillon (1):
  irqchip: atmel-aic: Fix irqdomain initialization

Dmitry Torokhov (2):
  irqchip: bcm7120-l2: Fix error handling of irq_of_parse_and_map
  irqchip: brcmstb-l2: Fix error handling of irq_of_parse_and_map


 drivers/irqchip/irq-atmel-aic-common.c | 6 +++---
 drivers/irqchip/irq-bcm7120-l2.c   | 4 ++--
 drivers/irqchip/irq-brcmstb-l2.c   | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-atmel-aic-common.c 
b/drivers/irqchip/irq-atmel-aic-common.c
index 6ae3cdee0681..cc4f9d80122e 100644
--- a/drivers/irqchip/irq-atmel-aic-common.c
+++ b/drivers/irqchip/irq-atmel-aic-common.c
@@ -217,8 +217,9 @@ struct irq_domain *__init aic_common_of_init(struct 
device_node *node,
}
 
ret = irq_alloc_domain_generic_chips(domain, 32, 1, name,
-handle_level_irq, 0, 0,
-IRQCHIP_SKIP_SET_WAKE);
+handle_fasteoi_irq,
+IRQ_NOREQUEST | IRQ_NOPROBE |
+IRQ_NOAUTOEN, 0, 0);
if (ret)
goto err_domain_remove;
 
@@ -230,7 +231,6 @@ struct irq_domain *__init aic_common_of_init(struct 
device_node *node,
gc->unused = 0;
gc->wake_enabled = ~0;
gc->chip_types[0].type = IRQ_TYPE_SENSE_MASK;
-   gc->chip_types[0].handler = handle_fasteoi_irq;
gc->chip_types[0].chip.irq_eoi = irq_gc_eoi;
gc->chip_types[0].chip.irq_set_wake = irq_gc_set_wake;
gc->chip_types[0].chip.irq_shutdown = aic_common_shutdown;
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index b9f4fb808e49..5fb38a2ac226 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -101,9 +101,9 @@ static int bcm7120_l2_intc_init_one(struct device_node *dn,
int parent_irq;
 
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;
}
 
data->irq_map_mask |= be32_to_cpup(map_mask + irq);
diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index c15c840987d2..14691a4cb84c 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -135,9 +135,9 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
__raw_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;
}
 
--
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 v2] adjtimex.2: add explanation about ADJ_TAI action

[Laurent Georget]

Hello,

Le 29/11/2014 10:27, Michael Kerrisk (man-pages) a écrit :
> Hello Laurent,
> 
> Thanks for working on this. I have one question; see below.
> 
>>
>> diff --git a/man2/adjtimex.2 b/man2/adjtimex.2
>> index 20a2f0b..871e607 100644
>> --- a/man2/adjtimex.2
>> +++ b/man2/adjtimex.2
>> @@ -26,9 +26,6 @@
>>  .\" Modified 2004-05-27 by Michael Kerrisk 
>>  .\" Modified 2014-11-28 by Laurent Georget 
>>  .\"
>> -.\" FIXME Document ADJ_TAI (added in Linux 2.6.26)
>> -.\" commit 153b5d054ac2d98ea0d86504884326b6777f683d
>> -.\"
>>  .\" FIXME Document ADJ_MICRO and ADJ_NANO (added in Linux 2.6.26)
>>  .\" commit eea83d896e318bda54be2d2770d2c5d6668d11db
>>  .\" Author: Roman Zippel 
>> @@ -74,6 +71,17 @@ struct timex {
>>  (read-only) */
>>  struct timeval time; /* current time (read-only) */
>>  long tick;   /* usecs between clock ticks */
> 
> What is the following piece about? Did you mean to include it in this patch?

Those are new fields added in struct timex since the last edition of the
man page. Maybe I should split the commit in two subcommits: the first
one to add the new fields, and the second one to specifically add the
ADJ_TAI flag?

> 
>> +
>> +long ppsfreq;/* pps frequency (scaled ppm) (read-only) */
>> +long jitter; /* pps jitter (usec) (read-only) */
>> +int shift;   /* interval duration (sec) (read-only) */
>> +long stabil; /* pps stability (scaled ppm) (read-only) */
>> +long jitcnt; /* jitter limit exceeded (read-only) */
>> +long calcnt; /* calibration intervals (read-only) */
>> +long errcnt; /* calibration errors (read-only) */
>> +long stbcnt; /* stability limit exceeded (read-only) */
>> +
>> +int tai; /* TAI offset (s) (read-only) */
>>  };
> 
> Thanks,
> 
> Michael
> 

Thanks,

Laurent

--
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: manual merge of the block tree with the ext4 tree

[Sabrina Dubroca]

Hello,

[adding Jeremiah Mahler to CC]

2014-11-27, 14:53:47 +1100, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in
> fs/fs-writeback.c between commit ef7fdf5e8c87 ("vfs: add support for a
> lazytime mount option") from the ext4 tree and commit 9c6ac78eb352
> ("writeback: fix a subtle race condition in I_DIRTY clearing") from the
> block tree.
> 
> I fixed it up (I took a guess, plese check - see below) and can carry
> the fix as necessary (no action is required).
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc fs/fs-writeback.c
> index 3d87174408ae,2d609a5fbfea..
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@@ -482,14 -479,30 +482,30 @@@ __writeback_single_inode(struct inode *
>* write_inode()
>*/
>   spin_lock(&inode->i_lock);
> - /* Clear I_DIRTY_PAGES if we've written out all dirty pages */
> - if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
> - inode->i_state &= ~I_DIRTY_PAGES;
> + 
>  -dirty = inode->i_state & I_DIRTY;
>  -inode->i_state &= ~I_DIRTY;
>  +dirty = inode->i_state & I_DIRTY_INODE;
>  +inode->i_state &= ~I_DIRTY_INODE;
> + 
> + /*
> +  * Paired with smp_mb() in __mark_inode_dirty().  This allows
> +  * __mark_inode_dirty() to test i_state without grabbing i_lock -
> +  * either they see the I_DIRTY bits cleared or we see the dirtied
> +  * inode.
> +  *
> +  * I_DIRTY_PAGES is always cleared together above even if @mapping
> +  * still has dirty pages.  The flag is reinstated after smp_mb() if
> +  * necessary.  This guarantees that either __mark_inode_dirty()
> +  * sees clear I_DIRTY_PAGES or we see PAGECACHE_TAG_DIRTY.
> +  */
> + smp_mb();
> + 
> + if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
> + inode->i_state |= I_DIRTY_PAGES;
> + 
>   spin_unlock(&inode->i_lock);
> + 
>   /* Don't write the inode if only I_DIRTY_PAGES was set */
>  -if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) {
>  +if (dirty) {
>   int err = write_inode(inode, wbc);
>   if (ret == 0)
>   ret = err;


I think there's a problem in your fix, Stephen.

I'm getting hangs at boot (strangely -- in QEMU -- only when booting
via grub, not when using -kernel) and during shutdown.  Jeremiah seems
to have the same problem and his bisection led to the merge commit:
https://lkml.org/lkml/2014/11/29/17

The following solves both issues for me.  I think it makes sense given
the #defines from ef7fdf5e8c87, since Tejun intended to clear
I_DIRTY_PAGES.


diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index b70e45f45afa..6b2510d97a0a 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -484,7 +484,7 @@ __writeback_single_inode(struct inode *inode, struct 
writeback_control *wbc)
spin_lock(&inode->i_lock);
 
dirty = inode->i_state & I_DIRTY_INODE;
-   inode->i_state &= ~I_DIRTY_INODE;
+   inode->i_state &= ~I_DIRTY;
 
/*
 * Paired with smp_mb() in __mark_inode_dirty().  This allows


-- 
Thanks,
Sabrina
--
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] Fixed type id

[Ren Kimura]

From: RKX1209 

Signed-off-by: RKX1209 
---
 arch/x86/mm/init_32.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index c8140e1..957f7f0 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -304,14 +304,14 @@ repeat:
 #endif
for (; pmd_idx < PTRS_PER_PMD && pfn < end_pfn;
 pmd++, pmd_idx++) {
-   unsigned int addr = pfn * PAGE_SIZE + PAGE_OFFSET;
+   unsigned long addr = pfn * PAGE_SIZE + PAGE_OFFSET;
 
/*
 * Map with big pages if possible, otherwise
 * create normal page tables:
 */
if (use_pse) {
-   unsigned int addr2;
+   unsigned long addr2;
pgprot_t prot = PAGE_KERNEL_LARGE;
/*
 * first pass will use the same initial
-- 
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: [PATCH] Fixed type id

[Richard Weinberger]

On Sat, Nov 29, 2014 at 11:13 AM, Ren Kimura  wrote:
> From: RKX1209 
>
> Signed-off-by: RKX1209 

What issue does this fix?
On 32bit an address should fit into an integer.

> ---
>  arch/x86/mm/init_32.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index c8140e1..957f7f0 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -304,14 +304,14 @@ repeat:
>  #endif
> for (; pmd_idx < PTRS_PER_PMD && pfn < end_pfn;
>  pmd++, pmd_idx++) {
> -   unsigned int addr = pfn * PAGE_SIZE + PAGE_OFFSET;
> +   unsigned long addr = pfn * PAGE_SIZE + PAGE_OFFSET;
>
> /*
>  * Map with big pages if possible, otherwise
>  * create normal page tables:
>  */
> if (use_pse) {
> -   unsigned int addr2;
> +   unsigned long addr2;
> pgprot_t prot = PAGE_KERNEL_LARGE;
> /*
>  * first pass will use the same initial
> --
> 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/



-- 
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: [PATCH] drm: i2c: tda998x: Retry fetching the EDID if it fails first time.

[Jean-Francois Moine]

On Fri, 28 Nov 2014 09:02:39 +
Andrew Jackson  wrote:

> > It seems that your patch is deprecated by Laurent Pinchart's
> > [PATCH] drm: tda998x: Use drm_do_get_edid()
> > http://lists.freedesktop.org/archives/dri-devel/2014-November/072906.html
> >   
> 
> Thank you for the heads-up, I'd not seen that.  I'll consider how my patch 
> might be modified to suit the new infrastructure.

You don't need any patch: drm_do_get_edid() already loops on reading
the EDID.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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 v2] fs-fat: Less function calls in fat_fill_super() after error detection

[OGAWA Hirofumi]

SF Markus Elfring  writes:

> From: Markus Elfring 
> Date: Sat, 29 Nov 2014 07:37:34 +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.

iput() checks NULL of inode. What is wrong just remove NULL check,
instead of adding new jump labels?

Thanks.
-- 
OGAWA Hirofumi 
--
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: [BUG] linux-next: 20141127 boot hang

[Stephen Rothwell]

Hi Jeremiah,

On Sat, 29 Nov 2014 01:15:10 -0800 Jeremiah Mahler  wrote:
>
> all,
> 
> On Fri, Nov 28, 2014 at 03:32:50PM -0800, Jeremiah Mahler wrote:
> > On Thu, Nov 27, 2014 at 03:16:19PM -0800, Jeremiah Mahler wrote:
> > > 
> > > I just tried the latest linux-next 20141127 (commit 3bcf494d225fd19) and
> > > it hangs very early in the boot sequence, after decompressing the kernel
> > > and after fsck (see attached screen shot).  I have tried it with two
> > > different machines and they both have the same problem.  It worked with
> > > version 20141126.
> > > 
> > []
> > 
> > My bisect results so far indicate that the bug was introduced by this
> > merge commit.
> > 
> >   commit 0305904a7416ced1358c5ff575e58135453bfc1d
> >   Merge: 38a4751 2ef5864
> >   Author: Stephen Rothwell 
> >   Date:   Thu Nov 27 14:53:44 2014 +1100
> >   
> >   Merge remote-tracking branch 'block/for-next'
> >   
> >   Conflicts:
> >   fs/fs-writeback.c
> > 
> []
> 
> Something is definitely broken at this merge commit.  I haven't
> quite figured out how to bisect the patches inside the merge commit.
> Any suggestions are welcome.

It could easily actually be the merge itself. There was a conflict in
that merge that I fixed up as best I could and asked others to check
the resolution.

I know that Cristoph thinks that the lazytime stuff is not ready for
-next yet, but are there any other comments?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpSsv8k0daVb.pgp
Description: OpenPGP digital signature

Re: [PATCH] e1000: remove unused variables

[Lino Sanfilippo]

On 29.11.2014 00:28, Florian Fainelli wrote:

> Also, if you do a read that is not stored in any return value, the
> compiler is now free to remove that actual read, 

This does not apply to reads from iomem (see "volatile" specifier in
readl()).

Regards,
Lino

--
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] mm/zsmalloc: allocate exactly size of struct zs_pool

[Ganesh Mahendran]

In zs_create_pool(), we allocate memory more then sizeof(struct zs_pool)
  ovhd_size = roundup(sizeof(*pool), PAGE_SIZE);

This patch allocate memory of exactly needed size.

Signed-off-by: Ganesh Mahendran 
---
 mm/zsmalloc.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 2021df5..4d0a063 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -979,12 +979,11 @@ static bool can_merge(struct size_class *prev, int size, 
int pages_per_zspage)
  */
 struct zs_pool *zs_create_pool(gfp_t flags)
 {
-   int i, ovhd_size;
+   int i;
struct zs_pool *pool;
struct size_class *prev_class = NULL;
 
-   ovhd_size = roundup(sizeof(*pool), PAGE_SIZE);
-   pool = kzalloc(ovhd_size, GFP_KERNEL);
+   pool = kzalloc(sizeof(*pool), GFP_KERNEL);
if (!pool)
return NULL;
 
-- 
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/

Re: [PATCH 1/2] ASoC: rt5677: Add ACPI device probing

[Mark Brown]

On Sat, Nov 29, 2014 at 12:51:59AM +0100, Rafael J. Wysocki wrote:
> On Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:

> > OK, we probably should have one to aid discoverability since as far as I
> > can tell what's happening is that people (hi Intel!) are allocating
> > their own identifiers for devices produced by other vendors that turn up
> > on their boards.  If people can find the set of IDs in use there's more
> > chance they'll use the same ones as other people.

> There's the PRP0001 ID that can be use to in combination with the
> "compatible" property which then works the same way as for DT.

> That should be sufficient if the properties are going to be the
> same for ACPI (_DSD) and DT.

We've got people making BIOSs right now for systems you can actually buy 
that are intended to run Windows which we need to support; right now the
pressing problem I'm seeing is that we've got BIOS vendors not using
properties at all and we're going to be ending up with configuration
coming from big DMI tables instead which is miserable, Windows is
perfectly happy to have custom drivers installed per machine.  Do we
know if Windows supports PRP0001 as it currently stands?

> > If those are device IDs then what you're saying is what I'd expect to
> > happen and it's part of the reason I'd expect us to be registering IDs
> > along with registering properties - if people are defining device
> > specific properties they really ought to be tied to the IDs that are in
> > use especially if (as seems likely to be the case with the current state
> > of the world) people are doing things without attempting to coordinate
> > and we're ending up trying to document the deployed reality.

> The rule of thumb (in my view) should be that if the device object's _DSD is
> going to return the same set of properties as for DT and no other special
> handling determined by the ID is required (ie. nothing along the lines of
> "if the device ID is X, the _ABC method works like that" which has to be known
> by the driver), "PRP0001" should be returned by _HID and then the value of the
> "compatible" property should be the same as for DT.

This is a reasonable idea but we do need it to be compatible with
Windows and we still need to make sure we have a process in place that
BIOS authors and driver authors focused on Windows can reasonably be
expected to work with.  That's not something we have right now for DT
(our DT process involves contributing to Linux) so the problem remains
effectively the same.

We also need a way of getting the word out to people that they should be
doing this (also a problem no matter if we use PRP0001 or something UEFI
specific).

> Otherwise, a new device ID needs to be allocated for the device and _HID
> should return that ID.  Also, if the device is compatible with another
> device with an already allocated ID (for _HID), _CID may return the device ID
> of the compatible device.  [Of course, it's better if _HID is the same for
> identical devices.]

I honestly don't see BIOS authors as being likely to care about adding
things to the CID if their systems are working (I'm assuming that HID is
the primary device ID and CID are further backup compatible IDs).


signature.asc
Description: Digital signature

[PATCH] Drivers:staging:clocking-wizard: Added a newline

[Athira S]

Fixed checkpatch warning:
Missing a newline after declarations

Signed-off-by: Athira S 
---
 drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c 
b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
index 7202d8e..bb01cb8 100644
--- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
+++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
@@ -248,6 +248,7 @@ static int clk_wzrd_probe(struct platform_device *pdev)
clkout_name, clk_name, 0, 1, reg);
if (IS_ERR(clk_wzrd->clkout[i])) {
int j;
+
for (j = i + 1; j < WZRD_NUM_OUTPUTS; j++)
clk_unregister(clk_wzrd->clkout[j]);
dev_err(&pdev->dev,
-- 
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: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection

[Julia Lawall]

On Sat, 29 Nov 2014, OGAWA Hirofumi wrote:

> SF Markus Elfring  writes:
>
> > From: Markus Elfring 
> > Date: Sat, 29 Nov 2014 07:37:34 +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.
>
> iput() checks NULL of inode. What is wrong just remove NULL check,
> instead of adding new jump labels?

Personally, I prefer that code that can be statically determined not to
need to be executed not to be executed.  It can make the code easier to
understand, because each function is only called when doing so is useful,
and it can be helpful to static analysis.

julia
--
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: [tip:irq/irqdomain] irqdomain: Introduce helper function irq_domain_add_hierarchy()

[Borislav Petkov]

On Sun, Nov 23, 2014 at 10:11:44AM -0800, tip-bot for Jiang Liu wrote:
> Commit-ID:  afb7da83b9f476728623130703acb553d7c7c4d9
> Gitweb: http://git.kernel.org/tip/afb7da83b9f476728623130703acb553d7c7c4d9
> Author: Jiang Liu 
> AuthorDate: Sat, 15 Nov 2014 22:24:02 +0800
> Committer:  Thomas Gleixner 
> CommitDate: Sun, 23 Nov 2014 13:01:46 +0100
> 
> irqdomain: Introduce helper function irq_domain_add_hierarchy()
> 
> Introduce helper function irq_domain_add_hierarchy(), which creates
> a linear irqdomain if parameter 'size' is not zero, otherwise creates
> a tree irqdomain.
> 
> Signed-off-by: Jiang Liu 
> Cc: Tony Luck 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Bjorn Helgaas 
> Cc: Grant Likely 
> Cc: Marc Zyngier 
> Cc: Yijing Wang 
> Cc: Yingjoe Chen 
> Cc: Borislav Petkov 
> Cc: Benjamin Herrenschmidt 
> Cc: Matthias Brugger 
> Link: 
> http://lkml.kernel.org/r/1416061447-9472-5-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner 
> ---
>  include/linux/irqdomain.h |  4 
>  kernel/irq/irqdomain.c| 36 
>  2 files changed, 40 insertions(+)
> 
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index dd2709b..676d730 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -259,6 +259,10 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d, 
> struct device_node *ctrlr,
>  extern struct irq_data *irq_domain_get_irq_data(struct irq_domain *domain,
>   unsigned int virq);
>  #ifdef   CONFIG_IRQ_DOMAIN_HIERARCHY
> +extern struct irq_domain *irq_domain_add_hierarchy(struct irq_domain *parent,
> + unsigned int flags, unsigned int size,
> + struct device_node *node,
> + const struct irq_domain_ops *ops, void *host_data);
>  extern int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
>  unsigned int nr_irqs, int node, void *arg,
>  bool realloc);
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 9c88db7..7fac311 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -742,6 +742,42 @@ static int irq_domain_alloc_descs(int virq, unsigned int 
> cnt,
>  }
>  
>  #ifdef   CONFIG_IRQ_DOMAIN_HIERARCHY
> +/**
> + * irq_domain_add_hierarchy - Add a irqdomain into the hierarchy
> + * @parent:  Parent irq domain to associate with the new domain
> + * @flags:   Irq domain flags associated to the domain
> + * @size:Size of the domain. See below
> + * @node:Optional device-tree node of the interrupt controller
> + * @ops: Pointer to the interrupt domain callbacks
> + * @host_data:   Controller private data pointer
> + *
> + * If @size is 0 a tree domain is created, otherwise a linear domain.
> + *
> + * If successful the parent is associated to the new domain and the
> + * domain flags are set.
> + * Returns pointer to IRQ domain, or NULL on failure.
> + */
> +struct irq_domain *irq_domain_add_hierarchy(struct irq_domain *parent,
> + unsigned int flags,
> + unsigned int size,
> + struct device_node *node,
> + const struct irq_domain_ops *ops,
> + void *host_data)
> +{
> + struct irq_domain *domain;
> +
> + if (size)
> + domain = irq_domain_add_linear(node, size, ops, host_data);
> + else
> + domain = irq_domain_add_tree(node, ops, host_data);
> + if (domain) {
> + domain->parent = parent;
> + domain->flags |= flags;
> + }

Ok, I'm going to reply to this patch because it is on the splat path but
fixing this would need a bit more reorganizing.

So I'm seeing the lockdep splat below really early on an IVB laptop.

Basically we're not supposed to do __GFP_FS allocations with IRQs off:

  2737  /* We're only interested __GFP_FS allocations for now */
  2738  if (!(gfp_mask & __GFP_FS))
  2739  return;
  2740  
  2741  /*
  2742   * Oi! Can't be having __GFP_FS allocations with IRQs disabled.
  2743   */
  2744  if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
<--- HERE!
  2745  return;
  2746  
  2747  mark_held_locks(curr, RECLAIM_FS);
  2748  }

Now, AFAICT, enable_IR_x2apic() disables interrupts and the whole init
is done with IRQs off but down that path intel_setup_irq_remapping()
calls irq_domain_add_hierarchy() and it does by default GFP_KERNEL
allocations.

The obvious fix is this and the machine boots fine with it. I'm not sure
it is kosher though so I rather run it by people first:

---
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 7fac311057b8..c21a003b996a 10

[PATCH] staging:drivers:staging:clocking-wizard:clk-xlnx-clock-wizard.c: Added a line after declaration

[Anjana Sasindran]

This patch fix the checkpatch.pl warning

WARNING:Missing a blank line after declaration

Signed-off-by: Anjana Sasindran 
---
 drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c 
b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
index 7202d8e..5fa813d 100644
--- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
+++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
@@ -234,6 +234,7 @@ static int clk_wzrd_probe(struct platform_device *pdev)
/* register div per output */
for (i = WZRD_NUM_OUTPUTS - 1; i >= 0 ; i--) {
const char *clkout_name;
+   
if (of_property_read_string_index(np, "clock-output-names", i,
  &clkout_name)) {
dev_err(&pdev->dev,
-- 
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: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

[Pavel Machek]

Hi!

> +Flash LED handling under Linux
> +==
> +
> +Some LED devices support two modes - torch and flash. The modes are
> +supported by the LED class (see Documentation/leds/leds-class.txt)
> +and LED Flash class respectively.
> +
> +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol
> +must be defined in the kernel config. A flash LED driver must register
> +in the LED subsystem with led_classdev_flash_register to gain flash
> +capabilities.
> +
> +Following sysfs attributes are exposed for controlling flash led devices:
> +
> + - flash_brightness - flash LED brightness in microamperes (RW)
> + - max_flash_brightness - maximum available flash LED brightness (RO)
> + - indicator_brightness - privacy LED brightness in microamperes (RW)
> + - max_indicator_brightness - maximum privacy LED brightness in
> +  microamperes (RO)
> + - flash_timeout - flash strobe duration in microseconds (RW)
> + - max_flash_timeout - maximum available flash strobe duration (RO)
> + - flash_strobe - flash strobe state (RW)
> + - flash_sync_strobe - one flash device can control more than one
> +   sub-led; when this atrribute is set to 1
> +   the flash led will be strobed synchronously
> +   with the other ones controlled by the same
> +   device (RW)

This is not really clear. Does flash_timeout or flash_brightness need
to be set, first?

Do we really want to have separate indicator brightnesses in uA?
Should we maybe reuse existing "brightness" parameter for torch and
indication, maybe adding single (RO) indicator_brightness attribute?

> + - flash_fault - bitmask of flash faults that may have occurred,
> + possible flags are:
> + * 0x01 - flash controller voltage to the flash LED has exceeded
> +  the limit specific to the flash controller
> + * 0x02 - the flash strobe was still on when the timeout set by
> +  the user has expired; not all flash controllers may
> +  set this in all such conditions
> + * 0x04 - the flash controller has overheated
> + * 0x08 - the short circuit protection of the flash controller
> +  has been triggered
> + * 0x10 - current in the LED power supply has exceeded the limit
> +  specific to the flash controller
> + * 0x40 - flash controller voltage to the flash LED has been
> +  below the minimum limit specific to the flash
> + * 0x80 - the input voltage of the flash controller is below
> +  the limit under which strobing the flash at full
> +  current will not be possible. The condition persists
> +  until this flag is no longer set
> + * 0x100 - the temperature of the LED has exceeded its allowed
> +   upper limit

How are faults cleared? Should it be list of strings, instead of
bitmask? We may want to add new fault modes in future...

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/RFC v8 04/14] v4l2-async: change custom.match callback argument type

[Pavel Machek]

On Fri 2014-11-28 10:17:56, Jacek Anaszewski wrote:
> It is useful to have an access to the async sub-device
> being matched, not only to the related struct device.
> Change match callback argument from struct device
> to struct v4l2_subdev. It will allow e.g. for matching
> a sub-device by its "name" property.
> 
> Signed-off-by: Jacek Anaszewski 
> Acked-by: Kyungmin Park 
> Cc: Guennadi Liakhovetski 
> Cc: Laurent Pinchart 
> Cc: Hans Verkuil 

Acked-by: Pavel Machek 
-- 
(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] ACPI / video: check _DOD list when creating backlight device

[Aaron Lu]

On 11/29/2014 01:18 AM, Brian Norris wrote:
> On Fri, Nov 28, 2014 at 07:55:00PM +0800, Aaron Lu wrote:
>> On 11/28/2014 05:59 PM, Brian Norris wrote:
>>> And indeed, there is a regression! My Dell Latituded E6410's backlight
>>> control no longer works after this commit, and I get messages like this
>>> instead:
>>>
>>> [   57.214610] ACPI: Failed to switch the brightness
>>>
>>> If I revert this commit, my backlight controls work again. Also, I
>>> regain a cooling device (?) that was being ignored:
>>>
>>> [1.332682] acpi device:02: registered as cooling_device0
>>>
>>> Do you need any additional info to handle the regression, or should we
>>> just revert the patch?
>>
>> Please attach acpidump, dmesg with video.dyndbg="module video +pft" in
>> kernel cmdline, list the /sys/class/backlight with and without this
>> commit, thanks.
> 
> Appending dmesg and attaching acpidump. Unfortunately, I'm using a few
> binary modules, since Wifi and GPU suspend/resume support are broken
> otherwise, but I did test briefly with Nouveau anyway. Results are
> essentially the same with Nouveau (although Nouveau seems to provide an
> extra backlight device, though it doesn't seem to do anything for me).
> 
> Before reverting:
> 
> $ ls -al /sys/class/backlight
> total 0
> drwxr-xr-x  2 root root 0 Nov 28 09:01 .
> drwxr-xr-x 58 root root 0 Nov 28 09:01 ..
> 
> After reverting:
> 
> $ ls -al /sys/class/backlight
> total 0
> drwxr-xr-x  2 root root 0 Nov 28 09:10 .
> drwxr-xr-x 50 root root 0 Nov 28 09:10 ..
> lrwxrwxrwx  1 root root 0 Nov 28 09:09 acpi_video0 -> 
> ../../devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0

The current logic to bind device doesn't work with your system, that
logic is there for a long time so I prefer not to change that, instead,
I can change the newly added function acpi_video_device_in_dod to let it
directly compare the 0-12 bits of the ID to decide if the video output
device is in the _DOD list. Can you please try the following patch?

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 41e6b977ceb2..185a57d13723 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1164,7 +1164,8 @@ static bool acpi_video_device_in_dod(struct 
acpi_video_device *device)
return true;
 
for (i = 0; i < video->attached_count; i++) {
-   if (video->attached_array[i].bind_info == device)
+   if ((video->attached_array[i].value.int_val & 0xfff) ==
+   (device->device_id & 0xfff))
return true;
}
 

Thanks,
Aaron
--
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/RFC v8 07/14] exynos4-is: Add support for v4l2-flash subdevs

[Pavel Machek]

On Fri 2014-11-28 10:17:59, Jacek Anaszewski wrote:
> This patch adds suppport for external v4l2-flash devices.
> The support includes parsing "flashes" Device Tree property
> and asynchronous subdevice registration.
> 
> Signed-off-by: Jacek Anaszewski 
> Acked-by: Kyungmin Park 
> Cc: Sylwester Nawrocki 

Acked-by: Pavel Machek 

-- 
(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/

[PATCH] staging:drivers:staging:ft1000:ft1000_pcmcia:ft1000_hw.c:Added a blank line after declaration

[Anjana Sasindran]

This patch fix the checkpatch.pl warning

WARNING: Missing a blank line after declaration

Signed-off-by: Anjana Sasindran 
---
 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 11dbe36..d5475b7 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -2042,6 +2042,7 @@ static void ft1000_get_drvinfo(struct net_device *dev,
 static u32 ft1000_get_link(struct net_device *dev)
 {
struct ft1000_info *info;
+
info = netdev_priv(dev);
return info->mediastate;
 }
-- 
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: [PATCH] staging:drivers:staging:ft1000:ft1000_pcmcia:ft1000_hw.c:Added a blank line after declaration

[Belisko Marek]

Hi Anjana,

please update subject to something like staging: ft1000: 

Marek


On Sat, Nov 29, 2014 at 2:34 PM, Anjana Sasindran
 wrote:
> This patch fix the checkpatch.pl warning
>
> WARNING: Missing a blank line after declaration
>
> Signed-off-by: Anjana Sasindran 
> ---
>  drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
> b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> index 11dbe36..d5475b7 100644
> --- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> +++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> @@ -2042,6 +2042,7 @@ static void ft1000_get_drvinfo(struct net_device *dev,
>  static u32 ft1000_get_link(struct net_device *dev)
>  {
> struct ft1000_info *info;
> +
> info = netdev_priv(dev);
> return info->mediastate;
>  }
> --
> 1.9.1
>



-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
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] HID: Wacom: Deletion of an unnecessary check before the function call "vfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 14:34:59 +0100

The vfree() function performs also input parameter validation.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/ethernet/sun/cassini.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/sun/cassini.c 
b/drivers/net/ethernet/sun/cassini.c
index 37f87ff..d745808 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -5179,8 +5179,7 @@ static void cas_remove_one(struct pci_dev *pdev)
cp = netdev_priv(dev);
unregister_netdev(dev);
 
-   if (cp->fw_data)
-   vfree(cp->fw_data);
+   vfree(cp->fw_data);
 
mutex_lock(&cp->pm_mutex);
cancel_work_sync(&cp->reset_task);
-- 
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: ft1000 : ft1000-pcmcia: replace __attribute ((__packed__) with __packed macro per coding style guidelines in ft1000_dnld.c

[Belisko Marek]

Please use shorter summary phrase (which appear an subject) + split
commit message to more line (not one long line).

marek

On Sat, Nov 29, 2014 at 3:49 AM, Geoff Darst  wrote:
> Replace two instances of __attribute ((__packed__) with __packed macro to 
> address the warning found by the checkpatch.pl tool.
>
> Signed-off-by: Geoff Darst 
> ---
>  drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c 
> b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
> index c1856f7..df1cf0c 100644
> --- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
> +++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c
> @@ -99,7 +99,7 @@ struct dsp_file_hdr {
> u32  version_data_offset;   /* Offset were scrambled version data 
> begins. */
> u32  version_data_size; /* Size, in words, of scrambled version data. 
> */
> u32  nDspImages;/* Number of DSP images in file. */
> -} __attribute__ ((packed));
> +} __packed;
>
>  struct dsp_image_info {
> u32  coff_date; /* Date/time when DSP Coff image was built. */
> @@ -110,7 +110,7 @@ struct dsp_image_info {
> u32  version;   /* Embedded version # of DSP code. */
> unsigned short checksum;/* Dsp File checksum */
> unsigned short pad1;
> -} __attribute__ ((packed));
> +} __packed;
>
>  void card_bootload(struct net_device *dev)
>  {
> --
> 1.9.3
>



-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
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:ft1000:ft1000_pcmcia:ft1000_hw.c:Added a blank line after declaration

[Anjana Sasindran]

This patch fix the checkpatch.pl warning

WARNING: Missing a blank line after declaration

Signed-off-by: Anjana Sasindran 
---
 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 11dbe36..d5475b7 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -2042,6 +2042,7 @@ static void ft1000_get_drvinfo(struct net_device *dev,
 static u32 ft1000_get_link(struct net_device *dev)
 {
struct ft1000_info *info;
+
info = netdev_priv(dev);
return info->mediastate;
 }
-- 
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: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection

[OGAWA Hirofumi]

Julia Lawall  writes:

>> iput() checks NULL of inode. What is wrong just remove NULL check,
>> instead of adding new jump labels?
>
> Personally, I prefer that code that can be statically determined not to
> need to be executed not to be executed.  It can make the code easier to
> understand, because each function is only called when doing so is useful,
> and it can be helpful to static analysis.

Hm, first of all, we want to prevent the bugs. More labels are more
chances of bug (and we don't care micro optimize on this error path),
isn't it?  Increasing the chance of bugs and bothers developers for
analyzer sounds like strange.

(And we are initializing those for avoiding to be bothered by choosing
correct label. If we really care micro optimize, initialization of those
should not be required and should not be touched on other paths, and gcc
can warn its usage.)

Thanks.
-- 
OGAWA Hirofumi 
--
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] net: cassini: Deletion of an unnecessary check before the function call "vfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 14:34:59 +0100

The vfree() function performs also input parameter validation.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/net/ethernet/sun/cassini.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/sun/cassini.c 
b/drivers/net/ethernet/sun/cassini.c
index 37f87ff..d745808 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -5179,8 +5179,7 @@ static void cas_remove_one(struct pci_dev *pdev)
cp = netdev_priv(dev);
unregister_netdev(dev);
 
-   if (cp->fw_data)
-   vfree(cp->fw_data);
+   vfree(cp->fw_data);
 
mutex_lock(&cp->pm_mutex);
cancel_work_sync(&cp->reset_task);
-- 
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: [tip:irq/irqdomain] irqdomain: Introduce helper function irq_domain_add_hierarchy()

[Jiang Liu]

On 2014/11/29 20:53, Borislav Petkov wrote:
> On Sun, Nov 23, 2014 at 10:11:44AM -0800, tip-bot for Jiang Liu wrote:
>> Commit-ID:  afb7da83b9f476728623130703acb553d7c7c4d9
>> Gitweb: 
>> http://git.kernel.org/tip/afb7da83b9f476728623130703acb553d7c7c4d9
>> Author: Jiang Liu 
>> AuthorDate: Sat, 15 Nov 2014 22:24:02 +0800
>> Committer:  Thomas Gleixner 
>> CommitDate: Sun, 23 Nov 2014 13:01:46 +0100
>>
>> irqdomain: Introduce helper function irq_domain_add_hierarchy()
>>
>> Introduce helper function irq_domain_add_hierarchy(), which creates
>> a linear irqdomain if parameter 'size' is not zero, otherwise creates
>> a tree irqdomain.
>>
>> Signed-off-by: Jiang Liu 
>> Cc: Tony Luck 
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: Bjorn Helgaas 
>> Cc: Grant Likely 
>> Cc: Marc Zyngier 
>> Cc: Yijing Wang 
>> Cc: Yingjoe Chen 
>> Cc: Borislav Petkov 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Matthias Brugger 
>> Link: 
>> http://lkml.kernel.org/r/1416061447-9472-5-git-send-email-jiang@linux.intel.com
>> Signed-off-by: Thomas Gleixner 
>> ---
>>  include/linux/irqdomain.h |  4 
>>  kernel/irq/irqdomain.c| 36 
>>  2 files changed, 40 insertions(+)
>>
>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>> index dd2709b..676d730 100644
>> --- a/include/linux/irqdomain.h
>> +++ b/include/linux/irqdomain.h
>> @@ -259,6 +259,10 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d, 
>> struct device_node *ctrlr,
>>  extern struct irq_data *irq_domain_get_irq_data(struct irq_domain *domain,
>>  unsigned int virq);
>>  #ifdef  CONFIG_IRQ_DOMAIN_HIERARCHY
>> +extern struct irq_domain *irq_domain_add_hierarchy(struct irq_domain 
>> *parent,
>> +unsigned int flags, unsigned int size,
>> +struct device_node *node,
>> +const struct irq_domain_ops *ops, void *host_data);
>>  extern int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
>> unsigned int nr_irqs, int node, void *arg,
>> bool realloc);
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index 9c88db7..7fac311 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -742,6 +742,42 @@ static int irq_domain_alloc_descs(int virq, unsigned 
>> int cnt,
>>  }
>>  
>>  #ifdef  CONFIG_IRQ_DOMAIN_HIERARCHY
>> +/**
>> + * irq_domain_add_hierarchy - Add a irqdomain into the hierarchy
>> + * @parent: Parent irq domain to associate with the new domain
>> + * @flags:  Irq domain flags associated to the domain
>> + * @size:   Size of the domain. See below
>> + * @node:   Optional device-tree node of the interrupt controller
>> + * @ops:Pointer to the interrupt domain callbacks
>> + * @host_data:  Controller private data pointer
>> + *
>> + * If @size is 0 a tree domain is created, otherwise a linear domain.
>> + *
>> + * If successful the parent is associated to the new domain and the
>> + * domain flags are set.
>> + * Returns pointer to IRQ domain, or NULL on failure.
>> + */
>> +struct irq_domain *irq_domain_add_hierarchy(struct irq_domain *parent,
>> +unsigned int flags,
>> +unsigned int size,
>> +struct device_node *node,
>> +const struct irq_domain_ops *ops,
>> +void *host_data)
>> +{
>> +struct irq_domain *domain;
>> +
>> +if (size)
>> +domain = irq_domain_add_linear(node, size, ops, host_data);
>> +else
>> +domain = irq_domain_add_tree(node, ops, host_data);
>> +if (domain) {
>> +domain->parent = parent;
>> +domain->flags |= flags;
>> +}
> 
> Ok, I'm going to reply to this patch because it is on the splat path but
> fixing this would need a bit more reorganizing.
> 
> So I'm seeing the lockdep splat below really early on an IVB laptop.
> 
> Basically we're not supposed to do __GFP_FS allocations with IRQs off:
> 
>   2737/* We're only interested __GFP_FS allocations for now */
>   2738if (!(gfp_mask & __GFP_FS))
>   2739return;
>   2740
>   2741/*
>   2742 * Oi! Can't be having __GFP_FS allocations with IRQs 
> disabled.
>   2743 */
>   2744if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
> <--- HERE!
>   2745return;
>   2746
>   2747mark_held_locks(curr, RECLAIM_FS);
>   2748}
> 
> Now, AFAICT, enable_IR_x2apic() disables interrupts and the whole init
> is done with IRQs off but down that path intel_setup_irq_remapping()
> calls irq_domain_add_hierarchy() and it does by default GFP_KERNEL
> alloca

[PATCH 1/1] HID: Wacom: Deletion of unnecessary checks before the function call "input_free_device"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 15:16:01 +0100

The input_free_device() 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 
---
 drivers/hid/wacom_sys.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index eb55316..21ced00 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1099,10 +1099,8 @@ static void wacom_free_inputs(struct wacom *wacom)
 {
struct wacom_wac *wacom_wac = &(wacom->wacom_wac);
 
-   if (wacom_wac->input)
-   input_free_device(wacom_wac->input);
-   if (wacom_wac->pad_input)
-   input_free_device(wacom_wac->pad_input);
+   input_free_device(wacom_wac->input);
+   input_free_device(wacom_wac->pad_input);
wacom_wac->input = NULL;
wacom_wac->pad_input = NULL;
 }
-- 
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: fs-fat: Less function calls in fat_fill_super() after error detection

[SF Markus Elfring]

> More labels are more chances of bug (and we don't care micro optimize
> on this error path), isn't it?

I would prefer that a few jump targets can be redirected so that unnecessary
function calls (and corresponding checks) can be avoided.


> Increasing the chance of bugs and bothers developers for analyzer sounds
> like strange.

There are different opinions around source code clarity.


> (And we are initializing those for avoiding to be bothered by choosing
> correct label.

Pointer initialisation is convenient and safe in some use cases, isn't it?


> If we really care micro optimize, initialization of those should not
> be required and should not be touched on other paths, and gcc can warn
> its usage.)

I imagine that a software optimiser can eventually perform better job
if unneeded statements could be omitted, couldn't it?

Regards,
Markus
--
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: [tip:irq/irqdomain] irqdomain: Introduce helper function irq_domain_add_hierarchy()

[Borislav Petkov]

On Sat, Nov 29, 2014 at 10:29:33PM +0800, Jiang Liu wrote:
>  Thanks for reporting and fixing this. How about using GFP_ATOMIC
> here?

Well, I don't see the need to use GFP_ATOMIC if we absolutely don't have
to. And in this case lockdep is, AFAICT, correct in saying that we still
can do allocations with interrupts disabled, only not go down into fs
and do all kinds of lock grabbing operations like page reclaim, writeout
or whatever it is being done nowadays there.

Yeah, this is also some old "no-no" in my memory which says that we
should almost never use GFP_ATOMIC if it can be helped.

OTOH, I wonder if this code would rather need to hand down explicit gfp
flags in case it should be able to do GFP_ATOMIC operations at some
point...

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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: [RFC v2 1/2] compiler: use compiler to detect integer overflows

[Sasha Levin]

On 11/26/2014 10:13 PM, Linus Torvalds wrote:
> .. which I didn't actually validate. And I suspect gcc won't be good
> enough to optimize, so it probably generates horrendous code.

That's correct. It's pretty bad.

> And the thing is, I think it's just *wrong* to do "overflow in signed
> type". The code that does it shouldn't be helped to do it, it should
> be fixed to use an unsigned type.
> 
> In other words - in this case, the lofft_t should probably just be a u64.

In this case it's very tied to userspace. One caller is the space allocation
ioctl, which gets this from userspace:

struct space_resv {
[...]
__s64   l_start;
__s64   l_len;  /* len == 0 means until end of file */
[...]
};

Since we can't just change those to unsigned, we'd still need to do an overflow
check with signed integers somewhere.


Thanks,
Sasha
--
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:ft1000_pcmcia:Added a blank line after declaration

[Anjana Sasindran]

This patch fix the checkpatch.pl warning

WARNING: Missing a blank line after declaration

Signed-off-by: Anjana Sasindran 
---
 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 11dbe36..d5475b7 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -2042,6 +2042,7 @@ static void ft1000_get_drvinfo(struct net_device *dev,
 static u32 ft1000_get_link(struct net_device *dev)
 {
struct ft1000_info *info;
+
info = netdev_priv(dev);
return info->mediastate;
 }
-- 
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: [RFC PATCH] proc, pidns: Add highpid

[Andy Lutomirski]

On Nov 28, 2014 9:24 PM, "Greg KH"  wrote:
>
> On Fri, Nov 28, 2014 at 03:05:01PM -0800, Andy Lutomirski wrote:
> > Pid reuse is common, which means that it's difficult or impossible
> > to read information about a pid from /proc without races.
> >
> > This introduces a second number associated with each (task, pidns)
> > pair called highpid.  Highpid is a 64-bit number, and, barring
> > extremely unlikely circumstances or outright error, a (highpid, pid)
> > will never be reused.
> >
> > With just this change, a program can open /proc/PID/status, read the
> > "Highpid" field, and confirm that it has the expected value.  If the
> > pid has been reused, then highpid will be different.
> >
> > The initial implementation is straightforward: highpid is simply a
> > 64-bit counter. If a high-end system can fork every 3 ns (which
> > would be amazing, given that just allocating a pid requires at
> > atomic operation), it would take well over 1000 years for highpid to
> > wrap.
> >
> > For CRIU's benefit, the next highpid can be set by a privileged
> > user.
> >
> > NB: The sysctl stuff only works on 64-bit systems.  If the approach
> > looks good, I'll fix that somehow.
> >
> > Signed-off-by: Andy Lutomirski 
> > ---
> >
> > If this goes in, there's plenty of room to add new interfaces to
> > make this more useful.  For example, we could add a fancier tgkill
> > that adds and validates hightgid and highpid, and we might want to
> > add a syscall to read one's own hightgid and highpid.  These would
> > be quite useful for pidfiles.
> >
> > David, would this be useful for kdbus?
> >
> > CRIU people: will this be unduly difficult to support in CRIU?
> >
> > If you all think this is a good idea, I'll fix the sysctl stuff and
> > document it.  It might also be worth adding "Hightgid" to status.
> >
> >  fs/proc/array.c   |  5 -
> >  include/linux/pid.h   |  2 ++
> >  include/linux/pid_namespace.h |  1 +
> >  kernel/pid.c  | 19 +++
> >  kernel/pid_namespace.c| 22 ++
> >  5 files changed, 44 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > index cd3653e4f35c..f1e0e69d19f9 100644
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -159,6 +159,7 @@ static inline void task_state(struct seq_file *m, 
> > struct pid_namespace *ns,
> >   int g;
> >   struct fdtable *fdt = NULL;
> >   const struct cred *cred;
> > + const struct upid *upid;
> >   pid_t ppid, tpid;
> >
> >   rcu_read_lock();
> > @@ -170,12 +171,14 @@ static inline void task_state(struct seq_file *m, 
> > struct pid_namespace *ns,
> >   if (tracer)
> >   tpid = task_pid_nr_ns(tracer, ns);
> >   }
> > + upid = pid_upid_ns(pid, ns);
> >   cred = get_task_cred(p);
> >   seq_printf(m,
> >   "State:\t%s\n"
> >   "Tgid:\t%d\n"
> >   "Ngid:\t%d\n"
> >   "Pid:\t%d\n"
> > + "Highpid:\t%llu\n"
> >   "PPid:\t%d\n"
> >   "TracerPid:\t%d\n"
> >   "Uid:\t%d\t%d\t%d\t%d\n"
>
> Changing existing proc files like this is dangerous and can cause lots
> of breakage in userspace programs if you are not careful.  Usually
> adding fields to the end of the file is best, but sometimes even then
> things can break :(

Point taken.  I had hoped that everything would parse /proc/PID/status
by looking for the lamed headers.  I'll see what the history of new
fields in there is, but I can change this easily enough.

--Andy

> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" 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: [tip:irq/irqdomain] irqdomain: Introduce helper function irq_domain_add_hierarchy()

[Jiang Liu]

On 2014/11/29 22:56, Borislav Petkov wrote:
> On Sat, Nov 29, 2014 at 10:29:33PM +0800, Jiang Liu wrote:
>>  Thanks for reporting and fixing this. How about using GFP_ATOMIC
>> here?
> 
> Well, I don't see the need to use GFP_ATOMIC if we absolutely don't have
> to. And in this case lockdep is, AFAICT, correct in saying that we still
> can do allocations with interrupts disabled, only not go down into fs
> and do all kinds of lock grabbing operations like page reclaim, writeout
> or whatever it is being done nowadays there.
> 
> Yeah, this is also some old "no-no" in my memory which says that we
> should almost never use GFP_ATOMIC if it can be helped.
Thanks for the info about GFP_ATOMIC, originally I have an impression
that we should use GFP_ATOMIC when interrupt is disabled:(

> 
> OTOH, I wonder if this code would rather need to hand down explicit gfp
> flags in case it should be able to do GFP_ATOMIC operations at some
> point...
> 
> Thanks.
> 
--
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] net-ipvlan: Deletion of an unnecessary check before the function call "free_percpu"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 16:23:20 +0100

The free_percpu() 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 
---
 drivers/net/ipvlan/ipvlan_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index 96b71b0..feb1853 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -125,8 +125,7 @@ static void ipvlan_uninit(struct net_device *dev)
struct ipvl_dev *ipvlan = netdev_priv(dev);
struct ipvl_port *port = ipvlan->port;
 
-   if (ipvlan->pcpu_stats)
-   free_percpu(ipvlan->pcpu_stats);
+   free_percpu(ipvlan->pcpu_stats);
 
port->count -= 1;
if (!port->count)
-- 
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: [RFC PATCH] proc, pidns: Add highpid

[Andy Lutomirski]

On Fri, Nov 28, 2014 at 7:34 PM, Eric W. Biederman
 wrote:
> Andy Lutomirski  writes:
>
>> Pid reuse is common, which means that it's difficult or impossible
>> to read information about a pid from /proc without races.
>
> Sigh.
>
> What we need are not race free pids, but a file descriptor based process
> management api.  Possibly one that starts by handing you a proc
> directory.

I agree completely, and the Capsicum stuff from FreeBSD would probably
be a very good start here.

>
> Which probably means that we need a proc file we can write to and send
> signals to a process, and another proc file we can select on and wait
> for the process to exit.

That too.  In fact, I have an old patch that went nowhere that makes
the proc directory fd itself pollable.

>
> Making pids bigger just looks like bandaid.
>
> Remember evovle things in the direction of an object capability system
> things wind up being more maintainable.

Yes, but this really is intended to be a much better bandaid than what
people currently use.

I'm aiming this at two main use cases that aren't going to switch to
using fds any time soon.  One is shell stuff and PID files.  If we can
put something like "12345@81726162" in /run/lock/foo.pid and safely
kill `cat /run/lock/foo.pid`, that would be nice (even though sensible
users don't use pid files any more, there are *tons* of things that
still use them).  This could also be used for diagnostics.  Suppose
the kernel log indicates a misbehaving pid.  There's currently no
race-free way to poke at those pids.

The much more pressing issue is that there are apparently programs
that think that checking the process's starttime is a good idea for
avoiding PID reuse races.  Both kdbus v1 and v2 do this, hopefully
only for diagnostics.  This is, IMO, completely unacceptable, but I
really don't expect kdbus to start passing even more fds around when
they'll be ignored most of the time.  So, if kdbus is going to be
merged at some point, I'd like to give it the opportunity to name the
sender of a message in a way that is only mildly dangerous (in non
race-related ways) as opposed to being totally broken.

Now if someone wants to implement real light-weight capability-ish fds
in Linux, that would be neat.  IIRC someone tried several years ago
using fds with some high bits set, but it never went anywhere.

FWIW, given that I seem to be the most vocal reviewer of the kdbus
patches, I feel like it's nice to offer some assistance in a piece of
the kdbus stuff that I think really would benefit from a new kernel
feature.

--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/

Re: [tip:irq/irqdomain] irqdomain: Introduce helper function irq_domain_add_hierarchy()

[Borislav Petkov]

On Sat, Nov 29, 2014 at 11:21:11PM +0800, Jiang Liu wrote:
> Thanks for the info about GFP_ATOMIC, originally I have an impression
> that we should use GFP_ATOMIC when interrupt is disabled:(

Hmm, that's actually a good point. GFP_NOFS has __GFP_WAIT which means
that we can wait and resched when the first alloc attempt fails so maybe
GFP_ATOMIC would be the correct solution after all...

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] Drivers:input:mousedev.c: Fixed trailing statement on the next line

[Athira S]

Fixed checkpatch error:
trailing statements should be on next line

Signed-off-by: Athira S 
---
 drivers/input/mousedev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index b604564..be2cc5c 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -248,7 +248,8 @@ static void mousedev_key_event(struct mousedev *mousedev,
case BTN_4:
case BTN_EXTRA: index = 4; break;
 
-   default:return;
+   default:
+   return;
}
 
if (value) {
-- 
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 1/1] fs-notify: Deletion of an unnecessary check before the function call "iput"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 16:42:50 +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/notify/inode_mark.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/notify/inode_mark.c b/fs/notify/inode_mark.c
index 3daf513..d8157a6 100644
--- a/fs/notify/inode_mark.c
+++ b/fs/notify/inode_mark.c
@@ -231,8 +231,7 @@ void fsnotify_unmount_inodes(struct list_head *list)
 */
spin_unlock(&inode_sb_list_lock);
 
-   if (need_iput_tmp)
-   iput(need_iput_tmp);
+   iput(need_iput_tmp);
 
/* for each watch, send FS_UNMOUNT and then remove it */
fsnotify(inode, FS_UNMOUNT, inode, FSNOTIFY_EVENT_INODE, NULL, 
0);
-- 
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: [RFC PATCH] userns: Disallow setgroups unless the gid_map writer is privileged

[serge]

iiuc this should be ok for lxc since it always has a privileged map writer. 

(sorry I'm pretty much afk until dec 10)

Thanks,
- sergeOn 11/28/14 16:53 Andy Lutomirski wrote:
Classic unix permission checks have an interesting feature.  The
group permissions for a file can be set to less than the other
permissions on a file.  Occasionally this is used deliberately to
give a certain group of users fewer permissions than the default.

User namespaces break this usage.  Groups set in rgid or egid are
unaffected because an unprivileged user namespace creator can only
map a single group, so setresgid inside and outside the namespace
have the same effect.  However, an unprivileged user namespace
creator can currently use setgroups(2) to drop all supplementary
groups, so, if a supplementary group denies access to some resource,
user namespaces can be used to bypass that restriction.

To fix this issue without unduly breaking existing user code, this
introduces a new user namespace flag USERNS_SETGROUPS_ALLOWED.  If
that flag is not set, then setgroups(2) will fail regardless of the
caller's capabilities.

USERNS_SETGROUPS_ALLOWED is cleared in a new user namespace.  By
default, if the writer of gid_map has CAP_SETGID in the parent
userns and the parent userns has USERNS_SETGROUPS_ALLOWED, then the
USERNS_SETGROUPS_ALLOWED will be set in the child.

While it could be safe to set USERNS_SETGROUPS_ALLOWED if the user
namespace creator has no supplementary groups, doing so could be
surprising and could have unpleasant interactions with setns(2).

The default behavior can be overridden by adding a line of the form
"setgroups allow" or "setgroups deny" to gid_map.  The former will
return -EPERM if the caller is not permitted to set
USERNS_SETGROUPS_ALLOWED, and the latter will clear
USERNS_SETGROUPS_ALLOWED even if the flag would otherwise be set.

This change should break userspace by the minimal amount needed to
fix this issue.  Any application that uses newgidmap(1) should be
unaffected by this fix, and unprivileged users that create user
namespaces to manipulate mounts or sandbox themselves will also be
unaffected unless they try to use setgroups(2).

This should fix CVE-2014-8989.

Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski 
---

Eric, this is an alternative to your patch.  I think it will cause
less breakage, and it will keep unprivileged user namespaces
more or less fully functional.

Kenton, I think that neither run-bundle nor supervisor-main will be
broken by this patch.

 include/linux/user_namespace.h |  3 +++
 kernel/groups.c|  3 +++
 kernel/user.c  |  1 +
 kernel/user_namespace.c| 36 
 4 files changed, 43 insertions(+)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index e95372654f09..a74c1f3d44fe 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -17,6 +17,8 @@ struct uid_gid_map {  /* 64 bytes -- 1 cache line */
} extent[UID_GID_MAP_MAX_EXTENTS];
 };
 
+#define USERNS_SETGROUPS_ALLOWED 1
+
 struct user_namespace {
struct uid_gid_map  uid_map;
struct uid_gid_map  gid_map;
@@ -27,6 +29,7 @@ struct user_namespace {
kuid_t  owner;
kgid_t  group;
unsigned intproc_inum;
+   unsigned intflags;
 
/* Register of per-UID persistent keyrings for this namespace */
 #ifdef CONFIG_PERSISTENT_KEYRINGS
diff --git a/kernel/groups.c b/kernel/groups.c
index 451698f86cfa..e27433809978 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* init to 2 - one for init_task, one to ensure it is never freed */
@@ -223,6 +224,8 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user *, 
grouplist)
struct group_info *group_info;
int retval;
 
+   if (!(current_user_ns()->flags & USERNS_SETGROUPS_ALLOWED))
+   return -EPERM;
if (!ns_capable(current_user_ns(), CAP_SETGID))
return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
diff --git a/kernel/user.c b/kernel/user.c
index 4efa39350e44..f8cdb1ec6049 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -51,6 +51,7 @@ struct user_namespace init_user_ns = {
.owner = GLOBAL_ROOT_UID,
.group = GLOBAL_ROOT_GID,
.proc_inum = PROC_USER_INIT_INO,
+   .flags = USERNS_SETGROUPS_ALLOWED,
 #ifdef CONFIG_PERSISTENT_KEYRINGS
.persistent_keyring_register_sem =
__RWSEM_INITIALIZER(init_user_ns.persistent_keyring_register_sem),
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index aa312b0dc3ec..6e7b9ee5bddc 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -600,6 +600,8 @@ static ssize_t map_write(struct file *file, const char 
__user *buf,
unsigned long page = 0;
char *kbuf, *pos, *next_line;

Re: [PATCH] Drivers:input:mousedev.c: Fixed trailing statement on the next line

[Belisko Marek]

On Sat, Nov 29, 2014 at 4:39 PM, Athira S  wrote:
> Fixed checkpatch error:
> trailing statements should be on next line
>
> Signed-off-by: Athira S 
> ---
>  drivers/input/mousedev.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
> index b604564..be2cc5c 100644
> --- a/drivers/input/mousedev.c
> +++ b/drivers/input/mousedev.c
> @@ -248,7 +248,8 @@ static void mousedev_key_event(struct mousedev *mousedev,
> case BTN_4:
> case BTN_EXTRA: index = 4; break;
>
> -   default:return;
> +   default:
> +   return;
    missing tab here
> }
>
> if (value) {
> --
> 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/

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
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-namei: Deletion of an unnecessary check before the function call "iput"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 17:00:21 +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/namei.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index ca81416..ce69074 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3759,8 +3759,7 @@ exit2:
dput(dentry);
}
mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
-   if (inode)
-   iput(inode);/* truncate the inode here */
+   iput(inode);/* truncate the inode here */
inode = NULL;
if (delegated_inode) {
error = break_deleg_wait(&delegated_inode);
-- 
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] i8k: Add support for temperature sensor labels

[Pali Rohár]

This patch adds labels for temperature sensors if SMM function with EAX register
0x11a3 reports it. These informations was taken from DOS binary NBSVC.MDM.

Signed-off-by: Pali Rohár 
---
 drivers/char/i8k.c |  110 +---
 1 file changed, 88 insertions(+), 22 deletions(-)

diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index e34a019..77af46b 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -42,6 +42,7 @@
 #define I8K_SMM_GET_FAN0x00a3
 #define I8K_SMM_GET_SPEED  0x02a3
 #define I8K_SMM_GET_TEMP   0x10a3
+#define I8K_SMM_GET_TEMP_TYPE  0x11a3
 #define I8K_SMM_GET_DELL_SIG1  0xfea3
 #define I8K_SMM_GET_DELL_SIG2  0xffa3
 
@@ -288,6 +289,14 @@ static int i8k_set_fan(int fan, int speed)
return i8k_smm(®s) ? : i8k_get_fan_status(fan);
 }
 
+static int i8k_get_temp_type(int sensor)
+{
+   struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP_TYPE, };
+
+   regs.ebx = sensor & 0xff;
+   return i8k_smm(®s) ? : regs.eax & 0xff;
+}
+
 /*
  * Read the cpu temperature.
  */
@@ -493,6 +502,29 @@ static int i8k_open_fs(struct inode *inode, struct file 
*file)
  * Hwmon interface
  */
 
+static ssize_t i8k_hwmon_show_temp_label(struct device *dev,
+  struct device_attribute *devattr,
+  char *buf)
+{
+   static const char * const labels[] = {
+   "CPU",
+   "GPU",
+   "SODIMM",
+   "Other",
+   "Ambient",
+   "Other",
+   };
+   int index = to_sensor_dev_attr(devattr)->index;
+   int type;
+
+   type = i8k_get_temp_type(index);
+   if (type < 0)
+   return type;
+   if (type >= ARRAY_SIZE(labels))
+   type = ARRAY_SIZE(labels) - 1;
+   return sprintf(buf, "%s\n", labels[type]);
+}
+
 static ssize_t i8k_hwmon_show_temp(struct device *dev,
   struct device_attribute *devattr,
   char *buf)
@@ -555,9 +587,13 @@ static ssize_t i8k_hwmon_set_pwm(struct device *dev,
 }
 
 static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 0);
+static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, i8k_hwmon_show_temp_label, 
NULL, 0);
 static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp2_label, S_IRUGO, i8k_hwmon_show_temp_label, 
NULL, 1);
 static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp3_label, S_IRUGO, i8k_hwmon_show_temp_label, 
NULL, 2);
 static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 3);
+static SENSOR_DEVICE_ATTR(temp4_label, S_IRUGO, i8k_hwmon_show_temp_label, 
NULL, 3);
 static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, i8k_hwmon_show_fan, NULL,
  I8K_FAN_LEFT);
 static SENSOR_DEVICE_ATTR(pwm1, S_IRUGO | S_IWUSR, i8k_hwmon_show_pwm,
@@ -569,31 +605,35 @@ static SENSOR_DEVICE_ATTR(pwm2, S_IRUGO | S_IWUSR, 
i8k_hwmon_show_pwm,
 
 static struct attribute *i8k_attrs[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr, /* 0 */
-   &sensor_dev_attr_temp2_input.dev_attr.attr, /* 1 */
-   &sensor_dev_attr_temp3_input.dev_attr.attr, /* 2 */
-   &sensor_dev_attr_temp4_input.dev_attr.attr, /* 3 */
-   &sensor_dev_attr_fan1_input.dev_attr.attr,  /* 4 */
-   &sensor_dev_attr_pwm1.dev_attr.attr,/* 5 */
-   &sensor_dev_attr_fan2_input.dev_attr.attr,  /* 6 */
-   &sensor_dev_attr_pwm2.dev_attr.attr,/* 7 */
+   &sensor_dev_attr_temp1_label.dev_attr.attr, /* 1 */
+   &sensor_dev_attr_temp2_input.dev_attr.attr, /* 2 */
+   &sensor_dev_attr_temp2_label.dev_attr.attr, /* 3 */
+   &sensor_dev_attr_temp3_input.dev_attr.attr, /* 4 */
+   &sensor_dev_attr_temp3_label.dev_attr.attr, /* 5 */
+   &sensor_dev_attr_temp4_input.dev_attr.attr, /* 6 */
+   &sensor_dev_attr_temp4_label.dev_attr.attr, /* 7 */
+   &sensor_dev_attr_fan1_input.dev_attr.attr,  /* 8 */
+   &sensor_dev_attr_pwm1.dev_attr.attr,/* 9 */
+   &sensor_dev_attr_fan2_input.dev_attr.attr,  /* 10 */
+   &sensor_dev_attr_pwm2.dev_attr.attr,/* 11 */
NULL
 };
 
 static umode_t i8k_is_visible(struct kobject *kobj, struct attribute *attr,
  int index)
 {
-   if (index == 0 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP1))
+   if (index >= 0 && index <= 1 && !(i8k_hwmon_flags & 
I8K_HWMON_HAVE_TEMP1))
return 0;
-   if (index == 1 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP2))
+   if (index >= 2 && index <= 3 && !(i8k_hwmon_flags & 
I8K_HWMON_HAVE_TEMP2))
return 0;
-   if (index == 2 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP3))
+   if (index >= 4 && index <= 5 && !(i8k_hwmon_flags & 
I8K_HWMON_HAVE_TEMP3)

Re: [RFC PATCH] proc, pidns: Add highpid

[Cyrill Gorcunov]

On Fri, Nov 28, 2014 at 03:05:01PM -0800, Andy Lutomirski wrote:
> Pid reuse is common, which means that it's difficult or impossible
> to read information about a pid from /proc without races.
> 
> This introduces a second number associated with each (task, pidns)
> pair called highpid.  Highpid is a 64-bit number, and, barring
> extremely unlikely circumstances or outright error, a (highpid, pid)
> will never be reused.
> 
> With just this change, a program can open /proc/PID/status, read the
> "Highpid" field, and confirm that it has the expected value.  If the
> pid has been reused, then highpid will be different.
> 
> The initial implementation is straightforward: highpid is simply a
> 64-bit counter. If a high-end system can fork every 3 ns (which
> would be amazing, given that just allocating a pid requires at
> atomic operation), it would take well over 1000 years for highpid to
> wrap.
> 
> For CRIU's benefit, the next highpid can be set by a privileged
> user.
> 
> NB: The sysctl stuff only works on 64-bit systems.  If the approach
> looks good, I'll fix that somehow.
> 
> Signed-off-by: Andy Lutomirski 
> ---
> 
> If this goes in, there's plenty of room to add new interfaces to
> make this more useful.  For example, we could add a fancier tgkill
> that adds and validates hightgid and highpid, and we might want to
> add a syscall to read one's own hightgid and highpid.  These would
> be quite useful for pidfiles.
> 
> David, would this be useful for kdbus?
> 
> CRIU people: will this be unduly difficult to support in CRIU?

Hi Andy. I think it won't be hard to support.
--
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: fs-fat: Less function calls in fat_fill_super() after error detection

[OGAWA Hirofumi]

SF Markus Elfring  writes:

>> More labels are more chances of bug (and we don't care micro optimize
>> on this error path), isn't it?
>
> I would prefer that a few jump targets can be redirected so that unnecessary
> function calls (and corresponding checks) can be avoided.

It is from real bugs in my experience, it saw several times those (mine
and other guys, in linux and others). And I think it doesn't have value
to maintain labels for micro optimization in *this error path* though.

So, if you or analyzer can check bugs by the patches affect to those
label usage in future,

Acked-by: OGAWA Hirofumi 
-- 
OGAWA Hirofumi 
--
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] i8k: Add support for temperature sensor labels

[Pali Rohár]

On Saturday 29 November 2014 17:04:07 Pali Rohár wrote:
> This patch adds labels for temperature sensors if SMM function
> with EAX register 0x11a3 reports it. These informations was
> taken from DOS binary NBSVC.MDM.
> 
> Signed-off-by: Pali Rohár 
> ---
>  drivers/char/i8k.c |  110
> +--- 1 file
> changed, 88 insertions(+), 22 deletions(-)

I tested patch on Latitude E6440 and i8k CPU & GPU temps match 
intel coretemp & amd radeion temps.

But I would like if somebody with other Dell laptop can test if 
temperature labels are correct...

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH urgent v2] sched: Add missing rcu protection to wake_up_all_idle_cpus

[Andy Lutomirski]

Locklessly doing is_idle_task(rq->curr) is only okay because of RCU
protection.  The older variant of the broken code checked
rq->curr == rq->idle instead and therefore didn't need RCU.

Fixes: f6be8af1c95d sched: Add new API wake_up_if_idle() to wake up the idle cpu
Cc: Chuansheng Liu 
Signed-off-by: Andy Lutomirski 
---

This fixes a 3.18 regression, I think.  This code seems to only be called
inside preempt_disable, so I think it's unlikely to be a problem in practice.

Compile-tested only, although the kbuild bot is chewing on it.

Changes from v1:
 - Cc the right people (whoops)
 - Add rcu_read_lock and rcu_read_unlock.

 kernel/sched/core.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 240157c13ddc..b7937512965f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1623,8 +1623,10 @@ void wake_up_if_idle(int cpu)
struct rq *rq = cpu_rq(cpu);
unsigned long flags;
 
-   if (!is_idle_task(rq->curr))
-   return;
+   rcu_read_lock();
+
+   if (!is_idle_task(rcu_dereference(rq->curr)))
+   goto out;
 
if (set_nr_if_polling(rq->idle)) {
trace_sched_wake_idle_without_ipi(cpu);
@@ -1635,6 +1637,9 @@ void wake_up_if_idle(int cpu)
/* Else cpu is not in idle, do nothing here */
raw_spin_unlock_irqrestore(&rq->lock, flags);
}
+
+out:
+   rcu_read_unlock();
 }
 
 bool cpus_share_cache(int this_cpu, int that_cpu)
-- 
1.9.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: [RFC PATCH] userns: Disallow setgroups unless the gid_map writer is privileged

[Eric W. Biederman]

Andy Lutomirski  writes:

The patch is buggy.

Nacked-by: "Eric W. Biederman" 

> ---
>
> Eric, this is an alternative to your patch.  I think it will cause
> less breakage, and it will keep unprivileged user namespaces
> more or less fully functional.
>
> Kenton, I think that neither run-bundle nor supervisor-main will be
> broken by this patch.
>
>  include/linux/user_namespace.h |  3 +++
>  kernel/groups.c|  3 +++
>  kernel/user.c  |  1 +
>  kernel/user_namespace.c| 36 
>  4 files changed, 43 insertions(+)
>
> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
> index e95372654f09..a74c1f3d44fe 100644
> --- a/include/linux/user_namespace.h
> +++ b/include/linux/user_namespace.h
> @@ -17,6 +17,8 @@ struct uid_gid_map {/* 64 bytes -- 1 cache line */
>   } extent[UID_GID_MAP_MAX_EXTENTS];
>  };
>  
> +#define USERNS_SETGROUPS_ALLOWED 1
> +
>  struct user_namespace {
>   struct uid_gid_map  uid_map;
>   struct uid_gid_map  gid_map;
> @@ -27,6 +29,7 @@ struct user_namespace {
>   kuid_t  owner;
>   kgid_t  group;
>   unsigned intproc_inum;
> + unsigned intflags;

If you are going to add a flags field it needs to be atomic as otherwise
changing or reading individual flags won't be safe without a lock.

>   /* Register of per-UID persistent keyrings for this namespace */
>  #ifdef CONFIG_PERSISTENT_KEYRINGS
> diff --git a/kernel/groups.c b/kernel/groups.c
> index 451698f86cfa..e27433809978 100644
> --- a/kernel/groups.c
> +++ b/kernel/groups.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /* init to 2 - one for init_task, one to ensure it is never freed */
> @@ -223,6 +224,8 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user 
> *, grouplist)
>   struct group_info *group_info;
>   int retval;
>  
> + if (!(current_user_ns()->flags & USERNS_SETGROUPS_ALLOWED))
> + return -EPERM;
>   if (!ns_capable(current_user_ns(), CAP_SETGID))
>   return -EPERM;
>   if ((unsigned)gidsetsize > NGROUPS_MAX)
> diff --git a/kernel/user.c b/kernel/user.c
> index 4efa39350e44..f8cdb1ec6049 100644
> --- a/kernel/user.c
> +++ b/kernel/user.c
> @@ -51,6 +51,7 @@ struct user_namespace init_user_ns = {
>   .owner = GLOBAL_ROOT_UID,
>   .group = GLOBAL_ROOT_GID,
>   .proc_inum = PROC_USER_INIT_INO,
> + .flags = USERNS_SETGROUPS_ALLOWED,
>  #ifdef CONFIG_PERSISTENT_KEYRINGS
>   .persistent_keyring_register_sem =
>   __RWSEM_INITIALIZER(init_user_ns.persistent_keyring_register_sem),
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index aa312b0dc3ec..6e7b9ee5bddc 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -600,6 +600,8 @@ static ssize_t map_write(struct file *file, const char 
> __user *buf,
>   unsigned long page = 0;
>   char *kbuf, *pos, *next_line;
>   ssize_t ret = -EINVAL;
> + unsigned int gid_flags = 0;
> + bool seen_explicit_gid_flag = false;
>  
>   /*
>* The id_map_mutex serializes all writes to any given map.
> @@ -633,6 +635,19 @@ static ssize_t map_write(struct file *file, const char 
> __user *buf,
>   if (cap_valid(cap_setid) && !file_ns_capable(file, ns, CAP_SYS_ADMIN))
>   goto out;
>  
> + /* Deal with supplementary groups. */
> + if (map == &ns->gid_map) {
> + /*
> +  * By default, setgroups is allowed inside the userns
> +  * if the writer has no supplementary groups (making
> +  * it useless) or if the writer is privileged.
> +  */
> + if ((ns->parent->flags & USERNS_SETGROUPS_ALLOWED) &&
> + file_ns_capable(file, ns->parent, CAP_SETGID) &&
> + ns_capable(ns->parent, CAP_SETGID))
> + gid_flags = USERNS_SETGROUPS_ALLOWED;

We can't do this.

It is wrong to mix permissions and flags to request functionality.

That way lies madness, and impossible maintenance, and it will silently
break every application that expects setgroups to work if they have
CAP_SETGID after a mapping has been established.

> + }
> +
>   /* Get a buffer */
>   ret = -ENOMEM;
>   page = __get_free_page(GFP_TEMPORARY);
> @@ -667,6 +682,25 @@ static ssize_t map_write(struct file *file, const char 
> __user *buf,
>   next_line = NULL;
>   }
>  
> + /* Is this line a gid_map option? */
> + if (map == &ns->gid_map) {
> + if (!strcmp(pos, "setgroups deny")) {
> + if (seen_explicit_gid_flag)
> + goto out;
> + seen_explicit_gid_flag = 1;
> + gid_flags = 0;
> + continu

Re: [PATCH 2/7] KVM: arm: guest debug, define API headers

[Christoffer Dall]

On Tue, Nov 25, 2014 at 04:10:00PM +, Alex Bennée wrote:
> This commit defines the API headers for guest debugging. There are two
> architecture specific debug structures:
> 
>   - kvm_guest_debug_arch, allows us to pass in HW debug registers
>   - kvm_debug_exit_arch, signals the exact debug exit and address
> 
> The type of debugging being used is control by the architecture specific
s/control/controlled/ ?
> control bits of the kvm_guest_debug->control flags in the ioctl
> structure.
> 
> Signed-off-by: Alex Bennée 
> 
> diff --git a/arch/arm64/include/uapi/asm/kvm.h 
> b/arch/arm64/include/uapi/asm/kvm.h
> index 8e38878..de2450c 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -93,10 +93,30 @@ struct kvm_sregs {
>  struct kvm_fpu {
>  };
>  
> +/* See ARM ARM D7.3: Debug Registers

/* needs to go on a separate line.

> + *
> + * The control registers are stored as 64bit values as the setup code
> + * is shared with the normal cpu context restore code in hyp.S which
> + * is 64 bit only.

is this comment here because the architecture defines them as 32-bits?
If so, adding that would make this comment make more sense.

> + */
> +#define KVM_ARM_NDBG_REGS 16
>  struct kvm_guest_debug_arch {
> + __u64 dbg_bcr[KVM_ARM_NDBG_REGS];
> + __u64 dbg_bvr[KVM_ARM_NDBG_REGS];
> + __u64 dbg_wcr[KVM_ARM_NDBG_REGS];
> + __u64 dbg_wvr[KVM_ARM_NDBG_REGS];
>  };
>  
> +/* Exit types which define why we did a debug exit */
> +#define KVM_DEBUG_EXIT_ERROR 0x0
> +#define KVM_DEBUG_EXIT_SINGLE_STEP   0x1
> +#define KVM_DEBUG_EXIT_SW_BKPT   0x2
> +#define KVM_DEBUG_EXIT_HW_BKPT   0x3
> +#define KVM_DEBUG_EXIT_HW_WTPT   0x4
> +
>  struct kvm_debug_exit_arch {
> + __u64 address;
> + __u32 exit_type;
>  };
>  
>  struct kvm_sync_regs {
> @@ -198,4 +218,12 @@ struct kvm_arch_memory_slot {
>  
>  #endif
>  
> +/* Architecture related debug defines - upper 16 bits of

same not with commenting style here

> + * kvm_guest_debug->control
> + */
> +#define KVM_GUESTDBG_USE_SW_BP_SHIFT 16
> +#define KVM_GUESTDBG_USE_SW_BP   (1 << 
> KVM_GUESTDBG_USE_SW_BP_SHIFT)
> +#define KVM_GUESTDBG_USE_HW_BP_SHIFT 17
> +#define KVM_GUESTDBG_USE_HW_BP   (1 << 
> KVM_GUESTDBG_USE_HW_BP_SHIFT)
> +
>  #endif /* __ARM_KVM_H__ */
> -- 
> 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 2/7] KVM: arm: guest debug, define API headers

[Christoffer Dall]

On Wed, Nov 26, 2014 at 03:04:10PM +, Alex Bennée wrote:
> 
> Peter Maydell  writes:
> 
> > On 25 November 2014 at 16:10, Alex Bennée  wrote:
> >> +/* Exit types which define why we did a debug exit */
> >> +#define KVM_DEBUG_EXIT_ERROR   0x0
> >> +#define KVM_DEBUG_EXIT_SINGLE_STEP 0x1
> >> +#define KVM_DEBUG_EXIT_SW_BKPT 0x2
> >> +#define KVM_DEBUG_EXIT_HW_BKPT 0x3
> >> +#define KVM_DEBUG_EXIT_HW_WTPT 0x4
> >
> > The names of these imply that they're generic, but they're
> > defined in an arch-specific header file...
> 
> Yeah, I think these will die and I'll just export the syndrome
> information directly to QEMU.

huh?

-Christoffer
--
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 3/7] KVM: arm: guest debug, add stub KVM_SET_GUEST_DEBUG ioctl

[Christoffer Dall]

On Tue, Nov 25, 2014 at 04:10:01PM +, Alex Bennée wrote:
> This commit adds a stub function to support the KVM_SET_GUEST_DEBUG
> ioctl. Currently any operation flag will return EINVAL. Actual
> functionality will be added with further patches.
> 
> Signed-off-by: Alex Bennée .
> 
> diff --git a/Documentation/virtual/kvm/api.txt 
> b/Documentation/virtual/kvm/api.txt
> index 7610eaa..2c6386e 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2570,7 +2570,7 @@ handled.
>  4.87 KVM_SET_GUEST_DEBUG
>  
>  Capability: KVM_CAP_SET_GUEST_DEBUG
> -Architectures: x86, s390, ppc
> +Architectures: x86, s390, ppc, arm64
>  Type: vcpu ioctl
>  Parameters: struct kvm_guest_debug (in)
>  Returns: 0 on success; -1 on error
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 9e193c8..a0ff410 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -180,6 +180,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
> ext)
>   case KVM_CAP_ARM_PSCI:
>   case KVM_CAP_ARM_PSCI_0_2:
>   case KVM_CAP_READONLY_MEM:
> + case KVM_CAP_SET_GUEST_DEBUG:

Don't we usually wait with introducing visibility to user space until
you actually do support the ioctl?

>   r = 1;
>   break;
>   case KVM_CAP_COALESCED_MMIO:
> @@ -302,7 +303,34 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>  int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>   struct kvm_guest_debug *dbg)
>  {
> - return -EINVAL;
> + /* If it's not enabled clear all flags */
> + if (!(dbg->control & KVM_GUESTDBG_ENABLE)) {
> + vcpu->guest_debug = 0;
> + return 0;
> + }
> +
> + vcpu->guest_debug = dbg->control;
> + kvm_info("%s: guest_debug is 0x%lx\n", __func__, vcpu->guest_debug);
> +
> + /* Single Step */
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + kvm_info("SS requested, not yet implemented\n");
> + return -EINVAL;
> + }
> +
> + /* Software Break Points */
> + if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP) {
> + kvm_info("SW BP support requested, not yet implemented\n");
> + return -EINVAL;
> + }
> +
> + /* Hardware assisted Break and Watch points */
> + if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
> + kvm_info("HW BP support requested, not yet implemented\n");
> + return -EINVAL;
> + }
> +
> + return 0;
>  }
>  
>  
> -- 
> 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 4/7] KVM: arm64: guest debug, add SW break point support

[Christoffer Dall]

On Wed, Nov 26, 2014 at 05:07:20PM +0100, Andrew Jones wrote:
> On Tue, Nov 25, 2014 at 04:10:02PM +, Alex Bennée wrote:
> > This adds support for SW breakpoints inserted by userspace.
> > 
> > First we need to trap all BKPT exceptions in the hypervisor (ELS). This
> > in controlled through the MDCR_EL2 register. I've added a new field to
> > the vcpu structure to hold this value. There should be scope to
> > rationlise this with the VCPU_DEBUG_FLAGS/KVM_ARM64_DEBUG_DIRTY_SHIFT
> > manipulation in later patches.
> 
> I think we should start using the new mdcr_el2 field everywhere we plan
> to within the same series that it is introduced. Otherwise it's hard
> to tell if we need an mdcr_el2 field, or if a more generic field would
> suffice. We can always translate bits of a more generic field to
> mdcr_el2 bits when necessary, but not the reverse.
> 
Agreed, this is getting messy already with this patch.

-Christoffer
--
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] Drivers:input:mousedev.c: Fixed trailing statement on the next line

[Athira S]

Fixed checkpatch error:
trailing statements should be on next line

signed-off-by: Athira S 
---
 drivers/input/mousedev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index be2cc5c..28988f5 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -248,8 +248,8 @@ static void mousedev_key_event(struct mousedev *mousedev,
case BTN_4:
case BTN_EXTRA: index = 4; break;
 
-   default:
-   return;
+   default:
+   return;
}
 
if (value) {
-- 
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: [PATCH 4/7] KVM: arm64: guest debug, add SW break point support

[Christoffer Dall]

On Tue, Nov 25, 2014 at 04:10:02PM +, Alex Bennée wrote:
> This adds support for SW breakpoints inserted by userspace.
> 
> First we need to trap all BKPT exceptions in the hypervisor (ELS). This
> in controlled through the MDCR_EL2 register. I've added a new field to

this is ?

> the vcpu structure to hold this value. There should be scope to
> rationlise this with the VCPU_DEBUG_FLAGS/KVM_ARM64_DEBUG_DIRTY_SHIFT
> manipulation in later patches.

I don't understand what you mean with rationalising something in later
patches.

> 
> Once the exception arrives we triggers an exit from the main hypervisor
> loop to the hypervisor controller. The kvm_debug_exit_arch carries the

hypervisor controller is userspace?

> address of the exception. If the controller doesn't know of breakpoint

the breakint ?

> then we have a guest inserted breakpoint and the hypervisor needs to
> start again and deliver the exception to guest.

to the guest

> 
> Signed-off-by: Alex Bennée 
> 
> diff --git a/Documentation/virtual/kvm/api.txt 
> b/Documentation/virtual/kvm/api.txt
> index 2c6386e..9383359 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2592,7 +2592,7 @@ when running. Common control bits are:
>  The top 16 bits of the control field are architecture specific control
>  flags which can include the following:
>  
> -  - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86]
> +  - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
>- KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
>- KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
>- KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index a0ff410..48d26bb 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -303,6 +303,9 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>  int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>   struct kvm_guest_debug *dbg)
>  {
> + /* Route debug traps to el2? */
> + bool route_el2 = false;
> +
>   /* If it's not enabled clear all flags */
>   if (!(dbg->control & KVM_GUESTDBG_ENABLE)) {
>   vcpu->guest_debug = 0;
> @@ -320,8 +323,8 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu 
> *vcpu,
>  
>   /* Software Break Points */
>   if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP) {
> - kvm_info("SW BP support requested, not yet implemented\n");
> - return -EINVAL;
> + kvm_info("SW BP support requested\n");
> + route_el2 = true;
>   }
>  
>   /* Hardware assisted Break and Watch points */
> @@ -330,6 +333,20 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu 
> *vcpu,
>   return -EINVAL;
>   }
>  
> + /* If we are going to handle any debug exceptions we need to

wings on the comments

> +  * set MDCE_EL2.TDE to ensure they are routed to the
> +  * hypervisor. If userspace determines the exception was
> +  * actually internal to the guest it needs to handle
> +  * re-injecting the exception.
> +  */
> + if (route_el2) {
> + kvm_info("routing debug exceptions");
> + vcpu->arch.mdcr_el2 = MDCR_EL2_TDE;
> + } else {
> + kvm_info("not routing debug exceptions");
> + vcpu->arch.mdcr_el2 = 0;
> + }
> +
>   return 0;
>  }
>  
> diff --git a/arch/arm64/include/asm/kvm_host.h 
> b/arch/arm64/include/asm/kvm_host.h
> index 2012c4b..38b0f07 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -98,6 +98,7 @@ struct kvm_vcpu_arch {
>  
>   /* HYP configuration */
>   u64 hcr_el2;
> + u32 mdcr_el2;
>  
>   /* Exception Information */
>   struct kvm_vcpu_fault_info fault;
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 9a9fce0..8da1043 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -122,6 +122,7 @@ int main(void)
>DEFINE(VCPU_HPFAR_EL2, offsetof(struct kvm_vcpu, 
> arch.fault.hpfar_el2));
>DEFINE(VCPU_DEBUG_FLAGS,   offsetof(struct kvm_vcpu, arch.debug_flags));
>DEFINE(VCPU_HCR_EL2,   offsetof(struct kvm_vcpu, 
> arch.hcr_el2));
> +  DEFINE(VCPU_MDCR_EL2,  offsetof(struct kvm_vcpu, arch.mdcr_el2));
>DEFINE(VCPU_IRQ_LINES, offsetof(struct kvm_vcpu, arch.irq_lines));
>DEFINE(VCPU_HOST_CONTEXT,  offsetof(struct kvm_vcpu, 
> arch.host_cpu_context));
>DEFINE(VCPU_TIMER_CNTV_CTL,offsetof(struct kvm_vcpu, 
> arch.timer_cpu.cntv_ctl));
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 34b8bd0..28dc92b 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -71,6 +71,26 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct 
> kvm_run *run)
>   

Re: [PATCH] i8k: Add support for temperature sensor labels

[Guenter Roeck]

On 11/29/2014 08:04 AM, Pali Rohár wrote:

This patch adds labels for temperature sensors if SMM function with EAX register
0x11a3 reports it. These informations was taken from DOS binary NBSVC.MDM.

Signed-off-by: Pali Rohár 
---
  drivers/char/i8k.c |  110 +---
  1 file changed, 88 insertions(+), 22 deletions(-)

diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index e34a019..77af46b 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -42,6 +42,7 @@
  #define I8K_SMM_GET_FAN   0x00a3
  #define I8K_SMM_GET_SPEED 0x02a3
  #define I8K_SMM_GET_TEMP  0x10a3
+#define I8K_SMM_GET_TEMP_TYPE  0x11a3
  #define I8K_SMM_GET_DELL_SIG1 0xfea3
  #define I8K_SMM_GET_DELL_SIG2 0xffa3

@@ -288,6 +289,14 @@ static int i8k_set_fan(int fan, int speed)
return i8k_smm(®s) ? : i8k_get_fan_status(fan);
  }

+static int i8k_get_temp_type(int sensor)
+{
+   struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP_TYPE, };
+
+   regs.ebx = sensor & 0xff;
+   return i8k_smm(®s) ? : regs.eax & 0xff;
+}
+
  /*
   * Read the cpu temperature.
   */
@@ -493,6 +502,29 @@ static int i8k_open_fs(struct inode *inode, struct file 
*file)
   * Hwmon interface
   */

+static ssize_t i8k_hwmon_show_temp_label(struct device *dev,
+  struct device_attribute *devattr,
+  char *buf)
+{
+   static const char * const labels[] = {
+   "CPU",
+   "GPU",
+   "SODIMM",
+   "Other",
+   "Ambient",
+   "Other",
+   };
+   int index = to_sensor_dev_attr(devattr)->index;
+   int type;
+
+   type = i8k_get_temp_type(index);
+   if (type < 0)
+   return type;
+   if (type >= ARRAY_SIZE(labels))
+   type = ARRAY_SIZE(labels) - 1;
+   return sprintf(buf, "%s\n", labels[type]);
+}
+
  static ssize_t i8k_hwmon_show_temp(struct device *dev,
   struct device_attribute *devattr,
   char *buf)
@@ -555,9 +587,13 @@ static ssize_t i8k_hwmon_set_pwm(struct device *dev,
  }

  static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 0);
+static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, i8k_hwmon_show_temp_label, 
NULL, 0);
  static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp2_label, S_IRUGO, i8k_hwmon_show_temp_label, 
NULL, 1);
  static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp3_label, S_IRUGO, i8k_hwmon_show_temp_label, 
NULL, 2);
  static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 3);
+static SENSOR_DEVICE_ATTR(temp4_label, S_IRUGO, i8k_hwmon_show_temp_label, 
NULL, 3);
  static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, i8k_hwmon_show_fan, NULL,
  I8K_FAN_LEFT);
  static SENSOR_DEVICE_ATTR(pwm1, S_IRUGO | S_IWUSR, i8k_hwmon_show_pwm,
@@ -569,31 +605,35 @@ static SENSOR_DEVICE_ATTR(pwm2, S_IRUGO | S_IWUSR, 
i8k_hwmon_show_pwm,

  static struct attribute *i8k_attrs[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr, /* 0 */
-   &sensor_dev_attr_temp2_input.dev_attr.attr, /* 1 */
-   &sensor_dev_attr_temp3_input.dev_attr.attr, /* 2 */
-   &sensor_dev_attr_temp4_input.dev_attr.attr, /* 3 */
-   &sensor_dev_attr_fan1_input.dev_attr.attr,  /* 4 */
-   &sensor_dev_attr_pwm1.dev_attr.attr,/* 5 */
-   &sensor_dev_attr_fan2_input.dev_attr.attr,  /* 6 */
-   &sensor_dev_attr_pwm2.dev_attr.attr,/* 7 */
+   &sensor_dev_attr_temp1_label.dev_attr.attr, /* 1 */
+   &sensor_dev_attr_temp2_input.dev_attr.attr, /* 2 */
+   &sensor_dev_attr_temp2_label.dev_attr.attr, /* 3 */
+   &sensor_dev_attr_temp3_input.dev_attr.attr, /* 4 */
+   &sensor_dev_attr_temp3_label.dev_attr.attr, /* 5 */
+   &sensor_dev_attr_temp4_input.dev_attr.attr, /* 6 */
+   &sensor_dev_attr_temp4_label.dev_attr.attr, /* 7 */
+   &sensor_dev_attr_fan1_input.dev_attr.attr,  /* 8 */
+   &sensor_dev_attr_pwm1.dev_attr.attr,/* 9 */
+   &sensor_dev_attr_fan2_input.dev_attr.attr,  /* 10 */
+   &sensor_dev_attr_pwm2.dev_attr.attr,/* 11 */
NULL
  };

  static umode_t i8k_is_visible(struct kobject *kobj, struct attribute *attr,
  int index)
  {
-   if (index == 0 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP1))
+   if (index >= 0 && index <= 1 && !(i8k_hwmon_flags & 
I8K_HWMON_HAVE_TEMP1))
return 0;
-   if (index == 1 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP2))
+   if (index >= 2 && index <= 3 && !(i8k_hwmon_flags & 
I8K_HWMON_HAVE_TEMP2))
return 0;
-   if (index == 2 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP3))
+   if (index >= 4 && index <= 5 && !(i8k_hwmon_flags & 
I8K_HWM

Re: [PATCH] i8k: Add support for temperature sensor labels

[Guenter Roeck]

On 11/29/2014 08:09 AM, Pali Rohár wrote:

On Saturday 29 November 2014 17:04:07 Pali Rohár wrote:

This patch adds labels for temperature sensors if SMM function
with EAX register 0x11a3 reports it. These informations was
taken from DOS binary NBSVC.MDM.

Signed-off-by: Pali Rohár 
---
  drivers/char/i8k.c |  110
+--- 1 file
changed, 88 insertions(+), 22 deletions(-)


I tested patch on Latitude E6440 and i8k CPU & GPU temps match
intel coretemp & amd radeion temps.

But I would like if somebody with other Dell laptop can test if
temperature labels are correct...



I have a couple; I'll try to give it a test this weekend.

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: [RFC PATCH] userns: Disallow setgroups unless the gid_map writer is privileged

[Andy Lutomirski]

On Sat, Nov 29, 2014 at 8:16 AM, Eric W. Biederman
 wrote:
> Andy Lutomirski  writes:
>
> The patch is buggy.
>
> Nacked-by: "Eric W. Biederman" 
>
>> ---
>>
>> Eric, this is an alternative to your patch.  I think it will cause
>> less breakage, and it will keep unprivileged user namespaces
>> more or less fully functional.
>>
>> Kenton, I think that neither run-bundle nor supervisor-main will be
>> broken by this patch.
>>
>>  include/linux/user_namespace.h |  3 +++
>>  kernel/groups.c|  3 +++
>>  kernel/user.c  |  1 +
>>  kernel/user_namespace.c| 36 
>>  4 files changed, 43 insertions(+)
>>
>> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
>> index e95372654f09..a74c1f3d44fe 100644
>> --- a/include/linux/user_namespace.h
>> +++ b/include/linux/user_namespace.h
>> @@ -17,6 +17,8 @@ struct uid_gid_map {/* 64 bytes -- 1 cache line */
>>   } extent[UID_GID_MAP_MAX_EXTENTS];
>>  };
>>
>> +#define USERNS_SETGROUPS_ALLOWED 1
>> +
>>  struct user_namespace {
>>   struct uid_gid_map  uid_map;
>>   struct uid_gid_map  gid_map;
>> @@ -27,6 +29,7 @@ struct user_namespace {
>>   kuid_t  owner;
>>   kgid_t  group;
>>   unsigned intproc_inum;
>> + unsigned intflags;
>
> If you are going to add a flags field it needs to be atomic as otherwise
> changing or reading individual flags won't be safe without a lock.

Will fix.

>
>>   /* Register of per-UID persistent keyrings for this namespace */
>>  #ifdef CONFIG_PERSISTENT_KEYRINGS
>> diff --git a/kernel/groups.c b/kernel/groups.c
>> index 451698f86cfa..e27433809978 100644
>> --- a/kernel/groups.c
>> +++ b/kernel/groups.c
>> @@ -6,6 +6,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  /* init to 2 - one for init_task, one to ensure it is never freed */
>> @@ -223,6 +224,8 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user 
>> *, grouplist)
>>   struct group_info *group_info;
>>   int retval;
>>
>> + if (!(current_user_ns()->flags & USERNS_SETGROUPS_ALLOWED))
>> + return -EPERM;
>>   if (!ns_capable(current_user_ns(), CAP_SETGID))
>>   return -EPERM;
>>   if ((unsigned)gidsetsize > NGROUPS_MAX)
>> diff --git a/kernel/user.c b/kernel/user.c
>> index 4efa39350e44..f8cdb1ec6049 100644
>> --- a/kernel/user.c
>> +++ b/kernel/user.c
>> @@ -51,6 +51,7 @@ struct user_namespace init_user_ns = {
>>   .owner = GLOBAL_ROOT_UID,
>>   .group = GLOBAL_ROOT_GID,
>>   .proc_inum = PROC_USER_INIT_INO,
>> + .flags = USERNS_SETGROUPS_ALLOWED,
>>  #ifdef CONFIG_PERSISTENT_KEYRINGS
>>   .persistent_keyring_register_sem =
>>   __RWSEM_INITIALIZER(init_user_ns.persistent_keyring_register_sem),
>> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
>> index aa312b0dc3ec..6e7b9ee5bddc 100644
>> --- a/kernel/user_namespace.c
>> +++ b/kernel/user_namespace.c
>> @@ -600,6 +600,8 @@ static ssize_t map_write(struct file *file, const char 
>> __user *buf,
>>   unsigned long page = 0;
>>   char *kbuf, *pos, *next_line;
>>   ssize_t ret = -EINVAL;
>> + unsigned int gid_flags = 0;
>> + bool seen_explicit_gid_flag = false;
>>
>>   /*
>>* The id_map_mutex serializes all writes to any given map.
>> @@ -633,6 +635,19 @@ static ssize_t map_write(struct file *file, const char 
>> __user *buf,
>>   if (cap_valid(cap_setid) && !file_ns_capable(file, ns, CAP_SYS_ADMIN))
>>   goto out;
>>
>> + /* Deal with supplementary groups. */
>> + if (map == &ns->gid_map) {
>> + /*
>> +  * By default, setgroups is allowed inside the userns
>> +  * if the writer has no supplementary groups (making
>> +  * it useless) or if the writer is privileged.
>> +  */
>> + if ((ns->parent->flags & USERNS_SETGROUPS_ALLOWED) &&
>> + file_ns_capable(file, ns->parent, CAP_SETGID) &&
>> + ns_capable(ns->parent, CAP_SETGID))
>> + gid_flags = USERNS_SETGROUPS_ALLOWED;
>
> We can't do this.
>
> It is wrong to mix permissions and flags to request functionality.
>
> That way lies madness, and impossible maintenance, and it will silently
> break every application that expects setgroups to work if they have
> CAP_SETGID after a mapping has been established.

We can make writing gid_map fail unless you either have permissions or
add the "setgroups disallow" option.  Would that be better?  It avoids
silent creation of a strangely behaving userns.  This would be an easy
adjustment to this patch.

I don't like the "allow setgroups if there are no supplementary
groups" because it's weird and unexpected (and will therefore break
things, I expect) and because it may interact insecurely with setns
and other such things.

--Andy

>
>> + }
>> +
>>   /* G

Re: [PATCH] i8k: Add support for temperature sensor labels

[Pali Rohár]

On Saturday 29 November 2014 17:24:08 Guenter Roeck wrote:
> On 11/29/2014 08:04 AM, Pali Rohár wrote:
> > +static bool __init i8k_check_temp(int sensor)
> > +{
> > +   int err;
> > +
> > +   /*
> > +* Check if temperature sensor type is valid.
> > +*
> > +* If it is valid then sensor should work. But some
> > sensors are not +* available at any time. E.g GPU sensor
> > on Optimus/PowerExpress/Enduro + * card does not work (or
> > return bogus value) when card is turned off. +   * So this
> > function should not fail in this case. + */
> > +   err = i8k_get_temp_type(sensor);
> > +   if (err >= 0)
> > +   return true;
> > +
> 
> Are you sure this function is provided for all systems ?
> I am a bit concerned that we may wrongly disable sensors this
> way, especially on older systems.
> 

I do not know if that function is provided on all systems. But 
this code does not disable sensors. If function fail, then we 
fallback to temperature read down. Return true means that we 
enable sensor.

> It might be safer to create another set of flags and enable
> the labels only if the sensor is known to exist and if
> reading its type (label) works.
> 
> > +   /*
> > +* Check if temperatrue reading does not fail.
> > +*
> 
> temperature
> 
> > +* Sometimes detection of temperature sensor type does not
> > work but +   * reading temperature working fine. Sometimes
> > temperature value is too +   * high and i8k_get_temp()
> > returns -ERANGE. But there is no reason to + * ignore
> > these temperature sensors.
> > +*/
> > +   err = i8k_get_temp(sensor);
> > +   if (err >= 0 || err == -ERANGE)
> > +   return true;
> > +
> 
> Please simplify to
>   return err >= 0 || err == -ERANGE;
> 

I'm using style:

check_function_1();
if (not_failed)
return true;

check_function_2();
if (not_failed)
return true;

return false; // disable sensor

So I think it is better to have same style for both checks...

> > +   return false;
> > +}
> > +
> > 
> >   static int __init i8k_init_hwmon(void)
> >   {
> >   
> > int err;
> > 
> > @@ -613,18 +684,13 @@ static int __init i8k_init_hwmon(void)
> > 
> > i8k_hwmon_flags = 0;
> > 
> > /* CPU temperature attributes, if temperature reading is
> > OK */
> > 
> > -   err = i8k_get_temp(0);
> > -   if (err >= 0 || err == -ERANGE)
> > +   if (i8k_check_temp(0))
> 
> The introduction of i8k_check_temp() should be a separate
> patch.
> 
> Thanks,
> Guenter
> 

Ok.

> > i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP1;
> > 
> > -   /* check for additional temperature sensors */
> > -   err = i8k_get_temp(1);
> > -   if (err >= 0 || err == -ERANGE)
> > +   if (i8k_check_temp(1))
> > 
> > i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP2;
> > 
> > -   err = i8k_get_temp(2);
> > -   if (err >= 0 || err == -ERANGE)
> > +   if (i8k_check_temp(2))
> > 
> > i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP3;
> > 
> > -   err = i8k_get_temp(3);
> > -   if (err >= 0 || err == -ERANGE)
> > +   if (i8k_check_temp(3))
> > 
> > i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP4;
> > 
> > /* Left fan attributes, if left fan is present */

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

iwlwifi intel 6300 slow

[Jurriaan]

I had a Lenovo W700 laptop with Intel 5300 wireless card, running Debian
Testing. Speed to and from my NAS via a Western Digital N900 router was
about 16 megabyte/s - limited by the NAS.

After updating to a W701 with an Intel 6300 wireless card, speed is down
to 1-2 megabyte/s. Replacing the card is not really an option, Lenovo
has blessed this model with a whitelist in the BIOS.

I tried booting 3.18-rc6, but that made no difference against 3.16.

There's a lot of complaints about this card on the net, but it seems
most are about poor performance when roaming or with a weak signal. 
I've tries the various 11n_disable=x swcrypto=x options, I've tried
fiddling with the router (20/40 MHz, N only or mixed etc) but so far,
the speed remains abysmal.

1)
Can anybody tell me what logs/debugging I can post to help clear up this
issue?

2)
If anybody has this card running great with another router, I'd be very
interested to learn which one!

Thanks,
Jurriaan

wlan0 IEEE 802.11abgn  ESSID:"onderneming10_5"
  Mode:Managed  Frequency:5.2 GHz  Access Point: 00:90:A9:0E:D5:58
  Bit Rate=270 Mb/s   Tx-Power=15 dBm
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:off
  Link Quality=52/70  Signal level=-58 dBm
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:101   Missed beacon:0

i03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
Subsystem: Intel Corporation Centrino Ultimate-N 6300 3x3 AGN
Flags: bus master, fast devsel, latency 0, IRQ 56
Memory at f600 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-24-d7-ff-ff-61-65-8c
Kernel driver in use: iwlwifi

iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG disabled
iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, 
REV=0x74
iwlwifi :03:00.0: L1 Enabled; Disabling L0S
--
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] i8k: Add support for temperature sensor labels

[Pali Rohár]

On Saturday 29 November 2014 17:24:56 Guenter Roeck wrote:
> On 11/29/2014 08:09 AM, Pali Rohár wrote:
> > On Saturday 29 November 2014 17:04:07 Pali Rohár wrote:
> >> This patch adds labels for temperature sensors if SMM
> >> function with EAX register 0x11a3 reports it. These
> >> informations was taken from DOS binary NBSVC.MDM.
> >> 
> >> Signed-off-by: Pali Rohár 
> >> ---
> >> 
> >>   drivers/char/i8k.c |  110
> >> 
> >> +--- 1 file
> >> changed, 88 insertions(+), 22 deletions(-)
> > 
> > I tested patch on Latitude E6440 and i8k CPU & GPU temps
> > match intel coretemp & amd radeion temps.
> > 
> > But I would like if somebody with other Dell laptop can test
> > if temperature labels are correct...
> 
> I have a couple; I'll try to give it a test this weekend.
> 
> Guenter

Ok, thanks! Can you include also this patch when you will do testing?

https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-testing&id=723493ca59c8d81fed3e7f261165fee493a29ffa

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] i8k: Add support for temperature sensor labels

[Steven Honeyman]

On 29 November 2014 at 16:09, Pali Rohár  wrote:
> On Saturday 29 November 2014 17:04:07 Pali Rohár wrote:
>> This patch adds labels for temperature sensors if SMM function
>> with EAX register 0x11a3 reports it. These informations was
>> taken from DOS binary NBSVC.MDM.
>>
>> Signed-off-by: Pali Rohár 
>> ---
>>  drivers/char/i8k.c |  110
>> +--- 1 file
>> changed, 88 insertions(+), 22 deletions(-)
>
> I tested patch on Latitude E6440 and i8k CPU & GPU temps match
> intel coretemp & amd radeion temps.
>
> But I would like if somebody with other Dell laptop can test if
> temperature labels are correct...

Tested and working on E6540:
(I manually masked the serial/service tag)

-Before-

*[steven@e6540 linux]$ cat /proc/i8k
1.0 A12 6xx 44 -22 1 -22 3223 -1 -22
*[steven@e6540 linux]$ sensors
i8k-virtual-0
Adapter: Virtual device
fan2:3223 RPM
temp1:+46.0°C
temp2:+44.0°C
temp3:+38.0°C

coretemp-isa-
Adapter: ISA adapter
Physical id 0:  +49.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0: +45.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1: +49.0°C  (high = +84.0°C, crit = +100.0°C)

-After-

*[steven@e6540 ~]$ cat /proc/i8k
1.0 A12 6xx 47 -22 1 -22 3176 -1 -22
*[steven@e6540 ~]$ sensors
i8k-virtual-0
Adapter: Virtual device
fan2:3176 RPM
CPU:  +47.0°C
Ambient:  +45.0°C
SODIMM:   +38.0°C

coretemp-isa-
Adapter: ISA adapter
Physical id 0:  +47.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0: +45.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1: +46.0°C  (high = +84.0°C, crit = +100.0°C)
--
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/RFC v8 04/14] v4l2-async: change custom.match callback argument type

[Laurent Pinchart]

Hi Jacek,

Thank you for the patch.

On Friday 28 November 2014 10:17:56 Jacek Anaszewski wrote:
> It is useful to have an access to the async sub-device
> being matched, not only to the related struct device.
> Change match callback argument from struct device
> to struct v4l2_subdev. It will allow e.g. for matching
> a sub-device by its "name" property.

In principle I agree. However, we will need to reimplement v4l2-async based on 
the component (drivers/base/component.c) framework at some point. As the 
component framework is based on struct device, will it still be possible to 
match on subdev name in that case ? If not, we might need to try to find 
another approach to the issue.

> Signed-off-by: Jacek Anaszewski 
> Acked-by: Kyungmin Park 
> Cc: Guennadi Liakhovetski 
> Cc: Laurent Pinchart 
> Cc: Hans Verkuil 
> ---
>  drivers/media/v4l2-core/v4l2-async.c |   16 
>  include/media/v4l2-async.h   |2 +-
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c
> b/drivers/media/v4l2-core/v4l2-async.c index 85a6a34..8140992 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -22,10 +22,10 @@
>  #include 
>  #include 
> 
> -static bool match_i2c(struct device *dev, struct v4l2_async_subdev *asd)
> +static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev
> *asd) {
>  #if IS_ENABLED(CONFIG_I2C)
> - struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_client *client = i2c_verify_client(sd->dev);
>   return client &&
>   asd->match.i2c.adapter_id == client->adapter->nr &&
>   asd->match.i2c.address == client->addr;
> @@ -34,14 +34,14 @@ static bool match_i2c(struct device *dev, struct
> v4l2_async_subdev *asd) #endif
>  }
> 
> -static bool match_devname(struct device *dev, struct v4l2_async_subdev
> *asd) +static bool match_devname(struct v4l2_subdev *sd, struct
> v4l2_async_subdev *asd) {
> - return !strcmp(asd->match.device_name.name, dev_name(dev));
> + return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
>  }
> 
> -static bool match_of(struct device *dev, struct v4l2_async_subdev *asd)
> +static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> {
> - return dev->of_node == asd->match.of.node;
> + return sd->dev->of_node == asd->match.of.node;
>  }
> 
>  static LIST_HEAD(subdev_list);
> @@ -52,7 +52,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
> v4l2_async_notifier * struct v4l2_subdev *sd)
>  {
>   struct v4l2_async_subdev *asd;
> - bool (*match)(struct device *, struct v4l2_async_subdev *);
> + bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
> 
>   list_for_each_entry(asd, ¬ifier->waiting, list) {
>   /* bus_type has been verified valid before */
> @@ -79,7 +79,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
> v4l2_async_notifier * }
> 
>   /* match cannot be NULL here */
> - if (match(sd->dev, asd))
> + if (match(sd, asd))
>   return asd;
>   }
> 
> diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
> index 7683569..1c0b586 100644
> --- a/include/media/v4l2-async.h
> +++ b/include/media/v4l2-async.h
> @@ -51,7 +51,7 @@ struct v4l2_async_subdev {
>   unsigned short address;
>   } i2c;
>   struct {
> - bool (*match)(struct device *,
> + bool (*match)(struct v4l2_subdev *,
> struct v4l2_async_subdev *);
>   void *priv;
>   } custom;

-- 
Regards,

Laurent Pinchart

--
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] XFS: Deletion of unnecessary checks before two function calls

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 17:40:22 +0100

The functions xfs_blkdev_put() and xfs_qm_dqrele() test whether their argument
is NULL and then return 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/xfs/xfs_qm.c| 12 +---
 fs/xfs/xfs_super.c |  3 +--
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c
index d68f230..9a4b50a 100644
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -1749,23 +1749,21 @@ xfs_qm_vop_dqalloc(
xfs_iunlock(ip, lockflags);
if (O_udqpp)
*O_udqpp = uq;
-   else if (uq)
+   else
xfs_qm_dqrele(uq);
if (O_gdqpp)
*O_gdqpp = gq;
-   else if (gq)
+   else
xfs_qm_dqrele(gq);
if (O_pdqpp)
*O_pdqpp = pq;
-   else if (pq)
+   else
xfs_qm_dqrele(pq);
return 0;
 
 error_rele:
-   if (gq)
-   xfs_qm_dqrele(gq);
-   if (uq)
-   xfs_qm_dqrele(uq);
+   xfs_qm_dqrele(gq);
+   xfs_qm_dqrele(uq);
return error;
 }
 
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 206b97f..97eaa25 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -796,8 +796,7 @@ xfs_open_devices(
  out_free_ddev_targ:
xfs_free_buftarg(mp, mp->m_ddev_targp);
  out_close_rtdev:
-   if (rtdev)
-   xfs_blkdev_put(rtdev);
+   xfs_blkdev_put(rtdev);
  out_close_logdev:
if (logdev && logdev != ddev)
xfs_blkdev_put(logdev);
-- 
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: [GIT PULL] namespace updates for v3.17-rc1

[Richard Weinberger]

Am 26.11.2014 um 00:15 schrieb Richard Weinberger:
> Eric,
> 
> On Thu, Aug 21, 2014 at 4:09 PM, Eric W. Biederman
>  wrote:
>> Richard Weinberger  writes:
>>
>>> Am 21.08.2014 15:12, schrieb Christoph Hellwig:
 On Wed, Aug 20, 2014 at 09:53:49PM -0700, Eric W. Biederman wrote:
> Richard Weinberger  writes:
>
>> On Wed, Aug 6, 2014 at 2:57 AM, Eric W. Biederman 
>>  wrote:
>>
>> This commit breaks libvirt-lxc.
>> libvirt does in lxcContainerMountBasicFS():
>
> The bugs fixed are security issues, so if we have to break a small
> number of userspace applications we will.  Anything that we can
> reasonably do to avoid regressions will be done.

 Can you explain the security issues in detail?  Breaking common
 userspace like libvirt-lxc with just a little bit of handwaiving is
 entirely unacceptable.
>>>
>>> It looks like commit 87b47932f40a11280584bce260cbdb3b5f9e8b7d in
>>> git.kernel.org/cgit/linux/kernel/git/ebiederm/user-namespace.git for-next
>>> unbreaks libvirt-lxc.
>>> I hope it hits Linus tree and -stable before the offending commit hits 
>>> users.
>>
>> I plan to send the pull request to Linus as soon as I have caught my
>> breath (from all of the conferences this week) that I can be certain I
>> am thinking clearly and not rushing things.
> 
> Today I've upgraded my LXC testbed to the most recent kernel and found
> libvirt-lxc broken again (sic!).
> Remounting /proc/sys/ is failing.
> Investigating into the issue showed that commit "mnt: Implicitly add
> MNT_NODEV on remount as we do on mount"
> is not mainline.
> Why did you left out this patch? In my previous mails I explicitly
> stated that exactly this commit unbreaks libvirt-lxc.
> 
> Now the userspace breaking changes are mainline and hit users hard. :-(

*kind ping*
...to make sure that this issue doesn't get lost.

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/

[PATCH 1/1] fs-DLM: Deletion of unnecessary checks before the function call "kfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 17:55:39 +0100

The kfree() 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/dlm/lockspace.c | 3 +--
 fs/dlm/memory.c| 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/dlm/lockspace.c b/fs/dlm/lockspace.c
index f3e7278..b660b93 100644
--- a/fs/dlm/lockspace.c
+++ b/fs/dlm/lockspace.c
@@ -674,8 +674,7 @@ static int new_lockspace(const char *name, const char 
*cluster,
  out_lkbidr:
idr_destroy(&ls->ls_lkbidr);
for (i = 0; i < DLM_REMOVE_NAMES_MAX; i++) {
-   if (ls->ls_remove_names[i])
-   kfree(ls->ls_remove_names[i]);
+   kfree(ls->ls_remove_names[i]);
}
  out_rsbtbl:
vfree(ls->ls_rsbtbl);
diff --git a/fs/dlm/memory.c b/fs/dlm/memory.c
index 7cd24bc..2d2eaa0 100644
--- a/fs/dlm/memory.c
+++ b/fs/dlm/memory.c
@@ -86,8 +86,7 @@ void dlm_free_lkb(struct dlm_lkb *lkb)
struct dlm_user_args *ua;
ua = lkb->lkb_ua;
if (ua) {
-   if (ua->lksb.sb_lvbptr)
-   kfree(ua->lksb.sb_lvbptr);
+   kfree(ua->lksb.sb_lvbptr);
kfree(ua);
}
}
-- 
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] i8k: Add support for temperature sensor labels

[Gabriele Mazzotta]

On Saturday 29 November 2014 17:09:35 Pali Rohár wrote:
> On Saturday 29 November 2014 17:04:07 Pali Rohár wrote:
> > This patch adds labels for temperature sensors if SMM function
> > with EAX register 0x11a3 reports it. These informations was
> > taken from DOS binary NBSVC.MDM.
> > 
> > Signed-off-by: Pali Rohár 
> > ---
> > 
> >  drivers/char/i8k.c |  110
> > 
> > +--- 1 file
> > changed, 88 insertions(+), 22 deletions(-)
> 
> I tested patch on Latitude E6440 and i8k CPU & GPU temps match
> intel coretemp & amd radeion temps.
> 
> But I would like if somebody with other Dell laptop can test if
> temperature labels are correct...

I tested it on my XPS13 9333, here what sensors outputs:

acpitz-virtual-0
Adapter: Virtual device
temp1:+27.8°C  (crit = +105.0°C)
temp2:+29.8°C  (crit = +105.0°C)

coretemp-isa-
Adapter: ISA adapter
Physical id 0:  +62.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0: +62.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1: +61.0°C  (high = +100.0°C, crit = +100.0°C)

i8k-virtual-0
Adapter: Virtual device
fan2:   0 RPM
CPU:  +62.0°C  
Ambient:  +49.0°C  
SODIMM:   +46.0°C  
temp4:N/A

CPU seems to be correct, but I can't say anything on Ambient and SODIMM.
temp4 is constantly equal to SODIMM without this patch, so I'd say N/A
is correct.


Gabriele
--
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] i8k: Add support for temperature sensor labels

[Pali Rohár]

On Saturday 29 November 2014 18:07:19 Gabriele Mazzotta wrote:
> On Saturday 29 November 2014 17:09:35 Pali Rohár wrote:
> > On Saturday 29 November 2014 17:04:07 Pali Rohár wrote:
> > > This patch adds labels for temperature sensors if SMM
> > > function with EAX register 0x11a3 reports it. These
> > > informations was taken from DOS binary NBSVC.MDM.
> > > 
> > > Signed-off-by: Pali Rohár 
> > > ---
> > > 
> > >  drivers/char/i8k.c |  110
> > > 
> > > +--- 1
> > > file changed, 88 insertions(+), 22 deletions(-)
> > 
> > I tested patch on Latitude E6440 and i8k CPU & GPU temps
> > match intel coretemp & amd radeion temps.
> > 
> > But I would like if somebody with other Dell laptop can test
> > if temperature labels are correct...
> 
> I tested it on my XPS13 9333, here what sensors outputs:
> 
> acpitz-virtual-0
> Adapter: Virtual device
> temp1:+27.8°C  (crit = +105.0°C)
> temp2:+29.8°C  (crit = +105.0°C)
> 
> coretemp-isa-
> Adapter: ISA adapter
> Physical id 0:  +62.0°C  (high = +100.0°C, crit = +100.0°C)
> Core 0: +62.0°C  (high = +100.0°C, crit = +100.0°C)
> Core 1: +61.0°C  (high = +100.0°C, crit = +100.0°C)
> 
> i8k-virtual-0
> Adapter: Virtual device
> fan2:   0 RPM
> CPU:  +62.0°C
> Ambient:  +49.0°C
> SODIMM:   +46.0°C
> temp4:N/A
> 
> CPU seems to be correct, but I can't say anything on Ambient
> and SODIMM. temp4 is constantly equal to SODIMM without this
> patch, so I'd say N/A is correct.
> 
> 
> Gabriele

It is unknown for me how to directly read Ambient and SODIMM
temperatures (without Dell SMM functions). So we can only trust
Dell SMM that it reporting correct values and type is really
Ambient and SODIMM.

And about temp4:

Label is not set when SMM function fails. Original DOS NBSVC.MDM
just ignore all sensors for which SMM type function fails.

This patch should not disable any sensor, so if you previously
had some value (<= 128°C) and now not, then there is some bug.

Can you test this patch?
https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-testing&id=723493ca59c8d81fed3e7f261165fee493a29ffa

It is possible that same value is caused by incorrect use of
prev[] array which should be fixed by above patch.

Can you test i8k with and without above patch?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v6 37/46] tun: move internal flag defines out of uapi

[Michael S. Tsirkin]

On Fri, Nov 28, 2014 at 08:15:32AM +0008, Jason Wang wrote:
> 
> 
> On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin  wrote:
> >TUN_ flags are internal and never exposed
> >to userspace. Any application using it is almost
> >certainly buggy.
> >
> >Move them out to tun.c, we'll remove them in follow-up patches.
> >
> >Signed-off-by: Michael S. Tsirkin 
> >---
> > include/uapi/linux/if_tun.h | 16 ++
> > drivers/net/tun.c   | 74
> >++---
> > 2 files changed, 26 insertions(+), 64 deletions(-)
> >
> >diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> >index e9502dd..277a260 100644
> >--- a/include/uapi/linux/if_tun.h
> >+++ b/include/uapi/linux/if_tun.h
> >@@ -22,21 +22,11 @@
> > /* Read queue size */
> > #define TUN_READQ_SIZE  500
> >-
> >-/* TUN device flags */
> >-#define TUN_TUN_DEV 0x0001  
> >-#define TUN_TAP_DEV 0x0002
> >+/* TUN device type flags: deprecated. Use IFF_TUN/IFF_TAP instead. */
> >+#define TUN_TUN_DEV IFF_TUN
> >+#define TUN_TAP_DEV IFF_TAP
> > #define TUN_TYPE_MASK   0x000f
> >-#define TUN_FASYNC  0x0010
> >-#define TUN_NOCHECKSUM  0x0020
> >-#define TUN_NO_PI   0x0040
> >-/* This flag has no real effect */
> >-#define TUN_ONE_QUEUE   0x0080
> >-#define TUN_PERSIST 0x0100  
> >-#define TUN_VNET_HDR0x0200
> >-#define TUN_TAP_MQ  0x0400
> >-
> > /* Ioctl defines */
> > #define TUNSETNOCSUM  _IOW('T', 200, int)  #define TUNSETDEBUG
> >_IOW('T', 201, int) diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >index 9dd3746..bc89d07 100644
> >--- a/drivers/net/tun.c
> >+++ b/drivers/net/tun.c
> >@@ -103,6 +103,21 @@ do {
> >\
> > } while (0)
> > #endif
> >+/* TUN device flags */
> >+
> >+/* IFF_ATTACH_QUEUE is never stored in device flags,
> >+ * overload it to mean fasync when stored there.
> >+ */
> >+#define TUN_FASYNC  IFF_ATTACH_QUEUE
> >+#define TUN_NO_PI   IFF_NO_PI
> >+/* This flag has no real effect */
> >+#define TUN_ONE_QUEUE   IFF_ONE_QUEUE
> >+#define TUN_PERSIST IFF_PERSIST
> >+#define TUN_VNET_HDRIFF_VNET_HDR
> >+#define TUN_TAP_MQ  IFF_MULTI_QUEUE
> >+
> >+#define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
> >+  IFF_MULTI_QUEUE)
> > #define GOODCOPY_LEN 128
> > #define FLT_EXACT_COUNT 8
> >@@ -1521,32 +1536,7 @@ static struct proto tun_proto = {
> > static int tun_flags(struct tun_struct *tun)
> > {
> >-int flags = 0;
> >-
> >-if (tun->flags & TUN_TUN_DEV)
> >-flags |= IFF_TUN;
> >-else
> >-flags |= IFF_TAP;
> >-
> >-if (tun->flags & TUN_NO_PI)
> >-flags |= IFF_NO_PI;
> >-
> >-/* This flag has no real effect.  We track the value for backwards
> >- * compatibility.
> >- */
> >-if (tun->flags & TUN_ONE_QUEUE)
> >-flags |= IFF_ONE_QUEUE;
> >-
> >-if (tun->flags & TUN_VNET_HDR)
> >-flags |= IFF_VNET_HDR;
> >-
> >-if (tun->flags & TUN_TAP_MQ)
> >-flags |= IFF_MULTI_QUEUE;
> >-
> >-if (tun->flags & TUN_PERSIST)
> >-flags |= IFF_PERSIST;
> >-
> >-return flags;
> >+return tun->flags & (TUN_FEATURES | IFF_PERSIST | IFF_TUN | IFF_TAP);
> > }
> >   static ssize_t tun_show_flags(struct device *dev, struct
> >device_attribute *attr,
> >@@ -1706,28 +1696,8 @@ static int tun_set_iff(struct net *net, struct file
> >*file, struct ifreq *ifr)
> > tun_debug(KERN_INFO, tun, "tun_set_iff\n");
> >-if (ifr->ifr_flags & IFF_NO_PI)
> >-tun->flags |= TUN_NO_PI;
> >-else
> >-tun->flags &= ~TUN_NO_PI;
> >-
> >-/* This flag has no real effect.  We track the value for backwards
> >- * compatibility.
> >- */
> >-if (ifr->ifr_flags & IFF_ONE_QUEUE)
> >-tun->flags |= TUN_ONE_QUEUE;
> >-else
> >-tun->flags &= ~TUN_ONE_QUEUE;
> >-
> >-if (ifr->ifr_flags & IFF_VNET_HDR)
> >-tun->flags |= TUN_VNET_HDR;
> >-else
> >-tun->flags &= ~TUN_VNET_HDR;
> >-
> >-if (ifr->ifr_flags & IFF_MULTI_QUEUE)
> >-tun->flags |= TUN_TAP_MQ;
> >-else
> >-tun->flags &= ~TUN_TAP_MQ;
> >+tun->flags = (tun->flags & ~TUN_FEATURES) |
> >+(ifr->ifr_flags & TUN_FEATURES);
> > /* Make sure persistent devices do not get stuck in
> >  * xoff state.
> >@@ -1890,9 +1860,11 @@ static long __tun_chr_ioctl(struct file *file,
> >unsigned int cmd,
> > if (cmd == TUNGETFEATURES) {
> > /* Currently this just means: "what IFF flags are valid?".
> >  * This is needed because we never checked for invalid flags on
> >- * TUNSETIFF. */
> >-return put_user(IFF_TUN | IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE |
> >-IFF_VNET_HDR | IFF_MULTI_QUEUE,
> >+ * TUNSETIFF.  Why do we report IFF_TUN and IFF_TAP which are
> >+ * not legal f

Disable input device

[Pali Rohár]

Hello,

there is request to introduce some option (via sysfs) to disable 
one input device. Originally it was for tsc2005 touchscreen found 
on Nokia N900 cellphone. Use case is to completely disable 
touchscreen when phone is in pocket or when screen is locked via 
slide switch (to prevent random clicks).

But it would be better to have disable option for all input 
devices. Sometimes input device is not use and only consume 
power. Another case is when input device (e.g. keyboard or 
touchpad) is integrated into machine (e.g. on laptops) and user 
does not want to use it (so make sure that kernel does not send 
events to userspace).

I would like to ask, how to solve it?

What do you think about adding new sysfs file "disable" (accept 
values 1 or 0) for every input device? With "1" it cause that 
kernel will drop all events from specific input device and if 
driver provide some function is can be called (e.g. for power 
management or disabling device at hardware level).

Or do you prefer something other?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v6 38/46] tun: drop most type defines

[Michael S. Tsirkin]

On Fri, Nov 28, 2014 at 08:17:48AM +0008, Jason Wang wrote:
> 
> 
> On Fri, Nov 28, 2014 at 4:11 AM, Michael S. Tsirkin  wrote:
> >It's just as easy to use IFF_ flags directly,
> >there's no point in adding our own defines.
> >
> >Signed-off-by: Michael S. Tsirkin 
> >---
> > drivers/net/tun.c | 62
> >+--
> > 1 file changed, 28 insertions(+), 34 deletions(-)
> >
> >diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> 
> Patch looks fine, but I don't see the reason that why not squash patch 37
> into this.
> 
> [..]

squashing is always easy, I thought review is easier if at each step
identity to original code can be verified directly.
--
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] userns: Disallow setgroups unless the gid_map writer is privileged

[Andy Lutomirski]

Classic unix permission checks have an interesting feature.  The
group permissions for a file can be set to less than the other
permissions on a file.  Occasionally this is used deliberately to
give a certain group of users fewer permissions than the default.

User namespaces break this usage.  Groups set in rgid or egid are
unaffected because an unprivileged user namespace creator can only
map a single group, so setresgid inside and outside the namespace
have the same effect.  However, an unprivileged user namespace
creator can currently use setgroups(2) to drop all supplementary
groups, so, if a supplementary group denies access to some resource,
user namespaces can be used to bypass that restriction.

To fix this issue, this introduces a new user namespace flag
USERNS_SETGROUPS_ALLOWED.  If that flag is not set, then
setgroups(2) will fail regardless of the caller's capabilities.

USERNS_SETGROUPS_ALLOWED is cleared in a new user namespace.  By
default, if the writer of gid_map has CAP_SETGID in the parent
userns and the parent userns has USERNS_SETGROUPS_ALLOWED, then the
USERNS_SETGROUPS_ALLOWED will be set in the child.  If the writer is
not so privileged, then writing to gid_map will fail unless the
writer adds "setgroups deny" to gid_map, in which case the check is
skipped but USERNS_SETGROUPS_ALLOWED will remain cleared.

The full semantics are:

If "setgroups allow" is present or no explicit "setgroups" setting
is written to gid_map, then writing to gid_map will fail with -EPERM
unless the opener and writer have CAP_SETGID in the parent namespace
and the parent namespace has USERNS_SETGROUPS_ALLOWED.

If "setgroups deny" is present, then writing gid_map will work as
before, but USERNS_SETGROUPS_ALLOWED will remain cleared.  This will
result in processes in the userns that have CAP_SETGID to be
nontheless unable to use setgroups(2).  If this breaks something
inside the userns, then this is okay -- the userns creator
specifically requested this behavior.

While it could be safe to set USERNS_SETGROUPS_ALLOWED if the user
namespace creator has no supplementary groups, doing so could be
surprising and could have unpleasant interactions with setns(2).

Any application that uses newgidmap(1) should be unaffected by this
fix, but unprivileged users that create user namespaces to
manipulate mounts or sandbox themselves will break until they start
using "setgroups deny".

This should fix CVE-2014-8989.

Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski 
---

Unlike v1, this *will* break things like Sandstorm.  Fixing them will be
easy.  I agree that this will result in better long-term semantics, but
I'm not so happy about breaking working software.

If this is unpalatable, here's a different option: get rid of all these
permission checks and just change setgroups.  Specifically, make it so
that setgroups(2) in a userns will succeed but will silently refuse to
remove unmapped groups.

Changes from v1:
 - Userns flags are now properly atomic.
 - "setgroups allow" is now the default, so legacy unprivileged gid_map
   writers will start to fail.

 include/linux/user_namespace.h |  3 +++
 kernel/groups.c|  3 +++
 kernel/user.c  |  1 +
 kernel/user_namespace.c| 42 ++
 4 files changed, 49 insertions(+)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index e95372654f09..0ae4a8c97165 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -17,6 +17,8 @@ struct uid_gid_map {  /* 64 bytes -- 1 cache line */
} extent[UID_GID_MAP_MAX_EXTENTS];
 };
 
+#define USERNS_SETGROUPS_ALLOWED 0
+
 struct user_namespace {
struct uid_gid_map  uid_map;
struct uid_gid_map  gid_map;
@@ -27,6 +29,7 @@ struct user_namespace {
kuid_t  owner;
kgid_t  group;
unsigned intproc_inum;
+   unsigned long   flags;
 
/* Register of per-UID persistent keyrings for this namespace */
 #ifdef CONFIG_PERSISTENT_KEYRINGS
diff --git a/kernel/groups.c b/kernel/groups.c
index 451698f86cfa..b5ec42423202 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* init to 2 - one for init_task, one to ensure it is never freed */
@@ -223,6 +224,8 @@ SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user *, 
grouplist)
struct group_info *group_info;
int retval;
 
+   if (!test_bit(USERNS_SETGROUPS_ALLOWED, ¤t_user_ns()->flags))
+   return -EPERM;
if (!ns_capable(current_user_ns(), CAP_SETGID))
return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
diff --git a/kernel/user.c b/kernel/user.c
index 4efa39350e44..58fba8ea0845 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -51,6 +51,7 @@ struct user_namespace init_user_ns = {
.owner = GLOBAL_ROOT_UID,

Re: [PATCH v6 34/46] virtio_net: disable mac write for virtio 1.0

[Michael S. Tsirkin]

On Fri, Nov 28, 2014 at 08:48:24AM +0008, Jason Wang wrote:
> 
> 
> On Fri, Nov 28, 2014 at 4:10 AM, Michael S. Tsirkin  wrote:
> >The spec states that mac in config space is only driver-writable in the
> >legacy case.  Fence writing it in virtnet_set_mac_address() in the
> >virtio 1.0 case.
> >
> >Suggested-by: Cornelia Huck 
> >Signed-off-by: Michael S. Tsirkin 
> >---
> > drivers/net/virtio_net.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> >index c6a72d3..9ab3c50 100644
> >--- a/drivers/net/virtio_net.c
> >+++ b/drivers/net/virtio_net.c
> >@@ -1030,7 +1030,8 @@ static int virtnet_set_mac_address(struct net_device
> >*dev, void *p)
> >  "Failed to set mac address by vq command.\n");
> > return -EINVAL;
> > }
> >-} else if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC)) {
> >+} else if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC) &&
> >+   !virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> > unsigned int i;
> > /* Naturally, this has an atomicity problem. */
> >-- 
> >MST
> 
> Does this mean there's no way to setting mac addres
> if ctrl mac addr is disabled in virtio-1?

More exactly: no way for host to know the guest mac address.

> If yes, we'd better keep this compatibility somehow.

If host wants to be notified about guest mac updates,
it must enable the appropriate ctrl command.
Or if it's an old host, it just doesn't enable virtio-1.

There's no way around this - it's in the spec.


-- 
MST
--
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 v6 01/46] virtio: add low-level APIs for feature bits

[Michael S. Tsirkin]

On Fri, Nov 28, 2014 at 11:02:20AM +0100, Cornelia Huck wrote:
> On Thu, 27 Nov 2014 22:07:36 +0200
> "Michael S. Tsirkin"  wrote:
> 
> > Add low level APIs to test/set/clear feature bits.
> > For use by transports, to make it easier to
> > write code independent of feature bit array format.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >  include/linux/virtio_config.h | 53 
> > ---
> >  1 file changed, 50 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
> > index 7f4ef66..249fcd6 100644
> > --- a/include/linux/virtio_config.h
> > +++ b/include/linux/virtio_config.h
> > @@ -77,11 +77,47 @@ void virtio_check_driver_offered_feature(const struct 
> > virtio_device *vdev,
> >  unsigned int fbit);
> > 
> >  /**
> > - * virtio_has_feature - helper to determine if this device has this 
> > feature.
> > + * __virtio_test_bit - helper to test feature bits. For use by transports.
> > + * Devices should normally use virtio_has_feature,
> > + * which includes more checks.
> >   * @vdev: the device
> >   * @fbit: the feature bit
> >   */
> > -static inline bool virtio_has_feature(const struct virtio_device *vdev,
> > +static inline bool __virtio_test_bit(const struct virtio_device *vdev,
> > +unsigned int fbit)
> > +{
> > +   /* Did you forget to fix assumptions on max features? */
> > +   if (__builtin_constant_p(fbit))
> > +   BUILD_BUG_ON(fbit >= 32);
> > +   else
> > +   BUG_ON(fbit >= 32);
> 
> Does this want to be a helper? Might be overkill, but I'm always wary
> of changes that need to be applied manually in many different places :)

I'm not sure.  It's just an assert, if it's not obvious
what it checks then it doesn't serve a useful purpose.

> > +
> > +   return test_bit(fbit, vdev->features);
> > +}
> > +
> > +/**
> > + * __virtio_set_bit - helper to set feature bits. For use by transports.
> > + * @vdev: the device
> > + * @fbit: the feature bit
> > + */
> > +static inline void __virtio_set_bit(struct virtio_device *vdev,
> > +   unsigned int fbit)
> > +{
> > +   /* Did you forget to fix assumptions on max features? */
> > +   if (__builtin_constant_p(fbit))
> > +   BUILD_BUG_ON(fbit >= 32);
> > +   else
> > +   BUG_ON(fbit >= 32);
> > +
> > +   set_bit(fbit, vdev->features);
> > +}
> > +
> > +/**
> > + * __virtio_clear_bit - helper to set feature bits. For use by transports.
> 
> s/set/clear/

Good catch, thanks.

> > + * @vdev: the device
> > + * @fbit: the feature bit
> > + */
> > +static inline void __virtio_clear_bit(struct virtio_device *vdev,
> >   unsigned int fbit)
> >  {
> > /* Did you forget to fix assumptions on max features? */
> > @@ -90,10 +126,21 @@ static inline bool virtio_has_feature(const struct 
> > virtio_device *vdev,
> > else
> > BUG_ON(fbit >= 32);
> > 
> > +   clear_bit(fbit, vdev->features);
> > +}
> > +
> > +/**
> > + * virtio_has_feature - helper to determine if this device has this 
> > feature.
> > + * @vdev: the device
> > + * @fbit: the feature bit
> > + */
> > +static inline bool virtio_has_feature(const struct virtio_device *vdev,
> > + unsigned int fbit)
> > +{
> > if (fbit < VIRTIO_TRANSPORT_F_START)
> > virtio_check_driver_offered_feature(vdev, fbit);
> > 
> > -   return test_bit(fbit, vdev->features);
> > +   return __virtio_test_bit(vdev, fbit);
> >  }
> > 
> >  static inline
--
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 v6 20/46] KVM: s390: enable virtio-ccw revision 1

[Michael S. Tsirkin]

On Fri, Nov 28, 2014 at 11:09:10AM +0100, Cornelia Huck wrote:
> On Thu, 27 Nov 2014 22:09:30 +0200
> "Michael S. Tsirkin"  wrote:
> 
> > From: Cornelia Huck 
> > 
> > Now that virtio-ccw has everything needed to support virtio 1.0 in
> > place, try to enable it if the host supports it.
> > 
> > MST: enable virtio 1.0 feature bit
> 
> Stale comment?

Sure, thanks.

> > 
> > Reviewed-by: David Hildenbrand 
> > Signed-off-by: Cornelia Huck 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >  drivers/s390/kvm/virtio_ccw.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
> > index 79f6737..8ec68dd 100644
> > --- a/drivers/s390/kvm/virtio_ccw.c
> > +++ b/drivers/s390/kvm/virtio_ccw.c
> > @@ -103,7 +103,7 @@ struct virtio_rev_info {
> >  };
> > 
> >  /* the highest virtio-ccw revision we support */
> > -#define VIRTIO_CCW_REV_MAX 0
> > +#define VIRTIO_CCW_REV_MAX 1
> > 
> >  struct virtio_ccw_vq_info {
> > struct virtqueue *vq;
--
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 v6 01/46] virtio: add low-level APIs for feature bits

[Michael S. Tsirkin]

On Fri, Nov 28, 2014 at 01:10:57PM +0100, David Hildenbrand wrote:
> > Add low level APIs to test/set/clear feature bits.
> > For use by transports, to make it easier to
> > write code independent of feature bit array format.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >  include/linux/virtio_config.h | 53 
> > ---
> >  1 file changed, 50 insertions(+), 3 deletions(-)
> > 
> 
> As these functions really set feature bits, I would rather name them:
> 
> virtio_has_feature ...
> virtio_set_feature ...
> virtio_clear_feature ...

We have these as high level APIs for drivers.
These are low level ones so need a different
name.


> But in general, this looks good to me!
--
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: [Update][PATCH] USB / PM: Drop CONFIG_PM_RUNTIME from the USB core

[Alan Stern]

On Sat, 29 Nov 2014, Rafael J. Wysocki wrote:

> > There are also one or two places in Documentation/usb that mention 
> > CONFIG_PM_RUNTIME.
> 
> I found this in Documentation/usb/power-management.txt:
> 
> "Note: Dynamic PM support for USB is present only if the kernel was
>  built with CONFIG_USB_SUSPEND enabled (which depends on
>  CONFIG_PM_RUNTIME).  System PM support is present only if the kernel
>  was built with CONFIG_SUSPEND or CONFIG_HIBERNATION enabled.
> 
>  (Starting with the 3.10 kernel release, dynamic PM support for USB is
>  present whenever the kernel was built with CONFIG_PM_RUNTIME enabled.
>  The CONFIG_USB_SUSPEND option has been eliminated.)"
> 
> but I'm quite unsure how to change it.  What about:
> 
> "System PM support is present only if the kernel was built with CONFIG_SUSPEND
>  or CONFIG_HIBERNATION enabled.  Dynamic PM support for USB is present 
> whenever
>  the kernel was built with CONFIG_PM enabled.
> 
>  [Historically, dynamic PM support for USB was present only if the kernel
>  had been built with CONFIG_USB_SUSPEND enabled (which depended on
>  CONFIG_PM_RUNTIME).  Starting with the 3.10 kernel release, dynamic PM 
> support
>  for USB was present whenever the kernel was built with CONFIG_PM_RUNTIME
>  enabled.  The CONFIG_USB_SUSPEND option had been eliminated.]

That sounds fine.  Thanks.

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 v6 02/46] virtio: use u32, not bitmap for features

[Michael S. Tsirkin]

On Fri, Nov 28, 2014 at 01:44:57PM +0100, Cornelia Huck wrote:
> On Thu, 27 Nov 2014 22:07:41 +0200
> "Michael S. Tsirkin"  wrote:
> 
> > It seemed like a good idea to use bitmap for features
> > in struct virtio_device, but it's actually a pain,
> > and seems to become even more painful when we get more
> > than 32 feature bits.  Just change it to a u32 for now.
> > 
> > Based on patch by Rusty.
> > 
> > Suggested-by: David Hildenbrand 
> > Signed-off-by: Rusty Russell 
> > Signed-off-by: Cornelia Huck 
> > Signed-off-by: Michael S. Tsirkin 
> 
> > diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
> > index d34ebfa..ab95a4c 100644
> > --- a/drivers/virtio/virtio_pci.c
> > +++ b/drivers/virtio/virtio_pci.c
> > @@ -120,8 +120,7 @@ static void vp_finalize_features(struct virtio_device 
> > *vdev)
> > vring_transport_features(vdev);
> > 
> > /* We only support 32 feature bits. */
> 
> I think you can kill this comment...

Why? It's still true for virtio pci at this point, that's why we
just do iowrite32 here.

> > -   BUILD_BUG_ON(ARRAY_SIZE(vdev->features) != 1);
> > -   iowrite32(vdev->features[0], vp_dev->ioaddr+VIRTIO_PCI_GUEST_FEATURES);
> > +   iowrite32(vdev->features, vp_dev->ioaddr+VIRTIO_PCI_GUEST_FEATURES);
> 
> ...and add blanks around '+', as you're touching this line anyway.
> 
> >  }
> > 
> >  /* virtio config->get() implementation */
> 
> Reviewed-by: Cornelia Huck 
--
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] ACPI / video: check _DOD list when creating backlight device

[Brian Norris]

On Sat, Nov 29, 2014 at 09:01:47PM +0800, Aaron Lu wrote:
> On 11/29/2014 01:18 AM, Brian Norris wrote:
> > On Fri, Nov 28, 2014 at 07:55:00PM +0800, Aaron Lu wrote:
> >> On 11/28/2014 05:59 PM, Brian Norris wrote:
> >>> Do you need any additional info to handle the regression, or should we
> >>> just revert the patch?
> >>
> >> Please attach acpidump, dmesg with video.dyndbg="module video +pft" in
> >> kernel cmdline, list the /sys/class/backlight with and without this
> >> commit, thanks.
[...]
> > Before reverting:
> > 
> > $ ls -al /sys/class/backlight
> > total 0
> > drwxr-xr-x  2 root root 0 Nov 28 09:01 .
> > drwxr-xr-x 58 root root 0 Nov 28 09:01 ..
> > 
> > After reverting:
> > 
> > $ ls -al /sys/class/backlight
> > total 0
> > drwxr-xr-x  2 root root 0 Nov 28 09:10 .
> > drwxr-xr-x 50 root root 0 Nov 28 09:10 ..
> > lrwxrwxrwx  1 root root 0 Nov 28 09:09 acpi_video0 -> 
> > ../../devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0
> 
> The current logic to bind device doesn't work with your system, that
> logic is there for a long time so I prefer not to change that, instead,
> I can change the newly added function acpi_video_device_in_dod to let it
> directly compare the 0-12 bits of the ID to decide if the video output
> device is in the _DOD list. Can you please try the following patch?
> 
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 41e6b977ceb2..185a57d13723 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -1164,7 +1164,8 @@ static bool acpi_video_device_in_dod(struct 
> acpi_video_device *device)
>   return true;
>  
>   for (i = 0; i < video->attached_count; i++) {
> - if (video->attached_array[i].bind_info == device)
> + if ((video->attached_array[i].value.int_val & 0xfff) ==
> + (device->device_id & 0xfff))
>   return true;
>   }

Thanks for the patch! This works better for me:

$ ls -al /sys/class/backlight/
total 0
drwxr-xr-x  2 root root 0 Nov 29 09:00 .
drwxr-xr-x 50 root root 0 Nov 29 09:00 ..
lrwxrwxrwx  1 root root 0 Nov 29 08:59 acpi_video0 -> 
../../devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0

And I see no dmesg dev_dbg() prints from the acpi/video module.

Tested-by: Brian Norris 

Should we try to get this into 3.18, then?

Thanks,
Brian
--
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] tty: serial: serial-omap: depend on !8250_omap

[Tony Lindgren]

* Sebastian Andrzej Siewior  [141129 01:50]:
> * Sebastian Andrzej Siewior | 2014-11-26 23:01:46 [+0100]:
> 
> >Technically speaking this is not required. If both are enabled then the
> >Maikefile order says that 8250 one wins, the second is never probed.
> >
> >If we choose to enable 8250_omap via defconfig then one might get supprised
> >that his console isn't working anymore since nothing says use ttySx
> >instead ttyOx.
> >This patch _tries_ to bring this to the users' attention by not showing
> >the serial-omap driver once the 8250 one is enabled. So the user might
> >choose to use the help text which says that this driver (8250_omap)
> >uses ttySx instead ttyOx.
> >
> >Signed-off-by: Sebastian Andrzej Siewior 
> >---
> >This is my attempt to warn the defconfig user of the defconfig change
> >(which did not yet happen). Any suggestions?
> 
> This is was Uwe Kleine-König suggested off-list:
> 
> |Currently there are two drivers for the serial device. Until the new one
> |matured enough to drop the old one, let them conflict each other. They
> |both handle the same devices, but only one can be responsible for a
> |single device. There is no technical need, but having two drivers in the
> |same kernel might result in surprises.
> 
> I personally don't mind having two drivers enabled since the makefile
> order is always the same. My main concern is the ttyOx -> ttySx switch
> after the newer driver is enabled by default via defconfig (and the user
> does not know it). "make oldconfig" is covered by "default n".
> Uwe's has a point about "matured enough to drop the old one". It isn't
> mentioned anywhere that the newer driver supports also DMA. Is this
> something we want to add to the help text?
> Could someone that will probably be dealling with possible fallout comment
> on this? This patch shouldn't go in without an ACK.

Well the nightmare userspace switch from ttyS to ttyO few years ago is
something we want to avoid.. I think the best solution would be to make
serial-omap.c transparently provide support for ttyO using the new 8250
code so both ttyS and ttyO devices would just work. Otherwise it will
be years of "my serial port stopped working" questions again.

Regards,

Tony
--
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: manual merge of the block tree with the ext4 tree

[Theodore Ts'o]

Note the relevant changes from the ext4 tree were dropped from the
dev branch, so this shouldn't be an issue moving forward.

  - 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/

[PATCH 1/1] SPI-txx9: Deletion of an unnecessary check before the function call "clk_disable"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 18:34:20 +0100

The clk_disable() 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 
---
 drivers/spi/spi-txx9.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/spi/spi-txx9.c b/drivers/spi/spi-txx9.c
index 0da7c67..9190124 100644
--- a/drivers/spi/spi-txx9.c
+++ b/drivers/spi/spi-txx9.c
@@ -402,8 +402,7 @@ exit_busy:
 exit:
if (c->workqueue)
destroy_workqueue(c->workqueue);
-   if (c->clk)
-   clk_disable(c->clk);
+   clk_disable(c->clk);
spi_master_put(master);
return ret;
 }
-- 
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 v8 2/4] ARM: mediatek: Add sysirq interrupt polarity support

[Beniamino Galvani]

On Tue, Nov 25, 2014 at 04:04:20PM +0800, Yingjoe Chen wrote:
> Mediatek SoCs have interrupt polarity support in sysirq which
> allows to invert polarity for given interrupt. Add this support
> using hierarchy irq domain.
>
> [...]
> 
> +static int __init mtk_sysirq_of_init(struct device_node *node,
> +  struct device_node *parent)
> +{
> + struct irq_domain *domain, *domain_parent;
> + struct mtk_sysirq_chip_data *chip_data;
> + int ret = 0;
> +
> + domain_parent = irq_find_host(parent);
> + if (!domain_parent) {
> + pr_err("mtk_sysirq: interrupt-parent not found\n");
> + return -EINVAL;
> + }
> +
> + chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
> + if (!chip_data)
> + return -ENOMEM;
> +
> + chip_data->intpol_base = of_io_request_and_map(node, 0, "intpol");
> + if (!chip_data->intpol_base) {

Hi,

you should use IS_ERR() to check the return value here.

Beniamino
--
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] i8k: Add support for temperature sensor labels

[Greg Kroah-Hartman]

On Sat, Nov 29, 2014 at 05:04:07PM +0100, Pali Rohár wrote:
> This patch adds labels for temperature sensors if SMM function with EAX 
> register
> 0x11a3 reports it. These informations was taken from DOS binary NBSVC.MDM.
> 
> Signed-off-by: Pali Rohár 
> ---
>  drivers/char/i8k.c |  110 
> +---
>  1 file changed, 88 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> index e34a019..77af46b 100644
> --- a/drivers/char/i8k.c
> +++ b/drivers/char/i8k.c
> @@ -42,6 +42,7 @@
>  #define I8K_SMM_GET_FAN  0x00a3
>  #define I8K_SMM_GET_SPEED0x02a3
>  #define I8K_SMM_GET_TEMP 0x10a3
> +#define I8K_SMM_GET_TEMP_TYPE0x11a3
>  #define I8K_SMM_GET_DELL_SIG10xfea3
>  #define I8K_SMM_GET_DELL_SIG20xffa3
>  
> @@ -288,6 +289,14 @@ static int i8k_set_fan(int fan, int speed)
>   return i8k_smm(®s) ? : i8k_get_fan_status(fan);
>  }
>  
> +static int i8k_get_temp_type(int sensor)
> +{
> + struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP_TYPE, };
> +
> + regs.ebx = sensor & 0xff;
> + return i8k_smm(®s) ? : regs.eax & 0xff;
> +}
> +
>  /*
>   * Read the cpu temperature.
>   */
> @@ -493,6 +502,29 @@ static int i8k_open_fs(struct inode *inode, struct file 
> *file)
>   * Hwmon interface
>   */
>  
> +static ssize_t i8k_hwmon_show_temp_label(struct device *dev,
> +struct device_attribute *devattr,
> +char *buf)
> +{
> + static const char * const labels[] = {
> + "CPU",
> + "GPU",
> + "SODIMM",
> + "Other",
> + "Ambient",
> + "Other",
> + };
> + int index = to_sensor_dev_attr(devattr)->index;
> + int type;
> +
> + type = i8k_get_temp_type(index);
> + if (type < 0)
> + return type;
> + if (type >= ARRAY_SIZE(labels))
> + type = ARRAY_SIZE(labels) - 1;
> + return sprintf(buf, "%s\n", labels[type]);
> +}

No Documentation/ABI/ entry for your new sysfs file?
--
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] Drivers:staging:clocking-wizard: Added a newline

[Greg KH]

On Sat, Nov 29, 2014 at 06:03:06PM +0530, Athira S wrote:
> Fixed checkpatch warning:
> Missing a newline after declarations
> 
> Signed-off-by: Athira S 

Is "Athira S" what you use to sign legal documents?  If not, please fix
and resend.
--
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] i8k: Add support for temperature sensor labels

[Pali Rohár]

On Saturday 29 November 2014 18:43:15 Greg Kroah-Hartman wrote:
> On Sat, Nov 29, 2014 at 05:04:07PM +0100, Pali Rohár wrote:
> > This patch adds labels for temperature sensors if SMM
> > function with EAX register 0x11a3 reports it. These
> > informations was taken from DOS binary NBSVC.MDM.
> > 
> > Signed-off-by: Pali Rohár 
> > ---
> > 
> >  drivers/char/i8k.c |  110
> >  +--- 1
> >  file changed, 88 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> > index e34a019..77af46b 100644
> > --- a/drivers/char/i8k.c
> > +++ b/drivers/char/i8k.c
> > @@ -42,6 +42,7 @@
> > 
> >  #define I8K_SMM_GET_FAN0x00a3
> >  #define I8K_SMM_GET_SPEED  0x02a3
> >  #define I8K_SMM_GET_TEMP   0x10a3
> > 
> > +#define I8K_SMM_GET_TEMP_TYPE  0x11a3
> > 
> >  #define I8K_SMM_GET_DELL_SIG1  0xfea3
> >  #define I8K_SMM_GET_DELL_SIG2  0xffa3
> > 
> > @@ -288,6 +289,14 @@ static int i8k_set_fan(int fan, int
> > speed)
> > 
> > return i8k_smm(®s) ? : i8k_get_fan_status(fan);
> >  
> >  }
> > 
> > +static int i8k_get_temp_type(int sensor)
> > +{
> > +   struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP_TYPE, };
> > +
> > +   regs.ebx = sensor & 0xff;
> > +   return i8k_smm(®s) ? : regs.eax & 0xff;
> > +}
> > +
> > 
> >  /*
> >  
> >   * Read the cpu temperature.
> >   */
> > 
> > @@ -493,6 +502,29 @@ static int i8k_open_fs(struct inode
> > *inode, struct file *file)
> > 
> >   * Hwmon interface
> >   */
> > 
> > +static ssize_t i8k_hwmon_show_temp_label(struct device
> > *dev, +struct device_attribute *devattr,
> > +  char *buf)
> > +{
> > +   static const char * const labels[] = {
> > +   "CPU",
> > +   "GPU",
> > +   "SODIMM",
> > +   "Other",
> > +   "Ambient",
> > +   "Other",
> > +   };
> > +   int index = to_sensor_dev_attr(devattr)->index;
> > +   int type;
> > +
> > +   type = i8k_get_temp_type(index);
> > +   if (type < 0)
> > +   return type;
> > +   if (type >= ARRAY_SIZE(labels))
> > +   type = ARRAY_SIZE(labels) - 1;
> > +   return sprintf(buf, "%s\n", labels[type]);
> > +}
> 
> No Documentation/ABI/ entry for your new sysfs file?

It is standard hwmon sysfs entry which is used by other hwmon 
drivers... It is not i8k.ko driver specific.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ext4: fix suboptimal seek_{data,hole} extents traversial

[Theodore Ts'o]

On Fri, Nov 28, 2014 at 06:02:02PM +0300, Dmitry Monakhov wrote:
> FYI: inline_data feature is fatally broken

Thanks for finding the bugs!

> 2) ext4_inline_data_fiemap(0 ignores start and len arguments from 
> ext4_filemap()
>which obviously result in endless loop for anyone who want to use
>fiemap for inline files (which my patch try to do)

Would this have been triggered using filefrag?  I just checked and
noticed we don't have a filefrag test in xfstests; of course it would
be impossible to test other than the filefrag -v command successfully
completed, but maybe it might be worth adding such a test.

   - 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: [PATCH] i8k: Add support for temperature sensor labels

[Greg Kroah-Hartman]

On Sat, Nov 29, 2014 at 06:49:43PM +0100, Pali Rohár wrote:
> On Saturday 29 November 2014 18:43:15 Greg Kroah-Hartman wrote:
> > On Sat, Nov 29, 2014 at 05:04:07PM +0100, Pali Rohár wrote:
> > > This patch adds labels for temperature sensors if SMM
> > > function with EAX register 0x11a3 reports it. These
> > > informations was taken from DOS binary NBSVC.MDM.
> > > 
> > > Signed-off-by: Pali Rohár 
> > > ---
> > > 
> > >  drivers/char/i8k.c |  110
> > >  +--- 1
> > >  file changed, 88 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> > > index e34a019..77af46b 100644
> > > --- a/drivers/char/i8k.c
> > > +++ b/drivers/char/i8k.c
> > > @@ -42,6 +42,7 @@
> > > 
> > >  #define I8K_SMM_GET_FAN  0x00a3
> > >  #define I8K_SMM_GET_SPEED0x02a3
> > >  #define I8K_SMM_GET_TEMP 0x10a3
> > > 
> > > +#define I8K_SMM_GET_TEMP_TYPE0x11a3
> > > 
> > >  #define I8K_SMM_GET_DELL_SIG10xfea3
> > >  #define I8K_SMM_GET_DELL_SIG20xffa3
> > > 
> > > @@ -288,6 +289,14 @@ static int i8k_set_fan(int fan, int
> > > speed)
> > > 
> > >   return i8k_smm(®s) ? : i8k_get_fan_status(fan);
> > >  
> > >  }
> > > 
> > > +static int i8k_get_temp_type(int sensor)
> > > +{
> > > + struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP_TYPE, };
> > > +
> > > + regs.ebx = sensor & 0xff;
> > > + return i8k_smm(®s) ? : regs.eax & 0xff;
> > > +}
> > > +
> > > 
> > >  /*
> > >  
> > >   * Read the cpu temperature.
> > >   */
> > > 
> > > @@ -493,6 +502,29 @@ static int i8k_open_fs(struct inode
> > > *inode, struct file *file)
> > > 
> > >   * Hwmon interface
> > >   */
> > > 
> > > +static ssize_t i8k_hwmon_show_temp_label(struct device
> > > *dev, +  struct device_attribute *devattr,
> > > +char *buf)
> > > +{
> > > + static const char * const labels[] = {
> > > + "CPU",
> > > + "GPU",
> > > + "SODIMM",
> > > + "Other",
> > > + "Ambient",
> > > + "Other",
> > > + };
> > > + int index = to_sensor_dev_attr(devattr)->index;
> > > + int type;
> > > +
> > > + type = i8k_get_temp_type(index);
> > > + if (type < 0)
> > > + return type;
> > > + if (type >= ARRAY_SIZE(labels))
> > > + type = ARRAY_SIZE(labels) - 1;
> > > + return sprintf(buf, "%s\n", labels[type]);
> > > +}
> > 
> > No Documentation/ABI/ entry for your new sysfs file?
> 
> It is standard hwmon sysfs entry which is used by other hwmon 
> drivers... It is not i8k.ko driver specific.

Ok, then why is this driver not in a "hwmon-standard" location in the
kernel tree?

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] Drivers:input:mousedev.c: Fixed trailing statement on the next line

[Joe Perches]

On Sat, 2014-11-29 at 21:50 +0530, Athira S wrote:
> Fixed checkpatch error:
> trailing statements should be on next line
> 
> signed-off-by: Athira S 
> ---
>  drivers/input/mousedev.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
> index be2cc5c..28988f5 100644
> --- a/drivers/input/mousedev.c
> +++ b/drivers/input/mousedev.c
> @@ -248,8 +248,8 @@ static void mousedev_key_event(struct mousedev *mousedev,
>   case BTN_4:
>   case BTN_EXTRA: index = 4; break;
>  
> - default:
> - return;
> + default:
> + return;

Please run your suggested patches though
scripts/checkpatch.pl before sending them.

Don't send patches on top of your own
unapplied patches.  Use the original and
create a new patch.

Probably none of this needs to be changed.


--
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] net-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 29 Nov 2014 18:55:40 +0100

The pci_dev_put() 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 
---
 drivers/net/ethernet/pasemi/pasemi_mac.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c 
b/drivers/net/ethernet/pasemi/pasemi_mac.c
index 30d934d..44e8d7d 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1837,10 +1837,8 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
return err;
 
 out:
-   if (mac->iob_pdev)
-   pci_dev_put(mac->iob_pdev);
-   if (mac->dma_pdev)
-   pci_dev_put(mac->dma_pdev);
+   pci_dev_put(mac->iob_pdev);
+   pci_dev_put(mac->dma_pdev);
 
free_netdev(dev);
 out_disable_device:
-- 
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/