Hi all,
I've uploaded today's linux-next tree to the master branch of the
repository below:
git://gitorious.org/thierryreding/linux-next.git
A next-20131016 tag is also provided for convenience.
Gained two new conflicts, but nothing too exciting. x86 and ARM default
configurations as well as the x86 allmodconfig mostly build fine on the
final tree. There was a failure for the ARM at91x40_defconfig, but the
proper fix wasn't immediately obvious to me, so I've left it broken for
now.
Thierry
Today's linux-next merge of the tip tree got a conflict in
include/linux/wait.h
caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
(sched/wait: Clean up wait.h details a bit).
I've cleaned it up (see below). Please verify that the resolution looks
good.
Thanks,
Thierry
---
diff --cc include/linux/wait.h
index d9eff54,a2726c7..0395985
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@@ -253,59 -275,9 +275,45 @@@ do {
__ret; \
})
+#define __wait_event_cmd(wq, condition, cmd1, cmd2) \
+do { \
+ DEFINE_WAIT(__wait); \
+ \
+ for (;;) { \
+ prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE); \
+ if (condition) \
+ break; \
+ cmd1; \
+ schedule(); \
+ cmd2; \
+ } \
+ finish_wait(&wq, &__wait); \
+} while (0)
+
+/**
+ * wait_event_cmd - sleep until a condition gets true
+ * @wq: the waitqueue to wait on
+ * @condition: a C expression for the event to wait for
+ * cmd1: the command will be executed before sleep
+ * cmd2: the command will be executed after sleep
+ *
+ * The process is put to sleep (TASK_UNINTERRUPTIBLE) until the
+ * @condition evaluates to true. The @condition is checked each time
+ * the waitqueue @wq is woken up.
+ *
+ * wake_up() has to be called after changing any variable that could
+ * change the result of the wait condition.
+ */
+#define wait_event_cmd(wq, condition, cmd1, cmd2) \
+do { \
+ if (condition) \
+ break; \
+ __wait_event_cmd(wq, condition, cmd1, cmd2); \
+} while (0)
+
- #define __wait_event_interruptible(wq, condition, ret) \
- do { \
- DEFINE_WAIT(__wait); \
- \
- for (;;) { \
- prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE); \
- if (condition) \
- break; \
- if (!signal_pending(current)) { \
- schedule(); \
- continue; \
- } \
- ret = -ERESTARTSYS; \
- break; \
- } \
- finish_wait(&wq, &__wait); \
- } while (0)
+ #define __wait_event_interruptible(wq, condition) \
+ ___wait_event(wq, condition, TASK_INTERRUPTIBLE, 0, 0, \
+ schedule())
/**
* wait_event_interruptible - sleep until a condition gets true
Today's linux-next merge of the kvm-arm tree got conflicts in
arch/arm/kvm/reset.c
caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and ac570e0
(ARM: kvm: rename cpu_reset to avoid name clash).
I've fixed them up (see below). Please verify that the resolution looks
good.
Thanks,
Thierry
---
diff --cc arch/arm/kvm/reset.c
index c02ba4a,d9bbd83..d153e64
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@@ -62,12 -62,13 +62,13 @@@ int kvm_reset_vcpu(struct kvm_vcpu *vcp
const struct kvm_irq_level *cpu_vtimer_irq;
switch (vcpu->arch.target) {
+ case KVM_ARM_TARGET_CORTEX_A7:
case KVM_ARM_TARGET_CORTEX_A15:
- if (vcpu->vcpu_id > a15_max_cpu_idx)
+ if (vcpu->vcpu_id > cortexa_max_cpu_idx)
return -EINVAL;
- reset_regs = &a15_regs_reset;
- cpu_reset = &cortexa_regs_reset;
++ reset_regs = &cortexa_regs_reset;
vcpu->arch.midr = read_cpuid_id();
- cpu_vtimer_irq = &a15_vtimer_irq;
+ cpu_vtimer_irq = &cortexa_vtimer_irq;
break;
default:
return -ENODEV;
On 16/10/13 19:51, Thierry Reding wrote:
> Today's linux-next merge of the kvm-arm tree got conflicts in
>
> arch/arm/kvm/reset.c
>
> caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and ac570e0
> (ARM: kvm: rename cpu_reset to avoid name clash).
>
> I've fixed them up (see below). Please verify that the resolution looks
> good.
Looks good to me (I have the same resolution in my own tree).
Thanks Thierry.
M.
> Thanks,
> Thierry
> ---
> diff --cc arch/arm/kvm/reset.c
> index c02ba4a,d9bbd83..d153e64
> --- a/arch/arm/kvm/reset.c
> +++ b/arch/arm/kvm/reset.c
> @@@ -62,12 -62,13 +62,13 @@@ int kvm_reset_vcpu(struct kvm_vcpu *vcp
> const struct kvm_irq_level *cpu_vtimer_irq;
>
> switch (vcpu->arch.target) {
> + case KVM_ARM_TARGET_CORTEX_A7:
> case KVM_ARM_TARGET_CORTEX_A15:
> - if (vcpu->vcpu_id > a15_max_cpu_idx)
> + if (vcpu->vcpu_id > cortexa_max_cpu_idx)
> return -EINVAL;
> - reset_regs = &a15_regs_reset;
> - cpu_reset = &cortexa_regs_reset;
> ++ reset_regs = &cortexa_regs_reset;
> vcpu->arch.midr = read_cpuid_id();
> - cpu_vtimer_irq = &a15_vtimer_irq;
> + cpu_vtimer_irq = &cortexa_vtimer_irq;
> break;
> default:
> return -ENODEV;
>
--
Jazz is not dead. It just smells funny...
On 16 October 2013 11:58, Marc Zyngier <[email protected]> wrote:
> On 16/10/13 19:51, Thierry Reding wrote:
>> Today's linux-next merge of the kvm-arm tree got conflicts in
>>
>> arch/arm/kvm/reset.c
>>
>> caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and ac570e0
>> (ARM: kvm: rename cpu_reset to avoid name clash).
>>
>> I've fixed them up (see below). Please verify that the resolution looks
>> good.
>
> Looks good to me (I have the same resolution in my own tree).
>
Yes, fix is good.
This will stay a conflict until kvm/next and kvm/fixes merge, which
doesn't happen before after the merge window, usually. If that's
going to cause too many headaches, maybe we need to talk to the KVM
guys (cc'ed) about a solution until then.
Thanks,
-Christoffer
On Wed, Oct 16, 2013 at 12:02:08PM -0700, Christoffer Dall wrote:
> On 16 October 2013 11:58, Marc Zyngier <[email protected]> wrote:
> > On 16/10/13 19:51, Thierry Reding wrote:
> >> Today's linux-next merge of the kvm-arm tree got conflicts in
> >>
> >> arch/arm/kvm/reset.c
> >>
> >> caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and ac570e0
> >> (ARM: kvm: rename cpu_reset to avoid name clash).
> >>
> >> I've fixed them up (see below). Please verify that the resolution looks
> >> good.
> >
> > Looks good to me (I have the same resolution in my own tree).
> >
> Yes, fix is good.
>
> This will stay a conflict until kvm/next and kvm/fixes merge, which
> doesn't happen before after the merge window, usually. If that's
> going to cause too many headaches, maybe we need to talk to the KVM
> guys (cc'ed) about a solution until then.
It shouldn't be a problem. Mark and I share the rerere cache, so unless
the conflict changes somehow it'll get resolved automatically in future
merges.
Thierry
On 16 October 2013 12:04, Thierry Reding <[email protected]> wrote:
> On Wed, Oct 16, 2013 at 12:02:08PM -0700, Christoffer Dall wrote:
>> On 16 October 2013 11:58, Marc Zyngier <[email protected]> wrote:
>> > On 16/10/13 19:51, Thierry Reding wrote:
>> >> Today's linux-next merge of the kvm-arm tree got conflicts in
>> >>
>> >> arch/arm/kvm/reset.c
>> >>
>> >> caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and ac570e0
>> >> (ARM: kvm: rename cpu_reset to avoid name clash).
>> >>
>> >> I've fixed them up (see below). Please verify that the resolution looks
>> >> good.
>> >
>> > Looks good to me (I have the same resolution in my own tree).
>> >
>> Yes, fix is good.
>>
>> This will stay a conflict until kvm/next and kvm/fixes merge, which
>> doesn't happen before after the merge window, usually. If that's
>> going to cause too many headaches, maybe we need to talk to the KVM
>> guys (cc'ed) about a solution until then.
>
> It shouldn't be a problem. Mark and I share the rerere cache, so unless
> the conflict changes somehow it'll get resolved automatically in future
> merges.
>
Cool, I had no idea how you dealt with these merges, but I figured a
daily manual operation was probably not how it works:)
On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> Today's linux-next merge of the tip tree got a conflict in
>
> include/linux/wait.h
>
> caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> (sched/wait: Clean up wait.h details a bit).
Gargh, where did that come from?!
On Wed, Oct 16, 2013 at 10:06:45PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got a conflict in
> >
> > include/linux/wait.h
> >
> > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > (sched/wait: Clean up wait.h details a bit).
>
> Gargh, where did that come from?!
Also, wth does that live?
# git show 1ab2460
fatal: ambiguous argument '1ab2460': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
# git remote show next
* remote next
Fetch URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
And I made sure to update the remote.
On Wed, 16 Oct 2013 22:14:10 +0200 Peter Zijlstra <[email protected]>
wrote:
> On Wed, Oct 16, 2013 at 10:06:45PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > > Today's linux-next merge of the tip tree got a conflict in
> > >
> > > include/linux/wait.h
> > >
> > > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > > (sched/wait: Clean up wait.h details a bit).
> >
> > Gargh, where did that come from?!
>
> Also, wth does that live?
>
>
> # git show 1ab2460
> fatal: ambiguous argument '1ab2460': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
> # git remote show next
> * remote next
> Fetch URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
> And I made sure to update the remote.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
It seems to have moved to
git://gitorious.org/thierryreding/linux-next.git
NeilBrown
On Thu, Oct 17, 2013 at 07:31:00AM +1100, NeilBrown wrote:
> It seems to have moved to
> git://gitorious.org/thierryreding/linux-next.git
Uhm.. what happened to sfr and why would we trust gitorious?
On Wed, Oct 16, 2013 at 10:14:10PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 16, 2013 at 10:06:45PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > > Today's linux-next merge of the tip tree got a conflict in
> > >
> > > include/linux/wait.h
> > >
> > > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > > (sched/wait: Clean up wait.h details a bit).
> >
> > Gargh, where did that come from?!
>
> Also, wth does that live?
>
>
> # git show 1ab2460
> fatal: ambiguous argument '1ab2460': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
> # git remote show next
> * remote next
> Fetch URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
> And I made sure to update the remote.
Mark and I use this repository as a temporary location:
git://gitorious.org/thierryreding/linux-next.git
If we ever decide to do this again when Stephen's on vacation, we should
try to get shared access setup for the kernel.org repository. Providing
temporary service was a spontaneous decision, so we didn't prepare very
well. Sorry for the inconvenience.
Thierry
On Wed, Oct 16, 2013 at 10:06:45PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got a conflict in
> >
> > include/linux/wait.h
> >
> > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > (sched/wait: Clean up wait.h details a bit).
>
> Gargh, where did that come from?!
FWIW, commit 1ab2460 came in through Neil's md tree.
Thierry
On Wed, Oct 16, 2013 at 10:35:06PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 17, 2013 at 07:31:00AM +1100, NeilBrown wrote:
> > It seems to have moved to
> > git://gitorious.org/thierryreding/linux-next.git
>
> Uhm.. what happened to sfr and why would we trust gitorious?
sfr is on vacation. Back at the time when Mark Brown and I volunteered
to continue doing the linux-next trees in Stephen's absence I didn't
have a kernel.org account. Also we decided rather late that we wanted to
do this so there was no time to set things up properly. We had to make
do with what we had.
Today's next-20131016 tag is signed with my GPG key that I use for my
kernel.org account as well, so that should make it about equally trust-
worthy as anything I'd be pushing to kernel.org.
Thierry
Hey Neil;
it looks like its one of your patches isn't it?
http://www.spinics.net/lists/raid/msg44100.html
http://www.spinics.net/lists/raid/msg44101.html
Given that I can't find them in a lkml archive means nobody's ever seen
those patches.
Anyway; has that 3/3 patch ever been ran with lockdep enabled?
Stuff like:
+ for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
+ spin_lock_init(conf->hash_locks + i);
And:
+static void __lock_all_hash_locks(struct r5conf *conf)
+{
+ int i;
+ for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
+ spin_lock(conf->hash_locks + i);
+}
Tends to complain real loud.
This leaves one to wonder...
'fancy' locking scheme:1, validation effort:0
On Wed, Oct 16, 2013 at 10:51:15PM +0200, Thierry Reding wrote:
> On Wed, Oct 16, 2013 at 10:35:06PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 17, 2013 at 07:31:00AM +1100, NeilBrown wrote:
> > > It seems to have moved to
> > > git://gitorious.org/thierryreding/linux-next.git
> >
> > Uhm.. what happened to sfr and why would we trust gitorious?
>
> sfr is on vacation. Back at the time when Mark Brown and I volunteered
> to continue doing the linux-next trees in Stephen's absence I didn't
> have a kernel.org account. Also we decided rather late that we wanted to
> do this so there was no time to set things up properly. We had to make
> do with what we had.
>
> Today's next-20131016 tag is signed with my GPG key that I use for my
> kernel.org account as well, so that should make it about equally trust-
> worthy as anything I'd be pushing to kernel.org.
Fair enough; and thanks for doing this.
On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> Today's linux-next merge of the tip tree got a conflict in
>
> include/linux/wait.h
>
> caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> (sched/wait: Clean up wait.h details a bit).
>
> I've cleaned it up (see below). Please verify that the resolution looks
> good.
> +#define __wait_event_cmd(wq, condition, cmd1, cmd2) \
> +do { \
> + DEFINE_WAIT(__wait); \
> + \
> + for (;;) { \
> + prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE); \
> + if (condition) \
> + break; \
> + cmd1; \
> + schedule(); \
> + cmd2; \
> + } \
> + finish_wait(&wq, &__wait); \
> +} while (0)
Ideally we'd write the new thing like:
#define __wait_event_cmd(wq, condition, cmd1, cmd2) \
(void)___wait_event(wq, condition, TASK_UNINTERRUPTIBLE, 0, 0, \
cmd1; schedule(); cmd2)
On 10/16/13 11:51, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131016 tag is also provided for convenience.
>
> Gained two new conflicts, but nothing too exciting. x86 and ARM default
> configurations as well as the x86 allmodconfig mostly build fine on the
> final tree. There was a failure for the ARM at91x40_defconfig, but the
> proper fix wasn't immediately obvious to me, so I've left it broken for
> now.
on i386, when CONFIG_NET_NS is not enabled:
net/sched/em_ipset.c: In function 'em_ipset_change':
net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named 'nd_net'
net/sched/em_ipset.c: In function 'em_ipset_destroy':
net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named 'nd_net'
--
~Randy
On Wed, 16 Oct 2013 14:48:32 -0700
Randy Dunlap <[email protected]> wrote:
> On 10/16/13 11:51, Thierry Reding wrote:
> > Hi all,
> >
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> >
> > git://gitorious.org/thierryreding/linux-next.git
> >
> > A next-20131016 tag is also provided for convenience.
> >
> > Gained two new conflicts, but nothing too exciting. x86 and ARM default
> > configurations as well as the x86 allmodconfig mostly build fine on the
> > final tree. There was a failure for the ARM at91x40_defconfig, but the
> > proper fix wasn't immediately obvious to me, so I've left it broken for
> > now.
>
> on i386, when CONFIG_NET_NS is not enabled:
>
> net/sched/em_ipset.c: In function 'em_ipset_change':
> net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named 'nd_net'
> net/sched/em_ipset.c: In function 'em_ipset_destroy':
> net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named 'nd_net'
>
>
I think this should fix.
--- a/net/sched/em_ipset.c 2013-10-06 14:48:25.030449222 -0700
+++ b/net/sched/em_ipset.c 2013-10-16 15:38:05.030278287 -0700
@@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
{
struct xt_set_info *set = data;
ip_set_id_t index;
- struct net *net = qdisc_dev(tp->q)->nd_net;
+ struct net *net = dev_net(qdisc_dev(tp->q));
if (data_len != sizeof(*set))
return -EINVAL;
@@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
{
const struct xt_set_info *set = (const void *) em->data;
if (set) {
- ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
+ ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
kfree((void *) em->data);
}
}
On 10/16/13 15:39, Stephen Hemminger wrote:
> On Wed, 16 Oct 2013 14:48:32 -0700
> Randy Dunlap <[email protected]> wrote:
>
>> On 10/16/13 11:51, Thierry Reding wrote:
>>> Hi all,
>>>
>>> I've uploaded today's linux-next tree to the master branch of the
>>> repository below:
>>>
>>> git://gitorious.org/thierryreding/linux-next.git
>>>
>>> A next-20131016 tag is also provided for convenience.
>>>
>>> Gained two new conflicts, but nothing too exciting. x86 and ARM default
>>> configurations as well as the x86 allmodconfig mostly build fine on the
>>> final tree. There was a failure for the ARM at91x40_defconfig, but the
>>> proper fix wasn't immediately obvious to me, so I've left it broken for
>>> now.
>>
>> on i386, when CONFIG_NET_NS is not enabled:
>>
>> net/sched/em_ipset.c: In function 'em_ipset_change':
>> net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named 'nd_net'
>> net/sched/em_ipset.c: In function 'em_ipset_destroy':
>> net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named 'nd_net'
>>
>>
>
> I think this should fix.
>
That works. Thanks.
Acked-by: Randy Dunlap <[email protected]>
>
>
> --- a/net/sched/em_ipset.c 2013-10-06 14:48:25.030449222 -0700
> +++ b/net/sched/em_ipset.c 2013-10-16 15:38:05.030278287 -0700
> @@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
> {
> struct xt_set_info *set = data;
> ip_set_id_t index;
> - struct net *net = qdisc_dev(tp->q)->nd_net;
> + struct net *net = dev_net(qdisc_dev(tp->q));
>
> if (data_len != sizeof(*set))
> return -EINVAL;
> @@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
> {
> const struct xt_set_info *set = (const void *) em->data;
> if (set) {
> - ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
> + ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
> kfree((void *) em->data);
> }
> }
> --
--
~Randy
Randy found that if network namespace not enabled then
nd_net does not exist and would cause compilation failure.
This is handled correctly by using the dev_net() macro.
Signed-off-by: Stephen Hemminger <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
--- a/net/sched/em_ipset.c 2013-10-06 14:48:25.030449222 -0700
+++ b/net/sched/em_ipset.c 2013-10-16 15:38:05.030278287 -0700
@@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
{
struct xt_set_info *set = data;
ip_set_id_t index;
- struct net *net = qdisc_dev(tp->q)->nd_net;
+ struct net *net = dev_net(qdisc_dev(tp->q));
if (data_len != sizeof(*set))
return -EINVAL;
@@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
{
const struct xt_set_info *set = (const void *) em->data;
if (set) {
- ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
+ ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
kfree((void *) em->data);
}
}
On 10/16/13 11:51, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131016 tag is also provided for convenience.
>
> Gained two new conflicts, but nothing too exciting. x86 and ARM default
> configurations as well as the x86 allmodconfig mostly build fine on the
> final tree. There was a failure for the ARM at91x40_defconfig, but the
> proper fix wasn't immediately obvious to me, so I've left it broken for
> now.
on x86_64:
drivers/built-in.o: In function `mcam_v4l_open':
mcam-core.c:(.text+0x4eed2b): undefined reference to `vb2_dma_sg_memops'
CONFIG_VIDEOBUF2_DMA_SG=m
Full randconfig file is attached.
--
~Randy
On Wed, 16 Oct 2013 22:52:07 +0200 Peter Zijlstra <[email protected]>
wrote:
> Hey Neil;
>
> it looks like its one of your patches isn't it?
>
> http://www.spinics.net/lists/raid/msg44100.html
> http://www.spinics.net/lists/raid/msg44101.html
>
> Given that I can't find them in a lkml archive means nobody's ever seen
> those patches.
>
> Anyway; has that 3/3 patch ever been ran with lockdep enabled?
I always run with lockdep enabled, and I have done at least basic testing
(I've been on leave for a few weeks and don't remember exactly where I got
to).
And I haven't seen any lockdep reports.
>
> Stuff like:
>
> + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> + spin_lock_init(conf->hash_locks + i);
>
> And:
>
> +static void __lock_all_hash_locks(struct r5conf *conf)
> +{
> + int i;
> + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> + spin_lock(conf->hash_locks + i);
> +}
>
> Tends to complain real loud.
Why is that?
Because "conf->hash_locks + i" gets used as the "name" of the lockdep map for
each one, and when they are all locked it looks like nested locking??
the lock_all_hash_locks doesn't get called very often and my testing mustn't
have got that far. I just tried something that would trigger the
"lock_all_device_hash_locks_irq" (as it is in the current version) and it
went "splat" just as you said it would.
Thanks.
Do you have a suggestion for how to make this work?
Would
spin_lock_nested(conf->hash_locks + i, i)
do the trick?
Thanks,
NeilBrown
>
> This leaves one to wonder...
> 'fancy' locking scheme:1, validation effort:0
>
On Wed, 16 Oct 2013 23:30:05 +0200 Peter Zijlstra <[email protected]>
wrote:
> On Wed, Oct 16, 2013 at 08:51:39PM +0200, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got a conflict in
> >
> > include/linux/wait.h
> >
> > caused by commits 1ab2460 (wait: add wait_event_cmd()) and fb869b6
> > (sched/wait: Clean up wait.h details a bit).
> >
> > I've cleaned it up (see below). Please verify that the resolution looks
> > good.
>
> > +#define __wait_event_cmd(wq, condition, cmd1, cmd2) \
> > +do { \
> > + DEFINE_WAIT(__wait); \
> > + \
> > + for (;;) { \
> > + prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE); \
> > + if (condition) \
> > + break; \
> > + cmd1; \
> > + schedule(); \
> > + cmd2; \
> > + } \
> > + finish_wait(&wq, &__wait); \
> > +} while (0)
>
> Ideally we'd write the new thing like:
>
> #define __wait_event_cmd(wq, condition, cmd1, cmd2) \
> (void)___wait_event(wq, condition, TASK_UNINTERRUPTIBLE, 0, 0, \
> cmd1; schedule(); cmd2)
>
Oooo.. that looks much nicer. I'll make it look like that before it goes
upstream.
Thanks,
NeilBrown
On 10/16/2013 11:51 AM, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131016 tag is also provided for convenience.
>
> Gained two new conflicts, but nothing too exciting. x86 and ARM default
> configurations as well as the x86 allmodconfig mostly build fine on the
> final tree. There was a failure for the ARM at91x40_defconfig, but the
> proper fix wasn't immediately obvious to me, so I've left it broken for
> now.
>
Upside: mips qemu run now passes (mips64 qemu build still fails).
Downside: Up to 13 build failures, from 12.
Besides the mips64 qemu build, current failures are:
arm:allmodconfig
blackfin:defconfig
mips:nlm_xlp_defconfig
mips:cavium_octeon_defconfig
powerpc: (7 out of 14)
sparc64:allmodconfig
xtensa:allmodconfig (new failure)
Details are at http://server.roeck-us.net:8010/builders.
Guenter
On Thu, Oct 17, 2013 at 12:28:59PM +1100, NeilBrown wrote:
> I always run with lockdep enabled, and I have done at least basic testing
Very good!
> >
> > Stuff like:
> >
> > + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> > + spin_lock_init(conf->hash_locks + i);
> >
> > And:
> >
> > +static void __lock_all_hash_locks(struct r5conf *conf)
> > +{
> > + int i;
> > + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> > + spin_lock(conf->hash_locks + i);
> > +}
> >
> > Tends to complain real loud.
>
> Why is that?
> Because "conf->hash_locks + i" gets used as the "name" of the lockdep map for
> each one, and when they are all locked it looks like nested locking??
Exactly so; they all share the same class (and name) because they have
the same init site; so indeed the multiple lock will look like a nested
lock.
> Do you have a suggestion for how to make this work?
> Would
> spin_lock_nested(conf->hash_locks + i, i)
> do the trick?
spin_lock_nest_lock(conf->hash_locks + i, &conf->device_lock);
Would be the better option; your suggestion might just work because
NR_STRIP_HASH_LOCKS is 8 and we have exactly 8 subclasses available, but
any increase to NR_STRIPE_HASH_LOCKS will make things explode again.
The spin_lock_nest_lock() annotation tells that the lock order is
irrelevant because all such multiple acquisitions are serialized under
the other lock.
Also, if in future you feel the need to increase NR_STRIP_HASH_LOCKS,
please keep it <= 64 or so; if you have a need to go above that, please
yell and we'll see if we can do something smarter.
This is because of:
- each spin_lock() increases preempt_count and that's 8 bits; we
wouldn't want to overflow that
- each consecutive nested spin_lock() increases the total acquisition
wait-time for all locks. Note that the worst case acquisition time
for even a single hash lock is gated by the complete acquisition time
of all of them in this scenario.
On Wed, Oct 16, 2013 at 12:02:08PM -0700, Christoffer Dall wrote:
> On 16 October 2013 11:58, Marc Zyngier <[email protected]> wrote:
> > On 16/10/13 19:51, Thierry Reding wrote:
> >> Today's linux-next merge of the kvm-arm tree got conflicts in
> >>
> >> arch/arm/kvm/reset.c
> >>
> >> caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and ac570e0
> >> (ARM: kvm: rename cpu_reset to avoid name clash).
> >>
> >> I've fixed them up (see below). Please verify that the resolution looks
> >> good.
> >
> > Looks good to me (I have the same resolution in my own tree).
> >
> Yes, fix is good.
>
> This will stay a conflict until kvm/next and kvm/fixes merge, which
> doesn't happen before after the merge window, usually. If that's
So in this case it happened today because part of powerpc patches where
based on commit after -rc4 and I had to merge to be able to pull them.
Christoffer can you look at queue branch of kvm.git and see that the
resolution is correct?
--
Gleb.
On 17 October 2013 07:55, Gleb Natapov <[email protected]> wrote:
> On Wed, Oct 16, 2013 at 12:02:08PM -0700, Christoffer Dall wrote:
>> On 16 October 2013 11:58, Marc Zyngier <[email protected]> wrote:
>> > On 16/10/13 19:51, Thierry Reding wrote:
>> >> Today's linux-next merge of the kvm-arm tree got conflicts in
>> >>
>> >> arch/arm/kvm/reset.c
>> >>
>> >> caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and ac570e0
>> >> (ARM: kvm: rename cpu_reset to avoid name clash).
>> >>
>> >> I've fixed them up (see below). Please verify that the resolution looks
>> >> good.
>> >
>> > Looks good to me (I have the same resolution in my own tree).
>> >
>> Yes, fix is good.
>>
>> This will stay a conflict until kvm/next and kvm/fixes merge, which
>> doesn't happen before after the merge window, usually. If that's
> So in this case it happened today because part of powerpc patches where
> based on commit after -rc4 and I had to merge to be able to pull them.
> Christoffer can you look at queue branch of kvm.git and see that the
> resolution is correct?
>
Yes, the resolution is correct. Thanks.
From: Stephen Hemminger <[email protected]>
Date: Wed, 16 Oct 2013 17:29:34 -0700
> Randy found that if network namespace not enabled then
> nd_net does not exist and would cause compilation failure.
>
> This is handled correctly by using the dev_net() macro.
>
> Signed-off-by: Stephen Hemminger <[email protected]>
> Acked-by: Randy Dunlap <[email protected]>
Applied, thanks everyone.
On Thu, 17 Oct 2013 11:23:49 +0200 Peter Zijlstra <[email protected]>
wrote:
> On Thu, Oct 17, 2013 at 12:28:59PM +1100, NeilBrown wrote:
> > I always run with lockdep enabled, and I have done at least basic testing
>
> Very good!
>
> > >
> > > Stuff like:
> > >
> > > + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> > > + spin_lock_init(conf->hash_locks + i);
> > >
> > > And:
> > >
> > > +static void __lock_all_hash_locks(struct r5conf *conf)
> > > +{
> > > + int i;
> > > + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> > > + spin_lock(conf->hash_locks + i);
> > > +}
> > >
> > > Tends to complain real loud.
> >
> > Why is that?
> > Because "conf->hash_locks + i" gets used as the "name" of the lockdep map for
> > each one, and when they are all locked it looks like nested locking??
>
> Exactly so; they all share the same class (and name) because they have
> the same init site; so indeed the multiple lock will look like a nested
> lock.
>
> > Do you have a suggestion for how to make this work?
> > Would
> > spin_lock_nested(conf->hash_locks + i, i)
> > do the trick?
>
> spin_lock_nest_lock(conf->hash_locks + i, &conf->device_lock);
Unfortunately this doesn't work as the order is backwards.
hash_lock is taken first, then (when necessary) device lock.
(hash_lock is needed more often, so we split it up to reduce contention.
device lock is needed less often, but sometimes when hash_lock is held).
I've currently got:
spin_lock_init(conf->hash_locks);
for (i = 1; i < NR_STRIPE_HASH_LOCKS; i++)
spin_lock_init(conf->hash_locks + i);
and
spin_lock(conf->hash_locks);
for (i = 1; i < NR_STRIPE_HASH_LOCKS; i++)
spin_lock_nest_lock(conf->hash_locks + i, conf->hash_locks);
spin_lock(&conf->device_lock);
which doesn't trigger any lockdep warnings and isn't too ugly.
Does it seem OK to you?
Thanks,
NeilBrown
>
> Would be the better option; your suggestion might just work because
> NR_STRIP_HASH_LOCKS is 8 and we have exactly 8 subclasses available, but
> any increase to NR_STRIPE_HASH_LOCKS will make things explode again.
>
> The spin_lock_nest_lock() annotation tells that the lock order is
> irrelevant because all such multiple acquisitions are serialized under
> the other lock.
>
> Also, if in future you feel the need to increase NR_STRIP_HASH_LOCKS,
> please keep it <= 64 or so; if you have a need to go above that, please
> yell and we'll see if we can do something smarter.
I've added a comment to this effect in the code.
>
> This is because of:
> - each spin_lock() increases preempt_count and that's 8 bits; we
> wouldn't want to overflow that
> - each consecutive nested spin_lock() increases the total acquisition
> wait-time for all locks. Note that the worst case acquisition time
> for even a single hash lock is gated by the complete acquisition time
> of all of them in this scenario.