All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [igt-dev] [PATCH i-g-t v2] Add Arm drivers as supported drivers by igt.
From: Liviu Dudau @ 2019-06-20 12:41 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: IGT GPU Tool, Petri Latvala
In-Reply-To: <20190620123632.GS12905@phenom.ffwll.local>

On Thu, Jun 20, 2019 at 02:36:32PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 04:13:58PM +0100, Liviu Dudau wrote:
> > Add the drivers maintained by Arm developers to the igt.
> > 
> > v2: Order the modules array entries alphabetically, as per
> > Petri Latvala's suggestion.
> > 
> > Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
> 
> Still kinda wondering why you need this here ... kms is supposed to be
> hw/driver agnostic, so DRIVER_ANY should work.

I'm looking at adding writeback scaling tests that not all drivers are going to
support from the start, so I thought it is better to have a more specific
driver that I can target, even if the DRM APIs are generic.

Best regards,
Liviu

> 
> Maybe you want to check specific constraints in your tests, but then we
> need something like igt_require(is_komeda_driver(fd)); which can inspect
> what you're actually running on when the test executes.
> 
> The drivers in this list thus far are all about exercising the gem side of
> things, where you _really_ don't want to open random garbage. Because the
> ioctls aren't even defined.
> 
> On kms all ioctls are cross-driver, and only once you've opened something
> does it make sense to check for features and stuff (looking at properties,
> or getcap flags, or whatever).
> 
> Cheers, Daniel
> 
> PS: Yes I know that some of the DRIVER_I915 | DRIVER_AMDGPU tests really
> should have been converted to DRIVER_ANY instead. I didn't catch that in
> review way back, but I think I explained to Harry et al meanwhile ...
> 
> > ---
> >  lib/drmtest.c | 3 +++
> >  lib/drmtest.h | 4 ++++
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > index 25f203530..17bb87d1f 100644
> > --- a/lib/drmtest.c
> > +++ b/lib/drmtest.c
> > @@ -205,7 +205,10 @@ static const struct module {
> >  	void (*modprobe)(const char *name);
> >  } modules[] = {
> >  	{ DRIVER_AMDGPU, "amdgpu" },
> > +	{ DRIVER_HDLCD, "hdlcd" },
> >  	{ DRIVER_INTEL, "i915", modprobe_i915 },
> > +	{ DRIVER_KOMEDA, "komeda" },
> > +	{ DRIVER_MALIDP, "mali_dp" },
> >  	{ DRIVER_PANFROST, "panfrost" },
> >  	{ DRIVER_V3D, "v3d" },
> >  	{ DRIVER_VC4, "vc4" },
> > diff --git a/lib/drmtest.h b/lib/drmtest.h
> > index 6c4c3899c..952f0c4b6 100644
> > --- a/lib/drmtest.h
> > +++ b/lib/drmtest.h
> > @@ -45,6 +45,10 @@
> >  #define DRIVER_AMDGPU	(1 << 4)
> >  #define DRIVER_V3D	(1 << 5)
> >  #define DRIVER_PANFROST	(1 << 6)
> > +#define DRIVER_HDLCD	(1 << 7)
> > +#define DRIVER_MALIDP	(1 << 8)
> > +#define DRIVER_KOMEDA	(1 << 9)
> > +
> >  /*
> >   * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> >   * with vgem as well as a supported driver, you can end up with a
> > -- 
> > 2.22.0
> > 
> > _______________________________________________
> > igt-dev mailing list
> > igt-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply

* [Qemu-devel] [PATCH v5 0/3] fw_cfg: Add edk2_add_host_crypto_policy()
From: Philippe Mathieu-Daudé @ 2019-06-20 12:19 UTC (permalink / raw)
  To: Laszlo Ersek, qemu-devel
  Cc: Peter Maydell, Andrew Jones, Eduardo Habkost, Michael S. Tsirkin,
	qemu-arm, Paolo Bonzini, Philippe Mathieu-Daudé

Hi,

This series add edk2_add_host_crypto_policy() and the Edk2Crypto object.

The Edk2Crypto object is used to hold configuration values specific
to EDK2.

So far only the 'https' policy is supported.

A usercase example is the 'HTTPS Boof' feature of OVMF [*].

Usage example:

$ qemu-system-x86_64 \
    --object edk2_crypto,id=https,\
        ciphers=/etc/crypto-policies/back-ends/openssl.config,\
        cacerts=/etc/pki/ca-trust/extracted/edk2/cacerts.bin

(On Fedora these files are provided by the ca-certificates and
crypto-policies packages).

[*]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README

Since v4:
- Addressed Laszlo comments (see patch#1 description)
Since v3:
- Addressed Markus' comments (do not care about heap)
Since v2:
- Split of
Since v1:
- Addressed Michael and Laszlo comments.

Please review,

Phil.

$ git backport-diff -u fw_cfg_edk2_crypto_policies-v3
Key:
[####] : number of functional differences between upstream/downstream patch
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/3:[0164] [FC] 'hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()'
002/3:[----] [--] 'hw/i386: Use edk2_add_host_crypto_policy()'
003/3:[----] [--] 'hw/arm/virt: Use edk2_add_host_crypto_policy()'

v4: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04300.html
v3: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02965.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02522.html
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg01598.html

Philippe Mathieu-Daudé (3):
  hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()
  hw/i386: Use edk2_add_host_crypto_policy()
  hw/arm/virt: Use edk2_add_host_crypto_policy()

 MAINTAINERS                             |   2 +
 hw/Makefile.objs                        |   1 +
 hw/arm/virt.c                           |   7 +
 hw/firmware/Makefile.objs               |   1 +
 hw/firmware/uefi_edk2_crypto_policies.c | 209 ++++++++++++++++++++++++
 hw/i386/pc.c                            |   7 +
 include/hw/firmware/uefi_edk2.h         |  30 ++++
 7 files changed, 257 insertions(+)
 create mode 100644 hw/firmware/Makefile.objs
 create mode 100644 hw/firmware/uefi_edk2_crypto_policies.c
 create mode 100644 include/hw/firmware/uefi_edk2.h

-- 
2.20.1



^ permalink raw reply

* [thud][PATCH] packagegroup-*-graphics: add virtual provider for GPU driver
From: Anand Balagopalakrishnan @ 2019-06-20 12:40 UTC (permalink / raw)
  To: meta-arago

- Add a new virtual provider for GPU driver
- Specify Rogue and SGX as GPU driver provider for J7 and other platforms
- Replace SGX with virtual GPU provider in package groups

Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
---
 meta-arago-distro/conf/distro/include/arago-prefs.inc                   | 2 ++
 .../packagegroups/packagegroup-arago-tisdk-graphics-sdk-host.bb         | 2 +-
 .../packagegroups/packagegroup-arago-tisdk-graphics-sdk-target.bb       | 2 +-
 .../recipes-core/packagegroups/packagegroup-arago-tisdk-graphics.bb     | 2 +-
 4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta-arago-distro/conf/distro/include/arago-prefs.inc b/meta-arago-distro/conf/distro/include/arago-prefs.inc
index e9e9177..3f36747 100644
--- a/meta-arago-distro/conf/distro/include/arago-prefs.inc
+++ b/meta-arago-distro/conf/distro/include/arago-prefs.inc
@@ -9,11 +9,13 @@ PREFERRED_PROVIDER_virtual/gettext = "gettext"
 PREFERRED_PROVIDER_virtual/egl = "ti-sgx-ddk-um"
 PREFERRED_PROVIDER_virtual/libgles1 = "ti-sgx-ddk-um"
 PREFERRED_PROVIDER_virtual/libgles2 = "ti-sgx-ddk-um"
+PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km"
 
 # J7 has a Rogue GPU core
 PREFERRED_PROVIDER_virtual/egl_j7-evm = "ti-img-rogue-umlibs"
 PREFERRED_PROVIDER_virtual/libgles1_j7-evm = "ti-img-rogue-umlibs"
 PREFERRED_PROVIDER_virtual/libgles2_j7-evm = "ti-img-rogue-umlibs"
+PREFERRED_PROVIDER_virtual/gpudriver_j7-evm = "ti-img-rogue-driver"
 
 PREFERRED_PROVIDER_libgbm = "libgbm"
 PREFERRED_PROVIDER_libgbm-dev = "libgbm-dev"
diff --git a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics-sdk-host.bb b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics-sdk-host.bb
index 96ed27b..486d080 100644
--- a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics-sdk-host.bb
+++ b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics-sdk-host.bb
@@ -6,7 +6,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 inherit packagegroup
 
-GRAPHICS_RDEPENDS = "ti-sgx-ddk-km-src"
+GRAPHICS_RDEPENDS = "${PREFERRED_PROVIDER_virtual/gpudriver}-src"
 
 GRAPHICS_RDEPENDS_append_omap-a15 = "\
     ti-gc320-driver-src \
diff --git a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics-sdk-target.bb b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics-sdk-target.bb
index 7e18d08..3f6485f 100644
--- a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics-sdk-target.bb
+++ b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics-sdk-target.bb
@@ -12,7 +12,7 @@ GRAPHICS_RDEPENDS = "\
     wayland-dev \
     weston-dev \
     ${PREFERRED_PROVIDER_virtual/egl}-dev \
-    ti-sgx-ddk-km-dev \
+    ${PREFERRED_PROVIDER_virtual/gpudriver}-dev \
 "
 
 GRAPHICS_RDEPENDS_append_omap-a15 = "\
diff --git a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics.bb b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics.bb
index 69cfea5..de9e8c4 100644
--- a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics.bb
+++ b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-graphics.bb
@@ -24,7 +24,7 @@ GRAPHICS_WAYLAND_append_k3 = "\
 GRAPHICS_RDEPENDS = "\
     libgbm \
     ${PREFERRED_PROVIDER_virtual/egl} \
-    ${@bb.utils.contains('MACHINE_FEATURES','sgx','ti-sgx-ddk-km','',d)} \
+    ${@bb.utils.contains('MACHINE_FEATURES','sgx','${PREFERRED_PROVIDER_virtual/gpudriver}','',d)} \
     ${@bb.utils.contains('MACHINE_FEATURES','sgx','glmark2','',d)} \
 "
 
-- 
1.9.1



^ permalink raw reply related

* Re: [Qemu-devel] [PATCH] memory: do not do out of bound notification
From: Paolo Bonzini @ 2019-06-20 12:04 UTC (permalink / raw)
  To: Yan Zhao; +Cc: Auger Eric, qemu-devel@nongnu.org, Peter Xu
In-Reply-To: <20190620105752.GD9303@joy-OptiPlex-7040>

On 20/06/19 12:57, Yan Zhao wrote:
> On Thu, Jun 20, 2019 at 04:35:29PM +0800, Paolo Bonzini wrote:
>> On 20/06/19 06:02, Peter Xu wrote:
>>> Seems workable, to be explicit - we can even cut it into chunks with
>>> different size to be efficient.
>>
>> Yes, this is not hard (completely untested):
>>
>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
>> index 44b1231157..541538bc6c 100644
>> --- a/hw/i386/intel_iommu.c
>> +++ b/hw/i386/intel_iommu.c
>> @@ -3388,39 +3388,34 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
>>      }
>>  
>>      assert(start <= end);
>> -    size = end - start;
>> +    while (end > start) {
>> +        size = end - start;
>> +        /* Only keep the lowest bit of either size or start.  */
>> +        size = MIN(size & -size, start & -start);
>> +        /* Should not happen, but limit to address width too just in case */
>> +        size = MIN(size, 1ULL << s->aw_bits);
>>  
>> -    if (ctpop64(size) != 1) {
>> -        /*
>> -         * This size cannot format a correct mask. Let's enlarge it to
>> -         * suite the minimum available mask.
>> -         */
>> -        int n = 64 - clz64(size);
>> -        if (n > s->aw_bits) {
>> -            /* should not happen, but in case it happens, limit it */
>> -            n = s->aw_bits;
>> -        }
>> -        size = 1ULL << n;
>> -    }
>> +        assert((start & (size - 1)) == 0);
>>  
>> -    entry.target_as = &address_space_memory;
>> -    /* Adjust iova for the size */
>> -    entry.iova = n->start & ~(size - 1);
>> -    /* This field is meaningless for unmap */
>> -    entry.translated_addr = 0;
>> -    entry.perm = IOMMU_NONE;
>> -    entry.addr_mask = size - 1;
>> +        entry.target_as = &address_space_memory;
>> +        entry.iova = start;
>> +        /* This field is meaningless for unmap */
>> +        entry.translated_addr = 0;
>> +        entry.perm = IOMMU_NONE;
>> +        entry.addr_mask = size - 1;
>>  
>> -    trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
>> -                             VTD_PCI_SLOT(as->devfn),
>> -                             VTD_PCI_FUNC(as->devfn),
>> -                             entry.iova, size);
>> +        trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
>> +                                 VTD_PCI_SLOT(as->devfn),
>> +                                 VTD_PCI_FUNC(as->devfn),
>> +                                 entry.iova, size);
>>  
>> -    map.iova = entry.iova;
>> -    map.size = entry.addr_mask;
>> -    iova_tree_remove(as->iova_tree, &map);
>> +        map.iova = entry.iova;
>> +        map.size = entry.addr_mask;
>> +        iova_tree_remove(as->iova_tree, &map);
>>  
>> -    memory_region_notify_one(n, &entry);
>> +        memory_region_notify_one(n, &entry);
>> +        start += size;
>> +    }
>>  }
>>  
>>  static void vtd_address_space_unmap_all(IntelIOMMUState *s)
>>
>>
>> Yan,
>>
>> if something like this works for you, let me know and I will submit it
>> as a proper patch.
> 
> Thanks and I'll try it tomorrow and let you know the result.
> But may I know why it cannot simply be like below?

Because the API is that addr_mask is a power of two minus 1.

Paolo

> Thanks
> Yan
> 
> 
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index b0d8a1c..2956db6 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -3374,7 +3374,6 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
>      IntelIOMMUState *s = as->iommu_state;
>      DMAMap map;
> 
>      /*
>       * Note: all the codes in this function has a assumption that IOVA
>       * bits are no more than VTD_MGAW bits (which is restricted by
> @@ -3392,23 +3391,8 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
>      assert(start <= end);
>      size = end - start;
> 
> -    if (ctpop64(size) != 1) {
> -        /*
> -         * This size cannot format a correct mask. Let's enlarge it to
> -         * suite the minimum available mask.
> -         */
> -        int n = 64 - clz64(size);
> -        if (n > s->aw_bits) {
> -            /* should not happen, but in case it happens, limit it */
> -            n = s->aw_bits;
> -        }
> -        size = 1ULL << n;
> -    }
> -
> -
>      entry.target_as = &address_space_memory;
> -    /* Adjust iova for the size */
> -    entry.iova = n->start & ~(size - 1);
> +    entry.iova = n->start;
>      /* This field is meaningless for unmap */
>      entry.translated_addr = 0;
>      entry.perm = IOMMU_NONE;
> 
> 
> 



^ permalink raw reply

* Re: [Qemu-devel] [PATCH v5 0/3] fw_cfg: Add edk2_add_host_crypto_policy()
From: Philippe Mathieu-Daudé @ 2019-06-20 12:24 UTC (permalink / raw)
  To: Laszlo Ersek, qemu-devel
  Cc: Peter Maydell, Andrew Jones, Eduardo Habkost, Michael S. Tsirkin,
	qemu-arm, Paolo Bonzini
In-Reply-To: <20190620121930.9729-1-philmd@redhat.com>

On 6/20/19 2:19 PM, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> This series add edk2_add_host_crypto_policy() and the Edk2Crypto object.
> 
> The Edk2Crypto object is used to hold configuration values specific
> to EDK2.
> 
> So far only the 'https' policy is supported.
> 
> A usercase example is the 'HTTPS Boof' feature of OVMF [*].
> 
> Usage example:
> 
> $ qemu-system-x86_64 \
>     --object edk2_crypto,id=https,\
>         ciphers=/etc/crypto-policies/back-ends/openssl.config,\
>         cacerts=/etc/pki/ca-trust/extracted/edk2/cacerts.bin
> 
> (On Fedora these files are provided by the ca-certificates and
> crypto-policies packages).
> 
> [*]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
> 
> Since v4:
> - Addressed Laszlo comments (see patch#1 description)
> Since v3:
> - Addressed Markus' comments (do not care about heap)
> Since v2:
> - Split of
> Since v1:
> - Addressed Michael and Laszlo comments.

Please discard this cover, series sent again with patches properly attached.

^ permalink raw reply

* Re: [PATCH RFC] proc/meminfo: add NetBuffers counter for socket buffers
From: Konstantin Khlebnikov @ 2019-06-20 12:40 UTC (permalink / raw)
  To: Vlastimil Babka, linux-mm, linux-kernel, netdev
In-Reply-To: <9f611f72-c883-45e9-cb2a-824ba27356d9@suse.cz>

On 20.06.2019 15:03, Vlastimil Babka wrote:
> On 5/15/19 1:55 PM, Konstantin Khlebnikov wrote:
>> Socket buffers always were dark-matter that lives by its own rules.
> 
> Is the information even exported somewhere e.g. in sysfs or via netlink yet?

in /proc/self/net/protocols

protocol  size sockets  memory press maxhdr  slab module     cl co di ac io in de sh ss gs se re sp bi br ha uh gp em
PACKET    1408      0      -1   NI       0   no   kernel      n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n
PINGv6    1088      0      -1   NI       0   yes  kernel      y  y  y  n  n  y  n  n  y  y  y  y  n  y  y  y  y  y  n
RAWv6     1088      0      -1   NI       0   yes  kernel      y  y  y  n  y  y  y  n  y  y  y  y  n  y  y  y  y  n  n
UDPLITEv6 1080      0      -1   NI       0   yes  kernel      y  y  y  n  y  y  y  n  y  y  y  y  n  n  y  y  y  y  n
UDPv6     1080     21     111   NI       0   yes  kernel      y  y  y  n  y  n  y  n  y  y  y  y  n  n  y  y  y  y  n
TCPv6     2048  49297  442697   no     304   yes  kernel      y  y  y  y  y  y  y  y  y  y  y  y  y  n  y  y  y  y  y
UNIX      1024    158      -1   NI       0   yes  kernel      n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n
UDP-Lite   920      0      -1   NI       0   yes  kernel      y  y  y  n  y  y  y  n  y  y  y  y  y  n  y  y  y  y  n
PING       880      0      -1   NI       0   yes  kernel      y  y  y  n  n  y  n  n  y  y  y  y  n  y  y  y  y  y  n
RAW        888      0      -1   NI       0   yes  kernel      y  y  y  n  y  y  y  n  y  y  y  y  n  y  y  y  y  n  n
UDP        920      0     111   NI       0   yes  kernel      y  y  y  n  y  n  y  n  y  y  y  y  y  n  y  y  y  y  n
TCP       1888      0  442697   no     304   yes  kernel      y  y  y  y  y  y  y  y  y  y  y  y  y  n  y  y  y  y  y
NETLINK   1040      1      -1   NI       0   no   kernel      n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n  n

column 'sockets' is virtualized, while 'memory' is not

> 
>> This patch adds line NetBuffers that exposes most common kinds of them.
> 
> Did you encounter a situation where the number was significant and this
> would help finding out why memory is occupied?

Might be. In example above tcp buffers are 1,7G.
This is real server, with 0.5T ram though.

> 
>> TCP and UDP are most important species.
>> SCTP is added as example of modular protocol.
>> UNIX have no memory counter for now, should be easy to add.
>>
>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> 
> Right now it's a sum of a few values, which should be fine wrt
> /proc/meminfo overhead. But I guess netdev guys should have a say in
> this. Also you should update the corresponding Documentation/ file.

Later I send another proposal: even bigger sum - "MemKernel".
https://lore.kernel.org/linux-mm/155853600919.381.8172097084053782598.stgit@buzz/
Which gives estimation for all kinds of 'kernel' memory. It seems more useful for me.

> 
> Thanks,
> Vlastimil
> 
>> ---
>>   fs/proc/meminfo.c  |    5 ++++-
>>   include/linux/mm.h |    6 ++++++
>>   mm/page_alloc.c    |    3 ++-
>>   net/core/sock.c    |   20 ++++++++++++++++++++
>>   net/sctp/socket.c  |    2 +-
>>   5 files changed, 33 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
>> index 7bc14716fc5d..0ee2300a916d 100644
>> --- a/fs/proc/meminfo.c
>> +++ b/fs/proc/meminfo.c
>> @@ -41,6 +41,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>>   	unsigned long sreclaimable, sunreclaim, misc_reclaimable;
>>   	unsigned long kernel_stack_kb, page_tables, percpu_pages;
>>   	unsigned long anon_pages, file_pages, swap_cached;
>> +	unsigned long net_buffers;
>>   	long kernel_misc;
>>   	int lru;
>>   
>> @@ -66,12 +67,13 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>>   	kernel_stack_kb = global_zone_page_state(NR_KERNEL_STACK_KB);
>>   	page_tables = global_zone_page_state(NR_PAGETABLE);
>>   	percpu_pages = pcpu_nr_pages();
>> +	net_buffers = total_netbuffer_pages();
>>   
>>   	/* all other kinds of kernel memory allocations */
>>   	kernel_misc = i.totalram - i.freeram - anon_pages - file_pages
>>   		      - sreclaimable - sunreclaim - misc_reclaimable
>>   		      - (kernel_stack_kb >> (PAGE_SHIFT - 10))
>> -		      - page_tables - percpu_pages;
>> +		      - page_tables - percpu_pages - net_buffers;
>>   	if (kernel_misc < 0)
>>   		kernel_misc = 0;
>>   
>> @@ -137,6 +139,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>>   	show_val_kb(m, "VmallocUsed:    ", 0ul);
>>   	show_val_kb(m, "VmallocChunk:   ", 0ul);
>>   	show_val_kb(m, "Percpu:         ", percpu_pages);
>> +	show_val_kb(m, "NetBuffers:     ", net_buffers);
>>   	show_val_kb(m, "KernelMisc:     ", kernel_misc);
>>   
>>   #ifdef CONFIG_MEMORY_FAILURE
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 0e8834ac32b7..d0a58355bfb7 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -2254,6 +2254,12 @@ extern void si_meminfo_node(struct sysinfo *val, int nid);
>>   extern unsigned long arch_reserved_kernel_pages(void);
>>   #endif
>>   
>> +#ifdef CONFIG_NET
>> +extern unsigned long total_netbuffer_pages(void);
>> +#else
>> +static inline unsigned long total_netbuffer_pages(void) { return 0; }
>> +#endif
>> +
>>   extern __printf(3, 4)
>>   void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...);
>>   
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 3b13d3914176..fcdd7c6e72b9 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -5166,7 +5166,7 @@ void show_free_areas(unsigned int filter, nodemask_t *nodemask)
>>   		" active_file:%lu inactive_file:%lu isolated_file:%lu\n"
>>   		" unevictable:%lu dirty:%lu writeback:%lu unstable:%lu\n"
>>   		" slab_reclaimable:%lu slab_unreclaimable:%lu\n"
>> -		" mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n"
>> +		" mapped:%lu shmem:%lu pagetables:%lu bounce:%lu net_buffers:%lu\n"
>>   		" free:%lu free_pcp:%lu free_cma:%lu\n",
>>   		global_node_page_state(NR_ACTIVE_ANON),
>>   		global_node_page_state(NR_INACTIVE_ANON),
>> @@ -5184,6 +5184,7 @@ void show_free_areas(unsigned int filter, nodemask_t *nodemask)
>>   		global_node_page_state(NR_SHMEM),
>>   		global_zone_page_state(NR_PAGETABLE),
>>   		global_zone_page_state(NR_BOUNCE),
>> +		total_netbuffer_pages(),
>>   		global_zone_page_state(NR_FREE_PAGES),
>>   		free_pcp,
>>   		global_zone_page_state(NR_FREE_CMA_PAGES));
>> diff --git a/net/core/sock.c b/net/core/sock.c
>> index 75b1c950b49f..dfca4e024b74 100644
>> --- a/net/core/sock.c
>> +++ b/net/core/sock.c
>> @@ -142,6 +142,7 @@
>>   #include <trace/events/sock.h>
>>   
>>   #include <net/tcp.h>
>> +#include <net/udp.h>
>>   #include <net/busy_poll.h>
>>   
>>   static DEFINE_MUTEX(proto_list_mutex);
>> @@ -3573,3 +3574,22 @@ bool sk_busy_loop_end(void *p, unsigned long start_time)
>>   }
>>   EXPORT_SYMBOL(sk_busy_loop_end);
>>   #endif /* CONFIG_NET_RX_BUSY_POLL */
>> +
>> +#if IS_ENABLED(CONFIG_IP_SCTP)
>> +atomic_long_t sctp_memory_allocated;
>> +EXPORT_SYMBOL_GPL(sctp_memory_allocated);
>> +#endif
>> +
>> +unsigned long total_netbuffer_pages(void)
>> +{
>> +	unsigned long ret = 0;
>> +
>> +#if IS_ENABLED(CONFIG_IP_SCTP)
>> +	ret += atomic_long_read(&sctp_memory_allocated);
>> +#endif
>> +#ifdef CONFIG_INET
>> +	ret += atomic_long_read(&tcp_memory_allocated);
>> +	ret += atomic_long_read(&udp_memory_allocated);
>> +#endif
>> +	return ret;
>> +}
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index e4e892cc5644..9d11afdeeae4 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -107,7 +107,7 @@ static int sctp_sock_migrate(struct sock *oldsk, struct sock *newsk,
>>   			     enum sctp_socket_type type);
>>   
>>   static unsigned long sctp_memory_pressure;
>> -static atomic_long_t sctp_memory_allocated;
>> +extern atomic_long_t sctp_memory_allocated;
>>   struct percpu_counter sctp_sockets_allocated;
>>   
>>   static void sctp_enter_memory_pressure(struct sock *sk)
>>
> 


^ permalink raw reply

* Re: [PATCH 2/2] sha1-file: use OBJECT_INFO_NO_FETCH_IF_MISSING
From: Derrick Stolee @ 2019-06-20 12:39 UTC (permalink / raw)
  To: Jeff King, Christian Couder
  Cc: git, Junio C Hamano, Johannes Schindelin, Christian Couder
In-Reply-To: <20190620085009.GC3952@sigill.intra.peff.net>

On 6/20/2019 4:50 AM, Jeff King wrote:
> On Thu, Jun 20, 2019 at 10:30:26AM +0200, Christian Couder wrote:
> 
>> Currently the OBJECT_INFO_FOR_PREFETCH flag is used to check
>> if we should fetch objects from promisor remotes when we
>> haven't found them elsewhere.
>>
>> Now that OBJECT_INFO_NO_FETCH_IF_MISSING exists, let's use
>> it instead to be more correct in case this new flag is ever
>> used without OBJECT_INFO_QUICK.
> 
> I said earlier that this one would need to be tweaked for the new
> upstream name. But actually, I think it is not necessary after Stolee's
> patch.

Yes, I believe that 31f5256c82  does an equivalent thing to the
combination of these patches.

Thanks,
-Stolee


^ permalink raw reply

* Re: [PATCH 5/8] btrfs: stop using block_rsv_release_bytes everywhere
From: Josef Bacik @ 2019-06-20 12:39 UTC (permalink / raw)
  To: Nikolay Borisov; +Cc: Josef Bacik, linux-btrfs
In-Reply-To: <8fb785be-79ad-1870-447c-fc87f7bebb04@suse.com>

On Thu, Jun 20, 2019 at 11:32:21AM +0300, Nikolay Borisov wrote:
> 
> 
> On 19.06.19 г. 20:47 ч., Josef Bacik wrote:
> > block_rsv_release_bytes() is the internal to the block_rsv code, and
> > shouldn't be called directly by anything else.  Switch all users to the
> > exported helpers.
> > 
> > Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> > ---
> >  fs/btrfs/extent-tree.c | 14 ++++++--------
> >  1 file changed, 6 insertions(+), 8 deletions(-)
> > 
> > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> > index 6995edf887e1..d1fce37107b4 100644
> > --- a/fs/btrfs/extent-tree.c
> > +++ b/fs/btrfs/extent-tree.c
> > @@ -4750,12 +4750,11 @@ static void btrfs_inode_rsv_release(struct btrfs_inode *inode, bool qgroup_free)
> >  void btrfs_delayed_refs_rsv_release(struct btrfs_fs_info *fs_info, int nr)
> >  {
> >  	struct btrfs_block_rsv *block_rsv = &fs_info->delayed_refs_rsv;
> > -	struct btrfs_block_rsv *global_rsv = &fs_info->global_block_rsv;
> >  	u64 num_bytes = btrfs_calc_trans_metadata_size(fs_info, nr);
> >  	u64 released = 0;
> >  
> > -	released = block_rsv_release_bytes(fs_info, block_rsv, global_rsv,
> > -					   num_bytes, NULL);
> > +	released = __btrfs_block_rsv_release(fs_info, block_rsv, num_bytes,
> > +					     NULL);
> 
> You should use btrfs_block_rsv_release when qgroup_to_release is NULL.
> 

btrfs_block_rsv_release() is a void, __btrfs_block_rsv_release returns how much
was free'd.  This could be cleaned up later, but I'm purposefully trying to not
change code and just move things around.  Thanks,

Josef

^ permalink raw reply

* [thud][PATCH v2] arago-prefs: specify GLES providers for J7 EVM
From: Anand Balagopalakrishnan @ 2019-06-20 12:38 UTC (permalink / raw)
  To: meta-arago
In-Reply-To: <1560958508-141402-1-git-send-email-anandb@ti.com>

Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
---
 meta-arago-distro/conf/distro/include/arago-prefs.inc | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta-arago-distro/conf/distro/include/arago-prefs.inc b/meta-arago-distro/conf/distro/include/arago-prefs.inc
index a96569f..e9e9177 100644
--- a/meta-arago-distro/conf/distro/include/arago-prefs.inc
+++ b/meta-arago-distro/conf/distro/include/arago-prefs.inc
@@ -9,6 +9,12 @@ PREFERRED_PROVIDER_virtual/gettext = "gettext"
 PREFERRED_PROVIDER_virtual/egl = "ti-sgx-ddk-um"
 PREFERRED_PROVIDER_virtual/libgles1 = "ti-sgx-ddk-um"
 PREFERRED_PROVIDER_virtual/libgles2 = "ti-sgx-ddk-um"
+
+# J7 has a Rogue GPU core
+PREFERRED_PROVIDER_virtual/egl_j7-evm = "ti-img-rogue-umlibs"
+PREFERRED_PROVIDER_virtual/libgles1_j7-evm = "ti-img-rogue-umlibs"
+PREFERRED_PROVIDER_virtual/libgles2_j7-evm = "ti-img-rogue-umlibs"
+
 PREFERRED_PROVIDER_libgbm = "libgbm"
 PREFERRED_PROVIDER_libgbm-dev = "libgbm-dev"
 
-- 
1.9.1



^ permalink raw reply related

* Re: [igt-dev] [PATCH i-g-t v2] Add Arm drivers as supported drivers by igt.
From: Liviu Dudau @ 2019-06-20 12:39 UTC (permalink / raw)
  To: IGT GPU Tool
In-Reply-To: <20190620105021.GD22949@platvala-desk.ger.corp.intel.com>

On Thu, Jun 20, 2019 at 01:50:21PM +0300, Petri Latvala wrote:
> On Thu, Jun 20, 2019 at 10:28:42AM +0100, Liviu Dudau wrote:
> > On Thu, Jun 20, 2019 at 11:00:24AM +0300, Petri Latvala wrote:
> > > On Wed, Jun 19, 2019 at 04:13:58PM +0100, Liviu Dudau wrote:
> > > > Add the drivers maintained by Arm developers to the igt.
> > > > 
> > > > v2: Order the modules array entries alphabetically, as per
> > > > Petri Latvala's suggestion.
> > > > 
> > > > Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
> > > > ---
> > > >  lib/drmtest.c | 3 +++
> > > >  lib/drmtest.h | 4 ++++
> > > >  2 files changed, 7 insertions(+)
> > > > 
> > > > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > > > index 25f203530..17bb87d1f 100644
> > > > --- a/lib/drmtest.c
> > > > +++ b/lib/drmtest.c
> > > > @@ -205,7 +205,10 @@ static const struct module {
> > > >  	void (*modprobe)(const char *name);
> > > >  } modules[] = {
> > > >  	{ DRIVER_AMDGPU, "amdgpu" },
> > > > +	{ DRIVER_HDLCD, "hdlcd" },
> > > >  	{ DRIVER_INTEL, "i915", modprobe_i915 },
> > > > +	{ DRIVER_KOMEDA, "komeda" },
> > > > +	{ DRIVER_MALIDP, "mali_dp" },
> > > 
> > 
> > Hi Petri,
> > 
> > > 
> > > Should this be "mali-dp" instead?
> > >
> > 
> > insmod/modprobe places some equivalence between dashes and underscores. The
> > platform driver structure in the kernel is called "mali-dp", but the module
> > is called "mali_dp" (confusing, I know, but at least that is what lsmod shows
> > after inserting "mali-dp" module).
> > 
> > Not sure what the correct answer is here, I thought we're using module names.
> 
> 
> It's both :P
> 
> The string is compared to the driver_name field (or what was the name)
> to see if the device is DRIVER_MALIDP, and if the function pointer is
> not set, the string is also used for modprobe().
> 
> So the string should be the device's driver_name, and the function
> pointer set to a function that loads the .ko if the module name is
> different.

Went back to the list of modules and (cough) the module is called mali-dp.ko.
No idea why lsmod shows it as mali_dp :(

I'm sending v3 now with the fix, thank you for reporting it!

Best regards,
Liviu

> 
> 
> -- 
> Petri Latvala

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply

* Re: [Qemu-devel] [PATCH v17 01/10] hw/arm/virt: Add RAS platform version for migration
From: Igor Mammedov @ 2019-06-20 12:04 UTC (permalink / raw)
  To: Dongjiu Geng
  Cc: peter.maydell, ehabkost, kvm, mst, mtosatti, qemu-devel, linuxarm,
	shannon.zhaosl, zhengxiang9, qemu-arm, james.morse, xuwei5,
	jonathan.cameron, pbonzini, lersek, rth
In-Reply-To: <1557832703-42620-2-git-send-email-gengdongjiu@huawei.com>

On Tue, 14 May 2019 04:18:14 -0700
Dongjiu Geng <gengdongjiu@huawei.com> wrote:

> Support this feature since version 4.1, disable it by
> default in the old version.
> 
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> ---
>  hw/arm/virt.c         | 6 ++++++
>  include/hw/arm/virt.h | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 5331ab7..7bdd41b 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -2043,8 +2043,14 @@ DEFINE_VIRT_MACHINE_AS_LATEST(4, 1)
>  
>  static void virt_machine_4_0_options(MachineClass *mc)
>  {
> +    VirtMachineClass *vmc = VIRT_MACHINE_CLASS(OBJECT_CLASS(mc));
> +
>      virt_machine_4_1_options(mc);
>      compat_props_add(mc->compat_props, hw_compat_4_0, hw_compat_4_0_len);
> +    /* Disable memory recovery feature for 4.0 as RAS support was
> +     * introduced with 4.1.
> +     */
> +    vmc->no_ras = true;

So it would mean that the feature is enabled unconditionally for
new machine types and consumes resources whether user needs it or not.

In light of the race for leaner QEMU and faster startup times,
it might be better to make RAS optional and make user explicitly
enable it using a machine option.


>  }
>  DEFINE_VIRT_MACHINE(4, 0)
>  
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index 4240709..7f1a033 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -104,6 +104,7 @@ typedef struct {
>      bool disallow_affinity_adjustment;
>      bool no_its;
>      bool no_pmu;
> +    bool no_ras;
>      bool claim_edge_triggered_timers;
>      bool smbios_old_sys_ver;
>      bool no_highmem_ecam;



^ permalink raw reply

* Re: [PATCH] sched/isolation: Prefer housekeeping cpu in local node
From: Peter Zijlstra @ 2019-06-20 12:38 UTC (permalink / raw)
  To: Wanpeng Li; +Cc: linux-kernel, Ingo Molnar, Ingo Molnar, Frederic Weisbecker
In-Reply-To: <1561030614-17026-1-git-send-email-wanpengli@tencent.com>

On Thu, Jun 20, 2019 at 07:36:54PM +0800, Wanpeng Li wrote:
> From: Wanpeng Li <wanpengli@tencent.com>
> 
> In real product setup, there will be houseeking cpus in each nodes, it 
> is prefer to do housekeeping from local node, fallback to global online 
> cpumask if failed to find houseeking cpu from local node.
> 
> Cc: Ingo Molnar <mingo@redhat.com> 
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
> ---
>  kernel/sched/isolation.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> index 123ea07..9eb6805 100644
> --- a/kernel/sched/isolation.c
> +++ b/kernel/sched/isolation.c
> @@ -16,9 +16,16 @@ static unsigned int housekeeping_flags;
>  
>  int housekeeping_any_cpu(enum hk_flags flags)
>  {
> +	int cpu;
> +
>  	if (static_branch_unlikely(&housekeeping_overridden))
> -		if (housekeeping_flags & flags)
> -			return cpumask_any_and(housekeeping_mask, cpu_online_mask);
> +		if (housekeeping_flags & flags) {
> +			cpu = cpumask_any_and(housekeeping_mask, cpu_cpu_mask(smp_processor_id()));
> +			if (cpu < nr_cpu_ids)
> +				return cpu;
> +			else
> +				return cpumask_any_and(housekeeping_mask, cpu_online_mask);
> +		}
>  	return smp_processor_id();
>  }
>  EXPORT_SYMBOL_GPL(housekeeping_any_cpu);

Why not something like so? IIRC there's more places that want this, but
I can't seem to remember quite where.

diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 123ea07a3f3b..1cceab5f094c 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -16,9 +16,15 @@ static unsigned int housekeeping_flags;
 
 int housekeeping_any_cpu(enum hk_flags flags)
 {
-	if (static_branch_unlikely(&housekeeping_overridden))
-		if (housekeeping_flags & flags)
+	if (static_branch_unlikely(&housekeeping_overridden)) {
+		if (housekeeping_flags & flags) {
+			cpu = sched_numa_find_closest(housekeeping_mask, smp_processor_id());
+			if (cpu < nr_cpu_ids)
+				return cpu;
+
 			return cpumask_any_and(housekeeping_mask, cpu_online_mask);
+		}
+	}
 	return smp_processor_id();
 }
 EXPORT_SYMBOL_GPL(housekeeping_any_cpu);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b08dee29ef5e..0db7431c7207 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1212,9 +1212,6 @@ enum numa_topology_type {
 extern enum numa_topology_type sched_numa_topology_type;
 extern int sched_max_numa_distance;
 extern bool find_numa_distance(int distance);
-#endif
-
-#ifdef CONFIG_NUMA
 extern void sched_init_numa(void);
 extern void sched_domains_numa_masks_set(unsigned int cpu);
 extern void sched_domains_numa_masks_clear(unsigned int cpu);
@@ -1224,6 +1221,8 @@ static inline void sched_domains_numa_masks_set(unsigned int cpu) { }
 static inline void sched_domains_numa_masks_clear(unsigned int cpu) { }
 #endif
 
+extern int sched_numa_find_closest(const struct cpumask *cpus, int cpu);
+
 #ifdef CONFIG_NUMA_BALANCING
 /* The regions in numa_faults array from task_struct */
 enum numa_faults_stats {
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 63184cf0d0d7..408e94a6637c 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1726,6 +1726,20 @@ void sched_domains_numa_masks_clear(unsigned int cpu)
 
 #endif /* CONFIG_NUMA */
 
+int sched_numa_find_closest(const struct cpumask *cpus, int cpu)
+{
+#ifdef CONFIG_NUMA
+	int i, j = cpu_to_node(cpu);
+
+	for (i = 0; i < sched_domains_numa_levels; ++) {
+		cpu = cpumask_any_and(cpus, sched_domains_numa_mask[i][j]);
+		if (cpu < nr_cpu_ids)
+			return cpu;
+	}
+#endif
+	return nr_cpu_ids;
+}
+
 static int __sdt_alloc(const struct cpumask *cpu_map)
 {
 	struct sched_domain_topology_level *tl;

^ permalink raw reply related

* Re: [Qemu-devel] [QEMU PATCH v4 0/10]: target/i386: kvm: Add support for save and restore of nested state
From: Paolo Bonzini @ 2019-06-20 12:38 UTC (permalink / raw)
  To: Liran Alon, qemu-devel
  Cc: ehabkost, kvm, maran.wilson, mtosatti, dgilbert, rth, jmattson
In-Reply-To: <20190619162140.133674-1-liran.alon@oracle.com>

On 19/06/19 18:21, Liran Alon wrote:
> Hi,
> 
> This series aims to add support for QEMU to be able to migrate VMs that
> are running nested hypervisors. In order to do so, it utilizes the new
> IOCTLs introduced in KVM commit 8fcc4b5923af ("kvm: nVMX: Introduce
> KVM_CAP_NESTED_STATE") which was created for this purpose.

Applied with just three minor changes that should be uncontroversial:

> 6rd patch updates linux-headers to have updated struct kvm_nested_state.
> The updated struct now have explicit fields for the data portion.

Changed patch title to "linux-headers: sync with latest KVM headers from
Linux 5.2"

> 7rd patch add vmstate support for saving/restoring kernel integer types (e.g. __u16).
> 
> 8th patch adds support for saving and restoring nested state in order to migrate
> guests which run a nested hypervisor.

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index e924663f32..f3cf6e1b27 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1671,10 +1671,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
             struct kvm_vmx_nested_state_hdr *vmx_hdr =
                 &env->nested_state->hdr.vmx;

+            env->nested_state->format = KVM_STATE_NESTED_FORMAT_VMX;
             vmx_hdr->vmxon_pa = -1ull;
             vmx_hdr->vmcs12_pa = -1ull;
         }
-
     }

     cpu->kvm_msr_buf = g_malloc0(MSR_BUF_SIZE);

which is a no-op since KVM_STATE_NESTED_FORMAT_VMX is zero, but it's tidy.

> 9th patch add support for KVM_CAP_EXCEPTION_PAYLOAD. This new KVM capability
> allows userspace to properly distingiush between pending and injecting exceptions.
> 
> 10th patch changes the nested virtualization migration blocker to only
> be added when kernel lack support for one of the capabilities required
> for correct nested migration. i.e. Either KVM_CAP_NESTED_STATE or
> KVM_CAP_EXCEPTION_PAYLOAD.

Had to disable this for SVM unfortunately.

^ permalink raw reply related

* [cip-dev] [PATCH 4.4-cip] spi: pxa2xx: Fix build error because of missing header
From: Ben Hutchings @ 2019-06-20 12:37 UTC (permalink / raw)
  To: cip-dev

From: Mika Westerberg <mika.westerberg@linux.intel.com>

commit 089bd46d8bc1fe5a28351e82e4adcaa5a40121b5 upstream.

Kbuild test robot reports:

  drivers/spi/spi-pxa2xx.c: In function ?setup_cs?:
  drivers/spi/spi-pxa2xx.c:1190:20: error: implicit declaration of function ?desc_to_gpio?
  ...

Reason for this is the fact that those functions are declared in
linux/gpio/consumer.h which is not included in the driver. Fix this by
including it.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
This fixes a build regression for some configurations since I applied
the backport of commit 3d3bc50700ba "spi: pxa2xx: Add support for GPIO
descriptor chip selects".

Ben.

 drivers/spi/spi-pxa2xx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 9233a1cb4dee..02685ccaa97b 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -28,6 +28,7 @@
 #include <linux/spi/spi.h>
 #include <linux/delay.h>
 #include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/slab.h>
 #include <linux/clk.h>
 #include <linux/pm_runtime.h>
-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

^ permalink raw reply related

* Re: [Qemu-devel] [RFC] spice-core: allow setting properties from QMP
From: Kevin Pouget @ 2019-06-20 11:54 UTC (permalink / raw)
  To: Eric Blake, spice-devel; +Cc: Marc-Andre Lureau, qemu-devel
In-Reply-To: <e9fcdbfd-cde2-fc91-ce1d-6bfe06d39c4f@redhat.com>

Hello Eric,

> A new command may be okay, however,

thanks, I've fix the typos and updated the patch to use an Enum, which
indeed makes more sense.

I've also updated "spice-query" command to provide the current value
of the "video-codec" property,
but it made me wonder if I should improve this QMP interface with a
json list, or keep the current string-based list
("enc1:codec1;enc2:codec2").

I CC the spice-devel list to get their point of view

The current behavior is:

--> { "execute": "set-spice", "arguments": { "property":
"video-codecs", "value": "spice:mjpeg;gstreamer:h264" } }
<-- {"return":{},"id":"libvirt-23"}

--> { "execute": "query-spice" }
<-- {.... "video-codecs": "spice:mjpeg;gstreamer:h264;" ....}


I put the new version of the RFC patch below

best regards,

Kevin

---

This patch allows setting spice properties from the QMP interface.

At the moment, only the 'video-codecs' property is supported.

Signed-off-by: Kevin Pouget <kpouget@redhat.com>
---
 qapi/ui.json    | 42 ++++++++++++++++++++++++++++++++++++++++--
 ui/spice-core.c | 21 +++++++++++++++++++++
 2 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/qapi/ui.json b/qapi/ui.json
index 59e412139a..5f67096bcb 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -211,12 +211,16 @@
 #
 # @channels: a list of @SpiceChannel for each active spice channel
 #
+# @video-codecs: The list of encoders:codecs currently allowed for
+#                video streaming (since: ...)
+#
 # Since: 0.14.0
 ##
 { 'struct': 'SpiceInfo',
   'data': {'enabled': 'bool', 'migrated': 'bool', '*host': 'str',
'*port': 'int',
            '*tls-port': 'int', '*auth': 'str', '*compiled-version': 'str',
-           'mouse-mode': 'SpiceQueryMouseMode', '*channels': ['SpiceChannel']},
+           'mouse-mode': 'SpiceQueryMouseMode', '*channels': ['SpiceChannel'],
+           'video-codecs': 'str'},
   'if': 'defined(CONFIG_SPICE)' }

 ##
@@ -257,7 +261,8 @@
 #                "tls": false
 #             },
 #             [ ... more channels follow ... ]
-#          ]
+#          ],
+#          "video-codecs": "spice:mjpeg;gstreamer:h264;"
 #       }
 #    }
 #
@@ -265,6 +270,39 @@
 { 'command': 'query-spice', 'returns': 'SpiceInfo',
   'if': 'defined(CONFIG_SPICE)' }

+##
+# @SpiceProperty:
+#
+# An enumeration of Spice properties that can be set at runtime.
+#
+# @video-codecs: the ;-separated list of video-codecs allowed for
+# spice-server video streaming.
+#
+# Since: ...
+##
+{ 'enum': 'SpiceProperty',
+  'data': [ 'video-codecs'],
+  'if': 'defined(CONFIG_SPICE)' }
+
+##
+# @set-spice:
+#
+# Set Spice properties.
+# @property: the SPICE property to modify
+# @value: the new value to affect to this property
+#
+# Since: ...
+#
+# Example:
+#
+# -> { "execute": "set-spice", "arguments": { "property": "video-codecs",
+#                                             "value": "spice:mjpeg;" } }
+# <- { "returns": {} }
+##
+{ 'command': 'set-spice',
+  'data': {'property': 'SpiceProperty', 'value': 'str'},
+  'if': 'defined(CONFIG_SPICE)' }
+
 ##
 # @SPICE_CONNECTED:
 #
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 63e8694df8..1660f49f15 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -506,6 +506,25 @@ static QemuOptsList qemu_spice_opts = {
     },
 };

+void qmp_set_spice(SpiceProperty property, const char *value, Error **errp)
+{
+    int invalid_codecs;
+
+    switch(property) {
+    case SPICE_PROPERTY_VIDEO_CODECS:
+        invalid_codecs = spice_server_set_video_codecs(spice_server, value);
+
+        if (invalid_codecs) {
+            error_setg(errp, "Found %d invalid video-codecs while
setting spice"
+                       " property 'video-codec=%s'", invalid_codecs, value);
+        }
+        break;
+    default:
+        /* only reached in case of version mismatched */
+        error_setg(errp, "Property #%d not supported.", property);
+    }
+}
+
 SpiceInfo *qmp_query_spice(Error **errp)
 {
     QemuOpts *opts = QTAILQ_FIRST(&qemu_spice_opts.head);
@@ -555,6 +574,8 @@ SpiceInfo *qmp_query_spice(Error **errp)
                        SPICE_QUERY_MOUSE_MODE_SERVER :
                        SPICE_QUERY_MOUSE_MODE_CLIENT;

+    info->video_codecs = spice_server_get_video_codecs(spice_server);
+
     /* for compatibility with the original command */
     info->has_channels = true;
     info->channels = qmp_query_spice_channels();
-- 
2.21.0


^ permalink raw reply related

* [PATCH] spi/acpi: avoid spurious matches during slave enumeration
From: Ard Biesheuvel @ 2019-06-20 12:36 UTC (permalink / raw)
  To: linux-spi
  Cc: broonie, Ard Biesheuvel, Mika Westerberg, andy.shevchenko,
	masahisa.kojima, Rafael J. Wysocki, Jarkko Nikula, linux-acpi,
	Lukas Wunner

In the new SPI ACPI slave enumeration code, we use the value of
lookup.max_speed_khz as a flag to decide whether a match occurred.
However, doing so only makes sense if we initialize its value to
zero beforehand, or otherwise, random junk from the stack will
cause spurious matches.

So zero initialize the lookup struct fully, and only set the non-zero
members explicitly.

Fixes: 4c3c59544f33 ("spi/acpi: enumerate all SPI slaves in the namespace")
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: andy.shevchenko@gmail.com
Cc: masahisa.kojima@linaro.org
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: linux-acpi@vger.kernel.org
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/spi/spi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index a31e1e291335..4057f256ef76 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1953,7 +1953,7 @@ static acpi_status acpi_register_spi_device(struct spi_controller *ctlr,
 {
 	acpi_handle parent_handle = NULL;
 	struct list_head resource_list;
-	struct acpi_spi_lookup lookup;
+	struct acpi_spi_lookup lookup = {};
 	struct spi_device *spi;
 	int ret;
 
@@ -1962,8 +1962,6 @@ static acpi_status acpi_register_spi_device(struct spi_controller *ctlr,
 		return AE_OK;
 
 	lookup.ctlr		= ctlr;
-	lookup.mode		= 0;
-	lookup.bits_per_word	= 0;
 	lookup.irq		= -1;
 
 	INIT_LIST_HEAD(&resource_list);
-- 
2.20.1


^ permalink raw reply related

* [Qemu-devel] [PATCH RESEND v5 0/3] fw_cfg: Add edk2_add_host_crypto_policy()
From: Philippe Mathieu-Daudé @ 2019-06-20 12:21 UTC (permalink / raw)
  To: qemu-devel, Laszlo Ersek
  Cc: Peter Maydell, Andrew Jones, Eduardo Habkost, Michael S. Tsirkin,
	qemu-arm, Paolo Bonzini, Philippe Mathieu-Daudé

Hi,

This series add edk2_add_host_crypto_policy() and the Edk2Crypto object.

The Edk2Crypto object is used to hold configuration values specific
to EDK2.

So far only the 'https' policy is supported.

A usercase example is the 'HTTPS Boof' feature of OVMF [*].

Usage example:

$ qemu-system-x86_64 \
    --object edk2_crypto,id=https,\
        ciphers=/etc/crypto-policies/back-ends/openssl.config,\
        cacerts=/etc/pki/ca-trust/extracted/edk2/cacerts.bin

(On Fedora these files are provided by the ca-certificates and
crypto-policies packages).

[*]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README

Since v4:
- Addressed Laszlo comments (see patch#1 description)
Since v3:
- Addressed Markus' comments (do not care about heap)
Since v2:
- Split of
Since v1:
- Addressed Michael and Laszlo comments.

Please review,

Phil.

$ git backport-diff -u fw_cfg_edk2_crypto_policies-v3
Key:
[####] : number of functional differences between upstream/downstream patch
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/3:[0164] [FC] 'hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()'
002/3:[----] [--] 'hw/i386: Use edk2_add_host_crypto_policy()'
003/3:[----] [--] 'hw/arm/virt: Use edk2_add_host_crypto_policy()'

v4: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04300.html
v3: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02965.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02522.html
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg01598.html

Philippe Mathieu-Daudé (3):
  hw/firmware: Add Edk2Crypto and edk2_add_host_crypto_policy()
  hw/i386: Use edk2_add_host_crypto_policy()
  hw/arm/virt: Use edk2_add_host_crypto_policy()

 MAINTAINERS                             |   2 +
 hw/Makefile.objs                        |   1 +
 hw/arm/virt.c                           |   7 +
 hw/firmware/Makefile.objs               |   1 +
 hw/firmware/uefi_edk2_crypto_policies.c | 209 ++++++++++++++++++++++++
 hw/i386/pc.c                            |   7 +
 include/hw/firmware/uefi_edk2.h         |  30 ++++
 7 files changed, 257 insertions(+)
 create mode 100644 hw/firmware/Makefile.objs
 create mode 100644 hw/firmware/uefi_edk2_crypto_policies.c
 create mode 100644 include/hw/firmware/uefi_edk2.h

-- 
2.20.1


^ permalink raw reply

* Re: [igt-dev] [PATCH i-g-t v2] Add Arm drivers as supported drivers by igt.
From: Daniel Vetter @ 2019-06-20 12:36 UTC (permalink / raw)
  To: Liviu Dudau; +Cc: IGT GPU Tool, Petri Latvala
In-Reply-To: <20190619151358.22815-1-liviu.dudau@arm.com>

On Wed, Jun 19, 2019 at 04:13:58PM +0100, Liviu Dudau wrote:
> Add the drivers maintained by Arm developers to the igt.
> 
> v2: Order the modules array entries alphabetically, as per
> Petri Latvala's suggestion.
> 
> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Still kinda wondering why you need this here ... kms is supposed to be
hw/driver agnostic, so DRIVER_ANY should work.

Maybe you want to check specific constraints in your tests, but then we
need something like igt_require(is_komeda_driver(fd)); which can inspect
what you're actually running on when the test executes.

The drivers in this list thus far are all about exercising the gem side of
things, where you _really_ don't want to open random garbage. Because the
ioctls aren't even defined.

On kms all ioctls are cross-driver, and only once you've opened something
does it make sense to check for features and stuff (looking at properties,
or getcap flags, or whatever).

Cheers, Daniel

PS: Yes I know that some of the DRIVER_I915 | DRIVER_AMDGPU tests really
should have been converted to DRIVER_ANY instead. I didn't catch that in
review way back, but I think I explained to Harry et al meanwhile ...

> ---
>  lib/drmtest.c | 3 +++
>  lib/drmtest.h | 4 ++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 25f203530..17bb87d1f 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -205,7 +205,10 @@ static const struct module {
>  	void (*modprobe)(const char *name);
>  } modules[] = {
>  	{ DRIVER_AMDGPU, "amdgpu" },
> +	{ DRIVER_HDLCD, "hdlcd" },
>  	{ DRIVER_INTEL, "i915", modprobe_i915 },
> +	{ DRIVER_KOMEDA, "komeda" },
> +	{ DRIVER_MALIDP, "mali_dp" },
>  	{ DRIVER_PANFROST, "panfrost" },
>  	{ DRIVER_V3D, "v3d" },
>  	{ DRIVER_VC4, "vc4" },
> diff --git a/lib/drmtest.h b/lib/drmtest.h
> index 6c4c3899c..952f0c4b6 100644
> --- a/lib/drmtest.h
> +++ b/lib/drmtest.h
> @@ -45,6 +45,10 @@
>  #define DRIVER_AMDGPU	(1 << 4)
>  #define DRIVER_V3D	(1 << 5)
>  #define DRIVER_PANFROST	(1 << 6)
> +#define DRIVER_HDLCD	(1 << 7)
> +#define DRIVER_MALIDP	(1 << 8)
> +#define DRIVER_KOMEDA	(1 << 9)
> +
>  /*
>   * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
>   * with vgem as well as a supported driver, you can end up with a
> -- 
> 2.22.0
> 
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply

* [thud][PATCH 1/1] img-pvr-drivers: specify SGX and Rogue as virtual providers for GPU driver
From: Anand Balagopalakrishnan @ 2019-06-20 12:36 UTC (permalink / raw)
  To: meta-ti

- specify both SGX and Rogue drivers as virtual providers for GPU driver
- remove unused omapdrm-pvr provides

Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
---
 recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.10.5187610.bb | 4 +++-
 recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb       | 8 ++------
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.10.5187610.bb b/recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.10.5187610.bb
index a79abfd..1c73362 100644
--- a/recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.10.5187610.bb
+++ b/recipes-bsp/powervr-drivers/ti-img-rogue-driver_1.10.5187610.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://README;beginline=15;endline=20;md5=0403c7dea01a2b8232
 
 inherit module
 
-MACHINE_KERNEL_PR_append = "a"
+MACHINE_KERNEL_PR_append = "b"
 PR = "${MACHINE_KERNEL_PR}"
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
@@ -13,6 +13,8 @@ COMPATIBLE_MACHINE = "j7-evm"
 
 DEPENDS = "virtual/kernel"
 
+PROVIDES = "virtual/gpudriver"
+
 BRANCH = "linux/thud/k4.19/${PV}"
 
 SRC_URI = "git://git.ti.com/graphics/ti-img-rogue-driver.git;branch=${BRANCH}"
diff --git a/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb b/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb
index 2b1e1ee..8338ed7 100644
--- a/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb
+++ b/recipes-bsp/powervr-drivers/ti-sgx-ddk-km_1.17.4948957.bb
@@ -7,18 +7,14 @@ inherit module
 
 COMPATIBLE_MACHINE = "ti33x|ti43x|omap-a15|k3"
 
-MACHINE_KERNEL_PR_append = "q"
+MACHINE_KERNEL_PR_append = "r"
 PR = "${MACHINE_KERNEL_PR}"
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 DEPENDS = "virtual/kernel"
 
-PROVIDES = "omapdrm-pvr"
-
-RPROVIDES_${PN} = "omapdrm-pvr"
-RREPLACES_${PN} = "omapdrm-pvr"
-RCONFLICTS_${PN} = "omapdrm-pvr"
+PROVIDES = "virtual/gpudriver"
 
 BRANCH = "ti-img-sgx/${PV}/k4.19"
 
-- 
1.9.1



^ permalink raw reply related

* Re: [PATCH] media: mt9m111: fix fw-node refactoring
From: Sakari Ailus @ 2019-06-20 12:35 UTC (permalink / raw)
  To: Robert Jarzmik
  Cc: Mauro Carvalho Chehab, Enrico Scholz, linux-media, linux-kernel
In-Reply-To: <20190620101717.7h2hczachuk2rjr6@valkosipuli.retiisi.org.uk>

On Thu, Jun 20, 2019 at 01:17:17PM +0300, Sakari Ailus wrote:
> diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
> index bd3a51c3b081..9761a6105407 100644
> --- a/drivers/media/i2c/mt9m111.c
> +++ b/drivers/media/i2c/mt9m111.c
> @@ -1263,9 +1263,11 @@ static int mt9m111_probe(struct i2c_client *client,
>  	if (!mt9m111)
>  		return -ENOMEM;
>  
> -	ret = mt9m111_probe_fw(client, mt9m111);
> -	if (ret)
> -		return ret;
> +	if (dev_fwnode(client->dev)) {

&client->dev

> +		ret = mt9m111_probe_fw(client, mt9m111);
> +		if (ret)
> +			return ret;
> +	}
>  
>  	mt9m111->clk = v4l2_clk_get(&client->dev, "mclk");
>  	if (IS_ERR(mt9m111->clk))

-- 
Sakari Ailus

^ permalink raw reply

* [PATCH net] ipv6: fix neighbour resolution with raw socket
From: Nicolas Dichtel @ 2019-06-20 12:34 UTC (permalink / raw)
  To: davem; +Cc: netdev, Nicolas Dichtel

The scenario is the following: the user uses a raw socket to send an ipv6
packet, destinated to a not-connected network, and specify a connected nh.
Here is the corresponding python script to reproduce this scenario:

 import socket
 IPPROTO_RAW = 255
 send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
 # scapy
 # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
 # str(p)
 req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
 send_s.sendto(req, ('fd00:175::2', 0, 0, 0))

fd00:175::/64 is a connected route and fd00:200::fa is not a connected
host.

With this scenario, the kernel starts by sending a NS to resolve
fd00:175::2. When it receives the NA, it flushes its queue and try to send
the initial packet. But instead of sending it, it sends another NS to
resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
the user sends again the packet, it now uses the right nh (fd00:175::2).

The problem is that ip6_dst_lookup_neigh() uses the rt6i_gateway, which is
:: because the associated route is a connected route, thus it uses the dst
addr of the packet. Let's use rt6_nexthop() to choose the right nh.

Note that rt and in6addr_any are const in ip6_dst_lookup_neigh(), thus
let's constify rt6_nexthop() to avoid ugly cast.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 include/net/ip6_route.h | 4 ++--
 net/ipv6/ip6_output.c   | 2 +-
 net/ipv6/route.c        | 3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 4790beaa86e0..ee7405e759ba 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -262,8 +262,8 @@ static inline bool ip6_sk_ignore_df(const struct sock *sk)
 	       inet6_sk(sk)->pmtudisc == IPV6_PMTUDISC_OMIT;
 }
 
-static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt,
-					   struct in6_addr *daddr)
+static inline const struct in6_addr *rt6_nexthop(const struct rt6_info *rt,
+						 const struct in6_addr *daddr)
 {
 	if (rt->rt6i_flags & RTF_GATEWAY)
 		return &rt->rt6i_gateway;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 834475717110..21efcd02f337 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -59,8 +59,8 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
 {
 	struct dst_entry *dst = skb_dst(skb);
 	struct net_device *dev = dst->dev;
+	const struct in6_addr *nexthop;
 	struct neighbour *neigh;
-	struct in6_addr *nexthop;
 	int ret;
 
 	if (ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr)) {
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 11ad62effd56..b6449bc03f11 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -218,7 +218,8 @@ static struct neighbour *ip6_dst_neigh_lookup(const struct dst_entry *dst,
 {
 	const struct rt6_info *rt = container_of(dst, struct rt6_info, dst);
 
-	return ip6_neigh_lookup(&rt->rt6i_gateway, dst->dev, skb, daddr);
+	return ip6_neigh_lookup(rt6_nexthop(rt, &in6addr_any),
+				dst->dev, skb, daddr);
 }
 
 static void ip6_confirm_neigh(const struct dst_entry *dst, const void *daddr)
-- 
2.21.0


^ permalink raw reply related

* Re: [PATCH v2 0/3] ceph: don't NULL terminate virtual xattr values
From: Andy Shevchenko @ 2019-06-20 12:34 UTC (permalink / raw)
  To: Jeff Layton
  Cc: linux-kernel, ceph-devel, idryomov, zyan, sage, agruenba, joe,
	pmladek, rostedt, geert+renesas
In-Reply-To: <7c12abe8a7e6cd3cfe9129a1e74d9c788ff2f1a9.camel@kernel.org>

On Thu, Jun 20, 2019 at 07:41:06AM -0400, Jeff Layton wrote:
> On Thu, 2019-06-20 at 13:24 +0300, Andy Shevchenko wrote:
> > On Wed, Jun 19, 2019 at 12:45:25PM -0400, Jeff Layton wrote:

> > So, then don't use snprintf() for this, simple memcpy() designed for that kind
> > of things.
> > 
> 
> memcpy from what? For many of these xattrs, we need to format integer
> data into strings. I could roll my own routine to do this formatting,
> but that's sort of what sprintf and its variants are for and I'd rather
> not reimplement all of it from scratch.

So, use bigger temporary buffer and decide what to do with data if it doesn't
fit the destination one.

String without nul is not considered as a string, thus, memcpy() the data.

> > > This patch makes ceph's virtual xattrs not include NULL termination
> > > when formatting their values. In order to handle this, a new
> > > snprintf_noterm function is added, and ceph is changed over to use
> > > this to populate the xattr value buffer.
> > 
> > In terms of vsnprintf(), and actually compiler point of view, it's not a string
> > anymore, it's a text-based data.
> > 
> > Personally, I don't see an advantage of a deep intrusion into vsnprintf().
> > The wrapper can be made to achieve this w/o touching the generic code. Thus,
> > you can quickly and cleanly fix the issue, while discussing this with wider
> > audience.
> > 
> 
> Sorry, if I'm being dense but I'm not sure I follow here.
> 
> Are you suggesting I should just copy/paste most of vsnprintf into a new
> function that just leaves off the termination at the end, and leave the
> original alone?

Yes. The data you are expecting is not a string anymore from these functions
point of view. Even GCC nowadays complains on strncpy() when nul doesn't fit
the destination buffer.

> That seems like a bit of a waste, but if that's the
> consensus then ok.

My personal view is not a consensus, let's wait for more opinions.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* Re: [igt-dev] [PATCH i-g-t 3/3] runner/settings: Be consistent with empty blacklist
From: Petri Latvala @ 2019-06-20 12:34 UTC (permalink / raw)
  To: Arkadiusz Hiler; +Cc: igt-dev
In-Reply-To: <20190620122902.20761-3-arkadiusz.hiler@intel.com>

On Thu, Jun 20, 2019 at 03:29:02PM +0300, Arkadiusz Hiler wrote:
> If provided an empty blacklist let's fail instead of returning a value
> of uninitialized variable.
> 
> Cc: Oleg Vasilev <oleg.vasilev@intel.com>
> Cc: Petri Latvala <petri.latvala@intel.com>
> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>


Reviewed-by: Petri Latvala <petri.latvala@intel.com>


> ---
>  runner/settings.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/runner/settings.c b/runner/settings.c
> index 9920e1a6..8b39c063 100644
> --- a/runner/settings.c
> +++ b/runner/settings.c
> @@ -227,7 +227,7 @@ static bool parse_blacklist(struct regex_list *exclude_regexes,
>  	FILE *f;
>  	char *line = NULL;
>  	size_t line_len = 0;
> -	bool status;
> +	bool status = false;
>  
>  	if ((f = fopen(blacklist_filename, "r")) == NULL) {
>  		fprintf(stderr, "Cannot open blacklist file %s\n", blacklist_filename);
> -- 
> 2.21.0
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply

* [PATCH] Revert "drm/amd/display: Enable fast plane updates when state->allow_modeset = true"
From: Nicholas Kazlauskas @ 2019-06-20 12:34 UTC (permalink / raw)
  To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: David Francis, Harry Wentland, Nicholas Kazlauskas

This reverts commit ebc8c6f18322ad54275997a888ca1731d74b711f.

There are still missing corner cases with cursor interaction and these
fast plane updates on Picasso and Raven2 leading to endless PSTATE
warnings for typical desktop usage depending on the userspace.

This change should be reverted until these issues have been resolved.

Cc: David Francis <david.francis@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 33dcd4187157..d6acbcfa570c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6471,6 +6471,14 @@ static bool should_reset_plane(struct drm_atomic_state *state,
 	struct drm_crtc_state *new_crtc_state;
 	int i;
 
+	/*
+	 * TODO: Remove this hack once the checks below are sufficient
+	 * enough to determine when we need to reset all the planes on
+	 * the stream.
+	 */
+	if (state->allow_modeset)
+		return true;
+
 	/* Exit early if we know that we're adding or removing the plane. */
 	if (old_plane_state->crtc != new_plane_state->crtc)
 		return true;
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related

* Re: [igt-dev] [PATCH i-g-t 2/3] runner/resultgen: Don't pass NULL to str*() functions
From: Petri Latvala @ 2019-06-20 12:33 UTC (permalink / raw)
  To: Arkadiusz Hiler; +Cc: igt-dev
In-Reply-To: <20190620122902.20761-2-arkadiusz.hiler@intel.com>

On Thu, Jun 20, 2019 at 03:29:01PM +0300, Arkadiusz Hiler wrote:
> If we don't get values from the JSON strlen() and strcmp() on them would
> dereference NULL pointer.
> 
> Cc: Petri Latvala <petri.latvala@intel.com>
> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>


Reviewed-by: Petri Latvala <petri.latvala@intel.com>


> ---
>  runner/resultgen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/runner/resultgen.c b/runner/resultgen.c
> index 7b4cd519..58b95220 100644
> --- a/runner/resultgen.c
> +++ b/runner/resultgen.c
> @@ -866,7 +866,7 @@ static void fill_from_journal(int fd,
>  
>  static void override_result_single(struct json_object *obj)
>  {
> -	const char *errtext = NULL, *result = NULL;
> +	const char *errtext = "", *result = "";
>  	struct json_object *textobj;
>  	bool dmesgwarns = false;
>  
> -- 
> 2.21.0
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply


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.