Re: [-next] BUG_ON in scsi_target_destroy()

[Xiong Zhou]

Hi,

On Wed, Apr 13, 2016 at 11:14 PM, James Bottomley
 wrote:
> On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote:
>> Hi Sergey,  Xiong,
>>
>> Can you try below patch?
>>
>> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
>> > Hello,
>> >
>> > commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
>> > Author: Johannes Thumshirn 
>> > Date:   Tue Apr 5 11:50:44 2016 +0200
>> >
>> > scsi: Add intermediate STARGET_REMOVE state to
>> > scsi_target_state
>> >
>> >
>> > BUG_ON()s (next-20160411) each time I remove a usb flash
>> >
>> > [   49.561600]  [] scsi_target_destroy+0x5a/0xcb
>> > [scsi_mod]
>> > [   49.561607]  [] scsi_target_reap+0x4a/0x4f
>> > [scsi_mod]
>> > [   49.561613]  [] __scsi_remove_device+0xc3/0xd0
>> > [scsi_mod]
>> > [   49.561619]  [] scsi_forget_host+0x52/0x63
>> > [scsi_mod]
>> > [   49.561623]  [] scsi_remove_host+0x8c/0x102
>> > [scsi_mod]
>> > [   49.561627]  [] usb_stor_disconnect+0x6b/0xab
>> > [usb_storage]
>> > [   49.561634]  []
>> > usb_unbind_interface+0x77/0x1ca [usbcore]
>> > [   49.561636]  []
>> > __device_release_driver+0x9d/0x121
>> > [   49.561638]  []
>> > device_release_driver+0x23/0x30
>> > [   49.561639]  [] bus_remove_device+0xfb/0x10e
>> > [   49.561641]  [] device_del+0x164/0x1e6
>> > [   49.561648]  [] ?
>> > remove_intf_ep_devs+0x3b/0x48 [usbcore]
>> > [   49.561655]  [] usb_disable_device+0x84/0x1a5
>> > [usbcore]
>> > [   49.561661]  [] usb_disconnect+0x94/0x19f
>> > [usbcore]
>> > [   49.561667]  [] hub_event+0x5c1/0xdea
>> > [usbcore]
>> > [   49.561670]  [] process_one_work+0x1dc/0x37f
>> > [   49.561672]  [] worker_thread+0x282/0x36d
>> > [   49.561673]  [] ? rescuer_thread+0x2ae/0x2ae
>> > [   49.561675]  [] kthread+0xd2/0xda
>> > [   49.561678]  [] ret_from_fork+0x22/0x40
>> > [   49.561679]  [] ?
>> > kthread_worker_fn+0x13e/0x13e
>> >
>> > -ss
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux
>> > -scsi" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>>
>> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
>> index 0734927..0c00928 100644
>> --- a/drivers/scsi/scsi_sysfs.c
>> +++ b/drivers/scsi/scsi_sysfs.c
>> @@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device
>> *sdev)
>>  void __scsi_remove_device(struct scsi_device *sdev)
>>  {
>>   struct device *dev = >sdev_gendev;
>> + struct scsi_target *starget;
>>
>>   /*
>>* This cleanup path is not reentrant and while it is
>> impossible
>> @@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device
>> *sdev)
>>* remoed sysfs visibility from the device, so make the
>> target
>>* invisible if this was the last device underneath it.
>>*/
>> - scsi_target_reap(scsi_target(sdev));
>> + starget = scsi_target(sdev);
>> + starget->state = STARGET_REMOVE;
>> + scsi_target_reap(starget);
>
> How about good grief no!  A device with multiple targets will get it's
> lists screwed with this
>
> The STARGET_REMOVE state you added only applies to the case we're
> trying to kill a target.  In the natural operation case, which is what
> everyone else is running into, we will try to remove a running target
> when it has no more scsi devices left on it.  So the correct patch
> should be to make the BUG_ON see this:
>
> James
>
> ---
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 27df7e7..e0a78f5 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -319,8 +319,7 @@ static void scsi_target_destroy(struct scsi_target 
> *starget)
> struct Scsi_Host *shost = dev_to_shost(dev->parent);
> unsigned long flags;
>
> -   BUG_ON(starget->state != STARGET_REMOVE &&
> -  starget->state != STARGET_CREATED);
> +   BUG_ON(starget->state == STARGET_DEL);
> starget->state = STARGET_DEL;
> transport_destroy_device(dev);
> spin_lock_irqsave(shost->host_lock, flags);
>


This will survive modprobe -r scsi_debug ..

Just to make sure, is this _REMOVE state able to do the latter thing what it was
trying to do, in this way ?


commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
Author: Johannes Thumshirn 
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
state is only valid in the path from scsi_remove_target() to
scsi_target_destroy() indicating this target is going to be removed.

This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI]
scsi_remove_target: fix softlockup regression on hot remove") and
40998193560d ("scsi: restart list search after unlock in
scsi_remove_target") in a more 

Re: [-next] BUG_ON in scsi_target_destroy()

[Xiong Zhou]

Hi,

On Wed, Apr 13, 2016 at 11:14 PM, James Bottomley
 wrote:
> On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote:
>> Hi Sergey,  Xiong,
>>
>> Can you try below patch?
>>
>> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
>> > Hello,
>> >
>> > commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
>> > Author: Johannes Thumshirn 
>> > Date:   Tue Apr 5 11:50:44 2016 +0200
>> >
>> > scsi: Add intermediate STARGET_REMOVE state to
>> > scsi_target_state
>> >
>> >
>> > BUG_ON()s (next-20160411) each time I remove a usb flash
>> >
>> > [   49.561600]  [] scsi_target_destroy+0x5a/0xcb
>> > [scsi_mod]
>> > [   49.561607]  [] scsi_target_reap+0x4a/0x4f
>> > [scsi_mod]
>> > [   49.561613]  [] __scsi_remove_device+0xc3/0xd0
>> > [scsi_mod]
>> > [   49.561619]  [] scsi_forget_host+0x52/0x63
>> > [scsi_mod]
>> > [   49.561623]  [] scsi_remove_host+0x8c/0x102
>> > [scsi_mod]
>> > [   49.561627]  [] usb_stor_disconnect+0x6b/0xab
>> > [usb_storage]
>> > [   49.561634]  []
>> > usb_unbind_interface+0x77/0x1ca [usbcore]
>> > [   49.561636]  []
>> > __device_release_driver+0x9d/0x121
>> > [   49.561638]  []
>> > device_release_driver+0x23/0x30
>> > [   49.561639]  [] bus_remove_device+0xfb/0x10e
>> > [   49.561641]  [] device_del+0x164/0x1e6
>> > [   49.561648]  [] ?
>> > remove_intf_ep_devs+0x3b/0x48 [usbcore]
>> > [   49.561655]  [] usb_disable_device+0x84/0x1a5
>> > [usbcore]
>> > [   49.561661]  [] usb_disconnect+0x94/0x19f
>> > [usbcore]
>> > [   49.561667]  [] hub_event+0x5c1/0xdea
>> > [usbcore]
>> > [   49.561670]  [] process_one_work+0x1dc/0x37f
>> > [   49.561672]  [] worker_thread+0x282/0x36d
>> > [   49.561673]  [] ? rescuer_thread+0x2ae/0x2ae
>> > [   49.561675]  [] kthread+0xd2/0xda
>> > [   49.561678]  [] ret_from_fork+0x22/0x40
>> > [   49.561679]  [] ?
>> > kthread_worker_fn+0x13e/0x13e
>> >
>> > -ss
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux
>> > -scsi" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>>
>> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
>> index 0734927..0c00928 100644
>> --- a/drivers/scsi/scsi_sysfs.c
>> +++ b/drivers/scsi/scsi_sysfs.c
>> @@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device
>> *sdev)
>>  void __scsi_remove_device(struct scsi_device *sdev)
>>  {
>>   struct device *dev = >sdev_gendev;
>> + struct scsi_target *starget;
>>
>>   /*
>>* This cleanup path is not reentrant and while it is
>> impossible
>> @@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device
>> *sdev)
>>* remoed sysfs visibility from the device, so make the
>> target
>>* invisible if this was the last device underneath it.
>>*/
>> - scsi_target_reap(scsi_target(sdev));
>> + starget = scsi_target(sdev);
>> + starget->state = STARGET_REMOVE;
>> + scsi_target_reap(starget);
>
> How about good grief no!  A device with multiple targets will get it's
> lists screwed with this
>
> The STARGET_REMOVE state you added only applies to the case we're
> trying to kill a target.  In the natural operation case, which is what
> everyone else is running into, we will try to remove a running target
> when it has no more scsi devices left on it.  So the correct patch
> should be to make the BUG_ON see this:
>
> James
>
> ---
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 27df7e7..e0a78f5 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -319,8 +319,7 @@ static void scsi_target_destroy(struct scsi_target 
> *starget)
> struct Scsi_Host *shost = dev_to_shost(dev->parent);
> unsigned long flags;
>
> -   BUG_ON(starget->state != STARGET_REMOVE &&
> -  starget->state != STARGET_CREATED);
> +   BUG_ON(starget->state == STARGET_DEL);
> starget->state = STARGET_DEL;
> transport_destroy_device(dev);
> spin_lock_irqsave(shost->host_lock, flags);
>


This will survive modprobe -r scsi_debug ..

Just to make sure, is this _REMOVE state able to do the latter thing what it was
trying to do, in this way ?


commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
Author: Johannes Thumshirn 
Date:   Tue Apr 5 11:50:44 2016 +0200

scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
state is only valid in the path from scsi_remove_target() to
scsi_target_destroy() indicating this target is going to be removed.

This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI]
scsi_remove_target: fix softlockup regression on hot remove") and
40998193560d ("scsi: restart list search after unlock in
scsi_remove_target") in a more comprehensive way.

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Juergen Gross]

On 14/04/16 21:44, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote:
>> On 13/04/16 20:52, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
 On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez  wrote:
> So more to it, if the EFI entry already provides a way into Linux
> in a more streamlined fashion bringing it closer to the bare metal
> boot entry, why *would* we add another boot entry to x86, even if
> its small and self contained ?

 We would avoid using EFI if:
>>>
>>> And this is what I was looking for, thanks!
>>>
 * Being called both on real hardware and under Xen would make the EFI
 entry point more complicated
>>>
>>> That's on the EFI Linux maintainer to assess. And he seems willing to
>>> consider this.
>>>
 * Adding the necessary EFI support into Xen would be a significant
 chunk of extra work
>>>
>>> This seems to be a good sticking point, but Andi noted another aspect
>>> of this or redundancy as well.
>>>
 * Requiring PVH mode to implement EFI would make it more difficult for
 other kernes (NetBSD, FreeBSD) to act as dom0s.
>>>
>>> What if this is an option only then ?
>>>

 * Requiring PVH mode to use EFI would make it more difficult to
 support unikernel-style workloads for domUs.
>>>
>>> What if this is an option only then ?
>>
>> So first of all, you asked why anyone would oppose EFI, and this is part
>> of the answer to that.
>>
>> Secondly, you mean "What if this is the only thing the Linux maintainers
>> will accept?"  And you already know the answer to that.
> 
> No, I meant to ask, would it be possible to make booting HVMLite using EFI
> be optional ? That way if you already support EFI that can be used on
> your entires with some small modifications.

So you suggest to add two HVMlite modes regarding boot interface
instead of one?

I still have the impression you are suggesting by using the same entry
everything is solved in the OS. You still need the support of HVMlite
especially in the early boot path to make sure the OS won't try to use
the complete EFI standard.

> 
>> How much of a burden it would be on the rest of the open-source
>> ecosystem (Xen, *BSDs, ) is a combination of some as-yet unknown facts
>> (i.e., what a minimal Xen/Linux EFI interface would look like) and a
>> matter of judgement (i.e., given the same interface, reasonable people
>> may come to different conclusions about whether the interface is an
>> undue burden to impose on others or not).
>>
>> But I would hope that the Linux maintainers would at least consider the
>> broader community when weighing their decisions, and not take advantage
>> of their position of dominance to simply ignore the effect of their
>> choices on everybody else.
> 
> This has nothing to do with dominance or anything nefarious, I'm asking
> simply for a full engineering evaluation of all possibilities, with
> the long term in mind. Not for now, but for hardware assumptions which
> are sensible 5 years from now.

No, they are not.

Given how long the EFI standard is available now and how buggy many
vendor's implementations are I don't expect all computers sold in 5
years will have a usable EFI. This will be true especially for
consumer devices where no EFI is available today.


Juergen

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Juergen Gross]

On 14/04/16 21:44, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote:
>> On 13/04/16 20:52, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
 On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez  wrote:
> So more to it, if the EFI entry already provides a way into Linux
> in a more streamlined fashion bringing it closer to the bare metal
> boot entry, why *would* we add another boot entry to x86, even if
> its small and self contained ?

 We would avoid using EFI if:
>>>
>>> And this is what I was looking for, thanks!
>>>
 * Being called both on real hardware and under Xen would make the EFI
 entry point more complicated
>>>
>>> That's on the EFI Linux maintainer to assess. And he seems willing to
>>> consider this.
>>>
 * Adding the necessary EFI support into Xen would be a significant
 chunk of extra work
>>>
>>> This seems to be a good sticking point, but Andi noted another aspect
>>> of this or redundancy as well.
>>>
 * Requiring PVH mode to implement EFI would make it more difficult for
 other kernes (NetBSD, FreeBSD) to act as dom0s.
>>>
>>> What if this is an option only then ?
>>>

 * Requiring PVH mode to use EFI would make it more difficult to
 support unikernel-style workloads for domUs.
>>>
>>> What if this is an option only then ?
>>
>> So first of all, you asked why anyone would oppose EFI, and this is part
>> of the answer to that.
>>
>> Secondly, you mean "What if this is the only thing the Linux maintainers
>> will accept?"  And you already know the answer to that.
> 
> No, I meant to ask, would it be possible to make booting HVMLite using EFI
> be optional ? That way if you already support EFI that can be used on
> your entires with some small modifications.

So you suggest to add two HVMlite modes regarding boot interface
instead of one?

I still have the impression you are suggesting by using the same entry
everything is solved in the OS. You still need the support of HVMlite
especially in the early boot path to make sure the OS won't try to use
the complete EFI standard.

> 
>> How much of a burden it would be on the rest of the open-source
>> ecosystem (Xen, *BSDs, ) is a combination of some as-yet unknown facts
>> (i.e., what a minimal Xen/Linux EFI interface would look like) and a
>> matter of judgement (i.e., given the same interface, reasonable people
>> may come to different conclusions about whether the interface is an
>> undue burden to impose on others or not).
>>
>> But I would hope that the Linux maintainers would at least consider the
>> broader community when weighing their decisions, and not take advantage
>> of their position of dominance to simply ignore the effect of their
>> choices on everybody else.
> 
> This has nothing to do with dominance or anything nefarious, I'm asking
> simply for a full engineering evaluation of all possibilities, with
> the long term in mind. Not for now, but for hardware assumptions which
> are sensible 5 years from now.

No, they are not.

Given how long the EFI standard is available now and how buggy many
vendor's implementations are I don't expect all computers sold in 5
years will have a usable EFI. This will be true especially for
consumer devices where no EFI is available today.


Juergen

Re: [PATCH] fujitsu-laptop: Support radio LED

[Darren Hart]

On Fri, Apr 15, 2016 at 03:03:33PM +0930, Jonathan Woithe wrote:
> On Thu, Apr 14, 2016 at 09:42:55PM -0700, Darren Hart wrote:
> > > Signed-off-by: Michał Kępień 
> > 
> > Jonathan, please check your character set, a few mangled characters here
> > which I have to fix up to use.  UTF-8 seems to work reliably.
> 
> Sorry about that.  Normally UTF-8 stuff goes through just fine so I'm not sure
> what happened there.  I'll admit I've never touched the default mutt charset
> settings though so perhaps there's a corner case that's not being handled. 
> I'll look into it.
> 
> > > Acked-by: Jonathan Woithe 
> > > 
> > > Michał hasn't indicated that a revised patch is in the works so I'm fine 
> > > if
> > > you proceed with the one below.  I've selected the relevant parts of his
> > > preamble for inclusion in the commit message, but feel free to edit 
> > > further
> > > to your taste.
> > 
> > Yeah, tough call, some guess work involved here, and where we are
> > uncertain, we should document it.  I don't think we need to include bits
> > about uncertain future plans or speculation on how things might be done. 
> > Keep it to what this patch does and any qualifiers a developer should be
> > aware of.
> 
> I agree.  Also note that a followup post from the original submitter
> indicated they were happy to go with what I proposed.
> 
> > I've made a couple cosmetic changes and queued to for-next. Please review
> > and let me know if you have any concerns.
> 
> Sure.  Pardon my ignorance of such things, but what is the most
> straight-forward way to review the queued commit (preferrably without
> cloning an entire kernel git repo)?

You can see the tree in the MAINTAINERS file, but I suppose that doesn't make it
obvious how to browse it. You can do that via the git web interface on
infradead. The direct link to this patch is here:

http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/commit/34b5199d2b69f9be731233af2425c53cc7ff995b

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] fujitsu-laptop: Support radio LED

[Darren Hart]

On Fri, Apr 15, 2016 at 03:03:33PM +0930, Jonathan Woithe wrote:
> On Thu, Apr 14, 2016 at 09:42:55PM -0700, Darren Hart wrote:
> > > Signed-off-by: Michał Kępień 
> > 
> > Jonathan, please check your character set, a few mangled characters here
> > which I have to fix up to use.  UTF-8 seems to work reliably.
> 
> Sorry about that.  Normally UTF-8 stuff goes through just fine so I'm not sure
> what happened there.  I'll admit I've never touched the default mutt charset
> settings though so perhaps there's a corner case that's not being handled. 
> I'll look into it.
> 
> > > Acked-by: Jonathan Woithe 
> > > 
> > > Michał hasn't indicated that a revised patch is in the works so I'm fine 
> > > if
> > > you proceed with the one below.  I've selected the relevant parts of his
> > > preamble for inclusion in the commit message, but feel free to edit 
> > > further
> > > to your taste.
> > 
> > Yeah, tough call, some guess work involved here, and where we are
> > uncertain, we should document it.  I don't think we need to include bits
> > about uncertain future plans or speculation on how things might be done. 
> > Keep it to what this patch does and any qualifiers a developer should be
> > aware of.
> 
> I agree.  Also note that a followup post from the original submitter
> indicated they were happy to go with what I proposed.
> 
> > I've made a couple cosmetic changes and queued to for-next. Please review
> > and let me know if you have any concerns.
> 
> Sure.  Pardon my ignorance of such things, but what is the most
> straight-forward way to review the queued commit (preferrably without
> cloning an entire kernel git repo)?

You can see the tree in the MAINTAINERS file, but I suppose that doesn't make it
obvious how to browse it. You can do that via the git web interface on
infradead. The direct link to this patch is here:

http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/commit/34b5199d2b69f9be731233af2425c53cc7ff995b

-- 
Darren Hart
Intel Open Source Technology Center

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

[Ingo Molnar]

* Denys Vlasenko  wrote:

> > In fact, the following patch seems to fix it:
> > 
> > diff --git a/include/scsi/scsi_transport_fc.h 
> > b/include/scsi/scsi_transport_fc.h
> > index bf66ea6..56b9e81 100644
> > --- a/include/scsi/scsi_transport_fc.h
> > +++ b/include/scsi/scsi_transport_fc.h
> > @@ -796,7 +796,7 @@ fc_remote_port_chkready(struct fc_rport *rport)
> > return result;
> >  }
> >  
> > -static inline u64 wwn_to_u64(u8 *wwn)
> > +static __always_inline u64 wwn_to_u64(u8 *wwn)
> >  {
> > return get_unaligned_be64(wwn);
> >  }
> 
> It is not a guarantee.

Of course it's a workaround - but is there any deterministic way to turn off 
this 
GCC bug (by activating some GCC command line switch), or do we have to live 
with 
objtool warning about this GCC?

Which, by the way, is pretty cool!

Thanks,

Ingo

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

[Ingo Molnar]

* Denys Vlasenko  wrote:

> > In fact, the following patch seems to fix it:
> > 
> > diff --git a/include/scsi/scsi_transport_fc.h 
> > b/include/scsi/scsi_transport_fc.h
> > index bf66ea6..56b9e81 100644
> > --- a/include/scsi/scsi_transport_fc.h
> > +++ b/include/scsi/scsi_transport_fc.h
> > @@ -796,7 +796,7 @@ fc_remote_port_chkready(struct fc_rport *rport)
> > return result;
> >  }
> >  
> > -static inline u64 wwn_to_u64(u8 *wwn)
> > +static __always_inline u64 wwn_to_u64(u8 *wwn)
> >  {
> > return get_unaligned_be64(wwn);
> >  }
> 
> It is not a guarantee.

Of course it's a workaround - but is there any deterministic way to turn off 
this 
GCC bug (by activating some GCC command line switch), or do we have to live 
with 
objtool warning about this GCC?

Which, by the way, is pretty cool!

Thanks,

Ingo

Re: [PATCH] fujitsu-laptop: Support radio LED

[Jonathan Woithe]

On Thu, Apr 14, 2016 at 09:42:55PM -0700, Darren Hart wrote:
> > Signed-off-by: Michał Kępień 
> 
> Jonathan, please check your character set, a few mangled characters here
> which I have to fix up to use.  UTF-8 seems to work reliably.

Sorry about that.  Normally UTF-8 stuff goes through just fine so I'm not sure
what happened there.  I'll admit I've never touched the default mutt charset
settings though so perhaps there's a corner case that's not being handled. 
I'll look into it.

> > Acked-by: Jonathan Woithe 
> > 
> > Michał hasn't indicated that a revised patch is in the works so I'm fine if
> > you proceed with the one below.  I've selected the relevant parts of his
> > preamble for inclusion in the commit message, but feel free to edit further
> > to your taste.
> 
> Yeah, tough call, some guess work involved here, and where we are
> uncertain, we should document it.  I don't think we need to include bits
> about uncertain future plans or speculation on how things might be done. 
> Keep it to what this patch does and any qualifiers a developer should be
> aware of.

I agree.  Also note that a followup post from the original submitter
indicated they were happy to go with what I proposed.

> I've made a couple cosmetic changes and queued to for-next. Please review
> and let me know if you have any concerns.

Sure.  Pardon my ignorance of such things, but what is the most
straight-forward way to review the queued commit (preferrably without
cloning an entire kernel git repo)?

jonathan

Re: [PATCH] fujitsu-laptop: Support radio LED

[Jonathan Woithe]

On Thu, Apr 14, 2016 at 09:42:55PM -0700, Darren Hart wrote:
> > Signed-off-by: Michał Kępień 
> 
> Jonathan, please check your character set, a few mangled characters here
> which I have to fix up to use.  UTF-8 seems to work reliably.

Sorry about that.  Normally UTF-8 stuff goes through just fine so I'm not sure
what happened there.  I'll admit I've never touched the default mutt charset
settings though so perhaps there's a corner case that's not being handled. 
I'll look into it.

> > Acked-by: Jonathan Woithe 
> > 
> > Michał hasn't indicated that a revised patch is in the works so I'm fine if
> > you proceed with the one below.  I've selected the relevant parts of his
> > preamble for inclusion in the commit message, but feel free to edit further
> > to your taste.
> 
> Yeah, tough call, some guess work involved here, and where we are
> uncertain, we should document it.  I don't think we need to include bits
> about uncertain future plans or speculation on how things might be done. 
> Keep it to what this patch does and any qualifiers a developer should be
> aware of.

I agree.  Also note that a followup post from the original submitter
indicated they were happy to go with what I proposed.

> I've made a couple cosmetic changes and queued to for-next. Please review
> and let me know if you have any concerns.

Sure.  Pardon my ignorance of such things, but what is the most
straight-forward way to review the queued commit (preferrably without
cloning an entire kernel git repo)?

jonathan

Re: [PATCH 1/7] PM / devfreq: event: Add new Exynos NoC probe driver

[Chanwoo Choi]

On 2016년 04월 12일 17:07, Krzysztof Kozlowski wrote:
> On 04/08/2016 07:00 AM, Chanwoo Choi wrote:
>> This patch adds NoC (Network on Chip) Probe driver which provides
>> the primitive values to get the performance data. The packets that the 
>> Network
>> on Chip (NoC) probes detects are transported over the network infrastructure.
>> Exynos542x bus has multiple NoC probes to provide bandwidth information about
>> behavior of the SoC that you can use while analyzing system performance.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  .../bindings/devfreq/event/exynos-nocp.txt |  86 +++
>>  drivers/devfreq/event/Kconfig  |   8 +
>>  drivers/devfreq/event/Makefile |   2 +
>>  drivers/devfreq/event/exynos-nocp.c| 247 
>> +
>>  drivers/devfreq/event/exynos-nocp.h|  78 +++
>>  5 files changed, 421 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
>>  create mode 100644 drivers/devfreq/event/exynos-nocp.c
>>  create mode 100644 drivers/devfreq/event/exynos-nocp.h
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt 
>> b/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
>> new file mode 100644
>> index ..03b74fed034c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
>> @@ -0,0 +1,86 @@
>> +
>> +* Samsung Exynos NoC (Network on Chip) Probe device
>> +
>> +The Samsung Exynos542x SoC has NoC (Network on Chip) Probe for NoC bus.
>> +NoC provides the primitive values to get the performance data. The packets
>> +that the Network on Chip (NoC) probes detects are transported over
>> +the network infrastructure to observer units. You can configure probes to
>> +capture packets with header or data on the data request response network,
>> +or as traffic debug or statistic collectors. Exynos542x bus has multiple
>> +NoC probes to provide bandwidth information about behavior of the SoC
>> +that you can use while analyzing system performance.
>> +
>> +Required properties:
>> +- compatible: Should be "samsung,exynos5420-nocp"
>> +- reg: physical base address of each NoC Probe and length of memory mapped 
>> region.
>> +
>> +Optional properties:
>> +- clock-names : the name of clock used by the NoC Probe, "nocp"
>> +- clocks : phandles for clock specified in "clock-names" property
>> +
>> +Example1 : NoC Probe nodes in exynos5420.dtsi are listed below.
>> +
>> +nocp_mem0_0: nocp_mem0_0@10CA1000 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x10CA1000 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_mem0_1: nocp_mem0_1@10CA1400 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x10CA1400 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_mem0_2: nocp_mem0_2@10CA1800 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x10CA1800 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_mem0_3: nocp_mem0_0@10CA1C00 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x10CA1C00 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_g3d_0: nocp_g3d_0@11A51000 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x11A51000 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_g3d_1: nocp_g3d_1@11A51400 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x11A51400 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +
>> +Example2 : Events of each NoC Probe node in exynos5422-odroidxu3-common.dtsi
>> +are listed below.
>> +
>> +
>> +_mem0_0 {
>> +status = "okay";
>> +};
>> +
>> +_mem0_1 {
>> +status = "okay";
>> +};
>> +
>> +_mem0_2 {
>> +status = "okay";
>> +};
>> +
>> +_mem0_3 {
>> +status = "okay";
>> +};
>> +
>> +_g3d_0 {
>> +status = "okay";
>> +};
>> +
>> +_g3d_1 {
>> +status = "okay";
>> +};
> 
> I think this split in documentation between DTSI and DTS is not needed
> for example. Just add one example without the status and it should be
> sufficient to get the idea.

I'll modify it as following:

Example1 : NoC Probe nodes in Device Tree are listed below.

nocp_mem0_0: nocp@10CA1000 {
compatible = "samsung,exynos5420-nocp";
reg = <0x10CA1000 0x200>;
};

> 
>> diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
>> index a11720affc31..1e8b4f469f38 100644
>> --- a/drivers/devfreq/event/Kconfig
>> +++ b/drivers/devfreq/event/Kconfig
>> @@ -13,6 +13,14 @@ menuconfig PM_DEVFREQ_EVENT
>>  
>>  if PM_DEVFREQ_EVENT
>>  
>> +config DEVFREQ_EVENT_EXYNOS_NOCP
>> +bool "EXYNOS 

Re: [PATCH 1/7] PM / devfreq: event: Add new Exynos NoC probe driver

[Chanwoo Choi]

On 2016년 04월 12일 17:07, Krzysztof Kozlowski wrote:
> On 04/08/2016 07:00 AM, Chanwoo Choi wrote:
>> This patch adds NoC (Network on Chip) Probe driver which provides
>> the primitive values to get the performance data. The packets that the 
>> Network
>> on Chip (NoC) probes detects are transported over the network infrastructure.
>> Exynos542x bus has multiple NoC probes to provide bandwidth information about
>> behavior of the SoC that you can use while analyzing system performance.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  .../bindings/devfreq/event/exynos-nocp.txt |  86 +++
>>  drivers/devfreq/event/Kconfig  |   8 +
>>  drivers/devfreq/event/Makefile |   2 +
>>  drivers/devfreq/event/exynos-nocp.c| 247 
>> +
>>  drivers/devfreq/event/exynos-nocp.h|  78 +++
>>  5 files changed, 421 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
>>  create mode 100644 drivers/devfreq/event/exynos-nocp.c
>>  create mode 100644 drivers/devfreq/event/exynos-nocp.h
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt 
>> b/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
>> new file mode 100644
>> index ..03b74fed034c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
>> @@ -0,0 +1,86 @@
>> +
>> +* Samsung Exynos NoC (Network on Chip) Probe device
>> +
>> +The Samsung Exynos542x SoC has NoC (Network on Chip) Probe for NoC bus.
>> +NoC provides the primitive values to get the performance data. The packets
>> +that the Network on Chip (NoC) probes detects are transported over
>> +the network infrastructure to observer units. You can configure probes to
>> +capture packets with header or data on the data request response network,
>> +or as traffic debug or statistic collectors. Exynos542x bus has multiple
>> +NoC probes to provide bandwidth information about behavior of the SoC
>> +that you can use while analyzing system performance.
>> +
>> +Required properties:
>> +- compatible: Should be "samsung,exynos5420-nocp"
>> +- reg: physical base address of each NoC Probe and length of memory mapped 
>> region.
>> +
>> +Optional properties:
>> +- clock-names : the name of clock used by the NoC Probe, "nocp"
>> +- clocks : phandles for clock specified in "clock-names" property
>> +
>> +Example1 : NoC Probe nodes in exynos5420.dtsi are listed below.
>> +
>> +nocp_mem0_0: nocp_mem0_0@10CA1000 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x10CA1000 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_mem0_1: nocp_mem0_1@10CA1400 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x10CA1400 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_mem0_2: nocp_mem0_2@10CA1800 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x10CA1800 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_mem0_3: nocp_mem0_0@10CA1C00 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x10CA1C00 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_g3d_0: nocp_g3d_0@11A51000 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x11A51000 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +nocp_g3d_1: nocp_g3d_1@11A51400 {
>> +compatible = "samsung,exynos5420-nocp";
>> +reg = <0x11A51400 0x200>;
>> +status = "disabled";
>> +};
>> +
>> +
>> +Example2 : Events of each NoC Probe node in exynos5422-odroidxu3-common.dtsi
>> +are listed below.
>> +
>> +
>> +_mem0_0 {
>> +status = "okay";
>> +};
>> +
>> +_mem0_1 {
>> +status = "okay";
>> +};
>> +
>> +_mem0_2 {
>> +status = "okay";
>> +};
>> +
>> +_mem0_3 {
>> +status = "okay";
>> +};
>> +
>> +_g3d_0 {
>> +status = "okay";
>> +};
>> +
>> +_g3d_1 {
>> +status = "okay";
>> +};
> 
> I think this split in documentation between DTSI and DTS is not needed
> for example. Just add one example without the status and it should be
> sufficient to get the idea.

I'll modify it as following:

Example1 : NoC Probe nodes in Device Tree are listed below.

nocp_mem0_0: nocp@10CA1000 {
compatible = "samsung,exynos5420-nocp";
reg = <0x10CA1000 0x200>;
};

> 
>> diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
>> index a11720affc31..1e8b4f469f38 100644
>> --- a/drivers/devfreq/event/Kconfig
>> +++ b/drivers/devfreq/event/Kconfig
>> @@ -13,6 +13,14 @@ menuconfig PM_DEVFREQ_EVENT
>>  
>>  if PM_DEVFREQ_EVENT
>>  
>> +config DEVFREQ_EVENT_EXYNOS_NOCP
>> +bool "EXYNOS NoC (Network On Chip) 

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

[Darren Hart]

On Fri, Apr 15, 2016 at 10:18:58AM +0800, Li, Aubrey wrote:

Hi Aubrey,

>  res = platform_get_resource(pdev, IORESOURCE_MEM,
>  PLAT_RESOURCE_ISP_DATA_INDEX);
>  -   if (!res) {
>  -   dev_err(>dev, "Failed to get res of punit ISP 
>  data\n");
>  -   return -ENXIO;
>  +   ++punit_res;
>  +   if (res) {
>  +   *punit_res = *res;
>  +   dev_info(>dev, "punit ISP data res: %pR\n", res);
> >>>
> >>> Okay, what if you re-arrange this to some helper first
> >>>
> >>
> >> Thanks for the idea, but I don't like a helper here, did you see
> >> anything harmful of the current implementation?
> > 
> > In both arguments, we need to identify the WHY.
> > 
> > I imagine Andy is trying to reduce the copy and paste potential for error as
> > well as error introduction in future patches. There are... 7 or so cases 
> > with
> > near identical usage, that's a compelling argument for a refactor such as 
> > the
> > helper Andy suggests.
> > 
> > Aubrey, you said you don't like it. Why is that? Will it not save enough 
> > lines
> > of code to be worth it? Are you concerned about revalidating the change?
> 
> dev_info with different strings makes the helper useless, or more
> complex than desired if we have to write a helper here.
> 
> Also, we have necessary resource above, which returns directly if there
> is a error. For the coding style consistency in a routine, I really
> don't like we call platform_get_resource() directly at first and then
> put it into a helper later. The current implementation is
> straightforward and clean.

Both of those could be addressed with arguments, macros, etc. However, that
becomes subjective quickly, and I appreciate the incremental functional fix
here. I think this bit is fine as is.

...

>  diff --git a/drivers/platform/x86/intel_punit_ipc.c 
>  b/drivers/platform/x86/intel_punit_ipc.c
>  index bd87540..a47a41f 100644
>  --- a/drivers/platform/x86/intel_punit_ipc.c
>  +++ b/drivers/platform/x86/intel_punit_ipc.c
>  @@ -227,6 +227,11 @@ static int intel_punit_get_bars(struct 
>  platform_device *pdev)
>  struct resource *res;
>  void __iomem *addr;
> 
>  +   /*
>  +* The following resources are required
>  +* - BIOS_IPC BASE_DATA
>  +* - BIOS_IPC BASE_IFACE
>  +*/
>  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  addr = devm_ioremap_resource(>dev, res);
>  if (IS_ERR(addr))
>  @@ -239,29 +244,40 @@ static int intel_punit_get_bars(struct 
>  platform_device *pdev)
>  return PTR_ERR(addr);
>  punit_ipcdev->base[BIOS_IPC][BASE_IFACE] = addr;
> 
>  +   /*
>  +* The following resources are optional
>  +* - ISPDRIVER_IPC BASE_DATA
>  +* - ISPDRIVER_IPC BASE_IFACE
>  +* - GTDRIVER_IPC BASE_DATA
>  +* - GTDRIVER_IPC BASE_IFACE
>  +*/
>  res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
>  -   addr = devm_ioremap_resource(>dev, res);
>  -   if (IS_ERR(addr))
>  -   return PTR_ERR(addr);
>  -   punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = addr;
>  +   if (res) {
>  +   addr = devm_ioremap_resource(>dev, res);
>  +   if (!IS_ERR(addr))
>  +   punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = 
>  addr;
>  +   }
> >>>
> >>> And here, what about just replacing return to dev_warn()?
> >>
> >> I don't think we need to continue the subsequent ops if an error address
> >> returns.
> > 
> > Why is that? Will the driver fail to provide any functionality? Or could it 
> > be
> > the other IFACEs could still be of some use?
> > 
> > This one does need a justification.
> > 
> We discussed this.
> - For the necessary resources, if we obtain an error address, we should
> return immediately.
> - For the optional resources, we keep quiet if we don't get them, that
> is, not throwing a warning out.

Andy, he's checking for "res" now too, which is a good extra check since
devm_ioremap_resource will issue a dev_err "invalid resource" if it's NULL, even
though in our case, that's expected for an optional resource. This adds the
extra nesting, and a dev_warn wouldn't be appropriate for an option resource.

I'm happy to queue this to fixes at this point. Andy, are you OK with the
resolution here?


-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

[Darren Hart]

On Fri, Apr 15, 2016 at 10:18:58AM +0800, Li, Aubrey wrote:

Hi Aubrey,

>  res = platform_get_resource(pdev, IORESOURCE_MEM,
>  PLAT_RESOURCE_ISP_DATA_INDEX);
>  -   if (!res) {
>  -   dev_err(>dev, "Failed to get res of punit ISP 
>  data\n");
>  -   return -ENXIO;
>  +   ++punit_res;
>  +   if (res) {
>  +   *punit_res = *res;
>  +   dev_info(>dev, "punit ISP data res: %pR\n", res);
> >>>
> >>> Okay, what if you re-arrange this to some helper first
> >>>
> >>
> >> Thanks for the idea, but I don't like a helper here, did you see
> >> anything harmful of the current implementation?
> > 
> > In both arguments, we need to identify the WHY.
> > 
> > I imagine Andy is trying to reduce the copy and paste potential for error as
> > well as error introduction in future patches. There are... 7 or so cases 
> > with
> > near identical usage, that's a compelling argument for a refactor such as 
> > the
> > helper Andy suggests.
> > 
> > Aubrey, you said you don't like it. Why is that? Will it not save enough 
> > lines
> > of code to be worth it? Are you concerned about revalidating the change?
> 
> dev_info with different strings makes the helper useless, or more
> complex than desired if we have to write a helper here.
> 
> Also, we have necessary resource above, which returns directly if there
> is a error. For the coding style consistency in a routine, I really
> don't like we call platform_get_resource() directly at first and then
> put it into a helper later. The current implementation is
> straightforward and clean.

Both of those could be addressed with arguments, macros, etc. However, that
becomes subjective quickly, and I appreciate the incremental functional fix
here. I think this bit is fine as is.

...

>  diff --git a/drivers/platform/x86/intel_punit_ipc.c 
>  b/drivers/platform/x86/intel_punit_ipc.c
>  index bd87540..a47a41f 100644
>  --- a/drivers/platform/x86/intel_punit_ipc.c
>  +++ b/drivers/platform/x86/intel_punit_ipc.c
>  @@ -227,6 +227,11 @@ static int intel_punit_get_bars(struct 
>  platform_device *pdev)
>  struct resource *res;
>  void __iomem *addr;
> 
>  +   /*
>  +* The following resources are required
>  +* - BIOS_IPC BASE_DATA
>  +* - BIOS_IPC BASE_IFACE
>  +*/
>  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  addr = devm_ioremap_resource(>dev, res);
>  if (IS_ERR(addr))
>  @@ -239,29 +244,40 @@ static int intel_punit_get_bars(struct 
>  platform_device *pdev)
>  return PTR_ERR(addr);
>  punit_ipcdev->base[BIOS_IPC][BASE_IFACE] = addr;
> 
>  +   /*
>  +* The following resources are optional
>  +* - ISPDRIVER_IPC BASE_DATA
>  +* - ISPDRIVER_IPC BASE_IFACE
>  +* - GTDRIVER_IPC BASE_DATA
>  +* - GTDRIVER_IPC BASE_IFACE
>  +*/
>  res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
>  -   addr = devm_ioremap_resource(>dev, res);
>  -   if (IS_ERR(addr))
>  -   return PTR_ERR(addr);
>  -   punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = addr;
>  +   if (res) {
>  +   addr = devm_ioremap_resource(>dev, res);
>  +   if (!IS_ERR(addr))
>  +   punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = 
>  addr;
>  +   }
> >>>
> >>> And here, what about just replacing return to dev_warn()?
> >>
> >> I don't think we need to continue the subsequent ops if an error address
> >> returns.
> > 
> > Why is that? Will the driver fail to provide any functionality? Or could it 
> > be
> > the other IFACEs could still be of some use?
> > 
> > This one does need a justification.
> > 
> We discussed this.
> - For the necessary resources, if we obtain an error address, we should
> return immediately.
> - For the optional resources, we keep quiet if we don't get them, that
> is, not throwing a warning out.

Andy, he's checking for "res" now too, which is a good extra check since
devm_ioremap_resource will issue a dev_err "invalid resource" if it's NULL, even
though in our case, that's expected for an optional resource. This adds the
extra nesting, and a dev_warn wouldn't be appropriate for an option resource.

I'm happy to queue this to fixes at this point. Andy, are you OK with the
resolution here?


-- 
Darren Hart
Intel Open Source Technology Center

linux-next: Tree for Apr 15

[Stephen Rothwell]

Hi all,

Changes since 20160414:

The tip tree still had its build failure for which I reverted a commit.

The akpm-current tree still had its build failure for which I applied
a patch.

Non-merge commits (relative to Linus' tree): 3999
 3724 files changed, 148813 insertions(+), 87018 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (90de6800c240 Merge tag 'sh-fixes-4.6-rc1' of 
git://git.libc.org/linux-sh)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (d01ebf06e305 ARCv2: Enable LOCKDEP)
Merging arm-current/fixes (208fae5c3b94 ARM: 8550/1: protect idiv patching 
against undefined gcc behavior)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (b4dfd8e92956 bgmac: reset & enable Ethernet core before 
using it)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (c44da62b55bb ALSA: hda - Fix inconsistent 
monitor_present state until repoll)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (dea5c24a1404 lib: lz4: cleanup 
unaligned access efficiency detection)
Merging tty.current/tty-linus (bf1620068911 Linux 4.6-rc3)
Merging usb.current/usb-linus (e86103a75705 usb: hcd: out of bounds access in 
for_each_companion)
Merging usb-gadget-fixes/fixes (bf1620068911 Linux 4.6-rc3)
Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (053f78d35995 Merge tag 
'lkdtm-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 
into char-misc-linus)
Merging input-current/for-linus (7eb5ca09e48e Input: clarify we want 
BTN_TOOL_ on proximity)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftest-fixes/fi

linux-next: Tree for Apr 15

[Stephen Rothwell]

Hi all,

Changes since 20160414:

The tip tree still had its build failure for which I reverted a commit.

The akpm-current tree still had its build failure for which I applied
a patch.

Non-merge commits (relative to Linus' tree): 3999
 3724 files changed, 148813 insertions(+), 87018 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (90de6800c240 Merge tag 'sh-fixes-4.6-rc1' of 
git://git.libc.org/linux-sh)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (d01ebf06e305 ARCv2: Enable LOCKDEP)
Merging arm-current/fixes (208fae5c3b94 ARM: 8550/1: protect idiv patching 
against undefined gcc behavior)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (b4dfd8e92956 bgmac: reset & enable Ethernet core before 
using it)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (c44da62b55bb ALSA: hda - Fix inconsistent 
monitor_present state until repoll)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (dea5c24a1404 lib: lz4: cleanup 
unaligned access efficiency detection)
Merging tty.current/tty-linus (bf1620068911 Linux 4.6-rc3)
Merging usb.current/usb-linus (e86103a75705 usb: hcd: out of bounds access in 
for_each_companion)
Merging usb-gadget-fixes/fixes (bf1620068911 Linux 4.6-rc3)
Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (053f78d35995 Merge tag 
'lkdtm-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 
into char-misc-linus)
Merging input-current/for-linus (7eb5ca09e48e Input: clarify we want 
BTN_TOOL_ on proximity)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftest-fixes/fi

Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support

[Kees Cook]

On Thu, Apr 14, 2016 at 9:08 PM, Baoquan He  wrote:
> On 04/14/16 at 10:56am, Kees Cook wrote:
>> On Thu, Apr 14, 2016 at 8:06 AM, Baoquan He  wrote:
>> > On 04/13/16 at 11:02pm, Kees Cook wrote:
>> >> On Wed, Apr 13, 2016 at 7:11 AM, Kees Cook  wrote:
>> >> > On Wed, Apr 13, 2016 at 3:19 AM, Ingo Molnar  wrote:
>> >> >>
>> >> >> * Kees Cook  wrote:
>> >> >>
>> >> >>> FWIW, I've also had this tree up in my git branches, and the 0day
>> >> >>> tester hasn't complained at all about it in the last two weeks. I'd
>> >> >>> really like to see this in -next to fix the >4G (mainly kexec) issues
>> >> >>> and get us to feature parity with the arm64 kASLR work (randomized
>> >> >>> virtual address).
>> >>
>> >> So, I've done this and suddenly realized I hadn't boot-tested i386. It
>> >> doesn't work, unfortunately. (Which I find strange: I'd expect 0day to
>> >> have noticed...)
>> >>
>> >> Baoquan, have you tested this on 32-bit systems? I get a variety of
>> >> failures. Either it boots okay, it reboots, or I get tons of pte
>> >> errors like this:
>> >
>> > Hi Kees,
>> >
>> > I am sorry I didn't notice the change impacts i386. I got a i386 machine
>> > and had tests. Found i386 can't take separate randomzation since there's
>> > difference between i386 and x86_64.
>> >
>> > x86_64 has phys_base and can translate virt addr and phys addr according
>> > to below formula:
>> >
>> > paddr = vaddr - __START_KERNEL_map + phys_base;
>> >
>> > However i386 can only do like this:
>> >
>> > paddr = vaddr - PAGE_OFFSET;
>> >
>> > Besides i386 has to reserve 128M for VMALLOC at the end of kernel
>> > virtual address. So for i386 area 768M is the upper limit for
>> > randomization. But I am fine with the KERNEL_IMAGE_SIZE, the old default
>> > value. What do you say about this?
>> >
>> > So the plan should be keeping the old style of randomization for i386
>> > system:
>> >
>> > 1) Disable virtual address randomization in i386 case because it's
>> > useless. This should be done in patch:
>> >  x86, KASLR: Randomize virtual address separately
>> >
>> > 2) Add an upper limit for physical randomization if it's i386 system.
>> >  x86, KASLR: Add physical address randomization >4G
>> >
>> > I just got a test machine in office, and haven't had time to change
>> > code. You can change it directly, or I will do it tomorrow.
>>
>> I was thinking about the physical vs virtual on i386 as I woke up
>> today. :) Thanks for confirming! These changes appear to make the
>> series boot reliably on i386 (pardon any gmail-induced whitespace
>> damage...):
>>
>> diff --git a/arch/x86/boot/compressed/aslr.c 
>> b/arch/x86/boot/compressed/aslr.c
>> index 5bae54b50d4c..3a58fe8acb8e 100644
>> --- a/arch/x86/boot/compressed/aslr.c
>> +++ b/arch/x86/boot/compressed/aslr.c
>> @@ -347,6 +347,10 @@ static void process_e820_entry(struct e820entry *entry,
>> if (entry->type != E820_RAM)
>> return;
>>
>> +   /* On 32-bit, ignore entries entirely above our maximum. */
>> +   if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
>> +   return;
>> +
>> /* Ignore entries entirely below our minimum. */
>> if (entry->addr + entry->size < minimum)
>> return;
>> @@ -372,6 +376,11 @@ static void process_e820_entry(struct e820entry *entry,
>> /* Reduce size by any delta from the original address. */
>> region.size -= region.start - start_orig;
>>
>> +   /* On 32-bit, reduce region size to fit within max size. */
>> +   if (IS_ENABLED(CONFIG_X86_32) &&
>> +   region.start + region.size > KERNEL_IMAGE_SIZE)
>> +   region.size = KERNEL_IMAGE_SIZE - region.start;
>> +
>> /* Return if region can't contain decompressed kernel */
>> if (region.size < image_size)
>> return;
>> @@ -488,6 +497,8 @@ void choose_kernel_location(unsigned char *input,
>> }
>>
>> /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */
>> -   random = find_random_virt_offset(LOAD_PHYSICAL_ADDR, output_size);
>> +   if (IS_ENABLED(CONFIG_X86_64))
>> +   random = find_random_virt_offset(LOAD_PHYSICAL_ADDR,
>> +output_size);
>> *virt_offset = (unsigned char *)random;
>>  }
>>
>>
>> I will split these chunks up into the correct patches and resend the
>> series. If you get a chance, can you double-check this?
>
> Yes, these changes sounds great. I checked the series you posted, and
> have to say you make them look much better. The change logs are perfect
> and great code refactoring. Just one little bit thing, here:
>
> [kees: rewrote changelog, refactored goto into while, limit 32-bit to 1G]
> in patch [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G
>

Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support

[Kees Cook]

On Thu, Apr 14, 2016 at 9:08 PM, Baoquan He  wrote:
> On 04/14/16 at 10:56am, Kees Cook wrote:
>> On Thu, Apr 14, 2016 at 8:06 AM, Baoquan He  wrote:
>> > On 04/13/16 at 11:02pm, Kees Cook wrote:
>> >> On Wed, Apr 13, 2016 at 7:11 AM, Kees Cook  wrote:
>> >> > On Wed, Apr 13, 2016 at 3:19 AM, Ingo Molnar  wrote:
>> >> >>
>> >> >> * Kees Cook  wrote:
>> >> >>
>> >> >>> FWIW, I've also had this tree up in my git branches, and the 0day
>> >> >>> tester hasn't complained at all about it in the last two weeks. I'd
>> >> >>> really like to see this in -next to fix the >4G (mainly kexec) issues
>> >> >>> and get us to feature parity with the arm64 kASLR work (randomized
>> >> >>> virtual address).
>> >>
>> >> So, I've done this and suddenly realized I hadn't boot-tested i386. It
>> >> doesn't work, unfortunately. (Which I find strange: I'd expect 0day to
>> >> have noticed...)
>> >>
>> >> Baoquan, have you tested this on 32-bit systems? I get a variety of
>> >> failures. Either it boots okay, it reboots, or I get tons of pte
>> >> errors like this:
>> >
>> > Hi Kees,
>> >
>> > I am sorry I didn't notice the change impacts i386. I got a i386 machine
>> > and had tests. Found i386 can't take separate randomzation since there's
>> > difference between i386 and x86_64.
>> >
>> > x86_64 has phys_base and can translate virt addr and phys addr according
>> > to below formula:
>> >
>> > paddr = vaddr - __START_KERNEL_map + phys_base;
>> >
>> > However i386 can only do like this:
>> >
>> > paddr = vaddr - PAGE_OFFSET;
>> >
>> > Besides i386 has to reserve 128M for VMALLOC at the end of kernel
>> > virtual address. So for i386 area 768M is the upper limit for
>> > randomization. But I am fine with the KERNEL_IMAGE_SIZE, the old default
>> > value. What do you say about this?
>> >
>> > So the plan should be keeping the old style of randomization for i386
>> > system:
>> >
>> > 1) Disable virtual address randomization in i386 case because it's
>> > useless. This should be done in patch:
>> >  x86, KASLR: Randomize virtual address separately
>> >
>> > 2) Add an upper limit for physical randomization if it's i386 system.
>> >  x86, KASLR: Add physical address randomization >4G
>> >
>> > I just got a test machine in office, and haven't had time to change
>> > code. You can change it directly, or I will do it tomorrow.
>>
>> I was thinking about the physical vs virtual on i386 as I woke up
>> today. :) Thanks for confirming! These changes appear to make the
>> series boot reliably on i386 (pardon any gmail-induced whitespace
>> damage...):
>>
>> diff --git a/arch/x86/boot/compressed/aslr.c 
>> b/arch/x86/boot/compressed/aslr.c
>> index 5bae54b50d4c..3a58fe8acb8e 100644
>> --- a/arch/x86/boot/compressed/aslr.c
>> +++ b/arch/x86/boot/compressed/aslr.c
>> @@ -347,6 +347,10 @@ static void process_e820_entry(struct e820entry *entry,
>> if (entry->type != E820_RAM)
>> return;
>>
>> +   /* On 32-bit, ignore entries entirely above our maximum. */
>> +   if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
>> +   return;
>> +
>> /* Ignore entries entirely below our minimum. */
>> if (entry->addr + entry->size < minimum)
>> return;
>> @@ -372,6 +376,11 @@ static void process_e820_entry(struct e820entry *entry,
>> /* Reduce size by any delta from the original address. */
>> region.size -= region.start - start_orig;
>>
>> +   /* On 32-bit, reduce region size to fit within max size. */
>> +   if (IS_ENABLED(CONFIG_X86_32) &&
>> +   region.start + region.size > KERNEL_IMAGE_SIZE)
>> +   region.size = KERNEL_IMAGE_SIZE - region.start;
>> +
>> /* Return if region can't contain decompressed kernel */
>> if (region.size < image_size)
>> return;
>> @@ -488,6 +497,8 @@ void choose_kernel_location(unsigned char *input,
>> }
>>
>> /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */
>> -   random = find_random_virt_offset(LOAD_PHYSICAL_ADDR, output_size);
>> +   if (IS_ENABLED(CONFIG_X86_64))
>> +   random = find_random_virt_offset(LOAD_PHYSICAL_ADDR,
>> +output_size);
>> *virt_offset = (unsigned char *)random;
>>  }
>>
>>
>> I will split these chunks up into the correct patches and resend the
>> series. If you get a chance, can you double-check this?
>
> Yes, these changes sounds great. I checked the series you posted, and
> have to say you make them look much better. The change logs are perfect
> and great code refactoring. Just one little bit thing, here:
>
> [kees: rewrote changelog, refactored goto into while, limit 32-bit to 1G]
> in patch [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G
>
> In i386 KERNEL_IMAGE_SIZE is kept to be 0x2000, namely 512M, w/o kaslr
> enabled. So here I 

Re: [PATCH] fujitsu-laptop: Support radio LED

[Darren Hart]

On Tue, Apr 12, 2016 at 10:06:34PM +0930, Jonathan Woithe wrote:
> Hi Darren
> 
> On Sun, Apr 10, 2016 at 08:22:58PM +0930, Jonathan Woithe wrote:
> > On Sat, Apr 09, 2016 at 07:30:20PM -0700, Darren Hart wrote:
> > > Jonathan, Micha??,
> > > 
> > > Where are we with this? The above reads as "Doesn't appear to break 
> > > existing
> > > systems on hand". Jonathan, are you happy with this patch?
> > 
> > Sorry, I got caught up over the last couple of weeks with other tasks and
> > have not yet managed to confirm the lack of regressions on the S7020.  It
> > was on my list for this coming week though.  My comments quoted above were
> > theoretical rather than based on an actual test.  The patch appears fairly
> > innoculous given that BTNI bit 24 is not set on the S7020 but for
> > completeness I would prefer to give it a run on the S7020 before we merge
> > the patch.  I will make an effort to fit this in over the next couple of
> > days.
> 
> I have now tested the patch on the S7020 and unsurprisingly I have not
> observed any regressions.  I'm therefore happy to take the patch more or
> less as is.  However, I would like to see a brief comment in
> acpi_fujitsu_hotkey_add() about the use of bit 24 in BTNI to determine
> whether the LED handler should be registered since the reasoning is not
> obvious and is not evident from the code.  A copy of the original patch with
> such a comment inserted (no code changes) is below.
> 
> Signed-off-by: Michał Kępień 

Jonathan, please check your character set, a few mangled characters here which I
have to fix up to use. UTF-8 seems to work reliably.

Your headers currently include:
Content-Type: text/plain; charset=iso-8859-1

> Acked-by: Jonathan Woithe 
> 
> Michał hasn't indicated that a revised patch is in the works so I'm fine if
> you proceed with the one below.  I've selected the relevant parts of his
> preamble for inclusion in the commit message, but feel free to edit further
> to your taste.
> 

Yeah, tough call, some guess work involved here, and where we are uncertain, we
should document it. I don't think we need to include bits about uncertain future
plans or speculation on how things might be done. Keep it to what this patch
does and any qualifiers a developer should be aware of.

I've made a couple cosmetic changes and queued to for-next. Please review and
let me know if you have any concerns.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] fujitsu-laptop: Support radio LED

[Darren Hart]

On Tue, Apr 12, 2016 at 10:06:34PM +0930, Jonathan Woithe wrote:
> Hi Darren
> 
> On Sun, Apr 10, 2016 at 08:22:58PM +0930, Jonathan Woithe wrote:
> > On Sat, Apr 09, 2016 at 07:30:20PM -0700, Darren Hart wrote:
> > > Jonathan, Micha??,
> > > 
> > > Where are we with this? The above reads as "Doesn't appear to break 
> > > existing
> > > systems on hand". Jonathan, are you happy with this patch?
> > 
> > Sorry, I got caught up over the last couple of weeks with other tasks and
> > have not yet managed to confirm the lack of regressions on the S7020.  It
> > was on my list for this coming week though.  My comments quoted above were
> > theoretical rather than based on an actual test.  The patch appears fairly
> > innoculous given that BTNI bit 24 is not set on the S7020 but for
> > completeness I would prefer to give it a run on the S7020 before we merge
> > the patch.  I will make an effort to fit this in over the next couple of
> > days.
> 
> I have now tested the patch on the S7020 and unsurprisingly I have not
> observed any regressions.  I'm therefore happy to take the patch more or
> less as is.  However, I would like to see a brief comment in
> acpi_fujitsu_hotkey_add() about the use of bit 24 in BTNI to determine
> whether the LED handler should be registered since the reasoning is not
> obvious and is not evident from the code.  A copy of the original patch with
> such a comment inserted (no code changes) is below.
> 
> Signed-off-by: Michał Kępień 

Jonathan, please check your character set, a few mangled characters here which I
have to fix up to use. UTF-8 seems to work reliably.

Your headers currently include:
Content-Type: text/plain; charset=iso-8859-1

> Acked-by: Jonathan Woithe 
> 
> Michał hasn't indicated that a revised patch is in the works so I'm fine if
> you proceed with the one below.  I've selected the relevant parts of his
> preamble for inclusion in the commit message, but feel free to edit further
> to your taste.
> 

Yeah, tough call, some guess work involved here, and where we are uncertain, we
should document it. I don't think we need to include bits about uncertain future
plans or speculation on how things might be done. Keep it to what this patch
does and any qualifiers a developer should be aware of.

I've made a couple cosmetic changes and queued to for-next. Please review and
let me know if you have any concerns.

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH V2] regulator: pv88080: new regulator driver

[James Bans]

From: James Ban 

This is the driver for the Powerventure PV88080 BUCKs regulator.
It communicates via an I2C bus to the device.

Signed-off-by: James Ban 

---
Changes since PATCH V1
- Removed unnecessary array.
- Added detault case.

This patch applies against linux-next and next-20160413 


 .../devicetree/bindings/regulator/pv88080.txt  |   49 +++
 drivers/regulator/Kconfig  |7 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/pv88080-regulator.c  |  419 
 drivers/regulator/pv88080-regulator.h  |   92 +
 5 files changed, 568 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/pv88080.txt
 create mode 100644 drivers/regulator/pv88080-regulator.c
 create mode 100644 drivers/regulator/pv88080-regulator.h

diff --git a/Documentation/devicetree/bindings/regulator/pv88080.txt 
b/Documentation/devicetree/bindings/regulator/pv88080.txt
new file mode 100644
index 000..38a6142
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pv88080.txt
@@ -0,0 +1,49 @@
+* Powerventure Semiconductor PV88080 Voltage Regulator
+
+Required properties:
+- compatible: "pvs,pv88080".
+- reg: I2C slave address, usually 0x49.
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+  device. Each sub-node is identified using the node's name, with valid
+  values listed below. The content of each sub-node is defined by the
+  standard binding for regulators; see regulator.txt.
+  BUCK1, BUCK2, and BUCK3.
+
+Optional properties:
+- Any optional property defined in regulator.txt
+
+Example
+
+   pmic: pv88080@49 {
+   compatible = "pvs,pv88080";
+   reg = <0x49>;
+   interrupt-parent = <>;
+   interrupts = <24 24>;
+
+   regulators {
+   BUCK1 {
+   regulator-name = "buck1";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = < 22>;
+   regulator-max-microamp  = <704>;
+   };
+
+   BUCK2 {
+   regulator-name = "buck2";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   };
+
+   BUCK3 {
+   regulator-name = "buck3";
+   regulator-min-microvolt = <140>;
+   regulator-max-microvolt = <2193750>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   };
+   };
+   };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c77dc08..0b616e2 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -548,6 +548,13 @@ config REGULATOR_PV88060
  Say y here to support the voltage regulators and convertors
  PV88060
 
+config REGULATOR_PV88080
+   tristate "Powerventure Semiconductor PV88080 regulator"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ Say y here to support the buck convertors on PV88080
+
 config REGULATOR_PV88090
tristate "Powerventure Semiconductor PV88090 regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 8018b2e..22388c2 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
+obj-$(CONFIG_REGULATOR_PV88080) += pv88080-regulator.o
 obj-$(CONFIG_REGULATOR_PV88090) += pv88090-regulator.o
 obj-$(CONFIG_REGULATOR_PWM) += pwm-regulator.o
 obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
diff --git a/drivers/regulator/pv88080-regulator.c 
b/drivers/regulator/pv88080-regulator.c
new file mode 100644
index 000..d710756
--- /dev/null
+++ b/drivers/regulator/pv88080-regulator.c
@@ -0,0 +1,419 @@
+/*
+ * pv88080-regulator.c - Regulator device driver for PV88080
+ * Copyright (C) 2016  Powerventure Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ 

[PATCH V2] regulator: pv88080: new regulator driver

[James Bans]

From: James Ban 

This is the driver for the Powerventure PV88080 BUCKs regulator.
It communicates via an I2C bus to the device.

Signed-off-by: James Ban 

---
Changes since PATCH V1
- Removed unnecessary array.
- Added detault case.

This patch applies against linux-next and next-20160413 


 .../devicetree/bindings/regulator/pv88080.txt  |   49 +++
 drivers/regulator/Kconfig  |7 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/pv88080-regulator.c  |  419 
 drivers/regulator/pv88080-regulator.h  |   92 +
 5 files changed, 568 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/pv88080.txt
 create mode 100644 drivers/regulator/pv88080-regulator.c
 create mode 100644 drivers/regulator/pv88080-regulator.h

diff --git a/Documentation/devicetree/bindings/regulator/pv88080.txt 
b/Documentation/devicetree/bindings/regulator/pv88080.txt
new file mode 100644
index 000..38a6142
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pv88080.txt
@@ -0,0 +1,49 @@
+* Powerventure Semiconductor PV88080 Voltage Regulator
+
+Required properties:
+- compatible: "pvs,pv88080".
+- reg: I2C slave address, usually 0x49.
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+  device. Each sub-node is identified using the node's name, with valid
+  values listed below. The content of each sub-node is defined by the
+  standard binding for regulators; see regulator.txt.
+  BUCK1, BUCK2, and BUCK3.
+
+Optional properties:
+- Any optional property defined in regulator.txt
+
+Example
+
+   pmic: pv88080@49 {
+   compatible = "pvs,pv88080";
+   reg = <0x49>;
+   interrupt-parent = <>;
+   interrupts = <24 24>;
+
+   regulators {
+   BUCK1 {
+   regulator-name = "buck1";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = < 22>;
+   regulator-max-microamp  = <704>;
+   };
+
+   BUCK2 {
+   regulator-name = "buck2";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   };
+
+   BUCK3 {
+   regulator-name = "buck3";
+   regulator-min-microvolt = <140>;
+   regulator-max-microvolt = <2193750>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   };
+   };
+   };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c77dc08..0b616e2 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -548,6 +548,13 @@ config REGULATOR_PV88060
  Say y here to support the voltage regulators and convertors
  PV88060
 
+config REGULATOR_PV88080
+   tristate "Powerventure Semiconductor PV88080 regulator"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ Say y here to support the buck convertors on PV88080
+
 config REGULATOR_PV88090
tristate "Powerventure Semiconductor PV88090 regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 8018b2e..22388c2 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
+obj-$(CONFIG_REGULATOR_PV88080) += pv88080-regulator.o
 obj-$(CONFIG_REGULATOR_PV88090) += pv88090-regulator.o
 obj-$(CONFIG_REGULATOR_PWM) += pwm-regulator.o
 obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
diff --git a/drivers/regulator/pv88080-regulator.c 
b/drivers/regulator/pv88080-regulator.c
new file mode 100644
index 000..d710756
--- /dev/null
+++ b/drivers/regulator/pv88080-regulator.c
@@ -0,0 +1,419 @@
+/*
+ * pv88080-regulator.c - Regulator device driver for PV88080
+ * Copyright (C) 2016  Powerventure Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This 

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

This contains fixes for exynos, amdgpu, radeon, i915 and qxl.

It also contains some fixes to the core drm edid parser.

The qxl fix for a cursor hotspot issue, and the radeon are some
MST fixes that I've been running locally and make my monitor a bit
happier.

The exynos ones fix some regressions and build fixes.

amdgpu has a couple of small fixes.

and i915 has two DP MST fixes and a couple of other regression fixes.

Nothing to out of the ordinary or surprising at this point.

Dave.

The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb:

  Linux 4.6-rc3 (2016-04-10 17:58:30 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to ff3e84e8e479c3ba7148f8dc35a56cf091ab56d9:

  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes 
(2016-04-14 13:06:19 +1000)


Andrzej Hajda (2):
  drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
  drm/exynos: build fbdev code conditionally

Arnd Bergmann (1):
  drm/exynos: fix error handling in exynos_drm_subdrv_open

Bjørn Mork (1):
  drm/i915: fix deadlock on lid open

Chris Wilson (1):
  drm/i915: Exit cherryview_irq_handler() after one pass

Chunming Zhou (1):
  drm/amdgpu: add invisible pin size statistic

Dan Carpenter (2):
  drm/exynos: mic: fix an error code
  drm/exynos: fix a warning message

Dave Airlie (6):
  drm/radeon/mst: port some MST setup code from DAL.
  drm/radeon: use helper for mst connector dpms.
  Merge tag 'topic/drm-fixes-2016-04-07' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge tag 'drm-intel-fixes-2016-04-07' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Javier Martinez Canillas (1):
  drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency

John Keeping (1):
  drm/qxl: fix cursor position with non-zero hotspot

Junwei Zhang (1):
  drm/amd/amdgpu: fix irq domain remove for tonga ih

Lyude (2):
  drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
  drm/i915: Call intel_dp_mst_resume() before resuming displays

Marek Szyprowski (1):
  drm/exynos: fimd: fix broken dp_clock control

Paul Parsons (3):
  drm/edid: Fix EDID Established Timings I and II
  drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor
  drm/edid: Fix DMT 1024x768@43Hz (interlaced) timings

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 12 
 drivers/gpu/drm/amd/amdgpu/tonga_ih.c  |  2 +-
 drivers/gpu/drm/drm_edid.c | 10 +-
 drivers/gpu/drm/exynos/Kconfig |  2 +-
 drivers/gpu/drm/exynos/Makefile|  6 +++---
 drivers/gpu/drm/exynos/exynos_drm_core.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 11 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  | 11 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h  | 23 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_mic.c|  3 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c  | 12 +++-
 drivers/gpu/drm/i915/i915_drv.c|  4 ++--
 drivers/gpu/drm/i915/i915_irq.c|  4 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c|  6 ++
 drivers/gpu/drm/i915/intel_lvds.c  |  5 +
 drivers/gpu/drm/qxl/qxl_display.c  | 13 +
 drivers/gpu/drm/qxl/qxl_drv.h  |  2 ++
 drivers/gpu/drm/radeon/ni_reg.h|  2 ++
 drivers/gpu/drm/radeon/radeon_dp_mst.c | 31 +++---
 22 files changed, 104 insertions(+), 62 deletions(-)

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

This contains fixes for exynos, amdgpu, radeon, i915 and qxl.

It also contains some fixes to the core drm edid parser.

The qxl fix for a cursor hotspot issue, and the radeon are some
MST fixes that I've been running locally and make my monitor a bit
happier.

The exynos ones fix some regressions and build fixes.

amdgpu has a couple of small fixes.

and i915 has two DP MST fixes and a couple of other regression fixes.

Nothing to out of the ordinary or surprising at this point.

Dave.

The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb:

  Linux 4.6-rc3 (2016-04-10 17:58:30 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to ff3e84e8e479c3ba7148f8dc35a56cf091ab56d9:

  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes 
(2016-04-14 13:06:19 +1000)


Andrzej Hajda (2):
  drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
  drm/exynos: build fbdev code conditionally

Arnd Bergmann (1):
  drm/exynos: fix error handling in exynos_drm_subdrv_open

Bjørn Mork (1):
  drm/i915: fix deadlock on lid open

Chris Wilson (1):
  drm/i915: Exit cherryview_irq_handler() after one pass

Chunming Zhou (1):
  drm/amdgpu: add invisible pin size statistic

Dan Carpenter (2):
  drm/exynos: mic: fix an error code
  drm/exynos: fix a warning message

Dave Airlie (6):
  drm/radeon/mst: port some MST setup code from DAL.
  drm/radeon: use helper for mst connector dpms.
  Merge tag 'topic/drm-fixes-2016-04-07' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge tag 'drm-intel-fixes-2016-04-07' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Javier Martinez Canillas (1):
  drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency

John Keeping (1):
  drm/qxl: fix cursor position with non-zero hotspot

Junwei Zhang (1):
  drm/amd/amdgpu: fix irq domain remove for tonga ih

Lyude (2):
  drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
  drm/i915: Call intel_dp_mst_resume() before resuming displays

Marek Szyprowski (1):
  drm/exynos: fimd: fix broken dp_clock control

Paul Parsons (3):
  drm/edid: Fix EDID Established Timings I and II
  drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor
  drm/edid: Fix DMT 1024x768@43Hz (interlaced) timings

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 12 
 drivers/gpu/drm/amd/amdgpu/tonga_ih.c  |  2 +-
 drivers/gpu/drm/drm_edid.c | 10 +-
 drivers/gpu/drm/exynos/Kconfig |  2 +-
 drivers/gpu/drm/exynos/Makefile|  6 +++---
 drivers/gpu/drm/exynos/exynos_drm_core.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 11 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  | 11 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h  | 23 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_mic.c|  3 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c  | 12 +++-
 drivers/gpu/drm/i915/i915_drv.c|  4 ++--
 drivers/gpu/drm/i915/i915_irq.c|  4 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c|  6 ++
 drivers/gpu/drm/i915/intel_lvds.c  |  5 +
 drivers/gpu/drm/qxl/qxl_display.c  | 13 +
 drivers/gpu/drm/qxl/qxl_drv.h  |  2 ++
 drivers/gpu/drm/radeon/ni_reg.h|  2 ++
 drivers/gpu/drm/radeon/radeon_dp_mst.c | 31 +++---
 22 files changed, 104 insertions(+), 62 deletions(-)

Re: [-next] BUG_ON in scsi_target_destroy()

[Xiong Zhou]

Hi,

On Wed, Apr 13, 2016 at 4:41 PM, Johannes Thumshirn  wrote:
> Hi Sergey,  Xiong,
>
> Can you try below patch?

This survives modprobe -r scsi_debug.

>
> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
>> Hello,
>>
>> commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
>> Author: Johannes Thumshirn 
>> Date:   Tue Apr 5 11:50:44 2016 +0200
>>
>> scsi: Add intermediate STARGET_REMOVE state to scsi_target_state
>>
>>
>> BUG_ON()s (next-20160411) each time I remove a usb flash
>>
>> [   49.561600]  [] scsi_target_destroy+0x5a/0xcb [scsi_mod]
>> [   49.561607]  [] scsi_target_reap+0x4a/0x4f [scsi_mod]
>> [   49.561613]  [] __scsi_remove_device+0xc3/0xd0 
>> [scsi_mod]
>> [   49.561619]  [] scsi_forget_host+0x52/0x63 [scsi_mod]
>> [   49.561623]  [] scsi_remove_host+0x8c/0x102 [scsi_mod]
>> [   49.561627]  [] usb_stor_disconnect+0x6b/0xab 
>> [usb_storage]
>> [   49.561634]  [] usb_unbind_interface+0x77/0x1ca 
>> [usbcore]
>> [   49.561636]  [] __device_release_driver+0x9d/0x121
>> [   49.561638]  [] device_release_driver+0x23/0x30
>> [   49.561639]  [] bus_remove_device+0xfb/0x10e
>> [   49.561641]  [] device_del+0x164/0x1e6
>> [   49.561648]  [] ? remove_intf_ep_devs+0x3b/0x48 
>> [usbcore]
>> [   49.561655]  [] usb_disable_device+0x84/0x1a5 [usbcore]
>> [   49.561661]  [] usb_disconnect+0x94/0x19f [usbcore]
>> [   49.561667]  [] hub_event+0x5c1/0xdea [usbcore]
>> [   49.561670]  [] process_one_work+0x1dc/0x37f
>> [   49.561672]  [] worker_thread+0x282/0x36d
>> [   49.561673]  [] ? rescuer_thread+0x2ae/0x2ae
>> [   49.561675]  [] kthread+0xd2/0xda
>> [   49.561678]  [] ret_from_fork+0x22/0x40
>> [   49.561679]  [] ? kthread_worker_fn+0x13e/0x13e
>>
>>   -ss
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 0734927..0c00928 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
>  void __scsi_remove_device(struct scsi_device *sdev)
>  {
> struct device *dev = >sdev_gendev;
> +   struct scsi_target *starget;
>
> /*
>  * This cleanup path is not reentrant and while it is impossible
> @@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device *sdev)
>  * remoed sysfs visibility from the device, so make the target
>  * invisible if this was the last device underneath it.
>  */
> -   scsi_target_reap(scsi_target(sdev));
> +   starget = scsi_target(sdev);
> +   starget->state = STARGET_REMOVE;
> +   scsi_target_reap(starget);

Yes, scsi_target_reap is alse called from __scsi_remove_device,  and ->state is
_RUNNING here.


>
> put_device(dev);
>  }
>
>
>
> --
> Johannes Thumshirn
> Storage
> jthumsh...@suse.de
>  +49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
>

Re: [-next] BUG_ON in scsi_target_destroy()

[Xiong Zhou]

Hi,

On Wed, Apr 13, 2016 at 4:41 PM, Johannes Thumshirn  wrote:
> Hi Sergey,  Xiong,
>
> Can you try below patch?

This survives modprobe -r scsi_debug.

>
> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
>> Hello,
>>
>> commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
>> Author: Johannes Thumshirn 
>> Date:   Tue Apr 5 11:50:44 2016 +0200
>>
>> scsi: Add intermediate STARGET_REMOVE state to scsi_target_state
>>
>>
>> BUG_ON()s (next-20160411) each time I remove a usb flash
>>
>> [   49.561600]  [] scsi_target_destroy+0x5a/0xcb [scsi_mod]
>> [   49.561607]  [] scsi_target_reap+0x4a/0x4f [scsi_mod]
>> [   49.561613]  [] __scsi_remove_device+0xc3/0xd0 
>> [scsi_mod]
>> [   49.561619]  [] scsi_forget_host+0x52/0x63 [scsi_mod]
>> [   49.561623]  [] scsi_remove_host+0x8c/0x102 [scsi_mod]
>> [   49.561627]  [] usb_stor_disconnect+0x6b/0xab 
>> [usb_storage]
>> [   49.561634]  [] usb_unbind_interface+0x77/0x1ca 
>> [usbcore]
>> [   49.561636]  [] __device_release_driver+0x9d/0x121
>> [   49.561638]  [] device_release_driver+0x23/0x30
>> [   49.561639]  [] bus_remove_device+0xfb/0x10e
>> [   49.561641]  [] device_del+0x164/0x1e6
>> [   49.561648]  [] ? remove_intf_ep_devs+0x3b/0x48 
>> [usbcore]
>> [   49.561655]  [] usb_disable_device+0x84/0x1a5 [usbcore]
>> [   49.561661]  [] usb_disconnect+0x94/0x19f [usbcore]
>> [   49.561667]  [] hub_event+0x5c1/0xdea [usbcore]
>> [   49.561670]  [] process_one_work+0x1dc/0x37f
>> [   49.561672]  [] worker_thread+0x282/0x36d
>> [   49.561673]  [] ? rescuer_thread+0x2ae/0x2ae
>> [   49.561675]  [] kthread+0xd2/0xda
>> [   49.561678]  [] ret_from_fork+0x22/0x40
>> [   49.561679]  [] ? kthread_worker_fn+0x13e/0x13e
>>
>>   -ss
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 0734927..0c00928 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1276,6 +1276,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
>  void __scsi_remove_device(struct scsi_device *sdev)
>  {
> struct device *dev = >sdev_gendev;
> +   struct scsi_target *starget;
>
> /*
>  * This cleanup path is not reentrant and while it is impossible
> @@ -1315,7 +1316,9 @@ void __scsi_remove_device(struct scsi_device *sdev)
>  * remoed sysfs visibility from the device, so make the target
>  * invisible if this was the last device underneath it.
>  */
> -   scsi_target_reap(scsi_target(sdev));
> +   starget = scsi_target(sdev);
> +   starget->state = STARGET_REMOVE;
> +   scsi_target_reap(starget);

Yes, scsi_target_reap is alse called from __scsi_remove_device,  and ->state is
_RUNNING here.


>
> put_device(dev);
>  }
>
>
>
> --
> Johannes Thumshirn
> Storage
> jthumsh...@suse.de
>  +49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
>

Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

[Grumbach, Emmanuel]

On Fri, 2016-04-15 at 02:07 +, Borislav Petkov wrote:
> Hi,
> 
> so I'm seeing this when wlan0 tries to associate. On 4.6-rc2 + tip.
> After that, wifi is dead in the water. Anyone have a clue?
> 
> And 4.5 seems fine, I'm typing from it as we speak.
> ...




> [  661.142657] [ cut here ]
> [  661.142816] WARNING: CPU: 1 PID: 2485 at
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752
> iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
> [  661.143231] Timeout waiting for hardware access (CSR_GP_CNTRL
> 0x)
> 

This means that we have an electrical issue that prevents us from
accessing the device over the PCI bus. BAR has been garbaged or alike.
Every time I tried to debug that from the driver side it has ...
failed. Because the "good" in the end did exhibit the problem. So,
unless you are ready to embark for a bisection journey (and hope that
this time when you type 'git bisect good' it is really 'good'), I can't
do much.
What I can suggest is to install our latest backport based tree on 4.5.
This will allow you to have an easily bisectable tree. But it might
very well be that 4.5 + latest driver (equivalent to 4.6 as far as
iwlwifi is concerned) will be fine.
The backport tree is here [1]. Unfortunately, that's the only thing I
can suggest for now.

[1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
fi.git/
> -- 
> Regards/Gruss,
> Boris.
> 
> ECO tip #101: Trim your mails when you reply. Srsly.

Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

[Grumbach, Emmanuel]

On Fri, 2016-04-15 at 02:07 +, Borislav Petkov wrote:
> Hi,
> 
> so I'm seeing this when wlan0 tries to associate. On 4.6-rc2 + tip.
> After that, wifi is dead in the water. Anyone have a clue?
> 
> And 4.5 seems fine, I'm typing from it as we speak.
> ...




> [  661.142657] [ cut here ]
> [  661.142816] WARNING: CPU: 1 PID: 2485 at
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752
> iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
> [  661.143231] Timeout waiting for hardware access (CSR_GP_CNTRL
> 0x)
> 

This means that we have an electrical issue that prevents us from
accessing the device over the PCI bus. BAR has been garbaged or alike.
Every time I tried to debug that from the driver side it has ...
failed. Because the "good" in the end did exhibit the problem. So,
unless you are ready to embark for a bisection journey (and hope that
this time when you type 'git bisect good' it is really 'good'), I can't
do much.
What I can suggest is to install our latest backport based tree on 4.5.
This will allow you to have an easily bisectable tree. But it might
very well be that 4.5 + latest driver (equivalent to 4.6 as far as
iwlwifi is concerned) will be fine.
The backport tree is here [1]. Unfortunately, that's the only thing I
can suggest for now.

[1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
fi.git/
> -- 
> Regards/Gruss,
> Boris.
> 
> ECO tip #101: Trim your mails when you reply. Srsly.

Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support

[Baoquan He]

On 04/14/16 at 10:56am, Kees Cook wrote:
> On Thu, Apr 14, 2016 at 8:06 AM, Baoquan He  wrote:
> > On 04/13/16 at 11:02pm, Kees Cook wrote:
> >> On Wed, Apr 13, 2016 at 7:11 AM, Kees Cook  wrote:
> >> > On Wed, Apr 13, 2016 at 3:19 AM, Ingo Molnar  wrote:
> >> >>
> >> >> * Kees Cook  wrote:
> >> >>
> >> >>> FWIW, I've also had this tree up in my git branches, and the 0day
> >> >>> tester hasn't complained at all about it in the last two weeks. I'd
> >> >>> really like to see this in -next to fix the >4G (mainly kexec) issues
> >> >>> and get us to feature parity with the arm64 kASLR work (randomized
> >> >>> virtual address).
> >>
> >> So, I've done this and suddenly realized I hadn't boot-tested i386. It
> >> doesn't work, unfortunately. (Which I find strange: I'd expect 0day to
> >> have noticed...)
> >>
> >> Baoquan, have you tested this on 32-bit systems? I get a variety of
> >> failures. Either it boots okay, it reboots, or I get tons of pte
> >> errors like this:
> >
> > Hi Kees,
> >
> > I am sorry I didn't notice the change impacts i386. I got a i386 machine
> > and had tests. Found i386 can't take separate randomzation since there's
> > difference between i386 and x86_64.
> >
> > x86_64 has phys_base and can translate virt addr and phys addr according
> > to below formula:
> >
> > paddr = vaddr - __START_KERNEL_map + phys_base;
> >
> > However i386 can only do like this:
> >
> > paddr = vaddr - PAGE_OFFSET;
> >
> > Besides i386 has to reserve 128M for VMALLOC at the end of kernel
> > virtual address. So for i386 area 768M is the upper limit for
> > randomization. But I am fine with the KERNEL_IMAGE_SIZE, the old default
> > value. What do you say about this?
> >
> > So the plan should be keeping the old style of randomization for i386
> > system:
> >
> > 1) Disable virtual address randomization in i386 case because it's
> > useless. This should be done in patch:
> >  x86, KASLR: Randomize virtual address separately
> >
> > 2) Add an upper limit for physical randomization if it's i386 system.
> >  x86, KASLR: Add physical address randomization >4G
> >
> > I just got a test machine in office, and haven't had time to change
> > code. You can change it directly, or I will do it tomorrow.
> 
> I was thinking about the physical vs virtual on i386 as I woke up
> today. :) Thanks for confirming! These changes appear to make the
> series boot reliably on i386 (pardon any gmail-induced whitespace
> damage...):
> 
> diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
> index 5bae54b50d4c..3a58fe8acb8e 100644
> --- a/arch/x86/boot/compressed/aslr.c
> +++ b/arch/x86/boot/compressed/aslr.c
> @@ -347,6 +347,10 @@ static void process_e820_entry(struct e820entry *entry,
> if (entry->type != E820_RAM)
> return;
> 
> +   /* On 32-bit, ignore entries entirely above our maximum. */
> +   if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
> +   return;
> +
> /* Ignore entries entirely below our minimum. */
> if (entry->addr + entry->size < minimum)
> return;
> @@ -372,6 +376,11 @@ static void process_e820_entry(struct e820entry *entry,
> /* Reduce size by any delta from the original address. */
> region.size -= region.start - start_orig;
> 
> +   /* On 32-bit, reduce region size to fit within max size. */
> +   if (IS_ENABLED(CONFIG_X86_32) &&
> +   region.start + region.size > KERNEL_IMAGE_SIZE)
> +   region.size = KERNEL_IMAGE_SIZE - region.start;
> +
> /* Return if region can't contain decompressed kernel */
> if (region.size < image_size)
> return;
> @@ -488,6 +497,8 @@ void choose_kernel_location(unsigned char *input,
> }
> 
> /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */
> -   random = find_random_virt_offset(LOAD_PHYSICAL_ADDR, output_size);
> +   if (IS_ENABLED(CONFIG_X86_64))
> +   random = find_random_virt_offset(LOAD_PHYSICAL_ADDR,
> +output_size);
> *virt_offset = (unsigned char *)random;
>  }
> 
> 
> I will split these chunks up into the correct patches and resend the
> series. If you get a chance, can you double-check this?

Yes, these changes sounds great. I checked the series you posted, and
have to say you make them look much better. The change logs are perfect
and great code refactoring. Just one little bit thing, here:

[kees: rewrote changelog, refactored goto into while, limit 32-bit to 1G]
in patch [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G

In i386 KERNEL_IMAGE_SIZE is kept to be 0x2000, namely 512M, w/o kaslr
enabled. So here I guess it's a typo, should be "limit 32-bit to 1G". And
what I said is wrong about upper 

Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support

[Baoquan He]

On 04/14/16 at 10:56am, Kees Cook wrote:
> On Thu, Apr 14, 2016 at 8:06 AM, Baoquan He  wrote:
> > On 04/13/16 at 11:02pm, Kees Cook wrote:
> >> On Wed, Apr 13, 2016 at 7:11 AM, Kees Cook  wrote:
> >> > On Wed, Apr 13, 2016 at 3:19 AM, Ingo Molnar  wrote:
> >> >>
> >> >> * Kees Cook  wrote:
> >> >>
> >> >>> FWIW, I've also had this tree up in my git branches, and the 0day
> >> >>> tester hasn't complained at all about it in the last two weeks. I'd
> >> >>> really like to see this in -next to fix the >4G (mainly kexec) issues
> >> >>> and get us to feature parity with the arm64 kASLR work (randomized
> >> >>> virtual address).
> >>
> >> So, I've done this and suddenly realized I hadn't boot-tested i386. It
> >> doesn't work, unfortunately. (Which I find strange: I'd expect 0day to
> >> have noticed...)
> >>
> >> Baoquan, have you tested this on 32-bit systems? I get a variety of
> >> failures. Either it boots okay, it reboots, or I get tons of pte
> >> errors like this:
> >
> > Hi Kees,
> >
> > I am sorry I didn't notice the change impacts i386. I got a i386 machine
> > and had tests. Found i386 can't take separate randomzation since there's
> > difference between i386 and x86_64.
> >
> > x86_64 has phys_base and can translate virt addr and phys addr according
> > to below formula:
> >
> > paddr = vaddr - __START_KERNEL_map + phys_base;
> >
> > However i386 can only do like this:
> >
> > paddr = vaddr - PAGE_OFFSET;
> >
> > Besides i386 has to reserve 128M for VMALLOC at the end of kernel
> > virtual address. So for i386 area 768M is the upper limit for
> > randomization. But I am fine with the KERNEL_IMAGE_SIZE, the old default
> > value. What do you say about this?
> >
> > So the plan should be keeping the old style of randomization for i386
> > system:
> >
> > 1) Disable virtual address randomization in i386 case because it's
> > useless. This should be done in patch:
> >  x86, KASLR: Randomize virtual address separately
> >
> > 2) Add an upper limit for physical randomization if it's i386 system.
> >  x86, KASLR: Add physical address randomization >4G
> >
> > I just got a test machine in office, and haven't had time to change
> > code. You can change it directly, or I will do it tomorrow.
> 
> I was thinking about the physical vs virtual on i386 as I woke up
> today. :) Thanks for confirming! These changes appear to make the
> series boot reliably on i386 (pardon any gmail-induced whitespace
> damage...):
> 
> diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
> index 5bae54b50d4c..3a58fe8acb8e 100644
> --- a/arch/x86/boot/compressed/aslr.c
> +++ b/arch/x86/boot/compressed/aslr.c
> @@ -347,6 +347,10 @@ static void process_e820_entry(struct e820entry *entry,
> if (entry->type != E820_RAM)
> return;
> 
> +   /* On 32-bit, ignore entries entirely above our maximum. */
> +   if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
> +   return;
> +
> /* Ignore entries entirely below our minimum. */
> if (entry->addr + entry->size < minimum)
> return;
> @@ -372,6 +376,11 @@ static void process_e820_entry(struct e820entry *entry,
> /* Reduce size by any delta from the original address. */
> region.size -= region.start - start_orig;
> 
> +   /* On 32-bit, reduce region size to fit within max size. */
> +   if (IS_ENABLED(CONFIG_X86_32) &&
> +   region.start + region.size > KERNEL_IMAGE_SIZE)
> +   region.size = KERNEL_IMAGE_SIZE - region.start;
> +
> /* Return if region can't contain decompressed kernel */
> if (region.size < image_size)
> return;
> @@ -488,6 +497,8 @@ void choose_kernel_location(unsigned char *input,
> }
> 
> /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */
> -   random = find_random_virt_offset(LOAD_PHYSICAL_ADDR, output_size);
> +   if (IS_ENABLED(CONFIG_X86_64))
> +   random = find_random_virt_offset(LOAD_PHYSICAL_ADDR,
> +output_size);
> *virt_offset = (unsigned char *)random;
>  }
> 
> 
> I will split these chunks up into the correct patches and resend the
> series. If you get a chance, can you double-check this?

Yes, these changes sounds great. I checked the series you posted, and
have to say you make them look much better. The change logs are perfect
and great code refactoring. Just one little bit thing, here:

[kees: rewrote changelog, refactored goto into while, limit 32-bit to 1G]
in patch [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G

In i386 KERNEL_IMAGE_SIZE is kept to be 0x2000, namely 512M, w/o kaslr
enabled. So here I guess it's a typo, should be "limit 32-bit to 1G". And
what I said is wrong about upper limit yesterday, in fact i386 can put kernel
in [16M, 896M), not 768M. But 

[RFC PATCH] aliworkqueue: Adaptive lock integration on multi-core platform

[ling . ma . program]

From: Ma Ling 

Wire-latency(RC delay) dominate modern computer performance,
conventional serialized works cause cache line ping-pong seriously,
the process spend lots of time and power to complete.
specially on multi-core platform.

However if the serialized works are sent to one core and executed
ONLY when contention happens, that can save much time and power,
because all shared data are located in private cache of one core.
We call the mechanism as Adaptive Lock Integration.
(ali workqueue)

The new code is based on qspinlock and implement Lock Integration,
when user space application cause the bottle neck from kernel spinlock
the new mechanism could improve performance up to 1.65x for
https://lkml.org/lkml/2016/2/4/48 or
http://lkml.iu.edu/hypermail/linux/kernel/1602.0/03745.html
and 2.79x for https://lkml.org/lkml/2016/4/4/848 respectively.

And additional changes on Makefile/Kconfig are made to enable compiling of
this feature on x86 platform.

Signed-off-by: Ma Ling  
---
The patch is based on https://lkml.org/lkml/2015/12/31/20,
in this version we append init function and fix function name.

 arch/x86/Kconfig  |1 +
 include/linux/aliworkqueue.h  |   34 ++
 kernel/Kconfig.locks  |7 +++
 kernel/locking/Makefile   |1 +
 kernel/locking/aliworkqueue.c |   97 +
 5 files changed, 140 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/aliworkqueue.h
 create mode 100644 kernel/locking/aliworkqueue.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 328c835..f0a7df1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -42,6 +42,7 @@ config X86
select ARCH_USE_CMPXCHG_LOCKREF if X86_64
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+   select ARCH_USE_ALI_WORKQUEUE
select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH if SMP
select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_FRAME_POINTERS
diff --git a/include/linux/aliworkqueue.h b/include/linux/aliworkqueue.h
new file mode 100644
index 000..3c8437b
--- /dev/null
+++ b/include/linux/aliworkqueue.h
@@ -0,0 +1,34 @@
+#ifndef ALI_WORKQUEUE_H
+#define ALI_WORKQUEUE_H
+/*
+ * Adaptive Lock Integration
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2015 Alibaba Group.
+ *
+ * Authors: Ma Ling 
+ *
+ */
+typedef struct ali_workqueue {
+   void  *wq;
+} ali_workqueue_t;
+
+struct ali_workqueue_info {
+   struct ali_workqueue_info *next;
+   int pending;
+   void (*fn)(void *);
+   void *para;
+};
+
+void ali_workqueue(struct ali_workqueue *ali_wq, struct ali_workqueue_info 
*ali);
+void ali_workqueue_init(struct ali_workqueue *ali_wq);
+#endif /* ALI_WORKQUEUE_H */
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index ebdb004..4edc186 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -235,6 +235,13 @@ config LOCK_SPIN_ON_OWNER
def_bool y
depends on MUTEX_SPIN_ON_OWNER || RWSEM_SPIN_ON_OWNER
 
+config ARCH_USE_ALI_WORKQUEUE
+   bool
+
+config ALI_WORKQUEUE
+   def_bool y if ARCH_USE_ALI_WORKQUEUE
+   depends on SMP
+
 config ARCH_USE_QUEUED_SPINLOCKS
bool
 
diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
index 8e96f6c..b7c1280 100644
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_LOCKDEP) += lockdep.o
 ifeq ($(CONFIG_PROC_FS),y)
 obj-$(CONFIG_LOCKDEP) += lockdep_proc.o
 endif
+obj-$(CONFIG_ALI_WORKQUEUE) += aliworkqueue.o
 obj-$(CONFIG_SMP) += spinlock.o
 obj-$(CONFIG_LOCK_SPIN_ON_OWNER) += osq_lock.o
 obj-$(CONFIG_SMP) += lglock.o
diff --git a/kernel/locking/aliworkqueue.c b/kernel/locking/aliworkqueue.c
new file mode 100644
index 000..fe4c88e
--- /dev/null
+++ b/kernel/locking/aliworkqueue.c
@@ -0,0 +1,97 @@
+/*
+ * Adaptive Lock Integration
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2015 Alibaba Group.
+ *
+ 

[RFC PATCH] aliworkqueue: Adaptive lock integration on multi-core platform

[ling . ma . program]

From: Ma Ling 

Wire-latency(RC delay) dominate modern computer performance,
conventional serialized works cause cache line ping-pong seriously,
the process spend lots of time and power to complete.
specially on multi-core platform.

However if the serialized works are sent to one core and executed
ONLY when contention happens, that can save much time and power,
because all shared data are located in private cache of one core.
We call the mechanism as Adaptive Lock Integration.
(ali workqueue)

The new code is based on qspinlock and implement Lock Integration,
when user space application cause the bottle neck from kernel spinlock
the new mechanism could improve performance up to 1.65x for
https://lkml.org/lkml/2016/2/4/48 or
http://lkml.iu.edu/hypermail/linux/kernel/1602.0/03745.html
and 2.79x for https://lkml.org/lkml/2016/4/4/848 respectively.

And additional changes on Makefile/Kconfig are made to enable compiling of
this feature on x86 platform.

Signed-off-by: Ma Ling  
---
The patch is based on https://lkml.org/lkml/2015/12/31/20,
in this version we append init function and fix function name.

 arch/x86/Kconfig  |1 +
 include/linux/aliworkqueue.h  |   34 ++
 kernel/Kconfig.locks  |7 +++
 kernel/locking/Makefile   |1 +
 kernel/locking/aliworkqueue.c |   97 +
 5 files changed, 140 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/aliworkqueue.h
 create mode 100644 kernel/locking/aliworkqueue.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 328c835..f0a7df1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -42,6 +42,7 @@ config X86
select ARCH_USE_CMPXCHG_LOCKREF if X86_64
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+   select ARCH_USE_ALI_WORKQUEUE
select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH if SMP
select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_FRAME_POINTERS
diff --git a/include/linux/aliworkqueue.h b/include/linux/aliworkqueue.h
new file mode 100644
index 000..3c8437b
--- /dev/null
+++ b/include/linux/aliworkqueue.h
@@ -0,0 +1,34 @@
+#ifndef ALI_WORKQUEUE_H
+#define ALI_WORKQUEUE_H
+/*
+ * Adaptive Lock Integration
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2015 Alibaba Group.
+ *
+ * Authors: Ma Ling 
+ *
+ */
+typedef struct ali_workqueue {
+   void  *wq;
+} ali_workqueue_t;
+
+struct ali_workqueue_info {
+   struct ali_workqueue_info *next;
+   int pending;
+   void (*fn)(void *);
+   void *para;
+};
+
+void ali_workqueue(struct ali_workqueue *ali_wq, struct ali_workqueue_info 
*ali);
+void ali_workqueue_init(struct ali_workqueue *ali_wq);
+#endif /* ALI_WORKQUEUE_H */
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index ebdb004..4edc186 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -235,6 +235,13 @@ config LOCK_SPIN_ON_OWNER
def_bool y
depends on MUTEX_SPIN_ON_OWNER || RWSEM_SPIN_ON_OWNER
 
+config ARCH_USE_ALI_WORKQUEUE
+   bool
+
+config ALI_WORKQUEUE
+   def_bool y if ARCH_USE_ALI_WORKQUEUE
+   depends on SMP
+
 config ARCH_USE_QUEUED_SPINLOCKS
bool
 
diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
index 8e96f6c..b7c1280 100644
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_LOCKDEP) += lockdep.o
 ifeq ($(CONFIG_PROC_FS),y)
 obj-$(CONFIG_LOCKDEP) += lockdep_proc.o
 endif
+obj-$(CONFIG_ALI_WORKQUEUE) += aliworkqueue.o
 obj-$(CONFIG_SMP) += spinlock.o
 obj-$(CONFIG_LOCK_SPIN_ON_OWNER) += osq_lock.o
 obj-$(CONFIG_SMP) += lglock.o
diff --git a/kernel/locking/aliworkqueue.c b/kernel/locking/aliworkqueue.c
new file mode 100644
index 000..fe4c88e
--- /dev/null
+++ b/kernel/locking/aliworkqueue.c
@@ -0,0 +1,97 @@
+/*
+ * Adaptive Lock Integration
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2015 Alibaba Group.
+ *
+ * Authors: Ma Ling 
+ *
+ */
+#include 
+#include 
+#include 
+/*
+ * 

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

[Leon Romanovsky]

On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote:
> > On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote:
> > > This patch series removes the write() interface for user access in favor 
> > > of an
> > > ioctl() based approach. This is in response to the complaint that we had
> > > different handlers for write() and writev() doing different things and 
> > > expecting
> > > different types of data. See:
> > 
> > I think we should wait on applying these patches until we globally sort out
> > what to do with the rdma uapi.
> > 
> > It just doesn't make alot of sense for drivers to have their own personal
> > char devices. :(
> 
> I'm afraid I have to disagree at this time.  Someday we may have "1 char 
> device
> to rule them all" but right now we don't have any line of sight to that
> solution.  It may be _years_ before we can agree to the semantics which will
> work for all high speed, kernel bypass, rdma, low latency, network devices.

You didn't ever try to come and work on the solution. We talked about
finite time frame (_months_) which is doable based on knowledge that user
space parts are developed by the same companies and all our future changes
will be in one subsystem.

You were supposed to prepare "wish list" from this new API as an initial
phase. If you do it, you will find that it is very short and in the
initial meeting you will see that it similar to other participants in
linux-rdma community.

> 
> We need to fix the write/writev problem now.[1]

No, this driver in staging and the proper way to move it out will be to
converge on common API and one clear path instead of duplicating the
interfaces and "inventing the wheel".

> 
> Ira
> 
> [1] https://www.spinics.net/lists/linux-rdma/msg34451.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: Digital signature

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

[Leon Romanovsky]

On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote:
> On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote:
> > On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote:
> > > This patch series removes the write() interface for user access in favor 
> > > of an
> > > ioctl() based approach. This is in response to the complaint that we had
> > > different handlers for write() and writev() doing different things and 
> > > expecting
> > > different types of data. See:
> > 
> > I think we should wait on applying these patches until we globally sort out
> > what to do with the rdma uapi.
> > 
> > It just doesn't make alot of sense for drivers to have their own personal
> > char devices. :(
> 
> I'm afraid I have to disagree at this time.  Someday we may have "1 char 
> device
> to rule them all" but right now we don't have any line of sight to that
> solution.  It may be _years_ before we can agree to the semantics which will
> work for all high speed, kernel bypass, rdma, low latency, network devices.

You didn't ever try to come and work on the solution. We talked about
finite time frame (_months_) which is doable based on knowledge that user
space parts are developed by the same companies and all our future changes
will be in one subsystem.

You were supposed to prepare "wish list" from this new API as an initial
phase. If you do it, you will find that it is very short and in the
initial meeting you will see that it similar to other participants in
linux-rdma community.

> 
> We need to fix the write/writev problem now.[1]

No, this driver in staging and the proper way to move it out will be to
converge on common API and one clear path instead of duplicating the
interfaces and "inventing the wheel".

> 
> Ira
> 
> [1] https://www.spinics.net/lists/linux-rdma/msg34451.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: Digital signature

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

[Yuyang Du]

Hi Dietmar,

On Thu, Apr 14, 2016 at 01:52:43PM +0100, Dietmar Eggemann wrote:
> On 13/04/16 19:44, Yuyang Du wrote:
> > On Wed, Apr 13, 2016 at 05:28:18PM +0200, Vincent Guittot wrote:
> 
> [...]
> 
> > By "bailing out", you mean return without update because the delta is less
> > than 1ms?
> 
> yes.
> 
> > 
> >>> Examples of 1 periodic task pinned to a cpu on an ARM64 system, HZ=250
> >>> in steady state:
> >>>
> >>> (1) task runtime = 100us period = 200us
> >>>
> >>>   pelt  load/util signal
> >>>
> >>>   1us:  488-491
> >>>
> >>>   1ms:  483-534
> > 
> > 100us/200us = 50%, so the util should center around 512, it seems in this
> > regard, it is better, but the variance is undesirable.
> 
> I see. You mentioned the over-decay thing in the patch header. Is this
> also why you change the contribution of the most recent period from 1002
> (1024*y) to 1024?

Yes, it is because that (most recent) period is the "current" period.
 
> This variance gets worse if the ratio runtime/period is further reduced
> (e.g. 25us/1000us).
> 
> You can even create tasks which go stealth mode (e.g. 25us/1048us).

En... this is a good case to beat it.

> It shows periods of 0 load/util (~1.55s) and than massive spikes (~700 for
> ~300ms). The short runtime and the task period synced to 1024*1024ns
> allow that we hit consecutive enqueues or dequeues for a long time even
> the task might drift relative to the pelt window.

But whenever we pass 1ms, we will update. And I am curious, how does the
current 1us works in this case? Anyway, I will reproduce it myself.

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

[Yuyang Du]

Hi Dietmar,

On Thu, Apr 14, 2016 at 01:52:43PM +0100, Dietmar Eggemann wrote:
> On 13/04/16 19:44, Yuyang Du wrote:
> > On Wed, Apr 13, 2016 at 05:28:18PM +0200, Vincent Guittot wrote:
> 
> [...]
> 
> > By "bailing out", you mean return without update because the delta is less
> > than 1ms?
> 
> yes.
> 
> > 
> >>> Examples of 1 periodic task pinned to a cpu on an ARM64 system, HZ=250
> >>> in steady state:
> >>>
> >>> (1) task runtime = 100us period = 200us
> >>>
> >>>   pelt  load/util signal
> >>>
> >>>   1us:  488-491
> >>>
> >>>   1ms:  483-534
> > 
> > 100us/200us = 50%, so the util should center around 512, it seems in this
> > regard, it is better, but the variance is undesirable.
> 
> I see. You mentioned the over-decay thing in the patch header. Is this
> also why you change the contribution of the most recent period from 1002
> (1024*y) to 1024?

Yes, it is because that (most recent) period is the "current" period.
 
> This variance gets worse if the ratio runtime/period is further reduced
> (e.g. 25us/1000us).
> 
> You can even create tasks which go stealth mode (e.g. 25us/1048us).

En... this is a good case to beat it.

> It shows periods of 0 load/util (~1.55s) and than massive spikes (~700 for
> ~300ms). The short runtime and the task period synced to 1024*1024ns
> allow that we hit consecutive enqueues or dequeues for a long time even
> the task might drift relative to the pelt window.

But whenever we pass 1ms, we will update. And I am curious, how does the
current 1us works in this case? Anyway, I will reproduce it myself.

Re: [PATCH 1/3] rxrpc: Don't permit use of connect() op and simplify sendmsg() op

[David Howells]

David Miller  wrote:

> > Simplify the RxRPC user interface and remove the use of connect() to direct
> > client calls.  It is redundant given that sendmsg() can be given the target
> > address and calls to multiple targets are permitted from a client socket
> > and also from a service socket.
> 
> You can't just change completely the socket semantics for your
> protocol like this, every single userland application is going to
> break.
> 
> Sorry, there is no way I am applying changes like this.

Okay, fair enough.[*]

David

[*] I could point out that there is only one (under construction) userspace
application that uses this - and that doesn't use connect - but I can't quite
be 100% sure of that, so your point stands.

Re: [PATCH 1/3] rxrpc: Don't permit use of connect() op and simplify sendmsg() op

[David Howells]

David Miller  wrote:

> > Simplify the RxRPC user interface and remove the use of connect() to direct
> > client calls.  It is redundant given that sendmsg() can be given the target
> > address and calls to multiple targets are permitted from a client socket
> > and also from a service socket.
> 
> You can't just change completely the socket semantics for your
> protocol like this, every single userland application is going to
> break.
> 
> Sorry, there is no way I am applying changes like this.

Okay, fair enough.[*]

David

[*] I could point out that there is only one (under construction) userspace
application that uses this - and that doesn't use connect - but I can't quite
be 100% sure of that, so your point stands.

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

[Xiong Zhou]

On Wed, Apr 13, 2016 at 4:19 PM, Johannes Thumshirn  wrote:
> Hi Xiong
> Sorry for the late reply
>
> On Dienstag, 12. April 2016 21:01:53 CEST Xiong Zhou wrote:
>> How about this?
>>
>> drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy
>>
>> Signed-off-by: Xiong Zhou 
>> ---
>>  drivers/scsi/scsi_scan.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
>> index 27df7e7..21092e5 100644
>> --- a/drivers/scsi/scsi_scan.c
>> +++ b/drivers/scsi/scsi_scan.c
>> @@ -395,6 +395,8 @@ static void scsi_target_reap_ref_release(struct kref 
>> *kref)
>>   transport_remove_device(>dev);
>>   device_del(>dev);
>>   }
>> +
>> + starget->state = STARGET_REMOVE;
>>   scsi_target_destroy(starget);
>>  }
>
> The only scsi_target_reap_ref_release() caller is scsi_target_reap_ref_put(),
> which in turn is only called by scsi_target_reap(). scsi_target_reap()'s only
> callers are scsi_remove_target()/__scsi_remove_target(), which set the
> STARGET_REMOVE state and
>
> __scsi_add_device()
> scsi_get_host_dev()
> __scsi_scan_target()
>
> Which I'm currently investiganting (in parallel to reproducing the bug).

Thanks !

--
Xiong

>
>>
>> @@ -465,6 +467,7 @@ static struct scsi_target
>> *scsi_alloc_target(struct device *parent,
>>   dev_printk(KERN_ERR, dev, "target allocation failed, error %d\n", error);
>>   /* don't want scsi_target_reap to do the final
>>   * put because it will be under the host lock */
>> + starget->state = STARGET_REMOVE;
>>   scsi_target_destroy(starget);
>>   return NULL;
>>   }
>
> Here starget->state is STARGET_CREATED and the assertion is already aware of
> this state transitoin. IOTW this /shouldn't/ be needed.
>
>
> --
> Johannes Thumshirn
> Storage
> jthumsh...@suse.de
>  +49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
>

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

[Xiong Zhou]

On Wed, Apr 13, 2016 at 4:19 PM, Johannes Thumshirn  wrote:
> Hi Xiong
> Sorry for the late reply
>
> On Dienstag, 12. April 2016 21:01:53 CEST Xiong Zhou wrote:
>> How about this?
>>
>> drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy
>>
>> Signed-off-by: Xiong Zhou 
>> ---
>>  drivers/scsi/scsi_scan.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
>> index 27df7e7..21092e5 100644
>> --- a/drivers/scsi/scsi_scan.c
>> +++ b/drivers/scsi/scsi_scan.c
>> @@ -395,6 +395,8 @@ static void scsi_target_reap_ref_release(struct kref 
>> *kref)
>>   transport_remove_device(>dev);
>>   device_del(>dev);
>>   }
>> +
>> + starget->state = STARGET_REMOVE;
>>   scsi_target_destroy(starget);
>>  }
>
> The only scsi_target_reap_ref_release() caller is scsi_target_reap_ref_put(),
> which in turn is only called by scsi_target_reap(). scsi_target_reap()'s only
> callers are scsi_remove_target()/__scsi_remove_target(), which set the
> STARGET_REMOVE state and
>
> __scsi_add_device()
> scsi_get_host_dev()
> __scsi_scan_target()
>
> Which I'm currently investiganting (in parallel to reproducing the bug).

Thanks !

--
Xiong

>
>>
>> @@ -465,6 +467,7 @@ static struct scsi_target
>> *scsi_alloc_target(struct device *parent,
>>   dev_printk(KERN_ERR, dev, "target allocation failed, error %d\n", error);
>>   /* don't want scsi_target_reap to do the final
>>   * put because it will be under the host lock */
>> + starget->state = STARGET_REMOVE;
>>   scsi_target_destroy(starget);
>>   return NULL;
>>   }
>
> Here starget->state is STARGET_CREATED and the assertion is already aware of
> this state transitoin. IOTW this /shouldn't/ be needed.
>
>
> --
> Johannes Thumshirn
> Storage
> jthumsh...@suse.de
>  +49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
>

[RT PATCH] cputime: remove raw locks introduced by RT patchset

[Clark Williams]

Sebastian,

This patch removes the raw spinlock operations when updating cputtime
in the vtime_* functions in kernel/sched/cputime.c.

Based on Frederic's commit b7ce2277f087fd052, there is no need for
the raw spinlocks in vtime_* functions to guard against writer
concurrency and the RT versions of write_seqcount_begin() and
write_seqcount_end() make calls to preempt_disable_rt() and
preempt_enable_rt(), so we'll be in atomic context while updating
cputime.

I've run this patch on x86_64 4.4.6-rt14 and the RHEL-RT kernel, 
with 12h rteval runs on systems with both no tuning and systems
with isolcpus/rcu_nocbs/nohz_full cpus. No ill effects seen. 

Signed-off-by: Rik van Riel 
Signed-off-by: Clark Williams 
---
 kernel/sched/cputime.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 0f75a38cff96..9a823ced7e4a 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -696,45 +696,37 @@ static void __vtime_account_system(struct task_struct 
*tsk)
 
 void vtime_account_system(struct task_struct *tsk)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_gen_account_irq_exit(struct task_struct *tsk)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
if (context_tracking_in_user())
tsk->vtime_snap_whence = VTIME_USER;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_account_user(struct task_struct *tsk)
 {
cputime_t delta_cpu;
 
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
delta_cpu = get_vtime_delta(tsk);
tsk->vtime_snap_whence = VTIME_SYS;
account_user_time(tsk, delta_cpu, cputime_to_scaled(delta_cpu));
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_user_enter(struct task_struct *tsk)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
tsk->vtime_snap_whence = VTIME_USER;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_guest_enter(struct task_struct *tsk)
@@ -746,23 +738,19 @@ void vtime_guest_enter(struct task_struct *tsk)
 * synchronization against the reader (task_gtime())
 * that can thus safely catch up with a tickless delta.
 */
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
current->flags |= PF_VCPU;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 EXPORT_SYMBOL_GPL(vtime_guest_enter);
 
 void vtime_guest_exit(struct task_struct *tsk)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
current->flags &= ~PF_VCPU;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 EXPORT_SYMBOL_GPL(vtime_guest_exit);
 
@@ -775,30 +763,24 @@ void vtime_account_idle(struct task_struct *tsk)
 
 void arch_vtime_task_switch(struct task_struct *prev)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
prev->vtime_snap_whence = VTIME_SLEEPING;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
current->vtime_snap_whence = VTIME_SYS;
current->vtime_snap = sched_clock_cpu(smp_processor_id());
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_init_idle(struct task_struct *t, int cpu)
 {
unsigned long flags;
 
-   raw_spin_lock_irqsave(>vtime_lock, flags);
write_seqcount_begin(>vtime_seq);
t->vtime_snap_whence = VTIME_SYS;
t->vtime_snap = sched_clock_cpu(cpu);
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock_irqrestore(>vtime_lock, flags);
 }
 
 cputime_t task_gtime(struct task_struct *t)
-- 
2.5.5



pgp2CkPZ0ZVOr.pgp
Description: OpenPGP digital signature

[RT PATCH] cputime: remove raw locks introduced by RT patchset

[Clark Williams]

Sebastian,

This patch removes the raw spinlock operations when updating cputtime
in the vtime_* functions in kernel/sched/cputime.c.

Based on Frederic's commit b7ce2277f087fd052, there is no need for
the raw spinlocks in vtime_* functions to guard against writer
concurrency and the RT versions of write_seqcount_begin() and
write_seqcount_end() make calls to preempt_disable_rt() and
preempt_enable_rt(), so we'll be in atomic context while updating
cputime.

I've run this patch on x86_64 4.4.6-rt14 and the RHEL-RT kernel, 
with 12h rteval runs on systems with both no tuning and systems
with isolcpus/rcu_nocbs/nohz_full cpus. No ill effects seen. 

Signed-off-by: Rik van Riel 
Signed-off-by: Clark Williams 
---
 kernel/sched/cputime.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 0f75a38cff96..9a823ced7e4a 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -696,45 +696,37 @@ static void __vtime_account_system(struct task_struct 
*tsk)
 
 void vtime_account_system(struct task_struct *tsk)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_gen_account_irq_exit(struct task_struct *tsk)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
if (context_tracking_in_user())
tsk->vtime_snap_whence = VTIME_USER;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_account_user(struct task_struct *tsk)
 {
cputime_t delta_cpu;
 
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
delta_cpu = get_vtime_delta(tsk);
tsk->vtime_snap_whence = VTIME_SYS;
account_user_time(tsk, delta_cpu, cputime_to_scaled(delta_cpu));
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_user_enter(struct task_struct *tsk)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
tsk->vtime_snap_whence = VTIME_USER;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_guest_enter(struct task_struct *tsk)
@@ -746,23 +738,19 @@ void vtime_guest_enter(struct task_struct *tsk)
 * synchronization against the reader (task_gtime())
 * that can thus safely catch up with a tickless delta.
 */
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
current->flags |= PF_VCPU;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 EXPORT_SYMBOL_GPL(vtime_guest_enter);
 
 void vtime_guest_exit(struct task_struct *tsk)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
__vtime_account_system(tsk);
current->flags &= ~PF_VCPU;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 EXPORT_SYMBOL_GPL(vtime_guest_exit);
 
@@ -775,30 +763,24 @@ void vtime_account_idle(struct task_struct *tsk)
 
 void arch_vtime_task_switch(struct task_struct *prev)
 {
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
prev->vtime_snap_whence = VTIME_SLEEPING;
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 
-   raw_spin_lock(>vtime_lock);
write_seqcount_begin(>vtime_seq);
current->vtime_snap_whence = VTIME_SYS;
current->vtime_snap = sched_clock_cpu(smp_processor_id());
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock(>vtime_lock);
 }
 
 void vtime_init_idle(struct task_struct *t, int cpu)
 {
unsigned long flags;
 
-   raw_spin_lock_irqsave(>vtime_lock, flags);
write_seqcount_begin(>vtime_seq);
t->vtime_snap_whence = VTIME_SYS;
t->vtime_snap = sched_clock_cpu(cpu);
write_seqcount_end(>vtime_seq);
-   raw_spin_unlock_irqrestore(>vtime_lock, flags);
 }
 
 cputime_t task_gtime(struct task_struct *t)
-- 
2.5.5



pgp2CkPZ0ZVOr.pgp
Description: OpenPGP digital signature

Re: [PATCH 01/14] drm/amdgpu: use drm_crtc_send_vblank_event()

[Michel Dänzer]

On 15.04.2016 02:48, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Replace the legacy drm_send_vblank_event() with the new helper function.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 6de2ce53..92c5a71 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -3370,7 +3370,7 @@ static int dce_v10_0_pageflip_irq(struct amdgpu_device 
> *adev,
>  
>   /* wakeup usersapce */
>   if (works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(_crtc->base, works->event);
>  
>   spin_unlock_irqrestore(>ddev->event_lock, flags);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index e9ccc6b..2f784f2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -3366,7 +3366,7 @@ static int dce_v11_0_pageflip_irq(struct amdgpu_device 
> *adev,
>  
>   /* wakeup usersapce */
>   if(works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(_crtc->base, works->event);
>  
>   spin_unlock_irqrestore(>ddev->event_lock, flags);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index e56b55d..9155e3b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -3379,7 +3379,7 @@ static int dce_v8_0_pageflip_irq(struct amdgpu_device 
> *adev,
>  
>   /* wakeup usersapce */
>   if (works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(_crtc->base, works->event);
>  
>   spin_unlock_irqrestore(>ddev->event_lock, flags);
>  
> 

This patch and patch 8 are

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH 01/14] drm/amdgpu: use drm_crtc_send_vblank_event()

[Michel Dänzer]

On 15.04.2016 02:48, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Replace the legacy drm_send_vblank_event() with the new helper function.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 6de2ce53..92c5a71 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -3370,7 +3370,7 @@ static int dce_v10_0_pageflip_irq(struct amdgpu_device 
> *adev,
>  
>   /* wakeup usersapce */
>   if (works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(_crtc->base, works->event);
>  
>   spin_unlock_irqrestore(>ddev->event_lock, flags);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index e9ccc6b..2f784f2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -3366,7 +3366,7 @@ static int dce_v11_0_pageflip_irq(struct amdgpu_device 
> *adev,
>  
>   /* wakeup usersapce */
>   if(works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(_crtc->base, works->event);
>  
>   spin_unlock_irqrestore(>ddev->event_lock, flags);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index e56b55d..9155e3b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -3379,7 +3379,7 @@ static int dce_v8_0_pageflip_irq(struct amdgpu_device 
> *adev,
>  
>   /* wakeup usersapce */
>   if (works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(_crtc->base, works->event);
>  
>   spin_unlock_irqrestore(>ddev->event_lock, flags);
>  
> 

This patch and patch 8 are

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

RE: [PATCH 3/3] fec: move to new ethtool api {get|set}_link_ksettings

[Fugang Duan]

From: Philippe Reynes  Sent: Friday, April 15, 2016 6:35 AM
> To: da...@davemloft.net; de...@googlers.com; f.faine...@gmail.com; Fugang
> Duan 
> Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Philippe Reynes
> 
> Subject: [PATCH 3/3] fec: move to new ethtool api {get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move the fec driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/ethernet/freescale/fec_main.c |   16 
>  1 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 08243c2..bfa10c3 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2058,8 +2058,8 @@ static void fec_enet_mii_remove(struct
> fec_enet_private *fep)
>   }
>  }
> 
> -static int fec_enet_get_settings(struct net_device *ndev,
> -   struct ethtool_cmd *cmd)
> +static int fec_enet_get_link_ksettings(struct net_device *ndev,
> +struct ethtool_link_ksettings *cmd)
>  {
>   struct fec_enet_private *fep = netdev_priv(ndev);
>   struct phy_device *phydev = fep->phy_dev; @@ -2067,11 +2067,11
> @@ static int fec_enet_get_settings(struct net_device *ndev,
>   if (!phydev)
>   return -ENODEV;
> 
> - return phy_ethtool_gset(phydev, cmd);
> + return phy_ethtool_ksettings_get(phydev, cmd);
>  }
> 
> -static int fec_enet_set_settings(struct net_device *ndev,
> -  struct ethtool_cmd *cmd)
> +static int fec_enet_set_link_ksettings(struct net_device *ndev,
> +const struct ethtool_link_ksettings *cmd)
>  {
>   struct fec_enet_private *fep = netdev_priv(ndev);
>   struct phy_device *phydev = fep->phy_dev; @@ -2079,7 +2079,7 @@
> static int fec_enet_set_settings(struct net_device *ndev,
>   if (!phydev)
>   return -ENODEV;
> 
> - return phy_ethtool_sset(phydev, cmd);
> + return phy_ethtool_ksettings_set(phydev, cmd);
>  }
> 
>  static void fec_enet_get_drvinfo(struct net_device *ndev, @@ -2562,8
> +2562,6 @@ fec_enet_set_wol(struct net_device *ndev, struct
> ethtool_wolinfo *wol)  }
> 
>  static const struct ethtool_ops fec_enet_ethtool_ops = {
> - .get_settings   = fec_enet_get_settings,
> - .set_settings   = fec_enet_set_settings,
>   .get_drvinfo= fec_enet_get_drvinfo,
>   .get_regs_len   = fec_enet_get_regs_len,
>   .get_regs   = fec_enet_get_regs,
> @@ -2583,6 +2581,8 @@ static const struct ethtool_ops fec_enet_ethtool_ops
> = {
>   .set_tunable= fec_enet_set_tunable,
>   .get_wol= fec_enet_get_wol,
>   .set_wol= fec_enet_set_wol,
> + .get_link_ksettings = fec_enet_get_link_ksettings,
> + .set_link_ksettings = fec_enet_set_link_ksettings,
>  };
> 
>  static int fec_enet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
> --
> 1.7.4.4

Acked-by: Fugang Duan 

RE: [PATCH 3/3] fec: move to new ethtool api {get|set}_link_ksettings

[Fugang Duan]

From: Philippe Reynes  Sent: Friday, April 15, 2016 6:35 AM
> To: da...@davemloft.net; de...@googlers.com; f.faine...@gmail.com; Fugang
> Duan 
> Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Philippe Reynes
> 
> Subject: [PATCH 3/3] fec: move to new ethtool api {get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move the fec driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/ethernet/freescale/fec_main.c |   16 
>  1 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 08243c2..bfa10c3 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2058,8 +2058,8 @@ static void fec_enet_mii_remove(struct
> fec_enet_private *fep)
>   }
>  }
> 
> -static int fec_enet_get_settings(struct net_device *ndev,
> -   struct ethtool_cmd *cmd)
> +static int fec_enet_get_link_ksettings(struct net_device *ndev,
> +struct ethtool_link_ksettings *cmd)
>  {
>   struct fec_enet_private *fep = netdev_priv(ndev);
>   struct phy_device *phydev = fep->phy_dev; @@ -2067,11 +2067,11
> @@ static int fec_enet_get_settings(struct net_device *ndev,
>   if (!phydev)
>   return -ENODEV;
> 
> - return phy_ethtool_gset(phydev, cmd);
> + return phy_ethtool_ksettings_get(phydev, cmd);
>  }
> 
> -static int fec_enet_set_settings(struct net_device *ndev,
> -  struct ethtool_cmd *cmd)
> +static int fec_enet_set_link_ksettings(struct net_device *ndev,
> +const struct ethtool_link_ksettings *cmd)
>  {
>   struct fec_enet_private *fep = netdev_priv(ndev);
>   struct phy_device *phydev = fep->phy_dev; @@ -2079,7 +2079,7 @@
> static int fec_enet_set_settings(struct net_device *ndev,
>   if (!phydev)
>   return -ENODEV;
> 
> - return phy_ethtool_sset(phydev, cmd);
> + return phy_ethtool_ksettings_set(phydev, cmd);
>  }
> 
>  static void fec_enet_get_drvinfo(struct net_device *ndev, @@ -2562,8
> +2562,6 @@ fec_enet_set_wol(struct net_device *ndev, struct
> ethtool_wolinfo *wol)  }
> 
>  static const struct ethtool_ops fec_enet_ethtool_ops = {
> - .get_settings   = fec_enet_get_settings,
> - .set_settings   = fec_enet_set_settings,
>   .get_drvinfo= fec_enet_get_drvinfo,
>   .get_regs_len   = fec_enet_get_regs_len,
>   .get_regs   = fec_enet_get_regs,
> @@ -2583,6 +2581,8 @@ static const struct ethtool_ops fec_enet_ethtool_ops
> = {
>   .set_tunable= fec_enet_set_tunable,
>   .get_wol= fec_enet_get_wol,
>   .set_wol= fec_enet_set_wol,
> + .get_link_ksettings = fec_enet_get_link_ksettings,
> + .set_link_ksettings = fec_enet_set_link_ksettings,
>  };
> 
>  static int fec_enet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
> --
> 1.7.4.4

Acked-by: Fugang Duan 

RE: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts

[KY Srinivasan]

> -Original Message-
> From: tar...@gmail.com [mailto:tar...@gmail.com] On Behalf Of Jeff Kirsher
> Sent: Thursday, April 14, 2016 7:21 PM
> To: KY Srinivasan 
> Cc: David Miller ; netdev
> ; LKML ;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; e...@mellanox.com; ja...@mellanox.com;
> yevge...@mellanox.com; Ronciak, John ; intel-
> wired-...@linuxonhyperv.com
> Subject: Re: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts
> 
> On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan 
> wrote:
> > Make adjustments to the Intel 10G VF driver to support
> > running on Hyper-V hosts.
> >
> > K. Y. Srinivasan (2):
> >   ethernet: intel: Add the device ID's presented while running on
> > Hyper-V
> >   intel: ixgbevf: Support Windows hosts (Hyper-V)
> >
> >  drivers/net/ethernet/intel/ixgbevf/defines.h  |5 +
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf.h  |   11 ++
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   56 ++---
> >  drivers/net/ethernet/intel/ixgbevf/mbx.c  |   12 ++
> >  drivers/net/ethernet/intel/ixgbevf/vf.c   |  138
> +
> >  drivers/net/ethernet/intel/ixgbevf/vf.h   |2 +
> >  6 files changed, 206 insertions(+), 18 deletions(-)
> 
> Don't know how you butchered the mailing list address, but you did not
> send this series to intel-wired-...@lists.osuosl.org mailing list.
> Please address the requested changes that Mark suggested and resubmit
> to the correct mailing list please.

Will do.

Thanks,

K. Y

RE: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts

[KY Srinivasan]

> -Original Message-
> From: tar...@gmail.com [mailto:tar...@gmail.com] On Behalf Of Jeff Kirsher
> Sent: Thursday, April 14, 2016 7:21 PM
> To: KY Srinivasan 
> Cc: David Miller ; netdev
> ; LKML ;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; e...@mellanox.com; ja...@mellanox.com;
> yevge...@mellanox.com; Ronciak, John ; intel-
> wired-...@linuxonhyperv.com
> Subject: Re: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts
> 
> On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan 
> wrote:
> > Make adjustments to the Intel 10G VF driver to support
> > running on Hyper-V hosts.
> >
> > K. Y. Srinivasan (2):
> >   ethernet: intel: Add the device ID's presented while running on
> > Hyper-V
> >   intel: ixgbevf: Support Windows hosts (Hyper-V)
> >
> >  drivers/net/ethernet/intel/ixgbevf/defines.h  |5 +
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf.h  |   11 ++
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   56 ++---
> >  drivers/net/ethernet/intel/ixgbevf/mbx.c  |   12 ++
> >  drivers/net/ethernet/intel/ixgbevf/vf.c   |  138
> +
> >  drivers/net/ethernet/intel/ixgbevf/vf.h   |2 +
> >  6 files changed, 206 insertions(+), 18 deletions(-)
> 
> Don't know how you butchered the mailing list address, but you did not
> send this series to intel-wired-...@lists.osuosl.org mailing list.
> Please address the requested changes that Mark suggested and resubmit
> to the correct mailing list please.

Will do.

Thanks,

K. Y

RE: [PATCH 2/3] phy: add generic function to support ksetting support

[Fugang Duan]

From: Philippe Reynes  Sent: Friday, April 15, 2016 6:35 AM
> To: da...@davemloft.net; de...@googlers.com; f.faine...@gmail.com; Fugang
> Duan 
> Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Philippe Reynes
> 
> Subject: [PATCH 2/3] phy: add generic function to support ksetting support
> 
> The old ethtool api (get_setting and set_setting) has generic phy functions
> phy_ethtool_sset and phy_ethtool_gset.
> To supprt the new ethtool api (get_link_ksettings and set_link_ksettings), we
> add generic phy function phy_ethtool_ksettings_get and
> phy_ethtool_ksettings_set.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/phy/phy.c |   81
> +
>  include/linux/phy.h   |4 ++
>  2 files changed, 85 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index
> 5590b9c..6f221c8 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -362,6 +362,60 @@ int phy_ethtool_sset(struct phy_device *phydev,
> struct ethtool_cmd *cmd)  }  EXPORT_SYMBOL(phy_ethtool_sset);
> 
> +int phy_ethtool_ksettings_set(struct phy_device *phydev,
> +   const struct ethtool_link_ksettings *cmd) {
> + u8 autoneg = cmd->base.autoneg;
> + u8 duplex = cmd->base.duplex;
> + u32 speed = cmd->base.speed;
> + u32 advertising;
> +
> + if (cmd->base.phy_address != phydev->mdio.addr)
> + return -EINVAL;
> +
> + ethtool_convert_link_mode_to_legacy_u32(,
> + cmd->link_modes.advertising);
> +
> + /* We make sure that we don't pass unsupported values in to the PHY */
> + advertising &= phydev->supported;
> +
> + /* Verify the settings we care about. */
> + if (autoneg != AUTONEG_ENABLE && autoneg != AUTONEG_DISABLE)
> + return -EINVAL;
> +
> + if (autoneg == AUTONEG_ENABLE && advertising == 0)
> + return -EINVAL;
> +
> + if (autoneg == AUTONEG_DISABLE &&
> + ((speed != SPEED_1000 &&
> +   speed != SPEED_100 &&
> +   speed != SPEED_10) ||
> +  (duplex != DUPLEX_HALF &&
> +   duplex != DUPLEX_FULL)))
> + return -EINVAL;
> +
> + phydev->autoneg = autoneg;
> +
> + phydev->speed = speed;
> +
> + phydev->advertising = advertising;
> +
> + if (autoneg == AUTONEG_ENABLE)
> + phydev->advertising |= ADVERTISED_Autoneg;
> + else
> + phydev->advertising &= ~ADVERTISED_Autoneg;
> +
> + phydev->duplex = duplex;
> +
> + phydev->mdix = cmd->base.eth_tp_mdix_ctrl;
> +
> + /* Restart the PHY */
> + phy_start_aneg(phydev);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(phy_ethtool_ksettings_set);
> +
>  int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd)  {
>   cmd->supported = phydev->supported;
> @@ -385,6 +439,33 @@ int phy_ethtool_gset(struct phy_device *phydev,
> struct ethtool_cmd *cmd)  }  EXPORT_SYMBOL(phy_ethtool_gset);
> 
> +int phy_ethtool_ksettings_get(struct phy_device *phydev,
> +   struct ethtool_link_ksettings *cmd) {
> + ethtool_convert_legacy_u32_to_link_mode(cmd-
> >link_modes.supported,
> + phydev->supported);
> +
> + ethtool_convert_legacy_u32_to_link_mode(cmd-
> >link_modes.advertising,
> + phydev->advertising);
> +
> + ethtool_convert_legacy_u32_to_link_mode(cmd-
> >link_modes.lp_advertising,
> + phydev->lp_advertising);
> +
> + cmd->base.speed = phydev->speed;
> + cmd->base.duplex = phydev->duplex;
> + if (phydev->interface == PHY_INTERFACE_MODE_MOCA)
> + cmd->base.port = PORT_BNC;
> + else
> + cmd->base.port = PORT_MII;
> +
> + cmd->base.phy_address = phydev->mdio.addr;
> + cmd->base.autoneg = phydev->autoneg;
> + cmd->base.eth_tp_mdix_ctrl = phydev->mdix;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(phy_ethtool_ksettings_get);
> +
>  /**
>   * phy_mii_ioctl - generic PHY MII ioctl interface
>   * @phydev: the phy_device struct
> diff --git a/include/linux/phy.h b/include/linux/phy.h index 2abd791..be3f83b
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -805,6 +805,10 @@ void phy_start_machine(struct phy_device *phydev);
> void phy_stop_machine(struct phy_device *phydev);  int
> phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);  int
> phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
> +int phy_ethtool_ksettings_get(struct phy_device *phydev,
> +   struct ethtool_link_ksettings *cmd); int
> +phy_ethtool_ksettings_set(struct phy_device *phydev,
> +   const struct ethtool_link_ksettings *cmd);
>  int phy_mii_ioctl(struct phy_device *phydev, 

RE: [PATCH 2/3] phy: add generic function to support ksetting support

[Fugang Duan]

From: Philippe Reynes  Sent: Friday, April 15, 2016 6:35 AM
> To: da...@davemloft.net; de...@googlers.com; f.faine...@gmail.com; Fugang
> Duan 
> Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Philippe Reynes
> 
> Subject: [PATCH 2/3] phy: add generic function to support ksetting support
> 
> The old ethtool api (get_setting and set_setting) has generic phy functions
> phy_ethtool_sset and phy_ethtool_gset.
> To supprt the new ethtool api (get_link_ksettings and set_link_ksettings), we
> add generic phy function phy_ethtool_ksettings_get and
> phy_ethtool_ksettings_set.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/phy/phy.c |   81
> +
>  include/linux/phy.h   |4 ++
>  2 files changed, 85 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index
> 5590b9c..6f221c8 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -362,6 +362,60 @@ int phy_ethtool_sset(struct phy_device *phydev,
> struct ethtool_cmd *cmd)  }  EXPORT_SYMBOL(phy_ethtool_sset);
> 
> +int phy_ethtool_ksettings_set(struct phy_device *phydev,
> +   const struct ethtool_link_ksettings *cmd) {
> + u8 autoneg = cmd->base.autoneg;
> + u8 duplex = cmd->base.duplex;
> + u32 speed = cmd->base.speed;
> + u32 advertising;
> +
> + if (cmd->base.phy_address != phydev->mdio.addr)
> + return -EINVAL;
> +
> + ethtool_convert_link_mode_to_legacy_u32(,
> + cmd->link_modes.advertising);
> +
> + /* We make sure that we don't pass unsupported values in to the PHY */
> + advertising &= phydev->supported;
> +
> + /* Verify the settings we care about. */
> + if (autoneg != AUTONEG_ENABLE && autoneg != AUTONEG_DISABLE)
> + return -EINVAL;
> +
> + if (autoneg == AUTONEG_ENABLE && advertising == 0)
> + return -EINVAL;
> +
> + if (autoneg == AUTONEG_DISABLE &&
> + ((speed != SPEED_1000 &&
> +   speed != SPEED_100 &&
> +   speed != SPEED_10) ||
> +  (duplex != DUPLEX_HALF &&
> +   duplex != DUPLEX_FULL)))
> + return -EINVAL;
> +
> + phydev->autoneg = autoneg;
> +
> + phydev->speed = speed;
> +
> + phydev->advertising = advertising;
> +
> + if (autoneg == AUTONEG_ENABLE)
> + phydev->advertising |= ADVERTISED_Autoneg;
> + else
> + phydev->advertising &= ~ADVERTISED_Autoneg;
> +
> + phydev->duplex = duplex;
> +
> + phydev->mdix = cmd->base.eth_tp_mdix_ctrl;
> +
> + /* Restart the PHY */
> + phy_start_aneg(phydev);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(phy_ethtool_ksettings_set);
> +
>  int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd)  {
>   cmd->supported = phydev->supported;
> @@ -385,6 +439,33 @@ int phy_ethtool_gset(struct phy_device *phydev,
> struct ethtool_cmd *cmd)  }  EXPORT_SYMBOL(phy_ethtool_gset);
> 
> +int phy_ethtool_ksettings_get(struct phy_device *phydev,
> +   struct ethtool_link_ksettings *cmd) {
> + ethtool_convert_legacy_u32_to_link_mode(cmd-
> >link_modes.supported,
> + phydev->supported);
> +
> + ethtool_convert_legacy_u32_to_link_mode(cmd-
> >link_modes.advertising,
> + phydev->advertising);
> +
> + ethtool_convert_legacy_u32_to_link_mode(cmd-
> >link_modes.lp_advertising,
> + phydev->lp_advertising);
> +
> + cmd->base.speed = phydev->speed;
> + cmd->base.duplex = phydev->duplex;
> + if (phydev->interface == PHY_INTERFACE_MODE_MOCA)
> + cmd->base.port = PORT_BNC;
> + else
> + cmd->base.port = PORT_MII;
> +
> + cmd->base.phy_address = phydev->mdio.addr;
> + cmd->base.autoneg = phydev->autoneg;
> + cmd->base.eth_tp_mdix_ctrl = phydev->mdix;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(phy_ethtool_ksettings_get);
> +
>  /**
>   * phy_mii_ioctl - generic PHY MII ioctl interface
>   * @phydev: the phy_device struct
> diff --git a/include/linux/phy.h b/include/linux/phy.h index 2abd791..be3f83b
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -805,6 +805,10 @@ void phy_start_machine(struct phy_device *phydev);
> void phy_stop_machine(struct phy_device *phydev);  int
> phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);  int
> phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
> +int phy_ethtool_ksettings_get(struct phy_device *phydev,
> +   struct ethtool_link_ksettings *cmd); int
> +phy_ethtool_ksettings_set(struct phy_device *phydev,
> +   const struct ethtool_link_ksettings *cmd);
>  int phy_mii_ioctl(struct phy_device *phydev, struct ifreq *ifr, int cmd);  
> int
> phy_start_interrupts(struct phy_device 

RE: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

[KY Srinivasan]

> -Original Message-
> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> Sent: Thursday, April 14, 2016 4:18 PM
> To: KY Srinivasan 
> Cc: David Miller ; Netdev
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; Robo Bot
> ; Jason Wang ;
> e...@mellanox.com; ja...@mellanox.com; yevge...@mellanox.com; John
> Ronciak ; intel-wired-lan  l...@lists.osuosl.org>
> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
> (Hyper-V)
> 
> On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan 
> wrote:
> > On Hyper-V, the VF/PF communication is a via software mediated path
> > as opposed to the hardware mailbox. Make the necessary
> > adjustments to support Hyper-V.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf.h  |   11 ++
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   56 ++---
> >  drivers/net/ethernet/intel/ixgbevf/mbx.c  |   12 ++
> >  drivers/net/ethernet/intel/ixgbevf/vf.c   |  138
> +
> >  drivers/net/ethernet/intel/ixgbevf/vf.h   |2 +
> >  5 files changed, 201 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > index 5ac60ee..f8d2a0b 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > @@ -460,9 +460,13 @@ enum ixbgevf_state_t {
> >
> >  enum ixgbevf_boards {
> > board_82599_vf,
> > +   board_82599_vf_hv,
> > board_X540_vf,
> > +   board_X540_vf_hv,
> > board_X550_vf,
> > +   board_X550_vf_hv,
> > board_X550EM_x_vf,
> > +   board_X550EM_x_vf_hv,
> >  };
> >
> >  enum ixgbevf_xcast_modes {
> > @@ -477,6 +481,13 @@ extern const struct ixgbevf_info
> ixgbevf_X550_vf_info;
> >  extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
> >  extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
> >
> > +
> > +extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
> > +extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
> > +
> >  /* needed by ethtool.c */
> >  extern const char ixgbevf_driver_name[];
> >  extern const char ixgbevf_driver_version[];
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > index 007cbe0..4a0ffac 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > @@ -49,6 +49,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "ixgbevf.h"
> >
> > @@ -62,10 +63,14 @@ static char ixgbevf_copyright[] =
> > "Copyright (c) 2009 - 2015 Intel Corporation.";
> >
> >  static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> > -   [board_82599_vf] = _82599_vf_info,
> > -   [board_X540_vf]  = _X540_vf_info,
> > -   [board_X550_vf]  = _X550_vf_info,
> > -   [board_X550EM_x_vf] = _X550EM_x_vf_info,
> > +   [board_82599_vf]= _82599_vf_info,
> > +   [board_82599_vf_hv] = _82599_vf_hv_info,
> > +   [board_X540_vf] = _X540_vf_info,
> > +   [board_X540_vf_hv]  = _X540_vf_hv_info,
> > +   [board_X550_vf] = _X550_vf_info,
> > +   [board_X550_vf_hv]  = _X550_vf_hv_info,
> > +   [board_X550EM_x_vf] = _X550EM_x_vf_info,
> > +   [board_X550EM_x_vf_hv]  = _X550EM_x_vf_hv_info,
> >  };
> >
> >  /* ixgbevf_pci_tbl - PCI Device ID Table
> > @@ -78,9 +83,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] =
> {
> >   */
> >  static const struct pci_device_id ixgbevf_pci_tbl[] = {
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
> > +   {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV),
> board_82599_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
> > +   {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV),
> board_X540_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
> > +   {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV),
> board_X550_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF),
> board_X550EM_x_vf },
> > +   {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV),
> board_X550EM_x_vf_hv},
> > /* required last entry */
> > {0, }
> >  };
> > @@ -1809,12 +1818,13 @@ static int ixgbevf_vlan_rx_add_vid(struct
> net_device *netdev,
> >  {
> > struct ixgbevf_adapter *adapter = netdev_priv(netdev);
> > struct ixgbe_hw *hw = >hw;
> > -   int err;
> > +   

RE: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

[KY Srinivasan]

> -Original Message-
> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> Sent: Thursday, April 14, 2016 4:18 PM
> To: KY Srinivasan 
> Cc: David Miller ; Netdev
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; Robo Bot
> ; Jason Wang ;
> e...@mellanox.com; ja...@mellanox.com; yevge...@mellanox.com; John
> Ronciak ; intel-wired-lan  l...@lists.osuosl.org>
> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts
> (Hyper-V)
> 
> On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan 
> wrote:
> > On Hyper-V, the VF/PF communication is a via software mediated path
> > as opposed to the hardware mailbox. Make the necessary
> > adjustments to support Hyper-V.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf.h  |   11 ++
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   56 ++---
> >  drivers/net/ethernet/intel/ixgbevf/mbx.c  |   12 ++
> >  drivers/net/ethernet/intel/ixgbevf/vf.c   |  138
> +
> >  drivers/net/ethernet/intel/ixgbevf/vf.h   |2 +
> >  5 files changed, 201 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > index 5ac60ee..f8d2a0b 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> > @@ -460,9 +460,13 @@ enum ixbgevf_state_t {
> >
> >  enum ixgbevf_boards {
> > board_82599_vf,
> > +   board_82599_vf_hv,
> > board_X540_vf,
> > +   board_X540_vf_hv,
> > board_X550_vf,
> > +   board_X550_vf_hv,
> > board_X550EM_x_vf,
> > +   board_X550EM_x_vf_hv,
> >  };
> >
> >  enum ixgbevf_xcast_modes {
> > @@ -477,6 +481,13 @@ extern const struct ixgbevf_info
> ixgbevf_X550_vf_info;
> >  extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
> >  extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
> >
> > +
> > +extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
> > +extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
> > +extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
> > +
> >  /* needed by ethtool.c */
> >  extern const char ixgbevf_driver_name[];
> >  extern const char ixgbevf_driver_version[];
> > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > index 007cbe0..4a0ffac 100644
> > --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> > @@ -49,6 +49,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "ixgbevf.h"
> >
> > @@ -62,10 +63,14 @@ static char ixgbevf_copyright[] =
> > "Copyright (c) 2009 - 2015 Intel Corporation.";
> >
> >  static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> > -   [board_82599_vf] = _82599_vf_info,
> > -   [board_X540_vf]  = _X540_vf_info,
> > -   [board_X550_vf]  = _X550_vf_info,
> > -   [board_X550EM_x_vf] = _X550EM_x_vf_info,
> > +   [board_82599_vf]= _82599_vf_info,
> > +   [board_82599_vf_hv] = _82599_vf_hv_info,
> > +   [board_X540_vf] = _X540_vf_info,
> > +   [board_X540_vf_hv]  = _X540_vf_hv_info,
> > +   [board_X550_vf] = _X550_vf_info,
> > +   [board_X550_vf_hv]  = _X550_vf_hv_info,
> > +   [board_X550EM_x_vf] = _X550EM_x_vf_info,
> > +   [board_X550EM_x_vf_hv]  = _X550EM_x_vf_hv_info,
> >  };
> >
> >  /* ixgbevf_pci_tbl - PCI Device ID Table
> > @@ -78,9 +83,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] =
> {
> >   */
> >  static const struct pci_device_id ixgbevf_pci_tbl[] = {
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
> > +   {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV),
> board_82599_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
> > +   {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV),
> board_X540_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
> > +   {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV),
> board_X550_vf_hv },
> > {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF),
> board_X550EM_x_vf },
> > +   {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV),
> board_X550EM_x_vf_hv},
> > /* required last entry */
> > {0, }
> >  };
> > @@ -1809,12 +1818,13 @@ static int ixgbevf_vlan_rx_add_vid(struct
> net_device *netdev,
> >  {
> > struct ixgbevf_adapter *adapter = netdev_priv(netdev);
> > struct ixgbe_hw *hw = >hw;
> > -   int err;
> > +   int err = 0;
> >
> > spin_lock_bh(>mbx_lock);
> >
> > /* add VID to filter table */
> > -   err = hw->mac.ops.set_vfta(hw, vid, 0, true);
> > +   

Re: [PATCH] mpt3sas: Remove usage of 'struct timeval'

[Martin K. Petersen]

> "Tina" == Tina Ruchandani  writes:

Tina> 'struct timeval' will have its tv_sec value overflow on 32-bit
Tina> systems in year 2038 and beyond. This patch replaces the use of
Tina> struct timeval for computing mpi_request.TimeStamp, and instead
Tina> uses ktime_t which provides 64-bit seconds value. The timestamp
Tina> computed remains unaffected (milliseconds since Unix epoch).

Broadcom folks, please review.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] mpt3sas: Remove usage of 'struct timeval'

[Martin K. Petersen]

> "Tina" == Tina Ruchandani  writes:

Tina> 'struct timeval' will have its tv_sec value overflow on 32-bit
Tina> systems in year 2038 and beyond. This patch replaces the use of
Tina> struct timeval for computing mpi_request.TimeStamp, and instead
Tina> uses ktime_t which provides 64-bit seconds value. The timestamp
Tina> computed remains unaffected (milliseconds since Unix epoch).

Broadcom folks, please review.

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v2 2/6] ARM: xen: Register with kernel restart handler

[Guenter Roeck]

Register with kernel restart handler instead of setting arm_pm_restart
directly.

Select a high priority of 192 to ensure that default restart handlers
are replaced if Xen is running.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

 arch/arm/xen/enlighten.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd7345c654..76a1d12fd27e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -193,14 +194,22 @@ after_register_vcpu_info:
put_cpu();
 }
 
-static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
+static int xen_restart(struct notifier_block *nb, unsigned long action,
+  void *data)
 {
struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
int rc;
rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, );
BUG_ON(rc);
+
+   return NOTIFY_DONE;
 }
 
+static struct notifier_block xen_restart_nb = {
+   .notifier_call = xen_restart,
+   .priority = 192,
+};
+
 static void xen_power_off(void)
 {
struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
@@ -370,7 +379,7 @@ static int __init xen_pm_init(void)
return -ENODEV;
 
pm_power_off = xen_power_off;
-   arm_pm_restart = xen_restart;
+   register_restart_handler(_restart_nb);
if (!xen_initial_domain()) {
struct timespec64 ts;
xen_read_wallclock();
-- 
2.5.0

[PATCH v2 3/6] ARM: PSCI: Register with kernel restart handler

[Guenter Roeck]

Register with kernel restart handler instead of setting arm_pm_restart
directly. This enables support for replacing the PSCI restart handler
with a different handler if necessary for a specific board.

Select a priority of 129 to indicate a higher than default priority, but
keep it as low as possible since PSCI reset is known to fail on some
boards.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by/Tested-by tags
Variable name change: np -> nb

 drivers/firmware/psci.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 11bfee8b79a9..a0f71480f145 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -231,11 +231,18 @@ static int get_set_conduit_method(struct device_node *np)
return 0;
 }
 
-static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
+static int psci_sys_reset(struct notifier_block *nb, unsigned long action,
+ void *data)
 {
invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+   return NOTIFY_DONE;
 }
 
+static struct notifier_block psci_sys_reset_nb = {
+   .notifier_call = psci_sys_reset,
+   .priority = 129,
+};
+
 static void psci_sys_poweroff(void)
 {
invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
@@ -461,7 +468,7 @@ static void __init psci_0_2_set_functions(void)
 
psci_ops.migrate_info_type = psci_migrate_info_type;
 
-   arm_pm_restart = psci_sys_reset;
+   register_restart_handler(_sys_reset_nb);
 
pm_power_off = psci_sys_poweroff;
 }
-- 
2.5.0

[PATCH v2 0/6] ARM/ARM64: Drop arm_pm_restart

[Guenter Roeck]

This is the final push to replace arm_pm_restart with the kernel restart
handler. Finally drop arm_pm_restart after it is no longer used.

---
v2: Rebased to v4.6-rc3
Added Reviewed-by/Acked/by/Tested-by tags
Variable name change in patch 3/6.


Guenter Roeck (6):
  ARM: prima2: Register with kernel restart handler
  ARM: xen: Register with kernel restart handler
  ARM: PSCI: Register with kernel restart handler
  ARM: Register with kernel restart handler
  ARM64: Remove arm_pm_restart
  ARM: Remove arm_pm_restart

 arch/arm/include/asm/system_misc.h   |  1 -
 arch/arm/kernel/reboot.c |  6 +-
 arch/arm/kernel/setup.c  | 20 ++--
 arch/arm/mach-prima2/rstc.c  | 11 +--
 arch/arm/xen/enlighten.c | 13 +++--
 arch/arm64/include/asm/system_misc.h |  2 --
 arch/arm64/kernel/process.c  |  7 +--
 drivers/firmware/psci.c  | 11 +--
 8 files changed, 49 insertions(+), 22 deletions(-)

[PATCH v2 2/6] ARM: xen: Register with kernel restart handler

[Guenter Roeck]

Register with kernel restart handler instead of setting arm_pm_restart
directly.

Select a high priority of 192 to ensure that default restart handlers
are replaced if Xen is running.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

 arch/arm/xen/enlighten.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd7345c654..76a1d12fd27e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -193,14 +194,22 @@ after_register_vcpu_info:
put_cpu();
 }
 
-static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
+static int xen_restart(struct notifier_block *nb, unsigned long action,
+  void *data)
 {
struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
int rc;
rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, );
BUG_ON(rc);
+
+   return NOTIFY_DONE;
 }
 
+static struct notifier_block xen_restart_nb = {
+   .notifier_call = xen_restart,
+   .priority = 192,
+};
+
 static void xen_power_off(void)
 {
struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
@@ -370,7 +379,7 @@ static int __init xen_pm_init(void)
return -ENODEV;
 
pm_power_off = xen_power_off;
-   arm_pm_restart = xen_restart;
+   register_restart_handler(_restart_nb);
if (!xen_initial_domain()) {
struct timespec64 ts;
xen_read_wallclock();
-- 
2.5.0

[PATCH v2 3/6] ARM: PSCI: Register with kernel restart handler

[Guenter Roeck]

Register with kernel restart handler instead of setting arm_pm_restart
directly. This enables support for replacing the PSCI restart handler
with a different handler if necessary for a specific board.

Select a priority of 129 to indicate a higher than default priority, but
keep it as low as possible since PSCI reset is known to fail on some
boards.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by/Tested-by tags
Variable name change: np -> nb

 drivers/firmware/psci.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 11bfee8b79a9..a0f71480f145 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -231,11 +231,18 @@ static int get_set_conduit_method(struct device_node *np)
return 0;
 }
 
-static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
+static int psci_sys_reset(struct notifier_block *nb, unsigned long action,
+ void *data)
 {
invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+   return NOTIFY_DONE;
 }
 
+static struct notifier_block psci_sys_reset_nb = {
+   .notifier_call = psci_sys_reset,
+   .priority = 129,
+};
+
 static void psci_sys_poweroff(void)
 {
invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
@@ -461,7 +468,7 @@ static void __init psci_0_2_set_functions(void)
 
psci_ops.migrate_info_type = psci_migrate_info_type;
 
-   arm_pm_restart = psci_sys_reset;
+   register_restart_handler(_sys_reset_nb);
 
pm_power_off = psci_sys_poweroff;
 }
-- 
2.5.0

[PATCH v2 0/6] ARM/ARM64: Drop arm_pm_restart

[Guenter Roeck]

This is the final push to replace arm_pm_restart with the kernel restart
handler. Finally drop arm_pm_restart after it is no longer used.

---
v2: Rebased to v4.6-rc3
Added Reviewed-by/Acked/by/Tested-by tags
Variable name change in patch 3/6.


Guenter Roeck (6):
  ARM: prima2: Register with kernel restart handler
  ARM: xen: Register with kernel restart handler
  ARM: PSCI: Register with kernel restart handler
  ARM: Register with kernel restart handler
  ARM64: Remove arm_pm_restart
  ARM: Remove arm_pm_restart

 arch/arm/include/asm/system_misc.h   |  1 -
 arch/arm/kernel/reboot.c |  6 +-
 arch/arm/kernel/setup.c  | 20 ++--
 arch/arm/mach-prima2/rstc.c  | 11 +--
 arch/arm/xen/enlighten.c | 13 +++--
 arch/arm64/include/asm/system_misc.h |  2 --
 arch/arm64/kernel/process.c  |  7 +--
 drivers/firmware/psci.c  | 11 +--
 8 files changed, 49 insertions(+), 22 deletions(-)

Re: [PATCH] mpt3sas: fix possible NULL dereference

[Martin K. Petersen]

> "Sudip" == Sudip Mukherjee  writes:

Sudip> We are dereferencing ioc->sense_dma_pool in pci_pool_free() and
Sudip> after that we are checking if it is NULL, before calling
Sudip> pci_pool_destroy().  Lets check if it is NULL before calling both
Sudip> pci_pool_free() and pci_pool_destroy().

Broadcom folks, please review.

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v2 4/6] ARM: Register with kernel restart handler

[Guenter Roeck]

By making use of the kernel restart handler, board specific restart
handlers can be prioritized amongst available mechanisms for a particular
board or system.

Select the default priority of 128 to indicate that the restart callback
in the machine description is the default restart mechanism.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

 arch/arm/kernel/setup.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index a28fce0bdbbe..735e6a2ce216 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1004,6 +1004,20 @@ void __init hyp_mode_check(void)
 #endif
 }
 
+static void (*__arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
+
+static int arm_restart(struct notifier_block *nb, unsigned long action,
+  void *data)
+{
+   __arm_pm_restart(action, data);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block arm_restart_nb = {
+   .notifier_call = arm_restart,
+   .priority = 128,
+};
+
 void __init setup_arch(char **cmdline_p)
 {
const struct machine_desc *mdesc;
@@ -1046,8 +1060,10 @@ void __init setup_arch(char **cmdline_p)
paging_init(mdesc);
request_standard_resources(mdesc);
 
-   if (mdesc->restart)
-   arm_pm_restart = mdesc->restart;
+   if (mdesc->restart) {
+   __arm_pm_restart = mdesc->restart;
+   register_restart_handler(_restart_nb);
+   }
 
unflatten_device_tree();
 
-- 
2.5.0

Re: [PATCH] mpt3sas: fix possible NULL dereference

[Martin K. Petersen]

> "Sudip" == Sudip Mukherjee  writes:

Sudip> We are dereferencing ioc->sense_dma_pool in pci_pool_free() and
Sudip> after that we are checking if it is NULL, before calling
Sudip> pci_pool_destroy().  Lets check if it is NULL before calling both
Sudip> pci_pool_free() and pci_pool_destroy().

Broadcom folks, please review.

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v2 4/6] ARM: Register with kernel restart handler

[Guenter Roeck]

By making use of the kernel restart handler, board specific restart
handlers can be prioritized amongst available mechanisms for a particular
board or system.

Select the default priority of 128 to indicate that the restart callback
in the machine description is the default restart mechanism.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

 arch/arm/kernel/setup.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index a28fce0bdbbe..735e6a2ce216 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1004,6 +1004,20 @@ void __init hyp_mode_check(void)
 #endif
 }
 
+static void (*__arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
+
+static int arm_restart(struct notifier_block *nb, unsigned long action,
+  void *data)
+{
+   __arm_pm_restart(action, data);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block arm_restart_nb = {
+   .notifier_call = arm_restart,
+   .priority = 128,
+};
+
 void __init setup_arch(char **cmdline_p)
 {
const struct machine_desc *mdesc;
@@ -1046,8 +1060,10 @@ void __init setup_arch(char **cmdline_p)
paging_init(mdesc);
request_standard_resources(mdesc);
 
-   if (mdesc->restart)
-   arm_pm_restart = mdesc->restart;
+   if (mdesc->restart) {
+   __arm_pm_restart = mdesc->restart;
+   register_restart_handler(_restart_nb);
+   }
 
unflatten_device_tree();
 
-- 
2.5.0

[PATCH v2 6/6] ARM: Remove arm_pm_restart

[Guenter Roeck]

All users of arm_pm_restart have been converted to use the kernel restart
handler.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

 arch/arm/include/asm/system_misc.h | 1 -
 arch/arm/kernel/reboot.c   | 6 +-
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/system_misc.h 
b/arch/arm/include/asm/system_misc.h
index a3d61ad984af..6c952538f1e8 100644
--- a/arch/arm/include/asm/system_misc.h
+++ b/arch/arm/include/asm/system_misc.h
@@ -11,7 +11,6 @@
 extern void cpu_init(void);
 
 void soft_restart(unsigned long);
-extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 extern void (*arm_pm_idle)(void);
 
 #define UDBG_UNDEFINED (1 << 0)
diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
index 71a2ff9ec490..4785c39ee3eb 100644
--- a/arch/arm/kernel/reboot.c
+++ b/arch/arm/kernel/reboot.c
@@ -20,7 +20,6 @@ typedef void (*phys_reset_t)(unsigned long);
 /*
  * Function pointers to optional machine specific functions
  */
-void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 void (*pm_power_off)(void);
 EXPORT_SYMBOL(pm_power_off);
 
@@ -140,10 +139,7 @@ void machine_restart(char *cmd)
local_irq_disable();
smp_send_stop();
 
-   if (arm_pm_restart)
-   arm_pm_restart(reboot_mode, cmd);
-   else
-   do_kernel_restart(cmd);
+   do_kernel_restart(cmd);
 
/* Give a grace period for failure to restart of 1s */
mdelay(1000);
-- 
2.5.0

[PATCH v2 6/6] ARM: Remove arm_pm_restart

[Guenter Roeck]

All users of arm_pm_restart have been converted to use the kernel restart
handler.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

 arch/arm/include/asm/system_misc.h | 1 -
 arch/arm/kernel/reboot.c   | 6 +-
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/system_misc.h 
b/arch/arm/include/asm/system_misc.h
index a3d61ad984af..6c952538f1e8 100644
--- a/arch/arm/include/asm/system_misc.h
+++ b/arch/arm/include/asm/system_misc.h
@@ -11,7 +11,6 @@
 extern void cpu_init(void);
 
 void soft_restart(unsigned long);
-extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 extern void (*arm_pm_idle)(void);
 
 #define UDBG_UNDEFINED (1 << 0)
diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
index 71a2ff9ec490..4785c39ee3eb 100644
--- a/arch/arm/kernel/reboot.c
+++ b/arch/arm/kernel/reboot.c
@@ -20,7 +20,6 @@ typedef void (*phys_reset_t)(unsigned long);
 /*
  * Function pointers to optional machine specific functions
  */
-void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 void (*pm_power_off)(void);
 EXPORT_SYMBOL(pm_power_off);
 
@@ -140,10 +139,7 @@ void machine_restart(char *cmd)
local_irq_disable();
smp_send_stop();
 
-   if (arm_pm_restart)
-   arm_pm_restart(reboot_mode, cmd);
-   else
-   do_kernel_restart(cmd);
+   do_kernel_restart(cmd);
 
/* Give a grace period for failure to restart of 1s */
mdelay(1000);
-- 
2.5.0

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

[Mike Galbraith]

On Thu, 2016-04-14 at 15:57 -0400, Tejun Heo wrote:
> Hello, Mike.
> 
> On Thu, Apr 14, 2016 at 08:07:37AM +0200, Mike Galbraith wrote:
> > Let /foo be an exclusive cpuset containing exclusive subset bar.
> > How can any task acquire set foo affinity if B really really
> > applies?  My box calls me a dummy if I try to create a "proper"
> > home
> > for tasks, one with both no snobby neighbors and proper affinity.
> 
> I'm not sure I quite understand what you're saying.  Are you referring
> to the cpuset.{cpu|mem}_exclusive knobs?

Yes.

-Mike

[PATCH v2 1/6] ARM: prima2: Register with kernel restart handler

[Guenter Roeck]

Register with kernel restart handler instead of setting arm_pm_restart
directly. By doing this, the prima2 reset handler can be prioritized
among other restart methods available on a particular board.

Select a high priority of 192 since the original code overwrites the
default arm restart handler.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

 arch/arm/mach-prima2/rstc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-prima2/rstc.c b/arch/arm/mach-prima2/rstc.c
index 7c251eb11d01..1639997c5b49 100644
--- a/arch/arm/mach-prima2/rstc.c
+++ b/arch/arm/mach-prima2/rstc.c
@@ -65,11 +65,18 @@ static struct reset_controller_dev sirfsoc_reset_controller 
= {
 
 #define SIRFSOC_SYS_RST_BIT  BIT(31)
 
-static void sirfsoc_restart(enum reboot_mode mode, const char *cmd)
+static int sirfsoc_restart(struct notifier_block *nb, unsigned long action,
+  void *data)
 {
writel(SIRFSOC_SYS_RST_BIT, sirfsoc_rstc_base);
+   return NOTIFY_DONE;
 }
 
+static struct notifier_block sirfsoc_restart_nb = {
+   .notifier_call  = sirfsoc_restart,
+   .priority   = 192,
+};
+
 static int sirfsoc_rstc_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -80,7 +87,7 @@ static int sirfsoc_rstc_probe(struct platform_device *pdev)
}
 
sirfsoc_reset_controller.of_node = np;
-   arm_pm_restart = sirfsoc_restart;
+   register_restart_handler(_restart_nb);
 
if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
reset_controller_register(_reset_controller);
-- 
2.5.0

[PATCH v2 5/6] ARM64: Remove arm_pm_restart

[Guenter Roeck]

All users of arm_pm_restart have been converted to use the kernel restart
handler.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Acked-by: Catalin Marinas 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by/Tested-by tags

 arch/arm64/include/asm/system_misc.h | 2 --
 arch/arm64/kernel/process.c  | 7 +--
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/system_misc.h 
b/arch/arm64/include/asm/system_misc.h
index 57f110bea6a8..f1d865b7d38d 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -43,8 +43,6 @@ struct mm_struct;
 extern void show_pte(struct mm_struct *mm, unsigned long addr);
 extern void __show_regs(struct pt_regs *);
 
-extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
-
 #define show_unhandled_signals_ratelimited()   \
 ({ \
static DEFINE_RATELIMIT_STATE(_rs,  \
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 80624829db61..29c29984eca0 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -66,8 +66,6 @@ EXPORT_SYMBOL(__stack_chk_guard);
 void (*pm_power_off)(void);
 EXPORT_SYMBOL_GPL(pm_power_off);
 
-void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
-
 /*
  * This is our default idle handler.
  */
@@ -153,10 +151,7 @@ void machine_restart(char *cmd)
efi_reboot(reboot_mode, NULL);
 
/* Now call the architecture specific reboot code. */
-   if (arm_pm_restart)
-   arm_pm_restart(reboot_mode, cmd);
-   else
-   do_kernel_restart(cmd);
+   do_kernel_restart(cmd);
 
/*
 * Whoops - the architecture was unable to reboot.
-- 
2.5.0

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

[Mike Galbraith]

On Thu, 2016-04-14 at 15:57 -0400, Tejun Heo wrote:
> Hello, Mike.
> 
> On Thu, Apr 14, 2016 at 08:07:37AM +0200, Mike Galbraith wrote:
> > Let /foo be an exclusive cpuset containing exclusive subset bar.
> > How can any task acquire set foo affinity if B really really
> > applies?  My box calls me a dummy if I try to create a "proper"
> > home
> > for tasks, one with both no snobby neighbors and proper affinity.
> 
> I'm not sure I quite understand what you're saying.  Are you referring
> to the cpuset.{cpu|mem}_exclusive knobs?

Yes.

-Mike

[PATCH v2 1/6] ARM: prima2: Register with kernel restart handler

[Guenter Roeck]

Register with kernel restart handler instead of setting arm_pm_restart
directly. By doing this, the prima2 reset handler can be prioritized
among other restart methods available on a particular board.

Select a high priority of 192 since the original code overwrites the
default arm restart handler.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

 arch/arm/mach-prima2/rstc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-prima2/rstc.c b/arch/arm/mach-prima2/rstc.c
index 7c251eb11d01..1639997c5b49 100644
--- a/arch/arm/mach-prima2/rstc.c
+++ b/arch/arm/mach-prima2/rstc.c
@@ -65,11 +65,18 @@ static struct reset_controller_dev sirfsoc_reset_controller 
= {
 
 #define SIRFSOC_SYS_RST_BIT  BIT(31)
 
-static void sirfsoc_restart(enum reboot_mode mode, const char *cmd)
+static int sirfsoc_restart(struct notifier_block *nb, unsigned long action,
+  void *data)
 {
writel(SIRFSOC_SYS_RST_BIT, sirfsoc_rstc_base);
+   return NOTIFY_DONE;
 }
 
+static struct notifier_block sirfsoc_restart_nb = {
+   .notifier_call  = sirfsoc_restart,
+   .priority   = 192,
+};
+
 static int sirfsoc_rstc_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -80,7 +87,7 @@ static int sirfsoc_rstc_probe(struct platform_device *pdev)
}
 
sirfsoc_reset_controller.of_node = np;
-   arm_pm_restart = sirfsoc_restart;
+   register_restart_handler(_restart_nb);
 
if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
reset_controller_register(_reset_controller);
-- 
2.5.0

[PATCH v2 5/6] ARM64: Remove arm_pm_restart

[Guenter Roeck]

All users of arm_pm_restart have been converted to use the kernel restart
handler.

Acked-by: Arnd Bergmann 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Acked-by: Catalin Marinas 
Signed-off-by: Guenter Roeck 
---
v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by/Tested-by tags

 arch/arm64/include/asm/system_misc.h | 2 --
 arch/arm64/kernel/process.c  | 7 +--
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/system_misc.h 
b/arch/arm64/include/asm/system_misc.h
index 57f110bea6a8..f1d865b7d38d 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -43,8 +43,6 @@ struct mm_struct;
 extern void show_pte(struct mm_struct *mm, unsigned long addr);
 extern void __show_regs(struct pt_regs *);
 
-extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
-
 #define show_unhandled_signals_ratelimited()   \
 ({ \
static DEFINE_RATELIMIT_STATE(_rs,  \
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 80624829db61..29c29984eca0 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -66,8 +66,6 @@ EXPORT_SYMBOL(__stack_chk_guard);
 void (*pm_power_off)(void);
 EXPORT_SYMBOL_GPL(pm_power_off);
 
-void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
-
 /*
  * This is our default idle handler.
  */
@@ -153,10 +151,7 @@ void machine_restart(char *cmd)
efi_reboot(reboot_mode, NULL);
 
/* Now call the architecture specific reboot code. */
-   if (arm_pm_restart)
-   arm_pm_restart(reboot_mode, cmd);
-   else
-   do_kernel_restart(cmd);
+   do_kernel_restart(cmd);
 
/*
 * Whoops - the architecture was unable to reboot.
-- 
2.5.0

[PATCH] libnvdimm, btt: add btt startup debug

[Dan Williams]

Report the reason for btt probe failures when debug is enabled.

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/btt.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index cc9fafed9362..68a7c3c1eed9 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -1383,11 +1383,15 @@ int nvdimm_namespace_attach_btt(struct 
nd_namespace_common *ndns)
struct btt *btt;
size_t rawsize;
 
-   if (!nd_btt->uuid || !nd_btt->ndns || !nd_btt->lbasize)
+   if (!nd_btt->uuid || !nd_btt->ndns || !nd_btt->lbasize) {
+   dev_dbg(_btt->dev, "incomplete btt configuration\n");
return -ENODEV;
+   }
 
rawsize = nvdimm_namespace_capacity(ndns) - SZ_4K;
if (rawsize < ARENA_MIN_SIZE) {
+   dev_dbg(_btt->dev, "%s must be at least %ld bytes\n",
+   dev_name(>dev), ARENA_MIN_SIZE + SZ_4K);
return -ENXIO;
}
nd_region = to_nd_region(nd_btt->dev.parent);

[PATCH] libnvdimm, pmem: clarify the write+clear_poison+write flow

[Dan Williams]

The ACPI specification does not specify the state of data after a clear
poison operation.  Potential future libnvdimm bus implementations for
other architectures also might not specify or disagree on the state of
data after clear poison.  Clarify why we write twice.

Reported-by: Jeff Moyer 
Reported-by: Vishal Verma 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/pmem.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index c6befaa9c708..d9a0dbc2d023 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -86,6 +86,20 @@ static int pmem_do_bvec(struct pmem_device *pmem, struct 
page *page,
flush_dcache_page(page);
}
} else {
+   /*
+* Note that we write the data both before and after
+* clearing poison.  The write before clear poison
+* handles situations where the latest written data is
+* preserved and the clear poison operation simply marks
+* the address range as valid without changing the data.
+* In this case application software can assume that an
+* interrupted write will either return the new good
+* data or an error.
+*
+* However, if pmem_clear_poison() leaves the data in an
+* indeterminate state we need to perform the write
+* after clear poison.
+*/
flush_dcache_page(page);
memcpy_to_pmem(pmem_addr, mem + off, len);
if (unlikely(bad_pmem)) {

[PATCH] libnvdimm, btt: add btt startup debug

[Dan Williams]

Report the reason for btt probe failures when debug is enabled.

Signed-off-by: Dan Williams 
---
 drivers/nvdimm/btt.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index cc9fafed9362..68a7c3c1eed9 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -1383,11 +1383,15 @@ int nvdimm_namespace_attach_btt(struct 
nd_namespace_common *ndns)
struct btt *btt;
size_t rawsize;
 
-   if (!nd_btt->uuid || !nd_btt->ndns || !nd_btt->lbasize)
+   if (!nd_btt->uuid || !nd_btt->ndns || !nd_btt->lbasize) {
+   dev_dbg(_btt->dev, "incomplete btt configuration\n");
return -ENODEV;
+   }
 
rawsize = nvdimm_namespace_capacity(ndns) - SZ_4K;
if (rawsize < ARENA_MIN_SIZE) {
+   dev_dbg(_btt->dev, "%s must be at least %ld bytes\n",
+   dev_name(>dev), ARENA_MIN_SIZE + SZ_4K);
return -ENXIO;
}
nd_region = to_nd_region(nd_btt->dev.parent);

[PATCH] libnvdimm, pmem: clarify the write+clear_poison+write flow

[Dan Williams]

The ACPI specification does not specify the state of data after a clear
poison operation.  Potential future libnvdimm bus implementations for
other architectures also might not specify or disagree on the state of
data after clear poison.  Clarify why we write twice.

Reported-by: Jeff Moyer 
Reported-by: Vishal Verma 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/pmem.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index c6befaa9c708..d9a0dbc2d023 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -86,6 +86,20 @@ static int pmem_do_bvec(struct pmem_device *pmem, struct 
page *page,
flush_dcache_page(page);
}
} else {
+   /*
+* Note that we write the data both before and after
+* clearing poison.  The write before clear poison
+* handles situations where the latest written data is
+* preserved and the clear poison operation simply marks
+* the address range as valid without changing the data.
+* In this case application software can assume that an
+* interrupted write will either return the new good
+* data or an error.
+*
+* However, if pmem_clear_poison() leaves the data in an
+* indeterminate state we need to perform the write
+* after clear poison.
+*/
flush_dcache_page(page);
memcpy_to_pmem(pmem_addr, mem + off, len);
if (unlikely(bad_pmem)) {

Re: [PATCH] pm80xx: Remove bogus address masking in pm8001_ioremap()

[Martin K. Petersen]

> "David" == David Daney  writes:

David> It is unclear what the original intent of the masking was, but it
David> is clearly incorrect to truncate a physical address before
David> calling ioremap().  On systems where there are valid physical
David> address bits above bit-31 (arm64 for example) the result is an
David> eventual OOPs when initializing the driver.

David> Remove the bogus code to fix it.

Applied to 4.7/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] pm80xx: Remove bogus address masking in pm8001_ioremap()

[Martin K. Petersen]

> "David" == David Daney  writes:

David> It is unclear what the original intent of the masking was, but it
David> is clearly incorrect to truncate a physical address before
David> calling ioremap().  On systems where there are valid physical
David> address bits above bit-31 (arm64 for example) the result is an
David> eventual OOPs when initializing the driver.

David> Remove the bogus code to fix it.

Applied to 4.7/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH] platform/chrome: cros_ec_dev - Populate compat_ioctl

[Guenter Roeck]

compat_ioctl has to be populated for 32 bit userspace applications to work
with 64 bit kernels.

Signed-off-by: Guenter Roeck 
---
 drivers/platform/chrome/cros_ec_dev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec_dev.c 
b/drivers/platform/chrome/cros_ec_dev.c
index 6c45e0f5ba7b..903b1d8dcab7 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -208,6 +208,9 @@ static const struct file_operations fops = {
.release = ec_device_release,
.read = ec_device_read,
.unlocked_ioctl = ec_device_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl = ec_device_ioctl,
+#endif
 };
 
 static void __remove(struct device *dev)
-- 
2.5.0

[PATCH] platform/chrome: cros_ec_dev - Populate compat_ioctl

[Guenter Roeck]

compat_ioctl has to be populated for 32 bit userspace applications to work
with 64 bit kernels.

Signed-off-by: Guenter Roeck 
---
 drivers/platform/chrome/cros_ec_dev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec_dev.c 
b/drivers/platform/chrome/cros_ec_dev.c
index 6c45e0f5ba7b..903b1d8dcab7 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -208,6 +208,9 @@ static const struct file_operations fops = {
.release = ec_device_release,
.read = ec_device_read,
.unlocked_ioctl = ec_device_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl = ec_device_ioctl,
+#endif
 };
 
 static void __remove(struct device *dev)
-- 
2.5.0

Re: [PATCH v7 2/3] gpio: dwapb: convert device node to fwnode

[Kefeng Wang]

On 2016/4/6 15:07, qiujiang wrote:
> This patch converts device node to fwnode for dwapb driver, so
> as to provide a unified fwnode for DT and ACPI bindings.
> 
> Acked-by: Andy Shevchenko 
> Signed-off-by: qiujiang 
> ---
>  drivers/gpio/gpio-dwapb.c| 37 
> 
>  drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
>  include/linux/platform_data/gpio-dwapb.h |  2 +-
>  3 files changed, 20 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> index 91afec8..3c4d8e6 100644
> --- a/drivers/gpio/gpio-dwapb.c
> +++ b/drivers/gpio/gpio-dwapb.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -290,14 +291,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio 
> *gpio,
>struct dwapb_port_property *pp)
>  {
>   struct gpio_chip *gc = >gc;
> - struct device_node *node = pp->node;
> + struct fwnode_handle  *fwnode = pp->fwnode;
>   struct irq_chip_generic *irq_gc = NULL;
>   unsigned int hwirq, ngpio = gc->ngpio;
>   struct irq_chip_type *ct;
>   int err, i;
>  
> - gpio->domain = irq_domain_add_linear(node, ngpio,
> -  _generic_chip_ops, gpio);
> + gpio->domain = irq_domain_create_linear(fwnode, ngpio,
> +  _generic_chip_ops, gpio);
>   if (!gpio->domain)
>   return;
>  
> @@ -414,7 +415,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
>   }
>  
>  #ifdef CONFIG_OF_GPIO
> - port->gc.of_node = pp->node;
> + port->gc.of_node = is_of_node(pp->fwnode) ?
> + to_of_node(pp->fwnode) : NULL;

It is enough to use port->gc.of_node = to_of_node(pp->fwnode);

Re: [PATCH v7 2/3] gpio: dwapb: convert device node to fwnode

[Kefeng Wang]

On 2016/4/6 15:07, qiujiang wrote:
> This patch converts device node to fwnode for dwapb driver, so
> as to provide a unified fwnode for DT and ACPI bindings.
> 
> Acked-by: Andy Shevchenko 
> Signed-off-by: qiujiang 
> ---
>  drivers/gpio/gpio-dwapb.c| 37 
> 
>  drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
>  include/linux/platform_data/gpio-dwapb.h |  2 +-
>  3 files changed, 20 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> index 91afec8..3c4d8e6 100644
> --- a/drivers/gpio/gpio-dwapb.c
> +++ b/drivers/gpio/gpio-dwapb.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -290,14 +291,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio 
> *gpio,
>struct dwapb_port_property *pp)
>  {
>   struct gpio_chip *gc = >gc;
> - struct device_node *node = pp->node;
> + struct fwnode_handle  *fwnode = pp->fwnode;
>   struct irq_chip_generic *irq_gc = NULL;
>   unsigned int hwirq, ngpio = gc->ngpio;
>   struct irq_chip_type *ct;
>   int err, i;
>  
> - gpio->domain = irq_domain_add_linear(node, ngpio,
> -  _generic_chip_ops, gpio);
> + gpio->domain = irq_domain_create_linear(fwnode, ngpio,
> +  _generic_chip_ops, gpio);
>   if (!gpio->domain)
>   return;
>  
> @@ -414,7 +415,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
>   }
>  
>  #ifdef CONFIG_OF_GPIO
> - port->gc.of_node = pp->node;
> + port->gc.of_node = is_of_node(pp->fwnode) ?
> + to_of_node(pp->fwnode) : NULL;

It is enough to use port->gc.of_node = to_of_node(pp->fwnode);

Re: [PATCH, RESEND 3] qla2xxx: Remove use of 'struct timeval'

[Martin K. Petersen]

> "Tina" == Tina Ruchandani  writes:

Tina,

>> Applied to 4.6/scsi-queue.

Tina> I am not seeing this patch in v4.6-rc3 in Linus's tree.

Not sure how I messed that up. Sorry!

Applied to 4.7/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH, RESEND 3] qla2xxx: Remove use of 'struct timeval'

[Martin K. Petersen]

> "Tina" == Tina Ruchandani  writes:

Tina,

>> Applied to 4.6/scsi-queue.

Tina> I am not seeing this patch in v4.6-rc3 in Linus's tree.

Not sure how I messed that up. Sorry!

Applied to 4.7/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts

[Jeff Kirsher]

On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan  wrote:
> Make adjustments to the Intel 10G VF driver to support
> running on Hyper-V hosts.
>
> K. Y. Srinivasan (2):
>   ethernet: intel: Add the device ID's presented while running on
> Hyper-V
>   intel: ixgbevf: Support Windows hosts (Hyper-V)
>
>  drivers/net/ethernet/intel/ixgbevf/defines.h  |5 +
>  drivers/net/ethernet/intel/ixgbevf/ixgbevf.h  |   11 ++
>  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   56 ++---
>  drivers/net/ethernet/intel/ixgbevf/mbx.c  |   12 ++
>  drivers/net/ethernet/intel/ixgbevf/vf.c   |  138 
> +
>  drivers/net/ethernet/intel/ixgbevf/vf.h   |2 +
>  6 files changed, 206 insertions(+), 18 deletions(-)

Don't know how you butchered the mailing list address, but you did not
send this series to intel-wired-...@lists.osuosl.org mailing list.
Please address the requested changes that Mark suggested and resubmit
to the correct mailing list please.

Re: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts

[Jeff Kirsher]

On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan  wrote:
> Make adjustments to the Intel 10G VF driver to support
> running on Hyper-V hosts.
>
> K. Y. Srinivasan (2):
>   ethernet: intel: Add the device ID's presented while running on
> Hyper-V
>   intel: ixgbevf: Support Windows hosts (Hyper-V)
>
>  drivers/net/ethernet/intel/ixgbevf/defines.h  |5 +
>  drivers/net/ethernet/intel/ixgbevf/ixgbevf.h  |   11 ++
>  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   56 ++---
>  drivers/net/ethernet/intel/ixgbevf/mbx.c  |   12 ++
>  drivers/net/ethernet/intel/ixgbevf/vf.c   |  138 
> +
>  drivers/net/ethernet/intel/ixgbevf/vf.h   |2 +
>  6 files changed, 206 insertions(+), 18 deletions(-)

Don't know how you butchered the mailing list address, but you did not
send this series to intel-wired-...@lists.osuosl.org mailing list.
Please address the requested changes that Mark suggested and resubmit
to the correct mailing list please.

Re: [PATCH 0/5] hisi_sas: v2 hw SATA fixes

[Martin K. Petersen]

> "John" == John Garry  writes:

John> This patchset introduces SATA support fixes for the HiSilicon v2
John> hw SAS controller.

John> Fixes include: - attach issue for SATA disk attached through
John> expander - intermittent issue for directly attaching multiple SATA
John> disks - add support for directly attaching SATA disk to phy index
John> 4+ - ITCT config issue

Applied to 4.7/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 0/5] hisi_sas: v2 hw SATA fixes

[Martin K. Petersen]

> "John" == John Garry  writes:

John> This patchset introduces SATA support fixes for the HiSilicon v2
John> hw SAS controller.

John> Fixes include: - attach issue for SATA disk attached through
John> expander - intermittent issue for directly attaching multiple SATA
John> disks - add support for directly attaching SATA disk to phy index
John> 4+ - ITCT config issue

Applied to 4.7/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

[Dave Chinner]

On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote:
> This lets userland get the filesystem freezing status, aka whether the
> filesystem is frozen or not. This is so that an application can know if
> it should freeze the filesystem or if it isn't necessary when taking a
> snapshot.

freezing nests, so there is no reason for avoiding a freeze when
doing a snapshot. Indeed, if you don't wrap freeze/thaw around a
snapshot, then if the fs is thawed while the snapshot is in progress
then you are going to get a corrupt snapshot

And, besides, polling for frozenness from userspace is inherently
racy - by the time the syscall returns, the information may be
incorrect, so you can't rely on it for decision making purposes in
userspace.

> +static int ioctl_fsgetfrozen(struct file *filp)
> +{
> + struct super_block *sb = file_inode(filp)->i_sb;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + return sb->s_writers.frozen;

This makes the internal freeze implementation states part of the
userspace ABI.  This needs an API that is separate from the internal
implementation...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

[Dave Chinner]

On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote:
> This lets userland get the filesystem freezing status, aka whether the
> filesystem is frozen or not. This is so that an application can know if
> it should freeze the filesystem or if it isn't necessary when taking a
> snapshot.

freezing nests, so there is no reason for avoiding a freeze when
doing a snapshot. Indeed, if you don't wrap freeze/thaw around a
snapshot, then if the fs is thawed while the snapshot is in progress
then you are going to get a corrupt snapshot

And, besides, polling for frozenness from userspace is inherently
racy - by the time the syscall returns, the information may be
incorrect, so you can't rely on it for decision making purposes in
userspace.

> +static int ioctl_fsgetfrozen(struct file *filp)
> +{
> + struct super_block *sb = file_inode(filp)->i_sb;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + return sb->s_writers.frozen;

This makes the internal freeze implementation states part of the
userspace ABI.  This needs an API that is separate from the internal
implementation...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v3 5/6] sched/deadline/rtmutex: Fix unprotected PI access in enqueue_task_dl()

[Xunlei Pang]

On 2016/04/15 at 09:58, Xunlei Pang wrote:
> On 2016/04/14 at 23:31, Peter Zijlstra wrote:
>> On Thu, Apr 14, 2016 at 07:37:06PM +0800, Xunlei Pang wrote:
>>> We access @pi_task's data without any lock in enqueue_task_dl(), though
>>> checked "dl_prio(pi_task->normal_prio)" condition, that's not enough.
>> The proper fix is to ensure that pi_task is guaranteed to be blocked.
> Even if pi_task was blocked, its parameters are still allowed to be changed,
> so we have to do that. Did I miss something?
>
> Regards,
> Xunlei

Fortunately, I just reproduced through an overnight test, so it really happened 
in reality as I thought.

[50697.042391] kernel BUG at kernel/sched/deadline.c:398!
[50697.048212] invalid opcode:  [#1] SMP
[50697.137676] CPU: 1 PID: 10676 Comm: bugon Tainted: GW   
4.6.0-rc3+ #19
[50697.146250] Hardware name: Intel Corporation Broadwell Client 
platform/SawTooth Peak, BIOS BDW-E1R1.86C.0127.R00.150
8062034 08/06/2015
[50697.159942] task: 880089d72b80 ti: 880074bb4000 task.ti: 
880074bb4000
[50697.168420] RIP: 0010:[]  [] 
replenish_dl_entity+0xff/0x110
[50697.178292] RSP: :88016ec43d90  EFLAGS: 00010046
[50697.184307] RAX: 0001 RBX: 880089d72d50 RCX: 0001
[50697.192390] RDX: 0010 RSI: 8800719858d0 RDI: 880089d72d50
[50697.200473] RBP: 88016ec43da8 R08: 0001 R09: 0097
[50697.208556] R10: 57102e72 R11: 0f9e6fd7 R12: 88016ec56e40
[50697.216638] R13: 88016ec56e40 R14: 00016e40 R15: 880089d72d50
[50697.224721] FS:  7f14e788b700() GS:88016ec4() 
knlGS:
[50697.233887] CS:  0010 DS:  ES:  CR0: 80050033
[50697.240396] CR2: 55be08240c68 CR3: 8a5d5000 CR4: 003406e0
[50697.248478] DR0:  DR1:  DR2: 
[50697.256561] DR3:  DR6: fffe0ff0 DR7: 0400
[50697.264643] Stack:
[50697.266917]  88016ec56e40 880089d72b80 0010 
88016ec43de8
[50697.275338]  810cbfe4 88016ec43de8 880089d72b80 
88016ec56e40
[50697.283757]  000188c5 880089d72d50 88016ec4f228 
88016ec43e18
[50697.292175] Call Trace:
[50697.294943]  
[50697.297122]  [] enqueue_task_dl+0x264/0x340
[50697.303838]  [] update_curr_dl+0x1c3/0x1f0
[50697.310249]  [] task_tick_dl+0x1c/0x80
[50697.316265]  [] scheduler_tick+0x5c/0xe0
[50697.322480]  [] ? tick_sched_do_timer+0x50/0x50
[50697.329383]  [] update_process_times+0x51/0x60
[50697.336188]  [] tick_sched_handle.isra.17+0x25/0x60
[50697.343486]  [] tick_sched_timer+0x3d/0x70
[50697.349895]  [] __hrtimer_run_queues+0xf3/0x270
[50697.356797]  [] hrtimer_interrupt+0xa8/0x1a0
[50697.363404]  [] local_apic_timer_interrupt+0x35/0x60
[50697.370799]  [] smp_apic_timer_interrupt+0x3d/0x50
[50697.377996]  [] apic_timer_interrupt+0x8c/0xa0
[50697.384798]  
[50697.384798]  
[50697.386974] Code: a9 48 c7 c7 38 5f a0 81 31 c0 48 89 75 e8 c6 05 5c 48 c8 
00 01 e8 74 20 0c 00 49 8b 84 24 28 09 00 00 8b 4b 54 48 8b 75 e8 eb c4 <0f> 0b 
0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
[50697.409201] RIP  [] replenish_dl_entity+0xff/0x110
[50697.416409]  RSP 
[50697.433683] ---[ end trace da6e1e42babefb7f ]---
[50697.438913] Kernel panic - not syncing: Fatal exception in interrupt
[50698.484088] Shutting down cpus with NMI
[50698.488434] Kernel Offset: disabled
[50698.492383] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Re: [PATCH v3 5/6] sched/deadline/rtmutex: Fix unprotected PI access in enqueue_task_dl()

[Xunlei Pang]

On 2016/04/15 at 09:58, Xunlei Pang wrote:
> On 2016/04/14 at 23:31, Peter Zijlstra wrote:
>> On Thu, Apr 14, 2016 at 07:37:06PM +0800, Xunlei Pang wrote:
>>> We access @pi_task's data without any lock in enqueue_task_dl(), though
>>> checked "dl_prio(pi_task->normal_prio)" condition, that's not enough.
>> The proper fix is to ensure that pi_task is guaranteed to be blocked.
> Even if pi_task was blocked, its parameters are still allowed to be changed,
> so we have to do that. Did I miss something?
>
> Regards,
> Xunlei

Fortunately, I just reproduced through an overnight test, so it really happened 
in reality as I thought.

[50697.042391] kernel BUG at kernel/sched/deadline.c:398!
[50697.048212] invalid opcode:  [#1] SMP
[50697.137676] CPU: 1 PID: 10676 Comm: bugon Tainted: GW   
4.6.0-rc3+ #19
[50697.146250] Hardware name: Intel Corporation Broadwell Client 
platform/SawTooth Peak, BIOS BDW-E1R1.86C.0127.R00.150
8062034 08/06/2015
[50697.159942] task: 880089d72b80 ti: 880074bb4000 task.ti: 
880074bb4000
[50697.168420] RIP: 0010:[]  [] 
replenish_dl_entity+0xff/0x110
[50697.178292] RSP: :88016ec43d90  EFLAGS: 00010046
[50697.184307] RAX: 0001 RBX: 880089d72d50 RCX: 0001
[50697.192390] RDX: 0010 RSI: 8800719858d0 RDI: 880089d72d50
[50697.200473] RBP: 88016ec43da8 R08: 0001 R09: 0097
[50697.208556] R10: 57102e72 R11: 0f9e6fd7 R12: 88016ec56e40
[50697.216638] R13: 88016ec56e40 R14: 00016e40 R15: 880089d72d50
[50697.224721] FS:  7f14e788b700() GS:88016ec4() 
knlGS:
[50697.233887] CS:  0010 DS:  ES:  CR0: 80050033
[50697.240396] CR2: 55be08240c68 CR3: 8a5d5000 CR4: 003406e0
[50697.248478] DR0:  DR1:  DR2: 
[50697.256561] DR3:  DR6: fffe0ff0 DR7: 0400
[50697.264643] Stack:
[50697.266917]  88016ec56e40 880089d72b80 0010 
88016ec43de8
[50697.275338]  810cbfe4 88016ec43de8 880089d72b80 
88016ec56e40
[50697.283757]  000188c5 880089d72d50 88016ec4f228 
88016ec43e18
[50697.292175] Call Trace:
[50697.294943]  
[50697.297122]  [] enqueue_task_dl+0x264/0x340
[50697.303838]  [] update_curr_dl+0x1c3/0x1f0
[50697.310249]  [] task_tick_dl+0x1c/0x80
[50697.316265]  [] scheduler_tick+0x5c/0xe0
[50697.322480]  [] ? tick_sched_do_timer+0x50/0x50
[50697.329383]  [] update_process_times+0x51/0x60
[50697.336188]  [] tick_sched_handle.isra.17+0x25/0x60
[50697.343486]  [] tick_sched_timer+0x3d/0x70
[50697.349895]  [] __hrtimer_run_queues+0xf3/0x270
[50697.356797]  [] hrtimer_interrupt+0xa8/0x1a0
[50697.363404]  [] local_apic_timer_interrupt+0x35/0x60
[50697.370799]  [] smp_apic_timer_interrupt+0x3d/0x50
[50697.377996]  [] apic_timer_interrupt+0x8c/0xa0
[50697.384798]  
[50697.384798]  
[50697.386974] Code: a9 48 c7 c7 38 5f a0 81 31 c0 48 89 75 e8 c6 05 5c 48 c8 
00 01 e8 74 20 0c 00 49 8b 84 24 28 09 00 00 8b 4b 54 48 8b 75 e8 eb c4 <0f> 0b 
0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
[50697.409201] RIP  [] replenish_dl_entity+0xff/0x110
[50697.416409]  RSP 
[50697.433683] ---[ end trace da6e1e42babefb7f ]---
[50697.438913] Kernel panic - not syncing: Fatal exception in interrupt
[50698.484088] Shutting down cpus with NMI
[50698.488434] Kernel Offset: disabled
[50698.492383] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

[Li, Aubrey]

On 2016/4/15 8:32, Darren Hart wrote:
> On Sun, Apr 10, 2016 at 09:46:48PM +0800, Li, Aubrey wrote:
>> On 2016/4/10 21:17, Andy Shevchenko wrote:
>>> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li  
>>> wrote:
 Currently the optional IPC resources prevent telemetry driver from
 probing if these resources are not in ACPI table. This patch decouples
 telemetry driver from these optional resources, so that telemetry driver
 has dependency only on the necessary ACPI resources.
>>>
>>> Darren, I have comments as well.
>>>

 Signed-off-by: Aubrey Li 
 ---
  drivers/platform/x86/intel_pmc_ipc.c   |   48 
 +++-
  drivers/platform/x86/intel_punit_ipc.c |   48 
 +---
  2 files changed, 54 insertions(+), 42 deletions(-)

 diff --git a/drivers/platform/x86/intel_pmc_ipc.c 
 b/drivers/platform/x86/intel_pmc_ipc.c
 index 092519e..29d9c02 100644
 --- a/drivers/platform/x86/intel_pmc_ipc.c
 +++ b/drivers/platform/x86/intel_pmc_ipc.c
 @@ -686,8 +686,8 @@ static int ipc_plat_get_res(struct platform_device 
 *pdev)
 ipcdev.acpi_io_size = size;
 dev_info(>dev, "io res: %pR\n", res);

 -   /* This is index 0 to cover BIOS data register */
 punit_res = punit_res_array;
 +   /* This is index 0 to cover BIOS data register */
 res = platform_get_resource(pdev, IORESOURCE_MEM,
 PLAT_RESOURCE_BIOS_DATA_INDEX);
 if (!res) {
 @@ -697,55 +697,51 @@ static int ipc_plat_get_res(struct platform_device 
 *pdev)
 *punit_res = *res;
 dev_info(>dev, "punit BIOS data res: %pR\n", res);

 +   /* This is index 1 to cover BIOS interface register */
 res = platform_get_resource(pdev, IORESOURCE_MEM,
 PLAT_RESOURCE_BIOS_IFACE_INDEX);
 if (!res) {
 dev_err(>dev, "Failed to get res of punit BIOS 
 iface\n");
 return -ENXIO;
 }
 -   /* This is index 1 to cover BIOS interface register */
 *++punit_res = *res;
 dev_info(>dev, "punit BIOS interface res: %pR\n", res);

 +   /* This is index 2 to cover ISP data register, optional */
>>>
>>> All above looks like a commentary fixes (except an additional
>>> 'optional' word in one case). Can you do this separately?
>>
>> I don't think it's necessary.
>>
> 
> This is typically necessary as you would not want the comment fixes above to 
> be
> backed out if the functional changes below were found to be buggy and 
> reverted.
> This is why we encourage small functional changes. It protects against
> inadvertent reverts and facilitates review.
> 
> That said, these comment changes continue below in a way that makes it a bit
> difficult to isolate them out, so I do not particularly object.

Yes, these comment changes are supposed to be together with the
functional changes, without functional changes, I won't touch these
comments.

> 
> That said, everyone should understand that Andy is part of the
> platform-driver-x86 maintainer team so please respect his comments as such.

I know Andy very well, we co-worked with PMC driver before, it was a
nice process.

> 
>>>
>>>
 res = platform_get_resource(pdev, IORESOURCE_MEM,
 PLAT_RESOURCE_ISP_DATA_INDEX);
 -   if (!res) {
 -   dev_err(>dev, "Failed to get res of punit ISP 
 data\n");
 -   return -ENXIO;
 +   ++punit_res;
 +   if (res) {
 +   *punit_res = *res;
 +   dev_info(>dev, "punit ISP data res: %pR\n", res);
>>>
>>> Okay, what if you re-arrange this to some helper first
>>>
>>
>> Thanks for the idea, but I don't like a helper here, did you see
>> anything harmful of the current implementation?
> 
> In both arguments, we need to identify the WHY.
> 
> I imagine Andy is trying to reduce the copy and paste potential for error as
> well as error introduction in future patches. There are... 7 or so cases with
> near identical usage, that's a compelling argument for a refactor such as the
> helper Andy suggests.
> 
> Aubrey, you said you don't like it. Why is that? Will it not save enough lines
> of code to be worth it? Are you concerned about revalidating the change?

dev_info with different strings makes the helper useless, or more
complex than desired if we have to write a helper here.

Also, we have necessary resource above, which returns directly if there
is a error. For the coding style consistency in a routine, I really
don't like we call platform_get_resource() directly at first and then
put it into a helper later. The current implementation is
straightforward and clean.

> 
> In my opinion, a refactor is a good 

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

[Li, Aubrey]

On 2016/4/15 8:32, Darren Hart wrote:
> On Sun, Apr 10, 2016 at 09:46:48PM +0800, Li, Aubrey wrote:
>> On 2016/4/10 21:17, Andy Shevchenko wrote:
>>> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li  
>>> wrote:
 Currently the optional IPC resources prevent telemetry driver from
 probing if these resources are not in ACPI table. This patch decouples
 telemetry driver from these optional resources, so that telemetry driver
 has dependency only on the necessary ACPI resources.
>>>
>>> Darren, I have comments as well.
>>>

 Signed-off-by: Aubrey Li 
 ---
  drivers/platform/x86/intel_pmc_ipc.c   |   48 
 +++-
  drivers/platform/x86/intel_punit_ipc.c |   48 
 +---
  2 files changed, 54 insertions(+), 42 deletions(-)

 diff --git a/drivers/platform/x86/intel_pmc_ipc.c 
 b/drivers/platform/x86/intel_pmc_ipc.c
 index 092519e..29d9c02 100644
 --- a/drivers/platform/x86/intel_pmc_ipc.c
 +++ b/drivers/platform/x86/intel_pmc_ipc.c
 @@ -686,8 +686,8 @@ static int ipc_plat_get_res(struct platform_device 
 *pdev)
 ipcdev.acpi_io_size = size;
 dev_info(>dev, "io res: %pR\n", res);

 -   /* This is index 0 to cover BIOS data register */
 punit_res = punit_res_array;
 +   /* This is index 0 to cover BIOS data register */
 res = platform_get_resource(pdev, IORESOURCE_MEM,
 PLAT_RESOURCE_BIOS_DATA_INDEX);
 if (!res) {
 @@ -697,55 +697,51 @@ static int ipc_plat_get_res(struct platform_device 
 *pdev)
 *punit_res = *res;
 dev_info(>dev, "punit BIOS data res: %pR\n", res);

 +   /* This is index 1 to cover BIOS interface register */
 res = platform_get_resource(pdev, IORESOURCE_MEM,
 PLAT_RESOURCE_BIOS_IFACE_INDEX);
 if (!res) {
 dev_err(>dev, "Failed to get res of punit BIOS 
 iface\n");
 return -ENXIO;
 }
 -   /* This is index 1 to cover BIOS interface register */
 *++punit_res = *res;
 dev_info(>dev, "punit BIOS interface res: %pR\n", res);

 +   /* This is index 2 to cover ISP data register, optional */
>>>
>>> All above looks like a commentary fixes (except an additional
>>> 'optional' word in one case). Can you do this separately?
>>
>> I don't think it's necessary.
>>
> 
> This is typically necessary as you would not want the comment fixes above to 
> be
> backed out if the functional changes below were found to be buggy and 
> reverted.
> This is why we encourage small functional changes. It protects against
> inadvertent reverts and facilitates review.
> 
> That said, these comment changes continue below in a way that makes it a bit
> difficult to isolate them out, so I do not particularly object.

Yes, these comment changes are supposed to be together with the
functional changes, without functional changes, I won't touch these
comments.

> 
> That said, everyone should understand that Andy is part of the
> platform-driver-x86 maintainer team so please respect his comments as such.

I know Andy very well, we co-worked with PMC driver before, it was a
nice process.

> 
>>>
>>>
 res = platform_get_resource(pdev, IORESOURCE_MEM,
 PLAT_RESOURCE_ISP_DATA_INDEX);
 -   if (!res) {
 -   dev_err(>dev, "Failed to get res of punit ISP 
 data\n");
 -   return -ENXIO;
 +   ++punit_res;
 +   if (res) {
 +   *punit_res = *res;
 +   dev_info(>dev, "punit ISP data res: %pR\n", res);
>>>
>>> Okay, what if you re-arrange this to some helper first
>>>
>>
>> Thanks for the idea, but I don't like a helper here, did you see
>> anything harmful of the current implementation?
> 
> In both arguments, we need to identify the WHY.
> 
> I imagine Andy is trying to reduce the copy and paste potential for error as
> well as error introduction in future patches. There are... 7 or so cases with
> near identical usage, that's a compelling argument for a refactor such as the
> helper Andy suggests.
> 
> Aubrey, you said you don't like it. Why is that? Will it not save enough lines
> of code to be worth it? Are you concerned about revalidating the change?

dev_info with different strings makes the helper useless, or more
complex than desired if we have to write a helper here.

Also, we have necessary resource above, which returns directly if there
is a error. For the coding style consistency in a routine, I really
don't like we call platform_get_resource() directly at first and then
put it into a helper later. The current implementation is
straightforward and clean.

> 
> In my opinion, a refactor is a good suggestion, but I would be OK with this
> patch as it is 

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Konrad Rzeszutek Wilk]

On Thu, Apr 14, 2016 at 11:12:01PM +0200, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote:
> > > This has nothing to do with dominance or anything nefarious, I'm asking
> > > simply for a full engineering evaluation of all possibilities, with
> > > the long term in mind. Not for now, but for hardware assumptions which
> > > are sensible 5 years from now.
> > 
> > There are two different things in my mind about this conversation:
> > 
> >  1). semantics of low-level code wrapped around pvops. On baremetal
> >it is easy - just look at Intel and AMD SDM.
> >And this is exactly what running in HVM or HVMLite mode will do -
> >all those low-level operations will have the same exact semantic
> >as baremetal.
> 
> Today Linux is KVM stupid for early boot code. I've pointed this out

-EPARSE?
> before, but again, there has been no reason found to need this. Perhaps
> for HVMLite we won't need this...

Are you talking about kvmtools? Which BTW are similar to how HVMLite
would expose the platform.
> 
> >There is no hope for the pv_ops to fix that.
> 
> Actually I beg to differ. See my patches and ongoing work.

I meant in terms of semantics. As in I cannot see some of
those pv-ops to have the same semantics as baremetal. For example
set_pte is simple on x86 (movq $, ).

While on Xen PV it is a potential batching hypercall with
lookup in an P2M table, then perhaps a sidelong look at
the M2P, then maybe the M2P override.

> 
> >And I am pretty sure the HVMLite in 5 years will have no
> >trouble in this as it will be running in VMX mode (HVM).
> 
> HVMLite may still use PV drivers for some things, its not super
> obvious to me that low level semantics will not be needed yet.

PV drivers are very different from low-level semantics.

And it will have to use them.

Maybe it is easier to think of this in terms of kvmtool - it
is pretty much how this would work - but instead of VirtIO
drivers you would be using the Xen PV drivers (thought one
could also use VirtIO ones if you wanted).
> 
> >  2). Boot entry.
> > 
> >The semantics on Linux are well known - they are documented in
> >Documentation/x86/boot.txt.
> > 
> >HVMLite Linux guests have to somehow provide that.
> > 
> >And how it is done seems to be tied around:
> > 
> >a) Use existing boot paths - which means making some
> >   extra stub code to call in those existing boot paths
> >   (for example Xen could bundle with an GRUB2-alike
> >code to be run when booting Linux using that boot-path).
> > 
> >   Or EFI (for a ton more code). Granted not all OSes
> >   support those, so not very OS agnostic.
> 
> What other OSes do is something to consider but if they don't
> do it because they are slacking in one domain should by no means
> be a reason to not evaluate the long term possible gains.
> Specially if we have reasons to believe more architectures will
> consider it and standardize on it.
> 
> It'd be silly not to take this a bit more seriously.

Complexity vs simplicity.
> 
> >Hard part - if the bootparams change then have to
> >   rev up the code in there. May be out of sync
> >   with Linux bootparams.
> 
> If we are going to ultimately standardize on EFI boot for new
> hardware it'd be rather silly to extend the boot params further.

Whoa there... Have you spoken to hpa,tglrx about this?

> 
> >b) Add another simpler boot entry point which has to copy
> >  "some" strings from its format in bootparams.
> > 
> > 
> >So this part of the discussion does not fall in the
> >hardware assumptions. Intel SDM or AMD mention nothing about
> >boot loaders or how to boot an OS - that is all in realms
> >of how software talks to software.
> 
> Right -- so one question to ask here is what other uses are there
> for this outside of say HVMLite. You mentioned Multiboot so far.
> 
> >  3). And there is the discussion on man-power to make this
> >happen.
> 
> Sure.
> 
> >  4). Lastly which one is simpler and involves less code so
> > that there is a less chance of bitrot.
> 
> Indeed.
> 
> You also forgot the tie-in between dead-code and semantics but

Wait, I just spoke about CPU semantics?! Which semantics
are you talking about?
> that clearly is not on your mind. But I'd say this is a good
> summary.

I put 'dead code' in the same realm as device drivers work.
And they seem to always have some issue or another.
Or maybe I getting unlucky and getting copied on those bugs.
> 
>   Luis

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Konrad Rzeszutek Wilk]

On Thu, Apr 14, 2016 at 11:12:01PM +0200, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote:
> > > This has nothing to do with dominance or anything nefarious, I'm asking
> > > simply for a full engineering evaluation of all possibilities, with
> > > the long term in mind. Not for now, but for hardware assumptions which
> > > are sensible 5 years from now.
> > 
> > There are two different things in my mind about this conversation:
> > 
> >  1). semantics of low-level code wrapped around pvops. On baremetal
> >it is easy - just look at Intel and AMD SDM.
> >And this is exactly what running in HVM or HVMLite mode will do -
> >all those low-level operations will have the same exact semantic
> >as baremetal.
> 
> Today Linux is KVM stupid for early boot code. I've pointed this out

-EPARSE?
> before, but again, there has been no reason found to need this. Perhaps
> for HVMLite we won't need this...

Are you talking about kvmtools? Which BTW are similar to how HVMLite
would expose the platform.
> 
> >There is no hope for the pv_ops to fix that.
> 
> Actually I beg to differ. See my patches and ongoing work.

I meant in terms of semantics. As in I cannot see some of
those pv-ops to have the same semantics as baremetal. For example
set_pte is simple on x86 (movq $, ).

While on Xen PV it is a potential batching hypercall with
lookup in an P2M table, then perhaps a sidelong look at
the M2P, then maybe the M2P override.

> 
> >And I am pretty sure the HVMLite in 5 years will have no
> >trouble in this as it will be running in VMX mode (HVM).
> 
> HVMLite may still use PV drivers for some things, its not super
> obvious to me that low level semantics will not be needed yet.

PV drivers are very different from low-level semantics.

And it will have to use them.

Maybe it is easier to think of this in terms of kvmtool - it
is pretty much how this would work - but instead of VirtIO
drivers you would be using the Xen PV drivers (thought one
could also use VirtIO ones if you wanted).
> 
> >  2). Boot entry.
> > 
> >The semantics on Linux are well known - they are documented in
> >Documentation/x86/boot.txt.
> > 
> >HVMLite Linux guests have to somehow provide that.
> > 
> >And how it is done seems to be tied around:
> > 
> >a) Use existing boot paths - which means making some
> >   extra stub code to call in those existing boot paths
> >   (for example Xen could bundle with an GRUB2-alike
> >code to be run when booting Linux using that boot-path).
> > 
> >   Or EFI (for a ton more code). Granted not all OSes
> >   support those, so not very OS agnostic.
> 
> What other OSes do is something to consider but if they don't
> do it because they are slacking in one domain should by no means
> be a reason to not evaluate the long term possible gains.
> Specially if we have reasons to believe more architectures will
> consider it and standardize on it.
> 
> It'd be silly not to take this a bit more seriously.

Complexity vs simplicity.
> 
> >Hard part - if the bootparams change then have to
> >   rev up the code in there. May be out of sync
> >   with Linux bootparams.
> 
> If we are going to ultimately standardize on EFI boot for new
> hardware it'd be rather silly to extend the boot params further.

Whoa there... Have you spoken to hpa,tglrx about this?

> 
> >b) Add another simpler boot entry point which has to copy
> >  "some" strings from its format in bootparams.
> > 
> > 
> >So this part of the discussion does not fall in the
> >hardware assumptions. Intel SDM or AMD mention nothing about
> >boot loaders or how to boot an OS - that is all in realms
> >of how software talks to software.
> 
> Right -- so one question to ask here is what other uses are there
> for this outside of say HVMLite. You mentioned Multiboot so far.
> 
> >  3). And there is the discussion on man-power to make this
> >happen.
> 
> Sure.
> 
> >  4). Lastly which one is simpler and involves less code so
> > that there is a less chance of bitrot.
> 
> Indeed.
> 
> You also forgot the tie-in between dead-code and semantics but

Wait, I just spoke about CPU semantics?! Which semantics
are you talking about?
> that clearly is not on your mind. But I'd say this is a good
> summary.

I put 'dead code' in the same realm as device drivers work.
And they seem to always have some issue or another.
Or maybe I getting unlucky and getting copied on those bugs.
> 
>   Luis

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Konrad Rzeszutek Wilk]

On Thu, Apr 14, 2016 at 10:56:19PM +0200, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote:
> > > On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Apr 14, 2016 at 12:23:17AM +0200, Luis R. Rodriguez wrote:
> > > > > VGA code will be dead code for HVMlite for sure as the design doc
> > > > > says it will not run VGA, the ACPI flag will be set but the check
> > > > > for that is not yet on Linux. That means the VGA Linux code will
> > > > > be there but we have no way to ensure it will not run nor that
> > > > > anything will muck with it.
> > > > 
> > > >  The worst it will do is try to read non-existent registers.
> > > 
> > > Really ?
> > > 
> > > Is that your position on all other possible dead code that may have been
> > > possible on old Xen PV guests as well ?
> > 
> > This is not just with Xen - it with other device drivers that are being
> > invoked on baremetal and are not present in hardware anymore.
> 
> Indeed, however virtualization makes this issue much more prominent.

I suppose - as it only exposes a certain type of platform and nothing
else.
> 
> > > As I hinted, after thinking about this for a while I realized that dead 
> > > code is
> > > likely present on bare metal as well even without virtualization, 
> > > specially if
> > 
> > Yes!
> > > you build large single kernels to support a wide array of features which 
> > > only
> > > late at run time can be determined. Virtualization and the pvops design 
> > > just
> > > makes this issue much more prominent. If there are other areas of code 
> > > exposed
> > > that actually may run, but we are not sure may run, I figured some other 
> > > folks
> > > with a bit more security conscience minds might even simply take the 
> > > position
> > > it may be a security risk to leave that code exposed. So to take a 
> > > position
> > > that 'the worst it will do is try to read non-existent registers' -- seems
> > > rather shortsighted here.
> > 
> > Security conscious people trim their CONFIG.
> 
> Not all Linux distributions want to do this, the more binaries the
> higher the cost to test / vet.

OK, but Linux distributions have many goals - and are pulled in
different directions so they cannot always achieve the 'low footprint -
small amount of code to do inspection from security standpoint'

> 
> > > Anyway for more details on thoughts on this refer to the this wiki:
> > > 
> > > http://kernelnewbies.org/KernelProjects/kernel-sandboxing
> > > 
> > > Since this is now getting off topic please send me your feedback on 
> > > another
> > > thread for the non-virtualization aspects of this if that interests you. 
> > > My
> > > point here was rather to highlight the importance of clear semantics due 
> > > to
> > > virtualization in light of possible dead code.
> > 
> > Thank you.
> > > 
> > > > The VGA code should be able to handle failures like that and
> > > > not initialize itself when the hardware is dead (or non-existent).
> > > 
> > > That's right, its through ACPI_FADT_NO_VGA and since its part of the 
> > > HVMLite
> > > design doc we want HVMlite design to address ACPI_FADT_NO_VGA properly.  
> > > I've
> > > paved the way for this to be done cleanly and easily now, but that code 
> > > should
> > > be in place before HVMLite code gets merged.
> > > 
> > > Does domU for old Xen PV also set ACPI_FADT_NO_VGA as well ?  Should it ?
> > 
> > It does not. Not sure - it seems to have worked fine for the last ten
> > years?
> 
> Maybe HVMLite will need it enabled then too, just for bug parity.

 Sure.
> 
> > > > > To be clear -- dead code concerns still exist even without
> > > > > virtualization solutions, its just that with virtualization
> > > > > this stuff comes up more and there has been no proactive
> > > > > measures to address this. The question of semantics here is
> > > > > to see to what extent we need earlier boot code annotations
> > > > > to ensure we address semantics proactively.
> > > > 
> > > > I think what you mean by dead code is another word for
> > > > hardware test coverage?
> > > 
> > > No, no, its very different given that with virtualization the scope of 
> > > possible
> > > dead code is significant and at run time you are certain a huge portion 
> > > of code
> > > should *never ever* run. So for instance we know once we boot bare metal 
> > > none
> > > of the Xen stuff should ever run, likewise on Xen dom0 we know none of 
> > > the KVM
> > > / bare-metal only stuff should never run, when on Xen domU, none of the 
> > > Xen
> > 
> > What is this 'bare metal only stuff' you speak of? On Xen dom0 most of
> > the baremetal code is running.
> 
> A lot, not all. In the past folks added stubs (used to be paravirt_enabled()
> checks) to some code, but we are simply not sure of other possible conflicts.
> This is an known unknown if you will.
> 
> > In fact that is 

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Konrad Rzeszutek Wilk]

On Thu, Apr 14, 2016 at 10:56:19PM +0200, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote:
> > > On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Apr 14, 2016 at 12:23:17AM +0200, Luis R. Rodriguez wrote:
> > > > > VGA code will be dead code for HVMlite for sure as the design doc
> > > > > says it will not run VGA, the ACPI flag will be set but the check
> > > > > for that is not yet on Linux. That means the VGA Linux code will
> > > > > be there but we have no way to ensure it will not run nor that
> > > > > anything will muck with it.
> > > > 
> > > >  The worst it will do is try to read non-existent registers.
> > > 
> > > Really ?
> > > 
> > > Is that your position on all other possible dead code that may have been
> > > possible on old Xen PV guests as well ?
> > 
> > This is not just with Xen - it with other device drivers that are being
> > invoked on baremetal and are not present in hardware anymore.
> 
> Indeed, however virtualization makes this issue much more prominent.

I suppose - as it only exposes a certain type of platform and nothing
else.
> 
> > > As I hinted, after thinking about this for a while I realized that dead 
> > > code is
> > > likely present on bare metal as well even without virtualization, 
> > > specially if
> > 
> > Yes!
> > > you build large single kernels to support a wide array of features which 
> > > only
> > > late at run time can be determined. Virtualization and the pvops design 
> > > just
> > > makes this issue much more prominent. If there are other areas of code 
> > > exposed
> > > that actually may run, but we are not sure may run, I figured some other 
> > > folks
> > > with a bit more security conscience minds might even simply take the 
> > > position
> > > it may be a security risk to leave that code exposed. So to take a 
> > > position
> > > that 'the worst it will do is try to read non-existent registers' -- seems
> > > rather shortsighted here.
> > 
> > Security conscious people trim their CONFIG.
> 
> Not all Linux distributions want to do this, the more binaries the
> higher the cost to test / vet.

OK, but Linux distributions have many goals - and are pulled in
different directions so they cannot always achieve the 'low footprint -
small amount of code to do inspection from security standpoint'

> 
> > > Anyway for more details on thoughts on this refer to the this wiki:
> > > 
> > > http://kernelnewbies.org/KernelProjects/kernel-sandboxing
> > > 
> > > Since this is now getting off topic please send me your feedback on 
> > > another
> > > thread for the non-virtualization aspects of this if that interests you. 
> > > My
> > > point here was rather to highlight the importance of clear semantics due 
> > > to
> > > virtualization in light of possible dead code.
> > 
> > Thank you.
> > > 
> > > > The VGA code should be able to handle failures like that and
> > > > not initialize itself when the hardware is dead (or non-existent).
> > > 
> > > That's right, its through ACPI_FADT_NO_VGA and since its part of the 
> > > HVMLite
> > > design doc we want HVMlite design to address ACPI_FADT_NO_VGA properly.  
> > > I've
> > > paved the way for this to be done cleanly and easily now, but that code 
> > > should
> > > be in place before HVMLite code gets merged.
> > > 
> > > Does domU for old Xen PV also set ACPI_FADT_NO_VGA as well ?  Should it ?
> > 
> > It does not. Not sure - it seems to have worked fine for the last ten
> > years?
> 
> Maybe HVMLite will need it enabled then too, just for bug parity.

 Sure.
> 
> > > > > To be clear -- dead code concerns still exist even without
> > > > > virtualization solutions, its just that with virtualization
> > > > > this stuff comes up more and there has been no proactive
> > > > > measures to address this. The question of semantics here is
> > > > > to see to what extent we need earlier boot code annotations
> > > > > to ensure we address semantics proactively.
> > > > 
> > > > I think what you mean by dead code is another word for
> > > > hardware test coverage?
> > > 
> > > No, no, its very different given that with virtualization the scope of 
> > > possible
> > > dead code is significant and at run time you are certain a huge portion 
> > > of code
> > > should *never ever* run. So for instance we know once we boot bare metal 
> > > none
> > > of the Xen stuff should ever run, likewise on Xen dom0 we know none of 
> > > the KVM
> > > / bare-metal only stuff should never run, when on Xen domU, none of the 
> > > Xen
> > 
> > What is this 'bare metal only stuff' you speak of? On Xen dom0 most of
> > the baremetal code is running.
> 
> A lot, not all. In the past folks added stubs (used to be paravirt_enabled()
> checks) to some code, but we are simply not sure of other possible conflicts.
> This is an known unknown if you will.
> 
> > In fact that is 

Re: [PATCH v6 3/4] soc: mediatek: Add MT2701 power dt-bindings

[James Liao]

Hi Yingjoe,

On Thu, 2016-04-14 at 18:56 +0800, Yingjoe Chen wrote:
> On Thu, 2016-04-14 at 16:16 +0800, James Liao wrote:
> > From: Shunli Wang 
> > 
> > Add power dt-bindings for MT2701.
> > 
> > Signed-off-by: Shunli Wang 
> > Signed-off-by: James Liao 
> > Acked-by: Rob Herring 
> > Reviewed-by: Kevin Hilman 
> > ---
> >  .../devicetree/bindings/soc/mediatek/scpsys.txt| 12 ++
> >  include/dt-bindings/power/mt2701-power.h   | 27 
> > ++
> >  2 files changed, 34 insertions(+), 5 deletions(-)
> >  create mode 100644 include/dt-bindings/power/mt2701-power.h
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
> > b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > index e8f15e3..ebb3144 100644
> > --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > @@ -9,17 +9,19 @@ domain control.
> >  
> >  The driver implements the Generic PM domain bindings described in
> >  power/power_domain.txt. It provides the power domains defined in
> > -include/dt-bindings/power/mt8173-power.h.
> > +include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
> >  
> >  Required properties:
> > -- compatible: Must be "mediatek,mt8173-scpsys"
> > +- compatible: Should be one of:
> > +   - "mediatek,mt2701-scpsys"
> > +   - "mediatek,mt8173-scpsys"
> >  - #power-domain-cells: Must be 1
> >  - reg: Address range of the SCPSYS unit
> >  - infracfg: must contain a phandle to the infracfg controller
> >  - clock, clock-names: clocks according to the common clock binding.
> > -  The clocks needed "mm", "mfg", "venc" and "venc_lt".
> > - These are the clocks which hardware needs to be enabled
> > - before enabling certain power domains.
> > +  The clocks needed "mm", "mfg", "venc", "venc_lt" and
> > +  "ethif". These are the clocks which hardware needs 
> > to be
> > +  enabled before enabling certain power domains.
> 
> 
> Clock ethif only exist on mt2701 so it is not required on mt8173.

You are right. Each SoC needs different clock for each power domain.
Here list all subsystems of available SoCs.



Best regards,

James

Re: [PATCH v6 3/4] soc: mediatek: Add MT2701 power dt-bindings

[James Liao]

Hi Yingjoe,

On Thu, 2016-04-14 at 18:56 +0800, Yingjoe Chen wrote:
> On Thu, 2016-04-14 at 16:16 +0800, James Liao wrote:
> > From: Shunli Wang 
> > 
> > Add power dt-bindings for MT2701.
> > 
> > Signed-off-by: Shunli Wang 
> > Signed-off-by: James Liao 
> > Acked-by: Rob Herring 
> > Reviewed-by: Kevin Hilman 
> > ---
> >  .../devicetree/bindings/soc/mediatek/scpsys.txt| 12 ++
> >  include/dt-bindings/power/mt2701-power.h   | 27 
> > ++
> >  2 files changed, 34 insertions(+), 5 deletions(-)
> >  create mode 100644 include/dt-bindings/power/mt2701-power.h
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
> > b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > index e8f15e3..ebb3144 100644
> > --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> > @@ -9,17 +9,19 @@ domain control.
> >  
> >  The driver implements the Generic PM domain bindings described in
> >  power/power_domain.txt. It provides the power domains defined in
> > -include/dt-bindings/power/mt8173-power.h.
> > +include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
> >  
> >  Required properties:
> > -- compatible: Must be "mediatek,mt8173-scpsys"
> > +- compatible: Should be one of:
> > +   - "mediatek,mt2701-scpsys"
> > +   - "mediatek,mt8173-scpsys"
> >  - #power-domain-cells: Must be 1
> >  - reg: Address range of the SCPSYS unit
> >  - infracfg: must contain a phandle to the infracfg controller
> >  - clock, clock-names: clocks according to the common clock binding.
> > -  The clocks needed "mm", "mfg", "venc" and "venc_lt".
> > - These are the clocks which hardware needs to be enabled
> > - before enabling certain power domains.
> > +  The clocks needed "mm", "mfg", "venc", "venc_lt" and
> > +  "ethif". These are the clocks which hardware needs 
> > to be
> > +  enabled before enabling certain power domains.
> 
> 
> Clock ethif only exist on mt2701 so it is not required on mt8173.

You are right. Each SoC needs different clock for each power domain.
Here list all subsystems of available SoCs.



Best regards,

James