Re: Kernel bug tracker

Re: Kernel bug tracker

[Anatoly Pugachev]

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

Re[2]: Kernel bug tracker

[Adverg Ebashinskii]

[-- Attachment #1.1: Type: text/plain, Size: 166 bytes --]


 
Hi Anatoly,
 
Thank you very much for your response. https://bugzilla.kernel.org looks exactly what I was looking for.
 
--
Regards,
Adverg Ebashinskii
 
 
 

[-- Attachment #1.2: Type: text/html, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Re[2]: Kernel bug tracker

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 2210 bytes --]

On Sun, 29 Aug 2021 12:39:28 +0300, Adverg Ebashinskii said:

> Hi Anatoly,

> Thank you very much for your response. https://bugzilla.kernel.org looks
> exactly what I was looking for.

Note that the Bugzilla probably *isn't* what you're looking for, if you're
looking for small easy patches to start with.

Hint: Many long-time kernel developers say the bugzilla is where kernel bugs go
to die.

That's because if it's an open bug in the bugzilla, one or more of the
following things are probably true:

* The bug has actually already been fixed but nobody ever bothered closing the
bugzilla entry.

* The bug isn't reproducible on a common configuration, either due to specific
hardware requirements (like a specific card at a specific firmware release), or
the software replicator for the issue isn't known, so only one computer can
reliably trigger the issue. (A few years back, Linus and a few others finally
swatted a bug that triggered on *one* system several times a week.  It turned
out to be a race condition, with a window caused by interrupts being re-enabled
3 instructions too early.  So that one system was doing something that hit this
literally billionth-of-a-second wide window several times a week).

* The bug doesn't have an obvious/easy fix, so it's sitting in the bugzilla
while people try to come up with a fix that isn't too ugly to be allowed to
live. Once you get all the git configuration done and working, it's usually
faster to just create and submit the patch rather than open a bugzilla entry,
so bugzilla entries don't get created for obvious patches.

* The bug report requires more information, and the original reporter of the
bug has evaporated.

Your best source for low-hanging fruit these days is probably drivers/staging,
as pretty much everything under there is *known* to be less-than-optimal. There
should even be a TODO file for each driver in there, saying what stuff is known
to need work.  (Note that it's always possible that things get fixed but the
TODO file doesn't get updated - that's a potential source of cleanup patches as
well)

Good luck.  And remember to back up your system before testing patches. :)


[-- 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

Re[6]: Kernel bug tracker

[Adverg Ebashinskii]

[-- Attachment #1.1: Type: text/plain, Size: 573 bytes --]


Hi Valdis,
 
> You might want to read this
 
Thanks for the info it was very interesting to read. My primary intention of getting into the Linux Kernel Development is that I myself used to be a C/Linux developer for years on the user side and pretty well-versed in the Linux user-space API. But the thing is that I have almost zero knowledge of what actually going on under the hood and how to debug and fix complicated problems related to the Kernel itself.  So this is the reason of my interest precisely to core subsystems.
 
--
Regards,
Adverg Ebashinskii
 
 

[-- Attachment #1.2: Type: text/html, Size: 1890 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Kernel bug tracker

[Thomas Schmitt]

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

Re: Kernel bug tracker

[Valdis Klētnieks]

[-- 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

Re: Kernel bug tracker

[Thomas Schmitt]

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

Re[2]: Kernel bug tracker

[Adverg Ebashinskii]

[-- 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

Re: Kernel bug tracker

[Thomas Schmitt]

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

Re: Kernel bug tracker

[Thomas Schmitt]

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

Re: Kernel bug tracker

[Thomas Schmitt]

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

Re[2]: Kernel bug tracker

[Adverg Ebashinskii]

[-- 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

Re: Kernel bug tracker

[Thomas Schmitt]

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