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

[PATCH 4.19] cgroup/cpuset: Wake up cpuset_attach_wq tasks in cpuset_cancel_attach()

by Waiman Long

commit ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 upstream. After a successful cpuset_can_attach() call which increments the attach_in_progress flag, either cpuset_cancel_attach() or cpuset_attach() will be called later. In cpuset_attach(), tasks in cpuset_attach_wq, if present, will be woken up at the end. That is not the case in cpuset_cancel_attach(). So missed wakeup is possible if the attach operation is somehow cancelled. Fix that by doing the wakeup in cpuset_cancel_attach() as well. Fixes: e44193d39e8d ("cpuset: let hotplug propagation work wait for task attaching") Signed-off-by: Waiman Long <longman(a)redhat.com> Reviewed-by: Michal Koutný <mkoutny(a)suse.com> Cc: stable(a)vger.kernel.org # v3.11+ Signed-off-by: Tejun Heo <tj(a)kernel.org> --- kernel/cgroup/cpuset.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index c6d412cebc43..3067d3e5a51d 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -1504,7 +1504,9 @@ static void cpuset_cancel_attach(struct cgroup_taskset *tset) cs = css_cs(css); mutex_lock(&cpuset_mutex); - css_cs(css)->attach_in_progress--; + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); mutex_unlock(&cpuset_mutex); } -- 2.31.1

2 years, 8 months

1
0
0 0

Request to pick "ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size"

by Daniel Golle

Hi, please pick 1e020e1b96afd ("ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size") from linux-next to stable trees. The commit fixes a problem with another recent commit 1b42b1a36fc94 ("ubi: ensure that VID header offset ... size") which has already made it to stable trees and thereby broke attaching UBI and hence renders devices unbootable. As a temporary fix I have applied this patch downstream in OpenWrt. Thank you! Best regards Daniel ----- Forwarded message from Daniel Golle <daniel(a)makrotopia.org> ----- Date: Sat, 15 Apr 2023 00:12:46 +0100 From: Daniel Golle <daniel(a)makrotopia.org> To: Richard Weinberger <richard(a)nod.at> Cc: Miquel Raynal <miquel.raynal(a)bootlin.com>, chengzhihao1 <chengzhihao1(a)huawei.com>, Nicolas Schichan <nschichan(a)freebox.fr>, George Kennedy <george.kennedy(a)oracle.com>, linux-kernel <linux-kernel(a)vger.kernel.org>, linux-mtd <linux-mtd(a)lists.infradead.org>, Sascha Hauer <s.hauer(a)pengutronix.de>, yi zhang <yi.zhang(a)huawei.com> Subject: Re: [PATCH -next v3] ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size Hi Richard, On Wed, Mar 29, 2023 at 11:33:40PM +0200, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > Von: "Miquel Raynal" <miquel.raynal(a)bootlin.com> > >> Thanks for testing. > >> > >> > Tested-by: Nicolas Schichan <nschichan(a)freebox.fr> > > > > Same here. > > > > Tested-by: Miquel Raynal <miquel.raynal(a)bootlin.com> # v5.10, v4.19 > > Applied to next, PR will follow soon. As stable linux trees are affected I wonder when this will hit linux-stable, ie. will it be part of 5.15.108, for example? Cheers Daniel ----- End forwarded message -----

2 years, 8 months

3
5
0 0

[PATCH] drm/amd/display: fix flickering caused by S/G mode

by Hamza Mahfooz

Currently, we allow the framebuffer for a given plane to move between memory domains, however when that happens it causes the screen to flicker, it is even possible for the framebuffer to change memory domains on every plane update (causing a continuous flicker effect). So, to fix this, don't perform an immediate flip in the aforementioned case. Cc: stable(a)vger.kernel.org Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)") Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 ++++++++++++++++++- 1 file changed, 39 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index da3045fdcb6d..9a4e7408384a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct drm_atomic_state *state) amdgpu_dm_plane_handle_cursor_update(plane, old_plane_state); } +static inline uint32_t get_mem_type(struct amdgpu_device *adev, + struct drm_gem_object *obj, + bool check_domain) +{ + struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj); + uint32_t mem_type; + + if (unlikely(amdgpu_bo_reserve(abo, true))) + return 0; + + if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1))) + goto err; + + if (check_domain && + amdgpu_display_supported_domains(adev, abo->flags) != + (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) + goto err; + + mem_type = abo->tbo.resource->mem_type; + amdgpu_bo_unreserve(abo); + + return mem_type; + +err: + amdgpu_bo_unreserve(abo); + return 0; +} + static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, struct dc_state *dc_state, struct drm_device *dev, @@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc)); int planes_count = 0, vpos, hpos; unsigned long flags; + uint32_t mem_type; u32 target_vblank, last_flip_vblank; bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state); bool cursor_update = false; @@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, } } + mem_type = get_mem_type(dm->adev, old_plane_state->fb->obj[0], + true); + /* * Only allow immediate flips for fast updates that don't - * change FB pitch, DCC state, rotation or mirroing. + * change memory domain, FB pitch, DCC state, rotation or + * mirroring. */ bundle->flip_addrs[planes_count].flip_immediate = crtc->state->async_flip && - acrtc_state->update_type == UPDATE_TYPE_FAST; + acrtc_state->update_type == UPDATE_TYPE_FAST && + (!mem_type || (mem_type && get_mem_type(dm->adev, + fb->obj[0], + false) == + mem_type)); timestamp_ns = ktime_get_ns(); bundle->flip_addrs[planes_count].flip_timestamp_in_us = div_u64(timestamp_ns, 1000); -- 2.40.0

2 years, 8 months

4
8
0 0

FAILED: patch "[PATCH] cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork()" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x eee87853794187f6adbe19533ed79c8b44b36a91 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041705-gauze-elated-d7c7@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: eee878537941 ("cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods") 42a11bf5c543 ("cgroup/cpuset: Make cpuset_fork() handle CLONE_INTO_CGROUP properly") 18f9a4d47527 ("cgroup/cpuset: Skip spread flags update on v2") e2d59900d936 ("cgroup/cpuset: Allow no-task partition to have empty cpuset.cpus.effective") 18065ebe9b33 ("cgroup/cpuset: Miscellaneous cleanups & add helper functions") f9da322e864e ("cgroup: cleanup comments") 8ca1b5a49885 ("mm/page_alloc: detect allocation forbidden by cpuset and bail out early") b94f9ac79a73 ("cgroup/cpuset: Change references of cpuset_mutex to cpuset_rwsem") 69dc8010b8fc ("Merge branch 'for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From eee87853794187f6adbe19533ed79c8b44b36a91 Mon Sep 17 00:00:00 2001 From: Waiman Long <longman(a)redhat.com> Date: Tue, 11 Apr 2023 09:35:59 -0400 Subject: [PATCH] cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In the case of CLONE_INTO_CGROUP, not all cpusets are ready to accept new tasks. It is too late to check that in cpuset_fork(). So we need to add the cpuset_can_fork() and cpuset_cancel_fork() methods to pre-check it before we can allow attachment to a different cpuset. We also need to set the attach_in_progress flag to alert other code that a new task is going to be added to the cpuset. Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups") Suggested-by: Michal Koutný <mkoutny(a)suse.com> Signed-off-by: Waiman Long <longman(a)redhat.com> Cc: stable(a)vger.kernel.org # v5.7+ Signed-off-by: Tejun Heo <tj(a)kernel.org> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 2ccfae74acf9..166a45019f66 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -2453,6 +2453,20 @@ static int fmeter_getrate(struct fmeter *fmp) static struct cpuset *cpuset_attach_old_cs; +/* + * Check to see if a cpuset can accept a new task + * For v1, cpus_allowed and mems_allowed can't be empty. + * For v2, effective_cpus can't be empty. + * Note that in v1, effective_cpus = cpus_allowed. + */ +static int cpuset_can_attach_check(struct cpuset *cs) +{ + if (cpumask_empty(cs->effective_cpus) || + (!is_in_v2_mode() && nodes_empty(cs->mems_allowed))) + return -ENOSPC; + return 0; +} + /* Called by cgroups to determine if a cpuset is usable; cpuset_rwsem held */ static int cpuset_can_attach(struct cgroup_taskset *tset) { @@ -2467,16 +2481,9 @@ static int cpuset_can_attach(struct cgroup_taskset *tset) percpu_down_write(&cpuset_rwsem); - /* allow moving tasks into an empty cpuset if on default hierarchy */ - ret = -ENOSPC; - if (!is_in_v2_mode() && - (cpumask_empty(cs->cpus_allowed) || nodes_empty(cs->mems_allowed))) - goto out_unlock; - - /* - * Task cannot be moved to a cpuset with empty effective cpus. - */ - if (cpumask_empty(cs->effective_cpus)) + /* Check to see if task is allowed in the cpuset */ + ret = cpuset_can_attach_check(cs); + if (ret) goto out_unlock; cgroup_taskset_for_each(task, css, tset) { @@ -2493,7 +2500,6 @@ static int cpuset_can_attach(struct cgroup_taskset *tset) * changes which zero cpus/mems_allowed. */ cs->attach_in_progress++; - ret = 0; out_unlock: percpu_up_write(&cpuset_rwsem); return ret; @@ -3264,6 +3270,68 @@ static void cpuset_bind(struct cgroup_subsys_state *root_css) percpu_up_write(&cpuset_rwsem); } +/* + * In case the child is cloned into a cpuset different from its parent, + * additional checks are done to see if the move is allowed. + */ +static int cpuset_can_fork(struct task_struct *task, struct css_set *cset) +{ + struct cpuset *cs = css_cs(cset->subsys[cpuset_cgrp_id]); + bool same_cs; + int ret; + + rcu_read_lock(); + same_cs = (cs == task_cs(current)); + rcu_read_unlock(); + + if (same_cs) + return 0; + + lockdep_assert_held(&cgroup_mutex); + percpu_down_write(&cpuset_rwsem); + + /* Check to see if task is allowed in the cpuset */ + ret = cpuset_can_attach_check(cs); + if (ret) + goto out_unlock; + + ret = task_can_attach(task, cs->effective_cpus); + if (ret) + goto out_unlock; + + ret = security_task_setscheduler(task); + if (ret) + goto out_unlock; + + /* + * Mark attach is in progress. This makes validate_change() fail + * changes which zero cpus/mems_allowed. + */ + cs->attach_in_progress++; +out_unlock: + percpu_up_write(&cpuset_rwsem); + return ret; +} + +static void cpuset_cancel_fork(struct task_struct *task, struct css_set *cset) +{ + struct cpuset *cs = css_cs(cset->subsys[cpuset_cgrp_id]); + bool same_cs; + + rcu_read_lock(); + same_cs = (cs == task_cs(current)); + rcu_read_unlock(); + + if (same_cs) + return; + + percpu_down_write(&cpuset_rwsem); + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); +} + /* * Make sure the new task conform to the current state of its parent, * which could have been changed by cpuset just after it inherits the @@ -3292,6 +3360,11 @@ static void cpuset_fork(struct task_struct *task) percpu_down_write(&cpuset_rwsem); guarantee_online_mems(cs, &cpuset_attach_nodemask_to); cpuset_attach_task(cs, task); + + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); } @@ -3305,6 +3378,8 @@ struct cgroup_subsys cpuset_cgrp_subsys = { .attach = cpuset_attach, .post_attach = cpuset_post_attach, .bind = cpuset_bind, + .can_fork = cpuset_can_fork, + .cancel_fork = cpuset_cancel_fork, .fork = cpuset_fork, .legacy_cftypes = legacy_files, .dfl_cftypes = dfl_files,

2 years, 8 months

2
1
0 0

[Regression] Cannot overwrite VID header offset any more [Was: [PATCH] ubi: ensure that VID header offset + VID header size <= alloc, size]

by Uwe Kleine-König

Hello, On Tue, Nov 15, 2022 at 10:14:44AM -0500, George Kennedy wrote: > Ensure that the VID header offset + VID header size does not exceed > the allocated area to avoid slab OOB. > > BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline] > BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] > BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197 > Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555 > > CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W > 6.0.0-1868 #1 > Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 > 04/01/2014 > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 > print_address_description mm/kasan/report.c:317 [inline] > print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433 > kasan_report+0xa7/0x11b mm/kasan/report.c:495 > crc32_body lib/crc32.c:111 [inline] > crc32_le_generic lib/crc32.c:179 [inline] > crc32_le_base+0x58c/0x626 lib/crc32.c:197 > ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067 > create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 > create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] > ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 > ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 > ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 > ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:870 [inline] > __se_sys_ioctl fs/ioctl.c:856 [inline] > __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0x0 > RIP: 0033:0x7f96d5cf753d > Code: > RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d > RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003 > RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 > R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000 > </TASK> > > Allocated by task 1555: > kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 > kasan_set_track mm/kasan/common.c:45 [inline] > set_alloc_info mm/kasan/common.c:437 [inline] > ____kasan_kmalloc mm/kasan/common.c:516 [inline] > __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525 > kasan_kmalloc include/linux/kasan.h:234 [inline] > __kmalloc+0x138/0x257 mm/slub.c:4429 > kmalloc include/linux/slab.h:605 [inline] > ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline] > create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 > create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] > ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 > ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 > ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 > ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:870 [inline] > __se_sys_ioctl fs/ioctl.c:856 [inline] > __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0x0 > > The buggy address belongs to the object at ffff88802bb36e00 > which belongs to the cache kmalloc-256 of size 256 > The buggy address is located 0 bytes to the right of > 256-byte region [ffff88802bb36e00, ffff88802bb36f00) > > The buggy address belongs to the physical page: > page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 > index:0x0 pfn:0x2bb36 > head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 > flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) > raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40 > raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff88802bb36e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffff88802bb36e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > ffff88802bb36f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ^ > ffff88802bb36f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff88802bb37000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== > > Fixes: 801c135ce73d ("UBI: Unsorted Block Images") > Reported-by: syzkaller <syzkaller(a)googlegroups.com> > Signed-off-by: George Kennedy <george.kennedy(a)oracle.com> > --- > drivers/mtd/ubi/build.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > index a32050fecabf..53aa4de6b963 100644 > --- a/drivers/mtd/ubi/build.c > +++ b/drivers/mtd/ubi/build.c > @@ -663,6 +663,12 @@ static int io_init(struct ubi_device *ubi, int max_beb_per1024) > ubi->ec_hdr_alsize = ALIGN(UBI_EC_HDR_SIZE, ubi->hdrs_min_io_size); > ubi->vid_hdr_alsize = ALIGN(UBI_VID_HDR_SIZE, ubi->hdrs_min_io_size); > + if (ubi->vid_hdr_offset && ((ubi->vid_hdr_offset + UBI_VID_HDR_SIZE) > > + ubi->vid_hdr_alsize)) { > + ubi_err(ubi, "VID header offset %d too large.", ubi->vid_hdr_offset); > + return -EINVAL; > + } > + This patch is in mainline as 1b42b1a36fc946f0d7088425b90d491b4257ca3e, and backported to various stable releases. For me this breaks ubiattach -m 0 -O 2048 I think the check ubi->vid_hdr_offset + UBI_VID_HDR_SIZE > ubi->vid_hdr_alsize is wrong. Without -O passed to ubiattach (and dynamic debug enabled) I get: [ 5294.936762] UBI DBG gen (pid 9619): sizeof(struct ubi_ainf_peb) 56 [ 5294.936769] UBI DBG gen (pid 9619): sizeof(struct ubi_wl_entry) 32 [ 5294.936774] UBI DBG gen (pid 9619): min_io_size 2048 [ 5294.936779] UBI DBG gen (pid 9619): max_write_size 2048 [ 5294.936783] UBI DBG gen (pid 9619): hdrs_min_io_size 512 [ 5294.936787] UBI DBG gen (pid 9619): ec_hdr_alsize 512 [ 5294.936791] UBI DBG gen (pid 9619): vid_hdr_alsize 512 [ 5294.936796] UBI DBG gen (pid 9619): vid_hdr_offset 512 [ 5294.936800] UBI DBG gen (pid 9619): vid_hdr_aloffset 512 [ 5294.936804] UBI DBG gen (pid 9619): vid_hdr_shift 0 [ 5294.936808] UBI DBG gen (pid 9619): leb_start 2048 [ 5294.936812] UBI DBG gen (pid 9619): max_erroneous 409 So the check would only pass for vid_hdr_offset <= 512 - UBI_VID_HDR_SIZE; note that even specifying the default value 512 (i.e. ubiattach -m 0 -O 512 ) fails the check. A less strong check would be: diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 0904eb40c95f..69c28a862430 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -666,8 +666,8 @@ static int io_init(struct ubi_device *ubi, int max_beb_per1024) ubi->ec_hdr_alsize = ALIGN(UBI_EC_HDR_SIZE, ubi->hdrs_min_io_size); ubi->vid_hdr_alsize = ALIGN(UBI_VID_HDR_SIZE, ubi->hdrs_min_io_size); - if (ubi->vid_hdr_offset && ((ubi->vid_hdr_offset + UBI_VID_HDR_SIZE) > - ubi->vid_hdr_alsize)) { + if (ubi->vid_hdr_offset && + ubi->vid_hdr_offset + UBI_VID_HDR_SIZE > ubi->peb_size) { ubi_err(ubi, "VID header offset %d too large.", ubi->vid_hdr_offset); return -EINVAL; } But I'm unsure if this would be too lax?! Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |

2 years, 8 months

2
2
0 0

FAILED: patch "[PATCH] cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork()" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x eee87853794187f6adbe19533ed79c8b44b36a91 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041703-wildland-privacy-e6d6@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: eee878537941 ("cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods") 42a11bf5c543 ("cgroup/cpuset: Make cpuset_fork() handle CLONE_INTO_CGROUP properly") 18f9a4d47527 ("cgroup/cpuset: Skip spread flags update on v2") e2d59900d936 ("cgroup/cpuset: Allow no-task partition to have empty cpuset.cpus.effective") 18065ebe9b33 ("cgroup/cpuset: Miscellaneous cleanups & add helper functions") f9da322e864e ("cgroup: cleanup comments") 8ca1b5a49885 ("mm/page_alloc: detect allocation forbidden by cpuset and bail out early") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From eee87853794187f6adbe19533ed79c8b44b36a91 Mon Sep 17 00:00:00 2001 From: Waiman Long <longman(a)redhat.com> Date: Tue, 11 Apr 2023 09:35:59 -0400 Subject: [PATCH] cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In the case of CLONE_INTO_CGROUP, not all cpusets are ready to accept new tasks. It is too late to check that in cpuset_fork(). So we need to add the cpuset_can_fork() and cpuset_cancel_fork() methods to pre-check it before we can allow attachment to a different cpuset. We also need to set the attach_in_progress flag to alert other code that a new task is going to be added to the cpuset. Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups") Suggested-by: Michal Koutný <mkoutny(a)suse.com> Signed-off-by: Waiman Long <longman(a)redhat.com> Cc: stable(a)vger.kernel.org # v5.7+ Signed-off-by: Tejun Heo <tj(a)kernel.org> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 2ccfae74acf9..166a45019f66 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -2453,6 +2453,20 @@ static int fmeter_getrate(struct fmeter *fmp) static struct cpuset *cpuset_attach_old_cs; +/* + * Check to see if a cpuset can accept a new task + * For v1, cpus_allowed and mems_allowed can't be empty. + * For v2, effective_cpus can't be empty. + * Note that in v1, effective_cpus = cpus_allowed. + */ +static int cpuset_can_attach_check(struct cpuset *cs) +{ + if (cpumask_empty(cs->effective_cpus) || + (!is_in_v2_mode() && nodes_empty(cs->mems_allowed))) + return -ENOSPC; + return 0; +} + /* Called by cgroups to determine if a cpuset is usable; cpuset_rwsem held */ static int cpuset_can_attach(struct cgroup_taskset *tset) { @@ -2467,16 +2481,9 @@ static int cpuset_can_attach(struct cgroup_taskset *tset) percpu_down_write(&cpuset_rwsem); - /* allow moving tasks into an empty cpuset if on default hierarchy */ - ret = -ENOSPC; - if (!is_in_v2_mode() && - (cpumask_empty(cs->cpus_allowed) || nodes_empty(cs->mems_allowed))) - goto out_unlock; - - /* - * Task cannot be moved to a cpuset with empty effective cpus. - */ - if (cpumask_empty(cs->effective_cpus)) + /* Check to see if task is allowed in the cpuset */ + ret = cpuset_can_attach_check(cs); + if (ret) goto out_unlock; cgroup_taskset_for_each(task, css, tset) { @@ -2493,7 +2500,6 @@ static int cpuset_can_attach(struct cgroup_taskset *tset) * changes which zero cpus/mems_allowed. */ cs->attach_in_progress++; - ret = 0; out_unlock: percpu_up_write(&cpuset_rwsem); return ret; @@ -3264,6 +3270,68 @@ static void cpuset_bind(struct cgroup_subsys_state *root_css) percpu_up_write(&cpuset_rwsem); } +/* + * In case the child is cloned into a cpuset different from its parent, + * additional checks are done to see if the move is allowed. + */ +static int cpuset_can_fork(struct task_struct *task, struct css_set *cset) +{ + struct cpuset *cs = css_cs(cset->subsys[cpuset_cgrp_id]); + bool same_cs; + int ret; + + rcu_read_lock(); + same_cs = (cs == task_cs(current)); + rcu_read_unlock(); + + if (same_cs) + return 0; + + lockdep_assert_held(&cgroup_mutex); + percpu_down_write(&cpuset_rwsem); + + /* Check to see if task is allowed in the cpuset */ + ret = cpuset_can_attach_check(cs); + if (ret) + goto out_unlock; + + ret = task_can_attach(task, cs->effective_cpus); + if (ret) + goto out_unlock; + + ret = security_task_setscheduler(task); + if (ret) + goto out_unlock; + + /* + * Mark attach is in progress. This makes validate_change() fail + * changes which zero cpus/mems_allowed. + */ + cs->attach_in_progress++; +out_unlock: + percpu_up_write(&cpuset_rwsem); + return ret; +} + +static void cpuset_cancel_fork(struct task_struct *task, struct css_set *cset) +{ + struct cpuset *cs = css_cs(cset->subsys[cpuset_cgrp_id]); + bool same_cs; + + rcu_read_lock(); + same_cs = (cs == task_cs(current)); + rcu_read_unlock(); + + if (same_cs) + return; + + percpu_down_write(&cpuset_rwsem); + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); +} + /* * Make sure the new task conform to the current state of its parent, * which could have been changed by cpuset just after it inherits the @@ -3292,6 +3360,11 @@ static void cpuset_fork(struct task_struct *task) percpu_down_write(&cpuset_rwsem); guarantee_online_mems(cs, &cpuset_attach_nodemask_to); cpuset_attach_task(cs, task); + + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); } @@ -3305,6 +3378,8 @@ struct cgroup_subsys cpuset_cgrp_subsys = { .attach = cpuset_attach, .post_attach = cpuset_post_attach, .bind = cpuset_bind, + .can_fork = cpuset_can_fork, + .cancel_fork = cpuset_cancel_fork, .fork = cpuset_fork, .legacy_cftypes = legacy_files, .dfl_cftypes = dfl_files,

2 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] purgatory: fix disabling debug info" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x d83806c4c0cccc0d6d3c3581a11983a9c186a138 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041747-monogram-playpen-8e77@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: d83806c4c0cc ("purgatory: fix disabling debug info") 56e0790c7f9e ("RISC-V: add infrastructure to allow different str* implementations") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d83806c4c0cccc0d6d3c3581a11983a9c186a138 Mon Sep 17 00:00:00 2001 From: Alyssa Ross <hi(a)alyssa.is> Date: Sun, 26 Mar 2023 18:21:21 +0000 Subject: [PATCH] purgatory: fix disabling debug info Since 32ef9e5054ec, -Wa,-gdwarf-2 is no longer used in KBUILD_AFLAGS. Instead, it includes -g, the appropriate -gdwarf-* flag, and also the -Wa versions of both of those if building with Clang and GNU as. As a result, debug info was being generated for the purgatory objects, even though the intention was that it not be. Fixes: 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") Signed-off-by: Alyssa Ross <hi(a)alyssa.is> Cc: stable(a)vger.kernel.org Acked-by: Nick Desaulniers <ndesaulniers(a)google.com> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> diff --git a/arch/riscv/purgatory/Makefile b/arch/riscv/purgatory/Makefile index d16bf715a586..5730797a6b40 100644 --- a/arch/riscv/purgatory/Makefile +++ b/arch/riscv/purgatory/Makefile @@ -84,12 +84,7 @@ CFLAGS_string.o += $(PURGATORY_CFLAGS) CFLAGS_REMOVE_ctype.o += $(PURGATORY_CFLAGS_REMOVE) CFLAGS_ctype.o += $(PURGATORY_CFLAGS) -AFLAGS_REMOVE_entry.o += -Wa,-gdwarf-2 -AFLAGS_REMOVE_memcpy.o += -Wa,-gdwarf-2 -AFLAGS_REMOVE_memset.o += -Wa,-gdwarf-2 -AFLAGS_REMOVE_strcmp.o += -Wa,-gdwarf-2 -AFLAGS_REMOVE_strlen.o += -Wa,-gdwarf-2 -AFLAGS_REMOVE_strncmp.o += -Wa,-gdwarf-2 +asflags-remove-y += $(foreach x, -g -gdwarf-4 -gdwarf-5, $(x) -Wa,$(x)) $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE $(call if_changed,ld) diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile index 17f09dc26381..82fec66d46d2 100644 --- a/arch/x86/purgatory/Makefile +++ b/arch/x86/purgatory/Makefile @@ -69,8 +69,7 @@ CFLAGS_sha256.o += $(PURGATORY_CFLAGS) CFLAGS_REMOVE_string.o += $(PURGATORY_CFLAGS_REMOVE) CFLAGS_string.o += $(PURGATORY_CFLAGS) -AFLAGS_REMOVE_setup-x86_$(BITS).o += -Wa,-gdwarf-2 -AFLAGS_REMOVE_entry64.o += -Wa,-gdwarf-2 +asflags-remove-y += $(foreach x, -g -gdwarf-4 -gdwarf-5, $(x) -Wa,$(x)) $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE $(call if_changed,ld)

2 years, 8 months

2
1
0 0

Re: new order

by FASTWAYBASE.US94＠consultant.com

Dea Sir. Please see attached new order and revert to us the delivery date/ FOB also inform us payment terms. Best Regards Susan Purchase Manager.

2 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork()" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x eee87853794187f6adbe19533ed79c8b44b36a91 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041702-vertebrae-bonsai-f1de@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: eee878537941 ("cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods") 42a11bf5c543 ("cgroup/cpuset: Make cpuset_fork() handle CLONE_INTO_CGROUP properly") 18f9a4d47527 ("cgroup/cpuset: Skip spread flags update on v2") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From eee87853794187f6adbe19533ed79c8b44b36a91 Mon Sep 17 00:00:00 2001 From: Waiman Long <longman(a)redhat.com> Date: Tue, 11 Apr 2023 09:35:59 -0400 Subject: [PATCH] cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In the case of CLONE_INTO_CGROUP, not all cpusets are ready to accept new tasks. It is too late to check that in cpuset_fork(). So we need to add the cpuset_can_fork() and cpuset_cancel_fork() methods to pre-check it before we can allow attachment to a different cpuset. We also need to set the attach_in_progress flag to alert other code that a new task is going to be added to the cpuset. Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups") Suggested-by: Michal Koutný <mkoutny(a)suse.com> Signed-off-by: Waiman Long <longman(a)redhat.com> Cc: stable(a)vger.kernel.org # v5.7+ Signed-off-by: Tejun Heo <tj(a)kernel.org> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 2ccfae74acf9..166a45019f66 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -2453,6 +2453,20 @@ static int fmeter_getrate(struct fmeter *fmp) static struct cpuset *cpuset_attach_old_cs; +/* + * Check to see if a cpuset can accept a new task + * For v1, cpus_allowed and mems_allowed can't be empty. + * For v2, effective_cpus can't be empty. + * Note that in v1, effective_cpus = cpus_allowed. + */ +static int cpuset_can_attach_check(struct cpuset *cs) +{ + if (cpumask_empty(cs->effective_cpus) || + (!is_in_v2_mode() && nodes_empty(cs->mems_allowed))) + return -ENOSPC; + return 0; +} + /* Called by cgroups to determine if a cpuset is usable; cpuset_rwsem held */ static int cpuset_can_attach(struct cgroup_taskset *tset) { @@ -2467,16 +2481,9 @@ static int cpuset_can_attach(struct cgroup_taskset *tset) percpu_down_write(&cpuset_rwsem); - /* allow moving tasks into an empty cpuset if on default hierarchy */ - ret = -ENOSPC; - if (!is_in_v2_mode() && - (cpumask_empty(cs->cpus_allowed) || nodes_empty(cs->mems_allowed))) - goto out_unlock; - - /* - * Task cannot be moved to a cpuset with empty effective cpus. - */ - if (cpumask_empty(cs->effective_cpus)) + /* Check to see if task is allowed in the cpuset */ + ret = cpuset_can_attach_check(cs); + if (ret) goto out_unlock; cgroup_taskset_for_each(task, css, tset) { @@ -2493,7 +2500,6 @@ static int cpuset_can_attach(struct cgroup_taskset *tset) * changes which zero cpus/mems_allowed. */ cs->attach_in_progress++; - ret = 0; out_unlock: percpu_up_write(&cpuset_rwsem); return ret; @@ -3264,6 +3270,68 @@ static void cpuset_bind(struct cgroup_subsys_state *root_css) percpu_up_write(&cpuset_rwsem); } +/* + * In case the child is cloned into a cpuset different from its parent, + * additional checks are done to see if the move is allowed. + */ +static int cpuset_can_fork(struct task_struct *task, struct css_set *cset) +{ + struct cpuset *cs = css_cs(cset->subsys[cpuset_cgrp_id]); + bool same_cs; + int ret; + + rcu_read_lock(); + same_cs = (cs == task_cs(current)); + rcu_read_unlock(); + + if (same_cs) + return 0; + + lockdep_assert_held(&cgroup_mutex); + percpu_down_write(&cpuset_rwsem); + + /* Check to see if task is allowed in the cpuset */ + ret = cpuset_can_attach_check(cs); + if (ret) + goto out_unlock; + + ret = task_can_attach(task, cs->effective_cpus); + if (ret) + goto out_unlock; + + ret = security_task_setscheduler(task); + if (ret) + goto out_unlock; + + /* + * Mark attach is in progress. This makes validate_change() fail + * changes which zero cpus/mems_allowed. + */ + cs->attach_in_progress++; +out_unlock: + percpu_up_write(&cpuset_rwsem); + return ret; +} + +static void cpuset_cancel_fork(struct task_struct *task, struct css_set *cset) +{ + struct cpuset *cs = css_cs(cset->subsys[cpuset_cgrp_id]); + bool same_cs; + + rcu_read_lock(); + same_cs = (cs == task_cs(current)); + rcu_read_unlock(); + + if (same_cs) + return; + + percpu_down_write(&cpuset_rwsem); + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); +} + /* * Make sure the new task conform to the current state of its parent, * which could have been changed by cpuset just after it inherits the @@ -3292,6 +3360,11 @@ static void cpuset_fork(struct task_struct *task) percpu_down_write(&cpuset_rwsem); guarantee_online_mems(cs, &cpuset_attach_nodemask_to); cpuset_attach_task(cs, task); + + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); } @@ -3305,6 +3378,8 @@ struct cgroup_subsys cpuset_cgrp_subsys = { .attach = cpuset_attach, .post_attach = cpuset_post_attach, .bind = cpuset_bind, + .can_fork = cpuset_can_fork, + .cancel_fork = cpuset_cancel_fork, .fork = cpuset_fork, .legacy_cftypes = legacy_files, .dfl_cftypes = dfl_files,

2 years, 8 months

2
1
0 0

[PATCH 6.1 1/3] cgroup/cpuset: Skip spread flags update on v2

by Waiman Long

commit 18f9a4d47527772515ad6cbdac796422566e6440 upstream. Cpuset v2 has no spread flags to set. So we can skip spread flags update if cpuset v2 is being used. Also change the name to cpuset_update_task_spread_flags() to indicate that there are multiple spread flags. Signed-off-by: Waiman Long <longman(a)redhat.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> --- kernel/cgroup/cpuset.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index fac426036620..7c418ce4d3c9 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -550,11 +550,15 @@ static void guarantee_online_mems(struct cpuset *cs, nodemask_t *pmask) /* * update task's spread flag if cpuset's page/slab spread flag is set * - * Call with callback_lock or cpuset_rwsem held. + * Call with callback_lock or cpuset_rwsem held. The check can be skipped + * if on default hierarchy. */ -static void cpuset_update_task_spread_flag(struct cpuset *cs, +static void cpuset_update_task_spread_flags(struct cpuset *cs, struct task_struct *tsk) { + if (cgroup_subsys_on_dfl(cpuset_cgrp_subsys)) + return; + if (is_spread_page(cs)) task_set_spread_page(tsk); else @@ -2157,7 +2161,7 @@ static void update_tasks_flags(struct cpuset *cs) css_task_iter_start(&cs->css, 0, &it); while ((task = css_task_iter_next(&it))) - cpuset_update_task_spread_flag(cs, task); + cpuset_update_task_spread_flags(cs, task); css_task_iter_end(&it); } @@ -2535,7 +2539,7 @@ static void cpuset_attach(struct cgroup_taskset *tset) WARN_ON_ONCE(set_cpus_allowed_ptr(task, cpus_attach)); cpuset_change_task_nodemask(task, &cpuset_attach_nodemask_to); - cpuset_update_task_spread_flag(cs, task); + cpuset_update_task_spread_flags(cs, task); } /* -- 2.31.1

2 years, 8 months

1
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror