- Linux-stable-mirror - lists.linaro.org

stable/linux-4.9.y boot: 41 boots: 0 failed, 41 passed (v4.9.168)

by kernelci.org bot

stable/linux-4.9.y boot: 41 boots: 0 failed, 41 passed (v4.9.168) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.9.y/kernel/v4.9.168/ Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.9.y/kernel/v4.9.168/ Tree: stable Branch: linux-4.9.y Git Describe: v4.9.168 Git Commit: e93d4749118fbb0ae8fc889706daa56d4dafecd4 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 20 unique boards, 12 SoC families, 8 builds out of 197 --- For more info write to <info(a)kernelci.org>

6 years, 7 months

1
0
0 0

stable/linux-4.14.y boot: 50 boots: 0 failed, 49 passed with 1 untried/unknown (v4.14.111)

by kernelci.org bot

stable/linux-4.14.y boot: 50 boots: 0 failed, 49 passed with 1 untried/unknown (v4.14.111) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.14.y/kernel/v4.14.1… Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.14.y/kernel/v4.14.111/ Tree: stable Branch: linux-4.14.y Git Describe: v4.14.111 Git Commit: 1ec8f1f0bffe34ebdf95dbe0fd4a6635a84612a8 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 27 unique boards, 13 SoC families, 8 builds out of 201 --- For more info write to <info(a)kernelci.org>

6 years, 7 months

1
0
0 0

stable-rc/linux-3.18.y boot: 51 boots: 1 failed, 44 passed with 6 offline (v3.18.138)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 51 boots: 1 failed, 44 passed with 6 offline (v3.18.138) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.138/ Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.138 Git Commit: a1a43d6522bc1da70f210d46485fac7a71c13ca8 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 22 unique boards, 12 SoC families, 13 builds out of 189 Boot Failure Detected: x86_64: x86_64_defconfig: gcc-7: minnowboard-turbot-E3826: 1 failed lab Offline Platforms: arm: bcm2835_defconfig: gcc-7 bcm2835-rpi-b: 1 offline lab tegra_defconfig: gcc-7 tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab multi_v7_defconfig: gcc-7 tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab sama5_defconfig: gcc-7 at91-sama5d4ek: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 7 months

1
0
0 0

stable/linux-5.0.y boot: 53 boots: 5 failed, 48 passed (v5.0.7)

by kernelci.org bot

stable/linux-5.0.y boot: 53 boots: 5 failed, 48 passed (v5.0.7) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-5.0.y/kernel/v5.0.7/ Full Build Summary: https://kernelci.org/build/stable/branch/linux-5.0.y/kernel/v5.0.7/ Tree: stable Branch: linux-5.0.y Git Describe: v5.0.7 Git Commit: 8b298d3a0bd5feeb47129c4889356b38b78ab231 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 30 unique boards, 14 SoC families, 9 builds out of 208 Boot Regressions Detected: arm64: defconfig: gcc-7: meson-gxbb-nanopi-k2: lab-baylibre: new failure (last pass: v5.0.6) meson-gxbb-p200: lab-baylibre: new failure (last pass: v5.0.5) meson-gxl-s805x-p241: lab-baylibre: new failure (last pass: v5.0.6) meson-gxl-s905x-khadas-vim: lab-baylibre: new failure (last pass: v5.0.5) meson-gxl-s905x-libretech-cc: lab-baylibre: new failure (last pass: v5.0.6) Boot Failures Detected: arm64: defconfig: gcc-7: meson-gxbb-nanopi-k2: 1 failed lab meson-gxbb-p200: 1 failed lab meson-gxl-s805x-p241: 1 failed lab meson-gxl-s905x-khadas-vim: 1 failed lab meson-gxl-s905x-libretech-cc: 1 failed lab --- For more info write to <info(a)kernelci.org>

6 years, 7 months

1
0
0 0

stable-rc/linux-4.14.y boot: 112 boots: 1 failed, 93 passed with 18 offline (v4.14.111)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 112 boots: 1 failed, 93 passed with 18 offline (v4.14.111) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.111/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.111 Git Commit: 1ec8f1f0bffe34ebdf95dbe0fd4a6635a84612a8 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 61 unique boards, 23 SoC families, 14 builds out of 201 Boot Failure Detected: arm64: defconfig: gcc-7: rk3399-firefly: 1 failed lab Offline Platforms: arm: bcm2835_defconfig: gcc-7 bcm2835-rpi-b: 1 offline lab multi_v7_defconfig: gcc-7 alpine-db: 1 offline lab at91-sama5d4_xplained: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab tegra_defconfig: gcc-7 tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab sunxi_defconfig: gcc-7 sun5i-r8-chip: 1 offline lab sama5_defconfig: gcc-7 at91-sama5d4_xplained: 1 offline lab qcom_defconfig: gcc-7 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab arm64: defconfig: gcc-7 apq8016-sbc: 1 offline lab juno-r2: 1 offline lab mt7622-rfb1: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 7 months

1
0
0 0

[patch 09/14] mm: writeback: use exact memcg dirty counts

by akpm＠linux-foundation.org

From: Greg Thelen <gthelen(a)google.com> Subject: mm: writeback: use exact memcg dirty counts Since a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat reporting") memcg dirty and writeback counters are managed as: 1) per-memcg per-cpu values in range of [-32..32] 2) per-memcg atomic counter When a per-cpu counter cannot fit in [-32..32] it's flushed to the atomic. Stat readers only check the atomic. Thus readers such as balance_dirty_pages() may see a nontrivial error margin: 32 pages per cpu. Assuming 100 cpus: 4k x86 page_size: 13 MiB error per memcg 64k ppc page_size: 200 MiB error per memcg Considering that dirty+writeback are used together for some decisions the errors double. This inaccuracy can lead to undeserved oom kills. One nasty case is when all per-cpu counters hold positive values offsetting an atomic negative value (i.e. per_cpu[*]=32, atomic=n_cpu*-32). balance_dirty_pages() only consults the atomic and does not consider throttling the next n_cpu*32 dirty pages. If the file_lru is in the 13..200 MiB range then there's absolutely no dirty throttling, which burdens vmscan with only dirty+writeback pages thus resorting to oom kill. It could be argued that tiny containers are not supported, but it's more subtle. It's the amount the space available for file lru that matters. If a container has memory.max-200MiB of non reclaimable memory, then it will also suffer such oom kills on a 100 cpu machine. The following test reliably ooms without this patch. This patch avoids oom kills. $ cat test mount -t cgroup2 none /dev/cgroup cd /dev/cgroup echo +io +memory > cgroup.subtree_control mkdir test cd test echo 10M > memory.max (echo $BASHPID > cgroup.procs && exec /memcg-writeback-stress /foo) (echo $BASHPID > cgroup.procs && exec dd if=/dev/zero of=/foo bs=2M count=100) $ cat memcg-writeback-stress.c /* * Dirty pages from all but one cpu. * Clean pages from the non dirtying cpu. * This is to stress per cpu counter imbalance. * On a 100 cpu machine: * - per memcg per cpu dirty count is 32 pages for each of 99 cpus * - per memcg atomic is -99*32 pages * - thus the complete dirty limit: sum of all counters 0 * - balance_dirty_pages() only sees atomic count -99*32 pages, which * it max()s to 0. * - So a workload can dirty -99*32 pages before balance_dirty_pages() * cares. */ #define _GNU_SOURCE #include <err.h> #include <fcntl.h> #include <sched.h> #include <stdlib.h> #include <stdio.h> #include <sys/stat.h> #include <sys/sysinfo.h> #include <sys/types.h> #include <unistd.h> static char *buf; static int bufSize; static void set_affinity(int cpu) { cpu_set_t affinity; CPU_ZERO(&affinity); CPU_SET(cpu, &affinity); if (sched_setaffinity(0, sizeof(affinity), &affinity)) err(1, "sched_setaffinity"); } static void dirty_on(int output_fd, int cpu) { int i, wrote; set_affinity(cpu); for (i = 0; i < 32; i++) { for (wrote = 0; wrote < bufSize; ) { int ret = write(output_fd, buf+wrote, bufSize-wrote); if (ret == -1) err(1, "write"); wrote += ret; } } } int main(int argc, char **argv) { int cpu, flush_cpu = 1, output_fd; const char *output; if (argc != 2) errx(1, "usage: output_file"); output = argv[1]; bufSize = getpagesize(); buf = malloc(getpagesize()); if (buf == NULL) errx(1, "malloc failed"); output_fd = open(output, O_CREAT|O_RDWR); if (output_fd == -1) err(1, "open(%s)", output); for (cpu = 0; cpu < get_nprocs(); cpu++) { if (cpu != flush_cpu) dirty_on(output_fd, cpu); } set_affinity(flush_cpu); if (fsync(output_fd)) err(1, "fsync(%s)", output); if (close(output_fd)) err(1, "close(%s)", output); free(buf); } Make balance_dirty_pages() and wb_over_bg_thresh() work harder to collect exact per memcg counters. This avoids the aforementioned oom kills. This does not affect the overhead of memory.stat, which still reads the single atomic counter. Why not use percpu_counter? memcg already handles cpus going offline, so no need for that overhead from percpu_counter. And the percpu_counter spinlocks are more heavyweight than is required. It probably also makes sense to use exact dirty and writeback counters in memcg oom reports. But that is saved for later. Link: http://lkml.kernel.org/r/20190329174609.164344-1-gthelen@google.com Signed-off-by: Greg Thelen <gthelen(a)google.com> Reviewed-by: Roman Gushchin <guro(a)fb.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [4.16+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/memcontrol.h | 5 ++++- mm/memcontrol.c | 20 ++++++++++++++++++-- 2 files changed, 22 insertions(+), 3 deletions(-) --- a/include/linux/memcontrol.h~writeback-use-exact-memcg-dirty-counts +++ a/include/linux/memcontrol.h @@ -566,7 +566,10 @@ struct mem_cgroup *lock_page_memcg(struc void __unlock_page_memcg(struct mem_cgroup *memcg); void unlock_page_memcg(struct page *page); -/* idx can be of type enum memcg_stat_item or node_stat_item */ +/* + * idx can be of type enum memcg_stat_item or node_stat_item. + * Keep in sync with memcg_exact_page_state(). + */ static inline unsigned long memcg_page_state(struct mem_cgroup *memcg, int idx) { --- a/mm/memcontrol.c~writeback-use-exact-memcg-dirty-counts +++ a/mm/memcontrol.c @@ -3882,6 +3882,22 @@ struct wb_domain *mem_cgroup_wb_domain(s return &memcg->cgwb_domain; } +/* + * idx can be of type enum memcg_stat_item or node_stat_item. + * Keep in sync with memcg_exact_page(). + */ +static unsigned long memcg_exact_page_state(struct mem_cgroup *memcg, int idx) +{ + long x = atomic_long_read(&memcg->stat[idx]); + int cpu; + + for_each_online_cpu(cpu) + x += per_cpu_ptr(memcg->stat_cpu, cpu)->count[idx]; + if (x < 0) + x = 0; + return x; +} + /** * mem_cgroup_wb_stats - retrieve writeback related stats from its memcg * @wb: bdi_writeback in question @@ -3907,10 +3923,10 @@ void mem_cgroup_wb_stats(struct bdi_writ struct mem_cgroup *memcg = mem_cgroup_from_css(wb->memcg_css); struct mem_cgroup *parent; - *pdirty = memcg_page_state(memcg, NR_FILE_DIRTY); + *pdirty = memcg_exact_page_state(memcg, NR_FILE_DIRTY); /* this should eventually include NR_UNSTABLE_NFS */ - *pwriteback = memcg_page_state(memcg, NR_WRITEBACK); + *pwriteback = memcg_exact_page_state(memcg, NR_WRITEBACK); *pfilepages = mem_cgroup_nr_lru_pages(memcg, (1 << LRU_INACTIVE_FILE) | (1 << LRU_ACTIVE_FILE)); *pheadroom = PAGE_COUNTER_MAX; _

6 years, 7 months

1
0
0 0

[patch 07/14] mm/huge_memory.c: fix modifying of page protection by insert_pfn_pmd()

by akpm＠linux-foundation.org

From: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.ibm.com> Subject: mm/huge_memory.c: fix modifying of page protection by insert_pfn_pmd() With some architectures like ppc64, set_pmd_at() cannot cope with a situation where there is already some (different) valid entry present. Use pmdp_set_access_flags() instead to modify the pfn which is built to deal with modifying existing PMD entries. This is similar to cae85cb8add3 ("mm/memory.c: fix modifying of page protection by insert_pfn()") We also do similar update w.r.t insert_pfn_pud eventhough ppc64 don't support pud pfn entries now. Without this patch we also see the below message in kernel log "BUG: non-zero pgtables_bytes on freeing mm:" Link: http://lkml.kernel.org/r/20190402115125.18803-1-aneesh.kumar@linux.ibm.com Signed-off-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com> Reported-by: Chandan Rajendra <chandan(a)linux.ibm.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) --- a/mm/huge_memory.c~mm-fix-modifying-of-page-protection-by-insert_pfn_pmd +++ a/mm/huge_memory.c @@ -755,6 +755,21 @@ static void insert_pfn_pmd(struct vm_are spinlock_t *ptl; ptl = pmd_lock(mm, pmd); + if (!pmd_none(*pmd)) { + if (write) { + if (pmd_pfn(*pmd) != pfn_t_to_pfn(pfn)) { + WARN_ON_ONCE(!is_huge_zero_pmd(*pmd)); + goto out_unlock; + } + entry = pmd_mkyoung(*pmd); + entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); + if (pmdp_set_access_flags(vma, addr, pmd, entry, 1)) + update_mmu_cache_pmd(vma, addr, pmd); + } + + goto out_unlock; + } + entry = pmd_mkhuge(pfn_t_pmd(pfn, prot)); if (pfn_t_devmap(pfn)) entry = pmd_mkdevmap(entry); @@ -766,11 +781,16 @@ static void insert_pfn_pmd(struct vm_are if (pgtable) { pgtable_trans_huge_deposit(mm, pmd, pgtable); mm_inc_nr_ptes(mm); + pgtable = NULL; } set_pmd_at(mm, addr, pmd, entry); update_mmu_cache_pmd(vma, addr, pmd); + +out_unlock: spin_unlock(ptl); + if (pgtable) + pte_free(mm, pgtable); } vm_fault_t vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr, @@ -821,6 +841,20 @@ static void insert_pfn_pud(struct vm_are spinlock_t *ptl; ptl = pud_lock(mm, pud); + if (!pud_none(*pud)) { + if (write) { + if (pud_pfn(*pud) != pfn_t_to_pfn(pfn)) { + WARN_ON_ONCE(!is_huge_zero_pud(*pud)); + goto out_unlock; + } + entry = pud_mkyoung(*pud); + entry = maybe_pud_mkwrite(pud_mkdirty(entry), vma); + if (pudp_set_access_flags(vma, addr, pud, entry, 1)) + update_mmu_cache_pud(vma, addr, pud); + } + goto out_unlock; + } + entry = pud_mkhuge(pfn_t_pud(pfn, prot)); if (pfn_t_devmap(pfn)) entry = pud_mkdevmap(entry); @@ -830,6 +864,8 @@ static void insert_pfn_pud(struct vm_are } set_pud_at(mm, addr, pud, entry); update_mmu_cache_pud(vma, addr, pud); + +out_unlock: spin_unlock(ptl); } _

6 years, 7 months

1
0
0 0

[patch 03/14] include/linux/bitrev.h: fix constant bitrev

by akpm＠linux-foundation.org

From: Arnd Bergmann <arnd(a)arndb.de> Subject: include/linux/bitrev.h: fix constant bitrev clang points out with hundreds of warnings that the bitrev macros have a problem with constant input: drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] u8 crc = bitrev8(data->val_status & 0x0F); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8' __constant_bitrev8(__x) : \ ~~~~~~~~~~~~~~~~~~~^~~~ include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8' u8 __x = x; \ ~~~ ^ Both the bitrev and the __constant_bitrev macros use an internal variable named __x, which goes horribly wrong when passing one to the other. The obvious fix is to rename one of the variables, so this adds an extra '_'. It seems we got away with this because - there are only a few drivers using bitrev macros - usually there are no constant arguments to those - when they are constant, they tend to be either 0 or (unsigned)-1 (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and give the correct result by pure chance. In fact, the only driver that I could find that gets different results with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver for fairly rare hardware (adding the maintainer to Cc for testing). Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Reviewed-by: Nick Desaulniers <ndesaulniers(a)google.com> Cc: Zhao Qiang <qiang.zhao(a)nxp.com> Cc: Yalin Wang <yalin.wang(a)sonymobile.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/bitrev.h | 46 +++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 23 deletions(-) --- a/include/linux/bitrev.h~bitrev-fix-constant-bitrev +++ a/include/linux/bitrev.h @@ -34,41 +34,41 @@ static inline u32 __bitrev32(u32 x) #define __constant_bitrev32(x) \ ({ \ - u32 __x = x; \ - __x = (__x >> 16) | (__x << 16); \ - __x = ((__x & (u32)0xFF00FF00UL) >> 8) | ((__x & (u32)0x00FF00FFUL) << 8); \ - __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \ - __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \ - __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \ - __x; \ + u32 ___x = x; \ + ___x = (___x >> 16) | (___x << 16); \ + ___x = ((___x & (u32)0xFF00FF00UL) >> 8) | ((___x & (u32)0x00FF00FFUL) << 8); \ + ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \ + ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \ + ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \ + ___x; \ }) #define __constant_bitrev16(x) \ ({ \ - u16 __x = x; \ - __x = (__x >> 8) | (__x << 8); \ - __x = ((__x & (u16)0xF0F0U) >> 4) | ((__x & (u16)0x0F0FU) << 4); \ - __x = ((__x & (u16)0xCCCCU) >> 2) | ((__x & (u16)0x3333U) << 2); \ - __x = ((__x & (u16)0xAAAAU) >> 1) | ((__x & (u16)0x5555U) << 1); \ - __x; \ + u16 ___x = x; \ + ___x = (___x >> 8) | (___x << 8); \ + ___x = ((___x & (u16)0xF0F0U) >> 4) | ((___x & (u16)0x0F0FU) << 4); \ + ___x = ((___x & (u16)0xCCCCU) >> 2) | ((___x & (u16)0x3333U) << 2); \ + ___x = ((___x & (u16)0xAAAAU) >> 1) | ((___x & (u16)0x5555U) << 1); \ + ___x; \ }) #define __constant_bitrev8x4(x) \ ({ \ - u32 __x = x; \ - __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \ - __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \ - __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \ - __x; \ + u32 ___x = x; \ + ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \ + ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \ + ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \ + ___x; \ }) #define __constant_bitrev8(x) \ ({ \ - u8 __x = x; \ - __x = (__x >> 4) | (__x << 4); \ - __x = ((__x & (u8)0xCCU) >> 2) | ((__x & (u8)0x33U) << 2); \ - __x = ((__x & (u8)0xAAU) >> 1) | ((__x & (u8)0x55U) << 1); \ - __x; \ + u8 ___x = x; \ + ___x = (___x >> 4) | (___x << 4); \ + ___x = ((___x & (u8)0xCCU) >> 2) | ((___x & (u8)0x33U) << 2); \ + ___x = ((___x & (u8)0xAAU) >> 1) | ((___x & (u8)0x55U) << 1); \ + ___x; \ }) #define bitrev32(x) \ _

6 years, 7 months

1
0
0 0

[patch 01/14] lib/string.c: implement a basic bcmp

by akpm＠linux-foundation.org

From: Nick Desaulniers <ndesaulniers(a)google.com> Subject: lib/string.c: implement a basic bcmp A recent optimization in Clang (r355672) lowers comparisons of the return value of memcmp against zero to comparisons of the return value of bcmp against zero. This helps some platforms that implement bcmp more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but an optimized implementation is in the works. This results in linkage failures for all targets with Clang due to the undefined symbol. For now, just implement bcmp as a tailcail to memcmp to unbreak the build. This routine can be further optimized in the future. Other ideas discussed: * A weak alias was discussed, but breaks for architectures that define their own implementations of memcmp since aliases to declarations are not permitted (only definitions). Arch-specific memcmp implementations typically declare memcmp in C headers, but implement them in assembly. * -ffreestanding also is used sporadically throughout the kernel. * -fno-builtin-bcmp doesn't work when doing LTO. Link: https://bugs.llvm.org/show_bug.cgi?id=41035 Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp Link: https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd1… Link: https://github.com/ClangBuiltLinux/linux/issues/416 Link: http://lkml.kernel.org/r/20190313211335.165605-1-ndesaulniers@google.com Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> Reported-by: Nathan Chancellor <natechancellor(a)gmail.com> Reported-by: Adhemerval Zanella <adhemerval.zanella(a)linaro.org> Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Suggested-by: James Y Knight <jyknight(a)google.com> Suggested-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Suggested-by: Nathan Chancellor <natechancellor(a)gmail.com> Suggested-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Acked-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Reviewed-by: Nathan Chancellor <natechancellor(a)gmail.com> Tested-by: Nathan Chancellor <natechancellor(a)gmail.com> Reviewed-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: David Laight <David.Laight(a)ACULAB.COM> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/string.h | 3 +++ lib/string.c | 20 ++++++++++++++++++++ 2 files changed, 23 insertions(+) --- a/include/linux/string.h~lib-stringc-implement-a-basic-bcmp +++ a/include/linux/string.h @@ -150,6 +150,9 @@ extern void * memscan(void *,int,__kerne #ifndef __HAVE_ARCH_MEMCMP extern int memcmp(const void *,const void *,__kernel_size_t); #endif +#ifndef __HAVE_ARCH_BCMP +extern int bcmp(const void *,const void *,__kernel_size_t); +#endif #ifndef __HAVE_ARCH_MEMCHR extern void * memchr(const void *,int,__kernel_size_t); #endif --- a/lib/string.c~lib-stringc-implement-a-basic-bcmp +++ a/lib/string.c @@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, con EXPORT_SYMBOL(memcmp); #endif +#ifndef __HAVE_ARCH_BCMP +/** + * bcmp - returns 0 if and only if the buffers have identical contents. + * @a: pointer to first buffer. + * @b: pointer to second buffer. + * @len: size of buffers. + * + * The sign or magnitude of a non-zero return value has no particular + * meaning, and architectures may implement their own more efficient bcmp(). So + * while this particular implementation is a simple (tail) call to memcmp, do + * not rely on anything but whether the return value is zero or non-zero. + */ +#undef bcmp +int bcmp(const void *a, const void *b, size_t len) +{ + return memcmp(a, b, len); +} +EXPORT_SYMBOL(bcmp); +#endif + #ifndef __HAVE_ARCH_MEMSCAN /** * memscan - Find a character in an area of memory. _

6 years, 7 months

1
0
0 0

stable/linux-4.19.y boot: 53 boots: 5 failed, 46 passed with 2 untried/unknown (v4.19.34)

by kernelci.org bot

stable/linux-4.19.y boot: 53 boots: 5 failed, 46 passed with 2 untried/unknown (v4.19.34) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.19.y/kernel/v4.19.3… Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.19.y/kernel/v4.19.34/ Tree: stable Branch: linux-4.19.y Git Describe: v4.19.34 Git Commit: 4d552acf337038028f7e2f63a927afb7adf65fc1 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 30 unique boards, 14 SoC families, 9 builds out of 206 Boot Regressions Detected: arm64: defconfig: gcc-7: meson-gxbb-nanopi-k2: lab-baylibre: new failure (last pass: v4.19.33) meson-gxbb-p200: lab-baylibre: new failure (last pass: v4.19.33) meson-gxl-s805x-p241: lab-baylibre: new failure (last pass: v4.19.33) meson-gxl-s905x-khadas-vim: lab-baylibre: new failure (last pass: v4.19.33) meson-gxl-s905x-libretech-cc: lab-baylibre: new failure (last pass: v4.19.33) Boot Failures Detected: arm64: defconfig: gcc-7: meson-gxbb-nanopi-k2: 1 failed lab meson-gxbb-p200: 1 failed lab meson-gxl-s805x-p241: 1 failed lab meson-gxl-s905x-khadas-vim: 1 failed lab meson-gxl-s905x-libretech-cc: 1 failed lab --- For more info write to <info(a)kernelci.org>

6 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror