* Re: Kernel bug tracker [not found] <1630659351.685242253@f502.i.mail.ru> @ 2021-09-03 11:00 ` Thomas Schmitt 2021-09-03 15:55 ` Valdis Klētnieks 0 siblings, 1 reply; 10+ messages in thread From: Thomas Schmitt @ 2021-09-03 11:00 UTC (permalink / raw) To: kernelnewbies; +Cc: ebashinskii, valdis.kletnieks Hi, Adverg Ebashinskii wrote: > The reason I looked for some bugs is that I’m not > really interested in driver development and digging into details of a > specific hardware. So I tried to get into some core subsystems like fs, net, > cgroups, etc... I could offer bugs of isofs with explanations and patch proposals: - isofs: prevent file time rollover after year 2038 Change the return type of function iso_date() from int to time64_t. - isofs: truncate oversized Rock Ridge names to 255 bytes Do not discard all bytes of the NM field where the overflow occurs, but rather append them to the accumulated name before truncating it to exactly 255 bytes. Map trailing incomplete UTF-8 bytes to '_'. - isofs: fix Oops with zisofs and large PAGE_SIZE https://lore.kernel.org/linux-scsi/20201120140633.1673-1-scdbackup@gmx.net/T/#u (No replies since 2020-11-20. I hope the tester of this patch still has the machine to confirm that the patch is still good.) What is obviously missing with my skills is ability to get attention of kernel developers for isofs and their trust that the proposals don't make things worse. As developer of libisofs and libburn i can provide motivations and facts from that experience. There would be 4 bugs in cdrom and sr to be fixed, 2 wishlist changes for them, and 2 wishlist changes for isofs. An example can be seen at https://lore.kernel.org/linux-scsi/20201006094026.1730-1-scdbackup@gmx.net/T/#u (My patch proposals were tested with kernels of a year ago. One of them meanwhile needs rework due to the demise of the .readpages method: isofs: Give zisofs a .readpages() method for use by mm/readahead My kernel development machine from then meanwhile has a production job.) Have a nice day :) Thomas _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel bug tracker 2021-09-03 11:00 ` Kernel bug tracker Thomas Schmitt @ 2021-09-03 15:55 ` Valdis Klētnieks 2021-09-03 16:58 ` Thomas Schmitt 0 siblings, 1 reply; 10+ messages in thread From: Valdis Klētnieks @ 2021-09-03 15:55 UTC (permalink / raw) To: Thomas Schmitt; +Cc: ebashinskii, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 797 bytes --] On Fri, 03 Sep 2021 13:00:55 +0200, "Thomas Schmitt" said: > I could offer bugs of isofs with explanations and patch proposals: > > - isofs: prevent file time rollover after year 2038 > Change the return type of function iso_date() from int to time64_t. The tricky part is, of course, that for this to work correctly, you need to have 64-bit timestamps in the on-disk format. > - isofs: truncate oversized Rock Ridge names to 255 bytes > Do not discard all bytes of the NM field where the overflow occurs, but > rather append them to the accumulated name before truncating it to exactly > 255 bytes. > Map trailing incomplete UTF-8 bytes to '_'. A better answer would probably be to truncate it at the last complete UTF-8 that leaves the string at 255 or less. [-- Attachment #1.2: Type: application/pgp-signature, Size: 494 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel bug tracker 2021-09-03 15:55 ` Valdis Klētnieks @ 2021-09-03 16:58 ` Thomas Schmitt 2021-09-05 10:10 ` Re[2]: " Adverg Ebashinskii 0 siblings, 1 reply; 10+ messages in thread From: Thomas Schmitt @ 2021-09-03 16:58 UTC (permalink / raw) To: kernelnewbies; +Cc: ebashinskii, valdis.kletnieks Hi, Valdis Klētnieks wrote: > The tricky part is, of course, that for this to work correctly, you need > to have 64-bit timestamps in the on-disk format. Initially yes. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627 i sketched what it thought was needed to do. But by the much more elegant https://github.com/torvalds/linux/commit/34be4dbf87fc the full ISO 9660 date range up to year 2155 would be correctly shown, if not in year 2038 signed int would roll over. Demo: xorriso -outdev /tmp/test_date.iso \ -blank as_needed \ -map /bin/true /victim \ -alter_date m 'Oct 01 22:06:12 2040' /victim -- mount /tmp/test_date.iso /mnt/iso ls -l /mnt/iso/victim yields currently ... Aug 26 1904 /mnt/iso/victim But after the really simple change to time64_t it yields ... Oct 1 2040 /mnt/iso/victim So this is really a low hanging fruit in fs. Still there today in the torvalds Github repo. ------------------------------------------------------------------------ > > - isofs: truncate oversized Rock Ridge names to 255 bytes > > Map trailing incomplete UTF-8 bytes to '_'. > A better answer would probably be to truncate it at the last complete UTF-8 > that leaves the string at 255 or less. My patch proposal could be changed accordingly. But with '_' as placeholders of bytes from incomplete UTF-8 characters there would be a distinction to names with the same start bytes but ending directly before the UTF-8 character which got cut apart. The need for real truncation should rarely occur. Main motivation for fixing this would be this observation: Currently Rock Ridge names of length >= 254 are coarsely truncated by discarding the whole NM entry where the overflow happened. This yields name lengths of much less than the permissible 255 bytes. There is no reason to see why to exclude length 254 and 255 and especially to truncate by possibly a hundred or more bytes than necessary. File names in ISO 9660 + Rock Ridge ISO 1234567890...230.more.bytes...12345678901234E ääääääääää...210.more.bytes...ääääääääääxää get shown after mount(8) in xterm with bash by /bin/ls as 12345678901234567890...60.more.bytes...1234567890123 'ääääääääääääääääääääääääääääääääääääääääääääää'$'\303' Note the leading blank with the plain ASCII name and the shell characters with the name that has 2-byte UTF-8 characters. (Rock Ridge encodes its names in one or more NM entries. Long names often get split between a NM in the file's ISO 9660 directory record and a NM in the Contiuation Area of the file. That second one gets dropped.) Other than the time rollover fix, this problem needs some knowledge about ISO 9660, which is available for free as ECMA-119, and about SUSP + RRIP of which specs are available for free too. Both are really simple, compared with e.g. UDF specs. I am ready to explain in detail what is neded to understand the problem. If Adverg Ebashinskii wants, i'll hand over my patch as guideline, or as base for own work, or just for review, testing, and posting. I can give instructions how to reproduce each of the three bugs by help of small ISO images made with xorriso. Have a nice day :) Thomas _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re[2]: Kernel bug tracker 2021-09-03 16:58 ` Thomas Schmitt @ 2021-09-05 10:10 ` Adverg Ebashinskii 2021-09-05 11:48 ` Thomas Schmitt 2021-09-05 11:57 ` Thomas Schmitt 0 siblings, 2 replies; 10+ messages in thread From: Adverg Ebashinskii @ 2021-09-05 10:10 UTC (permalink / raw) To: Thomas Schmitt, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 319 bytes --] Hi Thomas, Thanks for the brief explanation of the bugs. > i'll hand over my patch as guideline, or as > base for own work, or just for review, testing, and posting If you could share your patch here to understand the problem better I would gladly dig into it. -- Regards, Adverg Ebashinskii [-- Attachment #1.2: Type: text/html, Size: 2889 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel bug tracker 2021-09-05 10:10 ` Re[2]: " Adverg Ebashinskii @ 2021-09-05 11:48 ` Thomas Schmitt 2021-09-05 12:08 ` Thomas Schmitt 2021-09-06 8:11 ` Re[2]: " Adverg Ebashinskii 2021-09-05 11:57 ` Thomas Schmitt 1 sibling, 2 replies; 10+ messages in thread From: Thomas Schmitt @ 2021-09-05 11:48 UTC (permalink / raw) To: kernelnewbies; +Cc: ebashinskii Hi, Adverg Ebashinskii wrote: > If you could share your patch here to understand the problem better I would > gladly dig into it. Ok. Here is the simple one. The other comes in a separate mail. The following texts stem from git format-patch. If submitting for real, i would send them by git send-email to linux-kernel@vger.kernel.org and linux-scsi@vger.kernel.org. (The latter because Jens Axboe committed a few isofs changes in the past and because isofs is historically related to sr and cdrom.) ======================================================================== 0000-cover-letter.patch From 154a68527351db091e5de60388ba4cfb1fe779fd Mon Sep 17 00:00:00 2001 From: Thomas Schmitt <scdbackup@gmx.net> Date: Mon, 21 Sep 2020 18:20:14 +0200 Subject: [PATCH 0/1] isofs: prevent file time rollover after year 2038 The time values in struct inode of isofs result from calls to function iso_date() in isofs/util.c, which returns seconds in the range of signed int. This will rollover in 2038. ISO 9660 directory record timestamps are good for up to year 2155. (ECMA-119 9.1.5: 1900 + 255) The only callers of iso_date() are in isofs/inode.c and isofs/rock.c and put the result into struct inode.i_{a,c,m}time.tv_sec which is of type time64_t. The time value of iso_date() essentially stems from mktime64(). So return type time64_t is appropriate for iso_date(). -------------------------------------------------------------------------- Demonstration of the problem: Create an ISO 9660 filesystem with file date in 2040, using file /bin/true as victim payload: xorriso -outdev /tmp/test_date.iso \ -blank as_needed \ -map /bin/true /victim \ -alter_date m 'Oct 01 22:06:12 2040' /victim -- Inspect the current representation by isofs: mount /tmp/test_date.iso /mnt/iso ls -l /mnt/iso/victim This yields with int iso_date(): ... Aug 26 1904 /mnt/iso/victim After changing the type of iso_date() to time64_t: ... Oct 1 2040 /mnt/iso/victim For completeness i tested the last possible second: xorriso ... -alter_date m 'Dec 31 23:59:59 2155' /victim -- and got properly: ... Dec 31 2155 /mnt/iso/victim (When reproducing this it might be to wise to use December 30, to avoid any potential timezone problems.) -------------------------------------------------------------------------- Have a nice day :) Thomas Thomas Schmitt (1): isofs: prevent file time rollover after year 2038 fs/isofs/isofs.h | 3 ++- fs/isofs/util.c | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) -- 2.20.1 ======================================================================== 0001-isofs-prevent-file-time-rollover-after-year-2038.patch From 154a68527351db091e5de60388ba4cfb1fe779fd Mon Sep 17 00:00:00 2001 From: Thomas Schmitt <scdbackup@gmx.net> Date: Mon, 21 Sep 2020 18:20:06 +0200 Subject: [PATCH 1/1] isofs: prevent file time rollover after year 2038 Change the return type of function iso_date() from int to time64_t. Signed-off-by: Thomas Schmitt <scdbackup@gmx.net> --- fs/isofs/isofs.h | 3 ++- fs/isofs/util.c | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/isofs/isofs.h b/fs/isofs/isofs.h index 055ec6c586f7..527c0db72ff9 100644 --- a/fs/isofs/isofs.h +++ b/fs/isofs/isofs.h @@ -107,7 +107,8 @@ static inline unsigned int isonum_733(u8 *p) /* Ignore bigendian datum due to broken mastering programs */ return get_unaligned_le32(p); } -extern int iso_date(u8 *, int); + +time64_t iso_date(u8 *, int); struct inode; /* To make gcc happy */ diff --git a/fs/isofs/util.c b/fs/isofs/util.c index e88dba721661..348af786a8a4 100644 --- a/fs/isofs/util.c +++ b/fs/isofs/util.c @@ -16,10 +16,10 @@ * to GMT. Thus we should always be correct. */ -int iso_date(u8 *p, int flag) +time64_t iso_date(u8 *p, int flag) { int year, month, day, hour, minute, second, tz; - int crtime; + time64_t crtime; year = p[0]; month = p[1]; -- 2.20.1 ======================================================================== Have a nice day :) Thomas _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: Kernel bug tracker 2021-09-05 11:48 ` Thomas Schmitt @ 2021-09-05 12:08 ` Thomas Schmitt 2021-09-06 8:11 ` Re[2]: " Adverg Ebashinskii 1 sibling, 0 replies; 10+ messages in thread From: Thomas Schmitt @ 2021-09-05 12:08 UTC (permalink / raw) To: kernelnewbies; +Cc: ebashinskii Hi, maybe i should not have pasted my patches into a new mail. My mail client shows the first mail as three mails. Possibly an effect of the mailbox-like format which it got by pasting in two send-ready git patches. Strangely it shows the second mail with the Rock Ridge patch as a single one. Sorry for any confusion in the receiving mail boxes. Have a nice day :) Thomas _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re[2]: Kernel bug tracker 2021-09-05 11:48 ` Thomas Schmitt 2021-09-05 12:08 ` Thomas Schmitt @ 2021-09-06 8:11 ` Adverg Ebashinskii 2021-09-06 9:04 ` Thomas Schmitt 1 sibling, 1 reply; 10+ messages in thread From: Adverg Ebashinskii @ 2021-09-06 8:11 UTC (permalink / raw) To: Thomas Schmitt, kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 350 bytes --] > Ok. Here is the simple one. The other comes in a separate mail. Hello Thomas, I will try to submit the simplest one first (my very first patch). There are to questions: 1. When submitting the patch should I include you in the copy as the original author? 2. Can I also co-sign the patch by myself? -- Regards, Adverg Ebashinskii [-- Attachment #1.2: Type: text/html, Size: 617 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel bug tracker 2021-09-06 8:11 ` Re[2]: " Adverg Ebashinskii @ 2021-09-06 9:04 ` Thomas Schmitt 0 siblings, 0 replies; 10+ messages in thread From: Thomas Schmitt @ 2021-09-06 9:04 UTC (permalink / raw) To: kernelnewbies; +Cc: ebashinskii Hi, > 1. When submitting the patch should I include you in the copy > as the original author? I guess this is more a question for the experienced patch submitters. My cheat sheet points to https://www.kernel.org/doc/html/v5.10/process/submitting-patches.html The code change is trivial enough that i do not claim authorship. So how about Suggested-by: Thomas Schmitt <scdbackup@gmx.net> I found the bug and suggested an obvious fix. The most kernel merit i can claim is that i grepped through the kernel sources for callers of iso_date() and found them all ready for the change of result type. So maybe Co-developed-by: Thomas Schmitt <scdbackup@gmx.net> Signed-off-by: Thomas Schmitt <scdbackup@gmx.net> But on the other hand you should verify my claims in 0000-cover-letter.patch before posting your patch. A year has passed since i did my research and testing. So my statements create not more authorship than a detailed bug report would do. Have a nice day :) Thomas _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Kernel bug tracker 2021-09-05 10:10 ` Re[2]: " Adverg Ebashinskii 2021-09-05 11:48 ` Thomas Schmitt @ 2021-09-05 11:57 ` Thomas Schmitt 1 sibling, 0 replies; 10+ messages in thread From: Thomas Schmitt @ 2021-09-05 11:57 UTC (permalink / raw) To: kernelnewbies; +Cc: ebashinskii Hi, second patch proposal for isofs because Adverg Ebashinskii wrote: > If you could share your patch here to understand the problem better I would > gladly dig into it. ======================================================================== 0000-cover-letter.patch From 3d484405f0ad8d10ef490281da157bfdd7450cb6 Mon Sep 17 00:00:00 2001 From: Thomas Schmitt <scdbackup@gmx.net> Date: Tue, 22 Sep 2020 12:35:52 +0200 Subject: [PATCH 0/1] isofs: truncate oversized Rock Ridge names to 255 bytes Currently Rock Ridge names of length >= 254 are coarsely truncated by discarding the whole NM entry where the overflow happened. This yields name lengths of much less than the permissible 255 bytes. There is no reason to see why to exclude length 254 and 255 and especially to truncate by possibly a hundred or more bytes than necessary. So i propose to raise the length of permissible names to 255 and to let truncation yield exactly a string length of 255 bytes. Truncation shall take care to invalidate UTF-8 debris at the end of the resulting string (sorry ISO-8859). --------------------------------------------------------------------------- Tests made: Create an ISO 9660 image with file names of length 255, using file /bin/true as input for both files: victim1=12345678901234567890123456789012345678901234567890 victim1="$victim1"12345678901234567890123456789012345678901234567890 victim1="$victim1"12345678901234567890123456789012345678901234567890 victim1="$victim1"12345678901234567890123456789012345678901234567890 victim1="$victim1"12345678901234567890123456789012345678901234567890 victim1="$victim1"1234E victim2=äääääääääääääääääääääääää victim2="$victim2"äääääääääääääääääääääääää victim2="$victim2"äääääääääääääääääääääääää victim2="$victim2"äääääääääääääääääääääääää victim2="$victim2"äääääääääääääääääääääääää victim2="$victim2"xää xorriso -outdev /tmp/test_rr_name.iso \ -blank as_needed \ -map /bin/true /"$victim1" \ -map /bin/true /"$victim2" Currently the names get truncated to byte lengths 93 and 95: mount /tmp/test_rr_name.iso /mnt/iso /bin/ls /mnt/iso yields in xterm with bash 12345678901234567890...60.more.bytes...1234567890123 'ääääääääääääääääääääääääääääääääääääääääääääää'$'\303' Note the leading blank with the plain ASCII name and the shell characters with the name that has 2-byte UTF-8 characters. But /bin/ls /mnt/iso | cat yields 12345678901234567890...60.more.bytes...1234567890123 ääääääääääääääääääääääääääääääääääääääääääääää� The extra characters in xterm seem to be triggered by the presence of the half UTF-8 'ä' at the end. Its byte 0xc3 is there, byte 0xa4 is missing. (xterm and /bin/ls are from Debian 10.) If i make the UTF-8 name shorter to avoid truncation or if i move the 'x' to the start to cause truncation between complete UTF-8 'ä', the extra characters do not show up in ls to xterm. After my change in fs/isofs i get from /bin/ls /mnt/iso 1234567890...230.more.bytes...12345678901234E ääääääääää...210.more.bytes...ääääääääääxää Both strings have 255 bytes. xorriso cannot be talked into writing longer Rock Ridge names. So i rather set the new macro RR_NAME_LEN in rock.h to 33 to force truncation. The result with /bin/ls -1 /mnt/iso is: 123456789012345678901234567890123 ääääääääääääääää_ Note the half 'ä' at the end being mapped to '_'. So all characters are valid UTF-8 and no oddities of ls or xterm are to see. --------------------------------------------------------------------------- Remaining checkpatch.pl warning: scripts/checkpatch.pl complains about the string 'ääääääääääääääääääääääääääääääääääääääääääääää'$'\303' in this text by: WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) Maybe it should talk about "bytes" rather than "chars" or learn about multi-byte characters in UTF-8. I think it is beneficial if i show the whole mangled name, rather than describing it by some ASCII-only text. --------------------------------------------------------------------------- Have a nice day :) Thomas Thomas Schmitt (1): isofs: truncate oversized Rock Ridge names to 255 bytes fs/isofs/rock.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++--- fs/isofs/rock.h | 2 ++ 2 files changed, 71 insertions(+), 4 deletions(-) -- 2.20.1 ======================================================================== 0001-isofs-truncate-oversized-Rock-Ridge-names-to-255-byt.patch From 3d484405f0ad8d10ef490281da157bfdd7450cb6 Mon Sep 17 00:00:00 2001 From: Thomas Schmitt <scdbackup@gmx.net> Date: Tue, 22 Sep 2020 12:34:50 +0200 Subject: [PATCH 1/1] isofs: truncate oversized Rock Ridge names to 255 bytes Enlarge the limit for name bytes from 253 to 255. Do not discard all bytes of the NM field where the overflow occurs, but rather append them to the accumulated name before truncating it to exactly 255 bytes. Map trailing incomplete UTF-8 bytes to '_'. Signed-off-by: Thomas Schmitt <scdbackup@gmx.net> --- fs/isofs/rock.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++--- fs/isofs/rock.h | 2 ++ 2 files changed, 71 insertions(+), 4 deletions(-) diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c index 94ef92fe806c..e1db8776b67e 100644 --- a/fs/isofs/rock.c +++ b/fs/isofs/rock.c @@ -192,6 +192,63 @@ static int rock_check_overflow(struct rock_state *rs, int sig) return 0; } +/* + * Find backward from idx the start byte of a possible UTF-8 character. + * https://en.wikipedia.org/wiki/UTF-8#Description + * Return -1 if no incomplete UTF-8 sequence is found at the name end. + */ +static int rock_find_utf8_start(char *name, int idx) +{ + unsigned char *uname, uch; + int i; + + uname = (unsigned char *)name; + /* Up to 4-byte codes */ + for (i = 0; i < 4 && idx - i >= 0; i++) { + uch = uname[idx - i]; + if ((uch & 0xe0) == 0xc0) { + /* UTF-8 start byte for 2-byte codes */ + if (i >= 1) + return -1; /* tail is complete */ + else + return (idx - i); /* tail not complete */ + } else if ((uch & 0xf0) == 0xe0) { + /* UTF-8 start byte for 3-byte codes */ + if (i >= 2) + return -1; + else + return (idx - i); + } else if ((uch & 0xf8) == 0xf0) { + /* UTF-8 start byte for 4-byte codes */ + if (i >= 3) + return -1; + else + return (idx - i); + } else if ((uch & 0xc0) != 0x80) { + /* not an UTF-8 tail byte, so no UTF-8 */ + return -1; + } + } + /* That would be an oversized UTF-8 code or no UTF-8 at all */ + return -1; +} + +/* + * Replace trailing incomplete UTF-8 sequence by '_' characters. + */ +static void rock_erase_incomplete_utf8(char *name, int len) +{ + int i; + + if (len <= 0) + return; + i = rock_find_utf8_start(name, len - 1); + if (i < 0) + return; + for (; i < len; i++) + name[i] = '_'; +} + /* * return length of name field; 0: not found, -1: to be ignored */ @@ -271,16 +328,24 @@ int get_rock_ridge_filename(struct iso_directory_record *de, break; } len = rr->len - 5; - if (retnamlen + len >= 254) { - truncate = 1; - break; - } p = memchr(rr->u.NM.name, '\0', len); if (unlikely(p)) len = p - rr->u.NM.name; + if (retnamlen + len > RR_NAME_LEN) { + truncate = 1; + /* Take as many characters as possible */ + len = RR_NAME_LEN - retnamlen; + if (len <= 0) { + rock_erase_incomplete_utf8(retname, + retnamlen); + break; + } + } memcpy(retname + retnamlen, rr->u.NM.name, len); retnamlen += len; retname[retnamlen] = '\0'; + if (truncate == 1) + rock_erase_incomplete_utf8(retname, retnamlen); break; case SIG('R', 'E'): kfree(rs.buffer); diff --git a/fs/isofs/rock.h b/fs/isofs/rock.h index 1558cf22ef8a..0938fc11ced4 100644 --- a/fs/isofs/rock.h +++ b/fs/isofs/rock.h @@ -121,3 +121,5 @@ struct rock_ridge { #define RR_PL 32 /* Parent link */ #define RR_RE 64 /* Relocation directory */ #define RR_TF 128 /* Timestamps */ + +#define RR_NAME_LEN 255 /* Maximum length in bytes of a file name */ -- 2.20.1 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply related [flat|nested] 10+ messages in thread
[parent not found: <1630220663.155756289@f748.i.mail.ru>]
* Re: Kernel bug tracker [not found] <1630220663.155756289@f748.i.mail.ru> @ 2021-08-29 8:50 ` Anatoly Pugachev 0 siblings, 0 replies; 10+ messages in thread From: Anatoly Pugachev @ 2021-08-29 8:50 UTC (permalink / raw) To: Adverg Ebashinskii; +Cc: kernelnewbies On Sun, Aug 29, 2021 at 10:04 AM Adverg Ebashinskii <ebashinskii@mail.ru> wrote: > > Hello. > > I’m a kernel newbie and try to get involved into the Kernel development. So I’d like to start with small bug fixes related to any subsystem (fs is preferred since I familiar with it the most) or something like that. > > Is there some kernel bug tracker where anybody could pick a bug to fix and then send patches? https://bugzilla.kernel.org/ There's as well per linux distribution / vendor bug reporting web interfaces, like http://bugs.debian.org/ and/or https://bugs.launchpad.net/ https://bugzilla.redhat.com/ where users could first post their bugs _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-09-06 9:06 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1630659351.685242253@f502.i.mail.ru> 2021-09-03 11:00 ` Kernel bug tracker Thomas Schmitt 2021-09-03 15:55 ` Valdis Klētnieks 2021-09-03 16:58 ` Thomas Schmitt 2021-09-05 10:10 ` Re[2]: " Adverg Ebashinskii 2021-09-05 11:48 ` Thomas Schmitt 2021-09-05 12:08 ` Thomas Schmitt 2021-09-06 8:11 ` Re[2]: " Adverg Ebashinskii 2021-09-06 9:04 ` Thomas Schmitt 2021-09-05 11:57 ` Thomas Schmitt [not found] <1630220663.155756289@f748.i.mail.ru> 2021-08-29 8:50 ` Anatoly Pugachev
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).