linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the driver-core tree with the driver-core.current tree
@ 2013-12-09  3:47 Stephen Rothwell
  2013-12-09  8:21 ` Greg KH
  0 siblings, 1 reply; 23+ messages in thread
From: Stephen Rothwell @ 2013-12-09  3:47 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Tejun Heo

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
fs/sysfs/file.c between commit a8b14744429f ("sysfs: give different
locking key to regular and bin files") from the driver-core.current tree
and commit 414985ae23c0 ("sysfs, kernfs: move file core code to
fs/kernfs/file.c") (among others) from the driver-core tree.

I just dropped the driver-core.current tree commit as I don't see what
needs to be done after the other changes in the driver-core tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-12-09  3:47 linux-next: manual merge of the driver-core tree with the driver-core.current tree Stephen Rothwell
@ 2013-12-09  8:21 ` Greg KH
  2013-12-10 14:50   ` [PATCH driver-core-next] sysfs: bail early from kernfs_file_mmap() to avoid spurious lockdep warning Tejun Heo
  0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2013-12-09  8:21 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Tejun Heo

On Mon, Dec 09, 2013 at 02:47:12PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> fs/sysfs/file.c between commit a8b14744429f ("sysfs: give different
> locking key to regular and bin files") from the driver-core.current tree
> and commit 414985ae23c0 ("sysfs, kernfs: move file core code to
> fs/kernfs/file.c") (among others) from the driver-core tree.
> 
> I just dropped the driver-core.current tree commit as I don't see what
> needs to be done after the other changes in the driver-core tree.

Tejun said he would provide a merge fixup as we knew this was going to
be a problem :)

thanks,

greg k-h

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

* [PATCH driver-core-next] sysfs: bail early from kernfs_file_mmap() to avoid spurious lockdep warning
  2013-12-09  8:21 ` Greg KH
@ 2013-12-10 14:50   ` Tejun Heo
  2013-12-11  0:03     ` Stephen Rothwell
  2013-12-11  5:39     ` Greg KH
  0 siblings, 2 replies; 23+ messages in thread
From: Tejun Heo @ 2013-12-10 14:50 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Dave Jones

Hello,

Yeap, I was planning to send this out earlier but was completely
passed out yesterday after the first snowboarding in over a decade. :)

The offending commit a8b14744429f isn't applicable to
driver-core-next.  This was done this way because no matter what we
do, conflict is inevitable and keeping things minimal is the least
painful.  The following git branch pulls driver-core-linus into
driver-core-next, resolves the conflict by ignoring the offending
commit and applies this patch on top of it to implement the equivalent
fix.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git driver-core-fix-lockdep-class

For some reason, I can't reproduce the spurious lockdep warning Dave
is seeing so I'm not 100% sure but this is the same behavior as the
other patch that Dave tested in the original thread, so I'm relatively
sure this is the right fix.  This patch also adds comment to the
confusing if/else in the open path.

Greg, given that there will be more patches in driver-core-next, I
think it'll be best to pull driver-core-linus into driver-core-next to
avoid conflicts from the same commit.  You can pull my commit or if
you pull it yourself, just take all the chunks from driver-core-next
so that the resulting fs/sysfs/file.c is unchanged compared to
driver-core-next before pull, and then apply this patch.

Thanks.

------ 8< ------
>From 5cb9f29a28c87cbf62f74ff6bde3d9da2a565b1d Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj@kernel.org>
Date: Tue, 10 Dec 2013 09:29:17 -0500

This is v3.14 fix for the same issue that a8b14744429f ("sysfs: give
different locking key to regular and bin files") addresses for v3.13.
Due to the extensive kernfs reorganization in v3.14 branch, the same
fix couldn't be ported as-is.  The v3.13 fix was ignored while merging
it into v3.14 branch.

027a485d12e0 ("sysfs: use a separate locking class for open files
depending on mmap") assigned different lockdep key to
sysfs_open_file->mutex depending on whether the file implements mmap
or not in an attempt to avoid spurious lockdep warning caused by
merging of regular and bin file paths.

While this restored some of the original behavior of using different
locks (at least lockdep is concerned) for the different clases of
files.  The restoration wasn't full because now the lockdep key
assignment depends on whether the file has mmap or not instead of
whether it's a regular file or not.

This means that bin files which don't implement mmap will get assigned
the same lockdep class as regular files.  This is problematic because
file_operations for bin files still implements the mmap file operation
and checking whether the sysfs file actually implements mmap happens
in the file operation after grabbing @sysfs_open_file->mutex.  We
still end up adding locking dependency from mmap locking to
sysfs_open_file->mutex to the regular file mutex which triggers
spurious circular locking warning.

For v3.13, a8b14744429f ("sysfs: give different locking key to regular
and bin files") fixed it by giving sysfs_open_file->mutex different
lockdep keys depending on whether the file is regular or bin instead
of whether mmap exists or not; however, due to the way sysfs is now
layered behind kernfs, this approach is no longer viable.  kernfs can
tell whether a sysfs node has mmap implemented or not but can't tell
whether a bin file from a regular one.

This patch updates kernfs such that kernfs_file_mmap() checks
SYSFS_FLAG_HAS_MMAP and bail before grabbing sysfs_open_file->mutex so
that it doesn't add spurious locking dependency from mmap to
sysfs_open_file->mutex and changes sysfs so that it specifies
kernfs_ops->mmap iff the sysfs file implements mmap.  Combined, this
ensures that sysfs_open_file->mutex is grabbed under mmap path iff the
sysfs file actually implements mmap.  As sysfs_open_file->mutex is
already given a different lockdep key if mmap is implemented, this
removes the spurious locking dependency.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Dave Jones <davej@redhat.com>
Link: http://lkml.kernel.org/g/20131203184324.GA11320@redhat.com
---
 fs/kernfs/file.c | 18 ++++++++++++++----
 fs/sysfs/file.c  | 12 ++++++++----
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 4a5863b..fa05315 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -421,6 +421,16 @@ static int kernfs_file_mmap(struct file *file, struct vm_area_struct *vma)
 	const struct kernfs_ops *ops;
 	int rc;
 
+	/*
+	 * mmap path and of->mutex are prone to triggering spurious lockdep
+	 * warnings and we don't want to add spurious locking dependency
+	 * between the two.  Check whether mmap is actually implemented
+	 * without grabbing @of->mutex by testing HAS_MMAP flag.  See the
+	 * comment in kernfs_file_open() for more details.
+	 */
+	if (!(of->sd->s_flags & SYSFS_FLAG_HAS_MMAP))
+		return -ENODEV;
+
 	mutex_lock(&of->mutex);
 
 	rc = -ENODEV;
@@ -428,10 +438,7 @@ static int kernfs_file_mmap(struct file *file, struct vm_area_struct *vma)
 		goto out_unlock;
 
 	ops = kernfs_ops(of->sd);
-	if (ops->mmap)
-		rc = ops->mmap(of, vma);
-	if (rc)
-		goto out_put;
+	rc = ops->mmap(of, vma);
 
 	/*
 	 * PowerPC's pci_mmap of legacy_mem uses shmem_zero_setup()
@@ -596,6 +603,9 @@ static int kernfs_file_open(struct inode *inode, struct file *file)
 	 * happen on the same file.  At this point, we can't easily give
 	 * each file a separate locking class.  Let's differentiate on
 	 * whether the file has mmap or not for now.
+	 *
+	 * Both paths of the branch look the same.  They're supposed to
+	 * look that way and give @of->mutex different static lockdep keys.
 	 */
 	if (has_mmap)
 		mutex_init(&of->mutex);
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index ac77d2b..a67d1c6 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -142,9 +142,6 @@ static int sysfs_kf_bin_mmap(struct sysfs_open_file *of,
 	struct bin_attribute *battr = of->sd->priv;
 	struct kobject *kobj = of->sd->s_parent->priv;
 
-	if (!battr->mmap)
-		return -ENODEV;
-
 	return battr->mmap(of->file, kobj, battr, vma);
 }
 
@@ -197,6 +194,11 @@ static const struct kernfs_ops sysfs_bin_kfops_wo = {
 static const struct kernfs_ops sysfs_bin_kfops_rw = {
 	.read		= sysfs_kf_bin_read,
 	.write		= sysfs_kf_bin_write,
+};
+
+static const struct kernfs_ops sysfs_bin_kfops_mmap = {
+	.read		= sysfs_kf_bin_read,
+	.write		= sysfs_kf_bin_write,
 	.mmap		= sysfs_kf_bin_mmap,
 };
 
@@ -232,7 +234,9 @@ int sysfs_add_file_mode_ns(struct sysfs_dirent *dir_sd,
 	} else {
 		struct bin_attribute *battr = (void *)attr;
 
-		if ((battr->read && battr->write) || battr->mmap)
+		if (battr->mmap)
+			ops = &sysfs_bin_kfops_mmap;
+		else if (battr->read && battr->write)
 			ops = &sysfs_bin_kfops_rw;
 		else if (battr->read)
 			ops = &sysfs_bin_kfops_ro;
-- 
1.8.4.2

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

* Re: [PATCH driver-core-next] sysfs: bail early from kernfs_file_mmap() to avoid spurious lockdep warning
  2013-12-10 14:50   ` [PATCH driver-core-next] sysfs: bail early from kernfs_file_mmap() to avoid spurious lockdep warning Tejun Heo
@ 2013-12-11  0:03     ` Stephen Rothwell
  2013-12-11  5:39     ` Greg KH
  1 sibling, 0 replies; 23+ messages in thread
From: Stephen Rothwell @ 2013-12-11  0:03 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Greg KH, linux-next, linux-kernel, Dave Jones

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

Hi Tejun,

On Tue, 10 Dec 2013 09:50:04 -0500 Tejun Heo <tj@kernel.org> wrote:
>
> Greg, given that there will be more patches in driver-core-next, I
> think it'll be best to pull driver-core-linus into driver-core-next to
> avoid conflicts from the same commit.  You can pull my commit or if
> you pull it yourself, just take all the chunks from driver-core-next
> so that the resulting fs/sysfs/file.c is unchanged compared to
> driver-core-next before pull, and then apply this patch.
> 
> ------ 8< ------
> From 5cb9f29a28c87cbf62f74ff6bde3d9da2a565b1d Mon Sep 17 00:00:00 2001
> From: Tejun Heo <tj@kernel.org>
> Date: Tue, 10 Dec 2013 09:29:17 -0500
> 
> This is v3.14 fix for the same issue that a8b14744429f ("sysfs: give

I have added the patch as a merge fix patch for the merge of the
driver-core tree today.  I will throw it away if/when Greg applies it.

-- 
Cheers,
Stephen Rothwell <sfr@canb.auug.org.au>

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: [PATCH driver-core-next] sysfs: bail early from kernfs_file_mmap() to avoid spurious lockdep warning
  2013-12-10 14:50   ` [PATCH driver-core-next] sysfs: bail early from kernfs_file_mmap() to avoid spurious lockdep warning Tejun Heo
  2013-12-11  0:03     ` Stephen Rothwell
@ 2013-12-11  5:39     ` Greg KH
  1 sibling, 0 replies; 23+ messages in thread
From: Greg KH @ 2013-12-11  5:39 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Stephen Rothwell, linux-next, linux-kernel, Dave Jones

On Tue, Dec 10, 2013 at 09:50:04AM -0500, Tejun Heo wrote:
> Hello,
> 
> Yeap, I was planning to send this out earlier but was completely
> passed out yesterday after the first snowboarding in over a decade. :)
> 
> The offending commit a8b14744429f isn't applicable to
> driver-core-next.  This was done this way because no matter what we
> do, conflict is inevitable and keeping things minimal is the least
> painful.  The following git branch pulls driver-core-linus into
> driver-core-next, resolves the conflict by ignoring the offending
> commit and applies this patch on top of it to implement the equivalent
> fix.
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git driver-core-fix-lockdep-class

I've pulled from this and pushed it out as my driver-next branch, thanks
for doing this (note, I --ammend the patch and added my signed-off-by,
so you can't just pull and not get a conflict.)

thanks,

greg k-h

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2020-04-30  4:25 linux-next: manual merge of the driver-core tree with the driver-core.current tree Stephen Rothwell
@ 2020-04-30  8:15 ` Greg KH
  0 siblings, 0 replies; 23+ messages in thread
From: Greg KH @ 2020-04-30  8:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christophe JAILLET, John Stultz

On Thu, Apr 30, 2020 at 02:25:06PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the driver-core tree got a conflict in:
> 
>   drivers/base/dd.c
> 
> between commits:
> 
>   ce68929f07de ("driver core: Revert default driver_deferred_probe_timeout value to 0")
>   4ccc03e28ec3 ("driver core: Use dev_warn() instead of dev_WARN() for deferred_probe_timeout warnings")
>   35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires")
> 
> from the driver-core.current tree and commit:
> 
>   eb7fbc9fb118 ("driver core: Add missing '\n' in log messages")
> 
> from the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/base/dd.c
> index 94037be7f5d7,efe6df5bff26..000000000000
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@@ -258,8 -266,8 +258,8 @@@ int driver_deferred_probe_check_state(s
>   		return -ENODEV;
>   	}
>   
>  -	if (!driver_deferred_probe_timeout) {
>  -		dev_WARN(dev, "deferred probe timeout, ignoring dependency\n");
>  +	if (!driver_deferred_probe_timeout && initcalls_done) {
> - 		dev_warn(dev, "deferred probe timeout, ignoring dependency");
> ++		dev_warn(dev, "deferred probe timeout, ignoring dependency\n");
>   		return -ETIMEDOUT;
>   	}
>   
> @@@ -275,8 -283,7 +275,8 @@@ static void deferred_probe_timeout_work
>   	flush_work(&deferred_probe_work);
>   
>   	list_for_each_entry_safe(private, p, &deferred_probe_pending_list, deferred_probe)
> - 		dev_info(private->device, "deferred probe pending");
> + 		dev_info(private->device, "deferred probe pending\n");
>  +	wake_up(&probe_timeout_waitqueue);
>   }
>   static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
>   

Looks good, I'll handle this when the .linus branch gets merged into
Linus's tree.

thanks,

greg k-h

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

* linux-next: manual merge of the driver-core tree with the driver-core.current tree
@ 2020-04-30  4:25 Stephen Rothwell
  2020-04-30  8:15 ` Greg KH
  0 siblings, 1 reply; 23+ messages in thread
From: Stephen Rothwell @ 2020-04-30  4:25 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christophe JAILLET, John Stultz

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

Hi all,

Today's linux-next merge of the driver-core tree got a conflict in:

  drivers/base/dd.c

between commits:

  ce68929f07de ("driver core: Revert default driver_deferred_probe_timeout value to 0")
  4ccc03e28ec3 ("driver core: Use dev_warn() instead of dev_WARN() for deferred_probe_timeout warnings")
  35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires")

from the driver-core.current tree and commit:

  eb7fbc9fb118 ("driver core: Add missing '\n' in log messages")

from the driver-core tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/base/dd.c
index 94037be7f5d7,efe6df5bff26..000000000000
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@@ -258,8 -266,8 +258,8 @@@ int driver_deferred_probe_check_state(s
  		return -ENODEV;
  	}
  
 -	if (!driver_deferred_probe_timeout) {
 -		dev_WARN(dev, "deferred probe timeout, ignoring dependency\n");
 +	if (!driver_deferred_probe_timeout && initcalls_done) {
- 		dev_warn(dev, "deferred probe timeout, ignoring dependency");
++		dev_warn(dev, "deferred probe timeout, ignoring dependency\n");
  		return -ETIMEDOUT;
  	}
  
@@@ -275,8 -283,7 +275,8 @@@ static void deferred_probe_timeout_work
  	flush_work(&deferred_probe_work);
  
  	list_for_each_entry_safe(private, p, &deferred_probe_pending_list, deferred_probe)
- 		dev_info(private->device, "deferred probe pending");
+ 		dev_info(private->device, "deferred probe pending\n");
 +	wake_up(&probe_timeout_waitqueue);
  }
  static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-20  3:28               ` Greg KH
  2013-06-20  3:46                 ` Ming Lei
@ 2013-06-20  3:49                 ` Stephen Rothwell
  1 sibling, 0 replies; 23+ messages in thread
From: Stephen Rothwell @ 2013-06-20  3:49 UTC (permalink / raw)
  To: Greg KH; +Cc: Ming Lei, linux-next, linux-kernel, Takashi Iwai

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

Hi Greg,

On Wed, 19 Jun 2013 20:28:12 -0700 Greg KH <greg@kroah.com> wrote:
>
> Thanks, that helped out a lot.  I've now merged this together, and
> pushed it out to my driver-core-next branch, can you verify that I got
> it all correct?

And I have refetched the driver-core tree for today's linux-next so it
includes that merge.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-20  3:28               ` Greg KH
@ 2013-06-20  3:46                 ` Ming Lei
  2013-06-20  3:49                 ` Stephen Rothwell
  1 sibling, 0 replies; 23+ messages in thread
From: Ming Lei @ 2013-06-20  3:46 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Takashi Iwai

On Thu, Jun 20, 2013 at 11:28 AM, Greg KH <greg@kroah.com> wrote:
> On Thu, Jun 20, 2013 at 09:22:13AM +0800, Ming Lei wrote:
>> Hi Stephen,
>>
>> Thanks for your help.
>>
>> On Thu, Jun 20, 2013 at 9:06 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> >
>> > Try "git diff-tree --cc e4b00d75ee3ed3af9fac83970d21e27d1ad4aa8d"
>>
>> Greg, Stephen, so is sort of below generated patch what you expected?
>>
>> If yes, I will send it out to you.
>
> Thanks, that helped out a lot.  I've now merged this together, and
> pushed it out to my driver-core-next branch, can you verify that I got
> it all correct?

I just pull your driver-core-next branch, looks drivers/base/firmware_class.c
is fine now, thank you

Thanks,
--
Ming Lei

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-20  1:22             ` Ming Lei
@ 2013-06-20  3:28               ` Greg KH
  2013-06-20  3:46                 ` Ming Lei
  2013-06-20  3:49                 ` Stephen Rothwell
  0 siblings, 2 replies; 23+ messages in thread
From: Greg KH @ 2013-06-20  3:28 UTC (permalink / raw)
  To: Ming Lei; +Cc: Stephen Rothwell, linux-next, linux-kernel, Takashi Iwai

On Thu, Jun 20, 2013 at 09:22:13AM +0800, Ming Lei wrote:
> Hi Stephen,
> 
> Thanks for your help.
> 
> On Thu, Jun 20, 2013 at 9:06 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> >
> > Try "git diff-tree --cc e4b00d75ee3ed3af9fac83970d21e27d1ad4aa8d"
> 
> Greg, Stephen, so is sort of below generated patch what you expected?
> 
> If yes, I will send it out to you.

Thanks, that helped out a lot.  I've now merged this together, and
pushed it out to my driver-core-next branch, can you verify that I got
it all correct?

thanks,

greg k-h

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-20  1:06           ` Stephen Rothwell
@ 2013-06-20  1:22             ` Ming Lei
  2013-06-20  3:28               ` Greg KH
  0 siblings, 1 reply; 23+ messages in thread
From: Ming Lei @ 2013-06-20  1:22 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Takashi Iwai

Hi Stephen,

Thanks for your help.

On Thu, Jun 20, 2013 at 9:06 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

>
> Try "git diff-tree --cc e4b00d75ee3ed3af9fac83970d21e27d1ad4aa8d"

Greg, Stephen, so is sort of below generated patch what you expected?

If yes, I will send it out to you.

e4b00d75ee3ed3af9fac83970d21e27d1ad4aa8d
diff --cc drivers/base/firmware_class.c
index 6ede229,01e2103..7fefcb5
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@@ -452,35 -446,27 +452,52 @@@ static struct firmware_priv *to_firmwar
  	return container_of(dev, struct firmware_priv, dev);
  }

- static void fw_load_abort(struct firmware_buf *buf)
 -static void fw_load_abort(struct firmware_priv *fw_priv)
++static void __fw_load_abort(struct firmware_buf *buf)
  {
 -	struct firmware_buf *buf = fw_priv->buf;
 -
+ 	/*
+ 	 * There is a small window in which user can write to 'loading'
+ 	 * between loading done and disappearance of 'loading'
+ 	 */
+ 	if (test_bit(FW_STATUS_DONE, &buf->status))
+ 		return;
+
 +	list_del_init(&buf->pending_list);
  	set_bit(FW_STATUS_ABORT, &buf->status);
  	complete_all(&buf->completion);
 +}
 +
++static void fw_load_abort(struct firmware_priv *fw_priv)
++{
++	struct firmware_buf *buf = fw_priv->buf;
++
++	__fw_load_abort(buf);
+
+ 	/* avoid user action after loading abort */
+ 	fw_priv->buf = NULL;
+ }
+
  #define is_fw_load_aborted(buf)	\
  	test_bit(FW_STATUS_ABORT, &(buf)->status)

 +static LIST_HEAD(pending_fw_head);
 +
 +/* reboot notifier for avoid deadlock with usermode_lock */
 +static int fw_shutdown_notify(struct notifier_block *unused1,
 +			      unsigned long unused2, void *unused3)
 +{
 +	mutex_lock(&fw_lock);
 +	while (!list_empty(&pending_fw_head))
- 		fw_load_abort(list_first_entry(&pending_fw_head,
++		__fw_load_abort(list_first_entry(&pending_fw_head,
 +					       struct firmware_buf,
 +					       pending_list));
 +	mutex_unlock(&fw_lock);
 +	return NOTIFY_DONE;
 +}
 +
 +static struct notifier_block fw_shutdown_nb = {
 +	.notifier_call = fw_shutdown_notify,
 +};
 +
  static ssize_t firmware_timeout_show(struct class *class,
  				     struct class_attribute *attr,
  				     char *buf)
@@@ -911,23 -895,6 +927,23 @@@ static int fw_load_from_user_helper(str
  	fw_priv->buf = firmware->priv;
  	return _request_firmware_load(fw_priv, uevent, timeout);
  }
 +
 +#ifdef CONFIG_PM_SLEEP
 +/* kill pending requests without uevent to avoid blocking suspend */
 +static void kill_requests_without_uevent(void)
 +{
 +	struct firmware_buf *buf;
 +	struct firmware_buf *next;
 +
 +	mutex_lock(&fw_lock);
 +	list_for_each_entry_safe(buf, next, &pending_fw_head, pending_list) {
 +		if (!buf->need_uevent)
- 			 fw_load_abort(buf);
++			 __fw_load_abort(buf);
 +	}
 +	mutex_unlock(&fw_lock);
 +}
 +#endif
 +
  #else /* CONFIG_FW_LOADER_USER_HELPER */
  static inline int
  fw_load_from_user_helper(struct firmware *firmware, const char *name,


Thanks,
--
Ming Lei

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-20  0:23         ` Ming Lei
@ 2013-06-20  1:06           ` Stephen Rothwell
  2013-06-20  1:22             ` Ming Lei
  0 siblings, 1 reply; 23+ messages in thread
From: Stephen Rothwell @ 2013-06-20  1:06 UTC (permalink / raw)
  To: Ming Lei; +Cc: Greg KH, linux-next, linux-kernel, Takashi Iwai

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Hi Ming,

On Thu, 20 Jun 2013 08:23:30 +0800 Ming Lei <ming.lei@canonical.com> wrote:
>
> Yes, I already merged the two branches together in my local repository,
> and there is one merge commit, but I don't know how to generate/format
> patch for this merge commit only:
> 
> commit e4b00d75ee3ed3af9fac83970d21e27d1ad4aa8d
> Merge: bb07b00 8759793
> Author: Ming Lei <tom.leiming@gmail.com>
> Date:   Wed Jun 19 23:56:05 2013 +0800
> 
>     firmware loader: fix conflict driver-core-linus and driver-core-next
> 
>     Conflicts:
>         drivers/base/firmware_class.c
> 
> Anyone who knows, please let me know, thanks.

Try "git diff-tree --cc e4b00d75ee3ed3af9fac83970d21e27d1ad4aa8d"

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-19 16:36       ` Greg KH
@ 2013-06-20  0:23         ` Ming Lei
  2013-06-20  1:06           ` Stephen Rothwell
  0 siblings, 1 reply; 23+ messages in thread
From: Ming Lei @ 2013-06-20  0:23 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Takashi Iwai

On Thu, Jun 20, 2013 at 12:36 AM, Greg KH <greg@kroah.com> wrote:
>
> Can you merge the two branches together (driver-core-next and
> driver-core-linus) and send me the proper merge patch that I should be
> applying when doing that?  Then I can push that out through the

Yes, I already merged the two branches together in my local repository,
and there is one merge commit, but I don't know how to generate/format
patch for this merge commit only:

commit e4b00d75ee3ed3af9fac83970d21e27d1ad4aa8d
Merge: bb07b00 8759793
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Wed Jun 19 23:56:05 2013 +0800

    firmware loader: fix conflict driver-core-linus and driver-core-next

    Conflicts:
        drivers/base/firmware_class.c

Anyone who knows, please let me know, thanks.

Thanks,
--
Ming Lei

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-19 15:04     ` Ming Lei
@ 2013-06-19 16:36       ` Greg KH
  2013-06-20  0:23         ` Ming Lei
  0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2013-06-19 16:36 UTC (permalink / raw)
  To: Ming Lei; +Cc: Stephen Rothwell, linux-next, linux-kernel, Takashi Iwai

On Wed, Jun 19, 2013 at 11:04:04PM +0800, Ming Lei wrote:
> On Wed, Jun 19, 2013 at 10:39 PM, Greg KH <greg@kroah.com> wrote:
> > On Wed, Jun 19, 2013 at 02:58:39PM +0800, Ming Lei wrote:
> >> On Wed, Jun 19, 2013 at 1:32 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> > Hi Greg,
> >> >
> >> > Today's linux-next merge of the driver-core tree got a conflict in
> >> > drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
> >> > loader: fix use-after-free by double abort") from the driver-core.current
> >> > tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
> >> > lock at shutdown") from the driver-core tree.
> >> >
> >> > I fixed it up (more may be required - see below) and can carry the fix as
> >> > necessary (no action is required).
> >> >
> >> > --
> >> > Cheers,
> >> > Stephen Rothwell                    sfr@canb.auug.org.au
> >> >
> >> > diff --cc drivers/base/firmware_class.c
> >> > index 01e2103,6ede229..0000000
> >> > --- a/drivers/base/firmware_class.c
> >> > +++ b/drivers/base/firmware_class.c
> >> > @@@ -446,22 -452,11 +452,18 @@@ static struct firmware_priv *to_firmwar
> >> >         return container_of(dev, struct firmware_priv, dev);
> >> >   }
> >> >
> >> > - static void fw_load_abort(struct firmware_priv *fw_priv)
> >> > + static void fw_load_abort(struct firmware_buf *buf)
> >> >   {
> >> > -       struct firmware_buf *buf = fw_priv->buf;
> >> > -
> >> >  +      /*
> >> >  +       * There is a small window in which user can write to 'loading'
> >> >  +       * between loading done and disappearance of 'loading'
> >> >  +       */
> >> >  +      if (test_bit(FW_STATUS_DONE, &buf->status))
> >> >  +              return;
> >> >  +
> >> > +       list_del_init(&buf->pending_list);
> >> >         set_bit(FW_STATUS_ABORT, &buf->status);
> >> >         complete_all(&buf->completion);
> >> > -
> >> > -       /* avoid user action after loading abort */
> >> > -       fw_priv->buf = NULL;
> >>
> >> Hmm, maybe the most important part in the commit 875979368eb4
> >> ("firmware loader: fix use-after-free by double abort") has been removed, :-)
> >>
> >> In fact, the commit 87597936 is for linus tree only because it is a fix,
> >> so the conflict is caused by merging it with other firmware loader patches
> >> in -next tree.
> >>
> >> Greg, I can figure out one patch for -next easily, but it depends you
> >> push it on 3.10-rc or 3.11-rc.
> >
> > I'll be pushing your patch for 3.10-final to Linus as it fixes a bug,
> > but I will need something to resolve the merge issue properly.  Can you
> > provide me that patch/merge?
> 
> OK, I can send you one patch, but I am wondering the patch is against
> today's next tree or your driver-core/driver-core-next?
> 
> If it is against your driver-core/driver-core-next, would you mind letting
> me know how to generate the patch for the conflict?  Sorry for the stupid
> question, because I seldom meet such problem, :-(

Can you merge the two branches together (driver-core-next and
driver-core-linus) and send me the proper merge patch that I should be
applying when doing that?  Then I can push that out through the
driver-core-next tree to make linux-next work properly, as well as make
the merge sane for me when I pull in the final 3.10 release.

thanks,

greg k-h

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-19 14:39   ` Greg KH
@ 2013-06-19 15:04     ` Ming Lei
  2013-06-19 16:36       ` Greg KH
  0 siblings, 1 reply; 23+ messages in thread
From: Ming Lei @ 2013-06-19 15:04 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Takashi Iwai

On Wed, Jun 19, 2013 at 10:39 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Jun 19, 2013 at 02:58:39PM +0800, Ming Lei wrote:
>> On Wed, Jun 19, 2013 at 1:32 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > Hi Greg,
>> >
>> > Today's linux-next merge of the driver-core tree got a conflict in
>> > drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
>> > loader: fix use-after-free by double abort") from the driver-core.current
>> > tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
>> > lock at shutdown") from the driver-core tree.
>> >
>> > I fixed it up (more may be required - see below) and can carry the fix as
>> > necessary (no action is required).
>> >
>> > --
>> > Cheers,
>> > Stephen Rothwell                    sfr@canb.auug.org.au
>> >
>> > diff --cc drivers/base/firmware_class.c
>> > index 01e2103,6ede229..0000000
>> > --- a/drivers/base/firmware_class.c
>> > +++ b/drivers/base/firmware_class.c
>> > @@@ -446,22 -452,11 +452,18 @@@ static struct firmware_priv *to_firmwar
>> >         return container_of(dev, struct firmware_priv, dev);
>> >   }
>> >
>> > - static void fw_load_abort(struct firmware_priv *fw_priv)
>> > + static void fw_load_abort(struct firmware_buf *buf)
>> >   {
>> > -       struct firmware_buf *buf = fw_priv->buf;
>> > -
>> >  +      /*
>> >  +       * There is a small window in which user can write to 'loading'
>> >  +       * between loading done and disappearance of 'loading'
>> >  +       */
>> >  +      if (test_bit(FW_STATUS_DONE, &buf->status))
>> >  +              return;
>> >  +
>> > +       list_del_init(&buf->pending_list);
>> >         set_bit(FW_STATUS_ABORT, &buf->status);
>> >         complete_all(&buf->completion);
>> > -
>> > -       /* avoid user action after loading abort */
>> > -       fw_priv->buf = NULL;
>>
>> Hmm, maybe the most important part in the commit 875979368eb4
>> ("firmware loader: fix use-after-free by double abort") has been removed, :-)
>>
>> In fact, the commit 87597936 is for linus tree only because it is a fix,
>> so the conflict is caused by merging it with other firmware loader patches
>> in -next tree.
>>
>> Greg, I can figure out one patch for -next easily, but it depends you
>> push it on 3.10-rc or 3.11-rc.
>
> I'll be pushing your patch for 3.10-final to Linus as it fixes a bug,
> but I will need something to resolve the merge issue properly.  Can you
> provide me that patch/merge?

OK, I can send you one patch, but I am wondering the patch is against
today's next tree or your driver-core/driver-core-next?

If it is against your driver-core/driver-core-next, would you mind letting
me know how to generate the patch for the conflict?  Sorry for the stupid
question, because I seldom meet such problem, :-(


Thanks,
--
Ming Lei

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-19  6:58 ` Ming Lei
@ 2013-06-19 14:39   ` Greg KH
  2013-06-19 15:04     ` Ming Lei
  0 siblings, 1 reply; 23+ messages in thread
From: Greg KH @ 2013-06-19 14:39 UTC (permalink / raw)
  To: Ming Lei; +Cc: Stephen Rothwell, linux-next, linux-kernel, Takashi Iwai

On Wed, Jun 19, 2013 at 02:58:39PM +0800, Ming Lei wrote:
> On Wed, Jun 19, 2013 at 1:32 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Greg,
> >
> > Today's linux-next merge of the driver-core tree got a conflict in
> > drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
> > loader: fix use-after-free by double abort") from the driver-core.current
> > tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
> > lock at shutdown") from the driver-core tree.
> >
> > I fixed it up (more may be required - see below) and can carry the fix as
> > necessary (no action is required).
> >
> > --
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> >
> > diff --cc drivers/base/firmware_class.c
> > index 01e2103,6ede229..0000000
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@@ -446,22 -452,11 +452,18 @@@ static struct firmware_priv *to_firmwar
> >         return container_of(dev, struct firmware_priv, dev);
> >   }
> >
> > - static void fw_load_abort(struct firmware_priv *fw_priv)
> > + static void fw_load_abort(struct firmware_buf *buf)
> >   {
> > -       struct firmware_buf *buf = fw_priv->buf;
> > -
> >  +      /*
> >  +       * There is a small window in which user can write to 'loading'
> >  +       * between loading done and disappearance of 'loading'
> >  +       */
> >  +      if (test_bit(FW_STATUS_DONE, &buf->status))
> >  +              return;
> >  +
> > +       list_del_init(&buf->pending_list);
> >         set_bit(FW_STATUS_ABORT, &buf->status);
> >         complete_all(&buf->completion);
> > -
> > -       /* avoid user action after loading abort */
> > -       fw_priv->buf = NULL;
> 
> Hmm, maybe the most important part in the commit 875979368eb4
> ("firmware loader: fix use-after-free by double abort") has been removed, :-)
> 
> In fact, the commit 87597936 is for linus tree only because it is a fix,
> so the conflict is caused by merging it with other firmware loader patches
> in -next tree.
> 
> Greg, I can figure out one patch for -next easily, but it depends you
> push it on 3.10-rc or 3.11-rc.

I'll be pushing your patch for 3.10-final to Linus as it fixes a bug,
but I will need something to resolve the merge issue properly.  Can you
provide me that patch/merge?

thanks,

greg k-h

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-19  7:12 ` Stephen Rothwell
@ 2013-06-19  7:21   ` Ming Lei
  0 siblings, 0 replies; 23+ messages in thread
From: Ming Lei @ 2013-06-19  7:21 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Takashi Iwai

On Wed, Jun 19, 2013 at 3:12 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Greg,
>
> On Wed, 19 Jun 2013 15:32:25 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the driver-core tree got a conflict in
>> drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
>> loader: fix use-after-free by double abort") from the driver-core.current
>> tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
>> lock at shutdown") from the driver-core tree.
>>
>> I fixed it up (more may be required - see below) and can carry the fix as
>> necessary (no action is required).
>
> I missed the bit below (at least) and have now added this as a merge fix
> for the driver-core tree.

I think it is OK to merge, then I can add the 'more' part about the original
fix(875979368eb4) against today's change.

>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 19 Jun 2013 17:08:01 +1000
> Subject: [PATCH] fix up for fw_load_abort API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/base/firmware_class.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 57aa842..fdacd77 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -812,7 +812,7 @@ static void firmware_class_timeout_work(struct work_struct *work)
>                         struct firmware_priv, timeout_work.work);
>
>         mutex_lock(&fw_lock);
> -       fw_load_abort(fw_priv);
> +       fw_load_abort(fw_priv->buf);
>         mutex_unlock(&fw_lock);
>  }
>
> --
> 1.8.1
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-19  5:32 Stephen Rothwell
  2013-06-19  5:55 ` Greg KH
  2013-06-19  6:58 ` Ming Lei
@ 2013-06-19  7:12 ` Stephen Rothwell
  2013-06-19  7:21   ` Ming Lei
  2 siblings, 1 reply; 23+ messages in thread
From: Stephen Rothwell @ 2013-06-19  7:12 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Ming Lei, Takashi Iwai

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

Hi Greg,

On Wed, 19 Jun 2013 15:32:25 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
> loader: fix use-after-free by double abort") from the driver-core.current
> tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
> lock at shutdown") from the driver-core tree.
> 
> I fixed it up (more may be required - see below) and can carry the fix as
> necessary (no action is required).

I missed the bit below (at least) and have now added this as a merge fix
for the driver-core tree.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 19 Jun 2013 17:08:01 +1000
Subject: [PATCH] fix up for fw_load_abort API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/base/firmware_class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 57aa842..fdacd77 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -812,7 +812,7 @@ static void firmware_class_timeout_work(struct work_struct *work)
 			struct firmware_priv, timeout_work.work);
 
 	mutex_lock(&fw_lock);
-	fw_load_abort(fw_priv);
+	fw_load_abort(fw_priv->buf);
 	mutex_unlock(&fw_lock);
 }
 
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-19  5:32 Stephen Rothwell
  2013-06-19  5:55 ` Greg KH
@ 2013-06-19  6:58 ` Ming Lei
  2013-06-19 14:39   ` Greg KH
  2013-06-19  7:12 ` Stephen Rothwell
  2 siblings, 1 reply; 23+ messages in thread
From: Ming Lei @ 2013-06-19  6:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Takashi Iwai

On Wed, Jun 19, 2013 at 1:32 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
> loader: fix use-after-free by double abort") from the driver-core.current
> tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
> lock at shutdown") from the driver-core tree.
>
> I fixed it up (more may be required - see below) and can carry the fix as
> necessary (no action is required).
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
>
> diff --cc drivers/base/firmware_class.c
> index 01e2103,6ede229..0000000
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@@ -446,22 -452,11 +452,18 @@@ static struct firmware_priv *to_firmwar
>         return container_of(dev, struct firmware_priv, dev);
>   }
>
> - static void fw_load_abort(struct firmware_priv *fw_priv)
> + static void fw_load_abort(struct firmware_buf *buf)
>   {
> -       struct firmware_buf *buf = fw_priv->buf;
> -
>  +      /*
>  +       * There is a small window in which user can write to 'loading'
>  +       * between loading done and disappearance of 'loading'
>  +       */
>  +      if (test_bit(FW_STATUS_DONE, &buf->status))
>  +              return;
>  +
> +       list_del_init(&buf->pending_list);
>         set_bit(FW_STATUS_ABORT, &buf->status);
>         complete_all(&buf->completion);
> -
> -       /* avoid user action after loading abort */
> -       fw_priv->buf = NULL;

Hmm, maybe the most important part in the commit 875979368eb4
("firmware loader: fix use-after-free by double abort") has been removed, :-)

In fact, the commit 87597936 is for linus tree only because it is a fix,
so the conflict is caused by merging it with other firmware loader patches
in -next tree.

Greg, I can figure out one patch for -next easily, but it depends you
push it on 3.10-rc or 3.11-rc.


Thanks,
--
Ming Lei

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2013-06-19  5:32 Stephen Rothwell
@ 2013-06-19  5:55 ` Greg KH
  2013-06-19  6:58 ` Ming Lei
  2013-06-19  7:12 ` Stephen Rothwell
  2 siblings, 0 replies; 23+ messages in thread
From: Greg KH @ 2013-06-19  5:55 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Ming Lei, Takashi Iwai

On Wed, Jun 19, 2013 at 03:32:25PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
> loader: fix use-after-free by double abort") from the driver-core.current
> tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
> lock at shutdown") from the driver-core tree.
> 
> I fixed it up (more may be required - see below) and can carry the fix as
> necessary (no action is required).

Thanks, the merge looks correct, Ming, any objection?

greg k-h

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

* linux-next: manual merge of the driver-core tree with the driver-core.current tree
@ 2013-06-19  5:32 Stephen Rothwell
  2013-06-19  5:55 ` Greg KH
                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Stephen Rothwell @ 2013-06-19  5:32 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Ming Lei, Takashi Iwai

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
drivers/base/firmware_class.c between commit 875979368eb4 ("firmware
loader: fix use-after-free by double abort") from the driver-core.current
tree and commit fe304143b0c3 ("firmware: Avoid deadlock of usermodehelper
lock at shutdown") from the driver-core tree.

I fixed it up (more may be required - see below) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/base/firmware_class.c
index 01e2103,6ede229..0000000
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@@ -446,22 -452,11 +452,18 @@@ static struct firmware_priv *to_firmwar
  	return container_of(dev, struct firmware_priv, dev);
  }
  
- static void fw_load_abort(struct firmware_priv *fw_priv)
+ static void fw_load_abort(struct firmware_buf *buf)
  {
- 	struct firmware_buf *buf = fw_priv->buf;
- 
 +	/*
 +	 * There is a small window in which user can write to 'loading'
 +	 * between loading done and disappearance of 'loading'
 +	 */
 +	if (test_bit(FW_STATUS_DONE, &buf->status))
 +		return;
 +
+ 	list_del_init(&buf->pending_list);
  	set_bit(FW_STATUS_ABORT, &buf->status);
  	complete_all(&buf->completion);
- 
- 	/* avoid user action after loading abort */
- 	fw_priv->buf = NULL;
  }
  
  #define is_fw_load_aborted(buf)	\

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: manual merge of the driver-core tree with the driver-core.current tree
  2012-02-03  3:51 Stephen Rothwell
@ 2012-02-03 15:07 ` Greg KH
  0 siblings, 0 replies; 23+ messages in thread
From: Greg KH @ 2012-02-03 15:07 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Thomas Renninger

On Fri, Feb 03, 2012 at 02:51:06PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/base/cpu.c between commit 2885e25c422f ("driver core: cpu: remove
> kernel warning when removing a cpu") from the driver-core.current tree
> and commit fad12ac8c8c2 ("CPU: Introduce ARCH_HAS_CPU_AUTOPROBE and X86
> parts") from the driver-core tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Thanks for this, I'll fix it up when I merge them back together when
3.3-rc3 comes out.

greg k-h

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

* linux-next: manual merge of the driver-core tree with the driver-core.current tree
@ 2012-02-03  3:51 Stephen Rothwell
  2012-02-03 15:07 ` Greg KH
  0 siblings, 1 reply; 23+ messages in thread
From: Stephen Rothwell @ 2012-02-03  3:51 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Thomas Renninger

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
drivers/base/cpu.c between commit 2885e25c422f ("driver core: cpu: remove
kernel warning when removing a cpu") from the driver-core.current tree
and commit fad12ac8c8c2 ("CPU: Introduce ARCH_HAS_CPU_AUTOPROBE and X86
parts") from the driver-core tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/base/cpu.c
index 23f2c4c,2a0c670..0000000
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@@ -242,7 -224,9 +243,10 @@@ int __cpuinit register_cpu(struct cpu *
  	cpu->node_id = cpu_to_node(num);
  	cpu->dev.id = num;
  	cpu->dev.bus = &cpu_subsys;
 +	cpu->dev.release = cpu_device_release;
+ #ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE
+ 	cpu->dev.bus->uevent = arch_cpu_uevent;
+ #endif
  	error = device_register(&cpu->dev);
  	if (!error && cpu->hotpluggable)
  		register_cpu_control(cpu);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

end of thread, other threads:[~2020-04-30  8:15 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-09  3:47 linux-next: manual merge of the driver-core tree with the driver-core.current tree Stephen Rothwell
2013-12-09  8:21 ` Greg KH
2013-12-10 14:50   ` [PATCH driver-core-next] sysfs: bail early from kernfs_file_mmap() to avoid spurious lockdep warning Tejun Heo
2013-12-11  0:03     ` Stephen Rothwell
2013-12-11  5:39     ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2020-04-30  4:25 linux-next: manual merge of the driver-core tree with the driver-core.current tree Stephen Rothwell
2020-04-30  8:15 ` Greg KH
2013-06-19  5:32 Stephen Rothwell
2013-06-19  5:55 ` Greg KH
2013-06-19  6:58 ` Ming Lei
2013-06-19 14:39   ` Greg KH
2013-06-19 15:04     ` Ming Lei
2013-06-19 16:36       ` Greg KH
2013-06-20  0:23         ` Ming Lei
2013-06-20  1:06           ` Stephen Rothwell
2013-06-20  1:22             ` Ming Lei
2013-06-20  3:28               ` Greg KH
2013-06-20  3:46                 ` Ming Lei
2013-06-20  3:49                 ` Stephen Rothwell
2013-06-19  7:12 ` Stephen Rothwell
2013-06-19  7:21   ` Ming Lei
2012-02-03  3:51 Stephen Rothwell
2012-02-03 15:07 ` Greg KH

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