Re: [PATCH] Input: xpad - use LED API when identifying wireless controllers
On Sat, Dec 19, 2015 at 10:17:09PM +0100, Clement Calmels wrote:
> On Wed, 16 Dec 2015 14:44:08 -0800
> Dmitry Torokhov wrote:
>
> > When lighting up the segment identifying wireless controller, Instead
> > of sending command directly to the controller, let's do it via LED
> > API (usinf led_set_brightness) so that LED object state is in sync
> > with controller state and we'll light up the correct segment on
> > resume as well.
> >
> > Signed-off-by: Dmitry Torokhov
> > ---
> >
> > I do not have the hardware so please try this out.
> >
> > drivers/input/joystick/xpad.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/joystick/xpad.c
> > b/drivers/input/joystick/xpad.c index 36328b3..00a766b 100644
> > --- a/drivers/input/joystick/xpad.c
> > +++ b/drivers/input/joystick/xpad.c
> > @@ -1118,7 +1118,7 @@ static void xpad_send_led_command(struct
> > usb_xpad *xpad, int command) */
> > static void xpad_identify_controller(struct usb_xpad *xpad)
> > {
> > - xpad_send_led_command(xpad, (xpad->pad_nr % 4) + 2);
> > + led_set_brightness(>led->led_cdev, (xpad->pad_nr % 4)
> > + 2); }
> >
> > static void xpad_led_set(struct led_classdev *led_cdev,
>
> Hi Dimitri,
Hi Clement,
>
> My hardware: two wireless xpad 360 using a single usb receiver.
>
> Power on the first gamepad => light the "1" led.
> Power on the second gamepad => light the "2" led.
>
> Suspend the PC (systemctl suspend): the two gamepads are "disconnected"
> => blinking circle.
>
> Resume the PC, the two gamepads keep blinking but are working (tested
> with jstest).
>
> Power off and on the gamepad => still blinking.
> Reload (rmmod/modprobe) the xpad module => still blinking.
>
> That said, without your patch, the behavior is exactly the same.
> It seems that the suspend/resume broke the led feature. Even using
> the /sys/class/leds/xpad0/brigthness sysfs entry does not work.
>
OK, so the patch does work (the device is still correctly identified),
but resume requires additional patches. Could you try 'xpad' branch of
my tree on kernel.org [1] and let me know if it works for you?
Thanks!
--
Dmitry
[1] git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
--
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 v3 2/5] thermal: rockchip: fix a impossible condition caused by the warning
在 2015年12月04日 04:19, Dmitry Torokhov 写道:
On Thu, Dec 03, 2015 at 04:48:40PM +0800, Caesar Wang wrote:
As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'
Let's we remove the imposssible condition Since the Temperature is
currently represented as int not long in the thermal driver.
Fixes: commit 437df2172e8d
("thermal: rockchip: consistently use int for temperatures")
Reported-by: Dan Carpenter
Signed-off-by: Caesar Wang
---
Changes in v3:
- As Brian comments on https://patchwork.kernel.org/patch/7580661/,
let's remove the impossible condition.
Changes in v2: None
Changes in v1: None
drivers/thermal/rockchip_thermal.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index ae796ec..611de00 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -549,12 +549,6 @@ static int rockchip_configure_from_dt(struct device *dev,
thermal->tshut_temp = shut_temp;
}
- if (thermal->tshut_temp > INT_MAX) {
- dev_err(dev, "Invalid tshut temperature specified: %d\n",
- thermal->tshut_temp);
- return -ERANGE;
- }
Well, that is not entirely correct. The value that we read from DT is
u32, but we convert it down to int. I believe you want to move the check
up so that you do:
} else if (tshut_temp > INT_MAX) {
dev_err(dev, "Invalid tshut temperature specified: %d\n",
thermal->tshut_temp);
return -ERANGE;
} else {
thermal->tshut_temp = shut_temp;
}
Okay,
that's seem the following wll be resonable since the checkcode is a warning.
if (of_property_read_u32(np, "rockchip,hw-tshut-temp", _temp)) {
dev_warn(dev,
"Missing tshut temp property, using default %d\n",
thermal->chip->tshut_temp);
thermal->tshut_temp = thermal->chip->tshut_temp;
} else {
if (tshut_temp > INT_MAX) {
dev_err(dev, "Invalid tshut temperature specified: %d\n",
tshut_temp);
return -ERANGE;
}
thermal->tshut_temp = shut_temp;
}
Thanks,
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/
Re: [patch 3/5] futex: Document pi_state refcounting in requeue code
On Sat, Dec 19, 2015 at 08:07:39PM -, Thomas Gleixner wrote:
> Documentation of the pi_state refcounting in the requeue code is non
> existent. Add it.
>
OK, one nitpic on this one I guess - 80 characters is pretty narrow as it is in
my humble opinion, could we expand the newly added comment blocks to use all of
the 80 character limit?
> Signed-off-by: Thomas Gleixner
> ---
> kernel/futex.c | 36 +---
> 1 file changed, 33 insertions(+), 3 deletions(-)
>
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
...
> - /* We got the lock. */
> + /*
> + * We got the lock. We do neither drop
> + * the refcount on pi_state nor clear
> + * this->pi_state because the waiter
> + * needs the pi_state for cleaning up
> + * the user space value. It will drop
> + * the refcount after doing so.
> + */
> requeue_pi_wake_futex(this, , hb2);
> drop_count++;
> continue;
> } else if (ret) {
> - /* -EDEADLK */
> + /*
> + * rt_mutex_start_proxy_lock()
> + * detected a potential deadlock when
> + * we tried to queue that waiter. Drop
> + * the pi_state reference which we
> + * took above and remove the pointer
> + * to the state from the waiters
> + * futex_q object.
> + */
Especially the two paragraphs above ^
--
Darren Hart
Intel Open Source Technology Center
--
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 5/5] futex: Cleanup the goto confusion in requeue_pi()
On Sun, Dec 20, 2015 at 06:40:07AM +0100, Mike Galbraith wrote:
> On Sat, 2015-12-19 at 21:15 -0800, Darren Hart wrote:
>
> > As a follow-on, I think it might be worthwhile to create a symmetrical
> > get_pi_state() to the put_pi_state(), rather than handling the atomic_inc
> > directly.
>
> Ditto, immediate thought was future auditors will look for it.
Hrm, well, I had just dismissed this after some digging, but OK, let's think it
through a bit...
Turns out there is only one open coded atomic_inc. the other occurs through
attach_to_pi_state, sometimes via lookup_pi_state. We might be able to
consolidate that some so it had a more symmetric and consistent usage pattern.
A "get' in the futex op functions currently occurs via:
1) lookup_pi_state -> attach_to_pi_state()
2) attach_to_pi_state()
(directly - nearly copying lookup_pi_state at the call site)
3) futex_lock_pi_atomic -> attach_to_pi_state()
4) atomic_inc(pi_state->ref_count) in futex_requeue_pi on behalf of the waiter
in futex_wait_requeue_pi.
Newly allocated or re-purposed pi_states get their refcount set to 1 which
doesn't really count as a "get" until a lookup_pi_state or implicit acquisition
through futex_lock_pi_atomic->attach_to_pi_state.
As it turns out, lookup_pi_state is only used once in futex.c, but it really
does make that section more readable. Despite an overall savings of a couple of
lines, I think it's worth keeping, even if it adds another layer to the "get".
As a further cleanup, Thomas removed the unnecessary calls to put_pi_state, and
those that remain have no ambiguity about whether or not the pi_state is NULL.
We *could* drop the NULL check in put_pi_state, which would make it's use all
the more explicit. Perhaps a BUG_ON(!pi_state)? Not included below.
The first get is still implicit in the way the caching of the pi_state works.
This gets assigned with an existing refcount of 1 in attach_to_pi_owner from the
cache via alloc_pi_state. I don't know if there is a reason for starting it off
as 1 instead of 0. Perhaps we could make this more explicit by keeping it at 0
in the cache and using get_pi_state in alloc_pi_state before giving it to the
waiter?
Something like this perhaps? (Untested):
>From 2d4cce06d36b16dcd038d7a68a6efc7740848ee1 Mon Sep 17 00:00:00 2001
Message-Id:
<2d4cce06d36b16dcd038d7a68a6efc7740848ee1.1450596757.git.dvh...@linux.intel.com>
From: Darren Hart
Date: Sat, 19 Dec 2015 22:57:05 -0800
Subject: [PATCH] futex: Add a get_pi_state wrapper
For audit purposes, add an inline wrapper, get_pi_state(), around
atomic_inc(_state->refcount) to parallel the newly renamed
put_pi_state().
To make the get/set parallel and more explicit, keep the refcount at 0
while in the cache and only inc to 1 when it is allocated to a waiter
via alloc_pi_state().
Signed-off-by: Darren Hart
---
kernel/futex.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index ae83ea7..4c71c86 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -706,7 +706,7 @@ static int refill_pi_state_cache(void)
INIT_LIST_HEAD(_state->list);
/* pi_mutex gets initialized later */
pi_state->owner = NULL;
- atomic_set(_state->refcount, 1);
+ atomic_set(_state->refcount, 0);
pi_state->key = FUTEX_KEY_INIT;
current->pi_state_cache = pi_state;
@@ -714,12 +714,21 @@ static int refill_pi_state_cache(void)
return 0;
}
+/*
+ * Adds a reference to the pi_state object.
+ */
+static inline void get_pi_state(struct futex_pi_state *pi_state)
+{
+ atomic_inc(_state->refcount);
+}
+
static struct futex_pi_state * alloc_pi_state(void)
{
struct futex_pi_state *pi_state = current->pi_state_cache;
WARN_ON(!pi_state);
current->pi_state_cache = NULL;
+ get_pi_state(pi_state);
return pi_state;
}
@@ -756,10 +765,9 @@ static void put_pi_state(struct futex_pi_state *pi_state)
/*
* pi_state->list is already empty.
* clear pi_state->owner.
-* refcount is at 0 - put it back to 1.
+* refcount is already at 0.
*/
pi_state->owner = NULL;
- atomic_set(_state->refcount, 1);
current->pi_state_cache = pi_state;
}
}
@@ -954,7 +962,7 @@ static int attach_to_pi_state(u32 uval, struct
futex_pi_state *pi_state,
if (pid != task_pid_vnr(pi_state->owner))
return -EINVAL;
out_state:
- atomic_inc(_state->refcount);
+ get_pi_state(pi_state);
*ps = pi_state;
return 0;
}
@@ -1813,7 +1821,7 @@ retry_private:
* refcount on the pi_state and store the pointer in
* the futex_q object of the waiter.
*/
- atomic_inc(_state->refcount);
+ get_pi_state(pi_state);
Re: [BUG, bisect, linux-next] do_IRQ: No irq handler for vector
Jiang Liu, On Thu, Dec 17, 2015 at 07:40:33PM -0800, Jeremiah Mahler wrote: > all, > > I just started getting these "No irq handler for vector" messages > after upgrading to linux-next 20151217+. > > > (from the first boot) > ... > [2.282652] [drm] Initialized drm 1.1.0 20060810 > [2.318806] AVX version of gcm_enc/dec engaged. > [2.318810] AES CTR mode by8 optimization enabled > [2.324446] do_IRQ: 0.35 No irq handler for vector > [2.366146] iTCO_vendor_support: vendor-support=0 > [2.372762] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 > ... > [9.249887] wlan0: associate with 2c:5d:93:09:50:48 (try 1/3) > [9.265206] wlan0: RX AssocResp from 2c:5d:93:09:50:48 (capab=0x421 > status=0 aid=8) > [9.284088] wlan0: associated > [ 10.453048] do_IRQ: 0.35 No irq handler for vector > [ 10.457923] do_IRQ: 0.35 No irq handler for vector > [ 10.457932] do_IRQ: 0.35 No irq handler for vector > [ 10.501026] do_IRQ: 0.35 No irq handler for vector > [ 10.501033] do_IRQ: 0.35 No irq handler for vector > [ 10.513951] do_IRQ: 0.35 No irq handler for vector > ... > > > (second boot, and after a resume) > ... > [10527.998694] PM: noirq resume of devices complete after 21.488 msecs > [10527.999578] PM: early resume of devices complete after 0.850 msecs > [10528.000525] rtc_cmos 00:02: System wakeup disabled by ACPI > [10528.005265] do_IRQ: 0.84 No irq handler for vector > [10528.005450] sd 0:0:0:0: [sda] Starting disk > [10528.021257] tpm_tis 00:05: TPM is disabled/deactivated (0x6) > ... > [10530.005541] PM: resume of devices complete after 2005.925 msecs > [10530.005690] usb 3-1.4:1.0: rebind failed: -517 > [10530.005696] usb 3-1.4:1.1: rebind failed: -517 > [10530.006575] Restarting tasks ... > [10530.008347] do_IRQ: 0.84 No irq handler for vector > [10530.021258] done. > [10530.042883] Bluetooth: hci0: BCM: chip id 63 > ... > [10559.005603] mei_me :00:16.0: timer: init clients timeout hbm_state = 1. > [10559.005612] mei_me :00:16.0: unexpected reset: dev_state = > INIT_CLIENTS fw status = 1E000245 6106 > [10559.009508] do_IRQ: 0.84 No irq handler for vector > [10561.005639] mei_me :00:16.0: wait hw ready failed > [10561.005644] mei_me :00:16.0: hw_start failed ret = -62 > ... > > > I can test patches if anyone has any ideas :-) > > -- > - Jeremiah Mahler I performed a bisect and found that the following patch introduced the bug, which is still present in the latest linux-next 20151218+. From 41c7518a5d14543fa4aa1b5b9994ac26b38c0406 Mon Sep 17 00:00:00 2001 From: Jiang Liu Date: Mon, 30 Nov 2015 16:09:29 +0800 Subject: [PATCH] x86/irq: Fix a race condition between vector assigning and cleanup Joe Lawrence reported an use after release issue related to x86 IRQ management code. Please refer to the following link for more information: http://lkml.kernel.org/r/5653b688.4050...@stratus.com Thomas pointed out that it's caused by a race condition between __assign_irq_vector() and __send_cleanup_vector(). Based on Thomas' draft patch, we solve this race condition by: 1) Use move_in_progress to signal that an IRQ cleanup IPI is needed 2) Use old_domain to save old CPU mask for IRQ cleanup 3) Use vector to protect move_in_progress and old_domain This bugfix patch also helps to get rid of that atomic allocation in __send_cleanup_vector(). Fixes: a782a7e46bb5 "x86/irq: Store irq descriptor in vector array" Reported-and-tested-by: Joe Lawrence Signed-off-by: Jiang Liu Cc: sta...@vger.kernel.org Link: http://lkml.kernel.org/r/1448870970-1461-4-git-send-email-jiang@linux.intel.com Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/vector.c | 77 +++ 1 file changed, 34 insertions(+), 43 deletions(-) ... -- - 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] bluetooth:Fix variable assignment for internal function returns in the function l2cap_bredr_sig_cmd
Hi Nick,
> This makes all internal functions that can return a error code to
> properly signal this to the caller of the function l2cap_bredr_sig_cmd
> by making their return value equal to the variable err before returning
> to the caller of the function l2cap_bredr_sig_cmd with this value
> as to allow us to correctly signal when a failure has occurred when
> this particular function is called.
>
> Signed-off-by: Nicholas Krause
> ---
> net/bluetooth/l2cap_core.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 7c65ee2..488eebe 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -5319,7 +5319,7 @@ static inline int l2cap_bredr_sig_cmd(struct l2cap_conn
> *conn,
>
> switch (cmd->code) {
> case L2CAP_COMMAND_REJ:
> - l2cap_command_rej(conn, cmd, cmd_len, data);
> + err = l2cap_command_rej(conn, cmd, cmd_len, data);
> break;
this patch is wrong. Please try to understand on how L2CAP works and look up
what the caller of l2cap_bredr_sig_cmd does with the return code. Responses can
not cause another command reject.
Regards
Marcel
--
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 powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Fri, Dec 18, 2015 at 09:12:50AM -0800, Davidlohr Bueso wrote: > I've left this series testing overnight on a power7 box and so far so good, > nothing has broken. Davidlohr, thank you for your testing! Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH 1/2] mm, oom: introduce oom reaper
Tetsuo Handa wrote:
> Complete log is at http://I-love.SAKURA.ne.jp/tmp/serial-20151218.txt.xz .
> --
> [ 438.304082] Killed process 12680 (oom_reaper-test) total-vm:4324kB,
> anon-rss:120kB, file-rss:0kB, shmem-rss:0kB
> [ 439.318951] oom_reaper: attempts=11
> [ 445.581171] MemAlloc-Info: 796 stalling task, 0 dying task, 0 victim task.
> [ 618.955215] MemAlloc-Info: 979 stalling task, 0 dying task, 0 victim task.
> --
>
> Yes, this is an insane program. But what is important will be we prepare for
> cases when oom_reap_vmas() gave up waiting. Silent hang up is annoying.
s/gave up waiting/did not help/
I noticed yet another problem with this program.
The OOM victim (a child of memory hog process) received SIGKILL at
uptime = 438 and it terminated before uptime = 445 even though
oom_reap_vmas() gave up waiting at uptime = 439. However, the OOM killer
was not invoked again in order to kill the memory hog process before I
gave up waiting at uptime = 679. The OOM killer was needlessly kept
disabled for more than 234 seconds after the OOM victim terminated.
--
[ 438.180596] oom_reaper-test invoked oom-killer: order=0, oom_score_adj=0,
gfp_mask=0x26040c0(GFP_KERNEL|GFP_COMP|GFP_NOTRACK)
[ 438.183524] oom_reaper-test cpuset=/ mems_allowed=0
[ 438.185440] CPU: 0 PID: 13451 Comm: oom_reaper-test Not tainted
4.4.0-rc5-next-20151217+ #248
(...snipped...)
[ 438.301687] Out of memory: Kill process 12679 (oom_reaper-test) score 876 or
sacrifice child
[ 438.304082] Killed process 12680 (oom_reaper-test) total-vm:4324kB,
anon-rss:120kB, file-rss:0kB, shmem-rss:0kB
(...snipped...)
[ 568.185582] MemAlloc: oom_reaper-test(13451) seq=2 gfp=0x26040c0 order=0
delay=7403
[ 568.187593] oom_reaper-test R running task0 13451 8130 0x0080
[ 568.189546] 88007a4cb918 88007a5c4140 88007a4c
88007a4cc000
[ 568.191637] 88007a4cb950 88007fc10240 000100021bb8
81c11730
[ 568.193713] 88007a4cb930 816f5b77 88007fc10240
88007a4cb9d0
[ 568.195798] Call Trace:
[ 568.196878] [] schedule+0x37/0x90
[ 568.198402] [] schedule_timeout+0x117/0x1c0
[ 568.200078] [] ? init_timer_key+0x40/0x40
[ 568.201725] [] schedule_timeout_killable+0x24/0x30
[ 568.203512] [] out_of_memory+0x1f9/0x5a0
[ 568.205144] [] ? out_of_memory+0x2ad/0x5a0
[ 568.206800] [] __alloc_pages_nodemask+0xc43/0xc80
[ 568.208564] [] alloc_pages_current+0x96/0x1b0
[ 568.210259] [] ? new_slab+0x357/0x470
[ 568.211811] [] new_slab+0x3ce/0x470
[ 568.213329] [] ___slab_alloc+0x42a/0x5c0
[ 568.214917] [] ? seq_buf_alloc+0x35/0x40
[ 568.216486] [] ? mem_cgroup_end_page_stat+0x2d/0xb0
[ 568.218240] [] ? __lock_is_held+0x49/0x70
[ 568.219815] [] ? seq_buf_alloc+0x35/0x40
[ 568.221388] [] __slab_alloc+0x4a/0x81
[ 568.222980] [] ? seq_buf_alloc+0x35/0x40
[ 568.224565] [] __kmalloc+0x163/0x1b0
[ 568.226075] [] seq_buf_alloc+0x35/0x40
[ 568.227710] [] seq_read+0x31b/0x3c0
[ 568.229184] [] __vfs_read+0x32/0xf0
[ 568.230673] [] ? security_file_permission+0xa9/0xc0
[ 568.232408] [] ? rw_verify_area+0x4d/0xd0
[ 568.234068] [] vfs_read+0x7a/0x120
[ 568.235561] [] SyS_pread64+0x90/0xb0
[ 568.237062] [] entry_SYSCALL_64_fastpath+0x12/0x76
[ 568.238766] 2 locks held by oom_reaper-test/13451:
[ 568.240188] #0: (>lock){+.+.+.}, at: []
seq_read+0x47/0x3c0
[ 568.242303] #1: (oom_lock){+.+...}, at: []
__alloc_pages_nodemask+0x8a8/0xc80
(...snipped...)
[ 658.711079] MemAlloc: oom_reaper-test(13451) seq=2 gfp=0x26040c0 order=0
delay=180777
[ 658.713110] oom_reaper-test R running task0 13451 8130 0x0080
[ 658.715073] 88007a4cb918 88007a5c4140 88007a4c
88007a4cc000
[ 658.717166] 88007a4cb950 88007fc10240 000100021bb8
81c11730
[ 658.719248] 88007a4cb930 816f5b77 88007fc10240
88007a4cb9d0
[ 658.721345] Call Trace:
[ 658.722426] [] schedule+0x37/0x90
[ 658.723950] [] schedule_timeout+0x117/0x1c0
[ 658.725636] [] ? init_timer_key+0x40/0x40
[ 658.727304] [] schedule_timeout_killable+0x24/0x30
[ 658.729113] [] out_of_memory+0x1f9/0x5a0
[ 658.730757] [] ? out_of_memory+0x2ad/0x5a0
[ 658.732444] [] __alloc_pages_nodemask+0xc43/0xc80
[ 658.734314] [] alloc_pages_current+0x96/0x1b0
[ 658.736041] [] ? new_slab+0x357/0x470
[ 658.737643] [] new_slab+0x3ce/0x470
[ 658.739239] [] ___slab_alloc+0x42a/0x5c0
[ 658.740899] [] ? seq_buf_alloc+0x35/0x40
[ 658.742617] [] ? mem_cgroup_end_page_stat+0x2d/0xb0
[ 658.744489] [] ? __lock_is_held+0x49/0x70
[ 658.746157] [] ? seq_buf_alloc+0x35/0x40
[ 658.747801] [] __slab_alloc+0x4a/0x81
[ 658.749392] [] ? seq_buf_alloc+0x35/0x40
[ 658.751021] [] __kmalloc+0x163/0x1b0
[ 658.752562] [] seq_buf_alloc+0x35/0x40
[ 658.754145] [] seq_read+0x31b/0x3c0
[ 658.755678] [] __vfs_read+0x32/0xf0
[ 658.757194] [] ? security_file_permission+0xa9/0xc0
[ 658.758959] [] ?
Re: [PATCH 01/14] Bluetooth: use list_for_each_entry*
Hi Geliang, > Use list_for_each_entry*() instead of list_for_each*() to simplify > the code. > > Signed-off-by: Geliang Tang > --- > net/bluetooth/af_bluetooth.c | 12 ++-- > net/bluetooth/cmtp/capi.c| 8 ++-- > net/bluetooth/hci_core.c | 8 +++- > net/bluetooth/rfcomm/core.c | 46 ++-- > 4 files changed, 25 insertions(+), 49 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel -- 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] XFS: Use a signed return type for suffix_kstrtoint()
From: Markus Elfring
Date: Sun, 20 Dec 2015 07:56:36 +0100
The return type "unsigned long" was used by the suffix_kstrtoint()
function even though it will eventually return a negative error code.
Improve this implementation detail by using the type "int" instead.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
fs/xfs/xfs_super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 436b6ef..59c9b7b 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -137,7 +137,7 @@ static const match_table_t tokens = {
};
-STATIC unsigned long
+STATIC int
suffix_kstrtoint(char *s, unsigned int base, int *res)
{
int last, shift_left_factor = 0, _res;
--
2.6.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 5/5] futex: Cleanup the goto confusion in requeue_pi()
On Sat, Dec 19, 2015 at 09:15:24PM -0800, Darren Hart wrote: > > As a follow-on, I think it might be worthwhile to create a symmetrical > get_pi_state() to the put_pi_state(), rather than handling the atomic_inc > directly. > > And finally, while the break; in futex_requeue works, that function is quite > long and an explicit out_put_pi_state: label would make the intention clear > and > also avoid inadvertently breaking the implicit behavior of the break. > And while prototyping these changes, I've changed my mind, neither is a worthwhile change. The plist_for_each in futex_requeue really isn't that long and the breaks occur in a logical way and are now well documented with this series. An inadvertent change to this behavior seems unlikely. There is only one open coded atomic_inc in futex.c for the pi_state refcount, hardly worth a wrapper. Regards, -- Darren Hart Intel Open Source Technology Center -- 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 5/5] futex: Cleanup the goto confusion in requeue_pi()
On Sat, 2015-12-19 at 21:15 -0800, Darren Hart wrote: > As a follow-on, I think it might be worthwhile to create a symmetrical > get_pi_state() to the put_pi_state(), rather than handling the atomic_inc > directly. Ditto, immediate thought was future auditors will look for it. -Mike -- 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] futex: Prevent pi_state from double freeing in case of error
On Sat, Dec 19, 2015 at 07:24:38PM +0100, Thomas Gleixner wrote: > - Why are the reviews so sloppy and useless? > >The one I'm answering to is just hillarious and the other one picks >a random commit, claims that it inadvertantly introduced the issue >and is done with it. Really helpful. > > Folks, this is not the way it works. It took me a couple of hours to > get this analyzed properly, but I don't see that anyone involved in > this thread has spent more than a few seconds on it. > > At least I found a real issue related to this refcount stuff, but I > would have preferred that the people involved in this would have found > it in the first place instead of providing half baken crap. > > Yours grumpy > > tglx More care was clearly warranted on my part. I thought I saw the connection with the previous commit I referenced (it wasn't random!), but clearly didn't dig deep enough. My apologies, -- Darren Hart Intel Open Source Technology Center -- 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 v9 0/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs
> -Original Message- > From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Saturday, December 19, 2015 12:21 PM > To: KY Srinivasan > Cc: Jake Oshins ; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; vkuzn...@redhat.com; Haiyang Zhang > ; marc.zyng...@arm.com; > bhelg...@google.com; linux-...@vger.kernel.org > Subject: RE: [PATCH v9 0/7] PCI: hv: New paravirtual PCI front-end for Hyper- > V VMs > > On Sat, 19 Dec 2015, KY Srinivasan wrote: > > > From: Thomas Gleixner [mailto:t...@linutronix.de] > > > On Tue, 15 Dec 2015, KY Srinivasan wrote: > > > > > > > > Of these 7 patches, Greg has committed all of the VMBUS > > > > related supporting patches (3 patches). Thomas, can you > > > > take the IRQ related patches through your tree. > > > > > > That does not make any sense. > > > > > > > > Jake Oshins (7): > > > > > drivers:hv: Export a function that maps Linux CPU num onto Hyper-V > > > > > proc num > > > > > drivers:hv: Export hv_do_hypercall() > > > > > PCI: Make it possible to implement a PCI MSI IRQ Domain in a > module. > > > > > PCI: Add fwnode_handle to pci_sysdata > > > > > PCI: irqdomain: Look up IRQ domain by fwnode_handle > > > > > drivers:hv: Define the channel type of Hyper-V PCI Express > > > > > pass-through > > > > > PCI: hv: New paravirtual PCI front-end for Hyper-V VMs > > > > > > That series cannot be ripped apart. The PCI part does not even compile > > > w/o the drivers/hv part in place. > > > > What I was proposing was that after you pick up the hv related patches in > > Greg's tree in the next cycle, would you be willing to take the IRQ related > > patches through your tree. Sorry for the confusion. > > You mean: PCI: Make it possible to implement a PCI MSI IRQ Domain in a > module. > > Right? Aside from the misleading subject line, I can pick that one > up. The rest wants to go through the PCI tree. That is what I meant. Thanks Thomas. K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/5] futex: Cleanup the goto confusion in requeue_pi()
On Sat, Dec 19, 2015 at 08:07:41PM -, Thomas Gleixner wrote: > out_unlock: does not only drop the locks, it also drops the refcount > on the pi_state. Really intuitive. > > Move the label after the put_pi_state() call and use 'break' in the > error handling path of the requeue loop. > > Signed-off-by: Thomas Gleixner > --- > kernel/futex.c |5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1842,20 +1842,21 @@ static int futex_requeue(u32 __user *uad >*/ > this->pi_state = NULL; > put_pi_state(pi_state); > - goto out_unlock; > + break; > } > } > requeue_futex(this, hb1, hb2, ); > drop_count++; > } > > -out_unlock: > /* >* We took an extra initial reference to the pi_state either >* in futex_proxy_trylock_atomic() or in lookup_pi_state(). We >* need to drop it here again. >*/ > put_pi_state(pi_state); > + > +out_unlock: > double_unlock_hb(hb1, hb2); > wake_up_q(_q); > hb_waiters_dec(hb2); Thanks for catching the leak Thomas, sorry I missed it :-/ I thought you missed one point early on shortly after retry_private: where we goto out_unlock, but we haven't claimed the pi_state yet - so this appears to have been another unnecessary (harmless) put_pi_state call previously. For the series: Reviewed-by: Darren Hart As a follow-on, I think it might be worthwhile to create a symmetrical get_pi_state() to the put_pi_state(), rather than handling the atomic_inc directly. And finally, while the break; in futex_requeue works, that function is quite long and an explicit out_put_pi_state: label would make the intention clear and also avoid inadvertently breaking the implicit behavior of the break. Thanks, -- Darren Hart Intel Open Source Technology Center -- 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] README: remove LILO
Remove LILO from the README in order to keep the booting section agnostic. LILO development has also officially stopped. Signed-off-by: Diego Viola --- README | 36 ++-- 1 file changed, 10 insertions(+), 26 deletions(-) diff --git a/README b/README index f4756ee..460c555 100644 --- a/README +++ b/README @@ -253,9 +253,9 @@ COMPILING the kernel: Please note that you can still run a.out user programs with this kernel. - - Do a "make" to create a compressed kernel image. It is also - possible to do "make install" if you have lilo installed to suit the - kernel makefiles, but you may want to check your particular lilo setup first. + - Do a "make" to create a compressed kernel image. It is also possible to do + "make install" if your bootloader is configured to suit the kernel makefiles, + but you may want to check your particular setup first. To do the actual install, you have to be root, but none of the normal build should require that. Don't take the name of root in vain. @@ -292,29 +292,13 @@ COMPILING the kernel: image (e.g. .../linux/arch/i386/boot/bzImage after compilation) to the place where your regular bootable kernel is found. - - Booting a kernel directly from a floppy without the assistance of a - bootloader such as LILO, is no longer supported. - - If you boot Linux from the hard drive, chances are you use LILO, which - uses the kernel image as specified in the file /etc/lilo.conf. The - kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or - /boot/bzImage. To use the new kernel, save a copy of the old image - and copy the new image over the old one. Then, you MUST RERUN LILO - to update the loading map!! If you don't, you won't be able to boot - the new kernel image. - - Reinstalling LILO is usually a matter of running /sbin/lilo. - You may wish to edit /etc/lilo.conf to specify an entry for your - old kernel image (say, /vmlinux.old) in case the new one does not - work. See the LILO docs for more information. - - After reinstalling LILO, you should be all set. Shutdown the system, - reboot, and enjoy! - - If you ever need to change the default root device, video mode, - ramdisk size, etc. in the kernel image, use the 'rdev' program (or - alternatively the LILO boot options when appropriate). No need to - recompile the kernel to change these parameters. + The kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or + /boot/bzImage. To use the new kernel, save a copy of the old image and copy + the new image over the old one. + + You may wish to edit your bootloader config to add an entry for your old + kernel image (say, /vmlinux.old) in case the new one does not work. Refer to + your bootloader documentation for specific options. - Reboot with the new kernel and enjoy. -- 2.6.4 -- 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] sc16is7xx: fix incorrect register bits macro
In datasheet, Modem Status Register MSR[4-7] reflect the modem pins CTS/DSR/RI/CD signal state. Signed-off-by: Wills Wang --- drivers/tty/serial/sc16is7xx.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index edb5305..9d18c24 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -196,14 +196,14 @@ * or (IO6) * - only on 75x/76x */ -#define SC16IS7XX_MSR_CTS_BIT (1 << 0) /* CTS */ -#define SC16IS7XX_MSR_DSR_BIT (1 << 1) /* DSR (IO4) +#define SC16IS7XX_MSR_CTS_BIT (1 << 4) /* CTS */ +#define SC16IS7XX_MSR_DSR_BIT (1 << 5) /* DSR (IO4) * - only on 75x/76x */ -#define SC16IS7XX_MSR_RI_BIT (1 << 2) /* RI (IO7) +#define SC16IS7XX_MSR_RI_BIT (1 << 6) /* RI (IO7) * - only on 75x/76x */ -#define SC16IS7XX_MSR_CD_BIT (1 << 3) /* CD (IO6) +#define SC16IS7XX_MSR_CD_BIT (1 << 7) /* CD (IO6) * - only on 75x/76x */ #define SC16IS7XX_MSR_DELTA_MASK 0x0F /* Any of the delta bits! */ @@ -240,7 +240,7 @@ /* IOControl register bits (Only 750/760) */ #define SC16IS7XX_IOCONTROL_LATCH_BIT (1 << 0) /* Enable input latching */ -#define SC16IS7XX_IOCONTROL_GPIO_BIT (1 << 1) /* Enable GPIO[7:4] */ +#define SC16IS7XX_IOCONTROL_MODEM_BIT (1 << 1) /* Enable GPIO[7:4] as modem pins */ #define SC16IS7XX_IOCONTROL_SRESET_BIT (1 << 3) /* Software Reset */ /* EFCR register bits */ @@ -674,7 +674,7 @@ static void sc16is7xx_port_irq(struct sc16is7xx_port *s, int portno) case SC16IS7XX_IIR_CTSRTS_SRC: msr = sc16is7xx_port_read(port, SC16IS7XX_MSR_REG); uart_handle_cts_change(port, - !!(msr & SC16IS7XX_MSR_CTS_BIT)); + !!(msr & SC16IS7XX_MSR_DCTS_BIT)); break; case SC16IS7XX_IIR_THRI_SRC: sc16is7xx_handle_tx(port); -- 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 0/7][v4] Add OTG support for FSL socs
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Saturday, October 10, 2015 3:04 AM > To: Mehresh Ramneek-B31383 ; linux- > ker...@vger.kernel.org > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- > u...@vger.kernel.org; Mehresh Ramneek-B31383 > > Subject: Re: [PATCH 0/7][v4] Add OTG support for FSL socs > > Felipe Balbi writes: > > > Hi, > > > > Ramneek Mehresh writes: > >> Add support for otg for all freescale socs having internal usb phy. > >> > >> Ramneek Mehresh (7): > >> usb:fsl:otg: Make fsl otg driver as tristate > >> usb:fsl:otg: Add controller version based ULPI and UTMI phy > >> usb:fsl:otg: Add support to add/remove usb host driver > >> usb:fsl:otg: Signal host drv when host is otg > >> usb:fsl:otg: Modify otg_event to start host drv > >> usb:fsl:otg: Combine host/gadget start/resume for ID change > >> usb:fsl:otg: Add host-gadget drv sync delay > > > > Unless Alan's okay with the host side changes, I can't accept any of > > these. However, I must say some of the flags you add here already > > exist in some way, shape or form. For example, look at is_b_host flag. > Could you please be more specific...which flag you think that I should remove/I'm re-defining. The flags I'm defining are: have_hcd : defined in fsl specific structure for fsl specific use-case had_hcd: defined in fsl specific structure for fsl specific use-case is_otg : defined in include/linux/usb.h Are you suggesting using otg_port or is_b_host instead of is_otg? As I understand, is_b_host is specifically to check if an otg B device is in host mode...correct? I just need a flag to check if a controller is capable of otg operations? That's why defined "is_otg" flag. Please suggest. > Just saw Alan's reply, still, please have a look at these other flags which > already exist in usbcore today. > > -- > balbi -- 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] devpts: Sensible /dev/ptmx & force newinstance
On December 19, 2015 8:11:50 PM PST, ebied...@xmission.com wrote: >ebied...@xmission.com (Eric W. Biederman) writes: > In that system ptys simply did not work after boot when I tested associating /dev/ptmx with the first mount of the devpts >filesystem. >>> >>> Assuming userspace isn't broken by that patch, is a fixed >association >>> with first mount otherwise an acceptable solution for magic >/dev/ptmx >>> (where /dev/ptmx is not a symlink to /dev/pts/ptmx)? >> >> I do not believe a fixed association with the first mount is an >> acceptable solution for implementing /dev/ptmx in association with >> a change to cause mount of devpts to be an independent filesystem. >> Such an association fails to be backwards compatible with existing >> userspace, and it is extremely fragile. > >Ugh. After reviewing the userspace code that mounts devpts we have >to do use a magic /dev/ptmx to solve the issue we are trying to solve. > >The fragility of detecting the primary system devpts seems solvable. > >CentOS5 and openwrt-15.05 mount devpts, unmount devpts, >then mount devpts again. So a rule of mouting the internal devpts if >it >isn't mounted would work for those. > >CentOS6 uses switch_root and moves it's early mount of devpts onto the >primary root, and then because devpts is also in /etc/fstab tries and >fails to mount devpts once more at the same location. Implying >newinstance will make that mounting devpts twice. That sounds solvable >but I don't see a clean way of detecting that case yet. > >Ugh. > >I am going to pound my head up against what is needed to find the >primary system mount of devpts for a bit more and see if I can solve >that. Otherwise this exercise is pointless. > >Eric Does it matter if it mounts devpts twice? It seems like a waste of a minuscule amount of memory, and nothing else. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting. -- 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] devpts: Sensible /dev/ptmx & force newinstance
ebied...@xmission.com (Eric W. Biederman) writes: >>> In that system ptys simply did not work after boot when I tested >>> associating /dev/ptmx with the first mount of the devpts filesystem. >> >> Assuming userspace isn't broken by that patch, is a fixed association >> with first mount otherwise an acceptable solution for magic /dev/ptmx >> (where /dev/ptmx is not a symlink to /dev/pts/ptmx)? > > I do not believe a fixed association with the first mount is an > acceptable solution for implementing /dev/ptmx in association with > a change to cause mount of devpts to be an independent filesystem. > Such an association fails to be backwards compatible with existing > userspace, and it is extremely fragile. Ugh. After reviewing the userspace code that mounts devpts we have to do use a magic /dev/ptmx to solve the issue we are trying to solve. The fragility of detecting the primary system devpts seems solvable. CentOS5 and openwrt-15.05 mount devpts, unmount devpts, then mount devpts again. So a rule of mouting the internal devpts if it isn't mounted would work for those. CentOS6 uses switch_root and moves it's early mount of devpts onto the primary root, and then because devpts is also in /etc/fstab tries and fails to mount devpts once more at the same location. Implying newinstance will make that mounting devpts twice. That sounds solvable but I don't see a clean way of detecting that case yet. Ugh. I am going to pound my head up against what is needed to find the primary system mount of devpts for a bit more and see if I can solve that. Otherwise this exercise is pointless. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] Fix INT1 Recursion with unregistered breakpoints
Please consider the attached patch.
SUMMARY
This patch corrects a hard lockup failure of the system kernel if the
operating system receives a breakpoint exception at a code execution
address which was not registered with the operating system. The patch
allows kernel debuggers, application profiling and performance modules,
and external debugging tools to work better together at sharing the
breakpoint registers on the platform in a way that they do not cause
errors and system faults, and enables the full feature set in the
breakpoint API. If a kernel application triggers a breakpoint
or programs one in error, this patch will catch the condition and report
it to the system log without the operating system experiencing a system
fault. There are several consumers of the Linux Breakpoint API and all
of them can and sometimes do cause the condition this patch corrects.
CONDITIONS WHICH RESULT IN THIS SYSTEM FAULT
This system fault can be caused from several sources. Any kernel code
can access the debug registers and trigger a breakpoint directly by
writing to these registers and trigger a hard system hang if no
breakpoint was registered via arch_install_hw_breakpoint().
kgdb/kdb and the perf event system both present garbage status in dr6
then subsequently write this status into the thread.debugreg6 variable,
then in some cases call hw_breakpoint_restore() which writes this
status back into the dr6 hardware register.
arch/x86/kernel/kgdb.c
static void kgdb_hw_overflow_handler(struct perf_event *event,
struct perf_sample_data *data, struct pt_regs *regs)
{
struct task_struct *tsk = current;
int i;
for (i = 0; i < 4; i++)
if (breakinfo[i].enabled)
tsk->thread.debugreg6 |= (DR_TRAP0 << i);
}
arch/x86/kernel/kgdb.c
static void kgdb_correct_hw_break(void)
{
... snip ...
if (!dbg_is_early)
hw_breakpoint_restore();
... snip ...
}
arch/x86/kernel/hw_breakpoint.c
void hw_breakpoint_restore(void)
{
set_debugreg(__this_cpu_read(cpu_debugreg[0]), 0);
set_debugreg(__this_cpu_read(cpu_debugreg[1]), 1);
set_debugreg(__this_cpu_read(cpu_debugreg[2]), 2);
set_debugreg(__this_cpu_read(cpu_debugreg[3]), 3);
set_debugreg(current->thread.debugreg6, 6);
set_debugreg(__this_cpu_read(cpu_dr7), 7);
}
The hardware only altars those bits that change, the rest of the altered
dr6 value remains in the register.
Upon the next int1 exception, dr6 presents this manufactured status to
the int1 handler in hw_breakpoint.c which calls the non-existent
breakpoint exceptions and any handlers which may have validly
registered, creating phantom events. If other subsystems which call
the perf handlers also have breakpoints registered, this
manufactured status causes erroneous events to be signaled to the layers
above.
arch/x86/kernel/hw_breakpoint.c
static int hw_breakpoint_handler(struct die_args *args)
{
... snip ...
/* Handle all the breakpoints that were triggered */
for (i = 0; i < HBP_NUM; ++i) {
if (likely(!(dr6 & (DR_TRAP0 << i
continue;
... snip ...
perf_bp_event(bp, args->regs);
... snip ...
}
After a few iterations of this cycling through the system, the
thread.debugreg6 variable starts to resemble a random number generator
as far as to which breakpoint just occurred.
The perf handlers cause a different incarnation of this problem and
create the situation by triggering a stale breakpoint set in dr7 for
which the perf bp is NULL (not registered) or late and for which there
is a single code path that fails to set the resume flag and clear the
int1 exception status.
TESTING AND REVIEW PERFORMED
I have reviewed all the code that touches this patch and have
determined it will function and support all of the software that
depends on this handler properly. I have compiled and tested this
patch with a test harness that tests the robustness of the linux
breakpoint API and handlers in the following ways:
1. Setting multiple conditional breakpoints through
arch_install_hw_breakpoint API across four processors to test the rate
at which the interface can handle breakpoint exceptions
2. Setting unregistered breakpoints to test the handlers robustness
in dealing with error handling conditions and errant or spurious
hardware conditions and to simulate actual "lazy debug register
switching" with null bp handlers to test the
robustness of the handlers.
3. Clearing and setting breakpoints across multiple processors then
triggering concurrent exceptions in both interrupt and process
contexts.
This patch improves robustness in several ways in the linux kernel:
1. Corrects bug in handling unregistered breakpoints.
2. Provides hardware check of dr7 to determine source of breakpoint
if OS cannot ascertain the int1 source from its own state
Re: [PATCH v2 2/2] mfd: arizona: Update binding docs for selecting mono/stereo outputs
On Mon, Dec 14, 2015 at 10:19:12AM +, Charles Keepax wrote: > Update the device tree binding documentation to include the wlf,out-mono > property that is used to specify whether each output is a mono or stereo > output. > > Signed-off-by: Charles Keepax > --- > > Changes since v1: > - Clarify which outputs correspond to which entry in the out-mono list. > > Thanks, > Charles > > Documentation/devicetree/bindings/mfd/arizona.txt | 6 ++ > 1 file changed, 6 insertions(+) Acked-by: Rob Herring -- 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 v5] rtc: support DS1302 RTC on ICP DAS LP-8x4x
On Tue, Dec 15, 2015 at 08:45:23PM +0300, Sergei Ianovich wrote:
Nothing in this is specific to ICP, so the subject should be updated.
> Signed-off-by: Sergei Ianovich
> CC: Alexandre Belloni
> ---
>v4..v5
>* drop THIS_MODULE from struct platform driver
>* use "dallas" for vendor name per vendor-prefixes.txt
>
>v3..v4
>* move DTS bindings to a different patch
>
>v2..v3
>* use usleep_range instead of custom nsleep
>* number change (07/16 -> 09/21)
>
>v0..v2
>* use device tree
>* use devm helpers where possible
>
> .../devicetree/bindings/rtc/rtc-ds1302.txt | 14 +++
> drivers/rtc/Kconfig| 2 +-
> drivers/rtc/rtc-ds1302.c | 100
> -
> 3 files changed, 113 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> new file mode 100644
> index 000..810613b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> @@ -0,0 +1,14 @@
> +* Dallas Semiconductor DS-1302 RTC
> +
> +Simple device which could be used to store date/time between reboots.
> +
> +Required properties:
> +- compatible : Should be "dallas,rtc-ds1302"
> +- reg : Should be address and size of IO memory region
This device is a SPI (or SPI like?) interface. So you have some sort of
of FPGA logic in between the cpu and ds1302. The DT should have a node
for the controller and then the ds1302 as a child of it. A full blown
SPI driver may be overkill here, but that's a separate discussion from
the DT binding.
Rob
> +
> +Examples:
> +
> +rtc@4090 {
> + compatible = "dallas,rtc-ds1302";
> + reg = <0x1700901c 0x1>;
> +};
--
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 v3 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY
On Tue, Dec 15, 2015 at 02:46:08PM +0530, Kishon Vijay Abraham I wrote: > Deprecate using phy-omap-control driver to power on/off the PHY, > and use *syscon* framework to do the same. This handles > powering on/off the PHY for the USB2 PHYs used in various TI SoCs. > > Signed-off-by: Kishon Vijay Abraham I > --- > Documentation/devicetree/bindings/phy/ti-phy.txt |8 +- > drivers/phy/phy-omap-usb2.c | 94 > ++ > include/linux/phy/omap_usb.h | 23 ++ > 3 files changed, 107 insertions(+), 18 deletions(-) > > diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt > b/Documentation/devicetree/bindings/phy/ti-phy.txt > index 49e5b0c..a3b3945 100644 > --- a/Documentation/devicetree/bindings/phy/ti-phy.txt > +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt > @@ -31,6 +31,8 @@ OMAP USB2 PHY > > Required properties: > - compatible: Should be "ti,omap-usb2" > +Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY > +in DRA7x The 2nd instance is different somehow? Rob -- 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 v3 7/9] phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY
On Tue, Dec 15, 2015 at 02:46:06PM +0530, Kishon Vijay Abraham I wrote: > Deprecate using phy-omap-control driver to set PCS value of the PHY > and start using *syscon* API to do the same. > > Signed-off-by: Kishon Vijay Abraham I > Acked-by: Roger Quadros > --- > Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++ > drivers/phy/phy-ti-pipe3.c | 34 > +- > 2 files changed, 35 insertions(+), 1 deletion(-) Acked-by: Rob Herring -- 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] devicetree: mxsfb: add reset-active property
On Tue, Dec 15, 2015 at 05:24:56PM +, Mans Rullgard wrote: > Some boards connect the LCD_RESET pin to a reset input on the > display panel. On these boards, this pin must be set to the > proper level for the display to function. > > This adds an optional "reset-active" property to the "display" > subnode such that devicetrees can specify the desired polarity > of the LCD_RESET pin. > > Signed-off-by: Mans Rullgard Acked-by: Rob Herring -- 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 v3 6/9] phy: ti-pipe3: use *syscon* framework API to power on/off the PHY
On Tue, Dec 15, 2015 at 02:46:05PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to power on/off the PHY and
> use *syscon* framework to do the same.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bindings/phy/ti-phy.txt | 10 ++-
> drivers/phy/phy-ti-pipe3.c | 90
> ++
> 2 files changed, 85 insertions(+), 15 deletions(-)
For the binding:
Acked-by: Rob Herring
One comment on the driver though.
[...]
> --- a/drivers/phy/phy-ti-pipe3.c
> +++ b/drivers/phy/phy-ti-pipe3.c
[...]
> @@ -144,18 +155,53 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3
> *phy);
>
> static int ti_pipe3_power_off(struct phy *x)
> {
> + u32 val;
> + int ret;
> struct ti_pipe3 *phy = phy_get_drvdata(x);
>
> - omap_control_phy_power(phy->control_dev, 0);
> + if (phy->phy_power_syscon) {
Writing this as:
if (!phy->phy_power_syscon) {
...
return 0;
}
//regmap code
will make it simpler to remove the deprecated code later.
> + val = PIPE3_PHY_TX_RX_POWEROFF <<
> + PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
> +
> + ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
> + PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
> + if (ret < 0)
> + return ret;
> + } else {
> + omap_control_phy_power(phy->control_dev, 0);
> + }
>
> return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] irqchip: add documentation for TS-4800 interrupt controller
On Fri, Dec 18, 2015 at 02:39:18PM -0500, Damien Riegel wrote: > This is an interrupt-controller implemented in an FPGA, to multiplex > interrupts generated from other IPs. The FPGA usually uses a GPIO as a > parent interrupt controller to notify that one of the multiplexed > interrupts has triggered. > > Signed-off-by: Damien Riegel > --- > .../bindings/interrupt-controller/technologic,ts4800.txt | 16 > > 1 file changed, 16 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt Acked-by: Rob Herring -- 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] can: sja1000: add documentation for Technologic Systems version
On Fri, Dec 18, 2015 at 03:17:24PM -0500, Damien Riegel wrote: > This commit adds documentation for the Technologic Systems version of > SJA1000. The difference with the NXP version is in the way the registers > are accessed. > > Signed-off-by: Damien Riegel > --- > Documentation/devicetree/bindings/net/can/sja1000.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/net/can/sja1000.txt > b/Documentation/devicetree/bindings/net/can/sja1000.txt > index b4a6d53..7a158d5 100644 > --- a/Documentation/devicetree/bindings/net/can/sja1000.txt > +++ b/Documentation/devicetree/bindings/net/can/sja1000.txt > @@ -2,7 +2,7 @@ Memory mapped SJA1000 CAN controller from NXP (formerly > Philips) > > Required properties: > > -- compatible : should be "nxp,sja1000". > +- compatible : should be one of "nxp,sja1000", "technologic,sja1000". > > - reg : should specify the chip select, address offset and size required > to map the registers of the SJA1000. The size is usually 0x80. > @@ -14,6 +14,7 @@ Optional properties: > > - reg-io-width : Specify the size (in bytes) of the IO accesses that > should be performed on the device. Valid value is 1, 2 or 4. > + Must be set to 2 for technologic version. > Default to 1 (8 bits). Really, this should default to 2 for technologic version and not be required. Rob -- 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 v5] mtd: support BB SRAM on ICP DAS LP-8x4x
On Tue, Dec 15, 2015 at 09:58:53PM +0300, Sergei Ianovich wrote:
> This provides an MTD device driver for 512kB of battery backed up SRAM
> on ICPDAS LP-8X4X programmable automation controllers.
>
> SRAM chip is connected via FPGA and is not accessible without a driver,
> unlike flash memory which is wired to CPU MMU.
>
> This SRAM becomes an excellent persisent storage of volatile process
> data like counter values and sensor statuses. Storing those data in
> flash or mmc card is not a viable solution.
>
> Signed-off-by: Sergei Ianovich
> Reviewed-by: Brian Norris
> ---
>v4..v5
>* remove .owner from struct platform_driver
>* constify struct of_device_id
> for further Brian Norris comments:
>* drop unused property from doc file
>* move defconfig update to a different file
>* drop extra match w/ of_match_device()
>
>v3..v4 for Brian Norris 'Reviewed-by'
>* add doc file for DT binding
>* move DTS binding to a different patch (8/21)
>* drop unused include directive
>* drop safely unused callback
>* drop non-default partion probe types
>* drop duplicate error checks
>* drop duplicate error reporting
>* fixed error message on MTD registeration
>* fixed module removal routine
>
>v2..v3
>* no changes (except number 08/16 -> 10/21)
>
>v0..v2
>* use device tree
>* use devm helpers where possible
>
> .../devicetree/bindings/mtd/sram-lp8x4x.txt| 20 +++
> drivers/mtd/devices/Kconfig| 14 ++
> drivers/mtd/devices/Makefile | 1 +
> drivers/mtd/devices/sram_lp8x4x.c | 199
> +
> 4 files changed, 234 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> create mode 100644 drivers/mtd/devices/sram_lp8x4x.c
>
> diff --git a/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> b/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> new file mode 100644
> index 000..476934f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> @@ -0,0 +1,20 @@
> +512kB battery backed up SRAM on LP-8x4x industrial computers
> +
> +Required properties:
> +- compatible : should be "icpdas,sram-lp8x4x"
No wildcards please. Otherwise looks fine.
> +
> +- reg: physical base addresses and region lengths of
> + * IO memory range
> + * SRAM page selector
> +
> +SRAM chip is connected via FPGA and is not accessible without a driver,
> +unlike flash memory which is wired to CPU MMU. Driver is essentially
> +an address translation routine.
> +
> +Example:
> +
> + sram@a000 {
> + compatible = "icpdas,sram-lp8x4x";
> + reg = <0xa000 0x1000
> +0x901e 0x1>;
> + };
--
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 v5] Fix INT1 Recursion with unregistered breakpoints
> /* > + * Check if we got an execute breakpoint, if so > + * set the resume flag to avoid int1 recursion. > + */ > + if ((dr7 & (DR_RW_MASK << ((i * DR_CONTROL_SIZE) + > + DR_CONTROL_SHIFT))) == DR_RW_EXECUTE) > + args->regs->flags |= X86_EFLAGS_RF; > + > + /* This patch is functionaly correct but I still need to make it perfect. I more try and test run. I tested this and it works, but I need to shift it the other way (right) rather than (left) since DR_RW_EXECUTE is always 0 this will always work but to be perfect I need to do: if (((dr7 >> ((i * DR_CONTROL_SIZE) + DR_CONTROL_SHIFT)) & DR_RW_MASK) == DR_RW_EXECUTE) and that is perfect syntax. Jeff -- 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 v5] Fix INT1 Recursion with unregistered breakpoints
Please consider the attached patch.
SUMMARY
This patch corrects a hard lockup failure of the system kernel if the
operating system receives a breakpoint exception at a code execution
address which was not registered with the operating system. The patch
allows kernel debuggers, application profiling and performance modules,
and external debugging tools to work better together at sharing the
breakpoint registers on the platform in a way that they do not cause
errors and system faults, and enables the full feature set in the
breakpoint API. If a kernel application triggers a breakpoint
or programs one in error, this patch will catch the condition and report
it to the system log without the operating system experiencing a system
fault. There are several consumers of the Linux Breakpoint API and all
of them can and sometimes do cause the condition this patch corrects.
CONDITIONS WHICH RESULT IN THIS SYSTEM FAULT
This system fault can be caused from several sources. Any kernel code
can access the debug registers and trigger a breakpoint directly by
writing to these registers and trigger a hard system hang if no
breakpoint was registered via arch_install_hw_breakpoint().
kgdb/kdb and the perf event system both present garbage status in dr6
then subsequently write this status into the thread.debugreg6 variable,
then in some cases call hw_breakpoint_restore() which writes this
status back into the dr6 hardware register.
arch/x86/kernel/kgdb.c
static void kgdb_hw_overflow_handler(struct perf_event *event,
struct perf_sample_data *data, struct pt_regs *regs)
{
struct task_struct *tsk = current;
int i;
for (i = 0; i < 4; i++)
if (breakinfo[i].enabled)
tsk->thread.debugreg6 |= (DR_TRAP0 << i);
}
arch/x86/kernel/kgdb.c
static void kgdb_correct_hw_break(void)
{
... snip ...
if (!dbg_is_early)
hw_breakpoint_restore();
... snip ...
}
arch/x86/kernel/hw_breakpoint.c
void hw_breakpoint_restore(void)
{
set_debugreg(__this_cpu_read(cpu_debugreg[0]), 0);
set_debugreg(__this_cpu_read(cpu_debugreg[1]), 1);
set_debugreg(__this_cpu_read(cpu_debugreg[2]), 2);
set_debugreg(__this_cpu_read(cpu_debugreg[3]), 3);
set_debugreg(current->thread.debugreg6, 6);
set_debugreg(__this_cpu_read(cpu_dr7), 7);
}
The hardware only altars those bits that change, the rest of the altered
dr6 value remains in the register.
Upon the next int1 exception, dr6 presents this manufactured status to
the int1 handler in hw_breakpoint.c which calls the non-existent
breakpoint exceptions and any handlers which may have validly
registered, creating phantom events. If other subsystems which call
the perf handlers also have breakpoints registered, this
manufactured status causes erroneous events to be signaled to the layers
above.
arch/x86/kernel/hw_breakpoint.c
static int hw_breakpoint_handler(struct die_args *args)
{
... snip ...
/* Handle all the breakpoints that were triggered */
for (i = 0; i < HBP_NUM; ++i) {
if (likely(!(dr6 & (DR_TRAP0 << i
continue;
... snip ...
perf_bp_event(bp, args->regs);
... snip ...
}
After a few iterations of this cycling through the system, the
thread.debugreg6 variable starts to resemble a random number generator
as far as to which breakpoint just occurred.
The perf handlers cause a different incarnation of this problem and
create the situation by triggering a stale breakpoint set in dr7 for
which the perf bp is NULL (not registered) or late and for which there
is a single code path that fails to set the resume flag and clear the
int1 exception status.
TESTING AND REVIEW PERFORMED
I have reviewed all the code that touches this patch and have
determined it will function and support all of the software that
depends on this handler properly. I have compiled and tested this
patch with a test harness that tests the robustness of the linux
breakpoint API and handlers in the following ways:
1. Setting multiple conditional breakpoints through
arch_install_hw_breakpoint API across four processors to test the rate
at which the interface can handle breakpoint exceptions
2. Setting unregistered breakpoints to test the handlers robustness
in dealing with error handling conditions and errant or spurious
hardware conditions and to simulate actual "lazy debug register
switching" with null bp handlers to test the
robustness of the handlers.
3. Clearing and setting breakpoints across multiple processors then
triggering concurrent exceptions in both interrupt and process
contexts.
This patch improves robustness in several ways in the linux kernel:
1. Corrects bug in handling unregistered breakpoints.
2. Provides hardware check of dr7 to determine source of breakpoint
if OS cannot ascertain the int1 source from its own state
Re: [Propose] Isolate core_pattern in mnt namespace.
On 12/20/2015 10:37 AM, Al Viro wrote: On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern is a kernel wide setting, not belongs to a container. So we want to add core_pattern into mnt namespace. What do you think about it? Hi Eric, I found your patch about "net: Implement the per network namespace sysctl infrastructure", I want to do the similar thing in mnt namespace. Is that suggested way? Why mnt namespace and not something else? Hi Al, Well, because core_pattern indicates the path to store core file. In different mnt namespace, we would like to change the path with different value. In addition, Let's considering other namespaces: UTS ns: contains informations of kernel and arch, not proper for core_pattern. IPC ns: communication informations, not proper for core_pattern PID ns: core_pattern is not related with pid net ns: obviousely no. user ns: not proper too. Then I believe it's better to do this in mnt namespace. of course, core_pattern is just one example. After this infrastructure finished, we can implement more sysctls as per-mnt if necessary, I think. Al, what do you think about this idea? Yang . -- 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 18/43] MAINTAINERS: add kdbus
On Sat, Dec 19, 2015 at 04:23:51PM -0800, Greg KH wrote: > On Sat, Dec 19, 2015 at 10:10:24AM +0800, Fengguang Wu wrote: > > On Fri, Dec 18, 2015 at 07:33:36AM -0800, Greg KH wrote: > > > On Fri, Dec 18, 2015 at 03:51:41PM +0800, Fengguang Wu wrote: > > > > CC: Greg Kroah-Hartman > > > > Signed-off-by: Fengguang Wu > > > > --- > > > > MAINTAINERS | 10 ++ > > > > 1 file changed, 10 insertions(+) > > > > > > > > --- linux.orig/MAINTAINERS 2015-12-18 15:43:28.229016896 +0800 > > > > +++ linux/MAINTAINERS 2015-12-18 15:43:28.229016896 +0800 > > > > @@ -6005,6 +6005,16 @@ S: Maintained > > > > F: Documentation/kbuild/kconfig-language.txt > > > > F: scripts/kconfig/ > > > > > > > > +KDBUS > > > > +M: Greg Kroah-Hartman > > > > +T: git > > > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git kdbus > > > > +S: Supported > > > > +F: ipc/kdbus/ > > > > +F: Documentation/kdbus/ > > > > +F: samples/kdbus/ > > > > +F: tools/testing/selftests/kdbus/ > > > > +F: include/uapi/linux/kdbus.h > > > > > > What is this patch for? I didn't send this or create this entry, why > > > did you? > > > > Greg, that is necessary for the 0day email testing feature. After > > adding the above information, when someone posted patch modifying the > > listed kdbus files, the robot will know to apply the patch to your > > char-misc/kdbus branch for testing. > > There is no char-misc/kdbus anymore, please do a 'git pull --prune' to > delete branches that get removed. And even if there was, that old > branch did have a MAINTAINERS entry in it... Ah got it. Sorry, then this patch should be dropped. Regards, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] fs: make devpts/inode.c explicitly non-modular
[Re: [PATCH 7/8] fs: make devpts/inode.c explicitly non-modular] On 17/12/2015 (Thu 11:46) Peter Hurley wrote: > Hi Paul, > > On 12/17/2015 11:11 AM, Paul Gortmaker wrote: > > The Kconfig currently controlling compilation of this code is: > > > > config UNIX98_PTYS > > bool "Unix98 PTY support" if EXPERT > > > > ...meaning that it currently is not being built as a module by anyone. > > > > Lets remove the couple traces of modularity so that when reading the > > driver there is no doubt it is builtin-only. > > > > Since module_init translates to device_initcall in the non-modular > > case, the init ordering gets bumped to one level earlier when we > > use the more appropriate fs_initcall here. However we've made similar > > changes before without any fallout and none is expected here either. > > There's a slim possibility moving the devpts init up to fs level > (where it belongs) may impact certain broken userspace setups, since the > system devpts instance would now always be mounted before initramfs. > > I'm still waiting to receive a reply back from Eric Biederman about > that userspace configuration, so I don't have a definitive answer on > whether this patch will break that setup. I did not see any problems when using what amounts to using a pretty standard Ubuntu rootfs. Let me know if there is some other user space situation I should be looking at. And thanks for the basic ack that generally overall we should be using the initlevels we created that obviously map to where certain things belong, like fs in this case. Paul. -- > > Regards, > Peter Hurley > > > Cc: Al Viro > > Cc: Andrew Morton > > Cc: Peter Hurley > > Cc: Josh Triplett > > Cc: David Howells > > Signed-off-by: Paul Gortmaker > > --- > > fs/devpts/inode.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c > > index c35ffdc12bba..3c89b1f0804f 100644 > > --- a/fs/devpts/inode.c > > +++ b/fs/devpts/inode.c > > @@ -12,7 +12,6 @@ > > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > > > -#include > > #include > > #include > > #include > > @@ -703,4 +702,4 @@ static int __init init_devpts_fs(void) > > } > > return err; > > } > > -module_init(init_devpts_fs) > > +fs_initcall(init_devpts_fs) > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] Fix INT1 Recursion with unregistered breakpoints
On 12/19/15, Jeff Merkey wrote: > On 12/19/15, Jeff Merkey wrote: >> On 12/19/15, Mike Galbraith wrote: >>> On Sat, 2015-12-19 at 19:13 -0700, Jeff Merkey wrote: >>> @@ -519,6 +528,18 @@ static int hw_breakpoint_handler(struct die_args *args) (dr6 & (~DR_TRAP_BITS))) rc = NOTIFY_DONE; + /* + * if we are about to signal to + * do_debug() to stop further processing + * and we have not ascertained the source + * of the breakpoint, log it as spurious. + */ >>> >>> Ahem... >>> >>> >>> >> >> It matches the comments in the other section os code. So what is >> wrong with this. The rest of the file uses the exact same comment >> style. >> >> Please help me with this. >> >> Jeff >> > > OK. Somethings fritzed with how my emails are getting sent. I just > create this, tested it, > and it applies PERFECTLY to my git clone. Let me go back and try again. > > Throw this one away. try try again. > > Jeff > I sent v4 and its appears to be right. Jeff -- 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: [Propose] Isolate core_pattern in mnt namespace.
On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: > On 12/17/2015 07:23 PM, Dongsheng Yang wrote: > >Hi guys, > > We are working on making core dump behaviour isolated in > >container. But the problem is, the /proc/sys/kernel/core_pattern > >is a kernel wide setting, not belongs to a container. > > > > So we want to add core_pattern into mnt namespace. What > >do you think about it? > > Hi Eric, > I found your patch about "net: Implement the per network namespace > sysctl infrastructure", I want to do the similar thing > in mnt namespace. Is that suggested way? Why mnt namespace and not something else? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] Fix INT1 Recursion with unregistered breakpoints
On 12/19/15, Jeff Merkey wrote: > On 12/19/15, Mike Galbraith wrote: >> On Sat, 2015-12-19 at 19:13 -0700, Jeff Merkey wrote: >> >>> @@ -519,6 +528,18 @@ static int hw_breakpoint_handler(struct die_args >>> *args) >>> (dr6 & (~DR_TRAP_BITS))) >>> rc = NOTIFY_DONE; >>> >>> + /* >>> + * if we are about to signal to >>> + * do_debug() to stop further processing >>> + * and we have not ascertained the source >>> + * of the breakpoint, log it as spurious. >>> + */ >> >> Ahem... >> >> >> > > It matches the comments in the other section os code. So what is > wrong with this. The rest of the file uses the exact same comment > style. > > Please help me with this. > > Jeff > OK. Somethings fritzed with how my emails are getting sent. I just create this, tested it, and it applies PERFECTLY to my git clone. Let me go back and try again. Throw this one away. try try again. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] Fix INT1 Recursion with unregistered breakpoints
On 12/19/15, Mike Galbraith wrote: > On Sat, 2015-12-19 at 19:13 -0700, Jeff Merkey wrote: > >> @@ -519,6 +528,18 @@ static int hw_breakpoint_handler(struct die_args >> *args) >> (dr6 & (~DR_TRAP_BITS))) >> rc = NOTIFY_DONE; >> >> +/* >> +* if we are about to signal to >> +* do_debug() to stop further processing >> +* and we have not ascertained the source >> +* of the breakpoint, log it as spurious. >> +*/ > > Ahem... > > > It matches the comments in the other section os code. So what is wrong with this. The rest of the file uses the exact same comment style. Please help me with this. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] Fix INT1 Recursion with unregistered breakpoints
On Sat, 2015-12-19 at 19:13 -0700, Jeff Merkey wrote: > @@ -519,6 +528,18 @@ static int hw_breakpoint_handler(struct die_args > *args) > (dr6 & (~DR_TRAP_BITS))) > rc = NOTIFY_DONE; > > + /* > + * if we are about to signal to > + * do_debug() to stop further processing > + * and we have not ascertained the source > + * of the breakpoint, log it as spurious. > + */ Ahem... -- 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: [Propose] Isolate core_pattern in mnt namespace.
On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern is a kernel wide setting, not belongs to a container. So we want to add core_pattern into mnt namespace. What do you think about it? Hi Eric, I found your patch about "net: Implement the per network namespace sysctl infrastructure", I want to do the similar thing in mnt namespace. Is that suggested way? Thanx Yang Yang -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nvmem: delete unneeded IS_ERR test
Hi Julia, Thanks to check this, but there was a patch fixing it.:-) 在 2015年12月20日 05:19, Julia Lawall 写道: devm_kzalloc returns NULL rather than an ERR_PTR value. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x,e; @@ * x = devm_kzalloc(...) ... when != x = e * IS_ERR(x) // Signed-off-by: Julia Lawall --- drivers/nvmem/rockchip-efuse.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c index f552134..811c73c 100644 --- a/drivers/nvmem/rockchip-efuse.c +++ b/drivers/nvmem/rockchip-efuse.c @@ -136,8 +136,8 @@ static int rockchip_efuse_probe(struct platform_device *pdev) context = devm_kzalloc(dev, sizeof(struct rockchip_efuse_context), GFP_KERNEL); - if (IS_ERR(context)) - return PTR_ERR(context); + if (!context) + return -ENOMEM; Fixed in this patch[0]. patch[0]: https://patchwork.kernel.org/patch/7842821/ Thanks, Caesar clk = devm_clk_get(dev, "pclk_efuse"); if (IS_ERR(clk)) ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- 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/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller
Hello Sascha,
On Fri, Dec 18, 2015 at 08:16:33AM +0100, Sascha Hauer wrote:
> On Thu, Dec 17, 2015 at 11:23:31AM -0800, Eduardo Valentin wrote:
> > On Wed, Dec 16, 2015 at 07:23:22PM +0800, Daniel Kurtz wrote:
> > > On Mon, Nov 30, 2015 at 7:42 PM, Sascha Hauer
> > > wrote:
> > > > +Example:
> > > > +
> > > > + thermal: thermal@1100b000 {
> > > > + #thermal-sensor-cells = <1>;
> > >
> > > Tiny nit: this should now be:
> > >
> > > #thermal-sensor-cells = <0>;
> >
> >
> > This is actually not so tiny'shy. Why does this driver masks out all
> > sensors available? Why don't we expose all of them and use id property
> > to expose and identify each of them?
>
> This has been the case until v9 of this series. It was requested by
> Mediatek that the CPU frequency regulation works better when the maximum
> of all sensors is taken instead of only single sensors. We decided to
> expose the maximum of all sensors in the device tree. IN the end it will
> be easier to add additional sensors should we need them later than it is
> to get rid of sensors we don't need.
Apologize as I completely missed this transition from v9 to v10. In
fact, I really cannot understand the benefit of having such constraint
implemented in the driver. In device tree you can mark a thermal zone as
status disabled and it won't appear in your system.
One can select which sensors / thermal zones are required. And even
reuse same dtsi, and change status on dts per board.
The combination of the above, with the possibility to select the maximum
from thermal core / sysfs, would be bring much more flexibility for a
system engineer, than having the maximum coded in the driver, because,
well, changing that relation would require changing the code. If you
keep the driver as simple as possible, changing the this setup later
would be as simple as changing the dts(i).
What do you think?
BR,
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 v4] Fix INT1 Recursion with unregistered breakpoints
Please consider the attached patch.
SUMMARY
This patch corrects a hard lockup failure of the system kernel if the
operating system receives a breakpoint exception at a code execution
address which was not registered with the operating system. The patch
allows kernel debuggers, application profiling and performance modules,
and external debugging tools to work better together at sharing the
breakpoint registers on the platform in a way that they do not cause
errors and system faults, and enables the full feature set in the
breakpoint API. If a kernel application triggers a breakpoint
or programs one in error, this patch will catch the condition and report
it to the system log without the operating system experiencing a system
fault. There are several consumers of the Linux Breakpoint API and all
of them can and sometimes do cause the condition this patch corrects.
CONDITIONS WHICH RESULT IN THIS SYSTEM FAULT
This system fault can be caused from several sources. Any kernel code
can access the debug registers and trigger a breakpoint directly by
writing to these registers and trigger a hard system hang if no
breakpoint was registered via arch_install_hw_breakpoint().
kgdb/kdb and the perf event system both present garbage status in dr6
then subsequently write this status into the thread.debugreg6 variable,
then in some cases call hw_breakpoint_restore() which writes this
status back into the dr6 hardware register.
arch/x86/kernel/kgdb.c
static void kgdb_hw_overflow_handler(struct perf_event *event,
struct perf_sample_data *data, struct pt_regs *regs)
{
struct task_struct *tsk = current;
int i;
for (i = 0; i < 4; i++)
if (breakinfo[i].enabled)
tsk->thread.debugreg6 |= (DR_TRAP0 << i);
}
arch/x86/kernel/kgdb.c
static void kgdb_correct_hw_break(void)
{
... snip ...
if (!dbg_is_early)
hw_breakpoint_restore();
... snip ...
}
arch/x86/kernel/hw_breakpoint.c
void hw_breakpoint_restore(void)
{
set_debugreg(__this_cpu_read(cpu_debugreg[0]), 0);
set_debugreg(__this_cpu_read(cpu_debugreg[1]), 1);
set_debugreg(__this_cpu_read(cpu_debugreg[2]), 2);
set_debugreg(__this_cpu_read(cpu_debugreg[3]), 3);
set_debugreg(current->thread.debugreg6, 6);
set_debugreg(__this_cpu_read(cpu_dr7), 7);
}
The hardware only altars those bits that change, the rest of the altered
dr6 value remains in the register.
Upon the next int1 exception, dr6 presents this manufactured status to
the int1 handler in hw_breakpoint.c which calls the non-existent
breakpoint exceptions and any handlers which may have validly
registered, creating phantom events. If other subsystems which call
the perf handlers also have breakpoints registered, this
manufactured status causes erroneous events to be signaled to the layers
above.
arch/x86/kernel/hw_breakpoint.c
static int hw_breakpoint_handler(struct die_args *args)
{
... snip ...
/* Handle all the breakpoints that were triggered */
for (i = 0; i < HBP_NUM; ++i) {
if (likely(!(dr6 & (DR_TRAP0 << i
continue;
... snip ...
perf_bp_event(bp, args->regs);
... snip ...
}
After a few iterations of this cycling through the system, the
thread.debugreg6 variable starts to resemble a random number generator
as far as to which breakpoint just occurred.
The perf handlers cause a different incarnation of this problem and
create the situation by triggering a stale breakpoint set in dr7 for
which the perf bp is NULL (not registered) or late and for which there
is a single code path that fails to set the resume flag and clear the
int1 exception status.
TESTING AND REVIEW PERFORMED
I have reviewed all the code that touches this patch and have
determined it will function and support all of the software that
depends on this handler properly. I have compiled and tested this
patch with a test harness that tests the robustness of the linux
breakpoint API and handlers in the following ways:
1. Setting multiple conditional breakpoints through
arch_install_hw_breakpoint API across four processors to test the rate
at which the interface can handle breakpoint exceptions
2. Setting unregistered breakpoints to test the handlers robustness
in dealing with error handling conditions and errant or spurious
hardware conditions and to simulate actual "lazy debug register
switching" with null bp handlers to test the
robustness of the handlers.
3. Clearing and setting breakpoints across multiple processors then
triggering concurrent exceptions in both interrupt and process
contexts.
This patch improves robustness in several ways in the linux kernel:
1. Corrects bug in handling unregistered breakpoints.
2. Provides hardware check of dr7 to determine source of breakpoint
if OS cannot ascertain the int1 source from its own state
Re: [PATCH] serial: atmel: remove module device table
[[PATCH] serial: atmel: remove module device table] On 18/12/2015 (Fri 15:49)
Arnd Bergmann wrote:
> A recent patch removed most of the module-specific code from the atmel
> serial driver, but left the MODULE_DEVICE_TABLE in place, so we can't
> build it any more:
>
> drivers/tty/serial/atmel_serial.c:192:1: error: type defaults to 'int' in
> declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int]
> drivers/tty/serial/atmel_serial.c:192:1: warning: parameter names (without
> types) in function declaration
>
> This removes the table as well to avoid the error.
I sent the same fix on Thursday. Again, sorry that my testing did
not uncover this earlier. I was build testing for ARM on almost a daily
basis but not so regularly for MIPS.
http://lkml.kernel.org/r/1450364746-815-1-git-send-email-paul.gortma...@windriver.com
Paul.
--
>
> Signed-off-by: Arnd Bergmann
> Fixes: c39dfebc7798 ("drivers/tty/serial: make serial/atmel_serial.c
> explicitly non-modular")
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index 50e785a0ea73..1c0884d8ef32 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -188,8 +188,6 @@ static const struct of_device_id atmel_serial_dt_ids[] = {
> { .compatible = "atmel,at91sam9260-usart" },
> { /* sentinel */ }
> };
> -
> -MODULE_DEVICE_TABLE(of, atmel_serial_dt_ids);
> #endif
>
> static inline struct atmel_uart_port *
>
--
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] sc16is7xx: fix incorrect register bits macro
On Sat, Dec 19, 2015 at 07:20:06PM +0800, Wills Wang wrote: > In datasheet, Modem Status Register MSR[4-5] reflect the modem pins > CTS/DSR/RI/CD signal state. > > Signed-off-by: Wills Wang > --- > drivers/tty/serial/sc16is7xx.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c > index edb5305..9d18c24 100644 > --- a/drivers/tty/serial/sc16is7xx.c > +++ b/drivers/tty/serial/sc16is7xx.c > @@ -196,14 +196,14 @@ > * or (IO6) > * - only on 75x/76x > */ > -#define SC16IS7XX_MSR_CTS_BIT(1 << 0) /* CTS */ > -#define SC16IS7XX_MSR_DSR_BIT(1 << 1) /* DSR (IO4) > +#define SC16IS7XX_MSR_CTS_BIT(1 << 4) /* CTS */ > +#define SC16IS7XX_MSR_DSR_BIT(1 << 5) /* DSR (IO4) BIT(4) BIT(5)? Please do that at the same time... thanks, 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/
[GIT PULL] TTY/Serial fixes for 4.4-rc6
The following changes since commit 527e9316f8ec44bd53d90fb9f611fa752bb9: Linux 4.4-rc4 (2015-12-06 15:43:12 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.4-rc6 for you to fetch changes up to 9ce119f318ba1a07c29149301f1544b6c4bea52a: tty: Fix GPF in flush_to_ldisc() (2015-12-12 23:05:28 -0800) TTY/Serial fixes for 4.4-rc6 Here are some tty/serial driver fixes for 4.4-rc6 that resolve some reported problems. All of these have been in linux-next. The details are in the shortlog. Signed-off-by: Greg Kroah-Hartman Geert Uytterhoeven (1): serial: earlycon: Add missing spinlock initialization Masahiro Yamada (1): serial: 8250_uniphier: fix dl_read and dl_write functions Peter Hurley (2): n_tty: Fix poll() after buffer-limited eof push read tty: Fix GPF in flush_to_ldisc() Yoshihiro Shimoda (1): serial: sh-sci: Fix length of scatterlist drivers/tty/n_tty.c | 22 +- drivers/tty/serial/8250/8250_uniphier.c | 8 ++-- drivers/tty/serial/earlycon.c | 2 ++ drivers/tty/serial/sh-sci.c | 2 +- drivers/tty/tty_buffer.c| 2 +- 5 files changed, 19 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] USB driver fixes for 4.4-rc6
The following changes since commit 9f9499ae8e6415cefc4fe0a96ad0e27864353c89: Linux 4.4-rc5 (2015-12-13 17:42:58 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.4-rc6 for you to fetch changes up to e50293ef9775c5f1cf3fcc093037dd6a8c5684ea: USB: fix invalid memory access in hub_activate() (2015-12-18 09:30:34 -0800) USB fixes for 4.4-rc6 Here are some USB and PHY fixes for 4.4-rc6. All of them resolve some reported problems. Full details in the shortlog. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): USB: fix invalid memory access in hub_activate() Arnd Bergmann (1): phy: sun9i-usb: add USB dependency Chunfeng Yun (1): phy: core: Get a refcount to phy in devm_of_phy_get_by_index() Dan Carpenter (1): USB: ipaq.c: fix a timeout loop Greg Kroah-Hartman (1): Merge tag 'phy-for-4.4-rc' of git://git.kernel.org/.../kishon/linux-phy into usb-linus Julia Lawall (7): phy: brcmstb-sata: add missing of_node_put phy: mt65xx-usb3: add missing of_node_put phy: berlin-sata: add missing of_node_put phy: rockchip-usb: add missing of_node_put phy: miphy28lp: add missing of_node_put phy: miphy365x: add missing of_node_put phy: cygnus: pcie: add missing of_node_put drivers/phy/Kconfig | 1 + drivers/phy/phy-bcm-cygnus-pcie.c | 16 drivers/phy/phy-berlin-sata.c | 20 ++-- drivers/phy/phy-brcmstb-sata.c| 17 - drivers/phy/phy-core.c| 21 +++-- drivers/phy/phy-miphy28lp.c | 16 +++- drivers/phy/phy-miphy365x.c | 16 +++- drivers/phy/phy-mt65xx-usb3.c | 20 +--- drivers/phy/phy-rockchip-usb.c| 17 - drivers/usb/core/hub.c| 22 +++--- drivers/usb/serial/ipaq.c | 3 ++- 11 files changed, 122 insertions(+), 47 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] perf test 21("Test object code reading") failure on ARM64
On Sat, Dec 19, 2015 at 11:04:21AM +0800, xiakaixu wrote:
>
> >>>...
> >
> > Hi,
> >
> > What is your objdump version?
>
> Hi,
>
> Sorry for the late reply.
>
> # objdump --version
> GNU objdump (GNU Binutils) 2.25.
>
> I am sure that the system is Little endian.
> >
I have attached a patch if you care to try it with your setup.
If it still fails, output from -v and last objdump command output
would be helpful.
Regards,
Jan
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index a767a6400c5c..faf726865fac 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -33,44 +33,83 @@ static unsigned int hex(char c)
return c - 'A' + 10;
}
-static size_t read_objdump_line(const char *line, size_t line_len, void *buf,
- size_t len)
+static size_t read_objdump_chunk(const char **line, unsigned char **buf,
+size_t *buf_len)
+{
+ size_t bytes_read = 0;
+ unsigned char *chunk_start = *buf;
+
+ /* Read bytes */
+ while (*buf_len > 0) {
+ char c1, c2;
+
+ /* Get 2 hex digits */
+ c1 = *(*line)++;
+ if (!isxdigit(c1))
+ break;
+ c2 = *(*line)++;
+ if (!isxdigit(c2))
+ break;
+
+ /* Store byte and advance buf */
+ **buf = (hex(c1) << 4) | hex(c2);
+ (*buf)++;
+ (*buf_len)--;
+ bytes_read++;
+
+ /* End of chunk? */
+ if (isspace(**line))
+ break;
+ }
+
+ /*
+* objdump will display raw insn as LE if code endian
+* is LE and bytes_per_chunk > 1. In that case reverse
+* the chunk we just read.
+*/
+ if (bytes_read > 1 && !bigendian()) {
+ unsigned char *chunk_end = chunk_start + bytes_read - 1;
+ unsigned char tmp;
+
+ while (chunk_start < chunk_end) {
+ tmp = *chunk_start;
+ *chunk_start = *chunk_end;
+ *chunk_end = tmp;
+ chunk_start++;
+ chunk_end--;
+ }
+ }
+
+ return bytes_read;
+}
+
+static size_t read_objdump_line(const char *line, unsigned char *buf,
+ size_t buf_len)
{
const char *p;
- size_t i, j = 0;
+ size_t ret, bytes_read = 0;
/* Skip to a colon */
p = strchr(line, ':');
if (!p)
return 0;
- i = p + 1 - line;
+ p++;
- /* Read bytes */
- while (j < len) {
- char c1, c2;
-
- /* Skip spaces */
- for (; i < line_len; i++) {
- if (!isspace(line[i]))
- break;
- }
- /* Get 2 hex digits */
- if (i >= line_len || !isxdigit(line[i]))
- break;
- c1 = line[i++];
- if (i >= line_len || !isxdigit(line[i]))
- break;
- c2 = line[i++];
- /* Followed by a space */
- if (i < line_len && line[i] && !isspace(line[i]))
+ /* Skip initial spaces */
+ while (*p) {
+ if (!isspace(*p))
break;
- /* Store byte */
- *(unsigned char *)buf = (hex(c1) << 4) | hex(c2);
- buf += 1;
- j++;
+ p++;
}
+
+ do {
+ ret = read_objdump_chunk(, , _len);
+ bytes_read += ret;
+ p++;
+ } while (ret > 0);
+
/* return number of successfully read bytes */
- return j;
+ return bytes_read;
}
static int read_objdump_output(FILE *f, void *buf, size_t *len, u64 start_addr)
@@ -95,7 +134,7 @@ static int read_objdump_output(FILE *f, void *buf, size_t
*len, u64 start_addr)
}
/* read objdump data into temporary buffer */
- read_bytes = read_objdump_line(line, ret, tmp, sizeof(tmp));
+ read_bytes = read_objdump_line(line, tmp, sizeof(tmp));
if (!read_bytes)
continue;
@@ -152,7 +191,7 @@ static int read_via_objdump(const char *filename, u64 addr,
void *buf,
ret = read_objdump_output(f, buf, , addr);
if (len) {
- pr_debug("objdump read too few bytes\n");
+ pr_debug("objdump read too few bytes: %lu\n", len);
if (!ret)
ret = len;
}
Re: [PATCH 18/43] MAINTAINERS: add kdbus
On Sat, Dec 19, 2015 at 10:10:24AM +0800, Fengguang Wu wrote: > On Fri, Dec 18, 2015 at 07:33:36AM -0800, Greg KH wrote: > > On Fri, Dec 18, 2015 at 03:51:41PM +0800, Fengguang Wu wrote: > > > CC: Greg Kroah-Hartman > > > Signed-off-by: Fengguang Wu > > > --- > > > MAINTAINERS | 10 ++ > > > 1 file changed, 10 insertions(+) > > > > > > --- linux.orig/MAINTAINERS2015-12-18 15:43:28.229016896 +0800 > > > +++ linux/MAINTAINERS 2015-12-18 15:43:28.229016896 +0800 > > > @@ -6005,6 +6005,16 @@ S: Maintained > > > F: Documentation/kbuild/kconfig-language.txt > > > F: scripts/kconfig/ > > > > > > +KDBUS > > > +M: Greg Kroah-Hartman > > > +T: git > > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git kdbus > > > +S: Supported > > > +F: ipc/kdbus/ > > > +F: Documentation/kdbus/ > > > +F: samples/kdbus/ > > > +F: tools/testing/selftests/kdbus/ > > > +F: include/uapi/linux/kdbus.h > > > > What is this patch for? I didn't send this or create this entry, why > > did you? > > Greg, that is necessary for the 0day email testing feature. After > adding the above information, when someone posted patch modifying the > listed kdbus files, the robot will know to apply the patch to your > char-misc/kdbus branch for testing. There is no char-misc/kdbus anymore, please do a 'git pull --prune' to delete branches that get removed. And even if there was, that old branch did have a MAINTAINERS entry in it... thanks, 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/
[PATCH] ARM64: Improve copy_page for 128 cache line sizes.
Adding a check for the cache line size is not much overhead. Special case 128 byte cache line size. This improves copy_page by 85% on ThunderX compared to the original implementation. For LMBench, it improves between 4-10%. Signed-off-by: Andrew Pinski --- arch/arm64/lib/copy_page.S | 39 +++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S index 512b9a7..4c28789 100644 --- a/arch/arm64/lib/copy_page.S +++ b/arch/arm64/lib/copy_page.S @@ -18,6 +18,7 @@ #include #include #include +#include /* * Copy a page from src to dest (both are page aligned) @@ -27,8 +28,17 @@ * x1 - src */ ENTRY(copy_page) + /* Special case 128 byte or more cache lines */ + mrs x2, ctr_el0 + lsr x2, x2, CTR_CWG_SHIFT + and w2, w2, CTR_CWG_MASK + cmp w2, 5 + b.ge2f + /* Assume cache line size is 64 bytes. */ prfmpldl1strm, [x1, #64] + /* Align the loop is it fits in one cache line. */ + .balign 64 1: ldp x2, x3, [x1] ldp x4, x5, [x1, #16] ldp x6, x7, [x1, #32] @@ -43,4 +53,33 @@ ENTRY(copy_page) tst x1, #(PAGE_SIZE - 1) b.ne1b ret + +2: + /* The cache line size is at least 128 bytes. */ + prfmpldl1strm, [x1, #128] + /* Align the loop so it fits in one cache line */ + .balign 128 +1: prfmpldl1strm, [x1, #256] + ldp x2, x3, [x1] + ldp x4, x5, [x1, #16] + ldp x6, x7, [x1, #32] + ldp x8, x9, [x1, #48] + stnpx2, x3, [x0] + stnpx4, x5, [x0, #16] + stnpx6, x7, [x0, #32] + stnpx8, x9, [x0, #48] + + ldp x2, x3, [x1, #64] + ldp x4, x5, [x1, #80] + ldp x6, x7, [x1, #96] + ldp x8, x9, [x1, #112] + add x1, x1, #128 + stnpx2, x3, [x0, #64] + stnpx4, x5, [x0, #80] + stnpx6, x7, [x0, #96] + stnpx8, x9, [x0, #112] + add x0, x0, #128 + tst x1, #(PAGE_SIZE - 1) + b.ne1b + ret ENDPROC(copy_page) -- 1.7.2.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/
Klientskie bazi dannix Mnogo! Bistro! Nedorogo! tel/viber/whatsapp: +79139393506 Skype: prodawez389 Email: mamontova...@gmail.com Yznaite podrobnee!!! Zwonite!!
Klientskie bazi dannix Mnogo! Bistro! Nedorogo! tel/viber/whatsapp: +79139393506 Skype: prodawez389 Email: gmartinov...@gmail.com Yznaite podrobnee!!! Zvonite!!!
Re: [PATCH v2 1/2] crypto: KEYS: convert public key to the akcipher api
Hi Tadeusz,
[auto build test ERROR on crypto/master]
[also build test ERROR on v4.4-rc5 next-20151218]
url:
https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-KEYS-convert-public-key-to-akcipher-api/20151213-103429
base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
master
config: x86_64-randconfig-s4-12200710 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from include/crypto/public_key.h:17:0,
from include/linux/verify_pefile.h:15,
from arch/x86/kernel/kexec-bzimage64.c:22:
include/keys/asymmetric-type.h: In function 'asymmetric_key_ids':
>> include/keys/asymmetric-type.h:74:12: error: dereferencing pointer to
>> incomplete type 'const struct key'
return key->payload.data[asym_key_ids];
^
vim +74 include/keys/asymmetric-type.h
7901c1a8 David Howells 2014-09-16 68
size_t len_1,
7901c1a8 David Howells 2014-09-16 69
const void *val_2,
7901c1a8 David Howells 2014-09-16 70
size_t len_2);
146aa8b1 David Howells 2015-10-21 71 static inline
146aa8b1 David Howells 2015-10-21 72 const struct asymmetric_key_ids
*asymmetric_key_ids(const struct key *key)
146aa8b1 David Howells 2015-10-21 73 {
146aa8b1 David Howells 2015-10-21 @74 return key->payload.data[asym_key_ids];
146aa8b1 David Howells 2015-10-21 75 }
7901c1a8 David Howells 2014-09-16 76
7901c1a8 David Howells 2014-09-16 77 /*
:: The code at line 74 was first introduced by commit
:: 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc KEYS: Merge the type-specific
data with the payload data
:: TO: David Howells
:: CC: David Howells
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
RE: REPLY.
I write to seek your assistance for safe keeping of two military trunk boxes valuable that will be of great benefit to both of us,i will explain further when you respond to my direct Email: captcaseythoree...@r7.com I would appreciate your urgent response. Capt.Casey Thoreen( US ARMY OFFICER CURRENTLY SERVING IN AFGHANISTAN) -- 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 V3] Fix INT1 Recursion with unregistered breakpoints
I cleaned up the areas you identified and I am building and testing the the patch with the debugger test harness. As soon as it passes the build completes and it passes the test harness I will submit v4 of the patch. Jeff On 12/19/15, Thomas Gleixner wrote: > On Mon, 14 Dec 2015, Jeff Merkey wrote: >> +/* >> +* check if we got an execute breakpoint >> +* from the dr7 register. if we did, set >> +* the resume flag to avoid int1 recursion. > > Malformatted comment as any other comment you touched. > >> +*/ >> +if ((dr7 & (3 << ((i * 4) + 16))) == 0) >> +args->regs->flags |= X86_EFLAGS_RF; > > This still uses magic numbers instead of the proper defines. I asked > for that before. > > Thanks, > > tglx > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] serial: rewrite pxa2xx-uart to use 8250_core
Sergei Ianovich writes: > On Sat, 2015-12-19 at 20:31 +0100, Robert Jarzmik wrote: >> Sergei Ianovich writes: >> Thanks for spotting this. This is caused by a change in the latest >> > version of the patch (SERIAL_8250_PXA instead of SERIAL_PXA). This >> > change could be reverted. >> Actually I'm against the revert. >> The name change looks very good to me, please keep it. > > Is it worth adding an error if CONFIG_SERIAL_PXA is defined? I don't think so. > Or is there any other way of preventing this patch launching Linus' "flag > days" as Russel King named it? I must think about it, and test a bit more. Ah and a small hint : if you include back Russell in the conversation, don't forget the double "ll" if you wish him to answer. > I understand that people are afraid of taking this patch. If it starts > causing troubles at runtime, it will be difficult to diagnose. There > will be no console for most people. So it is probably good idea to fail > at boot time. Who are "the people" ? If it's about something already written in a mailing list, please point me to it so that it can help me think about it. >> > > But that can be handled in an subsequent patch to keep your acks >> > > and >> > > reviews. >> > I will respin the patch. Please comment on the acks and reviews. >> > They >> > were made at an earlier version of the patch. That version no longer >> > applies. Can the updated version carry on the flags? >> I don't get you. If you mean keeping CONFIG_SERIAL_8250_PXA, then yes, >> please >> keep it. > > I mean should the patch be re-revied and re-acked? Well it depends on what was since then. If it's a trivial commit message fix or a typo, I don't think it's necessary. If it's the algorithm, the code logic, or even I think you should ask again. For a name change in CONFIG_SERIAL_PXA into CONFIG_SERIAL_8250_PXA (change from v3 to v4), I must admit I don't know. Maybe Kevin or Arnd might give a clue. Cheers. -- Robert -- 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 V3] Fix INT1 Recursion with unregistered breakpoints
On 12/19/15, Thomas Gleixner wrote: > On Mon, 14 Dec 2015, Jeff Merkey wrote: >> +/* >> +* check if we got an execute breakpoint >> +* from the dr7 register. if we did, set >> +* the resume flag to avoid int1 recursion. > > Malformatted comment as any other comment you touched. > >> +*/ >> +if ((dr7 & (3 << ((i * 4) + 16))) == 0) >> +args->regs->flags |= X86_EFLAGS_RF; > > This still uses magic numbers instead of the proper defines. I asked > for that before. > > Thanks, > > tglx > Yes Sir, I'll get that fixed right away. Jeff -- 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: pinctrl-adi2: Use a signed return type for adi_gpio_irq_startup()
>>> This introduces a compile warning. >> >> How do you think about to show the exact message you get? > > I can't actually compile it myself. It seems that I can understand your feedback also a bit better since I received the information from a background process like "kbuild test robot". Will it become acceptable to adjust the data structure "irq_chip" for the variable "adi_gpio_irqchip"? Should I just skip my update suggestion for this specific source code area? http://lxr.free-electrons.com/source/include/linux/irq.h?v=4.3#L320 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/
[GIT PULL REQUEST] md fixes for 4.4-rc
The following changes since commit 9f9499ae8e6415cefc4fe0a96ad0e27864353c89: Linux 4.4-rc5 (2015-12-13 17:42:58 -0800) are available in the git repository at: git://neil.brown.name/md tags/md/4.4-rc5-fixes for you to fetch changes up to cb01c5496d2d9c0c862443561df16ff122db348f: Fix remove_and_add_spares removes drive added as spare in slot_store (2015-12-18 15:19:16 +1100) 4 fixes for md in 4.4-rc5 - 2 recently introduced regressions fixed. - one older bug in RAID10 - tagged for -stable since 4.2 - one minor sysfs api improvement. Artur Paszkiewicz (1): md/raid10: fix data corruption and crash during resync Goldwyn Rodrigues (1): Fix remove_and_add_spares removes drive added as spare in slot_store Mikulas Patocka (1): md: fix bug due to nested suspend Shaohua Li (1): MD: change journal disk role to disk 0 drivers/md/md.c | 22 +++--- drivers/md/md.h | 8 ++-- drivers/md/raid10.c | 4 +++- 3 files changed, 24 insertions(+), 10 deletions(-) signature.asc Description: PGP signature
Re: [PATCH] mm, oom: initiallize all new zap_details fields before use
On 12/19/2015 02:52 PM, Kirill A. Shutemov wrote: > On Fri, Dec 18, 2015 at 08:04:51PM -0500, Sasha Levin wrote: >> > Commit "mm, oom: introduce oom reaper" forgot to initialize the two new >> > fields >> > of struct zap_details in unmap_mapping_range(). This caused using stack >> > garbage >> > on the call to unmap_mapping_range_tree(). >> > >> > Signed-off-by: Sasha Levin >> > --- >> > mm/memory.c |1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/mm/memory.c b/mm/memory.c >> > index 206c8cd..0e32993 100644 >> > --- a/mm/memory.c >> > +++ b/mm/memory.c >> > @@ -2431,6 +2431,7 @@ void unmap_mapping_range(struct address_space >> > *mapping, >> >details.last_index = hba + hlen - 1; >> >if (details.last_index < details.first_index) >> >details.last_index = ULONG_MAX; >> > + details.check_swap_entries = details.ignore_dirty = false; > Should we use c99 initializer instead to make it future-proof? I didn't do that to make these sort of failures obvious. In this case, if we would have used an initializer and it would default to the "wrong" values it would be much harder to find this bug. 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/
Re: [PATCH] pinctrl-adi2: Use a signed return type for adi_gpio_irq_startup()
Hi Markus,
[auto build test WARNING on pinctrl/for-next]
[also build test WARNING on v4.4-rc5 next-20151218]
url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/pinctrl-adi2-Use-a-signed-return-type-for-adi_gpio_irq_startup/20151220-010253
base:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
for-next
config: blackfin-CM-BF548_defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All warnings (new ones prefixed by >>):
>> drivers/pinctrl/pinctrl-adi2.c:584:2: warning: initialization from
>> incompatible pointer type [enabled by default]
drivers/pinctrl/pinctrl-adi2.c:584:2: warning: (near initialization for
'adi_gpio_irqchip.irq_startup') [enabled by default]
vim +584 drivers/pinctrl/pinctrl-adi2.c
e9a03add Sonic Zhang 2013-09-03 568request >>= 1;
e9a03add Sonic Zhang 2013-09-03 569}
e9a03add Sonic Zhang 2013-09-03 570
e9a03add Sonic Zhang 2013-09-03 571if (!umask)
e9a03add Sonic Zhang 2013-09-03 572chained_irq_exit(chip, desc);
e9a03add Sonic Zhang 2013-09-03 573 }
e9a03add Sonic Zhang 2013-09-03 574
e9a03add Sonic Zhang 2013-09-03 575 static struct irq_chip adi_gpio_irqchip =
{
e9a03add Sonic Zhang 2013-09-03 576.name = "GPIO",
e9a03add Sonic Zhang 2013-09-03 577.irq_ack = adi_gpio_ack_irq,
e9a03add Sonic Zhang 2013-09-03 578.irq_mask = adi_gpio_mask_irq,
e9a03add Sonic Zhang 2013-09-03 579.irq_mask_ack = adi_gpio_mask_ack_irq,
e9a03add Sonic Zhang 2013-09-03 580.irq_unmask = adi_gpio_unmask_irq,
e9a03add Sonic Zhang 2013-09-03 581.irq_disable = adi_gpio_mask_irq,
e9a03add Sonic Zhang 2013-09-03 582.irq_enable = adi_gpio_unmask_irq,
e9a03add Sonic Zhang 2013-09-03 583.irq_set_type = adi_gpio_irq_type,
e9a03add Sonic Zhang 2013-09-03 @584.irq_startup = adi_gpio_irq_startup,
e9a03add Sonic Zhang 2013-09-03 585.irq_shutdown = adi_gpio_irq_shutdown,
e9a03add Sonic Zhang 2013-09-03 586.irq_set_wake = adi_gpio_set_wake,
e9a03add Sonic Zhang 2013-09-03 587 };
e9a03add Sonic Zhang 2013-09-03 588
e9a03add Sonic Zhang 2013-09-03 589 static int adi_get_groups_count(struct
pinctrl_dev *pctldev)
e9a03add Sonic Zhang 2013-09-03 590 {
e9a03add Sonic Zhang 2013-09-03 591struct adi_pinctrl *pinctrl =
pinctrl_dev_get_drvdata(pctldev);
e9a03add Sonic Zhang 2013-09-03 592
:: The code at line 584 was first introduced by commit
:: e9a03add0c6ed5341fc59ff9c76843c2888a33fa pinctrl: ADI PIN control driver
for the GPIO controller on bf54x and bf60x.
:: TO: Sonic Zhang
:: CC: Linus Walleij
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v5] serial: support for 16550A serial ports on LP-8x4x
On Tue, 2015-12-15 at 22:51 +0100, Arnd Bergmann wrote:
> On Wednesday 16 December 2015 00:04:45 Sergei Ianovich wrote:
> > +Examples (from pxa27x-lp8x4x.dts):
> > +
> > + uart@9050 {
>
> By convention, the name should be 'serial', not 'uart'.
>
arch/arm/boot/dts/pxa2xx.dtsi uses 'uart'. Should I change the names in
the patch with dts file for LP-8xx?
--
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] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
On Fri, Dec 18, 2015 at 11:34 AM, Vijay Pandurangan wrote:
> Packets that arrive from real hardware devices have ip_summed ==
> CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
> CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
> current version of veth will replace CHECKSUM_NONE with
> CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
> a veth device to be delivered to the application. This caused applications
> at Twitter to receive corrupt data when network hardware was corrupting
> packets.
>
> We believe this was added as an optimization to skip computing and
> verifying checksums for communication between containers. However, locally
> generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
> written does nothing for them. As far as we can tell, after removing this
> code, these packets are transmitted from one stack to another unmodified
> (tcpdump shows invalid checksums on both sides, as expected), and they are
> delivered correctly to applications. We didn’t test every possible network
> configuration, but we tried a few common ones such as bridging containers,
> using NAT between the host and a container, and routing from hardware
> devices to containers. We have effectively deployed this in production at
> Twitter (by disabling RX checksum offloading on veth devices).
>
> This code dates back to the first version of the driver, commit
> ("[NET]: Virtual ethernet device driver"), so I
> suspect this bug occurred mostly because the driver API has evolved
> significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
> packet checksumming") (in December 2010) fixed this for packets that get
> created locally and sent to hardware devices, by not changing
> CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
> in from hardware devices.
>
> Co-authored-by: Evan Jones
> Signed-off-by: Evan Jones
> Cc: Nicolas Dichtel
> Cc: Phil Sutter
> Cc: Toshiaki Makita
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Vijay Pandurangan
Acked-by: Cong Wang
--
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] veth: don't modify ip-summed; doing so treats packets with bad checksums as good.
On Sat, Dec 19, 2015 at 1:01 PM, Cong Wang wrote:
> On Fri, Dec 18, 2015 at 11:42 AM, Vijay Pandurangan wrote:
>> Evan and I have demonstrated this bug on Kubernetes as well, so it's
>> not just a problem in Mesos. (See
>> https://github.com/kubernetes/kubernetes/issues/18898)
>>
>
> Interesting... then this problem is much more serious than I thought.
>
> Looks like in RX path the bridge sets the checksum to CHECKSUM_NONE
> too:
>
> static inline void skb_forward_csum(struct sk_buff *skb)
> {
> /* Unfortunately we don't support this one. Any brave souls? */
> if (skb->ip_summed == CHECKSUM_COMPLETE)
> skb->ip_summed = CHECKSUM_NONE;
> }
>
> I guess this is probably why Docker/Kubernetes could be affected too.
Hmm, no, actually this is due to netem does the software checksum
and sets it to CHECKSUM_NONE:
if (q->corrupt && q->corrupt >= get_crandom(>corrupt_cor)) {
if (!(skb = skb_unshare(skb, GFP_ATOMIC)) ||
(skb->ip_summed == CHECKSUM_PARTIAL &&
skb_checksum_help(skb)))
return qdisc_drop(skb, sch);
skb->data[prandom_u32() % skb_headlen(skb)] ^=
1<<(prandom_u32() % 8);
}
But anyway, your patch still looks correct 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/
[PATCH] nvmem: delete unneeded IS_ERR test
devm_kzalloc returns NULL rather than an ERR_PTR value. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x,e; @@ * x = devm_kzalloc(...) ... when != x = e * IS_ERR(x) // Signed-off-by: Julia Lawall --- drivers/nvmem/rockchip-efuse.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c index f552134..811c73c 100644 --- a/drivers/nvmem/rockchip-efuse.c +++ b/drivers/nvmem/rockchip-efuse.c @@ -136,8 +136,8 @@ static int rockchip_efuse_probe(struct platform_device *pdev) context = devm_kzalloc(dev, sizeof(struct rockchip_efuse_context), GFP_KERNEL); - if (IS_ERR(context)) - return PTR_ERR(context); + if (!context) + return -ENOMEM; clk = devm_clk_get(dev, "pclk_efuse"); if (IS_ERR(clk)) -- 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] devpts: Sensible /dev/ptmx & force newinstance
Peter Hurley writes: > On 12/11/2015 11:40 AM, Eric W. Biederman wrote: >> Forcing newinstance for every mount of the devpts filesystem actually >> requires the association between /dev/ptmx and the currently mounted >> instance of devpts at /dev/pts. Simply remembering the first mount of >> the devpts filesystem and associating that with /dev/ptmx is not >> enough. I am aware of at least one instance where an initramfs mounts >> devpts before the main system instance of devpts is mounted. > > Can you point me to that usage please? I have found that the Dracut versions in CentOS5 and CentOS6 generates initial ramdisks that mount devpts before the primary OS mount of devpts on /dev/pts. I have also found that openwrt-15.05 without an initial ramdisk does something strange during startup and boots devpts twice as well. I have looked but I haven't seen that pattern elsewhere but my search space of 15ish distros is small compared to what is out there. Given that mounting devpts multiple times has been implemented at least twice independently I would not be surprised if mounting devpts multiple times during boot shows up somewhere else. > I ask because there's a patch to move devpts init from module initcall > up to fs initcall (neither devpts nor the pty driver is actually built > as a module anyway), and I'd like to look at what the consequences > might be for that userspace configuration. I don't expect there are any. As all of this happens before userspace initializes anyway.We have enough variation in the kernel anyway that the device number the first devpts is mounted on varies between kernels already. >> In that system ptys simply did not work after boot when I tested >> associating /dev/ptmx with the first mount of the devpts filesystem. > > Assuming userspace isn't broken by that patch, is a fixed association > with first mount otherwise an acceptable solution for magic /dev/ptmx > (where /dev/ptmx is not a symlink to /dev/pts/ptmx)? I do not believe a fixed association with the first mount is an acceptable solution for implementing /dev/ptmx in association with a change to cause mount of devpts to be an independent filesystem. Such an association fails to be backwards compatible with existing userspace, and it is extremely fragile. If the association between the device node and the filesystem in the mount namespace is insufficient for backwards compatibility I do not believe full backwards compatibility is acheivable with a magic version of /dev/ptmx. On the flip side the consequences of a ptmx symlink in devpts pointing to pts/ptmx look extremely minor. Of my test cases only openwrt-15.05 and CentOS5 fail, as they don't use devtmpfs. While debian-6.0.2, debian-7.9, debian-8.2, CentOS6, CentOS7, fedora32, magia-5, mint-17.3, opensuse-42.1, slackware-14.1, unbuntu-14.04.3 and ubuntu-15.10 all work. By making the change in behavior controlled by a kernel command line option (devpts.newinstance is what I have been testing with) that allows me to build a single kernel that works on everything. Which is enough backwards compatibility for me. I still have not quite reached the point of testing what the real world consequences for programs such as lxc that currently use the newinstance option are. There is a possibility that if someone is bind mounting /dev/pts/ptmx over /dev/ptmx they might break. Similarly there may be a few cases do "mknod ptmx c 5 2" and that will start failing. I don't expect running into weird userspace cases that fail will change my opinion on a path forward, but it will be good to know what the consequences are of flipping the option. As so far everything thing looks like it will just work. Right now having a nano-flag day and putting a symlink in devtmps looks a whole lot cleaner in both implementation, maintenance and use than a magic /dev/ptmx. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: xpad - use LED API when identifying wireless controllers
On Wed, 16 Dec 2015 14:44:08 -0800
Dmitry Torokhov wrote:
> When lighting up the segment identifying wireless controller, Instead
> of sending command directly to the controller, let's do it via LED
> API (usinf led_set_brightness) so that LED object state is in sync
> with controller state and we'll light up the correct segment on
> resume as well.
>
> Signed-off-by: Dmitry Torokhov
> ---
>
> I do not have the hardware so please try this out.
>
> drivers/input/joystick/xpad.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/joystick/xpad.c
> b/drivers/input/joystick/xpad.c index 36328b3..00a766b 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -1118,7 +1118,7 @@ static void xpad_send_led_command(struct
> usb_xpad *xpad, int command) */
> static void xpad_identify_controller(struct usb_xpad *xpad)
> {
> - xpad_send_led_command(xpad, (xpad->pad_nr % 4) + 2);
> + led_set_brightness(>led->led_cdev, (xpad->pad_nr % 4)
> + 2); }
>
> static void xpad_led_set(struct led_classdev *led_cdev,
Hi Dimitri,
My hardware: two wireless xpad 360 using a single usb receiver.
Power on the first gamepad => light the "1" led.
Power on the second gamepad => light the "2" led.
Suspend the PC (systemctl suspend): the two gamepads are "disconnected"
=> blinking circle.
Resume the PC, the two gamepads keep blinking but are working (tested
with jstest).
Power off and on the gamepad => still blinking.
Reload (rmmod/modprobe) the xpad module => still blinking.
That said, without your patch, the behavior is exactly the same.
It seems that the suspend/resume broke the led feature. Even using
the /sys/class/leds/xpad0/brigthness sysfs entry does not work.
Best regards,
Clement
--
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] USB-FHCI: Use a signed return type for fhci_create_ep()
On Sat, Dec 19, 2015 at 09:55:02PM +0100, SF Markus Elfring wrote: > > Just make it an int. > > Thanks for your suggestion. > > Will any more software developers prefer this data type > at some source code places? > Use s32 if the hardware spec specifies that you must. Otherwise prefer ordinary types. > > > The caller also casts it to u32... > > Do you want to get rid of similar casts in affected functions? If you want, that would be great. I just enjoy complaining generally, though. :P regards, dan carpenter -- 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] IB/usnic: delete unneeded IS_ERR test
kzalloc doesn't return ERR_PTR, so there is no need to test for it. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x,e; @@ * x = kzalloc(...) ... when != x = e * IS_ERR_OR_NULL(x) // Signed-off-by: Julia Lawall --- drivers/infiniband/hw/usnic/usnic_ib_verbs.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c index f8e3211..20f53e5 100644 --- a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c +++ b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c @@ -625,8 +625,8 @@ struct ib_mr *usnic_ib_reg_mr(struct ib_pd *pd, u64 start, u64 length, virt_addr, length); mr = kzalloc(sizeof(*mr), GFP_KERNEL); - if (IS_ERR_OR_NULL(mr)) - return ERR_PTR(mr ? PTR_ERR(mr) : -ENOMEM); + if (!mr) + return ERR_PTR(-ENOMEM); mr->umem = usnic_uiom_reg_get(to_upd(pd)->umem_pd, start, length, access_flags, 0); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] veth: don't modify ip-summed; doing so treats packets with bad checksums as good.
On Fri, Dec 18, 2015 at 11:42 AM, Vijay Pandurangan wrote:
> Evan and I have demonstrated this bug on Kubernetes as well, so it's
> not just a problem in Mesos. (See
> https://github.com/kubernetes/kubernetes/issues/18898)
>
Interesting... then this problem is much more serious than I thought.
Looks like in RX path the bridge sets the checksum to CHECKSUM_NONE
too:
static inline void skb_forward_csum(struct sk_buff *skb)
{
/* Unfortunately we don't support this one. Any brave souls? */
if (skb->ip_summed == CHECKSUM_COMPLETE)
skb->ip_summed = CHECKSUM_NONE;
}
I guess this is probably why Docker/Kubernetes could be affected too.
--
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] RDS: don't pretend to use cpu notifiers
From: Sebastian Andrzej Siewior
It looks like an attempt to use CPU notifier here which was never
completed. Nobody tried to wire it up completely since 2k9. So I unwind
this code and get rid of everything not required. Oh look! 19 lines were
removed while code still does the same thing.
Acked-by: Santosh Shilimkar
Tested-by: Santosh Shilimkar
Signed-off-by: Sebastian Andrzej Siewior
---
v2:
Test and Ack tag added.
net/rds/page.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/net/rds/page.c b/net/rds/page.c
index 9005a2c..5a14e6d 100644
--- a/net/rds/page.c
+++ b/net/rds/page.c
@@ -179,37 +179,18 @@ out:
}
EXPORT_SYMBOL_GPL(rds_page_remainder_alloc);
-static int rds_page_remainder_cpu_notify(struct notifier_block *self,
-unsigned long action, void *hcpu)
+void rds_page_exit(void)
{
- struct rds_page_remainder *rem;
- long cpu = (long)hcpu;
+ unsigned int cpu;
- rem = _cpu(rds_page_remainders, cpu);
+ for_each_possible_cpu(cpu) {
+ struct rds_page_remainder *rem;
- rdsdebug("cpu %ld action 0x%lx\n", cpu, action);
+ rem = _cpu(rds_page_remainders, cpu);
+ rdsdebug("cpu %u\n", cpu);
- switch (action) {
- case CPU_DEAD:
if (rem->r_page)
__free_page(rem->r_page);
rem->r_page = NULL;
- break;
}
-
- return 0;
-}
-
-static struct notifier_block rds_page_remainder_nb = {
- .notifier_call = rds_page_remainder_cpu_notify,
-};
-
-void rds_page_exit(void)
-{
- int i;
-
- for_each_possible_cpu(i)
- rds_page_remainder_cpu_notify(_page_remainder_nb,
- (unsigned long)CPU_DEAD,
- (void *)(long)i);
}
--
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] USB-FHCI: Use a signed return type for fhci_create_ep()
> Just make it an int. Thanks for your suggestion. Will any more software developers prefer this data type at some source code places? > The caller also casts it to u32... Do you want to get rid of similar casts in affected functions? 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: net, ipv6: out of bounds access in secret_stable
On Fri, Dec 18, 2015 at 5:13 PM, Sasha Levin wrote:
> Hi Hannes,
>
> I've hit the following out of bounds access while fuzzing on the latest -next
> kernel.
>
> This code was added in 3d1bec9932 ("ipv6: introduce secret_stable to
> ipv6_devconf").
>
> [ 459.553655] BUG: KASAN: stack-out-of-bounds in strlen+0x58/0x90 at addr
> 8802ab0efb0e
> [ 459.554953] Read of size 1 by task trinity-c91/22576
> [ 459.555805] page:ea000aac3bc0 count:0 mapcount:0 mapping:
> (null) index:0x0
> [ 459.556899] flags: 0x26f8000()
> [ 459.557521] page dumped because: kasan: bad access detected
> [ 459.558320] CPU: 7 PID: 22576 Comm: trinity-c91 Not tainted
> 4.4.0-rc5-next-20151218-sasha-00021-gaba8d84-dirty #2750
> [ 459.559809] 549d0aa3 8802ab0ef860
> a1042384
> [ 459.561036] 41b58ab3 ac667cdb a10422d9
> 8802ab0ef848
> [ 459.562245] 9f6a417e 549d0aa3 8802ab0efb0e
> 8802ab0efb0e
> [ 459.563429] Call Trace:
> [ 459.563831] dump_stack (lib/dump_stack.c:52)
> [ 459.564623] ? _atomic_dec_and_lock (lib/dump_stack.c:27)
> [ 459.565628] ? __dump_page (mm/debug.c:126)
> [ 459.566538] kasan_report_error (include/linux/kasan.h:28
> mm/kasan/report.c:170 mm/kasan/report.c:237)
> [ 459.570997] __asan_report_load1_noabort (mm/kasan/report.c:277)
> [ 459.572119] ? check_preemption_disabled (lib/smp_processor_id.c:39)
> [ 459.573731] ? strlen (lib/string.c:481 (discriminator 1))
> [ 459.574646] strlen (lib/string.c:481 (discriminator 1))
> [ 459.575485] proc_dostring (kernel/sysctl.c:1825 kernel/sysctl.c:1906)
> [ 459.576445] ? alloc_debug_processing (mm/slub.c:1054)
> [ 459.577523] addrconf_sysctl_stable_secret (net/ipv6/addrconf.c:5395)
Looks like we don't initialize the array on stack for write case.
At least other callers always initialize the data for both read
and write.
Please try the attached patch.
Thanks!
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 17f8e7e..8d4fa7c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5369,13 +5369,11 @@ static int addrconf_sysctl_stable_secret(struct
ctl_table *ctl, int write,
goto out;
}
- if (!write) {
- err = snprintf(str, sizeof(str), "%pI6",
- >secret);
- if (err >= sizeof(str)) {
- err = -EIO;
- goto out;
- }
+ err = snprintf(str, sizeof(str), "%pI6",
+ >secret);
+ if (err >= sizeof(str)) {
+ err = -EIO;
+ goto out;
}
err = proc_dostring(, write, buffer, lenp, ppos);
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/19/2015 4:41 PM, Måns Rullgård wrote: Andy Shevchenko writes: On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote: On 12/19/2015 3:07 PM, Måns Rullgård wrote: Julian Margetson writes: Total pages: 522752 [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg Please add ignore_log_level. Had to truncate the kernel command line to add it. I guess Måns meant 'ignore_loglevel' Obviously. I can never remember where the underscores go. :-) -- 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] x86/signal: Cleanup get_nr_restart_syscall
On Sat, Dec 19, 2015 at 6:43 AM, Dmitry V. Levin wrote: > Check for TS_COMPAT instead of TIF_IA32 to distinguish ia32 tasks > from 64-bit tasks. > Check for __X32_SYSCALL_BIT iff CONFIG_X86_X32_ABI is defined. LGTM. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/2] um: Protect memory mapped file
This series protect the memory mapped file. Changes since v3: * add Tristan Schmelcher's ack Changes since v2; addressed Tristan Schmelcher's comment: * remove the whole fchmod call [1/2] Changes since v1; addressed Richard Weinberger's comments: * add attacker model to the patch description [1/2] * remove errno reset [2/2] Regards, Mickaël Mickaël Salaün (2): um: Do not set unsecure permission for temporary file um: Use race-free temporary file creation arch/um/os-Linux/mem.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) -- 2.6.4 -- 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] USB-FHCI: Use a signed return type for fhci_create_ep()
Hello. On 12/19/2015 11:15 PM, SF Markus Elfring wrote: From: Markus Elfring Date: Sat, 19 Dec 2015 21:10:20 +0100 The return type "u32" was used by the fhci_create_ep() function even though it will eventually return a negative error code. Improve this implementation detail by using the type "s32" instead. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/usb/host/fhci-tds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/fhci-tds.c b/drivers/usb/host/fhci-tds.c index f82ad5d..c1ae172 100644 --- a/drivers/usb/host/fhci-tds.c +++ b/drivers/usb/host/fhci-tds.c @@ -149,7 +149,7 @@ void fhci_ep0_free(struct fhci_usb *usb) * data_mem The data memory partition(BUS) * ring_len TD ring length */ -u32 fhci_create_ep(struct fhci_usb *usb, enum fhci_mem_alloc data_mem, +s32 fhci_create_ep(struct fhci_usb *usb, enum fhci_mem_alloc data_mem, Should be just *int*, I think. [...] MBR, Sergei -- 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: pinctrl-adi2: Use a signed return type for adi_gpio_irq_startup()
On Sat, Dec 19, 2015 at 09:40:27PM +0100, SF Markus Elfring wrote: > > This introduces a compile warning. > > How do you think about to show the exact message you get? > I can't actually compile it myself. > > > These functions are supposed to return 1 if there is an IRQ pending. > > Change the -EINVAL to 0. > > Is there any more source code clean-up needed around the comment "FIXME" > in the affected function? Delete the FIXME comment. regards, dan carpenter -- 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] [media] gsc-m2m: Use an unsigned data type for a variable
On Sat, Dec 19, 2015 at 04:23:11PM +0100, SF Markus Elfring wrote:
> diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
> b/drivers/media/platform/exynos-gsc/gsc-m2m.c
> index d82e717..f2c091c 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
> @@ -701,7 +701,7 @@ static unsigned int gsc_m2m_poll(struct file *file,
> {
> struct gsc_ctx *ctx = fh_to_ctx(file->private_data);
> struct gsc_dev *gsc = ctx->gsc_dev;
> - int ret;
> + unsigned int ret;
>
> if (mutex_lock_interruptible(>lock))
> return -ERESTARTSYS;
I'm suspect returning -ERESTARTSYS is a bug.
regards,
dan carpenter
--
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/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote: >> On 12/19/2015 3:07 PM, Måns Rullgård wrote: >>> Julian Margetson writes: > Total pages: 522752 [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg >>> >>> Please add ignore_log_level. >>> >> Had to truncate the kernel command line to add it. > > I guess Måns meant 'ignore_loglevel' Obviously. I can never remember where the underscores go. -- Måns Rullgård -- 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: pinctrl-adi2: Use a signed return type for adi_gpio_irq_startup()
> This introduces a compile warning. How do you think about to show the exact message you get? > These functions are supposed to return 1 if there is an IRQ pending. > Change the -EINVAL to 0. Is there any more source code clean-up needed around the comment "FIXME" in the affected function? 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: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote: > On 12/19/2015 3:07 PM, Måns Rullgård wrote: >> Julian Margetson writes: >>> Total pages: 522752 >>> [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 >>> console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg >> >> Please add ignore_log_level. >> > Had to truncate the kernel command line to add it. I guess Måns meant 'ignore_loglevel' -- With Best Regards, Andy Shevchenko -- 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/
[tip:x86/urgent] x86/paravirt: Prevent rtc_cmos platform device init on PV guests
Commit-ID: d8c98a1d1488747625ad6044d423406e17e99b7a
Gitweb: http://git.kernel.org/tip/d8c98a1d1488747625ad6044d423406e17e99b7a
Author: David Vrabel
AuthorDate: Fri, 11 Dec 2015 09:07:53 -0500
Committer: Thomas Gleixner
CommitDate: Sat, 19 Dec 2015 21:35:13 +0100
x86/paravirt: Prevent rtc_cmos platform device init on PV guests
Adding the rtc platform device in non-privileged Xen PV guests causes
an IRQ conflict because these guests do not have legacy PIC and may
allocate irqs in the legacy range.
In a single VCPU Xen PV guest we should have:
/proc/interrupts:
CPU0
0: 4934 xen-percpu-virq timer0
1: 0 xen-percpu-ipi spinlock0
2: 0 xen-percpu-ipi resched0
3: 0 xen-percpu-ipi callfunc0
4: 0 xen-percpu-virq debug0
5: 0 xen-percpu-ipi callfuncsingle0
6: 0 xen-percpu-ipi irqwork0
7:321 xen-dyn-event xenbus
8: 90 xen-dyn-event hvc_console
...
But hvc_console cannot get its interrupt because it is already in use
by rtc0 and the console does not work.
genirq: Flags mismatch irq 8. (hvc_console) vs. (rtc0)
We can avoid this problem by realizing that unprivileged PV guests (both
Xen and lguests) are not supposed to have rtc_cmos device and so
adding it is not necessary.
Privileged guests (i.e. Xen's dom0) do use it but they should not have
irq conflicts since they allocate irqs above legacy range (above
gsi_top, in fact).
Instead of explicitly testing whether the guest is privileged we can
extend pv_info structure to include information about guest's RTC
support.
Reported-and-tested-by: Sander Eikelenboom
Signed-off-by: David Vrabel
Signed-off-by: Boris Ostrovsky
Cc: vkuzn...@redhat.com
Cc: xen-de...@lists.xenproject.org
Cc: konrad.w...@oracle.com
Cc: sta...@vger.kernel.org # 4.2+
Link:
http://lkml.kernel.org/r/1449842873-2613-1-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/paravirt.h | 6 ++
arch/x86/include/asm/paravirt_types.h | 5 +
arch/x86/include/asm/processor.h | 1 +
arch/x86/kernel/rtc.c | 3 +++
arch/x86/lguest/boot.c| 1 +
arch/x86/xen/enlighten.c | 4 +++-
6 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 10d0596..c759b3c 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -19,6 +19,12 @@ static inline int paravirt_enabled(void)
return pv_info.paravirt_enabled;
}
+static inline int paravirt_has_feature(unsigned int feature)
+{
+ WARN_ON_ONCE(!pv_info.paravirt_enabled);
+ return (pv_info.features & feature);
+}
+
static inline void load_sp0(struct tss_struct *tss,
struct thread_struct *thread)
{
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index 31247b5..3d44191 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -70,9 +70,14 @@ struct pv_info {
#endif
int paravirt_enabled;
+ unsigned int features;/* valid only if paravirt_enabled is set */
const char *name;
};
+#define paravirt_has(x) paravirt_has_feature(PV_SUPPORTED_##x)
+/* Supported features */
+#define PV_SUPPORTED_RTC(1<<0)
+
struct pv_init_ops {
/*
* Patch may replace one of the defined code sequences with
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 6752225..2d5a50c 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -472,6 +472,7 @@ static inline unsigned long current_top_of_stack(void)
#else
#define __cpuidnative_cpuid
#define paravirt_enabled() 0
+#define paravirt_has(x)0
static inline void load_sp0(struct tss_struct *tss,
struct thread_struct *thread)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index cd96852..4af8d06 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
#endif
+ if (paravirt_enabled() && !paravirt_has(RTC))
+ return -ENODEV;
+
platform_device_register(_device);
dev_info(_device.dev,
"registered platform RTC device (no PNP device found)\n");
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index a0d09f6..a43b2ea 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1414,6 +1414,7 @@ __init void lguest_init(void)
pv_info.kernel_rpl = 1;
/* Everyone except Xen runs with this set. */
pv_info.shared_kernel_pmd = 1;
+ pv_info.features = 0;
/*
* We set up all the lguest overrides for sensitive operations. These
diff --git
Re: [LKP] [lkp] [x86/irq] 4c24cee6b2: IP-Config: Auto-configuration of network failed
On Tue, 15 Dec 2015, Jiang Liu wrote: > Hi Boris and Ying, > Aha, found a possible regression. Could you please help to > apply the attached bugfix patch ontop of "cc22b9b83f6a x86/irq: > Enhance __assign_irq_vector() to rollback in case of failure"? > Hi Ying, I have push this patch to github so it should reach > 0day test farm soon:) So if that's fixed, can you please resend the series with everything folded back? Thanks, tglx -- 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] USB-FHCI: Use a signed return type for fhci_create_ep()
Just make it an int. The caller also casts it to u32... regards, dan carpenter -- 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 v9 0/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs
On Sat, 19 Dec 2015, KY Srinivasan wrote: > > From: Thomas Gleixner [mailto:t...@linutronix.de] > > On Tue, 15 Dec 2015, KY Srinivasan wrote: > > > > > > Of these 7 patches, Greg has committed all of the VMBUS > > > related supporting patches (3 patches). Thomas, can you > > > take the IRQ related patches through your tree. > > > > That does not make any sense. > > > > > > Jake Oshins (7): > > > > drivers:hv: Export a function that maps Linux CPU num onto Hyper-V > > > > proc num > > > > drivers:hv: Export hv_do_hypercall() > > > > PCI: Make it possible to implement a PCI MSI IRQ Domain in a module. > > > > PCI: Add fwnode_handle to pci_sysdata > > > > PCI: irqdomain: Look up IRQ domain by fwnode_handle > > > > drivers:hv: Define the channel type of Hyper-V PCI Express > > > > pass-through > > > > PCI: hv: New paravirtual PCI front-end for Hyper-V VMs > > > > That series cannot be ripped apart. The PCI part does not even compile > > w/o the drivers/hv part in place. > > What I was proposing was that after you pick up the hv related patches in > Greg's tree in the next cycle, would you be willing to take the IRQ related > patches through your tree. Sorry for the confusion. You mean: PCI: Make it possible to implement a PCI MSI IRQ Domain in a module. Right? Aside from the misleading subject line, I can pick that one up. The rest wants to go through the PCI tree. Thanks, tglx -- 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-slicoss: Use a signed return type for slic_card_locate()
It returns zero or negative error codes. The callers expect int. It is harmless. It should just be int. regards, dan carpenter -- 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] SCSI-lpfc: Use a signed return type for two functions
It returns zero or negative error codes. The callers expect int. The current code is harmless. It should return an int. regards, dan carpenter -- 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/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/19/2015 3:07 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/19/2015 1:19 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/19/2015 1:05 PM, Måns Rullgård wrote:
Andy Shevchenko writes:
On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
OK, I've found something. The dma setup errors are benign, caused by
the driver calling dmaengine_prep_slave_sg() even for non-dma
operations.
I suppose the following is a quick fix to avoid preparing descriptor
for non-DMA operations (not tested anyhow)
a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1041,6 +1041,9 @@ static void sata_dwc_qc_prep_by_tag(struct
ata_queued_cmd *qc, u8 tag)
__func__, ap->port_no, get_dma_dir_descript(qc->dma_dir),
qc->n_elem);
+ if (!is_slave_direction(qc->dma_dir))
+ return;
+
desc = dma_dwc_xfer_setup(qc);
if (!desc) {
dev_err(ap->dev, "%s: dma_dwc_xfer_setup returns NULL\n",
I already have a better patch sitting here.
The real error is the lock recursion that's reported
later. I wasn't seeing it since I was running a UP non-preempt kernel.
With lock debugging enabled, I get the same error. This patch should
fix it.
- spin_lock_irqsave(>host->lock, flags);
hsdevp->cmd_issued[tag] = cmd_issued;
- spin_unlock_irqrestore(>host->lock, flags);
+
This will create a second empty line, though I don't care it is so minor.
The patch leaves one blank line before the following block comment. I
think it looks better that way.
Still can't get the patch applied .
Sorry, didn't realise it conflicted with an intervening patch I had in
my tree. Try this one.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.19 14:44:52 =~=~=~=~=~=~=~=~=~=~=~=
U-Boot 2015.a (May 16 2015 - 14:20:11)
CPU: AMCC PowerPC 460EX Rev. B at 1155 MHz (PLB=231 OPB=115 EBC=115)
No Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter enabled
32 kB I-Cache 32 kB D-Cache
Board: Sam460ex/cr, PCIe 4x + SATA-2
I2C: ready
DRAM: 2 GiB (ECC not enabled, 462 MHz, CL4)
PCI: Bus Dev VenId DevId Class Int
00 04 1095 3512 0104 00
00 06 126f 0501 0380 00
PCIE1: successfully set as root-complex
02 00 1002 683f 0300 ff
Net: ppc_4xx_eth0
FPGA: Revision 03 (2010-10-07)
SM502: found
PERMD2:not found
VGA: 1
VESA: OK
[0.00] Using Canyonlands machine description
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc
version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #1 PREEMPT Sat Dec 19 14:25:55 AST 2015
[0.00] Zone ranges:
[0.00] DMA [mem 0x-0x2fff]
[0.00] Normal empty
[0.00] HighMem [mem 0x3000-0x7fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x-0x7fff]
[0.00] Initmem setup node 0 [mem 0x-0x7fff]
[0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 522752
[0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200
console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg
Please add ignore_log_level.
Had to truncate the kernel command line to add it.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.19 15:59:55 =~=~=~=~=~=~=~=~=~=~=~=
U-Boot 2015.a (May 16 2015 - 14:20:11)
CPU: AMCC PowerPC 460EX Rev. B at 1155 MHz (PLB=231 OPB=115 EBC=115)
No Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter enabled
32 kB I-Cache 32 kB D-Cache
Board: Sam460ex/cr, PCIe 4x + SATA-2
I2C: ready
DRAM: 2 GiB (ECC not enabled, 462 MHz, CL4)
PCI: Bus Dev VenId DevId Class Int
00 04 1095 3512 0104 00
00 06 126f 0501 0380 00
PCIE1: successfully set as root-complex
02 00 1002 683f 0300 ff
Net: ppc_4xx_eth0
FPGA: Revision 03 (2010-10-07)
SM502: found
PERMD2:not found
VGA: 1
VESA: OK
[0.00] Using Canyonlands machine description
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc
version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #1 PREEMPT Sat Dec 19 14:25:55 AST 2015
[0.00] Zone ranges:
[0.00] DMA [mem 0x-0x2fff]
[0.00] Normal empty
[0.00] HighMem [mem 0x3000-0x7fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x-0x7fff]
[0.00] Initmem setup node 0 [mem 0x-0x7fff]
[
[PATCH] USB-FHCI: Use a signed return type for fhci_create_ep()
From: Markus Elfring
Date: Sat, 19 Dec 2015 21:10:20 +0100
The return type "u32" was used by the fhci_create_ep() function even though
it will eventually return a negative error code.
Improve this implementation detail by using the type "s32" instead.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/usb/host/fhci-tds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/fhci-tds.c b/drivers/usb/host/fhci-tds.c
index f82ad5d..c1ae172 100644
--- a/drivers/usb/host/fhci-tds.c
+++ b/drivers/usb/host/fhci-tds.c
@@ -149,7 +149,7 @@ void fhci_ep0_free(struct fhci_usb *usb)
* data_memThe data memory partition(BUS)
* ring_lenTD ring length
*/
-u32 fhci_create_ep(struct fhci_usb *usb, enum fhci_mem_alloc data_mem,
+s32 fhci_create_ep(struct fhci_usb *usb, enum fhci_mem_alloc data_mem,
u32 ring_len)
{
struct endpoint *ep;
--
2.6.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] ti-st: Use a signed return type for st_ll_sleep_state()
It returns zero or negative error codes. The return value is never checked. Make it an int. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] serial: rewrite pxa2xx-uart to use 8250_core
On Sat, 2015-12-19 at 20:31 +0100, Robert Jarzmik wrote: > Sergei Ianovich writes: > Thanks for spotting this. This is caused by a change in the latest > > version of the patch (SERIAL_8250_PXA instead of SERIAL_PXA). This > > change could be reverted. > Actually I'm against the revert. > The name change looks very good to me, please keep it. Is it worth adding an error if CONFIG_SERIAL_PXA is defined? Or is there any other way of preventing this patch launching Linus' "flag days" as Russel King named it? I understand that people are afraid of taking this patch. If it starts causing troubles at runtime, it will be difficult to diagnose. There will be no console for most people. So it is probably good idea to fail at boot time. > > > But that can be handled in an subsequent patch to keep your acks > > > and > > > reviews. > > I will respin the patch. Please comment on the acks and reviews. > > They > > were made at an earlier version of the patch. That version no longer > > applies. Can the updated version carry on the flags? > I don't get you. If you mean keeping CONFIG_SERIAL_8250_PXA, then yes, > please > keep it. I mean should the patch be re-revied and re-acked? -- 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] pinctrl-adi2: Use a signed return type for adi_gpio_irq_startup()
This introduces a compile warning. These functions are supposed to return 1 if there is an IRQ pending. Change the -EINVAL to 0. regards, dan carpenter -- 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 3/5] futex: Document pi_state refcounting in requeue code
Documentation of the pi_state refcounting in the requeue code is non
existent. Add it.
Signed-off-by: Thomas Gleixner
---
kernel/futex.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1709,6 +1709,8 @@ static int futex_requeue(u32 __user *uad
* exist yet, look it up one more time to ensure we have a
* reference to it. If the lock was taken, ret contains the
* vpid of the top waiter task.
+* If the lock was not taken, we have pi_state and an initial
+* refcount on it. In case of an error we have nothing.
*/
if (ret > 0) {
WARN_ON(pi_state);
@@ -1724,12 +1726,16 @@ static int futex_requeue(u32 __user *uad
* it. So we rather use the known value than
* rereading and handing potential crap to
* lookup_pi_state.
+*
+* If that call succeeds then we have pi_state
+* and an initial refcount on it.
*/
ret = lookup_pi_state(ret, hb2, , _state);
}
switch (ret) {
case 0:
+ /* We hold a reference on the pi state. */
break;
case -EFAULT:
put_pi_state(pi_state);
@@ -1804,19 +1810,38 @@ static int futex_requeue(u32 __user *uad
* of requeue_pi if we couldn't acquire the lock atomically.
*/
if (requeue_pi) {
- /* Prepare the waiter to take the rt_mutex. */
+ /*
+* Prepare the waiter to take the rt_mutex. Take a
+* refcount on the pi_state and store the pointer in
+* the futex_q object of the waiter.
+*/
atomic_inc(_state->refcount);
this->pi_state = pi_state;
ret = rt_mutex_start_proxy_lock(_state->pi_mutex,
this->rt_waiter,
this->task);
if (ret == 1) {
- /* We got the lock. */
+ /*
+* We got the lock. We do neither drop
+* the refcount on pi_state nor clear
+* this->pi_state because the waiter
+* needs the pi_state for cleaning up
+* the user space value. It will drop
+* the refcount after doing so.
+*/
requeue_pi_wake_futex(this, , hb2);
drop_count++;
continue;
} else if (ret) {
- /* -EDEADLK */
+ /*
+* rt_mutex_start_proxy_lock()
+* detected a potential deadlock when
+* we tried to queue that waiter. Drop
+* the pi_state reference which we
+* took above and remove the pointer
+* to the state from the waiters
+* futex_q object.
+*/
this->pi_state = NULL;
put_pi_state(pi_state);
goto out_unlock;
@@ -1827,6 +1852,11 @@ static int futex_requeue(u32 __user *uad
}
out_unlock:
+ /*
+* We took an extra initial reference to the pi_state either
+* in futex_proxy_trylock_atomic() or in lookup_pi_state(). We
+* need to drop it here again.
+*/
put_pi_state(pi_state);
double_unlock_hb(hb1, hb2);
wake_up_q(_q);
--
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 4/5] futex: Remove pointless put_pi_state calls in requeue()
In the error handling cases we neither have pi_state nor a reference to it. Remove the pointless code. Signed-off-by: Thomas Gleixner --- kernel/futex.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1737,9 +1737,9 @@ static int futex_requeue(u32 __user *uad case 0: /* We hold a reference on the pi state. */ break; + + /* If the above failed, then pi_state is NULL */ case -EFAULT: - put_pi_state(pi_state); - pi_state = NULL; double_unlock_hb(hb1, hb2); hb_waiters_dec(hb2); put_futex_key(); @@ -1755,8 +1755,6 @@ static int futex_requeue(u32 __user *uad * exit to complete. * - The user space value changed. */ - put_pi_state(pi_state); - pi_state = NULL; double_unlock_hb(hb1, hb2); hb_waiters_dec(hb2); put_futex_key(); -- 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 5/5] futex: Cleanup the goto confusion in requeue_pi()
out_unlock: does not only drop the locks, it also drops the refcount on the pi_state. Really intuitive. Move the label after the put_pi_state() call and use 'break' in the error handling path of the requeue loop. Signed-off-by: Thomas Gleixner --- kernel/futex.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1842,20 +1842,21 @@ static int futex_requeue(u32 __user *uad */ this->pi_state = NULL; put_pi_state(pi_state); - goto out_unlock; + break; } } requeue_futex(this, hb1, hb2, ); drop_count++; } -out_unlock: /* * We took an extra initial reference to the pi_state either * in futex_proxy_trylock_atomic() or in lookup_pi_state(). We * need to drop it here again. */ put_pi_state(pi_state); + +out_unlock: double_unlock_hb(hb1, hb2); wake_up_q(_q); hb_waiters_dec(hb2); -- 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/5] futex: Drop refcount if requeue_pi() acquired the rtmutex
If the proxy lock in the requeue loop acquires the rtmutex for a
waiter then it acquired also refcount on the pi_state related to the
futex, but the waiter side does not drop the reference count.
Add the missing free_pi_state() call.
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
---
kernel/futex.c |5 +
1 file changed, 5 insertions(+)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2755,6 +2755,11 @@ static int futex_wait_requeue_pi(u32 __u
if (q.pi_state && (q.pi_state->owner != current)) {
spin_lock(q.lock_ptr);
ret = fixup_pi_state_owner(uaddr2, , current);
+ /*
+* Drop the reference to the pi state which
+* the requeue_pi() code acquired for us.
+*/
+ free_pi_state(q.pi_state);
spin_unlock(q.lock_ptr);
}
} else {
--
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 0/5] futex: Plug a pi_state leak and clarify the refcounting
A recent patch claimed that there is a double free in the requeue_pi code, which is not the case. While analysing the issue I found the contrary, i.e. a leak. This series fixes the leak and clarifies the code so it's more clear how that refcounting on the pi state works. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/5] futex: Rename free_pi_state() to put_pi_state()
free_pi_state() is confusing as it is in fact only freeing/caching the
pi state when the last reference is gone. Rename it to put_pi_state()
which reflects better what it is doing.
Signed-off-by: Thomas Gleixner
---
kernel/futex.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -725,9 +725,12 @@ static struct futex_pi_state * alloc_pi_
}
/*
+ * Drops a reference to the pi_state object and frees or caches it
+ * when the last reference is gone.
+ *
* Must be called with the hb lock held.
*/
-static void free_pi_state(struct futex_pi_state *pi_state)
+static void put_pi_state(struct futex_pi_state *pi_state)
{
if (!pi_state)
return;
@@ -1729,7 +1732,7 @@ static int futex_requeue(u32 __user *uad
case 0:
break;
case -EFAULT:
- free_pi_state(pi_state);
+ put_pi_state(pi_state);
pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
@@ -1746,7 +1749,7 @@ static int futex_requeue(u32 __user *uad
* exit to complete.
* - The user space value changed.
*/
- free_pi_state(pi_state);
+ put_pi_state(pi_state);
pi_state = NULL;
double_unlock_hb(hb1, hb2);
hb_waiters_dec(hb2);
@@ -1815,7 +1818,7 @@ static int futex_requeue(u32 __user *uad
} else if (ret) {
/* -EDEADLK */
this->pi_state = NULL;
- free_pi_state(pi_state);
+ put_pi_state(pi_state);
goto out_unlock;
}
}
@@ -1824,7 +1827,7 @@ static int futex_requeue(u32 __user *uad
}
out_unlock:
- free_pi_state(pi_state);
+ put_pi_state(pi_state);
double_unlock_hb(hb1, hb2);
wake_up_q(_q);
hb_waiters_dec(hb2);
@@ -1973,7 +1976,7 @@ static void unqueue_me_pi(struct futex_q
__unqueue_futex(q);
BUG_ON(!q->pi_state);
- free_pi_state(q->pi_state);
+ put_pi_state(q->pi_state);
q->pi_state = NULL;
spin_unlock(q->lock_ptr);
@@ -2759,7 +2762,7 @@ static int futex_wait_requeue_pi(u32 __u
* Drop the reference to the pi state which
* the requeue_pi() code acquired for us.
*/
- free_pi_state(q.pi_state);
+ put_pi_state(q.pi_state);
spin_unlock(q.lock_ptr);
}
} else {
--
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] mm, oom: initiallize all new zap_details fields before use
On Fri, Dec 18, 2015 at 08:04:51PM -0500, Sasha Levin wrote: > Commit "mm, oom: introduce oom reaper" forgot to initialize the two new fields > of struct zap_details in unmap_mapping_range(). This caused using stack > garbage > on the call to unmap_mapping_range_tree(). > > Signed-off-by: Sasha Levin > --- > mm/memory.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/memory.c b/mm/memory.c > index 206c8cd..0e32993 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -2431,6 +2431,7 @@ void unmap_mapping_range(struct address_space *mapping, > details.last_index = hba + hlen - 1; > if (details.last_index < details.first_index) > details.last_index = ULONG_MAX; > + details.check_swap_entries = details.ignore_dirty = false; Should we use c99 initializer instead to make it future-proof? -- Kirill A. Shutemov -- 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/
