All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	open-osd <osd-dev@open-osd.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: linux-next: manual merge of the osd tree with the scsi tree
Date: Sun, 29 Nov 2009 15:07:14 +0200	[thread overview]
Message-ID: <4B127202.1010900@panasas.com> (raw)
In-Reply-To: <4B123A82.10104@panasas.com>

On 11/29/2009 11:10 AM, Boaz Harrosh wrote:
> On 11/27/2009 05:32 AM, Stephen Rothwell wrote:
>> Hi Boaz,
>>
>> Today's linux-next merge of the osd tree got a conflict in
>> drivers/scsi/osd/osd_uld.c between commit
>> f89b9ee4a722721ed205b8c29555ac75fbe8c2cc ("[SCSI] osduld: Use
>> device->release instead of internal kref") from the scsi tree and commit
>> 9b579fe8588b861dcf0c9b620757729643db4557 ("osduld: Use device->release
>> instead of internal kref") from the osd tree.
>>
>> These are slightly different versions of the same patch ...
>>
>> And commit 01e4c32c668251e74eb179ee1207c075466c4ef8 ("osduld: No need to
>> use dev_set_drvdata on embedded devices") from the osd also contributes
>> to the conflict.
>>
> 
> James has squashed these two patches together. Which do belong together
> I should say. In my tree they are separate. I will change my tree to
> match James's.
> 
> Thanks James, I prefer it much better this way.
> 

James hi.

In your merge of the patch:
    [SCSI] osduld: Use device->release instead of internal kref
at:
    [jejb: fold in use of container_of]

You have made a mistake, which renders the driver unusable.
At osd_remove() you changed the use of dev_get_drvdata to an, container_of()
but it is the *wrong* dev at this point this dev here is the grand-parent of
the embedded dev in question.

Also at the next patch:
    [SCSI] libosd: osd_dev_info: Unique Identification of an OSD device

a new use of dev_get_drvdata() is not converted to a container_of(), which by
now will return NULL.

Should I repost the correct two patches (my preference)? should I send in a fix to
current scsi-misc tree? or should I send two SQUASH-ME patches to the two bad commits
in your tree?

How do you want to proceed?

>> I fixed it up (the obvious way) and can carry the fix for a while.
> 

Stephan, I have not yet fixed up the conflict in -next, please carry that
fix you have for a little while, until we resolve it.

> Thanks
> Boaz

Boaz

  reply	other threads:[~2009-11-29 13:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-27  3:32 linux-next: manual merge of the osd tree with the scsi tree Stephen Rothwell
2009-11-29  9:10 ` Boaz Harrosh
2009-11-29 13:07   ` Boaz Harrosh [this message]
2009-11-29 13:46     ` James Bottomley
2009-11-29 14:23       ` Boaz Harrosh
2009-11-29 14:25         ` [PATCH 1/2] osduld: Use device->release instead of internal kref Boaz Harrosh
2009-11-29 14:26         ` [PATCH 2/2] libosd: osd_dev_info: Unique Identification of an OSD device Boaz Harrosh
2009-11-29 15:23         ` linux-next: manual merge of the osd tree with the scsi tree James Bottomley
2009-11-29 21:44           ` Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B127202.1010900@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=osd-dev@open-osd.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.