* Re: Kernel bug tracker [not found] <1630220663.155756289@f748.i.mail.ru> @ 2021-08-29 8:50 ` Anatoly Pugachev 2021-08-29 9:39 ` Re[2]: " Adverg Ebashinskii [not found] ` <1630659311.419989149@f519.i.mail.ru> 1 sibling, 1 reply; 6+ 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] 6+ messages in thread
* Re[2]: Kernel bug tracker 2021-08-29 8:50 ` Kernel bug tracker Anatoly Pugachev @ 2021-08-29 9:39 ` Adverg Ebashinskii 2021-08-31 7:09 ` Valdis Klētnieks 0 siblings, 1 reply; 6+ messages in thread From: Adverg Ebashinskii @ 2021-08-29 9:39 UTC (permalink / raw) To: Anatoly Pugachev; +Cc: kernelnewbies [-- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re[2]: Kernel bug tracker 2021-08-29 9:39 ` Re[2]: " Adverg Ebashinskii @ 2021-08-31 7:09 ` Valdis Klētnieks 0 siblings, 0 replies; 6+ messages in thread From: Valdis Klētnieks @ 2021-08-31 7:09 UTC (permalink / raw) To: Adverg Ebashinskii; +Cc: Anatoly Pugachev, kernelnewbies [-- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <1630659311.419989149@f519.i.mail.ru>]
[parent not found: <41823.1630683623@turing-police>]
* Re[6]: Kernel bug tracker [not found] ` <41823.1630683623@turing-police> @ 2021-09-05 10:07 ` Adverg Ebashinskii 0 siblings, 0 replies; 6+ messages in thread From: Adverg Ebashinskii @ 2021-09-05 10:07 UTC (permalink / raw) To: Valdis Klētnieks, kernelnewbies [-- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel bug tracker @ 2021-09-03 15:55 Valdis Klētnieks 2021-09-03 16:58 ` Thomas Schmitt 0 siblings, 1 reply; 6+ 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] 6+ 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; 6+ 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] 6+ 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 0 siblings, 1 reply; 6+ 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] 6+ 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-06 8:11 ` Re[2]: " Adverg Ebashinskii 0 siblings, 1 reply; 6+ 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] 6+ messages in thread
* Re[2]: Kernel bug tracker 2021-09-05 11:48 ` Thomas Schmitt @ 2021-09-06 8:11 ` Adverg Ebashinskii 0 siblings, 0 replies; 6+ 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] 6+ messages in thread
end of thread, other threads:[~2021-09-06 8:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1630220663.155756289@f748.i.mail.ru>
2021-08-29 8:50 ` Kernel bug tracker Anatoly Pugachev
2021-08-29 9:39 ` Re[2]: " Adverg Ebashinskii
2021-08-31 7:09 ` Valdis Klētnieks
[not found] ` <1630659311.419989149@f519.i.mail.ru>
[not found] ` <41823.1630683623@turing-police>
2021-09-05 10:07 ` Re[6]: " Adverg Ebashinskii
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-06 8:11 ` Re[2]: " Adverg Ebashinskii
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).