Bug#582281: Promised utility now available
On Fri, 21 May 2010 16:48:38 -0400 (EDT), Jonathan Nieder wrote:
>
> I am not the kernel team, but for issues in upstream code, it is
> _always_ a good idea to go to upstream directly[1].
To the Debian Kernel Team:
Upon the advice of Jonathan Nieder, I will pursue this directly with
upstream, but I will keep you informed of what's going on by updates
to this bug log. If you have a problem with that, please say so.
On Fri, 21 May 2010 16:48:38 -0400 (EDT), Jonathan Nieder wrote:
>
> $ grep '^[0-9]*)' Documentation/SubmittingPatches
> 1) "diff -up"
> 2) Describe your changes.
> 3) Separate your changes.
> 4) Style check your changes.
> 5) Select e-mail destination.
> 6) Select your CC (e-mail carbon copy) list.
> 7) No MIME, no links, no compression, no attachments. Just plain text.
> 8) E-mail size.
> 9) Name your kernel version.
> 10) Don't get discouraged. Re-submit.
> 11) Include PATCH in the subject
> 12) Sign your work
> 13) When to use Acked-by: and Cc:
> 14) Using Reported-by:, Tested-by: and Reviewed-by:
> 15) The canonical patch format
> 16) Sending "git pull" requests (from Linus emails)
> 1) Read Documentation/CodingStyle
> 2) #ifdefs are ugly
> 3) 'static inline' is better than a macro
> 4) Don't over-design.
> $ scripts/get_maintainer.pl -f fs/partitions/ibm.c
> "Martin K. Petersen" <martin.petersen@oracle.com>
> Jens Axboe <jens.axboe@oracle.com>
> linux-kernel@vger.kernel.org
>
> Summary: the best thing is to send your patch as a _unified_ diff
> (i.e. generated with diff -u), and include it inline in a message
> to the addresses listed above, with the following format:
>
> some timeless words about the patch
>
> Signed-off-by line (see Documentation/SubmittingPatches for what
> this means and why)
> ---
> some timely words about the patch
>
> the patch (diff -up output)
>
> It seems I have only been able to make more work for you lately.
> Sorry. I would also be willing to pass on the patch myself, but at
> minimum this requires your signed-off-by line, and it might be good to
> get to know the process anyway.
>
> You can see lots of examples at http://news.gmane.org/gmane.linux.kernel
>
> Hope that helps,
> Jonathan
>
> [1] The corresponding Debian bug report is still useful, as a way to
> track the status of the bug in Debian (e.g., what versions have the
> patch applied).
To Jonathan:
I'm willing to do this. But there are a couple of
practical considerations why I don't think I'll go that route.
First of all, I have never been able to successfully send or receive
in-line patches using my e-mail client. (You may recall my inability
to successfully receive some patches for parted that you sent me
earlier.) Somehow or other, my e-mail client hoses them up. I don't
know if its the handling of tabs or wrapping long lines, or just what
the problem is.
Second, although my patch works, there is a potential data access
issue involved here. My little stand-alone utility program will fix
that problem, but it relies on knowledgeable human intervention
in advance to prevent data from becoming unreadable. IBM may prefer
a more sophisticated solution. For example, they may prefer a
solution that checks for a valid file system or swap space on the block
that a non-reserved minidisk would use, and, if that is the case, and if
a valid filesystem or swap space is not found on the block that a
reserved minidisk would use, it may automatically set the disk offset
field in the CMS disk label to zero and update the label. That would
involve more work, and is probably beyond my capabilities at this point,
but IBM may choose that as a solution.
>From my research, this bug was probably introduced between kernel
2.6.30.10 and and 2.6.31. That's when they changed the definition
of "blocksize" from dbev_hardsect_size(bdev) to
bdev_logical_block_size(bdev). That apparently fixed one problem
and caused another (this one).
I previously found a bug in the DIAG driver (could not bring read-only
minidisks online) and wrote a zap to fix the problem. But IBM's
solution was more elegant and added several more kernel messages.
Their fix was better than mine. And their fix to this problem may
be better than mine too. So I'm going to send an e-mail to
Linux390@de.ibm.com to report the bug and see what happens.
In the meantime, my patch is available for users who want to build
a custom kernel with my patch applied to fix the problem.
Wish me luck!
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: