drivers/crypto/sa2ul.c:432:1: warning: the frame size of 1076 bytes is larger than 1024 bytes
by kernel test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 4b6c093e21d36bede0fd88fd0aeb3b03647260e4
commit: d2c8ac187fc922e73930a1b2f6a211e27f595d01 crypto: sa2ul - Add AEAD algorithm support
date: 3 weeks ago
config: arc-randconfig-r023-20200816 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d2c8ac187fc922e73930a1b2f6a211e27f595d01
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
All warnings (new ones prefixed by >>):
In file included from include/linux/device.h:15,
from include/linux/dmaengine.h:8,
from drivers/crypto/sa2ul.c:12:
drivers/crypto/sa2ul.c: In function 'sa_sha_init':
drivers/crypto/sa2ul.c:1486:33: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1486 | crypto_ahash_digestsize(tfm), (u64)rctx);
| ^
include/linux/dev_printk.h:123:47: note: in definition of macro 'dev_dbg'
123 | dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
| ^~~~~~~~~~~
drivers/crypto/sa2ul.c: In function 'sa_prepare_iopads':
>> drivers/crypto/sa2ul.c:432:1: warning: the frame size of 1076 bytes is larger than 1024 bytes [-Wframe-larger-than=]
432 | }
| ^
vim +432 drivers/crypto/sa2ul.c
407
408 static void sa_prepare_iopads(struct algo_data *data, const u8 *key,
409 u16 key_sz, __be32 *ipad, __be32 *opad)
410 {
411 SHASH_DESC_ON_STACK(shash, data->ctx->shash);
412 int block_size = crypto_shash_blocksize(data->ctx->shash);
413 int digest_size = crypto_shash_digestsize(data->ctx->shash);
414 u8 k_ipad[SHA1_BLOCK_SIZE];
415 u8 k_opad[SHA1_BLOCK_SIZE];
416
417 shash->tfm = data->ctx->shash;
418
419 prepare_kiopad(k_ipad, k_opad, key, key_sz);
420
421 memzero_explicit(ipad, block_size);
422 memzero_explicit(opad, block_size);
423
424 crypto_shash_init(shash);
425 crypto_shash_update(shash, k_ipad, block_size);
426 sa_export_shash(shash, block_size, digest_size, ipad);
427
428 crypto_shash_init(shash);
429 crypto_shash_update(shash, k_opad, block_size);
430
431 sa_export_shash(shash, block_size, digest_size, opad);
> 432 }
433
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
6 months
drivers/crypto/chelsio/chcr_ktls.c:1078: undefined reference to `tls_get_record'
by kernel test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 86cfccb66937dd6cbf26ed619958b9e587e6a115
commit: 5a4b9fe7fece62ecab6fb28fe92362f83b41c33e cxgb4/chcr: complete record tx handling
date: 5 months ago
config: parisc-randconfig-r013-20200807 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5a4b9fe7fece62ecab6fb28fe92362f83b41c33e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
All errors (new ones prefixed by >>):
hppa-linux-ld: drivers/crypto/chelsio/chcr_ktls.o: in function `chcr_ktls_xmit':
>> drivers/crypto/chelsio/chcr_ktls.c:1078: undefined reference to `tls_get_record'
hppa-linux-ld: drivers/crypto/chelsio/chcr_ktls.o: in function `.LC10':
>> chcr_ktls.c:(.rodata.cst4+0x0): undefined reference to `tls_validate_xmit_skb'
vim +1078 drivers/crypto/chelsio/chcr_ktls.c
996
997 /* nic tls TX handler */
998 int chcr_ktls_xmit(struct sk_buff *skb, struct net_device *dev)
999 {
1000 struct chcr_ktls_ofld_ctx_tx *tx_ctx;
1001 struct tcphdr *th = tcp_hdr(skb);
1002 int data_len, qidx, ret = 0, mss;
1003 struct tls_record_info *record;
1004 struct chcr_ktls_info *tx_info;
1005 u32 tls_end_offset, tcp_seq;
1006 struct tls_context *tls_ctx;
1007 struct sk_buff *local_skb;
1008 int new_connection_state;
1009 struct sge_eth_txq *q;
1010 struct adapter *adap;
1011 unsigned long flags;
1012
1013 tcp_seq = ntohl(th->seq);
1014
1015 mss = skb_is_gso(skb) ? skb_shinfo(skb)->gso_size : skb->data_len;
1016
1017 /* check if we haven't set it for ktls offload */
1018 if (!skb->sk || !tls_is_sk_tx_device_offloaded(skb->sk))
1019 goto out;
1020
1021 tls_ctx = tls_get_ctx(skb->sk);
1022 if (unlikely(tls_ctx->netdev != dev))
1023 goto out;
1024
1025 tx_ctx = chcr_get_ktls_tx_context(tls_ctx);
1026 tx_info = tx_ctx->chcr_info;
1027
1028 if (unlikely(!tx_info))
1029 goto out;
1030
1031 /* check the connection state, we don't need to pass new connection
1032 * state, state machine will check and update the new state if it is
1033 * stuck due to responses not received from HW.
1034 * Start the tx handling only if state is KTLS_CONN_TX_READY.
1035 */
1036 new_connection_state = chcr_ktls_update_connection_state(tx_info, 0);
1037 if (new_connection_state != KTLS_CONN_TX_READY)
1038 goto out;
1039
1040 /* don't touch the original skb, make a new skb to extract each records
1041 * and send them separately.
1042 */
1043 local_skb = alloc_skb(0, GFP_KERNEL);
1044
1045 if (unlikely(!local_skb))
1046 return NETDEV_TX_BUSY;
1047
1048 adap = tx_info->adap;
1049 qidx = skb->queue_mapping;
1050 q = &adap->sge.ethtxq[qidx + tx_info->first_qset];
1051 cxgb4_reclaim_completed_tx(adap, &q->q, true);
1052 /* update tcb */
1053 ret = chcr_ktls_xmit_tcb_cpls(tx_info, q, ntohl(th->seq),
1054 ntohl(th->ack_seq),
1055 ntohs(th->window));
1056 if (ret) {
1057 dev_kfree_skb_any(local_skb);
1058 return NETDEV_TX_BUSY;
1059 }
1060
1061 /* copy skb contents into local skb */
1062 chcr_ktls_skb_copy(skb, local_skb);
1063
1064 /* go through the skb and send only one record at a time. */
1065 data_len = skb->data_len;
1066 /* TCP segments can be in received from host either complete or partial.
1067 * chcr_end_part_handler will handle cases if complete record or end
1068 * part of the record is received. Incase of partial end part of record,
1069 * we will send the complete record again.
1070 */
1071 do {
1072 int i;
1073
1074 cxgb4_reclaim_completed_tx(adap, &q->q, true);
1075 /* lock taken */
1076 spin_lock_irqsave(&tx_ctx->base.lock, flags);
1077 /* fetch the tls record */
> 1078 record = tls_get_record(&tx_ctx->base, tcp_seq,
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
6 months, 1 week
Re: [riscv:for-next 2/7] arch/riscv/kernel/setup.c:74:2: error: implicit declaration of function 'early_ioremap_setup'
by Rong Chen
Hi Atish,
We can reproduce this error if using the reproduce steps:
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3d109b0e0949bfd68cc00ffa9d78186fab037bc1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv
Best Regards,
Rong Chen
On 8/27/20 6:20 AM, Atish Patra wrote:
> I can't seem to reproduce this issue. I have an older version gcc
> though (8.2). I am surprised by the error as well we are already
> including the early_ioremap.h.
>
> --- a/arch/riscv/include/asm/Kbuild
> +++ b/arch/riscv/include/asm/Kbuild
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> +generic-y += early_ioremap.h
> generic-y += extable.h
> generic-y += flat.h
> generic-y += kvm_para.h
>
> On Wed, 2020-08-26 at 09:54 +0800, kernel test robot wrote:
>> tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git for-
>> next
>> head: f75fa0a51b8b544ebd0d03a74c6b04d9f6b95781
>> commit: 3d109b0e0949bfd68cc00ffa9d78186fab037bc1 [2/7] RISC-V: Add
>> early ioremap support
>> config: riscv-allyesconfig (attached as .config)
>> compiler: riscv64-linux-gcc (GCC) 9.3.0
>> reproduce (this is a W=1 build):
>> wget
>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>> -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout 3d109b0e0949bfd68cc00ffa9d78186fab037bc1
>> # save the attached .config to linux build tree
>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>> make.cross ARCH=riscv
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <lkp(a)intel.com>
>>
>> All errors (new ones prefixed by >>):
>>
>> arch/riscv/kernel/setup.c: In function 'setup_arch':
>>>> arch/riscv/kernel/setup.c:74:2: error: implicit declaration of
>>>> function 'early_ioremap_setup' [-Werror=implicit-function-
>>>> declaration]
>> 74 | early_ioremap_setup();
>> | ^~~~~~~~~~~~~~~~~~~
>> cc1: some warnings being treated as errors
>>
>> #
>> https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?i...
>> git remote add riscv
>> https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
>> git fetch --no-tags riscv for-next
>> git checkout 3d109b0e0949bfd68cc00ffa9d78186fab037bc1
>> vim +/early_ioremap_setup +74 arch/riscv/kernel/setup.c
>>
>> 63
>> 64 void __init setup_arch(char **cmdline_p)
>> 65 {
>> 66 parse_dtb();
>> 67 init_mm.start_code = (unsigned long) _stext;
>> 68 init_mm.end_code = (unsigned long) _etext;
>> 69 init_mm.end_data = (unsigned long) _edata;
>> 70 init_mm.brk = (unsigned long) _end;
>> 71
>> 72 *cmdline_p = boot_command_line;
>> 73
>> > 74 early_ioremap_setup();
>> 75 parse_early_param();
>> 76
>> 77 setup_bootmem();
>> 78 paging_init();
>> 79 #if IS_ENABLED(CONFIG_BUILTIN_DTB)
>> 80 unflatten_and_copy_device_tree();
>> 81 #else
>> 82 if (early_init_dt_verify(__va(dtb_early_pa)))
>> 83 unflatten_device_tree();
>> 84 else
>> 85 pr_err("No DTB found in kernel
>> mappings\n");
>> 86 #endif
>> 87
>>
>> ---
>> 0-DAY CI Kernel Test Service, Intel Corporation
>> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months
drivers/video/fbdev/core/fbcon.c:3509:8-16: WARNING: use scnprintf or sprintf
by kernel test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: fc80c51fd4b23ec007e88d4c688f2cac1b8648e7
commit: abfc19ff202d287742483e15fd478ddd6ada2187 coccinelle: api: add device_attr_show script
date: 6 days ago
config: parisc-randconfig-c003-20200810 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
coccinelle warnings: (new ones prefixed by >>)
>> drivers/video/fbdev/core/fbcon.c:3509:8-16: WARNING: use scnprintf or sprintf
drivers/video/fbdev/core/fbcon.c:3484:8-16: WARNING: use scnprintf or sprintf
--
>> drivers/tty/vt/vt.c:3820:8-16: WARNING: use scnprintf or sprintf
drivers/tty/vt/vt.c:3828:8-16: WARNING: use scnprintf or sprintf
Please review and possibly fold the followup patch.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months, 1 week
[PATCH] coccinelle: api: fix kobj_to_dev.cocci warnings
by Julia Lawall
From: kernel test robot <lkp(a)intel.com>
Use kobj_to_dev() instead of container_of()
Generated by: scripts/coccinelle/api/kobj_to_dev.cocci
Fixes: a2fc3718bc22 ("coccinelle: api: add kobj_to_dev.cocci script")
CC: Denis Efremov <efremov(a)linux.com>
Signed-off-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Julia Lawall <julia.lawall(a)inria.fr>
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux.git for-5.10
head: a2fc3718bc22e85378085568ecc5765fb28cabce
commit: a2fc3718bc22e85378085568ecc5765fb28cabce [3/3] coccinelle: api: add kobj_to_dev.cocci script
:::::: branch date: 5 days ago
:::::: commit date: 5 days ago
udlfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1457,7 +1457,7 @@ static ssize_t edid_show(
struct file *filp,
struct kobject *kobj, struct bin_attribute *a,
char *buf, loff_t off, size_t count) {
- struct device *fbdev = container_of(kobj, struct device, kobj);
+ struct device *fbdev = kobj_to_dev(kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dlfb = fb_info->par;
@@ -1479,7 +1479,7 @@ static ssize_t edid_store(
struct file *filp,
struct kobject *kobj, struct bin_attribute *a,
char *src, loff_t src_off, size_t src_size) {
- struct device *fbdev = container_of(kobj, struct device, kobj);
+ struct device *fbdev = kobj_to_dev(kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dlfb = fb_info->par;
int ret;
7 months, 1 week
Re: [linuxppc:next-test 70/80] /usr/bin/powerpc64-linux-gnu-ld: warning: discarding dynamic section .rela.opd
by Nick Desaulniers
On Thu, Aug 27, 2020 at 5:57 PM Alan Modra <amodra(a)gmail.com> wrote:
>
> On Thu, Aug 27, 2020 at 06:02:14PM +0200, Ulrich Weigand wrote:
> > Nick Desaulniers <ndesaulniers(a)google.com> wrote on 27.08.2020 14:52:36:
> >
> > > > > All warnings (new ones prefixed by >>):
> > > > >
> > > > >>> /usr/bin/powerpc64-linux-gnu-ld: warning: discarding dynamic
> > > section .rela.opd
> > > > >
> > > >
> > > > We have /DISCARD/ *(.rela*) in the VDSO linker scripts.
Indeed, I see that in arch/powerpc/kernel/vdso64/vdso64.lds.S. Kees,
Fangrui, does `.rela*` not match `.rela.opd`? That doesn't sound
right. Unless it's not the vdso link that's producing the warning? I
guess the warning is from GNU BFD, not LLD. Maybe the warning is
coming from linking a different object file that doesn't use the same
linker script, or perhaps the `-T` argument is being dropped?
> > > >
> > > > What is going on here with clang ?
This warning is from the linker flag --orphan-handling=warn. It's
been very handy for us to find bugs for other architectures and Kees
has been working on a large series to use it in arm, arm64, and x86.
So the general question is, should we keep the section or discard it,
or should it not be produced in the first place?
> > >
> > > Looks like .rela.opd was maybe synthesized. cc Dr. Weigand, whos name
> > > shows up on llvm/test/MC/PowerPC/ppc64-relocs-01.s, which is the only
> > > hit I get in the codebase of `opd` (at least for tests, still looking
> > > to see if ".opd" gets appended somewhere.
> >
> > Well, this is the old ELFv1 ABI for big-endian PowerPC, which uses
> > function descriptors, which reside in the .opd section. These are
> > emitted by LLVM in the PPCLinuxAsmPrinter::emitFunctionEntryLabel
Ah, "official procedure descriptors" -> opd. Christophe, do we expect
the vdso to be ELFv1 ABI? This code in LLVM has two other cases:
1. ppc32
2. ELFv2
If it should not be ELFv1, then something may be amiss in kbuild when
building for Clang; maybe Clang has a different command line option
for v2 and there's a cc-option check that's silently failing. Maybe
clang has a different implicit default than gcc (which should be fixed
in clang if so).
The log didn't provide enough info if linking the vdso was the
problem. computeTargetABI() in
llvm/lib/Target/PowerPC/PPCTargetMachine.cpp seems to imply that ppc64
(big endian) always uses elfv1, unless you specify a machine that
starts with "elfv2" in the ABI.
Christophe, did you test your series for big endian and little endian?
Maybe just an issue for big endian?
> > section, and they usually do require relocations since the function
> > descriptor contains the address of the function text (however those
> > relocations should be resolved during final link). I don't think
> > there should be much difference between GCC and LLVM in how those
> > are handled.
>
> .opd can only be resolved at link time when creating fixed position
> executables. .opd does need dynamic relocs in PIEs or shared
> libraries.
>
> Kernel VDSO is rather special though, and I'm not up to speed with
> whatever hackery the kernel folk use to create it and/or relocate it
> when the kernel is relocated. Quite possibly the warning should just
> be ignored.
I'm not sure if the kernel does relocations upon vdso load.
--
Thanks,
~Nick Desaulniers
7 months, 2 weeks
include/asm-generic/qspinlock.h:94:9: sparse: sparse: context imbalance in '__msm_console_write' - unexpected unlock
by kernel test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 005c53447a63cbce10de37406975a34d7bdc8704
commit: 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e tty: serial: msm_serial: Fix lockup for sysrq and oops
date: 9 months ago
config: arm64-randconfig-s031-20200829 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
sparse warnings: (new ones prefixed by >>)
drivers/tty/serial/msm_serial.c:736:25: sparse: sparse: context imbalance in 'msm_handle_rx_dm' - unexpected unlock
drivers/tty/serial/msm_serial.c:802:28: sparse: sparse: context imbalance in 'msm_handle_rx' - unexpected unlock
drivers/tty/serial/msm_serial.c:1100:12: sparse: sparse: context imbalance in 'msm_set_baud_rate' - unexpected unlock
drivers/tty/serial/msm_serial.c: note: in included file (through arch/arm64/include/generated/asm/qspinlock.h, arch/arm64/include/asm/spinlock.h, include/linux/spinlock.h, ...):
>> include/asm-generic/qspinlock.h:94:9: sparse: sparse: context imbalance in '__msm_console_write' - unexpected unlock
# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e
vim +/__msm_console_write +94 include/asm-generic/qspinlock.h
a33fda35e3a765 Waiman Long 2015-04-24 83
a33fda35e3a765 Waiman Long 2015-04-24 84 #ifndef queued_spin_unlock
a33fda35e3a765 Waiman Long 2015-04-24 85 /**
a33fda35e3a765 Waiman Long 2015-04-24 86 * queued_spin_unlock - release a queued spinlock
a33fda35e3a765 Waiman Long 2015-04-24 87 * @lock : Pointer to queued spinlock structure
a33fda35e3a765 Waiman Long 2015-04-24 88 */
a33fda35e3a765 Waiman Long 2015-04-24 89 static __always_inline void queued_spin_unlock(struct qspinlock *lock)
a33fda35e3a765 Waiman Long 2015-04-24 90 {
a33fda35e3a765 Waiman Long 2015-04-24 91 /*
ca50e426f96c90 Pan Xinhui 2016-06-03 92 * unlock() needs release semantics:
a33fda35e3a765 Waiman Long 2015-04-24 93 */
626e5fbc143589 Will Deacon 2018-04-26 @94 smp_store_release(&lock->locked, 0);
a33fda35e3a765 Waiman Long 2015-04-24 95 }
a33fda35e3a765 Waiman Long 2015-04-24 96 #endif
a33fda35e3a765 Waiman Long 2015-04-24 97
:::::: The code at line 94 was first introduced by commit
:::::: 626e5fbc14358901ddaa90ce510e0fbeab310432 locking/qspinlock: Use smp_store_release() in queued_spin_unlock()
:::::: TO: Will Deacon <will.deacon(a)arm.com>
:::::: CC: Ingo Molnar <mingo(a)kernel.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months, 2 weeks