On 4/23/19 11:21 AM, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 2dc702c991e3 HID: input: use the Resolution Multiplier for high-resolution scrolling.
>
> The bot has tested the following trees: v5.0.9.
>
> v5.0.9: Failed to apply! Possible dependencies:
> 724f54bc0063 ("HID: input: make sure the wheel high resolution multiplier is set")
>
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
>
This patch will only apply *after* the application of the first patch, since they "overlap".
Yes, that is probably not the best circumstance. I think Benjamin wanted to keep the issue in patch 2/2 distinct.
Was the first patch applied before attempting application of the second patch?
James
From: Chen-Yu Tsai <wens(a)csie.org>
The code path for Macs goes through bcm_apple_get_resources(), which
skips over the code that sets up the regulator supplies. As a result,
the call to regulator_bulk_enable() / regulator_bulk_disable() results
in a NULL pointer dereference.
This was reported on the kernel.org Bugzilla, bug 202963.
Unbreak Broadcom Bluetooth support on Intel Macs by checking if the
supplies were set up before enabling or disabling them.
The same does not need to be done for the clocks, as the common clock
framework API checks for NULL pointers.
Fixes: 75d11676dccb ("Bluetooth: hci_bcm: Add support for regulator supplies")
Cc: <stable(a)vger.kernel.org> # 5.0.x
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
---
I do not own a Mac, so this needs to be tested by someone else.
---
drivers/bluetooth/hci_bcm.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index ddbe518c3e5b..b5d31d583d60 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -228,9 +228,15 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool powered)
int err;
if (powered && !dev->res_enabled) {
- err = regulator_bulk_enable(BCM_NUM_SUPPLIES, dev->supplies);
- if (err)
- return err;
+ /* Intel Macs use bcm_apple_get_resources() and don't
+ * have regulator supplies configured.
+ */
+ if (dev->supplies[0].supply) {
+ err = regulator_bulk_enable(BCM_NUM_SUPPLIES,
+ dev->supplies);
+ if (err)
+ return err;
+ }
/* LPO clock needs to be 32.768 kHz */
err = clk_set_rate(dev->lpo_clk, 32768);
@@ -259,7 +265,13 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool powered)
if (!powered && dev->res_enabled) {
clk_disable_unprepare(dev->txco_clk);
clk_disable_unprepare(dev->lpo_clk);
- regulator_bulk_disable(BCM_NUM_SUPPLIES, dev->supplies);
+
+ /* Intel Macs use bcm_apple_get_resources() and don't
+ * have regulator supplies configured.
+ */
+ if (dev->supplies[0].supply)
+ regulator_bulk_disable(BCM_NUM_SUPPLIES,
+ dev->supplies);
}
/* wait for device to power on and come out of reset */
--
2.20.1
On 04/23, Greg KH wrote:
>On Mon, Apr 22, 2019 at 10:59:50PM +0800, Zhenliang Wei wrote:
>> In the fixes commit, removing SIGKILL from each thread signal mask and
>> executing "goto fatal" directly will skip the call to
>> "trace_signal_deliver". At this point, the delivery tracking of the
>> SIGKILL signal will be inaccurate.
>>
>> Therefore, we need to add trace_signal_deliver before "goto fatal"
>> after executing sigdelset.
>>
>> Note: The action[SIGKILL] must be SIG_DFL, and SEND_SIG_NOINFO matches
>> the fact that SIGKILL doesn't have any info.
>>
>> Acked-by: Christian Brauner <christian(a)brauner.io>
>> Fixes: cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT")
>> Signed-off-by: Zhenliang Wei <weizhenliang(a)huawei.com>
>> ---
>> kernel/signal.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/signal.c b/kernel/signal.c index
>> 227ba170298e..0f69ada376ef 100644
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2441,6 +2441,7 @@ bool get_signal(struct ksignal *ksig)
>> if (signal_group_exit(signal)) {
>> ksig->info.si_signo = signr = SIGKILL;
>> sigdelset(¤t->pending.signal, SIGKILL);
>> + trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, SIG_DFL);
>> recalc_sigpending();
>> goto fatal;
>> }
>> --
>> 2.14.1.windows.1
>>
>>
>
><formletter>
>
>This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>for how to do this properly.
>
></formletter>
Thans for your reply, is that mean I still need to add tags
Cc: stable(a)vger.kernel.org
if I want to submit this patch to the stable kernel tree?
Is my understanding correct or missing?
Wei
On 04/23, Oleg wrote:
>On 04/23, weizhenliang wrote:
>>
>> Last time Oleg suggested using SIG_DFL as the third parameter, but its type is 'void (*)(int)', but not expected 'struct k_sigaction *'.
>
>Yes I misread the signature of TRACE_EVENT(signal_deliver), and I thought you at least compiled the kernel with your patch applied ;)
>
>> How about
>> trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, &sighand->action[signr
>> - 1]); ?
>
>sure, this should fix the problem.
Sorry about that, I will pay more attention to it in the future.
And thanks for your reply, I will re-adjust the patch later.
Wei.
On Tue, Apr 23, 2019 at 09:41 PM Christian wrote:
>On Tue, Apr 23, 2019 at 01:10:52PM +0000, weizhenliang wrote:
>> On Mon, Apr 22, 2019 at 11:25 PM Oleg Nesterov <oleg(a)redhat.com> wrote:
>> >On 04/22, Zhenliang Wei wrote:
>> >>
>> >> --- a/kernel/signal.c
>> >> +++ b/kernel/signal.c
>> >> @@ -2441,6 +2441,7 @@ bool get_signal(struct ksignal *ksig)
>> >> if (signal_group_exit(signal)) {
>> >> ksig->info.si_signo = signr = SIGKILL;
>> >> sigdelset(¤t->pending.signal, SIGKILL);
>> >> + trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, SIG_DFL);
>> >> recalc_sigpending();
>> >> goto fatal;
>> >> }
>> >
>> >Reviewed-by: Oleg Nesterov <oleg(a)redhat.com>
>>
>> Last time Oleg suggested using SIG_DFL as the third parameter, but its type is 'void (*)(int)', but not expected 'struct k_sigaction *'.
>
>Sigh, I should've caught that in the first commit.
>Although it suggests you didn't even compile your patch...
>
>>
>> How about
>> trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, &sighand->action[signr
>> - 1]); ?
>
>That should work, yes.
Sorry about that, I was too focused on the functionality and didn't notice the compile warning.
And thanks for your reply, I will pay more attention to it in the future.
Zhenliang Wei