kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
* Please give advise about my first patch attempt
@ 2020-08-27  8:49 Thomas Schmitt
  2020-08-27  9:26 ` Lukas Bulwahn
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Thomas Schmitt @ 2020-08-27  8:49 UTC (permalink / raw)
  To: kernelnewbies

Hi,

i am preparing my first patch.
May i ask for review and advise how to make it acceptable ?

The patch shall fix an old regression of cdrom and sr drivers.
Although drivers/cdrom has no mailing list entry in MAINTAINERS, i assume
that such patches should go to linux-scsi@vger.kernel.org which is listed
for drivers/scsi/sr*. Right ?

So the change affects two different subsystems which have the same maintainer
and have a very close relation. Do i need to split it into two, nevertheless ?

The change is relative to git tag v5.8 of
  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
It is not locally committed yet, so i cannot run git format-patch for now.
I plan to do if i get some approval here.

I tested with three different optical drives at SATA and USB by
  dd if=/dev/sr0 bs=2048 count=1 of=/dev/null
Unchanged yields ENOMEDIUM or EIO. Changed yields success.

Please also tell me if my mailer (used with this mail) would cause problems.

--------------------------------------------------------------------------

Affected files:
  drivers/cdrom/cdrom.c
  drivers/scsi/sr.c
  include/linux/cdrom.h

Check passed:
  scripts/checkpatch.pl
reports
  total: 0 errors, 0 warnings, 131 lines checked

--------------------------------------------------------------------------
Intended commit message:
--------------------------------------------------------------------------

Re-enable waiting for CD drive to complete medium decision after tray load

If
  open("/dev/sr0", O_RDONLY);
pulls in the tray of an optical drive, it immediately returns -1 with
errno ENOMEDIUM or the first read(2) fails with EIO. Later, when the drive
has stopped blinking, another open() yields success and read() works.
This affects not only userland reading of the device file but also mounting
the device.

Commit 210ba1d1724f5c4ed87a2ab1a21ca861a915f734 of january 2008 switched
sr_drive_status() away from indirectly using sr_do_ioctl() for sending
TEST UNIT READY commands. sr_do_ioctl() has a wait-and-retry loop for
the drive's intermediate sense reply:
  2 04 01 Logical unit is in process of becoming ready
Since then sr_drive_status() does not wait any more.
By commit 96bcc722c47d07b6fd05c9d0cb3ab8ea5574c5b1 of july 2008 it now
returns CDS_DRIVE_NOT_READY if above drive reply is received.

But the function open_for_data() in drivers/cdrom/cdrom.c expects that
its call of cdo->drive_status() waits until the drive has decided about
the usability of the inserted medium. Any reply other than CDS_DISC_OK
yields ENOMEDIUM.
Even if the drive waits with its reply to START/STOP UNIT until it is
ready (e.g. Pioneer BDR-S09), the first read(2) yields EIO, because the
newly loaded medium gets not properly assessed by check_disk_change()
before sr_block_open() returns.

Fix the problem by a new function wait_for_medium_decision() which gets
called by open_for_data() instead of directly calling cdo->drive_status().
Make sure that scsi/sr.c assesses the newly loaded medium without additional
risk of deadlock.

After loading the tray and due waiting for readiness, cdrom_open() now returns
-EDEADLK to urge its caller to drop its mutex, to re-run check_disk_change(),
and then to call cdrom_open() again. Only scsi/sr.c is for now aware of this.

cdrom/gdrom.c, paride/pcd.c, and ide/ide-cd.c call cdrom_open() too, but i
cannot test them. So their unchanged code will return -EDEADLK instead of
retrying. Not worse or more deceiving than -ENOMEDIUM or -EIO.

Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>

--------------------------------------------------------------------------
Code change:
--------------------------------------------------------------------------

diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index d82b3b7658bd..9e113b0dfc82 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -286,6 +286,18 @@
 #include <scsi/scsi_common.h>
 #include <scsi/scsi_request.h>

+/*
+ * For the wait-and-retry loop after possibly having loaded the drive tray.
+ * 10 retries in 20 seconds are hardcoded in sr_do_ioctl() which was used
+ * up to 2008.
+ * But time spans up to 25 seconds were measured by libburn on
+ * drives connected via SATA or USB-SATA bridges.
+ * So 20 retries * 2000 ms = 40 seconds seems more appropriate.
+ */
+#define CD_OPEN_MEDIUM_RETRY_MAX 20
+#define CD_OPEN_MEDIUM_RETRY_MSLEEP 2000
+#include <linux/delay.h>
+
 /* used to tell the module to turn on full debugging messages */
 static bool debug;
 /* default compatibility mode */
@@ -1040,10 +1052,38 @@ static void cdrom_count_tracks(struct cdrom_device_info *cdi, tracktype *tracks)
 	       tracks->cdi, tracks->xa);
 }

+static
+int wait_for_medium_decision(struct cdrom_device_info *cdi)
+{
+	int ret, retry = 0;
+	const struct cdrom_device_ops *cdo = cdi->ops;
+
+	/* Wait until the intermediate drive status CDS_DRIVE_NOT_READY ends */
+	while (1) {
+		ret = cdo->drive_status(cdi, CDSL_CURRENT);
+		if (ret == CDS_DRIVE_NOT_READY &&
+		    retry++ < CD_OPEN_MEDIUM_RETRY_MAX)
+			msleep(CD_OPEN_MEDIUM_RETRY_MSLEEP);
+		else
+			break;
+	}
+	if (ret != CDS_DISC_OK)
+		return ret;
+	/*
+	 * It is hard to test whether very recent readiness can cause race
+	 * conditions with media change events. So wait a while to never
+	 * undercut the average delay between actual readiness and detection
+	 * which was tested without this additional msleep().
+	 */
+	msleep(CD_OPEN_MEDIUM_RETRY_MSLEEP / 2);
+
+	return CDS_DISC_OK;
+}
+
 static
 int open_for_data(struct cdrom_device_info *cdi)
 {
-	int ret;
+	int ret, tray_was_moved = 0;
 	const struct cdrom_device_ops *cdo = cdi->ops;
 	tracktype tracks;
 	cd_dbg(CD_OPEN, "entering open_for_data\n");
@@ -1069,13 +1109,17 @@ int open_for_data(struct cdrom_device_info *cdi)
 					ret=-ENOMEDIUM;
 					goto clean_up_and_return;
 				}
+				tray_was_moved = 1;
 			} else {
 				cd_dbg(CD_OPEN, "bummer. this drive can't close the tray.\n");
 				ret=-ENOMEDIUM;
 				goto clean_up_and_return;
 			}
-			/* Ok, the door should be closed now.. Check again */
-			ret = cdo->drive_status(cdi, CDSL_CURRENT);
+			/*
+			 * The door should be closed now, or in the process of
+			 * closing and assessing the medium.
+			 */
+			ret = wait_for_medium_decision(cdi);
 			if ((ret == CDS_NO_DISC) || (ret==CDS_TRAY_OPEN)) {
 				cd_dbg(CD_OPEN, "bummer. the tray is still not closed.\n");
 				cd_dbg(CD_OPEN, "tray might not contain a medium\n");
@@ -1090,6 +1134,14 @@ int open_for_data(struct cdrom_device_info *cdi)
 			ret = -ENOMEDIUM;
 			goto clean_up_and_return;
 		}
+		if (tray_was_moved) {
+			/*
+			 * Bail out now to let callers like sr_block_open()
+			 * unlock their mutex and run check_disk_change()
+			 */
+			ret = -EDEADLK;
+			goto clean_up_and_return;
+		}
 	}
 	cdrom_count_tracks(cdi, &tracks);
 	if (tracks.error == CDS_NO_DISC) {
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 0c4aa4665a2f..a26c33c44ab9 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -521,7 +521,7 @@ static int sr_block_open(struct block_device *bdev, fmode_t mode)
 {
 	struct scsi_cd *cd;
 	struct scsi_device *sdev;
-	int ret = -ENXIO;
+	int ret = -ENXIO, tried = 0;

 	cd = scsi_cd_get(bdev->bd_disk);
 	if (!cd)
@@ -529,11 +529,16 @@ static int sr_block_open(struct block_device *bdev, fmode_t mode)

 	sdev = cd->device;
 	scsi_autopm_get_device(sdev);
+retry:
+	tried++;
 	check_disk_change(bdev);

 	mutex_lock(&cd->lock);
 	ret = cdrom_open(&cd->cdi, bdev, mode);
 	mutex_unlock(&cd->lock);
+	if (ret == -EDEADLK && tried <= 1)
+		/* Tray was loaded. Assess medium by check_disk_change(). */
+		goto retry;

 	scsi_autopm_put_device(sdev);
 	if (ret)
diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h
index 8543fa59da72..68d8297e6208 100644
--- a/include/linux/cdrom.h
+++ b/include/linux/cdrom.h
@@ -100,8 +100,17 @@ int cdrom_read_tocentry(struct cdrom_device_info *cdi,
 		struct cdrom_tocentry *entry);

 /* the general block_device operations structure: */
+
+/*
+ * Peculiarity:
+ * cdrom_open() returns -EDEADLK after automatically loading the tray, because
+ * it expects to be called under various mutexes after the callers called
+ * check_disk_change() outside of these mutex acquirations. Callers which get
+ * -EDEADLK should for once re-run check_disk_change() and retry cdrom_open().
+ */
 extern int cdrom_open(struct cdrom_device_info *cdi, struct block_device *bdev,
 			fmode_t mode);
+
 extern void cdrom_release(struct cdrom_device_info *cdi, fmode_t mode);
 extern int cdrom_ioctl(struct cdrom_device_info *cdi, struct block_device *bdev,
 		       fmode_t mode, unsigned int cmd, unsigned long arg);

--------------------------------------------------------------------------


Have a nice day :)

Thomas


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

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27  8:49 Please give advise about my first patch attempt Thomas Schmitt
@ 2020-08-27  9:26 ` Lukas Bulwahn
  2020-08-27 16:34   ` Thomas Schmitt
  2020-08-27  9:52 ` Garrit Franke
  2020-08-27 18:32 ` Pawan Gupta
  2 siblings, 1 reply; 11+ messages in thread
From: Lukas Bulwahn @ 2020-08-27  9:26 UTC (permalink / raw)
  To: Thomas Schmitt; +Cc: kernelnewbies


Hi Thomas,

On Thu, 27 Aug 2020, Thomas Schmitt wrote:

> Hi,
> 
> i am preparing my first patch.
> May i ask for review and advise how to make it acceptable ?
> 
> The patch shall fix an old regression of cdrom and sr drivers.
> Although drivers/cdrom has no mailing list entry in MAINTAINERS, i assume
> that such patches should go to linux-scsi@vger.kernel.org which is listed
> for drivers/scsi/sr*. Right ?
> 
> So the change affects two different subsystems which have the same maintainer
> and have a very close relation. Do i need to split it into two, nevertheless ?
>

I do not think there is a need to split it. Just take all maintainers as 
recipients.

./scripts/get_maintainer.pl  include/linux/cdrom.h
Jens Axboe <axboe@kernel.dk> (maintainer:UNIFORM CDROM DRIVER)
linux-kernel@vger.kernel.org (open list)

./scripts/get_maintainer.pl  drivers/scsi/sr.c
Jens Axboe <axboe@kernel.dk> (maintainer:SCSI CDROM DRIVER)
"James E.J. Bottomley" <jejb@linux.ibm.com> (maintainer:SCSI SUBSYSTEM)
"Martin K. Petersen" <martin.petersen@oracle.com> (maintainer:SCSI 
SUBSYSTEM)
linux-scsi@vger.kernel.org (open list:SCSI CDROM DRIVER)
linux-kernel@vger.kernel.org (open list)

./scripts/get_maintainer.pl  drivers/cdrom/cdrom.c
Jens Axboe <axboe@kernel.dk> (maintainer:UNIFORM CDROM DRIVER)
linux-kernel@vger.kernel.org (open list)


I assume Jens Axboe is going to pick it and forward that to Linus.

> The change is relative to git tag v5.8 of
>   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> It is not locally committed yet, so i cannot run git format-patch for now.
> I plan to do if i get some approval here.
>

It is probably best to base it on v5.9-rc2 (or -rc3 next week) and check 
if it cleanly applies on the latest linux-next. More on that is in the 
kernel documentation, see how to contribute.


> I tested with three different optical drives at SATA and USB by
>   dd if=/dev/sr0 bs=2048 count=1 of=/dev/null
> Unchanged yields ENOMEDIUM or EIO. Changed yields success.
> 
> Please also tell me if my mailer (used with this mail) would cause problems.
>

I suggest to use an own branch on git, then git format-patch -1, git 
send-email ... <patch>, which usually does what you want without any 
bigger issues.

I cannot comment on the technical stuff, but that what the mailing list is 
good for; so, if you got the tools for submitting a patch set up, just go 
for the mailing lists. Not that too many people care for CDROM drivers 
nowadays, but you will probably get some feedback and maybe you are the 
next maintainer for CDROM drivers when you continue to test CDROM :)


Lukas

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27  8:49 Please give advise about my first patch attempt Thomas Schmitt
  2020-08-27  9:26 ` Lukas Bulwahn
@ 2020-08-27  9:52 ` Garrit Franke
  2020-08-27 13:19   ` Greg KH
  2020-08-27 18:32 ` Pawan Gupta
  2 siblings, 1 reply; 11+ messages in thread
From: Garrit Franke @ 2020-08-27  9:52 UTC (permalink / raw)
  To: Thomas Schmitt; +Cc: Linux Kernel List

Hi Thomas,

Noob here.

On Thu, Aug 27, 2020 at 10:49 AM Thomas Schmitt <scdbackup@gmx.net> wrote:
>
> Commit 210ba1d1724f5c4ed87a2ab1a21ca861a915f734 of january 2008 switched
> sr_drive_status() away from indirectly using sr_do_ioctl() for sending
> TEST UNIT READY commands. sr_do_ioctl() has a wait-and-retry loop for
> the drive's intermediate sense reply:

In a recent Patch of mine, Greg nicely pointed out that commits should
have a standard format across mailing lists: sha ("Commit Message").

See: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2235132.html

Regards
Garrit

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27  9:52 ` Garrit Franke
@ 2020-08-27 13:19   ` Greg KH
  2020-08-27 14:02     ` Leam Hall
  0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2020-08-27 13:19 UTC (permalink / raw)
  To: Garrit Franke; +Cc: Thomas Schmitt, Linux Kernel List

On Thu, Aug 27, 2020 at 11:52:56AM +0200, Garrit Franke wrote:
> Hi Thomas,
> 
> Noob here.
> 
> On Thu, Aug 27, 2020 at 10:49 AM Thomas Schmitt <scdbackup@gmx.net> wrote:
> >
> > Commit 210ba1d1724f5c4ed87a2ab1a21ca861a915f734 of january 2008 switched
> > sr_drive_status() away from indirectly using sr_do_ioctl() for sending
> > TEST UNIT READY commands. sr_do_ioctl() has a wait-and-retry loop for
> > the drive's intermediate sense reply:
> 
> In a recent Patch of mine, Greg nicely pointed out that commits should
> have a standard format across mailing lists: sha ("Commit Message").
> 
> See: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2235132.html

That is also documented in the ever-growing submitting patches document
somewhere...

thanks,

greg k-h

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27 13:19   ` Greg KH
@ 2020-08-27 14:02     ` Leam Hall
  2020-08-27 16:01       ` Greg KH
  0 siblings, 1 reply; 11+ messages in thread
From: Leam Hall @ 2020-08-27 14:02 UTC (permalink / raw)
  To: Linux Kernel List; +Cc: Garrit Franke, Thomas Schmitt

On Thu, Aug 27, 2020 at 9:20 AM Greg KH <greg@kroah.com> wrote:

> That is also documented in the ever-growing submitting patches document
> somewhere...

This?

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27 14:02     ` Leam Hall
@ 2020-08-27 16:01       ` Greg KH
  0 siblings, 0 replies; 11+ messages in thread
From: Greg KH @ 2020-08-27 16:01 UTC (permalink / raw)
  To: Leam Hall; +Cc: Garrit Franke, Thomas Schmitt, Linux Kernel List

On Thu, Aug 27, 2020 at 10:02:21AM -0400, Leam Hall wrote:
> On Thu, Aug 27, 2020 at 9:20 AM Greg KH <greg@kroah.com> wrote:
> 
> > That is also documented in the ever-growing submitting patches document
> > somewhere...
> 
> This?
> 
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html

That's a pretty old version :)

And sorry for being vague, I was meaning that somewhere in that file it
talked about how to properly reference git ids, it's in section 2:
	https://www.kernel.org/doc/html/latest/process/submitting-patches.html
at the end of the section.

thanks,

greg k-h

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27  9:26 ` Lukas Bulwahn
@ 2020-08-27 16:34   ` Thomas Schmitt
  2020-08-27 17:30     ` Lukas Bulwahn
  0 siblings, 1 reply; 11+ messages in thread
From: Thomas Schmitt @ 2020-08-27 16:34 UTC (permalink / raw)
  To: kernelnewbies; +Cc: lukas.bulwahn, garritfranke, greg

Hi,

Lukas Bulwahn wrote:
> Just take all maintainers as recipients.
> axboe@kernel.dk linux-kernel@vger.kernel.org jejb@linux.ibm.com
> martin.petersen@oracle.com linux-scsi@vger.kernel.org

Really that loudly ?
Ain't linux-kernel@vger.kernel.org too general ?


> It is probably best to base it on v5.9-rc2

Done. The patch was accepted by git apply. git diff looks good.
(There were indeed changes in cdrom.c and cdrom.h. It's not that dead. :))

It compiles, but does not boot:

  [1.099627] nvme nvme0: failed to set APST feature (-10)
  Gave up waiting for root filesystem device

I booted the 5.8 kernel and was happy to see my SSD well and alive.
Then i reverted my changes, compiled and installed the original 5.9-rc2.
Same boot failure (it would have been astonishing if not).

So i cannot test on 5.9-rc2.
(Had to manually rename vmlinuz-5.9.0-rc2-ts and initrd.img-5.9.0-rc2-ts
 before update-grub was willing to create a .cfg which does not boot it
 by default. Eww ... whenever i leave the trodden path ...)


> check if it cleanly applies on the latest linux-next

I read
  https://www.kernel.org/doc/man-pages/linux-next.html
and did without really knowing why:

  $ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
  $ git fetch linux-next
  ...
  * [new branch]                akpm          -> linux-next/akpm
  * [new branch]                akpm-base     -> linux-next/akpm-base
  * [new branch]                master        -> linux-next/master
  * [new branch]                pending-fixes -> linux-next/pending-fixes
  * [new branch]                stable        -> linux-next/stable
  * [new tag]                   next-20200827 -> next-20200827
  $ git checkout master
  ...
  $ git remote update
  ...
  Fetching linux-next
  $ git checkout -B linux-next-20200827-ts-issue-2 next-20200827
  Switched to a new branch 'linux-next-20200827-ts-issue-2'
  $ git apply /home/thomas/v5.9-rc2_issue_2.git.diff
  $

Compilation succeeds and it boots.

  dd if=/dev/sr0 bs=2048 count=1 of=/dev/null
  dd if=/dev/sr1 bs=2048 count=1 of=/dev/null
both succeed starting from open tray with a readable medium in it.

So shall i base my patch on next-20200827 ?

-------------------------------------------------------------------------

> > Please also tell me if my mailer (used with this mail) would cause
> > problems.

> I suggest [...] git send-email ... <patch>

I am not sure whether i can get git send-email to work due to local
network issues. My free software mails go out by a primitive SMTP client
which gets fed with plain text files, usually created by vim.

Thus i ask whether my mails show any properties which would hamper
acceptance of a patch, which i would generate by git format-patch.

(I look at patches in https://marc.info/?l=linux-scsi and will try to
 mimick them in my text file as good as possible.)


> I cannot comment on the technical stuff, but that what the mailing list is
> good for

Shall i mention that i am developer of libburn since 2006, which on Linux
operates optical drives from userspace via ioctl(SG_IO) ?


> maybe you are the
> next maintainer for CDROM drivers when you continue to test CDROM :)

Urm. This risk exists by having 7 more cdrom and sr problems fixed in
my local production kernel 4.19, plus 2 of fs/iso9660.
But my clumsiness with community and git will hopefully prevent that.

In general it is not easy to test CDROM beyond sr, because the non-sr
devices are very outdated and need bus hardware which i don't have
any more since years. But sr drives are capricious enough to be fun.

-------------------------------------------------------------------------

Garrit Franke wrote:
> In a recent Patch of mine, Greg nicely pointed out that commits should
> have a standard format across mailing lists: sha ("Commit Message").
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2235132.html

Applied to my commit message draft. Thanks for pointing out.


Greg KH wrote:
> That is also documented in the ever-growing submitting patches document

In next-20200827 it's line 930 of Doc*/process/submitting-patches.rst .

I now plan to write:

  Commit 210ba1d1724f ("[SCSI] sr: update to follow tray status correctly")
  of january 2008 switched sr_drive_status() away from indirectly using
  ...
  By commit 96bcc722c47d ("[SCSI] sr: report more accurate drive status
  after closing the tray.") of july 2008 it now returns CDS_DRIVE_NOT_READY
  ...


Have a nice day :)

Thomas


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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27 16:34   ` Thomas Schmitt
@ 2020-08-27 17:30     ` Lukas Bulwahn
  2020-08-28 13:03       ` Thomas Schmitt
  0 siblings, 1 reply; 11+ messages in thread
From: Lukas Bulwahn @ 2020-08-27 17:30 UTC (permalink / raw)
  To: Thomas Schmitt; +Cc: lukas.bulwahn, garritfranke, greg, kernelnewbies



On Thu, 27 Aug 2020, Thomas Schmitt wrote:

> Hi,
> 
> Lukas Bulwahn wrote:
> > Just take all maintainers as recipients.
> > axboe@kernel.dk linux-kernel@vger.kernel.org jejb@linux.ibm.com
> > martin.petersen@oracle.com linux-scsi@vger.kernel.org
> 
> Really that loudly ?
> Ain't linux-kernel@vger.kernel.org too general ?
> 
>

Don't worry about CCing linux-kernel, at this point, it is more for the 
purpose of a "pretty complete" email archive. Nobody follows it at full 
length, some just have some smart scripts to react to senders, keywords, 
files, etc.

> > It is probably best to base it on v5.9-rc2
> 
> Done. The patch was accepted by git apply. git diff looks good.
> (There were indeed changes in cdrom.c and cdrom.h. It's not that dead. :))
> 
> It compiles, but does not boot:
> 
>   [1.099627] nvme nvme0: failed to set APST feature (-10)
>   Gave up waiting for root filesystem device
> 
> I booted the 5.8 kernel and was happy to see my SSD well and alive.
> Then i reverted my changes, compiled and installed the original 5.9-rc2.
> Same boot failure (it would have been astonishing if not).
> 
> So i cannot test on 5.9-rc2.
> (Had to manually rename vmlinuz-5.9.0-rc2-ts and initrd.img-5.9.0-rc2-ts
>  before update-grub was willing to create a .cfg which does not boot it
>  by default. Eww ... whenever i leave the trodden path ...)
> 
> 
> > check if it cleanly applies on the latest linux-next
> 
> I read
>   https://www.kernel.org/doc/man-pages/linux-next.html
> and did without really knowing why:
> 
>   $ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>   $ git fetch linux-next
>   ...
>   * [new branch]                akpm          -> linux-next/akpm
>   * [new branch]                akpm-base     -> linux-next/akpm-base
>   * [new branch]                master        -> linux-next/master
>   * [new branch]                pending-fixes -> linux-next/pending-fixes
>   * [new branch]                stable        -> linux-next/stable
>   * [new tag]                   next-20200827 -> next-20200827
>   $ git checkout master
>   ...
>   $ git remote update
>   ...
>   Fetching linux-next
>   $ git checkout -B linux-next-20200827-ts-issue-2 next-20200827
>   Switched to a new branch 'linux-next-20200827-ts-issue-2'
>   $ git apply /home/thomas/v5.9-rc2_issue_2.git.diff
>   $
> 
> Compilation succeeds and it boots.
> 
>   dd if=/dev/sr0 bs=2048 count=1 of=/dev/null
>   dd if=/dev/sr1 bs=2048 count=1 of=/dev/null
> both succeed starting from open tray with a readable medium in it.
> 
> So shall i base my patch on next-20200827 ?
>

Yes, you can base it on next-20200827 (it probably applies on the current 
master as well).

You can use git format-patch --base, then maintainers know where it 
applied cleanly. And if it does not apply on their tree, when they 
include, they will let you know.
  
> -------------------------------------------------------------------------
> 
> > > Please also tell me if my mailer (used with this mail) would cause
> > > problems.
> 
> > I suggest [...] git send-email ... <patch>
> 
> I am not sure whether i can get git send-email to work due to local
> network issues. My free software mails go out by a primitive SMTP client
> which gets fed with plain text files, usually created by vim.
> 
> Thus i ask whether my mails show any properties which would hamper
> acceptance of a patch, which i would generate by git format-patch.
> 
> (I look at patches in https://marc.info/?l=linux-scsi and will try to
>  mimick them in my text file as good as possible.)
> 
>

Do not look at marc.info, it might have already messed up the email.

Archives at https://lore.kernel.org/ can give you the raw text and that 
archive is tested among kernel maintainers for picking patches.

You can prepare your patch and send it to kernelnewbies.

Then, pick it from https://lore.kernel.org/kernelnewbies/ and try to apply 
your own patch with git am. If that works, it is probably fine.


Lukas

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27  8:49 Please give advise about my first patch attempt Thomas Schmitt
  2020-08-27  9:26 ` Lukas Bulwahn
  2020-08-27  9:52 ` Garrit Franke
@ 2020-08-27 18:32 ` Pawan Gupta
  2 siblings, 0 replies; 11+ messages in thread
From: Pawan Gupta @ 2020-08-27 18:32 UTC (permalink / raw)
  To: Thomas Schmitt; +Cc: kernelnewbies

On Thu, Aug 27, 2020 at 10:49:51AM +0200, Thomas Schmitt wrote:
> Hi,
> 
> i am preparing my first patch.
> May i ask for review and advise how to make it acceptable ?

If you are not running it already you can catch common mistakes by
running checkpatch script from the kernel source top directory like:

  $ ./scripts/checkpatch.pl --strict --codespell -g <commit-id>

Also would suggest to build kernel with warnings treated as errors:

  $ make CFLAGS_KERNEL+=-Werror ...

Thanks,
Pawan

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-27 17:30     ` Lukas Bulwahn
@ 2020-08-28 13:03       ` Thomas Schmitt
  2020-09-03 15:59         ` Thomas Schmitt
  0 siblings, 1 reply; 11+ messages in thread
From: Thomas Schmitt @ 2020-08-28 13:03 UTC (permalink / raw)
  To: kernelnewbies; +Cc: lukas.bulwahn, garritfranke, greg

Hi,

i might get a community problem with the goal of my patch.

While googling for hints of acceptance for cdrom on
linux-scsi@vger.kernel.org i came to a thread where a much more
expensive fix of the problem was obviously rejected by Jens Axboe
in november 2019:

  https://lore.kernel.org/linux-scsi/c6fe572c-530e-93eb-d62a-cb2f89c7b4ec@kernel.dk/
  "I think the main complaint with this is that it's kind of a stretch to
   add core functionality for a device type that's barely being
   manufactured anymore and is mostly used in a virtualized fashion. I
   think it you could fix this without 10 patches of churn and without
   adding a new ->open() addition to fops, then people would be a lot more
   receptive to the idea of improving cdrom auto-close."

Well, 10 patches. Each about the code size of my single one.
But also a negative opinion towards the device class by the maintainer.

That proposal fixes tray loading for audio, too. I did not care because
i cannot test realistically.
Then there are patches 04/10 and 08/10 which shall avoid blocking other
processes from inquiring the drive while it is loading its tray because
of the automatic load feature in open_for_data().
Mine has a 40 seconds timeout instead, blocking CDROM ioctls and
sr_bdops.open() == sr_block_open() to that particular drive.


Would it be wise to mention from the beginning that i studied that
proposal ?

My opinion is now that if concurrent access from multiple threads to a
drive is more important than a working automatic tray load on open(2),
then automatic tray loading should be disabled at all.
If concurrent drive inspection by multiple threads at any time is not
a main goal, then i would still advertise my patch.

Should i mention this opinion from the beginning ?

I have a few other cdrom+sr fixes in my local 4.19 kernel.
I don't want to spoil their chances by starting with a non-starter.


Any strategic proposals to not appear clueless in front of Jens Axboe
would be welcome.
Due to real life issues i will probably until mid of next week not be able
to post a patch on linux-scsi and to then react swiftly on demanding
requests.

-----------------------------------------------------------------------

Lukas Bulwahn wrote:
> Archives at https://lore.kernel.org/ can give you the raw text and that
> archive is tested among kernel maintainers for picking patches.
> You can prepare your patch and send it to kernelnewbies.
> Then, pick it from https://lore.kernel.org/kernelnewbies/ and try to apply
> your own patch with git am. If that works, it is probably fine.

Pawan Gupta wrote:
>   $ ./scripts/checkpatch.pl --strict --codespell -g <commit-id>
>   $ make CFLAGS_KERNEL+=-Werror ...

I surely learn a lot here. Already lagging behind now ... :)


Have a nice day :)

Thomas


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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Please give advise about my first patch attempt
  2020-08-28 13:03       ` Thomas Schmitt
@ 2020-09-03 15:59         ` Thomas Schmitt
  0 siblings, 0 replies; 11+ messages in thread
From: Thomas Schmitt @ 2020-09-03 15:59 UTC (permalink / raw)
  To: kernelnewbies; +Cc: lukas.bulwahn, garritfranke, greg

Hi,

i'm back at work with my patch for automatic CD loading, but the target
moves faster than i can follow.

Meanwhile the sr part of my change plays on a fresh construction site
of linux-scsi:
  https://lore.kernel.org/linux-scsi/730eced4-c804-a78f-3d52-2a448dbd1b84@interlog.com/T/#t
  "rework check_disk_change()"
  2020-09-02 14:11 Christoph Hellwig

Currently our plans overlap by [PATCH 17/19] "sr: use
bdev_check_media_change" although they do not (yet) really conflict
  https://lore.kernel.org/linux-scsi/730eced4-c804-a78f-3d52-2a448dbd1b84@interlog.com/T/#m9d4c4b6145ed41d6467f2dc4728d6fd0345e94f1


It seems unwise to propose changes while Christoph Hellwig is actively
working on the same code.
(And i don't even know where to get the git branch with such a recent
 change when it is committed.)

What is the socially acceptable way to coordinate plans with him ?
- Shall i patiently wait until he is done with cdrom and sr ?
- Shall i announce my interest in fixing automatic tray loading and
  other things in a brief mail to the list ?
- Shall i post my patches (*) as they are and just wait for instructions ?

(*)
Studying Christoph's work in linux-scsi brought me to the prediction
that they will want separate patches for cdrom and sr.
Also i reworked my implementation along his design pattern of factoring
out and exporting functions and then calling them where beneficial.
(I.e. my -EDEADLK hack is dead. Long live cdrom_handle_open_tray().
 Larger cdrom patch, but also nicer looking code.)


Have a nice day :)

Thomas


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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-09-03 15:59 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-27  8:49 Please give advise about my first patch attempt Thomas Schmitt
2020-08-27  9:26 ` Lukas Bulwahn
2020-08-27 16:34   ` Thomas Schmitt
2020-08-27 17:30     ` Lukas Bulwahn
2020-08-28 13:03       ` Thomas Schmitt
2020-09-03 15:59         ` Thomas Schmitt
2020-08-27  9:52 ` Garrit Franke
2020-08-27 13:19   ` Greg KH
2020-08-27 14:02     ` Leam Hall
2020-08-27 16:01       ` Greg KH
2020-08-27 18:32 ` Pawan Gupta

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).