* Re: [PATCH v2] random: avoid superfluous call to RDRAND in CRNG extraction
From: Ard Biesheuvel @ 2022-01-05 15:28 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Linux Kernel Mailing List, Theodore Y. Ts'o,
Linux Crypto Mailing List
In-Reply-To: <20211231114903.60882-1-Jason@zx2c4.com>
On Fri, 31 Dec 2021 at 12:50, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> RDRAND is not fast. RDRAND is actually quite slow. We've known this for
> a while, which is why functions like get_random_u{32,64} were converted
> to use batching of our ChaCha-based CRNG instead.
>
> Yet CRNG extraction still includes a call to RDRAND, in the hot path of
> every call to get_random_bytes(), /dev/urandom, and getrandom(2).
>
> This call to RDRAND here seems quite superfluous. CRNG is already
> extracting things based on a 256-bit key, based on good entropy, which
> is then reseeded periodically, updated, backtrack-mutated, and so
> forth. The CRNG extraction construction is something that we're already
> relying on to be secure and solid. If it's not, that's a serious
> problem, and it's unlikely that mixing in a measly 32 bits from RDRAND
> is going to alleviate things.
>
> And in the case where the CRNG doesn't have enough entropy yet, we're
> already initializing the ChaCha key row with RDRAND in
> crng_init_try_arch_early().
>
> Removing the call to RDRAND improves performance on an i7-11850H by
> 370%. In other words, the vast majority of the work done by
> extract_crng() prior to this commit was devoted to fetching 32 bits of
> RDRAND.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> drivers/char/random.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 4de0feb69781..17ec60948795 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1023,7 +1023,7 @@ static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
> static void _extract_crng(struct crng_state *crng,
> __u8 out[CHACHA_BLOCK_SIZE])
> {
> - unsigned long v, flags, init_time;
> + unsigned long flags, init_time;
>
> if (crng_ready()) {
> init_time = READ_ONCE(crng->init_time);
> @@ -1033,8 +1033,6 @@ static void _extract_crng(struct crng_state *crng,
> &input_pool : NULL);
> }
> spin_lock_irqsave(&crng->lock, flags);
> - if (arch_get_random_long(&v))
> - crng->state[14] ^= v;
> chacha20_block(&crng->state[0], out);
> if (crng->state[12] == 0)
> crng->state[13]++;
Given that arch_get_random_long() may be backed by other things than
special instructions on some architectures/platforms, avoiding it if
we can on any path that may be a hot path is good, so
Acked-by: Ard Biesheuvel <ardb@kernel.org>
^ permalink raw reply
* Western Digital My Cloud Mirror (Ex) MTD devices not detected on newer kernels.
From: info @ 2022-01-05 15:27 UTC (permalink / raw)
To: linux-mtd
Hi,
I'd like to upgrade the kernel of my Western Digital My Cloud Mirror
(same as My Cloud Ex, Armada-370 SoC). My /dev/mtd* devices are not
showing on any kernel 4.16.1 or newer.
I noticed someone else had a very similar if not the same issue:
https://yhbt.net/lore/all/CAK+FTGhwM02y_eg6cE=GNcOH8G8eQjia0PD+JVrR=eSedQxWAA@mail.gmail.com/
. Unfortunately I don't know how to hook in to this conversation and if
I should or not.
As far as my understanding goes, at some point in time (4.16.1)
CONFIG_MTD_NAND_PXA3xx was dropped in favor of CONFIG_MTD_NAND_MARVELL .
But for some reason it does not work on my board. I use the same DTS
file for both builds btw.
Basically, if I compile a 4.14.260 kernel with at least this set:
CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_PXA3xx=y
I get:
wannes@mcm:~$ cat /proc/mtd
dev: size erasesize name
mtd0: 10000000 00020000 "pxa3xx_nand-0"
mtd1: 00500000 00020000 "u-Boot"
mtd2: 00500000 00020000 "uImage"
mtd3: 00500000 00020000 "ramdisk"
mtd4: 0c900000 00020000 "image.cfs"
mtd5: 00f00000 00020000 "rescue firmware"
mtd6: 01400000 00020000 "config"
mtd7: 00500000 00020000 "reserve"
wannes@mcm:~$ uname -r
4.14.260
wannes@mcm:~$
When I compile a newer kernel (5.16.rc8 for this example), I changed the
config to this:
wannes@mcm:~/src/linux-stable$ grep NAND .config | grep -v not\ set
CONFIG_MTD_NAND_CORE=y
CONFIG_MTD_RAW_NAND=y
CONFIG_MTD_NAND_ORION=y
CONFIG_MTD_NAND_MARVELL=y
CONFIG_MTD_NAND_BRCMNAND=y
CONFIG_MTD_NAND_PLATFORM=y
CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND_ECC_SW_HAMMING=y
CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC=y
CONFIG_MTD_NAND_ECC_SW_BCH=y
wannes@mcm:~/src/linux-stable$ cat /proc/mtd
dev: size erasesize name
wannes@mcm:~/src/linux-stable$ dmesg | grep mtd
mtdoops: mtd device (mtddev=name/number) must be supplied
wannes@mcm:~/src/linux-stable$
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add entry for QEMU Guest Agent Windows components
From: Marc-André Lureau @ 2022-01-05 15:23 UTC (permalink / raw)
To: Kostiantyn Kostiuk
Cc: Michael Roth, Paolo Bonzini, Daniel P . Berrange, qemu-devel,
Philippe Mathieu-Daudé
In-Reply-To: <20220105095055.44475-1-kkostiuk@redhat.com>
On Wed, Jan 5, 2022 at 1:51 PM Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
> Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f871d759fd..1f255ec874 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2729,6 +2729,14 @@ F: scripts/qemu-guest-agent/
> F: tests/unit/test-qga.c
> T: git https://github.com/mdroth/qemu.git qga
>
> +QEMU Guest Agent Win32
> +M: Konstantin Kostiuk <kkostiuk@redhat.com>
> +S: Maintained
> +F: qga/*win32*
> +F: qga/vss-win32/
> +F: qga/installer/
> +T: git https://github.com/kostyanf14/qemu.git qga-win32
> +
> QOM
> M: Paolo Bonzini <pbonzini@redhat.com>
> R: Daniel P. Berrange <berrange@redhat.com>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 3/4] drm/i915/ttm: ensure we unmap when purging
From: Thomas Hellström @ 2022-01-05 15:28 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
In-Reply-To: <20220105145835.142950-3-matthew.auld@intel.com>
On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
> Purging can happen during swapping out, or directly invoked with the
> madvise ioctl. In such cases this doesn't involve a ttm move, which
> skips umapping the object.
>
> Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 8d61d4538a64..f148e7e48f86 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -399,6 +399,8 @@ int i915_ttm_purge(struct drm_i915_gem_object
> *obj)
> if (obj->mm.madv == __I915_MADV_PURGED)
> return 0;
>
> + ttm_bo_unmap_virtual(bo);
> +
> ret = ttm_bo_validate(bo, &place, &ctx);
> if (ret)
> return ret;
The swap notifier and the move code both call i915_ttm_move_notify() to
achieve this before calling i915_ttm_purge. This ensures both cpu- and
gpu ptes are torn down, and also when we extend to dynamic dma-buf
exporting, makes sure dma-buf importers unbind.
So I suggest we make a i915_ttm_truncate wrapper function that calls
i915_ttm_move_notify() and then ttm_bo_purge(), and use that as the
truncate callback as well as from those places we call i915_ttm_purge
without a prior call to i915_ttm_move_notify(), which seems to be the
ones you've identified in patch 3 and 4,
/Thomas
^ permalink raw reply
* Re: [PATCH 3/4] drm/i915/ttm: ensure we unmap when purging
From: Thomas Hellström @ 2022-01-05 15:28 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
In-Reply-To: <20220105145835.142950-3-matthew.auld@intel.com>
On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
> Purging can happen during swapping out, or directly invoked with the
> madvise ioctl. In such cases this doesn't involve a ttm move, which
> skips umapping the object.
>
> Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 8d61d4538a64..f148e7e48f86 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -399,6 +399,8 @@ int i915_ttm_purge(struct drm_i915_gem_object
> *obj)
> if (obj->mm.madv == __I915_MADV_PURGED)
> return 0;
>
> + ttm_bo_unmap_virtual(bo);
> +
> ret = ttm_bo_validate(bo, &place, &ctx);
> if (ret)
> return ret;
The swap notifier and the move code both call i915_ttm_move_notify() to
achieve this before calling i915_ttm_purge. This ensures both cpu- and
gpu ptes are torn down, and also when we extend to dynamic dma-buf
exporting, makes sure dma-buf importers unbind.
So I suggest we make a i915_ttm_truncate wrapper function that calls
i915_ttm_move_notify() and then ttm_bo_purge(), and use that as the
truncate callback as well as from those places we call i915_ttm_purge
without a prior call to i915_ttm_move_notify(), which seems to be the
ones you've identified in patch 3 and 4,
/Thomas
^ permalink raw reply
* Re: [LTP] [PATCH 1/1] doc/maintainer: Add policy for new functionality
From: Cyril Hrubis @ 2022-01-05 15:29 UTC (permalink / raw)
To: Richard Palethorpe; +Cc: pvorel, ltp@lists.linux.it
In-Reply-To: <87lf0ffw1y.fsf@suse.de>
Hi!
> Yes. Although we could add "next" and "rc" flags to tst_test (or
> similar). Then require an environment variable to be set (or check the
> kernel version) otherwise the test will return TCONF.
>
> For LTP releases we just need to check if the flags are still needed or
> if the feature has been merged. The metadata parser can generate a list
> of tests to check.
>
> This seems like quite little work to me. In fact we don't even have to
> implement it until someone wants it. We can just add it to the policy.
I was thinking of this and if we really want this feature it would make
sense to add "remove_before_use" flag to the test structure what would
render the test resultless. Ideally it would include the kernel version
the functionality is going to be included into, then we can
automatically check in the CI the test metadata against latest release
kernel version and either remove the flag or bump it in case it didn't
get in.
Maybe just .remove_after_release = "5.9"
@Ritchie feel free to go ahead if you want to implement and maintain
something like this.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply
* [linux-next:master 7722/10864] drivers/net/ethernet/intel/iavf/iavf_main.c:1891:6-8: WARNING: possible condition with no effect (if == else)
From: kernel test robot @ 2022-01-05 15:27 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 8243 bytes --]
CC: kbuild-all(a)lists.01.org
CC: Linux Memory Management List <linux-mm@kvack.org>
TO: Brett Creeley <brett.creeley@intel.com>
CC: Tony Nguyen <anthony.l.nguyen@intel.com>
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 7a769a3922d81cfc74ab4d90a9cc69485f260976
commit: 8afadd1cd8ba1df757011eb58c471eca0ac81872 [7722/10864] iavf: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 offload enable/disable
:::::: branch date: 7 hours ago
:::::: commit date: 3 weeks ago
config: s390-randconfig-c024-20220105 (https://download.01.org/0day-ci/archive/20220105/202201052357.4Vvbm3Tc-lkp(a)intel.com/config)
compiler: s390-linux-gcc (GCC) 11.2.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
cocci warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/intel/iavf/iavf_main.c:1891:6-8: WARNING: possible condition with no effect (if == else)
vim +1891 drivers/net/ethernet/intel/iavf/iavf_main.c
b476b0030e612e Jakub Pawlak 2019-05-14 1858
8afadd1cd8ba1d Brett Creeley 2021-11-29 1859 /**
8afadd1cd8ba1d Brett Creeley 2021-11-29 1860 * iavf_set_vlan_offload_features - set VLAN offload configuration
8afadd1cd8ba1d Brett Creeley 2021-11-29 1861 * @adapter: board private structure
8afadd1cd8ba1d Brett Creeley 2021-11-29 1862 * @prev_features: previous features used for comparison
8afadd1cd8ba1d Brett Creeley 2021-11-29 1863 * @features: updated features used for configuration
8afadd1cd8ba1d Brett Creeley 2021-11-29 1864 *
8afadd1cd8ba1d Brett Creeley 2021-11-29 1865 * Set the aq_required bit(s) based on the requested features passed in to
8afadd1cd8ba1d Brett Creeley 2021-11-29 1866 * configure VLAN stripping and/or VLAN insertion if supported. Also, schedule
8afadd1cd8ba1d Brett Creeley 2021-11-29 1867 * the watchdog if any changes are requested to expedite the request via
8afadd1cd8ba1d Brett Creeley 2021-11-29 1868 * virtchnl.
8afadd1cd8ba1d Brett Creeley 2021-11-29 1869 **/
8afadd1cd8ba1d Brett Creeley 2021-11-29 1870 void
8afadd1cd8ba1d Brett Creeley 2021-11-29 1871 iavf_set_vlan_offload_features(struct iavf_adapter *adapter,
8afadd1cd8ba1d Brett Creeley 2021-11-29 1872 netdev_features_t prev_features,
8afadd1cd8ba1d Brett Creeley 2021-11-29 1873 netdev_features_t features)
8afadd1cd8ba1d Brett Creeley 2021-11-29 1874 {
8afadd1cd8ba1d Brett Creeley 2021-11-29 1875 bool enable_stripping = true, enable_insertion = true;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1876 u16 vlan_ethertype = 0;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1877 u64 aq_required = 0;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1878
8afadd1cd8ba1d Brett Creeley 2021-11-29 1879 /* keep cases separate because one ethertype for offloads can be
8afadd1cd8ba1d Brett Creeley 2021-11-29 1880 * disabled at the same time as another is disabled, so check for an
8afadd1cd8ba1d Brett Creeley 2021-11-29 1881 * enabled ethertype first, then check for disabled. Default to
8afadd1cd8ba1d Brett Creeley 2021-11-29 1882 * ETH_P_8021Q so an ethertype is specified if disabling insertion and
8afadd1cd8ba1d Brett Creeley 2021-11-29 1883 * stripping.
8afadd1cd8ba1d Brett Creeley 2021-11-29 1884 */
8afadd1cd8ba1d Brett Creeley 2021-11-29 1885 if (features & (NETIF_F_HW_VLAN_STAG_RX | NETIF_F_HW_VLAN_STAG_TX))
8afadd1cd8ba1d Brett Creeley 2021-11-29 1886 vlan_ethertype = ETH_P_8021AD;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1887 else if (features & (NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_TX))
8afadd1cd8ba1d Brett Creeley 2021-11-29 1888 vlan_ethertype = ETH_P_8021Q;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1889 else if (prev_features & (NETIF_F_HW_VLAN_STAG_RX | NETIF_F_HW_VLAN_STAG_TX))
8afadd1cd8ba1d Brett Creeley 2021-11-29 1890 vlan_ethertype = ETH_P_8021AD;
8afadd1cd8ba1d Brett Creeley 2021-11-29 @1891 else if (prev_features & (NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_TX))
8afadd1cd8ba1d Brett Creeley 2021-11-29 1892 vlan_ethertype = ETH_P_8021Q;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1893 else
8afadd1cd8ba1d Brett Creeley 2021-11-29 1894 vlan_ethertype = ETH_P_8021Q;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1895
8afadd1cd8ba1d Brett Creeley 2021-11-29 1896 if (!(features & (NETIF_F_HW_VLAN_STAG_RX | NETIF_F_HW_VLAN_CTAG_RX)))
8afadd1cd8ba1d Brett Creeley 2021-11-29 1897 enable_stripping = false;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1898 if (!(features & (NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_CTAG_TX)))
8afadd1cd8ba1d Brett Creeley 2021-11-29 1899 enable_insertion = false;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1900
8afadd1cd8ba1d Brett Creeley 2021-11-29 1901 if (VLAN_ALLOWED(adapter)) {
8afadd1cd8ba1d Brett Creeley 2021-11-29 1902 /* VIRTCHNL_VF_OFFLOAD_VLAN only has support for toggling VLAN
8afadd1cd8ba1d Brett Creeley 2021-11-29 1903 * stripping via virtchnl. VLAN insertion can be toggled on the
8afadd1cd8ba1d Brett Creeley 2021-11-29 1904 * netdev, but it doesn't require a virtchnl message
8afadd1cd8ba1d Brett Creeley 2021-11-29 1905 */
8afadd1cd8ba1d Brett Creeley 2021-11-29 1906 if (enable_stripping)
8afadd1cd8ba1d Brett Creeley 2021-11-29 1907 aq_required |= IAVF_FLAG_AQ_ENABLE_VLAN_STRIPPING;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1908 else
8afadd1cd8ba1d Brett Creeley 2021-11-29 1909 aq_required |= IAVF_FLAG_AQ_DISABLE_VLAN_STRIPPING;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1910
8afadd1cd8ba1d Brett Creeley 2021-11-29 1911 } else if (VLAN_V2_ALLOWED(adapter)) {
8afadd1cd8ba1d Brett Creeley 2021-11-29 1912 switch (vlan_ethertype) {
8afadd1cd8ba1d Brett Creeley 2021-11-29 1913 case ETH_P_8021Q:
8afadd1cd8ba1d Brett Creeley 2021-11-29 1914 if (enable_stripping)
8afadd1cd8ba1d Brett Creeley 2021-11-29 1915 aq_required |= IAVF_FLAG_AQ_ENABLE_CTAG_VLAN_STRIPPING;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1916 else
8afadd1cd8ba1d Brett Creeley 2021-11-29 1917 aq_required |= IAVF_FLAG_AQ_DISABLE_CTAG_VLAN_STRIPPING;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1918
8afadd1cd8ba1d Brett Creeley 2021-11-29 1919 if (enable_insertion)
8afadd1cd8ba1d Brett Creeley 2021-11-29 1920 aq_required |= IAVF_FLAG_AQ_ENABLE_CTAG_VLAN_INSERTION;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1921 else
8afadd1cd8ba1d Brett Creeley 2021-11-29 1922 aq_required |= IAVF_FLAG_AQ_DISABLE_CTAG_VLAN_INSERTION;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1923 break;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1924 case ETH_P_8021AD:
8afadd1cd8ba1d Brett Creeley 2021-11-29 1925 if (enable_stripping)
8afadd1cd8ba1d Brett Creeley 2021-11-29 1926 aq_required |= IAVF_FLAG_AQ_ENABLE_STAG_VLAN_STRIPPING;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1927 else
8afadd1cd8ba1d Brett Creeley 2021-11-29 1928 aq_required |= IAVF_FLAG_AQ_DISABLE_STAG_VLAN_STRIPPING;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1929
8afadd1cd8ba1d Brett Creeley 2021-11-29 1930 if (enable_insertion)
8afadd1cd8ba1d Brett Creeley 2021-11-29 1931 aq_required |= IAVF_FLAG_AQ_ENABLE_STAG_VLAN_INSERTION;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1932 else
8afadd1cd8ba1d Brett Creeley 2021-11-29 1933 aq_required |= IAVF_FLAG_AQ_DISABLE_STAG_VLAN_INSERTION;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1934 break;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1935 }
8afadd1cd8ba1d Brett Creeley 2021-11-29 1936 }
8afadd1cd8ba1d Brett Creeley 2021-11-29 1937
8afadd1cd8ba1d Brett Creeley 2021-11-29 1938 if (aq_required) {
8afadd1cd8ba1d Brett Creeley 2021-11-29 1939 adapter->aq_required |= aq_required;
8afadd1cd8ba1d Brett Creeley 2021-11-29 1940 mod_delayed_work(iavf_wq, &adapter->watchdog_task, 0);
8afadd1cd8ba1d Brett Creeley 2021-11-29 1941 }
8afadd1cd8ba1d Brett Creeley 2021-11-29 1942 }
8afadd1cd8ba1d Brett Creeley 2021-11-29 1943
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH v3 0/5] aio: fix use-after-free and missing wakeups
From: Eric Biggers @ 2022-01-05 15:26 UTC (permalink / raw)
To: Jens Axboe
Cc: Linus Torvalds, Alexander Viro, Benjamin LaHaise, linux-aio,
linux-fsdevel, Linux Kernel Mailing List, Ramji Jiyani,
Christoph Hellwig, Oleg Nesterov, Martijn Coenen, stable
In-Reply-To: <4a472e72-d527-db79-d46e-efa9d4cad5bb@kernel.dk>
On Thu, Dec 09, 2021 at 02:46:45PM -0700, Jens Axboe wrote:
> On 12/9/21 11:00 AM, Linus Torvalds wrote:
> > On Wed, Dec 8, 2021 at 5:06 PM Eric Biggers <ebiggers@kernel.org> wrote:
> >>
> >> Careful review is appreciated; the aio poll code is very hard to work
> >> with, and it doesn't appear to have many tests. I've verified that it
> >> passes the libaio test suite, which provides some coverage of poll.
> >>
> >> Note, it looks like io_uring has the same bugs as aio poll. I haven't
> >> tried to fix io_uring.
> >
> > I'm hoping Jens is looking at the io_ring case, but I'm also assuming
> > that I'll just get a pull request for this at some point.
>
> Yes, when I saw this original posting I did discuss it with Pavel as
> well, and we agree that the same issue exists there. Which isn't too
> surprising, as that's where the io_uring poll code from originally.
>
Jens, any update on fixing the io_uring version of the bug? Note, syzbot has
managed to use io_uring poll to hit the WARN_ON_ONCE() that I added in
__wake_up_pollfree(), which proves that it is broken.
- Eric
^ permalink raw reply
* Re: [PATCH dt + pci 1/2] dt-bindings: Add 'slot-power-limit-milliwatt' PCIe port property
From: Rob Herring @ 2022-01-05 15:26 UTC (permalink / raw)
To: Pali Rohár; +Cc: Marek Behún, devicetree, PCI, Bjorn Helgaas
In-Reply-To: <20220105151410.wm5ti6kbjmvm5dwf@pali>
On Wed, Jan 5, 2022 at 9:14 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Wednesday 05 January 2022 08:27:21 Rob Herring wrote:
> > On Wed, Jan 5, 2022 at 8:14 AM Marek Behún <kabel@kernel.org> wrote:
> > >
> > > On Fri, 12 Nov 2021 09:25:20 -0600
> > > Rob Herring <robh@kernel.org> wrote:
> > >
> > > > On Sun, Oct 31, 2021 at 04:07:05PM +0100, Marek Behún wrote:
> > > > > From: Pali Rohár <pali@kernel.org>
> > > > >
> > > > > This property specifies slot power limit in mW unit. It is a form-factor
> > > > > and board specific value and must be initialized by hardware.
> > > > >
> > > > > Some PCIe controllers delegate this work to software to allow hardware
> > > > > flexibility and therefore this property basically specifies what should
> > > > > host bridge program into PCIe Slot Capabilities registers.
> > > > >
> > > > > The property needs to be specified in mW unit instead of the special format
> > > > > defined by Slot Capabilities (which encodes scaling factor or different
> > > > > unit). Host drivers should convert the value from mW to needed format.
> > > > >
> > > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > > Signed-off-by: Marek Behún <kabel@kernel.org>
> > > > > ---
> > > > > Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
> > > > > 1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> > > > > index 6a8f2874a24d..7296d599c5ac 100644
> > > > > --- a/Documentation/devicetree/bindings/pci/pci.txt
> > > > > +++ b/Documentation/devicetree/bindings/pci/pci.txt
> > > > > @@ -32,6 +32,12 @@ driver implementation may support the following properties:
> > > > > root port to downstream device and host bridge drivers can do programming
> > > > > which depends on CLKREQ signal existence. For example, programming root port
> > > > > not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
> > > > > +- slot-power-limit-miliwatt:
> > > >
> > > > Typo.
> > > >
> > > > But we shouldn't be adding to pci.txt. This needs to go in the
> > > > schema[1]. Patch to devicetree-spec list or GH PR is fine.
> > >
> > > Hello Rob,
> > >
> > > Pali's PR draft https://github.com/devicetree-org/dt-schema/pull/64
> > > looks like it's going to take some time to work out.
> > >
> > > In the meantime, is it possible to somehow get the
> > > slot-power-limit-milliwatt property merged into pci.txt so that we can start
> > > putting it into existing device-trees?
> > >
> > > Or would it break dt_bindings_check if it isn't put into dt-schema's
> > > pci-bus.yaml?
> > >
> > > Or should we simply put it into current version of pci-bus.yaml and
> > > work out the split proposed by Pali's PR afterwards?
> >
> > In the existing pci-bus.yaml is fine.
>
> Hello Rob! I do not think that it is possible to add this property
> correctly in to the existing pci-bus.yaml file. As this file is not
> prepared for slot properties. And I guess that adding new property at
> "random" place is against the idea of schema validation (that validation
> procedure accepts only valid DTS files).
The only issue I see is the property would be allowed in host bridge
nodes rather than only root port or PCIe-PCIe bridge nodes because the
current file is a mixture of all of those. I think a note that the
property is not valid in host bridge nodes would be sufficient. It's
still better than documenting in pci.txt.
Rob
^ permalink raw reply
* Re: [PATCH] crypto: qat - Unsigned comparison with less than zero
From: Giovanni Cabiddu @ 2022-01-05 15:26 UTC (permalink / raw)
To: Jiapeng Chong
Cc: herbert, davem, qat-linux, linux-crypto, linux-kernel,
Abaci Robot
In-Reply-To: <20220105152005.43305-1-jiapeng.chong@linux.alibaba.com>
On Wed, Jan 05, 2022 at 11:20:05PM +0800, Jiapeng Chong wrote:
> Fix coccicheck warning:
>
> ./drivers/crypto/qat/qat_4xxx/adf_4xxx_hw_data.c:67:5-8: WARNING:
> Unsigned expression compared with zero: ret < 0.
>
> Reported-by: Abaci Robot <abaci@linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
There is already a patch under review that fixes this:
https://marc.info/?l=linux-crypto-vger&m=164138836020725&w=2
Thanks,
--
Giovanni
^ permalink raw reply
* [PATCH nf] netfilter: nft_payload: do not update layer 4 checksum when mangling fragments
From: Pablo Neira Ayuso @ 2022-01-05 15:26 UTC (permalink / raw)
To: netfilter-devel
IP fragments do not come with the transport header, hence skip bogus
layer 4 checksum updates.
Reported-by: Steffen Weinreich <steve@weinreich.org>
Tested-by: Steffen Weinreich <steve@weinreich.org>
Fixes: 1814096980bb ("netfilter: nft_payload: layer 4 checksum adjustment for pseudoheader fields")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_payload.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/netfilter/nft_payload.c b/net/netfilter/nft_payload.c
index bd689938a2e0..58e96a0fe0b4 100644
--- a/net/netfilter/nft_payload.c
+++ b/net/netfilter/nft_payload.c
@@ -546,6 +546,9 @@ static int nft_payload_l4csum_offset(const struct nft_pktinfo *pkt,
struct sk_buff *skb,
unsigned int *l4csum_offset)
{
+ if (pkt->fragoff)
+ return -1;
+
switch (pkt->tprot) {
case IPPROTO_TCP:
*l4csum_offset = offsetof(struct tcphdr, check);
--
2.30.2
^ permalink raw reply related
* [PATCH net-next] testptp: set pin function before other requests
From: Miroslav Lichvar @ 2022-01-05 15:25 UTC (permalink / raw)
To: netdev; +Cc: Miroslav Lichvar, Richard Cochran, Vladimir Oltean
When the -L option of the testptp utility is specified with other
options (e.g. -p to enable PPS output), the user probably wants to
apply it to the pin configured by the -L option.
Reorder the code to set the pin function before other function requests
to avoid confusing users.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Vladimir Oltean <olteanv@gmail.com>
---
tools/testing/selftests/ptp/testptp.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/ptp/testptp.c b/tools/testing/selftests/ptp/testptp.c
index f7911aaeb007..c0f6a062364d 100644
--- a/tools/testing/selftests/ptp/testptp.c
+++ b/tools/testing/selftests/ptp/testptp.c
@@ -354,6 +354,18 @@ int main(int argc, char *argv[])
}
}
+ if (pin_index >= 0) {
+ memset(&desc, 0, sizeof(desc));
+ desc.index = pin_index;
+ desc.func = pin_func;
+ desc.chan = index;
+ if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) {
+ perror("PTP_PIN_SETFUNC");
+ } else {
+ puts("set pin function okay");
+ }
+ }
+
if (extts) {
memset(&extts_request, 0, sizeof(extts_request));
extts_request.index = index;
@@ -444,18 +456,6 @@ int main(int argc, char *argv[])
}
}
- if (pin_index >= 0) {
- memset(&desc, 0, sizeof(desc));
- desc.index = pin_index;
- desc.func = pin_func;
- desc.chan = index;
- if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) {
- perror("PTP_PIN_SETFUNC");
- } else {
- puts("set pin function okay");
- }
- }
-
if (pps != -1) {
int enable = pps ? 1 : 0;
if (ioctl(fd, PTP_ENABLE_PPS, enable)) {
--
2.33.1
^ permalink raw reply related
* Re: [f2fs-dev] [PATCH] f2fs: quota: fix potential deadlock
From: Chao Yu @ 2022-01-05 15:25 UTC (permalink / raw)
To: Greg KH; +Cc: jaegeuk, Yi Zhuang, stable, linux-f2fs-devel
In-Reply-To: <YdWy1I7pFrnV4NTa@kroah.com>
On 2022/1/5 23:01, Greg KH wrote:
> On Tue, Jan 04, 2022 at 11:48:25PM +0800, Chao Yu wrote:
>> On 2022/1/4 23:17, Greg KH wrote:
>>> On Tue, Jan 04, 2022 at 11:05:36PM +0800, Chao Yu wrote:
>>>> On 2022/1/4 21:18, Greg KH wrote:
>>>>> On Tue, Jan 04, 2022 at 09:05:13PM +0800, Chao Yu wrote:
>>>>>> commit a5c0042200b28fff3bde6fa128ddeaef97990f8d upstream.
>>>>>>
>>>>>> As Yi Zhuang reported in bugzilla:
>>>>>>
>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=214299
>>>>>>
>>>>>> There is potential deadlock during quota data flush as below:
>>>>>>
>>>>>> Thread A: Thread B:
>>>>>> f2fs_dquot_acquire
>>>>>> down_read(&sbi->quota_sem)
>>>>>> f2fs_write_checkpoint
>>>>>> block_operations
>>>>>> f2fs_look_all
>>>>>> down_write(&sbi->cp_rwsem)
>>>>>> f2fs_quota_write
>>>>>> f2fs_write_begin
>>>>>> __do_map_lock
>>>>>> f2fs_lock_op
>>>>>> down_read(&sbi->cp_rwsem)
>>>>>> __need_flush_qutoa
>>>>>> down_write(&sbi->quota_sem)
>>>>>>
>>>>>> This patch changes block_operations() to use trylock, if it fails,
>>>>>> it means there is potential quota data updater, in this condition,
>>>>>> let's flush quota data first and then trylock again to check dirty
>>>>>> status of quota data.
>>>>>>
>>>>>> The side effect is: in heavy race condition (e.g. multi quota data
>>>>>> upaters vs quota data flusher), it may decrease the probability of
>>>>>> synchronizing quota data successfully in checkpoint() due to limited
>>>>>> retry time of quota flush.
>>>>>>
>>>>>> Fixes: db6ec53b7e03 ("f2fs: add a rw_sem to cover quota flag changes")
>>>>>> Cc: stable@vger.kernel.org # v5.3+
>>>>>> Reported-by: Yi Zhuang <zhuangyi1@huawei.com>
>>>>>> Signed-off-by: Chao Yu <chao@kernel.org>
>>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>> ---
>>>>>> fs/f2fs/checkpoint.c | 3 ++-
>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>>>>> index 83e9bc0f91ff..7b0282724231 100644
>>>>>> --- a/fs/f2fs/checkpoint.c
>>>>>> +++ b/fs/f2fs/checkpoint.c
>>>>>> @@ -1162,7 +1162,8 @@ static bool __need_flush_quota(struct f2fs_sb_info *sbi)
>>>>>> if (!is_journalled_quota(sbi))
>>>>>> return false;
>>>>>> - down_write(&sbi->quota_sem);
>>>>>> + if (!down_write_trylock(&sbi->quota_sem))
>>>>>> + return true;
>>>>>> if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) {
>>>>>> ret = false;
>>>>>> } else if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) {
>>>>>> --
>>>>>> 2.32.0
>>>>>>
>>>>>
>>>>> What stable tree(s) is this for?
>>>>
>>>> Oh, please help to try applying to 5.4, 5.10, and 5.15 stable trees, thanks!
>>>
>>> This is already in the 5.15.6 kernel release, do you need it applied
>>> there again? :)
>>
>> Oops, no, so 5.4 and 5.10 is enough. ;)
>> We can skip 5.15 since this patch was merged in 5.15-rc1 at the first time.
>
> It was merged in 5.16-rc1, and then backported to 5.15.6. You might
> want to check your git scripts.
Oh, yes, you're right, it looks we merged patches with same title in both 5.15-rc1
and 5.16-rc1, that won't happen usually... so I positioning the wrong merge time
only based on patch title...
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=a5c0042200b28fff3bde6fa128ddeaef97990f8d
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=9de71ede81e6d1a111fdd868b2d78d459fa77f80
>
> Anyway, now queued up, thanks.
Thank you!
Thanks,
>
> greg k-h
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [PATCH] f2fs: quota: fix potential deadlock
From: Chao Yu @ 2022-01-05 15:25 UTC (permalink / raw)
To: Greg KH; +Cc: stable, jaegeuk, linux-f2fs-devel, Yi Zhuang
In-Reply-To: <YdWy1I7pFrnV4NTa@kroah.com>
On 2022/1/5 23:01, Greg KH wrote:
> On Tue, Jan 04, 2022 at 11:48:25PM +0800, Chao Yu wrote:
>> On 2022/1/4 23:17, Greg KH wrote:
>>> On Tue, Jan 04, 2022 at 11:05:36PM +0800, Chao Yu wrote:
>>>> On 2022/1/4 21:18, Greg KH wrote:
>>>>> On Tue, Jan 04, 2022 at 09:05:13PM +0800, Chao Yu wrote:
>>>>>> commit a5c0042200b28fff3bde6fa128ddeaef97990f8d upstream.
>>>>>>
>>>>>> As Yi Zhuang reported in bugzilla:
>>>>>>
>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=214299
>>>>>>
>>>>>> There is potential deadlock during quota data flush as below:
>>>>>>
>>>>>> Thread A: Thread B:
>>>>>> f2fs_dquot_acquire
>>>>>> down_read(&sbi->quota_sem)
>>>>>> f2fs_write_checkpoint
>>>>>> block_operations
>>>>>> f2fs_look_all
>>>>>> down_write(&sbi->cp_rwsem)
>>>>>> f2fs_quota_write
>>>>>> f2fs_write_begin
>>>>>> __do_map_lock
>>>>>> f2fs_lock_op
>>>>>> down_read(&sbi->cp_rwsem)
>>>>>> __need_flush_qutoa
>>>>>> down_write(&sbi->quota_sem)
>>>>>>
>>>>>> This patch changes block_operations() to use trylock, if it fails,
>>>>>> it means there is potential quota data updater, in this condition,
>>>>>> let's flush quota data first and then trylock again to check dirty
>>>>>> status of quota data.
>>>>>>
>>>>>> The side effect is: in heavy race condition (e.g. multi quota data
>>>>>> upaters vs quota data flusher), it may decrease the probability of
>>>>>> synchronizing quota data successfully in checkpoint() due to limited
>>>>>> retry time of quota flush.
>>>>>>
>>>>>> Fixes: db6ec53b7e03 ("f2fs: add a rw_sem to cover quota flag changes")
>>>>>> Cc: stable@vger.kernel.org # v5.3+
>>>>>> Reported-by: Yi Zhuang <zhuangyi1@huawei.com>
>>>>>> Signed-off-by: Chao Yu <chao@kernel.org>
>>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>> ---
>>>>>> fs/f2fs/checkpoint.c | 3 ++-
>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>>>>> index 83e9bc0f91ff..7b0282724231 100644
>>>>>> --- a/fs/f2fs/checkpoint.c
>>>>>> +++ b/fs/f2fs/checkpoint.c
>>>>>> @@ -1162,7 +1162,8 @@ static bool __need_flush_quota(struct f2fs_sb_info *sbi)
>>>>>> if (!is_journalled_quota(sbi))
>>>>>> return false;
>>>>>> - down_write(&sbi->quota_sem);
>>>>>> + if (!down_write_trylock(&sbi->quota_sem))
>>>>>> + return true;
>>>>>> if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) {
>>>>>> ret = false;
>>>>>> } else if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) {
>>>>>> --
>>>>>> 2.32.0
>>>>>>
>>>>>
>>>>> What stable tree(s) is this for?
>>>>
>>>> Oh, please help to try applying to 5.4, 5.10, and 5.15 stable trees, thanks!
>>>
>>> This is already in the 5.15.6 kernel release, do you need it applied
>>> there again? :)
>>
>> Oops, no, so 5.4 and 5.10 is enough. ;)
>> We can skip 5.15 since this patch was merged in 5.15-rc1 at the first time.
>
> It was merged in 5.16-rc1, and then backported to 5.15.6. You might
> want to check your git scripts.
Oh, yes, you're right, it looks we merged patches with same title in both 5.15-rc1
and 5.16-rc1, that won't happen usually... so I positioning the wrong merge time
only based on patch title...
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=a5c0042200b28fff3bde6fa128ddeaef97990f8d
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=9de71ede81e6d1a111fdd868b2d78d459fa77f80
>
> Anyway, now queued up, thanks.
Thank you!
Thanks,
>
> greg k-h
^ permalink raw reply
* Re: [RFC 00/13] kprobe/bpf: Add support to attach multiple kprobes
From: Masami Hiramatsu @ 2022-01-05 15:24 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, netdev, bpf,
lkml, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Steven Rostedt, Naveen N. Rao, Anil S Keshavamurthy,
David S. Miller
In-Reply-To: <20220104080943.113249-1-jolsa@kernel.org>
On Tue, 4 Jan 2022 09:09:30 +0100
Jiri Olsa <jolsa@redhat.com> wrote:
> hi,
> adding support to attach multiple kprobes within single syscall
> and speed up attachment of many kprobes.
>
> The previous attempt [1] wasn't fast enough, so coming with new
> approach that adds new kprobe interface.
Yes, since register_kprobes() just registers multiple kprobes on
array. This is designed for dozens of kprobes.
> The attachment speed of of this approach (tested in bpftrace)
> is now comparable to ftrace tracer attachment speed.. fast ;-)
Yes, because that if ftrace, not kprobes.
> The limit of this approach is forced by using ftrace as attach
> layer, so it allows only kprobes on function's entry (plus
> return probes).
Note that you also need to multiply the number of instances.
>
> This patchset contains:
> - kprobes support to register multiple kprobes with current
> kprobe API (patches 1 - 8)
> - bpf support ot create new kprobe link allowing to attach
> multiple addresses (patches 9 - 14)
>
> We don't need to care about multiple probes on same functions
> because it's taken care on the ftrace_ops layer.
Hmm, I think there may be a time to split the "kprobe as an
interface for the software breakpoint" and "kprobe as a wrapper
interface for the callbacks of various instrumentations", like
'raw_kprobe'(or kswbp) and 'kprobes'.
And this may be called as 'fprobe' as ftrace_ops wrapper.
(But if the bpf is enough flexible, this kind of intermediate layer
may not be needed, it can use ftrace_ops directly, eventually)
Jiri, have you already considered to use ftrace_ops from the
bpf directly? Are there any issues?
(bpf depends on 'kprobe' widely?)
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/1] softmmu: fix device deletion events with -device JSON syntax
From: Thomas Huth @ 2022-01-05 15:19 UTC (permalink / raw)
To: Daniel P. Berrangé, Laurent Vivier
Cc: Kevin Wolf, Eduardo Habkost, Peter Krempa, qemu-devel,
Markus Armbruster, Paolo Bonzini, Eric Blake
In-Reply-To: <YdW2qk19K5N7gr9W@redhat.com>
On 05/01/2022 16.18, Daniel P. Berrangé wrote:
> On Wed, Jan 05, 2022 at 04:00:54PM +0100, Laurent Vivier wrote:
>> On 05/01/2022 15:55, Daniel P. Berrangé wrote:
>>> On Wed, Jan 05, 2022 at 03:49:12PM +0100, Laurent Vivier wrote:
>>>> On 05/01/2022 13:38, Daniel P. Berrangé wrote:
>>>>> The -device JSON syntax impl leaks a reference on the created
>>>>> DeviceState instance. As a result when you hot-unplug the
>>>>> device, the device_finalize method won't be called and thus
>>>>> it will fail to emit the required DEVICE_DELETED event.
>>>>>
>>>>> A 'json-cli' feature was previously added against the
>>>>> 'device_add' QMP command QAPI schema to indicated to mgmt
>>>>> apps that -device supported JSON syntax. Given the hotplug
>>>>> bug that feature flag is no unusable for its purpose, so
>>>>
>>>> Not sure to understand: do you mean "now unusable"?
>>>
>>> An application wants to known whether QEMU can support JSON
>>> syntax with -device. If they look for the 'json-cli' feature
>>> as a witness, they'll end up using JSON with QEMU 6.2 which
>>> is giving them broken hotplug. This is unusable for any
>>> non-trivial use cases. So we need a new witness to indicate
>>> whether JSON is viable with -device, that only the newly
>>> fixed QEMU will report.
>>
>> I understand that, my problem was with your sentence:
>>
>> "Given the hotplug bug that feature flag is no unusable for its purpose"
>
> What's the problem with that ? It is reasonabled to say a -device impl
> which is broken for hotplug is not usable for non-toy use cases.
So it should be "not usable" instead of "no usable" in the commit description.
Thomas
^ permalink raw reply
* Re: [PATCH v1 20/34] tests/docker: add libfuse3 development headers
From: Richard W.M. Jones @ 2022-01-05 14:26 UTC (permalink / raw)
To: Alex Bennée
Cc: fam, Thomas Huth, berrange, Beraldo Leal, qemu-devel,
Wainer dos Santos Moschetta, f4bug, Hanna Reitz, stefanha, crosa,
pbonzini, aurelien
In-Reply-To: <20220105135009.1584676-21-alex.bennee@linaro.org>
On Wed, Jan 05, 2022 at 01:49:55PM +0000, Alex Bennée wrote:
> From: Stefan Hajnoczi <stefanha@redhat.com>
>
> The FUSE exports feature is not built because most container images do
> not have libfuse3 development headers installed. Add the necessary
> packages to the Dockerfiles.
>
> Cc: Hanna Reitz <hreitz@redhat.com>
> Cc: Richard W.M. Jones <rjones@redhat.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> Acked-by: Richard W.M. Jones <rjones@redhat.com>
> Reviewed-by: Beraldo Leal <bleal@redhat.com>
> Tested-by: Beraldo Leal <bleal@redhat.com>
> Message-Id: <20211207160025.52466-1-stefanha@redhat.com>
> [AJB: migrate to lcitool qemu.yml and regenerate]
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
I checked all the package names and they look good, so:
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Rich.
> tests/docker/dockerfiles/alpine.docker | 1 +
> tests/docker/dockerfiles/centos8.docker | 1 +
> tests/docker/dockerfiles/fedora.docker | 1 +
> tests/docker/dockerfiles/opensuse-leap.docker | 1 +
> tests/docker/dockerfiles/ubuntu2004.docker | 1 +
> tests/lcitool/projects/qemu.yml | 1 +
> 6 files changed, 6 insertions(+)
>
> diff --git a/tests/docker/dockerfiles/alpine.docker b/tests/docker/dockerfiles/alpine.docker
> index 97c7a88d1f..eb2251c81c 100644
> --- a/tests/docker/dockerfiles/alpine.docker
> +++ b/tests/docker/dockerfiles/alpine.docker
> @@ -29,6 +29,7 @@ RUN apk update && \
> dtc-dev \
> eudev-dev \
> findutils \
> + fuse3-dev \
> g++ \
> gcc \
> gcovr \
> diff --git a/tests/docker/dockerfiles/centos8.docker b/tests/docker/dockerfiles/centos8.docker
> index 3c62b62a99..cbb909d02b 100644
> --- a/tests/docker/dockerfiles/centos8.docker
> +++ b/tests/docker/dockerfiles/centos8.docker
> @@ -30,6 +30,7 @@ RUN dnf update -y && \
> device-mapper-multipath-devel \
> diffutils \
> findutils \
> + fuse3-devel \
> gcc \
> gcc-c++ \
> genisoimage \
> diff --git a/tests/docker/dockerfiles/fedora.docker b/tests/docker/dockerfiles/fedora.docker
> index 6784878b56..60207f3da3 100644
> --- a/tests/docker/dockerfiles/fedora.docker
> +++ b/tests/docker/dockerfiles/fedora.docker
> @@ -37,6 +37,7 @@ exec "$@"' > /usr/bin/nosync && \
> device-mapper-multipath-devel \
> diffutils \
> findutils \
> + fuse3-devel \
> gcc \
> gcc-c++ \
> gcovr \
> diff --git a/tests/docker/dockerfiles/opensuse-leap.docker b/tests/docker/dockerfiles/opensuse-leap.docker
> index 5510bdf19c..f57d8cfb29 100644
> --- a/tests/docker/dockerfiles/opensuse-leap.docker
> +++ b/tests/docker/dockerfiles/opensuse-leap.docker
> @@ -22,6 +22,7 @@ RUN zypper update -y && \
> dbus-1 \
> diffutils \
> findutils \
> + fuse3-devel \
> gcc \
> gcc-c++ \
> gcovr \
> diff --git a/tests/docker/dockerfiles/ubuntu2004.docker b/tests/docker/dockerfiles/ubuntu2004.docker
> index 40402b91fe..4e562dfdcd 100644
> --- a/tests/docker/dockerfiles/ubuntu2004.docker
> +++ b/tests/docker/dockerfiles/ubuntu2004.docker
> @@ -46,6 +46,7 @@ RUN export DEBIAN_FRONTEND=noninteractive && \
> libepoxy-dev \
> libfdt-dev \
> libffi-dev \
> + libfuse3-dev \
> libgbm-dev \
> libgcrypt20-dev \
> libglib2.0-dev \
> diff --git a/tests/lcitool/projects/qemu.yml b/tests/lcitool/projects/qemu.yml
> index 2e2271510e..ed5ab1407a 100644
> --- a/tests/lcitool/projects/qemu.yml
> +++ b/tests/lcitool/projects/qemu.yml
> @@ -18,6 +18,7 @@ packages:
> - diffutils
> - dtrace
> - findutils
> + - fuse3
> - g++
> - gcc
> - gcovr
> --
> 2.30.2
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
^ permalink raw reply
* stable/linux-4.19.y build: 198 builds: 6 failed, 192 passed, 2 errors, 32 warnings (v4.19.224)
From: kernelci.org bot @ 2022-01-05 15:23 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable/linux-4.19.y build: 198 builds: 6 failed, 192 passed, 2 errors, 32 warnings (v4.19.224)
Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.19.y/kernel/v4.19.224/
Tree: stable
Branch: linux-4.19.y
Git Describe: v4.19.224
Git Commit: a94dc7407bf3aab53c9fd65d24065a43353a0dbe
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Built: 7 unique architectures
Build Failures Detected:
arm:
rpc_defconfig: (gcc-10) FAIL
mips:
ip27_defconfig: (gcc-10) FAIL
ip28_defconfig: (gcc-10) FAIL
riscv:
allnoconfig: (gcc-10) FAIL
defconfig: (gcc-10) FAIL
tinyconfig: (gcc-10) FAIL
Errors and Warnings Detected:
arc:
arm64:
defconfig (gcc-10): 3 warnings
defconfig+arm64-chromebook (gcc-10): 3 warnings
arm:
omap1_defconfig (gcc-10): 1 warning
rpc_defconfig (gcc-10): 2 errors
i386:
allnoconfig (gcc-10): 2 warnings
i386_defconfig (gcc-10): 2 warnings
tinyconfig (gcc-10): 2 warnings
mips:
lemote2f_defconfig (gcc-10): 1 warning
loongson3_defconfig (gcc-10): 1 warning
malta_qemu_32r6_defconfig (gcc-10): 1 warning
mtx1_defconfig (gcc-10): 3 warnings
nlm_xlp_defconfig (gcc-10): 1 warning
riscv:
x86_64:
allnoconfig (gcc-10): 3 warnings
tinyconfig (gcc-10): 3 warnings
x86_64_defconfig (gcc-10): 3 warnings
x86_64_defconfig+x86-chromebook (gcc-10): 3 warnings
Errors summary:
1 arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
1 arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
Warnings summary:
7 ld: warning: creating DT_TEXTREL in a PIE
6 aarch64-linux-gnu-ld: warning: -z norelro ignored
4 ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
4 arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
3 ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
2 sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
2 net/core/rtnetlink.c:3197:1: warning: the frame size of 1328 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 {standard input}:132: Warning: macro instruction expanded into multiple instructions
1 sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
1 net/core/rtnetlink.c:3197:1: warning: the frame size of 1344 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 drivers/gpio/gpio-omap.c:1233:34: warning: array ‘omap_gpio_match’ assumed to have one element
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (i386, gcc-10) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
allnoconfig (riscv, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (x86_64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
allnoconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ar7_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
assabet_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
at91_dt_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath25_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath79_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
badge4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm2835_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bigsur_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_be_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_stb_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
capcella_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ci20_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cobalt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
collie_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
corgi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
davinci_all_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
db1xxx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (riscv, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
aarch64-linux-gnu-ld: warning: -z norelro ignored
aarch64-linux-gnu-ld: warning: -z norelro ignored
aarch64-linux-gnu-ld: warning: -z norelro ignored
--------------------------------------------------------------------------------
defconfig+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
aarch64-linux-gnu-ld: warning: -z norelro ignored
aarch64-linux-gnu-ld: warning: -z norelro ignored
aarch64-linux-gnu-ld: warning: -z norelro ignored
--------------------------------------------------------------------------------
dove_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
e55_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
efm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
em_x270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ep93xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
exynos_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ezx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
footbridge_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gcw0_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gemini_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h5000_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hackkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hisi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hsdk_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-10) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
imote2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
integrator_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop32x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop33x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip22_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jazz_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
keystone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ks8695_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lasat_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
net/core/rtnetlink.c:3197:1: warning: the frame size of 1328 bytes is larger than 1024 bytes [-Wframe-larger-than=]
--------------------------------------------------------------------------------
loongson1b_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1c_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
net/core/rtnetlink.c:3197:1: warning: the frame size of 1328 bytes is larger than 1024 bytes [-Wframe-larger-than=]
--------------------------------------------------------------------------------
lpc18xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpd270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
magician_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mainstone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_qemu_32r6_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
{standard input}:132: Warning: macro instruction expanded into multiple instructions
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_xpa_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mini2440_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
moxart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mpc30x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mps2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msp71xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
--------------------------------------------------------------------------------
multi_v4t_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mxs_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
neponset_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netwinder_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nhk8815_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
net/core/rtnetlink.c:3197:1: warning: the frame size of 1344 bytes is larger than 1024 bytes [-Wframe-larger-than=]
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc950_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc960_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omap1_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/gpio/gpio-omap.c:1233:34: warning: array ‘omap_gpio_match’ assumed to have one element
--------------------------------------------------------------------------------
omap2plus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omega2p_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
orion5x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
oxnas_v6_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
palmz72_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pcm027_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pic32mzda_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pistachio_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pleb_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa168_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qcom_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rb532_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rm200_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm, gcc-10) — FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
--------------------------------------------------------------------------------
rt305x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c6400_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s5pv210_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sama5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shmobile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
simpad_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
socfpga_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear6xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spitz_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
stm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sunxi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tango4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0219_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tegra_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (x86_64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (i386, gcc-10) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (riscv, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u8500_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
versatile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vexpress_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vf610m4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
viper_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vocore2_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
workpad_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
x86_64_defconfig+x86-chromebook (x86_64, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_64.S:1738: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
xcep_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* Re: [PATCH] headers/uninline: Uninline single-use function: kobject_has_children()
From: Greg Kroah-Hartman @ 2022-01-05 15:23 UTC (permalink / raw)
To: Ingo Molnar
Cc: Kirill A. Shutemov, Linus Torvalds, linux-kernel, linux-arch,
Andrew Morton, Peter Zijlstra, Thomas Gleixner, David S. Miller,
Ard Biesheuvel, Josh Poimboeuf, Jonathan Corbet, Al Viro
In-Reply-To: <YdTiF5dVeizYtIDS@gmail.com>
On Wed, Jan 05, 2022 at 01:11:03AM +0100, Ingo Molnar wrote:
>
> * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > On Tue, Jan 04, 2022 at 04:09:57PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 04, 2022 at 02:54:31PM +0100, Ingo Molnar wrote:
> > > >
> > > > * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > > On Tue, Jan 04, 2022 at 11:54:55AM +0100, Ingo Molnar wrote:
> > > > > > There's one happy exception though, all the uninlining patches that
> > > > > > uninline a single-call function are probably fine as-is:
> > > > >
> > > > > <snip>
> > > > >
> > > > > > 3443e75fd1f8 headers/uninline: Uninline single-use function: kobject_has_children()
> > > > >
> > > > > Let me go take this right now, no need for this to wait, it should be
> > > > > out of kobject.h as you rightfully show there is only one user.
> > > >
> > > > Sure - here you go!
> > >
> > > I just picked it out of your git tree already :)
> > >
> > > Along those lines, any objection to me taking at least one other one?
> > > 3f8757078d27 ("headers/prep: usb: gadget: Fix namespace collision") and
>
> Ack.
>
> > > 6fb993fa3832 ("headers/deps: USB: Optimize <linux/usb/ch9.h>
>
> Ack.
This one required me to fix up a usb core file that was only including
this .h file and not kernel.h which it also needed. Now resolved in my
tree.
> > > dependencies, remove <linux/device.h>") look like I can take now into my
> > > USB tree with no problems.
> >
> > Also these look good to go now:
> > bae9ddd98195 ("headers/prep: Fix non-standard header section: drivers/usb/cdns3/core.h")
>
> Ack.
>
> > c027175b37e5 ("headers/prep: Fix non-standard header section: drivers/usb/host/ohci-tmio.c")
>
> Ack.
>
> Note that these latter two patches just simplified the task of my
> (simplistic) tooling, which is basically a shell script that inserts
> header dependencies to the head of .c and .h files, right in front of
> the first #include line it encounters.
>
> These two patches do have some marginal clean-up value too, so I'm not
> opposed to merging them - just wanted to declare their true role. :-)
They all are sane cleanups, so I've taken them in my tree now. Make
your patchset a bit smaller against 5.17-rc1 when that comes around :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] sfc: Use swap() instead of open coding it
From: Jiapeng Chong @ 2022-01-05 15:22 UTC (permalink / raw)
To: ecree.xilinx
Cc: habetsm.xilinx, davem, kuba, ast, daniel, hawk, john.fastabend,
netdev, linux-kernel, bpf, Jiapeng Chong, Abaci Robot
Clean the following coccicheck warning:
./drivers/net/ethernet/sfc/efx_channels.c:870:36-37: WARNING opportunity
for swap().
./drivers/net/ethernet/sfc/efx_channels.c:824:36-37: WARNING opportunity
for swap().
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
---
drivers/net/ethernet/sfc/efx_channels.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx_channels.c b/drivers/net/ethernet/sfc/efx_channels.c
index b015d1f2e204..ead550ae2709 100644
--- a/drivers/net/ethernet/sfc/efx_channels.c
+++ b/drivers/net/ethernet/sfc/efx_channels.c
@@ -819,11 +819,8 @@ int efx_realloc_channels(struct efx_nic *efx, u32 rxq_entries, u32 txq_entries)
old_txq_entries = efx->txq_entries;
efx->rxq_entries = rxq_entries;
efx->txq_entries = txq_entries;
- for (i = 0; i < efx->n_channels; i++) {
- channel = efx->channel[i];
- efx->channel[i] = other_channel[i];
- other_channel[i] = channel;
- }
+ for (i = 0; i < efx->n_channels; i++)
+ swap(efx->channel[i], other_channel[i]);
/* Restart buffer table allocation */
efx->next_buffer_table = next_buffer_table;
@@ -865,11 +862,8 @@ int efx_realloc_channels(struct efx_nic *efx, u32 rxq_entries, u32 txq_entries)
/* Swap back */
efx->rxq_entries = old_rxq_entries;
efx->txq_entries = old_txq_entries;
- for (i = 0; i < efx->n_channels; i++) {
- channel = efx->channel[i];
- efx->channel[i] = other_channel[i];
- other_channel[i] = channel;
- }
+ for (i = 0; i < efx->n_channels; i++)
+ swap(efx->channel[i], other_channel[i]);
goto out;
}
--
2.20.1.7.g153144c
^ permalink raw reply related
* Re: [Patch v4 18/24] drm/amdkfd: CRIU checkpoint and restore xnack mode
From: philip yang @ 2022-01-05 15:22 UTC (permalink / raw)
To: Rajneesh Bhardwaj, amd-gfx, dri-devel
Cc: alexander.deucher, daniel.vetter, felix.kuehling,
christian.koenig, airlied
In-Reply-To: <20211223003711.13064-19-rajneesh.bhardwaj@amd.com>
[-- Attachment #1: Type: text/html, Size: 4650 bytes --]
^ permalink raw reply
* barebox extending boot-scripts
From: Frank Wunderlich @ 2022-01-05 15:20 UTC (permalink / raw)
To: barebox
Hi,
i'm making my first steps and try to add more boot-scripts (to land in /env/boot)
i added a scipt in
arch/arm/boards/rockchip-rk3568-evb/defaultenv/mmc-linux
and set
DEFAULT_ENVIRONMENT_PATH [=arch/arm/boards/rockchip-rk3568-evb/defaultenv]
but if i boot the board /env/boot only contains the 2 default scripts
barebox@Rockchip RK3568 EVB:/ ls /env/boot/
bnet net
so maybe the dir/config-option i used is for defining variables only right? should this point to an directory or a file?
i see this file which looks like the source of it
./defaultenv/defaultenv-2-base/boot/net
I've put them there and they appear, but this is not board specific, so if i later want to upstream one this is maybe not the right place.
./defaultenv/defaultenv-2-menu/menu/10-boot-all/net
seems to be a menu entry, but have not yet figured out how i can define one to add my scripts too
have not found anything for it in the documentation yet
btw. is there a way to use ls with wildcard without printing the path?
ls /mnt/sd.1/extlinux/
Image_5.16 Image_5.16-next.gz Image_5.16.gz
ls /mnt/sd.1/extlinux/Image*
/mnt/sd.1/extlinux/Image_5.16
/mnt/sd.1/extlinux/Image_5.16-next.gz
/mnt/sd.1/extlinux/Image_5.16.gz
i want to list only files matching Image*, but without path....number of columns does not matter
regards Frank
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH v8 16/19] ima: Enable re-auditing of modified files
From: Stefan Berger @ 2022-01-05 15:21 UTC (permalink / raw)
To: Stefan Berger, linux-integrity
Cc: zohar, serge, christian.brauner, containers, dmitry.kasatkin,
ebiederm, krzysztof.struczynski, roberto.sassu, mpeters, lhinds,
lsturman, puiterwi, jejb, jamjoom, linux-kernel, paul, rgb,
linux-security-module, jmorris
In-Reply-To: <20220104170416.1923685-17-stefanb@linux.vnet.ibm.com>
On 1/4/22 12:04, Stefan Berger wrote:
> From: Stefan Berger <stefanb@linux.ibm.com>
>
> Walk the list of ns_status associated with an iint if the file has
> changed and reset the IMA_AUDITED flag, which is part of the
> IMA_DONE_MASK. This causes a new audit message to be emitted when the
> file is again accessed on either the host or in an IMA namespace.
>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> ---
> security/integrity/ima/ima_main.c | 33 ++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 99dc984b49c9..bc3ab08f39c6 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -153,6 +153,35 @@ static void ima_rdwr_violation_check(struct ima_namespace *ns,
> "invalid_pcr", "open_writers");
> }
>
> +#ifdef CONFIG_IMA_NS
> +
> +static void mask_iint_ns_status_flags(struct integrity_iint_cache *iint,
> + unsigned long mask)
> +{
> + struct ns_status *status;
> + unsigned long flags;
> +
> + read_lock(&iint->ns_list_lock);
> + list_for_each_entry(status, &iint->ns_list, ns_next) {
> + flags = iint_flags(iint, status) & mask;
> + set_iint_flags(iint, status, flags);
> + }
> + read_unlock(&iint->ns_list_lock);
> +}
> +
> +#else
> +
> +static void mask_iint_ns_status_flags(struct integrity_iint_cache *iint,
> + unsigned long mask)
> +{
> + unsigned long flags;
> +
> + flags = iint_flags(iint, NULL) & mask;
> + set_iint_flags(iint, NULL, flags);
> +}
> +
> +#endif
> +
The above two cases are due to this here:
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 547425c20e11..201a9d46d6e1 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -138,6 +138,10 @@ struct integrity_iint_cache {
enum integrity_status ima_creds_status:4;
enum integrity_status evm_status:4;
struct ima_digest_data *ima_hash;
+#ifdef CONFIG_IMA_NS
+ rwlock_t ns_list_lock;
+ struct list_head ns_list;
+#endif
};
Ideally namespaced and non-namespaced code cases would share the code and to be able to share it the above #ifdef CONFIG_IMA_NS in integrity.hshouldn't be there but we would have the lock and list in IMA namespacing and non-namespacing case. The above two code cases shown above are just the beginning and as more variables are moved from the iint into the ns_status these types of 'two cases of code' would show up in more places. So I think we should prevent this already now.
To be able to share the code we need an ns_status on a list in the non-namespacing case as well. In the non-namespacing case it would always be a single ns_status on the list. What is worth a decision is how to get the ns_status on the list. One idea would be to conditionally embed it into the integrity_iint_cache like this:
/* integrity data associated with an inode */
struct integrity_iint_cache {
struct rb_node rb_node; /* rooted in integrity_iint_tree */
struct mutex mutex; /* protects: version, flags, digest */
struct inode *inode; /* back pointer to inode in question */
u64 version; /* track inode changes */
unsigned long flags;
unsigned long atomic_flags;
enum integrity_status ima_file_status:4;
enum integrity_status ima_mmap_status:4;
enum integrity_status ima_bprm_status:4;
enum integrity_status ima_read_status:4;
enum integrity_status ima_creds_status:4;
enum integrity_status evm_status:4;
struct ima_digest_data *ima_hash;
rwlock_t ns_list_lock;
struct list_head ns_list;
#ifndef CONFIG_IMA_NS
struct ns_status status;
#endif
};
This would prevent a 2nd cache just for allocation of ns_status in the
non-namespacing case and getting the embedded ns_status onto the list
would also be like this:
INIT_LIST_HEAD(&iint->ns_list);
#ifndef CONFIG_IMA_NS
INIT_LIST_HEAD(&iint->status.ns_next);
list_add_tail(&iint->status.ns_next, &iint->ns_list);
#endif
The other option is to allocated the ns_status via a minimal
implementation of ima_ns_status.c for the non-namespaced case using
kmalloc's from a cache for ns_status structures.
Also, the new 'rwlock_t ns_list_lock' in the iint would really only be
necessary for locking in the namespacing case. However, to be able to
share the code we would need to keep this lock around for the
non-namespacing case as well so that we can call read_lock() in both
cases. An option would be to introduce a macro for the locking that is a
no-op in the non-namespacing case and does the actual locking in the
namespacing case. I am not sure what would be better. I would prefer to
explicitly see the read_lock()...
> static void ima_check_last_writer(struct integrity_iint_cache *iint,
> struct inode *inode, struct file *file)
> {
> @@ -169,8 +198,10 @@ static void ima_check_last_writer(struct integrity_iint_cache *iint,
> if (!IS_I_VERSION(inode) ||
> !inode_eq_iversion(inode, iint->version) ||
> (iint->flags & IMA_NEW_FILE)) {
> - iint->flags &= ~(IMA_DONE_MASK | IMA_NEW_FILE);
> + mask_iint_ns_status_flags(iint,
> + ~(IMA_DONE_MASK | IMA_NEW_FILE));
> iint->measured_pcrs = 0;
> +
> if (update)
> ima_update_xattr(iint, file);
> }
^ permalink raw reply related
* [PATCH v4] receive-pack.c: consolidate find header logic
From: John Cai via GitGitGadget @ 2022-01-05 15:21 UTC (permalink / raw)
To: git; +Cc: John Cai, John Cai
In-Reply-To: <pull.1125.v3.git.git.1640931460758.gitgitgadget@gmail.com>
From: John Cai <johncai86@gmail.com>
There are two functions that have very similar logic of finding a header
value. find_commit_header, and find_header. We can conslidate the logic
by introducing a new function find_header_mem, which is equivalent to
find_commit_header except it takes a len parameter that determines how
many bytes will be read. find_commit_header and find_header can then both
call find_header_mem.
This reduces duplicate logic, as the logic for finding header values
can now all live in one place.
Signed-off-by: John Cai <johncai86@gmail.com>
---
Consolidate find_header logic into one function
This addresses the NEEDSWORK comment in builtin/receive-pack.c:
/**
* NEEDSWORK: reuse find_commit_header() from jk/commit-author-parsing
* after dropping "_commit" from its name and possibly moving it out
* of commit.c
**/
There are two functions that have very similar logic of finding a header
value. find_commit_header, and find_header. We can conslidate the logic
by introducing a new function find_header_mem, which is equivalent to
find_commit_header except it takes a len parameter that determines how
many bytes will be read. find_commit_header and find_header can then
both call find_header_mem.
This reduces duplicate logic, as the logic for finding header values can
now all live in one place.
Changes since v4:
* added NEEDSWORK block detailing what needs to be done to clean up
find_header_mem
Changes since v3:
* fixed verbiage in commit message
* adjusted style of an if block (based on Junio's feedback)
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1125%2Fjohn-cai%2Fjc%2Freplace-find-header-v4
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1125/john-cai/jc/replace-find-header-v4
Pull-Request: https://github.com/git/git/pull/1125
Range-diff vs v3:
1: 463df42e7e0 ! 1: a7b00022b00 receive-pack.c: consolidate find header logic
@@ Commit message
There are two functions that have very similar logic of finding a header
value. find_commit_header, and find_header. We can conslidate the logic
- by using find_commit_header and replacing the logic in find_header.
-
- Introduce a new function find_header_max, which is equivalent to
+ by introducing a new function find_header_mem, which is equivalent to
find_commit_header except it takes a len parameter that determines how
- many bytes to read. find_commit_header can then call find_header_max
- with 0 as the len.
+ many bytes will be read. find_commit_header and find_header can then both
+ call find_header_mem.
- This cleans up duplicate logic, as the logic for finding header values
- is now all in one place.
+ This reduces duplicate logic, as the logic for finding header values
+ can now all live in one place.
Signed-off-by: John Cai <johncai86@gmail.com>
@@ builtin/receive-pack.c: static char *prepare_push_cert_nonce(const char *path, t
+ size_t out_len;
+ const char *val = find_header_mem(msg, len, key, &out_len);
+
-+ if (val == NULL)
++ if (!val)
+ return NULL;
+
+ if (next_line)
@@ commit.c: struct commit_list **commit_list_append(struct commit *commit,
const char *line = msg;
- while (line) {
++ /*
++ * NEEDSWORK: Between line[0] and msg[len], there may not be a LF nor NUL
++ * at all, and strchrnul() will scan beyond the range we were given
++ * Make this operation safer and abide by the contract to only read up to len.
++ */
+ while (line && line < msg + len) {
const char *eol = strchrnul(line, '\n');
builtin/receive-pack.c | 33 ++++++++++-----------------------
commit.c | 14 ++++++++++++--
commit.h | 5 +++++
3 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 9f4a0b816cf..5c2732a0d07 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -581,32 +581,19 @@ static char *prepare_push_cert_nonce(const char *path, timestamp_t stamp)
return strbuf_detach(&buf, NULL);
}
-/*
- * NEEDSWORK: reuse find_commit_header() from jk/commit-author-parsing
- * after dropping "_commit" from its name and possibly moving it out
- * of commit.c
- */
static char *find_header(const char *msg, size_t len, const char *key,
const char **next_line)
{
- int key_len = strlen(key);
- const char *line = msg;
-
- while (line && line < msg + len) {
- const char *eol = strchrnul(line, '\n');
-
- if ((msg + len <= eol) || line == eol)
- return NULL;
- if (line + key_len < eol &&
- !memcmp(line, key, key_len) && line[key_len] == ' ') {
- int offset = key_len + 1;
- if (next_line)
- *next_line = *eol ? eol + 1 : eol;
- return xmemdupz(line + offset, (eol - line) - offset);
- }
- line = *eol ? eol + 1 : NULL;
- }
- return NULL;
+ size_t out_len;
+ const char *val = find_header_mem(msg, len, key, &out_len);
+
+ if (!val)
+ return NULL;
+
+ if (next_line)
+ *next_line = val + out_len + 1;
+
+ return xmemdupz(val, out_len);
}
/*
diff --git a/commit.c b/commit.c
index a348f085b2b..5ece03e6373 100644
--- a/commit.c
+++ b/commit.c
@@ -1631,12 +1631,18 @@ struct commit_list **commit_list_append(struct commit *commit,
return &new_commit->next;
}
-const char *find_commit_header(const char *msg, const char *key, size_t *out_len)
+const char *find_header_mem(const char *msg, size_t len,
+ const char *key, size_t *out_len)
{
int key_len = strlen(key);
const char *line = msg;
- while (line) {
+ /*
+ * NEEDSWORK: Between line[0] and msg[len], there may not be a LF nor NUL
+ * at all, and strchrnul() will scan beyond the range we were given
+ * Make this operation safer and abide by the contract to only read up to len.
+ */
+ while (line && line < msg + len) {
const char *eol = strchrnul(line, '\n');
if (line == eol)
@@ -1653,6 +1659,10 @@ const char *find_commit_header(const char *msg, const char *key, size_t *out_len
return NULL;
}
+const char *find_commit_header(const char *msg, const char *key, size_t *out_len)
+{
+ return find_header_mem(msg, strlen(msg), key, out_len);
+}
/*
* Inspect the given string and determine the true "end" of the log message, in
* order to find where to put a new Signed-off-by trailer. Ignored are
diff --git a/commit.h b/commit.h
index 3ea32766bcb..38cc5426615 100644
--- a/commit.h
+++ b/commit.h
@@ -290,12 +290,17 @@ void free_commit_extra_headers(struct commit_extra_header *extra);
/*
* Search the commit object contents given by "msg" for the header "key".
+ * Reads up to "len" bytes of "msg".
* Returns a pointer to the start of the header contents, or NULL. The length
* of the header, up to the first newline, is returned via out_len.
*
* Note that some headers (like mergetag) may be multi-line. It is the caller's
* responsibility to parse further in this case!
*/
+const char *find_header_mem(const char *msg, size_t len,
+ const char *key,
+ size_t *out_len);
+
const char *find_commit_header(const char *msg, const char *key,
size_t *out_len);
base-commit: c8b2ade48c204690119936ada89cd938c476c5c2
--
gitgitgadget
^ permalink raw reply related
* Re: [LKP] Re: [x86/mm/64] f154f29085: BUG:kernel_reboot-without-warning_in_boot_stage - clang KCOV?
From: Borislav Petkov @ 2022-01-05 15:21 UTC (permalink / raw)
To: Yin Fengwei
Cc: Marco Elver, Carel Si, Joerg Roedel, LKML, x86@kernel.org,
lkp@lists.01.org, lkp, bfields@fieldses.org, llvm@lists.linux.dev
In-Reply-To: <fa2f7d50-5226-726d-a9ad-2c42cb5c4054@intel.com>
On Wed, Jan 05, 2022 at 08:47:28PM +0800, Yin Fengwei wrote:
> it's better that clang restore its behavior to clang-12.
Probably, but I'm not gonna hold my breath - folks are likely very
busy...
> Or people need to use __no_profile annotation if want to add function
> before GCOV/KASAN is initialized.
... yap, and because fixing it this way is easy, I've already queued the
__no_profile solution:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/mm&id=b64dfcde1ca9cb82e38e573753f0c0db8fb841c2
Thanks.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ 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.