[EXTENSION] Request to add new extension to Crash Extension Modules page: sdinfo
by briston_dev＠foxmail.com
Dear Crash Utility Maintainers,
I would like to submit a new extension module for inclusion in the Crash Extension Modules page. Below are the required details:
1.Extension Name: sdinfo
2.Command(s): sdinfo
3.Comments
- Functionality: Displays Linux kernel's SCSI disk information, including devices, hosts, targets, and associated I/O requests and SCSI commands. Support for NVMe devices is currently under development and will be added in upcoming releases.
- To build the module from the top-level `crash-<version>` directory, enter:
$ cp <path-to>/scsi.c scsi.mk extensions
$ make extensions
- Package Website: https://github.com/briston-dev/crash-diskutils
- Requires crash-utility version >= 7.2.8
- Author: Yao Sang <sangyao(a)kylinos.cn>
As specified in the extension guidelines, please add this module to the Crash Extension Modules page. This extension will be actively maintained with regular updates to ensure compatibility with new kernel versions and additional feature enhancements.
Let me know if additional information is needed. Thank you for your consideration!
Best regards,
Yao Sang
2 hours, 26 minutes
- 1
- 0
[PATCH v1 0/5] extension: Several improvements on eppic extension
by Tao Liu
Eppic works as a crash extension for a long time, and it is a very convenient
tool to extend crash's function:
1) People don't need to write an actual crash extension, which requires
knowledge of crash APIs, such as readmem(), gdb_interface() etc.
Implementing such an crash extension is hard for normal users.
2) Eppic programs are C-syntax-like scripting, no compile needed, so friendly
to kernel developers who are already familiar with C. It's a good alternative
for people who are unfamiliar with python (comparing to drgn/pykdump).
3) Writing eppic programs is similar to do kernel programming, people can use
kernel data structures/global variables directly, again, friendly to kernel
developers.
Personally I think eppic is a good tool and would like to push it forward to
make it used more widely, improved consistently. However I hardly heard anyone
who are using it, I guess it is due to it's extension position and unknown to
others.
In this patchset, I will make several improvements on eppic, although it is
still a crash extension, but I think it is made more easily for
compile/run/scripting.
To-do:
Some crash functions should be exposed to eppic, such as
maple_tree/rbtree etc, so people can iterate these kernel structures
with no problem, e.g. vma iteration. The exposure isn't hard and can be
implemented later.
Tao Liu (5):
extensions: modify search path and extension preload
Makefile: allow "make eppic" to create the eppic extension
configure: Add EPPIC to Cflags
eppic.patch: Add customized functions to eppic
alias: create "eppic" alias to run eppic programs
Makefile | 12 ++-
configure.c | 14 ++-
defs.h | 2 +-
extensions.c | 83 +++++++++++-------
extensions/Makefile | 2 +-
extensions/eppic.mk | 13 ++-
extensions/eppic.patch | 195 +++++++++++++++++++++++++++++++++++++++++
main.c | 16 +++-
8 files changed, 295 insertions(+), 42 deletions(-)
create mode 100644 extensions/eppic.patch
--
2.47.0
1 day, 6 hours
- 1
- 5
Re: [PATCH RFC][makedumpfile 00/10] btf/kallsyms based eppic extension for mm page filtering
by Tao Liu
Hi YAMAZAKI,
Thanks for your comments.
On Thu, Aug 7, 2025 at 11:42 PM YAMAZAKI MASAMITSU(山崎 真光)
<yamazaki-msmt(a)nec.com> wrote:
>
> Thank you for the suggestion.
> I think it's a good idea,
> but epppic needs careful consideration.
Do you mean there are drawbacks of using eppic?
From my side, one advantage of eppic is, users can use the kernel data
structures/variables directly without redefine it, like:
struct task_struct *p;
p = (struct task_struct *)&init_task;
Users don't need to include headers to define what task_struct looks
like, and can use global variable init_task without declaring it. The
callbacks of eppic can resolve these missing info via
dwarf/btf/kallsyms during runtime. I think this feature can make the
eppic scripts tidy and convenient. Also we can use other similar c
interpreters, but I haven't encountered one with the similar feature,
also considering eppic has been in makedumpfile for years, so people
may already be familiar with it...
> I'm sorry, but please let me check for a moment.
>
Sure, no problem, please take your time.
Thanks,
Tao Liu
> Thanks,
> Masa
>
> On 2025/08/05 12:16, Tao Liu wrote:
> > Kindly ping...
> >
> > Any comments for this patchset?
> >
> > Thanks,
> > Tao Liu
> >
> >
> > On Tue, Jun 10, 2025 at 9:57 PM Tao Liu <ltao(a)redhat.com> wrote:
> >> A) This patchset will introduce the following features to makedumpfile:
> >>
> >> 1) Enable eppic script for memory pages filtering.
> >> 2) Enable btf and kallsyms for symbol type and address resolving.
> >> 3) Port maple tree data structures and functions, primarily used for
> >> vma iteration.
> >>
> >> B) The purpose of the features are:
> >>
> >> 1) Currently makedumpfile filters mm pages based on page flags, because flags
> >> can help to determine one page's usage. But this page-flag-checking method
> >> lacks of flexibility in certain cases, e.g. if we want to filter those mm
> >> pages occupied by GPU during vmcore dumping due to:
> >>
> >> a) GPU may be taking a large memory and contains sensitive data;
> >> b) GPU mm pages have no relations to kernel crash and useless for vmcore
> >> analysis.
> >>
> >> But there is no GPU mm page specific flags, and apparently we don't need
> >> to create one just for kdump use. A programmable filtering tool is more
> >> suitable for such cases. In addition, different GPU vendors may use
> >> different ways for mm pages allocating, programmable filtering is better
> >> than hard coding these GPU specific logics into makedumpfile in this case.
> >>
> >> 2) Currently makedumpfile already contains a programmable filtering tool, aka
> >> eppic script, which allows user to write customized code for data erasing.
> >> However it has the following drawbacks:
> >>
> >> a) cannot do mm page filtering.
> >> b) need to access to debuginfo of both kernel and modules, which is not
> >> applicable in the 2nd kernel.
> >> c) Poor performance, making vmcore dumping time unacceptable (See
> >> the following performance testing).
> >>
> >> makedumpfile need to resolve the dwarf data from debuginfo, to get symbols
> >> types and addresses. In recent kernel there are dwarf alternatives such
> >> as btf/kallsyms which can be used for this purpose. And btf/kallsyms info
> >> are already packed within vmcore, so we can use it directly.
> >>
> >> 3) Maple tree data structures are used in recent kernels, such as vma
> >> iteration. So maple tree poring is needed.
> >>
> >> With these, this patchset introduces an upgraded eppic, which is based on
> >> btf/kallsyms symbol resolving, and is programmable for mm page filtering.
> >> The following info shows its usage and performance, please note the tests
> >> are performed in 1st kernel:
> >>
> >> $ time ./makedumpfile -d 31 -l /var/crash/127.0.0.1-2025-06-10-18\:03\:12/vmcore
> >> /tmp/dwarf.out -x /lib/debug/lib/modules/6.11.8-300.fc41.x86_64/vmlinux
> >> --eppic eppic_scripts/filter_amdgpu_mm_pages.c
> >> real 14m6.894s
> >> user 4m16.900s
> >> sys 9m44.695s
> >>
> >> $ time ./makedumpfile -d 31 -l /var/crash/127.0.0.1-2025-06-10-18\:03\:12/vmcore
> >> /tmp/btf.out --eppic eppic_scripts/filter_amdgpu_mm_pages.c
> >> real 0m10.672s
> >> user 0m9.270s
> >> sys 0m1.130s
> >>
> >> -rw------- 1 root root 367475074 Jun 10 18:06 btf.out
> >> -rw------- 1 root root 367475074 Jun 10 21:05 dwarf.out
> >> -rw-rw-rw- 1 root root 387181418 Jun 10 18:03 /var/crash/127.0.0.1-2025-06-10-18:03:12/vmcore
> >>
> >> C) Discussion:
> >>
> >> 1) GPU types: Currently only tested with amdgpu's mm page filtering, others
> >> are not tested.
> >> 2) Code structure: There are some similar code shared by makedumpfile and
> >> crash, such as maple tree data structure, also I planed to port the
> >> btf/kallsyms code to crash as well, so there are code duplications for
> >> crash & makedumpfile. Since I havn't working on crash poring, code change
> >> on btf/kallsyms is expected. How can we share the code, creating a common
> >> library or keep the duplication as it is?
> >> 3) OS: The code can work on rhel-10+/rhel9.5+ on x86_64/arm64/s390/ppc64.
> >> Others are not tested.
> >>
> >> D) Testing:
> >>
> >> 1) If you don't want to create your vmcore, you can find a vmcore which I
> >> created with amdgpu mm pages unfiltered [1], the amdgpu mm pages are
> >> allocated by program [2]. You can use the vmcore in 1st kernel to filter
> >> the amdgpu mm pages by the previous performance testing cmdline. To
> >> verify the pages are filtered in crash:
> >>
> >> Unfiltered:
> >> crash> search -c "!QAZXSW@#EDC"
> >> ffff96b7fa800000: !QAZXSW@#EDCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> >> ffff96b87c800000: !QAZXSW@#EDCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> >> crash> rd ffff96b7fa800000
> >> ffff96b7fa800000: 405753585a415121 !QAZXSW@
> >> crash> rd ffff96b87c800000
> >> ffff96b87c800000: 405753585a415121 !QAZXSW@
> >>
> >> Filtered:
> >> crash> search -c "!QAZXSW@#EDC"
> >> crash> rd ffff96b7fa800000
> >> rd: page excluded: kernel virtual address: ffff96b7fa800000 type: "64-bit KVADDR"
> >> crash> rd ffff96b87c800000
> >> rd: page excluded: kernel virtual address: ffff96b87c800000 type: "64-bit KVADDR"
> >>
> >> 2) You can use eppic_scripts/print_all_vma.c against an ordinary vmcore to
> >> test only btf/kallsyms functions by output all VMAs if no amdgpu
> >> vmcores/machine avaliable.
> >>
> >> [1]: https://people.redhat.com/~ltao/core/
> >> [2]: https://gist.github.com/liutgnu/a8cbce1c666452f1530e1410d1f352df
> >>
> >> Tao Liu (10):
> >> dwarf_info: Support kernel address randomization
> >> dwarf_info: Fix a infinite recursion bug for search_domain
> >> Add page filtering function
> >> Add btf/kallsyms support for symbol type/address resolving
> >> Export necessary btf/kallsyms functions to eppic extension
> >> Port the maple tree data structures and functions
> >> Supporting main() as the entry of eppic script
> >> Enable page filtering for dwarf eppic
> >> Enable page filtering for btf/kallsyms eppic
> >> Introducing 2 eppic scripts to test the dwarf/btf eppic extension
> >>
> >> Makefile | 6 +-
> >> btf.c | 919 +++++++++++++++++++++++++
> >> btf.h | 176 +++++
> >> dwarf_info.c | 15 +-
> >> eppic_maple.c | 431 ++++++++++++
> >> eppic_maple.h | 8 +
> >> eppic_scripts/filter_amdgpu_mm_pages.c | 36 +
> >> eppic_scripts/print_all_vma.c | 29 +
> >> erase_info.c | 123 +++-
> >> erase_info.h | 22 +
> >> extension_btf.c | 218 ++++++
> >> extension_eppic.c | 41 +-
> >> extension_eppic.h | 6 +-
> >> kallsyms.c | 371 ++++++++++
> >> kallsyms.h | 42 ++
> >> makedumpfile.c | 21 +-
> >> makedumpfile.h | 11 +
> >> 17 files changed, 2448 insertions(+), 27 deletions(-)
> >> create mode 100644 btf.c
> >> create mode 100644 btf.h
> >> create mode 100644 eppic_maple.c
> >> create mode 100644 eppic_maple.h
> >> create mode 100644 eppic_scripts/filter_amdgpu_mm_pages.c
> >> create mode 100644 eppic_scripts/print_all_vma.c
> >> create mode 100644 extension_btf.c
> >> create mode 100644 kallsyms.c
> >> create mode 100644 kallsyms.h
> >>
> >> --
> >> 2.47.0
> >>
1 week, 4 days
- 1
- 0
Re: [PATCH] Add blk_mq shared tags support for dev -d/-D
by Lianbo Jiang
Hi, Tao
Thank you for the patch.
On 6/27/25 19:33, devel-request(a)lists.crash-utility.osci.io wrote:
> Date: Fri, 27 Jun 2025 23:30:59 +1200
> From: Tao Liu<ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH] Add blk_mq shared tags support for
> dev -d/-D
> To:devel@lists.crash-utility.osci.io
> Cc: Tao Liu<ltao(a)redhat.com>
> Message-ID:<20250627113058.42612-2-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> When blk_mq shared tags enabled for devices like scsi, the IO status is
> incorrect, e.g:
>
> crash> dev -d
> MAJOR GENDISK NAME REQUEST_QUEUE TOTAL ASYNC SYNC
> 8 ffff90528df86000 sda ffff9052a3d61800 144 144 0
> 8 ffff905280718c00 sdb ffff9052a3d63c00 48 48 0
>
> crash> epython rqlist
> ffff90528e94a5c0 sda is unknown, deadline: 89.992 (90) rq_alloc: 0.196
> ffff90528e92f700 sda is unknown, deadline: 89.998 (90) rq_alloc: 0.202
> ffff90528e95ccc0 sda is unknown, deadline: 89.999 (90) rq_alloc: 0.203
> ffff90528e968bc0 sdb is unknown, deadline: 89.997 (90) rq_alloc: 0.201
>
> The root cause is: for shared tags case, only the shared tags are put
> into count. Without this patch, tags of all the hw_ctx are counted,
> which is incorrect.
>
> After apply the patch:
>
> crash> dev -d
> MAJOR GENDISK NAME REQUEST_QUEUE TOTAL READ WRITE
> 8 ffff90528df86000 sda ffff9052a3d61800 3 3 0
> 8 ffff905280718c00 sdb ffff9052a3d63c00 1 1 0
>
> This patch makes the following modification:
> 1) blk_mq shared tag support.
> 2) Function renaming: queue_for_each_hw_ctx -> blk_mq_queue_tag_busy_iter,
> because the latter is more close to the corresponding kernel function.
> 3) Extract a new queue_for_each_hw_ctx() function to be called for both
> shared-tags case and the hw_ctx case.
>
> Note:
> The patch is safe for earlier kernels which have no blk_mq shared tags
> implemented, because the blk_mq_is_shared_tags() check will exit safely.
>
> Signed-off-by: Tao Liu<ltao(a)redhat.com>
> ---
>
> Please discard the previous patch "Filter repeated rq for cmd dev -d/-D",
> because filtering is an incorrect fix.
>
> ---
> defs.h | 3 ++
> dev.c | 96 ++++++++++++++++++++++++++++++++++++++-----------------
> symbols.c | 6 ++++
> 3 files changed, 76 insertions(+), 29 deletions(-)
>
> diff --git a/defs.h b/defs.h
> index bbd6d4b..4fecb83 100644
> --- a/defs.h
> +++ b/defs.h
> @@ -2271,6 +2271,9 @@ struct offset_table { /* stash of commonly-used offsets */
> long task_struct_thread_context_x28;
> long neigh_table_hash_heads;
> long neighbour_hash;
> + long request_queue_tag_set;
> + long blk_mq_tag_set_flags;
> + long blk_mq_tag_set_shared_tags;
> };
>
> struct size_table { /* stash of commonly-used sizes */
> diff --git a/dev.c b/dev.c
> index 9d38aef..0a4d5c9 100644
> --- a/dev.c
> +++ b/dev.c
> @@ -4326,6 +4326,12 @@ struct bt_iter_data {
> #define MQ_RQ_IN_FLIGHT 1
> #define REQ_OP_BITS 8
> #define REQ_OP_MASK ((1 << REQ_OP_BITS) - 1)
> +#define BLK_MQ_F_TAG_HCTX_SHARED (1 << 3)
> +
> +static bool blk_mq_is_shared_tags(unsigned int flags)
> +{
> + return flags & BLK_MQ_F_TAG_HCTX_SHARED;
> +}
>
> static uint op_is_write(uint op)
> {
> @@ -4403,43 +4409,72 @@ static void bt_for_each(ulong q, ulong tags, ulong sbq, uint reserved, uint nr_r
> sbitmap_for_each_set(&sc, bt_iter, &iter_data);
> }
>
> -static void queue_for_each_hw_ctx(ulong q, ulong *hctx, uint cnt, struct diskio *dio)
> +static bool queue_for_each_hw_ctx(ulong q, ulong blk_mq_tags_ptr,
> + bool bitmap_tags_is_ptr, struct diskio *dio)
> {
> - uint i;
> + uint i, nr_reserved_tags = 0;
Found a warning here:
gcc -c -g -DX86_64 -DLZO -DGDB_16_2 dev.c -Wall -O2 -Wstrict-prototypes
-Wmissing-prototypes -fstack-protector -Wformat-security
dev.c: In function ‘queue_for_each_hw_ctx’:
dev.c:4415:14: warning: unused variable ‘i’ [-Wunused-variable]
4415 | uint i, nr_reserved_tags = 0;
| ^
Other changes are fine to me, so: Ack(with the above fix).
Thanks
Lianbo
> + ulong tags = 0, addr = 0;
> + bool ret = FALSE;
> +
> + if (!readmem(blk_mq_tags_ptr, KVADDR, &tags, sizeof(ulong),
> + "blk_mq_hw_ctx.tags", RETURN_ON_ERROR))
> + goto out;
> +
> + addr = tags + OFFSET(blk_mq_tags_nr_reserved_tags);
> + if (!readmem(addr, KVADDR, &nr_reserved_tags, sizeof(uint),
> + "blk_mq_tags_nr_reserved_tags", RETURN_ON_ERROR))
> + goto out;
> +
> + if (nr_reserved_tags) {
> + addr = tags + OFFSET(blk_mq_tags_breserved_tags);
> + if (bitmap_tags_is_ptr &&
> + !readmem(addr, KVADDR, &addr, sizeof(ulong),
> + "blk_mq_tags.bitmap_tags", RETURN_ON_ERROR))
> + goto out;
> + bt_for_each(q, tags, addr, 1, nr_reserved_tags, dio);
> + }
> + addr = tags + OFFSET(blk_mq_tags_bitmap_tags);
> + if (bitmap_tags_is_ptr &&
> + !readmem(addr, KVADDR, &addr, sizeof(ulong),
> + "blk_mq_tags.bitmap_tags", RETURN_ON_ERROR))
> + goto out;
> + bt_for_each(q, tags, addr, 0, nr_reserved_tags, dio);
> +
> + ret = TRUE;
> +out:
> + return ret;
> +}
> +
> +/*
> + * Replica of kernel block/blk-mq-tag.c:blk_mq_queue_tag_busy_iter()
> +*/
> +static void blk_mq_queue_tag_busy_iter(ulong q, ulong *hctx, uint cnt,
> + struct diskio *dio)
> +{
> + uint i, flags;
> int bitmap_tags_is_ptr = 0;
> + ulong addr = 0;
>
> if (MEMBER_TYPE("blk_mq_tags", "bitmap_tags") == TYPE_CODE_PTR)
> bitmap_tags_is_ptr = 1;
>
> - for (i = 0; i < cnt; i++) {
> - ulong addr = 0, tags = 0;
> - uint nr_reserved_tags = 0;
> + readmem(q + OFFSET(request_queue_tag_set), KVADDR, &addr,
> + sizeof(ulong), "request_queue.tag_set", RETURN_ON_ERROR);
>
> - /* Tags owned by the block driver */
> - addr = hctx[i] + OFFSET(blk_mq_hw_ctx_tags);
> - if (!readmem(addr, KVADDR, &tags, sizeof(ulong),
> - "blk_mq_hw_ctx.tags", RETURN_ON_ERROR))
> - break;
> + readmem(addr + OFFSET(blk_mq_tag_set_flags), KVADDR,
> + &flags, sizeof(uint), "blk_mq_tag_set.flags", RETURN_ON_ERROR);
>
> - addr = tags + OFFSET(blk_mq_tags_nr_reserved_tags);
> - if (!readmem(addr, KVADDR, &nr_reserved_tags, sizeof(uint),
> - "blk_mq_tags_nr_reserved_tags", RETURN_ON_ERROR))
> - break;
> + if (blk_mq_is_shared_tags(flags)) {
> + addr = addr + OFFSET(blk_mq_tag_set_shared_tags);
> + queue_for_each_hw_ctx(q, addr, bitmap_tags_is_ptr, dio);
> + return;
> + }
>
> - if (nr_reserved_tags) {
> - addr = tags + OFFSET(blk_mq_tags_breserved_tags);
> - if (bitmap_tags_is_ptr &&
> - !readmem(addr, KVADDR, &addr, sizeof(ulong),
> - "blk_mq_tags.bitmap_tags", RETURN_ON_ERROR))
> - break;
> - bt_for_each(q, tags, addr, 1, nr_reserved_tags, dio);
> - }
> - addr = tags + OFFSET(blk_mq_tags_bitmap_tags);
> - if (bitmap_tags_is_ptr &&
> - !readmem(addr, KVADDR, &addr, sizeof(ulong),
> - "blk_mq_tags.bitmap_tags", RETURN_ON_ERROR))
> - break;
> - bt_for_each(q, tags, addr, 0, nr_reserved_tags, dio);
> + for (i = 0; i < cnt; i++) {
> + /* Tags owned by the block driver */
> + addr = hctx[i] + OFFSET(blk_mq_hw_ctx_tags);
> + if (queue_for_each_hw_ctx(q, addr, bitmap_tags_is_ptr, dio) == FALSE)
> + return;
> }
> }
>
> @@ -4489,7 +4524,7 @@ static void get_mq_diskio_from_hw_queues(ulong q, struct diskio *dio)
> return;
> }
>
> - queue_for_each_hw_ctx(q, hctx_array, cnt, dio);
> + blk_mq_queue_tag_busy_iter(q, hctx_array, cnt, dio);
>
> FREEBUF(hctx_array);
> }
> @@ -4914,6 +4949,9 @@ void diskio_init(void)
> MEMBER_SIZE_INIT(class_private_devices, "class_private",
> "class_devices");
> MEMBER_OFFSET_INIT(disk_stats_in_flight, "disk_stats", "in_flight");
> + MEMBER_OFFSET_INIT(request_queue_tag_set, "request_queue", "tag_set");
> + MEMBER_OFFSET_INIT(blk_mq_tag_set_flags, "blk_mq_tag_set", "flags");
> + MEMBER_OFFSET_INIT(blk_mq_tag_set_shared_tags, "blk_mq_tag_set", "shared_tags");
>
> dt->flags |= DISKIO_INIT;
> }
> diff --git a/symbols.c b/symbols.c
> index e30fafe..794519a 100644
> --- a/symbols.c
> +++ b/symbols.c
> @@ -11487,6 +11487,12 @@ dump_offset_table(char *spec, ulong makestruct)
> OFFSET(blk_mq_tags_nr_reserved_tags));
> fprintf(fp, " blk_mq_tags_rqs: %ld\n",
> OFFSET(blk_mq_tags_rqs));
> + fprintf(fp, " request_queue_tag_set: %ld\n",
> + OFFSET(request_queue_tag_set));
> + fprintf(fp, " blk_mq_tag_set_flags: %ld\n",
> + OFFSET(blk_mq_tag_set_flags));
> + fprintf(fp, " blk_mq_tag_set_shared_tags: %ld\n",
> + OFFSET(blk_mq_tag_set_shared_tags));
>
> fprintf(fp, " subsys_private_subsys: %ld\n", OFFSET(subsys_private_subsys));
> fprintf(fp, " subsys_private_klist_devices: %ld\n",
> -- 2.47.0
2 weeks, 2 days
- 2
- 2
شهادة الأبوة في المغرب
by pikolasikolatest2＠gmail.com
كل ما تحتاج معرفته حول شهادة الأبوة بالمغرب
يمكنك تحميل الطلب من خلال الرابط المباشر
https://www.targir.com/2025/04/blog-post_14.html
معلومات شاملة لاستخراج شهادة الأبوة والإجراءات القانونية المرتبطة بها
ما هي شهادة الأبوة في المغرب؟
شهادة الأبوة وثيقة قانونية تصدر بناءً على حكم قضائي، وتُثبت العلاقة البنوية بين الطفل ووالده البيولوجي، في حال عدم وجود عقد زواج رسمي أو تسجيل سابق. تُعَد هذه الشهادة جزءًا من الإجراءات القضائية التي تدخل ضمن قضايا الحالة المدنية.
الحالات التي تستوجب استخراج شهادة الأبوة
1. الأطفال غير المسجلين في الحالة المدنية
عندما يولد طفل خارج إطار الزواج أو لم يُسجَّل بصفة قانونية في دفتر الحالة المدنية، يحتاج الأب إلى رفع دعوى للحصول على شهادة الأبوة.
2. إثبات النسب في غياب عقد زواج
في حالات عدم توفر وثيقة الزواج بين الأبوين، يُلجأ إلى المحكمة لتقديم التصريح بالأبوة.
إجراءات الحصول على شهادة الأبوة
أولا: رفع دعوى أمام المحكمة
يتوجب على الأب أو ولي أمر الطفل تقديم طلب إلى المحكمة الابتدائية التي يقع فيها مقر سكن الطفل أو الأب، وذلك من أجل إصدار حكم قضائي بإثبات الأبوة.
ثانياً: الوثائق المطلوبة
نسخة من بطاقة التعريف الوطنية
عقد الازدياد الخاص بالطفل (إن وُجد)
شهادة طبية للولادة
شهادة السكنى
وثائق أو إثباتات تدعم علاقة الأب بالطفل
نموذج شهادة الأبوة pdf
تتيح بعض المواقع الإلكترونية تحميل نموذج شهادة الأبوة PDF قابل للطباعة، غير أن إصدارها الرسمي لا يتم إلا بعد حكم قضائي، ويتم توجيهها لمصلحة الحالة المدنية لتسجيل الطفل.
الأسئلة الشائعة حول شهادة الأبوة
هل يمكن تقديم طلب شهادة الأبوة إلكترونياً؟
لا، المسطرة تظل قضائية وتتطلب الحضور أمام المحكمة.
ما هي مدة الحصول على شهادة الأبوة؟
قد تختلف المدة حسب عدد الجلسات، ولكن عادة ما تستغرق بين شهر إلى ثلاثة أشهر، حسب تعقيد الملف.
صلة بين شهادة الأبوة وبعض التصاريح القانونية الأخرى
تم الربط ضمن هذا الدليل بين شهادة الأبوة وبعض المفاهيم القانونية الأخرى التي يبحث عنها الكثير، مثل:
1. التصريح الأمني وتصريح السفر
غالباً ما يُطلب في بعض الحالات القانونية توفير تصريح أمني عند استخراج أوراق ثبوتية، كما هو الحال في:
الأوراق المطلوبة لاستخراج تصريح السفر من منطقة التجنيد
تصريح أمني مستعجل
التصريح الأمني الإلكتروني
2. استبدال التصريح برخصة قيادة
في حالات مثل شروط إصدار رخصة قيادة بعد التصريح أو تجديد التصريح إلى رخصة، من المهم التأكد من إثبات الهوية القانونية، وهو ما يجعل شهادة الأبوة ضرورية في بعض الحالات القانونية الخاصة.
شهادة الأبوة
الغاية من هذه الوثيقة هي إثبات علاقة الأبوة بالابن سواء كان راشدا أم قاصرا وغالبا ما تطلب في بعض المساطر الإدارية.
صاحب الطلب
المغربي المقيم بالخارج
الوثائق المطلوبة
بالنسبة للراشد :
· بطاقة التسجيل ؛
· الدفتر العائلي
بالنسبة للقاصر :
· بطاقة تسجيل الأب ؛
· الدفتر العائلي .
المصلحة المكلفة باستلام الوثائق المطلوبة
المصالح القنصلية التابعة لمحل إقامة صاحب الطلب
المصلحة المكلفة بتقديم الخدمة
المصالح القنصلية التابعة لمحل إقامة صاحب الطلب
في حالة تعذر الحصول على الخدمة
مؤسسة الوسيط
لأجل الاتصال
وزارة الشؤون الخارجية والتعاون
مصدر المعلومات (الإدارة المعنية)
وزارة الشؤون الخارجية والتعاون_أرشيف
يمكنك تحميل الطلب من خلال الرابط المباشر
نموذج شهادة الأبوة بالمغرب
محكمة الأسرة بـ: [اسم المدينة]
رقم الملف: [يُترك للمحكمة]
رقم القضية: [يُترك للمحكمة]
بيان تصريح بالأبوة
أنا الموقع أسفله:
الاسم الكامل: [الاسم الكامل للأب]
رقم بطاقة التعريف الوطنية: [رقم CIN]
تاريخ ومكان الازدياد: [تاريخ ومكان ولادة الأب]
العنوان الكامل: [عنوان الإقامة]
المهنة: [المهنة الحالية]
أُصرّح بموجب هذا، وبكامل قواي العقلية والقانونية، بما يلي:
أن الطفل (ة) المسمى (ة): [اسم الطفل/ة]
المولود (ة) بتاريخ: [تاريخ الولادة]
بـ: [مكان الولادة]
هو(هي) ابني/ابنتي البيولوجي(ة)، وقد وُلد(ت) نتيجة علاقة أبوية قائمة بيني وبين السيدة:
[اسم الأم]، المولودة بتاريخ: [تاريخ ميلاد الأم]، والحاملة لرقم بطاقة التعريف الوطنية: [رقم CIN الأم].
وأتحمل كامل المسؤولية القانونية والأبوية تجاه هذا الطفل/ة، وأطلب من المحكمة الموقرة إصدار حكم قضائي يثبت نسب الطفل لي، وتمكينه من التسجيل في الحالة المدنية.
الإمضاء
الإسم الكامل: _____________________
التوقيع: ___________________________
التاريخ: ____ / ____ / ________
ملاحظات :
يُرفق هذا النموذج بالوثائق الداعمة كـ: نسخة البطاقة الوطنية، شهادة السكنى، شهادة الولادة، وغيرها.
يُودَع لدى كتابة ضبط المحكمة الابتدائية (قسم قضاء الأسرة) التي يقع ضمن اختصاصها محل ولادة الطفل أو محل سكن الأب.
2 weeks, 2 days
- 1
- 0
[PATCH RFC][makedumpfile 00/10] btf/kallsyms based eppic extension for mm page filtering
by Tao Liu
A) This patchset will introduce the following features to makedumpfile:
1) Enable eppic script for memory pages filtering.
2) Enable btf and kallsyms for symbol type and address resolving.
3) Port maple tree data structures and functions, primarily used for
vma iteration.
B) The purpose of the features are:
1) Currently makedumpfile filters mm pages based on page flags, because flags
can help to determine one page's usage. But this page-flag-checking method
lacks of flexibility in certain cases, e.g. if we want to filter those mm
pages occupied by GPU during vmcore dumping due to:
a) GPU may be taking a large memory and contains sensitive data;
b) GPU mm pages have no relations to kernel crash and useless for vmcore
analysis.
But there is no GPU mm page specific flags, and apparently we don't need
to create one just for kdump use. A programmable filtering tool is more
suitable for such cases. In addition, different GPU vendors may use
different ways for mm pages allocating, programmable filtering is better
than hard coding these GPU specific logics into makedumpfile in this case.
2) Currently makedumpfile already contains a programmable filtering tool, aka
eppic script, which allows user to write customized code for data erasing.
However it has the following drawbacks:
a) cannot do mm page filtering.
b) need to access to debuginfo of both kernel and modules, which is not
applicable in the 2nd kernel.
c) Poor performance, making vmcore dumping time unacceptable (See
the following performance testing).
makedumpfile need to resolve the dwarf data from debuginfo, to get symbols
types and addresses. In recent kernel there are dwarf alternatives such
as btf/kallsyms which can be used for this purpose. And btf/kallsyms info
are already packed within vmcore, so we can use it directly.
3) Maple tree data structures are used in recent kernels, such as vma
iteration. So maple tree poring is needed.
With these, this patchset introduces an upgraded eppic, which is based on
btf/kallsyms symbol resolving, and is programmable for mm page filtering.
The following info shows its usage and performance, please note the tests
are performed in 1st kernel:
$ time ./makedumpfile -d 31 -l /var/crash/127.0.0.1-2025-06-10-18\:03\:12/vmcore
/tmp/dwarf.out -x /lib/debug/lib/modules/6.11.8-300.fc41.x86_64/vmlinux
--eppic eppic_scripts/filter_amdgpu_mm_pages.c
real 14m6.894s
user 4m16.900s
sys 9m44.695s
$ time ./makedumpfile -d 31 -l /var/crash/127.0.0.1-2025-06-10-18\:03\:12/vmcore
/tmp/btf.out --eppic eppic_scripts/filter_amdgpu_mm_pages.c
real 0m10.672s
user 0m9.270s
sys 0m1.130s
-rw------- 1 root root 367475074 Jun 10 18:06 btf.out
-rw------- 1 root root 367475074 Jun 10 21:05 dwarf.out
-rw-rw-rw- 1 root root 387181418 Jun 10 18:03 /var/crash/127.0.0.1-2025-06-10-18:03:12/vmcore
C) Discussion:
1) GPU types: Currently only tested with amdgpu's mm page filtering, others
are not tested.
2) Code structure: There are some similar code shared by makedumpfile and
crash, such as maple tree data structure, also I planed to port the
btf/kallsyms code to crash as well, so there are code duplications for
crash & makedumpfile. Since I havn't working on crash poring, code change
on btf/kallsyms is expected. How can we share the code, creating a common
library or keep the duplication as it is?
3) OS: The code can work on rhel-10+/rhel9.5+ on x86_64/arm64/s390/ppc64.
Others are not tested.
D) Testing:
1) If you don't want to create your vmcore, you can find a vmcore which I
created with amdgpu mm pages unfiltered [1], the amdgpu mm pages are
allocated by program [2]. You can use the vmcore in 1st kernel to filter
the amdgpu mm pages by the previous performance testing cmdline. To
verify the pages are filtered in crash:
Unfiltered:
crash> search -c "!QAZXSW@#EDC"
ffff96b7fa800000: !QAZXSW@#EDCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ffff96b87c800000: !QAZXSW@#EDCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
crash> rd ffff96b7fa800000
ffff96b7fa800000: 405753585a415121 !QAZXSW@
crash> rd ffff96b87c800000
ffff96b87c800000: 405753585a415121 !QAZXSW@
Filtered:
crash> search -c "!QAZXSW@#EDC"
crash> rd ffff96b7fa800000
rd: page excluded: kernel virtual address: ffff96b7fa800000 type: "64-bit KVADDR"
crash> rd ffff96b87c800000
rd: page excluded: kernel virtual address: ffff96b87c800000 type: "64-bit KVADDR"
2) You can use eppic_scripts/print_all_vma.c against an ordinary vmcore to
test only btf/kallsyms functions by output all VMAs if no amdgpu
vmcores/machine avaliable.
[1]: https://people.redhat.com/~ltao/core/
[2]: https://gist.github.com/liutgnu/a8cbce1c666452f1530e1410d1f352df
Tao Liu (10):
dwarf_info: Support kernel address randomization
dwarf_info: Fix a infinite recursion bug for search_domain
Add page filtering function
Add btf/kallsyms support for symbol type/address resolving
Export necessary btf/kallsyms functions to eppic extension
Port the maple tree data structures and functions
Supporting main() as the entry of eppic script
Enable page filtering for dwarf eppic
Enable page filtering for btf/kallsyms eppic
Introducing 2 eppic scripts to test the dwarf/btf eppic extension
Makefile | 6 +-
btf.c | 919 +++++++++++++++++++++++++
btf.h | 176 +++++
dwarf_info.c | 15 +-
eppic_maple.c | 431 ++++++++++++
eppic_maple.h | 8 +
eppic_scripts/filter_amdgpu_mm_pages.c | 36 +
eppic_scripts/print_all_vma.c | 29 +
erase_info.c | 123 +++-
erase_info.h | 22 +
extension_btf.c | 218 ++++++
extension_eppic.c | 41 +-
extension_eppic.h | 6 +-
kallsyms.c | 371 ++++++++++
kallsyms.h | 42 ++
makedumpfile.c | 21 +-
makedumpfile.h | 11 +
17 files changed, 2448 insertions(+), 27 deletions(-)
create mode 100644 btf.c
create mode 100644 btf.h
create mode 100644 eppic_maple.c
create mode 100644 eppic_maple.h
create mode 100644 eppic_scripts/filter_amdgpu_mm_pages.c
create mode 100644 eppic_scripts/print_all_vma.c
create mode 100644 extension_btf.c
create mode 100644 kallsyms.c
create mode 100644 kallsyms.h
--
2.47.0
2 weeks, 3 days
- 1
- 10
- ← Newer
- 1
- Older →