Hi KP,

I love your patch! Perhaps something to improve:

[auto build test WARNING on bpf-next/master]

url:    
https://github.com/0day-ci/linux/commits/KP-Singh/Generalizing-bpf_local_storage/20200709-181906
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: s390-randconfig-s032-20200719 (attached as .config)
compiler: s390-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-49-g707c5017-dirty
        # 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=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <l...@intel.com>


sparse warnings: (new ones prefixed by >>)

>> kernel/bpf/bpf_local_storage.c:237:16: sparse: sparse: non size-preserving 
>> integer to pointer cast

vim +237 kernel/bpf/bpf_local_storage.c

   221  
   222  /* Publish local_storage to the address.  This is used because we are 
already
   223   * in a region where we cannot grab a lock on the object owning the 
storage (
   224   * (e.g sk->sk_lock). Hence, atomic ops is used.
   225   *
   226   * From now on, the addr pointer is protected
   227   * by the local_storage->lock.  Hence, upon freeing,
   228   * the local_storage->lock must be held before unlinking the storage 
from the
   229   * owner.
   230   */
   231  int bpf_local_storage_publish(struct bpf_local_storage_elem 
*first_selem,
   232                                struct bpf_local_storage **addr,
   233                                struct bpf_local_storage *curr)
   234  {
   235          struct bpf_local_storage *prev;
   236  
 > 237          prev = cmpxchg(addr, NULL, curr);
   238          if (unlikely(prev)) {
   239                  /* Note that even first_selem was linked to smap's
   240                   * bucket->list, first_selem can be freed immediately
   241                   * (instead of kfree_rcu) because
   242                   * bpf_local_storage_map_free() does a
   243                   * synchronize_rcu() before walking the bucket->list.
   244                   * Hence, no one is accessing selem from the
   245                   * bucket->list under rcu_read_lock().
   246                   */
   247                  bpf_selem_unlink_map(first_selem);
   248                  return -EAGAIN;
   249          }
   250  
   251          return 0;
   252  }
   253  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Attachment: .config.gz
Description: application/gzip

Reply via email to