| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <202505261743.n48LBgti-lkp@intel.com>
Date: Mon, 26 May 2025 17:49:36 +0800
From: kernel test robot <lkp@...el.com>
To: yangtengteng@...edance.com, edumazet@...gle.com, kuniyu@...zon.com,
pabeni@...hat.com, willemb@...gle.com, davem@...emloft.net,
kuba@...nel.org, horms@...nel.org, wuyun.abel@...edance.com,
shakeel.butt@...ux.dev
Cc: llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
zhoufeng.zf@...edance.com, wangdongdong.6@...edance.com,
zhangrui.rod@...edance.com, yangzhenze@...edance.com,
yangtengteng@...edance.com
Subject: Re: [PATCH net-next] Fix sock_exceed_buf_limit not being triggered
in __sk_mem_raise_allocated
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/yangtengteng-bytedance-com/Fix-sock_exceed_buf_limit-not-being-triggered-in-__sk_mem_raise_allocated/20250526-144725
base: net-next/main
patch link: https://lore.kernel.org/r/20250526064619.5412-1-yangtengteng%40bytedance.com
patch subject: [PATCH net-next] Fix sock_exceed_buf_limit not being triggered in __sk_mem_raise_allocated
config: i386-buildonly-randconfig-002-20250526 (https://download.01.org/0day-ci/archive/20250526/202505261743.n48LBgti-lkp@intel.com/config)
compiler: clang version 20.1.2 (https://github.com/llvm/llvm-project 58df0ef89dd64126512e4ee27b4ac3fd8ddf6247)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250526/202505261743.n48LBgti-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@...el.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505261743.n48LBgti-lkp@intel.com/
All errors (new ones prefixed by >>):
>> net/core/sock.c:3284:67: error: expected ')'
3284 | charged = mem_cgroup_charge_skmem(memcg, amt, gfp_memcg_charge();
| ^
net/core/sock.c:3284:36: note: to match this '('
3284 | charged = mem_cgroup_charge_skmem(memcg, amt, gfp_memcg_charge();
| ^
1 error generated.
vim +3284 net/core/sock.c
3257
3258 /**
3259 * __sk_mem_raise_allocated - increase memory_allocated
3260 * @sk: socket
3261 * @size: memory size to allocate
3262 * @amt: pages to allocate
3263 * @kind: allocation type
3264 *
3265 * Similar to __sk_mem_schedule(), but does not update sk_forward_alloc.
3266 *
3267 * Unlike the globally shared limits among the sockets under same protocol,
3268 * consuming the budget of a memcg won't have direct effect on other ones.
3269 * So be optimistic about memcg's tolerance, and leave the callers to decide
3270 * whether or not to raise allocated through sk_under_memory_pressure() or
3271 * its variants.
3272 */
3273 int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)
3274 {
3275 struct mem_cgroup *memcg = mem_cgroup_sockets_enabled ? sk->sk_memcg : NULL;
3276 struct proto *prot = sk->sk_prot;
3277 bool charged = true;
3278 long allocated;
3279
3280 sk_memory_allocated_add(sk, amt);
3281 allocated = sk_memory_allocated(sk);
3282
3283 if (memcg) {
> 3284 charged = mem_cgroup_charge_skmem(memcg, amt, gfp_memcg_charge();
3285 if (!charged)
3286 goto suppress_allocation;
3287 }
3288
3289 /* Under limit. */
3290 if (allocated <= sk_prot_mem_limits(sk, 0)) {
3291 sk_leave_memory_pressure(sk);
3292 return 1;
3293 }
3294
3295 /* Under pressure. */
3296 if (allocated > sk_prot_mem_limits(sk, 1))
3297 sk_enter_memory_pressure(sk);
3298
3299 /* Over hard limit. */
3300 if (allocated > sk_prot_mem_limits(sk, 2))
3301 goto suppress_allocation;
3302
3303 /* Guarantee minimum buffer size under pressure (either global
3304 * or memcg) to make sure features described in RFC 7323 (TCP
3305 * Extensions for High Performance) work properly.
3306 *
3307 * This rule does NOT stand when exceeds global or memcg's hard
3308 * limit, or else a DoS attack can be taken place by spawning
3309 * lots of sockets whose usage are under minimum buffer size.
3310 */
3311 if (kind == SK_MEM_RECV) {
3312 if (atomic_read(&sk->sk_rmem_alloc) < sk_get_rmem0(sk, prot))
3313 return 1;
3314
3315 } else { /* SK_MEM_SEND */
3316 int wmem0 = sk_get_wmem0(sk, prot);
3317
3318 if (sk->sk_type == SOCK_STREAM) {
3319 if (sk->sk_wmem_queued < wmem0)
3320 return 1;
3321 } else if (refcount_read(&sk->sk_wmem_alloc) < wmem0) {
3322 return 1;
3323 }
3324 }
3325
3326 if (sk_has_memory_pressure(sk)) {
3327 u64 alloc;
3328
3329 /* The following 'average' heuristic is within the
3330 * scope of global accounting, so it only makes
3331 * sense for global memory pressure.
3332 */
3333 if (!sk_under_global_memory_pressure(sk))
3334 return 1;
3335
3336 /* Try to be fair among all the sockets under global
3337 * pressure by allowing the ones that below average
3338 * usage to raise.
3339 */
3340 alloc = sk_sockets_allocated_read_positive(sk);
3341 if (sk_prot_mem_limits(sk, 2) > alloc *
3342 sk_mem_pages(sk->sk_wmem_queued +
3343 atomic_read(&sk->sk_rmem_alloc) +
3344 sk->sk_forward_alloc))
3345 return 1;
3346 }
3347
3348 suppress_allocation:
3349
3350 if (kind == SK_MEM_SEND && sk->sk_type == SOCK_STREAM) {
3351 sk_stream_moderate_sndbuf(sk);
3352
3353 /* Fail only if socket is _under_ its sndbuf.
3354 * In this case we cannot block, so that we have to fail.
3355 */
3356 if (sk->sk_wmem_queued + size >= sk->sk_sndbuf) {
3357 /* Force charge with __GFP_NOFAIL */
3358 if (memcg && !charged) {
3359 mem_cgroup_charge_skmem(memcg, amt,
3360 gfp_memcg_charge() | __GFP_NOFAIL);
3361 }
3362 return 1;
3363 }
3364 }
3365
3366 if (kind == SK_MEM_SEND || (kind == SK_MEM_RECV && charged))
3367 trace_sock_exceed_buf_limit(sk, prot, allocated, kind);
3368
3369 sk_memory_allocated_sub(sk, amt);
3370
3371 if (memcg && charged)
3372 mem_cgroup_uncharge_skmem(memcg, amt);
3373
3374 return 0;
3375 }
3376
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Powered by blists - more mailing lists