December 2017 - Linux-stable-mirror

[Linux-stable-mirror] Patch "sched/deadline: Make sure the replenishment timer fires in the next period" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched/deadline: Make sure the replenishment timer fires in the next period to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sched-deadline-make-sure-the-replenishment-timer-fires-in-the-next-period.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Daniel Bristot de Oliveira <bristot(a)redhat.com> Date: Thu, 2 Mar 2017 15:10:57 +0100 Subject: sched/deadline: Make sure the replenishment timer fires in the next period From: Daniel Bristot de Oliveira <bristot(a)redhat.com> [ Upstream commit 5ac69d37784b237707a7b15d199cdb6c6fdb6780 ] Currently, the replenishment timer is set to fire at the deadline of a task. Although that works for implicit deadline tasks because the deadline is equals to the begin of the next period, that is not correct for constrained deadline tasks (deadline < period). For instance: f.c: --------------- %< --------------- int main (void) { for(;;); } --------------- >% --------------- # gcc -o f f.c # trace-cmd record -e sched:sched_switch \ -e syscalls:sys_exit_sched_setattr \ chrt -d --sched-runtime 490000000 \ --sched-deadline 500000000 \ --sched-period 1000000000 0 ./f # trace-cmd report | grep "{pid of ./f}" After setting parameters, the task is replenished and continue running until being throttled: f-11295 [003] 13322.113776: sys_exit_sched_setattr: 0x0 The task is throttled after running 492318 ms, as expected: f-11295 [003] 13322.606094: sched_switch: f:11295 [-1] R ==> watchdog/3:32 [0] But then, the task is replenished 500719 ms after the first replenishment: <idle>-0 [003] 13322.614495: sched_switch: swapper/3:0 [120] R ==> f:11295 [-1] Running for 490277 ms: f-11295 [003] 13323.104772: sched_switch: f:11295 [-1] R ==> swapper/3:0 [120] Hence, in the first period, the task runs 2 * runtime, and that is a bug. During the first replenishment, the next deadline is set one period away. So the runtime / period starts to be respected. However, as the second replenishment took place in the wrong instant, the next replenishment will also be held in a wrong instant of time. Rather than occurring in the nth period away from the first activation, it is taking place in the (nth period - relative deadline). Signed-off-by: Daniel Bristot de Oliveira <bristot(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Luca Abeni <luca.abeni(a)santannapisa.it> Reviewed-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Reviewed-by: Juri Lelli <juri.lelli(a)arm.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it> Link: http://lkml.kernel.org/r/ac50d89887c25285b47465638354b63362f8adff.148839293… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/sched/deadline.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -510,10 +510,15 @@ static void update_dl_entity(struct sche } } +static inline u64 dl_next_period(struct sched_dl_entity *dl_se) +{ + return dl_se->deadline - dl_se->dl_deadline + dl_se->dl_period; +} + /* * If the entity depleted all its runtime, and if we want it to sleep * while waiting for some new execution time to become available, we - * set the bandwidth enforcement timer to the replenishment instant + * set the bandwidth replenishment timer to the replenishment instant * and try to activate it. * * Notice that it is important for the caller to know if the timer @@ -535,7 +540,7 @@ static int start_dl_timer(struct task_st * that it is actually coming from rq->clock and not from * hrtimer's time base reading. */ - act = ns_to_ktime(dl_se->deadline); + act = ns_to_ktime(dl_next_period(dl_se)); now = hrtimer_cb_get_time(timer); delta = ktime_to_ns(now) - rq_clock(rq); act = ktime_add_ns(act, delta); Patches currently in stable-queue which might be from bristot(a)redhat.com are queue-4.4/sched-deadline-make-sure-the-replenishment-timer-fires-in-the-next-period.patch queue-4.4/sched-deadline-throttle-a-constrained-deadline-task-activated-after-the-deadline.patch queue-4.4/sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "rtc: pcf8563: fix output clock rate" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: pcf8563: fix output clock rate to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-pcf8563-fix-output-clock-rate.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Philipp Zabel <p.zabel(a)pengutronix.de> Date: Tue, 7 Nov 2017 13:12:17 +0100 Subject: rtc: pcf8563: fix output clock rate From: Philipp Zabel <p.zabel(a)pengutronix.de> [ Upstream commit a3350f9c57ffad569c40f7320b89da1f3061c5bb ] The pcf8563_clkout_recalc_rate function erroneously ignores the frequency index read from the CLKO register and always returns 32768 Hz. Fixes: a39a6405d5f9 ("rtc: pcf8563: add CLKOUT to common clock framework") Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-pcf8563.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/rtc/rtc-pcf8563.c +++ b/drivers/rtc/rtc-pcf8563.c @@ -427,7 +427,7 @@ static unsigned long pcf8563_clkout_reca return 0; buf &= PCF8563_REG_CLKO_F_MASK; - return clkout_rates[ret]; + return clkout_rates[buf]; } static long pcf8563_clkout_round_rate(struct clk_hw *hw, unsigned long rate, Patches currently in stable-queue which might be from p.zabel(a)pengutronix.de are queue-4.4/rtc-pcf8563-fix-output-clock-rate.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "RDMA/cma: Avoid triggering undefined behavior" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/cma: Avoid triggering undefined behavior to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-cma-avoid-triggering-undefined-behavior.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Wed, 11 Oct 2017 10:48:45 -0700 Subject: RDMA/cma: Avoid triggering undefined behavior From: Bart Van Assche <bart.vanassche(a)wdc.com> [ Upstream commit c0b64f58e8d49570aa9ee55d880f92c20ff0166b ] According to the C standard the behavior of computations with integer operands is as follows: * A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. * The behavior for signed integer underflow and overflow is undefined. Hence only use unsigned integers when checking for integer overflow. This patch is what I came up with after having analyzed the following smatch warnings: drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len' drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len' Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Acked-by: Sean Hefty <sean.hefty(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/cma.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -1353,7 +1353,7 @@ static struct rdma_id_private *cma_id_fr return id_priv; } -static inline int cma_user_data_offset(struct rdma_id_private *id_priv) +static inline u8 cma_user_data_offset(struct rdma_id_private *id_priv) { return cma_family(id_priv) == AF_IB ? 0 : sizeof(struct cma_hdr); } @@ -1731,7 +1731,8 @@ static int cma_req_handler(struct ib_cm_ struct rdma_id_private *listen_id, *conn_id; struct rdma_cm_event event; struct net_device *net_dev; - int offset, ret; + u8 offset; + int ret; listen_id = cma_id_from_event(cm_id, ib_event, &net_dev); if (IS_ERR(listen_id)) @@ -3118,7 +3119,8 @@ static int cma_resolve_ib_udp(struct rdm struct ib_cm_sidr_req_param req; struct ib_cm_id *id; void *private_data; - int offset, ret; + u8 offset; + int ret; memset(&req, 0, sizeof req); offset = cma_user_data_offset(id_priv); @@ -3175,7 +3177,8 @@ static int cma_connect_ib(struct rdma_id struct rdma_route *route; void *private_data; struct ib_cm_id *id; - int offset, ret; + u8 offset; + int ret; memset(&req, 0, sizeof req); offset = cma_user_data_offset(id_priv); Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.4/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch queue-4.4/rdma-cma-avoid-triggering-undefined-behavior.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "raid5: Set R5_Expanded on parity devices as well as data." has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled raid5: Set R5_Expanded on parity devices as well as data. to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: NeilBrown <neilb(a)suse.com> Date: Tue, 17 Oct 2017 16:18:36 +1100 Subject: raid5: Set R5_Expanded on parity devices as well as data. From: NeilBrown <neilb(a)suse.com> [ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ] When reshaping a fully degraded raid5/raid6 to a larger nubmer of devices, the new device(s) are not in-sync and so that can make the newly grown stripe appear to be "failed". To avoid this, we set the R5_Expanded flag to say "Even though this device is not fully in-sync, this block is safe so don't treat the device as failed for this stripe". This flag is set for data devices, not not for parity devices. Consequently, if you have a RAID6 with two devices that are partly recovered and a spare, and start a reshape to include the spare, then when the reshape gets past the point where the recovery was up to, it will think the stripes are failed and will get into an infinite loop, failing to make progress. So when contructing parity on an EXPAND_READY stripe, set R5_Expanded. Reported-by: Curt <lightspd(a)gmail.com> Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/raid5.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -1681,8 +1681,11 @@ static void ops_complete_reconstruct(voi struct r5dev *dev = &sh->dev[i]; if (dev->written || i == pd_idx || i == qd_idx) { - if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) + if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) { set_bit(R5_UPTODATE, &dev->flags); + if (test_bit(STRIPE_EXPAND_READY, &sh->state)) + set_bit(R5_Expanded, &dev->flags); + } if (fua) set_bit(R5_WantFUA, &dev->flags); if (sync) Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.4/md-cluster-free-md_cluster_info-if-node-leave-cluster.patch queue-4.4/autofs-fix-careless-error-in-recent-commit.patch queue-4.4/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch queue-4.4/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch queue-4.4/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "ppp: Destroy the mutex when cleanup" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ppp: Destroy the mutex when cleanup to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ppp-destroy-the-mutex-when-cleanup.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Gao Feng <gfree.wind(a)vip.163.com> Date: Tue, 31 Oct 2017 18:25:37 +0800 Subject: ppp: Destroy the mutex when cleanup From: Gao Feng <gfree.wind(a)vip.163.com> [ Upstream commit f02b2320b27c16b644691267ee3b5c110846f49e ] The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the good readbility, it's better to invoke it in exit func when the init func invokes mutex_init. Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com> Acked-by: Guillaume Nault <g.nault(a)alphalink.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ppp/ppp_generic.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -942,6 +942,7 @@ static __net_exit void ppp_exit_net(stru unregister_netdevice_many(&list); rtnl_unlock(); + mutex_destroy(&pn->all_ppp_mutex); idr_destroy(&pn->units_idr); } Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are queue-4.4/ppp-destroy-the-mutex-when-cleanup.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Shriya <shriyak(a)linux.vnet.ibm.com> Date: Fri, 13 Oct 2017 10:06:41 +0530 Subject: powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo From: Shriya <shriyak(a)linux.vnet.ibm.com> [ Upstream commit cd77b5ce208c153260ed7882d8910f2395bfaabd ] The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which returns the last frequency requested by the kernel, but may not reflect the actual frequency the processor is running at. This patch makes a call to cpufreq_get() instead which returns the current frequency reported by the hardware. Fixes: fb5153d05a7d ("powerpc: powernv: Implement ppc_md.get_proc_freq()") Signed-off-by: Shriya <shriyak(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/powernv/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/platforms/powernv/setup.c +++ b/arch/powerpc/platforms/powernv/setup.c @@ -295,7 +295,7 @@ static unsigned long pnv_get_proc_freq(u { unsigned long ret_freq; - ret_freq = cpufreq_quick_get(cpu) * 1000ul; + ret_freq = cpufreq_get(cpu) * 1000ul; /* * If the backend cpufreq driver does not exist, Patches currently in stable-queue which might be from shriyak(a)linux.vnet.ibm.com are queue-4.4/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/perf/hv-24x7: Fix incorrect comparison in memord" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/perf/hv-24x7: Fix incorrect comparison in memord to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-perf-hv-24x7-fix-incorrect-comparison-in-memord.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Mon, 9 Oct 2017 21:52:44 +1100 Subject: powerpc/perf/hv-24x7: Fix incorrect comparison in memord From: Michael Ellerman <mpe(a)ellerman.id.au> [ Upstream commit 05c14c03138532a3cb2aa29c2960445c8753343b ] In the hv-24x7 code there is a function memord() which tries to implement a sort function return -1, 0, 1. However one of the conditions is incorrect, such that it can never be true, because we will have already returned. I don't believe there is a bug in practice though, because the comparisons are an optimisation prior to calling memcmp(). Fix it by swapping the second comparision, so it can be true. Reported-by: David Binderman <dcb314(a)hotmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/perf/hv-24x7.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/perf/hv-24x7.c +++ b/arch/powerpc/perf/hv-24x7.c @@ -514,7 +514,7 @@ static int memord(const void *d1, size_t { if (s1 < s2) return 1; - if (s2 > s1) + if (s1 > s2) return -1; return memcmp(d1, d2, s1); Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.4/powerpc-perf-hv-24x7-fix-incorrect-comparison-in-memord.patch queue-4.4/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch queue-4.4/powerpc-ipic-fix-status-get-and-status-clear.patch queue-4.4/powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/opal: Fix EBUSY bug in acquiring tokens" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/opal: Fix EBUSY bug in acquiring tokens to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: "William A. Kennington III" <wak(a)google.com> Date: Fri, 22 Sep 2017 16:58:00 -0700 Subject: powerpc/opal: Fix EBUSY bug in acquiring tokens From: "William A. Kennington III" <wak(a)google.com> [ Upstream commit 71e24d7731a2903b1ae2bba2b2971c654d9c2aa6 ] The current code checks the completion map to look for the first token that is complete. In some cases, a completion can come in but the token can still be on lease to the caller processing the completion. If this completed but unreleased token is the first token found in the bitmap by another tasks trying to acquire a token, then the __test_and_set_bit call will fail since the token will still be on lease. The acquisition will then fail with an EBUSY. This patch reorganizes the acquisition code to look at the opal_async_token_map for an unleased token. If the token has no lease it must have no outstanding completions so we should never see an EBUSY, unless we have leased out too many tokens. Since opal_async_get_token_inrerruptible is protected by a semaphore, we will practically never see EBUSY anymore. Fixes: 8d7248232208 ("powerpc/powernv: Infrastructure to support OPAL async completion") Signed-off-by: William A. Kennington III <wak(a)google.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/powernv/opal-async.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/powerpc/platforms/powernv/opal-async.c +++ b/arch/powerpc/platforms/powernv/opal-async.c @@ -39,18 +39,18 @@ int __opal_async_get_token(void) int token; spin_lock_irqsave(&opal_async_comp_lock, flags); - token = find_first_bit(opal_async_complete_map, opal_max_async_tokens); + token = find_first_zero_bit(opal_async_token_map, opal_max_async_tokens); if (token >= opal_max_async_tokens) { token = -EBUSY; goto out; } - if (__test_and_set_bit(token, opal_async_token_map)) { + if (!__test_and_clear_bit(token, opal_async_complete_map)) { token = -EBUSY; goto out; } - __clear_bit(token, opal_async_complete_map); + __set_bit(token, opal_async_token_map); out: spin_unlock_irqrestore(&opal_async_comp_lock, flags); Patches currently in stable-queue which might be from wak(a)google.com are queue-4.4/powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/ipic: Fix status get and status clear" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/ipic: Fix status get and status clear to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-ipic-fix-status-get-and-status-clear.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Christophe Leroy <christophe.leroy(a)c-s.fr> Date: Wed, 18 Oct 2017 11:16:47 +0200 Subject: powerpc/ipic: Fix status get and status clear From: Christophe Leroy <christophe.leroy(a)c-s.fr> [ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ] IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR which is the mask register. Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/sysdev/ipic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/powerpc/sysdev/ipic.c +++ b/arch/powerpc/sysdev/ipic.c @@ -845,12 +845,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq u32 ipic_get_mcp_status(void) { - return ipic_read(primary_ipic->regs, IPIC_SERMR); + return ipic_read(primary_ipic->regs, IPIC_SERSR); } void ipic_clear_mcp_status(u32 mask) { - ipic_write(primary_ipic->regs, IPIC_SERMR, mask); + ipic_write(primary_ipic->regs, IPIC_SERSR, mask); } /* Return an interrupt vector or NO_IRQ if no interrupt is pending. */ Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are queue-4.4/powerpc-ipic-fix-status-get-and-status-clear.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:47:43 CET 2017 From: Markus Elfring <elfring(a)users.sourceforge.net> Date: Wed, 1 Nov 2017 18:42:45 +0100 Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill() From: Markus Elfring <elfring(a)users.sourceforge.net> [ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ] Source code review for a specific software refactoring showed the need for another correction because the error code "-1" was returned so far if a call of the function "sony_call_snc_handle" failed here. Thus assign the return value from these two function calls also to the variable "err" and provide it in case of a failure. Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw") Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Link: https://lkml.org/lkml/2017/10/31/463 Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com> Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/sony-laptop.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/drivers/platform/x86/sony-laptop.c +++ b/drivers/platform/x86/sony-laptop.c @@ -1655,17 +1655,19 @@ static int sony_nc_setup_rfkill(struct a if (!rfk) return -ENOMEM; - if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) { + err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result); + if (err < 0) { rfkill_destroy(rfk); - return -1; + return err; } hwblock = !(result & 0x1); - if (sony_call_snc_handle(sony_rfkill_handle, - sony_rfkill_address[nc_type], - &result) < 0) { + err = sony_call_snc_handle(sony_rfkill_handle, + sony_rfkill_address[nc_type], + &result); + if (err < 0) { rfkill_destroy(rfk); - return -1; + return err; } swblock = !(result & 0x2); Patches currently in stable-queue which might be from elfring(a)users.sourceforge.net are queue-4.4/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch

7 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2017