* Re: [PATCH v3] f2fs: issue discard align to section in LFS mode
From: Chao Yu @ 2018-07-24 2:40 UTC (permalink / raw)
To: Yunlong Song, jaegeuk, chao, yunlong.song
Cc: miaoxie, bintian.wang, shengyong1, heyunlei, linux-f2fs-devel,
linux-kernel
In-Reply-To: <1532005095-111878-1-git-send-email-yunlong.song@huawei.com>
On 2018/7/19 20:58, Yunlong Song wrote:
> For the case when sbi->segs_per_sec > 1 with lfs mode, take
> section:segment = 5 for example, if the section prefree_map is
> ...previous section | current section (1 1 0 1 1) | next section...,
> then the start = x, end = x + 1, after start = start_segno +
> sbi->segs_per_sec, start = x + 5, then it will skip x + 3 and x + 4, but
> their bitmap is still set, which will cause duplicated
> f2fs_issue_discard of this same section in the next write_checkpoint:
>
> round 1: section bitmap : 1 1 1 1 1, all valid, prefree_map: 0 0 0 0 0
> then rm data block NO.2, block NO.2 becomes invalid, prefree_map: 0 0 1 0 0
> write_checkpoint: section bitmap: 1 1 0 1 1, prefree_map: 0 0 0 0 0,
> prefree of NO.2 is cleared, and no discard issued
>
> round 2: rm data block NO.0, NO.1, NO.3, NO.4
> all invalid, but prefree bit of NO.2 is set and cleared in round 1, then
> prefree_map: 1 1 0 1 1
> write_checkpoint: section bitmap: 0 0 0 0 0, prefree_map: 0 0 0 1 1, no
> valid blocks of this section, so discard issued, but this time prefree
> bit of NO.3 and NO.4 is skipped due to start = start_segno + sbi->segs_per_sec;
>
> round 3:
> write_checkpoint: section bitmap: 0 0 0 0 0, prefree_map: 0 0 0 1 1 ->
> 0 0 0 0 0, no valid blocks of this section, so discard issued,
> this time prefree bit of NO.3 and NO.4 is cleared, but the discard of
> this section is sent again...
>
> To fix this problem, we can align the start and end value to section
> boundary for fstrim and real-time discard operation, and decide to issue
> discard only when the whole section is invalid, which can issue discard
> aligned to section size as much as possible and avoid redundant discard.
>
> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
> Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Thanks,
^ permalink raw reply
* Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge
From: D'Souza, Nelson @ 2018-07-24 1:43 UTC (permalink / raw)
To: David Ahern, netdev@vger.kernel.org
In-Reply-To: <51e237af-2db6-8905-22c9-9739f7d5a9b0@cumulusnetworks.com>
Hi David,
I copy and pasted the configs onto my device, but pings on test-vrf do not work in my setup.
I'm essentially seeing the same issue as I reported before.
In this case, pings sent out on test-vrf (host ns) are received and replied to by the loopback interface (foo ns). Although the replies are seen at the test-vrf level, they are not locally delivered to the ping application.
Logs are as follows...
a) pings on test-vrf or br0 fail.
# ping -I test-vrf 172.16.2.2 -c1 -w1
PING 172.16.2.2 (172.16.2.2): 56 data bytes
--- 172.16.2.2 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
b) tcpdump in the foo namespace, shows icmp echos/replies on veth2
# ip netns exec foo tcpdump -i veth2 icmp -c 2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:34:13.205210 IP 172.16.1.1 > 172.16.2.2: ICMP echo request, id 19513, seq 0, length 64
18:34:13.205253 IP 172.16.2.2 > 172.16.1.1: ICMP echo reply, id 19513, seq 0, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel
c) tcpdump in the host namespace, shows icmp echos/replies on test-vrf, br0 and veth1:
# tcpdump -i test-vrf icmp -c 2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on test-vrf, link-type EN10MB (Ethernet), capture size 262144 bytes
18:34:13.204061 IP 172.16.1.1 > 172.16.2.2: ICMP echo request, id 19513, seq 0, length 64
18:34:13.205278 IP 172.16.2.2 > 172.16.1.1: ICMP echo reply, id 19513, seq 0, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel
Thanks,
Nelson
On 7/23/18, 3:00 PM, "David Ahern" <dsa@cumulusnetworks.com> wrote:
On 7/20/18 1:03 PM, D'Souza, Nelson wrote:
> Setup is as follows:
>
> ethUSB(ingress port) -> mgmtbr0 (bridge) -> mgmtvrf (vrf)
| netns foo
[ test-vrf ] |
| |
[ br0 ] 172.16.1.1 |
| |
[ veth1 ] ============|======= [ veth2 ] lo
| 172.16.1.2 172.16.2.2
|
Copy and paste the following into your environment:
ip netns add foo
ip li add veth1 type veth peer name veth2
ip li set veth2 netns foo
ip -netns foo li set lo up
ip -netns foo li set veth2 up
ip -netns foo addr add 172.16.1.2/24 dev veth2
ip li add test-vrf type vrf table 123
ip li set test-vrf up
ip ro add vrf test-vrf unreachable default
ip li add br0 type bridge
ip li set veth1 master br0
ip li set veth1 up
ip li set br0 up
ip addr add dev br0 172.16.1.1/24
ip li set br0 master test-vrf
ip -netns foo addr add 172.16.2.2/32 dev lo
ip ro add vrf test-vrf 172.16.2.2/32 via 172.16.1.2
Does ping work?
# ping -I test-vrf 172.16.2.2
ping: Warning: source address might be selected on device other than
test-vrf.
PING 172.16.2.2 (172.16.2.2) from 172.16.1.1 test-vrf: 56(84) bytes of data.
64 bytes from 172.16.2.2: icmp_seq=1 ttl=64 time=0.228 ms
64 bytes from 172.16.2.2: icmp_seq=2 ttl=64 time=0.263 ms
and:
# ping -I br0 172.16.2.2
PING 172.16.2.2 (172.16.2.2) from 172.16.1.1 br0: 56(84) bytes of data.
64 bytes from 172.16.2.2: icmp_seq=1 ttl=64 time=0.227 ms
64 bytes from 172.16.2.2: icmp_seq=2 ttl=64 time=0.223 ms
^C
--- 172.16.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.223/0.225/0.227/0.002 ms
^ permalink raw reply
* [PATCH V4 2/7] mmc: sdhci: Change SDMA address register for v4 mode
From: Chunyan Zhang @ 2018-07-24 2:47 UTC (permalink / raw)
To: Ulf Hansson, Adrian Hunter
Cc: linux-mmc, linux-kernel, Orson Zhai, Baolin Wang, Billows Wu,
Jason Wu, zhang.lyra
In-Reply-To: <1532340508-8749-3-git-send-email-zhang.chunyan@linaro.org>
According to the SD host controller specification version 4.10, when
Host Version 4 is enabled, SDMA uses ADMA System Address register
(05Fh-058h) instead of using SDMA System Address register to
support both 32-bit and 64-bit addressing.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
---
drivers/mmc/host/sdhci.c | 31 +++++++++++++++++++++----------
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index cab5350..b7ad8e5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -729,7 +729,7 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
}
}
-static u32 sdhci_sdma_address(struct sdhci_host *host)
+static dma_addr_t sdhci_sdma_address(struct sdhci_host *host)
{
if (host->bounce_buffer)
return host->bounce_addr;
@@ -737,6 +737,18 @@ static u32 sdhci_sdma_address(struct sdhci_host *host)
return sg_dma_address(host->data->sg);
}
+static void sdhci_set_sdma_addr(struct sdhci_host *host, dma_addr_t addr)
+{
+ if (host->v4_mode) {
+ sdhci_writel(host, addr, SDHCI_ADMA_ADDRESS);
+ if (host->flags & SDHCI_USE_64_BIT_DMA)
+ sdhci_writel(host, (u64)addr >> 32, SDHCI_ADMA_ADDRESS_HI);
+ } else {
+ sdhci_writel(host, addr, SDHCI_DMA_ADDRESS);
+ }
+
+}
+
static unsigned int sdhci_target_timeout(struct sdhci_host *host,
struct mmc_command *cmd,
struct mmc_data *data)
@@ -996,8 +1008,7 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
SDHCI_ADMA_ADDRESS_HI);
} else {
WARN_ON(sg_cnt != 1);
- sdhci_writel(host, sdhci_sdma_address(host),
- SDHCI_DMA_ADDRESS);
+ sdhci_set_sdma_addr(host, sdhci_sdma_address(host));
}
}
@@ -2824,7 +2835,7 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
* some controllers are faulty, don't trust them.
*/
if (intmask & SDHCI_INT_DMA_END) {
- u32 dmastart, dmanow;
+ dma_addr_t dmastart, dmanow;
dmastart = sdhci_sdma_address(host);
dmanow = dmastart + host->data->bytes_xfered;
@@ -2832,12 +2843,12 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
* Force update to the next DMA block boundary.
*/
dmanow = (dmanow &
- ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1)) +
+ ~((dma_addr_t)SDHCI_DEFAULT_BOUNDARY_SIZE - 1)) +
SDHCI_DEFAULT_BOUNDARY_SIZE;
host->data->bytes_xfered = dmanow - dmastart;
- DBG("DMA base 0x%08x, transferred 0x%06x bytes, next 0x%08x\n",
- dmastart, host->data->bytes_xfered, dmanow);
- sdhci_writel(host, dmanow, SDHCI_DMA_ADDRESS);
+ DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
+ &dmastart, host->data->bytes_xfered, &dmanow);
+ sdhci_set_sdma_addr(host, dmanow);
}
if (intmask & SDHCI_INT_DATA_END) {
@@ -3581,8 +3592,8 @@ int sdhci_setup_host(struct sdhci_host *host)
}
}
- /* SDMA does not support 64-bit DMA */
- if (host->flags & SDHCI_USE_64_BIT_DMA)
+ /* SDMA does not support 64-bit DMA if v4 mode not set */
+ if ((host->flags & SDHCI_USE_64_BIT_DMA) && !host->v4_mode)
host->flags &= ~SDHCI_USE_SDMA;
if (host->flags & SDHCI_USE_ADMA) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] systemd: Allow custom coredump config options
From: ChenQi @ 2018-07-24 2:52 UTC (permalink / raw)
To: Alistair Francis, Andre McCurdy; +Cc: OE Core mailing list
In-Reply-To: <CAKmqyKNrUdU9wcUH8no9J_XNE=4ztujQ95tap7Zk5HBWv9XT9g@mail.gmail.com>
On 07/24/2018 07:16 AM, Alistair Francis wrote:
> On Wed, Jul 18, 2018 at 4:48 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Wed, Jul 18, 2018 at 3:53 PM, Alistair Francis
>> <alistair.francis@wdc.com> wrote:
>>> If the user has enabled coredump let's allow them to customise the
>>> config options.
>>>
>>> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
>>> ---
>>> meta/recipes-core/systemd/systemd_239.bb | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/meta/recipes-core/systemd/systemd_239.bb b/meta/recipes-core/systemd/systemd_239.bb
>>> index 7822548993..a625d060a9 100644
>>> --- a/meta/recipes-core/systemd/systemd_239.bb
>>> +++ b/meta/recipes-core/systemd/systemd_239.bb
>>> @@ -279,6 +279,18 @@ do_install() {
>>> chown polkitd:root ${D}${datadir}/polkit-1/rules.d
>>> fi
>>> fi
>>> +
>>> + # If coredump was enabled, enable it in the config.
>>> + # This just sets the default, but can be used to customise the values.
>>> + if ${@bb.utils.contains('PACKAGECONFIG', 'coredump', 'true', 'false', d)}; then
>>> + sed 's|#Storage.*|Storage=external|g' -i ${D}${sysconfdir}/systemd/coredump.conf
>>> + sed 's|#Compress.*|Compress=yes|g' -i ${D}${sysconfdir}/systemd/coredump.conf
>>> + sed 's|#ProcessSizeMax.*|ProcessSizeMax=2G|g' -i ${D}${sysconfdir}/systemd/coredump.conf
>>> + sed 's|#ExternalSizeMax.*|ExternalSizeMax=2G|g' -i ${D}${sysconfdir}/systemd/coredump.conf
>>> + sed 's|#JournalSizeMax.*|JournalSizeMax=767M|g' -i ${D}${sysconfdir}/systemd/coredump.conf
>>> + sed 's|#MaxUse.*|MaxUse=|g' -i ${D}${sysconfdir}/systemd/coredump.conf
>>> + sed 's|#KeepFree.*|KeepFree=|g' -i ${D}${sysconfdir}/systemd/coredump.conf
>> How does this allow the user to customise the config options?
> They can edit the sed command line and have different options.
>
>> By forcing the options to the _current_ default values you are
>> creating a maintenance problem - ie you'll still be forcing these
>> values even if/when the upstream defaults are changed.
> That is a good point, is there a usual way to allow edits to config
> files like this?
>
> Alistair
>
It depends on what package you are modifying, as different packages have
different ways to handle their configuration. It also depends on what
configuration you are going to customize, maybe the config customization
is generally wanted by most users, maybe it's not.
Back to this systemd coredump case, the best way to customize things is
to drop in configuration files to /etc/systemd/coredump.conf.d/ via
bbappend.
https://www.freedesktop.org/software/systemd/man/coredump.conf.html
Best Regards,
Chen Qi
>>> + fi
>>> }
>>>
>>>
>>> --
>>> 2.17.1
>>>
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
From: Sergey Senozhatsky @ 2018-07-24 2:53 UTC (permalink / raw)
To: Minchan Kim
Cc: Tino Lehnig, ngupta, linux-kernel, Sergey Senozhatsky,
Andrew Morton
In-Reply-To: <20180724010342.GA195675@rodete-desktop-imager.corp.google.com>
On (07/24/18 10:03), Minchan Kim wrote:
> On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> > Hello,
> >
> > after enabling the writeback feature in zram, I encountered the kernel bug
> > below with heavy swap utilization. There is one specific workload that
> > triggers the bug reliably and that is running Windows in KVM while
> > overcommitting memory. The Windows VMs would fill all allocated memory with
> > zero pages while booting. A few seconds after the host hits zram swap, the
> > console on the host is flooded with the bug message. A few more seconds
> > later I also encountered filesystem errors on the host causing the root
> > filesystem to be mounted read-only. The filesystem errors do not occur when
> > leaving RAM available for the host OS by limiting physical memory of the
> > QEMU processes via cgroups.
> >
> > I started three KVM instances with the following commands in my tests. Any
> > Windows ISO or disk image can be used. Less instances and smaller allocated
> > memory will also trigger the bug as long as swapping occurs. The type of
> > writeback device does not seem to matter. I have tried a SATA SSD and an
> > NVMe Optane drive so far. My test machine has 256 GB of RAM and one CPU. I
> > saw the same behavior on another machine with two CPUs and 128 GB of RAM.
> >
> > The bug does not occur when using zram as swap without "backing_dev" being
> > set, but I had even more severe problems when running the same test on
> > Ubuntu Kernels 4.15 and 4.17. Regardless of the writeback feature being used
> > or not, the host would eventually lock up entirely when swap is in use on
> > zram. The lockups may not be related directly to zram though and were
> > apparently fixed in 4.18. I had absolutely no problems on Ubuntu Kernel 4.13
> > either, before the writeback feature was introduced.
>
> We didn't release v4.18 yet. Could you say what kernel tree/what version
> you used?
>
> Now I don't have enough time to dig in.
>
> Sergey, I really appreciate if you could have availabe time to look into.
> Anyway, I could try to see it asap if Sergey is not available.
> No worry.
Interesting case.
Will take me several days to get to it.
Sorry, quite busy at the moment.
-ss
^ permalink raw reply
* [PATCH V4 4/7] mmc: sdhci: add 32-bit block count support for v4 mode
From: Chunyan Zhang @ 2018-07-24 2:51 UTC (permalink / raw)
To: Ulf Hansson, Adrian Hunter
Cc: linux-mmc, linux-kernel, Orson Zhai, Baolin Wang, Billows Wu,
Jason Wu, zhang.lyra
In-Reply-To: <1532340508-8749-5-git-send-email-zhang.chunyan@linaro.org>
Host Controller Version 4.10 re-defines SDMA System Address register
as 32-bit Block Count for v4 mode, and SDMA uses ADMA System
Address register (05Fh-058h) instead if v4 mode is enabled. Also
when using 32-bit block count, 16-bit block count register need
to be set to zero.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
---
drivers/mmc/host/sdhci.c | 14 +++++++++++++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 920d8ec..c272a2b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1070,7 +1070,19 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
/* Set the DMA boundary value and block size */
sdhci_writew(host, SDHCI_MAKE_BLKSZ(host->sdma_boundary, data->blksz),
SDHCI_BLOCK_SIZE);
- sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
+
+ /*
+ * For Version 4.10 onwards, if v4 mode is enabled, 16-bit Block Count
+ * register need to be set to zero, 32-bit Block Count register would
+ * be selected.
+ */
+ if (host->version >= SDHCI_SPEC_410 && host->v4_mode) {
+ if (sdhci_readw(host, SDHCI_BLOCK_COUNT))
+ sdhci_writew(host, 0, SDHCI_BLOCK_COUNT);
+ sdhci_writew(host, data->blocks, SDHCI_32BIT_BLK_CNT);
+ } else {
+ sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
+ }
}
static inline bool sdhci_auto_cmd12(struct sdhci_host *host,
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 23318ff..81aae07 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -28,6 +28,7 @@
#define SDHCI_DMA_ADDRESS 0x00
#define SDHCI_ARGUMENT2 SDHCI_DMA_ADDRESS
+#define SDHCI_32BIT_BLK_CNT SDHCI_DMA_ADDRESS
#define SDHCI_BLOCK_SIZE 0x04
#define SDHCI_MAKE_BLKSZ(dma, blksz) (((dma & 0x7) << 12) | (blksz & 0xFFF))
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] block: zram: Replace GFP_ATOMIC with GFP_KERNEL
From: Sergey Senozhatsky @ 2018-07-24 2:52 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: minchan, ngupta, sergey.senozhatsky.work, axboe, linux-kernel,
linux-block, Andrew Morton
In-Reply-To: <20180723141304.3300-1-baijiaju1990@gmail.com>
On (07/23/18 22:13), Jia-Ju Bai wrote:
> read_from_bdev_async() and write_to_bdev() are never called in atomic
> context. They call bio_alloc() with GFP_ATOMIC, which is not necessary.
> GFP_ATOMIC can be replaced with GFP_KERNEL.
[..]
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 0f3fadd71230..b958ed0b8c35 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -450,7 +450,7 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec,
> {
> struct bio *bio;
>
> - bio = bio_alloc(GFP_ATOMIC, 1);
> + bio = bio_alloc(GFP_KERNEL, 1);
> if (!bio)
> return -ENOMEM;
>
> @@ -538,7 +538,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec *bvec,
> struct bio *bio;
> unsigned long entry;
>
> - bio = bio_alloc(GFP_ATOMIC, 1);
> + bio = bio_alloc(GFP_KERNEL, 1);
> if (!bio)
> return -ENOMEM;
I think the intent here is different and is not related to atomic
contexts.
Consider the following
OMM -> swapout -> __zram_bvec_write() -> write_to_bdev() -> bio_alloc(GFP_KERNEL) -> [OOM?]
So maybe we can do a bit better than GFP_ATOMIC (NOIO, etc.), but in general,
I believe, we can't use GFP_KERNEL [at least in write_to_bdev()].
-ss
^ permalink raw reply
* Re: [PATCH v3 bpf-next 2/8] veth: Add driver XDP
From: Toshiaki Makita @ 2018-07-24 1:47 UTC (permalink / raw)
To: Jakub Kicinski, Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180723172324.248c4dc9@cakuba.netronome.com>
Hi Jakub,
Thanks for reviewing!
On 2018/07/24 9:23, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:02 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> This is the basic implementation of veth driver XDP.
>>
>> Incoming packets are sent from the peer veth device in the form of skb,
>> so this is generally doing the same thing as generic XDP.
>>
>> This itself is not so useful, but a starting point to implement other
>> useful veth XDP features like TX and REDIRECT.
>>
>> This introduces NAPI when XDP is enabled, because XDP is now heavily
>> relies on NAPI context. Use ptr_ring to emulate NIC ring. Tx function
>> enqueues packets to the ring and peer NAPI handler drains the ring.
>>
>> Currently only one ring is allocated for each veth device, so it does
>> not scale on multiqueue env. This can be resolved by allocating rings
>> on the per-queue basis later.
>>
>> Note that NAPI is not used but netif_rx is used when XDP is not loaded,
>> so this does not change the default behaviour.
>>
>> v3:
>> - Fix race on closing the device.
>> - Add extack messages in ndo_bpf.
>>
>> v2:
>> - Squashed with the patch adding NAPI.
>> - Implement adjust_tail.
>> - Don't acquire consumer lock because it is guarded by NAPI.
>> - Make poll_controller noop since it is unnecessary.
>> - Register rxq_info on enabling XDP rather than on opening the device.
>>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
>> +static struct sk_buff *veth_xdp_rcv_skb(struct veth_priv *priv,
>> + struct sk_buff *skb)
>> +{
>> + u32 pktlen, headroom, act, metalen;
>> + void *orig_data, *orig_data_end;
>> + int size, mac_len, delta, off;
>> + struct bpf_prog *xdp_prog;
>> + struct xdp_buff xdp;
>> +
>> + rcu_read_lock();
>> + xdp_prog = rcu_dereference(priv->xdp_prog);
>> + if (unlikely(!xdp_prog)) {
>> + rcu_read_unlock();
>> + goto out;
>> + }
>> +
>> + mac_len = skb->data - skb_mac_header(skb);
>> + pktlen = skb->len + mac_len;
>> + size = SKB_DATA_ALIGN(VETH_XDP_HEADROOM + pktlen) +
>> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> + if (size > PAGE_SIZE)
>> + goto drop;
>> +
>> + headroom = skb_headroom(skb) - mac_len;
>> + if (skb_shared(skb) || skb_head_is_locked(skb) ||
>> + skb_is_nonlinear(skb) || headroom < XDP_PACKET_HEADROOM) {
>> + struct sk_buff *nskb;
>> + void *head, *start;
>> + struct page *page;
>> + int head_off;
>> +
>> + page = alloc_page(GFP_ATOMIC);
>> + if (!page)
>> + goto drop;
>> +
>> + head = page_address(page);
>> + start = head + VETH_XDP_HEADROOM;
>> + if (skb_copy_bits(skb, -mac_len, start, pktlen)) {
>> + page_frag_free(head);
>> + goto drop;
>> + }
>> +
>> + nskb = veth_build_skb(head,
>> + VETH_XDP_HEADROOM + mac_len, skb->len,
>> + PAGE_SIZE);
>> + if (!nskb) {
>> + page_frag_free(head);
>> + goto drop;
>> + }
>
>> +static int veth_enable_xdp(struct net_device *dev)
>> +{
>> + struct veth_priv *priv = netdev_priv(dev);
>> + int err;
>> +
>> + if (!xdp_rxq_info_is_reg(&priv->xdp_rxq)) {
>> + err = xdp_rxq_info_reg(&priv->xdp_rxq, dev, 0);
>> + if (err < 0)
>> + return err;
>> +
>> + err = xdp_rxq_info_reg_mem_model(&priv->xdp_rxq,
>> + MEM_TYPE_PAGE_SHARED, NULL);
>
> nit: doesn't matter much but looks like a mix of MEM_TYPE_PAGE_SHARED
> and MEM_TYPE_PAGE_ORDER0
Actually I'm not sure when to use MEM_TYPE_PAGE_ORDER0. It seems a page
allocated by alloc_page() can be freed by page_frag_free() and it is
more lightweight than put_page(), isn't it?
virtio_net is doing it in a similar way.
--
Toshiaki Makita
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t v7] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
From: Dhinakaran Pandiyan @ 2018-07-24 2:52 UTC (permalink / raw)
To: Radhakrishna Sripada, igt-dev; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <20180723182545.19461-1-radhakrishna.sripada@intel.com>
On Mon, 2018-07-23 at 11:25 -0700, Radhakrishna Sripada wrote:
> From: Anusha Srivatsa <anusha.srivatsa@intel.com>
>
> Cleanup the testcases by moving the platform checks to a single
> function.
>
> The earlier version of the path is posted here [1]
>
> v2: Make use of the property enums to get the supported rotations
> v3: Move hardcodings to a single function(Ville)
> v4: Include the cherryview exception for reflect subtest(Maarten)
> v5: Rebase and move the check from CNL to ICL for reflect-x case
> v6: Fix the CI regression
> v7: rebase
>
> [1]: https://patchwork.freedesktop.org/patch/209647/
>
Oh well, I wrote my comments below and then read this link. Please add
new test requirements in separate patches. Only have the code movement
here.
> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> ---
> tests/kms_rotation_crc.c | 35 ++++++++++++++++++++---------------
> 1 file changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> index 6cb5858adb0f..f20b8a6d4ba1 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -43,6 +43,7 @@ typedef struct {
> uint32_t override_fmt;
> uint64_t override_tiling;
> int devid;
> + int gen;
> } data_t;
>
> typedef struct {
> @@ -284,6 +285,17 @@ static void prepare_fbs(data_t *data,
> igt_output_t *output,
> igt_plane_set_position(plane, data->pos_x, data-
> >pos_y);
> }
>
> +static void igt_check_rotation(data_t *data)
> +{
> + if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
> + igt_require(data->gen >= 9);
> + if (data->rotation & IGT_REFLECT_X)
> + igt_require(data->gen >= 11 ||
This check used to be igt_require(gen >= 10
> + (IS_CHERRYVIEW(data->devid) && (data-
> >rotation & IGT_ROTATION_0)));
There was also a check for tiling format
- (IS_CHERRYVIEW(data.devid) &&
reflect_x->rot == IGT_ROTATION_0
- && reflect_x->tiling ==
LOCAL_I915_FORMAT_MOD_X_TILED));
> + if (data->rotation & IGT_ROTATION_180)
> + igt_require(data->gen >= 4);
Doesn't look like this requirement was is in the test earlier.
> +}
> +
> static void test_single_case(data_t *data, enum pipe pipe,
> igt_output_t *output, igt_plane_t
> *plane,
> enum rectangle_type rect,
> @@ -352,15 +364,18 @@ static void test_plane_rotation(data_t *data,
> int plane_type, bool test_bad_form
>
> igt_display_require_output(display);
>
> + igt_check_rotation(data);
> +
> for_each_pipe_with_valid_output(display, pipe, output) {
> igt_plane_t *plane;
> int i, j;
>
> - if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
> - continue;
> -
> igt_output_set_pipe(output, pipe);
>
> + if (IS_CHERRYVIEW(data->devid) && (data->rotation &
> IGT_REFLECT_X) &&
> + pipe != kmstest_pipe_to_index('B'))
> + continue;
> +
Why do this?
> plane = igt_output_get_plane_type(output,
> plane_type);
> igt_require(igt_plane_has_prop(plane,
> IGT_PLANE_ROTATION));
>
> @@ -521,14 +536,13 @@ igt_main
> };
>
> data_t data = {};
> - int gen = 0;
>
> igt_skip_on_simulation();
>
> igt_fixture {
> data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
> data.devid = intel_get_drm_devid(data.gfx_fd);
> - gen = intel_gen(data.devid);
> + data.gen = intel_gen(data.devid);
>
> kmstest_set_vt_graphics_mode();
>
> @@ -541,16 +555,12 @@ igt_main
> igt_subtest_f("%s-rotation-%s",
> plane_test_str(subtest->plane),
> rot_test_str(subtest->rot)) {
> - igt_require(!(subtest->rot &
> - (IGT_ROTATION_90 |
> IGT_ROTATION_270)) ||
> - gen >= 9);
> data.rotation = subtest->rot;
> test_plane_rotation(&data, subtest->plane,
> false);
> }
> }
>
> igt_subtest_f("sprite-rotation-90-pos-100-0") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.pos_x = 100,
> data.pos_y = 0;
> @@ -560,7 +570,6 @@ igt_main
> data.pos_y = 0;
>
> igt_subtest_f("bad-pixel-format") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.override_fmt = DRM_FORMAT_RGB565;
> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY,
> true);
> @@ -568,7 +577,6 @@ igt_main
> data.override_fmt = 0;
>
> igt_subtest_f("bad-tiling") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.override_tiling =
> LOCAL_I915_FORMAT_MOD_X_TILED;
> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY,
> true);
> @@ -579,9 +587,6 @@ igt_main
> igt_subtest_f("primary-%s-reflect-x-%s",
> tiling_test_str(reflect_x->tiling),
> rot_test_str(reflect_x->rot)) {
> - igt_require(gen >= 10 ||
> - (IS_CHERRYVIEW(data.devid) &&
> reflect_x->rot == IGT_ROTATION_0
> - && reflect_x->tiling ==
> LOCAL_I915_FORMAT_MOD_X_TILED));
> data.rotation = (IGT_REFLECT_X | reflect_x-
> >rot);
> data.override_tiling = reflect_x->tiling;
> test_plane_rotation(&data,
> DRM_PLANE_TYPE_PRIMARY, false);
> @@ -596,7 +601,7 @@ igt_main
> enum pipe pipe;
> igt_output_t *output;
>
> - igt_require(gen >= 9);
> + igt_require(data.gen >= 9);
> igt_display_require_output(&data.display);
>
> for_each_pipe_with_valid_output(&data.display, pipe,
> output) {
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v7] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
From: Dhinakaran Pandiyan @ 2018-07-24 2:52 UTC (permalink / raw)
To: Radhakrishna Sripada, igt-dev; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <20180723182545.19461-1-radhakrishna.sripada@intel.com>
On Mon, 2018-07-23 at 11:25 -0700, Radhakrishna Sripada wrote:
> From: Anusha Srivatsa <anusha.srivatsa@intel.com>
>
> Cleanup the testcases by moving the platform checks to a single
> function.
>
> The earlier version of the path is posted here [1]
>
> v2: Make use of the property enums to get the supported rotations
> v3: Move hardcodings to a single function(Ville)
> v4: Include the cherryview exception for reflect subtest(Maarten)
> v5: Rebase and move the check from CNL to ICL for reflect-x case
> v6: Fix the CI regression
> v7: rebase
>
> [1]: https://patchwork.freedesktop.org/patch/209647/
>
Oh well, I wrote my comments below and then read this link. Please add
new test requirements in separate patches. Only have the code movement
here.
> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> ---
> tests/kms_rotation_crc.c | 35 ++++++++++++++++++++---------------
> 1 file changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> index 6cb5858adb0f..f20b8a6d4ba1 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -43,6 +43,7 @@ typedef struct {
> uint32_t override_fmt;
> uint64_t override_tiling;
> int devid;
> + int gen;
> } data_t;
>
> typedef struct {
> @@ -284,6 +285,17 @@ static void prepare_fbs(data_t *data,
> igt_output_t *output,
> igt_plane_set_position(plane, data->pos_x, data-
> >pos_y);
> }
>
> +static void igt_check_rotation(data_t *data)
> +{
> + if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
> + igt_require(data->gen >= 9);
> + if (data->rotation & IGT_REFLECT_X)
> + igt_require(data->gen >= 11 ||
This check used to be igt_require(gen >= 10
> + (IS_CHERRYVIEW(data->devid) && (data-
> >rotation & IGT_ROTATION_0)));
There was also a check for tiling format
- (IS_CHERRYVIEW(data.devid) &&
reflect_x->rot == IGT_ROTATION_0
- && reflect_x->tiling ==
LOCAL_I915_FORMAT_MOD_X_TILED));
> + if (data->rotation & IGT_ROTATION_180)
> + igt_require(data->gen >= 4);
Doesn't look like this requirement was is in the test earlier.
> +}
> +
> static void test_single_case(data_t *data, enum pipe pipe,
> igt_output_t *output, igt_plane_t
> *plane,
> enum rectangle_type rect,
> @@ -352,15 +364,18 @@ static void test_plane_rotation(data_t *data,
> int plane_type, bool test_bad_form
>
> igt_display_require_output(display);
>
> + igt_check_rotation(data);
> +
> for_each_pipe_with_valid_output(display, pipe, output) {
> igt_plane_t *plane;
> int i, j;
>
> - if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
> - continue;
> -
> igt_output_set_pipe(output, pipe);
>
> + if (IS_CHERRYVIEW(data->devid) && (data->rotation &
> IGT_REFLECT_X) &&
> + pipe != kmstest_pipe_to_index('B'))
> + continue;
> +
Why do this?
> plane = igt_output_get_plane_type(output,
> plane_type);
> igt_require(igt_plane_has_prop(plane,
> IGT_PLANE_ROTATION));
>
> @@ -521,14 +536,13 @@ igt_main
> };
>
> data_t data = {};
> - int gen = 0;
>
> igt_skip_on_simulation();
>
> igt_fixture {
> data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
> data.devid = intel_get_drm_devid(data.gfx_fd);
> - gen = intel_gen(data.devid);
> + data.gen = intel_gen(data.devid);
>
> kmstest_set_vt_graphics_mode();
>
> @@ -541,16 +555,12 @@ igt_main
> igt_subtest_f("%s-rotation-%s",
> plane_test_str(subtest->plane),
> rot_test_str(subtest->rot)) {
> - igt_require(!(subtest->rot &
> - (IGT_ROTATION_90 |
> IGT_ROTATION_270)) ||
> - gen >= 9);
> data.rotation = subtest->rot;
> test_plane_rotation(&data, subtest->plane,
> false);
> }
> }
>
> igt_subtest_f("sprite-rotation-90-pos-100-0") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.pos_x = 100,
> data.pos_y = 0;
> @@ -560,7 +570,6 @@ igt_main
> data.pos_y = 0;
>
> igt_subtest_f("bad-pixel-format") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.override_fmt = DRM_FORMAT_RGB565;
> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY,
> true);
> @@ -568,7 +577,6 @@ igt_main
> data.override_fmt = 0;
>
> igt_subtest_f("bad-tiling") {
> - igt_require(gen >= 9);
> data.rotation = IGT_ROTATION_90;
> data.override_tiling =
> LOCAL_I915_FORMAT_MOD_X_TILED;
> test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY,
> true);
> @@ -579,9 +587,6 @@ igt_main
> igt_subtest_f("primary-%s-reflect-x-%s",
> tiling_test_str(reflect_x->tiling),
> rot_test_str(reflect_x->rot)) {
> - igt_require(gen >= 10 ||
> - (IS_CHERRYVIEW(data.devid) &&
> reflect_x->rot == IGT_ROTATION_0
> - && reflect_x->tiling ==
> LOCAL_I915_FORMAT_MOD_X_TILED));
> data.rotation = (IGT_REFLECT_X | reflect_x-
> >rot);
> data.override_tiling = reflect_x->tiling;
> test_plane_rotation(&data,
> DRM_PLANE_TYPE_PRIMARY, false);
> @@ -596,7 +601,7 @@ igt_main
> enum pipe pipe;
> igt_output_t *output;
>
> - igt_require(gen >= 9);
> + igt_require(data.gen >= 9);
> igt_display_require_output(&data.display);
>
> for_each_pipe_with_valid_output(&data.display, pipe,
> output) {
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 1/5] f2fs: clear victim_secmap when section has full valid blocks
From: Chao Yu @ 2018-07-24 2:52 UTC (permalink / raw)
To: Yunlong Song, jaegeuk, chao, yunlong.song
Cc: miaoxie, bintian.wang, shengyong1, heyunlei, linux-f2fs-devel,
linux-kernel
In-Reply-To: <1532355022-163029-2-git-send-email-yunlong.song@huawei.com>
On 2018/7/23 22:10, Yunlong Song wrote:
> Without this patch, f2fs only clears victim_secmap when it finds out
> that the section has no valid blocks at all, but forgets to clear the
> victim_secmap when the whole section has full valid blocks.
>
> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
> ---
> fs/f2fs/segment.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index cfff7cf..255bff5 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -776,7 +776,9 @@ static void __remove_dirty_segment(struct f2fs_sb_info *sbi, unsigned int segno,
> if (test_and_clear_bit(segno, dirty_i->dirty_segmap[t]))
> dirty_i->nr_dirty[t]--;
>
> - if (get_valid_blocks(sbi, segno, true) == 0)
> + if (get_valid_blocks(sbi, segno, true) == 0 ||
> + get_valid_blocks(sbi, segno, true) ==
> + (sbi->segs_per_sec << sbi->log_blocks_per_seg))
BLKS_PER_SEC(sbi)?
Thanks,
> clear_bit(GET_SEC_FROM_SEG(sbi, segno),
> dirty_i->victim_secmap);
> }
>
^ permalink raw reply
* Re: [PATCH 1/5] f2fs: clear victim_secmap when section has full valid blocks
From: Chao Yu @ 2018-07-24 2:52 UTC (permalink / raw)
To: Yunlong Song, jaegeuk, chao, yunlong.song
Cc: miaoxie, bintian.wang, shengyong1, heyunlei, linux-f2fs-devel,
linux-kernel
In-Reply-To: <1532355022-163029-2-git-send-email-yunlong.song@huawei.com>
On 2018/7/23 22:10, Yunlong Song wrote:
> Without this patch, f2fs only clears victim_secmap when it finds out
> that the section has no valid blocks at all, but forgets to clear the
> victim_secmap when the whole section has full valid blocks.
>
> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
> ---
> fs/f2fs/segment.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index cfff7cf..255bff5 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -776,7 +776,9 @@ static void __remove_dirty_segment(struct f2fs_sb_info *sbi, unsigned int segno,
> if (test_and_clear_bit(segno, dirty_i->dirty_segmap[t]))
> dirty_i->nr_dirty[t]--;
>
> - if (get_valid_blocks(sbi, segno, true) == 0)
> + if (get_valid_blocks(sbi, segno, true) == 0 ||
> + get_valid_blocks(sbi, segno, true) ==
> + (sbi->segs_per_sec << sbi->log_blocks_per_seg))
BLKS_PER_SEC(sbi)?
Thanks,
> clear_bit(GET_SEC_FROM_SEG(sbi, segno),
> dirty_i->victim_secmap);
> }
>
^ 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 2:53 UTC (permalink / raw)
To: Tonghao Zhang
Cc: Linux Kernel Network Developers, toshiaki.makita1, virtualization,
mst
In-Reply-To: <CAMDZJNXWs+yqAcZ-7gW6RQjen0-mzfJ-Ar-O0_wttse2A-3-HQ@mail.gmail.com>
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.
--
Toshiaki Makita
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] xfs_db: add -d to short help for write command
From: Darrick J. Wong @ 2018-07-24 1:49 UTC (permalink / raw)
To: Eric Sandeen; +Cc: linux-xfs
In-Reply-To: <fba33a51-50c1-ade6-79d2-f7ceaceb372f@redhat.com>
On Mon, Jul 23, 2018 at 06:25:27PM -0700, Eric Sandeen wrote:
> And note in the man page that -c and -d are exclusive.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Looks ok,
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
--D
> ---
>
> diff --git a/db/write.c b/db/write.c
> index 5ef76bcd..bbaa609d 100644
> --- a/db/write.c
> +++ b/db/write.c
> @@ -38,7 +38,7 @@ static int write_f(int argc, char **argv);
> static void write_help(void);
>
> static const cmdinfo_t write_cmd =
> - { "write", NULL, write_f, 0, -1, 0, N_("[-c] [field or value]..."),
> + { "write", NULL, write_f, 0, -1, 0, N_("[-c|-d] [field or value]..."),
> N_("write value to disk"), write_help };
>
> void
> diff --git a/man/man8/xfs_db.8 b/man/man8/xfs_db.8
> index 10f2beb9..a1ee3514 100644
> --- a/man/man8/xfs_db.8
> +++ b/man/man8/xfs_db.8
> @@ -837,7 +837,7 @@ and
> bits respectively, and their string equivalent reported
> (but no modifications are made).
> .TP
> -.BI "write [\-c] [\-d] [" "field value" "] ..."
> +.BI "write [\-c|\-d] [" "field value" "] ..."
> Write a value to disk.
> Specific fields can be set in structures (struct mode),
> or a block can be set to data values (data mode),
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" 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
* [PATCH bpf-next] bpf: btf: fix inconsistent IS_ERR and PTR_ERR
From: YueHaibing @ 2018-07-24 2:55 UTC (permalink / raw)
To: ast, daniel, quentin.monnet, jakub.kicinski, bhole_prashant_q7,
osk
Cc: linux-kernel, netdev, davem, YueHaibing
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>
---
tools/bpf/bpftool/map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 9c81918..0ee3ba4 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -230,7 +230,7 @@ static int get_btf(struct bpf_map_info *map_info, struct btf **btf)
*btf = btf__new((__u8 *)btf_info.btf, btf_info.btf_size, NULL);
if (IS_ERR(*btf)) {
- err = PTR_ERR(btf);
+ err = PTR_ERR(*btf);
*btf = NULL;
}
--
2.7.0
^ permalink raw reply related
* [LTP] [RFC PATCH 1/1] pounder21: Remove
From: Li Wang @ 2018-07-24 2:57 UTC (permalink / raw)
To: ltp
In-Reply-To: <1784802899.35188200.1532349973680.JavaMail.zimbra@redhat.com>
On Mon, Jul 23, 2018 at 8:46 PM, Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
> > It's is obsolete, not being built.
>
> I think Li runs this internally.
>
I occasionally use the pounder suit as a stress test to run more than 24
hours.
But I'm OK to remove it from the latest ltp because it has long time no
substantive updating and the version I used is always ltp-full-20150903.
>
> [adding Hanns/IBM]
>
> I've seen pounder mentioned in RH BZs, though I'm not sure
> if LTP is the origin of pounder version that's used.
>
> Regards,
> Jan
>
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20180724/334770b1/attachment.html>
^ permalink raw reply
* Re: [Openvpn-devel] Dynamic challenge/response questions
From: Jonathan K. Bullard @ 2018-07-24 2:58 UTC (permalink / raw)
To: Selva Nair <selva.nair@; +Cc: Gert Doering <gert@
In-Reply-To: <CAKuzo_hQGh6j5BJCv4whVOkJOgikUSuw5wAtmcQBWtsJ0QsUNg@...278...>
I was testing Tunnelblick with Selva's C/R server and config (thanks
again for that) and there was a problem. Maybe I'm (still)
misunderstanding something, but a SIGUSR1 restart asks for the normal
username/password instead of a static C/R.
That is, the first thing after the restart is ">PASSWORD:Need 'Auth'
username/password" instead of ">PASSWORD:Need 'Auth' username/password
SC:1,Type something (e.g., hello): ".
Should Tunnelblick save the static challenge info (like it saves the
dynamic challenge info) and use it again whenever it sees a
">PASSWORD:Need 'Auth' username/password"? (Except when there is also
a pending dynamic challenge, in which case it would use that instead.)
Also, there's an oddity (that doesn't cause a problem) in that the
first thing Tunnelblick sees over the management interface for the
original connection is "ENTER PASSWORD:SUCCESS: password is correct"
-- that comes even before ">INFO:OpenVPN Management Interface Version
1 -- type 'help' for more info", and long before any username or
password has been entered.
Once I get everything working (and I understand it myself), I plan to
submit a patch to doc/management-notes.txt that will (I hope) clarify
the C/R documentation.
Thanks,
Jon
On Thu, Jul 19, 2018 at 4:22 PM, Selva Nair <selva.nair@...277...> wrote:
> Hi,
>
> Here is the config. There are no secrets, so just input anything
> against the username/password/static challenge prompts (use short
> non-empty strings). For dynamic challenge, the answer must be correct
> for the connection to succeed.
>
> If the server is down please ping me.
>
> Selva
>
> On Thu, Jul 19, 2018 at 3:14 PM, Gert Doering <gert@...1296...> wrote:
>> Hi,
>>
>> On Thu, Jul 19, 2018 at 02:38:55PM -0400, Selva Nair wrote:
>>> On Thu, Jul 19, 2018 at 1:52 PM, Gert Doering <gert@...1296...> wrote:
>>> > On Thu, Jul 19, 2018 at 11:43:17AM -0400, Jonathan K. Bullard wrote:
>>> >> Thank you, Selva! (Now all I need to do is get it working!)
>>> >
>>> > Looking very much forward to see this happen :-)
>>> >
>>> > ($payingCustomer )
>>>
>>> Send some ??????/$$ from $payingCustomer this way :)
>>
>> I might elicit some funding for Beer at the Hackathon... *tempt*
>>
>> (They do already sponsor our fun - all my buildslaves run on their vmware
>> farm and eat their bandwith... :-) - just no direct flow of money)
>>
>>> Jon: I have a server for testing static and dynamic challenge. If
>>> interested I can send you a config. Or use access server with a free
>>> test license. Mine will just challenge with 1 + 1 = ? kind of
>>> questions, nothing fancy.
>>
>> Interest! (Though I might actually have the config already, just
>> never came around to work on it)
>>
>> gert
>> --
>> "If was one thing all people took for granted, was conviction that if you
>> feed honest figures into a computer, honest figures come out. Never doubted
>> it myself till I met a computer with a sense of humor."
>> Robert A. Heinlein, The Moon is a Harsh Mistress
>>
>> Gert Doering - Munich, Germany gert@...1296...
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/8] veth: Avoid drops by oversized packets when XDP is enabled
From: Toshiaki Makita @ 2018-07-24 1:56 UTC (permalink / raw)
To: Jakub Kicinski, Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180723172707.74a8acfa@cakuba.netronome.com>
On 2018/07/24 9:27, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:03 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> All oversized packets including GSO packets are dropped if XDP is
>> enabled on receiver side, so don't send such packets from peer.
>>
>> Drop TSO and SCTP fragmentation features so that veth devices themselves
>> segment packets with XDP enabled. Also cap MTU accordingly.
>>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> Is there any precedence for fixing up features and MTU like this? Most
> drivers just refuse to install the program if settings are incompatible.
I don't know any precedence. I can refuse the program on installing it
when features and MTU are not appropriate. Is it preferred?
Note that with current implementation wanted_features are not touched so
features will be restored when the XDP program is removed. MTU will not
be restored though, as I do not remember the original MTU.
>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>> index 78fa08cb6e24..f5b72e937d9d 100644
>> --- a/drivers/net/veth.c
>> +++ b/drivers/net/veth.c
>> @@ -542,6 +542,23 @@ static int veth_get_iflink(const struct net_device *dev)
>> return iflink;
>> }
>>
>> +static netdev_features_t veth_fix_features(struct net_device *dev,
>> + netdev_features_t features)
>> +{
>> + struct veth_priv *priv = netdev_priv(dev);
>> + struct net_device *peer;
>> +
>> + peer = rtnl_dereference(priv->peer);
>> + if (peer) {
>> + struct veth_priv *peer_priv = netdev_priv(peer);
>> +
>> + if (peer_priv->_xdp_prog)
>> + features &= ~NETIF_F_GSO_SOFTWARE;
>> + }
>> +
>> + return features;
>> +}
>> +
>> static void veth_set_rx_headroom(struct net_device *dev, int new_hr)
>> {
>> struct veth_priv *peer_priv, *priv = netdev_priv(dev);
>> @@ -591,14 +608,33 @@ static int veth_xdp_set(struct net_device *dev, struct bpf_prog *prog,
>> goto err;
>> }
>> }
>> +
>> + if (!old_prog) {
>> + peer->hw_features &= ~NETIF_F_GSO_SOFTWARE;
>> + peer->max_mtu = PAGE_SIZE - VETH_XDP_HEADROOM -
>> + peer->hard_header_len -
>> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> + if (peer->mtu > peer->max_mtu)
>> + dev_set_mtu(peer, peer->max_mtu);
>> + }
>> }
>>
>> if (old_prog) {
>> - if (!prog && dev->flags & IFF_UP)
>> - veth_disable_xdp(dev);
>> + if (!prog) {
>> + if (dev->flags & IFF_UP)
>> + veth_disable_xdp(dev);
>> +
>> + if (peer) {
>> + peer->hw_features |= NETIF_F_GSO_SOFTWARE;
>> + peer->max_mtu = ETH_MAX_MTU;
>> + }
>> + }
>> bpf_prog_put(old_prog);
>> }
>>
>> + if ((!!old_prog ^ !!prog) && peer)
>> + netdev_update_features(peer);
>> +
>> return 0;
>> err:
>> priv->_xdp_prog = old_prog;
>> @@ -643,6 +679,7 @@ static const struct net_device_ops veth_netdev_ops = {
>> .ndo_poll_controller = veth_poll_controller,
>> #endif
>> .ndo_get_iflink = veth_get_iflink,
>> + .ndo_fix_features = veth_fix_features,
>> .ndo_features_check = passthru_features_check,
>> .ndo_set_rx_headroom = veth_set_rx_headroom,
>> .ndo_bpf = veth_xdp,
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: Toshiaki Makita @ 2018-07-24 1:59 UTC (permalink / raw)
To: Toshiaki Makita
Cc: kbuild test robot, kbuild-all, netdev, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer
In-Reply-To: <201807240711.kbMKpUVb%fengguang.wu@intel.com>
On 2018/07/24 9:19, kbuild test robot wrote:
> Hi Toshiaki,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on bpf-next/master]
>
> url: https://github.com/0day-ci/linux/commits/Toshiaki-Makita/veth-Driver-XDP/20180724-065517
> base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
> config: i386-randconfig-x001-201829 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
> In file included from include/linux/kernel.h:10:0,
> from include/linux/list.h:9,
> from include/linux/timer.h:5,
> from include/linux/netdevice.h:28,
> from drivers//net/veth.c:11:
> drivers//net/veth.c: In function 'veth_xdp_xmit':
>>> drivers//net/veth.c:300:16: error: implicit declaration of function 'xdp_ok_fwd_dev' [-Werror=implicit-function-declaration]
> if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
This is because this series depends on commit d8d7218ad842 ("xdp:
XDP_REDIRECT should check IFF_UP and MTU") which is currently in DaveM's
net-next tree, as I noted in the cover letter.
--
Toshiaki Makita
^ permalink raw reply
* Re: [Openvpn-devel] Dynamic challenge/response questions
From: Jonathan K. Bullard @ 2018-07-24 3:04 UTC (permalink / raw)
To: Selva Nair <selva.nair@; +Cc: Gert Doering <gert@
In-Reply-To: <CAKuzo_iM_zUP+8=_1N+3axV+nU1B3B5r190G1U80w7uECdoBsQ@...278...>
Hi,
On Mon, Jul 23, 2018 at 10:31 PM, Selva Nair <selva.nair@...277...> wrote:
> On Sat, Jul 21, 2018 at 1:21 PM, Jonathan K. Bullard
> <jkbullard@...277...> wrote:
>
>> Some, perhaps including Selva's $payingCustomer, may not want to use
>> Tunnelblick betas or use OpenVPN 2.5 until it is released.
>
> I missed this last time... Its Gert who has $$payingCustomer(s) :)
Oops, sorry. (Sorry you don't have $payingCustomers, too : )
Oh, and sorry for my top-post, too : (
Best regards,
Jon
^ permalink raw reply
* Re: [PATCH] tpm: add support for partial reads
From: Jason Gunthorpe @ 2018-07-24 2:05 UTC (permalink / raw)
To: Tadeusz Struk
Cc: James Bottomley, Jarkko Sakkinen, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <ee0f0ccf-f757-a7d4-bf55-316f81fb490b@intel.com>
On Mon, Jul 23, 2018 at 04:42:38PM -0700, Tadeusz Struk wrote:
> On 07/23/2018 03:08 PM, Jason Gunthorpe wrote:
> > On Mon, Jul 23, 2018 at 03:00:20PM -0700, Tadeusz Struk wrote:
> >> On 07/23/2018 02:56 PM, Jason Gunthorpe wrote:
> >>> The proposed patch doesn't clear the data_pending if the entire buffer
> >>> is not consumed, so of course it is ABI breaking, that really isn't OK.
> >> The data_pending will be cleared by the timeout handler if the user doesn't
> >> read the response fully before the timeout expires. The is the same situation
> >> if the user would not read the response at all.
> > That causes write() to fail with EBUSY
> >
> > NAK from me on breaking the ABI like this
>
> What if we introduce this new behavior only for the non-blocking mode
> as James suggested? Or do you have some other suggestions?
I think you should do it entirely in userspace.
But something sensible linked to O_NONBLOCK could be OK.
Jason
^ permalink raw reply
* Re: [PATCH 1/3] [BUGFIX] tracing: Fix double free of event_trigger_data
From: Steven Rostedt @ 2018-07-24 2:10 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Ingo Molnar, Shuah Khan, Tom Zanussi, Hiraku Toyooka,
linux-kernel, stable
In-Reply-To: <153149926702.11274.12489440326560729788.stgit@devbox>
On Sat, 14 Jul 2018 01:27:47 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Fix a double free bug of event_trigger_data caused by
> calling unregister_trigger() from register_snapshot_trigger().
> This kicks a kernel BUG if double free checker is enabled
> as below;
>
> kernel BUG at /home/mhiramat/ksrc/linux/mm/slub.c:296!
> invalid opcode: 0000 [#1] SMP PTI
> CPU: 2 PID: 4312 Comm: ftracetest Not tainted 4.18.0-rc1+ #44
> Hardware name: ASUS All Series/B85M-G, BIOS 2108 08/11/2014
> RIP: 0010:set_freepointer.part.37+0x0/0x10
> Code: 41 b8 01 00 00 00 29 c8 4d 8d 0c 0c b9 10 00 00 00 50 e8 e3 28 23 00 8b 53 08 5e 5f 89 d1 81 e1 00 04 00 00 e9 e9 fe ff ff 90 <0f> 0b 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 48 c7 c6 90 7f 0d
> RSP: 0018:ffffa799caa3bd90 EFLAGS: 00010246
> RAX: ffff9b825f8c8e80 RBX: ffff9b825f8c8e80 RCX: ffff9b825f8c8e80
> RDX: 0000000000021562 RSI: ffff9b830e9e70e0 RDI: 0000000000000202
> RBP: 0000000000000246 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff9b830e0072c0
> R13: ffffeb8e0d7e3200 R14: ffffffff961db7af R15: 00000000fffffffe
> FS: 00007f135ba9f700(0000) GS:ffff9b830e800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000563736b5f3a2 CR3: 0000000295916005 CR4: 00000000001606e0
> Call Trace:
> kfree+0x35d/0x380
> event_trigger_callback+0x13f/0x1c0
> event_trigger_write+0xf2/0x1a0
> ? lock_acquire+0x9f/0x200
> __vfs_write+0x26/0x170
> ? rcu_read_lock_sched_held+0x6b/0x80
> ? rcu_sync_lockdep_assert+0x2e/0x60
> ? __sb_start_write+0x13e/0x1a0
> ? vfs_write+0x18a/0x1b0
> vfs_write+0xc1/0x1b0
> ksys_write+0x45/0xa0
> do_syscall_64+0x60/0x200
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> unregister_trigger() will free given event_trigger_data
> at last. But that event_trigger_data will be freed again
> in event_trigger_callback() if register_snapshot_trigger()
> is failed, and causes a double free bug.
>
> Registering the data should be the final operation in the
> register function on normal path, because the trigger
> must be ready for taking action right after it is
> registered.
Nice catch. I can reproduce this. But this patch is fixing the symptom
and not the disease.
>
> Fixes: commit 93e31ffbf417 ("tracing: Add 'snapshot' event trigger command")
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
> Cc: stable@vger.kernel.org
> ---
> kernel/trace/trace.c | 5 +++++
> kernel/trace/trace.h | 2 ++
> kernel/trace/trace_events_trigger.c | 10 ++++++----
> 3 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index f054bd6a1c66..2556d8c097d2 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -980,6 +980,11 @@ static void free_snapshot(struct trace_array *tr)
> tr->allocated_snapshot = false;
> }
>
> +void tracing_free_snapshot_instance(struct trace_array *tr)
> +{
> + free_snapshot(tr);
> +}
> +
> /**
> * tracing_alloc_snapshot - allocate snapshot buffer.
> *
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index f8f86231ad90..03468bb8a79a 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -1823,12 +1823,14 @@ static inline void trace_event_eval_update(struct trace_eval_map **map, int len)
> #ifdef CONFIG_TRACER_SNAPSHOT
> void tracing_snapshot_instance(struct trace_array *tr);
> int tracing_alloc_snapshot_instance(struct trace_array *tr);
> +void tracing_free_snapshot_instance(struct trace_array *tr);
> #else
> static inline void tracing_snapshot_instance(struct trace_array *tr) { }
> static inline int tracing_alloc_snapshot_instance(struct trace_array *tr)
> {
> return 0;
> }
> +static inline void tracing_free_snapshot_instance(struct trace_array *tr) { }
> #endif
>
> extern struct trace_iterator *tracepoint_print_iter;
> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> index d18249683682..40e2f4406b2c 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -1079,11 +1079,13 @@ register_snapshot_trigger(char *glob, struct event_trigger_ops *ops,
> struct event_trigger_data *data,
> struct trace_event_file *file)
> {
> - int ret = register_trigger(glob, ops, data, file);
> + int free_if_fail = !file->tr->allocated_snapshot;
> + int ret = 0;
>
> - if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) {
> - unregister_trigger(glob, ops, data, file);
> - ret = 0;
> + if (!tracing_alloc_snapshot_instance(file->tr)) {
> + ret = register_trigger(glob, ops, data, file);
> + if (ret == 0 && free_if_fail)
> + tracing_free_snapshot_instance(file->tr);
> }
>
> return ret;
Really, when we register_trigger() we should be able to freely call
unresgister_trigger() with no side effects like the above happens.
Instead of doing the above, I believe this is a better approach:
Thoughts?
P.S. This brings up another minor bug. The failure should return ENOMEM
not ENOENT.
-- Steve
diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index d18249683682..d15a746bcdfb 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -679,6 +679,7 @@ event_trigger_callback(struct event_command *cmd_ops,
goto out_free;
out_reg:
+ event_trigger_init(trigger_ops, trigger_data);
ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file);
/*
* The above returns on success the # of functions enabled,
@@ -687,9 +688,9 @@ event_trigger_callback(struct event_command *cmd_ops,
*/
if (!ret) {
ret = -ENOENT;
- goto out_free;
+ goto out_free_trigger;
} else if (ret < 0)
- goto out_free;
+ goto out_free_trigger;
ret = 0;
out:
return ret;
@@ -699,6 +700,10 @@ event_trigger_callback(struct event_command *cmd_ops,
cmd_ops->set_filter(NULL, trigger_data, NULL);
kfree(trigger_data);
goto out;
+
+ out_free_trigger:
+ event_trigger_free(trigger_ops, trigger_data);
+ goto out;
}
/**
^ permalink raw reply related
* Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Alex Williamson @ 2018-07-24 3:16 UTC (permalink / raw)
To: Sinan Kaya; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <CAK9iUCPG-H3vWjiEnjAgr_nWEf=0Sn+AvRt68_Sg16Zw8TobRg@mail.gmail.com>
On Mon, 23 Jul 2018 19:20:41 -0700
Sinan Kaya <Okaya@kernel.org> wrote:
> On 7/23/18, Alex Williamson <alex.williamson@redhat.com> wrote:
> > On Mon, 23 Jul 2018 17:40:02 -0700
> > Sinan Kaya <okaya@kernel.org> wrote:
> >
> >> On 7/23/2018 5:13 PM, Alex Williamson wrote:
> >> > + * The NVMe specification requires that controllers support PCIe FLR,
> >> > but
> >> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR
> >> > (-1
> >> > + * config space) unless the device is quiesced prior to FLR.
> >>
> >> Does disabling the memory bit in PCI config space as part of the FLR
> >> reset function help? (like the very first thing)
> >
> > No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
> > call pcie_flr(), the Samsung controller dies just as it did previously.
> >
> >> Can we do that in the pcie_flr() function to cover other endpoint types
> >> that might be pushing traffic while code is trying to do a reset?
> >
> > Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY?
>
> Yes
>
> > I tried
> > that too, it doesn't work either. I'm not really sure the theory
> > behind clearing memory, clearing busmaster to stop DMA seems like a
> > sane thing to do, but doesn't help here.
>
> Let me explain what I guessed. You might be able to fill in the blanks
> where I am completely off.
>
> We do vfio initiated flr reset immediately following guest machine
> shutdown. The card could be fully enabled and pushing traffic to the
> system at this moment.
>
> I don't know if vfio does any device disable or not.
Yes, pci_clear_master() is the very first thing we do in
vfio_pci_disable(), well before we try to reset the device.
> FLR is supposed to reset the endpoint but endpoint doesn't recover per
> your report.
>
> Having vendor specific reset routines for PCIE endpoints defeats the
> purpose of FLR.
>
> Since the adapter is fully functional, i suggested turning off bus
> master and memory enable bits to stop endpoint from sending packets.
>
> But, this is not helping either.
>
> Those sleep statements looked very fragile to be honest.
>
> I was curious if there is something else that we could do for other endpoints.
>
> No objections otherwise.
I certainly agree that it would be nice if FLR was more robust on these
devices, but if all devices behaved within the specs we wouldn't have
these quirks to start with ;) Just as you're suggesting maybe we could
disable busmaster before FLR, which is reasonable but doesn't work
here, I'm basically moving that to a class specific action, quiesce the
controller at the NVMe level rather than PCI level. Essentially that's
why I thought it reasonable to apply to all NVMe class devices rather
than create just a quirk that delays after FLR for Intel and another
that disables the NVMe controller just for Samsung. Once I decide to
apply to the whole class, then I need to bring in the device specific
knowledge already found in the native nvme driver for the delay between
clearing the enable bit and checking the ready status bit. If it's
fragile, then the bare metal nvme driver has the same frailty. For the
delay I added, all I can say is that it works for me and improves the
usability of the device for this purpose. I know that 200ms is too
low, ISTR the issue was fixed at 210-220ms, so 250ms provides some
headroom and I've not seen any issues there. If we want to make it 500
or 1000ms, that's fine by me, I expect it'd work, it's just unnecessary
until we find devices that need longer delays. Thanks,
Alex
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Alex Williamson @ 2018-07-24 3:16 UTC (permalink / raw)
In-Reply-To: <CAK9iUCPG-H3vWjiEnjAgr_nWEf=0Sn+AvRt68_Sg16Zw8TobRg@mail.gmail.com>
On Mon, 23 Jul 2018 19:20:41 -0700
Sinan Kaya <Okaya@kernel.org> wrote:
> On 7/23/18, Alex Williamson <alex.williamson@redhat.com> wrote:
> > On Mon, 23 Jul 2018 17:40:02 -0700
> > Sinan Kaya <okaya@kernel.org> wrote:
> >
> >> On 7/23/2018 5:13 PM, Alex Williamson wrote:
> >> > + * The NVMe specification requires that controllers support PCIe FLR,
> >> > but
> >> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR
> >> > (-1
> >> > + * config space) unless the device is quiesced prior to FLR.
> >>
> >> Does disabling the memory bit in PCI config space as part of the FLR
> >> reset function help? (like the very first thing)
> >
> > No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
> > call pcie_flr(), the Samsung controller dies just as it did previously.
> >
> >> Can we do that in the pcie_flr() function to cover other endpoint types
> >> that might be pushing traffic while code is trying to do a reset?
> >
> > Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY?
>
> Yes
>
> > I tried
> > that too, it doesn't work either. I'm not really sure the theory
> > behind clearing memory, clearing busmaster to stop DMA seems like a
> > sane thing to do, but doesn't help here.
>
> Let me explain what I guessed. You might be able to fill in the blanks
> where I am completely off.
>
> We do vfio initiated flr reset immediately following guest machine
> shutdown. The card could be fully enabled and pushing traffic to the
> system at this moment.
>
> I don't know if vfio does any device disable or not.
Yes, pci_clear_master() is the very first thing we do in
vfio_pci_disable(), well before we try to reset the device.
> FLR is supposed to reset the endpoint but endpoint doesn't recover per
> your report.
>
> Having vendor specific reset routines for PCIE endpoints defeats the
> purpose of FLR.
>
> Since the adapter is fully functional, i suggested turning off bus
> master and memory enable bits to stop endpoint from sending packets.
>
> But, this is not helping either.
>
> Those sleep statements looked very fragile to be honest.
>
> I was curious if there is something else that we could do for other endpoints.
>
> No objections otherwise.
I certainly agree that it would be nice if FLR was more robust on these
devices, but if all devices behaved within the specs we wouldn't have
these quirks to start with ;) Just as you're suggesting maybe we could
disable busmaster before FLR, which is reasonable but doesn't work
here, I'm basically moving that to a class specific action, quiesce the
controller at the NVMe level rather than PCI level. Essentially that's
why I thought it reasonable to apply to all NVMe class devices rather
than create just a quirk that delays after FLR for Intel and another
that disables the NVMe controller just for Samsung. Once I decide to
apply to the whole class, then I need to bring in the device specific
knowledge already found in the native nvme driver for the delay between
clearing the enable bit and checking the ready status bit. If it's
fragile, then the bare metal nvme driver has the same frailty. For the
delay I added, all I can say is that it works for me and improves the
usability of the device for this purpose. I know that 200ms is too
low, ISTR the issue was fixed at 210-220ms, so 250ms provides some
headroom and I've not seen any issues there. If we want to make it 500
or 1000ms, that's fine by me, I expect it'd work, it's just unnecessary
until we find devices that need longer delays. Thanks,
Alex
^ permalink raw reply
* [qemu-upstream-4.11-testing test] 125508: regressions - FAIL
From: osstest service owner @ 2018-07-24 3:16 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 125508 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125508/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl <job status> broken in 125498
test-arm64-arm64-libvirt-xsm <job status> broken in 125498
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 124797
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail pass in 125498
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 4 host-install(4) broken in 125498 blocked in 124797
test-arm64-arm64-xl 4 host-install(4) broken in 125498 blocked in 124797
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
version targeted for testing:
qemuu 20c76f9a5fbf16d58c6add2ace2ff0fabd785926
baseline version:
qemuu 43139135a8938de44f66333831d3a8655d07663a
Last test of basis 124797 2018-06-28 16:27:31 Z 25 days
Testing same since 125273 2018-07-17 11:38:59 Z 6 days 5 attempts
------------------------------------------------------------
People who touched revisions under test:
Alberto Garcia <berto@igalia.com>
Alexandro Sanchez Bach <alexandro@phi.nz>
Anthony PERARD <anthony.perard@citrix.com>
Brijesh Singh <brijesh.singh@amd.com>
Bruce Rogers <brogers@suse.com>
Christian Borntraeger <borntraeger@de.ibm.com>
Cornelia Huck <cohuck@redhat.com>
Daniel P. Berrange <berrange@redhat.com>
Daniel P. Berrangé <berrange@redhat.com>
David Gibson <david@gibson.dropbear.id.au>
Dr. David Alan Gilbert <dgilbert@redhat.com>
Eduardo Habkost <ehabkost@redhat.com>
Eric Blake <eblake@redhat.com>
Fam Zheng <famz@redhat.com>
Geert Uytterhoeven <geert+renesas@glider.be>
Gerd Hoffmann <kraxel@redhat.com>
Greg Kurz <groug@kaod.org>
Halil Pasic <pasic@linux.ibm.com>
Henry Wertz <hwertz10@gmail.com>
Jack Schwartz <jack.schwartz@oracle.com>
Jan Kiszka <jan.kiszka@siemens.com>
Jason Andryuk <jandryuk@gmail.com>
Jason Wang <jasowang@redhat.com>
Jeff Cody <jcody@redhat.com>
Jintack Lim <jintack@cs.columbia.edu>
John Snow <jsnow@redhat.com>
John Thomson <git@johnthomson.fastmail.com.au>
Kevin Wolf <kwolf@redhat.com>
KONRAD Frederic <frederic.konrad@adacore.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Laszlo Ersek <lersek@redhat.com>
Laurent Vivier <laurent@vivier.eu>
Laurent Vivier <lvivier@redhat.com>
linzhecheng <linzhecheng@huawei.com>
Marc-André Lureau <marcandre.lureau@redhat.com>
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Max Filippov <jcmvbkbc@gmail.com>
Max Reitz <mreitz@redhat.com>
Michael Roth <mdroth@linux.vnet.ibm.com>
Michael S. Tsirkin <mst@redhat.com>
Michael Walle <michael@walle.cc>
Michal Privoznik <mprivozn@redhat.com>
Murilo Opsfelder Araujo <muriloo@linux.vnet.ibm.com>
Nia Alarie <nia.alarie@gmail.com>
Olaf Hering <olaf@aepfle.de>
Paolo Bonzini <pbonzini@redhat.com>
Peter Lieven <pl@kamp.de>
Peter Maydell <peter.maydell@linaro.org>
Peter Xu <peterx@redhat.com>
Philippe Mathieu-Daudé <f4bug@amsat.org>
Prasad Singamsetty <prasad.singamsetty@oracle.com>
Prasad Singamsetty <prasad.singamsety@oracle.com>
R. Nageswara Sastry <nasastry@in.ibm.com>
Richard Henderson <richard.henderson@linaro.org>
Ross Lagerwall <ross.lagerwall@citrix.com>
Shannon Zhao <zhaoshenglong@huawei.com>
Stefan Berger <stefanb@linux.vnet.ibm.com>
Stefan Hajnoczi <stefanha@redhat.com>
Thomas Huth <thuth@redhat.com>
Tiwei Bie <tiwei.bie@intel.com>
Victor Kamensky <kamensky@cisco.com>
Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-job test-arm64-arm64-xl broken
broken-job test-arm64-arm64-libvirt-xsm broken
Not pushing.
(No revision log; it would be 3001 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
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.