* Re: [PATCH] cpufreq: qcom-kryo: add NULL entry to the end of_device_id array
From: Viresh Kumar @ 2018-07-24 3:43 UTC (permalink / raw)
To: YueHaibing; +Cc: ilia.lin, rjw, linux-kernel, linux-pm
In-Reply-To: <20180723123429.20040-1-yuehaibing@huawei.com>
On 23-07-18, 20:34, YueHaibing wrote:
> Make sure of_device_id tables are NULL terminated
> Found by coccinelle spatch "misc/of_table.cocci"
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
> index 29389ac..efc9a7a 100644
> --- a/drivers/cpufreq/qcom-cpufreq-kryo.c
> +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> @@ -183,6 +183,7 @@ static struct platform_driver qcom_cpufreq_kryo_driver = {
> static const struct of_device_id qcom_cpufreq_kryo_match_list[] __initconst = {
> { .compatible = "qcom,apq8096", },
> { .compatible = "qcom,msm8996", },
> + {}
> };
>
> /*
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
From: David Gibson @ 2018-07-24 2:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Cédric Le Goater, qemu-ppc, qemu-devel, Marcel Apfelbaum,
Andrea Bolognani, Michael S. Tsirkin
In-Reply-To: <3692f644f72a1af49b7d5988d6b8482ea2f1e271.camel@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]
On Tue, Jul 24, 2018 at 09:55:53AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-23 at 14:16 +1000, David Gibson wrote:
> > >
> > > Now, this is an ICS subclass, so why shouldn't it directly poke at the
> > > target ICP ?
> >
> > That's ok in theory, but causing it to expose the icp interface to a
> > new module isn't great.
> >
> > > It's an alternate to the normal ICS since it behaves a bit
> > > differently (PQ bits & all).
> >
> > AFAICT the PQ bits are effectively another filtering layer on top of
> > the same ICS logic as elsewhere. I think it's better if we can share
> > that shared logic, rather than replicating it.
>
> I don't know, is there much shared logic ? And the shared bits are the
> subclassing, that's handled that way...
>
> This is really a different piece of HW, a separate ICS implementation,
> that has its own quirks, is configured via different registers, does
> EOI differently etc...
>
> Even the resend stuff is done differently, the resend bitmap is
> actually SW visible via an IODA table.
>
> I mean, we could (maybe we do these days not sure) have an ICS
> superclass wrapper on the actual icp_irq() but that's really all there
> is to it I think.
Hm, yeah, fair enough. I realized what I was suggesting would
actually need another layer of qirqs than we have, so it's not a good
idea after all. Ok, I'm happy proceeding with exposing icp_irq().
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: Toshiaki Makita @ 2018-07-24 3:41 UTC (permalink / raw)
To: Tonghao Zhang
Cc: Linux Kernel Network Developers, toshiaki.makita1, virtualization,
mst
In-Reply-To: <CAMDZJNVVJs35kuvktTxn+mmDz7db+1K-kfuOoMUn9Z=WoayUVw@mail.gmail.com>
On 2018/07/24 12:28, Tonghao Zhang wrote:
> On Tue, Jul 24, 2018 at 10:53 AM Toshiaki Makita
> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>
>> On 2018/07/24 2:31, Tonghao Zhang wrote:
>>> On Mon, Jul 23, 2018 at 10:20 PM Toshiaki Makita
>>> <toshiaki.makita1@gmail.com> wrote:
>>>>
>>>> On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
>>>>> On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
>>>>> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>>>>>
>>>>>> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
>>>>>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>>>>>
>>>>>>> Factor out generic busy polling logic and will be
>>>>>>> used for in tx path in the next patch. And with the patch,
>>>>>>> qemu can set differently the busyloop_timeout for rx queue.
>>>>>>>
>>>>>>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>>>>> ---
>>>>>> ...
>>>>>>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
>>>>>>> + struct vhost_virtqueue *rvq,
>>>>>>> + struct vhost_virtqueue *tvq,
>>>>>>> + bool rx)
>>>>>>> +{
>>>>>>> + struct socket *sock = rvq->private_data;
>>>>>>> +
>>>>>>> + if (rx) {
>>>>>>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
>>>>>>> + vhost_poll_queue(&tvq->poll);
>>>>>>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
>>>>>>> + vhost_disable_notify(&net->dev, tvq);
>>>>>>> + vhost_poll_queue(&tvq->poll);
>>>>>>> + }
>>>>>>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>>>>>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>>>> + vhost_poll_queue(&rvq->poll);
>>>>>>
>>>>>> Now we wait for vq_avail for rx as well, I think you cannot skip
>>>>>> vhost_enable_notify() on tx. Probably you might want to do:
>>>>> I think vhost_enable_notify is needed.
>>>>>
>>>>>> } else if (sock && sk_has_rx_data(sock->sk)) {
>>>>>> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>>> vhost_poll_queue(&rvq->poll);
>>>>>> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
>>>>>> vhost_disable_notify(&net->dev, rvq);
>>>>>> vhost_poll_queue(&rvq->poll);
>>>>>> }
>>>>>> }
>>>>> As Jason review as before, we only want rx kick when packet is pending at
>>>>> socket but we're out of available buffers. So we just enable notify,
>>>>> but not poll it ?
>>>>>
>>>>> } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>>>> !vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>> vhost_poll_queue(&rvq->poll);
>>>>> else {
>>>>> vhost_enable_notify(&net->dev, rvq);
>>>>> }
>>>>
>>>> When vhost_enable_notify() returns true the avail becomes non-empty
>>>> while we are enabling notify. We may delay the rx process if we don't
>>>> check the return value of vhost_enable_notify().
>>> I got it thanks.
>>>>>> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
>>>>> I cant find why it is better, if necessary, we can do it.
>>>>
>>>> The reason is pretty simple... we are busypolling the socket so we don't
>>>> need rx wakeups during it?
>>> OK, but one question, how about rx? do we use the
>>> vhost_net_disable_vq/vhost_net_ensable_vq on rx ?
>>
>> If we are busypolling the sock tx buf? I'm not sure if polling it
>> improves the performance.
> Not the sock tx buff, when we are busypolling in handle_rx, we will
> check the tx vring via vhost_vq_avail_empty.
> So, should we the disable tvq, e.g. vhost_net_disable_vq(net, tvq)?> --
When you want to stop vq kicks from the guest you should call
vhost_disable_notify() and when you want to stop vq wakeups from the
socket you should call vhost_net_disable_vq().
You are polling vq_avail so you want to stop vq kicks thus
vhost_disable_notify() is needed and it is already called.
--
Toshiaki Makita
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: btf: fix inconsistent IS_ERR and PTR_ERR
From: Jakub Kicinski @ 2018-07-24 3:40 UTC (permalink / raw)
To: YueHaibing
Cc: ast, daniel, quentin.monnet, bhole_prashant_q7, osk, linux-kernel,
netdev, davem
In-Reply-To: <20180724025524.22012-1-yuehaibing@huawei.com>
On Tue, 24 Jul 2018 10:55:24 +0800, YueHaibing wrote:
> Fix inconsistent IS_ERR and PTR_ERR in get_btf,
> the proper pointer to be passed as argument is '*btf'
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
FWIW:
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Thanks!
^ permalink raw reply
* Re: [PATCH v6 3/6] Uprobes: Support SDT markers having reference count (semaphore)
From: Ravi Bangoria @ 2018-07-24 3:34 UTC (permalink / raw)
To: Oleg Nesterov
Cc: srikar, rostedt, mhiramat, peterz, mingo, acme,
alexander.shishkin, jolsa, namhyung, linux-kernel, ananth,
alexis.berlemont, naveen.n.rao, linux-arm-kernel, linux-mips,
linux, ralf, paul.burton, Ravi Bangoria
In-Reply-To: <20180723162629.GA8584@redhat.com>
Hi Oleg,
On 07/23/2018 09:56 PM, Oleg Nesterov wrote:
> I have a mixed feeling about this series... I'll try to summarise my thinking
> tomorrow, but I do not see any obvious problem so far. Although I have some
> concerns about 5/6, I need to re-read it after sleep.
Sure.
>
>
> On 07/16, Ravi Bangoria wrote:
>>
>> +static int delayed_uprobe_install(struct vm_area_struct *vma)
>> +{
>> + struct list_head *pos, *q;
>> + struct delayed_uprobe *du;
>> + unsigned long vaddr;
>> + int ret = 0, err = 0;
>> +
>> + mutex_lock(&delayed_uprobe_lock);
>> + list_for_each_safe(pos, q, &delayed_uprobe_list) {
>> + du = list_entry(pos, struct delayed_uprobe, list);
>> +
>> + if (!du->uprobe->ref_ctr_offset ||
>
> Is it possible to see ->ref_ctr_offset == 0 in delayed_uprobe_list?
I'll remove this check.
>
>> @@ -1072,7 +1282,13 @@ int uprobe_mmap(struct vm_area_struct *vma)
>> struct uprobe *uprobe, *u;
>> struct inode *inode;
>>
>> - if (no_uprobe_events() || !valid_vma(vma, true))
>> + if (no_uprobe_events())
>> + return 0;
>> +
>> + if (vma->vm_flags & VM_WRITE)
>> + delayed_uprobe_install(vma);
>
> Obviously not nice performance-wise... OK, I do not know if it will actually
> hurt in practice and probably we can use the better data structures if necessary.
> But can't we check MMF_HAS_UPROBES at least? I mean,
>
> if (vma->vm_flags & VM_WRITE && test_bit(MMF_HAS_UPROBES, &vma->vm_mm->flags))
> delayed_uprobe_install(vma);
>
> ?
Yes.
>
>
> Perhaps we can even add another flag later, MMF_HAS_DELAYED_UPROBES set by
> delayed_uprobe_add().
Yes, good idea.
Thanks for the review,
Ravi
^ permalink raw reply
* [GIT PULL] dts changes to use ti-sysc driver for omap4 l4
From: Tony Lindgren @ 2018-07-24 3:40 UTC (permalink / raw)
To: linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 91f6278bfa3966529c61808bd3cb8f05d7ed5dc6:
ARM: dts: am335x: add am335x-sancloud-bbe board support (2018-07-17 01:05:37 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.19/dt-pt3-signed
for you to fetch changes up to ab8b1fdd012f41b27f85a6bb271389fd7ff349ea:
Merge branch 'omap-for-v4.19/dt-sysc-v2' into omap-for-v4.19/dt (2018-07-20 22:22:08 -0700)
----------------------------------------------------------------
Start using ti-sysc with device tree data for omap4 l4 devices
With ti-sysc driver working for most use cases, we can start converting
the omap variant SoCs to use device tree data for the interconnect target
modules instead of the legacy hwmod platform data.
We start with omap4 l4 devices excluding the ones that still depend on
a reset controller driver like DSP MMU. And we don't yet convert the l4
ABE instance as that needs a bit more work.
We also add a proper interconnect hierarchy for the devices while at it
to make further work on genpd easier and to avoid most deferred probe
issues.
At this point we are not dropping any platform data, and we initially
still use it to validate the dts data. Then in later merge cycles we
can start dropping the related platform data.
----------------------------------------------------------------
Tony Lindgren (6):
dt-bindings: Update omap l4 binding for optional registers
ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data
ARM: dts: omap4: Probe watchdog 3 with ti-sysc
ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc
ARM: dts: omap4: Add l4 ranges for 4460
Merge branch 'omap-for-v4.19/dt-sysc-v2' into omap-for-v4.19/dt
Documentation/devicetree/bindings/arm/omap/l4.txt | 15 +-
arch/arm/boot/dts/omap4-l4.dtsi | 2444 +++++++++++++++++++++
arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
arch/arm/boot/dts/omap4.dtsi | 812 +------
arch/arm/boot/dts/omap4460.dtsi | 36 +
5 files changed, 2526 insertions(+), 783 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-l4.dtsi
^ permalink raw reply
* [GIT PULL] dts changes to use ti-sysc driver for omap4 l4
From: Tony Lindgren @ 2018-07-24 3:40 UTC (permalink / raw)
To: arm; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 91f6278bfa3966529c61808bd3cb8f05d7ed5dc6:
ARM: dts: am335x: add am335x-sancloud-bbe board support (2018-07-17 01:05:37 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.19/dt-pt3-signed
for you to fetch changes up to ab8b1fdd012f41b27f85a6bb271389fd7ff349ea:
Merge branch 'omap-for-v4.19/dt-sysc-v2' into omap-for-v4.19/dt (2018-07-20 22:22:08 -0700)
----------------------------------------------------------------
Start using ti-sysc with device tree data for omap4 l4 devices
With ti-sysc driver working for most use cases, we can start converting
the omap variant SoCs to use device tree data for the interconnect target
modules instead of the legacy hwmod platform data.
We start with omap4 l4 devices excluding the ones that still depend on
a reset controller driver like DSP MMU. And we don't yet convert the l4
ABE instance as that needs a bit more work.
We also add a proper interconnect hierarchy for the devices while at it
to make further work on genpd easier and to avoid most deferred probe
issues.
At this point we are not dropping any platform data, and we initially
still use it to validate the dts data. Then in later merge cycles we
can start dropping the related platform data.
----------------------------------------------------------------
Tony Lindgren (6):
dt-bindings: Update omap l4 binding for optional registers
ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data
ARM: dts: omap4: Probe watchdog 3 with ti-sysc
ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc
ARM: dts: omap4: Add l4 ranges for 4460
Merge branch 'omap-for-v4.19/dt-sysc-v2' into omap-for-v4.19/dt
Documentation/devicetree/bindings/arm/omap/l4.txt | 15 +-
arch/arm/boot/dts/omap4-l4.dtsi | 2444 +++++++++++++++++++++
arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
arch/arm/boot/dts/omap4.dtsi | 812 +------
arch/arm/boot/dts/omap4460.dtsi | 36 +
5 files changed, 2526 insertions(+), 783 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-l4.dtsi
^ permalink raw reply
* Re: [PATCH v5 net-next 0/6] net: ethernet: ti: cpsw: add MQPRIO and CBS Qdisc offload
From: David Miller @ 2018-07-24 3:38 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, corbet, akpm, netdev, linux-doc, linux-kernel,
linux-omap, vinicius.gomes, henrik, jesus.sanchez-palencia,
ilias.apalodimas, p-varis, spatton, francois.ozog, yogeshs,
nsekhar, andrew
In-Reply-To: <20180723212634.3219-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 24 Jul 2018 00:26:28 +0300
> This series adds MQPRIO and CBS Qdisc offload for TI cpsw driver.
> It potentially can be used in audio video bridging (AVB) and time
> sensitive networking (TSN).
>
> Patchset was tested on AM572x EVM and BBB boards. Last patch from this
> series adds detailed description of configuration with examples. For
> consistency reasons, in role of talker and listener, tools from
> patchset "TSN: Add qdisc based config interface for CBS" were used and
> can be seen here: https://www.spinics.net/lists/netdev/msg460869.html
>
> Based on net-next/master
Series applied, thanks Ivan.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 net-next 0/6] net: ethernet: ti: cpsw: add MQPRIO and CBS Qdisc offload
From: David Miller @ 2018-07-24 3:38 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, corbet, akpm, netdev, linux-doc, linux-kernel,
linux-omap, vinicius.gomes, henrik, jesus.sanchez-palencia,
ilias.apalodimas, p-varis, spatton, francois.ozog, yogeshs,
nsekhar, andrew
In-Reply-To: <20180723212634.3219-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 24 Jul 2018 00:26:28 +0300
> This series adds MQPRIO and CBS Qdisc offload for TI cpsw driver.
> It potentially can be used in audio video bridging (AVB) and time
> sensitive networking (TSN).
>
> Patchset was tested on AM572x EVM and BBB boards. Last patch from this
> series adds detailed description of configuration with examples. For
> consistency reasons, in role of talker and listener, tools from
> patchset "TSN: Add qdisc based config interface for CBS" were used and
> can be seen here: https://www.spinics.net/lists/netdev/msg460869.html
>
> Based on net-next/master
Series applied, thanks Ivan.
^ permalink raw reply
* [PATCH 1/2 V3] xfs_repair: notify user if free inodes contain errors
From: Eric Sandeen @ 2018-07-24 2:34 UTC (permalink / raw)
To: Eric Sandeen, linux-xfs
In-Reply-To: <b6f745ab-3016-9a95-3085-8584f7200b64@redhat.com>
xfs_repair checks allocated but unused (free) inodes in on-disk clusters,
and up until now silently repairs any errors, and as a result does not
alter exit status if errors are found.
The in-kernel verifiers will be noisy about these errors and instruct
the user to run repair, so it's best if repair is explicit about any
fixes it makes as a result.
To ensure we catch anything the kernel would complain about, re-use
xfs_dinode_verify to determine whether we must clear a free inode.
Note, however, that the verifier contains only a subset of the checks
currently in clear_dinode. This should be ok; if it's not, the checks
should be added to the verifier in any case.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
diff --git a/libxfs/libxfs_api_defs.h b/libxfs/libxfs_api_defs.h
index a98483b..05c06a7 100644
--- a/libxfs/libxfs_api_defs.h
+++ b/libxfs/libxfs_api_defs.h
@@ -134,6 +134,7 @@
#define xfs_symlink_hdr_ok libxfs_symlink_hdr_ok
#define xfs_verify_cksum libxfs_verify_cksum
+#define xfs_dinode_verify libxfs_dinode_verify
#define xfs_alloc_ag_max_usable libxfs_alloc_ag_max_usable
#define xfs_allocbt_maxrecs libxfs_allocbt_maxrecs
diff --git a/repair/dinode.c b/repair/dinode.c
index d36338f..c0db15a 100644
--- a/repair/dinode.c
+++ b/repair/dinode.c
@@ -2560,12 +2560,20 @@ _("bad (negative) size %" PRId64 " on inode %" PRIu64 "\n"),
*/
if (was_free) {
/*
- * easy case, inode free -- inode and map agree, clear
+ * easy case, inode free -- inode and map agree, check
* it just in case to ensure that format, etc. are
* set correctly
*/
- if (!no_modify)
- *dirty += clear_dinode(mp, dino, lino);
+ if (libxfs_dinode_verify(mp, lino, dino) != NULL) {
+ do_warn(
+ _("free inode %" PRIu64 " contains errors, "), lino);
+ if (!no_modify) {
+ *dirty += clear_dinode(mp, dino, lino);
+ do_warn(_("corrected\n"));
+ } else {
+ do_warn(_("would correct\n"));
+ }
+ }
*used = is_free;
return 0;
}
^ permalink raw reply related
* WARNING in port_delete
From: Dae R. Jeong @ 2018-07-24 3:36 UTC (permalink / raw)
To: perex, tiwai, colin.king
Cc: alsa-devel, linux-kernel, lifeasageek, kt0755, bammanag
Reporting the crash: WARNING in port_delete
This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
version of Syzkaller), which we descrbie more at the end of this
report. Our analysis shows that the race occurs when invoking two close
syscalls concurrently.
The executed program is as follows:
r0 = open("/dev/snd/seq", 0x0, 0x0)
ioctl(r0, SNDRV_SEQ_IOCTL_CREATE_PORT, {{0x80}, "706f72943000000000000000000000000000000000000000000000000000000000233f770800000000000000000000000000000000000000001000", 0xffffffffffffffff, 0xfffffffffffffbff})
r1 = openat(AT_FDCWD, "/dev/sequencer2", 0x8402, 0x0)
close(r0)
close(r1)
and two threads executed the program as follows:
Thread0 Thread1
open("/dev/snd/seq")
ioctl(r0, SNDRV_SEQ_IOCTL_CREATE_PORT)
openat("/dev/sequencer2")
close(r0) close(r1)
(Note that two close() syscalls were exeuted after openat() syscall, and
two close() syscalls were executed concurrently.)
Crash log:
==================================================================
WARNING: CPU: 1 PID: 32519 at /home/daeryong/workspace/race-fuzzer/kernels_repo/kernel_v4.18-rc3/sound/core/seq/seq_ports.c:275 port_delete+0xde/0xf0 sound/core/seq/seq_ports.c:275
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 32519 Comm: syz-executor0 Not tainted 4.18.0-rc3 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x16e/0x22c lib/dump_stack.c:113
panic+0x1a8/0x3a7 kernel/panic.c:184
__warn+0x191/0x1a0 kernel/panic.c:536
report_bug+0x132/0x1b0 lib/bug.c:186
fixup_bug.part.10+0x28/0x50 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x284/0x2c0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:port_delete+0xde/0xf0 sound/core/seq/seq_ports.c:275
Code: 00 00 e8 b5 68 d2 fd 8b 83 58 01 00 00 85 c0 75 1d e8 86 5c ae fd 48 89 df e8 3e 52 d2 fd 31 c0 5b 41 5c 5d c3 e8 72 5c ae fd <0f> 0b eb c8 e8 69 5c ae fd 0f 0b eb da 0f 1f 44 00 00 55 48 89 e5
RSP: 0018:ffff8801d635f900 EFLAGS: 00010216
RAX: 0000000000040000 RBX: ffff8801da196900 RCX: ffffffff839b86ee
RDX: 0000000000005e94 RSI: ffffc90002640000 RDI: ffff8801da196978
RBP: ffff8801d635f910 R08: 0000000000000098 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff839ba820
R13: ffff8801da196950 R14: ffff8801ed5bc080 R15: ffff8801da196958
snd_seq_delete_port+0x2b0/0x2d0 sound/core/seq/seq_ports.c:303
snd_seq_ioctl_delete_port+0x5b/0xa0 sound/core/seq/seq_clientmgr.c:1325
snd_seq_kernel_client_ctl+0xd4/0xf0 sound/core/seq/seq_clientmgr.c:2361
snd_seq_event_port_detach+0xcb/0x120 sound/core/seq/seq_ports.c:705
delete_port+0x3a/0x70 sound/core/seq/oss/seq_oss_init.c:354
snd_seq_oss_release+0x7c/0x90 sound/core/seq/oss/seq_oss_init.c:433
odev_release+0x40/0x60 sound/core/seq/oss/seq_oss.c:153
__fput+0x234/0x470 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x15a/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:192 [inline]
exit_to_usermode_loop+0x2a3/0x2b0 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x485/0x4b0 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x456469
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fe9a8936b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 000000000072bfa0 RCX: 0000000000456469
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000014
RBP: 0000000000000054 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe9a89376d4
R13: 00000000ffffffff R14: 00000000006f5880 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
= About RaceFuzzer
RaceFuzzer is a customized version of Syzkaller, specifically tailored
to find race condition bugs in the Linux kernel. While we leverage
many different technique, the notable feature of RaceFuzzer is in
leveraging a custom hypervisor (QEMU/KVM) to interleave the
scheduling. In particular, we modified the hypervisor to intentionally
stall a per-core execution, which is similar to supporting per-core
breakpoint functionality. This allows RaceFuzzer to force the kernel
to deterministically trigger racy condition (which may rarely happen
in practice due to randomness in scheduling).
RaceFuzzer's C repro always pinpoints two racy syscalls. Since C
repro's scheduling synchronization should be performed at the user
space, its reproducibility is limited (reproduction may take from 1
second to 10 minutes (or even more), depending on a bug). This is
because, while RaceFuzzer precisely interleaves the scheduling at the
kernel's instruction level when finding this bug, C repro cannot fully
utilize such a feature. Please disregard all code related to
"should_hypercall" in the C repro, as this is only for our debugging
purposes using our own hypervisor.
^ permalink raw reply
* [PATCH v6 3/6] Uprobes: Support SDT markers having reference count (semaphore)
From: Ravi Bangoria @ 2018-07-24 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723162629.GA8584@redhat.com>
Hi Oleg,
On 07/23/2018 09:56 PM, Oleg Nesterov wrote:
> I have a mixed feeling about this series... I'll try to summarise my thinking
> tomorrow, but I do not see any obvious problem so far. Although I have some
> concerns about 5/6, I need to re-read it after sleep.
Sure.
>
>
> On 07/16, Ravi Bangoria wrote:
>>
>> +static int delayed_uprobe_install(struct vm_area_struct *vma)
>> +{
>> + struct list_head *pos, *q;
>> + struct delayed_uprobe *du;
>> + unsigned long vaddr;
>> + int ret = 0, err = 0;
>> +
>> + mutex_lock(&delayed_uprobe_lock);
>> + list_for_each_safe(pos, q, &delayed_uprobe_list) {
>> + du = list_entry(pos, struct delayed_uprobe, list);
>> +
>> + if (!du->uprobe->ref_ctr_offset ||
>
> Is it possible to see ->ref_ctr_offset == 0 in delayed_uprobe_list?
I'll remove this check.
>
>> @@ -1072,7 +1282,13 @@ int uprobe_mmap(struct vm_area_struct *vma)
>> struct uprobe *uprobe, *u;
>> struct inode *inode;
>>
>> - if (no_uprobe_events() || !valid_vma(vma, true))
>> + if (no_uprobe_events())
>> + return 0;
>> +
>> + if (vma->vm_flags & VM_WRITE)
>> + delayed_uprobe_install(vma);
>
> Obviously not nice performance-wise... OK, I do not know if it will actually
> hurt in practice and probably we can use the better data structures if necessary.
> But can't we check MMF_HAS_UPROBES at least? I mean,
>
> if (vma->vm_flags & VM_WRITE && test_bit(MMF_HAS_UPROBES, &vma->vm_mm->flags))
> delayed_uprobe_install(vma);
>
> ?
Yes.
>
>
> Perhaps we can even add another flag later, MMF_HAS_DELAYED_UPROBES set by
> delayed_uprobe_add().
Yes, good idea.
Thanks for the review,
Ravi
^ permalink raw reply
* Re: [PATCH v1 4/9] scsi: ufs: add option to change default UFS power management level
From: Asutosh Das (asd) @ 2018-07-24 3:34 UTC (permalink / raw)
To: Rob Herring
Cc: Subhash Jadavani, Can Guo, Vivek Gautam, Rajendra Nayak,
Vinayak Holikatti, James E.J. Bottomley, Martin K. Petersen,
linux-scsi, linux-arm-msm, Venkat Gopalakrishnan, Mark Rutland,
Mathieu Malaterre, devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqLXUvUj8n=1Xv-_ssqB6rayMvxOTnGzeN1vS9yx4-jqOQ@mail.gmail.com>
On 7/23/2018 8:06 PM, Rob Herring wrote:
> On Sun, Jul 22, 2018 at 9:20 PM Asutosh Das (asd)
> <asutoshd@codeaurora.org> wrote:
>>
>> On 7/12/2018 2:03 AM, Rob Herring wrote:
>>> On Fri, Jul 06, 2018 at 06:00:31PM +0530, Asutosh Das wrote:
>>>> From: Subhash Jadavani <subhashj@codeaurora.org>
>>>>
>>>> UFS device and link can be put in multiple different low power modes hence
>>>> UFS driver supports multiple different low power modes. By default UFS
>>>> driver selects the default (optimal) low power mode (which gives moderate
>>>> power savings and have relatively less enter and exit latencies) but
>>>> we might have to tune this default power mode for different chipset
>>>> platforms to meet the low power requirements/goals. Hence this patch
>>>> adds option to change default UFS low power mode (level).
>>>>
>>>> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
>>>> Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
>>>> Signed-off-by: Can Guo <cang@codeaurora.org>
>>>> Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
>>>> ---
>>>> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 11 ++++++++
>>>> drivers/scsi/ufs/ufshcd-pltfrm.c | 14 +++++++++++
>>>> drivers/scsi/ufs/ufshcd.c | 29 +++++++++++++++-------
>>>> drivers/scsi/ufs/ufshcd.h | 4 +--
>>>> 4 files changed, 47 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> index c39dfef..f564d9a 100644
>>>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>>> @@ -38,6 +38,15 @@ Optional properties:
>>>> defined or a value in the array is "0" then it is assumed
>>>> that the frequency is set by the parent clock or a
>>>> fixed rate clock source.
>>>> +- rpm-level : UFS Runtime power management level. Following PM levels are supported:
>>>> + 0 - Both UFS device and Link in active state (Highest power consumption)
>>>> + 1 - UFS device in active state but Link in Hibern8 state
>>>> + 2 - UFS device in Sleep state but Link in active state
>>>> + 3 - UFS device in Sleep state and Link in hibern8 state (default PM level)
>>>> + 4 - UFS device in Power-down state and Link in Hibern8 state
>>>> + 5 - UFS device in Power-down state and Link in OFF state (Lowest power consumption)
>>>> +- spm-level : UFS System power management level. Allowed PM levels are same as rpm-level.
>>>
>>> What's the default?
>>>
>>> I assume these are minimums? The OS can pick higher power states. This
>>> seems to be a bit Linux specific (as 'runtime PM' could be considered
>>> Linux specific). For every other device, we don't put this type of
>>> information in DT, but is user controlled.
>> I didn't completely understand your comment.
>> Do you not want these properties to be in DT file?
>
> Right, not if it is a user decision.
>
>> When you say user-controlled, do you mean control it through sysfs entries?
>
> Yes.
>
>>> So really, wouldn't 1
>>> property be sufficient for cases where a mode doesn't work due to
>>> some h/w limitation. Otherwise, it is an OS or user decision.
>> I didn't completely understand this. Could you please elaborate on your
>> intent here?
>
> The case that makes sense for this to be in DT is if there are h/w
> limitations that prevent some low power modes. In such a case, that
> limit is not likely specific to runtime PM or system suspend.
>
>>>> -lanes-per-direction : number of lanes available per direction - either 1 or 2.
>>>> Note that it is assume same number of lanes is used both
>>>> directions at once. If not specified, default is 2 lanes per direction.
>>>> @@ -66,4 +75,6 @@ Example:
>>>> freq-table-hz = <100000000 200000000>, <0 0>, <0 0>;
>>>> phys = <&ufsphy1>;
>>>> phy-names = "ufsphy";
>>>> + rpm-level = <3>;
>>>
>>> Why specified if 3 is the default?
>> Ah yes - that should be removed.
>> I'll remove it in v2.
>>
>>>
>>>> + spm-level = <5>;
>>>
>>> These seem like sane defaults. When and why would you use some
>>> different?
>> I think each of the deeper sleep modes are associated with an increasing
>> wakeup latency. For e.g. '0' would have the highest power-consumption
>> and no resume latency at all as compared to '5'.
>> So depending on use-cases other modes may be chosen.
>
> The use-case can change in a running system. For example if you are
> plugged in, then you probably don't want to enter a lower power mode.
>
> Rob
>
Ok - Thanks.
I'm gonna make the following changes in v2:
1. Remove these entries from DT
2. Add support for these entries in sysfs.
3. Keep 3 as the default value for [rpm/spm]-levels
-asd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [Fuego] [PATCH] busybox: add support for command head/hexdump/hostname/id/ifconfig/install
From: Wang, Mingyu @ 2018-07-24 3:33 UTC (permalink / raw)
To: Tim.Bird@sony.com, fuego@lists.linuxfoundation.org
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF7C1B5810@USCULXMSG01.am.sony.com>
Hi Tim,
The test script for command id and install have been modified.
Other comments are also confirmed and fixed.
Please check the new patch.
by Wangmy
-----Original Message-----
From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
Sent: Tuesday, July 24, 2018 7:35 AM
To: Wang, Mingyu/王 鸣瑜 <wangmy@cn.fujitsu.com>; fuego@lists.linuxfoundation.org
Subject: RE: [Fuego] [PATCH] busybox: add support for command head/hexdump/hostname/id/ifconfig/install
See comments inline below.
> -----Original Message-----
> From: Wang Mingyu
>
> Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
> ---
> .../tests/Functional.busybox/tests/busybox_head.sh | 22
> ++++++++++++++++++++++
> .../Functional.busybox/tests/busybox_hexdump.sh | 19
> +++++++++++++++++++
> .../Functional.busybox/tests/busybox_hostname.sh | 13 +++++++++++++
> .../tests/Functional.busybox/tests/busybox_id.sh | 13 +++++++++++++
> .../Functional.busybox/tests/busybox_ifconfig.sh | 13 +++++++++++++
> .../Functional.busybox/tests/busybox_install.sh | 17 +++++++++++++++++
> 6 files changed, 97 insertions(+)
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_head.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_hostname.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_id.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_install.sh
>
> diff --git a/engine/tests/Functional.busybox/tests/busybox_head.sh
> b/engine/tests/Functional.busybox/tests/busybox_head.sh
> new file mode 100644
> index 0000000..be0269e
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_head.sh
> @@ -0,0 +1,22 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command head #
> +1) Option -n
> +
> +test="head"
> +
> +mkdir test_dir
> +touch test_dir/test1
This is not needed (the 'touch')
> +echo "This is the 1st line.">test_dir/test1 echo "This is the 2nd
> +line.">>test_dir/test1 echo "This is the 3rd line.">>test_dir/test1
> +busybox head -n 2 test_dir/test1 > log
Please use a space before the redirection operator.
> +
> +if [ "$(busybox head -n 1 log)" = "This is the 1st line." ] && [ "$(tail -n 1 log)"
> = "This is the 2nd line." ]
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm log
> +rm -rf test_dir
> diff --git a/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> b/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> new file mode 100644
> index 0000000..d598c72
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command hexdump
> +# 1) Option: -c
> +
> +test="hexdump"
> +
> +mkdir test_dir
> +touch test_dir/test1
> +echo "HELLO WORLD">test_dir/test1
> +busybox hexdump -c test_dir/test1 > log
> +if head -n 1 log | grep "0000000 H E L L O W O R L D \\\n" && [
> "$(tail -n 1 log)" = "000000c" ]
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm log
> +rm -rf test_dir
> diff --git a/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> b/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> new file mode 100644
> index 0000000..f854515
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command hostname
> +# 1) Option none
> +
> +test="hostname"
> +
> +if [ $(busybox hostname) = $(hostname) ]
On a busybox-based system, this just tests the program against itself.
Maybe compare with $(cat /etc/hostname)?
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_id.sh
> b/engine/tests/Functional.busybox/tests/busybox_id.sh
> new file mode 100644
> index 0000000..9f53fcc
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_id.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command id
> +# 1) Option none
> +
> +test="id"
> +
> +if [ "$(busybox id)" = "$(id)" ]
Same issue here. If busybox is the main tool for a board, then
'id' will just be a symlink to busybox, and this test just verifies
that the same command produces the same output.
This one I'm not sure what to do with this one. Maybe
see if there's a shell variable that has the UID?
Or, check that 'id' is not 'busybox id'?
Let me know what you think.
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> b/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> new file mode 100644
> index 0000000..31b07d2
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command ifconfig
> +# 1) Option none
> +
> +test="ifconfig"
> +
> +if busybox ifconfig
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_install.sh
> b/engine/tests/Functional.busybox/tests/busybox_install.sh
> new file mode 100644
> index 0000000..a8cba56
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_install.sh
> @@ -0,0 +1,17 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command install
> +# 1) Option none
> +
> +test="install"
> +
> +mkdir test_dir test_install_dir
> +echo "ls test_install_dir">test_dir/test1
I'm not sure what's going on here.
test1 should have the contents: 'ls test_install_dir'.
It's not clear to me that this is executable.
> +busybox install test_dir/test1 test_install_dir
> +if [ $(./test_install_dir/test1) = test1 ]
Are you trying to execute the script?
I'm confused.
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm -rf test_dir test_install_dir;
> --
> 1.8.3.1
Thanks for the patch.
Please address my feedback and re-submit.
(Note: Sorry - but I will be out-of-the-office the rest of this week,
so my responses will be delayed until next week.)
Regards,
-- Tim
^ permalink raw reply
* Re: [Fuego] [PATCH] busybox: modify the code of option g+x in chmod1 test
From: Wang, Mingyu @ 2018-07-24 3:33 UTC (permalink / raw)
To: Tim.Bird@sony.com, fuego@lists.linuxfoundation.org
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF7C1B57F3@USCULXMSG01.am.sony.com>
Hi Tim,
I didn't find out where the problem was. Maybe because my mail client is in Chinese.
I have changed it to the English version and revised the patch and sent it again.
by Wangmy
-----Original Message-----
From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
Sent: Tuesday, July 24, 2018 7:25 AM
To: Wang, Mingyu/王 鸣瑜 <wangmy@cn.fujitsu.com>; fuego@lists.linuxfoundation.org
Subject: RE: [Fuego] [PATCH] busybox: modify the code of option g+x in chmod1 test
OK - this is applied and pushed. But it was a bit harder to apply than anticipated because your mailer decided to put the message body in base64 encoding.
You other patches don't have this issue. I'm not sure what happened on this one. The only thing I can think of is maybe there was a non-8-bit-ASCII character somewhere in the patch? The only "strange" characters are the quotes (maybe in the patch message) - maybe one of those got turned into a Unicode char or some other extended character-set character.
If you can, please check this.
-- Tim
> -----Original Message-----
> From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
> bounces@lists.linuxfoundation.org] On Behalf Of Wang Mingyu
> Sent: Sunday, July 22, 2018 10:35 PM
> To: fuego@lists.linuxfoundation.org
> Subject: [Fuego] [PATCH] busybox: modify the code of option g+x in
> chmod1 test
>
> Change the cut to retrieve the group permission bytes, to check that
> they are 'execute' ('x').
>
> Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
> ---
> engine/tests/Functional.busybox/tests/busybox_chmod1.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> b/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> index cdc7d18..2eef95a 100644
> --- a/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> +++ b/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> @@ -21,7 +21,7 @@ else
> fi;
>
> busybox chmod g+x ./test_dir/test1
> -if [ "$(busybox ls -l ./test_dir | grep -v "total" | cut -b 1-3)" =
> "-rw" ]
> +if [ "$(busybox ls -l ./test_dir | grep -v "total" | cut -b 5-7)" =
> +"r-x" ]
> then
> echo " -> $test: Changed file permissions verification#2 succeeded."
> else
> --
> 1.8.3.1
>
>
>
> _______________________________________________
> Fuego mailing list
> Fuego@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/fuego
^ permalink raw reply
* [PATCH 0/2 V3] xfs_repair: rework inode clearing and free inode validation
From: Eric Sandeen @ 2018-07-24 2:27 UTC (permalink / raw)
To: linux-xfs
Warn the user if any free inodes contain errors, and set exit code
in the process. Do this by running the existing dinode verifier and
clearing / warning if it fails.
2nd patch separates out the inode validation from the clearing function
There is a functional change here which I'm on the fence about; free
inodes are now only cleared if they won't pass the dinode verifier,
which is the only thing the kernel would squawk about. But that's
a subset of the clear_inode checks.
The old clear_dinode function checked a lot of things that the
verifier simply doesn't care about, but I think it's ok for
those tests to go away; if the kernel does care about, say, extent
count on a free inode, the verifier should test it.
^ permalink raw reply
* Re: [PATCH v2 2/2] clk: qcom: Add qspi (Quad SPI) clocks for sdm845
From: Doug Anderson @ 2018-07-24 3:30 UTC (permalink / raw)
To: Taniya Das
Cc: Stephen Boyd, Andy Gross, grahamr, Girish Mahadevan, Amit Nischal,
Bjorn Andersson, Michael Turquette, linux-arm-msm, LKML,
David Brown, open list:ARM/QUALCOMM SUPPORT, linux-clk
In-Reply-To: <f4f92dcd-7a63-f9de-a7a0-c403672d5c6c@codeaurora.org>
Hi,
On Mon, Jul 23, 2018 at 7:22 PM, Taniya Das <tdas@codeaurora.org> wrote:
>
>
> On 7/24/2018 3:24 AM, Douglas Anderson wrote:
>>
>> Add both the interface and core clock.
>>
>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>> ---
>>
>> Changes in v2:
>> - Only 19.2, 100, 150, and 300 MHz now.
>> - All clocks come from MAIN rather than EVEN.
>> - Use parent map 0 instead of new parent map 9.
>>
>> drivers/clk/qcom/gcc-sdm845.c | 63 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 63 insertions(+)
>>
>> diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
>> index 0f694ed4238a..5bca634e277a 100644
>> --- a/drivers/clk/qcom/gcc-sdm845.c
>> +++ b/drivers/clk/qcom/gcc-sdm845.c
>> @@ -162,6 +162,13 @@ static const char * const gcc_parent_names_10[] = {
>> "core_bi_pll_test_se",
>> };
>> +static const char * const gcc_parent_names_9[] = {
>> + "bi_tcxo",
>> + "gpll0",
>> + "gpll0_out_even",
>> + "core_pi_sleep_clk",
>> +};
>> +
>
>
> Please remove this.
Oops, that's embarrassing. Please stay tuned for v3.
-Doug
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: Toshiaki Makita @ 2018-07-24 2:24 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180723180246.1836bc11@cakuba.netronome.com>
On 2018/07/24 10:02, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:05 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> This allows NIC's XDP to redirect packets to veth. The destination veth
>> device enqueues redirected packets to the napi ring of its peer, then
>> they are processed by XDP on its peer veth device.
>> This can be thought as calling another XDP program by XDP program using
>> REDIRECT, when the peer enables driver XDP.
>>
>> Note that when the peer veth device does not set driver xdp, redirected
>> packets will be dropped because the peer is not ready for NAPI.
...
>> +static int veth_xdp_xmit(struct net_device *dev, int n,
>> + struct xdp_frame **frames, u32 flags)
>> +{
>> + struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
>> + struct net_device *rcv;
>> + int i, drops = 0;
>> +
>> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
>> + return -EINVAL;
>> +
>> + rcv = rcu_dereference(priv->peer);
>> + if (unlikely(!rcv))
>> + return -ENXIO;
>> +
>> + rcv_priv = netdev_priv(rcv);
>> + /* xdp_ring is initialized on receive side? */
>> + if (!rcu_access_pointer(rcv_priv->xdp_prog))
>> + return -ENXIO;
>> +
>> + spin_lock(&rcv_priv->xdp_ring.producer_lock);
>> + for (i = 0; i < n; i++) {
>> + struct xdp_frame *frame = frames[i];
>> + void *ptr = veth_xdp_to_ptr(frame);
>> +
>> + if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
>> + __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
>
> Would you mind sparing a few more words how this is safe vs the
> .ndo_close() on the peer? Personally I'm a bit uncomfortable with the
> IFF_UP check in xdp_ok_fwd_dev(), I'm not sure what's supposed to
> guarantee the device doesn't go down right after that check, or is
> already down, but netdev->flags are not atomic...
Actually it is guarded by RCU. On closing the device rcv_priv->xdp_prog
is set to be NULL, and synchronize_net() is called from within
netif_napi_del(). Then ptr_ring is cleaned-up.
xdp_ok_fwd_dev() is doing the same check as non-XDP case, but it may not
be appropriate because IFF_UP check here is not usable as you say.
>
>> + xdp_return_frame_rx_napi(frame);
>> + drops++;
>> + }
>> + }
>> + spin_unlock(&rcv_priv->xdp_ring.producer_lock);
>> +
>> + if (flags & XDP_XMIT_FLUSH)
>> + __veth_xdp_flush(rcv_priv);
>> +
>> + return n - drops;
>> +}
>> +
>> static struct sk_buff *veth_xdp_rcv_one(struct veth_priv *priv,
>> struct xdp_frame *frame)
>> {
>> @@ -760,6 +804,7 @@ static const struct net_device_ops veth_netdev_ops = {
>> .ndo_features_check = passthru_features_check,
>> .ndo_set_rx_headroom = veth_set_rx_headroom,
>> .ndo_bpf = veth_xdp,
>> + .ndo_xdp_xmit = veth_xdp_xmit,
>> };
>>
>> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
>
>
>
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: Tonghao Zhang @ 2018-07-24 3:28 UTC (permalink / raw)
To: makita.toshiaki
Cc: Linux Kernel Network Developers, toshiaki.makita1, virtualization,
mst
In-Reply-To: <14d01d2d-0eb8-172b-1c53-7dadc5fffbac@lab.ntt.co.jp>
On Tue, Jul 24, 2018 at 10:53 AM Toshiaki Makita
<makita.toshiaki@lab.ntt.co.jp> wrote:
>
> On 2018/07/24 2:31, Tonghao Zhang wrote:
> > On Mon, Jul 23, 2018 at 10:20 PM Toshiaki Makita
> > <toshiaki.makita1@gmail.com> wrote:
> >>
> >> On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
> >>> On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
> >>> <makita.toshiaki@lab.ntt.co.jp> wrote:
> >>>>
> >>>> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
> >>>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>>>>
> >>>>> Factor out generic busy polling logic and will be
> >>>>> used for in tx path in the next patch. And with the patch,
> >>>>> qemu can set differently the busyloop_timeout for rx queue.
> >>>>>
> >>>>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>>>> ---
> >>>> ...
> >>>>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
> >>>>> + struct vhost_virtqueue *rvq,
> >>>>> + struct vhost_virtqueue *tvq,
> >>>>> + bool rx)
> >>>>> +{
> >>>>> + struct socket *sock = rvq->private_data;
> >>>>> +
> >>>>> + if (rx) {
> >>>>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
> >>>>> + vhost_poll_queue(&tvq->poll);
> >>>>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
> >>>>> + vhost_disable_notify(&net->dev, tvq);
> >>>>> + vhost_poll_queue(&tvq->poll);
> >>>>> + }
> >>>>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
> >>>>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
> >>>>> + vhost_poll_queue(&rvq->poll);
> >>>>
> >>>> Now we wait for vq_avail for rx as well, I think you cannot skip
> >>>> vhost_enable_notify() on tx. Probably you might want to do:
> >>> I think vhost_enable_notify is needed.
> >>>
> >>>> } else if (sock && sk_has_rx_data(sock->sk)) {
> >>>> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
> >>>> vhost_poll_queue(&rvq->poll);
> >>>> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
> >>>> vhost_disable_notify(&net->dev, rvq);
> >>>> vhost_poll_queue(&rvq->poll);
> >>>> }
> >>>> }
> >>> As Jason review as before, we only want rx kick when packet is pending at
> >>> socket but we're out of available buffers. So we just enable notify,
> >>> but not poll it ?
> >>>
> >>> } else if ((sock && sk_has_rx_data(sock->sk)) &&
> >>> !vhost_vq_avail_empty(&net->dev, rvq)) {
> >>> vhost_poll_queue(&rvq->poll);
> >>> else {
> >>> vhost_enable_notify(&net->dev, rvq);
> >>> }
> >>
> >> When vhost_enable_notify() returns true the avail becomes non-empty
> >> while we are enabling notify. We may delay the rx process if we don't
> >> check the return value of vhost_enable_notify().
> > I got it thanks.
> >>>> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
> >>> I cant find why it is better, if necessary, we can do it.
> >>
> >> The reason is pretty simple... we are busypolling the socket so we don't
> >> need rx wakeups during it?
> > OK, but one question, how about rx? do we use the
> > vhost_net_disable_vq/vhost_net_ensable_vq on rx ?
>
> If we are busypolling the sock tx buf? I'm not sure if polling it
> improves the performance.
Not the sock tx buff, when we are busypolling in handle_rx, we will
check the tx vring via vhost_vq_avail_empty.
So, should we the disable tvq, e.g. vhost_net_disable_vq(net, tvq)?> --
> Toshiaki Makita
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH 16/20] fork: Move and describe why the code examines PIDNS_ADDING
From: Eric W. Biederman @ 2018-07-24 3:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Andrew Morton, linux-kernel, Wen Yang, majiang,
Eric W. Biederman
In-Reply-To: <87efft5ncd.fsf_-_@xmission.com>
Normally this would be something that would be handled by handling
signals that are sent to a group of processes but in this case the
forking process is not a member of the group being signaled. Thus
special code is needed to prevent a race with pid namespaces exiting,
and fork adding new processes within them.
Move this test up before the signal restart just in case signals are
also pending. Fatal conditions should take presedence over restarts.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
kernel/fork.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index cc5be0d01ce6..b9c54318a292 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1922,6 +1922,12 @@ static __latent_entropy struct task_struct *copy_process(
rseq_fork(p, clone_flags);
+ /* Don't start children in a dying pid namespace */
+ if (unlikely(!(ns_of_pid(pid)->pid_allocated & PIDNS_ADDING))) {
+ retval = -ENOMEM;
+ goto bad_fork_cancel_cgroup;
+ }
+
/*
* Process group and session signals need to be delivered to just the
* parent before the fork or both the parent and the child after the
@@ -1935,10 +1941,7 @@ static __latent_entropy struct task_struct *copy_process(
retval = -ERESTARTNOINTR;
goto bad_fork_cancel_cgroup;
}
- if (unlikely(!(ns_of_pid(pid)->pid_allocated & PIDNS_ADDING))) {
- retval = -ENOMEM;
- goto bad_fork_cancel_cgroup;
- }
+
init_task_pid_links(p);
if (likely(p->pid)) {
--
2.17.1
^ permalink raw reply related
* [PATCH 11/20] signal: Pass pid type into send_sigio_to_task & send_sigurg_to_task
From: Eric W. Biederman @ 2018-07-24 3:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Andrew Morton, linux-kernel, Wen Yang, majiang,
Eric W. Biederman
In-Reply-To: <87efft5ncd.fsf_-_@xmission.com>
This information is already present and using it directly simplifies the logic
of the code.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
fs/fcntl.c | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 1523588fd759..5d596a00f40b 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -723,7 +723,7 @@ static inline int sigio_perm(struct task_struct *p,
static void send_sigio_to_task(struct task_struct *p,
struct fown_struct *fown,
- int fd, int reason, int group)
+ int fd, int reason, enum pid_type type)
{
/*
* F_SETSIG can change ->signum lockless in parallel, make
@@ -767,11 +767,11 @@ static void send_sigio_to_task(struct task_struct *p,
else
si.si_band = mangle_poll(band_table[reason - POLL_IN]);
si.si_fd = fd;
- if (!do_send_sig_info(signum, &si, p, group))
+ if (!do_send_sig_info(signum, &si, p, type != PIDTYPE_PID))
break;
/* fall-through: fall back on the old plain SIGIO signal */
case 0:
- do_send_sig_info(SIGIO, SEND_SIG_PRIV, p, group);
+ do_send_sig_info(SIGIO, SEND_SIG_PRIV, p, type != PIDTYPE_PID);
}
}
@@ -780,14 +780,10 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
struct task_struct *p;
enum pid_type type;
struct pid *pid;
- int group = 1;
read_lock(&fown->lock);
type = fown->pid_type;
- if (type == PIDTYPE_PID)
- group = 0;
-
pid = fown->pid;
if (!pid)
goto out_unlock_fown;
@@ -795,12 +791,12 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
if (type <= PIDTYPE_TGID) {
rcu_read_lock();
p = pid_task(pid, PIDTYPE_PID);
- send_sigio_to_task(p, fown, fd, band, group);
+ send_sigio_to_task(p, fown, fd, band, type);
rcu_read_unlock();
} else {
read_lock(&tasklist_lock);
do_each_pid_task(pid, type, p) {
- send_sigio_to_task(p, fown, fd, band, group);
+ send_sigio_to_task(p, fown, fd, band, type);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
}
@@ -809,10 +805,10 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
}
static void send_sigurg_to_task(struct task_struct *p,
- struct fown_struct *fown, int group)
+ struct fown_struct *fown, enum pid_type type)
{
if (sigio_perm(p, fown, SIGURG))
- do_send_sig_info(SIGURG, SEND_SIG_PRIV, p, group);
+ do_send_sig_info(SIGURG, SEND_SIG_PRIV, p, type != PIDTYPE_PID);
}
int send_sigurg(struct fown_struct *fown)
@@ -820,15 +816,11 @@ int send_sigurg(struct fown_struct *fown)
struct task_struct *p;
enum pid_type type;
struct pid *pid;
- int group = 1;
int ret = 0;
read_lock(&fown->lock);
type = fown->pid_type;
- if (type == PIDTYPE_PID)
- group = 0;
-
pid = fown->pid;
if (!pid)
goto out_unlock_fown;
@@ -838,12 +830,12 @@ int send_sigurg(struct fown_struct *fown)
if (type <= PIDTYPE_TGID) {
rcu_read_lock();
p = pid_task(pid, PIDTYPE_PID);
- send_sigurg_to_task(p, fown, group);
+ send_sigurg_to_task(p, fown, type);
rcu_read_unlock();
} else {
read_lock(&tasklist_lock);
do_each_pid_task(pid, type, p) {
- send_sigurg_to_task(p, fown, group);
+ send_sigurg_to_task(p, fown, type);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
}
--
2.17.1
^ permalink raw reply related
* [PATCH 14/20] signal: Push pid type down into __send_signal
From: Eric W. Biederman @ 2018-07-24 3:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Andrew Morton, linux-kernel, Wen Yang, majiang,
Eric W. Biederman
In-Reply-To: <87efft5ncd.fsf_-_@xmission.com>
This information is already available in the callers and by pushing it
down it makes the code a little clearer, and allows implementing
better handling of signales set to a group of processes in fork.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
kernel/signal.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 8decc70c1dc2..1ef94303d87a 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -998,7 +998,7 @@ static inline void userns_fixup_signal_uid(struct siginfo *info, struct task_str
#endif
static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
- int group, int from_ancestor_ns)
+ enum pid_type type, int from_ancestor_ns)
{
struct sigpending *pending;
struct sigqueue *q;
@@ -1012,7 +1012,7 @@ static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
from_ancestor_ns || (info == SEND_SIG_FORCED)))
goto ret;
- pending = group ? &t->signal->shared_pending : &t->pending;
+ pending = (type != PIDTYPE_PID) ? &t->signal->shared_pending : &t->pending;
/*
* Short-circuit ignored signals and support queuing
* exactly one non-rt signal, so that we can get more
@@ -1096,9 +1096,9 @@ static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
out_set:
signalfd_notify(t, sig);
sigaddset(&pending->signal, sig);
- complete_signal(sig, t, group);
+ complete_signal(sig, t, type != PIDTYPE_PID);
ret:
- trace_signal_generate(sig, info, t, group, result);
+ trace_signal_generate(sig, info, t, type != PIDTYPE_PID, result);
return ret;
}
@@ -1112,7 +1112,7 @@ static int send_signal(int sig, struct siginfo *info, struct task_struct *t,
!task_pid_nr_ns(current, task_active_pid_ns(t));
#endif
- return __send_signal(sig, info, t, type != PIDTYPE_PID, from_ancestor_ns);
+ return __send_signal(sig, info, t, type, from_ancestor_ns);
}
static void print_fatal_signal(int signr)
@@ -1377,7 +1377,7 @@ int kill_pid_info_as_cred(int sig, struct siginfo *info, struct pid *pid,
if (sig) {
if (lock_task_sighand(p, &flags)) {
- ret = __send_signal(sig, info, p, 1, 0);
+ ret = __send_signal(sig, info, p, PIDTYPE_TGID, 0);
unlock_task_sighand(p, &flags);
} else
ret = -ESRCH;
--
2.17.1
^ permalink raw reply related
* [PATCH 19/20] fork: Have new threads join on-going signal group stops
From: Eric W. Biederman @ 2018-07-24 3:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Andrew Morton, linux-kernel, Wen Yang, majiang,
Eric W. Biederman
In-Reply-To: <87efft5ncd.fsf_-_@xmission.com>
There are only two signals that are delivered to every member of a
signal group: SIGSTOP and SIGKILL. Signal delivery requires every
signal appear to be delivered either before or after a clone syscall.
SIGKILL terminates the clone so does not need to be considered. Which
leaves only SIGSTOP that needs to be considered when creating new
threads.
Today in the event of a group stop TIF_SIGPENDING will get set and the
fork will restart ensuring the fork syscall participates in the group
stop.
A fork (especially of a process with a lot of memory) is one of the
most expensive system so we really only want to restart a fork when
necessary.
It is easy so check to see if a SIGSTOP is ongoing have have the new
thread join it immediate after the clone completes. Making it appear
the clone completed happened just before the SIGSTOP.
The calculate_sigpending function will see the bits set in jobctl and
set TIF_SIGPENDING to ensure the new task takes the slow path to userspace.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
include/linux/sched/signal.h | 2 ++
kernel/fork.c | 27 +++++++++++++++------------
kernel/signal.c | 14 ++++++++++++++
3 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
index 7cabc0bc38f6..f3507bf165d0 100644
--- a/include/linux/sched/signal.h
+++ b/include/linux/sched/signal.h
@@ -385,6 +385,8 @@ static inline void ptrace_signal_wake_up(struct task_struct *t, bool resume)
signal_wake_up_state(t, resume ? __TASK_TRACED : 0);
}
+void task_join_group_stop(struct task_struct *task);
+
#ifdef TIF_RESTORE_SIGMASK
/*
* Legacy restore_sigmask accessors. These are inefficient on
diff --git a/kernel/fork.c b/kernel/fork.c
index e07281254552..6c358846a8b8 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1934,18 +1934,20 @@ static __latent_entropy struct task_struct *copy_process(
goto bad_fork_cancel_cgroup;
}
- /*
- * Process group and session signals need to be delivered to just the
- * parent before the fork or both the parent and the child after the
- * fork. Restart if a signal comes in before we add the new process to
- * it's process group.
- * A fatal signal pending means that current will exit, so the new
- * thread can't slip out of an OOM kill (or normal SIGKILL).
- */
- recalc_sigpending();
- if (signal_pending(current)) {
- retval = -ERESTARTNOINTR;
- goto bad_fork_cancel_cgroup;
+ if (!(clone_flags & CLONE_THREAD)) {
+ /*
+ * Process group and session signals need to be delivered to just the
+ * parent before the fork or both the parent and the child after the
+ * fork. Restart if a signal comes in before we add the new process to
+ * it's process group.
+ * A fatal signal pending means that current will exit, so the new
+ * thread can't slip out of an OOM kill (or normal SIGKILL).
+ */
+ recalc_sigpending();
+ if (signal_pending(current)) {
+ retval = -ERESTARTNOINTR;
+ goto bad_fork_cancel_cgroup;
+ }
}
@@ -1986,6 +1988,7 @@ static __latent_entropy struct task_struct *copy_process(
&p->group_leader->thread_group);
list_add_tail_rcu(&p->thread_node,
&p->signal->thread_head);
+ task_join_group_stop(p);
}
attach_pid(p, PIDTYPE_PID);
calculate_sigpending(p);
diff --git a/kernel/signal.c b/kernel/signal.c
index f6687c7d7a8c..78e2d5d196f3 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -375,6 +375,20 @@ static bool task_participate_group_stop(struct task_struct *task)
return false;
}
+void task_join_group_stop(struct task_struct *task)
+{
+ /* Have the new thread join an on-going signal group stop */
+ unsigned long jobctl = current->jobctl;
+ if (jobctl & JOBCTL_STOP_PENDING) {
+ struct signal_struct *sig = current->signal;
+ unsigned long signr = jobctl & JOBCTL_STOP_SIGMASK;
+ unsigned long gstop = JOBCTL_STOP_PENDING | JOBCTL_STOP_CONSUME;
+ if (task_set_jobctl_pending(task, signr | gstop)) {
+ sig->group_stop_count++;
+ }
+ }
+}
+
/*
* allocate a new signal queue record
* - this may be called without locks if and only if t == current, otherwise an
--
2.17.1
^ permalink raw reply related
* [PATCH 17/20] fork: Unconditionally exit if a fatal signal is pending
From: Eric W. Biederman @ 2018-07-24 3:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Andrew Morton, linux-kernel, Wen Yang, majiang,
Eric W. Biederman
In-Reply-To: <87efft5ncd.fsf_-_@xmission.com>
In practice this does not change anything as testing for fatal_signal_pending
and exiting for with an error code duplicates the work of the next clause
which recalculates pending signals and then exits fork if any are pending.
In both cases the pending signal will trigger the slow path when existing
to userspace, and the fatal signal will cause do_exit to be called.
The advantage of making this a separate test is that it makes it clear
processing the fatal signal will terminate the fork, and it allows the
rest of the signal logic to be updated without fear that this important
case will be lost.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
kernel/fork.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index b9c54318a292..22d4cdb9a7ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1928,6 +1928,12 @@ static __latent_entropy struct task_struct *copy_process(
goto bad_fork_cancel_cgroup;
}
+ /* Let kill terminate clone/fork in the middle */
+ if (fatal_signal_pending(current)) {
+ retval = -EINTR;
+ goto bad_fork_cancel_cgroup;
+ }
+
/*
* Process group and session signals need to be delivered to just the
* parent before the fork or both the parent and the child after the
--
2.17.1
^ permalink raw reply related
* [PATCH 12/20] signal: Pass pid type into do_send_sig_info
From: Eric W. Biederman @ 2018-07-24 3:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Andrew Morton, linux-kernel, Wen Yang, majiang,
Eric W. Biederman
In-Reply-To: <87efft5ncd.fsf_-_@xmission.com>
This passes the information we already have at the call sight into
do_send_sig_info. Ultimately allowing for better handling of signals
sent to a group of processes during fork.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
drivers/tty/sysrq.c | 2 +-
fs/fcntl.c | 6 +++---
include/linux/signal.h | 2 +-
kernel/signal.c | 10 +++++-----
mm/oom_kill.c | 4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 6364890575ec..06ed20dd01ba 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -348,7 +348,7 @@ static void send_sig_all(int sig)
if (is_global_init(p))
continue;
- do_send_sig_info(sig, SEND_SIG_FORCED, p, true);
+ do_send_sig_info(sig, SEND_SIG_FORCED, p, PIDTYPE_MAX);
}
read_unlock(&tasklist_lock);
}
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 5d596a00f40b..a04accf6847f 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -767,11 +767,11 @@ static void send_sigio_to_task(struct task_struct *p,
else
si.si_band = mangle_poll(band_table[reason - POLL_IN]);
si.si_fd = fd;
- if (!do_send_sig_info(signum, &si, p, type != PIDTYPE_PID))
+ if (!do_send_sig_info(signum, &si, p, type))
break;
/* fall-through: fall back on the old plain SIGIO signal */
case 0:
- do_send_sig_info(SIGIO, SEND_SIG_PRIV, p, type != PIDTYPE_PID);
+ do_send_sig_info(SIGIO, SEND_SIG_PRIV, p, type);
}
}
@@ -808,7 +808,7 @@ static void send_sigurg_to_task(struct task_struct *p,
struct fown_struct *fown, enum pid_type type)
{
if (sigio_perm(p, fown, SIGURG))
- do_send_sig_info(SIGURG, SEND_SIG_PRIV, p, type != PIDTYPE_PID);
+ do_send_sig_info(SIGURG, SEND_SIG_PRIV, p, type);
}
int send_sigurg(struct fown_struct *fown)
diff --git a/include/linux/signal.h b/include/linux/signal.h
index d8f2bf3d41e6..fe125b0335f7 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -258,7 +258,7 @@ enum pid_type;
extern int next_signal(struct sigpending *pending, sigset_t *mask);
extern int do_send_sig_info(int sig, struct siginfo *info,
- struct task_struct *p, bool group);
+ struct task_struct *p, enum pid_type type);
extern int group_send_sig_info(int sig, struct siginfo *info,
struct task_struct *p, enum pid_type type);
extern int __group_send_sig_info(int, struct siginfo *, struct task_struct *);
diff --git a/kernel/signal.c b/kernel/signal.c
index c7527338fe9d..2c09e6143dd8 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1161,13 +1161,13 @@ specific_send_sig_info(int sig, struct siginfo *info, struct task_struct *t)
}
int do_send_sig_info(int sig, struct siginfo *info, struct task_struct *p,
- bool group)
+ enum pid_type type)
{
unsigned long flags;
int ret = -ESRCH;
if (lock_task_sighand(p, &flags)) {
- ret = send_signal(sig, info, p, group);
+ ret = send_signal(sig, info, p, type != PIDTYPE_PID);
unlock_task_sighand(p, &flags);
}
@@ -1284,7 +1284,7 @@ int group_send_sig_info(int sig, struct siginfo *info, struct task_struct *p,
rcu_read_unlock();
if (!ret && sig)
- ret = do_send_sig_info(sig, info, p, true);
+ ret = do_send_sig_info(sig, info, p, type);
return ret;
}
@@ -1448,7 +1448,7 @@ int send_sig_info(int sig, struct siginfo *info, struct task_struct *p)
if (!valid_signal(sig))
return -EINVAL;
- return do_send_sig_info(sig, info, p, false);
+ return do_send_sig_info(sig, info, p, PIDTYPE_PID);
}
#define __si_special(priv) \
@@ -3199,7 +3199,7 @@ do_send_specific(pid_t tgid, pid_t pid, int sig, struct siginfo *info)
* probe. No signal is actually delivered.
*/
if (!error && sig) {
- error = do_send_sig_info(sig, info, p, false);
+ error = do_send_sig_info(sig, info, p, PIDTYPE_PID);
/*
* If lock_task_sighand() failed we pretend the task
* dies after receiving the signal. The window is tiny,
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 84081e77bc51..2cc9b238368f 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -920,7 +920,7 @@ static void oom_kill_process(struct oom_control *oc, const char *message)
* in order to prevent the OOM victim from depleting the memory
* reserves from the user space under its control.
*/
- do_send_sig_info(SIGKILL, SEND_SIG_FORCED, victim, true);
+ do_send_sig_info(SIGKILL, SEND_SIG_FORCED, victim, PIDTYPE_TGID);
mark_oom_victim(victim);
pr_err("Killed process %d (%s) total-vm:%lukB, anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(victim), victim->comm, K(victim->mm->total_vm),
@@ -958,7 +958,7 @@ static void oom_kill_process(struct oom_control *oc, const char *message)
*/
if (unlikely(p->flags & PF_KTHREAD))
continue;
- do_send_sig_info(SIGKILL, SEND_SIG_FORCED, p, true);
+ do_send_sig_info(SIGKILL, SEND_SIG_FORCED, p, PIDTYPE_TGID);
}
rcu_read_unlock();
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.