On Wed, Jul 24, 2019 at 06:10:53PM -0400, Michael S. Tsirkin wrote:
> Christoph - would a documented API wrapping dma_mask make sense?
> With the documentation explaining how users must
> desist from using DMA APIs if that returns false ...
We have some bigger changes in this are planned,
On Tue, Jul 23, 2019 at 09:19:33PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午5:17, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 03:57:17AM -0400, Jason Wang wrote:
> > > We don't mark dirty pages if the map was teared down outside MMU
> > > notifier. This will lead untracked dirty
On 7/24/19 12:25 PM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Hi,
>
> This is mostly Jerome's work, converting the block/bio and related areas
> to call put_user_page*() instead of put_page(). Because I've changed
> Jerome's patches, in some cases significantly, I'd like to get
On 7/23/19 11:17 PM, Christoph Hellwig wrote:
> On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubb...@gmail.com wrote:
>> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter.
>> Then, use the new iov_iter_get_pages_use_gup() to retrieve it when
>> it is time to release the
On Tue, Jul 23, 2019 at 05:38:51PM +0200, Christoph Hellwig wrote:
> On Mon, Jul 22, 2019 at 04:36:09PM +0100, Robin Murphy wrote:
> >> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> >> index c8be1c4f5b55..37c143971211 100644
> >> --- a/drivers/virtio/virtio_ring.c
> >>
On 7/23/19 9:25 PM, john.hubb...@gmail.com wrote:
> From: Jérôme Glisse
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
>
Hi,
I suspect that the virtio network driver calls some skb BPF programs with
skb->data_end - skb->data != skb->len, but only for forwarded packets.
For instance, the attached sched_cls tc program prints skb->data,
skb->data_end and skb->len for each packet:
-0 [000] ..s.
On 2019/7/20 0:13, Michael S. Tsirkin wrote:
> On Fri, Jul 19, 2019 at 03:31:29PM +, 冉 jiang wrote:
>> On 2019/7/19 22:29, Jiang wrote:
>>> On 2019/7/19 10:36, Jason Wang wrote:
On 2019/7/18 下午10:43, Michael S. Tsirkin wrote:
> On Thu, Jul 18, 2019 at 10:42:47AM -0400, Michael S.
On 2019/7/24 上午10:38, Eric Biggers wrote:
[This email was generated by a script. Let me know if you have any
suggestions
to make it better, or if you want it re-generated with the latest
status.]
Of the currently open syzbot reports against the upstream kernel, I've
manually
marked 3
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan
---
drivers/gpu/drm/qxl/qxl_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan
---
drivers/gpu/drm/bochs/bochs_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
Following specification review a few things were changed in v8 of the
virtio-iommu series [1], but have been omitted when merging the base
driver. Add them now:
* Remove the EXEC flag.
* Add feature bit for the MMIO flag.
* Change domain_bits to domain_range.
* Add NOMEM status flag.
[1]
Update MAINTAINERS and .mailmap with my @linaro.org address, since I
don't have access to my @arm.com address anymore.
Signed-off-by: Jean-Philippe Brucker
---
.mailmap| 1 +
MAINTAINERS | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index
On 2019/7/19 22:29, Jiang wrote:
>
> On 2019/7/19 10:36, Jason Wang wrote:
>>
>> On 2019/7/18 下午10:43, Michael S. Tsirkin wrote:
>>> On Thu, Jul 18, 2019 at 10:42:47AM -0400, Michael S. Tsirkin wrote:
On Thu, Jul 18, 2019 at 10:01:05PM +0800, Jason Wang wrote:
> On 2019/7/18 下午9:04,
On 2019/7/19 10:36, Jason Wang wrote:
>
> On 2019/7/18 下午10:43, Michael S. Tsirkin wrote:
>> On Thu, Jul 18, 2019 at 10:42:47AM -0400, Michael S. Tsirkin wrote:
>>> On Thu, Jul 18, 2019 at 10:01:05PM +0800, Jason Wang wrote:
On 2019/7/18 下午9:04, Michael S. Tsirkin wrote:
> On Thu, Jul
On 7/18/19 7:01 AM, Michael S. Tsirkin wrote:
Lots of comments bitrotted. Fix them up.
Fixes: 418a3ab1e778 (mm/balloon_compaction: List interfaces)
Reviewed-by: Wei Wang
Signed-off-by: Michael S. Tsirkin
---
fixes since v3:
teaks suggested by Wei
mm/balloon_compaction.c | 71
This change makes ring buffer reclaim threshold num_free configurable for
better performance, while it's hard coded as 1/2 * queue now.
According to our test with qemu + dpdk, packet dropping happens when the guest
is not able to provide free buffer in avail ring timely.
Smaller value of
Since we move Documentation/x86 docs to Documentation/arch/x86
dir, redirect the doc pointer to them.
Signed-off-by: Alex Shi
Cc: Jonathan Corbet
Cc: Tony Luck
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Changbin Du
Cc: linux-...@vger.kernel.org
Cc:
On 7/3/2019 7:27 PM, Fuqian Huang wrote:
> kmemdup is introduced to duplicate a region of memory in a neat way.
> Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
> write the size twice (sometimes lead to mistakes), kmemdup improves
> readability, leads to smaller code and also
kmemdup is introduced to duplicate a region of memory in a neat way.
Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
write the size twice (sometimes lead to mistakes), kmemdup improves
readability, leads to smaller code and also reduce the chances of mistakes.
Suggestion to use
kmemdup is introduced to duplicate a region of memory in a neat way.
Rather than kmalloc/kzalloc + memset, which the programmer needs to
write the size twice (sometimes lead to mistakes), kmemdup improves
readability, leads to smaller code and also reduce the chances of mistakes.
Suggestion to use
in vm_find_vqs() irq has a wrong type
so, in case of no IRQ resource defined,
wrong parameter will be passed to request_irq()
Signed-off-by: Ihor Matushchak
---
drivers/virtio/virtio_mmio.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_mmio.c
Saying `kvm` is a pretty loaded term. There are at least 5 frontends for it
that I know of (qemu, firecracker, nemu, cloud-hypervisor, crosvm, etc).
Are you looking for strictly open source options?
> On Jul 2, 2019, at 5:56 AM, Turritopsis Dohrnii Teo En Ming
> wrote:
>
> Good evening
in vm_find_vqs() irq has a wrong type
so, in case of no IRQ resource defined,
wrong parameter will be passed to request_irq()
Signed-off-by: Ihor Matushchak
---
Changes in v2:
Don't overwrite error code value.
drivers/virtio/virtio_mmio.c | 7 ++-
1 file changed, 6 insertions(+), 1
Quoting Ihor Matushchak (2019-07-02 17:48:18)
> in vm_find_vqs() irq has a wrong type
> so, in case of no IRQ resource defined,
> wrong parameter will be passed to request_irq()
>
> Signed-off-by: Ihor Matushchak
Reviewed-by: Ivan T. Ivanov
Thanks!
> ---
> Changes in v2:
> Don't overwrite
Hi,
Quoting Ihor Matushchak (2019-07-02 12:59:18)
> in vm_find_vqs() irq has a wrong type
> so, in case of no IRQ resource defined,
> wrong parameter will be passed to request_irq()
>
> Signed-off-by: Ihor Matushchak
> ---
> drivers/virtio/virtio_mmio.c | 7 ++-
> 1 file changed, 6
On 2019-06-13, at 20:04:01 -0700, syzbot wrote:
> syzbot has tested the proposed patch but the reproducer still
> triggered crash: memory leak in batadv_tvlv_handler_register
There's already a fix for this batman leak:
https://lore.kernel.org/netdev/17d64c058965f...@google.com/
Handle devices which defer their attach to the iommu in the dma-iommu api
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
memory leak in batadv_tvlv_handler_register
484.626788][ T156] bond0 (unregistering): Releasing backup interface
bond_slave_1
Warning: Permanently added '10.128.0.87' (ECDSA) to the list of known
Add a gfp_t parameter to the iommu_ops::map function.
Remove the needless locking in the AMD iommu driver.
The iommu_ops::map function (or the iommu_map function which calls it)
was always supposed to be sleepable (according to Joerg's comment in
this thread:
Convert the AMD iommu driver to the dma-iommu api. Remove the iova
handling and reserve region code from the AMD iommu driver.
Signed-off-by: Tom Murphy
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/amd_iommu.c | 677 --
2 files changed, 68
Use the dev->coherent_dma_mask when allocating in the dma-iommu ops api.
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index
We can remove the mutex lock from amd_iommu_map and amd_iommu_unmap.
iommu_map doesn’t lock while mapping and so no two calls should touch
the same iova range. The AMD driver already handles the page table page
allocations without locks so we can safely remove the locks.
Signed-off-by: Tom Murphy
Convert the AMD iommu driver to the dma-iommu api. Remove the iova
handling and reserve region code from the AMD iommu driver.
Change-log:
V4:
-Rebase on top of linux-next
-Split the removing of the unnecessary locking in the amd iommu driver into a
seperate patch
-refactor the "iommu/dma-iommu:
Hello,
syzbot found the following crash on:
HEAD commit:788a0249 Merge tag 'arc-5.2-rc4' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15dc9ea6a0
kernel config: https://syzkaller.appspot.com/x/.config?x=d5c73825cbdc7326
Em Tue, 4 Jun 2019 06:46:14 -0300
Mauro Carvalho Chehab escreveu:
> Em Mon, 3 Jun 2019 09:34:15 +0200
> Christophe Leroy escreveu:
>
> > [...]
> >
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index 8c1c636308c8..e868d2bd48b8 100644
> > > --- a/arch/powerpc/Kconfig
> >
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
memory leak in vhost_net_ioctl
ANGE): hsr_slave_1: link becomes ready
2019/06/13 18:24:57 executed programs: 18
BUG: memory leak
unreferenced object 0x88811cbc6ac0 (size 64):
comm "syz-executor.0",
The current vsock code for removal of socket from the list is both
subject to race and inefficient. It takes the lock, checks whether
the socket is in the list, drops the lock and if the socket was on the
list, deletes it from the list. This is subject to race because as soon
as the lock is
From: John Hubbard
Trivial build warning fix: don't return a value from a function
whose type is "void".
Signed-off-by: John Hubbard
---
fs/ceph/debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/debugfs.c b/fs/ceph/debugfs.c
index 2eb88ed22993..fa14c8e8761d
From: Jérôme Glisse
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
From: Jérôme Glisse
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
From: Jérôme Glisse
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
From: Jérôme Glisse
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
From: Jérôme Glisse
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: Jérôme Glisse
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: Jérôme Glisse
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
In commit d241a95f3514 ("block: optionally mark pages dirty in
bio_release_pages"), new "bool mark_dirty" argument was added to
bio_release_pages.
In upcoming work, another bool argument (to indicate that the pages came
from get_user_pages) is going to be added. That's one
From: Jérôme Glisse
Add a helper to test if call to iov_iter_get_pages*() with a given
iter would result in calls to GUP (get_user_pages*()). We want to
use different tracking of page references if they are coming from
GUP (get_user_pages*()) and thus we need to know when GUP is used
for a
From: John Hubbard
Provide more capable variation of put_user_pages_dirty_lock(),
and delete put_user_pages_dirty(). This is based on the
following:
1. Lots of call sites become simpler if a bool is passed
into put_user_page*(), instead of making the call site
choose which put_user_page*()
From: John Hubbard
Hi,
This is mostly Jerome's work, converting the block/bio and related areas
to call put_user_page*() instead of put_page(). Because I've changed
Jerome's patches, in some cases significantly, I'd like to get his
feedback before we actually leave him listed as the author (he
On Mon, Jul 22, 2019 at 02:44:40PM +0100, Jean-Philippe Brucker wrote:
> Update MAINTAINERS and .mailmap with my @linaro.org address, since I
> don't have access to my @arm.com address anymore.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> .mailmap| 1 +
> MAINTAINERS | 2 +-
> 2 files
On Tue, 2 Jul 2019 13:30:07 +0800 Jason Wang wrote:
> On 2019/7/2 Eric Biggers wrote:
> > [This email was generated by a script. Let me know if you have any
> > suggestions
> > to make it better, or if you want it re-generated with the latest status.]
> >
> > Of the currently open syzbot
Hello Syzbot
On Fri, 14 Jun 2019 11:04:03 +0800 syzbot wrote:
>
>Hello,
>
>syzbot has tested the proposed patch but the reproducer still triggered crash:
>memory leak in batadv_tvlv_handler_register
>
> 484.626788][ T156] bond0 (unregistering): Releasing backup interface
> bond_slave_1
Signed-off-by: Geert Uytterhoeven
---
mm/balloon_compaction.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index ba739b76e6c52e55..17ac81d8d26bcb50 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -60,7
Hello Syzbot
On Fri, 14 Jun 2019 11:04:03 +0800 syzbot wrote:
>
>Hello,
>
>syzbot has tested the proposed patch but the reproducer still triggered crash:
>memory leak in batadv_tvlv_handler_register
>
It is not ubuf leak which is addressed in this thread. Good news.
I will see this new leak
Hello Syzbot
On Fri, 14 Jun 2019 02:26:02 +0800 syzbot wrote:
>
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered crash:
> memory leak in vhost_net_ioctl
>
Oh sorry for my poor patch.
> ANGE): hsr_slave_1: link becomes ready
> 2019/06/13 18:24:57 executed
Hello Dmitry
On Thu, 13 Jun 2019 20:12:06 +0800 Dmitry Vyukov wrote:
> On Thu, Jun 13, 2019 at 2:07 PM Hillf Danton wrote:
> >
> > Hello Jason
> >
> > On Thu, 13 Jun 2019 17:10:39 +0800 Jason Wang wrote:
> > >
> > > This is basically a kfree(ubuf) after the second vhost_net_flush() in
> > >
On Thu, Jun 06, 2019 at 02:28:55PM -0400, Michael S. Tsirkin wrote:
> I'd prefer just changing the definition.
> ifdefs have a disadvantage that it's easy to get
> wrong code if you forget to include a header.
>
> I queued the below - pls confirm it works for you.
Fine by me, I figured that
Hello Jason
On Thu, 13 Jun 2019 17:10:39 +0800 Jason Wang wrote:
>
> This is basically a kfree(ubuf) after the second vhost_net_flush() in
> vhost_net_release().
>
Fairly good catch.
> Could you please post a formal patch?
>
I'd like very much to do that; but I wont, I am afraid, until I
Clang warns:
drivers/vhost/vhost.c:2085:5: warning: macro expansion producing
'defined' has undefined behavior [-Wexpansion-to-defined]
#if VHOST_ARCH_CAN_ACCEL_UACCESS
^
drivers/vhost/vhost.h:98:38: note: expanded from macro
'VHOST_ARCH_CAN_ACCEL_UACCESS'
#define
On Wed, 05 Jun 2019 16:42:05 -0700 (PDT) syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit:788a0249 Merge tag 'arc-5.2-rc4' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15dc9ea6a0
kernel config:
Le 30/05/2019 à 01:23, Mauro Carvalho Chehab a écrit :
Mostly due to x86 and acpi conversion, several documentation
links are still pointing to the old file. Fix them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/acpi/dsd/leds.txt | 2 +-
On 05/30/2019 04:53 AM, Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/acpi/dsd/leds.txt | 2 +-
>
VirtIO DRM driver crashes when setting specific 16.16 fixed-point
property values
When running a virtual machine with a VirtIO GPU, it's possible to
crash the entire VM by setting the value of a 16.16 fixed-point
property to any value below 65536 (1.0 in 16.16 format or 0x0001).
As a specific
On Thursday, May 30, 2019 1:23:53 AM CEST Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
For the Italian documentation I just send I patch to fix them in a dedicated
patch
>
> Signed-off-by:
On 22/05/2019 14:02, Johannes Berg wrote:
Hi,
While my main interest is mostly in UML right now [1] I've CC'ed the
qemu and virtualization lists because something similar might actually
apply to other types of virtualization.
I'm thinking about adding virt-io support to UML, but the tricky
On 22/05/2019 14:46, Johannes Berg wrote:
Hi Anton,
I'm thinking about adding virt-io support to UML, but the tricky part is
that while I want to use the virt-io basics (because it's a nice
interface from the 'inside'), I don't actually want the stock drivers
that are part of the kernel now
On Monday, May 20, 2019 4:47:39 PM CEST Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/acpi/dsd/leds.txt | 2 +-
>
On Wed, 24 Jul 2019 10:39:13 +0200
Christian Borntraeger wrote:
>
>
> On 24.07.19 10:34, Cornelia Huck wrote:
> > On Wed, 24 Jul 2019 08:44:19 +0200
> > Christian Borntraeger wrote:
> >
> >> On 24.07.19 00:58, Halil Pasic wrote:
> >>> The access to airq_areas was racy ever since the adapter
On Wed, 24 Jul 2019 08:44:19 +0200
Christian Borntraeger wrote:
>
>
> On 24.07.19 00:58, Halil Pasic wrote:
> > The access to airq_areas was racy ever since the adapter interrupts got
> > introduced to virtio-ccw, but since commit 39c7dcb15892 ("virtio/s390:
> > make airq summary indicators
On 24.07.19 10:34, Cornelia Huck wrote:
> On Wed, 24 Jul 2019 08:44:19 +0200
> Christian Borntraeger wrote:
>
>> On 24.07.19 00:58, Halil Pasic wrote:
>>> The access to airq_areas was racy ever since the adapter interrupts got
>>> introduced to virtio-ccw, but since commit 39c7dcb15892
On Wed, 24 Jul 2019 08:44:19 +0200
Christian Borntraeger wrote:
> On 24.07.19 00:58, Halil Pasic wrote:
> > The access to airq_areas was racy ever since the adapter interrupts got
> > introduced to virtio-ccw, but since commit 39c7dcb15892 ("virtio/s390:
> > make airq summary indicators DMA")
On Tue, Jul 23, 2019 at 09:25:13PM -0700, john.hubb...@gmail.com wrote:
> From: Jérôme Glisse
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page().
>
> This is part a tree-wide conversion, as described in
On 24.07.19 00:58, Halil Pasic wrote:
> The access to airq_areas was racy ever since the adapter interrupts got
> introduced to virtio-ccw, but since commit 39c7dcb15892 ("virtio/s390:
> make airq summary indicators DMA") this became an issue in practice as
> well. Namely before that commit the
On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubb...@gmail.com wrote:
> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter.
> Then, use the new iov_iter_get_pages_use_gup() to retrieve it when
> it is time to release the pages. That allows choosing between put_page()
>
75 matches
Mail list logo
