From matthewc at axis.com Fri Mar 1 11:29:19 2024 From: matthewc at axis.com (Matthew Chae) Date: Fri, 1 Mar 2024 12:29:19 +0100 Subject: fix large PID overflow their column in top command In-Reply-To: <20240221212303.11038f5e@nbbrfq.loc> References: <4458638ee54e4ae7a47a9586de9b874d@AcuMS.aculab.com> <20240213191635.624115f4@nbbrfq.loc> <20240215214614.0c6047ce@nbbrfq.loc> <20240221212303.11038f5e@nbbrfq.loc> Message-ID: On 2/21/24 21:23, Bernhard Reutner-Fischer wrote: > Hi Sukyoung! > > please don't top-post > > On Mon, 19 Feb 2024 10:22:05 +0000 > Matthew Chae wrote: > >> Hi Bernhard, >> >> I'm sending new patch and the result of bloatcheck. >> For me, this size is reduced to 135 bytes. What do you think? > > Well, 135b is better than the initial 360b :) > >> Can you take a look at these attachments? > > I'd love to. > But it doesn't apply, unfortunately: > $ git am -s 0004-Allocate-PID-PPID-space-dynamically-in-top-command.patch > Applying: Allocate PID/PPID space dynamically in top command > error: patch failed: procps/top.c:637 > error: procps/top.c: patch does not apply > Patch failed at 0001 Allocate PID/PPID space dynamically in top command > hint: Use 'git am --show-current-patch=diff' to see the failed patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > $ git am --abort > $ patch -p1 -i 0004-Allocate-PID-PPID-space-dynamically-in-top-command.patch > patching file procps/top.c > Hunk #1 FAILED at 637. > Hunk #2 FAILED at 696. > Hunk #3 FAILED at 709. > 3 out of 3 hunks FAILED -- saving rejects to file procps/top.c.rej > > So I'd have to manually fiddle the patch to apply, which i honestly > don't have time for ATM, as much as i love code-golf in general. > It?s very strange. Anyway, I'm sorry for causing you inconvenience. At least now it shows successful results like below. git am -s 0005-Allocate-PID-PPID-space-dynamically-in-top-command.patch Applying: Allocate PID/PPID space dynamically in top command Plus, the size is reduced more. It shows 115 bytes. You can check this in the bloatcheck_result file. > Furthermore (and i'm about to update https://busybox.net/developer > accordingly), for legal reasons, we require a Signed-off-by, as > detailed in > https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=sign%20off#sign-your-work-the-developer-s-certificate-of-origin > so please check you legal department (which should be fine for axis) > and mark your contributions accordingly by 'git commit -s ...' iff this > is in line with your legal situation (again, axis legal will most > likely understand what this is about without much further ado, AFAIK). I already added this in the previous patch. Can you check the attachment? If I'm missing something, please let me know. > >> >> PS: >> The function of count_digits() is implemented inside of display_process_list(). >> To reduce the size, strlen() is not used. > > Did you look if manually outlining count_digits() like you did in the > previous version is beneficial? > I don?t think outlining count_digits() is beneficial now. It appears that, at least until now, there is no use case within BusyBox for counting the digits of an integer variable. In terms of size as well, using strlen() and utoa() as in the attached code appears to be more advantageous. BTW, using make_human_readable_str() in the approach you recommended does not seem appropriate for calculating the number of digits. (pid_len = strlen(make_human_readable_str(pid_max,0,0)) If I misunderstood, please let me know. > And, did you check my previous question if it is better to use the > manual buf "painting", perusing in this case pid_len (for the > compile-time constant 6 as it is now) and ppid_len (ditto), and, for > your other patch on top, username_len (for the current compile-time > constant 8)? The loop to determine the max {,p}pid len is not for free > of course, so it's okish if that manifests size-wise. > When large numbers are assigned to PID and PPID, they occupy many digits, leading to overflow in the PID and PPID columns. Consequently, it becomes impossible to display the entire data accurately and neatly. Additionally, a significant portion of the user name may get truncated, providing very limited information about the user name. By using this patch, although the loop is not for free, it allows for the very accurate display of results from the top command. Furthermore, the size is reduced to an appropriate level(115 bytes), enabling very efficient results with minimal investment." Below is an example of how it can be improved. Before: PID PPID USER 4876586 4394176 busy After: PID PPID USER 4876548 4394517 busybox > PS: 135b is better than the initial suggestion of ~300b, but given > architectures tend to end up with very different codegen per arch and > compilers used, i'm always curious which arch and which compiler > (version) was used to obtain the alleged results. Guess you target > chris with gcc-12-ish? > Stating the target arch usually allows us a rough estimate > about overall impact on other arches. I?m giving you the arch and compiler information below. C Compiler: gcc -> gcc-10* ARCH x86_64 > > Many thanks in advance and cheers, > Bernhard > >> >> Br-Matthew >> >> ________________________________ >> From: Bernhard Reutner-Fischer >> Sent: Thursday, February 15, 2024 9:46 PM >> To: Matthew Chae >> Cc: rep.dot.nop at gmail.com ; David Laight ; 'Denys Vlasenko' ; busybox at busybox.net ; Christopher Wong >> Subject: Re: fix large PID overflow their column in top command >> >> On Wed, 14 Feb 2024 14:05:15 +0000 >> Matthew Chae wrote: >> >>> Hi Bernhard, >>> >>> I'm sending new patch and the result of bloatcheck. >> >> Many thanks for the updated patch! >> >> function old new delta >> display_process_list 1406 1765 +359 >> .rodata 99721 99724 +3 >> ------------------------------------------------------------------------------ >> (add/remove: 0/0 grow/shrink: 2/0 up/down: 362/0) Total: 362 bytes >> text data bss dec hex filename >> 1009548 16507 1840 1027895 faf37 busybox_old >> 1009910 16507 1840 1028257 fb0a1 busybox_unstripped >> >> I think that's too much. For me this gives +293 bytes, still way too much. >> Can you please see if it helps to retain the manual formatting of >> PID PPID USER? >> >> PS: >> >> procps/top.c: In function ?display_process_list?: >> procps/top.c:664:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] >> 664 | typedef struct { unsigned quot, rem; } bb_div_t; >> | ^~~~~~~ >> >> so please move your new #define PID_STR block down to right before >> /* what info of the processes is shown */ >> >> In >> + int lines = (lines_rem - 1); >> please drop the superfluous braces. >> >> It is most likely not smaller to use >> pid_len = strlen(make_human_readable_str(pid_max,0,0)) >> than to introduce this private count_digits(), i fear? >> Maybe we could amortize the addition of count_digits by >> reusing it elsewhere, as a follow-up. >> >> thanks >> >>> Can you review these and give me your thoughts? >>> Just let me know if you think that the code size needs to be reduced. >>> >>> Br-Matthew >>> ________________________________ >>> From: Bernhard Reutner-Fischer >>> Sent: Tuesday, February 13, 2024 7:16 PM >>> To: Matthew Chae >>> Cc: rep.dot.nop at gmail.com ; David Laight ; 'Denys Vlasenko' ; busybox at busybox.net ; Christopher Wong >>> Subject: Re: fix large PID overflow their column in top command >>> >>> On Mon, 5 Feb 2024 09:56:20 +0000 >>> Matthew Chae wrote: >>> >>>> Hi David, >>>> >>>> I'm sending an improved patch based on your comments. >>>> >>>> Not only does it not care about the PID_MAX value, >>>> it searches all the contents to be output to recognize the required column width >>>> and dynamically allocates the space for PID and PPID appropriately without creating a lot of empty space. >>>> >>>> Additionally, this patch still allows user names to be displayed up to 8 characters without truncation. >>>> >>>> Can you look through the attachment? >>> >>> Unfortunately the patch does not apply to current master. >>> How much would your patch add to the size? Can you bring it down to a >>> minimum? >>> See make baseline; apply the patch;make bloatcheck >>> >>> thanks >>> >>>> (0002-Allocate-PID-PPID-space-dynamically-in-top-command.patch) >>>> >>>> BR-Matthew Chae >>>> ________________________________ >>>> From: David Laight >>>> Sent: Thursday, November 23, 2023 6:10 PM >>>> To: 'Denys Vlasenko' ; Matthew Chae >>>> Cc: busybox at busybox.net ; Christopher Wong >>>> Subject: RE: fix large PID overflow their column in top command >>>> >>>> ... >>>>> + fp = xfopen_for_read("/proc/sys/kernel/pid_max"); >>>>> + if (!fgets(pid_buf, PID_DIGITS_MAX + 1, fp)) { >>>>> ... >>>>> + if (strncmp(pid_buf, "32768", 5) == 0) >>>>> + pid_digits_num = 5; >>>>> + else >>>>> + pid_digits_num = PID_DIGITS_MAX; >>>>> >>>>> The logic above is not sound. Even if sysctl kernel.pid_max >>>>> is 32768, there can be already running processes with pids > 99999. >>>> >>>> It's also probably wrong for pretty much all other values. >>>> >>>> I'd just base the column width on strlen(pid_buf) with a minimum >>>> value of 5. >>>> >>>> It is unlikely that pid_max has been reduced - so column overflow >>>> it that case probably doesn't really matter. >>>> >>>> The more interesting case is really a system with a very large pid_max >>>> that has never run many processes. >>>> You don't really want lots of blank space. >>>> >>>> I can't remember whether top reads everything before doing any output? >>>> Since the output is sorted it probably almost always does. >>>> In which case it knows the column width it will need. >>>> >>>> I did post a patch a while back that enabled 'Irix mode'. >>>> (100% cpu is one cpu at 100%, not all cpus at 100%) >>>> Maybe I should dig it out again. >>>> >>>> David >>>> >>>> - >>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK >>>> Registration No: 1397386 (Wales) >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Allocate-PID-PPID-space-dynamically-in-top-command.patch Type: text/x-patch Size: 3723 bytes Desc: not available URL: -------------- next part -------------- function old new delta display_process_list 1406 1503 +97 .rodata 99900 99918 +18 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/0 up/down: 115/0) Total: 115 bytes text data bss dec hex filename 1011743 16507 1840 1030090 fb7ca busybox_old 1011858 16507 1840 1030205 fb83d busybox_unstripped From matthewc at axis.com Fri Mar 1 11:36:41 2024 From: matthewc at axis.com (Matthew Chae) Date: Fri, 1 Mar 2024 12:36:41 +0100 Subject: fix large PID overflow their column in top command In-Reply-To: References: <4458638ee54e4ae7a47a9586de9b874d@AcuMS.aculab.com> <20240213191635.624115f4@nbbrfq.loc> <20240215214614.0c6047ce@nbbrfq.loc> <20240221212303.11038f5e@nbbrfq.loc> Message-ID: <1fa111d8-6265-47e0-a0f7-2ffb5bbce8b4@axis.com> On 3/1/24 12:29, Matthew Chae wrote: > On 2/21/24 21:23, Bernhard Reutner-Fischer wrote: >> Hi Sukyoung! >> >> please don't top-post >> >> On Mon, 19 Feb 2024 10:22:05 +0000 >> Matthew Chae wrote: >> >>> Hi Bernhard, >>> >>> I'm sending new patch and the result of bloatcheck. >>> For me, this size is reduced to 135 bytes. What do you think? >> >> Well, 135b is better than the initial 360b :) >> >>> Can you take a look at these attachments? >> >> I'd love to. >> But it doesn't apply, unfortunately: >> $ git am -s 0004-Allocate-PID-PPID-space-dynamically-in-top-command.patch >> Applying: Allocate PID/PPID space dynamically in top command >> error: patch failed: procps/top.c:637 >> error: procps/top.c: patch does not apply >> Patch failed at 0001 Allocate PID/PPID space dynamically in top command >> hint: Use 'git am --show-current-patch=diff' to see the failed patch >> When you have resolved this problem, run "git am --continue". >> If you prefer to skip this patch, run "git am --skip" instead. >> To restore the original branch and stop patching, run "git am --abort". >> $ git am --abort >> $ patch -p1 -i >> 0004-Allocate-PID-PPID-space-dynamically-in-top-command.patch >> patching file procps/top.c >> Hunk #1 FAILED at 637. >> Hunk #2 FAILED at 696. >> Hunk #3 FAILED at 709. >> 3 out of 3 hunks FAILED -- saving rejects to file procps/top.c.rej >> >> So I'd have to manually fiddle the patch to apply, which i honestly >> don't have time for ATM, as much as i love code-golf in general. >> > It?s very strange. Anyway, I'm sorry for causing you inconvenience. > At least now it shows successful results like below. > > git am -s 0005-Allocate-PID-PPID-space-dynamically-in-top-command.patch > Applying: Allocate PID/PPID space dynamically in top command > > Plus, the size is reduced more. It shows 115 bytes. You can check this > in the bloatcheck_result file. > >> Furthermore (and i'm about to update https://busybox.net/developer >> accordingly), for legal reasons, we require a Signed-off-by, as >> detailed in >> https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=sign%20off#sign-your-work-the-developer-s-certificate-of-origin >> so please check you legal department (which should be fine for axis) >> and mark your contributions accordingly by 'git commit -s ...' iff this >> is in line with your legal situation (again, axis legal will most >> likely understand what this is about without much further ado, AFAIK). > I already added this in the previous patch. Can you check the > attachment? If I'm missing something, please let me know. > >> >>> >>> PS: >>> The function of count_digits() is implemented inside of >>> display_process_list(). >>> To reduce the size, strlen() is not used. >> >> Did you look if manually outlining count_digits() like you did in the >> previous version is beneficial? >> > I don?t think outlining count_digits() is beneficial now. It appears > that, at least until now, there is no use case within BusyBox for > counting the digits of an integer variable. In terms of size as well, > using strlen() and utoa() as in the attached code appears to be more > advantageous. BTW, using make_human_readable_str() in the approach you > recommended does not seem appropriate for calculating the number of > digits. (pid_len = strlen(make_human_readable_str(pid_max,0,0)) > If I misunderstood, please let me know. > >> And, did you check my previous question if it is better to use the >> manual buf "painting", perusing in this case pid_len (for the >> compile-time constant 6 as it is now) and ppid_len (ditto), and, for >> your other patch on top, username_len (for the current compile-time >> constant 8)? The loop to determine the max {,p}pid len is not for free >> of course, so it's okish if that manifests size-wise. >> > When large numbers are assigned to PID and PPID, they occupy many > digits, leading to overflow in the PID and PPID columns. Consequently, > it becomes impossible to display the entire data accurately and neatly. > Additionally, a significant portion of the user name may get truncated, > providing very limited information about the user name. By using this > patch, although the loop is not for free, it allows for the very > accurate display of results from the top command. Furthermore, the size > is reduced to an appropriate level(115 bytes), enabling very efficient > results with minimal investment." > > Below is an example of how it can be improved. > Before: > ? PID? PPID USER > 4876586 4394176 busy > > After: > ?? PID??? PPID USER > 4876548 4394517 busybox This example appears well-organized in Thunderbird as I intended, but it does not appear to be aligned properly in Outlook. If any recipients use Outlook to view this example, please ignore this example. > >> PS: 135b is better than the initial suggestion of ~300b, but given >> architectures tend to end up with very different codegen per arch and >> compilers used, i'm always curious which arch and which compiler >> (version) was used to obtain the alleged results. Guess you target >> chris with gcc-12-ish? >> Stating the target arch usually allows us a rough estimate >> about overall impact on other arches. > > I?m giving you the arch and compiler information below. > C Compiler: gcc -> gcc-10* > ARCH x86_64 > >> >> Many thanks in advance and cheers, >> Bernhard >> >>> >>> Br-Matthew >>> >>> ________________________________ >>> From: Bernhard Reutner-Fischer >>> Sent: Thursday, February 15, 2024 9:46 PM >>> To: Matthew Chae >>> Cc: rep.dot.nop at gmail.com ; David Laight >>> ; 'Denys Vlasenko' >>> ; busybox at busybox.net >>> ; Christopher Wong >>> Subject: Re: fix large PID overflow their column in top command >>> >>> On Wed, 14 Feb 2024 14:05:15 +0000 >>> Matthew Chae wrote: >>> >>>> Hi Bernhard, >>>> >>>> I'm sending new patch and the result of bloatcheck. >>> >>> Many thanks for the updated patch! >>> >>> function???????????????????????????????????????????? old???? new?? delta >>> display_process_list??????????????????????????????? 1406??? 1765??? +359 >>> .rodata??????????????????????????????????????????? 99721?? 99724????? +3 >>> ------------------------------------------------------------------------------ >>> (add/remove: 0/0 grow/shrink: 2/0 up/down: 362/0)???????????? Total: >>> 362 bytes >>> ??? text??? data????? bss????? dec????? hex? filename >>> 1009548?? 16507???? 1840? 1027895?? faf37? busybox_old >>> 1009910?? 16507???? 1840? 1028257?? fb0a1 busybox_unstripped >>> >>> I think that's too much. For me this gives +293 bytes, still way too >>> much. >>> Can you please see if it helps to retain the manual formatting of >>> PID PPID USER? >>> >>> PS: >>> >>> procps/top.c: In function ?display_process_list?: >>> procps/top.c:664:1: warning: ISO C90 forbids mixed declarations and >>> code [-Wdeclaration-after-statement] >>> ?? 664 | typedef struct { unsigned quot, rem; } bb_div_t; >>> ?????? | ^~~~~~~ >>> >>> so please move your new #define PID_STR block down to right before >>> /* what info of the processes is shown */ >>> >>> In >>> +?????? int lines = (lines_rem - 1); >>> please drop the superfluous braces. >>> >>> It is most likely not smaller to use >>> pid_len = strlen(make_human_readable_str(pid_max,0,0)) >>> than to introduce this private count_digits(), i fear? >>> Maybe we could amortize the addition of count_digits by >>> reusing it elsewhere, as a follow-up. >>> >>> thanks >>> >>>> Can you review these and give me your thoughts? >>>> Just let me know if you think that the code size needs to be reduced. >>>> >>>> Br-Matthew >>>> ________________________________ >>>> From: Bernhard Reutner-Fischer >>>> Sent: Tuesday, February 13, 2024 7:16 PM >>>> To: Matthew Chae >>>> Cc: rep.dot.nop at gmail.com ; David Laight >>>> ; 'Denys Vlasenko' >>>> ; busybox at busybox.net >>>> ; Christopher Wong >>>> Subject: Re: fix large PID overflow their column in top command >>>> >>>> On Mon, 5 Feb 2024 09:56:20 +0000 >>>> Matthew Chae wrote: >>>> >>>>> Hi David, >>>>> >>>>> I'm sending an improved patch based on your comments. >>>>> >>>>> Not only does it not care about the PID_MAX value, >>>>> it searches all the contents to be output to recognize the required >>>>> column width >>>>> and dynamically allocates the space for PID and PPID appropriately >>>>> without creating a lot of empty space. >>>>> >>>>> Additionally, this patch still allows user names to be displayed up >>>>> to 8 characters without truncation. >>>>> >>>>> Can you look through the attachment? >>>> >>>> Unfortunately the patch does not apply to current master. >>>> How much would your patch add to the size? Can you bring it down to a >>>> minimum? >>>> See make baseline; apply the patch;make bloatcheck >>>> >>>> thanks >>>> >>>>> (0002-Allocate-PID-PPID-space-dynamically-in-top-command.patch) >>>>> >>>>> BR-Matthew Chae >>>>> ________________________________ >>>>> From: David Laight >>>>> Sent: Thursday, November 23, 2023 6:10 PM >>>>> To: 'Denys Vlasenko' ; Matthew Chae >>>>> >>>>> Cc: busybox at busybox.net ; Christopher Wong >>>>> >>>>> Subject: RE: fix large PID overflow their column in top command >>>>> >>>>> ... >>>>>> +?????? fp = xfopen_for_read("/proc/sys/kernel/pid_max"); >>>>>> +?????? if (!fgets(pid_buf, PID_DIGITS_MAX + 1, fp)) { >>>>>> ... >>>>>> +?????? if (strncmp(pid_buf, "32768", 5) == 0) >>>>>> +?????????????? pid_digits_num = 5; >>>>>> +?????? else >>>>>> +?????????????? pid_digits_num = PID_DIGITS_MAX; >>>>>> >>>>>> The logic above is not sound. Even if sysctl kernel.pid_max >>>>>> is 32768, there can be already running processes with pids > 99999. >>>>> >>>>> It's also probably wrong for pretty much all other values. >>>>> >>>>> I'd just base the column width on strlen(pid_buf) with a minimum >>>>> value of 5. >>>>> >>>>> It is unlikely that pid_max has been reduced - so column overflow >>>>> it that case probably doesn't really matter. >>>>> >>>>> The more interesting case is really a system with a very large pid_max >>>>> that has never run many processes. >>>>> You don't really want lots of blank space. >>>>> >>>>> I can't remember whether top reads everything before doing any output? >>>>> Since the output is sorted it probably almost always does. >>>>> In which case it knows the column width it will need. >>>>> >>>>> I did post a patch a while back that enabled 'Irix mode'. >>>>> (100% cpu is one cpu at 100%, not all cpus at 100%) >>>>> Maybe I should dig it out again. >>>>> >>>>> ???????? David >>>>> >>>>> - >>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton >>>>> Keynes, MK1 1PT, UK >>>>> Registration No: 1397386 (Wales) >>>> >>> >> From matthewc at axis.com Fri Mar 1 11:53:41 2024 From: matthewc at axis.com (Matthew Chae) Date: Fri, 1 Mar 2024 12:53:41 +0100 Subject: fix large PID overflow their column in top command In-Reply-To: <1fa111d8-6265-47e0-a0f7-2ffb5bbce8b4@axis.com> References: <4458638ee54e4ae7a47a9586de9b874d@AcuMS.aculab.com> <20240213191635.624115f4@nbbrfq.loc> <20240215214614.0c6047ce@nbbrfq.loc> <20240221212303.11038f5e@nbbrfq.loc> <1fa111d8-6265-47e0-a0f7-2ffb5bbce8b4@axis.com> Message-ID: <55a05fe3-b60f-467a-9c71-084f8e6100d4@axis.com> On 3/1/24 12:36, Matthew Chae wrote: > On 3/1/24 12:29, Matthew Chae wrote: >> On 2/21/24 21:23, Bernhard Reutner-Fischer wrote: >>> Hi Sukyoung! >>> >>> please don't top-post >>> >>> On Mon, 19 Feb 2024 10:22:05 +0000 >>> Matthew Chae wrote: >>> >>>> Hi Bernhard, >>>> >>>> I'm sending new patch and the result of bloatcheck. >>>> For me, this size is reduced to 135 bytes. What do you think? >>> >>> Well, 135b is better than the initial 360b :) >>> >>>> Can you take a look at these attachments? >>> >>> I'd love to. >>> But it doesn't apply, unfortunately: >>> $ git am -s >>> 0004-Allocate-PID-PPID-space-dynamically-in-top-command.patch >>> Applying: Allocate PID/PPID space dynamically in top command >>> error: patch failed: procps/top.c:637 >>> error: procps/top.c: patch does not apply >>> Patch failed at 0001 Allocate PID/PPID space dynamically in top command >>> hint: Use 'git am --show-current-patch=diff' to see the failed patch >>> When you have resolved this problem, run "git am --continue". >>> If you prefer to skip this patch, run "git am --skip" instead. >>> To restore the original branch and stop patching, run "git am --abort". >>> $ git am --abort >>> $ patch -p1 -i >>> 0004-Allocate-PID-PPID-space-dynamically-in-top-command.patch >>> patching file procps/top.c >>> Hunk #1 FAILED at 637. >>> Hunk #2 FAILED at 696. >>> Hunk #3 FAILED at 709. >>> 3 out of 3 hunks FAILED -- saving rejects to file procps/top.c.rej >>> >>> So I'd have to manually fiddle the patch to apply, which i honestly >>> don't have time for ATM, as much as i love code-golf in general. >>> >> It?s very strange. Anyway, I'm sorry for causing you inconvenience. >> At least now it shows successful results like below. >> >> git am -s 0005-Allocate-PID-PPID-space-dynamically-in-top-command.patch >> Applying: Allocate PID/PPID space dynamically in top command >> >> Plus, the size is reduced more. It shows 115 bytes. You can check this >> in the bloatcheck_result file. >> >>> Furthermore (and i'm about to update https://busybox.net/developer >>> accordingly), for legal reasons, we require a Signed-off-by, as >>> detailed in >>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=sign%20off#sign-your-work-the-developer-s-certificate-of-origin >>> so please check you legal department (which should be fine for axis) >>> and mark your contributions accordingly by 'git commit -s ...' iff this >>> is in line with your legal situation (again, axis legal will most >>> likely understand what this is about without much further ado, AFAIK). >> I already added this in the previous patch. Can you check the >> attachment? If I'm missing something, please let me know. >> >>> >>>> >>>> PS: >>>> The function of count_digits() is implemented inside of >>>> display_process_list(). >>>> To reduce the size, strlen() is not used. >>> >>> Did you look if manually outlining count_digits() like you did in the >>> previous version is beneficial? >>> >> I don?t think outlining count_digits() is beneficial now. It appears >> that, at least until now, there is no use case within BusyBox for >> counting the digits of an integer variable. In terms of size as well, >> using strlen() and utoa() as in the attached code appears to be more >> advantageous. BTW, using make_human_readable_str() in the approach you >> recommended does not seem appropriate for calculating the number of >> digits. (pid_len = strlen(make_human_readable_str(pid_max,0,0)) >> If I misunderstood, please let me know. >> >>> And, did you check my previous question if it is better to use the >>> manual buf "painting", perusing in this case pid_len (for the >>> compile-time constant 6 as it is now) and ppid_len (ditto), and, for >>> your other patch on top, username_len (for the current compile-time >>> constant 8)? The loop to determine the max {,p}pid len is not for free >>> of course, so it's okish if that manifests size-wise. >>> >> When large numbers are assigned to PID and PPID, they occupy many >> digits, leading to overflow in the PID and PPID columns. Consequently, >> it becomes impossible to display the entire data accurately and >> neatly. Additionally, a significant portion of the user name may get >> truncated, providing very limited information about the user name. By >> using this patch, although the loop is not for free, it allows for the >> very accurate display of results from the top command. Furthermore, >> the size is reduced to an appropriate level(115 bytes), enabling very >> efficient results with minimal investment." >> >> Below is an example of how it can be improved. >> Before: >> ?? PID? PPID USER >> 4876586 4394176 busy >> >> After: >> ??? PID??? PPID USER >> 4876548 4394517 busybox > > This example appears well-organized in Thunderbird as I intended, but it > does not appear to be aligned properly in Outlook. If any recipients use > Outlook to view this example, please ignore this example. > I apologize for the continued emails. When copying and pasting the results from the command prompt into Thunderbird or Outlook, the example appears much better organized than the actual result. In reality, the 'Before' results of the 'top' command are much less organized than they appear above. >> >>> PS: 135b is better than the initial suggestion of ~300b, but given >>> architectures tend to end up with very different codegen per arch and >>> compilers used, i'm always curious which arch and which compiler >>> (version) was used to obtain the alleged results. Guess you target >>> chris with gcc-12-ish? >>> Stating the target arch usually allows us a rough estimate >>> about overall impact on other arches. >> >> I?m giving you the arch and compiler information below. >> C Compiler: gcc -> gcc-10* >> ARCH x86_64 >> >>> >>> Many thanks in advance and cheers, >>> Bernhard >>> >>>> >>>> Br-Matthew >>>> >>>> ________________________________ >>>> From: Bernhard Reutner-Fischer >>>> Sent: Thursday, February 15, 2024 9:46 PM >>>> To: Matthew Chae >>>> Cc: rep.dot.nop at gmail.com ; David Laight >>>> ; 'Denys Vlasenko' >>>> ; busybox at busybox.net >>>> ; Christopher Wong >>>> Subject: Re: fix large PID overflow their column in top command >>>> >>>> On Wed, 14 Feb 2024 14:05:15 +0000 >>>> Matthew Chae wrote: >>>> >>>>> Hi Bernhard, >>>>> >>>>> I'm sending new patch and the result of bloatcheck. >>>> >>>> Many thanks for the updated patch! >>>> >>>> function???????????????????????????????????????????? old???? new >>>> delta >>>> display_process_list??????????????????????????????? 1406??? 1765 >>>> +359 >>>> .rodata??????????????????????????????????????????? 99721 >>>> 99724????? +3 >>>> ------------------------------------------------------------------------------ >>>> (add/remove: 0/0 grow/shrink: 2/0 up/down: 362/0)???????????? Total: >>>> 362 bytes >>>> ??? text??? data????? bss????? dec????? hex? filename >>>> 1009548?? 16507???? 1840? 1027895?? faf37? busybox_old >>>> 1009910?? 16507???? 1840? 1028257?? fb0a1 busybox_unstripped >>>> >>>> I think that's too much. For me this gives +293 bytes, still way too >>>> much. >>>> Can you please see if it helps to retain the manual formatting of >>>> PID PPID USER? >>>> >>>> PS: >>>> >>>> procps/top.c: In function ?display_process_list?: >>>> procps/top.c:664:1: warning: ISO C90 forbids mixed declarations and >>>> code [-Wdeclaration-after-statement] >>>> ?? 664 | typedef struct { unsigned quot, rem; } bb_div_t; >>>> ?????? | ^~~~~~~ >>>> >>>> so please move your new #define PID_STR block down to right before >>>> /* what info of the processes is shown */ >>>> >>>> In >>>> +?????? int lines = (lines_rem - 1); >>>> please drop the superfluous braces. >>>> >>>> It is most likely not smaller to use >>>> pid_len = strlen(make_human_readable_str(pid_max,0,0)) >>>> than to introduce this private count_digits(), i fear? >>>> Maybe we could amortize the addition of count_digits by >>>> reusing it elsewhere, as a follow-up. >>>> >>>> thanks >>>> >>>>> Can you review these and give me your thoughts? >>>>> Just let me know if you think that the code size needs to be reduced. >>>>> >>>>> Br-Matthew >>>>> ________________________________ >>>>> From: Bernhard Reutner-Fischer >>>>> Sent: Tuesday, February 13, 2024 7:16 PM >>>>> To: Matthew Chae >>>>> Cc: rep.dot.nop at gmail.com ; David Laight >>>>> ; 'Denys Vlasenko' >>>>> ; busybox at busybox.net >>>>> ; Christopher Wong >>>>> Subject: Re: fix large PID overflow their column in top command >>>>> >>>>> On Mon, 5 Feb 2024 09:56:20 +0000 >>>>> Matthew Chae wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> I'm sending an improved patch based on your comments. >>>>>> >>>>>> Not only does it not care about the PID_MAX value, >>>>>> it searches all the contents to be output to recognize the >>>>>> required column width >>>>>> and dynamically allocates the space for PID and PPID appropriately >>>>>> without creating a lot of empty space. >>>>>> >>>>>> Additionally, this patch still allows user names to be displayed >>>>>> up to 8 characters without truncation. >>>>>> >>>>>> Can you look through the attachment? >>>>> >>>>> Unfortunately the patch does not apply to current master. >>>>> How much would your patch add to the size? Can you bring it down to a >>>>> minimum? >>>>> See make baseline; apply the patch;make bloatcheck >>>>> >>>>> thanks >>>>> >>>>>> (0002-Allocate-PID-PPID-space-dynamically-in-top-command.patch) >>>>>> >>>>>> BR-Matthew Chae >>>>>> ________________________________ >>>>>> From: David Laight >>>>>> Sent: Thursday, November 23, 2023 6:10 PM >>>>>> To: 'Denys Vlasenko' ; Matthew Chae >>>>>> >>>>>> Cc: busybox at busybox.net ; Christopher Wong >>>>>> >>>>>> Subject: RE: fix large PID overflow their column in top command >>>>>> >>>>>> ... >>>>>>> +?????? fp = xfopen_for_read("/proc/sys/kernel/pid_max"); >>>>>>> +?????? if (!fgets(pid_buf, PID_DIGITS_MAX + 1, fp)) { >>>>>>> ... >>>>>>> +?????? if (strncmp(pid_buf, "32768", 5) == 0) >>>>>>> +?????????????? pid_digits_num = 5; >>>>>>> +?????? else >>>>>>> +?????????????? pid_digits_num = PID_DIGITS_MAX; >>>>>>> >>>>>>> The logic above is not sound. Even if sysctl kernel.pid_max >>>>>>> is 32768, there can be already running processes with pids > 99999. >>>>>> >>>>>> It's also probably wrong for pretty much all other values. >>>>>> >>>>>> I'd just base the column width on strlen(pid_buf) with a minimum >>>>>> value of 5. >>>>>> >>>>>> It is unlikely that pid_max has been reduced - so column overflow >>>>>> it that case probably doesn't really matter. >>>>>> >>>>>> The more interesting case is really a system with a very large >>>>>> pid_max >>>>>> that has never run many processes. >>>>>> You don't really want lots of blank space. >>>>>> >>>>>> I can't remember whether top reads everything before doing any >>>>>> output? >>>>>> Since the output is sorted it probably almost always does. >>>>>> In which case it knows the column width it will need. >>>>>> >>>>>> I did post a patch a while back that enabled 'Irix mode'. >>>>>> (100% cpu is one cpu at 100%, not all cpus at 100%) >>>>>> Maybe I should dig it out again. >>>>>> >>>>>> ???????? David >>>>>> >>>>>> - >>>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton >>>>>> Keynes, MK1 1PT, UK >>>>>> Registration No: 1397386 (Wales) >>>>> >>>> >>> > From rep.dot.nop at gmail.com Sat Mar 2 16:08:00 2024 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Sat, 2 Mar 2024 17:08:00 +0100 Subject: [V2 PATCH] crond: log5 fix typo, replace log level '4' with '5' In-Reply-To: References: Message-ID: <20240302170800.576fdaf5@nbbrfq.loc> On Thu, 1 Feb 2024 03:17:09 +0000 Jones Syue ??? wrote: > Found previous patch accidentally adds 'x' permission to file 'crond.c', > attached v2 patch would not change permissions of file 'crond.c', > thank you :) Applied, thanks! From rep.dot.nop at gmail.com Sat Mar 2 16:08:51 2024 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Sat, 2 Mar 2024 17:08:51 +0100 Subject: [PATCH] awk: fix segfault when compiled by clang In-Reply-To: <65aa981d.5TChNMNXWAYI/wWg%rmy@pobox.com> References: <65aa981d.5TChNMNXWAYI/wWg%rmy@pobox.com> Message-ID: <20240302170851.5e120752@nbbrfq.loc> On Fri, 19 Jan 2024 15:41:17 +0000 Ron Yorston wrote: > A 32-bit build of BusyBox using clang segfaulted in the test > "awk assign while assign". Specifically, on line 7 of the test > input where the adjustment of the L.v pointer when the Fields > array was reallocated > > L.v += Fields - old_Fields_ptr; > > was out by 4 bytes. > > Rearrange to code so both gcc and clang generate code that works. Applied, thanks! From dario.binacchi at amarulasolutions.com Sun Mar 3 10:21:55 2024 From: dario.binacchi at amarulasolutions.com (Dario Binacchi) Date: Sun, 3 Mar 2024 11:21:55 +0100 Subject: [RESEND PATCH 1/1] ip link: support for the CAN netlink In-Reply-To: References: <20240225091333.1553331-1-dario.binacchi@amarulasolutions.com> <20240225091333.1553331-2-dario.binacchi@amarulasolutions.com> Message-ID: Hello Denys, On Mon, Feb 26, 2024 at 2:13?PM Denys Vlasenko wrote: > > On Sun, Feb 25, 2024 at 10:13?AM Dario Binacchi > wrote: > > I developed this application to test the Linux kernel series [1]. As > > described in it I could not use the iproute2 package since the > > microcontroller is without MMU. > > I don't think we need to have "iplinkcan" applet. > (I'm not sure having the non-standard "iplink" et al was a good idea > in the first place) > Let's just use "ip link set type can ..." syntax only > > > > > + case ARG_restart: { > > + __u32 val = 1; > > + > > + NEXT_ARG(); > > + addattr_l(&req.n, sizeof(req), IFLA_CAN_RESTART, &val, sizeof(val)); > > + break; > > + } > > Why NEXT_ARG()? "restart" has no parameters, right? You are right. Do I need to make a patch to remove the comment? Or does it not matter? I reran the tests for my use cases. Everything is okay. Thanks for the review and having merged the patch Thanks and regards, Dario > > I'm applying your patch with some changes. > Please try current git. -- Dario Binacchi Senior Embedded Linux Developer dario.binacchi at amarulasolutions.com __________________________________ Amarula Solutions SRL Via Le Canevare 30, 31100 Treviso, Veneto, IT T. +39 042 243 5310 info at amarulasolutions.com www.amarulasolutions.com From rob at landley.net Mon Mar 4 23:34:35 2024 From: rob at landley.net (Rob Landley) Date: Mon, 4 Mar 2024 17:34:35 -0600 Subject: Heads up, mv -x (--swap) option. Message-ID: FYI it was added to coreutils here: https://github.com/coreutils/coreutils/commit/6cd2d5e5335b And toybox here: https://github.com/landley/toybox/commit/a2419ad52d48 mv -x takes exactly two arguments and calls: renameat2(AT_FDCWD, argv[1], AT_FDCWD, argv[2], RENAME_EXCHANGE); Which does an atomic exchange. Rob P.S. My toybox patch is fluffy because I support building a subset of the commands on freebsd and macos, and didn't want to break cp/mv/install there calling a linux-only syscall/flag, so I added a wrapper to lib/portability.c to quarrantine the #ifdef. Both the syscall and the exchange flag for it were added to linux in 2014, so maybe they've caught up by now or have an equivalent? Dunno. I tweaked some help text while I was there, 80% of that patch is basically noise to you guys. I haven't actually looked at the coreutils patch because gplv3... From Brett.Allen at pega.com Tue Mar 5 00:17:40 2024 From: Brett.Allen at pega.com (Allen, Brett) Date: Tue, 5 Mar 2024 00:17:40 +0000 Subject: [PATCH] awk.c: fix CVE-2023-42366 (bug #15874) Message-ID: Hi All ? I noticed the patch below was submitted to Bugzilla but I didn?t see it get posted to this list. I was checking for a fix to CVE-2023-42366 so wanted to ensure it wasn?t overlooked. >From 5cf8b332429a1dd9afef3337bae92aeddaeff993 Mon Sep 17 00:00:00 2001 From: Valery Ushakov uwe at stderr.spb.ru Date: Wed, 24 Jan 2024 22:24:41 +0300 Subject: [PATCH] awk.c: fix CVE-2023-42366 (bug #15874) Make sure we don't read past the end of the string in next_token() when backslash is the last character in an (invalid) regexp. --- editors/awk.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/editors/awk.c b/editors/awk.c index 728ee8685..be48df7c7 100644 --- a/editors/awk.c +++ b/editors/awk.c @@ -1165,9 +1165,11 @@ static uint32_t next_token(uint32_t expected) s[-1] = bb_process_escape_sequence((const char **)&pp); if (*p == '\\') *s++ = '\\'; - if (pp == p) + if (pp == p) { + if (*p == '\0') + syntax_error(EMSG_UNEXP_EOS); *s++ = *p++; - else + } else p = pp; } } -- 2.34.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daggs at gmx.com Fri Mar 8 18:53:34 2024 From: daggs at gmx.com (daggs) Date: Fri, 8 Mar 2024 19:53:34 +0100 Subject: listing partguid of a device Message-ID: Greetings, I wonder if there is a way to use busybox to list partguid of a device? busybox's blkid cannot do it while stock blkid can. Thanks. From jonessyue at qnap.com Mon Mar 11 09:40:38 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Mon, 11 Mar 2024 09:40:38 +0000 Subject: [PATCH] bloat-o-meter: line wrapped at 75 columns instead of 80 Message-ID: This patch replaces the 78 "-" prints with 75 "-". And replace the 80 columns summary line with 77 columns. ("%s" is considered as two chars and should be filled with whitespace " ", so 77 = 75 + 2) Consider this senario: a patch contains the output of "bloat-o-meter" to clarify about the size impact/diff, and when we validate this patch with "~/linux/scripts/checkpatch.pl" (from linux kernel source tree), which checks for style violations, it might complain about line wrapped like:[1] WARNING: \ Possible unwrapped commit description (prefer a maximum 75 chars per line) The 1st complaint is seperation line with 78 '-' prints, and the 2nd complaint is summary line "(add/remove ... Total: n bytes)". Although these two warnings are not harmful at all, it is helpful and makes life easier if this kind of patch (with "bloat-o-meter" output) could be passed by 'checkpatch.pl' in the first place without manually inspection. [1] line wrapped at 75 columns: https://www.kernel.org/doc/html/latest/process/submitting-patches.html Signed-off-by: Jones Syue --- scripts/bloat-o-meter | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/bloat-o-meter b/scripts/bloat-o-meter index b4a1d28113b0..7fe4a06ae19e 100755 --- a/scripts/bloat-o-meter +++ b/scripts/bloat-o-meter @@ -130,10 +130,10 @@ for d, n in delta: old_sz = old.get(n, {}).get("size", "-") new_sz = new.get(n, {}).get("size", "-") print("%-48s %7s %7s %+7d" % (n, old_sz, new_sz, d)) -print("-"*78) +print("-"*75) total="(add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s)%%sTotal: %s bytes"\ % (add, remove, grow, shrink, up, -down, up-down) -print(total % (" "*(80-len(total)))) +print(total % (" "*(77-len(total)))) if flag_timing: print("\n%d/%d; %d Parse origin/new; processing nsecs" % (end_t1-start_t1, end_t2-start_t2, end_t3-start_t3)) -- 2.1.4 From jonessyue at qnap.com Mon Mar 11 09:48:59 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Mon, 11 Mar 2024 09:48:59 +0000 Subject: [PATCH] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: Message-ID: > Consider this senario: a patch contains the output of "bloat-o-meter" to Ohh by bad, found a nit/typo by checkpatch.pl, will come out next v2 ;) WARNING: 'senario' may be misspelled - perhaps 'scenario'? #10: Consider this senario: a patch contains the output of "bloat-o-meter" to ^^^^^^^ total: 0 errors, 1 warnings, 12 lines checked -- Regards, Jones Syue | ??? QNAP Systems, Inc. From jonessyue at qnap.com Mon Mar 11 09:55:55 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Mon, 11 Mar 2024 09:55:55 +0000 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 Message-ID: This patch replaces the 78 "-" prints with 75 "-". And replace the 80 columns summary line with 77 columns. ("%s" is considered as two chars and should be filled with whitespace " ", so 77 = 75 + 2) Consider this scenario: a patch contains the output of "bloat-o-meter" to clarify about the size impact/diff, and when we validate this patch with "~/linux/scripts/checkpatch.pl" (from linux kernel source tree), which checks for style violations, it might complain about line wrapped like:[1] WARNING: \ Possible unwrapped commit description (prefer a maximum 75 chars per line) The 1st complaint is seperation line with 78 '-' prints, and the 2nd complaint is summary line "(add/remove ... Total: n bytes)". Although these two warnings are not harmful at all, it is helpful and makes life easier if this kind of patch (with "bloat-o-meter" output) could be passed by 'checkpatch.pl' in the first place without manually inspection. [1] line wrapped at 75 columns: https://www.kernel.org/doc/html/latest/process/submitting-patches.html Signed-off-by: Jones Syue --- v2: - fix nit/typo with correct word 'scenario' v1: http://lists.busybox.net/pipermail/busybox/2024-March/090656.html --- scripts/bloat-o-meter | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/bloat-o-meter b/scripts/bloat-o-meter index b4a1d28113b0..7fe4a06ae19e 100755 --- a/scripts/bloat-o-meter +++ b/scripts/bloat-o-meter @@ -130,10 +130,10 @@ for d, n in delta: old_sz = old.get(n, {}).get("size", "-") new_sz = new.get(n, {}).get("size", "-") print("%-48s %7s %7s %+7d" % (n, old_sz, new_sz, d)) -print("-"*78) +print("-"*75) total="(add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s)%%sTotal: %s bytes"\ % (add, remove, grow, shrink, up, -down, up-down) -print(total % (" "*(80-len(total)))) +print(total % (" "*(77-len(total)))) if flag_timing: print("\n%d/%d; %d Parse origin/new; processing nsecs" % (end_t1-start_t1, end_t2-start_t2, end_t3-start_t3)) -- 2.1.4 From explorer09 at gmail.com Mon Mar 11 10:39:33 2024 From: explorer09 at gmail.com (Kang-Che Sung) Date: Mon, 11 Mar 2024 18:39:33 +0800 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: Message-ID: Jones Syue ??? ? 2024?3?11? ?????? > This patch replaces the 78 "-" prints with 75 "-". And replace the 80 > columns summary line with 77 columns. ("%s" is considered as two chars > and should be filled with whitespace " ", so 77 = 75 + 2) > > Consider this scenario: a patch contains the output of "bloat-o-meter" to > clarify about the size impact/diff, and when we validate this patch with > "~/linux/scripts/checkpatch.pl" (from linux kernel source tree), which > checks for style violations, it might complain about line wrapped like:[1] > WARNING: \ > Possible unwrapped commit description (prefer a maximum 75 chars per line) > > The 1st complaint is seperation line with 78 '-' prints, and the 2nd > complaint is summary line "(add/remove ... Total: n bytes)". Although > these two warnings are not harmful at all, it is helpful and makes life > easier if this kind of patch (with "bloat-o-meter" output) could be passed > by 'checkpatch.pl' in the first place without manually inspection. > > [1] line wrapped at 75 columns: > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > Signed-off-by: Jones Syue > --- > v2: > - fix nit/typo with correct word 'scenario' > v1: http://lists.busybox.net/pipermail/busybox/2024-March/090656.html > --- > scripts/bloat-o-meter | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > I was curious. Is there a reason for BusyBox's bloat-o-meter script not to keep in sync with the version that comes in the Linux kernel source? I occasionally use the bloat-o-meter from the Linux kernel to compare even BusyBox binaries. There shouldn't be any functional differences between the two versions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at wetterwald.eu Mon Mar 11 10:49:26 2024 From: martin at wetterwald.eu (Martin Wetterwald) Date: Mon, 11 Mar 2024 11:49:26 +0100 Subject: grep: BUG with empty -f pattern file when -x and -F are used at the same time Message-ID: Hello, Following commit https://git.busybox.net/busybox/commit/?id=c3295d233b6a7d924814eec9a5c5999a876daf9e that landed in the 1.32.0 in 2020 fixed a grep behavior issue when -x was specified together with an empty pattern file -f. The patch adds the regex .* to the patterns when -x is set and -f pattern file is empty. This becomes an issue only when -F (no regex) is used. This doesn't look like a regression, because this issue was already there before the above patch was applied. I wrote a small script to illustrate the problem, which only happens when -F, -x, together with an empty -f pattern file are specified. Execute this script on busybox 1.31.1, 1.32.0 and above, GNU grep and BSD grep. It shouldn't output anything, but it does. Script output when using busybox 1.31.1 (before the above commit) : > grep -f > grep -xf > hello > grep -Ff > grep -Fxf > hello Script output when using busybox 1.36.1 (after the above commit introduced in 1.32.0) : > grep -f > grep -xf > grep -Ff > grep -Fxf > hello Following the above fix, one of the hellos has (correctly) disappeared, but there is still the last one that shouldn't be there. Script output when using GNU grep 3.4 or GNU grep 3.11 > grep -f > grep -xf > grep -Ff > grep -Fxf Script output when using grep (BSD grep, GNU compatible) 2.6.0-FreeBSD > grep -f > grep -xf > grep -Ff > grep -Fxf You will find the script below. Best Regards, Martin #!/bin/sh # Grep bug # Strange interaction between -F, -x and -f flags when the -f file is empty # Bug noticed on busybox 1.36.1 grep # No bug found on GNU grep 3.4 :> patterns echo "hello" > file # According to the manual: -f file will match NOTHING if the given file is # empty # No pattern means no match. # Should output nothing echo "grep -f" grep -f patterns file # -> OK! # Should output nothing # Because adding -x shouldn't change anything: # We'll work by line now, but I still didn't provide any pattern anyway echo "grep -xf" grep -xf patterns file # -> OK! # Should output nothing # Adding -F shouldn't change anything: I promise I don't use regex, and it's # the case... # An empty string is not a regex, right? echo "grep -Ff" grep -Ff patterns file # -> OK! # Should output nothing # Adding -F and -x shouldn't change anything... echo "grep -Fxf" grep -Fxf patterns file # -> KO! It outputs something. # I'm promising not to use regex with -F, but, because I use -x with -f, # busybox adds a pattern ".*". But this is now a regex, internally! But due to # the -F, this regex won't be understood... # The user shouldn't be impacted by this now "internal regex". # User is not aware that a regex was provided internally. # https://elixir.bootlin.com/busybox/1.36.1/source/findutils/grep.c#L772 From ncopa at alpinelinux.org Mon Mar 11 11:57:38 2024 From: ncopa at alpinelinux.org (Natanael Copa) Date: Mon, 11 Mar 2024 12:57:38 +0100 Subject: [PATCH] wget: add header Accept: */* Message-ID: <20240311115738.18177-1-ncopa@alpinelinux.org> Some servers (like https://netfilter.org) returns failure if the Accept header is missing. Both GNU wget and curl adds this header, so make busybox do the same. fixes: https://bugs.busybox.net/show_bug.cgi?id=15982 function old new delta wget_main 3120 3144 +24 .rodata 79296 79310 +14 wget_user_headers 76 84 +8 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 3/0 up/down: 46/0) Total: 46 bytes text data bss dec hex filename 825278 14260 2008 841546 cd74a busybox_old 825324 14260 2008 841592 cd778 busybox_unstripped --- networking/wget.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/networking/wget.c b/networking/wget.c index 199ddd4da..48486fdee 100644 --- a/networking/wget.c +++ b/networking/wget.c @@ -212,14 +212,16 @@ enum { HDR_USER_AGENT = (1<<1), HDR_RANGE = (1<<2), HDR_CONTENT_TYPE = (1<<3), - HDR_AUTH = (1<<4) * ENABLE_FEATURE_WGET_AUTHENTICATION, - HDR_PROXY_AUTH = (1<<5) * ENABLE_FEATURE_WGET_AUTHENTICATION, + HDR_ACCEPT = (1<<4), + HDR_AUTH = (1<<5) * ENABLE_FEATURE_WGET_AUTHENTICATION, + HDR_PROXY_AUTH = (1<<6) * ENABLE_FEATURE_WGET_AUTHENTICATION, }; static const char wget_user_headers[] ALIGN1 = "Host:\0" "User-Agent:\0" "Range:\0" "Content-Type:\0" + "Accept:\0" # if ENABLE_FEATURE_WGET_AUTHENTICATION "Authorization:\0" "Proxy-Authorization:\0" @@ -229,6 +231,7 @@ static const char wget_user_headers[] ALIGN1 = # define USR_HEADER_USER_AGENT (G.user_headers & HDR_USER_AGENT) # define USR_HEADER_RANGE (G.user_headers & HDR_RANGE) # define USR_HEADER_CONTENT_TYPE (G.user_headers & HDR_CONTENT_TYPE) +# define USR_HEADER_ACCEPT (G.user_headers & HDR_ACCEPT) # define USR_HEADER_AUTH (G.user_headers & HDR_AUTH) # define USR_HEADER_PROXY_AUTH (G.user_headers & HDR_PROXY_AUTH) #else /* No long options, no user-headers :( */ @@ -236,6 +239,7 @@ static const char wget_user_headers[] ALIGN1 = # define USR_HEADER_USER_AGENT 0 # define USR_HEADER_RANGE 0 # define USR_HEADER_CONTENT_TYPE 0 +# define USR_HEADER_ACCEPT 0 # define USR_HEADER_AUTH 0 # define USR_HEADER_PROXY_AUTH 0 #endif @@ -1232,6 +1236,8 @@ static void download_one_url(const char *url) SENDFMT(sfp, "Host: %s\r\n", target.host); if (!USR_HEADER_USER_AGENT) SENDFMT(sfp, "User-Agent: %s\r\n", G.user_agent); + if (!USR_HEADER_ACCEPT) + SENDFMT(sfp, "Accept: */*\r\n"); /* Ask server to close the connection as soon as we are done * (IOW: we do not intend to send more requests) -- 2.44.0 From jonessyue at qnap.com Tue Mar 12 10:34:05 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Tue, 12 Mar 2024 10:34:05 +0000 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: Message-ID: > I was curious. Is there a reason for BusyBox's bloat-o-meter script not to > keep in sync with the version that comes in the Linux kernel source? It looks like busybox's bloat-o-meter has this addon: .rodata section diff. Commit f14f7fc5cad5 ("Teach bloatometer about .rodata, and tweak the display into something that") introduced this feature through 'readelf'. https://git.busybox.net/busybox/commit/?id=f14f7fc5cad5 After poking around mailing list found this thread has a talk about "[PATCH] update kernel's scripts/bloat-o-meter from busybox", and somehow not goes to linux kernel upstream: https://lore.kernel.org/all/200906020104.56471.rob at landley.net/t/ linux kernel's bloat-o-meter has an alternative checks for read-only sections. Commit c50e3f512a5a ("bloat-o-meter: include read-only data section in report) introduced it through 'nm' with type 'r' or 'R'. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c50e3f512a5a > I occasionally use the bloat-o-meter from the Linux kernel to compare even > BusyBox binaries. There shouldn't be any functional differences between the > two versions. Per test it looks like busybox has one more items: ".rodata", if the modification contains a format strings like this: log5("crond_dummy 1 %d %d\n", crond_dummy_global_int, crond_dummy_local_int); The output of two versions: ~/busybox/scripts/bloat-o-meter ~/busybox_unstripped_{orig,fix} function old new delta crond_dummy_func - 211 +211 .rodata 59300 59404 +104 crond_main 704 709 +5 static.crond_dummy_local_int - 4 +4 crond_dummy_global_int - 4 +4 ------------------------------------------------------------------------------ (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total: 328 bytes ~/git/linux/scripts/bloat-o-meter -c ~/busybox_unstripped_{orig,fix} add/remove: 1/0 grow/shrink: 1/0 up/down: 216/0 (216) Function old new delta crond_dummy_func - 211 +211 crond_main 704 709 +5 Total: Before=692144, After=692360, chg +0.03% add/remove: 2/0 grow/shrink: 0/0 up/down: 8/0 (8) Data old new delta crond_dummy_local_int - 4 +4 crond_dummy_global_int - 4 +4 Total: Before=13500, After=13508, chg +0.06% add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) RO Data old new delta Total: Before=35929, After=35929, chg +0.00% -- Regards, Jones Syue | ??? QNAP Systems, Inc. From jonessyue at qnap.com Wed Mar 13 01:08:13 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Wed, 13 Mar 2024 01:08:13 +0000 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: Message-ID: > Per test it looks like busybox has one more items: ".rodata", if the > modification contains a format strings like this: > log5("crond_dummy 1 %d %d\n", crond_dummy_global_int, crond_dummy_local_int); Looks like the formatted strings is considered as a string literal, not a symbol, while linux kernel's bloat-o-meter is doing symbol lookup through 'nm', which could not find the diff of string literal, and show nothing change in the 'RO Data' category. The string literal is resident in the .rodata section, and busybox's bloat-o-meter is reading the .rodata section through 'readelf' so it could find the size diff. -- Regards, Jones Syue | ??? QNAP Systems, Inc. From jonessyue at qnap.com Wed Mar 13 01:22:00 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Wed, 13 Mar 2024 01:22:00 +0000 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: Message-ID: > This patch replaces the 78 "-" prints with 75 "-". And replace the 80 > columns summary line with 77 columns. ("%s" is considered as two chars > and should be filled with whitespace " ", so 77 = 75 + 2) This is an example which showing how this patch wrapped line to 75 columns, use awk to count the line length and prepend it to each line's head[1]. Before applying this patch, the seperation line and summary line are wrapped to 78 columns: 72 crond_dummy_func - 211 +211 72 .rodata 59300 59404 +104 72 crond_main 704 709 +5 72 static.crond_dummy_local_int - 4 +4 72 crond_dummy_global_int - 4 +4 78 ------------------------------------------------------------------------------ 78 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total: 328 bytes After applying this patch, the seperation line and summary line are wrapped to 75 columns: 72 crond_dummy_func - 211 +211 72 .rodata 59300 59404 +104 72 crond_main 704 709 +5 72 static.crond_dummy_local_int - 4 +4 72 crond_dummy_global_int - 4 +4 75 --------------------------------------------------------------------------- 75 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total: 328 bytes [1] while read -r line; \ do \ awk '{ print length, $line }'; \ done < <(~/busybox/scripts/bloat-o-meter ~/busybox_unstripped_{orig,fix}); -- Regards, Jones Syue | ??? QNAP Systems, Inc. From dietmar.schindler at manrolandgoss.com Wed Mar 13 06:43:12 2024 From: dietmar.schindler at manrolandgoss.com (dietmar.schindler at manrolandgoss.com) Date: Wed, 13 Mar 2024 06:43:12 +0000 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: Message-ID: <31f188b3852243739b180658c1416f26@manrolandgoss.com> > From: busybox On Behalf Of Jones Syue ??? > Sent: Wednesday, March 13, 2024 2:22 AM > > > This patch replaces the 78 "-" prints with 75 "-". And replace the 80 > > columns summary line with 77 columns. ("%s" is considered as two chars > > and should be filled with whitespace " ", so 77 = 75 + 2) > > This is an example which showing how this patch wrapped line to 75 columns, > use awk to count the line length and prepend it to each line's head[1]. > Before applying this patch, the seperation line and summary line are > wrapped to 78 columns: > > 72 crond_dummy_func - 211 +211 > 72 .rodata 59300 59404 +104 > 72 crond_main 704 709 +5 > 72 static.crond_dummy_local_int - 4 +4 > 72 crond_dummy_global_int - 4 +4 > 78 ------------------------------------------------------------------------------ > 78 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total: 328 bytes > > After applying this patch, the seperation line and summary line are > wrapped to 75 columns: > > 72 crond_dummy_func - 211 +211 > 72 .rodata 59300 59404 +104 > 72 crond_main 704 709 +5 > 72 static.crond_dummy_local_int - 4 +4 > 72 crond_dummy_global_int - 4 +4 > 75 --------------------------------------------------------------------------- > 75 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total: 328 bytes How about 72 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total bytes: 328 to keep the numbers aligned? -- Best regards, Dietmar Schindler ________________________________ manroland Goss web systems GmbH | Managing Director: Franz Kriechbaum Registered Office: Augsburg | Trade Register: AG Augsburg | HRB-No.: 32609 | VAT: DE815764857 Confidentiality note: This message and any attached documents may contain confidential or proprietary information of manroland|Goss. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. If you have received this communication in error, please immediately notify the sender and delete the message from your system. All liability for viruses is excluded to the fullest extent permitted by law. ________________________________ From jonessyue at qnap.com Wed Mar 13 10:02:07 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Wed, 13 Mar 2024 10:02:07 +0000 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: <31f188b3852243739b180658c1416f26@manrolandgoss.com> References: <31f188b3852243739b180658c1416f26@manrolandgoss.com> Message-ID: > How about > > 72 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total bytes: 328 > > to keep the numbers aligned? Yes! 72 is totally aligned with function/old/new/delta length! :) And IMHO 75 columns is still a bit preferred than 72 columns, two reasons are considered: 1. consistent with linux kernel upstream. Found this thread had a v1 proposal patch to do line wrapped at 72 columns: https://lore.kernel.org/lkml/1427827225.18175.3.camel at perches.com/T/#u and finally 75 columns goes to upstream, Commit 2a076f40d8c9b ("checkpatch, SubmittingPatches: suggest line wrapping commit messages at 75 columns"): https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2a076f40d8c9b 2. easy to maintain and grep keyword '75'. 75-columns patch uses 's/78/75; s/80/77/' replacement and keeps keyword '75' in the file, if someday wide screen is very popular and output width exceeded that said 100 columns would not ruin people's life, we could easily find the expected length '75' and replace it with a wider numbers. 72-columns patch uses 's/78/72; s/80/74/' replacement might a bit hard to find the expected length afterward. By the way, loop is not required in my previous length counting script :) simply pipe to awk is fine: ~/busybox/scripts/bloat-o-meter ~/busybox_unstripped_{orig,fix} \ | awk '{ print length, $0 }' -- Regards, Jones Syue | ??? QNAP Systems, Inc. From xoneca at gmail.com Wed Mar 13 23:38:03 2024 From: xoneca at gmail.com (Xabier Oneca -- xOneca) Date: Thu, 14 Mar 2024 00:38:03 +0100 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: <31f188b3852243739b180658c1416f26@manrolandgoss.com> Message-ID: Hi Jones, > > How about > > > > 72 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total bytes: 328 > > > > to keep the numbers aligned? > > Yes! 72 is totally aligned with function/old/new/delta length! :) > And IMHO 75 columns is still a bit preferred than 72 columns, two reasons > are considered: He didn't mean to reduce the length of the line to 72, but to align the number (328 bytes) in the example with the last column of previous lines. Is one thing I also noted that your patch changed. Note the final 'bytes' word changed side. Cheers, Xabier Oneca_,,_ From jonessyue at qnap.com Thu Mar 14 00:45:28 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Thu, 14 Mar 2024 00:45:28 +0000 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: <31f188b3852243739b180658c1416f26@manrolandgoss.com> Message-ID: > He didn't mean to reduce the length of the line to 72, but to align > the number (328 bytes) in the example with the last column of previous > lines. Is one thing I also noted that your patch changed. Note the > final 'bytes' word changed side. Ohh okay now i see! Thank you Xabier and Dietmar for kindly feedback :) the 'bytes' is switched from the right hand side to the left hand side of the numbers '328'. Will come out next v3 later :) <... cut ...> 72 crond_dummy_global_int - 4 +4 75 --------------------------------------------------------------------------- 75 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total: 328 bytes 72 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total bytes: 328 -- Regards, Jones Syue | ??? QNAP Systems, Inc. From rep.dot.nop at gmail.com Thu Mar 14 21:18:14 2024 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Thu, 14 Mar 2024 22:18:14 +0100 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: References: Message-ID: <20240314221814.66dd717a@nbbrfq.loc> On Mon, 11 Mar 2024 18:39:33 +0800 Kang-Che Sung wrote: > I was curious. Is there a reason for BusyBox's bloat-o-meter script not to > keep in sync with the version that comes in the Linux kernel source? > > I occasionally use the bloat-o-meter from the Linux kernel to compare even > BusyBox binaries. There shouldn't be any functional differences between the > two versions. IIRC the variant living in the kernel does not handle symbol aliases properly and uses nm(1). Our variant uses readelf(1) and works also for code that uses aliases, like your favourite libc and other such binaries. The choice from using the max 80 char width comes from a time where we did not usually add the bloat-o-meter output to commit messages, but i agree that we should shorten it to silence the patch checkers. I like Dietmars suggestion to keep the numbers aligned. What is missing in our variant is support for -p "ARCH-PREFIX-" for readelf. Should probably switch to argparse too. HTH From jonessyue at qnap.com Fri Mar 15 03:41:17 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Fri, 15 Mar 2024 03:41:17 +0000 Subject: [PATCH v3] bloat-o-meter: line wrapped at max 75 columns to silence patch checkers Message-ID: Change the outout of bloat-o-meter, line wrapped at maximum 75 columns; including 'function/old/new/delta' title and numbers, seperation line with '-', and the last line 'Total'. Also put 'Total' numbers to the last column in order to keep it aligned with previous 'delta' numbers. Consider this scenario: a patch contains the output of bloat-o-meter to clarify about the size impact/diff, and when we validate this patch with '~/linux/scripts/checkpatch.pl' (from linux kernel source tree), which checks for style violations, it might complain about line wrapped like:[1] WARNING: \ Possible unwrapped commit description (prefer a maximum 75 chars per line) Although these warnings are not harmful at all, it is helpful and makes life easier if this kind of patch (with bloat-o-meter output) could be passed by 'checkpatch.pl' in the first place without manually inspection. [1] line wrapped at 75 columns: https://www.kernel.org/doc/html/latest/process/submitting-patches.html Signed-off-by: Jones Syue --- v3: - keep 'Total' numbers aligned with previois 'delta' numbers - 'function/old/new/delta' title and numbers wrapped at max 75 columns - add clear intention to subject: silence patch checkers v2: http://lists.busybox.net/pipermail/busybox/2024-March/090658.html - fix patch description's nit/typo with correct word 'scenario' v1: http://lists.busybox.net/pipermail/busybox/2024-March/090656.html --- scripts/bloat-o-meter | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/scripts/bloat-o-meter b/scripts/bloat-o-meter index b4a1d28113b0..651399103fbe 100755 --- a/scripts/bloat-o-meter +++ b/scripts/bloat-o-meter @@ -124,16 +124,16 @@ delta.reverse() if flag_timing: end_t3 = int(time.time() * 1e9) -print("%-48s %7s %7s %+7s" % ("function", "old", "new", "delta")) +print("%-48s %8s %8s %+8s" % ("function", "old", "new", "delta")) for d, n in delta: if d: old_sz = old.get(n, {}).get("size", "-") new_sz = new.get(n, {}).get("size", "-") - print("%-48s %7s %7s %+7d" % (n, old_sz, new_sz, d)) -print("-"*78) -total="(add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s)%%sTotal: %s bytes"\ + print("%-48s %8s %8s %+8d" % (n, old_sz, new_sz, d)) +print("-"*75) +total="(add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s)%%sTotal bytes: %s"\ % (add, remove, grow, shrink, up, -down, up-down) -print(total % (" "*(80-len(total)))) +print(total % (" "*(77-len(total)))) if flag_timing: print("\n%d/%d; %d Parse origin/new; processing nsecs" % (end_t1-start_t1, end_t2-start_t2, end_t3-start_t3)) -- 2.1.4 From jonessyue at qnap.com Fri Mar 15 03:48:00 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Fri, 15 Mar 2024 03:48:00 +0000 Subject: [PATCH v3] bloat-o-meter: line wrapped at max 75 columns to silence patch checkers In-Reply-To: References: Message-ID: > Change the outout of bloat-o-meter, line wrapped at maximum 75 columns; > including 'function/old/new/delta' title and numbers, seperation line with > '-', and the last line 'Total'. Also put 'Total' numbers to the last column > in order to keep it aligned with previous 'delta' numbers. This is an example, use awk to count length per line[1]. Before applied this patch: 72 function old new delta 72 crond_dummy_func - 211 +211 72 .rodata 59300 59404 +104 72 crond_main 704 709 +5 72 static.crond_dummy_local_int - 4 +4 72 crond_dummy_global_int - 4 +4 78 ------------------------------------------------------------------------------ 78 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total: 328 bytes After applied this patch: 75 function old new delta 75 crond_dummy_func - 211 +211 75 .rodata 59300 59404 +104 75 crond_main 704 709 +5 75 static.crond_dummy_local_int - 4 +4 75 crond_dummy_global_int - 4 +4 75 --------------------------------------------------------------------------- 75 (add/remove: 3/0 grow/shrink: 2/0 up/down: 328/0) Total bytes: 328 [1] ~/git/busybox/scripts/bloat-o-meter ~/busybox_unstripped_{orig,fix} \ | awk '{ print length, $0 }' -- Regards, Jones Syue | ??? QNAP Systems, Inc. From social at ljena.de Sun Mar 17 22:42:03 2024 From: social at ljena.de (Malte) Date: Sun, 17 Mar 2024 23:42:03 +0100 Subject: Strange behaviour in chmod when setting sticky bit using symbolic notation Message-ID: <4de5f0fe-41a8-47cc-a624-9b6248ff3c1b@ljena.de> Hello, I was tinkering with a Dockerfile based upon Alpine distro / BusyBox 1.36.1, and I noticed that sticky bits would not be set if I used # chmod -v u=rwx,g=rwx,o=t ./somefile mode of './somefile/' changed to 0770 (rwxrwx---) instead of # chmod 1770 ./somefile (this works) mode of './somefile/' changed to 1770 (rwxrwx--T) the rest of the permissions will get set correctly, only sticky bit will not and only when using symbolic notation. I checked other distros and it works there. Can someone confirm this behaviour? I checked older versions, too. Of course there is a workaround like # chmod -v u=rwx,g=rwx,o=,a+t ./somefile but it should work also with o=t or o+t. Best regards Malte From daggs at gmx.com Mon Mar 18 17:53:52 2024 From: daggs at gmx.com (daggs) Date: Mon, 18 Mar 2024 18:53:52 +0100 Subject: listing partguid of a device In-Reply-To: References: Message-ID: > Greetings, > > I wonder if there is a way to use busybox to list partguid of a device? > busybox's blkid cannot do it while stock blkid can. > > Thanks. > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox > short answer, seems like thats a no. in case someone needs such support, I'm attaching a patch that I wrote for gdisk that prints the part guids. Dagg -------------- next part -------------- A non-text attachment was scrubbed... Name: add_part_guid_to_gdisk.patch Type: text/x-patch Size: 1734 bytes Desc: not available URL: From jonessyue at qnap.com Tue Mar 19 03:10:45 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Tue, 19 Mar 2024 03:10:45 +0000 Subject: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80 In-Reply-To: <20240314221814.66dd717a@nbbrfq.loc> References: <20240314221814.66dd717a@nbbrfq.loc> Message-ID: > The choice from using the max 80 char width comes from a time where we > did not usually add the bloat-o-meter output to commit messages, but i > agree that we should shorten it to silence the patch checkers. I like > Dietmars suggestion to keep the numbers aligned. > > What is missing in our variant is support for -p "ARCH-PREFIX-" for > readelf. Should probably switch to argparse too. argparse and prefix sounds cool! Thanks Bernhard, i will add this to my todo list. -- Regards, Jones Syue | ??? QNAP Systems, Inc. From jonessyue at qnap.com Tue Mar 19 09:28:23 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Tue, 19 Mar 2024 09:28:23 +0000 Subject: [PATCH 1/2] bloat-o-meter: switch arguments parsing to argparse Message-ID: This patch switches arguments parsing to argparse module, which makes it easy to extend further arguments into this script. Note that one thing is changed: how additional parameters is pass-through to readelf, now it needs an assignment char '=' followed by a pair of single/double quotes to wrap additional parameters, like: ./scripts/bloat-o-meter --="-a -n" busybox_unstripped_{old,new} or ./scripts/bloat-o-meter busybox_unstripped_{old,new} --="-a -n" It is a bit different in old days, always pass-through in the tail: ./scripts/bloat-o-meter busybox_unstripped_{old,new} -- -a -n This is a help usage show how it looks like: ./scripts/bloat-o-meter -h usage: bloat-o-meter [-h] [-t] [-- OPT] file1 file2 Simple script used to compare symbol size and section size of 2 object files, and report size difference. Object files like unstripped binaries with extra information could generate a detailed report, which is strongly recommended. positional arguments: file1 Old file to compare, e.g. busybox_unstripped_old file2 New file to compare, e.g. busybox_unstripped_new optional arguments: -h, --help show this help message and exit -t Show time spent on parsing/processing -- OPT Pass additional parameters to readelf, e.g. --="-a" Signed-off-by: Jones Syue --- scripts/bloat-o-meter | 64 ++++++++++++++++++++------------------------------- 1 file changed, 25 insertions(+), 39 deletions(-) diff --git a/scripts/bloat-o-meter b/scripts/bloat-o-meter index b4a1d28113b0..72b0693764bf 100755 --- a/scripts/bloat-o-meter +++ b/scripts/bloat-o-meter @@ -7,41 +7,27 @@ # This software may be used and distributed according to the terms # of the GNU General Public License, incorporated herein by reference. -import sys, os +import sys, os, argparse -def usage(): - sys.stderr.write("usage: %s [-t] file1 file2 [-- ]\n" - % sys.argv[0]) - sys.stderr.write("\t-t\tShow time spent on parsing/processing\n") - sys.stderr.write("\t--\tPass additional parameters to readelf\n") - sys.exit(1) +usage=''' +Simple script used to compare symbol size and section size of 2 object files, +and report size difference. Object files like unstripped binaries with extra +information could generate a detailed report, which is strongly recommended. +''' +parser = argparse.ArgumentParser(description=usage) +parser.add_argument('-t', action='store_true', + help='Show time spent on parsing/processing') +parser.add_argument('--', dest='opt', default='', + help='Pass additional parameters to readelf, e.g. --="-a"') +parser.add_argument('file1', help='Old file to compare, ' + 'e.g. busybox_unstripped_old') +parser.add_argument('file2', help='New file to compare, ' + 'e.g. busybox_unstripped_new') +args = parser.parse_args() -f1, f2 = (None, None) -flag_timing, dashes = (False, False) - -for f in sys.argv[1:]: - if f.startswith("-"): - if f == "--": # sym_args - dashes = True - break - if f == "-t": # timings - flag_timing = True - else: - if not os.path.exists(f): - sys.stderr.write("Error: file '%s' does not exist\n" % f) - usage() - if f1 is None: - f1 = f - elif f2 is None: - f2 = f - else: - usage() -if flag_timing: +if args.t: import time -if f1 is None or f2 is None: - usage() -sym_args = " ".join(sys.argv[3 + flag_timing + dashes:]) def getsizes(file): sym, alias, lut, section = {}, {}, {}, {} for l in os.popen("readelf -W -S " + file).readlines(): @@ -52,7 +38,7 @@ def getsizes(file): if x[1] not in [".rodata"]: continue sym[x[1]] = {"addr" : int(x[3], 16), "size" : int(x[5], 16)} section[x[0][1:-1]] = {"name" : x[1]} - for l in os.popen("readelf -W -s %s %s" % (sym_args, file)).readlines(): + for l in os.popen("readelf -W -s %s %s" % (args.opt, file)).readlines(): l = l.strip() if not (len(l) and l[0].isdigit() and len(l.split()) == 8): continue @@ -80,14 +66,14 @@ def getsizes(file): sym[alias[(addr, sz)]["name"]] = {"addr" : addr, "size": sz} return sym -if flag_timing: +if args.t: start_t1 = int(time.time() * 1e9) -old = getsizes(f1) -if flag_timing: +old = getsizes(args.file1) +if args.t: end_t1 = int(time.time() * 1e9) start_t2 = int(time.time() * 1e9) -new = getsizes(f2) -if flag_timing: +new = getsizes(args.file2) +if args.t: end_t2 = int(time.time() * 1e9) start_t3 = int(time.time() * 1e9) grow, shrink, add, remove, up, down = 0, 0, 0, 0, 0, 0 @@ -121,7 +107,7 @@ for name in common: delta.sort() delta.reverse() -if flag_timing: +if args.t: end_t3 = int(time.time() * 1e9) print("%-48s %7s %7s %+7s" % ("function", "old", "new", "delta")) @@ -134,7 +120,7 @@ print("-"*78) total="(add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s)%%sTotal: %s bytes"\ % (add, remove, grow, shrink, up, -down, up-down) print(total % (" "*(80-len(total)))) -if flag_timing: +if args.t: print("\n%d/%d; %d Parse origin/new; processing nsecs" % (end_t1-start_t1, end_t2-start_t2, end_t3-start_t3)) print("total nsecs: %d" % (end_t3-start_t1)) -- 2.1.4 From jonessyue at qnap.com Tue Mar 19 09:29:59 2024 From: jonessyue at qnap.com (=?iso-2022-jp?B?Sm9uZXMgU3l1ZSAbJEJpLVhnPSEbKEI=?=) Date: Tue, 19 Mar 2024 09:29:59 +0000 Subject: [PATCH 2/2] bloat-o-meter: add -p argument with arch prefix Message-ID: This patch add '-p' argument with the arch prefix, in order to call target-specific readelf for bloat-o-meter report. It is useful when cross compiling busybox with specific toolchain, in case host's native readelf does not work. '-p' help msg is leveraging linux kernel's bloat-o-meter. For example, the arch prefix is 'arm-linux-gnu-': ./scripts/bloat-o-meter -p arm-linux-gnu- busybox_unstripped_{old,new} Signed-off-by: Jones Syue --- scripts/bloat-o-meter | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/scripts/bloat-o-meter b/scripts/bloat-o-meter index 72b0693764bf..21dff3e4bf8d 100755 --- a/scripts/bloat-o-meter +++ b/scripts/bloat-o-meter @@ -19,6 +19,9 @@ parser.add_argument('-t', action='store_true', help='Show time spent on parsing/processing') parser.add_argument('--', dest='opt', default='', help='Pass additional parameters to readelf, e.g. --="-a"') +parser.add_argument('-p', dest='prefix', default='', + help='Arch prefix for the tool being used. Useful in ' + 'cross build scenarios. e.g. -p arm-linux-gnu-') parser.add_argument('file1', help='Old file to compare, ' 'e.g. busybox_unstripped_old') parser.add_argument('file2', help='New file to compare, ' @@ -30,7 +33,10 @@ if args.t: def getsizes(file): sym, alias, lut, section = {}, {}, {}, {} - for l in os.popen("readelf -W -S " + file).readlines(): + readelf = 'readelf' + if args.prefix: + readelf = "%sreadelf" % (args.prefix) + for l in os.popen("%s -W -S %s" % (readelf, file)).readlines(): x = l.replace("[ ", "[", 1).split() if len(x)<6: continue # Should take these into account too! @@ -38,7 +44,7 @@ def getsizes(file): if x[1] not in [".rodata"]: continue sym[x[1]] = {"addr" : int(x[3], 16), "size" : int(x[5], 16)} section[x[0][1:-1]] = {"name" : x[1]} - for l in os.popen("readelf -W -s %s %s" % (args.opt, file)).readlines(): + for l in os.popen("%s -W -s %s %s" % (readelf, args.opt, file)).readlines(): l = l.strip() if not (len(l) and l[0].isdigit() and len(l.split()) == 8): continue -- 2.1.4 From misha.zavertkin at mail.ru Thu Mar 21 08:05:33 2024 From: misha.zavertkin at mail.ru (=?UTF-8?B?0JzQuNGI0LAg0JfQsNCy0ZHRgNGC0LrQuNC9?=) Date: Thu, 21 Mar 2024 11:05:33 +0300 Subject: =?UTF-8?B?Rml4IHBpbmcgYWNjZXB0aW5nIG9ubHkgc2FtZSBzaXplZCBwYWNrZXRz?= Message-ID: <1711008333.82411503@f764.i.mail.ru> * IPv4 version ignoring?IP header in size * Ping replys from?8.8.8.8 have limited size, so pinging it with large packets (more than 89 bytes in payload) caused false ping fails ???????To reproduce: ?ping -s 88? will succeed ?ping -s 89? will fails ? diff --git a/networking/ping.c b/networking/ping.c index b7e6955a9..ecf9c569e 100644 --- a/networking/ping.c +++ b/networking/ping.c @@ -696,7 +696,7 @@ static int unpack4(char *buf, int sz, struct sockaddr_in *from) ??? ?int hlen; ? ??? ?/* discard if too short */ -?? ?if (sz < (datalen + ICMP_MINLEN)) +?? ?if (sz < (sizeof(struct iphdr) + ICMP_MINLEN)) ??? ??? ?return 0; ? ??? ?/* check IP header */ @@ -732,7 +732,7 @@ static int unpack6(char *packet, int sz, struct sockaddr_in6 *from, int hoplimit ??? ?char buf[INET6_ADDRSTRLEN]; ? ??? ?/* discard if too short */ -?? ?if (sz < (datalen + sizeof(struct icmp6_hdr))) +?? ?if (sz < sizeof(struct icmp6_hdr)) ??? ??? ?return 0; ? ??? ?icmppkt = (struct icmp6_hdr *) packet; ? -- ???? ????????? ?????????? ?? ????? Mail.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at kleine-koenig.org Sat Mar 23 17:04:29 2024 From: uwe at kleine-koenig.org (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=) Date: Sat, 23 Mar 2024 18:04:29 +0100 Subject: [PATCH] tc: Fix compilation with Linux v6.8-rc1 Message-ID: <20240323170430.215522-2-uwe@kleine-koenig.org> From: Uwe Kleine-K?nig Linux v6.8-rc1 removed the definitions related to CBQ making tc fail to build. Add some #ifdefs to handle this missing support. --- Hello, this is just a minimal patch to make tc compile again. Maybe it makes more sense to drop cbq completely?? Best regards Uwe networking/tc.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/networking/tc.c b/networking/tc.c index 3a79fd2d9ea5..d08fd13598b9 100644 --- a/networking/tc.c +++ b/networking/tc.c @@ -231,6 +231,13 @@ static int cbq_parse_opt(int argc, char **argv, struct nlmsghdr *n) return 0; } #endif + +#ifndef TCA_CBQ_MAX +/* + * Linux v6.8-rc1~131^2~60^2^2 removed the uapi definitions for CBQ. + * See https://git.kernel.org/linus/33241dca48626 + */ +#else static int cbq_print_opt(struct rtattr *opt) { struct rtattr *tb[TCA_CBQ_MAX+1]; @@ -322,6 +329,7 @@ static int cbq_print_opt(struct rtattr *opt) done: return 0; } +#endif static FAST_FUNC int print_qdisc( const struct sockaddr_nl *who UNUSED_PARAM, @@ -372,8 +380,10 @@ static FAST_FUNC int print_qdisc( int qqq = index_in_strings(_q_, name); if (qqq == 0) { /* pfifo_fast aka prio */ prio_print_opt(tb[TCA_OPTIONS]); +#ifdef TCA_CBQ_MAX } else if (qqq == 1) { /* class based queuing */ cbq_print_opt(tb[TCA_OPTIONS]); +#endif } else { /* don't know how to print options for this qdisc */ printf("(options for %s)", name); @@ -442,9 +452,11 @@ static FAST_FUNC int print_class( int qqq = index_in_strings(_q_, name); if (qqq == 0) { /* pfifo_fast aka prio */ /* nothing. */ /*prio_print_opt(tb[TCA_OPTIONS]);*/ +#ifdef TCA_CBQ_MAX } else if (qqq == 1) { /* class based queuing */ /* cbq_print_copt() is identical to cbq_print_opt(). */ cbq_print_opt(tb[TCA_OPTIONS]); +#endif } else { /* don't know how to print options for this class */ printf("(options for %s)", name); -- 2.43.0 From harv at gmx.de Mon Mar 25 10:37:17 2024 From: harv at gmx.de (Harvey) Date: Mon, 25 Mar 2024 11:37:17 +0100 Subject: Changing HOME ENV-Variable In-Reply-To: References: <031f00da-4016-4311-b397-1c04e373d521@gmx.de> Message-ID: Hello all, in our systems created with buildroot the ENV-Variable HOME for user root is /: # env USER=root HOME=/ This leads to files and directories that are normally located in /root to be located in the root directory: # ls -la drwxr-xr-x 22 root root 500 Mar 24 19:54 . drwxr-xr-x 22 root root 500 Mar 24 19:54 .. -rw------- 1 root root 502 Mar 25 11:34 .ash_history drwx------ 3 root root 60 Mar 24 19:54 .cache drwx------ 3 root root 60 Mar 24 19:54 .config drwx------ 3 root root 60 Mar 24 19:54 .local -r-xr-xr-x 1 root root 888 Mar 24 19:52 .profile drwxr-xr-x 2 root root 60 Mar 24 19:52 .ssh drwxr-xr-x 2 root root 1280 Mar 24 19:53 bin drwx------ 3 root root 16384 Jan 1 1970 boot drwxr-xr-x 5 root root 4096 Feb 12 2019 data drwxr-xr-x 8 root root 2560 Mar 24 19:52 dev drwxr-xr-x 27 root root 1340 Mar 24 19:53 etc lrwxrwxrwx 1 root root 12 Mar 24 19:50 init -> /bin/busybox drwxr-xr-x 3 root root 460 Mar 24 19:52 lib drwxr-xr-x 2 root root 40 Mar 24 19:50 mnt dr-xr-xr-x 181 root root 0 Mar 24 19:52 proc drwx------ 2 root root 40 Mar 5 13:00 root drwxrwxrwt 18 root root 1460 Mar 24 19:53 run drwxr-xr-x 2 root root 1020 Mar 24 19:52 sbin drwxr-xr-x 3 root root 60 Mar 24 19:50 srv dr-xr-xr-x 13 root root 0 Mar 24 19:52 sys drwxrwxrwt 3 root root 100 Mar 25 11:30 tmp drwxr-xr-x 8 root root 160 Mar 24 19:52 usr drwxr-xr-x 9 root root 220 Mar 24 19:53 var I have looked around busbox (and buildroot) configuration but did not find a setting to change this. What did I overlook? Greetings Harvey From rep.dot.nop at gmail.com Tue Mar 26 18:55:11 2024 From: rep.dot.nop at gmail.com (rep.dot.nop at gmail.com) Date: Tue, 26 Mar 2024 19:55:11 +0100 Subject: [PATCH] tc: Fix compilation with Linux v6.8-rc1 In-Reply-To: <20240323170430.215522-2-uwe@kleine-koenig.org> References: <20240323170430.215522-2-uwe@kleine-koenig.org> Message-ID: <6B85B9D9-9354-4B60-9EC2-BE1A32C7C83C@gmail.com> On 23 March 2024 18:04:29 CET, "Uwe Kleine-K?nig" wrote: >From: Uwe Kleine-K?nig > >Linux v6.8-rc1 removed the definitions related to CBQ making tc fail to >build. Add some #ifdefs to handle this missing support. >--- >Hello, > >this is just a minimal patch to make tc compile again. Maybe it makes >more sense to drop cbq completely?? Yes, iirc there was a patch around to do just that. But i'd defer to the big tc (there is nothing left on our old impl) unless someone wants to have a look? thanks